BGP Tutorial update...

Travis Pugh tdp at discombobulated.net
Mon Jun 10 15:12:34 UTC 2002


"Olivier Bonaventure" writes:

> can define its own semantic. Second, since the community attribute
is
> transitive, you might receive routes from any peer containing such
community
> values and apply an invalid filter to those routes. This leakage of
> community values is not uncommon in practice based on our analysis
> of the BGP routing tables (see
http://alpha.infonet.fundp.ac.be/anabgp
> and http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-02.html )

This seems to be just as easily cured by setting an internal community
on routes from peers, and not specifying "additive" (in ciscospeak):

route-map peer-in
 set community xxx:yyy

> Using such community values for traffic engineering purposes could
quickly
> become a headache unless every one filters the community values that
it
> annouces to peers, but few operators have implemented such
filtering.

I don't know about others, but at the couple of ISPs I have worked at
it was standard procedure to set a non-additive community on incoming
prefixes from peers -- if this is done consistently, there will be no
problem with bogus matches from the peer, even if the community space
you and your peer use overlaps.

Further, if you are actually making decisions based on an internal
community scheme when you send routes to your peers, those routes
already go through an outbound route-map at the border -- so I don't
see a whole lot of overhead in adding a "set community" to some null
value when you send the prefixes out.

Perhaps this situation is better served with a BCP rather than adding
additional features to BGP itself?

Cheers.

-travis





More information about the NANOG mailing list