This quiz has a detailed solution already presented in one of my very first posts, in 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 to the respective CEs. As explained in the above-mentioned post, this is used to prevent a routing loop in situations when this LSA reaches another PE (for example, if there is a backdoor between two CEs, then this 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!!
It is interesting to note that Cisco does not fully respect the RFC standards. 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:
<<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.>>but Cisco sets the DN-bit only in the Type-3 LSAs (and it is using route tagging for External Type-5 routing loop prevention).
How does the PE decide what type of LSA to generate when an OSPF route is received over the MPLS cloud ?
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 192.168.1.254/32 (lo0 on CE1) reaches PE1 (R2) which sends it over the MPLS/BGP cloud as a VPNv4 and reaches PE2 (R4) as seen below:
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 in our quiz) 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 OSPF process with CE2, then the OSPF route is considered external 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), sothe domain-id is the same and in this case the route is considered internal and injected as a Type-3 LSA with the Down-bit (DN-bit) set as per loop prevention requirements:
R5#sh ip ospf data summary 192.168.1.254
OSPF Router with ID (192.168.2.254) (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: 192.168.1.254 (summary Network Number)
Advertising Router: 192.168.2.4
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!
Solutions
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.
Note that the OSPF adjacency gets reset when this command is configured!
2. Setting Different Domain-IDs
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 (which represents a candidate solution for scenarios with VRF-lite on CE, as in 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 192.168.1.254
OSPF Router with ID (192.168.2.254) (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: 192.168.1.254 (External Network Number )
Advertising Router: 192.168.2.4
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: 0.0.0.0
External Route Tag: 3489660929
3489660929 = 11010000.00000000.00000000.00000001 (in binary) which is according to the RFC 4577 (section 4.2.5.2):
“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-IDs
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.3. Using a Sham-Link (??)
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 0.0.0.0 255.255.255.255 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, but if you continue to use a different Area (area 2) 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!
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
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
O 192.168.1.0/31 [110/3] via 192.168.2.4, 00:40:44, FastEthernet0/0
O 192.168.1.254/32 [110/4] via 192.168.2.4, 00:40:44, FastEthernet0/0
