As you said at least no contradiction. Very relieved about that actually as i wouldn't want to be classed as a marketing man :-)
In networking we normally talk about bandwidth in one direction, i.e. 2 x 1GB = 2GB. However, if you are in marketing it's normal practice to count full-duplex traffic so marketing numbers are usually double. You won't find a real network engineer talking that way though ;-)
So, a channel of two gigabit ethernet ports is a 2GB channel.
NB: Often when channels come up, some think dual links automatically provide 2x the bandwidth.
A single flow normally uses only one of the two links. Two concurrent flows might, or might not, use both links. Depending on traffic attributes, and channel hash, all flows might only use one link.
but wait, so you guys are saying that if I put together 8 gigabit interfaces (the max I think in a 4500 switch) in order to get 8 Mbps speeds, I might never get it because the traffic just takes one interface?
I've read that many people do ethernetchannels so they can gain the speed.... but based on what Im reading here, it could be perhaps more for a redundancy thing than for speed gains
It's possible that one link of an 8GB etherchannel could become saturated, but unlikely. The default load-balancing scheme is source/destination MAC address. The switch takes a hash of these values and chooses a link based off the hash value.
There is a way to test which link will be chosen by entering a certain mode on the switch and issuing a command with the two MACs, but I can't remember it ATM (I know...HUGE help :)
I'll try to dig it up and edit this post.
The command(s) to test the load-balancing hash mechanism is this:
remote login switch
test etherchannel load-balance interface port-channel 1 mac 00d0.c0d7.2dd4 0002.fc26.2494
This is a great doc for all the ins and outs of EtherChannel Load-Balancing:
Hope this helps!
Yup, might only use one link.
As an example, if src-dest mac hash was active, and you channel between two L3 switches as a routed link, the src-mac hash is always the same. I.e. only one channel used. Solution, use some/all L3 within hash.
Another example, access edge with channel to upstream router. If you use just src mac or dest mac, only one channel would be used for traffic of one direction, to/from gateway IP (i.e. same mac). Solution, use hash other than single src or dest mac.
Also note that even a well selected hash can still direct traffic to the same link. Also take note of first table in Chris's reference.
There's nothing "bad" about channels, they just need to be fully understood.
Depending on the platform, hash options usually support some combination of L2 MACs, such as src MAC, dest MAC or src and dest MACs. They also, on the better platforms, support some combinations of L3 hashing based on src IP addr, dest IP addr, src and dest IP addr. Further, some even can include L3 port numbers.
In my prior example, an Ethernet channel between two routers would always see the same pair of MACs, those for each router interface. So, any hash that only uses MACs would hash all traffic to the same link. If we can use instead, IP addresses, often they would be different (the addresses within the packet, not those of the routers) so the hash would distribute traffic across the links.
Yet even that might not work well. Suppose you had two hosts, each with local 10 gig ports but the fiber plant between network switches/routers only supports gig. You decide to make a gig 8 port channel. If different flows pass data back and forth between the two hosts, the host IP addresses wouldn't change. Again, all host-to-host traffic would flow just across one link. Here is where hopefully a hash that supports L3 ports might help.
So, there are situations where a L2 hash won't work well. For those, you often need a L3 hash.