OSPF Strange Behaviour With Two Backbone Areas

[daudparvez]

Hi All,

I am trying OSPF in the scenario attached on GNS3 to explore virtual links.

I am facing a strange behaviour from R2 and R3.

Without configuring any virtual link, although R2 has the following Type 3 LSAs in it's LSDB, but it does not install these in it's Routing Table:

3.0.0.0/8

4.0.0.0/8

Also, R3 has following Type 3 LSA in it's LSDB but it does not install it in it's Routing Table:

1.0.0.0/8

Can someone please clarify this to me?

Keep in mind that this scenario is without configuring any virtual link.

Regards,

Daud Parvez

[Peter Paluch · Accepted solution]

Hello Daud,

You are absolutely correct about your observation and that is how OSPF is intended to run. R2 knows that is it an ABR because it has its interfaces in different areas. In such case, RFC 2328 mandates that R2 as an ABR processes summary LSAs only from Area 0. As the LSA-3 came through Area 1, they are installed into its LSDB but not processed - hence the requirement to have Area 0 contiguous.

RFC 2328, Section 16.2:

        The inter-area routes are calculated by examining summary-LSAs.
        If the router has active attachments to multiple areas, only
        backbone summary-LSAs are examined.  Routers attached to a
        single area examine that area's summary-LSAs.

Best regards,

Peter

[daudparvez]

Thanks Peter for your help as usual.

Best Regards,

Daud Parvez

[daudparvez]

Dear Peter,

Consider another scenario, in which i have configured a virtual link.

I will specifically consider the 1.0.0.0 subnet.

In this case, R5 installs two TYPE 3 LSAs for the mentioned subnet. One from R2 and one from R3 which gets it on the virtual link. Also, it installs the 1.0.0.0/8 in it's routing table with the next hop routers as R2.

Can you please explain how does this fit the RFC since R5 which is in a non-backbone area (area 1) gets it from another non-backbone area (area 2).

Regards,

[Peter Paluch]

Hello Daud,

Creating a virtual link between R2 and R3 will make them establish a directed (targeted) adjacency that lies in Area 0. In effect, it is as if you created a point-to-point unnumbered connection between R2 and R3. Now, for the origination of LSA3 by ABRs, the RFC 2328 Section 12.4.3 explains it at large. To say it in short, a router first computes its routing table (an internal OSPF routing table) for an area. Then, after this routing table is computed:

• if the area is the backbone area, it will take all intra-area and inter-area routes from this routing table, generate LSA-3 summaries for each of these networks and flood them to all other non-backbone areas (except totally stubby areas). Also, if a network for which a summary LSA is being generated is associated with a particular non-backbone area (it is internal within that area or the next hop towards it is within that area), the summary LSA will not be flooded into that area, as it would merely duplicate what is already known better.
• if the area is a non-backbone area, it will take all intra-area routes from this routing table, generate LSA-3 summaries for each of these networks, and flood them to the backbone area only

This is what happened with R2 and R3. Each of them knows about the 1.0.0.0 network as internal in Area 0. For R2, it is truly an internal network. For R3, it appears as internal network because R3 is by the means of virtual link to R2 also a full member of the Area 0. Thus, both R2 and R3 are ABRs between the backbone area 0 and the Area 1, and both of them originate the corresponding LSA-3 for all networks internal to area 0, among other things. Hence, R5 can see two LSA-3 entries for the 1.0.0.0 network because both R2 and R3 - as rightful ABRs - informed all non-backbone areas about their own distance to the corresponding network.

Best regards,

Peter

[Peter Paluch]

Daud,

You are always welcome. Thank you for your generous ratings!

One related point: Many times, OSPF is run on customer devices in a VRF (the VRF-lite deployment). On Cisco routers, by default, every time OSPF is run in a VRF, it thinks that it is actually running on a provider edge router as VRFs are common on provider devices. Now, there is a mechanism called MPLS Superbackbone that allows to interconnect several OSPF sites of a single customer over MPLS L3VPN (the "superbackbone") so that the see each other as OSPF IA networks. Ordinarily, they would see each other as OSPF E1/E2 networks because there is a redistribution between the customer's OSPF and provider's BGP, but the MPLS Superbackbone makes the individual customer sites consider each other as separate areas of the same OSPF domain. The details are not that important right now.

And this is where the problems with OSPF in VRF-lite start to appear. As I already indicated, OSPF run in VRF considers itself to be running on a provider edge device, and automatically considers itself "connected" to the MPLS Superbackbone. In other words, every OSPF run in VRF automatically considers itself as an ABR, without actually having any interfaces in different areas at all!

Now imagine that your network uses some non-zero area, and the area contains an internal router which runs OSPF in VRF (all its interfaces are in the same non-backbone area). If there are any summary LSAs being injected into this area by some other router, the router running OSPF in VRF will see the summary LSAs but will not process them. According to original RFC 2328, it should accept them just as any other internal router, but the difference here is that this router considers itself to be an ABR (because of the MPLS Superbackbone), and just as you saw with R2 in your first example, it will not process the received summary LSAs if they are not received in Area 0. This can be quite confusing, as VRFs are often used without any MPLS, and the notion of MPLS Superbackbone is by far not obvious.

This MPLS Superbackbone can be deactivated in the particular OSPF configuration using the capability vrf-lite command. This command causes that the OSPF does not think anymore it is an ABR to the MPLS Superbackbone, among other things, and will allow to process summary LSAs even if run in VRF just like any other internal router.

Best regards,

Peter