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

Objective

Compare three VPN deployment styles — legacy Crypto Map, Virtual Tunnel Interface (VTI), and DMVPN/DVTI (dynamic VTI) — and configure the VTI-based and spoke-side static-tunnel examples shown in the reference. You will learn the operational differences, how packet flow and routing differ, and how to verify tunnels and BGP peering in a hub-and-spoke design. This matters in production because design choice affects scalability, routing integration, convergence, and operational complexity (for example, whether you can run a dynamic routing protocol over the VPN or need per-peer static mappings).

Real-world scenario: NHPREP operates a central datacenter hub and many remote spokes. We want cryptographically protected tunnels that carry routing (BGP) for automated route distribution. We will compare how a legacy crypto-map approach, a VTI approach, and a hub DVTI approach meet these needs.

Topology (quick recap)

ASCII diagram with exact interfaces and IPs from the reference. All IPs and interface names are taken from the provided material.

Hub (ASA/FTD) and two spokes (Spoke shown with two static tunnels to two hubs):

Hub1 (ASA)

Loopback1: 10.254.1.1/24
Outside (public): 10.0.0.253
Inside: 10.250.0.1/24
VTI virtual addresses for hub: 172.16.1.253

Hub2 (ASA)

Outside (public): 10.0.0.254
VTI virtual address for hub: 172.16.1.254

Spoke (Firewall)

Tunnel1: 172.16.1.5/30 — tunnel destination 10.0.0.253
Tunnel2: 172.16.1.7/30 — tunnel destination 10.0.0.254
routeVTI entries point at 172.16.1.253 and 172.16.1.254 to establish BGP nexthops

ASCII Topology:

[Spoke Firewall]
 Tunnel1: 172.16.1.5/30 --(IPsec)--> Hub1 VTI: 172.16.1.253/32  (peer outside: 10.0.0.253)
 Tunnel2: 172.16.1.7/30 --(IPsec)--> Hub2 VTI: 172.16.1.254/32  (peer outside: 10.0.0.254)

[Hub1 ASA]
 Loopback1: 10.254.1.1/24
 Outside: 10.0.0.253

[Hub2 ASA]
 Outside: 10.0.0.254

Device table (relevant devices and addresses)

Device	Interface	IP address
Hub1 (ASA)	Loopback1	10.254.1.1/24
Hub1 (ASA)	Outside	10.0.0.253
Hub1 (ASA)	Hub VTI	172.16.1.253/32
Hub2 (ASA)	Outside / Hub VTI	10.0.0.254 / 172.16.1.254/32
Spoke (Firewall)	Tunnel1	172.16.1.5/30 (dest 10.0.0.253)
Spoke (Firewall)	Tunnel2	172.16.1.7/30 (dest 10.0.0.254)

Quick Recap

This lesson builds on the base topology and examples from lesson 1. We will not add new devices; instead we will configure the spoke-side IKEv2, IPsec profile, static Tunnel interfaces, routeVTI entries, and BGP neighbor toward the hub virtual IPs. These configurations exist in the reference material and are used to illustrate the practical differences between crypto maps, VTIs, and DVTI.

Key Concepts (theory + packet flow)

Crypto Map (legacy): crypto-maps bind IKE/IPsec policies to an outgoing physical interface and use ACLs to determine which traffic is encrypted. Packet flow: an outbound packet matches the ACL; IKE establishes SA; IPsec encapsulates traffic. Limitation: not a routable interface — routing protocols over a crypto-map require workarounds (next-hop changes or interface-based peers). In production, crypto maps are used for simple site-to-site where routing is static or NAT traversal is not required.
- Analogy: crypto-map is like gluing a sealed envelope to an interface — you can put letters inside it (matching ACLs), but you can't give that envelope an address that routing protocols can use.
Virtual Tunnel Interface (VTI / tunnel interface): creates a routable interface (logical interface) that is permanently up and can be assigned an IP address. Routing protocols (BGP/OSPF) can peer over it just like any routed link. Packet flow: packets are routed to the tunnel IP, then IPsec protection (via an ipsecprofile) encrypts them. In production, VTIs simplify running dynamic routing across VPN tunnels.
- Important behavior: VTIs are "always up" and do not rely on interesting traffic to bring up IKE. Multicast support may vary by platform (ASA/FTD historically lacked multicast over VTI).
Dynamic VTI / DVTI (hub behavior): hubs can create dynamic virtual-access interfaces (per-spoke) using a virtual-template; spokes dynamically create tunnel interfaces. This scales better for many spokes because the hub does not need a static interface per spoke. Packet flow: IKE exchange carries virtual-access assignment; a per-spoke VA interface is created on the hub when the spoke connects.
- In production: use DVTI (hub) when hub must support many spokes with automated routing (BGP). Route exchange via IKEv2 can include the spoke’s tunnel address.
Routing and BGP interplay: For hub-and-spoke topologies carrying many remote networks, BGP is commonly used (eBGP for DVTI hub/spoke examples). eBGP behavior: next-hop is updated and AS_PATH is modified as usual. When using VTIs/DVTI you can peer BGP directly over tunnel addresses (172.16.1.x in the reference).

Tip: Think of a VTI like creating a virtual point-to-point Ethernet between devices — you can put an IP on it and run routing, which removes the ACL-based traffic-selection complexity of crypto-map.

Step-by-step configuration

Step 1: Configure IKEv2 policy and IPsec proposal on the Spoke

What we are doing: Define the IKEv2 policy and IPsec proposal used to authenticate and protect the tunnel. These must match on the hub and the spoke to establish an IKEv2/IPsec SA.

crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384
!
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1
!
crypto ipsec profile VTI
 set ikev2 ipsec-proposal IPSEC_PROP
!

What just happened: The IKEv2 policy chooses the IKE parameters (encryption, integrity, Diffie-Hellman group). The IPsec proposal defines the ESP transforms (AES for encryption, SHA-1 for integrity). The ipsec profile named VTI ties the IKEv2 proposal to an IPsec profile that tunnel interfaces will reference. If hub and spoke parameters mismatch, IKEv2 negotiation will fail.

Real-world note: In production, ensure matching proposals and consider stronger integrity (sha256/384) and key lifetimes per your security policy.

Verify:

show running-config | section crypto ikev2
crypto ikev2 policy 10
 encryption aes-256
 integrity sha384
 group 19
 prf sha384

show running-config | section crypto ipsec
crypto ipsec ikev2 ipsec-proposal IPSEC_PROP
 protocol esp encryption aes
 protocol esp integrity sha-1

show running-config | section crypto ipsec profile
crypto ipsec profile VTI
 set ikev2 ipsec-proposal IPSEC_PROP

Step 2: Configure Tunnel interfaces on the Spoke (static VTI/tunnel interfaces)

What we are doing: Configure Tunnel1 and Tunnel2 interfaces with IP addresses and bind them to the IPsec profile. These create routable tunnel endpoints onto which you can run BGP.

interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!
interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!

What just happened: Each interface TunnelX defines a logical tunnel with its own IP. tunnel protection ipsec profile VTI binds the tunnel to the IPsec profile configured earlier. tunnel source interface outside uses the physical outside interface as the outer source IP for IKE and IPsec. With these tunnel interfaces in place, you can peer routing protocols (BGP) to the hub’s tunnel IPs.

Real-world note: Static Tunnel interfaces are appropriate on spokes connecting to redundant hubs (multiple Tunnel interfaces), but on a hub supporting many spokes, use dynamic virtual-template/DVTI to avoid creating hundreds of static interfaces.

Verify:

show running-config interface Tunnel1
interface Tunnel1
 nameif VTI
 ip address 172.16.1.5 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.253
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

show running-config interface Tunnel2
interface Tunnel2
 nameif VTI2
 ip address 172.16.1.7 255.255.255.254
 tunnel source interface outside
 tunnel destination 10.0.0.254
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Step 3: Configure tunnel-group entries for hub peers and pre-shared keys

What we are doing: Define tunnel-groups for the hub(s) so IKEv2 can authenticate the peer and (for dynamic VTI/hub exchange) provide the virtual-template mapping. Spoke needs a tunnel-group per hub peer IP.

tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
!
tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco
!

What just happened: Each tunnel-group identifies a remote peer by its public IP (10.0.0.253 and 10.0.0.254) and sets the IKEv2 pre-shared keys. During IKEv2 negotiation, the peer's identity (address) maps to the correct tunnel-group, allowing the devices to find the right ipsec profile and other per-peer attributes.

Real-world note: The IKEv2 identity that the peer presents must match what the remote device expects — for ASA/FTD, the tunnel-group peer name and IKEv2 identity must align.

Verify:

show running-config tunnel-group
tunnel-group 10.0.0.253 type ipsec-l2l
tunnel-group 10.0.0.253 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco

tunnel-group 10.0.0.254 type ipsec-l2l
tunnel-group 10.0.0.254 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco

Step 4: Configure routeVTI entries (spoke) to present hub virtual addresses as nexthops for BGP

What we are doing: Add routeVTI entries so the spoke can present and use the hub VTI addresses as reachable next-hops over the static tunnel interfaces. This is required on ASA/FTD-like platforms to route toward the hub’s VTI addresses.

routeVTI 172.16.1.253 255.255.255.255 172.16.1.253 1
routeVTI2 172.16.1.254 255.255.255.255 172.16.1.254 1

What just happened: These commands create host routes to the hub virtual IPs and associate them with the tunnel interfaces (so traffic to 172.16.1.253/254 is sent into the appropriate tunnel). This makes the hub VTI addresses reachable and usable as BGP neighbors. Effectively, they act like static routes pointing into the VTI.

Real-world note: On vendor platforms that support it, route set interface or routeVTI helps the hub learn the spoke’s tunnel endpoint via IKEv2 exchange — this enables dynamic learning of per-spoke tunnel IPs for DVTI hub behavior.

Verify:

show running-config | include routeVTI
routeVTI 172.16.1.253 255.255.255.255 172.16.1.253 1
routeVTI2 172.16.1.254 255.255.255.255 172.16.1.254 1

Step 5: Configure BGP on the Spoke to peer with the hub's VTI addresses

What we are doing: Run BGP on the spoke and establish neighbors with the hub virtual tunnel addresses. This demonstrates how VTIs enable routing protocols to operate over IPsec.

router bgp 65000
 timers bgp 5 15 0
 address-family ipv4 unicast
  neighbor 172.16.1.253 remote-as 65000
  neighbor 172.16.1.253 activate
!

(Note: The reference shows neighbor 172.16.1.253 remote-as65000 — the above uses the same neighbor IP and AS.)

What just happened: BGP is configured to peer with the hub at 172.16.1.253. Because the spoke has a routable Tunnel1 interface and a routeVTI that reaches the hub, the BGP session can establish over the encrypted tunnel. BGP timers are shortened here for faster convergence in the lab.

Real-world note: BGP over VPN simplifies large hub-and-spoke deployments: routes from each spoke can be advertised to the hub and redistributed centrally.

Verify (on Hub):

show bgpsummary
Neighbor        V   AS    MsgRcvd MsgSent   Up/Down
10.254.1.2      4 65001   3166    3167    2d10h
10.254.1.3      4 65002   2427    2436    1d20h

This is the sample output format shown in the reference for the hub; expect to see the peer IPs and AS numbers and the session state.

Verification Checklist

Check 1: IKEv2 and IPsec proposals match on both ends — verify with show running-config sections for crypto ikev2 and crypto ipsec ikev2 ipsec-proposal.
Check 2: Tunnel interfaces exist and have the configured IPs — verify with show running-config interface Tunnel1 and show running-config interface Tunnel2.
Check 3: BGP neighbor established via the tunnel — verify on the hub with show bgpsummary and confirm the neighbor shows as UP with message counts increasing.

Common Mistakes

Symptom	Cause	Fix
BGP neighbor does not come up	IPsec/IKE proposals (encryption/integrity/group) mismatch between hub and spoke	Ensure `crypto ikev2 policy` and `crypto ipsec ikev2 ipsec-proposal` match on both sides
Tunnel interface configured but traffic not routed	Missing routeVTI or route to hub virtual IP	Add `routeVTI` entries so hub VTI addresses are reachable via the tunnel
IKEv2 negotiation fails	Pre-shared key mismatch or tunnel-group identity mismatch	Verify `tunnel-group <peer-ip> ipsec-attributes ikev2 ... pre-shared-key` values match exactly
Tunnel up but routing not exchanged	BGP neighbor pointed at incorrect IP (not the VTI IP)	Confirm BGP neighbor uses the hub VTI IP (e.g., 172.16.1.253) and that routeVTI entry exists

Key Takeaways

Crypto Map is ACL-driven and attaches to physical interfaces — adequate for small static deployments but not ideal when you need routable tunnel endpoints for dynamic routing.
VTI / static tunnel interface gives you a routable logical interface for each tunnel, enabling BGP or other routing protocols to operate normally over IPsec — simplifies routing and troubleshooting.
DVTI / dynamic virtual-template (hub) scales better for hubs supporting many spokes because per-spoke virtual-access interfaces are created dynamically; combined with BGP, this supports large deployments with automated route exchange.
For production hub-and-spoke VPNs carrying routes, prefer VTI/DVTI and run a routing protocol (e.g., BGP) over the tunnel — this provides predictable convergence and simpler route distribution.

Final tip: When designing a production VPN fabric, choose VTIs when routing protocols must run directly over the VPN. Reserve legacy crypto-maps for simple static site-to-site use-cases. DVTI on the hub combined with per-spoke static VTIs on spokes (or dynamic spokes) gives the best scalability and operational model for enterprise hub-and-spoke topologies.

Crypto Map vs VTI vs DMVPN

Objective

Topology (quick recap)

Quick Recap

Key Concepts (theory + packet flow)

Step-by-step configuration

Step 1: Configure IKEv2 policy and IPsec proposal on the Spoke

Step 2: Configure Tunnel interfaces on the Spoke (static VTI/tunnel interfaces)

Step 3: Configure tunnel-group entries for hub peers and pre-shared keys

Step 4: Configure routeVTI entries (spoke) to present hub virtual addresses as nexthops for BGP

Step 5: Configure BGP on the Spoke to peer with the hub's VTI addresses

Verification Checklist

Common Mistakes

Key Takeaways