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

[Jason Lixfeld]

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.