FlexVPN Spoke-to-Spoke: The Interface Carrying Your Traffic Is in No Configuration File

FlexVPN is the design where the interesting interfaces do not appear in the configuration. A spoke is configured with one tunnel to the hub and a template; the tunnel to another spoke is built at the moment traffic needs it, cloned from that template, and removed when it is no longer used. Nothing about it was typed, and nothing about it survives a reload.

That is a genuine advantage and it changes how the design is inspected. Reading the running configuration tells you what will be built rather than what has been, and every troubleshooting habit that begins with comparing two configurations has to be replaced with one that begins with looking at what a template produced. The commands are different and the reasoning is different.

This article covers what FlexVPN is assembled from and how it differs from the older design, how a spoke reaches the hub and where its tunnel address comes from, how a direct spoke-to-spoke tunnel is actually built and in which direction, how routes reach the spokes without necessarily running a routing protocol, and the failures that look like negotiation problems and are not. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

The spoke-to-spoke tunnel is cloned from a template at the moment traffic needs it, which is why it appears in no configuration and why the establishment is driven by the far spoke rather than the near one.

What Is FlexVPN Assembled From?

What are the parts?

Four. A point-to-point tunnel interface on each spoke, pointing at the hub, protected by an IPsec profile. A virtual template on the hub and on every spoke, which is a configuration pattern rather than an interface. An IKEv2 profile that ties authentication, identity and the template together. And an authorization policy that decides what each connecting peer is given — an address, routes, other attributes. The interfaces that carry spoke-to-spoke traffic are cloned from the template when needed and belong to none of these four directly.

A Deeper Dive into the Building Blocks

The template is not an interface

A virtual template holds the settings that a cloned interface will receive: the addressing approach, the tunnel mode, the protection profile, the NHRP settings. It is never itself used to carry traffic. On a hub with two hundred spokes there is one template and two hundred cloned interfaces, each one a copy with its own peer.

This has a direct consequence for change control. Editing the template changes what future clones look like and does not change the ones that already exist, so a correction applied during an incident affects nothing until the sessions are reset. That difference catches people, because on an ordinary interface a configuration change takes effect immediately.

The cloned interface, and how to read it

A cloned interface appears in the interface list with a generated name and shows its own counters, state and peer. Its configuration is not in the running configuration, because it was not configured, and the command that displays what it was actually built with is a different one from the usual. That command is the single most useful thing to know when working with this technology.

Reading it answers questions that nothing else will: which template was used, what addressing it inherited, which protection profile is attached, and whether the settings that were expected actually arrived. Where the behaviour of a session differs from the design, the difference is visible there and nowhere else.

! What was actually built, as opposed to what was configured
Hub# show interfaces | include Virtual-Access
Virtual-Access1 is up, line protocol is up
Virtual-Access2 is up, line protocol is up
!
Hub# show derived-config interface Virtual-Access1
interface Virtual-Access1
 ip unnumbered Loopback0
 tunnel source GigabitEthernet0/0
 tunnel mode gre ip
 tunnel destination 203.0.113.11
 tunnel protection ipsec profile FLEX-IPSEC
end

The authorization policy, which is the unfamiliar part

When a peer authenticates, the hub looks up a policy and applies what it finds to that session. The policy can assign a tunnel address from a pool, install routes toward the peer, and set other session attributes. This is an authorization step in the ordinary sense — identity first, then what that identity is entitled to — and it is the mechanism that removes the need to configure anything per spoke on the hub.

The practical effect is that adding a branch requires no hub configuration at all, provided its identity matches an existing rule. On a network that adds sites regularly, that is the difference between a change window and a shipment.

! Authorization: what a connecting peer is given
Hub(config)# aaa new-model
Hub(config)# aaa authorization network FLEX-LIST local
!
Hub(config)# ip local pool FLEX-POOL 10.0.0.100 10.0.0.200
!
Hub(config)# crypto ikev2 authorization policy FLEX-POLICY
Hub(config-ikev2-author-policy)# pool FLEX-POOL
Hub(config-ikev2-author-policy)# route set interface
Hub(config-ikev2-author-policy)# route set access-list FLEX-ROUTES

Identity, and why it replaces a peer list

The hub does not hold a list of spoke addresses. It holds a rule about what an acceptable identity looks like — a name in a particular domain, typically — and any peer presenting one that matches is accepted and authorized. Spokes on dynamic addresses work without special handling because the address was never the identifier.

Getting the identity rule right is therefore the security boundary of the whole design. A rule that matches too broadly accepts peers it should not; a rule that matches too narrowly rejects legitimate branches in a way that looks like a key problem. Both failures present during negotiation and both are diagnosed from the same output.

! Hub: accept any peer whose identity is in our domain
Hub(config)# crypto ikev2 profile FLEX-HUB
Hub(config-ikev2-profile)# match identity remote fqdn domain branch.example.com
Hub(config-ikev2-profile)# identity local fqdn hub.example.com
Hub(config-ikev2-profile)# authentication local pre-share
Hub(config-ikev2-profile)# authentication remote pre-share
Hub(config-ikev2-profile)# keyring local FLEX-KR
Hub(config-ikev2-profile)# aaa authorization group psk list FLEX-LIST FLEX-POLICY
Hub(config-ikev2-profile)# virtual-template 1

The hub's template, in full

Unnumbered addressing from a loopback, so that no subnet needs to be allocated per spoke. The tunnel mode, which must match what the spokes use. The protection profile. And the NHRP settings that make redirection possible, which is what enables the spoke-to-spoke behaviour covered later.

! One template, cloned once per connected spoke
Hub(config)# interface Virtual-Template1 type tunnel
Hub(config-if)# ip unnumbered Loopback0
Hub(config-if)# ip nhrp network-id 1
Hub(config-if)# ip nhrp redirect
Hub(config-if)# tunnel source GigabitEthernet0/0
Hub(config-if)# tunnel mode gre ip
Hub(config-if)# tunnel protection ipsec profile FLEX-IPSEC

How Does a Spoke Reach the Hub, and Where Does Its Address Come From?

What does the spoke configure?

One point-to-point tunnel with the hub as its destination, protected by an IPsec profile, plus a template of its own for the spoke-to-spoke tunnels it will later build. Its tunnel address does not have to be configured: during negotiation the hub can assign one from a pool, and the spoke applies it to the interface. So a branch's entire configuration can be identical to every other branch's apart from its identity and its key.

A Deeper Dive into the Spoke Side

The static tunnel

Point-to-point, destination the hub, protected. It is an ordinary tunnel in every respect and behaves like one: it is up when the hub is routable, which as established elsewhere says nothing about whether negotiation succeeded. It exists to carry the spoke's traffic to the hub and to carry the resolution messages that build everything else.

Where the spoke's address is assigned by the hub rather than configured, the interface takes its address from the negotiation. That means the interface has no address until the session comes up, which is correct and looks alarming the first time it is seen.

! A complete spoke, apart from identity and key
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address negotiated
Spoke1(config-if)# ip nhrp network-id 1
Spoke1(config-if)# ip nhrp shortcut virtual-template 1
Spoke1(config-if)# tunnel source GigabitEthernet0/0
Spoke1(config-if)# tunnel destination 198.51.100.1
Spoke1(config-if)# tunnel mode gre ip
Spoke1(config-if)# tunnel protection ipsec profile FLEX-IPSEC
!
! And the template the spoke-to-spoke tunnels are cloned from
Spoke1(config)# interface Virtual-Template1 type tunnel
Spoke1(config-if)# ip unnumbered Tunnel0
Spoke1(config-if)# ip nhrp network-id 1
Spoke1(config-if)# ip nhrp shortcut virtual-template 1
Spoke1(config-if)# tunnel source GigabitEthernet0/0
Spoke1(config-if)# tunnel mode gre ip
Spoke1(config-if)# tunnel protection ipsec profile FLEX-IPSEC

Address assignment, and what it removes

Assigning the tunnel address from a pool on the hub means no addressing plan entry per branch, no risk of two branches being given the same address by two different engineers, and no configuration difference between one branch and the next. The address is allocated when the session establishes and returned when it ends.

What it costs is predictability. A branch does not have a fixed tunnel address, so anything that referred to one — a monitoring target, an access list, a static route — has to refer to something else. In practice that means the branch's inside addressing carries the identity and the tunnel address is treated as transient, which is the right arrangement anyway.

Hub redundancy, without a second configuration

A spoke can hold an ordered list of hubs and connect to the first that answers, moving to the next when the current one fails. This is a client behaviour attached to the tunnel rather than a routing arrangement, so no second tunnel interface and no metric manipulation is involved.

The behaviour on recovery is configurable and worth deciding deliberately. Returning to the primary as soon as it is available produces a second interruption; staying on the backup until it fails produces an even distribution that nobody planned. Neither is wrong and the choice should be made rather than inherited.

! An ordered hub list, tried in turn
Spoke1(config)# crypto ikev2 client flexvpn FLEX-CLIENT
Spoke1(config-ikev2-flexvpn)# peer 1 198.51.100.1
Spoke1(config-ikev2-flexvpn)# peer 2 203.0.113.1
Spoke1(config-ikev2-flexvpn)# client connect Tunnel0
!
Spoke1# show crypto ikev2 client flexvpn

What the spoke registers, and why

The spoke tells the hub its overlay address and its real address, which is what allows the hub to reach it and what allows the hub to answer resolution requests about it later. Without that registration the hub can terminate the tunnel and cannot tell any other spoke how to reach this one, so spoke-to-spoke resolution fails while everything through the hub works.

That is a specific and quiet failure worth naming: a branch that works perfectly for everything except direct branch-to-branch traffic, with no error anywhere. The mapping table on the hub is where it is visible.

! On the hub: who is registered, and with what real address
Hub# show ip nhrp
10.0.0.101/32 via 10.0.0.101
   Virtual-Access1 created 00:24:11, expire 01:35:49
   Type: dynamic, Flags: registered used nhop
   NBMA address: 203.0.113.11
!
Hub# show crypto ikev2 sa | include Status|Tunnel-id

Where the negotiation fails, and how it reads

Three causes account for most of it. An identity the hub's rule does not match, which reads as an authentication failure and is not one. A key mismatch, which reads the same way. And an authorization lookup that finds no policy, which produces a session that authenticates and then fails, and is distinguishable from the first two only by reading the detail.

The detailed key exchange output names which stage failed, and enabling protocol debugging on one peer address rather than globally is safe and conclusive. Doing it globally on a hub with many spokes is not.

How Does a Direct Spoke-to-Spoke Tunnel Get Built?

What is the sequence?

Traffic from one branch to another goes to the hub first, because that is where the route points. The hub forwards it, notices that it arrived and departed on the same overlay, and sends a redirect back to the sender. The sender then issues a resolution request toward the destination, which travels through the hub. The destination spoke receives it and initiates a key exchange directly back to the sender. Both ends clone an interface, the resolution is answered, and traffic moves off the hub.

A Deeper Dive into the Establishment

The redirect, which the hub sends

A hub configured to redirect watches for traffic that enters and leaves on the same overlay, which by definition means it is relaying between two spokes. Rather than continue relaying silently, it tells the sender that a better path may exist. The message identifies the destination and prompts the sender to attempt resolution.

This is one command on the hub's template and without it nothing further happens. Traffic continues to be relayed correctly and forever, with the hub carrying branch-to-branch load it was never meant to carry, and no indication that anything is missing.

The direction of establishment, which surprises people

The resolution request travels toward the destination, and it is the destination spoke that initiates the key exchange back to the requester. So the session is established in the opposite direction to the traffic that triggered it. This matters when a filter or an address translation sits in front of one spoke and not the other, because the constraint that applies is the one on the answering side.

It also explains a specific asymmetry: branch A can reach branch B directly while B cannot reach A directly, when only one of them can accept an inbound session. Diagnosing that from the sending side alone will not find it.

Reading the establishment as it happens

Three views. The mapping table, which shows the resolved entry and the real address it points to. The key exchange list, which shows a session to the other spoke that did not exist a moment ago. And the interface list, which shows a cloned interface that also did not exist. All three appearing is the confirmation; any one missing identifies the stage that failed.

! Before: only the hub
Spoke1# show ip nhrp brief
Spoke1# show crypto ikev2 sa | include 203.0.113
!
! Generate traffic to the other branch, then look again
Spoke1# ping 192.168.20.1 source 192.168.10.1 repeat 20
!
Spoke1# show ip nhrp
192.168.20.0/24 via 10.0.0.102
   Virtual-Access2 created 00:00:06, expire 00:04:54
   Type: dynamic, Flags: router nhop
   NBMA address: 203.0.113.12
!
Spoke1# show crypto ikev2 sa | include 203.0.113.12
Spoke1# show interfaces | include Virtual-Access

Why the first packets still go through the hub

Establishment takes time — a redirect, a resolution, a key exchange, an interface clone. During that period traffic keeps flowing through the hub, correctly. Nothing is dropped and nothing waits. The path simply improves once the direct tunnel is ready.

This is worth stating to anyone testing the design, because a short ping test will complete entirely through the hub and appear to show that spoke-to-spoke is not working. The test has to run long enough for establishment, and the confirmation is the mapping entry rather than the ping result.

How long the tunnel lives

The resolved mapping has a lifetime, and the tunnel is torn down when it expires with no traffic having refreshed it. A short lifetime keeps the number of simultaneous tunnels down and rebuilds them frequently; a long one keeps tunnels alive through gaps in traffic and holds more state on every spoke.

The right value depends on the traffic pattern. Branches that exchange traffic in bursts through the day are served by a longer lifetime; branches that talk to one another rarely are served by a shorter one. Setting it deliberately, once, per design, is better than discovering the default's implications under load.

When one side cannot accept a session

Address translation in front of a spoke, or a filter permitting only outbound sessions, prevents that spoke from being the answering side. Direct tunnels toward it will not establish, while direct tunnels it initiates — which happen when it is the destination of someone else's traffic — also will not, because it is still the one that must answer.

The workable outcome is that this branch relays through the hub, permanently, for branch-to-branch traffic. That is a capacity decision to make explicitly rather than a fault to chase, and the way to identify it is to test establishment in both directions rather than one. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

! Test in both directions - they are not equivalent
Spoke1# ping 192.168.20.1 source 192.168.10.1 repeat 30
Spoke1# show ip nhrp brief | include 192.168.20
!
Spoke2# ping 192.168.10.1 source 192.168.20.1 repeat 30
Spoke2# show ip nhrp brief | include 192.168.10
!
! And scope the debugging to one peer, never globally on a hub
Spoke1# debug nhrp packet
Spoke1# show ip nhrp traffic

How Do Routes Reach the Spokes?

What are the options?

Two. The key exchange itself can carry routes, so that a spoke learns what it needs during the same negotiation that established the tunnel and no routing protocol runs over the overlay at all. Or a routing protocol runs over the tunnels as it would anywhere else. The first scales further and reacts only to session events; the second reacts to everything a routing protocol reacts to. Which is right depends on whether anything behind a branch changes without the tunnel changing.

A Deeper Dive into Route Distribution

Routes carried by the negotiation

The authorization policy can specify what routes a peer receives, and they are installed when the session establishes and removed when it ends. On the hub side, the spoke's own networks are installed toward it automatically, so the hub learns the branch without configuration.

The appeal is that it removes an entire protocol from the design. No adjacencies, no hellos, no timers to tune on a hub with hundreds of neighbours, and no convergence event when a branch connects — just a route appearing. On a large hub-and-spoke deployment that is a substantial simplification.

! Push a summary to every spoke, and learn the spoke's own networks
Hub(config)# ip access-list standard FLEX-ROUTES
Hub(config-std-nacl)# permit 10.100.0.0 0.0.255.255
Hub(config-std-nacl)# permit 172.16.0.0 0.0.255.255
!
Hub(config)# crypto ikev2 authorization policy FLEX-POLICY
Hub(config-ikev2-author-policy)# route set access-list FLEX-ROUTES
!
! On the spoke, advertise what is behind it
Spoke1(config)# crypto ikev2 authorization policy default
Spoke1(config-ikev2-author-policy)# route set interface
Spoke1(config-ikev2-author-policy)# route set access-list SPOKE-NETS

What it does not do

Routes installed this way are tied to the session. They appear when it establishes and disappear when it ends, and they do not change in between. If a branch's inside network fails while its tunnel stays up, the route remains and traffic continues to be sent to a branch that cannot deliver it.

Where that matters — a branch with its own redundancy, or with networks that come and go — a routing protocol is the right answer, because reacting to changes behind the branch is exactly what it does. Where a branch is a single site with a fixed set of networks, the session-tied route is accurate by construction.

A routing protocol over the overlay

Running one is entirely ordinary. The tunnels are point-to-point interfaces and every mechanism works as it does elsewhere. The considerations are the familiar ones for any hub-and-spoke overlay: summarise toward the spokes, keep the hub's neighbour count manageable, and set timers explicitly rather than inheriting them from an interface bandwidth that was never meaningful.

The one addition is that the cloned spoke-to-spoke interfaces come and go. A protocol that forms an adjacency across each of them generates events every time a direct tunnel is built or expires, which is noise proportional to how dynamic the traffic pattern is. Running the protocol only on the tunnels to the hub, and leaving the direct tunnels to carry data traffic only, avoids that entirely.

Summarisation, which matters more here

A spoke needs a summary or a default plus its own specifics. Sending the full enterprise table to every branch multiplies memory and convergence work by the number of branches for no benefit. Summarising at the hub is the single most effective scaling step and it is available in both approaches — as a shorter prefix in the access list, or as a summary on the hub's interface.

It has one interaction with spoke-to-spoke worth knowing. Resolution is triggered by traffic toward a destination, not by the specificity of the route, so summarising does not prevent direct tunnels from forming. The redirect names the actual destination, and resolution proceeds from there.

Verifying what a spoke actually received

The routing table shows it, and the session detail shows where it came from. A route that is present and attributed to the session behaved as designed; a route that is missing points at the authorization policy rather than at any routing configuration, which is a different place to look than instinct suggests.

! What arrived, and from where
Spoke1# show ip route static | include Tunnel0|Virtual-Access
S     10.100.0.0/16 [1/0] via 10.0.0.1, Tunnel0
!
Spoke1# show crypto ikev2 sa detailed | include Remote subnets|Pushed
!
! On the hub, what it learned about this spoke
Hub# show ip route | include Virtual-Access

Which FlexVPN Failures Are Not Negotiation Failures?

What should be suspected first?

Four things that present as though the key exchange failed and did not. An authorization lookup with nothing to find, which terminates a session that authenticated perfectly. A missing redirect or shortcut, which leaves branch-to-branch traffic on the hub with no error anywhere. A template edited during an incident, which affects nothing until sessions are cleared. And a spoke that cannot accept an inbound session, which breaks direct tunnels in one direction only.

A Deeper Dive into the Failure Catalogue

Authorization, which runs after authentication

The sequence is identity, then authentication, then authorization. A failure at the third stage is reported alongside the first two and reads like a credential problem, which sends the investigation to the keyring and the identity rule where there is nothing wrong.

The distinguishing evidence is in the detailed session output, which names the stage reached. A session that reached authorization and stopped is an authorization problem, and the three things to check are whether network authorization is enabled at all, whether the list named on the profile exists, and whether the policy that list resolves to exists.

The template edit that does nothing

Changing a template during an incident is the natural reaction and it has no effect on any interface already cloned from it. The change is correct, the behaviour does not improve, and the reasonable conclusion — that the change was wrong — is itself wrong.

Clearing the sessions applies it. On a hub that means an interruption for every spoke, which is why a template change is a maintenance activity rather than an incident one wherever the incident is not total. Knowing this in advance prevents a sequence of increasingly speculative changes, each of which also appears to do nothing.

The asymmetric direct tunnel

Because the destination spoke initiates the session, a spoke that cannot accept inbound connections can never be the far end of a direct tunnel. Traffic toward it relays through the hub permanently while traffic it sends can go direct, which produces a puzzling mixture of behaviour across a set of branches that appear identically configured.

Testing from both ends separates it in a minute, and the conclusion is usually a design one rather than a fix: that branch relays, the hub carries the load, and the capacity plan accounts for it. Attempting to work around it by changing the spoke's configuration will not succeed, because the constraint is in front of the spoke.

State that outlives its usefulness

Cloned interfaces and mappings expire on a timer. A hub that has been running for a long time accumulates entries for spokes that reconnected under a different clone, and the interface list becomes longer than the number of connected branches. Most of this is harmless and some of it is confusing, because the obvious reading of the interface list is no longer accurate.

The counts to compare are the number of active key exchange sessions and the number of registered mappings. Those two should agree with the number of connected branches; the interface list may not, and treating it as the authority produces a headcount that is wrong.

! The counts that actually correspond to connected branches
Hub# show crypto ikev2 sa | count Status
Hub# show ip nhrp summary
IP NHRP statistics:
  Static  : 0    Dynamic : 148  Incomplete : 0
!
! Compare against the interface list, which may be longer
Hub# show interfaces | count Virtual-Access

A diagnostic order for this technology

Session before interface, always. Is there a key exchange session with this peer? If not, the problem is negotiation or authorization and the detailed output names which. If there is, was an interface cloned, and does its derived configuration match the template? If it does, is there a mapping, and does it point at the real address expected? Only then look at routing.

Working in that order avoids the most common waste of time in FlexVPN troubleshooting, which is inspecting a running configuration that does not describe any of the interfaces actually carrying traffic.

! In order, on the hub
Hub# show crypto ikev2 sa detailed | section 203.0.113.11
Hub# show interfaces | include Virtual-Access
Hub# show derived-config interface Virtual-Access1
Hub# show ip nhrp | include 203.0.113.11
Hub# show ip route | include Virtual-Access1
!
! And the one-line health view
Hub# show crypto session brief

What to capture routinely

Three counts and one sample. The session count, the mapping count, and the count of cloned interfaces, collected on a schedule so that a divergence between them is visible as a trend rather than discovered during an incident. And the derived configuration of one cloned interface, which is the evidence that the template in use is the template intended.

That last one catches the specific failure where a template was changed months ago and the sessions were never reset, so the production behaviour has been the old template's the whole time. Nothing else reveals it.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers FlexVPN within its transport technologies domain, and the emphasis is on the mechanism rather than a large build. Being able to describe the redirect and resolution sequence, say which side initiates the direct tunnel, and explain what a virtual template does covers most of what is asked about it.

Conclusion

FlexVPN replaces per-peer configuration with identity and a template. The hub holds no list of branches; it holds a rule about what an acceptable identity looks like and a policy describing what such a peer receives. Adding a branch touches nothing at the centre. The interfaces that carry the traffic are cloned from a pattern when a session establishes, which is why the running configuration describes what will be built rather than what exists.

The direct branch-to-branch tunnel depends on two settings and a sequence that runs in an unexpected direction. The hub must redirect, the spokes must be willing to install shortcuts, and the session that creates the direct tunnel is initiated by the destination rather than the sender. That direction is not a detail: it determines which side's filtering or address translation decides whether the tunnel can exist, and it means testing from one end proves only half of it.

What goes wrong is mostly not cryptographic. Authorization runs after authentication and its failure reads like a credential problem. A template edited during an incident changes nothing until sessions are cleared, which makes a correct fix look like a wrong one. Routes carried by the negotiation are as accurate as the session and no more, so a branch whose inside network fails independently keeps its route. In each case the evidence is in the session state or the derived configuration of a cloned interface, and in none of them is it in the configuration file. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

External Links

• RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 2332 — NBMA Next Hop Resolution Protocol (NHRP)
• RFC 4301 — Security Architecture for the Internet Protocol
• RFC 4303 — IP Encapsulating Security Payload (ESP)
• RFC 5685 — Redirect Mechanism for IKEv2
• Cisco — Dynamic Multipoint VPN and related VPN technologies
• Cisco Learning Network — CCIE Enterprise Infrastructure

Reference Notes

1. RFC 7296 specifies IKEv2, including the configuration payload used to assign an address and other attributes to a peer during negotiation.
2. RFC 7296 describes the separation of peer authentication from the subsequent decision about what an authenticated peer is permitted, which is the basis of the authorization step.
3. RFC 2332 defines NHRP, including the resolution request and reply used by a client to learn the NBMA address associated with an overlay destination.
4. RFC 2332 specifies the holding time carried in NHRP messages, which determines how long a resolved mapping remains valid without being refreshed.
5. RFC 4301 defines the IPsec security architecture, including the security association that protects traffic between two peers.
6. RFC 4303 specifies ESP, which provides the confidentiality and integrity applied to the tunnelled traffic.
7. Cisco documentation describes FlexVPN as an IKEv2-based framework using tunnel interfaces, in which dynamic peers are served by virtual access interfaces cloned from a virtual template.
8. Cisco documentation describes NHRP redirect on the hub and NHRP shortcut on the spokes as the mechanisms that cause spoke-to-spoke traffic to leave the hub path.
9. Cisco documentation states that a virtual access interface takes its configuration from the virtual template at the time it is cloned, so changes to the template do not affect existing virtual access interfaces.
10. Cisco documentation describes the IKEv2 authorization policy, which may assign an address from a local pool and install routes toward the peer for the duration of the session.
11. Cisco documentation describes the FlexVPN client, which holds an ordered list of peers and connects to them in turn, providing hub redundancy without a second tunnel interface.
12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include FlexVPN within the transport technologies and virtualisation domain.