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

Configuration Guide - VPN 01

NE05E and NE08E V300R003C10SPC500

This is NE05E and NE08E V300R003C10SPC500 Configuration Guide - 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).
Configuring a GRE Tunnel

Configuring a GRE Tunnel

GRE provides a mechanism of encapsulating packets of a protocol into packets of another protocol. This allows packets to be transmitted over heterogeneous networks. The channel for transmitting heterogeneous packets is called a tunnel.

Usage Scenario

A single network protocol (for example, IPv4) is used to transmit packets on a backbone network, whereas other protocols, such as IPv6 and Internet Packet Exchange (IPX), are used to transmit packets on non-backbone networks. Because the backbone and non-backbone networks use different protocols, packets cannot be transmitted between the non-backbone networks over the backbone network. Generic Routing Encapsulation (GRE) resolves this issue. GRE provides a mechanism of encapsulating packets of a protocol into packets of another protocol.

If the tunnel interface is deleted, all the configurations on the interface are deleted.

Pre-configuration Tasks

Before configuring an ordinary GRE tunnel, complete the following task:

  • Configuring reachable routes between the source and destination interfaces

Configuration Procedures

Figure 3-1 Flowchart for configuring GRE tunnel

Configuring the Interface Bound to GRE

To enable the source interface or interface with the source IP address of a GRE tunnel to transmit GRE-encapsulated packets, the interface must be bound to GRE.

Context

Perform the following steps on the NEs at both ends of a tunnel.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface interface-typeinterface-number

    The interface view is displayed.

  3. Run ip address ip-address { mask | mask-length }

    The IP address is set for the interface.

  4. Run binding tunnel gre

    The GRE protocol is bound to the interface.

  5. Run quit

    Return to the system view.

  6. Run commit

    The configuration is committed.

Configuring a Tunnel Interface

After creating a tunnel interface, specify GRE as the encapsulation type, set the tunnel source address or source interface, and set the tunnel destination address. In addition, set the tunnel interface network address so that the tunnel can support dynamic routing protocols.

Context

A GRE tunnel is established between two tunnel interfaces on two ends of a tunnel. Therefore, you need to configure tunnel interfaces of devices on both ends of the tunnel. Set the protocol type to GRE, and specify a source address or interface and a destination address for the tunnel interface. If the interface runs dynamic routing protocols, you also need to specify an IP address.

When configuring the source interface of a tunnel, note the following: Do not specify the source interface of a tunnel as its own tunnel interface. You can specify the source interface as the tunnel interface of another tunnel.

The MTU value is effective only when a local device sends packets over a GRE tunnel, whereas it is ineffective when the local device receives packets and forwards the packets over a GRE tunnel.

A tunnel interface is a logical interface, and its interface status changes to Down in the following cases:
  • The destination address of the tunnel interface is unreachable or is the same as the address of this interface.

  • The source interface status of the tunnel interface becomes Down.

  • The IP address of the tunnel interface is invalid.

  • The Keepalive function is configured on the tunnel interface and tunnel remote end is unreachable.

Perform the following steps on the NEs at the two ends of a tunnel.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface tunnel interface-number

    A tunnel interface is created, and the tunnel interface view is displayed.

    NOTE:

    For an integrated GRE tunnel, the tunnel interface must be a three-dimensional interface (named by the slot ID, subcard ID, and interface number). The slot ID of the tunnel interface must be consistent with the ID of the slot in which the source interface-bound tunnel service board resides. If the slot IDs are different, the GRE tunnel cannot be established.

  3. (Optional) Run description text

    The tunnel description information is configured.

  4. Run tunnel-protocol gre

    The tunnel is encapsulated with GRE.

  5. Run source { source-ip-address | interface-type interface-number }

    The source address or source interface of the tunnel is configured.

    NOTE:

    Run the binding tunnel gre command to bind GRE to the source interface or the interface where the source address resides. After the binding, a GRE tunnel can use the interface to forward packets encapsulated by GRE.

  6. Run destination [ vpn-instance vpn-instance-name ] ip-address

    The destination address of the tunnel is configured.

    After a tunnel interface is created, specify the source address or source interface and destination address of the tunnel.

  7. (Optional) Run mtu mtu

    The maximum transmission unit (MTU) of the tunnel interface is modified.

  8. (Optional) Run tunnel pathmtu enable

    Automatic path MTU discovery is enabled.

    By default, automatic path MTU discovery is disabled.

    If BGP nodes configured with the peer path-mtu auto-discovery command communicate over GRE tunnels, you can run the tunnel pathmtu enable command on tunnel interfaces to prevent over-fragmentation of TCP packets that carry BGP packets and improve BGP packet transmission efficiency.

  9. Configure the IP address of the tunnel interface. To support dynamic routing protocols on a tunnel, configure a network address for the tunnel interface. The network address of the tunnel interface may not be a public address, but should be in the same network segment on both ends of the tunnel. Perform either of the following operations:

    • Run the ip address ip-address { mask | mask-length } [ sub ] command to configure the IP address of the tunnel interface.

    • Run the ip address unnumbered interface interface-type interface-number command to configure IP unnumbered for the tunnel interface.

    By default, the network address of a tunnel interface is not set.

  10. Run quit

    Return to the system view.

  11. (Optional) Run global-gre forward-mode { through | loopback }

    A forwarding mode is specified, which takes effect on all distributed GRE tunnels.

    By default, the software loopback mode configured using the through parameter is used for distributed GRE tunnels. Configure either of the following forwarding parameters:

    • through: enables the software loopback mode. It supports high forwarding performance, but does not support HQoS functions for outgoing packets.
    • loopback: enables the hardware loopback mode. It supports a half of forwarding performance that the software loopback mode does and also supports HQoS functions for outgoing packets.

  12. Run commit

    The configuration is committed.

Configuring Routes for the Tunnel

Routes for a tunnel must be available on both the source and destination devices so that packets encapsulated with GRE can be forwarded correctly. A route passing through tunnel interfaces can be a static route or a dynamic route.

Context

The routes passing through a tunnel must be available on both the local and remote devices so that packets encapsulated by GRE can be forwarded properly. These routes can be static routes or dynamic routes. When configuring tunnel routes, note the following:
  • When configuring a static route, the destination address is the destination of the packet that is not encapsulated by GRE, rather than the destination address of the tunnel. The next hop is the address of the local tunnel interface.

  • When configuring a dynamic routing protocol, enable the protocol on both the tunnel interface and the physical interface connected to the private network. When you configure a route to the remote end of a tunnel, the next hop cannot be the address of the tunnel interface. Otherwise, GRE encapsulated packets cannot be forwarded properly.

    As shown in Figure 3-2, the source interface of Tunnel1 is interface1 on DeviceA, and the destination physical interface of Tunnel1 is interface2 on DeviceC. When configuring a dynamic routing protocol, you need to enable the protocol on both the tunnel interface and the interface connected to the PC. In the routing table, the outbound interface for the route to interface2 on DeviceC cannot be Tunnel1.

    In practical configurations, configure different routing protocols or change the metric of the tunnel interface. In this manner, you can avoid selecting a tunnel interface as an outbound interface for packets destined for the destination of the tunnel.

    Figure 3-2 Diagram of configuring the GRE dynamic routing protocol
    NOTE:

    Interfaces 1 through 4 in this example are GE 0/1/0, GE 0/2/0, Tunnel1, Tunnel2, respectively.



Perform the following steps on the devices at two ends of a tunnel.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Choose one of the following methods to configure routes passing through the tunnel interface.

    • Run the ip route-static ip-address { mask | mask-length } tunnel interface-number [ description text ] command to configure a static route.

    • Configure dynamic routes using IGP or BGP. Details for the procedure are not provided here. For the configuration of dynamic routes, see the NE Configuration Guide - IP Routing.

  3. Run commit

    The configuration is committed.

(Optional) Configuring a TTL Processing Mode for a GRE Tunnel

To enable a GRE tunnel to process TTLs carried in packets, configure the GRE tunnel to process these TTLs in pipe or uniform mode.

Context

Perform the following steps on NEs at both ends of a GRE tunnel.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run gre ttl-mode { pipe | uniform }

    A TTL processing mode is configured for the GRE tunnel.

    By default, a GRE tunnel processes TTLs carried in packets in pipe mode.

  3. Run commit

    The configuration is committed.

(Optional) Enabling the Keepalive Function

You can enable the Keepalive function for a GRE tunnel to avoid selecting an unavailable GRE tunnel to transmit packets.

Context

The Keepalive function can be configured on one end of a GRE tunnel to test the GRE tunnel status. If the remote end is found unreachable, the tunnel is disconnected on time to avoid data black hole.

Figure 3-3 GRE tunnel supporting Keepalive

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface tunnel interface-number

    The tunnel interface view is displayed.

  3. Run keepalive [ period period [ retry-times retry-times ] ]

    The Keepalive function is enabled.

    The GRE tunnel Keepalive function is unidirectional. Therefore, to realize the Keepalive function on both ends, enable the Keepalive function on both ends of a GRE tunnel. One end can be configured with the Keepalive function regardless of whether the remote end is enabled with the Keepalive function. But it is still recommended to enable the Keepalive function on both ends of the GRE tunnel.

    NOTE:

    Before configuring the tunnel policy and the GRE tunnel for the VPN, enable the GRE tunnel Keepalive function. With this function enabled, the VPN does not select the GRE tunnel that cannot reach the remote end, and the data loss can be avoided. The reasons for enabling the Keepalive function are listed below:

    • If the Keepalive function is not enabled, the local tunnel interface may always be Up regardless of whether data reaches the remote end.

    • If the Keepalive function is enabled on the local end, the local tunnel interface is set to Down when the remote end is unreachable. As a result, the VPN does not select the unreachable GRE tunnel and the data is not lost.

  4. Run commit

    The configuration is committed.

(Optional) Configuring GRE Security Options

Configuring GRE security options can improve GRE tunnel security.

Context

To enhance the security of a GRE tunnel, configure end-to-end checksum authentication or key authentication. This security mechanism can prevent the tunnel interface from incorrectly identifying and receiving packets from other devices.

Perform the following steps on the NEs at two ends of a tunnel.

Procedure

  1. Run system-view

    The system view is displayed.

  2. Run interface tunnel interface-number

    The tunnel interface view is displayed.

  3. Run gre key { plain key-number | [ cipher ] plain-cipher-text }

    A key is set for the tunnel interface.

    If keys are set for the tunnel interfaces on the two ends of the tunnel, ensure that the keys are the same. Alternatively, you may choose not to set keys for the tunnel interfaces on both ends of the tunnel.
    • plain key-number: specifies a plaintext key (integer).

    • plain-cipher-text: specifies a plaintext key (integer) or a ciphertext key.

    By default, no key is configured for the tunnel.

  4. Run commit

    The configuration is committed.

Verifying the GRE Tunnel Configuration

After a GRE tunnel is set up, you can view the running status and routing information about the tunnel interface.

Context

The GRE function has been configured.

Procedure

  • Run the display interface tunnel [ interface-number ] command to check tunnel interface information.
  • Run the display ip routing-table command to check the IPv4 routing table.
  • Run the ping -a source-ip-address host command to check whether the two ends of the tunnel can successfully ping each other.

Example

Run the display interface tunnel command. If the tunnel interface is Up, the configuration succeeds. For example:

<HUAWEI> display interface Tunnel1
Tunnel10 current state : UP (ifindex: 19)
Line protocol current state : UP
Last line protocol up time : 2013-03-06 10:21:44
Description:
Route Port,The Maximum Transmit Unit is 1500, Current BW: 65.53Kbps
Internet Address is 2.2.2.2/24
Encapsulation is TUNNEL, loopback not set
Tunnel source 10.1.1.2 (Vlanif10), destination vrf vpn2 10.1.1.1
Tunnel protocol/transport GRE/IP, key disabled
keepalive disabled
Checksumming of packets disabled
Current system time: 2013-03-07 04:43:26
    300 seconds input rate 0 bits/sec, 0 packets/sec
    300 seconds output rate 0 bits/sec, 0 packets/sec
    0 seconds input rate 0 bits/sec, 0 packets/sec
    0 seconds output rate 0 bits/sec, 0 packets/sec
    0 packets input,  0 bytes
    0 input error
    0 packets output,  0 bytes
    0 output error
    Input:
      Unicast: 0 packets, Multicast: 0 packets
    Output:
      Unicast: 0 packets, Multicast: 0 packets
    Input bandwidth utilization  : --
    Output bandwidth utilization : --
    Last 300 seconds input utility rate:  0.00%
    Last 300 seconds output utility rate: 0.00%

Run the display ip routing-table command. If the route passing through the tunnel interface exists in the routing table, the configuration succeeds. For example:

<HUAWEI> display ip routing-table
Route Flags: R - relay, D - download
to fib, T - to vpn-instance, B - black hole route
------------------------------------------------------------------------------
Routing Table : _public_
         Destinations : 15       Routes : 15

Destination/Mask    Proto   Pre  Cost        Flags NextHop         Interface

       10.1.1.0/24  Direct  0    0             D  10.1.1.2        Vlanif20
       10.1.1.2/32  Direct  0    0             D  127.0.0.1       Vlanif20
     10.1.1.255/32  Direct  0    0             D  127.0.0.1       Vlanif20
      10.2.1.0/24 Static 60   0             D 0.0.0.0        Tunnel1
       10.3.1.0/24  Direct  0    0             D  10.3.1.1        Vlanif10
       10.3.1.1/32  Direct  0    0             D  127.0.0.1       Vlanif10
     10.3.1.255/32  Direct  0    0             D  127.0.0.1       Vlanif10
       10.4.1.0/24  OSPF    10   2             D  10.3.1.2        Vlanif10
       10.5.1.0/24  Direct  0    0             D  10.5.1.1        Tunnel1
       10.5.1.1/32  Direct  0    0             D  127.0.0.1       Tunnel1
     10.5.1.255/32  Direct  0    0             D  127.0.0.1       Tunnel1
      127.0.0.0/8   Direct  0    0             D  127.0.0.1       InLoopBack0
      127.0.0.1/32  Direct  0    0             D  127.0.0.1       InLoopBack0
127.255.255.255/32  Direct  0    0             D  127.0.0.1       InLoopBack0
255.255.255.255/32  Direct  0    0             D  127.0.0.1       InLoopBack0

Run the ping -a source-ip-address host command to see that the ping from the local tunnel interface to the destination tunnel succeeds.

<HUAWEI> ping -a 10.1.1.1 10.1.1.2
  PING 10.1.1.2: 56  data bytes, press CTRL_C to break
    Reply from 10.1.1.2: bytes=56 Sequence=1 ttl=255 time=24 ms
    Reply from 10.1.1.2: bytes=56 Sequence=2 ttl=255 time=33 ms
    Reply from 10.1.1.2: bytes=56 Sequence=3 ttl=255 time=48 ms
    Reply from 10.1.1.2: bytes=56 Sequence=4 ttl=255 time=33 ms
    Reply from 10.1.1.2: bytes=56 Sequence=5 ttl=255 time=36 ms
  --- 10.1.1.2 ping statistics ---
    5 packet(s) transmitted
    5 packet(s) received
    0.00% packet loss
    round-trip min/avg/max = 24/34/48 ms
Translation
Download
Updated: 2019-01-14

Document ID: EDOC1100058925

Views: 33466

Downloads: 59

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