North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: BGP Tutorial update...
- From: Travis Pugh
- Date: Mon Jun 10 11:14:59 2002
"Olivier Bonaventure" writes:
> can define its own semantic. Second, since the community attribute
> transitive, you might receive routes from any peer containing such
> 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
> 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):
set community xxx:yyy
> Using such community values for traffic engineering purposes could
> become a headache unless every one filters the community values that
> annouces to peers, but few operators have implemented such
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?