Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

FAQ
It is currently Sat Aug 19, 2017 2:44 am


Author Message
mandrei99
Post  Post subject: OSPF neighbors stuck in ExStart - case 1 - interface type mismatch  |  Posted: Wed Dec 10, 2014 5:42 am

Joined: Tue Aug 04, 2009 9:16 am
Posts: 245

Offline
 

OSPF neighbors stuck in ExStart - case 1 - interface type mismatch

OSPF neighbors stuck in ExStart - case 1 - interface type mismatch


So we know that on a broadcast segment, two neighborship between two OSPF routers will allways be FULL given that all conditions are met. When there are more than two neighbors, the Designated Router and Backup Designated Router form a FULL adjacency with all routers on the segment and the DROthers will remain in 2-way state with each other. This is to avoid LSA flood storms on network segment with multiple OSPF speakers.


One of possible reasons why a neighbor would see FULL state neighborship with two other OSPF speakers on the broadcast segment and remain stuck in ExStart state with all the others is the interface type mismatch.


Let's see below:
Code:
admin@vMX-TEST> show ospf neighbor logical-system R3   
Address          Interface              State     ID               Pri  Dead
10.0.10.5        ge-0/0/3.10            Full      5.5.5.5          128    37
10.0.10.4        ge-0/0/3.10            ExStart   4.4.4.4          128    36
10.0.10.2        ge-0/0/3.10            ExStart   2.2.2.2          128    33
10.0.10.1        ge-0/0/3.10            ExStart   1.1.1.1          128    39
10.0.10.6        ge-0/0/3.10            Full      6.6.6.6          128    31


What we see is that R3 has full ospf neighborship with RID 5.5.5.5 and 6.6.6.6. This is not a coincidence, these are routers with highest router ID and they are designated and backup designated routers.

RFC 2328 tells us that specific network types do not require election of designated and backup designated routers:

Quote:
https://www.ietf.org/rfc/rfc2328.txt

C.6 Point-to-MultiPoint network parameters

On Point-to-MultiPoint networks, it may be necessary to
configure the set of neighbors that are directly reachable over
the Point-to-MultiPoint network. Each neighbor is identified by
its IP address on the Point-to-MultiPoint network. Designated
Routers are not elected on Point-to-MultiPoint networks, so the
Designated Router eligibility of configured neighbors is
undefined.




Code:
admin@vMX-TEST> show ospf interface ge-0/0/3.10 extensive logical-system R3
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/3.10         PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            5
  Type: P2MP, Address: 10.0.10.3, Mask: 255.255.255.0, MTU: 1500, Cost: 1
  Adj count: 2
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Cost: 1


R3's interface is set to point-to-multipoint type. This means that, on ethernet segments, it will accept both unicast and multicast OSPF messages from all routers in the segment, but it will only send unicast. This explains why neighbourship with designated and backup designated routers is "FULL". The neighbourship with DROther routers is stuck in ExStart because the P2MP node tries to elevate the neighbourship state from 2-way to Exstart/Exchange/Loading/FUll, but DROther routers refuse to do this because they already have FULL neighborship with the DR and the BDR.

This is seen in a traffic capture taken on R3's interface:
Code:
09:35:05.079191 Out IP truncated-ip - 46 bytes missing! 10.0.10.3 > 10.0.10.6: OSPFv2, Hello, length 76
09:35:05.761154  In IP 10.0.10.1 > 224.0.0.5: OSPFv2, Hello, length 76
09:35:06.019392 Out IP truncated-ip - 14 bytes missing! 10.0.10.3 > 10.0.10.1: OSPFv2, Database Description, length 44
09:35:06.019469 Out IP truncated-ip - 14 bytes missing! 10.0.10.3 > 10.0.10.2: OSPFv2, Database Description, length 44
09:35:06.919188 Out IP truncated-ip - 46 bytes missing! 10.0.10.3 > 10.0.10.4: OSPFv2, Hello, length 76
09:35:07.210970  In IP 10.0.10.2 > 224.0.0.5: OSPFv2, Hello, length 76
09:35:07.399361 Out IP truncated-ip - 14 bytes missing! 10.0.10.3 > 10.0.10.4: OSPFv2, Database Description, length 44


R3 tries to send OSPF Database Description messages in unicast form to DRother routers, but they do not reply, so the neighborship remains stuck in ExStart.

Question #2: If R3 has FULL neighborship with designated routers, in theory, R3 routes should be seen by all other routes, but that is not correct.

Code:
admin@vMX-TEST> show interfaces lo0.3 terse
Interface               Admin Link Proto    Local                 Remote
lo0.3                   up    up   inet     3.3.3.3             --> 0/0
                                            33.33.33.33         --> 0/0

admin@vMX-TEST> show ospf interface logical-system R3                   
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/3.10         PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            5
lo0.3               DR      0.0.0.0         3.3.3.3         0.0.0.0            0
lo0.3               DR      0.0.0.0         3.3.3.3         0.0.0.0            0

admin@vMX-TEST> show ospf neighbor logical-system R3
Address          Interface              State     ID               Pri  Dead
10.0.10.5        ge-0/0/3.10            Full      5.5.5.5          128    35
10.0.10.4        ge-0/0/3.10            ExStart   4.4.4.4          128    35
10.0.10.2        ge-0/0/3.10            ExStart   2.2.2.2          128    37
10.0.10.1        ge-0/0/3.10            ExStart   1.1.1.1          128    33
10.0.10.6        ge-0/0/3.10            Full      6.6.6.6          128    35



Here is R6's view of R3's router LSA:
Code:
admin@vMX-TEST> show ospf database lsa-id 3.3.3.3 extensive logical-system R6

    OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   3.3.3.3          3.3.3.3          0x8000002b  1063  0x22 0x9a16  84
  bits 0x0, link count 5
  id 10.0.10.3, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 5.5.5.5, data 10.0.10.3, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 6.6.6.6, data 10.0.10.3, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 33.33.33.33, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 3.3.3.3, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: PointToPoint, Node ID: 6.6.6.6
      Metric: 1, Unidirectional
    Type: PointToPoint, Node ID: 5.5.5.5
      Metric: 1, Unidirectional
  Aging timer 00:42:16
  Installed 00:17:42 ago, expires in 00:42:17, sent 00:17:42 ago
  Last changed 00:17:42 ago, Change count: 10
admin@vMX-TEST> show ospf database lsa-id 6.6.6.6 extensive logical-system R6   

    OSPF database, Area 0.0.0.0
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *6.6.6.6          6.6.6.6          0x80000023  1158  0x22 0x5332  48
  bits 0x0, link count 2
  id 10.0.10.5, data 10.0.10.6, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 6.6.6.6, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 10.0.10.5
      Metric: 1, Bidirectional
  Gen timer 00:30:41
  Aging timer 00:40:41
  Installed 00:19:18 ago, expires in 00:40:42, sent 00:19:16 ago
  Last changed 20:03:36 ago, Change count: 2, Ours


R3 reports individual "PointToPoint" segments with R5 and R6 while R6 sees the segment as "Transit" and this causes R6 to ignore all IDs provided by R3 in it's type 1 LSA, and it will not install routes 3.3.3.3/32 and 33.33.33.33/32 presented by R3:
Code:
admin@vMX-TEST> show route protocol ospf logical-system R6

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[OSPF/10] 20:04:54, metric 1
                    > to 10.0.10.1 via ge-0/0/6.10
2.2.2.2/32         *[OSPF/10] 19:40:19, metric 1
                    > to 10.0.10.2 via ge-0/0/6.10
4.4.4.4/32         *[OSPF/10] 18:17:55, metric 1
                    > to 10.0.10.4 via ge-0/0/6.10
5.5.5.5/32         *[OSPF/10] 20:04:54, metric 1
                    > to 10.0.10.5 via ge-0/0/6.10
224.0.0.5/32       *[OSPF/10] 20:05:09, metric 1
                      MultiRecv





Top
Display posts from previous:  Sort by  
E-mail friendPrint view

Topics related to - "OSPF neighbors stuck in ExStart - case 1 - interface type mismatch"
 Topics   Author   Replies   Views   Last post 
There are no new unread posts for this topic. Understanding the OSPF External NSSA LSA Metric Type 1 with JunOS examples

mandrei99

0

1464

Sun Mar 15, 2015 1:51 pm

mandrei99 View the latest post

There are no new unread posts for this topic. Junos VPLS Virtual circuit stuck in "VC-Dn" state

mandrei99

0

1887

Tue Jul 09, 2013 9:48 am

mandrei99 View the latest post

There are no new unread posts for this topic. Junos "show bgp summary" shows different outputs for neighbors

admin

0

715

Tue Jun 14, 2016 2:56 pm

admin View the latest post

There are no new unread posts for this topic. OSPF areas - how to achieve optimal routing - Cisco way

mandrei99

1

834

Tue Nov 25, 2014 8:46 pm

Exsosus View the latest post

There are no new unread posts for this topic. Attachment(s) OSPF: Dangers of non-standard area design - Juniper way

mandrei99

0

879

Thu Nov 13, 2014 12:29 pm

mandrei99 View the latest post

There are no new unread posts for this topic. Attachment(s) OSPF areas: Analysing an apprently redundant design - Cisco way

mandrei99

0

720

Tue Nov 18, 2014 11:14 am

mandrei99 View the latest post

There are no new unread posts for this topic. Injecting a default route in an OSPF NSSA area from a Juniper device

mandrei99

0

2982

Sun Mar 15, 2015 5:24 pm

mandrei99 View the latest post

There are no new unread posts for this topic. OSPF Multi area scenario with isolated areas cisco & Juniper - part 1.

mandrei99

0

1203

Thu Nov 13, 2014 9:51 am

mandrei99 View the latest post

There are no new unread posts for this topic. Junos: GRE interface in VR with local tunnel endpoint in main routing instance

mandrei99

0

2645

Thu May 23, 2013 9:33 am

mandrei99 View the latest post

 

Who is online
Users browsing this forum: No registered users and 0 guests
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum
Jump to:  
News News Site map Site map SitemapIndex SitemapIndex RSS Feed RSS Feed Channel list Channel list


Delete all board cookies | The team | All times are UTC - 5 hours [ DST ]



phpBB SEO