I am working on a particular practice lab has given me a headache for the past couple days. The lab is pre-configured with an L3VPN where OSPF is used as the PE-CE protocol, and there are a number of issues already introduced that I have to find and resolve. I have gotten all but one of the issues resolved.
The last issue to resolve for the lab is that the “customer RTR” can reach an end host hanging directly off PE3. Here is the simplified topology, showing where VRFs are configured and some relevant config:
Right off the bat, you might notice that Customer RTR is running a VRF with OSPF and is not connected to the MPLS, obvious answer is to add “capability vrf-lite” to that VRF’s OSPF process and call it a day. But, one of the very specific stipulations of this lab is that we cannot modify the Customer RTR at all.
One extra note, my next impulse was to run a Sham-link between PE1->PE3 and PE2->PE3, this would mean routes would be intra-area/type1&2 LSAs and not marked with the DN bit. However taking a closer look, PE3 does not run any VRF OSPF, so there is no OSPF process to run the Sham-link from. BGP just advertises the link via a network command under the VRF AFI.
For kicks and giggles I did replace the BGP network statement with an OSPF process and ran a sham-link and it did indeed work. But it was a lot of changing of the initial config and I really don’t think it was intended as an answer. I also did add ‘capability vrf -lite’ to ‘Customer RTR’, and that too fixed the issue…
I’m hoping there’s just some ‘gotcha’ config I’m not aware of or haven’t learned, or maybe this lab is just written incorrectly, but if anyone has a good idea please let me know.
Edit: I should probably mention that the 192.168.1.0/24 route is showing up in the OSPF database of ‘Customer RTR’ just not in the Route table, so the routes are propagating.