RE: Communities BCP [was: RE: BGP Path Filtering]
On the subject of communities, these are some I have seen regularly implemented for controlling routes advertised to peers. (code snippet follows) Where xxxx is the peer ASN: xxxx:80 Set LocalPref to 80 xxxx:90 Set LocalPref to 80 xxxx:100 Set LocalPref to 80 xxxx:110 Set LocalPref to 80 xxxx:1 Prepend xxxx 1 time in the AS Path xxxx:2 Prepend xxxx 2 times in the AS Path xxxx:3 Prepend xxxx 3 times in the AS Path xxxx:no-export Well known community that requests the advertisement not leave the AS. xxxx:666 BlackHole. I've implemented this community for clueful downstream peers that suffered frequent DOS attacks. They advertise a single or small block of their IPs to me and I will blackhole traffic destined for their IP. I've considered echoing this advertisement up to my upstreams (if they support it), but have not done so. The config bits that follow are from memory, so no guarantees of syntax accuracy. If anyone knows how I can have an Item matched multiple times in the route-map I would appreciate a reply. I.e. if a customer wanted to send xxxx:100 and xxxx:1, currently I would match on the xxxx:1 and the localpref change would not be applied. Thanks in advance to whoever comes up with this gem. Code Snippet: (Again, this may not be 100% correct on syntax, I'm doing it from memory.) Prefix-list customerxyz-in permit 200.200.0.0/16 le 24 Prefix-list customerxyz-bh-in permit 200.200.0.0/16 le 32 ip community-list 66 permit xxxx:666 ip community-list 10 permit xxxx:1 ip community-list 11 permit xxxx:2 ip community-list 12 permit xxxx:3 ip community-list 13 permit xxxx:80 ip community-list 14 permit xxxx:90 ip community-list 15 permit xxxx:100 ip community-list 16 permit xxxx:110 route-map customerxyz-in permit 10 match community 66 match ip address prefix-list customerxyz-bh-in (this uses the ...-bh-in list allowing prefix lengths up to /32) set community no-export additive set next-hop null0 route-map customerxyz-in permit 20 match community 10 match ip address prefix-list customerxyz-in (this uses the regular customer prefix list allowing lengths up to /24) set as-path prepend xxxx ... 30 and 40 similar, for community lists 11 and 12 route-map customerxyz-in permit 50 match community 13 match ip address prefix-list customerxyz-in set localpref 80 ... 60,70,80, and 90 similar, for community lists 14-17 Ejay Hire ISDN-NET Network Engineer -----Original Message----- From: Jay Ford [mailto:jay-ford@uiowa.edu] Sent: Friday, May 16, 2003 2:27 PM To: Joe Abley Cc: deepak@ai.net; Mark Radabaugh; nanog@merit.edu Subject: Re: Communities BCP [was: RE: BGP Path Filtering] On Fri, 16 May 2003, Joe Abley wrote:
Examples of characteristics I have seen in the wild are:
+ I was learnt from a peer + I was learnt from a transit provider + I was learnt from a customer + I was learnt over an exchange point + I was learnt over a private peering connection
These are all markers to be used in setting internal policy, so the choice of numbers really doesn't matter. You can add or remove characteristics from your list when necessary without having to renumber anything. You can (and probably should) strip all these attributes before sending routes to EBGP peers, so nobody else has to see them.
You can & definitely should strip those community values on announcements you receive from EBGP peers. Interesting things happen if you let others turn your routing policy knobs when you think they can't reach them. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951
On Fri, May 16, 2003 at 04:45:11PM -0500, Ejay Hire wrote:
The config bits that follow are from memory, so no guarantees of syntax accuracy. If anyone knows how I can have an Item matched multiple times in the route-map I would appreciate a reply. I.e. if a customer wanted to send xxxx:100 and xxxx:1, currently I would match on the xxxx:1 and the localpref change would not be applied. Thanks in advance to whoever comes up with this gem.
Actually you can accomplish this by using additive (but you would have to make sure all "bad" communities are caught and the values reset to a valid 'standard' route prior). This would allow you to know anything past this point is a valid, acceptable community which would leave you with checking null0, then local pref's and setting it properly.. I can supply a config, if folks are interested. Thanks, charles
On Fri, May 16, 2003 at 07:15:47PM -0400, Charles H. Gucker wrote:
On Fri, May 16, 2003 at 04:45:11PM -0500, Ejay Hire wrote:
The config bits that follow are from memory, so no guarantees of syntax accuracy. If anyone knows how I can have an Item matched multiple times in the route-map I would appreciate a reply. I.e. if a customer wanted to send xxxx:100 and xxxx:1, currently I would match on the xxxx:1 and the localpref change would not be applied. Thanks in advance to whoever comes up with this gem.
Actually you can accomplish this by using additive (but you would have to make sure all "bad" communities are caught and the values reset to a valid 'standard' route prior). This would allow you to know anything past this point is a valid, acceptable community which would leave you with checking null0, then local pref's and setting it properly..
I can supply a config, if folks are interested.
Ok, since I had a few moments, I put the config together: Using AS 666 as your AS, this would be your config. If you want to use this, you will have to become comfortable with regular expressions and such. Also, the more communities you accept, that are not in ranges, will make things slightly more complicated. Ok, here we go. ! End checking for invalid AS's within communities. ! permitting 666:0, 666:1, 666:2, 666:3, 666:666 ! ip community-list expanded ASN666-INVALID-COMMUNITY permit _(666:[4-9]_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _(666:[0-9][0-9]_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _(666:[0-57-9][0-57-9][0-57-9]_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _(666:[0-9][0-9][0-9][0-9]_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _(666:[0-6][0-9][0-9][0-9][0-9]_) ip community-list expanded ASN666-INVALID-COMMUNITY deny .* ! check for invalid AS community settings (Catch any as that's not 666:*_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _([0-9]:.*_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _([0-9][0-9]:.*_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _([0-57-9][0-57-9][0-57-9]:.*_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _([0-9][0-9][0-9][0-9]:.*_) ip community-list expanded ASN666-INVALID-COMMUNITY permit _([1-6][0-9][0-9][0-9][0-9]:.*_) Another handy thing would be to setup a "blank" community catch. It will decrease the time it takes to load announcements, since the following checking will only occur on announcements with communities attached. Most customers aren't going to send you communities for engineering purposes. ip community-list expanded ASN666-EMPTY-COMMUNITY permit ^$ Back to the route-map: route-map customer-in permit 10 description STANDARD: Match a blank community field and stamp with default attributes. match ip address prefix-list check-bit-size match community ASN666-EMPTY-COMMUNITY set local-preference 100 set metric 10 ! (do not set this if you accept customer metrics) set community <customer community tag> <location tag> ! route-map customer-in permit 20 description STANDARD: Match and set default attributes to any announcements with an invalid community. match community ASN6128-INVALID-COMMUNITY set local-preference 100 set metric 10 ! (do not set this if you accept customer metrics) set community <customer community tag> <location tag> <error community tag> ! route-map customer-in permit 30 description STANDARD: Match and set null-route for announcements with a community of 666:0. match community ASN666-NULL0 set community no-export additive set next-hop null0 set metric 10 ! (do not set this if you accept customer metrics) set community <customer community tag> <location tag> <error community tag> ! route-map customer-in permit 40 description STANDARD: Match and set local preference to 95 for valid communities. match community ASN666-LOCAL-PREF-95 set local-preference 95 set metric 10 ! (do not set this if you accept customer metrics) set community <customer community tag> <location tag> additive ! .. continue on with local pref and conclude with route-map customer-in permit 120 description STANDARD: Match and set local preference to 100 for valid communities. set local-preference 100 set metric 10 ! (do not set this if you accept customer metrics) set community <customer community tag> <location tag> ! This would allow you to setup a number of things prior the final acceptance. You can also check bit length and setup no-export based upon the bit size and such. But you would really want to do this after you check for invalid communities. The overall idea here is to make sure you're downstreams won't be able to send you "dirty" communities that would be inturn sent to your upstreams and acted upon. It also makes sure that your customer isn't setting anything they aren't suspose to which is why you would be able to trust the announcement (and community setting). Thanks, charles
participants (2)
-
Charles H. Gucker -
Ejay Hire