Wednesday, 23 November 2011

The IPv6 Conundrum

I have been making use of IPv6 for over 10 years now and only recently has support for it become good enough that I can think about treating IPv6 like IPv4. For a long time IPv6 was the poorer cousin of IPv4, less features, less support, more bugs.

Nowadays, I think it's reasonable that most people would expect IPv6 to be production ready. I certainly do. I would expect IPv6 to be able to support all my network needs and in theory replace IPv4.

Yet even today I've managed to find an issue that has broken down this assumption. I'll walk you through it but it's reasonably obscure but still annoying nonetheless.

First a little background. Here at work recently upgraded one of our switch blocks to support gigabit speeds to the desktop PCs. We used Cisco 2960S series for the access layer and 3560X series for the distribution layer.

Something interesting about these models of switches is that they all have a dedicated management port. This is a Good Thing &tm; as it allows you to completely separate your management traffic from your production traffic. For those vague on security, this means it's that much hard to take control of the network. Done properly, and your management IP addresses don't need to be routable on your production network at all.

Of course, this sounded great to me. Given, that this post is about IPv6, you might be able to see where this is going, but stick with me.

The configuration for the 2960S is easy enough. The management port is the only port configured for routed mode and given that they aren't normally L3 switches, this makes the management port the only physical port with an IP address. Simply string all the management ports together onto a management switch and you're away.

So far so good, I have a management port on each access switch, assigned both a IPv4 and an IPv6 address. Each port hooks back to a management switch which is connected to the rest of the network via a router (ok, it should be a firewall I'll admit).

Then we come to the 3560X switches. Since these switches are operating as distribution devices they do routing. Now here's the complicated bit, in order to provide separation for the management port, it needs to be placed into a vrf instance (virtual routing and forwarding) else the management traffic will be routed as per normal along with the production traffic.

Not so hard you say? VRF Lite has been supported on these devices for a while now that's true. VRF lite works a treat, for IPv4. When you start talking about IPv6 inside a vrf, you need to move it up a whole notch. Currently that technology only exists for complicated solutions like 6VPE over an MPLS network.

Thus, whilst I can separate my management traffic for IPv4, IPv6 still isn't supported to the same level and thus I cannot have separated management traffic for these devices if I wish to use IPv6 for management.

Yes, I can hear you say, why use IPv6 for management? You know, the simple answer is because I should be able to. After all this time, there shouldn't be any operational differences between these two protocols.Yet there still are which created issues if one is to try to head down the IPv6 only path.

As a result, I'm still forced to treat IPv6 (as much as I love it) as a lessor protocol compared to IPv4. That's just the way it is.

1 comment:

Ryan Ruckley said...

I have since learned that this may well be a hardware limitation with the TCAM that comes with a 3560X. The latest IOS has the commands for an IPv6 vrf but does not allow them to be configured.