Topic review - OSPF neighbors stuck in ExStart - case 1 - interface type mismatch
Author
Message
mandrei99
Post subject: OSPF neighbors stuck in ExStart - case 1 - interface type mismatch | 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:
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
[b]OSPF neighbors stuck in ExStart - case 1 - interface type mismatch[/b]
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 [/code]
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.
[/quote]
[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 [/code]
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 [/code]
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[/code]
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 [/code]
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[/code]