Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
ContentIndex
  
[+] Expand All
[-] Collapse All

No index entries found.

Related Documentation

  • Understanding Traffic Routing with Shortcut Tunnels
  • Example: Improving Network Resource Utilization with Auto Discovery VPN Dynamic Tunnels
  • Enabling OSPF to Update Routes Quickly After ADVPN Shortcut Tunnels Are Established

Understanding Auto Discovery VPN

AutoVPN deployments can use the Auto Discovery VPN (ADVPN) protocol to dynamically establish spoke-to-spoke VPN tunnels. When passing traffic from one spoke to another spoke, the hub can suggest that the spokes establish a direct security association (SA), called a shortcut, between each other. Shortcuts can be established and torn down dynamically between spokes, resulting in better network resource utilization and less reliance on a centrally located hub.

ADVPN Protocol

The ADVPN protocol is an extension of IKEv2 that allows a shortcut to be created between two VPN peers. Devices that support the ADVPN protocol send an ADVPN_SUPPORTED notification in the IKEv2 Notify payload during the initial IKE exchange. A device that supports ADVPN can act as either a shortcut suggester or a shortcut partner, but not both. This shortcut capability information, along with the ADVPN version number, is also exchanged.

Establishing a Shortcut

An IPsec VPN gateway can act as a shortcut suggester when it notices that traffic is exiting a tunnel with one of its peers and entering a tunnel with another peer. Figure 10 shows traffic from Spoke 1 to Spoke 3 passing through the hub.

Figure 10: Spoke-to-Spoke Traffic Passing Through Hub

Spoke-to-Spoke Traffic
Passing Through Hub

When ADVPN is configured on the devices, ADVPN shortcut capability information is exchanged between the hub and spokes. As long as Spokes 1 and 3 have previously advertised ADVPN shortcut partner capability to the hub, the hub can suggest that Spokes 1 and 3 establish a shortcut between each other.

The shortcut suggester uses its already established IKEv2 SAs with the peers to begin a shortcut exchange with one of the two peers. If the peer accepts the shortcut exchange, then the shortcut suggester begins a shortcut exchange with the other peer. The shortcut exchange includes information to allow the peers (referred to as shortcut partners) to establish IKE and IPsec SAs with each other. The creation of the shortcut between the shortcut partners starts only after both peers accept the shortcut exchange.

Figure 11 shows traffic passing through a shortcut between Spokes 1 and 3. Traffic from Spoke 1 to Spoke 3 does not need to traverse the hub.

Figure 11: Spoke-to-Spoke Traffic Passing Through Shortcut

 Spoke-to-Spoke
Traffic Passing Through Shortcut

Shortcut Initiator and Responder Roles

The shortcut suggester chooses one of the shortcut partners to act as the initiator for the shortcut; the other partner acts as the responder. If one of the partners is behind a NAT device, then the partner behind the NAT device is chosen as the initiator. If none of the partners is behind a NAT device, then the suggester randomly chooses one of the partners as the initiator; the other partner acts as the responder. If both partners are behind NAT devices, then a shortcut cannot be created between them; the suggester does not send a shortcut exchange to any of the peers.

The shortcut suggester begins the shortcut exchange with the responder first. If the responder accepts the shortcut suggestion, then the suggester notifies the initiator.

Using information contained in the shortcut suggester’s notification, the shortcut initiator establishes an IKEv2 exchange with the responder, and a new IPsec SA is established between the two partners. On each partner, the route to the network behind its partner now points to the shortcut instead of to the tunnel between the partner and the suggester. Traffic originating behind one of the partners that is destined to a network behind the other shortcut partner flows over the shortcut.

If the partners decline the shortcut suggestion, then the partners notify the suggester with the reason for the rejection. In this case, traffic between the partners continues to flow through the shortcut suggester.

Shortcut Attributes

The shortcut receives some of its attributes from the shortcut suggester while other attributes are inherited from the suggester-partner VPN tunnel configuration. Table 9 shows the parameters of the shortcut.

Table 9: Shortcut Parameters

Attributes

Received/Inherited From

ADVPN

Configuration

Antireplay

Configuration

Authentication algorithm

Configuration

Dead peer detection

Configuration

DF bit

Configuration

Encryption algorithm

Configuration

Establish tunnels

Suggester

External interface

Configuration

Gateway policy

Configuration

General IKE ID

Configuration

IKE version

Configuration

Install interval

Configuration

Local address

Configuration

Local identity

Suggester

NAT traversal

Configuration

Perfect forward secrecy

Configuration

Protocol

Configuration

Proxy ID

Not applicable

Remote address

Suggester

Remote identity

Suggester

Respond bad SPI

Configuration

Traffic selector

Not applicable

Shortcut Termination

By default, the shortcut lasts indefinitely. Shortcut partners terminate the shortcut if traffic falls below a specified rate for a specified time. By default, the shortcut is terminated if traffic falls below 5 packets per second for 900 seconds; the idle time and idle threshold values are configurable for partners. The shortcut can be manually deleted on either shortcut partner with the clear security ike security-association or clear security ipsec security-association commands to clear the corresponding IKE or IPsec SA. Either of the shortcut partners can terminate the shortcut at any time by sending an IKEv2 delete payload to the other shortcut partner.

When the shortcut is terminated, the corresponding IKE SA and all child IPsec SAs are deleted. After the shortcut is terminated, the corresponding route is deleted on both shortcut partners and traffic between the two peers again flows through the suggester. Shortcut termination information is sent from a partner to the suggester.

The lifetime of a shortcut is independent of the tunnel between the shortcut suggester and shortcut partner. The shortcut is not terminated simply because the tunnel between the suggester and partner is terminated.

ADVPN Configuration Limitations

Note the following limitations when configuring ADVPN:

  • Configuring an ADVPN partner is only allowed on site-to-site VPNs. Configuring an ADVPN suggester is only allowed on AutoVPN hubs.
  • You cannot configure both suggester and partner roles on the same gateway. When ADVPN is enabled on a gateway, you cannot disable both suggester and partner roles on the gateway.
  • As mentioned previously, you cannot create a shortcut between partners that are both behind NAT devices. The suggester can initiate a shortcut exchange if only one of the partners is behind a NAT device or if no partners are behind NAT devices.
  • Only the OSPF dynamic routing protocol is supported with ADVPN; RIP and BGP are not supported.

The following configurations are not supported with ADVPN:

  • IKEv1
  • Policy-based VPN
  • IKEv2 configuration payload
  • Traffic selectors
  • Preshared key
  • Point-to-point secure tunnel interfaces

Related Documentation

  • Understanding Traffic Routing with Shortcut Tunnels
  • Example: Improving Network Resource Utilization with Auto Discovery VPN Dynamic Tunnels
  • Enabling OSPF to Update Routes Quickly After ADVPN Shortcut Tunnels Are Established

Modified: 2016-05-01