Unbound loopbacks for multiple transport colors

[Torbjørn]

I have two edges connected to two switches and two routers running VRF lite. The both routers terminate an MPLS circuit and and internet circuit into separate VRFs. There are sub-interfaces for each VRF from the switches and routers towards my edges. To be able to utilize the redundant paths to each transport I must use unbound loopback interfaces as tunnel interfaces. The only way I have figured to keep the transports separated is to filter routes such that the loopback interface address for each color is only visible to the appropriate VRF.

Is there a better way to utilize redundant paths to different transports in scenarios like this?

[MHM Cisco World]

Can you share config 

[Kanan Huseynli]

HI,

topology is not clear. You have 2 circuits and both border (these are non-sdwan) are connected to circuits. Both circuits are terminated in different VRF. These routers are connected to switches and switches are connected to edge (sdwan) routers.

How many connections you have on edge side? It is preferred two physical cables connected to switch and at L2 passed on the same VLAN to border routers (where you have different VRF). Why do you need loopback also not clear, please give details.

[Torbjørn]

Had a read in the "Cisco SD-WAN" book and found this paragraph that covers my usecase pretty well:

---

In nearly all cases, the data center is the first site to be migrated to Cisco SD-WAN. While there are many ways to design SD-WAN into the data center, the most commonly deployed and strongly recommended approach is to insert and run the solution in parallel with the existing WAN. This is accomplished by standing up Cisco SD-WAN routers alongside the current WAN Edge infrastructure (behind the Multiprotocol Label Switching [MPLS] CE/PE or Internet Edge routers) and providing the routers connectivity to WAN transports indirectly. This is especially true when an organization doesn’t have the luxury of providing the Cisco SD-WAN router dedicated circuits or handoffs for all the transports already in service. It is common to see new SD-WAN routers leveraging private connectivity through an existing MPLS CE/PE router and public connectivity through an existing secure Internet Edge firewall. Figure 12-1 depicts this architecture.

---

Recreation of fig 12-1:

This doesn't quite describe the technical implementation of how routing for the different colors should work. In my case the topology is a bit different in that the internet circuits are terminated on the same "Enterprise edge" routers that the MPLS circuits are, and from there they are routed in separate VRFs such that all traffic must pass through the firewalls. The topology looks like this:

Since it is fairly common I assume that SD-WAN has a way to handle VRF separated transports. To make this work while maintainting link redundancy for the cEdges I would need to use unbound loopback interfaces, but this causes issues in using multiple colors and keeping them separated on layer 3. My head wants to extend the VRFs to the cEdges, but this isn't possible due to all transports having to reside in VPN 0. How would I go about implementing this?

[Kanan Huseynli · Accepted solution]

OK, I think I understood.

What type of underlay routing do you use to reach transport providers? BGP or Static? For MPLS border routers, for internet Firewalls should be next-hop for SDWAN routers, right?

You basically should force SDWAN routers to use firewall for internet, edge routers for MPLS (as next hop) by routing.

If static routing is used, just add explicit routes for MPLS and default route for internet.
If BGP is used, borders should advertise MPLS subnets to sdwan, and firewall should advertise internet default route to sdwan.

Based on "longer prefix-length wins" logic, for mpls subnets borders will be chosen as next-hop, for internet firewalls.

Note: border in different VRF can also be next-hop for internet, then based on topology switch must forward at L2 from sdwan to border, terminaed in VRF and somehow (e.g PBR) redirected to firewall.

[Kanan Huseynli]

Problem can be, how to design controller access..

What type of controllers do you use? cloud or on-prem. If, on-prem, are they behind NAT or they have pure public IP on them?

[Torbjørn]

Okay, so the solution to this is essentially to rely on "regular routing" and apply careful filtering of routes to keep the VRFs separated. The controllers are self hosted and reachable both through the MPLS VRF and the Internet VRF, so this won't be an issue.

Thank you!