Table of Contents 1 GRE Configuration Point to Multi-Point GRE Tunnel Configuration 2-1

Transcription

1 Table of Contents 1 GRE Configuration 1-1 GRE Overview 1-1 Introduction to GRE 1-1 GRE Security Options 1-3 GRE Applications 1-3 Protocols and Standards 1-4 Configuring a GRE over IPv4 Tunnel 1-4 Configuration Prerequisites 1-4 Configuration Procedure 1-4 Configuring a GRE over IPv6 Tunnel 1-6 Configuration Prerequisites 1-6 Configuration Procedure 1-6 Displaying and Maintaining GRE 1-8 GRE over IPv4 Tunnel Configuration Example 1-8 GRE over IPv6 Tunnel Configuration Example 1-11 Troubleshooting GRE Point to Multi-Point GRE Tunnel Configuration 2-1 P2MP GRE Tunnel Overview 2-1 Background 2-1 Operation of a P2MP GRE Tunnel 2-2 P2MP GRE Tunnel Backup 2-3 Advantages and Restrictions of the P2MP GRE Tunnel Technology 2-4 Configuring a P2MP GRE Tunnel 2-5 Configuration Prerequisites 2-5 Configuring a P2MP GRE Tunnel 2-5 Displaying and Maintaining P2MP GRE Tunnels 2-6 P2MP GRE Tunnel Configuration Examples 2-7 Basic P2MP GRE Tunnel Configuration Example 2-7 Configuration Example for P2MP GRE Tunnel Backup at the Headquarters 2-9 Configuration Example for P2MP GRE Tunnel Backup at a Branch 2-12 i

2 1 GRE Configuration This chapter includes these sections: GRE Overview Configuring a GRE over IPv4 Tunnel Configuring a GRE over IPv6 Tunnel Displaying and Maintaining GRE GRE over IPv4 Tunnel Configuration Example GRE over IPv6 Tunnel Configuration Example Troubleshooting GRE GRE Overview Introduction to GRE Generic Routing Encapsulation (GRE) is a protocol designed for encapsulating and carrying the packets of one network layer protocol (for example, IP) over another network layer protocol (for example, IP). GRE is a tunneling technology and serves as a Layer 3 tunneling protocol. A GER tunnel is a virtual point-to-point (P2P) connection for transferring encapsulated packets. Packets are encapsulated at one end of the tunnel and de-encapsulated at the other end. Figure 1-1 depicts the encapsulation and de-encapsulation processes. Figure 1-1 X protocol networks interconnected through the GRE tunnel The following takes the network shown in Figure 1-1 as an example to describe how an X protocol packet traverses the IP network through a GRE tunnel. Encapsulation process 1) After receiving an X protocol packet through the interface connected to Group 1, Device A submits it to the X protocol for processing. 2) The X protocol checks the destination address field in the packet header to determine how to route the packet. 3) If the packet must be tunneled to reach its destination, Device A sends it to the tunnel interface. 4) Upon receipt of the packet, the tunnel interface encapsulates it in a GRE packet. Then, the system encapsulates the packet in an IP packet and forwards the IP packet based on its destination address and the routing table. Format of an encapsulated packet Figure 1-2 shows the format of an encapsulated packet. 1-1

3 Figure 1-2 Format of an encapsulated packet As an example, Figure 1-3 shows the format of an X packet encapsulated for transmission over an IP tunnel. Figure 1-3 Format of an X packet encapsulated for transmission over an IP tunnel These are the terms involved: Payload: Packet that needs to be encapsulated and transmitted. Passenger protocol: Protocol that the payload packet uses, IPX in the example. Encapsulation or carrier protocol: Protocol used to encapsulate the payload packet, that is, GRE. Delivery or transport protocol: Protocol used to encapsulate the GRE packet and then forward the packet to the other end of the tunnel, IP in this example. Depending on the transport protocol, two tunnel modes are present: GRE over IPv4 and GRE over IPv6. De-encapsulation process De-encapsulation is the reverse process of encapsulation: 1) Upon receiving an IP packet from the tunnel interface, Device B checks the destination address. 2) If the destination is itself, Device B strips off the IP header of the packet and submits the resulting packet to the GRE protocol. 3) The GRE protocol checks the key, checksum and sequence number in the packet, and then strips off the GRE header and submits the payload to the X protocol for forwarding. Encapsulation and de-encapsulation processes on both ends of the GRE tunnel and the resulting increase in data volumes will degrade the forwarding efficiency for the GRE-enabled device to some extent. 1-2

4 GRE Security Options For the purpose of tunnel security, GRE provides two options: tunnel interface key and end-to-end checksum. According to RFC 1701, If the Key Present field of a GRE packet header is set to 1, the Key field will carry the key for the receiver to authenticate the source of the packet. This key must be the same at both ends of a tunnel. Otherwise, packets delivered over the tunnel will be discarded. If the Checksum Present bit of a GRE packet header is set to 1, the Checksum field contains valid information. The sender calculates the checksum for the GRE header and the payload and sends the packet containing the checksum to the peer. The receiver calculates the checksum for the received packet and compares it with that carried in the packet. If the checksums are the same, the receiver considers the packet intact and continues to process the packet. Otherwise, the receiver discards the packet. GRE Applications GRE supports these types of applications: Communication between local networks through a single-protocol backbone Scope enlargement of a hop-limited protocol VPN creation by connecting discontinuous subnets GRE-IPsec tunnel application Communication between local networks through a single-protocol backbone Figure 1-4 Communication between local networks through a single-protocol backbone In the example shown in Figure 1-4, Team 1 and Team 2 are local networks running IP. Through the GRE tunnel between Device A and Device B, Team 1 can communicate with Team 2. Scope enlargement of a hop-limited protocol such as RIP Figure 1-5 Network scope enlargement 1-3

5 When the hop count between two terminals exceeds 15, the terminals cannot communicate with each other. Using GRE, you can hide some hops so as to enlarge the scope of the network. VPN creation by connecting discontinuous subnets Figure 1-6 Connect discontinuous subnets with a tunnel to form a VPN In the example as shown in Figure 1-6, subnets Group 1 and Group 2 are deployed in different cities. They can constitute a trans-wan virtual private network (VPN) through the tunnel. GRE-IPsec tunnel application Figure 1-7 GRE-IPsec tunnel application GRE can work with IPsec, allowing data packets like routing protocol, voice, and video packets to be encapsulated by GRE and then encrypted by IPsec to improve security of data transmission in a tunnel. Protocols and Standards RFC 1701 Generic Routing Encapsulation (GRE) RFC 1702 Generic Routing Encapsulation over IPv4 networks RFC 2784 Generic Routing Encapsulation (GRE) Configuring a GRE over IPv4 Tunnel Configuration Prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can normally communicate with the interface used as the source interface of the tunnel interface on the peer device. Configuration Procedure Follow these steps to configure a GRE over IPv4 tunnel: 1-4

6 To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to GRE over IPv4 Configure the source address or interface for the tunnel interface Configure the destination address for the tunnel interface Enable GRE keepalive and set the interval and the maximum number of transmission attempts Enable the GRE packet checksum function Configure the key for the GRE tunnel interface Configure a route for packet forwarding through the tunnel interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre source { ip-address interface-type interface-number } destination ip-address keepalive [ seconds [ times ] ] gre checksum gre key key-number See the IP Routing Volume. By default, a device has no tunnel interface. By default, a tunnel interface has no IPv4 address. Optional By default, the tunnel mode is GRE over IPv4. Note that you need to configure the same tunnel mode on both ends of a tunnel. Otherwise, packet delivery will fail. By default, no source address or interface is configured for a tunnel interface. By default, no destination address is configured for a tunnel interface. Optional Disabled by default Optional Disabled by default Optional By default, no key is configured for a GRE tunnel interface. The two ends of a tunnel must have the same key or have no key at the same time. Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. Note that: For more information about tunnel interfaces and more configuration commands in a tunnel interface, see Tunneling Configuration in the IP Services Volume. For information about commands interface tunnel, tunnel-protocol, source, and destination, see Tunneling Commands in the IP Services Volume. The source address and destination address of a tunnel uniquely identify a path. They must be configured at both ends of the tunnel and the source address at one end must be the destination address at the other end and vice versa. Tunnel interfaces using the same encapsulation protocol must have different source addresses and destination addresses. If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. 1-5

7 You can enable or disable the checksum function at both ends of the tunnel as needed. If the checksum function is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you can configure a static route, using the address of the network segment that the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol on both the tunnel interface and the device interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets through the tunnel. It is not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. Configuring a GRE over IPv6 Tunnel Configuration Prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can normally communicate with the interface used as the source interface of the tunnel interface on the peer device. Configuration Procedure Follow these steps to configure a GRE over IPv6 tunnel: To do Use the command Remarks Enter system view system-view Enable the IPv6 packet forwarding function Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to GRE over IPv6 Configure the source address or interface for the tunnel interface Configure the destination address for the tunnel interface ipv6 interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre ipv6 source { ipv6-address interface-type interface-number } destination ipv6-address Disabled by default By default, there is no tunnel interface on a device. By default, no IPv4 address is configured for a tunnel interface. By default, the tunnel mode is GRE over IPv4. Note that you need to configure the same tunnel mode on both ends of a tunnel. Otherwise, packet delivery will fail. By default, no source address or interface is configured for a tunnel interface. By default, no destination address is configured for a tunnel interface. 1-6

8 To do Use the command Remarks Set the maximum number of encapsulations in the tunnel Enable the GRE packet checksum function Configure the key for the GRE tunnel interface Configure a route for packet forwarding through the tunnel encapsulation-limit [ number ] gre checksum gre key key-number See the IP Routing Volume. Optional 4 by default Optional Disabled by default Optional By default, no key is configured for a GRE tunnel interface. The two ends of a tunnel must have the same key or have no key at the same time. Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. Note that: For information about commands interface tunnel, tunnel-protocol, source, destination, and encapsulation-limit, see Tunneling Commands in the IP Services Volume. For more information about tunnel interfaces and related configurations, see Tunneling Configuration in the IP Services Volume. If you delete a tunnel interface, the functions configured on this tunnel interface will be removed as well. The source address and destination address of a tunnel uniquely identify a path. They must be configured at both ends of the tunnel and the source address at one end must be the destination address at the other end and vice versa. Tunnel interfaces using the same encapsulation protocol must have different source addresses and destination addresses. If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. You can enable or disable the checksum function at both ends of the tunnel as needed. If the checksum function is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you can configure a static route, using the address of the network segment the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol on both the tunnel interface and the device interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets through the tunnel. It is not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. 1-7

9 Displaying and Maintaining GRE To do Use the command Remarks Display information about a specified or all tunnel interfaces Display IPv6 information about a tunnel interface display interface tunnel [ number ] display ipv6 interface tunnel [ number ] [ verbose ] Available in any view Available in any view For information about commands display interface tunnel and display ipv6 interface tunnel, see Tunneling Commands in the IP Services Volume. GRE over IPv4 Tunnel Configuration Example Network requirements Device A and Device B are interconnected through the Internet. Two private IPv4 subnets Group 1 and Group 2 are interconnected through a GRE tunnel between the two devices. Figure 1-8 Network diagram for a GRE over IPv4 tunnel Configuration procedure Before the configuration, make sure that Device A and Device B are reachable to each other. 1) Configure Device A # Configure an IPv4 address for interface GigabitEthernet 0/1. <DeviceA> system-view [DeviceA] interface gigabitethernet 0/1 [DeviceA-GigabitEthernet0/1] ip address [DeviceA-GigabitEthernet0/1] quit # Configure an IPv4 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [DeviceA] interface gigabitethernet 0/2 [DeviceA-GigabitEthernet0/2] ip address [DeviceA-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [DeviceA] interface tunnel 0 # Configure an IPv4 address for interface Tunnel

10 [DeviceA-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [DeviceA-Tunnel0] tunnel-protocol gre # Configure the source address of interface Tunnel 0 to be the IP address of GigabitEthernet 0/2. [DeviceA-Tunnel0] source # Configure the destination address of interface Tunnel 0 to be the IP address of GigabitEthernet 0/2 on Device B. [DeviceA-Tunnel0] destination [DeviceA-Tunnel0] quit # Configure a static route from Device A through interface Tunnel 0 to Group 2. [DeviceA] ip route-static tunnel 0 2) Configure Device B # Configure an IPv4 address for interface GigabitEthernet 0/1. <DeviceB> system-view [DeviceB] interface gigabitethernet 0/1 [DeviceB-GigabitEthernet0/1] ip address [DeviceB-GigabitEthernet0/1] quit # Configure an IPv4 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [DeviceB] interface gigabitethernet 0/2 [DeviceB-GigabitEthernet0/2] ip address [DeviceB-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [DeviceB] interface tunnel 0 # Configure an IP address for interface Tunnel 0. [DeviceB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [DeviceB-Tunnel0] tunnel-protocol gre # Configure the source address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2. [DeviceB-Tunnel0] source # Configure the destination address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2 on Device A. [DeviceB-Tunnel0] destination [DeviceB-Tunnel0] quit # Configure a static route from Device B through interface Tunnel 0 to Group 1. [DeviceB] ip route-static tunnel 0 3) Verify the configuration # After the above configuration, display the tunnel interface status on Device A and Device B respectively. [DeviceA] display interface tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1476 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source , destination Tunnel keepalive disabled Tunnel protocol/transport GRE/IP 1-9

11 GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error [DeviceB] display interface tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1476 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source , destination Tunnel keepalive disabled Tunnel protocol/transport GRE/IP GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 2 bytes/sec, 0 packets/sec Last 300 seconds output: 2 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error # From Device B, you can ping the IP address of GigabitEthernet 0/1 on Device A. [DeviceB] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=2 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=2 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 2/2/2 ms 1-10

12 GRE over IPv6 Tunnel Configuration Example Network requirements Two IPv4 subnets Group 1 and Group 2 are interconnected through a GRE tunnel over the IPv6 network between Device A and Device B. Figure 1-9 Network diagram for a GRE over IPv6 tunnel IPv4 Group 1 GE0/ /24 Device A GE0/2 2002::1:1/64 Tunnel /24 IPv6 network GRE tunnel GE0/2 2002::2:1/64 Tunnel /24 Device B GE0/ /24 IPv4 Group 2 Configuration procedure Before the configuration, make sure that Device A and Device B are reachable to each other. 1) Configure Device A <DeviceA> system-view # Enable IPv6. [DeviceA] ipv6 # Configure an IPv4 address for interface GigabitEthernet 0/1. [DeviceA] interface gigabitethernet 0/1 [DeviceA-GigabitEthernet0/1] ip address [DeviceA-GigabitEthernet0/1] quit # Configure an IPv6 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [DeviceA] interface gigabitethernet 0/2 [DeviceA-GigabitEthernet0/2] ipv6 address 2002::1:1 64 [DeviceA-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [DeviceA] interface tunnel 0 # Configure an IPv4 address for interface Tunnel 0. [DeviceA-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv6. [DeviceA-Tunnel0] tunnel-protocol gre ipv6 # Configure the source address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2. [DeviceA-Tunnel0] source 2002::1:1 # Configure the destination address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2 on Device B). [DeviceA-Tunnel0] destination 2002::2:1 [DeviceA-Tunnel0] quit # Configure a static route from Device A through interface Tunnel 0 to Group 2. [DeviceA] ip route-static tunnel

13 2) Configure Device B <DeviceB> system-view # Enable IPv6. [DeviceB] ipv6 # Configure an IPv4 address for interface GigabitEthernet 0/1. [DeviceB] interface gigabitethernet 0/1 [DeviceB-GigabitEthernet0/1] ip address [DeviceB-GigabitEthernet0/1] quit # Configure an IPv6 address for interface GigabitEthernet 0/2, the physical interface of the tunnel). [DeviceB] interface gigabitethernet 0/2 [DeviceB-GigabitEthernet0/2] ipv6 address 2002::2:1 64 [DeviceB-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [DeviceB] interface tunnel 0 # Configure an IPv4 address for interface Tunnel 0. [DeviceB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv6. [DeviceB-Tunnel0] tunnel-protocol gre ipv6 # Configure the source address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2. [DeviceB-Tunnel0] source 2002::2:1 # Configure the destination address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2 on Device A. [DeviceB-Tunnel0] destination 2002::1:1 [DeviceB-Tunnel0] quit # Configure a static route from Device B through interface Tunnel 0 to Group 1. [DeviceB] ip route-static tunnel 0 3) Verify the configuration # After the above configuration, display the tunnel interface status on Device A and Device B respectively. [DeviceA] display interface Tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1456 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 2002::1:1, destination 2002::2:1 Tunnel protocol/transport GRE/IPv6 GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 1-12

14 0 output error [DeviceB] display interface Tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1456 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 2002::2:1, destination 2002::1:1 Tunnel protocol/transport GRE/IPv6 GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error # From Device B, you can ping the IP address of GigabitEthernet 0/1 on Device A. [DeviceB] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=3 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=3 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 2/2/3 ms Troubleshooting GRE The key to configuring GRE is to keep the configurations consistent. Most faults can be located by using the debugging gre or debugging tunnel command. This section analyzes one type of fault for illustration, with the scenario shown in Figure Figure 1-10 Troubleshoot GRE 1-13

15 Symptom: The interfaces at both ends of the tunnel are configured correctly and can ping each other, but Host A and Host B cannot ping each other. Solution: On Device A and Device C, execute the display ip routing-table command in any view respectively. On Device A, observe whether there is a route from Device A through Tunnel 0 to /16. On Device C, observe whether there is a route from Device C through Tunnel 0 to /16. If an expected static route is missing, use the ip route-static command in system view to configure. For example, configure a static route on Device A as follows: [DeviceA] ip route-static tunnel

16 2 Point to Multi-Point GRE Tunnel Configuration This chapter includes these sections: P2MP GRE Tunnel Overview Configuring a P2MP GRE Tunnel Displaying and Maintaining P2MP GRE Tunnels P2MP GRE Tunnel Configuration Examples P2MP GRE Tunnel Overview Background Figure 2-1 P2MP GRE tunnel application scenario A traditional GRE tunnel is a point to point connection. To use traditional GRE tunnels on an enterprise network as shown in Figure 2-1, you need to configure a P2P GRE tunnel between the headquarters and each branch. When an enterprise has plenty of branches, the configuration workload is huge and, adding new branches requires additional configurations on the headquarters node, burdening network administrators. Besides, if branches dial in to the network through ADSL, the configurations on the headquarters node is even complicated due to the indetermination of the public network addresses of the branches. Dynamic VPN technologies such as Dynamic Virtual Private Network (DVPN) can solve the problem because they support dynamic learning of the mappings of public network addresses and private network addresses and thereby can dynamically establish tunnels between the headquarters and the branches and between the branches. However, there is no unified standard for implementation of dynamic VPN at present. As a result, vendors use their proprietary protocols to implement dynamic VPN, making it difficult for devices of different vendors to cooperate. The P2MP GRE tunnel technology solves this problem. It is very applicable to enterprise networks with a lot of branches. In a P2MP GRE tunnel application, you only need to configure the tunnel interface on the headquarters node to work in P2MP GRE tunnel mode and that on each branch node to work in traditional P2P GRE tunnel mode. Then, a GRE tunnel will be established dynamically between the headquarters and each branch. 2-1

17 Operation of a P2MP GRE Tunnel The encapsulation and de-encapsulation of P2MP GRE tunnel packets are the same as those of P2P GRE tunnel packets. For more information, see Introduction to GRE. Figure 2-2 Learning tunnel destination addresses dynamically Dest /24 Tun Dest Headquarters Device A / /24 IPv4 network Tunnel / GRE tunnel GRE Tunnel /24 Device B Branch / /24 Host A Host B Different from a P2P GRE tunnel, a P2MP GRE tunnel does not require manual configuration of the tunnel destination addresses but learns them from GRE tunnel packets received from peers. As shown in Figure 2-2, Device A resides at the headquarters and has a P2MP GRE tunnel interface configured, while Device B resides at a branch and has a P2P GRE tunnel interface configured. After Device A receives a GRE packet from Device B, it establishes a tunnel entry, taking the source address in the transport protocol (IPv4) header as the tunnel destination address and the source address in the passenger protocol (IPv4) header (that is, the private network address of the branch) as the packet destination address. When forwarding a packet through a P2MP GRE tunnel, the device searches the tunnel entries for the tunnel destination address according to the packet s destination address, and then encapsulates the packet with GRE and then with IPv4, using the tunnel destination address as the destination address in the transport protocol header. The mask length of the packet destination address in a tunnel entry is configurable. After you configure a mask length for a packet destination address, the node at the headquarters establishes only one tunnel entry for private IP addresses in the same network segment, thus reducing the number of tunnel entries on the node at the headquarters and allowing branches to initiate establishment of tunnels by sending emulated data to the node at the headquarters. 2-2

18 P2MP GRE Tunnel Backup GRE tunnel backup at a branch Figure 2-3 GRE tunnel backup at a branch Branch Headquarters Device A Tunnel0 Device B IPv4 network Host A Tunnel0 Tunnel0 Host B GRE P2MP tunnel Device C (Backup gateway) As shown in Figure 2-3, for higher network reliability, a branch can use multiple gateway devices so that a GRE tunnel is established between the headquarters and each gateway of the branch for GRE tunnel backup. When creating a GRE tunnel on a gateway of the branch, you can configure the GRE key. The device at the headquarters will read the GRE key from the GRE packet and record the GRE key value in the corresponding tunnel entry. The device at the headquarters determines the priority of a tunnel entry according to the value of the GRE key, and uses the tunnel corresponding to the tunnel entry with the highest priority to forward packets destined for the peer and uses the other tunnels for backup. A tunnel entry without a GRE key has the highest priority. For tunnel entries carrying a GRE key, a smaller key value means a higher priority. You can configure the GRE key on only a tunnel interface in P2P GRE tunnel mode. A tunnel interface working in P2MP GRE tunnel mode does not support the GRE key argument. 2-3

19 GRE tunnel backup at the headquarters Figure 2-4 GRE tunnel backup at the headquarters As shown in Figure 2-4, for higher network reliability, you can deploy multiple gateways at the headquarters and specify one or more backup interfaces for the main tunnel interface on the main gateway, such as Tunnel 1, to implement headquarters node backup and GRE tunnel backup. If the link between the main gateway and the branch gateway goes down, the main tunnel interface will soon lose the matching tunnel entry for forwarding packets to the branch. In this case, the main tunnel interface will forward the packets to the backup interface, which will then forward the packets to the branch. You need to configure the GRE over IPv4 mode on the backup interface. When a matching tunnel entry on the main gateway exists, a backup interface can also participate in tunnel selection that is based on tunnel priority. If you do not specify a GRE key on a backup interface, the backup interface will have a lower priority than any P2MP tunnel entry. If you specify a GRE key on the backup interface, the key value will be compared with the GRE key values in the P2MP tunnel entries, and the smaller the key value, the higher the priority. Advantages and Restrictions of the P2MP GRE Tunnel Technology The P2MP GRE tunnel technology features the following advantages: Simple configuration. On the headquarters node, you only need to configure the P2MP GRE tunnel mode, instead of configuring a P2P GRE tunnel with each branch node. Low maintenance cost. When a branch is added, no manual configuration is required on the headquarters node; the headquarters node will learn the address of the added branch and then establish a tunnel with the branch node. Flexible access of branches. As the headquarters node learns tunnel destination addresses dynamically, whether the branches obtain public addresses dynamically or not does not impact the configurations on the headquarters node. This allows for more flexible accesses for branches. Wonderful interoperability and investment protection. Based on the standard GRE protocol, the P2MP GRE tunnel technology requires no special or proprietary protocol, nor special requirements on branch gateways. The branch gateways can be from any vendors as long as they support GRE. This not only ensures better cooperation of devices from different vendors, but also helps avoid repetitive investments on branch node devices. 2-4

20 High reliability. It supports GRE tunnel backup at the headquarters and branches, improving the network reliability. The P2MP GRE tunnel technology has the following restrictions: Both the transport protocol and passenger protocol must be IPv4. The headquarters node cannot send packets to a branch before the branch sends packets to it. Only after receiving a packet from the branch, can the headquarters node install a tunnel entry for the branch and send packets to the branch. No tunnel can be established between branch nodes and therefore branch nodes cannot communicate with each. Configuring a P2MP GRE Tunnel Configuration Prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can communicate with the interface used as the source interface of the tunnel interface on the peer device normally. Configuring a P2MP GRE Tunnel Follow these steps to configure a P2MP GRE tunnel: To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to P2MP GRE Configure the source address or interface for the tunnel interface Enable the GRE packet checksum function interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre p2mp source { ip-address interface-type interface-number } gre checksum By default, a device has no tunnel interface. By default, a tunnel interface has no IPv4 address. By default, the tunnel mode is GRE over IPv4. In P2MP GRE tunnel mode, both the transport protocol and passenger protocol are IPv4. Note that you need to configure the tunnel mode as GRE over IPv4 on the tunnel peers. By default, no source address or interface is configured for a tunnel interface. On each branch node, you need to configure the tunnel destination address as this source address. Optional Disabled by default For more information about the GRE packet checksum function, see GRE Security Options. Configure a route for packet See the IP Routing Volume. 2-5

21 To do Use the command Remarks forwarding through the tunnel Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. Configure the aging time for the tunnel entries Specify the backup interface Configure the mask or mask length of the private network addresses of the branch gre p2mp aging-time aging-time gre p2mp backup-interface tunnel number gre p2mp branch-network-mask { mask mask-length } Optional 5 seconds by default Optional By default, no backup interface is specified. The backup interface must be an existing tunnel interface that works in GRE over IPv4 mode. Optional By default, the mask of the private network address of a branch is , that is, the default mask length is 32. Note that: For more information about tunnel interfaces and related configurations, see Tunneling Configuration in the IP Services Volume. For information about commands interface tunnel, tunnel-protocol, and source, see Tunneling Commands in the IP Services Volume. Two or more P2MP GRE tunnel interfaces cannot share the same source address. If you specify a source interface for a P2MP GRE tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. You can enable or disable the checksum function at both ends of the tunnel as needed. If checksum is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. In contrast, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you can configure a static route, using the address of the network segment that the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol on both the tunnel interface and the interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that instructs the device to forward packets through the tunnel. It is not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. Displaying and Maintaining P2MP GRE Tunnels To do Use the command Remarks Display the tunnel entry information of a P2MP GRE tunnel interface Clear the tunnel entry information of a P2MP GRE tunnel interface display gre p2mp tunnel-table interface tunnel number reset gre p2mp tunnel-table [ interface tunnel number [ dest-address tunnel-dest-address] ] Available in any view Available in user view 2-6

22 P2MP GRE Tunnel Configuration Examples Basic P2MP GRE Tunnel Configuration Example Network requirements A company has a network at the headquarters and each of its branches. It is required to implement communication between the headquarters and the branches through GRE, while communication between the branches is not allowed. Figure 2-5 shows a simplified scenario, where there is only one branch. Device A is the gateway at the headquarters, and Device B is the gateway of the branch. Host A is an internal user at the headquarters and Host B is an internal user at the branch. A GRE tunnel is established between Device A and Device B to implement intercommunication between Host A and Host B. If you use P2P GRE tunnels, the number of GRE tunnels to be configured is the same as that of the branches. To simplify the configuration at the headquarters, you can create a P2MP GRE tunnel interface on Device A, and configure a GRE over IPv4 tunnel interface on Device B. This example gives only the configuration on Device B. The configuration on other branch gateways is similar. Figure 2-5 Network diagram for basic P2MP GRE tunnel configuration Configuration procedure 1) Configure Device A # Configure an IP address for interface GigabitEthernet 0/1. <DeviceA> system-view [DeviceA] interface gigabitethernet 0/1 [DeviceA GigabitEthernet0/1] ip address [DeviceA GigabitEthernet0/1] quit # Configure an IP address for interface GigabitEthernet 0/2. [DeviceA] interface gigabitethernet 0/2 [DeviceA GigabitEthernet0/2] ip address

23 [DeviceA GigabitEthernet0/2] quit # Create interface Tunnel 0 and configure an IP address for it. [DeviceA] interface tunnel 0 [DeviceA-Tunnel0] ip address # Configure the tunnel encapsulation mode as P2MP GRE. [DeviceA-Tunnel0] tunnel-protocol gre p2mp # Configure the mask of the branch network as [DeviceA-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [DeviceA-Tunnel0] gre p2mp aging-time 20 # Configure the source IP address of interface Tunnel 0. [DeviceA-Tunnel0] source [DeviceA-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel 0. [DeviceA] ip route-static tunnel 0 2) Configure Device B # Configure an IP address for interface GigabitEthernet 0/1. <DeviceB> system-view [DeviceB] interface gigabitethernet 0/1 [DeviceB GigabitEthernet0/1] ip address [DeviceB GigabitEthernet0/1] quit # Configure an IP address for interface GigabitEthernet 0/2. [DeviceB] interface gigabitethernet 0/2 [DeviceB GigabitEthernet0/2] ip address [DeviceB GigabitEthernet0/2] quit # Create interface Tunnel 0 and configure an IP address for it. [DeviceB] interface tunnel 0 [DeviceB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [DeviceB-Tunnel0] tunnel-protocol gre # Configure the source IP address of interface Tunnel 0. [DeviceB-Tunnel0] source # Configure the destination IP address of interface Tunnel 0. [DeviceB-Tunnel0] destination [DeviceB-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 0. [DeviceB] ip route-static tunnel 0 Verification # After the above configurations, view the tunnel entry information on Device A. No tunnel entry exists. [DeviceA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key # Ping Host A from Host B. The operation succeeds. # View tunnel entry information on Device A again. As the branch has initiated the establishment of the tunnel by sending packets to the headquarters, a tunnel entry should be installed, as shown in the following output information: [DeviceA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key

24 Configuration Example for P2MP GRE Tunnel Backup at the Headquarters Network requirements As shown in Figure 2-6, the headquarters uses two gateways at the egress of the internal network, with Device B for backup. Two GRE tunnels are created on Device C, the gateway at the branch, one for connecting Device A and the other for connecting Device B. Normally, packets are forwarded along the tunnel between Device A and Device C. When a failure occurs along this path, the tunnel between Device B and Device C is used to transmit packets. To meet the above requirements, you need to establish a P2MP GRE tunnel with the branch on both Device A and Device B, establish a GRE over IPv4 tunnel between Device A and Device B, and on Device A configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface. Thus, when Device A cannot find the corresponding tunnel entry for a packet, it delivers the packet to Device B, which then forwards the packet to Device C. To avoid looping, do not configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface on Device B. Figure 2-6 Network diagram for P2MP GRE tunnel backup at the headquarters Headquarters Device A Host A GE0/3 GE0/2 GE0/1 Tunnel1 Tunnel0 Tunnel0 Branch Device C IPv4 network GE0/1 GE0/2 GE0/3 GE0/2 Tunnel1 GE0/1 Tunnel0 Tunnel1 Host C GRE P2MP tunnel Host B Device B (Backup gateway) GRE over IPv4 tunnel Device Interface IP Address Device Interface IP Address Device A GE0/ /24 Device B GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 Tunnel /24 Tunnel /24 Tunnel /24 Tunnel /24 Device C GE0/ /24 Device C Tunnel /24 GE0/ /24 Tunnel /24 Configuration procedure Configure IP addresses and masks for interfaces as per Figure 2-6. (Omitted) 1) Configure Device A # Create interface Tunnel 1 and configure an IP address for it. <DeviceA> system-view 2-9

25 [DeviceA] interface tunnel 1 [DeviceA-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel 1 as GRE over IPv4. [DeviceA-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel 1. [DeviceA-Tunnel1] source [DeviceA-Tunnel1] destination [DeviceA-Tunnel1] quit # Create interface Tunnel 0 and configure an IP address for it. [DeviceA] interface tunnel 0 [DeviceA-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel 0 as P2MP GRE. [DeviceA-Tunnel0] tunnel-protocol gre p2mp # Configure the mask of the branch network connected to Tunnel 0 as [DeviceA-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [DeviceA-Tunnel0] gre p2mp aging-time 20 # Configure the source IP address of interface Tunnel 0. [DeviceA-Tunnel0] source # Configure Tunnel 1 as the backup interface of Tunnel 0. [DeviceA-Tunnel0] gre p2mp backup-interface tunnel 1 [DeviceA-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel 0. [DeviceA] ip route-static tunnel 0 2) Configure Device B # Create interface Tunnel 0 and configure an IP address for it. <DeviceB> system-view [DeviceB] interface tunnel 0 [DeviceB-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel 0 as P2MP GRE. [DeviceB-Tunnel0] tunnel-protocol gre p2mp # Configure the source IP address of interface Tunnel 0. [DeviceB-Tunnel0] source # Configure the mask of the branch network connected to Tunnel 0 as [DeviceB-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [DeviceA-Tunnel0] gre p2mp aging-time 20 [DeviceB-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel 0. [DeviceB] ip route-static tunnel 0 # Create tunnel interface Tunnel 1 and configure an IP address for it. [DeviceB] interface tunnel 1 [DeviceB-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel 1 as GRE over IPv4. [DeviceB-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel 1. [DeviceB-Tunnel1] source [DeviceB-Tunnel1] destination

26 [DeviceB-Tunnel1] quit 3) Configure Device C # Create interface Tunnel 0 and configure an IP address for it. <DeviceC> system-view [DeviceC] interface tunnel 0 [DeviceC-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel 0 as GRE over IPv4. [DeviceC-Tunnel0] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel 0. [DeviceC-Tunnel0] source [DeviceC-Tunnel0] destination [DeviceC-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 0 and priority value being 1. [DeviceC] ip route-static tunnel 0 preference 1 # Create tunnel interface Tunnel 1 and configure an IP address for it. [DeviceC] interface tunnel 1 [DeviceC-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel 1 as GRE over IPv4. [DeviceC-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel 1. [DeviceC-Tunnel1] source [DeviceC-Tunnel1] destination [DeviceC-Tunnel1] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 1 and priority value being 10. This makes the priority of this route lower than that of the static route of interface Tunnel 0, ensuring that Device C prefers the tunnel between Device A and Device C for packet forwarding. [DeviceC] ip route-static tunnel 1 preference 10 If the link between Device A and Device C goes down, Device C will sense the failure and try to send packets to Device B, initiating the establishment of the tunnel between Device B and Device C. Only then can Device B learn the tunnel entry. If Device A and Device C are directly connected, configuring a static route on Device C can ensure that Device C senses the failure of the link between Device A and Device C. If the two are not directly connected, you need to use either of the following methods to achieve the effect: Configure dynamic routing on Device A, Device B, and Device C. On Device C, associate the static route with a track entry, so as to use the track entry to track the status of the static route. For more information about track entry, see Track Configuration in the System Volume. Verification # After the above configurations. Ping Host A from Host C. The ping operation succeeds. View the tunnel entries on Device A and Device B. The output information is as follows: 2-11