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. 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 the 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 (for example, Frame Relay subinterfaces, but also unnumbered Ethernet interfaces) even when the subnet masks don’t match. The routers in my 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

11 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.
  2. What can I say ... your mind is even more devious than mine :D
  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. :)
  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.
  5. It might be easiest to use unnumbered dialup interfaces.
  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
  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
  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

  9. Thanks Ivan- do you know the reason for this exception...
  10. Hi there,

    I am currently working on reverse-engineering an OSPF DB and think the reason for not been able to be on the same network for both ends of a numbered p2p link is the fact that otherwise any area's router cannot work out the plumbing if these two routers have parallel links. Let's in fact remember though that these interface ip addresses are just IDs for the interfaces (that are in fact always considered transit interfaces and thus never source or destination of the traffic) and are NOT routed since it is their equivalent stub link (i.e. network/mask) that is routed instead.
    So, say for example that router 1 has link id (i.e. numbered interface ip addresse) A and B, and Router 2 has links C and D, then how one can identify by looking at Type-1 LSA, that the connections are (A-C and B-D) or (A-D and B-C) ?
    This holds though for numbered p2p links ...but what about unnumbered p2p links ? Unnumbered p2p interfaces are not identified by their interfaces ip address but by their MIB ifindex. How can any router in the area work out the plumbing of parallel unnumbered P2P links between any two routers ?
    This very same doubt was expressed by Jitendra Sharma @ the very end of this blog https://packetpushers.net/ospf-graphs-lsas-and-the-lsdb/

    Ciao
    Andrea

  11. Hi all,
    Forget my previous post - the question was ill-defined.

    RFC 2328 says the following @ 16.1.2.b:
    "
    Look up the vertex W's LSA (router-LSA or network-LSA) in Area A's link state database. If the LSA does not exist, or its LS age is equal to MaxAge, or it does not have a link back to vertex V, examine the next link in V's LSA.[23]
    "
    With [23] being the following:
    "
    Note that the presence of any link back to V is sufficient; it need not be the matching half of the link under consideration from V to W. This is enough to ensure that, before data traffic flows between a pair of neighboring routers, their link state databases will be synchronized.
    "

    Well, this means that OSPF/SPF doesn't really care if between two routers, being router 1 (with p2p numbered interface A and B towards 2) and router 2 (with p2p numbered interfaces B and C towards 1) with the actual connectivity/plumbing being A-C and B-D, there is a situation where R1 advertises (as transit p2p) only A in its LSA1 while R2 advertises only D or both B and D in its LSA1 for some reason as long as there is some ‘loose’ form of bi-directionality (i.e. not matching halves) which in this scenario it is indeed guaranteed since there are at least two working halves as such.

    Regarding the mask/network mismatch check though and thus the actual subject of this blog post, I think the following holds true:
    this excerpt from RFC 2328 @ 2.1 that says the following:
    " Interfaces to point-to-point networks need not be assigned IP addresses. When interface addresses are assigned, they are modeled as stub links, with each router advertising a stub connection to the other router's interface address. Optionally, an IP subnet can be assigned to the point-to-point network. In this case, both routers advertise a stub link to the IP subnet, instead of advertising each others' IP interface addresses.
    "

    So, it looks like that you can have the following possible scenarios:

    1. /32 P2P numbered:
      Each router advertising:
      • A P2P connection to the other router ID (seen within the incoming helloes and advertised as Link ID) with their local IP as Link Data
      • A stub link to the other router's interface address (seen as the SRC IP of incoming Helloes)
    2. P2P unnumbered:
      • Each router advertising a P2P connection to the other router ID (seen within the incoming helloes and advertised as Link ID) with their local MIB Ifindex as Link Data
    3. /N P2P numbered:
      Each router advertising:
      • A P2P connection to the other router ID (seen within the incoming helloes and advertised as Link ID) with their local IP as Link Data
      • A stub link to the IP subnet

    In this latter and third case it looks like that at least IOS doesn’t complain if there’s a mask mismatch but it does complain if there’s a network mismatch while JUNOS complains for both mismatches. The first gut feeling is that both of these matches are unnecessary since:

    • IP addresses in this case (i.e. P2P numbered) are just IDs and are not routed as such
    • We have just proved that there is no need for OSPF/SPF to work out the exact plumbing between two routers with parallel links as just any two halves would do. [note 23 @ RFC 2328]
    • There is no requirement for a next hop to have an ip address if the destination is a router which connects to the calculating router via a p2p interface (RFC 2328 @ 16.1.1 )

    Well, then, past the gut feeling, the only reasonable answer at this stage and after all these evidences to me is that there is an operational/practical requirement from the vendors whereby if you do decide (as it’s optional) to assign a subnet to a transit link then that means you want that subnet to be consistent across the link and if it is not then it is considered broken and should be fixed (you could have misconfigured a mask and therefore that could trigger/expose an address overlap/clash to the routing for instance) and that means that the adjacency over that link is not gonna form and thus that transit link and its associated mismatched mask and/or networks are not gonna be available to Dijkstra for computing transit/topology routing and stub-networks routing.

    Plus, to further validate the above-mentioned statement:

    On a P2P numbered link the reason for a network mismatch check cannot be to guarantee a working environment to ARP (ARP works with a mask mismatch but not on a network mismatch) since on a p2p interface the reading of the src ip/mac of the incoming helloes does/replaces the ARP job.

    On a P2P numbered link the reason for a network mismatch check cannot be the building of L3 NHs since there is no need for a L3 NH on a transit p2p link. The only NH needed is the L2/MAC NH and that is worked out by looking at the SRC MAC of the incoming helloes. This would be different if it was a transit network (LSA2 and thus broadcast network-type) rather than a transit link (LSA1 and thus p2p network-type). In the former case in fact any DROTHER would only see helloes coming in from the DR/BDR @ regime. So, in that case the interface ip address will have to be functional to discover the L2/MAC NH and therefore in that case a working ARP environment is mandatory in order to discover the L2/MAC NHs. I reckon in fact that the MAC/IP associations are guaranteed to be all discovered by just looking at the any-to-any helloes coming in during the DR election process as that has a dependency on a lucky timing.

    Cheers/Ciao
    Andrea

Add comment
Sidebar