Validator: initial discovery and traversal assistance

A router in a box, with nothing but a WAN address

BR-02 has just been installed. It has an IP address on its internet line and a small amount of configuration, and nothing else: it does not know where the Controller (formerly vSmart) or the Manager (formerly vManage) is, and the fabric does not yet know it. It cannot simply be told to connect to 10.255.0.11. Something has to introduce it, check that it is a device that belongs here, and give it the next addresses. That is the Validator, VAL-01 at 10.255.0.12 in the lab.

What the Validator does

Cisco calls this role orchestration. The word is helpful: the Validator arranges the introduction and then stays out of the conversation. The certificates and device lists that decide who is accepted are the subject of a later lesson, so this one treats them as given.

The first steps of a new edge

1. The edge gets a WAN address. It has an address and a route out on the transport, from DHCP or from configuration.
2. It contacts VAL-01. It uses the Validator address or name it knows. This is the only address it needs to start.
3. Mutual authentication. The edge and the Validator check each other's identity.
4. The Validator replies. It sends the addresses of the Controller and the Manager, and the public address the edge appeared from.
5. The edge builds its own connections. It connects to CTRL-01 and to the Manager, each with its own secure connection. The Validator is no longer in the path of any of this.

The Validator's part is short. An edge that fails here usually fails before any other component hears of it, which is why this stage is the first place to look for a router that does not appear.

Why NAT makes this necessary

A branch is often behind a device that translates addresses. The router sees its own private address, but the outside world sees a public address and port. Other routers need the public pair to send tunnel packets. The Validator is a server outside that NAT, so it sees the translated source and reports it. The result later appears in the TLOC (see TLOC components) as the public address and port. This is also why the Validator itself needs an address that devices on the internet side can reach, and not one hidden behind NAT.

Requirements for the Validator itself

• Reachable by every device that needs to join. For internet-connected branches, that normally means a public address or a name that resolves to one.
• Reachable by the Controller and the Manager, which also keep connections to it.
• Trusted identity. It holds a certificate from the same trust as the other components.
• Redundancy where the design needs it. If an edge has a name for the Validator, several addresses can sit behind it. Check your release for how a router uses more than one.

What the router shows

BR-02#show sdwan control connections
PEER TYPE  PEER SYSTEM IP  SITE ID  LOCAL COLOR   STATE
vsmart     10.255.0.11     1        biz-internet  up
vmanage    10.255.0.10     1        biz-internet  up

If the router shows only a Validator line that does not become a Controller or Manager connection, the introduction did not complete. Check the Validator address, the router's route to it, and the authentication details before looking at anything beyond.

What goes wrong at this stage

Mistakes to avoid

• Thinking the Validator must be in the data path or in a branch's routing. It is only contacted for introductions.
• Placing it where branches cannot reach it. Reaching it is the first step, so a good Controller and Manager are of no use if the Validator is out of reach.
• Mixing it up with the Controller because both are controllers in the fabric. The Controller holds routes; the Validator holds nothing the data plane needs.

Test yourself on the Validator