[c-nsp] Current BGP BCP for anchoring and announcing local prefixes

[Leah Lynch (Contractor)]

You can use the 'aggregate-address advertise-map' command, instead of
the route map and you should have the same effect setting communities on
the summaries. You can also try tuning the weight for the redistributed
routes to set he preference you like.

Leah

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jason Lixfeld
Sent: Monday, March 15, 2010 10:08 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Current BGP BCP for anchoring and announcing local
prefixes

I've been in the habit of using communities to anchor and announce
prefixes into BGP for years and I think my ways are somewhat dated.  I'm
looking for a bit of a refresh.  Wondering if anyone here has any
thoughts ;)

So hypothetically speaking:

!
router bgp 65535
 no synchronization
 neighbor 1.1.1.1 remote-as 1
 neighbor 1.1.1.1 route-map as1.in in
 neighbor 1.1.1.1 route-map as1.out out
 neighbor 1.1.1.1 description transit
 neighbor 1.1.1.1 send-community
 neighbor 2.2.2.2 remote as 2
 neighbor 2.2.2.2 route-map as2.in in
 neighbor 2.2.2.2 route-map as2.out out
 neighbor 2.2.2.2 description customer
 neighbor 2.2.2.2 send-community
 neighbor 9.9.9.9 remote-as 65535
 neighbor 9.9.9.9 send-community
 neighbor 9.9.9.9 description ibgp
 neighbor 9.9.9.9 update-source loopback0
 neighbor 9.9.9.9 next-hop-self
 network 10.10.10.0 mask 255.255.255.0 route-map local
!
ip route 10.10.10.0 255.255.255.0 null0 250 name "BGP Anchor"
!
ip bgp-community new-format
ip community-list expanded local permit 65535:100
ip community-list expanded transit permit 65535:50
ip community-list expanded customer permit 65535:150
!
route-map local
 set community 65535:100
!
route-map as1.in
 set community 65535:50
!
route-map as1.out
 match community local customer
!
route-map as2.in
 set community 65535:150
!
route-map as2.out
 match community local customer transit
!

This has served me well for quite a while.  I don't need to worry about
managing access-lists or prefix lists, I just tag prefixes as they are
received by transits or customers, or wrap a route-map around a network
statement and I'm good to go. 

Where I'm starting to run up against issues is when I start to remove
internal prefixes from OSPF and put them into BGP.  At this point, the
network statements don't really work anymore.  The locally anchored
route gets a high weight, so in cases where some IBGP speaker announces
a prefix that has the same length as what's being anchored, the
announced prefix is discarded in favour of the prefix with the higher
weight.  The net result is a RIB entry for the prefix with a next-hop of
null0 and black hole ensues.

aggregate-address may be a reasonable solution, but I can't seem to tag
a community with an aggregate-address statement like I can with a
network statement, so I'm thinking that maybe I've just got to re-think
this from the ground up.

I like the network-statement + community way of doing things because I
don't really have to touch much stuff when I go to anchor a new local
prefix.  I just create the network statement and attach the proper
route-map, and that's it.  No prefix-lists to modify, no EBGP facing
route-maps to modify.  It's nice and simple and somewhat elegant.

I'm hoping there's a solution out there that is equally if not more
simple and elegant.

Thanks in advance.
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/