On Wed, Oct 20, 2010 at 04:23:23PM -0400, Chris Morrow wrote: > > 4) reset next-hop as you ship the route internally to IBGP neighbors > (see ... the Wayne Gustavus's (verizon) talk from NANOG32 in Reston: > <http://www.nanog.org/meetings/nanog32/presentations/soricelli.pdf>) > > there are, as RAS is pointing out, many ways to skin this cat.
Well, that would work if you're adding a local static route to discard and then reannouncing it into IBGP... But if you're receiving the route from a customre EBGP session that wouldn't install the null route on the local box, potentially leaving you open to one customer flooding another customer on the same router. I also had some people point off offline that you could build a single prefix-list policy, then allow null routes to be accepted, and THEN begin your regular customer border policies. This is also true, but I forgot to mention that I've also found value in having separate max prefix limits for null route vs regular routes, which you couldn't implement via a policy over a single session. This entire discussion needs a giant disclaimer that says "Warning: The number of BGP speaking customers out there who aren't really masters of route-map and who will accidentally try to null route their entire bgp session is higher than you might expect". Making them actually take the time to configure a dedicated EBGP multihop session for it can help prevent these kinds of accidents too. Oh and if you've got a mixed Cisco/Juniper edge, you WILL need 2 prefix-lists to implement it on the Cisco, so the multihop session lets you use a single clean solution to cover all edge routers. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
