Trouble Shooting OSPF Adjacency Problems (3)

In today’s post we are going to resume our discussion about the reason that could lead to OSPF adjacency problems, and we’ll look into the below reasons:

  • Mismatched hello and dead interval values.
  • Mismatched MTU settings.

We’ll work on the same topology as below.

capture2

Mismatched Hello and Dead interval values

As we already know, OSPF adjacencies must have matching hello and dead interval values, as the routers do not negotiate the values and the adjacency is declared down.

We can examine this issue with the use of traceoptions:

We can notice the dead interval configured on the peer router is 21 sec, and the hello interval is set to 7 seconds and Router1 ignored the packet due to this mismatch.

ali@Router1# run show log OSPFLOG
Jan 2 00:04:47.362239 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan 2 00:04:47.362261 Version 2, length 48, ID 163.121.1.2, area 0.0.0.0
Jan 2 00:04:47.362266 checksum 0x0, authtype 1
Jan 2 00:04:47.362273 mask 255.255.255.252, hello_ivl 7, opts 0x12, prio 128
Jan 2 00:04:47.362279 dead_ivl 21, DR 0.0.0.0, BDR 0.0.0.0
Jan 2 00:04:47.362285 OSPF packet ignored: hello interval mismatch 7 from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.0

And by examining the O/P of the show ospf interface detail we can found that Router1 is using the default timers of 10 sec as Hello interval and 40 sec as Dead interval

ali@Router1# run 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: Password
Protection type: None
Topology default (ID 0) -> Cost: 1

By looking into the O/P of the monitor traffic interface detail, we can see the Hello and Dead intervals of both IN packets and OUT packets and we can make sure to set their values the same on both routers.

00:22:44.059611 In IP (tos 0xc0, ttl 1, id 16613, 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 7s, Dead Timer 21s, Mask 255.255.255.252, Priority 128
LLS: checksum: 0xfff6, length: 3
Extended Options (1), length: 4
Options: 0x00000001 [LSDB resync]00:22:50.412662 Out IP (tos 0xc0, ttl 1, id 25235, offset 0, flags [none], proto: OSPF (89), length: 76) 10.100.12.1 > 224.0.0.5: OSPFv2, Hello, length 56 [len 44]
Router-ID 163.121.1.1, 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]

Mismatched MTU Settings

OSPF is very sensitive to mismatched MTU and if there is any variance to the family INET MTU value, the adjacencies will not establish.

Noting that if the logical MTU values are not set for any of the protocol families, then the family INET MTU value will be 14 bytes below the configured physical MTU value, and if you are using VLAN tagging/inner VLAN tagging, the MTU value will be 18/22 bytes below configured physical MTU

If there is a difference in the MTU size the OSPF neighbors typically get stuck at the Exstart state on one Router and Exchange state on the other.

ali@Router2# run show ospf neighbor
Address           Interface                    State            ID               Pri  Dead
10.100.12.1      ge-0/0/1.112           ExStart   163.121.1.1      128    37
ali@Router1# run show ospf neighbor
Address              Interface                 State                ID               Pri  Dead
10.100.12.2      ge-0/0/1.112           Exchange  163.121.1.2      128    36

And by having a look at the traceoptions log we can find that the mismatch is the issue.

NB: We have flagged the error detail, hello detail, and packets

What we can notice from below O/P is the database description packets sent and received with their respective MTU sizes, so OSPF restated the signaling due to this MTU mismatch and will stuck at the Exstart/Exchange state.

ali@Router2# run show log OSPFLOG
Jan  2 00:56:22.289619 OSPF rcvd DbD 10.100.12.1 -> 224.0.0.5 (ge-0/0/1.112 IFL 78 area 0.0.0.0)
Jan  2 00:56:22.289626   Version 2, length 172, ID 163.121.1.1, area 0.0.0.0
Jan  2 00:56:22.289632   checksum 0x0, authtype 1
Jan  2 00:56:22.289638   options 0x52, i 0, m 0, ms 0, r 0, seq 0xa377cd12, mtu 1500
Jan  2 00:56:22.289713 OSPF restart signaling: Received DBD with LLS data from nbr ip=10.100.12.1 id=163.121.1.1.
Jan  2 00:56:22.289719 OSPF packet ignored: MTU mismatch from 10.100.12.1 on intf ge-0/0/1.112 area 0.0.0.0
Jan  2 00:56:23.586559 OSPF rcvd LSUpdate 10.100.12.1 -> 224.0.0.5 (ge-0/0/1.112 IFL 78 area 0.0.0.0)
Jan  2 00:56:23.586568   Version 2, length 112, ID 163.121.1.1, area 0.0.0.0
Jan  2 00:56:23.586574   checksum 0x0, authtype 1
Jan  2 00:56:23.586580   adv count 3
Jan  2 00:56:25.459808 OSPF hello from 163.121.1.1 (IFL 78, area 0.0.0.0) absorbed
Jan  2 00:56:27.091553 OSPF resend last DBD to 10.100.12.1
Jan  2 00:56:27.091607 OSPF sent DbD 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 78 area 0.0.0.0)
Jan  2 00:56:27.091613   Version 2, length 32, ID 163.121.1.2, area 0.0.0.0
Jan  2 00:56:27.091619   options 0x52, i 1, m 1, ms 1, r 0, seq 0xa377cd12, mtu 1482
Jan  2 00:56:27.091656 OSPF restart signaling: Add LLS data for DbD packet on interface ge-0/0/1.112.

Lastly we can use the monitor traffic interface detail, look for the DBD packets and I think it would be the fastest way in my opinion to get this issue resolved.

01:05:42.805146 Out IP (tos 0xc0, ttl   1, id 30892, offset 0, flags [none], proto: OSPF (89), length: 204) 10.100.12.1 > 224.0.0.5: OSPFv2, Database Description, length 184 [len 172]
Router-ID 163.121.1.1, Backbone Area, Authentication Type: simple (1)
Simple text password: Jun!p3r
Options [External, LLS, Opaque], DD Flags [none], MTU: 1500, Sequence: 0xa377cd12
Advertising Router 163.121.1.1, seq 0x80000014, age 21s, length 28
Router LSA (1), LSA-ID: 163.121.1.1
Options: [External, Demand Circuit]
Advertising Router 163.121.1.2, seq 0x80000019, age 87s, length 76
Router LSA (1), LSA-ID: 163.121.1.2
Options: [External, Demand Circuit]01:08:30.249575  In IP (tos 0xc0, ttl   1, id 20471, offset 0, flags [none], proto: OSPF (89), length: 64) 10.100.12.2 > 224.0.0.5: OSPFv2, Database Description, length 44 [len 32]
Router-ID 163.121.1.2, Backbone Area, Authentication Type: simple (1)
Simple text password: Jun!p3r
Options [External, LLS, Opaque], DD Flags [Init, More, Master], MTU: 1482, Sequence: 0xa377cd12
LLS: checksum: 0xfff6, length: 3
Extended Options (1), length: 4
Options: 0x00000001 [LSDB resync]

I wish this was informative and thank you for viewing.

Advertisements

Posted on January 2, 2017, 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: