IOS IPv6 Gotchas, Pt I

(I’m going to throw in some bonus BGP templates because I like templates when I have lots of neighbors to configure, may elaborate in a later post but with any familiarity with BGP at all, their purpose should be self-evident).

By default, old school IOS (not IOS-XR) presumes that any neighbor you configure (regardless of whether you configure the neighbor with an IPv4 address or an IPv6 address) supports the IPv4 address family.  This is advertised in the capabilities negotiation during the BGP OPEN phase of neighbor establishment.  See also: http://www.cisco.com/en/US/docs/ios/12_3t/ip_route/command/reference/ip2_b1gt.html#wp1078888 for explanation and method for turning this default off.  This post describes the default behaviour and recommends a decent, working configuration that keeps things clean and simple.

IOS  does not support sending IPv6 NLRI (or “routes,” hehe) by default; it requires configuration under BGP’s “address-family ipv6 unicast” stanza.  The effect is that if you just do “neighbor x:x:x:x:x:x:x remote-as xxxxx” as usual (without configuring it for the appropriate address-family), you will establish a TCP connection over IPv6, but send/receive only IPv4 routes.   Not very useful.  In my own opinion, it would be best to make protocol operation as address-family independent as possible.  It would be a good idea (again, in my less-than-humble opinion!) to advertise your IPv4 routes over IPv4-only, and IPv6 routes over IPv6 only.

Editor’s note: As an aside, caveats to this approach include using IS-IS to advertise both address-families, but since IS-IS runs directly on top of the data-link and has no real dependency on IPv4 or IPv6, it’s not really much of a caveat, haha.  Anyway, when that magic day comes along where you want to turn down IPv4 processing on a router, you need only turn down the IPv4 BGP sessions, or remove IPv4 address-family capability from IS-IS, or turn off OSPFv2…etc.

If one side of the BGP session is left to defaults, and the other side is configured to support only the IPv6 address family, the adjacency never comes up due to capability mismatch (one side supports IPv6 NLRI only, other side supports only IPv4).  For the session to come up, both sides have to support the same NLRI.

IOS provides a simple way to adjust your BGP configuration to handle this: the “no bgp default ipv4-unicast” command under the router bgp process as described in the link above.  After entering this command, the configuration is converted to address-family syntax, and neighbors must be explicitly activated to advertise one or more address families (typically IPv4 and IPv6 unicast).   This conversion does not affect existing BGP sessions.

After trying to add an IPv6 neighbor under the IPv6 address family, but before disabling the default behaviour of sending IPv4 unicast routes over all BGP sessions on an IOS router, the configuration looks a little like this:

router bgp 65000
!
template peer-policy CORE-POLICY
next-hop-self
soft-reconfiguration inbound
send-community both
exit-peer-policy
!
template peer-session IPV4-SESSION
remote-as 65000
update-source Loopback100
version 4
fall-over
exit-peer-session
!
template peer-session IPV6-SESSION
remote-as 65000
update-source Loopback300
version 4
fall-over
exit-peer-session
!

neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.1 inherit peer-session IPv4-SESSION
neighbor 2001:DB8:E53C::2 remote-as 65000
neighbor 2001:DB8:E53C::2 inherit peer-session IPv6-SESSION
!
address-family ipv4
neighbor 10.1.1.2 activate
neighbor 10.1.1.2 inherit peer-policy CORE-POLICY
no neighbor 2001:DB8:E53C::2 activate
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:E53C::2 activate
neighbor 2001:DB8:E53C::2 inherit peer-policy CORE-POLICY

If that IPv6 neighbor isn’t explicitly deactivated under the IPv4 configuration, there is a very good chance that the session may not come up due to parameter mismatch. After disabling the default behaviour of advertising IPv4-unicast routes over all sessions, the configuration begins to make more sense:

router bgp 22995
!
no bgp default ipv4-unicast
!
neighbor 10.0.0.1 inherit peer-session IPv4-SESSION
neighbor 2001:DB8:E53C::2 inherit peer-session IPv6-SESSION
!
address-family ipv4
neighbor 10.0.0.1 activate
neighbor 10.0.0.1 inherit peer-policy CORE-POLICY
exit-address-family
!
address-family ipv6
neighbor 2001:DB8:E53C::2 activate
neighbor 2001:DB8:E53C::2 inherit peer-policy CORE-POLICY
exit-address-family

The end result is a completely separate IPv6-only session to a neighbor, sending/receiving only IPv6 NLRI.  This keeps your IPv4 completely separate from IPv6, as far as BGP topology is concerned; and it keeps your configuration clean.  Although it’s also perfectly workable to send all NLRI for all address families over a single transport connection (i.e. send all IPv4/IPv6 routes using only IPv6 transport, or only IPv4 transport), I just wouldn’t do it; no sense hitching the IPv6 freight train to the IPv4 wagon.

IPv6

Y’know, I really wanted to throw myself into IPv6 this year; then I went and got distracted by a large-scale VMware deployment (hence the lack of posting over the last…three months).  We’re a three-person shop at $dayJob these days, supporting 700+ users across 20+ different countries, and that’s regrettably meant that the things that aren’t required RIGHT NOW get pushed off to the side.

Now that I’m finally finishing that up and comfortable enough with my giant NetApp storage array that I can go without looking at it for a few days, I’m starting to look back into IPv6 again.

I’ve some familiarity with the way the header looks and some basic deployment scenarios — but mostly just those acquired from my CCNP studies of old. Having gone through months of NANOG archives and found disagreement all over the ISP community with respect to the best way(s) to deploy IPv6, I’m even more intimidated.

(That said, I’ve done a paint-by-numbers deployment of IPv6 over MPLS VPN with some Cisco 3800-series routers we snagged from a decommissioned branch to bring some of my BGP/MPLS studies together; that was a ton of fun)

I’ve been prepping for it for a while, though, in terms of all my new hardware acquisitions. Anyone pushing something that wasn’t v6-aware right NOW has been shown the door since 2007, so I’m just about ready to go dual-stack across the enterprise (though few if any of my ISP’s are ready to support this deployment). Going to be one of those things where I’ll just have to take the documentation and start pushing it out and breaking it to see what works and what doesn’t.

But the most frightening thing of all is the sheer size of the address space. Jesus Christ, it’s big. Like, really big. Big enough that I completely forgot how subnetting worked in the first place. 32-bit dotted-decimal was easy to wrap one’s head around; hard to find anyone who’s been doing this for a while who doesn’t have a few hundred critical infrastructure/server addresses committed to memory — safe to say those days are gone.

Think of all the pages wasted on teaching those new to networking how to properly subnet in order to efficiently provision what was once a scarce resource, and how those practices are still being taught without a really big caveat: “Oh by the way, you don’t really have to know this anymore; the value of these pages is going to plummet in the next five years, and here’s why…”

For a lot of people, it’s going to be the first large technical revolution they’ve had to face.  IP hasn’t changed in over three decades; new features were merely layered on top of a fully functional protocol on demand.  But now everything that uses that fundamental protocol has to change; the magnitude of this project is enormous and IT departments who haven’t yet begun planning are years behind the curve (and this is a lot of IT departments, by my anecdotal measure).

I look around at the people who’ve been doing this stuff for years; they’d probably hoped to not have to face this before retirement, but that’s not going to be the case. How does one best go about convincing them that not only is a an IPv6 /64 a completely valid way to address a point-to-point link^[1], but a way that’s encouraged over the old practice of allocating an IPv4 /30 (or in the case of IPv6, a /127)?

There’s going to be a lot of money to be had in the IPv6-migration consulting business.

[1]: http://tools.ietf.org/html/draft-palet-v6ops-point2point-01