Trouble Shooting OSPF Adjacency Problems (2)

In the last post we’ve discussed some of the reasons that could lead to OSPF adjacency problems, in today’s post we are going to look at the below reasons and we shall continue the rest of the reasons in a subsequent post.

  • Mismatched interface types.
  • OSPF priority is set to 0 on both sides.
  • Mismatched area IDs or mismatched area types.

We’ll continue to work on the same topology as below.

capture2

Mismatched Interface Types

Mismatched interface types can cause OSPF adjacency problems, but some combinations can work and OSPF adjacency will reach the Full state.

For example, one side of the adjacency can be configured in point-to-point mode, and the other side of the adjacency can be configured in point-to-multipoint mode.

ali@Router1# show protocols ospf
area 0.0.0.0 {
interface ge-0/0/1.112 {
interface-type p2p;
authentication {
simple-password “$9$uXoJBRcKMXbs4B1X-ws4oz36”; ## SECRET-DATA
}
}
interface lo0.0;
ali@Router2# show protocols ospf
area 0.0.0.0 {
interface lo0.0;
interface ge-0/0/1.112 {
interface-type p2mp;
authentication {
simple-password “$9$ZyDH.QF/0BEDj/tOBEhVwY”; ## SECRET-DATA
}
}

And we can see that OSPF is up and running as follow.

ali@Router2# run show ospf neighbor detail
Address             Interface              State            ID               Pri  Dead
10.100.12.1      ge-0/0/1.112           Full      163.121.1.1      128    36
Area 0.0.0.0, opt 0x52, DR 0.0.0.0, BDR 0.0.0.0
Up 00:02:40, adjacent 00:02:35

However, if an OSPF adjacency has one side set to the default broadcast mode, and the other side set to point-to-point mode or point-to-multipoint mode, the adjacency will fail.

This can be concluded from the show ospf interfaces, the configuration mismatch that can be found in the traceoptions below and the O/P of the monitor traffic interface detail command.

Also we can notice that the adjacency on one router is stuck in the Init state in the O/P of show ospf neighbor command

On Router1;

ali@Router1# run 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            0ali@Router1> show ospf neighbor
ali@Router1>
ali@Router1> show log OSPFLOG
Jan 1 20:50:23 Router1 clear-log[1166]: logfile cleared
Jan  1 20:50:24.565357 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan  1 20:50:24.565388   Version 2, length 48, ID 163.121.1.2, area 0.0.0.0
Jan  1 20:50:24.565394   checksum 0x0, authtype 1
Jan  1 20:50:24.565400   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Jan  1 20:50:24.565406   dead_ivl 40, DR 10.100.12.2, BDR 0.0.0.0
Jan  1 20:50:24.565412 OSPF packet ignored: configuration mismatch from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.0

On Router2;

ali@Router2> show ospf interface
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            1ali@Router2> show ospf neighbor
Address          Interface                 State           ID               Pri  Dead
10.100.12.1      ge-0/0/1.112           Init      163.121.1.1      128    36
ali@Router2> monitor traffic detail interface ge-0/0/1.112
20:54:52.997098 Out IP (tos 0xc0, ttl   1, id 4355, offset 0, flags [none], proto: OSPF (89), length: 80) 10.100.12.2 > 224.0.0.5: OSPFv2, Hello, length 60 [len 48]
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
          Designated Router 10.100.12.2
Neighbor List:
163.121.1.1
LLS: checksum: 0xfff6, length: 3
Extended Options (1), length: 4
Options: 0x00000001 [LSDB resync]
20:54:58.775551  In IP (tos 0xc0, ttl   1, id 1718, 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]

OSPF priority is set to 0 on both sides

If the OSPF priority is set to 0 on broadcast interfaces, the adjacency will stuck in the 2-Way state.

This occurs because both routers believe that other routers are on the network segment that can act as the designated router (DR) and backup designated router (BDR).

We can Tshoot the above issue through show ospf interfaces detail and the use of traceoptions and monitor traffic detail interface command.

ali@Router2# run show ospf neighbor
Address            Interface                 State           ID               Pri  Dead
10.100.12.1      ge-0/0/1.112           2Way      163.121.1.1        0    32
ali@Router2# run show ospf interface detail
Interface                State           Area            DR ID           BDR ID          Nbrs
ge-0/0/1.112        DRother    0.0.0.0         0.0.0.0         0.0.0.0            1
Type: LAN, Address: 10.100.12.2, Mask: 255.255.255.252, MTU: 1500, Cost: 1
  Priority: 0
Adj count: 0
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: Password
Protection type: None
Topology default (ID 0) -> Cost: 1
Jan  1 21:34:01.861330 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan  1 21:34:01.861334   Version 2, length 48, ID 163.121.1.2, area 0.0.0.0
Jan  1 21:34:01.861339   checksum 0x0, authtype 1
Jan  1 21:34:01.861346   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 0
Jan  1 21:34:01.861351   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Jan  1 21:34:01.861397 RPD_OSPF_NBRUP: OSPF neighbor 10.100.12.2 (realm ospf-v2 ge-0/0/1.112 area 0.0.0.0) state changed from Init to 2Way due to 2WayRcvd (event reason: neighbor detected this router)Jan  1 21:34:01.861562 OSPF sent Hello 10.100.12.1 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan  1 21:34:01.861568   Version 2, length 48, ID 163.121.1.1, area 0.0.0.0
Jan  1 21:34:01.861574   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 0
Jan  1 21:34:01.861580   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

Mismatched area IDs or mismatched area types.

Mismatched area IDs will cause an OSPF adjacency to fail, in order to check this issue we can issue the show ospf interface command

ali@Router2# run show ospf interface ge-0/0/1.112
Interface                 State     Area            DR ID           BDR ID          Nbrs
ge-0/0/1.112        PtToPt    0.0.0.1         0.0.0.0         0.0.0.0            0
ali@Router1# run show ospf interface ge-0/0/1.112
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

And of-course with the use of the traceoptions

Jan  1 21:54:04.694379 OSPF sent Hello 10.100.12.1 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan  1 21:54:04.694384   Version 2, length 44, ID 163.121.1.1, area 0.0.0.0
Jan  1 21:54:04.694391   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Jan  1 21:54:04.694396   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Jan  1 21:54:11.599084 OSPF packet ignored: area mismatch (0.0.0.1) from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.0
Jan  1 21:54:11.599152 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.0)
Jan  1 21:54:11.599158   Version 2, length 44, ID 163.121.1.2, area 0.0.0.1
Jan  1 21:54:11.599164   checksum 0x46a6, authtype 1
Jan  1 21:54:11.599170   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Jan  1 21:54:11.599176   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

Mismatched area types (Stub Flag) can also affects the OSPF adjacency as the option field in the Hello packet signals the type of the area the interface belongs to, and if the two router have different area types eg. stub vs normal, the neighbors won’t show up.

N.B: We’ve adjusted the area id to be 1 instead of 0 in order to set the stub flag, putting Router2 in area 1, and Router1 in area 1 nssa.

We can see the differences in the O/P of the show ospf interface details command.

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        PtToPt     0.0.0.1         0.0.0.0         0.0.0.0            0
Type: P2P, Address: 10.100.12.2, 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
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.1         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, Stub NSSA
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 1

And the Traceoptions says it all

ali@Router1# run show log OSPFLOG | last 10
Jan  1 22:22:55.285989 OSPF periodic xmit from 10.100.12.1 to 224.0.0.5 (IFL 71 area 0.0.0.1)
Jan  1 22:22:57.548326 OSPF rcvd Hello 10.100.12.2 -> 224.0.0.5 (ge-0/0/1.112 IFL 71 area 0.0.0.1)
Jan  1 22:22:57.548440   Version 2, length 44, ID 163.121.1.2, area 0.0.0.1
Jan  1 22:22:57.548446   checksum 0x0, authtype 0
Jan  1 22:22:57.548452   mask 255.255.255.252, hello_ivl 10, opts 0x12, prio 128
Jan  1 22:22:57.548458   dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Jan  1 22:22:57.548464 OSPF packet ignored: area stubness mismatch from 10.100.12.2 on intf ge-0/0/1.112 area 0.0.0.1

The monitor traffic detail command shows the difference. In the Options field one side is signalling External, LLS (Link Local Signaling) ==> normal area, whereas the other side signals NSSA, LLS ==> NSSA area.

A Stub area will signal LLS only as illustrated below

ali@Router2# run monitor traffic detail interface ge-0/0/1.112
22:24:56.832460  In IP (tos 0xc0, ttl   1, id 12439, 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, Area 0.0.0.1, Authentication Type: none (0)
        Options [NSSA, 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]
22:24:57.998158 Out IP (tos 0xc0, ttl   1, id 10319, 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, Area 0.0.0.1, Authentication Type: none (0)
        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]

In the next post ISA we’ll continue our journey together to check the other reasons for OSPF adjacency problems hoping that we could finish this topic in the next blog post.

I hope this was informative and thanks for viewing

Advertisements

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