This article describes the behavior of Junos OS when using Ethernet interfaces for Point-to-Point connections, and the resulting adjacency formation.

In certain cases, adjacency issues (INIT state) can occur when using the Point-to-Point Interface type for the Open Shortest Path First (OSPF) protocol. Messages such as this can be seen:

May 10 12:16:17.458702 OSPF rcvd Hello 10.171.222.6 -> 224.0.0.5 (ae0.1 IFL 128 area 0.0.0.0)
May 10 12:16:17.458739 Version 2, length 48, ID 10.0.0.1, area 0.0.0.0
May 10 12:16:17.458768 checksum 0x0, authtype 0
May 10 12:16:17.458799 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 1
May 10 12:16:17.458828 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
May 10 12:16:17.458856 neighbor 10.171.222.1
May 10 12:16:17.458893 OSPF packet ignored: netmask 0.0.0.0 mismatch from 10.171.222.6 on intf ae0.1 area 0.0.0.0
 

 

As per RFC2328, section 10.5 (Receiving Hello Packets), there is one exception where Point-to-Point interfaces and on virtual links, the network mask in the received hello packets should be ignored.

Ethernet interfaces used as Point-to-Point are widely used for troubleshooting purposes. However, in Junos OS, the network mask will still be considered when Ethernet interfaces are used as Point-to-Point. This is an expected Junos OS behavior.

When Ethernet interfaces are used as Broadcast, Junos OS will still consider the network mask; in case of a mismatch, the OSPF neighbor will not form. The RFC exception applies to only actual Point-to-Point interfaces, such as Frame Relay; so, when configuring the Ethernet as Point-to-Point, it is recommended that the network mask also matches with the peer.