[c-nsp] Uneven LACP load-balancing
Keegan Holley
keegan.holley at sungard.com
Fri Nov 12 12:07:34 EST 2010
On Fri, Nov 12, 2010 at 11:54 AM, Benjamin Lovell <belovell at cisco.com>wrote:
> Following up on this. Does the 3560 support etherchannel hash on
> src-dst-mac and src-dst-ip? This should change up the hash between CEF and
> etherchannel and prevent a polarization like effect.
>
> SRC-DST-MAC probably isn't a good idea on a layer-3 link. There would be
only one possible outcome to the hash.
>
> On Nov 11, 2010, at 4:58 PM, Benjamin Lovell wrote:
>
> This really just shot in the dark but you have CEF hash for ECMP and then
>> etherchannel hash for link selection. I wonder if it's a weird example of
>> polarization such that because CEF hash decided left now all traffic subject
>> to etherchannel hash for that port-channel will resolve to one link.
>>
>> I don't know if this is true of how the CEF versus etherchannel hashing
>> works but it fits your results.
>>
>> -Ben
>>
>> On Nov 10, 2010, at 12:34 PM, Brandon Ewing wrote:
>>
>> I've got a weird problem that I hope someone can shed some light on. We
>>> have multiple 3560G's deployed currently, each utilizing 4 SFP's for
>>> uplink.
>>> The switches are configured with 2 L2 port-channels, with a different SVI
>>> in
>>> each port-channel pointing to our upstream router. IE:
>>>
>>> g0/49 + g0/51 to core A, carries Vlan 100
>>> g0/50 + g0/52 to core B, carries Vlan 200
>>>
>>> Group Port-channel Protocol Ports
>>>
>>> ------+-------------+-----------+-----------------------------------------------
>>> 4 Po4(SU) LACP Gi0/49(P) Gi0/51(P)
>>> 5 Po5(SU) LACP Gi0/50(P) Gi0/52(P)
>>>
>>>
>>> We have two default routes, pointing out the above vlans:
>>> switch#show ip cef 0.0.0.0 0.0.0.0
>>> 0.0.0.0/0
>>> nexthop 10.10.1.241 Vlan200
>>> nexthop 10.10.1.245 Vlan100
>>>
>>> The etherchannel load-balancing method is set to src-dst-ip:
>>> switch#show etherc load-balance
>>> EtherChannel Load-Balancing Configuration:
>>> src-dst-ip
>>>
>>> EtherChannel Load-Balancing Addresses Used Per-Protocol:
>>> Non-IP: Source XOR Destination MAC address
>>> IPv4: Source XOR Destination IP address
>>> IPv6: Source XOR Destination IP address
>>>
>>>
>>> However, we are not seeing an even distribution of traffic among the 4
>>> ports -- each L2 etherchannel is trasmitting on only one port:
>>> switch#show control util
>>> Port Receive Utilization Transmit Utilization
>>> Gi0/49 1 55
>>> Gi0/50 6 0
>>> Gi0/51 1 0
>>> Gi0/52 12 57
>>>
>>> Examination of flowstats from the core on the uplink interfaces shows a
>>> good
>>> mix of src/dst IPs -- so why am I getting the polarization?
>>>
>>> Additionally, examining a test flow with the command line shows that it
>>> SHOULD be working, but it's not:
>>>
>>> switch#show ip cef exact-route 172.16.79.186 192.168.42.183
>>> 172.16.79.186 -> 192.168.42.183 => IP adj out of Vlan100, addr
>>> 10.10.1.245
>>>
>>> switch#test etherchannel load-balance interface po4 ip 172.16.79.186
>>> 192.168.42.183
>>> Would select Gi0/51 of Po4
>>>
>>> However, g0/51 has no traffic on it, and hasn't for some time. Can
>>> anyone
>>> provide some clue? This is occuring on multiple switches, and all
>>> switches
>>> are running 12.2(50)SE1 ip services
>>>
>>> --
>>> Brandon Ewing (
>>> nicotine at warningg.com)
>>> _______________________________________________
>>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>
>>
>> _______________________________________________
>> cisco-nsp mailing list cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
More information about the cisco-nsp
mailing list