Otherwise known as Filtering BGP Advertisements Using BGP Communities For Fun and Profit but that made the layout terrible.
Filtering BGP advertisements using communities is a simple and effective way to control your advertisements. This can prevent common BGP route leaks with AS-PATHs that look like SOMEAS LEAKER-TRANSIT1 LEAKER LEAKER-TRANSIT2 SOMEPEER LEAKER-CUSTOMER when filtering transit sessions with prefix-list alone.
Before you can begin filtering using BGP communities, there are a few things you need to know and plan out.
What Are BGP Communities?
A BGP community is a group of destinations that share a common property. That common property is a path attribute that is included in BGP update messages. This information is somewhat like a GMail label, multiple communities can be attached to a particular route. By using these communities you can perform actions on the whole group without having to list each member in a prefix-list for example. You can use community attributes to trigger routing policy decisions, such as whether to accept a route or not, and if you do accept it, what preference you give it, and whether you advertise it upstream or to your peering partners.
BGP communities look like an AS number, ex:
2000. BGP Extended communities look like two ASNs separated with a :, ex:
How do you want to label routes, and influence your routing policy?
It may help to look at some examples of BGP communities supported by various providers when creating your own. Many ISPs publish their list of BGP Communities in their IRR AS record.
These published communities follow this format:
It would seem to me that the number ranges used in the
<Number> portion of the community should be partitioned out in a local way, ex:
|1 - 9||Originated, Customer Originated, Peer, and Transit routes|
|50 - 200||Localpref Modifiers (50 thru 200 in increments of 5 or 10)|
|300 - 500||Limit advertisements to upstreams, peers, and customers|
|3000 - 3010||Control insertion of own prepends|
Example Routing Policy, Communities and Cisco Config
|65001:1||Learned via Transit|
|65001:2||Learned via IX/Open Peering|
|65001:3||Learned via Customers|
|65001:4||Learned via Self|
|65001:100||Set Localpref = 100 (Customer Primary Link/Default)|
|65001:110||Set Localpref = 110 (Customer Preferred Link)|
|65001:90||Set Localpref = 90 (Customer Backup Link)|
|65001:50||Set Localpref = 50 (Customer Failback Link)|
|65001:65||Set Localpref = 65 (Peering Backup Link)|
|65001:300||Do not send routes to BGP customers or peers CAREFUL|
|65001:301||Do not send routes to upstreams/transits|
|65001:302||Do not send routes to IX peering|
|65001:303||Do not send routes to Customers CAREFUL|
|65001:304||Only send routes to downstreams/customers|
|65001:3001||Prepend AS65001 1x|
|65001:3002||Prepend AS65001 2x|
|65001:3003||Prepend AS65001 3x|
|65001:3004||Prepend AS65001 4x|