Back
Lesson 1 of 7

SD-Access Fabric Architecture

Objective

Understand the SD-Access fabric architecture using the LISP control plane and VXLAN data plane, and learn the foundational device configuration required on Border Nodes and the transit underlay so the fabric can build LISP/VXLAN tunnels between sites. This lesson explains why each configuration item matters in production networks — MTU sizing for VXLAN, default-route requirements for LISP Pub/Sub, and the role of Loopback interfaces as VXLAN/LISP locators — and shows hands-on commands and verification. In real deployments, these steps are used when stretching an SD-Access fabric across multiple sites (a “stretched” fabric) or when Border Nodes must form VXLAN tunnels over an MPLS or routed IP transit network.

Topology & Device Table

ASCII topology (exact IPs shown on every interface):

  [BN1]----------------[Transit-RTR]----------------[BN2]
  Lo0:198.51.100.1/32   Gi0/0:203.0.113.2/30   Gi0/1:203.0.113.6/30
  Gi0/1:203.0.113.1/30  Gi0/1:203.0.113.5/30  Lo0:198.51.100.2/32

Detailed view with interfaces:

BN1 (Border Node 1) - Loopback0: 198.51.100.1/32 - GigabitEthernet0/1 (to Transit-RTR): 203.0.113.1/30

Transit-RTR (Underlay / Plain IP transit) - GigabitEthernet0/0 (to BN1): 203.0.113.2/30 - GigabitEthernet0/1 (to BN2): 203.0.113.5/30

BN2 (Border Node 2) - Loopback0: 198.51.100.2/32 - GigabitEthernet0/1 (to Transit-RTR): 203.0.113.6/30

Device Table

DeviceInterfaceIP AddressSubnet MaskRole
BN1Loopback0198.51.100.1255.255.255.255Border Node LISP/VXLAN locator
BN1GigabitEthernet0/1203.0.113.1255.255.255.252Underlay transit link
Transit-RTRGigabitEthernet0/0203.0.113.2255.255.255.252Underlay router to BN1
Transit-RTRGigabitEthernet0/1203.0.113.5255.255.255.252Underlay router to BN2
BN2GigabitEthernet0/1203.0.113.6255.255.255.252Underlay transit link
BN2Loopback0198.51.100.2255.255.255.255Border Node LISP/VXLAN locator

Tip: The IP blocks used here are RFC 5737 documentation addresses (198.51.100.0/24 and 203.0.113.0/24). In production use your assigned addressing plan.

Key Concepts (theory before CLI)

  • LISP (Locator/ID Separation Protocol) control plane: LISP separates endpoint identifiers (EIDs, typically the fabric virtual-network addresses) from routing locators (RLOCs — the Loopback interfaces of Border Nodes). In an SD-Access stretched fabric, LISP provides endpoint-to-locator mapping and advertises reachability between Border Nodes. When LISP Pub/Sub is used, Border Nodes rely on a default route toward upstream for External Border capacity; Pub/Sub reduces per-VN iBGP peering needs.

  • VXLAN data plane: VXLAN encapsulates tenant traffic inside UDP/IP, adding ~50 bytes of overhead. The inner packet preserves VRF and SGT in SD-Access. Because VXLAN increases packet size, the underlay MTU must be sized (MTU > 1550) to prevent fragmentation; otherwise, TCP throughput will be impacted.

  • Border Node Loopback (Loopback0) role: Loopback0 addresses are stable RLOCs used by LISP/VXLAN. The plain IP transit only needs to provide reachability between these loopbacks; VXLAN tunnels are built using these RLOCs.

  • MTU and MSS considerations: VXLAN adds overhead — think of it like adding an extra envelope around a letter. If the underlay path MTU cannot accommodate the envelope, the packet will be fragmented or dropped. A practical mitigation is to set MTU > 1550 and/or adjust TCP MSS on edge-facing interfaces.

  • Production impact: In real data centers and WAN links, multicast support on the underlay matters only if you choose overlay multicast for L2 flooding; otherwise, unicast VXLAN tunnels can be used. Also, LISP Pub/Sub requires consistent control-plane architectures across connected sites.

Step-by-step configuration

We will prepare the underlay connectivity and the Border Node basics (Loopback RLOCs, MTU, default route). Each step shows the commands, reasons, and verification.

Step 1: Configure Loopback0 on Border Nodes (RLOC)

What we are doing: Create persistent RLOC addresses on each Border Node. The Loopback is the stable identifier LISP and VXLAN use for building tunnels. This matters because the transit network must only provide IP reachability to these loopbacks.

BN1# configure terminal
BN1(config)# interface Loopback0
BN1(config-if)# ip address 198.51.100.1 255.255.255.255
BN1(config-if)# exit
BN1(config)# end

BN2# configure terminal
BN2(config)# interface Loopback0
BN2(config-if)# ip address 198.51.100.2 255.255.255.255
BN2(config-if)# exit
BN2(config)# end

What just happened: Each Border Node now owns a /32 Loopback address that will act as the LISP/VXLAN RLOC. A /32 is used to ensure a single stable host route is advertised and reachable. LISP control-plane and VXLAN encapsulation reference these RLOCs to establish tunnels and mapping entries.

Real-world note: In production, Loopback0 must be reachable across the underlay; use dynamic routing or static routes in the transit network to advertise these /32s.

Verify:

BN1# show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Loopback0                  198.51.100.1    YES manual up                    up
GigabitEthernet0/1         203.0.113.1     YES manual up                    up
BN1# 

BN2# show ip interface brief
Interface                  IP-Address      OK? Method Status                Protocol
Loopback0                  198.51.100.2    YES manual up                    up
GigabitEthernet0/1         203.0.113.6     YES manual up                    up
BN2#


<div class="topology-diagram">
<img src="data:image/svg+xml;base64,PD9wbGFudHVtbCAxLjIwMjYuMT8+PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiBjb250ZW50U3R5bGVUeXBlPSJ0ZXh0L2NzcyIgZGF0YS1kaWFncmFtLXR5cGU9Ik5XRElBRyIgaGVpZ2h0PSIyMjlweCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ibm9uZSIgc3R5bGU9IndpZHRoOjYyMHB4O2hlaWdodDoyMjlweDtiYWNrZ3JvdW5kOiNGRkZGRkY7IiB2ZXJzaW9uPSIxLjEiIHZpZXdCb3g9IjAgMCA2MjAgMjI5IiB3aWR0aD0iNjIwcHgiIHpvb21BbmRQYW49Im1hZ25pZnkiPjxkZWZzLz48Zz48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMiIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI5Ny42MTcyIiB4PSIxNjkuMTUwNCIgeT0iMTYuMTM4NyI+VHJhbnNpdF9OZXR3b3JrPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjIzNS42NjQxIiB4PSIzMS4xMDM1IiB5PSIzMC4xMDc0Ij5QbGFpbiBJUCB0cmFuc2l0IChwb2ludC10by1wb2ludCAvMzAgbGlua3MpPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjEwMC4xMTMzIiB4PSIxNjYuNjU0MyIgeT0iMTcxLjMyNjIiPlZURVBfTG9vcGJhY2tzPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI2MS43Njc2IiB4PSI1IiB5PSIxODUuMjk0OSI+MTAuMS4xLjAvMjQgKFZURVAgTG9vcGJhY2sgLzMyIGFkZHJlc3Nlcyk8L3RleHQ+PHJlY3QgZmlsbD0iI0UyRTJGMCIgaGVpZ2h0PSI1IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7IiB3aWR0aD0iMzQwLjUzNzYiIHg9IjI3MS43Njc2IiB5PSIxNi40Njg4Ii8+PHJlY3QgZmlsbD0iI0UyRTJGMCIgaGVpZ2h0PSI1IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7IiB3aWR0aD0iMzQwLjUzNzYiIHg9IjI3MS43Njc2IiB5PSIxNzEuNjU2MyIvPjxwYXRoIGQ9Ik0zMjkuMzU3NCwyMS40Njg4IEwzMjkuMzU3NCw3Ny4wNzgxIiBmaWxsPSJub25lIiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7Ii8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iOTEuMTc5NyIgeD0iMjgzLjc2NzYiIHk9IjQ0LjE3OTIiPjE5Mi4xNjguMTAuMS8zMDwvdGV4dD48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSIyOS4yODMyIiB4PSIyODMuNzY3NiIgeT0iNTYuOTgzOSI+R2kwLzA8L3RleHQ+PHBhdGggZD0iTTMyOS4zNTc0LDExMS4wNDY5IEwzMjkuMzU3NCwxNzEuNjU2MyIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjYzLjE4NTUiIHg9IjI5Ny43NjQ2IiB5PSIxMzguNzU3MyI+MTAuMS4xLjEvMzI8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNTIuNzI4IiB4PSIyOTcuNzY0NiIgeT0iMTUxLjU2MiI+TG9vYmFjazA8L3RleHQ+PHBhdGggZD0iTTQ0MC41MzcxLDIxLjQ2ODggTDQ0MC41MzcxLDc3LjA3ODEiIGZpbGw9Im5vbmUiIHN0eWxlPSJzdHJva2U6IzE4MTgxODtzdHJva2Utd2lkdGg6MTsiLz48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI5MS4xNzk3IiB4PSIzOTQuOTQ3MyIgeT0iNDQuMTc5MiI+MTkyLjE2OC4xMC42LzMwPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI5LjI4MzIiIHg9IjM5NC45NDczIiB5PSI1Ni45ODM5Ij5HaTAvMDwvdGV4dD48cGF0aCBkPSJNNDQwLjUzNzEsMTExLjA0NjkgTDQ0MC41MzcxLDE3MS42NTYzIiBmaWxsPSJub25lIiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7Ii8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNjMuMTg1NSIgeD0iNDA4Ljk0NDMiIHk9IjEzOC43NTczIj4xMC4xLjEuMi8zMjwvdGV4dD48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI1Mi43MjgiIHg9IjQwOC45NDQzIiB5PSIxNTEuNTYyIj5Mb29iYWNrMDwvdGV4dD48cGF0aCBkPSJNNTU1LjIxNjEsMjEuNDY4OCBMNTU1LjIxNjEsNzcuMDc4MSIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9Ijk4LjE3ODIiIHg9IjUwNi4xMjciIHk9IjQ0LjE3OTIiPjE5Mi4xNjguMTAuMTAvMzA8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iMjkuMjgzMiIgeD0iNTA2LjEyNyIgeT0iNTYuOTgzOSI+R2kwLzA8L3RleHQ+PHBhdGggZD0iTTU1NS4yMTYxLDExMS4wNDY5IEw1NTUuMjE2MSwxNzEuNjU2MyIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjYzLjE4NTUiIHg9IjUyMy42MjMzIiB5PSIxMzguNzU3MyI+MTAuMS4xLjMvMzI8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNTIuNzI4IiB4PSI1MjMuNjIzMyIgeT0iMTUxLjU2MiI+TG9vYmFjazA8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSIzMDQuOTM1NSIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjMxNC45MzU1IiB5PSI5OC4yMTY4Ij5CTjE8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSI0MTYuMTE1MiIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjQyNi4xMTUyIiB5PSI5OC4yMTY4Ij5CTjI8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSI1MzAuNzk0MiIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjU0MC43OTQyIiB5PSI5OC4yMTY4Ij5CTjM8L3RleHQ+PD9wbGFudHVtbC1zcmMgVFN6RDJ1OG03MFJta3ZfWVpvU3hnRGlDQVE5QjQxNjRVOTBrNlI1SU9ZWVJrODY3eUJpdHRxM0FpU2w2Vml5MzNzeW9Ial9taUcxdWhYZkg1djNLYjRrYzdqN3V4bHUwUTlSTGtQSW0xcGlrQVVEbVphNEQ0Zm5BQ0F2UzlUcC0wZHcwZTZJeWEya3hwbnVZM0JUUDBUdUkzdVNSM29DRlF2bG80cUMtaWsteEtIRUozZlRxT0VuNmx4b3JQWmtsb0o1LU44SWVkbEhMb0YtUE5PQy1vMlRoUzNlQzR6TzNvSUhwdXlXWGhXVUliRWphNXBIbDczMG51NjA5MW1rdWpUZWw/PjwvZz48L3N2Zz4=" alt="Network Topology Diagram" style="max-width:100%;height:auto;background:#fff;padding:16px;border:1px solid #e5e7eb;border-radius:8px;" />
</div>

cisco
BN1# configure terminal
BN1(config)# interface GigabitEthernet0/1
BN1(config-if)# description Transit-to-Transit-RTR
BN1(config-if)# ip address 203.0.113.1 255.255.255.252
BN1(config-if)# no shutdown
BN1(config-if)# mtu 1600
BN1(config-if)# exit
BN1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.2
BN1(config)# end

Transit-RTR# configure terminal
Transit-RTR(config)# interface GigabitEthernet0/0
Transit-RTR(config-if)# ip address 203.0.113.2 255.255.255.252
Transit-RTR(config-if)# no shutdown
Transit-RTR(config-if)# mtu 1600
Transit-RTR(config-if)# exit
Transit-RTR(config)# interface GigabitEthernet0/1
Transit-RTR(config-if)# ip address 203.0.113.5 255.255.255.252
Transit-RTR(config-if)# no shutdown
Transit-RTR(config-if)# mtu 1600
Transit-RTR(config-if)# exit
Transit-RTR(config)# ip route 198.51.100.1 255.255.255.255 203.0.113.1
Transit-RTR(config)# ip route 198.51.100.2 255.255.255.255 203.0.113.6
Transit-RTR(config)# end

BN2# configure terminal
BN2(config)# interface GigabitEthernet0/1
BN2(config-if)# description Transit-to-Transit-RTR
BN2(config-if)# ip address 203.0.113.6 255.255.255.252
BN2(config-if)# no shutdown
BN2(config-if)# mtu 1600
BN2(config-if)# exit
BN2(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.5
BN2(config)# end

What just happened: All transit interfaces are up with MTU sized to 1600 (>1550 as required for VXLAN). Static routes on the Transit-RTR point to each Border Node Loopback /32 so that plain IP reachability exists between RLOCs. Border Nodes have a default route toward the transit router to reach external networks and for LISP Pub/Sub default-route dependency.

Real-world note: In production you will typically use an IGP (e.g., OSPF) for underlay reachability. Static routes are used here for simplicity and clarity in a lab.

Verify:

BN1# show ip route 198.51.100.0
Routing entry for 198.51.100.0/32
  Known via "static", distance 1, metric 0
  * 198.51.100.1/32 is directly connected, Loopback0
BN1# show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is GigabitEthernet, address is xxxx.xxxx.xxxx (bia xxxx.xxxx.xxxx)
  Description: Transit-to-Transit-RTR
  MTU 1600 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
  Internet address is 203.0.113.1/30
BN1#

Transit-RTR# show ip route
Codes: C - connected, S - static, R - RIP, O - OSPF, etc.
S    198.51.100.1/32 [1/0] via 203.0.113.1
S    198.51.100.2/32 [1/0] via 203.0.113.6
C    203.0.113.2/30 is directly connected, GigabitEthernet0/0
C    203.0.113.5/30 is directly connected, GigabitEthernet0/1
Transit-RTR#


<div class="topology-diagram">
<img src="data:image/svg+xml;base64,PD9wbGFudHVtbCAxLjIwMjYuMT8+PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hsaW5rIiBjb250ZW50U3R5bGVUeXBlPSJ0ZXh0L2NzcyIgZGF0YS1kaWFncmFtLXR5cGU9Ik5XRElBRyIgaGVpZ2h0PSIyMjlweCIgcHJlc2VydmVBc3BlY3RSYXRpbz0ibm9uZSIgc3R5bGU9IndpZHRoOjYyMHB4O2hlaWdodDoyMjlweDtiYWNrZ3JvdW5kOiNGRkZGRkY7IiB2ZXJzaW9uPSIxLjEiIHZpZXdCb3g9IjAgMCA2MjAgMjI5IiB3aWR0aD0iNjIwcHgiIHpvb21BbmRQYW49Im1hZ25pZnkiPjxkZWZzLz48Zz48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMiIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI5Ny42MTcyIiB4PSIxNjkuMTUwNCIgeT0iMTYuMTM4NyI+VHJhbnNpdF9OZXR3b3JrPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjIzNS42NjQxIiB4PSIzMS4xMDM1IiB5PSIzMC4xMDc0Ij5QbGFpbiBJUCB0cmFuc2l0IChwb2ludC10by1wb2ludCAvMzAgbGlua3MpPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjEwMC4xMTMzIiB4PSIxNjYuNjU0MyIgeT0iMTcxLjMyNjIiPlZURVBfTG9vcGJhY2tzPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI2MS43Njc2IiB4PSI1IiB5PSIxODUuMjk0OSI+MTAuMS4xLjAvMjQgKFZURVAgTG9vcGJhY2sgLzMyIGFkZHJlc3Nlcyk8L3RleHQ+PHJlY3QgZmlsbD0iI0UyRTJGMCIgaGVpZ2h0PSI1IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7IiB3aWR0aD0iMzQwLjUzNzYiIHg9IjI3MS43Njc2IiB5PSIxNi40Njg4Ii8+PHJlY3QgZmlsbD0iI0UyRTJGMCIgaGVpZ2h0PSI1IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7IiB3aWR0aD0iMzQwLjUzNzYiIHg9IjI3MS43Njc2IiB5PSIxNzEuNjU2MyIvPjxwYXRoIGQ9Ik0zMjkuMzU3NCwyMS40Njg4IEwzMjkuMzU3NCw3Ny4wNzgxIiBmaWxsPSJub25lIiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7Ii8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iOTEuMTc5NyIgeD0iMjgzLjc2NzYiIHk9IjQ0LjE3OTIiPjE5Mi4xNjguMTAuMS8zMDwvdGV4dD48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSIyOS4yODMyIiB4PSIyODMuNzY3NiIgeT0iNTYuOTgzOSI+R2kwLzA8L3RleHQ+PHBhdGggZD0iTTMyOS4zNTc0LDExMS4wNDY5IEwzMjkuMzU3NCwxNzEuNjU2MyIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjYzLjE4NTUiIHg9IjI5Ny43NjQ2IiB5PSIxMzguNzU3MyI+MTAuMS4xLjEvMzI8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNTIuNzI4IiB4PSIyOTcuNzY0NiIgeT0iMTUxLjU2MiI+TG9vYmFjazA8L3RleHQ+PHBhdGggZD0iTTQ0MC41MzcxLDIxLjQ2ODggTDQ0MC41MzcxLDc3LjA3ODEiIGZpbGw9Im5vbmUiIHN0eWxlPSJzdHJva2U6IzE4MTgxODtzdHJva2Utd2lkdGg6MTsiLz48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI5MS4xNzk3IiB4PSIzOTQuOTQ3MyIgeT0iNDQuMTc5MiI+MTkyLjE2OC4xMC42LzMwPC90ZXh0Pjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI5LjI4MzIiIHg9IjM5NC45NDczIiB5PSI1Ni45ODM5Ij5HaTAvMDwvdGV4dD48cGF0aCBkPSJNNDQwLjUzNzEsMTExLjA0NjkgTDQ0MC41MzcxLDE3MS42NTYzIiBmaWxsPSJub25lIiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjE7Ii8+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNjMuMTg1NSIgeD0iNDA4Ljk0NDMiIHk9IjEzOC43NTczIj4xMC4xLjEuMi8zMjwvdGV4dD48dGV4dCBmaWxsPSIjMDAwMDAwIiBmb250LWZhbWlseT0ic2Fucy1zZXJpZiIgZm9udC1zaXplPSIxMSIgbGVuZ3RoQWRqdXN0PSJzcGFjaW5nIiB0ZXh0TGVuZ3RoPSI1Mi43MjgiIHg9IjQwOC45NDQzIiB5PSIxNTEuNTYyIj5Mb29iYWNrMDwvdGV4dD48cGF0aCBkPSJNNTU1LjIxNjEsMjEuNDY4OCBMNTU1LjIxNjEsNzcuMDc4MSIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9Ijk4LjE3ODIiIHg9IjUwNi4xMjciIHk9IjQ0LjE3OTIiPjE5Mi4xNjguMTAuMTAvMzA8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iMjkuMjgzMiIgeD0iNTA2LjEyNyIgeT0iNTYuOTgzOSI+R2kwLzA8L3RleHQ+PHBhdGggZD0iTTU1NS4yMTYxLDExMS4wNDY5IEw1NTUuMjE2MSwxNzEuNjU2MyIgZmlsbD0ibm9uZSIgc3R5bGU9InN0cm9rZTojMTgxODE4O3N0cm9rZS13aWR0aDoxOyIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjExIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjYzLjE4NTUiIHg9IjUyMy42MjMzIiB5PSIxMzguNzU3MyI+MTAuMS4xLjMvMzI8L3RleHQ+PHRleHQgZmlsbD0iIzAwMDAwMCIgZm9udC1mYW1pbHk9InNhbnMtc2VyaWYiIGZvbnQtc2l6ZT0iMTEiIGxlbmd0aEFkanVzdD0ic3BhY2luZyIgdGV4dExlbmd0aD0iNTIuNzI4IiB4PSI1MjMuNjIzMyIgeT0iMTUxLjU2MiI+TG9vYmFjazA8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSIzMDQuOTM1NSIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjMxNC45MzU1IiB5PSI5OC4yMTY4Ij5CTjE8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSI0MTYuMTE1MiIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjQyNi4xMTUyIiB5PSI5OC4yMTY4Ij5CTjI8L3RleHQ+PHJlY3QgZmlsbD0iI0YxRjFGMSIgaGVpZ2h0PSIzMy45Njg4IiBzdHlsZT0ic3Ryb2tlOiMxODE4MTg7c3Ryb2tlLXdpZHRoOjAuNTsiIHdpZHRoPSI0NC44NDM4IiB4PSI1MzAuNzk0MiIgeT0iNzcuMDc4MSIvPjx0ZXh0IGZpbGw9IiMwMDAwMDAiIGZvbnQtZmFtaWx5PSJzYW5zLXNlcmlmIiBmb250LXNpemU9IjEyIiBsZW5ndGhBZGp1c3Q9InNwYWNpbmciIHRleHRMZW5ndGg9IjI0Ljg0MzgiIHg9IjU0MC43OTQyIiB5PSI5OC4yMTY4Ij5CTjM8L3RleHQ+PD9wbGFudHVtbC1zcmMgVFN6RDJ1OG03MFJta3ZfWVpvU3hnRGlDQVE5QjQxNjRVOTBrNlI1SU9ZWVJrODY3eUJpdHRxM0FpU2w2Vml5MzNzeW9Ial9taUcxdWhYZkg1djNLYjRrYzdqN3V4bHUwUTlSTGtQSW0xcGlrQVVEbVphNEQ0Zm5BQ0F2UzlUcC0wZHcwZTZJeWEya3hwbnVZM0JUUDBUdUkzdVNSM29DRlF2bG80cUMtaWsteEtIRUozZlRxT0VuNmx4b3JQWmtsb0o1LU44SWVkbEhMb0YtUE5PQy1vMlRoUzNlQzR6TzNvSUhwdXlXWGhXVUliRWphNXBIbDczMG51NjA5MW1rdWpUZWw/PjwvZz48L3N2Zz4=" alt="Network Topology Diagram" style="max-width:100%;height:auto;background:#fff;padding:16px;border:1px solid #e5e7eb;border-radius:8px;" />
</div>

cisco
BN1# configure terminal
BN1(config)# ip tcp adjust-mss 1450
BN1(config)# end

BN2# configure terminal
BN2(config)# ip tcp adjust-mss 1450
BN2(config)# end

What just happened: The global TCP MSS adjustment will rewrite the Maximum Segment Size option in TCP SYN packets to 1450 bytes so that when VXLAN (~50 bytes) and other headers are added, the post-encapsulation packet fits within the underlay MTU. This is a practical mitigation when some path segments cannot be set to MTU > 1550.

Real-world note: Use MSS tuning carefully — it affects TCP only, not UDP. Where possible, setting MTU end-to-end is preferred.

Verify:

BN1# show running-config | include ip tcp adjust-mss
ip tcp adjust-mss 1450
BN1#

Step 4: Configure domain and default-route considerations for LISP Pub/Sub

What we are doing: LISP Pub/Sub mode requires Border Nodes in external border role to have a default route toward upstream. Configure the domain name (use lab domain) and ensure a default route exists. This step satisfies the Pub/Sub requirement that the device has a 0.0.0.0/0 route for proper External Border functionality.

BN1# configure terminal
BN1(config)# ip domain-name lab.nhprep.com
BN1(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.2
BN1(config)# end

BN2# configure terminal
BN2(config)# ip domain-name lab.nhprep.com
BN2(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.5
BN2(config)# end

What just happened: The domain name is set to lab.nhprep.com (useful for AAA, certificates, and consistent naming). Each Border Node has a default route toward the transit router. For LISP Pub/Sub External Border operation, the presence of a default route toward upstream is required so external prefixes can be managed correctly.

Real-world note: In production, the default route often comes from an upstream edge firewall or Internet/MPLS provider via BGP. For lab clarity, we used static default routes.

Verify:

BN1# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0
  Known via "static", distance 1, metric 0, best
  * 0.0.0.0/0 is directly connected via 203.0.113.2
BN1# show running-config | include ip domain-name
ip domain-name lab.nhprep.com
BN1#

Verification Checklist

  • Check 1: Loopback0 RLOCs are up on both Border Nodes.

    • Verify with show ip interface brief on BN1 and BN2; expect Loopback0 with the configured /32 and status up/up.

  • Check 2: Transit underlay has reachability between Border Node loopbacks.

    • On Transit-RTR, show ip route should contain static routes to 198.51.100.1 and 198.51.100.2 via the appropriate next hops.

  • Check 3: MTU and TCP MSS adjustments are present.

    • On devices, show interfaces GigabitEthernet0/1 should report MTU 1600 bytes.
    • show running-config | include ip tcp adjust-mss should show ip tcp adjust-mss 1450.

  • Check 4: Default route exists for LISP Pub/Sub external Border behavior.

    • show ip route 0.0.0.0 should show a static/default route pointing to the transit router.

Common Mistakes

SymptomCauseFix
Border Nodes cannot form VXLAN/LISP tunnels (no control-plane adjacencies)Loopback RLOCs not reachable across the transitVerify IPs on transit links and static/IGP routes; ensure transit MTU and no ACLs blocking UDP encapsulation
Fragmentation or application performance issuesUnderlay MTU too small for VXLAN overheadIncrease MTU (>1550) on underlay links or configure ip tcp adjust-mss on edges
LISP Pub/Sub Border not functioning for external routesNo default route (0.0.0.0/0) present on Border NodeAdd default route to upstream as required for External Border in Pub/Sub mode
Inconsistent domain names or certificatesDomain not configured uniformly (lab.nhprep.com required by some services)Configure ip domain-name lab.nhprep.com on relevant devices

Key Takeaways

  • The SD-Access stretched fabric relies on a clear separation: LISP as the control plane (mapping EIDs to RLOCs) and VXLAN as the data plane (encapsulating traffic between RLOCs). Think of LISP as the phone book and VXLAN as the postal service that uses addresses from that book.
  • Border Node Loopback0 addresses are critical; they are the RLOCs that the underlay must reach. Ensure persistent /32 loopbacks and advertise them across the transit.
  • VXLAN adds approximately 50 bytes of overhead — ensure underlay MTU > 1550 and/or apply TCP MSS adjustments (e.g., ip tcp adjust-mss 1450) to prevent fragmentation.
  • For LISP Pub/Sub External Border behavior, a default route (0.0.0.0/0) toward upstream is required. In production, this typically comes from an edge BGP peer or upstream router.
  • In real networks, use an IGP for underlay reachability, ensure consistent MTU across the path, and confirm that all sites participating in SDA Transit use the same control-plane architecture (Pub/Sub or legacy LISP/BGP).

Final tip: Always validate underlay reachability and MTU prior to enabling the SDA overlay. If the underlay is healthy, LISP and VXLAN will have a solid foundation to build the fabric tunnels reliably.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security