Cisco SD-WAN vEdge Onboarding

Lessons Discussion
85

Hello Mathias

This looks like a high availability configuration that you’re setting up. You can take a look at this Cisco documentation that gives you detailed information about HA deployments:

From this document, I can give you a high level summary of how you can proceed:

Cisco SD-WAN’s affinity feature allows vEdge devices to intelligently manage control connections to multiple vSmart controllers deployed across different data centers. This ensures optimized connectivity, load balancing, and redundancy within a distributed network architecture.

Controller Group Identifiers
Each vSmart controller is assigned a controller group identifier using the controller-group-id command. These IDs, ranging from 0 to 100, categorize vSmarts by location or function—for example, assigning group 1 to controllers in Data Center 1 (DC1) and group 2 to those in Data Center 2 (DC2). This distinction forms the basis for affinity-based connection preferences on the vEdges.

Configuring Affinity on vEdge
On the vEdge device, the system controller-group-list command defines which vSmart groups the device is permitted to connect to, and the order sets the preference. For example, listing 1 2 means the vEdge will prefer group 1 over group 2. By default, each tunnel interface aims to establish two control connections, but this behavior can be tailored using max-omp-sessions and max-control-connections. Additionally, you can fine-tune connections by using exclude-controller-group-list on specific interfaces, effectively preventing them from connecting to certain controller groups.

I hope this has been helpful!

Laz

86

Hello, everyone.

I am very early into SD-WAN for ENCOR and Rene + my other resource mention that the vBond Orchestrator needs to have a public IP address.

I’ve asked some people regarding this and I just end up getting more and more confused.

The Cisco Learning Network says

vBond is the only SD-WAN component really need to be reachable with public IP address directly , other controllers such as vManage , vSmart, or even WAN Edges (vEdge & cEdge) can be in private networks.

vBond is responsible to provide public to private IP address mapping to all other components using STUN

What is a STUN server & client?

A STUN (Session Traversal Utilities for NAT) server

allows NAT clients (i.e. IP Phones behind a firewall) to set up phone calls to a VoIP provider hosted outside of the local network.

The STUN server allows clients to find out their public address, the type of NAT they are behind, and the Internet side port associated by the NAT with a particular local port.

This information is used to set up UDP communication between the client and the VoIP provider to establish a call.

The STUN protocol is defined in RFC 3489

The STUN server is contacted on UDP port 3478, however, the server will hint clients to perform tests on alternate IP and port numbers too (STUN servers have two IP addresses). The RFC states that this port and IP are arbitrary.

STUN is enabled on vBond to allow the tunnel interface to discover its public IP address and port number when the vEdge router is located behind a NAT (on vEdge routers only).

It’s not quite clicking for me here. I asked someone personally and they told me thisd:

Public IP address is a bit of a misnomer, there’s quite a few terms that don’t mean what you think they mean in the SDWAN architecture. There can’t be any NAT because the vBond is responsible for performing STUN operations to aid in NAT traversal for the other components and having any kind of address translation in the middle would mess with that process up. vBond doesn’t care whether an IP is public or not, we can run it over private if we have a routable private IP like with MPLS.

The bottom line is, that STUN is there to help the NATed devices figure out what their real IPs are.

ENCOR OCG

NAT detection: The vBond can detect when devices are being placed behind NAT
devices using Session Traversal Utilities for NAT (STUN) [RFC 5389] mechanisms.
Placing a vBond behind a NAT device is not recommended but requires a 1:1 static
NAT if it is placed behind a NAT device

The more I read this, the more confused I get. There aren’t many images regarding this online. Why exactly is NAT problematic here? That’s the first question, which leads to many more.

  1. Why would a vEdge router even be behind NAT
  2. What exactly is STUN and Traversal and how is it relevant here? I’ve read about this online but I don’t think I get it.
  3. The vBond device contains some public to private IP mappings?

I’m not sure if I am going too deep here, I just need a basic understanding for ENCOR. The vBond can probably detect when devices are being placed behind NAT devices? How does all of this work and come together? :smiley:

Thank you.
David

87

Hello David

What is meant by “public address” is indeed a misnomer, I agree with your friend. The statement should read “The vBond should not be assigned an IP address that is NAT translated” or “the vBond should not be placed behind a device performing NAT”. The idea is that the IP address of the vBond should be the same address that the rest of the infrastructure uses to reach it, i.e. no NAT translation. The use of the term “public IP” simply reinforces the idea that in an arrangement where the “public network” being used as the underlay of the SD-WAN infrastructure is indeed the Internet itself (which is probably the most common case), then you would use public IP addresses.

STUN or Session Traversal Utilities for NAT is a set of utilities that can be used to deal with some of the difficulties involved with using NAT. More about it can be found at this RFC 5389 where it is defined.

STUN requires a STUN server, and vBond acts as the STUN server for the rest of the devices. A STUN server cannot reliably perform its function if it is behind NAT. Why? The RFC explains how STUN works, and you can get a definitive answer for this question there.

It is quite common especially in branch offices or home offices, to have an edge router that is behind NAT. If you have a cable or xDSL connection from your local ISP, NAT will definitely be there. You don’t have to have it, but there are situations in which it is desirable (because typically it’s cheaper) and you would need the SD-WAN infrastructure to handle that.

I’ve shared this with you above, and linked to the RFC. I’ll just add that STUN is a set of tools that makes NAT traversal possible by allowing devices behind a NAT to discover their public IP address and port as seen by external servers, enabling peer-to-peer communication over UDP despite the address translation.

Yes, exactly, the vBond orchestrator in Cisco SD-WAN maintains and distributes public-to-private IP address mappings as part of its role as a STUN server. But again, the “public to private” can be misleading. Maybe “outside to inside” mappings is more accurate?

This is probably a bit deeper than you need for the ENCOR exam, but being curious, researching and knowing these things is vital if you want to become a good network engineer.

I hope this has been helpful!

Laz

88

Hello Laz.

Very well explained, I am happy that you can answer literally everything that I ask about :smiley:

Once the vBond discovers that the vEdge is indeed behind NAT (or PAT I should say), how does it allow the communication to work? The vEdge would need to be hole punched somehow, or not?

Thank you.
David

89

Hello David

Glad to hear that it is clear! Of course, I don’t have all the answers immediately. Sometimes, I do further research to ensure that what I’m sharing is correct. I too learn in the process!

When a Cisco vEdge router is behind NAT/PAT, the vBond orchestrator facilitates communication through a combination of STUN protocol and outbound connection initiation.

Since the vEdge router is preconfigured with the address of the vBond orchestrator, it initiates communication by sending STUN requests to vBond. These requests include the vEdge’s private IP and source port. The vBond observes the corresponding public IP and port from which the requests arrive, thereby detecting NAT and learning the vEdge’s translated public address.

The vBond then responds with the detected public IP and port information. Using this information, the vEdge router establishes outbound DTLS or TLS control connections to the vSmart and vManage controllers. These outbound connections allow NAT devices to create and maintain translation state.

As a result, no traditional “hole punching” is required. The process relies on vEdge’s outbound connections to maintain NAT state. This approach ensures NAT transparency without requiring manual port forwarding. The stateful NAT sessions are maintained through regular control plane keepalives and data plane traffic.

I hope this has been helpful!

Laz