Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,
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?

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?

Thanks,

LL

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <dc998cfd.0409291743.685a24de@posting.google.com>,
wld <aaabbb16@hotmail.com> 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
ne vlan or flooding to all ports in the second switch if client_a send
ata 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.
--
Everyone has a "Good Cause" for which they are prepared to spam.
-- Roberson's Law of the Internet

Archived from groups: comp.dcom.lans.ethernet (More info?)

Walter Roberson wrote:

> 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.

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.

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <dc998cfd.0409291743.685a24de@posting.google.com>,
aaabbb16@hotmail.com (wld) wrote:

> Hi,
> 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?
>

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

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <cjg01v$i26$1@canopus.cc.umanitoba.ca>,
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote:

>
> 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"

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

Archived from groups: comp.dcom.lans.ethernet (More info?)

On 2004-09-30, Rich Seifert <usenet@richseifert.com.invalid> wrote:
[snip]
> 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.
[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]
> 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]

Too bad I only have Tanenbaum here. :-]


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .

Archived from groups: comp.dcom.lans.ethernet (More info?)

In article <1097425288.962903@entelocal.ipberlin.com>,
jpd <read_the_sig@do.not.spam.it> wrote:

> On 2004-09-30, Rich Seifert <usenet@richseifert.com.invalid> wrote:
> [snip]
> > 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.
> [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?
>

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).

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

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