Etherchannel load balancing not working properly

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

myriadsupplyAsked:
Who is Participating?
 
eeRootConnect With a Mentor Commented:
Is the switch on the other side of the connection configured the same way?  You may want to try some of the different modes of load-balancing.  With src-dst-ip, the switch may put a lot of the traffic on one port if it sees the same IP because traffic is being forwarded to a router or encapsulated.  You may want to try src-mac on one of these switches and monitor it for a while to see how it behaves.
0
 
blue-screenCommented:
Can you share the full configuration of both sides?  Sounds like a misconfiguration or a bug.
0
 
mikecrConnect With a Mentor Commented:
eeRoot would be correct in his suggestion. When using port channeling, and depending on the algorithm used, i.e., PaGP, LACP, etc, if you try to load balance a destination then the first thing that happens is all traffic will go over the same link. REASON, you can't have out of order packets. This affects performance and stability. So, the algorithm will optimally choose the same path every time to get to the destination because it doesn't want to send packets out of order. Almost all TCP sessions would then use the same path to get to the destination.  It's like asynchronous routing. If you ever used BGP with two different ISP's for internet redundancy and didn't configure the BGP correctly, you could have your traffic going out one interface across one ISP and back in another from the internet. HTTP of all protocols hates that and doesn't work properly in that scenario. Although you're getting some load balancing going on, the traffic is going out one port and back in another, consquently coming in either out of order, or from a different direction and when the client has to talk to the router to send more packets, it doesn't know which one to talk to because they are both talking to it.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.