What happens when LAN interfaces are configured as point-to-point network type OSPF interfaces instead of default broadcast type? And more than 2 ospf routers are present on this media? Let’s test this on network (R1, R2, R3):
Routers are Cisco 7206VXR GNS3 emulated and run C7200 ADVENTERPRISEK9-M IOS version 15.3(3)XB12.
They are configured as:
|
R1 |
R2 |
R3 |
|
ena config ter ! router ospf 1 router-id 1.1.1.1 ! inter gi 0/0 ip add 123.0.0.1 255.255.255.0 no shut ip ospf 1 area 0 ip ospf network point-to-point ! |
ena config ter ! router ospf 1 router-id 2.2.2.2 ! inter gi 0/0 ip add 123.0.0.2 255.255.255.0 no shut ip ospf 1 area 0 ip ospf network point-to-point ! |
ena config ter ! router ospf 1 router-id 3.3.3.3 ! inter gi 0/0 ip add 123.0.0.3 255.255.255.0 no shut ip ospf 1 area 0 ip ospf network point-to-point ! |
All routers are connected to the same LAN and ping each other. OSPF adjacency debugging has been configured on all routers. An extract from any router logs shows continuous adjacency flappling:
|
*Aug 27 14:15:29.267: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from LOADING to FULL, Loading Done *Aug 27 14:15:29.579: OSPF-1 ADJ Gi0/0: 3.3.3.3 address 123.0.0.3 is dead, state DOWN *Aug 27 14:15:29.579: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset […]
*Aug 27 14:31:34.971: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from LOADING to FULL, Loading Done *Aug 27 14:31:34.971: OSPF-1 ADJ Gi0/0: Rcv LS REQ from 3.3.3.3 length 36 LSA count 1 *Aug 27 14:31:34.983: OSPF-1 ADJ Gi0/0: 3.3.3.3 address 123.0.0.3 is dead, state DOWN *Aug 27 14:31:34.987: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset […] |
Let’s trace chronologically what happens in R1, R2 and R3:
|
Time stamp |
R1 Router id: 1.1.1.1 |
R2 Router id: 2.2.2.2 |
R3 Router id: 3.3.3.3 |
|
*Aug 27 14:42:20.231 |
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset |
|
|
|
*Aug 27 14:42:20.247 |
OSPF-1 ADJ Gi0/0: 2 Way Communication to 3.3.3.3, state 2WAY |
|
|
|
*Aug 27 14:42:20.295
|
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from LOADING to FULL, Loading Done |
|
|
|
*Aug 27 14:42:20.335 |
|
|
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done |
|
*Aug 27 14:42:22.255 |
|
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset |
|
|
*Aug 27 14:42:22.275 |
|
OSPF-1 ADJ Gi0/0: 2 Way Communication to 1.1.1.1, state 2WAY |
|
|
*Aug 27 14:42:22.343 |
|
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from LOADING to FULL, Loading Done |
|
|
*Aug 27 14:42:22.367 |
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset |
|
|
|
*Aug 27 14:42:22.371 |
OSPF-1 ADJ Gi0/0: 2 Way Communication to 2.2.2.2, state 2WAY
|
|
|
|
*Aug 27 14:42:22.439 |
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done
|
|
|
|
*Aug 27 14:42:27.003 |
|
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset |
|
|
*Aug 27 14:42:27.007 |
|
OSPF-1 ADJ Gi0/0: 2 Way Communication to 3.3.3.3, state 2WAY |
|
|
*Aug 27 14:42:27.079 |
|
: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet0/0 from LOADING to FULL, Loading Done |
|
|
*Aug 27 14:42:27.123 |
|
|
%OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset |
|
*Aug 27 14:42:27.235 |
|
|
%OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done |
Now we shutdown gi0/0 OSPF interface on R3, reinitialize logs and unshutdown it again. We observe these log entries:
|
*Aug 27 17:30:39.807: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up *Aug 27 17:30:40.807: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up *Aug 27 17:30:40.815: OSPF-1 ADJ Gi0/0: Route adjust notification: UP/UP *Aug 27 17:30:40.819: OSPF-1 ADJ Gi0/0: Interface going Up *Aug 27 17:30:40.819: OSPF-1 ADJ Gi0/0: Interface state change to UP, new ospf state P2P *Aug 27 17:30:40.851: OSPF-1 ADJ Gi0/0: 2 Way Communication to 2.2.2.2, state 2WAY *Aug 27 17:30:40.851: OSPF-1 ADJ Gi0/0: Nbr 2.2.2.2: Prepare dbase exchange *Aug 27 17:30:40.855: OSPF-1 ADJ Gi0/0: Send DBD to 2.2.2.2 seq 0x7BC opt 0x52 flag 0x7 len 32 *Aug 27 17:30:40.859: OSPF-1 ADJ Gi0/0: 2.2.2.2 address 123.0.0.2 is dead, state DOWN *Aug 27 17:30:40.863: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from EXSTART to DOWN, Neighbor Down: Adjacency forced to reset *Aug 27 17:30:40.863: OSPF-1 ADJ Gi0/0: Nbr 2.2.2.2: Clean-up dbase exchange *Aug 27 17:30:40.863: OSPF-1 ADJ Gi0/0: 2 Way Communication to 1.1.1.1, state 2WAY *Aug 27 17:30:40.867: OSPF-1 ADJ Gi0/0: Nbr 1.1.1.1: Prepare dbase exchange |
During database exchange, R3 declares R2 as dead and put it in DOWN state.
In the next sequence R3 has succeeded to establish a neigborship with R2 by reaching FULL state. But identically to the first case the neighborship is declared dead and put in DOWN state:
|
*Aug 27 14:42:27.123: OSPF-1 ADJ Gi0/0: Nbr 1.1.1.1: Clean-up dbase exchange *Aug 27 14:42:27.171: OSPF-1 ADJ Gi0/0: 2 Way Communication to 2.2.2.2, state 2WAY *Aug 27 14:42:27.171: OSPF-1 ADJ Gi0/0: Nbr 2.2.2.2: Prepare dbase exchange *Aug 27 14:42:27.175: OSPF-1 ADJ Gi0/0: Send DBD to 2.2.2.2 seq 0x150D opt 0x52 flag 0x7 len 32 *Aug 27 14:42:27.175: OSPF-1 ADJ Gi0/0: Rcv DBD from 2.2.2.2 seq 0x106D opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART *Aug 27 14:42:27.179: OSPF-1 ADJ Gi0/0: First DBD and we are not SLAVE *Aug 27 14:42:27.187: OSPF-1 ADJ Gi0/0: Rcv DBD from 2.2.2.2 seq 0x150D opt 0x52 flag 0x2 len 92 mtu 1500 state EXSTART *Aug 27 14:42:27.191: OSPF-1 ADJ Gi0/0: NBR Negotiation Done. We are the MASTER *Aug 27 14:42:27.191: OSPF-1 ADJ Gi0/0: Nbr 2.2.2.2: Summary list built, size 3 *Aug 27 14:42:27.191: OSPF-1 ADJ Gi0/0: Send DBD to 2.2.2.2 seq 0x150E opt 0x52 flag 0x1 len 92 *Aug 27 14:42:27.211: OSPF-1 ADJ Gi0/0: Rcv LS REQ from 2.2.2.2 length 36 LSA count 1 *Aug 27 14:42:27.215: OSPF-1 ADJ Gi0/0: Send LS UPD to 123.0.0.2 length 76 LSA count 1 *Aug 27 14:42:27.219: OSPF-1 ADJ Gi0/0: Rcv DBD from 2.2.2.2 seq 0x150E opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE *Aug 27 14:42:27.219: OSPF-1 ADJ Gi0/0: Exchange Done with 2.2.2.2 *Aug 27 14:42:27.219: OSPF-1 ADJ Gi0/0: Send LS REQ to 2.2.2.2 length 36 LSA count 1 *Aug 27 14:42:27.231: OSPF-1 ADJ Gi0/0: Rcv LS UPD from 2.2.2.2 length 76 LSA count 1 *Aug 27 14:42:27.235: OSPF-1 ADJ Gi0/0: Synchronized with 2.2.2.2, state FULL *Aug 27 14:42:27.235: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done *Aug 27 14:42:27.339: OSPF-1 ADJ Gi0/0: Rcv pkt src 123.0.0.1 dst 224.0.0.5 id 1.1.1.1 type 4 if_state 4 : ignored due to unknown neighbor *Aug 27 14:42:29.291: OSPF-1 ADJ Gi0/0: Rcv pkt src 123.0.0.1 dst 224.0.0.5 id 1.1.1.1 type 5 if_state 4 : ignored due to unknown neighbor *Aug 27 14:42:29.487: OSPF-1 ADJ Gi0/0: 2.2.2.2 address 123.0.0.2 is dead, state DOWN *Aug 27 14:42:29.491: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from FULL to DOWN, Neighbor Down: Adjacency forced to reset *Aug 27 14:42:29.491: OSPF-1 ADJ Gi0/0: Nbr 2.2.2.2: Clean-up dbase exchange *Aug 27 14:42:29.495: OSPF-1 ADJ Gi0/0: 2 Way Communication to 1.1.1.1, state 2WAY |
In the next sequence of logs we check that after reception of a HELLO from R1 it instantly declares R2 as dead evenif a neighborship has been established with it.
|
*Aug 28 13:20:08.367: OSPF-1 HELLO Gi0/0: Rcv hello from 2.2.2.2 area 0 123.0.0.2 *Aug 28 13:20:08.367: OSPF-1 ADJ Gi0/0: 1.1.1.1 address 123.0.0.1 is dead, state DOWN […] *Aug 28 13:20:08.543: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on GigabitEthernet0/0 from LOADING to FULL, Loading Done […] *Aug 28 13:20:12.947: OSPF-1 HELLO Gi0/0: Rcv hello from 1.1.1.1 area 0 123.0.0.1 *Aug 28 13:20:12.947: OSPF-1 ADJ Gi0/0: 2.2.2.2 address 123.0.0.2 is dead, state DOWN […] *Aug 28 13:20:12.951: OSPF-1 ADJ Gi0/0: 2 Way Communication to 1.1.1.1, state 2WAY […] |
Let’s check what could explain this behavior in corresponding RFCs.
In RFC 2328, OSPF version 2, a point-to-point network is by definition a network that joins a single pair of routers. We could suppose that R3 expects only one neighbor over this link and then considers R1 and R2 to be the same router. A HELLO packet from R2 when R1 is adjacent would be interpreted by R3 as a reconfiguration of R1 (different router-id and source ip address).
What is misleading is that in RFC 5309: Point-to-Point Operation over LAN in Link State Routing Protocols, it is stated that: If the system ID or the router ID of an incoming hello packet does not match the system ID or the router ID for an established adjacency over a p2p-over-lan circuit, the packet MUST be discarded.
This point is not matched in our case as the HELLO packet from R1 in previous R3 log has caused R2 to be declared down and R1 neighorship to move to 2WAY state. To conform to RFC, R3 should have kept R2 adjacency and ignored R1 HELLO packet. We check though that other packet types: 4 or 5, are ignored if they are received with different router-id other than the one corresponding to active neighbor.
In summary:
- OSPF neighborships flaps if more than 2 routers are attached to the same LAN via P2P OSPF network types.
- Neighborship is reset upon reception of a different HELLO packet in this lab routers’ implementation.
- In RFC 5309, it is stated that this HELLO packet should be discarded!
