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
@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. :)
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
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
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
Thanks Ivan- do you know the reason for this exception...
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
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:
Each router advertising:
Each router advertising:
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:
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