OSPF ignores subnet mask mismatch on point-to-point links

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.

9 comments:

  1. 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.

    ReplyDelete
  2. What can I say ... your mind is even more devious than mine :D

    ReplyDelete
  3. @je: It has been done already -- http://blog.internetworkexpert.com/2008/01/08/understanding-ospf-network-types/ :)

    @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. :)

    ReplyDelete
  4. 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.

    ReplyDelete
  5. Ivan Pepelnjak25 July, 2009 19:11

    It might be easiest to use unnumbered dialup interfaces.

    ReplyDelete
  6. hello Ivan,

    I 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

    ReplyDelete
  7. Watch out for the JunOS interpretation of the standard.

    http://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

    ReplyDelete
  8. I test this on GNS3 and it's correct HOWEVER, you will still get a network mismatch if both devices do not believe the remote side is in the same network. Try this:
    R1:
    interface Serial0/0
    ip address 192.168.1.5 255.255.255.252
    ip ospf network point-to-point
    !
    router ospf 1
    log-adjacency-changes
    network 192.168.1.0 0.0.0.255 area 0
    neighbor 192.168.1.2
    !
    ip route 192.168.1.2 255.255.255.255 Serial0/0

    R2:
    interface Serial0/0
    ip address 192.168.1.2 255.255.255.252
    ip ospf network point-to-point
    !
    router ospf 1
    log-adjacency-changes
    network 192.168.1.0 0.0.0.255 area 0
    neighbor 192.168.1.5
    !
    ip route 192.168.1.5 255.255.255.255 Serial0/0

    You will still see:
    *Mar 1 00:34:24.471: OSPF: Rcv pkt from 192.168.1.5, Serial0/0, area 0.0.0.0 : src not on the same network

    ReplyDelete

  9. Thanks Ivan- do you know the reason for this exception...

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.