Troubleshooting OSPF adjacencies

viktor

I've been experimenting with different router images and I tried to establish the OSPF neighbor adjacency between a Cisco and an Alcatel (SR OS) router. OSPF is an industry standard routing protocol (unlike ISIS for example), so it should be supported on both platforms and the two different platforms should be able to exchange LSAs with each other. But for some reason by default they couldn't form the adjacency. So let's troubleshoot this problem. Here is the topology:

Topology

We have three different platforms: CSR1 is a Cisco CSR1000v router running IOS-XE, SR2 is running SR-OS from Alcatel and XR3 is a Cisco XRv router running IOS-XR. So let's try to establish the OSPF adjacency between CSR1 and SR2 according to this very basic topology above. Here is the configuration of CSR1:

CSR1(config)#int lo0
CSR1(config-if)#ip address 10.1.1.1 255.255.255.255
CSR1(config-if)#int g1
CSR1(config-if)#ip address 10.0.12.1 255.255.255.0
CSR1(config-if)#no shut
CSR1(config-if)#router ospf 1
CSR1(config-router)#network 0.0.0.0 255.255.255.255 area 0

And the configuration of SR2:

*A:SR2# configure port 1/1/1 
*A:SR2>config>port# ethernet mode network 
*A:SR2>config>port# no shutdown 
*A:SR2>config# port 1/1/2 
*A:SR2>config>port# ethernet mode network 
*A:SR2>config>port# no shutdown 
*A:SR2>config# router interface "system" 
*A:SR2>config>router>if# address 10.2.2.2/32 
*A:SR2>config>router# interface "to_CSR1"
*A:SR2>config>router>if$ address 10.0.12.2/24 
*A:SR2>config>router>if$ port 1/1/1 
*A:SR2>config>router>if$ no shutdown 
*A:SR2>config>router# interface "to_XR3"
*A:SR2>config>router>if$ address 10.0.23.2/24 
*A:SR2>config>router>if$ port 1/1/2 
*A:SR2>config>router>if$ no shutdown 
*A:SR2>config>router>if$ exit 
*A:SR2# configure router ospf 
*A:SR2>config>router>ospf$ area 0 
*A:SR2>config>router>ospf>area$ interface "system" 
*A:SR2>config>router>ospf>area>if$ back           
*A:SR2>config>router>ospf>area$ interface "to_CSR1" 
*A:SR2>config>router>ospf>area>if$ back 
*A:SR2>config>router>ospf>area$ back 
*A:SR2>config>router>ospf$ area 1 
*A:SR2>config>router>ospf>area$ interface "to_XR3" 

Now they should be forming the adjacency, but they aren't. Let's check the OSPF neighbors on CSR1:

CSR1#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.2.2.2          1   EXSTART/DR      00:00:38    10.0.12.2       GigabitEthernet1

*Jul 18 20:34:11.659: %OSPF-5-ADJCHG: Process 1, Nbr 10.2.2.2 on GigabitEthernet1 from EXSTART to DOWN, Neighbor Down: Too many retransmissions

The adjacency is stuck in the ExStart state, and after some time it went down. And again: they try to build the adjacency, but stuck in the ExStart state. The routers can clearly see each other (they can pass the 2-way state), but they can't exchange LSAs with each other. The situation is similar on SR2:

*A:SR2>config>router>ospf>area$ show router ospf neighbor 
  
===============================================================================
Rtr Base OSPFv2 Instance 0 Neighbors
===============================================================================
Interface-Name                   Rtr Id          State      Pri  RetxQ   TTL
   Area-Id
-------------------------------------------------------------------------------
to_CSR1                          10.1.1.1        ExchStart  1    0       37
   0.0.0.0
-------------------------------------------------------------------------------
No. of Neighbors: 1
===============================================================================

This one is stuck in the ExChange state. Let's run some debugs CSR1: the most useful debug for troubleshooting OSPF adjacencies is the debug ip ospf adj:

CSR1#debug ip ospf adj 
OSPF adjacency debugging is on

*Jul 18 20:35:15.571: OSPF-1 ADJ   Gi1: 2 Way Communication to 10.2.2.2, state 2WAY
*Jul 18 20:35:15.571: OSPF-1 ADJ   Gi1: Neighbor change event
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: DR/BDR election
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: Elect BDR 0.0.0.0
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: Elect DR 10.2.2.2
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: Elect BDR 10.1.1.1
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: Elect DR 10.2.2.2
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1: DR: 10.2.2.2 (Id)
*Jul 18 20:35:15.572: OSPF-1 ADJ   Gi1:    BDR: 10.1.1.1 (Id)

*Jul 18 20:35:15.574: OSPF-1 ADJ   Gi1: Rcv DBD from 10.2.2.2 seq 0x481 opt 0x42 flag 0x7 len 32  mtu 8922 state EXSTART
*Jul 18 20:35:15.574: OSPF-1 ADJ   Gi1: Nbr 10.2.2.2 has larger interface MTU

They can successfully pass the 2-way state: they list each other's RID as active neighbor in their own Hello, and at the end of the 2-way state they can successfully elect the DR/BDR for this segment. But once they exchange their DBD (Database Description) packets we can clearly see what the issue is: Nbr 10.2.2.2 has larger interface MTUSR2 has larger MTU than CSR1. The MTU of the interface is actually transmitted in the DBD packets, and it has to match with the MTU of the neighboring router. In this case SR2 by default has larger MTU (8922 bytes), so we have to lower it to 1500 bytes in order to match.

SR-OS MTU
DBD packet of SR2 with the interface MTU of 8922 bytes

Notice that the DBD packets are actually transmitted as unicast when the routers try to form the neighbor adjacency. And here is the DBD packet of CSR1:

CSR1 MTU
DBD packet of CSR1 with interface MTU of 1500 bytes

Notice that CSR1 supports Link Local Signaling (LLS) data block extension while SR2 does not, but that does not prevent the routers from forming the adjacency. So let's lower the MTU of SR2. SR-OS actually calculates the MTU a bit differently than IOS, SR2 claims that the port 1/1/1 has an interface MTU of 8936 bytes.

*A:SR2>config>router>ospf>area$ show port 1/1/1 

===============================================================================
Ethernet Interface
===============================================================================
Description        : 10/100/Gig Ethernet SFP
Interface          : 1/1/1                      Oper Speed       : 1 Gbps
Link-level         : Ethernet                   Config Speed     : 1 Gbps
Admin State        : up                         Oper Duplex      : full
Oper State         : up                         Config Duplex    : full
Physical Link      : Yes                        MTU              : 8936
Single Fiber Mode  : No                         Min Frame Length : 64 Bytes
IfIndex            : 35684352                   Hold time up     : 0 seconds
Last State Change  : 07/18/2025 20:23:10        Hold time down   : 0 seconds
Last Cleared Time  : N/A                        DDM Events       : Enabled
Phys State Chng Cnt: 1                          

While it is transmitted as 8922 bytes in the DBD packet. It's because it actually includes the Ethernet header itself which is 14 bytes (8922 + 14 = 8936). So we have to change it to 1514 bytes, not to 1500 bytes:

*A:SR2# configure port 1/1/1 ethernet mtu 1514 

And now they could successfully establish the adjacency:

*Jul 18 20:42:33.930: %OSPF-5-ADJCHG: Process 1, Nbr 10.2.2.2 on GigabitEthernet1 from LOADING to FULL, Loading Done
CSR1#show ip ospf neighbor 

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.2.2.2          1   FULL/DR         00:00:32    10.0.12.2       GigabitEthernet1

Now there is a workaround for this issue if you don't want to change the MTU, which is not really recommended, because you want the MTU to be consistent on all of your devices. But let's do this on XR3 which also has a default MTU of 1500 bytes, so we face the same issue just as before:

RP/0/0/CPU0:XR3(config)#int loopback 0
RP/0/0/CPU0:XR3(config-if)#ipv4 address 10.3.3.3/32
RP/0/0/CPU0:XR3(config-if)#int g0/0/0/0
RP/0/0/CPU0:XR3(config-if)#ipv4 address 10.0.23.3/24
RP/0/0/CPU0:XR3(config-if)#no shutdown 
RP/0/0/CPU0:XR3(config)#router ospf 1
RP/0/0/CPU0:XR3(config-ospf)#area 1
RP/0/0/CPU0:XR3(config-ospf-ar)#interface loopback 0
RP/0/0/CPU0:XR3(config-ospf-ar-if)#exit
RP/0/0/CPU0:XR3(config-ospf-ar)#interface g0/0/0/0
RP/0/0/CPU0:XR3(config-ospf-ar-if)#exit
RP/0/0/CPU0:XR3(config-ospf-ar)#commit 
RP/0/0/CPU0:XR3(config-ospf-ar)#do show ip ospf neigh
Fri Jul 18 20:49:55.040 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.2.2.2        1     EXSTART/DR      00:00:37    10.0.23.2       GigabitEthernet0/0/0/0
    Neighbor is up for 00:00:06

Total neighbor count: 1

XR3 cannot form the adjacency with SR2 because of the same issue: SR2 has larger interface MTU:

RP/0/0/CPU0:XR3#debug ospf 1 adj 
Fri Jul 18 20:52:45.109 UTC
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:  Neighbor change Event on intf GigabitEthernet0/0/0/0
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:  DR/BDR election on GigabitEthernet0/0/0/0 
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:  Elect BDR Router ID 10.2.2.2(IP Addr 10.0.23.2) 
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:  Elect DR Router ID 10.3.3.3(IP Addr 10.0.23.3)
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:        DR: 10.3.3.3(Id) 10.0.23.3(IP Addr)
RP/0/0/CPU0:Jul 18 20:52:59.658 : ospf[1018]:       BDR: 10.2.2.2(Id) 10.0.23.2(IP Addr)
RP/0/0/CPU0:Jul 18 20:53:04.317 : ospf[1018]:  Retransmitting DBD to 10.2.2.2 on GigabitEthernet0/0/0/0
RP/0/0/CPU0:Jul 18 20:53:04.317 : ospf[1018]:  Retransmitting DBD to 10.2.2.2 on GigabitEthernet0/0/0/0
RP/0/0/CPU0:Jul 18 20:53:04.317 : ospf[1018]:  Send DBD  to 10.2.2.2(10.0.23.2) on GigabitEthernet0/0/0/0 seq 0x5525 opt 0x52 flag 0x7 len 32, vrf default vrfid 0x60000000
RP/0/0/CPU0:Jul 18 20:53:04.317 : ospf[1018]:  Rcv DBD  from 10.2.2.2(10.0.23.2) on GigabitEthernet0/0/0/0 seq 0x5525 opt 0x42 flag 0 len 112 mtu 8922 state EXSTART vrf default vrfid 0x60000000
RP/0/0/CPU0:Jul 18 20:53:04.317 : ospf[1018]: Nbr 10.2.2.2 has larger interface MTU

We can actually resolve this issue without changing the MTU (again this is NOT recommended): there is command exists on IOS the mtu-ignore. If we issue this on XR3 the interface MTUs don't actually have to match anymore in order to form the adjacency:

RP/0/0/CPU0:XR3(config)#router ospf 1
RP/0/0/CPU0:XR3(config-ospf)#area 1
RP/0/0/CPU0:XR3(config-ospf-ar)#mtu-ignore 
RP/0/0/CPU0:XR3(config-ospf-ar)#commit


RP/0/0/CPU0:XR3(config-ospf-ar)#RP/0/0/CPU0:Jul 18 20:56:00.645 : ospf[1018]: %ROUTING-OSPF-5-ADJCHG : Process 1, Nbr 10.2.2.2 on GigabitEthernet0/0/0/0 in area 1 from LOADING to FULL, Loading Done, vrf default vrfid 0x60000000 

RP/0/0/CPU0:XR3(config-ospf-ar)#do show ip ospf neigh
Fri Jul 18 20:56:17.224 UTC

* Indicates MADJ interface
# Indicates Neighbor awaiting BFD session up

Neighbors for OSPF 1

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.2.2.2        1     FULL/BDR        00:00:32    10.0.23.2       GigabitEthernet0/0/0/0
    Neighbor is up for 00:00:16

Total neighbor count: 1

The moment I issued the commit the routers successfully formed the adjacency. Remember this does not change the MTU! This "solution" only skips the step when XR3 checks the MTU in the DBD. Now all three routers have exchanged LSA successfully, there is the LSDB of SR2:

*A:SR2# show router ospf database 

===============================================================================
Rtr Base OSPFv2 Instance 0 Link State Database (type: All)
===============================================================================
Type    Area Id         Link State Id   Adv Rtr Id      Age  Sequence   Cksum
-------------------------------------------------------------------------------
Router  0.0.0.0         10.1.1.1        10.1.1.1        1206 0x8000000d 0xb906
Router  0.0.0.0         10.2.2.2        10.2.2.2        1205 0x80000006 0x1564
Network 0.0.0.0         10.0.12.2       10.2.2.2        1205 0x80000001 0xf321
Summary 0.0.0.0         10.0.23.0       10.2.2.2        396  0x80000002 0x5076
Summary 0.0.0.0         10.3.3.3        10.2.2.2        396  0x80000001 0xf6dd
Router  0.0.0.1         10.2.2.2        10.2.2.2        397  0x80000007 0x631e
Router  0.0.0.1         10.3.3.3        10.3.3.3        398  0x80000002 0xdfbf
Network 0.0.0.1         10.0.23.3       10.3.3.3        398  0x80000001 0xc718
Summary 0.0.0.1         10.0.12.0       10.2.2.2        1204 0x80000003 0xc709
Summary 0.0.0.1         10.1.1.1        10.2.2.2        1204 0x80000001 0x39a1
Summary 0.0.0.1         10.2.2.2        10.2.2.2        2061 0x80000002 0x201c
-------------------------------------------------------------------------------
No. of LSAs: 11
===============================================================================

We can verify that SR2 works as an ABR: it creates both Router LSAs as well as Type-3 Summary LSAs for both areas.

*A:SR2# show router ospf status 

===============================================================================
Rtr Base OSPFv2 Instance 0 Status
===============================================================================
OSPF Cfg Router Id           : 0.0.0.0
OSPF Oper Router Id          : 10.2.2.2
OSPF Version                 : 2
OSPF Admin Status            : Enabled
OSPF Oper Status             : Enabled
Graceful Restart             : Disabled
GR Helper Mode               : Disabled
Preference                   : 10
External Preference          : 150
Backbone Router              : True
Area Border Router           : True
AS Border Router             : False

 

You should also read: