Troubleshooting OSPF Neighbor Adjacency

Hi Romy,

Each OSPF router should have a unique router ID. This error means that two routers are using the same router ID.

Rene

Hi Rene,

I think MTU also one of the factor to form a neighbor.

Davis

Hi Davis,

That’s correct. A MTU mismatch will prevent two routers from becoming OSPF neighbors unless you use the ip ospf mtu-ignore command on the interface.

Rene

Hi Rene,

I have a doubt with regards to the DROTHER issue that you talked about.
Isnt it alright even if we dont elect DR/BDR/DROTHER etc on the multi access network ?
It is fine if we dont mind a full OSPF neighborship between all the participant routers in the Multi access network.

As such why will they even elect a DR/BDR if we dont want it ? Or is the election compulsory ? Hence we have the DROTHER issue because of 0 priority ?

Hi Vikas,

On a multi-access network (depending on the OSPF network type) you normally have a DR/BDR election. All routers will form a full neighbor adjacency with the DR and BDR, but not with other routers…those are the DROTHERs.

If you see a multi-access network with no DR/BDR and only DROTHERs then you know something is wrong…this can happen because all routers have a priority of 0 or you might have a mismatch in the OSPF network type.

Rene

I dont understand how will it be an issue even if no DR/BDR is elected.

Hi Mansi,

OSPF routers only establish a full neighbor adjacency with the DR/BDR. They don’t exchange information with DROTHERs. So without a DR/BDR, your router will be unable to learn any topology information.

Rene

Hello,

I have a question regarding passive interfaces. From my understanding a “passive interface” under OSPF doesn’t send hello packets and makes adjacencies. I have the following config up on a router and would like clarification:

Routing Protocol is "ospf 250"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 10.16.1.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    10.0.0.0 0.255.255.255 area 28
  Passive Interface(s):
    Embedded-Service-Engine0/0
    GigabitEthernet0/2
    GigabitEthernet0/2.701
    Backplane-GigabitEthernet0/3
    GigabitEthernet0/0/0
    Serial0/3/0

CORVG01#sh ip ospf interface brief 
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Lo0          250   28              10.16.1.1/29       1     LOOP  0/0
SM1/0        250   28              Unnumbered Gi0/2.701 1     DOWN  0/0
Se0/3/0      250   28              10.160.9.2/30      64    DOWN  0/0
Gi0/2.701    250   28              10.0.8.250/24      1     DR    0/0<-------
Gi0/1        250   28              10.16.1.10/31      1     P2P   1/1
Gi0/0        250   28              10.16.1.8/31       1     P2P   1/1

my question is why are we still seeing Gi0/2.701 as on OSPF interface? is it because Interface Gi0/2.701 has an ip address that falls under the network 10.0.0.0 0.255.255.255 area 28 command?

router ospf 250
 router-id 10.16.1.1
 passive-interface default
 no passive-interface GigabitEthernet0/0
 no passive-interface GigabitEthernet0/1
 network 10.0.0.0 0.255.255.255 area 28 <---------

Thanks

HI Rene,

In case of NBMA network type , we should confgigure netwrok as NBMA inplace of broadcast ?
pls explain, in example you configured netwrok as Boradcast ,and earleir also it was broadcast,I think it should be non broadcast. pls clarify

R1(config)#interface serial 0/0
R1(config-if)#ip ospf network broadcast
R2(config)#interface serial 0/0
R2(config-if)#ip ospf network broadcast

Fabian,
You are correct. An interface’s being passive and having its attached prefix advertised are two separate things. As you said, setting an interface as passive means that neighbor relationships will not form via that interface because Hellos are not sent or accepted. However, as you discovered, an interface’s being passive does not prevent the OSPF process from advertising that interface’s prefix out some other interface.

Your network 10.0.0.0 0.255.255.255 area 28 command is what is responsible for this.

Rohitendu,
Cisco has five different options for OSPF over NBMA. Which one you should choose depends on several factors. One important consideration is whether the circuit supports multicast–this will determine whether you must define neighbors manually, or if they can discover each other. Additionally, you need to consider what is the topology of your WAN connection–full mesh, hub and spoke, …? This is important because you must ensure that any router eligible to be a DR or BDR must have reachability to all the other OSPF nodes.

Here is some information on the five different OSPF NBMA network types:

5 Modes of Operation
-Non-Broadcast (NBMA) - RFC Standard
-Point-To-Multipoint - RFC Standard
-Point-To-Point - Cisco Proprietary
-Broadcast - Cisco Proprietary
-Point-To-Multipoint, Non-Broadcast - Cisco Proprietary

Broadcast Mode
-LAN-style operational mode over NBMA (there is no RFC standard for this, hence Cisco proprietary)
-(config-if)# ip ospf network broadcast

Non-Broadcast Mode
-Default mode for X.25, FR, ATM
-Neighbors are statically configured
-Must be on one subnet
-Acts like a LAN environment
-DR/BDR are elected (DR/BDR must have full connectivity to all neighbors). This point will be a design constraint as your only option for a DR/BDR in a hub and spoke topology would be the hub
-Typically used in full mesh networks

Point-To-Multipoint Mode
-Requires a single subnet
-No DR/BDR elected
-Neighbors form automatically as long as the “broadcast” option is chosen in configuring the link
-Typically used in partial mesh networks
-(config-if)# ip ospf network point-to-multipoint

Point-To-Multipoint, Non-Broadcast
-Exactly the same as P2P mode, but neighbors do not form automatically. They must be configured manually

Point-To-Point Mode
-Uses separate sub-interfaces
-Requires different subnets
-No DR/BDR elected
-Neighbors form automatically

Hi Rene,

Please help! My topology is simple. R1–FW–R2. I am running ospf between R1 and R2. Firewall between R1 and R2 is transparent. R1 and R2 are able to ping each other through the firewall. However, I keep getting this error message. The hello and dead timer are identical on both R1 and R2. The neighbor already formed. However, it will disconnect and re-form back and forth…

*Mar  1 03:11:10.743: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Dead timer expired
 --More--
*Mar  1 03:11:15.243: %OSPF-5-ADJCHG: Process 1, Nbr 2.2.2.2 on FastEthernet0/1 from LOADING to FULL, Loading Done


R1#sh ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           1   FULL/DR         00:00:34    192.168.2.2     FastEthernet0/1


```
R1#
router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/1
 network 192.168.2.0 0.0.0.255 area 0

R2#
router ospf 1
 router-id 2.2.2.2
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/1
 network 192.168.2.0 0.0.0.255 area 0
```

Bruce,
It looks like your firewall might be blocking multicast traffic. On a broadcast network type, by default, OSPF needs to have 224.0.0.5 and 224.0.0.6 open.

One way you could test this is to tell OSPF to use unicast for these neighbors. Do this by a simple “neighbor W.X.Y.Z” statement under the OSPF router process where W.X.Y.Z is the IP address of the OSPF neighbor.

Hi Andrew,

I no long get the error message after I allowed 224.0.0.5 and 224.0.0.6 on my transparent firewall. Thank you so much!

Hi Rene

have you ever seen a scenerio that 2 routers are connected to each other and running ospf and one of them has FULL adjastancy and other has 2WAY .what might be the problem ? I had a job interview recently and this was one of them questions .Let me know if you have any idea

thanks

Georgi,
I think this question would need some clarification, and it depends on whether the two routers are the ONLY routers that are neighbors, or whether there are more than two routers.

The situation you describe could happen where the router that is in 2-Way has not been elected as a DR or BDR. In this situation (assuming we are dealing with a multi-access network), this is perfectly normal to have a 2-Way state. Any router that is not a DR or BDR that has a neighbor relationship with another router that is also not a DR or BDR would show up as 2-Way/DROTHER.

Now, if the person asking you this question was talking about where the two routers’ relationship with each other, that is a different story. In other words, let’s say there are two routers: A and B. If you issue “show ip ospf neighbor” on both A and B, and A shows as Full with B, but B shows as 2-Way with A, I don’t have an answer for that situation. In multi-access networks, OSPF only forms a Full relationship with either a DR or BDR, and that Full relationship goes both ways, so in this case A and B should see a Full relationship with each other. If only one side is seeing Full but the other is 2-Way, something is wrong, but I can’t think of what would cause that to happen.

Do you know whether there were only two routers in the scenario presented to you?

Hi Networklesson team ,

I was searching for a issue that “why ospf neighbors will stuck at exstart/exchange state” , i got good explanation at below cisco link .

please note at step 5 :
____________________________________________________________________________________
Router 7 debug output:

***OSPF ENABLED ON ROUTER7, BEGINS SENDING 
HELLOS AND BUILDING A ROUTER LSA  ////please note router building LSA Type 1////
00:17:44: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 64, sending broad/multicast, proto=89
00:17:44: OSPF: Build router LSA for area 0, 
router ID 170.170.11.7, seq 0x80000001

____________________________________________________________________________________

after going through it i have an doubt that at exactly which ospf state which LSAs are sent/transmitted and when the LSDB database is assumed as complete before applying SPF algo ?

Thanks on advance , contents and explanations is very clear crisp .

Sameer.

Hi Sameer,

I have a detailed explanation of the OSPF neighbor adjacency here:

In the LOADING state, LSUs are exchanged and when that’s done, the routers will show that they are synchronized. Once that’s done, they have everything they need to run SPF.

You can see the adjacency and SPF in action (and in the right order) if you enable these two debugs:

debug ip ospf adj
debug ip ospf spf statistic

Try that next time you have two routers, it’s interesting to see.

Hope this helps!

Rene

1 Like

In ospf to form neighborship why do we need the subnet mask to be same?
Also, why would mtu mismatch be an issue. Isn’t Ip will handle fragmentation?

Hello Tejas

The subnet mask is checked by OSPF only if a broadcast network type is being used, such as Ethernet. If it is a point to point connection, then no such check will take place. This is done so that the correct communication can take place between the two neighbors. If the network being shared between two OSPF neighbors have incorrect subnet masks, then when this network is being advertised by the two routers, it will be advertised with a different subnet mask. In other words, two different destinations would be advertised for the same network. This will cause other routers receiving this information to continually switch between the two resulting in a failure to converge.

Secondly, concerning the MTU mismatch, RFC 2328 which describes OSPFv2 states the following:

If the Interface MTU field in the Database Description packet indicates an IP datagram size that is larger than the router can accept on the receiving interface without fragmentation, the Database Description packet is rejected.

So if a router tries to negotiate an adjacency on an interface where the remote router has a different MTU, the adjacency will be denied. There are two reasons for this. The first is to eliminate any problems in the data plane, where user traffic is exchanged, where a sending host sends packets too large for a receiver (or a router along the path) to receive and process. The second and arguably more important for OSPF, is that it eliminates any problems in communication between OSPF routers in the control plane. Although fragmentation is an option, this is not preferred at all for any OSPF exchanges. Essentially, it keeps things as simple as possible as far as MTU goes so that failures will not occur due to MTU issues.

I hope this has been helpful!

Laz