[j-nsp] IPv6

[Richard A Steenbergen]

On Sun, Jan 24, 2010 at 06:16:25PM +0800, Mark Tinka wrote:
> 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.

Yeah JUNOS used to have that issue, where you couldn't match IPv4 and
IPv6 routes (either via route-filter or prefix-list) in the same policy.
I'm drawing a blank on which version they fixed it in, but I think it's
been fixed for at least 1-2 years now. Last I looked you still had to do
it in seperate terms like so, but you can use the same policy:

term ipv4 {
    from route-filter 1.2.0.0/16 upto /24;
    then whatever;
}
term ipv6 {
    from route-filter 2001:1234::/32 upto /48;
    then whatever;
}

Of course unlike IOS, with JUNOS you can just use chains/subroutines, so
even if they hadn't added this ability it's entirely possible to work
around it and still use 99% identical policies. We do most of our policy
heavy lifting on JUNOS, so the only time we needed to do this type of 
matching on IOS is customer prefix-lists, where you can just reference 
it on the BGP neighbor instead of a route-map (thus letting you use a 
common customer route-map too :P). IOS will let you define a prefix-list 
of the same name for different AFIs, and will automatically use the 
correct one based on the reference, like so:

ip prefix-list CUSTOMER:12345 permit 1.2.0.0/16 le 24
ipv6 prefix CUSTOMER:12345 permit 2001:1234::/32 le 48

address-family ipv4 unicast
 neighbor 1.1.1.1 prefix-list CUSTOMER:12345 in
address-family ipv6 unicast
 neighbor 2001:1234::12:34 prefix-list CUSTOMER:12345 in

I've spent years trying to talk Juniper into doing a neighbor based
prefix-list config to explicitly reject prefixes before even beginning
policy parsing, but with zero success. In the grand scheme of things
it's a pretty minor nit, but IMHO it would simplify the config, make it 
easier for people who are new to Juniper, and still give you all the 
flexibility of the policy language if the simple "filter this, THEN 
process policy" role that works 95% of the time wasn't enough for you. 
Fortunately I got them to do accepted-prefix-limit instead, which was 
good enough to solve the biggest complication caused by their design 
(tripping max-prefix on peers even though you successfully filtered the 
leak and had no reason to do so).

> >  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.

ISIS multi-topology is IMHO the best combination of avoiding unnecessary
duplication of effort that comes with a ships in the night OSPF config,
while still giving you the flexibility to run divergent topologies when
the proverbial #$%^& hits the fan and your Crisco decides it no longer
wants to forward IPv6 packets over a particular interface (which has
happened to us several times over the years). The biggest annoyance is
you have to remember to set your isis ipv6 metric as well as your
regular interface metric (which defaults to ipv4-unicast only in this
environment), but it's nothing you can't fix with a small commit script. 
We fired every piece of routing gear which couldn't handle this and a 
few other things reliably, which mostly only affected vendor F. :)

> 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.

Been there, done that, got the tshirt. Speaking of t-shirts, I got bored
one day and did this (credit for the original concept goes to Adam
Rothschild):

http://www.printfection.com/ras/PIC-In-A-Box/_p_4646346

Took a while to clean up all the stray lines on the vector art, but it 
prints quite nicely. :)

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)