Authentication for OSPFv3 Address Family support in IOS-XE? Think again

Bottom line up front: Cisco has a broken implementation of OSPFv3 authentication.

This story begins like many do with network engineers trying to do their best in implementing IPv6 after a thorough and exhaustive engineering exercise.  Cisco’s Aggregation Services Router (ASR) routing platform running IOS-XE, starting with version 3.1.0 until the most recent  3.09.02 S, provided configuration features for using the OSPFv3 Address Families.  This version of OSPFv3 supports the sending of routes for IPv6, IPv4 and Virtual Routing and Forwarding (VRF) tables all over a single routing protocol.  Many of us in the IPv6 community were excited with this feature as it adds new capabilities for converged routing.  For more information on the details on OSPFv3 Address Families take a look at the RFC.

How Cisco’s OSPFv3 Implementation works

OSPFv3 address family support works mostly like the standard OSPFv3 in Cisco IOS.  The key differences is how the commands are laid out in the IOS.  This is how the route process and interface configuration looks in standard OSPFv3:

ipv6 router ospf 1
passive interface default
no passive interface gi0/1
area 0 normal

interface gi0/1
ipv6 ospf 1 area 0
ipv6 ospf authentication ipsec spi 200 sha1 12345678900987654321ABCDEFFEDCBA12345678

Now this is what OSPFv3 Address Families looks like:

router ospfv3 1

address-family ipv6 unicast vrf RED
passive interface default
no passive interface gi0/1
area 0 normal

interface gi0/1
ospfv3 1 area 0
ospfv3 authentication ipsec spi 200 sha1 12345678900987654321ABCDEFFEDCBA12345678

The differences are subtle except for the added support of IPv4 and VRF address families.  These are features the standard OSPFv3 does not support.

How it Breaks

After OSPFv3 adjacencies are formed when using authentication, all seems well for a few days.  You will begin to notice losing routes to various sites.  When doing a “show ospfv3 neighbor,” you discover the adjacency goes from INIT, EXSTART, then to DOWN.  This repeats indefinitely.  Doing debugs “debug ospfv3 events/adj/hello” will yield little information, except what seems like some kind of layer 2 problem (e.g MTU issues, etc).  Even restarting the process “clear ospfv3 proc” does not fix or repair the problem.  The only fix is to manually remove the authentication SPI and re-apply it to all interfaces the router has it applied on.

Let me say that again: remove the IPsec SPI and re-apply it.  Yes, go back and re-read, troubling isn’t it?

Cisco’s Response to the Issue?

Cisco’s response to this apparent bug is almost as disturbing as the workaround.  Cisco’s response is OSPFv3 address family support is not a supported feature, therefore, OSPFv3 authentication is also not supported.  A feature is documented in support and feature listing, provided in the CLI, and with hundreds of configuration and documentation instructions online; is not supported and they will not be fixing it.  Cisco estimates are support are sometime in 2014.  The good news is they filed a bug report, not for the OPSFv3 authentication issue, but to remove the posted online documentation.

Cisco is likely to begin the process of removing their online documentation, so I would like to provide it here for your reading pleasure 🙂

What Next?

Moral of the story here is IPv6 deployment in the enterprise is a painful one, wrought with vendor promises and the lack of true parity with IPv4.  This is not to say don’t deploy IPv6, but deploy carefully and methodically.  Test out these designs in a lab before implementing.

How Tachyon Dynamics Can Help

We at Tachyon Dynamics have deep experience in deploying IPv6 in many enterprises and test environments, and are ready to help you achieve your IPv6 goals.  Feel free to read our website on our IPv6 capabilities.  We also provide world-class IPv6 training, take a look.  If you have any questions, please feel free to contact us any time!

Scroll to Top