Solved

Etherchannel load balancing not working properly

Posted on 2010-11-11
3
2,228 Views
Last Modified: 2013-12-24
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

0
Comment
Question by:myriadsupply
3 Comments
 
LVL 7

Expert Comment

by:blue-screen
ID: 34121703
Can you share the full configuration of both sides?  Sounds like a misconfiguration or a bug.
0
 
LVL 22

Accepted Solution

by:
eeRoot earned 250 total points
ID: 34121798
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
 
LVL 17

Assisted Solution

by:mikecr
mikecr earned 250 total points
ID: 34123889
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

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Quality of Service (QoS) options are nearly endless when it comes to networks today. This article is merely one example of how it can be handled in a hub-n-spoke design using a 3-tier configuration.
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now