frnkblk at iname
May 6, 2012, 10:12 AM
Post #15 of 20
Yes, we have jumbo frames turned on.
Re: Preserving double-tagged traffic on ICX6100
[In reply to]
As one of the regular NANOG posters writes, products should work with the
element of "least surprise". "Least surprise" in this case would be for
Brocade to do nothing with the inside tags. VLAN aggregation is a specific
feature in which tagged traffic (inner tags) on switch A is dropped off on
an untagged port on switch B so that switch B can wrap an outer tag around.
That does not describe our use of the double-tagged traffic.
As wrote in another email, Brocade has already an answer: they generated a
defect for this issue and is working on a fix. There's no doubt in my mind
that this is a bug.
On a side note, it's always mystified me why vendors don't make switches
which allow untagged traffic to be picked up on an edge port and multi-tag
it with TPID of my choice, and vice-versa. For example:
description edge port
tag 135 8100 1089 9100
description trunk uplink
tagged 1089 9100
which could expect traffic to come in untagged on 1/1/1, but push two tags
on, namely inner tag 135 with TPID 8100 and outer tag 1089 with TPID 9100,
and that would go out the switch on 1/1/24.
From: igor [at] ergens [mailto:igor [at] ergens] On Behalf Of Igor Ybema
Sent: Sunday, May 06, 2012 3:36 AM
To: Frank Bulk
Cc: foundry-nsp [at] puck
Subject: Re: [f-nsp] Preserving double-tagged traffic on ICX6100
> - I'm not sure how that feature is relevant to our situation. Typically
> Q-in-Q feature is used to describe a mechanism to take in double-tagged
> traffic and deliver it non-tagged on access ports. That's not what we're
> trying to do.
You are using jumbo frames then? I do hope so or else your max frames
will not get switched also.
> - while I think we could find a way to do that with the two other vendor
> product that participate in this double-tagged circuit, I'd rather not
> deviate from the default to compensate for this bug in ICX6100. It's
> mystified me why some L2 products seem to choke on double-tagged traffic
> when all it should care about is the outer tag.
Yes you are right. A switch which supports vlan's should only care
about the src mac, dst mac, (outer/first) ether type and vlan tag. It
should not in any way look into the payload of the frame. So, from
this perspective you could call it a bug what the ICX is doing.
However, with aggregated-vlan feature disabled I think it could be
plausible that the switch destroys the inner tag. It could be that the
switch is trying to be 'smart' and because it is seeing a vlan tag
which is not configured on the switch it destroyes that tag. But, when
following this thought, why this is only happening to broadcasts and
not to unicast is strange then.
So on each switch (aggregation or access) carrying q-in-q frames I
would always enable aggregated-vlan (and jumbo frames). And if I
notice strange behaviours after that, then I would call brocade and
let them figure out.
But we shall wait for Brocade to come with an answer. They, more then
anyone else, can tell us what the expected behaviour is and give us a
bugfix if needed.
foundry-nsp mailing list
foundry-nsp [at] puck