 |
Using BGP Communities in Peering
with the PCH Route-Servers
The Packet Clearing House route-servers accept a number of BGP communities
in order to allow peers specific control over the way in which routes which
they advertise to the route-server will be used. No communities are
necessary to peer with the PCH route-servers and participate in the Multi-Lateral
Peering Agreements which they facilitate, however use of the communities
will allow you to participate in the looking-glass without being a party
to the MLPA, or to pass full routes into the looking-glass and the archives
without inadvertently providing transit to other MLPA participants.
The following table describes each of the communities the PCH route-servers
understand:
| Community |
Behavior |
| None |
The default behavior of the route-server is to readvertise all learned
routes to all other PCH peers who choose to listen to them. This
has the effect of allowing you to participate in the MLPA route-server
function of the PCH router, as well as the looking-glass. |
| 3856:1 |
This community marks the prefix as one which you have learned via one
of your peers or transit providers, rather than internally or from a customer,
and which you wish the PCH route-server itself to listen to, but which
you do not want it to readvertise to any of the route-server's other peers.
If you wish to pass full routes to a PCH route-server, it is requested
that you label all but your internal and customer routes with the 3856:1
community. |
| 3856:2 |
This community marks the prefix as one which you have learned via one
of your peers or transit providers, rather than internally or from a customer,
and which you're providing solely for informational purposes, and do not
wish the PCH route-server to use itself, nor distribute to its other peers. |
| 3856:3 |
This community marks the prefix as one which you have learned via one
of your peers or transit providers, rather than internally or from a customer,
and which you wish to allow the PCH route-server to use and to readvertise
to all the other peers of the route-server. Use of this community
is NOT RECOMMENDED, and may be filtered by PCH if we think it's been
misapplied. Again, the effect of this community is to allow other
participants at the exchange to transit your network to the labeled prefix. |
| 3856:4 |
This community marks the prefix as one which belongs to your own network,
or which you have learned from a customer, and wish the PCH route-server
itself to listen to, but which you do not want it to readvertise to any
of the route-server's other peers. Use of this community has the
effect of allowing your prefixes to be visible in the looking-glass, without
participating in the MLPA route-server function of the PCH router. |
| 3856:5 |
This community marks the prefix as one which belongs to your own network,
or which you have learned from a customer, and which you're providing solely
for informational purposes, and do not wish the PCH route-server to use
itself, nor distribute to its other peers. |
| 3856:6 |
This community marks the prefix as one which belongs to your own network,
or which you have learned from a customer, and which you wish to allow
the PCH route-server to use and to readvertise to all other peers of the
route-server. Use of this community has the effect of allowing you
to participate in the MLPA route-server function of the PCH router, as
well as the looking-glass. This community has the same effect as
passing the route-server a prefix which is not labeled with any community
string ("None" above), but lets us know that you're doing so consciously. |
In order to apply a community attribute to a prefix which you advertise
to the route-server, several configuration tasks are necessary on your
peer router. First, "neighbor send-community" must be present to
activate outbound community labeling. Second, you must determine
which communities you wish to apply, and use a route-map to apply them.
The most common configuration uses an access-list to define which prefixes
are local or customer routes, and marks them as such. In the following
example, only customer routes are passed to the route-server, and they're
marked with the 3856:6 community. If the "neighbor distribute-list"
line were removed, full routes would be sent to the PCH router, but only
customer routes would be used in the MLPA (3856:6), while transit routes
would be visible only in the looking-glass (3856:1).
router bgp n
neighbor n.n.n.n remote-as 3856
neighbor n.n.n.n description PCH route-server
neighbor n.n.n.n send-community both
neighbor n.n.n.n route-map APPLY-PCH-COMMUNITIES
out
neighbor n.n.n.n distribute-list INTERNAL-AND-CUSTOMER-PREFIXES
out
!
ip access-list extended INTERNAL-AND-CUSTOMER-PREFIXES
remark #
remark # List all of your internal and customer
prefixes here
remark #
permit ip n.n.0.0 0.0.255.255 255.255.0.0
0.0.255.255
permit ip n.n.n.0 0.0.0.255 255.255.255.0
0.0.0.255
!
route-map APPLY-PCH-COMMUNITIES permit 10
match ip address INTERNAL-AND-CUSTOMER-PREFIXES
set community 3856:6
route-map APPLY-PCH-COMMUNITIES permit 20
set community 3856:1
In the example above, the portions in bold must be replaced with your own
information. Specifically, your own AS number in the "router bgp"
line; the IP address of the local PCH route-server in each of the "neighbor"
lines; and a list of your internal and customer prefixes and their masks
in the "permit ip" lines.
The following untested configuration code should do the same thing on
a Juniper under JunOS:
protocols {
bgp {
group route-server-eBGP
{
type external;
export INTERNAL-AND-CUSTOMER-PREFIXES-APPLY-PCH-COMMUNITIES;
peer-as 3856;
neighbor n.n.n.n;
}
}
}
policy-options {
policy-statement INTERNAL-AND-CUSTOMER-PREFIXES-APPLY-PCH-COMMUNITIES
{
term match-internal-and-customers
{
from {
route-filter n.n/16 exact;
route-filter n.n.n/24 exact;
}
then {
community set comm-internal-and-customers;
accept;
}
}
term match-all-others
{
then {
community set comm-all-others;
accept;
}
}
}
community comm-internal-and-customers members
3856:6;
community comm-all-others 3856:1;
Top of page
|
| |
|
