Hi, I am looking through the various algorithms that are there for Etherchannel Load Balancing and am trying to understand why would anyone ever configure the load balancing method to be based on the Mac Address. This is specifically targeted at 6500 Switches and considering that the topology is an Access Layer Switch dual homed to distribution layer switches in a V Topology. Now if the Access to Distribution links are L2 links carrying multiple VLANs than in most cases the traffic from servers connected on that Access Switch to remote devices will have the Mac-Address of the Default Gateway which is on the distribution. This would mean that 1 host will always communicate out to any remote host via that same link in the bundle. I would think that Src-Dst-Port would give a more distributed load on the links in that bundle. Can someone please correct me if I am missing something.
2. I have read through some documents that suggest that mls ip cef load-sharing full should be configured only at the distribution layer and at the core it should be left to the default of mls ip cef load-sharing simple. Just to confirm my understanding of this mls ip cef load-sharing full takes into account L4 port numbers in addition to src and dst ip addresses wheras the simple only takes into account the src and dst ip addresss. I would think again that it would be better to have mls ip cef load-sharing full configured everywhere to achieve a more distributed load in traffic. I believe the guide I was reading mentioned something about polarization and hence leaving it at the default on the Core and I cannot understand why this would happen?
3. I have always assumed that the mls ip cef load-sharing command is not needed on L2 access switches since it is used only when you have ECMP or multiple equal cost routes to the same destination. Just want to confirm that this is true.
4. Per documentation there is another keyword added to the mls ip cef load-sharing Full command which is simple. It says that the 'Full' uses unequal weight wheras with 'Full simple' equal weights are given to each link. I am not sure what weight refers to in this context. Could someone please explain.
Thx for your help.
1) about etherchannel load balancing methods
modern switches are able to apply different algorithms to different traffic type using Ethertype field to distinguish between them.
you can check this with:
sh etherchannel load-balance
EtherChannel Load-Balancing Configuration:
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
MPLS: Label or IP
you can configure the algorithm that provides the better fit for your needs.
there can be implications of these commands that is an explosion in size of the CEF table when taking in account L4 ports to define a flow.
Probably for this reason the recommendation is to do not enable it on core switches.
Or the implication can be an increased latency in forwarding.
I see this on my switch
mls ip cef load-sharing full ?
exclude-port Exclude source or destination port for load balancing algorithm
simple load balancing algorithm recommended for a single-stage CEF router
command reference doesn't provide much more light
it mentions using multiple adjacencies or not using multiple adjacencies.
but no mention of weights is done
see also for router 12.2
may you provide the link to the document you are referring to?
Hope to help
". . . am trying to understand why would anyone ever configure the load balancing method to be based on the Mac Address."
Short answer: history
Long answer: Well, that's what L2 works with (and Etherchannel isn't specifically targeted at 6500 switches). Etherchannel technology has been around a while, including on Cisco switches that were incapable of "seeing" higher stack information. There's also the issue that higher stack infomation, like addressing, differs. Today everyone thinks IP/TCP but other higher protocols, now generally in disuse, were common on LANs yet they all might run on the same L2.
The further points you make in your 1st paragraph are true, but again, you were often limited to what earlier Ethernetchannel hash algorithms on earlier platforms supported. Early switches often only supported srcmac or destmac for hashing and it was important with gateway vs. clients to use the choice that provided the best hash (a point often overlooked).
#2 CEF and Etherchannel are deterministic, given the same flow they will always make the same path decision. Given just two paths, each device would make the same choice (polarization), so to try to take advantage of all paths, what Cisco is basicly suggesting is to change the algorithm, per hop, to try to break up the usage of the same path.
If you haven't already seen this, you might want to review: http://www.cisco.com/en/US/docs/solutions/Enterprise/Campus/HA_campus_DG/hacampusdg.html#wp1108021
#3 Yes, CEF is L3
#4 I haven't found specific documentation either, but since I see "Default-Use source and destination IP address, with unequal weights given to each link to prevent polarization" (from http://www.cisco.com/en/US/products/ps9336/products_tech_note09186a0080a963a9.shtml#ecmplb), I suspect it's some type of randomization factor to try to keep each hop from hashing the same flow exactly the same way.
very good links the ones that you have provided specially the second one.
in CEF calculation each router uses an EXOR of last significant digits of IP SA, IP DA and of an hash value that can change at each reload (with default settings).
I think you have made a useful note in:
>> what Cisco is basicly suggesting is to change the algorithm, per hop, to try to break up the usage of the same path.
Hope to help
Ah, one of the hash values that changes per reload sounds much like a pseudo-random value to avoid "polarization". I suspect this value might only be used if a hash algorithm without the "simple" parameter is being used.
With such a hash computation (i.e. with extra pseudo-random hash attribute), though, don't see same link port being selected at each 6500 hop. In other words, "full" parameter on distribution 6500s not really necessary to preclude polarization if "simple" parameter not specified.
BTW, I too suspect that using CEF "full" might utilize more resources on a 6500, and for that reason might be one reason it's not suggested on the core 6500s.
Hi, Is there any command on a Layer 2 6500/sup720 access switch with dual port-channel uplinks to the distribution to load-balance between the 2 port-channels. Per my understanding the port-channel load-balance command is used to distribute the load among the links in the port-channel and mls ip cef load-sharing full simple will only be used to make a decision among L3 paths. Since this is a L2 switch how does it choose between the 2 port-channel links to forward the traffic. I am not sure if the mls ip cef load-sharing command applies here. Thx
the choice between two different L2 etherchannels is made by STP protocol.
This choice can be made on a per vlan (PVST+ or Rapid PVST) or an per STP instance (if using MST 802.1s).
This is not a load balancing choice and with default settings one etherchannel link will be idle and the other will be used for all traffic.
You can manipulate STP costs on a per VLAN / per MST instance basis to load share traffic of different Vlans over the two bundles.
Hope to help
Thx for responding. This is a V shaped topology with no blocking ports. Both uplinks from this switch are in forwarding per Spanning-Tree. I guess it would come down to how GLBP is distributing the load by assigning the AVFs. Pls correct me if this is a wrong assumption. thx
sorry I didn't read again your initial post describing your scenario.
Yes, it becomes a question of MAC address learning and traffic is directed from access switch to the link where the AVF MAC is seen as source address.
So I agree with you.
I would add that probably this is the better way to take advantage of GLBP load balancing capabilities for a population of clients.
Hope to help