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

FAQ
It is currently Sun Oct 20, 2019 1:12 pm


Username:
Subject:
Message body:
Enter your message here, it may contain no more than 60000 characters. 

Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek:
Font size:
 
Font colour
Options:
BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON
Disable BBCode
Disable smilies
Do not automatically parse URLs
Confirmation code
Confirmation code:
In an effort to prevent automatic submissions, we require that you enter both of the words displayed into the text field underneath.
     

Topic review - OSPF neighbors stuck in ExStart - case 1 - interface type mismatch
Author Message
Post subject: OSPF neighbors stuck in ExStart - case 1 - interface type mismatch  |  Post Posted: Wed Dec 10, 2014 5:42 am
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
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