Ticket #05

Ticket #05

Network diagram

IGP diagram


The problem:

R4 can't ping R5's Lo0 IP address. Fix the problem using OSPF commands.

The solution:

First, lets try to ping to R5's Lo0 IP address, 200.3.0.5, from R4.

On R4:

R4#ping 200.3.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.3.0.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Indeed, R4 can't reach R5's Lo0 IP address.


Lets have a look at R4's routing table entry for R5's Lo0 IP address.

On R4:

R4#sh ip route 200.3.0.5
% Subnet not in table

The route is missing. Maybe R4 have a default route?

On R4:

R4#sh ip route 0.0.0.0
% Network not in table   

No default route either.


Look at the IGP diagram, we can see that R4 should has an OSPF neighbor relationship with R5. Lets check this.

On R4:

R4#sh ip ospf neighbor

R4#

R4 has no OSPF neighbors! Which means that R4 has no way to know about R5's Lo0 IP address. Lets check if R4's FastEthernet0/0 is an OSPF enabled interface.

On R4:

R4#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               200.3.0.4/32       1     LOOP  0/0
Fa0/0        1     0               200.3.45.4/24      1     DR    0/0

OSPF is enabled on R4's FastEthernet0/0 interface, which is the interface facing R5. Lets make sure R5's FastEthernet0/0 is also an OSPF enabled interface.

On R5:

R5#sh ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          1     0               200.3.0.5/32       1     LOOP  0/0
Fa0/0        1     0               200.3.45.5/25      1     DR    0/0

OSPF is also enabled on R5's FastEthernet0/0 interface.


Lets sum up what we know until now:

  • We do have a problem. R4 can't ping R5's Lo0 IP address.
  • We know that the cause of the problem is that R4 and R5 haven't formed an OSPF neighbor relationship.
  • We know that OSPF is enabled on the interface connecting R4 and R5 to each other, which is FastEthernet0/0 on both routers.

Our next step will be to start debugging OSPF. First, lets check if R4 and R5 got a unicast connectivity at all.

On R4:

R4#ping 200.3.45.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.3.45.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/12 ms

We can see that R4 and R5 have a unicast connectivity between them. Our next step will be to enable OSPF hello packet debugging.

On R4:

R4#debug ip ospf hello
OSPF hello events debugging is on
R4#
*Dec 12 17:25:55.343: OSPF: Rcv hello from 200.3.5.5 area 0 from FastEthernet0/0 200.3.45.5
*Dec 12 17:25:55.347: OSPF: Mismatched hello parameters from 200.3.45.5
*Dec 12 17:25:55.347: OSPF: Dead R 40 C 40, Hello R 10 C 10  Mask R 255.255.255.128 C 255.255.255.0
R4#un all
All possible debugging has been turned off

Now we can see why R4 can't for an OSPF neighbor relationship with R5. They have a different network masks! The local, R4's, mask is /24 and the remote, R5's, mask is /25.

How can we fix that using OSPF commands? How can we tell the router to ignore the network mask?

Looking the the OSPFv2 RFC, 2328, Section 10.5 we can find the solution:

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.

We can see that if the interface is point-to-point OSPF interface, then the router will ignore the network mask. Lets test this.

On R4:

R4(config)#int f0/0
R4(config-if)#ip ospf network point-to-point

On R5:

R5(config)#int f0/0
R5(config-if)#ip ospf network point-to-point
R5(config-if)#
*Dec 12 17:32:50.775: %OSPF-5-ADJCHG: Process 1, Nbr 200.3.0.4 on FastEthernet0/0 from LOADING to FULL, Loading Done

Right after changing the OSPF network type on both ends of the link, the neighbor relationship is coming up in seconds.

Lets go back to R4 and try again to ping R5's Lo0 IP address.

On R4:

R4#ping 200.3.0.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.3.0.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/9/28 ms

Success!

                                          __ 
.-----.--.--.----.----.-----.-----.-----.|  |
|__ --|  |  |  __|  __|  -__|__ --|__ --||__|
|_____|_____|____|____|_____|_____|_____||__|