type-3 LSA injection with ospf virtual-link

[sunrise1916]

Hi,all

Recently,I've ran into a problem about ospf virtual-link while doing the lab of ospf.The situation is simply like below：

when the virtaul-link between R2-R4 is done I've found neither R2 nor R3 which both as the  ABR for area0 and area1 would not inject the type-3 LSA of the prefix 45.1.1.0,as a result, the referred type-3 LSA was injected by R4 only.

R2：

R2#sh ip ospf  database | in 45
45.1.1.0        4.4.4.4         7     (DNA) 0x80000001 0x00B844
45.1.1.0        4.4.4.4         363         0x80000002 0x00B645

R3：

R3#sh ip os database | in 45
45.1.1.0        4.4.4.4         9     (DNA) 0x80000001 0x00B844
45.1.1.0        4.4.4.4         492         0x80000002 0x00B645

Now I've got a little confused ablout this,is here some specific mechanisms of ospf virtual-link or other possibilities?

[Rolf Fischer]

Hi,

neither R2 or R3 which both as the  ABR for area0 and area1 would not inject the type-3 LSA of the prefix 45.1.1.0,as a result, the referred type-3 LSA was injected by R4 only.

I assume that 45.1.1.0 is the link between R4 and R5?

If so, that link belongs to Area 2 and a VL belongs always to Area 0, so with the VL R4 becomes an ABR for Area 2. Why do you think that R2 and R3, both ABRs for Area 1, should generate a Summary LSA for an Area-2-link?

Hope I understood the question correctly.

Rolf

[sunrise1916]

Hi,Rolf Fischer     

As we all know,after the virtual-link was done,R4 would generate a Summary LSA for 45.1.1.0 into

the backbone area.Now I think the area2 could be treated as a normal non-backbone area,then should

not R2 and R3 which both are ABRs translate the Summary LSA  which come from backbone area

for area1?

[jarar_m01]

HI,

OSPF :

"

I think the area2 could be treated as a normal non-backbone area,then should

not R2 and R3 which both are ABRs translate the Summary LSA  which come from backbone area

for area1? "

Bro after VL even R4 is ABR to Area1 why would R2 and R3 inject LSA3 while R4 is already doing it.

[Rolf Fischer]

Ok, now I understand the question.

As Jarar already said, the VL makes R4 an ABR for area 2 but also for area 1. That means that R4 is also known inside area 1 as area-internal, and a new summary to an internal router in area 1 is not necessary.

You will find a similar behavior with a "normal" ABR (no VL) which is attached to two non-backbone areas.

[EDIT]:

You will find a similar behavior with a "normal" ABR (no VL) which is attached to two non-backbone Areas.

This was wrong, I apologize for the confusion. I think the crucial difference is that the next-hops of a VL belong to the transit area (Area 1 in this case).

For Summary-LSA generation, RFC 2328 defines an equivalent of Distance Vector protocol's split horizon logic:

"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]

[18] This clause is only invoked when a non-backbone Area A supports transit data traffic (i.e., has TransitCapability set to TRUE).
For example, in the area configuration of Figure 6, Area 2 can support transit traffic due to the configured virtual link between Routers RT10 and RT11. As a result, Router RT11 need only originate a single summary-LSA into Area 2 (having the collapsed destination N9- N11,H1), since all of Router RT11's other eligible routes have next hops belonging to Area 2 itself (and as such only need be advertised by other area border routers; in this case, Routers RT10 and RT7)."

[Rolf Fischer · Accepted solution]

Hi,

I really had to think about that ...

Short answer: A VL belongs to the backbone area, but it acts like a unnumbered point-to-point link with "borrowed" IP-addresses from the transit area. This has an effect of next-hop calculations, and because of the intra-area "split-horizon" rule ABRs do not translate the summary LSAs learned via the VL back into the transit area.

Not easy to understand, so I have this simple gns3 lab to show what I mean:

Note that the second byte of the IP addresses are the area IDs.

Before we look at a VL, lets see what happens when we use a GRE-Tunnel instead. (Keep in mind that a GRE is a overlay-tunnel and even a unnumbered GRE tunnel works not the same way as a VL does. It's just for demonstration purposes.)

The tunnel IPs are 10.0.12.1 and .2 (Area 0) and the endpoints are the Area 1 addresses 10.1.12.1 and .2.

R2#show ip ospf database self-originate

                Summary Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum
10.2.0.2        2.2.2.2         33          0x80000001 0x00A87D

                Summary Net Link States (Area 1)
Link ID         ADV Router      Age         Seq#       Checksum
10.2.0.2        2.2.2.2         33          0x80000001 0x00A87D

10.2.0.2/32 belongs to Area 2 and R2 generates a Summary in Area 0 and another from Area 0 into Area 1. The advertising router is unchanged.

On R1 we can see the expected behavior:

R1#show ip ospf database self-originate

                Summary Net Link States (Area 1)
Link ID         ADV Router      Age         Seq#       Checksum
10.2.0.2        1.1.1.1         498         0x80000001 0x00FA43

R1 also translates the 10.2.0.2/32 summary from the Backbone Area into Area 1. The originating router is of course R1 now.

That's what we won't see with a VL. Let's check some details first.

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -        00:00:31    10.0.12.2       Tunnel0
2.2.2.2           0   FULL/  -        00:00:34    10.1.12.2       FastEthernet1/0.1

R1#show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Tu0          1     0               10.0.12.1/24       1000  P2P   1/1

From the Backbone-Area R2 is reachable via the Tunnel interface and the next-hop is also in Area 0 (10.0.12.2).

Now I delete the GRE tunnel and configure a VL instead.

R2#show ip ospf database self-originate

                Summary Net Link States (Area 0)
Link ID         ADV Router      Age         Seq#       Checksum
10.2.0.2        2.2.2.2         18          0x80000001 0x00A87D

                Summary Net Link States (Area 1)
Link ID         ADV Router      Age         Seq#       Checksum
10.2.0.2        2.2.2.2         18          0x80000001 0x00A87D

No difference on R2.

R1#show ip ospf database summary 10.2.0.2 self-originate

            OSPF Router with ID (1.1.1.1) (Process ID 

But no Summary originated from R1 now...

R1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
2.2.2.2           0   FULL/  -           -        10.1.12.2       OSPF_VL1
2.2.2.2           0   FULL/  -        00:00:33    10.1.12.2       FastEthernet1/0.1

And here is the difference: The VL belongs to the Backbone-Area but look at the next-hop address. It is an Area 1 address now. So let me repeat the RFC 2328 quote:

"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."

You can even see this very nicely with the following debug command:

R1#debug ip ospf lsa-generation
OSPF-1 LSGEN: Split-horizon: do not generate summary LSA from inter-area prefix, id 10.2.0.2, type 3, into area 1

Quite complicated but I hope it makes sense. Really a challenging question :)

HTH
Rolf

[sunrise1916]

Hi,Rolf Fischer For a apology that I came late, rfc2328 is truly detailed and your explanation is really perfect,thank you for taking time to explain this question, sincerely.