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

CX11x, CX31x, CX710 (Earlier Than V6.03), and CX91x Series Switch Modules V100R001C10 Configuration Guide 12

The documents describe the configuration of various services supported by the CX11x&CX31x&CX91x series switch modules The description covers configuration examples and function configurations.
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).
Principles

Principles

This section outlines the basic principles used when implementing GRE technology.

Basic Concepts

Implementation

Packets transmitted over a GRE tunnel undergo encapsulation and decapsulation processes. As shown in Figure 9-1, if the ingress PE transmits X protocol packets to the egress PE, the ingress PE encapsulates the packets and the egress PE decapsulates the packets. A GRE tunnel is a path along which encapsulated packets are transmitted.

Figure 9-1 Transmitting X protocol packets over a GRE tunnel

  • Encapsulation

    1. After receiving an X protocol packet from the interface connected to the X network, the ingress PE sends the packet to the X protocol.

    2. The X protocol checks the destination address in the packet header and searches the routing table or the forwarding table for the outbound interface. If the outbound interface is a GRE tunnel interface, the ingress PE adds a GRE header to the packet.

    3. The ingress PE adds an IP header to the packet because the backbone network runs the IP protocol. The source address in the IP header is the tunnel source address and the destination address in the IP header is the tunnel destination address.

    4. The ingress PE searches the IP routing table for the outbound interface based on the destination address in the IP header (tunnel destination address) and transmits the packet over the IP backbone network.

    NOTE:

    For details on the format of the encapsulated packet, see Packet Format.

  • Decapsulation

    The decapsulation process is opposite to the encapsulation process.

    1. After receiving the packet from the GRE tunnel interface, the egress PE analyzes the IP header in the packet and finds that itself is the destination of the packet. Then the egress PE removes the IP header and delivers the packet to the GRE protocol for processing.

    2. The GRE protocol removes the GRE header and delivers the packet to the X protocol.

Packet Format
Figure 9-2 shows the format of a GRE-encapsulated packet.
  • Passenger protocol: indicates the protocol of the original packet. The original packet is encapsulated in a GRE packet as the payload.

  • Encapsulation protocol: indicates the protocol used to encapsulate passenger protocol packets by adding a GRE header. It is also called the carrier protocol.

  • Transport protocol (or delivery protocol): indicates the protocol used to transmit the encapsulated packets.

Figure 9-2 GRE packet format

Table 9-1 describes the fields in a GRE header.

Table 9-1 Description of fields in a GRE header

Field

Description

C

Checksum bit.
  • 1: The GRE header contains the Checksum field.
  • 0: The GRE header does not contain the Checksum field.

K

Key bit.
  • 1: The GRE header contains the Key field.
  • 0: The GRE header does not contain the Key field.

Recursion

Number of times a packet is encapsulated by GRE. The value of this field increases by 1 every time the packet is encapsulated. If the packet is encapsulated more than three times, the device discards the packet. This field prevents a packet from being encapsulated infinitely.

NOTE:
  • According to RFC1701, the default value of this field is 0.

  • According to RFC2784, no error will occur if the field value on the transmit end is different from that on the receive end, and the receive end must ignore the field.

  • This field is only used to indicate the number of times a packet is encapsulated. When GRE decapsulates a packet, this field does not affect packet processing.

Flags

Reserved field. The value must be set to 0.

Version

Version number. The value must be set to 0.

Protocol Type

Type of the passenger protocol. A common passenger protocol is the IPv4 protocol, with the value of 0800.

Checksum

Checksum of the GRE header and the payload.

Key

Key used to authenticate the packet at the receive end.

NOTE:

Currently, the GRE header does not contain the Source Route field; therefore, bit 1, bit 3, and bit 4 are all set to 0.

Keepalive Detection

GRE does not provide the link status detection function. If the remote interface is unreachable, the tunnel cannot be immediately torn down. As a result, the source continuously forwards packets to the remote end which cannot receive the packets, generating a data black hole.

The Keepalive detection function monitors the tunnel status to check whether the remote end is reachable. If the remote end is unreachable, the source end tears down the tunnel immediately. This prevents data loss and data black holes and ensures reliable data transmission.

The Keepalive detection function is implemented as follows:
  1. After the Keepalive detection function is enabled on the source end of a GRE tunnel, the source end starts a timer to periodically send and count Keepalive probes. The number increases by 1 every time a Keepalive probe is sent.

  2. The remote end sends a reply packet to the source end after receiving a probe.

  3. If the source end receives a reply packet before the counter value reaches the preset value, the source end considers the remote end reachable. If the source end does not receive any reply packet when the counter reaches the preset value (retry times), the source end considers the remote end unreachable and tears down the tunnel. In this case, the source interface still sends Keepalive probes to the remote interface. When the remote interface becomes Up, the source interface becomes Up too and sets up a tunnel with the remote interface.

NOTE:

The Keepalive detection function takes effect on one end of a tunnel as long as it is configured at that end, regardless of whether it is configured on the other end. If the remote end receives a Keepalive probe, it sends a replay packet to the source end, regardless of whether it is configured with the Keepalive detection function.

Translation
Download
Updated: 2019-08-09

Document ID: EDOC1000041694

Views: 57499

Downloads: 3619

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