question about link aggregation between switches.

In article , wld wrote: :Can a link aggregation trunk connect to two vlans? :I mean that from switch_1 this trunk has four ports and port1 and port2 :from vlan1 and port3 and port4 from vlan2. or just works within :one vlan or flooding to all ports in the second switch if client_a send :data from switch_1 to client_b which connect switch_b?

For link aggregation, all the ports should have the same VLANs. Recall that it is possible that all except one of the links will go down and the aggregated link should still continue as much service as will fit in the bandwidth. That couldn't happen if the ports were carrying different vlans.

On many switches that support link aggregation, you can have multiple aggregated links, if you need (for some obscure reason) to separate the aggregation of particular vlans. [I don't know -- maybe you have a case where single port redundancy is good enough for one particular VLAN, but that if more ports start going down then you want to drop that VLAN in favour of other more important ones?]

:The second question is that how it support load balance. :suppose I setup a link aggragation trunk between two :switches uesing 4 port (100mb/port)if the 100mb data via :this trunk, Does 25mb go through to each port?

Depends on the software. Cisco offers a number of ways of load balancing. For example,

- if you have 2^N aggregated links, then take the last N bits of the destination MAC and send through the relative port indicated by that binary number

- similar but using the source MAC instead

- similar but XOR'ing the last N bits of the source MAC and destination MAC

- round robin (packets are given to each link in turn)

Typically, only round-robin will have an equal distribution of packets over the links, as in -most- networks, the majority of the traffic goes to a relatively small number of hosts (e.g., servers if you have them, Master Browsers or PDCs if you are into serverless Microsoft intranet networking; the router is another heavy-traffic destination.) Typically this unequal distribution of traffic happens for both sides of the aggregated link, and it is rare that the "top talkers" happen to distribute well over the links when using MAC based calculations.

Round robin does, though, have a potential disadvantage that can be very important in some situations. When you use round-robin, the packets do not necessarily travel at the same speed on each of the links (minor differences in cable lengths on the human scale translate into significant differences in timing at high symbol rates). This can result in packets arriving "out of order" -- if packet 1 is sent on link 1 and packet 2 is send on the slightly faster link 2, then packet 2 might be delivered before packet 1. If you are using UDP with internal sequence numbers [remember, UDP is unreliable transport, so you usually want some kind of sequence number to get some idea of how many packets didn't make it through], or if you are using TCP without Selective ACKs, this can result in your software discarding the slightly-late packets (UDP) or the slightly-early packets (TCP), with all the hastles that can lead to (e.g., retransmissions after timeouts in the TCP case.) Thus, although round robin sounds good at first, in that equal traffic goes over the links, in practice round robin is not usually used unless your programs or IP stack are written to cope with data arriving out of sequence. TCP with Selective ACKs should do fine in round robin, but traditional TCP can end up with big performance losses as up to N-1 packets can end up being discarded when the first packet arrives late.

Link aggregation makes multiple *physical* ports appear to higher-layer functions (including VLANs) as a single *logical* port. Thus, the situation you are asking about does not really occur. You cannot have two of the physical ports in the aggregation "belong" to one VLAN while the other two (in the same aggregation) "belong" to another VLAN. The four ports are logically one; VLAN allocations are made to the four ports *as a group*.

Now, it is perfectly possible to have a single port on a switch (aggregated or not) carry traffic for multiple VLANs, but this is not really the question you posed.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

The ordering problem is not really due to miniscule differences in cable length. The bigger problem is that not all frames are of equal length. Since frames must be sent "atomically" (i.e., an entire frame on a single physical link), a round-robin algorithm may have to send a

1500-byte frame on one link, then a 64-byte frame on the next. Even with perfectly equal cable lengths, the later-sent 64-byte frame will arrive long before the 1500-byte frame has been received. In fact, more than twenty 64-byte frames can be sent while that 1500-byte frame is still chugging away.

There is a complete discussion of the ordering problem, along with an analysis of a variety of frame distribution algorithms for link aggregation in Chapter 9 of "The Switch Book". [shameless plug admitted]

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

And lets not forget the havoc this would cause with RTP, SIP, etc. Could cause MAJOR degredation of call quality for VOIP, since in most cases packets received out of order are just dropped.

On 2004-09-30, Rich Seifert wrote: [snip]

Buuut... I may be displaying my ignorance here; I was under the impression that applications tend to either send lots of big packers or send lots of smaller ones, with transitions between the two being fairly rare. That would mean that smaller packets ``bypassing'' larger packets aren't very likely to both belong to the same stream. Am I wrong?

And anyway, especially TCP is supposed to deal properly with packets that arrive out-of-order. How come them stacks don't, then?

[snip]

Too bad I only have Tanenbaum here. :-]

That's probably true, but it tends to be quite application-dependent. While you are correct with regard to common apps such as ftp/bulk-file transfer, I can envision applications using a variety of packet lengths that would incur this problem. It also depends on what parameters are used to define the "conversation". (I try to avoid the word "stream" in this context. Most people think of "stream" as an application-to-application packet sequence. In link aggregation, the "conversation" is more likely defined as some unique pair of source-destination addresses, either at the Link or Network layers, and comprise packets from lots of different applications.)

Even so, there will often be an abrupt shift in packet length at the beginning or end of a message (e.g., the last packet in a file transfer is often shorter than the others in front of it, incurring the problem I described earlier).

First, TCP *does* deal with this case, but the performance implications can be severe. It is considered a "boundary" condition, and handled by exception-code, outside of the fast path. Thus, the system will *work*, but it is not something you want to incur.

Second, TCP is not the only transport layer. UDP performs no re-sequencing; applications may or may not deal with out-of-order packets efficiently. Plus, there are lots of protocols out there that are not even in the TCP/IP suite; switches must work with all of them.

-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX

Send replies to: usenet at richseifert dot com