No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

NE20E-S V800R010C10SPC500 Feature Description - VPN 01

This is NE20E-S V800R010C10SPC500 Feature Description - VPN
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Understanding DSVPN

Understanding DSVPN

This section describes the principles of DSVPN.

Basic Concepts

Figure 1 shows the typical network architecture of the DSVPN solution. An enterprise connects the Hub to Spokes in different geographical locations through the public network. The Hub uses the static public address, and Spokes use dynamic public addresses.

Figure 4-3 Typical enterprise networking

In the figure, the public network address is considered as a Non-Broadcast Multiple Access (NBMA) address, and the tunnel address is regarded as a protocol address.

DSVPN involves the following entities:

DSVPN Node
A DSVPN node is a device on which DSVPN is deployed, which can be a Spoke or Hub.
  • Spoke

    A Spoke is the network gateway of a branch. Generally, a Spoke uses a dynamic public network address.

  • Hub

    A Hub is the gateway in the headquarters and receives registration packets from Spokes. On a DSVPN network, the Hub can use a fixed public network address or a domain name.

mGRE, mGRE Tunnel Interface, and mGRE Tunnel

mGRE is a point-to-multipoint GRE technology developed based on GRE. It extends traditional P2P tunnel interfaces to P2MP mGRE tunnel interfaces. One tunnel interface can be used to establish tunnels with multiple remote devices by changing the interface type. Therefore, only one tunnel interface needs to be configured on the Hub or Spoke, reducing the GRE tunnel configuration workload.

The mGRE tunnel interface has the following attributes:
  • Source tunnel address: is the source address of a GRE encapsulated packet, that is, public network address of one end in Figure 1.
  • Destination tunnel address: is the destination address of a GRE encapsulated packet, that is, public network address of the other end in Figure 1. This address is based on NHRP, which is different from the manually specified destination address of the GRE tunnel interface.
  • Tunnel interface IP address: is the tunnel address in Figure 1. Similar to an IP address of a physical interface, a tunnel interface IP address is used for communication between devices, for example, routing information is obtained.
NOTE:
  • The destination IP address of a GRE tunnel interface is manually specified. Unlike this, the destination IP address of an mGRE tunnel interface is dynamically obtained by NHRP. A single mGRE tunnel interface can establish multiple GRE tunnels with different GRE peers.
  • mGRE tunnel interfaces do not support keepalive detection of the GRE interface.
NHRP

NHRP allows the source Spoke to obtain the dynamic public IP address of the destination Spoke on a non-broadcast multiple access (NBMA) network over which a DSVPN is deployed. When a Spoke accesses an NBMA network, it uses the outbound interface's public IP address to send an NHRP Registration request to the Hub. The Hub creates or updates its NHRP peer entry for the Spoke node based on the received request. The Spokes create and update NHRP peer entries by exchanging NHRP Resolution Request and Reply messages with each other.

Hub-Spoke Tunnel

A Hub-Spoke tunnel is established between a Spoke and the Hub. Figure 4-3 shows an example Hub-Spoke tunnel. Similarly, other Spokes also establish Hub-Spoke tunnels with the Hub.

On a DSVPN, Spoke information is not configured on the Hub. The Hub's public IP address and tunnel address are manually specified on the Spokes. When a Spoke accesses an NBMA network, it sends an NHRP Registration request to the Hub and notifies the Hub of its outbound interface's public IP address. After receiving the request, the Hub updates the local NHRP peer entry for the Spoke.

Spoke-Spoke Tunnel

Spoke-Spoke tunnels are established between Spokes. Figure 4-3 shows an example Spoke-Spoke tunnel.

After the source Spoke finds the destination Spoke's next hop in the routing table, it sends an NHRP Resolution request to obtain the destination Spoke's public IP address if the public IP address corresponding to the next hop cannot be found in the local NHRP peer table. Then the Spokes dynamically establish a VPN tunnel with each other through mGRE tunnel interfaces. In this manner, the source Spoke and destination Spoke can exchange data. If no traffic is forwarded through a Spoke-Spoke tunnel within a certain period, the tunnel is automatically dismantled.

DSVPN Fundamentals

Dynamic Smart VPN (DSVPN) allows VPNs to be established between branches in the following scenarios: non-shortcut scenarios on small- or medium-sized networks and shortcut scenarios on large-scale networks.

Route deployment varies according to different scenarios:
  • Non-shortcut scenario: route learning between branches

    In a non-shortcut scenario, there are only a few branches on a small- or medium-sized network, and the branches learn routes from each other so that the next-hop address of a route from a source Spoke to a destination Spoke subnet is the tunnel address of the destination Spoke. This deployment solution applies to small- or medium-sized networks, and the number of routes dynamically learned between branches is small, which therefore does not require high performance of the Hub and Spoke nodes.

  • Shortcut scenario: saving routes summarized to the HQ

    In a shortcut scenario, there are a large number of branches on a large-scale network, and the branches save only routes summarized to the HQ (Hub node) so that the next-hop address of a route from a source Spoke to a destination Spoke subnet is the tunnel address of the Hub node. If route learning in non-shortcut mode applies to the large-scale network, the Spoke nodes (branches) have to save network-wide routes and consume lots of CPU and memory resources to compute dynamic routes, which requires large capacity of routing tables and high performance of Spoke nodes. To compensate for this shortcoming, DSVPN is enhanced to support route learning in shortcut mode.

DSVPN Principles in Non-Shortcut Scenarios

Route Deployment

In a non-shortcut scenario, Spoke nodes establish tunnels with each other for direct communication. The next-hop address of a route from a source Spoke to a destination Spoke subnet is the tunnel address of the destination Spoke. Spoke nodes can learn routes from each other in the following ways:
  • Static routes are configured on branches.

    Static routes to destination branch subnets are configured on the source branch, and the next hops of the routes are the tunnel addresses of the destination branches.

  • Routes are dynamically learned between branches.

    DSVPN supports OSPF and BGP, both of which can implement route learning between branch subnets and between branch subnets and the HQ subnet. A routing protocol is configured on both the Hub node and Spoke nodes to implement dynamic route learning.

Branches learn routes from each other, and each Spoke node stores routes to all branch subnets.

Principles

DSVPN uses Next Hop Resolution Protocol (NHRP) to dynamically obtain a peer's public IP address. In non-shortcut scenarios, DSVPN working principles are as follows.

Figure 4-4 DSVPN principles in non-shortcut scenarios
On the network shown in Figure 4-4:
  1. The network administrator manually specifies a public IP address or tunnel address for the Hub node. All Spoke nodes on the network send registration requests to the Hub node.
  2. The Hub node generates NHRP peer entries based on the received requests and sends NHRP Registration Reply messages to the Spoke nodes.
  3. The Spoke nodes learn subnet routes from each other either by static route configuration or a dynamic routing protocol. The next hops of the routes are the tunnel addresses of the peer Spoke nodes.
  4. When the source Spoke node forwards a data packet, it obtains the public IP address corresponding to the packet next hop (tunnel address of the destination Spoke node).
  5. If the public IP address corresponding to the tunnel address of the destination Spoke does not exist, the source Spoke sends an NHRP Resolution Request message.
  6. The source Spoke node constructs an NHRP Resolution Request message to request the public IP address corresponding to the tunnel address of the destination Spoke node.
  7. After the NHRP Resolution Request message arrives at the Hub node, the Hub node sends the message to the destination Spoke node.
  8. The destination Spoke receives the NHRP Resolution Request message and sends an NHRP Resolution Reply message to the source Spoke.
  9. Then the source Spoke can directly communicate with the destination Spoke.
DSVPN Principles in Shortcut Scenarios

Route Deployment

In a shortcut scenario, the next-hop address of a route from a source Spoke to a destination Spoke subnet is the tunnel address of the Hub node. The branches are deployed to store only routes summarized to the HQ so that traffic to all destination branches is sent to the Hub node. Spoke nodes can learn routes in the following ways:
  • Static routes are configured on branches.

    Static routes to destination branch subnets are configured on the source branch, and the next hops of the routes are the tunnel address of the Hub node.

  • Branches dynamically learn routes destined for the HQ.

    DSVPN supports OSPF and BGP. Route summarization is configured on the Hub node, and either OSPF or BGP is configured on the Spoke nodes so that the Spoke nodes store only routes summarized to the Hub node. In this manner, traffic to all destination branches is sent to the Hub node. If different routing protocols are used, the Hub and Spoke nodes must be configured separately.

In shortcut mode, the default traffic egress is the Hub node. The branches do not learn routes from each other. The Hub node aggregates the branch routes and then advertises the summarized routes. Additionally, the Hub node forwards NHRP Resolution Request messages to the destination Spoke nodes. Upon receipt, the destination Spoke nodes parse and respond to the requests.

Principles

DSVPN uses NHRP to dynamically obtain a peer's public IP address. In shortcut scenarios, DSVPN working principles are as follows.

Figure 4-5 DSVPN principles in shortcut scenarios
On the network shown in Figure 4-5:
  1. The network administrator manually specifies a public IP address or tunnel address for the Hub node. All Spoke nodes on the network send registration requests to the Hub node.
  2. The Hub node generates NHRP peer entries based on the received requests and sends NHRP Registration Reply messages to the Spoke nodes.
  3. The Spoke nodes learn routes either by static route configuration or a dynamic routing protocol and store only routes summarized to the Hub node.
  4. When the source Spoke forwards a data packet, it searches for the public IP address corresponding to the packet next hop, encapsulates the data packet, and then sends the packet to the next hop. (The next hop here is the Hub node.)
  5. After the data packet reaches the Hub node, the Hub node sends the packet to the destination Spoke and sends an NHRP Redirect message to the source Spoke as well.
  6. Upon receipt, the source Spoke sends an NHRP Resolution Request message to the destination Spoke.
  7. After the NHRP Resolution Request message arrives at the Hub node, the Hub node forwards it to the destination Spoke.
  8. The destination Spoke receives the NHRP Resolution Request message and sends an NHRP Resolution Reply message to the source Spoke.
  9. Then the source Spoke can directly communicate with the destination Spoke.

DSVPN NAT Traversal

In Figure 1, when private networks of Spokes connect to the Hub through Network Address Translation (NAT), NAT traversal must be implemented to establish VPN tunnels between the Hub and Spokes, and between Spokes. DSVPN NAT traversal can be deployed so that Spokes can directly communicate across the NAT device.

Figure 4-6 DSVPN NAT traversal

Figure 1

  1. 1.The Spokes send NHRP Registration Request packets to the Hub. The NHRP Registration Request packets carry public network addresses of the Spokes.
  2. 2.NHRP on the Hub detects whether a NAT device exists between the Hub and Spokes. If the NAT device exists, the Hub encapsulates translated public addresses of Spokes in NAT extension fields of NHRP Registration Reply packets and sends the packets to the Spokes.
  3. 3.The source Spoke sends an NHRP Resolution Request packet to the destination Spoke. The packet carries the original private address and translated public address in NAT extension fields of the source Spoke.
  4. 4.The destination Spoke sends an NHRP Resolution Reply packet to the source Spoke. The packet carries the original private address and translated public address in NAT extension fields of the destination Spoke.
  5. 5.The source and destination Spokes learn the original private address and translated public network address of each other and establish an mGRE tunnel based on the translated public address. By doing this, Spokes can directly communicate across the NAT device.

DSVPN Protected by IPsec

On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
  • The establishment of an mGRE tunnel immediately triggers the establishment of an IPsec tunnel.
  • The IPsec technology uses ACL rules to identify unicast traffic to be encrypted. In an IPsec profile, complex ACL rules are required for identification, which is difficult to implement. DSVPN uses the NHRP and mGRE technologies, if deployed with IPsec, to guarantee high security for data transmission and simplifies network deployment.
  • An IPsec tunnel is dynamically established between the Spokes, preventing IPsec data exchanged between the Spokes from being decrypted and then encrypted by the Hub, which therefore reduces the delay in data transmission.
Figure 4-7 DSVPN protected by IPsec

On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
  1. On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
  2. On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
  3. On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows: DSVPN principles in non-shortcut scenarios and DSVPN principles in shortcut scenarios.
  4. On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
  5. On a DSVPN network, IPsec profiles are configured on the Hub and Spokes and bound to mGRE tunnel interfaces. mGRE tunnel setup will trigger IPsec tunnel setup. The implementation is as follows:
NOTE:

Digital envelop authentication is not supported when NHRP and IPsec are configured simultaneously.

Dual Hubs in Active/Standby Mode

In basic DSVPN networking, all Spokes are connected to one Hub. Spokes cannot communicate with each other if the Hub fails. Multiple Hubs can be deployed to improve network reliability.

NOTE:

Dual-hub backup is supported for DSVPN only in shortcut scenarios.

Figure 4-8 Dual Hubs in active/standby mode

The working mechanism is as follows:
  1. All Spokes send NHRP Registration requests to Hub 1 (active) and Hub 2 (standby) at the same time. (The request messages carry the Spokes' tunnel addresses and public IP addresses.) In addition, the Spokes locally generate NHRP peer tables for the Hubs. Each Spoke records the mappings between the tunnel addresses and public IP addresses of the Hubs in the NHRP peer table.
  2. Hub 1 and Hub 2 record the mapping between the tunnel addresses and public IP addresses of the Spokes based on the received requests, generate NHRP peer entries for the Spokes, and then send NHRP Registration Reply messages to the Spokes.
  3. Routing policies can be deployed on the Spokes to make Hub 1's routes have higher priorities than Hub 2's routes. When the Spokes need to communicate, NHRP Resolution requests are preferentially sent to Hub 1, which forwards the messages.
  4. For details about the principles of establishing tunnels between branches based on traffic, see DSVPN Principles in Shortcut Scenarios.
  5. If Hub 1 fails, the Spokes send NHRP Resolution requests to Hub 2, which forwards the messages. If Hub 1 recovers then, the Spokes choose Hub 1 again as the forwarder based on the predefined routing policies.
Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055135

Views: 10228

Downloads: 19

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next