FAQ - Why traffic cannot be transmitted at wire speed when being forwarded through the GRE tunnel

2

For S series switches excluding the S1700, why traffic cannot be transmitted at wire speed when being forwarded through the GRE tunnel?

When a packet is forwarded through a tunnel, a label is added to the packet at the tunnel egress. That is, the packet length is increased. The GRE tunnel adds 24 or 32 bytes to the original packet, and the length of a label is 4 bytes on the VPN tunnel. In this case, the total traffic exceeds the wire speed. Packets are discarded during forwarding.

Other related questions:
Why traffic cannot be transmitted at wire speed over a GRE tunnel
When a packet is forwarded through a tunnel, a label is added to the packet at the tunnel egress. That is, the packet length is increased. The GRE tunnel adds 24 or 32 bytes to the original packet, and the length of a label is 4 bytes on the VPN tunnel. In this case, the total traffic exceeds the wire speed. Packets are discarded during forwarding.

Why data packets do not pass the IPSec tunnel
Service packets fail to be transmitted after an IPSec tunnel is successfully established. To troubleshoot this fault, perform the following operations: 1. Check whether data packets match any ACL rule. 2. If NAT is configured on an interface, the matching ACL rule must deny data flows protected by IPSec. After confirming that the ACL rule is correctly configured, enable IPSec. 3. If SHA2 authentication is used, configure the ipsec authentication sha2 compatible enable command. 4. Check that the route configuration is correct. 5. Check that data packets can reach the AR router.

FAQs about OceanStor Toolkit
Refer to Revelations of Troublesolving cases on the right.

What are advantages and disadvantages of direct forwarding and tunnel forwarding
Direct forwarding: Packets do not need to be encapsulated and decapsulated. Therefore, the forwarding efficiency is high, and it is easy for network administrators to locate faults. However, user packets may be intercepted during transmission, threatening information security. In addition, packets of service VLANs need to be transparently transmitted, which increases maintenance workload on the Layer 2 network between ACs and APs. Tunnel forwarding: Packets are encrypted using the Datagram Transport Layer Security (DTLS) protocol, which prevents attackers from intercepting packets transmitted on the network. Therefore, tunnel forwarding has a high security. The configuration is also simple because only packets of the management VLAN need to be transparently transmitted between APs and ACs. However, encrypted packets make fault location difficult. Moreover, the forwarding efficiency is lower than that in direct forwarding because data packets must be encapsulated with a CAPWAP header.

Why cannot VRRP traffic be forwarded after MFF is enabled
If MFF is enabled on a device for Layer 2 isolation, an MFF entry is generated after a DHCP user gets online. The Gateway IP field in the MFF entry is the real gateway address. VRRP has been enabled on the device, so the Layer 3 gateway is a virtual VRRP gateway address. The destination MAC address and gateway IP address of the outgoing user packet are the virtual MAC address and virtual gateway address, which are different from those in the MFF entry. Therefore, VRRP traffic cannot be forwarded. To solve this problem, change the gateway list of the DHCP server as the VRRP virtual gateway address. After a DHCP user re-logs in, its MFF entry is updated. The gateway IP address and MAC address in the MFF entry are the virtual gateway address and virtual MAC address, so VRRP traffic can be forwarded.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top