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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
