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-boun...@puck.nether.net [mailto:cisco-nsp- > boun...@puck.nether.net] On Behalf Of Keegan Holley > Sent: Tuesday, July 19, 2011 8:22 PM > To: Steven Pfister > Cc: cisco-nsp@puck.nether.net > Subject: Re: [c-nsp] etherchannel load-balancing and unpredictability > > 2011/7/19 Steven Pfister <spfis...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
