WAN Edge hardware, virtual edges and platform families

Same job, different boxes

The lab has four WAN Edges: HUB-01 and HUB-02 at the data centres, BR-01 and BR-02 at branches. On the overlay they behave the same way: each has a system IP, a site ID, one or more transport interfaces, and control connections to the Controller (formerly vSmart), the Manager (formerly vManage) and the Validator (formerly vBond). What differs is what they run on, and that decides how many tunnels they can carry, how fast they can encrypt, and where they can be placed. A hub might be a large physical router or a virtual instance. A branch might be a small box or a virtual machine on a host already at the site.

The platform families by where they run

Model names change, and some platforms move to end of sale over time, so this table gives families, not a shopping list. Use the current compatibility and lifecycle information for your release.

IOS XE SD-WAN and Viptela OS

Both fill the WAN Edge role and both join the same fabric. The difference users meet most is the command line. A Viptela OS edge has its own syntax, and an IOS XE one uses IOS XE commands with SD-WAN commands under show sdwan. The lessons in this course use the IOS XE form, as the notice at the top says.

Mode: controller-managed or standalone

An IOS XE router that can run SD-WAN can run in one of two ways: as a normal IOS XE router configured from its own command line, or in the mode where the SD-WAN fabric manages it. Only the second is a WAN Edge in this course. How a router moves between the two, and whether the move is allowed on a given platform, is release-specific, so read the instructions for your model before changing it on a live device.

What to check before choosing a platform

1. Throughput with encryption on. The figure that matters is IPsec throughput with the services the site will use, not the interface speed on the data sheet. Use the vendor's published figures for the exact model and release, and keep headroom.
2. Number of tunnels and TLOCs. A hub terminates one set for each branch TLOC. The count grows with branches and transports, so hubs normally need the bigger platform.
3. Interfaces and transports. Enough WAN ports for the circuits planned, and the right media (Ethernet, cellular module, and so on).
4. Services on the same box. Security, application optimisation or routing features can reduce throughput or need more memory. Confirm they are supported on the model.
5. Software release and licence. The platform must be supported by the release that the Manager and the Controller run, and the licence must cover the features.
6. Where it will live. A cloud site needs a virtual edge; a small office with no rack may need a compact model.

In practice, size from the hub downwards. A hub that runs out of tunnel or throughput capacity limits every branch that connects to it, while a branch that is too small only limits itself.

The same configuration on different platforms

Because the overlay is built from the same pieces, the TLOC, colour and OMP behaviour you learn on one platform carries over to the next (see TLOC components). What does not carry over is capacity, interface names and the list of features. A template that sets GigabitEthernet1 as a tunnel interface fails on a model that numbers its ports differently, and that is one reason templates are written with variables for interface names, not fixed values.

Mistakes to avoid

• Choosing a platform from the port speed. Encrypted throughput with the planned features can be well below the interface speed, especially on small models.
• Assuming a feature seen on one model exists on another. Check by model and release.
• Mixing Viptela OS and IOS XE commands in notes and runbooks, then copying the wrong one onto a router.
• Under-sizing hubs because each branch is small. The hub carries them all.

Test yourself on WAN Edge platforms