How to Form SD-WAN Tunnels Using Multiple Loopbacks with Different Col

[vin.marco]

Hi everyone, I have a question for the experts here.
I need to build tunnels using multiple Loopback interfaces as the source, each one with a different color:

• one Loopback with the Private1 color,
• another with Private2,
• and a third one with Private3.

What is the correct way to configure this? Is it possible to assign different colors to separate Loopbacks and use them to form SD-WAN tunnels? Are there any best practices or limitations I should be aware of?

Thanks in advance for your help!

[Jeongjun Park]

Hi.

Many clients use this architecture.

You can achieve it.

Please check this sample configuration.

Device(config)# sdwan interface Loopback1
Device (config-interface-Loopback1)# tunnel-interface
Device (config-tunnel-interface)# encap ipsec
Device (config-tunnel-interface)# color 3g
Device (config-tunnel-interface)# bind GigabitEthernet1

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/configure-interfaces.html

and this is note.

* If one side uses loopback, other side is recommended to use public address. 

Thanks !

Please choose this as a solution If this is helpful.

[vin.marco]

So the answer is yes — I can create multiple Loopback interfaces and assign different colors to each of them. Are there any limitations or specific considerations I should be aware of?

[Cristian Matei]

Hi,

   Correct, the answer is yes. Couple of recommendations:

1. Use the underlying physical interface, across which the Loopback is routed, just as transport, meaning don't assign TLOC's to the physical interface as well, just to the Loopback.

2. If you have a Loopback routed over a single physical interface, use bind mode; if you have a Loopback routed over multiple physical interfaces, use unbind or standard mode

3. In terms of limitations, when using Lopback in bind or unbind mode, you need to be aware of the implicit ACL rules, aka allowed traffic / protocols behaviour. Read here starting with "Information About Implicit ACL on Loopback Interfaces" chapter: https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/configure-interfaces.html

One question though, what is the technical reason for which you want to use Loopbacks as TLOC's / tunnel termination, instead of using the physical interfaces; the use of Loopbacks exists to fix some design challenges and / or simplify policies. Without such technical reason, using Loopbacks adds complication in design, without fixing anything, which why would you do it? In network design you want to follow the KISS principle.

Thanks,

Cristian.

[vin.marco]

The technical reason is the following:
The cEdge devices and the provider routers are connected to a firewall. To avoid asymmetric routing and to ensure device redundancy, I’m planning to terminate the remote cEdge tunnels on Loopback interfaces on the HQ routers.

The HQ routers will establish an iBGP peering with the firewall, and by using BGP attributes I can prevent routing asymmetry.
So the decision is purely driven by design considerations.

I’m not sure if I’ve been entirely clear, hope it makes sense! 😊

[Cristian Matei]

Hi, 

    I'm not 100% confident I understood the exact scenario, however even without having a complete and clear picture, I don't see how you can avoid asymmetric routing by terminating tunnels on Loopbacks instead of on physical interfaces. By running BGP and using BGP attributes you can easily manipulate the ingress / egress paths to be symmetric, in order to terminate tunnels on physical interfaces.

Thanks,

Cristian.

[vin.marco]

Let me try to explain it better by referring to the topology diagram:
as you can see, all the gateways (GW) are directly connected to the firewall. I’m redistributing routes from OMP into BGP toward the firewall, and the firewall in turn redistributes BGP routes into the enterprise network.

At a site where I have two cEdge devices connected using TLOC Extension, I’m concerned that asymmetric routing could occur.

By using Loopback interfaces as TLOCs instead, I can ensure that OMP routes for all colors are received by both HQ cEdges. This also allows me to control which cEdge will forward the traffic out of the HQ site, helping to avoid routing asymmetry.

I hope this makes my intention clearer! 😊

[Cristian Matei]

Hi,

   I still see that you can ensure symmetric routing by not needing to use Loopbacks. Can you explain why, in your vision, if you don't use Loopbacks, you can't ensure that OMP routes for all colors are received by both HQ cEdges, as this seems to be your concern?

Thanks,

Cristian.

[vin.marco]

The reason is that each cEdge has only one physical interface that can carry a specific color. By using Loopback interfaces, I can create multiple logical interfaces, each with a different color.

All physical interfaces are already fully utilized: two of them are assigned to VPN 0, and the other two are used for additional service VPNs. On top of that, they are bundled in an LACP port-channel toward a stacked switch and then connected to the firewall cluster.

Therefore, the only practical way for me to have multiple TLOCs with different colors is to rely on Loopback interfaces.

[Cristian Matei]

Hi,

   What I understand from you now is different, in the sense that you don't have enough spare physical interfaces to meet the number of colours you need, right? Your call, however you must have at least one physical interface, right, in which case you can use sub-interfaces instead of Loopbacks; not saying this is the best call to make, as I'm not aware of the full implementation details which might shift the call on using or not using Loopbacks, just saying that you can use physical sub-interfaces and assign colors to different physical sub-interfaces.

Thanks,

Cristian.

[vin.marco]

I essentially have four interfaces: two are in LACP dedicated to VPN 0 with a single color, while the other two are also in LACP and are used to create the sub-interfaces needed to route the different VPNs I have to implement.

I also considered creating a separate sub-interface for each color, but using loopback interfaces seemed like a cleaner solution.

In your opinion, is it better to use sub-interfaces or loopbacks?

[Cristian Matei]

Hi,

   If the number of physical interfaces is your only reason for thinking on using Loopbacks, I would lean towards using sub-interfaces of the bundle (if the code version you're running supports it, if not upgrade) instead of Loopbacks, for following reasons, both following the already mentioned KISS principle in network design:

1. Adding Loopbacks adds some complexity in your routing, not much, but still, why would I add any additional complexity if not needed?

2. Adding Loopbacks ads some compexity in the SD-WAN control plane functionality, not much, but still, why would I add any additional complexity if not needed? To get a clear picture on this, read here starting with "Information About Implicit ACL on Loopback Interfaces" chapter: https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/system-interface/ios-xe-17/systems-interfaces-book-xe-sdwan/configure-interfaces.html

Thanks,

Cristian.

[Kanan Huseynli]

Hi,

only limitation would be number of TLOC (8 is supported). But I just didn't get purpose of more than two TLOCs (i.e color). You have two mpls transports, you may bind one TLOC to one transport. What is the meaning having more and more?