SD-Access Underlay: Manual vs LAN Automation

Before an SD-Access fabric can do anything clever - before LISP, before VXLAN, before a single policy - it needs one boring, rock-solid thing underneath it: an IP network where every fabric node can reach every other fabric node's loopback. That is the underlay, and it is the part of SD-Access that is not magic. It is just a well-built IGP.

This article covers what the underlay is, the two ways to build it (manual and LAN Automation), and why the choice matters. It is an honest concept-and-components piece: a full SD-Access fabric requires Cisco Catalyst Center, which a home lab does not have, so we are clear throughout about what needs the controller and what is plain networking you can verify yourself. For the wider context, see the network virtualization pillar.

The planes of SD-Access

SD-Access separates the network into four planes, and the underlay lives beneath all of them. It is worth having the whole model in mind, because every article in this series touches one of these:

Management plane

Cisco Catalyst Center. Provisions and operates the fabric. This is the part you cannot lab without the appliance.

Control plane

LISP. Maps endpoint identity to location. Runnable standalone on IOS XE - real captures exist.

Data plane

VXLAN. Encapsulates endpoint traffic across the fabric, carrying the VNI and the SGT.

Policy plane

TrustSec / SGTs. Segmentation by security group, independent of IP address.

The underlay sits beneath all four. It is the plain IP transport that carries the LISP control messages, the VXLAN-encapsulated data, and everything else. If the underlay is not solid, nothing above it works, and no amount of Catalyst Center will save you.

What the underlay must provide

The requirements are refreshingly simple:

Loopback reachability. Every fabric node has a loopback, and every node must be able to reach every other node's loopback. VXLAN tunnels and LISP sessions are built loopback-to-loopback.
Low convergence. When a link fails, the underlay must reconverge fast, because the fabric overlay depends on it.
A large enough MTU. VXLAN adds 50 bytes of encapsulation. The underlay must carry jumbo frames (9100 bytes is the Cisco recommendation) so a full-size endpoint frame plus VXLAN overhead does not fragment. This is the single most common underlay mistake - forget the MTU and everything looks fine until a large packet silently drops.
Nothing else. The underlay carries no endpoint traffic directly. Endpoints live in the overlay. The underlay only ever carries fabric-node-to-fabric-node traffic.

Manual underlay vs LAN Automation

Manual underlay

You build the IGP yourself - your choice of protocol, your addressing, your design. Catalyst Center then discovers the devices and provisions the fabric on top. Full control, more work.

LAN Automation

Catalyst Center builds the underlay for you - zero-touch. It PXE-boots new switches, assigns addressing from a pool, and configures IS-IS as the underlay IGP. Fast, consistent, opinionated.

Why LAN Automation uses IS-IS

This surprises people who expected OSPF. LAN Automation provisions IS-IS, and the reasons are sound:

IS-IS runs directly over Layer 2 (CLNS), not inside IP. That means it can form adjacencies and exchange topology before the IP addressing is fully configured - which is exactly what you need during a zero-touch, PXE-boot provisioning flow where the device does not yet have its addresses.
IS-IS is transport-agnostic. It carries IPv4 and IPv6 reachability as TLVs in the same protocol, so a dual-stack underlay is one IGP, not two.
It scales cleanly and has a long service-provider pedigree for exactly this kind of flat, fast underlay.

If you build the underlay manually you can use OSPF, EIGRP, or IS-IS - Catalyst Center does not care, it just needs loopback reachability. But if you let LAN Automation build it, you get IS-IS, and you should understand it. (IS-IS fundamentals are worth a refresher if you have only ever run OSPF; the concepts map closely.)

What you can verify without Catalyst Center

This is where we are honest about the lab. You cannot build an SD-Access fabric in CML - there is no Catalyst Center to provision it. But the underlay is plain networking, and every piece of it is verifiable on real IOS XE:

The IGP. An IS-IS or OSPF underlay with loopback reachability is a standard lab you can build and verify with show ip route and loopback-to-loopback pings. Nothing about it is SD-Access-specific.
The MTU. show interface | include MTU and a large ping with the do-not-fragment bit (ping x.x.x.x size 9000 df-bit) prove the underlay carries jumbo frames - the exact test that catches the number-one underlay mistake.
Fast convergence. BFD, tuned IGP timers - all standard, all verifiable.

What you cannot do without Catalyst Center is the LAN Automation flow itself (the PXE-boot, the pool assignment, the automatic IS-IS provisioning) and the fabric overlay that sits on top. We will not show you invented Catalyst Center screenshots. Where a component is real and standalone - like the underlay IGP - build it and verify it. Where it needs the controller, we describe the architecture and are clear that is what we are doing.

Underlay design principles

Point-to-point routed links only. No spanning tree, no Layer 2 in the underlay. Every fabric-node interconnect is a routed /30 or /31. The overlay handles all the Layer 2 semantics; the underlay is pure routing.
A loopback per node, advertised as a /32, reachable everywhere. This is the fabric's addressing anchor.
Jumbo MTU everywhere. 9100 bytes. Set it and test it before you provision the fabric.
Fast convergence. BFD on the underlay links. The overlay's resilience is capped by the underlay's convergence time.
Keep it dumb. The underlay should be the simplest possible IP network. All the intelligence belongs in the overlay. Resist the urge to add policy, QoS complexity, or filtering in the underlay - it makes the fabric harder to reason about for no benefit.

Key takeaways

The underlay is the plain IP network beneath the fabric - loopback-to-loopback reachability for every node, and nothing else. It is not magic; it is a well-built IGP.
SD-Access has four planes: management (Catalyst Center), control (LISP), data (VXLAN), policy (TrustSec/SGT). The underlay sits beneath all four.
Build it manually (any IGP, full control) or with LAN Automation (zero-touch, Catalyst Center provisions IS-IS).
LAN Automation uses IS-IS because it runs over Layer 2, works before IP is configured, and carries IPv4/IPv6 in one protocol - ideal for zero-touch provisioning.
The number-one underlay mistake is MTU. VXLAN adds ~50 bytes; the underlay needs jumbo frames (9100). Test with a large DF-bit ping.
The underlay IGP is fully labbable and verifiable on IOS XE. The LAN Automation flow and the fabric overlay need Catalyst Center - we say so rather than faking it.

Next: SD-Access fabric roles - edge, border, control plane, and fabric in a box. The full cluster index lives on the network virtualization pillar.