OSPFv3 Authentication Trailer
Cisco has added support for RFC7166 as of IOS 15.4(2)T and IOS-XE 3.11S
R1#sh run int gi0/0.12 Building configuration... Current configuration : 125 bytes ! interface GigabitEthernet0/0.12 encapsulation dot1Q 12 ipv6 address 2001:DB8:12:0:10:1:2:1/64 ospfv3 1 ipv6 area 0 end
Standard interface config. I’ll now configure the key chain and authenticate ensure all area 0 adjacencies:
R1#sh run | sec key chain key chain AUTH key 1 key-string RFC cryptographic-algorithm hmac-sha-512 R1#sh run | sec router ospfv3 router ospfv3 1 router-id 184.108.40.206 ! address-family ipv6 unicast authentication mode strict area 0 authentication key-chain AUTH exit-address-family
R1#show ospfv3 interface GigabitEthernet0/0.12 is up, line protocol is up Link Local Address FE80::A8AA:11FF:FE11:1111, Interface ID 15 Area 0, Process ID 1, Instance ID 0, Router ID 220.127.116.11 Network Type BROADCAST, Cost: 1 Cryptographic authentication enabled with strict key lifetime Sending SA: Key 1, Algorithm HMAC-SHA-512 - key chain AUTH Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 18.104.22.168, local address FE80::A8AA:22FF:FE22:2222 Backup Designated router (ID) 22.214.171.124, local address FE80::A8AA:11FF:FE11:1111 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:06 Graceful restart helper support enabled Index 1/1/1, flood queue length 0 Next 0x0(0)/0x0(0)/0x0(0) Last flood scan length is 2, maximum is 2 Last flood scan time is 0 msec, maximum is 0 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 126.96.36.199 (Designated Router) Suppress hello for 0 neighbor(s) R1#show ospfv3 neighbor OSPFv3 1 address-family ipv6 (router-id 188.8.131.52) Neighbor ID Pri State Dead Time Interface ID Interface 184.108.40.206 1 FULL/DR 00:00:33 15 GigabitEthernet0/0.12
Oddly, IOS-XR 5.2.0 still does not support this RFC. Only the previous IPSec authentication:
RP/0/0/CPU0:XR6(config-ospfv3-ar)#authentication ? disable Do not authenticate OSPFv3 packets ipsec Use IPSec AH authentication
OSPFv2 Multiarea Adjacency
In 2012 I wrote another post explaining the problem of suboptimal routing in OSPFv2. RFC5185 was created to allow a single interface to be in multiple areas. At the time of writing that original post, this feature was only in Junos and IOS-XE. This has now been added to IOS 15.4(1)T I recommend you read the above post first to understand the issue.
XR5 goes over the primary link, but XR6 goes over the backup:
RP/0/0/CPU0:XR5#traceroute 220.127.116.11 Thu Aug 7 21:39:21.188 UTC Type escape sequence to abort. Tracing the route to 18.104.22.168 1 10.0.15.1 9 msec 0 msec 0 msec 2 10.0.14.4 0 msec * 0 msec RP/0/0/CPU0:XR6#traceroute 22.214.171.124 Thu Aug 7 21:39:31.999 UTC Type escape sequence to abort. Tracing the route to 126.96.36.199 1 10.0.26.2 0 msec 0 msec 0 msec 2 10.0.24.4 0 msec * 0 msec
Configuration is pretty simple. Add the original area plus the second area to the interface needed:
interface GigabitEthernet0/0.13 encapsulation dot1Q 13 ip address 10.0.13.1 255.255.255.0 ip ospf multi-area 4 ip ospf 1 area 0
R1#show ip ospf 1 multi-area OSPF_MA0 is down, line protocol is down Primary Interface GigabitEthernet0/0.13, Area 4 Interface ID 17 MTU is 1500 bytes Interface DOWN as link is not P2P
An interesting caveat, the interface needs to be in point-to-point mode for this to work:
R1(config)#int gi0/0.13 R1(config-subif)#ip ospf net point-to-point
Once I’ve made the above changes on R1, R2, and R3:
R1#show ip ospf 1 multi-area OSPF_MA0 is up, line protocol is up Primary Interface GigabitEthernet0/0.13, Area 4 Interface ID 17 MTU is 1500 bytes Neighbor Count is 1
A traceroute from XR6 should now follow the path over the primary link:
RP/0/0/CPU0:XR6#traceroute 188.8.131.52 Thu Aug 7 21:55:58.302 UTC Type escape sequence to abort. Tracing the route to 184.108.40.206 1 10.0.26.2 0 msec 0 msec 0 msec 2 10.0.23.3 0 msec 0 msec 0 msec 3 10.0.13.1 0 msec 0 msec 0 msec 4 10.0.14.4 0 msec * 0 msec
OSPF Multi-Area Adjacency is one of those things that can fix some odd corner case topologies. I would not recommend it. The issue is that now R3 has a full area 4 and area 0 database. It’s also messy. Rather redesign your network!
IOS-XR has had this feature since v3.4.1 – A quick config on XR6:
RP/0/0/CPU0:XR6#sh run router ospf Thu Aug 7 22:05:25.833 UTC router ospf 1 area 0 interface GigabitEthernet0/0/0/0.26 network point-to-point ! ! area 10 multi-area-interface GigabitEthernet0/0/0/0.26 ! ! !
To verify on XR you need to look at the last few lines on a show ospf interface:
RP/0/0/CPU0:XR6#show ospf interface gi0/0/0/0.26 Thu Aug 7 22:05:53.841 UTC GigabitEthernet0/0/0/0.26 is up, line protocol is up Internet Address 10.0.26.6/24, Area 0 Process ID 1, Router ID 10.0.26.6, Network Type POINT_TO_POINT, Cost: 1 Transmit Delay is 1 sec, State POINT_TO_POINT, MTU 1500, MaxPktSz 1500 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:07:158 Index 1/1, flood queue length 0 Next 0(0)/0(0) Last flood scan length is 1, maximum is 1 Last flood scan time is 0 msec, maximum is 0 msec LS Ack List: current length 0, high water mark 16 Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 220.127.116.11 Suppress hello for 0 neighbor(s) Multi-area interface Count is 1 Multi-Area interface exist in area 10 Neighbor Count is 1
OSPFv3 Multiarea Adjacency
The config is identical to OSPFv2 so I’m not going to go over it here.
That’s a wrap for today.