[c-nsp] etherchannel load-balancing and unpredictability

[David Prall]

Keegan,
I think he isn't worried about it being unpredictable load wise. He's more
interested in it being predictable that a source .1 to .2 on the inside
switch goes over link 1, and that the .2 to .1 on the outside switch returns
over link 1. 

This link has a discussion of this:
http://www.cisco.com/en/US/tech/tk389/tk213/technologies_tech_note09186a0080
094714.shtml#cat4k

You can use test etherchannel to determine the exact interface the packets
will be hashed across. This is on the SP of 6500, I checked on a 3560E and
it is available, the link doesn't show a 4500 with IOS and I don't have one
to test on currently. I've used etherchannel load balancing for IPS and as a
span destination for IDS.

David

--
http://dcp.dcptech.com


> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-
> bounces at puck.nether.net] On Behalf Of Keegan Holley
> Sent: Tuesday, July 19, 2011 8:22 PM
> To: Steven Pfister
> Cc: cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] etherchannel load-balancing and unpredictability
> 
> 2011/7/19 Steven Pfister <SPfister at dps.k12.oh.us>
> 
> > 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.
> >
> > this is exactly what is unpredictable about it.  The operation is a
> hash so
> different src/dst pairs aren't always going to chose different links.
> For
> example (a very simple one)  if you have a subnet 192.168.100.0/24 and
> station .1 talks to station .3 and .5 there's nothing to prevent both
> of
> those conversations from using the same link.  It's based on a
> mathematical
> formula that does not vary.  If for example you add .2 and it talks to
> .4
> and .6 they may use the second link.  However, what if the "odd"
> numbered
> conversations are just above 1G say 1.2G or so.  They will drop packets
> and
> there will be no way to hash them to a different link other than
> changing
> load-balancing algorithms.  The being said the other algorithms are
> just as
> unpredictable for just the same reasons.  It depends completely on your
> traffic patterns.  Adding TCP/UDP port may even this out a bit but I
> don't
> believe it is supported on the 3560.
> _______________________________________________
> 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/