-03 published
This commit is contained in:
parent
9de16ce8a5
commit
ddcb56caea
1 changed files with 37 additions and 27 deletions
|
|
@ -129,13 +129,13 @@
|
|||
attribute may modify this attribute according to the local
|
||||
policy."</t>
|
||||
|
||||
<t>A basic operational need is to add or remove one or more
|
||||
communities to the received set. Another common need is to replace
|
||||
all received communities with a new set. To simplify the second
|
||||
case, most BGP policy implementations provide syntax to "set"
|
||||
community that operators use to mean "remove any/all communities
|
||||
present on the update received from the neighbor, and apply this set
|
||||
of communities instead."</t>
|
||||
<t>One basic operational need is to add or remove one or more
|
||||
communities to the received set. The focus of this document is
|
||||
another common operational need, to replace all communities with a
|
||||
new set. To simplify this second case, most BGP policy
|
||||
implementations provide syntax to "set" community that operators use
|
||||
to mean "remove any/all communities present on the route, and apply
|
||||
this set of communities instead."</t>
|
||||
|
||||
<t>Some operators prefer to write explicit policy to delete unwanted
|
||||
communities rather than using "set;" i.e. using a "delete community
|
||||
|
|
@ -144,7 +144,8 @@
|
|||
manipulation policy differences described in the following section
|
||||
exist in both "set" and "delete community *:*" syntax. For
|
||||
simplicity, the remainder of this document refers only to the "set"
|
||||
behaviors.</t>
|
||||
behaviors, which we refer to collectively as each implementation's
|
||||
'"set" directive.'</t>
|
||||
|
||||
</section>
|
||||
|
||||
|
|
@ -168,10 +169,10 @@
|
|||
<t>In this section we document the syntax and observed behavior of
|
||||
the "set" directive in several popular BGP implementations.</t>
|
||||
|
||||
<t>In Juniper Networks' JunOS, "community set" removes all received
|
||||
<t>In Juniper Networks' Junos OS, "community set" removes all received
|
||||
communities, Well-Known or otherwise.</t>
|
||||
|
||||
<t>In Cisco Systems' IOS-XR, "set community" removes all received
|
||||
<t>In Cisco Systems' IOS XR, "set community" removes all received
|
||||
communities except for the following:</t>
|
||||
|
||||
<texttable anchor="cisco">
|
||||
|
|
@ -184,16 +185,16 @@
|
|||
<c>65535:65281</c> <c>NO_EXPORT</c>
|
||||
<c>65535:65282</c> <c>NO_ADVERTISE</c>
|
||||
<c>65535:65283</c> <c>NO_EXPORT_SUBCONFED (or local-AS)</c>
|
||||
<postamble>Communities not removed by Cisco IOS/XR</postamble>
|
||||
<postamble>Communities not removed by Cisco IOS XR</postamble>
|
||||
</texttable>
|
||||
|
||||
<t>IOS-XR does allow Well-Known communities to be removed one at a
|
||||
<t>IOS XR does allow Well-Known communities to be removed one at a
|
||||
time by explicit policy; for example, "delete community accept-own".
|
||||
Operators are advised to consult IOS-XR documentation and/or Cisco
|
||||
Operators are advised to consult IOS XR documentation and/or Cisco
|
||||
Systems support for full details.</t>
|
||||
|
||||
<t>On Brocade NetIron: "set community X" removes all communities and
|
||||
sets X.</t>
|
||||
<t>On Extreme networks' Brocade NetIron: "set community X" removes
|
||||
all communities and sets X.</t>
|
||||
|
||||
<t>In Huawei's VRP product, "community set" removes all received
|
||||
communities, well-Known or otherwise.</t>
|
||||
|
|
@ -201,16 +202,21 @@
|
|||
<t>In OpenBSD's OpenBGPD, "set community" does not remove any
|
||||
communities, Well-Known or otherwise.</t>
|
||||
|
||||
<t>Nokia's SR OS has several directives that operate on communities.
|
||||
Its "set" directive is called using the "replace" keyword, replacing
|
||||
all communities, Well-Known or otherwise, with the specified
|
||||
communities.</t>
|
||||
|
||||
<section anchor="ianalist" title="Note on an Inconsistency">
|
||||
|
||||
<t>The IANA publishes a list of Well-Known Communities <xref
|
||||
target="IANA-WKS"/>.</t>
|
||||
|
||||
<t>IOS-XR's set of well-known communities that "set community"
|
||||
<t>IOS XR's set of well-known communities that "set community"
|
||||
will not overwrite diverges from IANA's list. Quite a few
|
||||
well-known communities from IANA's list do not receive special
|
||||
treatment in IOS-XR, and at least one specific community on
|
||||
IOS-XR's special treatment list (internet == 0:0) is not really
|
||||
treatment in IOS XR, and at least one specific community on
|
||||
IOS XR's special treatment list (internet == 0:0) is not really
|
||||
on IANA's list -- it's taken from the "Reserved" range
|
||||
[0x00000000-0x0000FFFF].</t>
|
||||
|
||||
|
|
@ -221,8 +227,7 @@
|
|||
|
||||
</section>
|
||||
|
||||
<section anchor="note" title="Note for Those Writing RFCs for New
|
||||
Community-Like Attributes">
|
||||
<section anchor="note" title="Note for Those Writing RFCs for New Community-Like Attributes">
|
||||
|
||||
<t>Care should be taken when establishing new <xref
|
||||
target="RFC1997"/>-like attributes (large communities, wide
|
||||
|
|
@ -238,13 +243,17 @@
|
|||
<t>Vendors SHOULD clearly document the behavior of "set" directive
|
||||
in their implementations.</t>
|
||||
|
||||
<t>Vendors MUST ensure that any Well-Known Communities specified
|
||||
after this document's publication are removed by their "set"
|
||||
directive.</t>
|
||||
<t>Vendors MUST ensure that their implementations' "set" directive
|
||||
treatment of any specific community does not change if/when that
|
||||
community becomes a new Well-Known Community through future
|
||||
standardization. For most implementations, this means that the
|
||||
"set" directive MUST continue to remove the community; for those
|
||||
implementations where the "set" directive removes no communities,
|
||||
that behavior MUST continue.</t>
|
||||
|
||||
<t>Given the implementation inconsistencies described in this
|
||||
document, network operators are urged never to rely on any implicit
|
||||
understanding of a neighbor ASN's bgp community handling. I.e.,
|
||||
understanding of a neighbor ASN's BGP community handling. I.e.,
|
||||
before announcing prefixes with NO_EXPORT or any other community to
|
||||
a neighbor ASN, the operator should confirm with that neighbor how
|
||||
the community will be treated.</t>
|
||||
|
|
@ -271,10 +280,11 @@
|
|||
|
||||
</section>
|
||||
|
||||
<section anchor="acks" title="Acknowledgements">
|
||||
<section anchor="acks" title="Acknowledgments">
|
||||
|
||||
<t>The authors thank Martijn Schmidt, Qin Wu for the Huawei data
|
||||
point, Job Snijders, David Farmer,John Heasley, and Jakob Heitz.</t>
|
||||
point, Greg Hankins, Job Snijders, David Farmer, John Heasley, and
|
||||
Jakob Heitz.</t>
|
||||
|
||||
</section>
|
||||
</middle>
|
||||
|
|
@ -286,7 +296,7 @@
|
|||
<?rfc include="reference.RFC.1997"?>
|
||||
<reference anchor="IANA-WKS" target="https://www.iana.org/assignments/bgp-well-known-communities/bgp-well-known-communities.xhtml">
|
||||
<front>
|
||||
<title>IANA Well-Known Comunities</title>
|
||||
<title>IANA Well-Known Communities</title>
|
||||
<author/>
|
||||
<date/>
|
||||
</front>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue