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-redistrib... Olivier -- http://www.infonet.fundp.ac.be

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..