No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Network type mismatch causes no OSPF routes to be installed in the routing table

Publication Date:  2012-07-27 Views:  72 Downloads:  0
Issue Description
Even though the ospf adjacency state is full (which means database description (DBD) and link-state updates (LSU) are exchanged) no ospf routes are installed in the routing tables.

Please refer to the topology below:


Alarm Information
Null.
Handling Process
** Note that we only had access to our router (huawei), and that we couldn't run the debug command because it's a production environement **

1. We first noticed that the other router elected it self as DR and choosed our router as BDR, thanks to the "display ospf peer" command, as you know there is no DR/BDR election in a P2P link:

[huawei]disp ospf peer

OSPF process 100 with router id 1.1.1.1
neighbors

area 0.0.0.0 interface 10.10.10.1(ethernet0/0/0)'s neighbors
router id: 2.2.2.2 address: 10.10.10.2
state: full mode:nbr is master priority: 1
DR: 10.10.10.2 BDR: 10.10.10.1 mtu: 0
dead timer due in 38 sec
retrans timer interval: 4
neighbor is up for 00:01:38
authentication sequence: [ 0 ]


2. We then confirmed the issue by checking the LSDB content (comparing LSAs that we originate and those that we receive from our neighbour):

[huawei]disp ospf lsdb originate-router 2.2.2.2

OSPF process 100 with router id 1.1.1.1
link state database

area: 0.0.0.0
type linkstate id advrouter age len sequence metric
router 2.2.2.2 2.2.2.2 168 48 80000010 0
network 10.10.10.2 2.2.2.2 168 32 80000001 0


[huawei]disp ospf lsdb self-originate

ospf process 100 with router id 1.1.1.1
link state database

area: 0.0.0.0
type linkstate id advrouter age len sequence metric
router 1.1.1.1 1.1.1.1 185 60 80000011 0



3. We then asked the engineers from the other vendor to recheck their configuration and to set the interface network type on their side to p2p, which immediately fixed the issue.

Root Cause
1. To establish a full adjacency state only the following parameters are checked:
- Area ID
- Hello interval
- Dead interval
- Authentication type and password
- Stub area flag

2. In our case network type was set to peer-to-peer on one side and to broadcast on the other side, which didn't prevent the full state adjacency.

3. A discrepancy is created in the ospf database because the exchanged LSAs describing the interconnection doesn't match, indicating direct adjacency from the point-to-point side and adjacency to a transit network from the broadcast side, in this case no routes are installed on the routing table to avoid inconsistency.

4. The interfaces on both side must be set to the same network type, in this case peer-to-peer is adviced.

Suggestions
When the OSPF process finds a dicrepancy in the database no routes are installed in the routing table, if you do face this kind of issue, check first the configuration on both sides if you can, looking for addressing or netwotk type mismatchs.

END