Where to configure the "capability vrf lite", on CE or PE?

[m1xed0s]

My understanding is:

1. "capability vrf lite" will make OSPF process to install the routes even with DN bit set.

2. PE running VRF will set the DN bit when advertising to CE if OSPF is used for PE-CE routing. But CE is the device to check the DN bit when installing the route...

So where to configure the

"capability vrf lite", assuming CE is not running VRF at all (most likely in real production)?

And also what if CE is actually running VRF?

[Joseph W. Doherty]

Ah, I now suspect I totally misunderstood your initial question.  You're really asking about the need, or not, of the command "capability vrf lite" and your mention of OSPF was as a possible example of need, correct?

[iores]

@Joseph W. Doherty I think I understand the need - to prevent the loop because of mutual redistribution between OSPF and BGP. As a result, the LSA 3, 5 and 7 have the Down Bit. However, if using only Area 0, and VRFs, is it necesseary to use the comand "capability vrf lite"? Or in general, what are use cases where this command is not necessary when using OSPF and VRFs?

[Giuseppe Larosa]

Hello @iores ,

the capability vrf lite is typically used on multi VRF CE or you can call it VRF aware CE devices.

The checking of the DN bit should never be disabled on PE nodes.

To be more clear there are some network design that rely on the fact that PE nodes do not install LSAs with DN bit set. I took part in a network design that relied on this. There were two PE nodes and they actullay connected on multiple VLANs to the same CE nodes. CE nodes were not VRF aware so they merged the OSPF DB. However, thanks to the DN bit check the PE nodes were not merging the OSPF DB ( they had one for each defined VRF).

Hope to help

Giuseppe

[Joseph W. Doherty]

It appears it's needed when you have a CE router, with multiple VRFs, using OSPF with a PE router, that's going to redistribute OSPF routes into BGP.

Down-bit Ignore Feature in OSPFV2 PE-CE Scenario on Cisco NX-OS (although explained in the context of NX-OS, it's the underlying issue that's of interest.

Chapter: OSPF Support for Multi-VRF on CE Routers 

Unless you're involved in the above, it shouldn't be an issue.  I suspect it has much to do with VRF-Lite is basically interface based and only BGP has the capability to "tag" VRFs to routes.  If you're using just OSFP with VRF-Lite, between devices, its a non-issue or if using BGP supporting VRF tags, it should be a non-issue.  Appears the issue is when you mix the two.

An usage example.

Additional links:

https://www.linkedin.com/pulse/my-vrf-gotcha-gerardo-marciales

https://ipwithease.com/vrf-vs-vrf-lite/

https://recursive-lookup.com/downbit-capabilityvrflite/

http://www.bscottrandall.com/4.1.9

Again, my apologies.  I initially took you initial posting just asking about the difference in capabilities between VRF-Lite and VRF.

[iores]

@Joseph W. Doherty No need to apologize! Thank you for your time. So the conclusion would be that command "capability vrf-lite" needs to be used only if OSPF and VRFs are used along with redistribution/route leaking between VRFs (not the GRT) or with additional areas except Area 0.

Another thing. Peter said, in the example he provided, that R1, since it consider itself as ABR, will not accept LSA 3 since they are coming from area 1. Wouldn't R1 as ABR accept but not forward further LSA 3? I am looking at this the same as the example of discontiguous network where ABR will receive but not forward further LSA 3 coming from area other than area 0.  What am I missing?

[Joseph W. Doherty]

"What am I missing?"

Honestly, at this point my head hurts (laugh) and it's not a part of networking I've ever experienced.  (The one network where I've used a MPLS VPN, we used BGP between our CEs and provider's PEs, where our other site CEs were one or more provider AS hops away.)

Skimming more of the documentation on this feature and the "issue" that's to be addressed, appears you may very much need it, but it appears Cisco support varies across platforms, other (more appropriate) features might be used, and/or a particular platform may not conform with relevant RFCs.  (Much of the forgoing is why my head hurts.  [This subject sort of reminds me of another posting which turned out there was an old and new OSPF RFC, which had different behaviors, and, of course, whether Cisco supported the newer RFC or which was the default, varied by platform.])

So, I'm sure I'm not the right person to clarify or confirm Cisco operation.  Peter would be ideal, but ever since he joined Cisco, they've kept him very busy and he doesn't nearly participate as he did in the past..

@Giuseppe Larosa I recall (?) has SP experience, where mine is all Enterprise.  He might be able to further clarify usage and/or Peter's comments.

[Giuseppe Larosa]

Hello @iores ,

>> So the conclusion would be that command "capability vrf-lite" needs to be used only if OSPF and VRFs are used along with redistribution/route leaking between VRFs (not the GRT) or with additional areas except Area 0.

You need to use the command capability vrf-lite to disable all the loop avoidance checks that are performed by PE nodes and it is typicall used on multi VRF CE nodes connected to one or more PE nodes.

This is explained here:

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-sy/iro-15-sy-book/iro-sup-vrf.html

Reviewing all the thread and Peter's posts, my guess is that he was thinking of a complete service provider network with MPLS L3 VPN with the routers connected to PE nodes ( not shown in his network schema).

Most of the times the command is needed to be able to accept LSAs with the DN bit set. These LSAs are typically generated by PE nodes as the result of redistribution of MP BGP routes in address family vrf <vrf-name> that were generated by remote VRF Sites PE nodes with added information.

The MPLS superbackbone that is mentioned in this thread is just an emulation. OSPF is not executed between PE nodes that take part to the same VRF. Actually PE nodes exchange VPNv4 MP BGP NLRI prefixes with added information. And the data plane is MPLS using a stack of two labels (ignore penultimate hop popping implicit null on penultimate router on the path for the moment).

On the remote PE node the PE-CE protocol is OSPF as it is in the local VRF site.

The MPLS superbackbone emulation is achieved in redistribution of OSPF in MP BGP AF vrf <vrf-name> and then in exporting to VPNv4 prefix by adding BGP extended communities attributes that allow the local PE node ( or remote PE node from the point of view of the PE creating the VPNv4 prefix) to rebuild OSPF LSAs according to some criteria.

These BGP extended communities allow to carry the following information :

OSPF Domain ID : this is a number that by default in Cisco implementation is equal to the OSPF process id that is redistributing the route from. It can also be set with an explicit command.

OSPF LSA type :  it says if the LSA is type 3,4,,5 .  There is no utility on carrying LSA type 1 or LSA type 2. The PE nodes act as ABR nodes so only LSA type 3,4,5 are of interest.

OSPF metric : metric value

These added info allows for the receiving PE nodes that are redistributiing VPNv4 MP BGP routes into the local VRF to build appropriate LSAs.

if the local OSPF Domain ID is different then the received OSPF Domain ID all rebuilt LSAs will be external type 5.

if the local OSPF Domiain ID is equal to received OSPF Domain ID , the MPLS superbackbone is triggered.

LSA type 3 are rebuilt as LSA type 3 originated locally by the PE node with appropriate metric in the area used on the PE -CE link(s)

LSA type 4 and type 5 are rebuilt as LSA type 4 and type 5 with type and metric.

From the point of view of the attached CE node  it is not aware of all the stuff performed in SP control plane, it receives a set of LSAs that are acceptable from locally attached PE node(s) and it can use it.

The PE nodes when creating these LSAs set the DN bit to signal that these LSAs are actually rebuilt from MP BGP and to make other PE nodes that would eventually receive them able to discard / ignore them as I have explained in a previous post.

From the document listed above we see the following sentence regarding show ip ospf N

>> When the OSPF VRF process is configured with the capability vrf-lite command under the router ospf command, the "Connected to MPLS VPN Superbackbone" line will not be present in the display.

This is probably what Peter Paluch was referring to in his posts in this thread.

Hope to help

Giuseppe