Recently I was working through one of the CBT nuggets OSPF NBMA labs by memory to try and reinforce the configuration and while I was practising I found that I was having issues with the multipoint OSPF area.
R3 is the hub router and R5 and R6 are the spoke routers.
R5 and R6 interfaces are left as the default OSPF network type which is point to point.
For this scenario the hello-interval is changed on R3’s interface to match the point to point hello interval, which is 10 seconds by default and this allows the neighbourship to form.
What I noticed is that the ip ospf network point-to-multipoint command had not been enabled on R3’s interface. The neighbourship formed but R3 was not receiving any routes from R5 or R6, as you can see from the above picture the 220.127.116.11/24 and 18.104.22.168/24 networks are not in the routing table.
Once the ip ospf network point-to-multipoint command is added, R3 is then able to correctly learn routes from R5 and R6 (the 22.214.171.124/24 and 126.96.36.199/24 networks).
I spent some time troubleshooting this problem, including running debugs but none of the debug commands gave me any feedback which lead me towards finding the issue. It was not until I went back and watched the video that I found the interface type had not been correctly configured and this was the reason R3 was not receiving these routes.
I wrote this post as a reminder to myself when configring OSPF over NBMA, even if the neighbours have formed and everything looks fine with the configuration if you still see issues with routes being learned then check the network type as this can cause problems, like the one mentioned here.
Inter Area summarisation
area range [area number][prefix] [mask]
A router configuration command used to summarise subnets internally to the OSPF domain between different areas. The area number is the area where the networks are currently received from.
External Summarisation and Redistribution
summary address [prefix][mask]
A router configuration command used to create a summary address for routes learned externally from the OSPF domain.
redistribute [routing protocol or prefix][metric] [metric-type][subnets]
A router configuration command used to redistribute routes learned from another routing protocol, you can assign a metric or metric type depending on the internal protocol (metric-type for OSPF/ISIS or just metric for all internal protocols). The subnets keyword tells OSPF to advertise the network as it is received and not to just advertise the classful network as this is the default.
As you all know if you are configuring OSPF an adjacency will not form with a neighbour router if the MTU is different on the connecting interface of each device. I ran into this issue recently when I was configuring a neighbour ship between a Cisco 877w and a Cisco 3750 switch. The thing that threw me off when I was troubleshooting why the adjacency would not form was that I could not find any indication of what the MTU was set to for the interfaces on either device. I checked and double checked but I could not get the adjacency to form so I enabled the debug ip ospf adj, here I could see the issue on the switch
error: OSPF: Nbr 10.23.0.254 has smaller interface MTU
According to this error the MTU on the switch is bigger than the what is configured on the router (by default) so effectively the devices cannot commnuicate. No big deal right we will just change the MTU for the SVI on the switch however when trying to do this we got the following: % ip mtu is not supported on this interface
After some digging around on the internet I found that there were 3 ways to change the MTU on the c3750:
- change the system MTU (system mtu 1500)
- change the system MTU routing (system mtu routing 1500)
- tell OSPF to ignore the MTU missmatch on the interface (ip ospf mtu-ignore)
Change the system mtu will require a reboot of the device, which is not such a hot idea in a production environment. Telling OSPF to ignore the MTU could cause other problems in communication so everything I found said to use this command with care. Changing the system mtu routing was the easiest and it seemed to have the least impact as it is a global command and does not require a reboot of the device.