Consistent Per Service Hashing - Alcatel-Lucent 7750 Configuration Manual

LAG link mapping profiles, can be enabled on a LAG as long as the following conditions are met:
•
•
•
•
•
LAG link mapping profile can co-exist with any-other hashing used over a given LAG (for
example, per flow hashing or per-link-hashing). SAPs/network interfaces that have no link
mapping profile configured will be subject to LAG hashing, while SAPs/network interfaces that
have configured LAG profile assigned will be subject to LAG link mapping behavior, which is
described above.

Consistent Per Service Hashing

The hashing feature described in this section applies to traffic going over LAG, Ethernet tunnels
(eth-tunnel) in loadsharing mode, or CCAG load balancing for VSM redundancy. The feature does
not apply to ECMP.
Per-service-hashing was introduced to ensure consistent forwarding of packets belonging to one
service. The feature can be enabled using the [no] per-service-hashing configuration option
under config>service>epipe and config>service>vpls, valid for Epipe, VPLS, PBB Epipe,
IVPLS and BVPLS. Chassis mode D is required.
The following behavior applies to the usage of the [no] per-service-hashing option.
•
•
The following algorithm describes the hash-key used for hashing when the new option is enabled:
•
•
7750 SR Interface Configuration Guide
LAG port-type must be standard.
LAG access adapt-qos must be link or port-fair (for LAGs in mode access or hybrid)
All ports of a LAG on a given router must belong to a single sub-group.
System must be at minimum in chassis mode d (configure system chassis-mode)
Access adapt-qos mode is distribute include-egr-hash-cfg.
The setting of the PBB Epipe/I-VPLS children dictates the hashing behavior of the traffic
destined to or sourced from an Epipe/I-VPLS endpoint (PW/SAP).
The setting of the B-VPLS parent dictates the hashing behavior only for transit traffic
through the B-VPLS instance (not destined to or sourced from a local I-VPLS/Epipe
children).
If the packet is PBB encapsulated (contains an I-TAG ethertype) at the ingress side and
enters a B-VPLS service, use the ISID value from the I-TAG. For PBB encapsulated
traffic entering other service types, use the related service ID
If the packet is not PBB encapsulated at the ingress side
→ For regular (non-PBB) VPLS and EPIPE services, use the related service ID
→ If the packet is originated from an ingress IVPLS or PBB Epipe SAP
−
If there is an ISID configured use the related ISID value
Interface Configuration
Page 131