CCIE Troubleshooting OSPF Hello Mismatch

Whilst reading the RFC for OSPFv2 – RFC 2328 I noticed an interesting sentence in section 10.5 about Receiving Hello Packets.

The generic input processing of OSPF packets will have checked the validity of the IP header and the OSPF packet header. Next, the values of the Network Mask, Hello Interval, and Router Dead Interval fields in the received Hello packet must
be checked against the values configured for the receiving interface. Any mismatch causes processing to stop and the packet to be dropped.

However, there is one exception to the above rule: on point-to-point networks and on virtual links, the Network Mask in the received Hello Packet should be ignored.

This could be a nice little trouble ticket, to demonstrate I have a very simple 2 router setup both router addressed and enabled for OPSF however R1 cannot ping the loopback address of R2, we will go through some basic troubleshooting to isolate the issue which will demonstrate the statement in the RFC

First we are going to prove that R1 cannot ping R2’s Loopback 2.2.2.2

[stextbox id=”download” color=”00cc00″]
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#

[/stextbox]

Ok so the problem does exist R1’s loopback cannot ping R2’s loopback. Do we have unicast connectivity between the routers?

[stextbox id=”download” color=”00cc00″]
R1#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R1#
[/stextbox]

Yes we can so the routers can see each other. The next step is to see if the route exists for 2.2.2.2 in R1’s routing table

[stextbox id=”download” color=”00cc00″]
R1#sh ip route 2.2.2.2
% Network not in table
R1#
[/stextbox]

No it doesn’t so lets just check out OSPF – do we have an ospf neighbor? and while we are at it lets check out if the interfaces are enabled for OSPF

[stextbox id=”download” color=”00cc00″]
R1#sh ip ospf neigh
R1#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               1.1.1.1/32         1     LOOP  0/0
Fa0/0        1     0               10.0.0.1/25        10    DR    0/0
R1#
R2#sh ip ospf neighbor
R2#sh ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               2.2.2.2/32         1     LOOP  0/0
Fa0/0        1     0               10.0.0.2/24        10    DR    0/0
R2#
[/stextbox]

The more observant of you will have already spotted the problem? Lets do a debug to see if it shows itself.

[stextbox id=”download” color=”00cc00″]
R1#debug ip ospf hello
OSPF hello events debugging is on
R1#
*Mar  1 07:32:33.838: OSPF: Rcv hello from 2.2.2.2 area 0 from FastEthernet0/0 10.0.0.2
*Mar  1 07:32:33.842: OSPF: Mismatched hello parameters from 10.0.0.2
*Mar  1 07:32:33.842: OSPF: Dead R 40 C 40, Hello R 10 C 10  Mask R 255.255.255.0 C 255.255.255.128
R1#
[/stextbox]

Here you see Mask Received /24 Mask Configured /25 so R2 has a /25 mask whilst R1 has a /24 mask = mismatch

The interfaces have different masks and one of the requirements for an OSPF hello as stated in the RFC above is that the network mask must match, however there is one exception to this and on a point-to-point link or a virtual-link the network mask should be ignored..

So let’s change the ospf network type to point to point and see what happens

[stextbox id=”download” color=”00cc00″]
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int f0/0
R1(config-if)#ip ospf network point-to-point
R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int f0/0
R2(config-if)#ip ospf network point-to-point
R2(config-if)#
*Mar  1 06:33:44.542: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on FastEthernet0/0 from LOADING to FULL, Loading Done
[/stextbox]

As you can see the OSPF neighbor comes up as the network mask is being ignored in the hello

So can R1’s loopback ping R2’s loopback?

[stextbox id=”download” color=”00cc00″]
R1#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/32 ms
R1#
[/stextbox]

Yes! An interesting problem – very simple but if asked to fix this problem without changing any interface settings this is how to do it.