Keegan,
If this were bad load sharing I could agree but the fact that one link
shows zero utilization makes me doubt this. Plus he said he does have
a good mix of src-dst IPs so low session count does not appear to be
the issue. The link utilization really looks like a polarization like
effect.
Brandon,
Just as a side note, "show ip cef exact-route" will show you the
software CEF hash. It's not useful on hardware platforms to determine
path selection as hardware will not necessarily make the same
decision. "show mls cef exact-route" is what you want to use on these
platforms. For distributed forwarding(DFC) platforms it may need to be
checked by attaching to the ingress LC.
-Ben
On Nov 11, 2010, at 11:12 PM, Keegan Holley wrote:
Port channels are prone to uneven distribution. Assuming this isnt
a bug The sessions are probably being distributed evenly. The
difference in throughput could be one or two hi bw sessions. For
example an entire company nat'ed to one public IP. Per session
hashing doesn't guarantee even traffic distribution. How long have
been seeing this problem? If it was a small number of sessions
things could look completely different tomorrow. One thing you can
do is add more variables to the equation. If it's supported you can
configure tcp port as part of the hashing algorithm. This will
account for multiple sessions between the same two IP's.
Sent from my iPhone
On Nov 10, 2010, at 12:34 PM, Brandon Ewing <[email protected]>
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/
