RE: Communities BCP [was: RE: BGP Path Filtering]

Mailman List Mirror (Read Only)
1

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

2

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

3

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