[j-nsp] IPv6

[Mark Tinka]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20100124/0862ae09/attachment.bin>