Trouble Shooting OSPF Adjacency Problems (1)

In this topic we are going to discuss some of the reasons that affect the OSPF adjacency between two peers and how to trouble shoot these issues in Junos.

First we will list the possible reasons for OSPF adjacency issues and we’ll discuss it in detail in subsequent paragraphs.

Possible Causes of OSPF Adjacency Issues:

  • Duplicate RIDs.
  • Mismatched subnet masks, or incorrect IP addressing.
  • Authentication mismatches.
  • Mismatched interface types.
  • OSPF priority is set to 0 on both sides.
  • Mismatched area IDs or mismatched area types.
  • Mismatched hello and dead interval values.
  • Mismatched MTU settings.

How to Troubleshoot Adjacency Problems ?

There are some basic troubleshooting commands that can be issued in order to get some clue over the problem you are facing, these commands are:

  • show ospf neighbors
  • show ospf interface
  • show ospf interface detail
  • show configuration protocols ospf

In addition to A/M commands, if there are no obvious reasons for an adjacency issue, you can take a closer look at the internal workings of the IGP. Using the monitor traffic interface interface-name detail command.

Also it would be handy to use traceoptions as it would be a great method in determining exactly what is wrong with an adjacency. Consider using the hello detail and error detail flags to troubleshoot adjacency issues.

We’ll try to make it as simple as we can, in the below topology we have two directly connected routers:

  • R1: lo0.0 163.121.1.1
  • R2: lo0.0 163.121.1.2
  • ge-0/0/1.112 on both routers have the address subnet 10.100.12/30
  • OSPF area 0 should be configured on both routers with interface ge-0/0/1.112

capture2

Mismatched RIDs Issues.

It is very important in a link-state network that no two routers share the same RID value for the below reasons:

  • RID is one method to verify if an LSA is already present in the database so If two routers share the same RID value, the LSDB might not be consistent on all routers.
  • Dijkstra calculation uses the RID, it is possible that an individual router might not generate a loop-free shortest path topology.

On Router1, we issued below commands;

ali@Router1> show ospf interface
Interface               State       Area            DR ID             BDR ID          Nbrs
ge-0/0/1.112        PtToPt  0.0.0.0         0.0.0.0           0.0.0.0            0
lo0.0                        DR       0.0.0.0         163.121.1.1      0.0.0.0            0ali@Router1> show ospf neighbor
ali@Router1>ali@Router1> show interfaces lo0.0
Logical interface lo0.0 (Index 66) (SNMP ifIndex 16)
Flags: SNMP-Traps Encapsulation: Unspecified
Input packets : 12
Output packets: 12
Security: Zone: Null
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Default Is-Primary
Local: 163.121.1.1

ali@Router1> show configuration routing-options
router-id 163.121.1.1;

On Router2;

ali@Router2> show ospf interface
Interface                State         Area              DR ID               BDR ID          Nbrs
ge-0/0/1.112        PtToPt       0.0.0.0            0.0.0.0          0.0.0.0            0
lo0.0                         DR           0.0.0.0         163.121.1.1        0.0.0.0            0ali@Router2> show ospf neighbors
ali@Router2>ali@Router2> show interfaces lo0.0
Logical interface lo0.0 (Index 66) (SNMP ifIndex 16)
Flags: SNMP-Traps Encapsulation: Unspecified
Input packets : 0
Output packets: 0
Security: Zone: Null
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Default Is-Primary
Local: 163.121.1.2

ali@Router2> show configuration routing-options
router-id 163.121.1.1;

We have enabled traceoptions on Router1 and flagged the hello, and error flags, and got the below;

Apr 29 20:16:16.391667 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Apr 29 20:16:16.391678   Version 2, length 44, ID 163.121.1.1, area 0.0.0.0
Apr 29 20:16:16.391684   checksum 0x0, authtype 0
Apr 29 20:16:16.391690   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Apr 29 20:16:16.391696   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Apr 29 20:16:16.391702 OSPF packet ignored: our router ID received from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.0

And we can find below O/P from Router2 after fixing the adjacncy.

ali@Router2> show ospf interface
Interface             State      Area                DR ID           BDR ID          Nbrs
ge-0/0/1.112     PtToPt    0.0.0.0           0.0.0.0         0.0.0.0            1
lo0.0                     DR         0.0.0.0         163.121.1.2     0.0.0.0            0
ali@Router2> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.100.12.1      ge-0/0/1.112           Full      163.121.1.1      128    35
ali@Router2>

Mismatched subnet masks:

Mismatched subnet masks, or incorrect IP addressing on an interface will cause the OSPF adjacency to fail. In our case we misconfigured the IP address on Router1 to be /24 instead of /30, we were abe to ping the other end successfully but the adjacency didn’t form and we can find the reason in the below traceoptions log

ali@Router1> ping 10.100.12.2 rapid
PING 10.100.12.2 (10.100.12.2): 56 data bytes
!!!!!
— 10.100.12.2 ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.396/0.840/2.211/0.687 msali@Router1> show log OSPFLOG
Apr 29 20:30:03.878646 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Apr 29 20:30:03.878668   Version 2, length 44, ID 163.121.1.2, area 0.0.0.0
Apr 29 20:30:03.878674   checksum 0x0, authtype 0
Apr 29 20:30:03.878680   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Apr 29 20:30:03.878686   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Apr 29 20:30:03.878692 OSPF packet ignored: netmask 255.255.255.252 mismatch from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.0

Authentication Mismatches

Authentication mismatches will cause an OSPF adjacency to fail. if the authentication method being used is plain text then you can acquire the password by using the monitor traffic interface interface-name detail command.

If any form of encryption is required in the authentication method, then it is impossible to decipher the authentication key. You must change the authentication key on both routers to establish the adjacency.

As we can see below we’ve set the authentication key to a simple password Jun!p3r on Router2 and by running below command we can see the password easily.

monitor traffic interface ge-0/0/1.112 detail
Address resolution is ON. Use to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on ge-0/0/1.112, capture size 1514 bytesReverse lookup for 224.0.0.2 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use to avoid reverse lookups on IP addresses.20:49:56.476501  In IP (tos 0xc0, ttl   1, id 21466, offset 0, flags [none], proto: OSPF (89), length: 76) 10.100.12.2 > 224.0.0.5: OSPFv2, Hello, length 56 [len 44]
Router-ID 163.121.1.2, Backbone Area, Authentication Type: simple (1)
Simple text password: Jun!p3r
Options [External, LLS]
Hello Timer 10s, Dead Timer 40s, Mask 255.255.255.252, Priority 128
LLS: checksum: 0xfff6, length: 3
Extended Options (1), length: 4
Options: 0x00000001 [LSDB resync]

And we can also found the authentication type mismatch in the traceoptions log (Simple/no authent.) as per below O/P

Apr 29 20:49:38.784663 OSPF sent Hello 10.100.12.1 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Apr 29 20:49:38.784669   Version 2, length 44, ID 163.121.1.1, area 0.0.0.0
Apr 29 20:49:38.784675   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Apr 29 20:49:38.784681   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Apr 29 20:49:39.598405 OSPF packet ignored: authentication type mismatch (1) from 10.100.12.2

Also we can find the authentication flag in the show ospf interface detail O/P as follow on both routers.

ali@Router1> show ospf interface ge-0/0/1.112 detail
Interface               State           Area            DR ID           BDR ID          Nbrs
ge-0/0/1.112        PtToPt       0.0.0.0         0.0.0.0         0.0.0.0            0
Type: P2P, Address: 10.100.12.1, Mask: 255.255.255.252, MTU: 1500, Cost: 1
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 1

On Router2:

ali@Router2# run show ospf interface ge-0/0/1.112 detail
Interface            State     Area                DR ID           BDR ID          Nbrs
ge-0/0/1.112        DR      0.0.0.0         163.121.1.2     0.0.0.0            0
Type: LAN, Address: 10.100.12.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1
DR addr: 10.100.12.2, Priority: 128
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: Password
Protection type: None
Topology default (ID 0) -> Cost: 1

We shall  continue the rest of the causes of OSPF adjacency problems in another blog, I hope this was informative and thank you for viewing.

Advertisements

Posted on December 31, 2016, in Juniper and tagged , . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: