[58507] in North American Network Operators' Group
RE: Communities BCP [was: RE: BGP Path Filtering]
daemon@ATHENA.MIT.EDU (Ejay Hire)
Fri May 16 17:52:06 2003
Date: Fri, 16 May 2003 16:45:11 -0500
From: "Ejay Hire" <ejay.hire@isdn.net>
To: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu
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
