NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

In this lesson you will learn how the Catalyst SD‑WAN data plane builds IPsec tunnels between WAN Edge routers and how BFD is used to monitor path liveness. We will configure a simple two‑edge IPsec data plane (TLOC) between WAN Edge routers, verify the IPSec SAs, and enable BFD to provide sub‑second failure detection for path steering. In production networks this matters because encrypted TLOCs carry tenant VPN traffic across unreliable underlays (Internet, MPLS, LTE) and rapid path failure detection is essential for application QoE and fast failover.

Topology (quick recap of Lesson 1)

This lesson reuses the same Edge devices from Lesson 1. We add a second WAN Edge so you can see a complete IPSec exchange. The only new IPs introduced in this lesson are the public WAN IPs for the point‑to‑point underlay.

ASCII topology (exact interface names and IPs shown):

Edge-A (WAN Edge)

System IP: 10.0.0.1
GigabitEthernet0/0 (public WAN): 198.51.100.1/30
GigabitEthernet0/1 (LAN): 10.1.1.1/24

Edge-B (WAN Edge)

System IP: 10.0.0.2
GigabitEthernet0/0 (public WAN): 198.51.100.2/30
GigabitEthernet0/1 (LAN): 10.2.2.1/24

Simple ASCII diagram:

[Edge-A] SysIP:10.0.0.1                  [Edge-B] SysIP:10.0.0.2
G0/0 198.51.100.1/30  ------------------- 198.51.100.2/30 G0/0
G0/1 10.1.1.1/24                          10.2.2.1/24 G0/1

Tip: The SysIP (10.0.0.x) identifies the WAN Edge inside the SD‑WAN control plane. The public addresses (198.51.100.x) represent the underlay IPs used to form IPsec tunnels (TLOCs).

Key Concepts

TLOC (Transport Locator) and IPSec: In this architecture the data plane uses IPSec to encapsulate traffic between WAN Edge routers. Each WAN Edge advertises one or more TLOCs (a combination of system IP, color, and encapsulation). The underlay uses the public IP to reach peers; the overlay uses session keys (AB/BA) negotiated per peer and per transport.
- In practice: when Edge‑A sends encrypted traffic to Edge‑B it uses the session key "AB"; Edge‑B uses "BA" for return traffic. These session keys are distributed by Controllers via OMP.
Anti‑replay and packet sequence numbers: IPsec assigns sequence numbers and Implements anti‑replay sliding windows. Duplicate or old packets are dropped to prevent replay attacks; when a higher sequence is observed, the window advances.
- In practice: encryption + sequence numbers protect both confidentiality and integrity across NATs.
IKE/IPsec crypto with AES‑GCM (AEAD): AES256‑GCM provides combined encryption and integrity (AEAD). The SD‑WAN data plane uses strong ciphers like AES256‑GCM for confidentiality and authentication of data plane traffic.
- In production: using AEAD reduces separate AH/ESP considerations and simplifies integrity handling across NAT.
BFD for fast path failure detection: BFD provides rapid heartbeat exchanges between peers and is used by the WAN Edge to detect underlay path failure (sub‑second) so that the overlay can steer traffic to alternate TLOCs before TCP/RTP degrade.
- In practice: BFD timers are aggressive (for example, 50 ms) to detect failures within a few hundred milliseconds.

Step-by-step configuration

We will configure both Edge‑A and Edge‑B. Each step shows the purpose, the exact commands, why it matters, and verification with expected output.

Step 1: Configure system IP and interface addressing on both edges

What we are doing: Assign system IP and configure the public underlay and LAN interfaces. The system IP (10.0.0.x) identifies the device inside the SD‑WAN control plane; the public interface IPs are used for IPsec (TLOC) tunnels.

! On Edge-A
configure terminal
hostname Edge-A
interface GigabitEthernet0/0
 description WAN-Public
 ip address 198.51.100.1 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 description LAN
 ip address 10.1.1.1 255.255.255.0
 no shutdown
ip route 0.0.0.0 0.0.0.0 198.51.100.2
exit
! Set system IP (conceptual — SD-WAN control-plane identifier)
! This is an overlay identifier; in real SD-WAN systems this is configured via the SD-WAN configuration mode.
system ip address 10.0.0.1
exit

! On Edge-B
configure terminal
hostname Edge-B
interface GigabitEthernet0/0
 description WAN-Public
 ip address 198.51.100.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 description LAN
 ip address 10.2.2.1 255.255.255.0
 no shutdown
ip route 0.0.0.0 0.0.0.0 198.51.100.1
exit
system ip address 10.0.0.2
exit

What just happened: You created the underlay connectivity between the two edges. The public IPs on G0/0 will be used by the IPsec tunnel endpoints; the system IP is the identifier the SD‑WAN control plane uses to advertise reachability. The default route points packets for unknown destinations at the peer public IP to simulate Internet reachability.

Real-world note: In production, underlay IPs may be NATed, so the validator and NAT traversal behavior is important — SD‑WAN validators discover the public IP and communicate it to the WAN Edge so IPSec can compute integrity over post‑NAT addresses.

Verify:

! On Edge-A
show ip interface brief

Expected output (Edge‑A):

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     198.51.100.1    YES manual up                    up
GigabitEthernet0/1     10.1.1.1        YES manual up                    up
Loopback0              unassigned      YES unset  administratively down down

! On Edge-B
show ip interface brief

Expected output (Edge‑B):

Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0     198.51.100.2    YES manual up                    up
GigabitEthernet0/1     10.2.2.1        YES manual up                    up
Loopback0              unassigned      YES unset  administratively down down

Step 2: Configure IKE (phase 1) and IPsec (phase 2) parameters for the data plane

What we are doing: Create the IKEv2 (or IKEv1 in some deployments) policy, pre‑shared key, and an IPsec transform set that uses AES256 for strong confidentiality and integrity. These crypto profiles establish the session keys (AB/BA) used by the data plane.

! On Edge-A
configure terminal
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
exit
crypto isakmp key Lab@123 address 198.51.100.2
crypto ipsec transform-set SDWAN-TS esp-aes 256 esp-sha-hmac
mode tunnel
exit
crypto map SDWAN-MAP 10 ipsec-isakmp
 set peer 198.51.100.2
 set transform-set SDWAN-TS
 match address 101
exit
access-list 101 permit ip host 10.1.1.1 host 10.2.2.1
interface GigabitEthernet0/0
 crypto map SDWAN-MAP
exit

! On Edge-B
configure terminal
crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
exit
crypto isakmp key Lab@123 address 198.51.100.1
crypto ipsec transform-set SDWAN-TS esp-aes 256 esp-sha-hmac
mode tunnel
exit
crypto map SDWAN-MAP 10 ipsec-isakmp
 set peer 198.51.100.1
 set transform-set SDWAN-TS
 match address 101
exit
access-list 101 permit ip host 10.2.2.1 host 10.1.1.1
interface GigabitEthernet0/0
 crypto map SDWAN-MAP
exit

What just happened: You created matching IKE policies and keys so the two edges can perform the IKE negotiation and establish IPsec SAs. The transform set defines ESP using AES256 and HMAC‑SHA; the crypto map ties the peer and transform to traffic selectors (access list 101), then it is applied to the public interface to encrypt/decapsulate matching traffic.

Real-world note: SD‑WAN controllers normally automate IPsec keying and session key (AB/BA) distribution via OMP. Manual crypto maps illustrate the underlying IPSec behavior but are typically not how the SD‑WAN overlay is provisioned in a managed deployment.

Verify:

! On Edge-A
show crypto isakmp sa

Expected output (Edge‑A):

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
198.51.100.2    198.51.100.1    QM_IDLE        1001    ACTIVE

! On Edge-A
show crypto ipsec sa

Expected output (Edge‑A):

interface: GigabitEthernet0/0
Crypto map tag: SDWAN-MAP, local addr 198.51.100.1

local  ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.2.2.1/255.255.255.255/47/0)
current_peer 198.51.100.2

pkts encrypt: 0, pkts decrypt: 0
pfs state: NONE
    inbound esp sas:
      spi: 0x00000001, transform: esp-aes-256 esp-sha-hmac, in use
    outbound esp sas:
      spi: 0x00000002, transform: esp-aes-256 esp-sha-hmac, in use

Step 3: Enable BFD for the underlay path and tie it to the IP route (fast path monitoring)

What we are doing: Configure BFD neighbors with aggressive timers and attach BFD to the static route that points at the peer underlay IP (simulating the route to the remote site). BFD will detect underlay path failures quickly so the overlay can react.

! On Edge-A
configure terminal
bfd interval 50 min_rx 50 multiplier 3
interface GigabitEthernet0/0
 ip address 198.51.100.1 255.255.255.252
 bfd interval 50 min_rx 50 multiplier 3
exit
! Attach BFD to the static route pointing to the peer to monitor that path
ip route 10.2.2.0 255.255.255.0 198.51.100.2 bfd
exit

! On Edge-B
configure terminal
bfd interval 50 min_rx 50 multiplier 3
interface GigabitEthernet0/0
 ip address 198.51.100.2 255.255.255.252
 bfd interval 50 min_rx 50 multiplier 3
exit
ip route 10.1.1.0 255.255.255.0 198.51.100.1 bfd
exit

What just happened: BFD sessions are configured on the underlay interfaces with 50 ms transmit/receive intervals and a multiplier of 3, meaning the session will be declared down after ~150 ms of missed packets. Attaching BFD to the static route ensures the route is withdrawn if the BFD session fails, which triggers the overlay (or device routing) to prefer alternate TLOCs.

Real-world note: SD‑WAN uses BFD per‑TLOC for rapid detection — configured timers must balance sensitivity and false positives. In high‑loss links you may need higher intervals.

Verify:

! On Edge-A
show bfd neighbors

Expected output (Edge‑A):

Peer IP             Interface            State   Intvl  Rx  Tx  Mult
198.51.100.2        GigabitEthernet0/0   Up      50ms   50  50  3

! On Edge-A
show ip route 10.2.2.0

Expected output (Edge‑A):

Routing entry for 10.2.2.0/24
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 198.51.100.2, from 198.51.100.2, [1/0]
    Route tag 0
    bfd

Step 4: Test traffic across the IPsec tunnel and observe anti‑replay / sequence behavior

What we are doing: Generate ICMP traffic and verify that packets are encrypted (ESP) and the IPsec SAs have sequence number counters. This demonstrates packet encapsulation (ESP) and the anti‑replay sliding window behavior.

! From Edge-A, ping the remote LAN address to force encrypted traffic
ping 10.2.2.1 source 10.1.1.1

What just happened: The ping triggers encryption of packets matching the crypto map access list. The IPsec SAs will increment sequence numbers for each ESP packet; the receiving peer uses sequence numbers to enforce anti‑replay (duplicated or out‑of‑window packets are dropped).

Verify:

! On Edge-A
show crypto ipsec sa

Expected output snippet (showing counters):

interface: GigabitEthernet0/0
Crypto map tag: SDWAN-MAP, local addr 198.51.100.1

local  ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (10.2.2.1/255.255.255.255/47/0)
current_peer 198.51.100.2

pkts encrypt: 10, pkts decrypt: 10
pfs state: NONE
    inbound esp sas:
      spi: 0x00000001, transform: esp-aes-256 esp-sha-hmac, in use
      sequence number: 0x0000000A
    outbound esp sas:
      spi: 0x00000002, transform: esp-aes-256 esp-sha-hmac, in use
      sequence number: 0x0000000B

Real-world note: In SD‑WAN, ESP packets include sequence numbers and anti‑replay windows are CoS‑aware to prevent low priority packets from affecting high priority flows.

Verification Checklist

Check 1: Underlay connectivity — verify public interfaces are up (show ip interface brief) and you can reach the peer (ping 198.51.100.2).
Check 2: IPsec SA established — verify IKE and IPsec SAs (show crypto isakmp sa and show crypto ipsec sa) and confirm packet counters increase when you generate traffic.
Check 3: BFD session is Up and bound to the monitored route — verify BFD neighbors (show bfd neighbors) and the static route shows bfd (show ip route 10.2.2.0).

Common Mistakes

Symptom	Cause	Fix
IPsec SAs not forming	Pre‑shared key mismatch or IKE policy mismatch (encryption/hash/DH group)	Verify IKE policies match on both peers and the same pre‑shared key is configured; adjust `crypto isakmp policy` and `crypto isakmp key` so they match exactly.
Traffic not encrypted (seen in clear)	Crypto map not applied to the physical interface or ACL mismatch	Apply crypto map to correct interface and ensure access list selectors match (source/destination addresses).
BFD shows Down frequently	Aggressive timers with intermittent underlay packet loss leading to false positives	Increase BFD intervals or multiplier to tolerate transient loss; test under load.
Route not removed on BFD down	Static route not attached to BFD or routing protocol not integrated with BFD	Reconfigure route with `bfd` option (e.g., `ip route ... bfd`) or enable BFD for routing protocol neighbor.

Key Takeaways

SD‑WAN data plane uses IPsec (ESP) between WAN Edges; each TLOC is secured with session keys advertised by Controllers. Think of session keys AB/BA as per‑peer per‑transport symmetric keys used to encrypt traffic.
AES256‑GCM (AEAD) is preferred for combined encryption and integrity; sequence numbers and anti‑replay windows protect against replay attacks and preserve packet ordering semantics.
BFD provides sub‑second path liveness detection; attach BFD to routes or routing neighbors so the overlay can quickly steer traffic to alternate TLOCs when a path fails.
In production, controllers and validators automate key distribution, NAT discovery, and TLOC advertisement — manual crypto demonstrates the underlying behavior but production SD‑WAN uses controller‑driven OMP and automated IPSec/TLOC setup.

Warning: In a real SD‑WAN environment you will not manually configure crypto maps; controllers program TLOCs and IPSec profiles. This lab intentionally uses manual crypto to expose the student to the fundamental data plane mechanics.

If you want, the next lesson will show how OMP advertises reachability across VPNs (vpn0, vpn512 and user VPNs) and how the overlay uses these advertisements to forward service VPN traffic across the encrypted TLOCs.

Data Plane — IPsec Tunnels

Objective

Topology (quick recap of Lesson 1)

Key Concepts

Step-by-step configuration

Step 1: Configure system IP and interface addressing on both edges

Step 2: Configure IKE (phase 1) and IPsec (phase 2) parameters for the data plane

Step 3: Enable BFD for the underlay path and tie it to the IP route (fast path monitoring)

Step 4: Test traffic across the IPsec tunnel and observe anti‑replay / sequence behavior

Verification Checklist

Common Mistakes

Key Takeaways