The common wisdom says that the subnet mask mismatch will stop the OSPF adjacency from forming (I’ve included a sample debugging printout in yesterday’s post). In reality, the subnet mask is checked only on the multi-access interfaces and is ignored on point-to-point links. The source of this seemingly weird behavior is Section 10.5 of RFC 2328 which says:
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, HelloInterval, and RouterDeadInterval 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. In other words, the above fields are really describing the attached network's configuration. 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.
Cisco conforms strictly to the RFC and allows OSPF neighbors to form adjacency over a point-to-point link (Frame Relay subinterface in my test lab) even when the subnet masks don't match. The routers in the lab happily formed the OSPF adjacency even though I've used a /24 mask on one end of the link and a /30 mask on the other end:
S1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Se1/0.100 1 1 10.0.8.1/24 64 P2P 1/1 Lo0 1 1 10.0.0.1/32 1 LOOP 0/0 S1#show ip ospf neighbor Serial1/0.100 Neighbor ID Pri State Dead Time Address Interface 10.0.0.11 0 FULL/ - 00:00:38 10.0.8.2 Serial1/0.100 C1#show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Fa0/0 1 0 10.0.1.1/24 10 BDR 1/1 Lo0 1 0 10.0.0.11/32 1 LOOP 0/0 Se1/0.100 1 1 10.0.8.2/30 64 P2P 1/1 Se1/0.101 1 1 0.0.0.0/0 64 P2P 1/1 C1#show ip ospf neighbor Serial1/0.100 Neighbor ID Pri State Dead Time Address Interface 10.0.2.2 0 FULL/ - 00:00:37 10.0.8.1 Serial1/0.100
This behavior was brought to my attention by Shahid Rox. Thanks.
Posts
Of course, if you're really interested in punishing yourself with exotic OSPF behavior, setting the OSPF network type to point-to-point will allow you to form mismatched adjacencies across multiaccess interfaces.
ReplyDeleteWhat can I say ... your mind is even more devious than mine :D
ReplyDelete@je: It has been done already -- http://blog.internetworkexpert.com/2008/01/08/understanding-ospf-network-types/ :)
ReplyDelete@ivan: Btw, netmask ignorance in case of adj formation over ptp-ifaces is clearly documented in ... (God forbid! :) big-J-vendor courseware.
Btw, the next step would be to mix numbered/unnumbered ifaces but.. *UNFORTUNATELY* it's prohibited. :)
Hi Ivan, I've got this situation, we have E1 with pvdm2-36dm to terminate branch dial connection. This pvdm works as async interfaces... while we have over than 50 branches we only have 31 lines available on E1, thus the point to point addressing will be assigned by dialing branch. Up to this point it's okay but the mask is /32, while HQ needs to understand branch' lan segment through routing protocol. The adjacency just won't come up due to the mismatched mask. Please help... what can I do in this situation.
ReplyDeleteIt might be easiest to use unnumbered dialup interfaces.
ReplyDeletehello Ivan,
ReplyDeleteI have some inconsistent behavior with ospf adjacencies which are established over links with mismatches masks. I have issues with ospf installing routes which are learned over an adjacency as described above, any ideas?
thanks
max
Watch out for the JunOS interpretation of the standard.
ReplyDeletehttp://kb.juniper.net/InfoCenter/index?page=content&id=KB23533
Section 1.2 of RFC 2328 defines point-to-points as.... "Point-to-point networks: A network that joins a single pair of routers. A 56Kb serial line is an example of a point-to-point network."
However Juniper seems to enforce mask checks for 'ethernet' point-to-point network types. That's a bummer because Quagga likes to set the Mask to 0.0.0.0 on point-to-pont adjacencies. http://forums.juniper.net/t5/Junos-and-Junosphere/ospf-point-to-point-interface-type-on-ethernet/td-p/39375