Multiple aggregated links between devices impossible?

Hello,

According to 'The All-New Switch Book', only a single 802.3ad aggregated link is possible between a pair of devices. *

Can someone please shed light on why this is?

My read (skim) of 802.3 suggests that so long as devices choose different operational keys for each aggregation, then there should be no reason multiple links don't work. The relevant sections seem to be

43.3.6.1 and 43.6.1.

Maybe there's another way. I'm using Cisco products, and have the following goals:

- 2 aggregated links, each one is tagged, and they're carrying different VLANs so that unrelated applications can't impact each other's available bandwidth.

- I want to use LACP because PAGP doesn't support standby links. A standby link is important to me so that loss of a single link doesn't diminish the available throughput, and also doesn't cause unpredictable redistribution of traffic when the link count changes.

If I had to, I could run one aggregation with PAGP and one with LACP, because only one of the aggregations really requires a consistent link count.

Thanks!

/chris

  • note that I haven't actually /tried/ configuring the aggregations. The network exists only on a whiteboard right now.
Reply to
chris
Loading thread data ...

Here's what Mr Seifert and Mr Edwards had to say on the matter, in section 9.5.1:

"IEEE 802.3ad specifies a method for vendor-interoperable link aggregation under the following constraints:

- Only one multiple-link aggregation is supported between a pair of devices. "

Additionally, there's a footnote: "There can be any number of non-aggregated individual links between a pair of devices."

Curiously, Cisco assures me that creating multiple LACP aggregations between a pair of Cisco switches is a supported configuration.

While I'm relieved that I don't need to redesign this aspect of the network, I remain puzzled by the contradiction.

/chris

Reply to
chris

(snip)

(snip)

"Vendor interoperable" means between devices from different vendors.

The standard doesn't say it will work between Cisco and any other companies switch, nor does Cisco.

-- glen

Reply to
Glen Herrmannsfeldt

Glen,

You snipped out the relevant part of the quote from Rich's book. Vendor interoperable isn't important to me. I'm only using one vendor.

The key phrase was "Only one multiple-link aggregation is supported"

So, Rich says I can only have one link per the standard, but Cisco says I can have two standards-compliant links.

This still looks like a contradiction to me. Am I misunderstanding something?

Perhaps you're arguing that many 802.3ad aggregations are permissible between Cisco devices, but only one 802.3ad aggregation is possible if the devices are from different vendors?

That doesn't make much sense to me. It seems to suggest that Cisco's technique for bringing up multiple aggregations is NOT 802.3ad compliant. Afterall, if something is standards-complaint, then vendor- interoperability should be a foregone conclusion.

Thanks for your input. The discussion is pretty much academic at this point because Cisco has blessed the configuration, but I still hope to clear up my misunderstanding.

/chris

Reply to
chris

chris wrote: (snip)

I am more used to this question as regarding programming languages, but I think it works here.

That the standard only requires one between different vendors.

Given that wording, maybe it should say "802.3ad compliant with the extension of allowing..." Vendors often supply extensions to standards, where the standard specifies the minimum.

In general when using an extension to the standard, you should be sure to document it such that others who follow you will know what you did. Someone later might decide to replace one Cisco device with one from another vendor, not knowing that an extension is being used.

There used to be discussion here about using 10baseT at 150m. The standard requires 100m on Cat3 cable, and the numbers pretty much allow for 150m on Cat5 cable. That is, as an extension to the standard. Doing that will cause problems later on if someone wants to run, for example, 100baseTX through the cable.

The standard tells you what will work. It doesn't guarantee that not following the standard will result in a system that won't work.

-- glen

Reply to
Glen Herrmannsfeldt

Well, what the standard expects to work anyway :)

Reminds me a little of "supported vs works" in HPspeak:

Supported, known to work -> warm fuzzies all around Supported, not known to not work -> an HPite may be in trouble Supported, known to not work -> an HPite is in trouble Unsupported, known to work -> lucky today, unlucky tomorrow? Unsupported, not known to not work -> there but for the grace of Turing Unsupported, known to not work -> no, it was not deliberate ;-)

Where in this case "Supported" would be "Supported by the standard" and "work" would be "vendor makes work" or somesuch.

rick jones

Reply to
Rick Jones

Is that speculation based on the text I quoted, or is the standard explicit on this point?

If it's the latter, the the question is settled (I'd appreciate a citation though). I don't see any indication that Cisco is doing anything beyond vanilla 802.3ad (they call it LACP, afterall), but anything is possible. OTOH, why would they bother? They had a proprietary aggregation mechanism before LACP.

So non-compliance (to a degree anyway) *is* what you were getting at.

It's not completely clear to me that I am using something nonstandard, but the point is well taken, and I appreciate your taking the time to mention it.

Well that was a fun sentence!

Thanks again.

/chris

Reply to
chris

chris wrote: (snip, I wrote)

Based on your quote. I have an original "Switch Book" but haven't looked this up. Then again, maybe it is only in the newer one.

-- glen

Reply to
Glen Herrmannsfeldt

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.