his post represents the solution and explanation for quiz-10.
Have a look at the quiz to understand the problem.
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.
The consequence of the Down bit is that
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 [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:
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
Let's see: Office #1
route 192.168.1.254/32 (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
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
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,
sh ip ospf data summary 192.168.1.254OSPF 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!
Now, let's see what solutions exists for this quiz:
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.
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:
sh ip osp data ex 192.168.1.254OSPF 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
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.
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.
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 numberson 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
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
Thank you for your comments and interest in the quiz!