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
