Dear Readers,
today I want to talk about OSPFv3. I won’t cover the glory details of OSPFv3, there are smarter guys than me out there who did that already 😉 and there are great resources to familiarize yourself with the protocol. However, it should be noted that OSPFv3 is not only OSPF for IPv6, OSPFv3 brought some major enhancements compared to OSPFv2. Wouldn’t it be cool to benefit from the enhancements in the IPv4 world as well?
In the beginning of our own Dual-Stack deployment back in 2011 we started to use OSPFv3 as main routing protocol (as we used OSPFv2 for IPv4). As I am still heavily involved in network operations here at ERNW, I always found it cumbersome to maintain two routing protocols. (granted, as we aren’t a big company, the network is mostly static without many configuration changes).
Still, I started to evaluate whether I can get rid of OSPFv2, and luckily since 2010 OSPFv3 supports multiple address families and can route IPv4 and IPv6. Awesome! Unfortunately, Cisco only started to support OSPFv3 with multiple address family beginning with 15.1S/15.2M/XE 3.10S (not sure about XR to be honest) and not all of our devices in the production network supported the required image. As our IPv6 traffic ratio increased, and the Cat4948 in place could only process IPv6 in software, it wasn’t that hard to convince Enno to replace it with an 3850.
After the 4948 was replaced and I had checked that every (routing) device supported OSPFv3 with multiple address families, we sat down on a Tuesday evening to migrate our IPv4 routing to OSPFv3.
Our approach was to configure OSPFv3 for IPv4 in parallel to OSPFv2 making sure there are ideally no disruptions to our production traffic. It went all pretty smooth and it was (I may sound a little disappointed) pretty unspectacular. We proceeded to remove OSPFv2 and it was just working as intended/desired. We are now running OSPFv3 for IPv4 and IPv6 for approximately six months without any issue.
Let’s have a look at the configuration of OSPFv3 for both address families. As you can see in the output below, the OSPFv3 router process does now have an address-family submenu where the IPv4 and IPv6 relevant parameters will get configured (including the router-id).
router ospfv3 2
address-family ipv4 unicast
router-id 1.1.1.1
exit-address-family
address-family ipv6 unicast
router-id 1.1.1.1
exit-address-family
As we can see I configured the router-id 1.1.1.1 for both address families to make sure they are consistent for each device. The next difference is that the interfaces that shall participate in the routing process are not configured by the (old school ;)) “network” statement within the router configuration context. I know that this was already possible for OSPFv2 (and my preferred style of configuring the interfaces but your mileage may vary ;)). Looking at the interface configuration of our gateway, we see the following lines relevant to OSPFv3
interface GigabitEthernet0/1
<output omitted>
ipv6 address FE80::1 link-local
ospfv3 2 ipv4 area 0
ospfv3 2 ipv4 network point-to-point
ospfv3 2 ipv6 area 0
ospfv3 2 ipv6 network point-to-point
It should be noted that IPv6 must be active on the interface as both adjacencies will be established over the link-local address:
22:32:50.186 CET: OSPFv3-2-IPv4 HELLO Gi0/1: Send hello to FF02::5 area 0
from FE80::1 interface ID 4
22:32:54.426 CET: OSPFv3-2-IPv4 HELLO Gi0/1: Rcv hello from 11.11.11.11 area 0
from FE80::2 interface ID 64
22:33:00.987 CET: OSPFv3-2-IPv6 HELLO Gi0/1: Send hello to FF02::5 area 0
from FE80::1 interface ID 4
22:34:01.119 CET: OSPFv3-2-IPv6 HELLO Gi0/1: Rcv hello from 11.11.11.11 area 0 from FE80::2 interface ID 64
As we are now running OSPFv3 only, we need to use different commands to verify the adjacencies, as the typical show ip ospf neighbor will of course show no neighbors. Instead we have to use the show ospfv3 ipv4/ipv6 neighbor for verification:
gw1#show ospfv3 ipv4 neighbor
OSPFv3 2 address-family ipv4 (router-id 1.1.1.1)
Neighbor ID Pri State Dead Time Interface ID Interface
11.11.11.11 0 FULL/ - 00:00:32 64 GigabitEthernet0/1
gw1#show ospfv3 ipv6 neighbor
OSPFv3 2 address-family ipv6 (router-id 1.1.1.1)
Neighbor ID Pri State Dead Time Interface ID Interface
11.11.11.11 0 FULL/ - 00:00:31 64 GigabitEthernet0/1
To verify that the routing information between both routers are exchanged we need to consult the routing table. As with the neighbor statement, we need to issue the show ip route ospfv3 for IPv4
gw1#show ip route ospfv3
<output omitted>
Gateway of last resort is 80.148.23.49 to network 0.0.0.0
62.0.0.0/8 is variably subnetted, 18 subnets, 4 masks
O 62.159.96.0/29 [110/2] via 172.17.1.2, 7w0d, GigabitEthernet0/1
O 62.159.96.8/29 [110/2] via 172.17.1.2, 7w0d, GigabitEthernet0/1
O 62.159.96.16/29 [110/2] via 172.17.1.2, 7w0d, GigabitEthernet0/1
O 62.159.96.24/29 [110/2] via 172.17.1.2, 7w0d, GigabitEthernet0/1
O 62.159.96.32/28 [110/2] via 172.17.1.2, 7w0d, GigabitEthernet0/1
<output omitted>
To verify the IPv6 routing table we need to issue the (slightly different) command “show ipv6 route ospf”.
gw1#show ipv6 route ospf
<output omitted>
O 2003:60:4010:1010::/64 [110/2]
via FE80::2, GigabitEthernet0/1
O 2003:60:4010:1020::/64 [110/2]
via FE80::2, GigabitEthernet0/1
O 2003:60:4010:1030::/64 [110/2]
via FE80::2, GigabitEthernet0/1
<output omitted>
Conclusion:
As we have seen today OSPFv3 can be used for routing both protocol families without any issues. We need to get used to a couple of different commands especially for IPv4, but that’s more or less a minor issue. Personally, I am happy to only have one routing protocol in our network and would do it again in a heartbeat. Would I recommend it? Well, it depends 😉 We have a very small network (in comparison to the networks of our customers) and only a handful of network devices. In large environment with all sorts of network devices from different vendors it might be difficult to pull the transition off. Even though the RFC is nearly six years old, you need very recent code for support on your platform (if it is supported at all). So, when you can make sure that nearly every network device supports it I would say go for it. Just be aware that you have to deal with redistribution from OSPFv2 to OSPFv3 and vice versa if some of your gear does not support it.
That concludes our blogpost for today. I hope you enjoyed it and ideally learned something new.
If you have any suggestion or comments, please leave a message.
If you want to hear more about IPv6 or like to chat in person with me, Enno or our exceptional line-up for the IPv6 Security Summit you might consider signing up for the event! I may be biased but I heard we treat our attendees well 😉 We also have a shared dinner (for all speaker and attendees) on Monday evening where you have the possibility to talk to all of us. You shouldn’t miss out on that opportunity!
Best,
Christopher