Hello andrew,
why it required different subnet?.
i labbed this but getting below error when i did with different subnet
*Oct 8 11:06:21.391: OSPF-10 ADJ Gi0/0: Rcv pkt from 192.168.12.2, area 0.0.0.0 : src not on the same network
Hello @lagapidis
on P2P network type, there is no DR/BDR election. Is it correct ?
Hello Sathish
One of the requirements for an OSPF adjacency to form is that the devices be directly connected. This means that by definition, the IP addresses on the connecting interfaces must be on the same subnet.
What Andrew is referring to here when he says ârequires different subnetsâ is that each point-to-point link between any pair of OSPF routers requires a separate subnet. This is in contrast to the point to multipoint mode, where you can have a single subnet within which multiple OSPF adjacencies can occur. Does that make sense?
I hope this has been helpful!
Laz
1 Like
Thank you @lagapidis
1 Like
Hello Sathish
Yes, on a point-to-point network type, there is no DR/BDR election. Take a look at this NetworkLessons note that details these network types for more info.
I hope this has been helpful!
Laz
Hello, everyone.
A lot of resources state that routers stuck in the EXSTART state could indicate a duplicate RID (also an MTU mismatch but thatâs outside of this question).
Iâm not quite sure whether they have this part correct. I havenât found a Cisco document that would imply that, itâs not even here:
What doesnât make sense is that the RID is also included in Hello messages, right? So routers canât just wait till EXSTART to realize that something is wrong, they shouldnât even make it past INIT.
Thank you
David
Hello David
Take a look at my response here, it should clear up the issue:
I hope this has been helpful!
Laz
Hello Laz.
Thanks, I didnât notice I asked a similar question twice 
David
1 Like
Hello, everyone.
I have these two routers configured (R5-R4). R4 has an MTU of 1400 while R5 has an MTU of 1500
If I configure the ip ospf mtu-ignore command on R5 (the higher MTU one), the adjacency works and enters the full state. If I configure it on R4, it remains stuck in EXSTART/EXCHANGE.
How does this work and why does it work this way? I originally thought it has to be configured on both sides because both sides check the MTU, do they not? So why does it only work on the Router with the higher MTU and why doesnât it need to exist on both?
Thank you
David
Hello David
This behavior is directly related to the statement in RFC 2328 which defines OSPFv2 which states:
If the Interface MTU field in the Database Description packet
indicates an IP datagram size that is larger than the router can
accept on the receiving interface without fragmentation, the
Database Description packet is rejected.
Notice the wording. If it is larger than⌠This results in an asymmetry between the two routers. If R5 has an MTU of 1400 and R4 has an MTU of 1500, then the MTU check will be successful in one direction but fail in the other. The check is not that the MTUs match, but that one MTU is larger than the other.
So in such a situation, R4 will accept the DBD packet from R5 but R5 will not accept the DBD from R4. When you issue the mtu-ignore command, this issue is resolved, and the adjacency forms.
Why does it work this way? MTU is a characteristic that is checked to ensure fragmentation is avoided. Unlike timers and area IDs, the MTUs are not required to be identical. MTUs must be set to prevent fragmentation, thus the check ensures that the values are âless than or equal toâ. This criterion is fulfilled from the point of view of R4, but not from R5, and this is why there is an asymmetry in the behavior.
Oh wow, Iâm also learning a lot from your questions. Itâs an opportunity to dig deep into the operation of OSPF.
I hope this has been helpful!
Laz