Hey Mark, > > Yes a good practice is to separate internet routes from internal/services > > l3vpn routes onto separate BGP control planes (different sessions at least) > > so that malformed bgp msg will affect just one part of your overall BGP > > infrastructure. > > I see you've been giving this advice for quite some time now.
I'm siding with Adam here. His disaster scenario actually happed to me in 3292. We ran for years VXR VPN route-reflectors, after we changed them to MX240 we added lot more RR's, with some hard justifications to management why we need more when we've had no trouble with the count we had. After about 3 months of running MX240 reflectors, we got bad BGP UPDATE and crashed each reflector, which was unprecedented outage in the history of the network. And tough to explain to management, considering we just had made the reflection more redundant with some significant investment. I'm sure they believed we just had cocked it up, as people don't really believe in chance/randomness, evident how people justify that things can't be broken, by explaining how in previous moment in time it wasn't broken, implying that transitioning from non-broken to broken is impossible. Note, this is not to trash on Juniper, all vendors have bad BGP implementations and I'm sure one can fuzz any of them to find crash bugs. Not only is it CAPEX irrelevant to have separate RR for IPv4 and IPv6, but you also get faster convergence, as more CPU cycles, fewer BGP neighbours, less routes. I view it as cheap insurance as well as very simple horizontal scaling. -- ++ytti _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp