OSPF Transit Area Split Horizon violation

[Sam-CCNP]

Hi,

I'm noticing some odd behaviour with regard to a transit area and it not conforming to RFC2328 on the network below: 

I have a virtual link between R1 and R2, which works, but R1 seems to be advertising a Summary LSA into Area 1 for the network between R3 and R4 (155.1.34.0) which it knows via its Virtual link to Area 0, even though 'RFC 2328 12.4.3. Summary-LSAs' states that for Summary LSA generation:

            o   Else, if the next hops associated with this set of paths
                belong to Area A itself, do not generate a summary-LSA
                for the route.[18] This is the logical equivalent of a
                Distance Vector protocol's split horizon logic.

So, basically, networks learnt via the virtual link shouldn't be advertised by the ABR at the end of the virtual link into the transit area as their next hops will be in that area itself and violate the above rule. Which, in the my topology, should mean networks in Area 0 area are advertised only by R2 and R3 into Area 1 and not R1 because the next hop is R7, which is in the transit area. But as you can see below, it is being advertised:

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
5.5.5.5 0.0.0.1 183 0x80000001 0x00B075
155.1.15.0 0.0.0.1 183 0x80000001 0x00F49A
155.1.24.0 0.0.0.2 234 0x80000001 0x008BF9
155.1.24.0 0.0.0.3 72 0x80000001 0x008FF3
155.1.34.0 0.0.0.1 58 0x80000001 0x003743 <--- Advertised by ABR R1
155.1.34.0 0.0.0.2 179 0x80000001 0x002753
155.1.34.0 0.0.0.3 72 0x80000001 0x001763

However, when I shut down the link between R3 and R7 (which is in Area 1) so that R3 is no longer an ABR, R1 stops advertising the Summary LSA into Area 1, which results in the output I would expect as per RFC 2328:

Summary Net Link States (Area 1)

Link ID ADV Router Age Seq# Checksum
5.5.5.5 0.0.0.1 117 0x80000001 0x00B075
155.1.15.0 0.0.0.1 117 0x80000001 0x00F49A
155.1.24.0 0.0.0.2 168 0x80000001 0x008BF9
155.1.34.0 0.0.0.2 113 0x80000001 0x002753

This only seems to happen to 155.1.34.0 but not to 155.1.24.0, which is also in Area 0.

I'm confused by this, can anyone explain?

Thanks for any help.

Sam

[M02@rt37]

Hello @Sam-CCNP

The section you mentioned from RFC 2328 outlines the logic for generating Summary-LSAs. It states that if the next hops associated with a set of paths belong to Area A itself (in your case, Area 1), then a summary-LSA for that route should not be generated. This is to prevent routing loops.

Virtual link is used to connect two areas through a transit area. When R3 is an ABR between Area 0 and the virtual link to Area 2, it might influence the SPF tree and cause certain routes to be included in the summary-LSAs.

When you shut down the link between R3 and R7, R3 is no longer an ABR. This topology change might trigger a recalculation of the SPF tree, and R1 refrains from generating the summary-LSA for 155.1.34.0 into Area 1. You mentioned that 155.1.24.0 does not exhibit the same behavior. This might be due to the specific network topology and SPF tree calculations. Each router calculates the SPF tree based on its local view of the LSDB and its understanding of the network topology.

If you want to prevent the generation of the unwanted summary-LSA for 155.1.34.0, you should adjust the OSPF network design, ensuring that ABRs are appropriately placed, or using OSPF filtering mechanisms to control LSAs.

[Sam-CCNP]

Hi M02@rt37,

Thanks for such a prompt reply.

Your first paragraph makes sense and is how I understand it.

But for your second paragraph, R3 is not a router used by the virtual link between Area 0 and Area 2. It is separate but its existence as an ABR does seem to influence R1 and its Summary LSA generation, which I do not understand. If I look at the routing table on R1 it is correct in that the 155.1.34.0 is an intra-area route with a metric of 4 and a next hop of R7:

R1#sh ip route 155.1.34.0
Routing entry for 155.1.34.0/24
Known via "ospf 1", distance 110, metric 4, type intra area
Last update from 155.1.17.7 on GigabitEthernet0/0, 00:19:18 ago
Routing Descriptor Blocks:
* 155.1.17.7, from 0.0.0.4, 00:19:18 ago, via GigabitEthernet0/0
Route metric is 4, traffic share count is 1

So that part, makes sense, but why is it advertising it as a Summary LSA into Area 1 when the next hop of 155.1.17.7 is in Area 1. It is violating the split horizon rule in your first paragraph.

Regards,

Sam

[M02@rt37]

Very interesting case @Sam-CCNP 

If R3 is an ABR between Area 0 and Area 1, its role may influence LSA flooding. ABRs are responsible for translating Type 1 and Type 2 LSAs between areas. It's possible that R3, as an ABR, is involved in the propagation of the summary LSA.

The presence of a virtual link (between R1 and R2) and the involvement of R3 might introduce considerations that go beyond a straightforward interpretation of split horizon. The virtual link essentially extends Area 0 to R2, and the interplay between virtual links and ABR roles can introduce complexities.

[Sam-CCNP]

Hi M02@rt37 ,

Yes, I don't get it. My setup is not especially complicated and yet I cant explain why R1 is generating a Type-3 LSA when it shouldn't.

Maybe there is an explanation somewhere in an RFC.

Regards,

Sam

[MHM Cisco World]

the R2 is ABR between Area0 and Area 1
R3 is ABR between Area1 and Area2 
I config virtual link
you can see in R1 the advertise router is R3 not R2 so the rule is correct

[Sam-CCNP]

Hi @MHM Cisco World ,

Your topology is different to mine.

I have 2x ABR in Area 0. To replicate correctly, you need another router - e.g. R6 - with one link to R4 and another to R1.

Then observe that the link between R4 and the new R6 router is being injected as a Type 3 into the transit area by R3.

Thanks.

Sam

[MHM Cisco World]

the devil in detail friend 
I make another link between R4 and R1 make two ABR router in Area 0 
you can see the 11.0.0.0  is now learn from both 3.3.3.3 (virtual) and from 10.0.0.4 R4 but the R1 not consider prefix from R4 even if it in db, the missing of  routing bit set is meaning that R1 not consider LSA3 from 10.0.0.4 in SPF.
MHM

[Sam-CCNP]

Hi, @MHM Cisco World 

The topology is still not replicated correctly.

Sam

[MHM Cisco World]

In your topolgy check ths routing bit

Share 

Ip ospf database summary 

MHM

[Sam-CCNP]

Hi @MHM Cisco World ,

We would be comparing and troubleshooting different topologies.

Setup as per mine and observe all the Summary LSA generated in the transit area that represent the link between the ABR that isn't a virtual link endpoint the the internal router that is in Area 0. See my diagram for a guide.

And note, its an Area 0 network I am observing not other areas.

Thanks,

Sam

[MHM Cisco World]

as I mention the R5 indeed receive the Lsa3 summary route but it without routing bit so it ignore it

OSPF Router with ID (13.0.0.5) (Process ID 100)

Summary Net Link States (Area 0)

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 2 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 6.6.6.6 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0x6AB4
Length: 28
Network Mask: /32
MTID: 0 Metric: 2

LS age: 7 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.0.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xFC30
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 578
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.0.0.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xB66F
Length: 28
Network Mask: /24
MTID: 0 Metric: 1

LS age: 144
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 10.0.0.0 (summary Network Number)
Advertising Router: 13.0.0.4
LS Seq Number: 80000001
Checksum: 0x8D92
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

LS age: 7 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 12.0.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xE248
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

LS age: 495
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 12.0.0.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0xA67C
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 153
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 12.0.0.0 (summary Network Number)
Advertising Router: 13.0.0.4
LS Seq Number: 80000001
Checksum: 0x69B5
Length: 28
Network Mask: /24
MTID: 0 Metric: 1

LS age: 7 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 14.0.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xBE6B
Length: 28
Network Mask: /24
MTID: 0 Metric: 1

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 495
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 14.0.0.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Checksum: 0x8C94
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 144
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 14.0.0.0 (summary Network Number)
Advertising Router: 13.0.0.4
LS Seq Number: 80000001
Checksum: 0x59C2
Length: 28
Network Mask: /24
MTID: 0 Metric: 2

Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 2 (DoNotAge)
Options: (No TOS-capability, DC, Upward)
LS Type: Summary Links(Network)
Link State ID: 15.0.0.0 (summary Network Number)
Advertising Router: 1.1.1.1
LS Seq Number: 80000001
Checksum: 0xB177
Length: 28
Network Mask: /24
MTID: 0 Metric: 1

[paul driver]

Hello

---

@Sam-CCNP wrote:

So, basically, networks learnt via the virtual link shouldn't be advertised by the ABR at the end of the virtual link into the transit area as their next hops will be in that area itself and violate the above rule. 

---

My understanding here is you can summarise from non backbone area into a transit area, but not from a transit area into backbone area when ospf transit capability enabled which should allow traffic advertised over the VL to use the next-hop of the transit path rtr instead of the VL next-hop.

router ospf x
capability transit ( should be on by default)