BGP Tutorial update...

Mailman List Mirror (Read Only)
1

Hi,

An update on the AS3257 community slide I included at the end of the BGP Tutorial - it was pointed out that www.as3257.net/html/communities.htm no longer existed as I had on the presentation. And there seem to be no links to it on the Tiscali website either...

It's still at www.archive.org under http://web.archive.org/web/20011004092913/http://www.as3257.net/html/communities.htm so anyone who is interested in the full copy of that website should grab a copy from there.

I'll try find out what has happened to the original site...

philip

2

Phil,

If you want a nice example of well documented community values via whois try Level-3:

whois -h whois.radb.net as3356

Everyone should take an example from them.

-Hank

3

Hank,

If you want a nice example of well documented community values via whois
try Level-3:

whois -h whois.radb.net as3356

Everyone should take an example from them.

I agree that Level3's traffic engineering communities are well documented.

However, operators willing to utilize the community values in the private AS space
(e.g. 64990:, 64991:xx below) should think twice before deploying configurations
to support those community values on their routers. A first issue is
that the status of those values is unclear within IETF and IANA and anyone
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 )

To take a simple example, assume that you implement the same community
values as Level3, e.g. :

remarks: 64990:0 - announce to customers but not to NA peers
remarks: 64990:XXX - do not announce on NA peerings to AS XXX
remarks: 64991:XXX - prepend once on NA peerings to AS XXX
remarks: 64992:XXX - prepend twice on NA peerings to AS XXX
remarks: 64993:XXX - prepend 3x on NA peerings to AS XXX
remarks: 64994:XXX - prepend 4x on NA peerings to AS XXX
remarks: --------------------------------------------------------

Then, you might well receive the following routes from your upstream peer :

route-views.oregon-ix.net>sh ip bgp community 64994:12076
BGP table version is 4638455, local router ID is 198.32.162.100
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network Next Hop Metric LocPrf Weight Path
* 81.64.0.0/14 209.244.2.115 0 0 3356 9057 6678 i
* 195.132.0.0/16 209.244.2.115 0 0 3356 9057 6678 i
* 212.198.0.0/16 209.244.2.115 0 0 3356 9057 6678 i

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.

A safer solution from an operational point of view would be to use
for this purpose non-transitive extended communities with a well-known
semantics that could be easily directed supported by router vendors.
See Bruno Quoitin's presentation at NANOG25 or
http://www.infonet.fundp.ac.be/doc/reports/draft-ietf-ptomaine-bgp-redistribution-00.txt

Olivier

4

"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

5

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

More appropriately,

ip community-list exp PRIVATE-AS permit 65[0-9][0-9][0-9]:.*
ip community-list exp PRIVATE-AS permit 64[6-9][0-9][0-9]:.*
ip community-list exp PRIVATE-AS permit 645[2-9][0-9]:.*
ip community-list exp PRIVATE-AS permit 6451[2-9]:.*

route-map peer-in
   set comm-list PRIVATE-AS delete

As not to destroy all communities coming in, since preservation of data is
good. Ideally you'd want to strip any 'prepend' and selective advertise
communities from peers as well, since one would hope they're not depending
on you to do TE work for them....

..kg..