On Tuesday 24 November 2009 06:25:45 am David Hughes wrote: > So you are generating the aggregate at the border? That > can certainly leave you black holing traffic under > several scenarios (anything that isolates that router). > Have you thought about generating the aggregate within > your network and propagating it via iBGP. At least the > border can't advertise it upstream instantaneously as it > won't know about it until iBGP is up.
Reading through this thread since yesterday, this is also one of the first things I'd recommend be done. In our case, our route reflectors generate our aggregates. All other peering routers simply pass them on if they receive them from the route reflectors via iBGP. Particularly useful if you have a peering router that was generating your aggregate at an exchange point, but suddenly lost its backhaul to your core, and along with it, its iBGP session. Not that I'm recommending it, but one of the unintended benefits we've seen of running a BGP-free core (for IPv4, that is) is that given how long core boxes take to boot, and how slow they may sometimes be in fully converging their BGP tables (while potentially blackholing traffic in the process, hence the little useful knobs in OSPF and IS-IS), not having to run BGP in the core means only edge routers are affected by a system restart. This would limit outages to a smaller part of the network than if a core router were restarting. Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/