The hashing feature described in this section applies to traffic going over LAG, Ethernet tunnels (eth-tunnel) in load-sharing 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>load-balancing and config>service>vpls>load-balancing, valid for Epipe, VPLS, PBB Epipe, IVPLS and BVPLS.
The following behavior applies to the usage of the [no] per-service-hashing option.
The setting of the PBB Epipe/I-VPLS children dictates the hashing behavior of the traffic destined for 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 for or sourced from a local I-VPLS/Epipe children).
The following algorithm describes the hash-key used for hashing when the new option is enabled:
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
If there is no ISID configured use the related service ID
For BVPLS transit traffic use the related flood list ID
Transit traffic is the traffic going between BVPLS endpoints
An example of non-PBB transit traffic in BVPLS is the OAM traffic
The above rules apply to Unicast, BUM flooded without MMRP or with MMRP, IGMP snooped regardless of traffic type
Operators may sometimes require the capability to query the system for the link in a LAG or Ethernet tunnel that is currently assigned to a specific service-id or ISID. This capability is provided using the tools>dump>map-to-phy-port {ccag ccag-id | lag lag-id | eth-tunnel tunnel-index} {isid isid [end-isid isid] | service servid-id | svc-name [end-service service-id | svc-name]} [summary] command.
An example usage is as follows:
A:Dut-B# tools dump map-to-phy-port lag 11 service 1
ServiceId ServiceName ServiceType Hashing Physical Link
---------- ------------- -------------- ----------------------- -------------
1 i-vpls per-service(if enabled) 3/2/8
A:Dut-B# tools dump map-to-phy-port lag 11 isid 1
ISID Hashing Physical Link
-------- ----------------------- -------------
1 per-service(if enabled) 3/2/8
A:Dut-B# tools dump map-to-phy-port lag 11 isid 1 end-isid 4
ISID Hashing Physical Link
-------- ----------------------- -------------
1 per-service(if enabled) 3/2/8
2 per-service(if enabled) 3/2/7
3 per-service(if enabled) 1/2/2
4 per-service(if enabled) 1/2/3