OSPF vrf's connected to mpls vpn superbackbone and virtual links

[richardgosen]

Hi All,

I am facing some issues where OSPF does not learn routes from multiple vrf's via a backend firewall which is in the same OSPF area.

Here is how the topology looks like:

MPLS VPN Backbone-->PE router (vrf) ospf area 1-->CE router (vrf) ospf area 1 | virtual-link transit area 1 | ospf area 2-->firewall, all interfaces in area 2-->CE router ospf area 2 | virtual-link transit area 3 | router (vrf) ospf area 3-->PE router (vrf) ospf area 3-->MPLS VPN Backbone.

I have the above topology to use resources from one vpn from another where the firewall blocks or accept the destination. The firewall learns all the routes from the vpn's in the routing table but does not pass the routes from one vpn to another. I can see them in de ospf database on the CE routers but not in the routing table of the specific vpn.

Do you guys know what I mean and is there some solution for this issue?

Richard

[Peter Paluch]

Richard,

I am having troubles finding out where are the individual ABRs, between which exact routers is the virtual link configured and which routers run in VRF as opposed to global routing table. Can you perhaps post a schematic topology that contains just the areas, PEs, CEs, ABRs and virtual links?

Thank you!

Best regards,

Peter

[Giuseppe Larosa]

Hello Richard,

>> The firewall learns all the routes from the vpn's in the routing table but does not pass the routes from one vpn to another. I can see them in de ospf database on the CE routers but not in the routing table of the specific vpn.

When a PE router generates an OSPF LSA in a VRF instance the PE node sets the DOWN bit to signal the LSA is coming from an MPLS backbone.

This setting is not considered by CE routers but it is checked by other PE nodes that will NOT use any received LSA with the DOWN bit set.

This is used as a loop prevention mechanism for multihomed VRF sites and complex topologies.

You may be able to make a PE router accept LSAs with DOWN bit set with the command

router ospf XX

capability vrf-lite

In addition to all of this you have  used virtual links in an attempt to make possible the propagation of LSAs end to end from PE to PE node.

Hope to help

Giuseppe

[richardgosen]

Also response to Peter Paluch

Thank you all for thinking this through. I am not a good draftsman but here is how it looks like.

The routing between the PE and CE is done with the "capability vrf-lite" on the CE router. The route towards the firewall is in one OSPF area (area 2). the firewall learns all the routes of vpn-a and vpn-b, but vpn-a is not learning the routes that are in vpn-b, although it is in the same area. Am I missing something here? Or is it just correct OSPF behaviour.

I am planning to get this going with RIPv2 en do mutual redistribution between OSPF en RIP.

Any thoughts?

Best regards,

Richard

[Peter Paluch · Accepted solution]

Hello Richard,

This picture is perfect! It helps immensely.

Your OSPF setup in this case is, to be honest, quite unfortunate. You have three daisy-chained areas, none of which is a backbone area. In OSPF, this is not allowed so understandably, there are virtual links configured. These virtual links between corresponding PEs and CEs virtually form a backbone but there is another problem - now, you have a partitioned backbone because of the Area 2 that sits between the two backbone partitions. Each partition contains the PE and CE pair along with the virtual link that connects them. However, a continuous backbone in your case requires that these two partitions are interconnected. The easiest way to do this is via configuring a virtual link between the CE routers in Area 2. Another options include

• creating a physical link or a GRE tunnel between CE routers and putting it into OSPF Area 0
• configuring a sham link between the PE routers in the appropriate VRF
• renumbering the Area 2 to Area 0

The reason why the firewall sees all routes while vpn-a and vpn-b do not see each other's routes is because the firewall is an internal router in the Area 2 and thus processes LSA-3 (inter-area prefixes) received in Area 2 from both CEs. However, CE routers are ABRs and by OSPF rules, they process LSA-3 received only in the backbone Area 0. Note that the only LSA-3 the CEs can currently receive in Area 0 are from PEs but not from each other. As a result, the CEs are currently unable to "represent" their areas 1 and 2 to each other. The virtual link between CEs will solve this.

I understand this is not an easy topic to digest so please feel welcome to ask further!

Best regards,

Peter

[richardgosen]

Thank you Peter for clarifying my setup. This example that I drawed is one of the many vpn's that is entering the datacenter. I have about 30 of these OSPF area's that are entering the datacenter this way. Untill now everything from the CE is routed statically to the firewall and from there back into antoher OSPF area. This is working fine, however, the static routes are enormous and second another datacenter must take over when the primary fails. So that is the story why I want to route dynamically and the first choise was OSPF.

I now understand why the vpn's do not learn the routes from each other because of the area 2 in the middle and the other  area's hanging there will only process LSA-3 received from the backbone.

This OSPF design is, like you mentioned, not the best scenario for realizing dynamic routing. It also has to be managed in the future and you have to do some "tricks" to make it work. I want to look at implementing RIPv2 at the CE router and redistribute this into the appropiate area with filtering of routes.

Thank you so much for explaining my setup. You have made it very clear to me.

Also thanks to Giuseppe for thinking with me.