Problems with OSPF Adjacency from EX-START to Down
Posted on 19 January 2018 by Beaming SupportIn this scenario we will be working from the diagram below. Our aim is to join a new area to our OSPF routing domain.
(Click image to enlarge)
In the diagram above, R1 will be our backbone router and will be in area 0, whilst R2’s 172.16.10.0 subnet will be in area 10. We will be using the configuration below to create our adjacency.
|
R1 interface Loopback1011 ip address 10.1.1.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.10.10.1 255.255.255.0 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.255 area 0 network 10.10.10.0 0.0.0.255 area 0 ! |
Here we can see that we are advertising both of our subnets into area 0.
Now on to R2 configuration.
|
R2 interface Loopback172 ip address 172.16.10.1 255.255.255.0 ! interface FastEthernet0/0 ip address 10.10.10.2 255.255.255.0 mtu 1200 duplex auto speed auto ! router ospf 1 log-adjacency-changes network 10.10.10.0 0.0.0.255 area 0 network 172.16.10.0 0.0.0.255 area 10 ! |
After waiting a short while, we’ll check the neighbour adjacency with command “show ip ospf ne” and see the following:
After that, we then see this:
Having reviewed our configuration, we notice that there is MTU mismatch on R2’s fastethernet 0/0 interface. So we now have two choices: we can either change the MTU on R2 back to 1500 or we are able to use command “ip ospf mtu-ignore”. You have to wait for the dead timer to expire before this command takes effect.
Explanation
The reason we see the state get stuck at “EXSTART” is because this state is where OSPF will exchange the link state information; if there is a MTU mismatch it is unable to fragment the packet as defined in RFC 2328
“The OSPF protocol runs directly over IP, using IP protocol 89.
OSPF does not provide any explicit fragmentation/reassembly”
Browse our support blog for more technical step-by-steps.