|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Communities BCP [was: RE: BGP Path Filtering]
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
|