Home / Network / Routing / Point-to-Point OSPF Network Operation over a LAN that connects multiple routers

Point-to-Point OSPF Network Operation over a LAN that connects multiple routers

introduction

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):

lab setup

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

!

deep analysis

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 flapping:

*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 un-shutdown 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 neighborship 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 even if 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.

anything in RFC

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 neighborship 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.

let’s wrap up

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!

Leave a Reply

adsense (1) application (2) architecture (4) asm (4) automatisation (2) backbone (1) cef (1) chd (2) cisco (6) cloud (1) command (5) controller (1) cost (6) coverage (2) debug (9) distance (6) fiber (1) gns3 (1) google (1) hpe (1) http (1) igmp (5) igp (8) internet (2) ip (2) label (1) ldp (1) logique (2) loop (5) lsp (1) mac (3) meraki (1) model (2) mpls (3) mroute (4) multicast (5) nat (1) ndp (2) network (3) next-hop (5) osi (5) pat (1) pim (4) poisoning (6) projet (2) qos (1) radio (3) rib (5) rip (5) route (6) router (6) routing (14) rpf (4) rrm (3) security (3) show (5) simulation (2) solution (2) split-horizon (5) sql (1) ssm (4) static (6) stp (2) summarization (5) switching (1) tcp/ip (1) telecom (1) template (1) traffic engineering (1) translation (1) travail (2) vpn (2) vrf (3) wifi (4) wlan (2)

  • What is the best way of subnetting?
    In this post, let’s recall what is subnetting (for routing and switching purposes) and how it is done. introduction and motivation Network subnetting is very important subject that maybe referred to as VLSM for variable length subnetting. The basic idea is about managing a space of IP addresses (IPv4). Historically, a network length or space
  • SSL VPN to my home network
    In this blog let’s try to connect to a home network from outside (internet) in a secure manner using SSL. NAT and PAT NAT and PAT is what allowed local IP addresses translation or mapping to some routable public IP address (over the internet). This mapping can be one to one (NAT) or many to
  • Routing from scratch… Part 1
    In this serie of posts we’ll explore routing operation. Let’s start from the general idea of how could we manage trafic, a move from one location to another… In the example of the figure presented next, the person in A wants to join its colleagues in location B through the network topology described in the
  • When a gateway says: “I’am not a good gateway… set redirection!”
    In this blog we explore how a gateway (a router) present in a LAN handles routing to the outside of this network and use redirection to enhance this operation. lab setup Our lab setup is 3 routers: R1, R2 and R3, in addition to 2 PC: PC1 and PC2. In this lab, PC1 tries to
  • Multicast: rather than dense, sparse it and let’s meet at rendez-vous point… Part 5
    in this post let’s detail the operation of PIM (Protocol Independent Multicast) in sparse mode. Previous posts tackled the operation of PIM dense mode. Let’s recall that PIM is the multicast routing protocol that allows PIM routers exchange information needed distribute multicast traffic to receivers. lab setup In our setup, Client1 is configured to join
September 2025
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
2930  
Table of Contents
Copied!