One document matched: draft-ietf-grow-bgp-redistribution-00.txt
Internet Engineering Task Force Olivier Bonaventure
INTERNET DRAFT UCL
Stefaan De Cnodder
Alcatel
Jeffrey Haas
NextHop
Bruno Quoitin
FUNDP
Russ White
Cisco
April, 2003
Expires October, 2003
Controlling the redistribution of BGP routes
<draft-ietf-grow-bgp-redistribution-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document proposes the redistribution extended community. This
new extended community allows a router to influence how a specific
route should be redistributed towards a specified set of eBGP
speakers. Several types of redistribution communities are proposed.
The first type may be used to indicate that a specific route should
not be announced over a specified set of eBGP sessions. The second
type may be used to indicate that the attached route should only be
Bonaventure et al. [Page 1]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
announced with the NO_EXPORT community over the specified set of eBGP
sessions and the third type may be used to indicate that the attached
route should be prepended n times when announced over a specified set
of eBGP sessions.
1 Introduction
In today's commercial Internet, many ISPs need to have some control
on their inter-domain traffic. In the outgoing direction, this
control can be obtained by configuring the BGP routers of the ISP to
favor some routes over others by using the LOCAL-PREF attribute.
However, due to the asymetry of Internet traffic, most ISPs also need
to control their incoming traffic.
+---------------+
| |
| AS22 |
| |
+---------------+
||
+---------------+ +---------------+
| 13.0.0.0/8 | | AS21 |
| 12.0.0.0/8 |===============| |
| AS20 | +---------------+
+---------------+
||
+---------------+
| |
| AS10 |
| |
+---------------+
Figure 1: Simple inter-domain topology
In the incoming direction, the only way to influence the traffic flow
is to control the redistribution of its routes. Several methods exist
and are used in practice [Halabi97,COM-SUR]. In this case, the ISP
needs to influence the redistribution and the selection of its own
routes by remote ISPs. Since the default configuration of many BGP
routers is to select the route with the smallest AS path length, a
common technique is to artificially increase the length of the AS
path for some announced routes. For example, in figure 1, if AS20
wanted to indicate that it prefers to receive its traffic towards
subnet 13.0.0.0/8 through its link with AS22, then it would announce
this prefix as usual on this link to AS22 and announce a prefix with
the AS20:AS20:AS20:AS20 path to AS21 and AS10. If AS10 and AS21 use
the AS path length to select the best BGP route, they will prefer the
Bonaventure et al. [Page 2]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
shorter route received by AS22. This requires manual configuration of
the BGP routers, but path prepending is very frequently used today on
the Internet [Huston01]. In some cases, the configuration burden can
be reduced by using the BGP communities attribute.
Recently, several large ISPs have gone one step further by defining
BGP communities that allow their customers to influence the
redistribution of their routes. For example, in figure 1, AS20 could
configure its BGP routers to always prepend AS20 four times when they
announce via eBGP a route received from one of AS20's customers with
a special community attribute. For this, AS20 needs to publish the
specific BGP communities that it supports and its customers need to
configure their router appropriately. If AS20 needs to define a new
BGP community or change an existing one, it must inform all its
customers may need to update the configuration of their routers.
A more detailed survey of the utilization of the BGP community
attribute by ISPs may be found in [COM-SUR]. This survey reveals the
following:
- Many different ASes define their own BGP community values
to allow their customers/peers to indicate that a
particular route should not be propagated towards a specific AS,
towards the routers attached to a specific IX, or towards ASes
within a given geographical area (e.g. a European AS could want
to prohibit a route from being announced to US peers).
- Many ASes define their own BGP community values
to allow their peers or customers to indicate that an
announced route should be prepended when announced towards a
specific AS, IX or set of ASes.
- Several ASes define their own BGP community attribute to indicate
that a given route should only be redistributed towards a
specified AS.
Furthermore, this survey also reveals that some ASes have difficulty
providing all these facilities while still relying on their assigned
set of BGP community values. For example, some ASes have chosen to
reuse several BGP community values in the private AS space (i.e.
community values 64512:00 - 65534:65535) to be able to define
structured communities that allow their customers to influence the
redistribution of their routes. Some of these community values
appear in BGP tables on the global Internet.
Although the survey shows that these BGP communities are widely used
today to provide such facilities, this is far from the best solution.
Requiring each AS to select its own values for the BGP communities
and to document these values in the routing registries is not very
efficient because it forces the BGP routers to be configured manually
based on information found in these registries, peering agreements,
Bonaventure et al. [Page 3]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
or elsewhere.
In this document, we define a new type of BGP extended community. By
using a set BGP extended communities with a precise syntax, we
support most of the current utilizations of the BGP community without
relying unnecessarily on manual configuration of the BGP routers. We
believe that reducing the manual configuration of these routers would
be very useful for the stability and the performance of the global
Internet.
2 Controlled redistribution of BGP routes
This document defines a method to allow a BGP speaker to influence
how its peers will redistribute its own routes. For this, the BGP
speaker may define for each announced route a redistribution policy
that controls how this route will be redistributed. This is done by
defining a set of allowed or requested operations and a list of BGP
speakers. The list of BGP speakers can be specified by listing either
the BGP speakers that are covered by the redistribution policy or
those that are not covered by this policy. The current version of
this document supports the following operations:
- the attached route should not be announced to the specified BGP
speakers
- the attached route should only be announced to the specified BGP
speakers
- the attached route should be announced with the NO_EXPORT
attribute to the specified BGP speakers
- the attached route should be prepended n times when announced to
to the specified BGP speakers
The redistribution policies are encoded in a special type of
extended community called the redistribution community. If a
redistribution policy applies to several of BGP speakers, then it
will be encoded in several redistribution communities.
2.1 The redistribution community
The extended communities attribute is defined in [EXT-COM]. This
Bonaventure et al. [Page 4]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
attribute allows a BGP router to attach a set of extended communi
ties to an UPDATE message. Each extended community value is encoded
as an eight octets quantity with a one or two octets type field and
a six or seven octet value field. Several types of extended commu
nity values are defined in [EXT-COM]. This document proposes a new
well-known extended community: the redistribution community.
The redistribution community is composed of a one octet type field
(regular type). It is encoded as defined in [EXT-COM]. The high-
order bit is cleared (type assigned by IANA). Since the redistribu
tion community is only used for signalling purposes between two
neighbor AS's, bit6 is set meaning that the extended community is
non-transitive across ASes. This is important to ensure that com
munities used to affect the redistribution of routes by a given AS
are not unnecessarily distributed over the entire Internet as it is
often the case today [COM-SUR]. The remaining 6 lower-order bits
are to be defined by IANA (TBDTBD notation in figure 1).
1 octet 1 octet 6 octets
+--------+--------+---------------------+
|01TBDTBD| Action | BGP_Speakers_Filter |
+--------+--------+---------------------+
Figure 1: Encoding of the redistribution community
The remaining 7 octets of the redistribution community indicate how
a router will advertise the received route to its peers. This
requires two pieces of information: a filter to select a subset of
BGP speakers and an action that indicates how the attached route
should be redistributed to the selected BGP speakers. The high-
order octet indicates the action to be taken and the 6 remaining
octets define the filter.
The Action octet is encoded as follow:
- The high and the second order bits (Bit7 and Bit6) are reserved
and set to zero in this document
- Bit5-3 are the Action type
- Bit2-0 are the Action parameters
Action types
This document defines three types of actions (values 000b - 010b).
Values 011b-111b are reserved for future use and are to be assigned
Bonaventure et al. [Page 5]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
by IANA by IETF consensus as defined in [RFC2434].
- 000b Prepend. This action means that the AS number of the
announcing router should be prepended when announcing the attached
route to the BGP speakers covered by the redistribution policy. The
action parameter indicates how many times the AS number should be
prepended. Using an action parameter of 000 with this type,
although legal, will not cause any additional prepending of the
route's AS PATH.
- 001b No_Export. This action means that the NO_EXPORT community
should be inserted when announcing the attached route to the BGP
speakers covered by the redistribution policy. This action type
does not require a parameter. The action parameter should be set to
zero by the sender and ignored by the receiver.
- 010b Do not announce. This action means that the route should not
be announced to the BGP speakers covered by the redistribution pol
icy. This action type does not require a parameter. The action
parameter should be set to zero by the sender and ignored by the
receiver.
The BGP Speakers Filter
The BGP_Speakers_Filter field is used to specify the BGP speakers
that will be affected by the specified action. It is composed of a
one octet type field and a five octets value field.
+--------+--------------------------------------+
| Type | BGP_Speakers_Filter Value (5 octets) |
+--------+--------------------------------------+
Figure 2: Encoding of the BGP_Speakers_Filter field
The BGP_Speakers_Filter field is used to specify the BGP speakers
that will be affected by the specified action. There are two meth
ods to specify the affected BGP speakers. The first method is to
explicitly list all those speakers inside the BGP_Speakers_Filters
field of the redistribution communities. In this case, the high
order bit of the type field of the BGP_Speakers_Filter field is set
to 1. The second method is to explicitly list only the BGP speak
ers that will not be affected by the specified action. In this
case, the high order bit of the BGP_Speakers_Filter type field
shall be set to 0. The 7 low order bits of the BGP_Speakers_Filter
type field are used to indicate the type of BGP speakers included
Bonaventure et al. [Page 6]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
in the five low order octets of the BGP_Speakers_Filter field.
This document defines four types of BGP_Speakers_Filters (values
0x01-0x04). Value 0x00 is reserved and values 0x05-0x3f are
reserved for future use and are to be assigned by IANA by IETF con
sensus as defined in [RFC2434]. Values 0x40-0x7f are vendor spe
cific and are assigned by IANA on a first come, first serve basis.
BGP_Speakers_Filter types
- The BGP_Speakers_Filter value contains a two octet AS number
(type 0x01)
- The BGP_Speakers_Filter value contains two two octet AS numbers
type 0x02)
- The BGP_Speakers_Filter value contains a CIDR prefix/length pair
(type 0x03)
- The BGP_Speakers_Filter value contains a four octets AS number
(type 0x04)
The BGP_Speakers_Filter value shall be encoded as follows. If this
field contains a two octet AS number, the AS number shall be placed
in the two low order octets. The three high order octets shall be
set to zero upon transmission and ignored upon reception.
+---------------------------+
| Must be Zero (3 octets) |
+---------------------------+
| AS number (2 octets) |
+---------------------------+
Figure 3: BGP speakers filter containing a single two octet AS number
If the BGP_Speakers_Filter value contains two two octet AS numbers,
one of the AS numbers should be placed in the two low order octets.
The other AS number should be placed in the next two higher order
octets and the last octet shall be set to zero upon transmission
and ignored upon reception.
+---------------------------+
| Must be Zero (1 octet) |
+---------------------------+
| AS number A (2 octets) |
+---------------------------+
| AS number B (2 octets) |
+---------------------------+
Figure 4: BGP speakers filter containing two distinct two octet AS number
Bonaventure et al. [Page 7]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
If the BGP_Speakers_Filter value contains a four octet AS number,
the AS number shall be placed in the four low order octets. The
high order octet shall be set to zero upon transmission and ignored
upon reception.
+---------------------------+
| Must be Zero (1 octet) |
+---------------------------+
| AS number (4 octets) |
+---------------------------+
Figure 5: BGP speakers filter containing a single four octets AS number
If the BGP_Speakers_Filter value contains a CIDR prefix/length
pair, it should be encoded as shown below:
+---------------------------+
| Length (1 octet) |
+---------------------------+
| Prefix (4 octets) |
+---------------------------+
Figure 6: BGP speakers filter containing a CIDR prefix/length pair
The Length field indicates the length in bits of the IP address
prefix. A length of zero indicates a prefix that matches all IP
addresses. The Prefix field contains IP address prefixes followed
by enough trailing bits with a value of zero to make the end of the
field fall on a four octets boundary.
2.2 Utilization of the redistribution communities
A router may, depending on its policy, add one or several redistri
bution communities to a route originated by itself or received from
another BGP speaker over an iBGP or an eBGP session. In practice,
it can be expected that the redistribution communities will often
be attached by the originator of the route will as this is an
attempt of the route originator to do some form of inter-domain
traffic engineering. In practice, it can also be expected that most
utilizations of the redistribution communities will only require to
attach a small number of those communities to a given route.
When a router attaches one or several redistribution communities to
a route, it must ensure that two of the included redistribution
communities do not conflict. This is necessary to ensure that the
redistribution communities will be processed in a deterministic
manner by the remote BGP peer. When several redistribution
Bonaventure et al. [Page 8]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
communities contain the same action type and parameter, then all
the BGP_Speakers_filters of those communities must have the same
high order bit in the BGP_Speakers_Filter type. A BGP router that
receives a route containing invalid redistribution communities for
a given action type and parameter should ignore all the redistribu
tion communities concerning this action type and parameter. This
ignore action must be logged.
2.3 Operations
This document defines the procedures to support the redistribution
communities that are non-transitive extended communities of type
01TBDTBD. An implementation that understands the redistribution
communities should discard and ignore upon receipt the extended
communities of the form 00TBDTBD (i.e. same type as a redistribu
tion community but transitive).
The redistribution communities defined in this document only affect
the redistribution of the associated route over eBGP sessions. The
redistribution communities do not affect the redistribution of
routes over iBGP sessions or between the sub-ASes of a confedera
tion.
When a router receives a route with redistribution communities, it
should apply the operations specified by these communities when
redistributing the route over eBGP sessions. Since the redistribu
tion communities defined by this document are non-transitive, a
router will remove the received redistribution communities when
redistributing those routes over eBGP sessions. Of course, nothing
prevents this router from adding its own redistribution communities
to this route before redistributing it.
A router should apply the policies defined by the redistribution
communities to the routes that is has selected for advertisement
from its Adj-Rib-Out based on its own policy. A route that contains
redistribution communities should be processed as follows:
First, the BGP speaker should build for each action type and param
eter contained in the redistribution communities attached to the
route a list of the target BGP speakers contained in the BGP_Speak
ers_filters for this action type. In the remainder of this sec
tion, we will use the wordings "an eBGP session is affected by
action type x" to indicate that either of the following is true
when the BGP_Speakers_Filters contain AS numbers:
Bonaventure et al. [Page 9]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
- the AS number of the remote BGP peer appears inside one of the
BGP_Speakers_Filter of the redistribution communities with action x
and the high order bit of the BGP_Speakers_Filter type is set to
one
- the AS number of the remote BGP peer does not appear inside any
of the BGP_Speakers_Filter of the redistribution communities with
action x and the high order bit of the BGP_Speakers_Filter type is
set to zero
When the BGP_Speakers_Filter contains a CIDR prefix/length, we will
use the wordings "an eBGP session is affected by action type x" to
indicate that either of the following is true:
- the IP address of at least one of the endpoints of the eBGP ses
sion belongs to the CIDR prefix specified inside one of the
BGP_Speakers_Filter of the redistribution communities with action x
and the high order bit of the BGP_Speakers_Filter type is set to
one
- the IP addresses of the local and the remote endpoints of the
eBGP session do not belong to the CIDR prefix specified inside one
of the BGP_Speakers_Filter of the redistribution communities with
action x and the high order bit of the BGP_Speakers_Filter type is
set to zero
Then, when a route is about to be redistributed over an eBGP ses
sion, the router first checks if this session is affected by action
type "Do not announce". If this is the case, the route is not
announced over this eBGP session. Otherwise, the router checks the
other action types as follows.
- If the eBGP session is affected by action type "No export" then
the well-known community NO_EXPORT is attached to the route.
- If the eBGP session is affected by one or more actions of type
"Prepend", then the AS-Path of the route shall be prepended n times
(with the AS number of the router redistributing the route) where n
is the smallest parameter of the matched "Prepend" actions.
Otherwise the route is announced over the eBGP session.
2.4 Filtering and precedence
Bonaventure et al. [Page 10]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
In order to allow operators to control the implementation of their
policies, a BGP implementation that supports the redistribution
communities should allow the operator to determine, on a per ses
sion basis whether redistribution communities are permitted or
denied on this session. For example, an AS could elect to receive
redistribution communities from its customers, but not on a shared-
cost peering session. A BGP implementation may provide additional
details in the filtering of the redistribution communities, but
this is implementation dependent and goes beyond this specifica
tion.
A BGP implementation that supports both the normal (extended) com
munities and the redistribution communities should allow the opera
tor to adjust the order in which these types of communities are
processed. The default precedence should be to first process the
redistribution communities before processing the other manually
defined (extended) communities.
3 IANA considerations
This document requests the attribution of a new BGP extended commu
nities type [EXT-COM] field from IANA.
The redistribution community contains two fields that are to be
maintained by IANA. The first field is the Action type that is part
of the Action octet defined in section 2.1 shall be maintained by
IANA. This document defines the utilization of action types 000b -
010b ; action types 011b - 111b are reserved for future use and are
to be assigned by IANA by IETF consensus as defined in [RFC2434].
The second field are the seven low order bits of the Type octet of
the BGP_Speakers_Filter defined in section 2.1. This document
defines four types of BGP_Speakers_Filters (values 0x01-0x04).
Value 0x00 is reserved and values 0x05-0x3f are reserved for future
use and are to be assigned by IANA by IETF consensus as defined in
[RFC2434]. Values 0x40-0x7f are vendor specific and are assigned
by IANA on a first come, first serve basis.
4 Security considerations
This extension to BGP does not change the underlying security
issues of the extended community attribute.
5 Conclusion
This document has proposed a new type of extended communities
Bonaventure et al. [Page 11]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
called the redistribution communities. These redistribution commu
nities can be used by a BGP router to influence the redistribution
of some of its routes by its peers. Three types of redistribution
communities have been proposed. The first type may be used to
indicate that a specific route should not be announced over the
specified set of eBGP sessions. The second type may be used to
indicate that the attached route should only be announced with the
NO_EXPORT community over the specified set of eBGP sessions and the
third type may be used to indicate that the attached route should
be prepended n times when announced over the specified set of eBGP
sessions.
Acknowledgements
This work was partially funded by the European Commission, within
the ATRIUM IST project. We would like to thank Bart Peirens,
Alvaro Retana and Andrew Partan for their comments.
References
[Halabi97] B. Halabi. Internet Routing Architectures. Cisco Press,
1997.
[Huston01] G. Huston. AS1221 BGP table statistics. available from
http://www.telstra.net/ops/bgp/, 2001.
[COM-SUR] B. Quoitin, O. Bonaventure, A survey of the utilization
of the BGP community attribute, Internet draft, draft-quoitin-bgp-
comm-survey-00.txt, work in progress, February 2002
[Quoitin02] B. Quoitin, An implementation of the BGP redistribution
communities in zebra, Technical report Infonet-TR-2002-03, February
2002, http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-03.html
[EXT-COM] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended com
munities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi
ties-05.txt, work in progress, May 2002.
[RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC2434, October 1998
Bonaventure et al. [Page 12]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
Authors' Addresses
Olivier Bonaventure,
Dept. Computing Science and Engineering
Universite catholique de Louvain (UCL)
Place Sainte-Barbe, 2, B-1348 Louvain-la-Neuve (Belgium)
Email: Olivier.Bonaventure@info.fundp.ac.be
URL : http://www.info.ucl.ac.be/people/OBO
Bruno Quoitin
Infonet group (FUNDP)
Rue Grandgagnage 21
B-5000 Namur
Email: Bruno.Quoitin@info.fundp.ac.be
URL : http://www.infonet.fundp.ac.be
Stefaan De Cnodder
Alcatel
Francis Wellesplein 1
B-2018 Antwerp, Belgium
Email: stefaan.de_cnodder@alcatel.be
Jeffrey Haas
NextHop Technologies
Email: jhaas@nexthop.com
Russ White
Cisco Systems
Email: ruwhite@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
Bonaventure et al. [Page 13]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Bonaventure et al. [Page 14]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
Appendix 1 Simple example
The redistribution communities defined in this document can be
used in two different ways. A first possible solution would be
to rely on the existing support for the extended communities in
BGP implementations and to manually configure the redistribution
communities defined in this document. This solution could be
used today by ISPs to support the redistribution communities (or a subset
of those communities) defined
in this document instead on defining special community values in
their community space and advertising them in the routing registries.
To illustrate a possible configuration with an existing BGP implementation
supporting the extended communities, we use a syntax similar
to the syntax used by zebra. Let us assume that one route
from AS3 has two peerings: one peering with AS2 and one peering with AS1.
The configuration below shows how AS3's router could be configured to
support the redistribution communities defined in this document. In
the configuration in figure A, we show each extended community in
hex format for readability reasons and only consider a subset of the
redistribution communities. Figure A shows how AS3 would configure its
routers to allow to request that a route announced to AS1 would be
prepended n times before being announced and to request that a specific
route would not be announced to AS2.
router bgp 3
neighbor 172.17.1.1 remote-as 1
neighbor 172.17.1.1 route-map prepend1_as1 out
neighbor 172.17.1.2 remote-as 2
neighbor 172.17.1.2 route-map do_not_announce_as2 out
! Extended community list
! --------------------------
! action "prepend x times"
! filter "include AS1"
!
ip extcommunity-list 1 permit 0x4401810000000001
ip extcommunity-list 2 permit 0x4402810000000001
ip extcommunity-list 3 permit 0x4403810000000001
ip extcommunity-list 4 permit 0x4404810000000001
!
! Route-maps
! --------------------------
! action "prepend x times"
! filter "include AS1"
!
route-map prepend_as1 permit 10
match extcommunity 1
Bonaventure et al. [Page 15]
draft-ietf-grow-bgp-redistribution-00.txt April 2003
set as-path prepend 1
!
route-map prepend_as1 permit 20
match extcommunity 2
set as-path prepend 2
!
route-map prepend_as1 permit 30
match extcommunity 3
set as-path prepend 3
!
route-map prepend_as1 permit 40
match extcommunity 4
set as-path prepend 4
!
! Extended community list
! --------------------------
! action "do not announce"
! filter "include AS2"
!
ip extcommunity-list 5 permit 0x4410810000000002
!
route-map do_not_announce_as2 deny 10
match extcommunity 5
!
Figure A: Sample configuration
For a router with a small number of peers, such a manual configura
tion of the redistribution communities is possible. However, if the
routers has many peers, the required configuration file may become
very large, especially if one wants to fully support all the redis
tribution communities defined in this document. In this case, a bet
ter solution is to rely on a direct support for the redistribution
communities inside the BGP implementation itself as discussed in
[Quoitin02]. With a BGP implementation supporting directly the redis
tribution communities, a few lines of configuration will be suffi
cient to enable or disable some or all of the redistribution communi
ties for each peer.
Bonaventure et al. [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 17:38:18 |