Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP Tutorial update...

  • From: Olivier Bonaventure
  • Date: Mon Jun 10 04:38:46 2002

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

-- 
http://www.infonet.fundp.ac.be




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.