Best Ethernet switch device for trunking support??

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
7 answers Last reply
More about best ethernet switch device trunking support
  1. 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
  2. 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.
  3. 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.
  4. 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
  5. 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
    :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.

    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.
  6. 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
    > :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.
    >
    > 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)
  7. 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
Ask a new question

Read More

Ethernet Switch Support Networking