OSPF Adjacency

in CCNP
Something interesting I came across today while browsing the web. We all know that for an OSPF neighbor relationship to form the subnet mask must match on each side of the link. What I came across today states that the subnet mask will be ignored on point-to-point links and virtual links. I decided to lab it up and it does work on point-to-point links with mismatching subnet masks. It is also referenced in RFC 2328
This section explains the detailed processing of a received
Hello Packet. (See Section A.3.2 for the format of Hello
packets.) 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.
I may have been the only one in the dark on this one, but I thought I'd share anyway
This section explains the detailed processing of a received
Hello Packet. (See Section A.3.2 for the format of Hello
packets.) 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.
I may have been the only one in the dark on this one, but I thought I'd share anyway

An expert is a man who has made all the mistakes which can be made.
Comments
CCNA | CCNA:Security | CCNP | CCIP
JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
JNCIS:SP | JNCIP:SP
I've worked a very large full mesh OSPF network that used unnumbered on all links. It was an environment that needed to adapt quickly to change with very little engineering changes when things moved. The best solution was to use unnumbered so IPs on links wouldn't have to be changed. You could use a simple template that could be applied to all interfaces no matter the site.
The fun part was all the VPNs in there
VPNs peered on un-numbered interfaces...??? You've trumped me. THAT has got to be interesting.
I haven't done much with VPNs on routers, just security appliances such as the ASA or Netscreens......
I would think the engineering required to change IP addresses on some links would be far less than the work required to re-engineer the VPN tunnels.
Yeah the tunnels were a bit more of a challenge, but they could be brought up after the links were put in so it wasn't as big of a deal trying to get them up without support. The problem was really the lack of knowledgeable people to support the infrastructure so it needed to be as plug and play as possible because links were always changing.