[c-nsp] Issue with port-channel hashing

Peter Rathlev peter at rathlev.dk
Mon Jul 25 08:22:19 EDT 2016


On Sun, 2016-07-24 at 07:46 +0200, james list wrote:
> where can I find the exact alghorithm for the load balancing
> decision?

Run "show etherchannel load-balance" to see the currently configured
hashing mode. (You cannot see the actual algorithm that way, but it's
probably "just" values XOR'ed and hashed/truncated to the relevant
number of bits.)

> I see two host on the same subnet (Storage replication) are using the
> same link.

You can use "show etherchannel load-balance hash-result" to find out
what hashing bucket a given packet will use. If you give it a port-
channel interface it will also translate the bucket number to a
physical interface:

Switch# show etherchannel 3 port-channel 
...
Index   Load      Port          EC state       No of bits
------+------+------------+------------------+-----------
 0      C3          Gi1/3             Active   4
 1      3C          Gi2/3             Active   4
...

Switch# show etherchannel load-balance hash-result interface Po3 ip 192.0.2.10 192.0.2.20
Computed RBH: 0x6
Would select Gi1/3 of Po3

Switch# show etherchannel load-balance hash-result interface Po3 mixed 192.0.2.10 1025 220 192.0.2.20 1500 
Computed RBH: 0x0
Would select Gi1/3 of Po3

Switch# show etherchannel load-balance hash-result interface Po3 mixed 192.0.2.10 1025 220 192.0.2.20 1502
Computed RBH: 0x2
Would select Gi2/3 of Po3

> I read that the command "port-channel load-balance src-dst-mixed-ip-
> port" could cause from secs to mins of traffic loss... I cannot try
> it :-(

Always be prepared for the worst, of course. But that changing the
load-balance algorithm should lead to more than a few seconds of
interruption seems a bit much.

If the Port-channel interface ends up flapping (I'm not sure but we
plan with this in mind) that would clear the learned MAC table entries
for that interface, which in turn would lead to unicast flooding until
addresses are relearned.

Flapping would require STP to converge. As long as the devices are
running a rapid STP protocol, which they always should, then this also
shouldn't lead to more than a few seconds of interruption.

But test it first and schedule a maintenance window.

-- 
Peter



More information about the cisco-nsp mailing list