Configuring Load Balancing Based on Inner Information of Tunnel Packets

Configuration Guide

This configuration is supported only in Admin-VS.

View	Format
Slot view	load-balance hash-fields tunnel-inner-ip enable NOTE: After the load-balance hash-fields tunnel-info disable command is run, the load-balance hash-fields tunnel-inner-ip enable command cannot be executed. After the load-balance hash-fields tunnel-inner-ip enable command is run, the execution of the load-balance hash-fields tunnel-info disable command causes the load-balance hash-fields tunnel-inner-ip enable configuration to be deleted from the device.

View

Format

Slot view

load-balance hash-fields tunnel-inner-ip enable

NOTE:

After the load-balance hash-fields tunnel-info disable command is run, the load-balance hash-fields tunnel-inner-ip enable command cannot be executed.

After the load-balance hash-fields tunnel-inner-ip enable command is run, the execution of the load-balance hash-fields tunnel-info disable command causes the load-balance hash-fields tunnel-inner-ip enable configuration to be deleted from the device.

Usage Scenarios

In a public IP over SRv6 BE/IP over SRv6 TE Policy or private IP over SRv6 BE/IP over SRv6 TE Policy load balancing scenario, the inner information of SRv6 packets transmitted by P nodes is not used as a hash factor by default. After the load-balance hash-fields tunnel-inner-ip enable command is run, the inner packet information of the SRv6 is mapped to the FlowLabel value of the outer IPv6 packets. The P nodes of SRv6 implement load balancing based on the new hash factor, that is, the FlowLabel value.

In an IPv4 over SRv6 BE/IPv4 over SRv6 TE Policy load balancing scenario, the load balancing can be implemented based on inner IPv4 packets transmitted over an SRv6 only when the inner IP packets carry the GTP, 4over4, 6over4, GRE, and L2TP information. In an IPv6 over SRv6 BE/IPv6 over SRv6 TE Policy load balancing scenario, the load balancing can be implemented based on inner IPv6 packets transmitted over an SRv6 only when the inner IP packets carry the GTP information.

L2TP control packets support load balancing based on inner IP packets, with the external IP address as the hash factor.
Non-L2TP control packets support load balancing based on inner IP packets, with the external IP address, tunnel ID, or session ID as the hash factor.
GTP-U v1 packets support load balancing based on inner IP packets, with the external IP address or GTP-TE-ID as the hash factor.
IP in IP packets support load balancing based on inner IP packets, with the inner 5-tuple as the hash factor.
6over4 packets support load balancing based on inner IP packets, with the inner 5-tuple as the hash factor.
GRE packets support load balancing based on the inner IP packets.
- For inner non-IP packets with the Key field carried in a GRE header, the following information can be hashed to FlowLabel: external SIP, external DIP, and GRE-Key.
- For inner non-IP packets with the Key field not carried in a GRE header, the following information can be hashed to FlowLabel: external SIP and external DIP.
- For inner IP packets with neither the Sequence field nor CR field carried in a GRE header, the following information can be hashed to FlowLabel: inner SIP, inner DIP, protocol, sport, and dport.
- For inner IP packets with the Sequence field and not the Key field carried in a GRE header, the following information can be hashed to FlowLabel: external SIP and external DIP.
- For inner IP packets with the Sequence field and Key field carried in a GRE header, the following information can be hashed to FlowLabel: external SIP, external DIP, and GRE-Key.

Follow-up Procedure

When a series of configurations are complete and take effect, run the save command to save the current configuration to the configuration file.