[c-nsp] etherchannel load-balancing and unpredictability

[Tóth András]

Hi Steven,

If the balance method is configured for src-dst IP, a given src/dst ip
pair will always use the same link, if the number of links in the
channel does not change. If more links are added, or gets removed, the
same ip pair might start using another link.

You can check the result of the load balance algorithm to see which
interface will be used for a particular src/dst ip/mac pair with the
following commands by appending the appropriate parameters based on
the balance method being used.
3560/3750 and 6500 switches: test etherchannel load-balance interface
port-channel <x> ...
4500 switches: show platform software etherchannel port-channel <x> map ...

I would also recommend you to review the following documentation if
you haven't done so yet which explains the usage of test etherchannel
command in detail.

Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080094714.shtml


Best regards,
Andras


On Tue, Jul 19, 2011 at 10:49 PM, Steven Pfister <SPfister at dps.k12.oh.us> wrote:
> I think I kind of see what you mean. For a given source/destination ip
> address pair. Switch A might always select path 1 every time going to
> switch B, but on the return trip, switch B might select path 2 every
> time going back to switch A. Something like that?
>
> But if that were the case, would that happen with all connections? The
> behavior we were seeing (one content filter has been removed from the
> network) is that some people were getting blocked correctly and some
> weren't, which is what I would expect if one filter were working
> correctly and the other wasn't.
>
> Steve Pfister
> Network Engineer
> Office of Information Technology
> Dayton Public Schools
> 115 S Ludlow St
> Dayton, OH 45402-1812
> Phone: 937-542-3149
> Cell: 937-673-6779
> spfister at dps.k12.oh.us ( mailto:spfister at dps.k12.oh.us )
>
>
>>>> John Gill <johgill at cisco.com> 7/19/2011 4:30 PM >>>
> Hello Steve,
> The port selection function is based on a hash of the inputs, in this
> case the source and destination IP address, and the output is a value
> that chooses a member interface.
>
> These functions between the input and output vary by platform, but for
> a
> given platform you can expect with the same flow, and even the reverse
>
> of that flow, you will get the same selection.
>
> Because the platforms implement this selection logic in hardware, they
>
> can and *do* vary between one model and another.  As a matter of fact,
>
> the new Nexus 5500 has the ability to choose between various
> polynomials
> used in this function.  You might find one gives you a better
> distribution over another.  In your case, it sounds like you need some
>
> state on both sides of the content filter to be in tact.  In this
> scenario, you would need the same platform on both sides to guarantee
> this kind of behavior.
>
> Regards,
> John Gill
> cisco
>
>
> On 7/19/11 4:11 PM, Steven Pfister wrote:
>> I have a question regarding etherchannel load balancing. I've got a
>> 4507R switch connected to a 3560 switch by means of two content
> filters
>> which are acting as transparent bridges. The two ports on each side
> that
>> the content filters are connected to are set up as access ports and
> are
>> in an etherchannel. The load balancing method on each switch is set
> to
>> src-dst-ip. I was under the impression that each pair of source and
>> destination ip address would select exactly one content filter no
> matter
>> which direction.
>>
>> I've been told that this can be 'unpredictable' and may cause
>> assymetric flows. The algorithm seems fairly straightforward to me.
> I
>> don't see where the unpredictability can come in. Can someone explain
> to
>> me what I'm missing?
>>
>>
>> Steve Pfister
>> Network Engineer
>> Office of Information Technology
>> Dayton Public Schools
>> 115 S Ludlow St
>> Dayton, OH 45402-1812
>> Phone: 937-542-3149
>> Cell: 937-673-6779
>> spfister at dps.k12.oh.us ( mailto:spfister at dps.k12.oh.us )
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>