To take a crack at it... - Route origin - customer, peer, transit provider, other (dial, etc) - Route geography - depends on your network, but some have seperate communities for POP, Country, Region, etc - Customer originated information - tweaks by your customers to selectively prepend, change local pref, not send to peers, or what not - Source AS - simply your AS:peer AS that the route was learned from There was an Internet Draft, last year, that summarized some of the approachs. I suspect overspecificity in this case has never done any harm, while lack of specificity has probably caused some heartache. - Daniel Golding On Fri, 16 May 2003, Deepak Jain wrote:
I like using BGP communities: o filter announcements you receive from downstreams based on your criteria of choice o set a specific BGP community (yourAS:whatever) on announcements which are to be propagated to various places (upstream providers, etc.) o do output filtering based on the communities you set Make sure you clear yourAS:whatever in announcements from your BGP peers.
You can use this same technique for prefixes you originate, so that all your outbound BGP filtering is based on communities.
I am hijacking this thread a bit. Setting communities is excellent advice especially if you are just starting out with downstream ASes.
The question is that changing your communities down the road might be a big headache depending on whether you'll come to need more advanced ways of filtering your announcements than coarse communities allow. Especially when going (through growth or acquisition) from a single metro network to a multi-metro or national/international one.
What criteria does the community think should be used when specifying communities. IMO, overspecificity [sp?] doesn't hurt, but others may (and have) disagreed. What's the BCP?
Thanks,
Deepak Jain AINET