On Sunday 24 January 2010 08:40:26 am Richard A Steenbergen wrote: > Given that, I see no real benefit to running independent > iBGP sessions, only more sessions which need to be > configured unnecessarily (and when they land on a Cisco, > they aren't nearly as easy to deploy and maintain > automatically :P).
Speaking of Cisco, one of the reasons we developed separate policy frameworks (Cisco's Route Maps) is because when we started deploying v6 over 2yrs ago, I recall we had some issues with IOS in matching v4 and v6 prefix lists in the same routing policy for a single iBGP multi-AFI session or independent iBGP sessions sharing the exact same routing policy. It's been a while but I can't quite remember whether we had somewhat similar issues with JUNOS around the same time (we might have, it's been a long time), but since we standardize our Cisco and Juniper configurations, we decided to use separate prefix lists/route filters for v4 and v6. > Can't say that I've ever seen an > instance where there would be a benefit from running the > two seperately either. War story: A little while after we completed our dual-stack deployment, we had an issue where v4 access to one remote edge router had been knocked out (just a couple of days before OoB access was deployed). I can't recall whether it's because someone hosed the v4 routing policy or managed to lock themselves out, but coming in over v6 fixed it immediately, as that wasn't affected. It's always made sense for us to keep both transports separate re: BGP since then; peer session templates (IOS) and BGP groups (JUNOS) means adding more session configuration when deploying new kit does not increase burden. But then again, this is clearly one of those situations where the cat can be skinned several ways and we're all happy :-). > Now IGP on the other hand is a > different story, I've seen several instances where > something bad happens (mostly to v6) where it pays to > run multi-topology isis so you can turn off v6 on a > particular link when a router decides it just doesn't > want to forward v6 packets via that interface any more. In fact, without proper pre-planning, it is probably safer to run ships-in-the-night OSPF (v2 and v3) than IS-IS, especially because of lack of topology congruency during the initial stages of turning up dual-stack v6 in IS-IS (which JUNOS does by default and IOS doesn't, an interesting situation if you take this position for granted in either platform). Luckily, both current versions of IOS and JUNOS that we support have MT implemented in them, although I know certain platforms currently in the field that do not. This could be troublesome. That said, we still prefer IS-IS, and we always ensure systems deployed not only support v6 in IS-IS, but also MT. War story: We experienced bad bugs in IOS's IS-IS implementation where v6 adjacencies refused to form under certain recovery conditions. After weeks with TAC working on this, it finally got fixed in revised code, however, it never affected our v4 IS-IS adjacencies. Fun times :-). Cheers, Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp