Best Ethernet switch device for trunking support??

[Guest]

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

Hi,

I am in embedded R&D, and am looking for a Fast Ethernet switch with
really good trunking (link aggregation, LAG, etc.) support. If I have
a trunk group with 3 ports, than this is what I am looking for:

1) Auto-failover to other ports in the trunk group if one port fails.

2) A trunking algorithm that can handle if one port of the trunk group
maxes out its bandwidth and should not be assigned new connections.
Let the other ports catch up a little bit and don't throw away any
data.

3) Support for interfacing to Cisco's EtherChannel trunking.

4) Something else besides a MAC based trunking algorithm, to be able
to more randomly distribute 2-way connections between ports in the
trunk groups.

I have used a Broadcom part in a previous design that handles number
1, but not the others. Now I am looking at Zarlink devices (ZL504xx
family), but they don't handle 1 internally (I have to reconfigure the
trunk group after I get an interrupt, but I'll lose data).

This is for a VoIP application.

ANy suggestions appreciated!

Greg in MA

 

[Guest]

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

In article <1e208886.0407200716.5a5f8357@posting.google.com>,
apage_88@hotmail.com (CCGolfer) wrote:

>
> I am in embedded R&D, and am looking for a Fast Ethernet switch with
> really good trunking (link aggregation, LAG, etc.) support. If I have
> a trunk group with 3 ports, than this is what I am looking for:
>
> 1) Auto-failover to other ports in the trunk group if one port fails.
>

I'm not sure what you mean by this. Any link aggregation system using
LACP (automatic configuration) will reconfigure an aggregation to
accommodate however many links are available, including dynamic changes
in availability. Whether frames are discarded as a result of
reconfiguration depends on: (1) How quickly the hardware can detect link
failure, and (2) Whether there are frames queued for transmission on the
failed link at the time failure is detected.

It is not generally feasible to re-queue any outstanding frames from one
link (the failed one) to another, working link in an aggregation. The
queued frames are generally discarded. Any protocol or application
running over an Ethernet (aggregated or not) MUST be capable of dealing
with undelivered frames; these can result from a variety of events
besides reconfiguration of aggregated links.

> 2) A trunking algorithm that can handle if one port of the trunk group
> maxes out its bandwidth and should not be assigned new connections.
> Let the other ports catch up a little bit and don't throw away any
> data.
>

This is not possible in practice. A "conversation" is assigned to a link
without any knowledge of the portion of the link capacity that that
conversation will consume. In addition, the offered load of a given
conversation will change over time. It is generally impractical (if not
impossible) to shift conversations from one link to another as a
function of their offered load. The requirement of sequential delivery
of frames (within a conversation) would necessitate flushing the queue
on the currently-active link for a conversation before shifting it to
another. This is way more trouble than it is worth (and tends to reduce
overall performance significantly).

>
> 4) Something else besides a MAC based trunking algorithm, to be able
> to more randomly distribute 2-way connections between ports in the
> trunk groups.
>

I don't know how much more "random" you can get than MAC addresses. Many
switches can (and indeed, must) be able to assign conversations to links
based on Layer 3 (IP) addresses (in order to support aggregated
connections to servers), and possibly, TCP/UDP port numbers (for
server-to-server connections). There is an extensive discussion of the
use of different assignment conventions in Chapter 9 of "The Switch
Book".


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

Send replies to: usenet at richseifert dot com

 

[Guest]

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

CCGolfer <apage_88@hotmail.com> wrote:
> Hi,

> I am in embedded R&D, and am looking for a Fast Ethernet switch with
> really good trunking (link aggregation, LAG, etc.) support. If I have
> a trunk group with 3 ports, than this is what I am looking for:

> 1) Auto-failover to other ports in the trunk group if one port fails.
>
> 2) A trunking algorithm that can handle if one port of the trunk group
> maxes out its bandwidth and should not be assigned new connections.
> Let the other ports catch up a little bit and don't throw away any
> data.

> 3) Support for interfacing to Cisco's EtherChannel trunking.

> 4) Something else besides a MAC based trunking algorithm, to be able
> to more randomly distribute 2-way connections between ports in the
> trunk groups.

> I have used a Broadcom part in a previous design that handles number
> 1, but not the others. Now I am looking at Zarlink devices (ZL504xx
> family), but they don't handle 1 internally (I have to reconfigure the
> trunk group after I get an interrupt, but I'll lose data).

> This is for a VoIP application.

> ANy suggestions appreciated!

Go for GB instead. No hazzle no "specials".

> Greg in MA

--
Peter Håkanson
IPSec Sverige ( At Gothenburg Riverside )
Sorry about my e-mail address, but i'm trying to keep spam out,
remove "icke-reklam" if you feel for mailing me. Thanx.

 

[Guest]

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

Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote in message news:<usenet--11FD7B.09222520072004@news-central.dca.giganews.com>...
> In article <1e208886.0407200716.5a5f8357@posting.google.com>,
> apage_88@hotmail.com (CCGolfer) wrote:
>
> >
> > I am in embedded R&D, and am looking for a Fast Ethernet switch with
> > really good trunking (link aggregation, LAG, etc.) support. If I have
> > a trunk group with 3 ports, than this is what I am looking for:
> >
> > 1) Auto-failover to other ports in the trunk group if one port fails.
> >
>
> I'm not sure what you mean by this. Any link aggregation system using
> LACP (automatic configuration) will reconfigure an aggregation to
> accommodate however many links are available, including dynamic changes
> in availability. Whether frames are discarded as a result of
> reconfiguration depends on: (1) How quickly the hardware can detect link
> failure, and (2) Whether there are frames queued for transmission on the
> failed link at the time failure is detected.
>
> It is not generally feasible to re-queue any outstanding frames from one
> link (the failed one) to another, working link in an aggregation. The
> queued frames are generally discarded. Any protocol or application
> running over an Ethernet (aggregated or not) MUST be capable of dealing
> with undelivered frames; these can result from a variety of events
> besides reconfiguration of aggregated links.

LACP is not really a feature that's available withing Ethernet switch
chips (made by companies like Zarlink or Broadcom), is it? I thought
it was something that router or switch equipment (Cisco, Lucent) would
support by their software. In the chip devices, link failure is
easily detected and they should be able to start using other ports in
a trunk group. Like you say, undelivered frames that are lost during
this shift must be able to be handled by the receiveng end. In my
case with VoIP, the RTP decoder layer will handle that, and we will
just hear a slight pop on the voice call while the switch occurs.

>
> > 2) A trunking algorithm that can handle if one port of the trunk group
> > maxes out its bandwidth and should not be assigned new connections.
> > Let the other ports catch up a little bit and don't throw away any
> > data.
> >
>
> This is not possible in practice. A "conversation" is assigned to a link
> without any knowledge of the portion of the link capacity that that
> conversation will consume. In addition, the offered load of a given
> conversation will change over time. It is generally impractical (if not
> impossible) to shift conversations from one link to another as a
> function of their offered load. The requirement of sequential delivery
> of frames (within a conversation) would necessitate flushing the queue
> on the currently-active link for a conversation before shifting it to
> another. This is way more trouble than it is worth (and tends to reduce
> overall performance significantly).

The way I thought it might be able to happen is for the device to know
how much bandwidth is being used on one port, and when a threshold is
reached it could stop assigning new conversations to that port until a
low-water mark is reached.

>
> >
> > 4) Something else besides a MAC based trunking algorithm, to be able
> > to more randomly distribute 2-way connections between ports in the
> > trunk groups.
> >
>
> I don't know how much more "random" you can get than MAC addresses. Many
> switches can (and indeed, must) be able to assign conversations to links
> based on Layer 3 (IP) addresses (in order to support aggregated
> connections to servers), and possibly, TCP/UDP port numbers (for
> server-to-server connections). There is an extensive discussion of the
> use of different assignment conventions in Chapter 9 of "The Switch
> Book".

We will always have a set of 2 or 3 source MAC addresses (each address
will have a pool of VoIP channels). Also, a very high percentage of
traffic will be routed through a gateway with a single destination
MAC. Routing to other destination MAC addresses on the same subnet
will make the decision more random, but that's done more in lab
testing and not once the application is used in the real world. So
it's really not so random at all.

 

[Guest]

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

In article <1e208886.0407210528.4980587c@posting.google.com>,
apage_88@hotmail.com (CCGolfer) wrote:

> LACP is not really a feature that's available withing Ethernet switch
> chips (made by companies like Zarlink or Broadcom), is it? I thought
> it was something that router or switch equipment (Cisco, Lucent) would
> support by their software.

That is true. Other than providing support (e.g., the low-level
primitives needed for LACP control), the chips themselves do not
implement LACP. However, the device in which the chips reside should
implement the protocol, and this provides the capability you asked for.
Why push a function into silicon (which costs real money) when it can be
done in software (which is essentially free, from a manufacturing
perspective)?

The only time it makes sense to do things in hardware is when the
function is performance-sensitive, such that software would degrade
system operation. I would not expect link failures to be commonplace (if
they are, you have bigger problems that need to be addressed), so a
software solution seems appropriate.

> In the chip devices, link failure is
> easily detected and they should be able to start using other ports in
> a trunk group.

Again, there is no need to do this in silicon, since it happens rarely.

> Like you say, undelivered frames that are lost during
> this shift must be able to be handled by the receiveng end. In my
> case with VoIP, the RTP decoder layer will handle that, and we will
> just hear a slight pop on the voice call while the switch occurs.
>

You will hear more than a slight pop if it is software handling the
switchover, but again, it is a rare event in the grand scheme of things.


>
> The way I thought it might be able to happen is for the device to know
> how much bandwidth is being used on one port, and when a threshold is
> reached it could stop assigning new conversations to that port until a
> low-water mark is reached.
>

This sounds attractive in principle, but it leads to a slew of other
problems. First, how does the device know "how much bandwidth is being
used"? What is the time period for the averaging algorithm? (Utilization
*always* implies time-averaging, since at any instant the utilization is
either zero or 100%.) Is it averaged over milliseconds? seconds?
minutes? Statistics would have to be kept on every port in real-time.

Even if you do keep the statistics, they change dynamically. A link that
is currently experiencing high average load (over whatever period you
choose) would force new conversations to other links. Now thosee other
links are getting higher load; if the first link's load then decreases,
one could say that your algorithm made the *wrong* decision. It should
have assigned the conversation to the link that would be experiencing
lower traffic *in the future*, however it is not possible to know which
link this is.

The lack of information about future traffic patterns makes any
distribution algorithm subject to challenge for some given set of
conversations. That is, all that your "new" algorithm does is to make
one set of situations look "better", at the cost of making a different
set of situations look "worse". In the end, there are still a bunch of
good cases and a bunch of bad ones.


>
> We will always have a set of 2 or 3 source MAC addresses (each address
> will have a pool of VoIP channels). Also, a very high percentage of
> traffic will be routed through a gateway with a single destination
> MAC. Routing to other destination MAC addresses on the same subnet
> will make the decision more random, but that's done more in lab
> testing and not once the application is used in the real world. So
> it's really not so random at all.

In that case, make your distribution algorithm a function of IP
addresses, preferably including both the source and destination in a
hash function. As long as connections between various sources and
destinations are relatively uniformly distributed (e.g., all VoIP calls
are not being made by one station to only one other station), this will
distribute the calls uniformly across all available links.


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

Send replies to: usenet at richseifert dot com

 

[Guest]

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

In article <usenet--A5D850.10202921072004@news-central.dca.giganews.com>,
Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote:
:Why push a function into silicon (which costs real money) when it can be
:done in software (which is essentially free, from a manufacturing
erspective)?

:The only time it makes sense to do things in hardware is when the
:function is performance-sensitive, such that software would degrade
:system operation.

It also makes sense to push software into silicon in order to provide
integrated feature-rich packages that can be dropped in to devices.

For example, playing (or installing) ring tones is not very performance
sensitive on a cell phone, but if you want your small-chipset
cellphone to be the one adopted by manufacturers for integration
into their PDAs, jeweled pendants, wrist watches, and shoes, then
you don't want to be telling those manufacturers that "This will
do everything for you!! Except that you need to put in a cpu and
a prom and an I/O interface in order to handle the ringing and the
ring-tone setup."
--
I predict that you will not trust this prediction.

 

[Guest]

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

Walter Roberson wrote:

> In article <usenet--A5D850.10202921072004@news-central.dca.giganews.com>,
> Rich Seifert <usenet-@-richseifert-dot-com.invalid> wrote:
> :Why push a function into silicon (which costs real money) when it can be
> :done in software (which is essentially free, from a manufacturing
> erspective)?
>
> :The only time it makes sense to do things in hardware is when the
> :function is performance-sensitive, such that software would degrade
> :system operation.
>
> It also makes sense to push software into silicon in order to provide
> integrated feature-rich packages that can be dropped in to devices.
>
> For example, playing (or installing) ring tones is not very performance
> sensitive on a cell phone, but if you want your small-chipset
> cellphone to be the one adopted by manufacturers for integration
> into their PDAs, jeweled pendants, wrist watches, and shoes, then
> you don't want to be telling those manufacturers that "This will
> do everything for you!! Except that you need to put in a cpu and
> a prom and an I/O interface in order to handle the ringing and the
> ring-tone setup."

No, you put the CPU and the prom and the I/O interface on _your_ chip.

Transistor count on an 8080 is 4500. Current semiconductor manufacturing
technology gives about 1 million transistors per square millimeter for
products aimed at the consumer market. Implementing an 8080 takes, then,
about .004 square millimeters of space. Drop in your 8080 and a little bit
of mask-programmed ROM and however much scratchpad you need and you're
there. So why design hardware to perform that same task?

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

 

[Guest]

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

Check GarrettCom's Magnum 6K family of Managed Switches

http://www.garrettcom.com/6k_family.htm

MNS-6K software info can be found at http://www.garrettcom.com/6k_soft.htm




apage_88@hotmail.com (CCGolfer) wrote in message news:<1e208886.0407200716.5a5f8357@posting.google.com>...
> Hi,
>
> I am in embedded R&D, and am looking for a Fast Ethernet switch with
> really good trunking (link aggregation, LAG, etc.) support. If I have
> a trunk group with 3 ports, than this is what I am looking for:
>
> 1) Auto-failover to other ports in the trunk group if one port fails.
>
> 2) A trunking algorithm that can handle if one port of the trunk group
> maxes out its bandwidth and should not be assigned new connections.
> Let the other ports catch up a little bit and don't throw away any
> data.
>
> 3) Support for interfacing to Cisco's EtherChannel trunking.
>
> 4) Something else besides a MAC based trunking algorithm, to be able
> to more randomly distribute 2-way connections between ports in the
> trunk groups.
>
> I have used a Broadcom part in a previous design that handles number
> 1, but not the others. Now I am looking at Zarlink devices (ZL504xx
> family), but they don't handle 1 internally (I have to reconfigure the
> trunk group after I get an interrupt, but I'll lose data).
>
> This is for a VoIP application.
>
> ANy suggestions appreciated!
>
> Greg in MA