Best Ethernet switch device for trunking support??

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.

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

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

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

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.

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.

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.

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.

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

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.

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

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.

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

In article , Rich Seifert 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?

Check GarrettCom's Magnum 6K family of Managed Switches