On Fri, Nov 12, 2010 at 11:54 AM, Benjamin Lovell <[email protected]>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 ( >>> [email protected]) >>> _______________________________________________ >>> cisco-nsp mailing list [email protected] >>> https://puck.nether.net/mailman/listinfo/cisco-nsp >>> archive at http://puck.nether.net/pipermail/cisco-nsp/ >>> >> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
