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: [email protected] [mailto:[email protected]] On Behalf Of Jason Lixfeld Sent: Monday, March 15, 2010 10:08 AM To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
