T his post represents the solution and explanation for quiz-10.
Have a look at the quiz to understand the problem.

Quiz Review

This quiz has a detailed solution already presented in one of my very first posts, from 2011, back in the times when I was "experimenting" with the term of "blogging" ☺ For this reason, please have a look at that post to understand the theoretic part and then read this article to get the full picture.

In short, the problem is caused by the fact that the PEs set the Down-bit (DN bit) in all Type-3 LSA sent towards the respective CEs. As explained in the above-mentioned post, this is used to prevent a routing loop in situations when that LSA reaches another PE (for example, if there is a backdoor between two CEs, then that LSA will reach other PEs via the backdoor link, thus creating a routing loop).

The consequence of the Down bit is that not only the PEs but any router running VRFs (with or without MPLS = VRF-lite or not) will drop the LSAs having the DN-bit set and in our quiz, CE2(R5) is using VRF-lite to keep separate routing tables for internal network vs. partner routes.
Note that the LSA is not actually dropped, it exists in the OSPF database (as shown in the quiz), but it is not considered for SPF calculations!

LSA with DN bit set

It is interesting to note that Cisco does not fully respect the RFC standards [UPDATE: RFC4577 RFC4577 actually talks about both methods: DN bit and route tagging, though it considers tagging as an "old implementation". Note that RFC4576 only talks about DN bit]. RFC 4577 (OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs) and RFC 4576 (Using a LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs) say:
(quote) When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.(end-of-quote)
but Cisco sets the DN-bit only in the Type-3 LSAs (and it is using route tagging for External Type-5 LSA as loop prevention mechanism).

How does the PE decide what type of LSA to generate when an OSPF route is received over the MPLS cloud (the superbackbone) ?

This is based on the attributes that travel along with the route within the VPNv4 prefix as BGP extended communities.

Let's see: Office #1 route (lo0 on CE1/R1) reaches PE1 (R2) which sends it over the MPLS/BGP cloud as a VPNv4 and reaches PE2 (R4).


PE2/R4 selects it as BGP best route (according to BGP rules) and then it redistributes it into Area 2 (towards R5/CE2), but before doing that, it needs to decide which type of LSA to generate for it. Under normal BGP-to-OSPF redistribution conditions, this route should be sent as a Type-5 External, but this is not true from customer's perspective - this route is NOT an external-AS one. Companies, which choose MPLS VPN services to interconnect their offices, expect the routes from other offices to be seen as internal, not external.
For this to happen, the second PE (R4) compares the domain-id contained in the VPNv4 route with the domain-id of the OSPF running with CE2. By default, in Cisco implementations for IPv4 (OSPFv2), the domain-id is set to be the same as the process-id. (Note that for OSPFv3, the default value is NULL).

The domain-id can be configured to a non-default value with the following command under the OSPF process:

R4(config)#router ospf 100 vrf CUST_A
R4(config-router)#domain-id ?
  A.B.C.D  OSPF domain ID in IP address format
  Null     Null Domain-ID
  type     OSPF domain ID type in Hex format

If the domain-id contained in the VPNv4 route is different than the one configured/existing in the local OSPF process on CE2, then the OSPF route is considered external (O E2) and it is injected as a Type-5 LSA.

In our quiz, as there's no special configuration for the domain-id, both PEs (R2 and R4) uses the process-id (100 on both routers). Here is output from PE (R4):


As a result, the route is considered internal (inter-area route, O IA), therefore injected as a Type-3 LSA with the Down-bit (DN-bit) set as per loop prevention requirements:

R5#sh ip ospf data summary

            OSPF Router with ID ( (Process ID 100)

                Summary Net Link States (Area 2)

  LS age: 1119
  Options: (No TOS-capability, DC, Downward)
  LS Type: Summary Links(Network)
  Link State ID: (summary Network Number)
  Advertising Router:
  LS Seq Number: 80000004
  Checksum: 0x2BB3
  Length: 28
  Network Mask: /32
        TOS: 0  Metric: 2

As I mentioned above, these LSAs with DN-bit set are not considered for SPF calculations by any OSPF router running VRFs => that summary LSA does not appear in the RIB on CE2/R5 router!


Now, let's see what solutions exists for this quiz:

1. Using capability vrf-lite Command

Cisco introduces an "elegant" solution for exactly this type of problem: command capability vrf-lite configured on the router running VRF-lite, which is not a PE, in order to make him consider that LSA (with DN-bit set) for the SPF calculations.

capability-vrf-lite "Capability VRF-Lite"
Note that the OSPF adjacency gets reset when this command is configured!

2. Setting Different Domain ID

Another solution is to manually configure different OSPF domain-ids on the PEs (using command domain-id) in order to force the OSPF routes learned over the MP-BGP to be injected as external Type-5 LSAs.
Cisco implementation does not set the DN-bit in the type-5 LSAs (and for this reason, this command represents a candidate solution for our quiz):

Let's set a different domain-id on PE2/R4 and see the result on CE2/R5:

Notice the routes learned as external "O E2"

R5#sh ip osp data ex

            OSPF Router with ID ( (Process ID 100)

                Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 302
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: (External Network Number )
  Advertising Router:
  LS Seq Number: 80000001
  Checksum: 0x9C6B
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0
        Metric: 2
        Forward Address:
        External Route Tag: 3489660929

Notice that there's no DN bit set on type-5 LSA (normally indicated by the Downward keyword) (contrary to what the RFC says !) but there is a route tag of 3489660929 = 11010000.00000000.00000000.00000001 (in binary) which is according to the RFC 4577 (section "1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 AS number of the VPN Backbone" (in our case 1)

2.1 Setting Different Process ID

Since, by default, the OSPF domain-id for OSPFv2 (in Cisco Implementation) is set equal to the Process-ID number, then configuring different process-ids on the PEs (under the relevant OSPF VRF instances) will get us in the exact situation as above solution 2.

Configuring a sham-link between PEs was indicated by a lot of readers as a possible solution to this quiz.
Unfortunately, it does not represent a solution right away because of 2 thinks that appear in the quiz:

  • the "network area X" that is configured on both PEs -- remember: Sham-Links Endpoint Addresses MUST NOT be advertised by OSPF
  • the bigger impediment is the difference in the Area numbers on the PE-CE Areas of the offices (Area 1 on R1-R2 vs Area 2 on R4-R5)
    Of course, nothing stops you from choosing one of the area number (let's say 1) and use this number in command area 1 sham-link x.x.x.x y.y.y.y) on both PEs => thus the sham-link and the adjacency will go up. Otherwise, if you continue to use a different Areas towards the CE2/R5 then the PE2/R4 will still send those routes as summary Type-3 and, of course, the DN-bit will still be set on them!

In order to make this solution to work, we need to solve these two above "extra"-issues and here is the final configuration:


As a result, due to the sham-link, the customer CE2/R5 (now configured in new Area 1) will see the OSPF routes redistributed by PE2/R4 as intra-area, which solves the quiz (since there is no DN-bit in type-1 LSAs):

R5#sh ip route vrf MY_NETWORK ospf is variably subnetted, 2 subnets, 2 masks
O [110/3] via, 00:40:44, FastEthernet0/0
O [110/4] via, 00:40:44, FastEthernet0/0

Thank you for your comments and interest in the quiz!