Mailing List Archive

IEEE 802.1ad vs Cisco's Q-in-Q
Does anybody know when (and if) is Cisco going to support the offical 802.1ad?

If i understand correctly, Cisco's Q-in-Q implementation doesn't support different ethertypes for
inner & outer tags, which probably means that Cisco switches don't care whether a frame is single or
double-tagged, as long as the outer ethertype is 0x8100 (or equal to the one configured).

So, are there any performance limitations when a double-tagged frame passes through a 6500 (or other
switch)? What happens if the inside of every frame has to be checked (because of QoS) and a
double-tagged frame is found? Does the switch send the double-tagged frame to the cpu because it
cannot recognise the protocol inside it?

--
Tassos
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
> Does anybody know when (and if) is Cisco going to support the offical
> 802.1ad?

No idea.

> If i understand correctly, Cisco's Q-in-Q implementation doesn't
> support different ethertypes for inner & outer tags, which probably
> means that Cisco switches don't care whether a frame is single or
> double-tagged, as long as the outer ethertype is 0x8100 (or equal to
> the one configured).

Why would you *want* to check this? Are you sure other vendors check?

We have a significant installed base of Extreme switches using a non
8100 Ethertype for the outer tag. It's a royal PITA to use, and we're
moving all new installations to simply using 8100 for outer and inner
Ethertypes. Much more flexible, saves us lots of headaches. We have
assumed from the start that the switches only look at the Ethertype
of the outer tag, and based our network architecture on that.

> So, are there any performance limitations when a double-tagged frame
> passes through a 6500 (or other switch)? What happens if the inside of
> every frame has to be checked (because of QoS) and a double-tagged
> frame is found? Does the switch send the double-tagged frame to the
> cpu because it cannot recognise the protocol inside it? -- Tassos

As far as I know the outer tag is checked, and that's it. Nothing from
the inner tag is checked. No performance issues with double tagged
frames, because the switches simply inspect the outer tag and forward
based on that.

If you need equipment which can look at both outer and inner tag, Cisco
will be happy to sell you GSR linecards which can do it, Juniper has the
IQ PICs (which we use heavily), etc. You might be able to find high end
switches which can do something sensible based on inspection of both
outer and inner tags - but don't expect "normal" switches to do it.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
sthaug@nethelp.no wrote on 14/11/2006 9:39 ìì:
>> Does anybody know when (and if) is Cisco going to support the offical
>> 802.1ad?
>
> No idea.
>
>> If i understand correctly, Cisco's Q-in-Q implementation doesn't
>> support different ethertypes for inner & outer tags, which probably
>> means that Cisco switches don't care whether a frame is single or
>> double-tagged, as long as the outer ethertype is 0x8100 (or equal to
>> the one configured).
>
> Why would you *want* to check this? Are you sure other vendors check?
>

I think 802.1ad defines 0x88a8 as the prefered outer tag (different from 0x8100 of 802.1q), which
makes it much easier for switches to know whether this is a single or a double-tagged frame.
And i think Extreme & Juniper follow this.

On the other hand, Cisco uses what i would call a "hack", since it seems to support double-tagging
by just using the single-tagging code (checking if the ethertype is 8100).

IMHO, the best solution would be to be able to configure both inner/outer ethertypes manually.

> We have a significant installed base of Extreme switches using a non
> 8100 Ethertype for the outer tag. It's a royal PITA to use, and we're
> moving all new installations to simply using 8100 for outer and inner
> Ethertypes. Much more flexible, saves us lots of headaches. We have
> assumed from the start that the switches only look at the Ethertype
> of the outer tag, and based our network architecture on that.

That's exactly what i'm also doing (common inner/outer ethertype), but some ip dslam vendors seem to
have problems setting them equal (although this is not 100% verified yet).

>
>> So, are there any performance limitations when a double-tagged frame
>> passes through a 6500 (or other switch)? What happens if the inside of
>> every frame has to be checked (because of QoS) and a double-tagged
>> frame is found? Does the switch send the double-tagged frame to the
>> cpu because it cannot recognise the protocol inside it? -- Tassos
>
> As far as I know the outer tag is checked, and that's it. Nothing from
> the inner tag is checked. No performance issues with double tagged
> frames, because the switches simply inspect the outer tag and forward
> based on that.
>

I'm actually talking about switches which are capable of looking into the ip header. So, what
happens if i'm using a class-map which is matching on src/dst ip and the ip packet is double-tagged?

I know that Cisco switches cannot check the ip header in double-tagged frames (that is not a problem
for me), but don't they get "confused" when they look into single & double-tagged frames since they
cannot differentiate them?

From what i know, when 0x8100 is found as ethertype in a frame, the switch just looks 4 bytes after
the tag, in order to get the frame length. But what happens if there is another tag there instead of
the length? Do all switches know how to react in such situations?

> If you need equipment which can look at both outer and inner tag, Cisco
> will be happy to sell you GSR linecards which can do it, Juniper has the
> IQ PICs (which we use heavily), etc. You might be able to find high end
> switches which can do something sensible based on inspection of both
> outer and inner tags - but don't expect "normal" switches to do it.
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

--
Tassos
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
> I think 802.1ad defines 0x88a8 as the prefered outer tag (different
> from 0x8100 of 802.1q), which makes it much easier for switches to
> know whether this is a single or a double-tagged frame. And i think
> Extreme & Juniper follow this.

Extreme uses 0x88a8 as the default outer Ethertype, but newer switches
let you configure any value, including 0x8100.

Juniper uses 0x8100 as the default outer Ethertype.

> On the other hand, Cisco uses what i would call a "hack", since it
> seems to support double-tagging by just using the single-tagging
> code (checking if the ethertype is 8100).

The Cisco solution may be a hack, but it's a very *useful* hack. Given
our operational experience, we would probably not use 0x88a8 for the
outer Ethertype even if all equipment supported it - it's simply not
flexible enough.

It *might* be useful to have a different Ethertype than 0x8100 for the
outer tag if you could define this on a per-port basis. For all switches
we've looked at so far, however, it is defined on a per-switch basis.

> IMHO, the best solution would be to be able to configure both
> inner/outer ethertypes manually.

I agree that it is useful to be able to configure the outer Ethertype.
I don't see the use for configuring the inner Ethertype.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
Tassos,



At this point we've went through this exercise. We have numerous Extreme
networks switches. Extreme follows the standard, while Cisco is
apparently choosing not to. Do a quick search while logged in at
www.cisco.com for the following: 0x88a8 or 88a8 and you will get exactly
zero results for either. I find this a bit disturbing when this is in
fact THE standard for vman/qinq/svlan/whatever xyz vendor chooses to
call it. Juniper among other companies have also standardized on 0x88a8.
It would seem to me that if Cisco wants to be a true leader in metro
Ethernet, they would support the standard that has been around for some
time now.



We do have a large install base of Cisco, Juniper and Extreme. We have
configured all of our Extreme switches and Juniper routers with vman
ethertype 0x8100 simply because we have too much Cisco gear around that
apparently will never support the newer standard.



If anyone can tell me that I'm wrong, I would love to see the
information where Cisco either does or is planning on supporting 0x88a8.




Ninja edit: I finally found one " Cisco document " , that appears to be
a PPT from Networkers, that references 88a8



http://72.14.209.104/search?q=cache:lD-ZYAawAbAJ:https://www.ciscoeventr
eg.com/ciscoexpo2005/switzerland/presentations/VJ-Rotary/6_IP_NGN_Metro_
Ethernet_Carrier_Services.ppt+0x88a8+802.1ad&hl=en&gl=us&ct=clnk&cd=11



Thanks,

Bryan F



_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
Here is another strange thing:

In CatOS:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00801dd67e.html#wp999435

"When a tunnel port receives tagged customer traffic from an 802.1Q trunk port, it does not strip
the received 802.1Q tag from the frame header; instead, the tunnel port leaves the 802.1Q tag
intact, adds a 1-byte EtherType field (0x8100) and a 1-byte length field, and puts the received
customer traffic into the VLAN to which the tunnel port is assigned. This EtherType 0x8100 traffic,
with the received 802.1Q tag intact, is called tunnel traffic."


In IOS:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00800da6fc.html#wp1013415

"When a tunnel port receives tagged customer traffic from an 802.1Q trunk port, it does not strip
the received 802.1Q tag from the frame header; instead, the tunnel port leaves the 802.1Q tag
intact, adds a 2-byte Ethertype field (0x8100) followed by a 2-byte field containing the priority
(CoS) and the VLAN. This Ethertype 0x8100 traffic, with the received 802.1Q tag intact, is called
tunnel traffic."


Am i missing something here (8100 hex = 1 byte?); Are these 2 totally different implementations?

Tassos


sthaug@nethelp.no wrote on 14/11/2006 11:45 ìì:
>> I think 802.1ad defines 0x88a8 as the prefered outer tag (different
>> from 0x8100 of 802.1q), which makes it much easier for switches to
>> know whether this is a single or a double-tagged frame. And i think
>> Extreme & Juniper follow this.
>
> Extreme uses 0x88a8 as the default outer Ethertype, but newer switches
> let you configure any value, including 0x8100.
>
> Juniper uses 0x8100 as the default outer Ethertype.
>
>> On the other hand, Cisco uses what i would call a "hack", since it
>> seems to support double-tagging by just using the single-tagging
>> code (checking if the ethertype is 8100).
>
> The Cisco solution may be a hack, but it's a very *useful* hack. Given
> our operational experience, we would probably not use 0x88a8 for the
> outer Ethertype even if all equipment supported it - it's simply not
> flexible enough.
>
> It *might* be useful to have a different Ethertype than 0x8100 for the
> outer tag if you could define this on a per-port basis. For all switches
> we've looked at so far, however, it is defined on a per-switch basis.
>
>> IMHO, the best solution would be to be able to configure both
>> inner/outer ethertypes manually.
>
> I agree that it is useful to be able to configure the outer Ethertype.
> I don't see the use for configuring the inner Ethertype.
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
sthaug@nethelp.no wrote on 14/11/2006 11:45 ìì:

>
> It *might* be useful to have a different Ethertype than 0x8100 for the
> outer tag if you could define this on a per-port basis. For all switches
> we've looked at so far, however, it is defined on a per-switch basis.
>

12.2(17a)SX (and later) seems to provide this functionality:

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a0080160a05.html#wp1055118

>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

--
Tassos

_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
Re: IEEE 802.1ad vs Cisco's Q-in-Q [ In reply to ]
> At this point we've went through this exercise. We have numerous Extreme
> networks switches. Extreme follows the standard, while Cisco is
> apparently choosing not to. Do a quick search while logged in at
> www.cisco.com for the following: 0x88a8 or 88a8 and you will get exactly
> zero results for either. I find this a bit disturbing when this is in
> fact THE standard for vman/qinq/svlan/whatever xyz vendor chooses to
> call it. Juniper among other companies have also standardized on 0x88a8.
> It would seem to me that if Cisco wants to be a true leader in metro
> Ethernet, they would support the standard that has been around for some
> time now.

802.1ad came out in 2005. I'm not normally a great Cisco defender - but
popular switches like the 3560 and 3750 series came out earlier than this
and I can't blame Cisco for not supporting 802.1ad on those series of
switches. After the standard came out it would certainly be good to see
new models of switches suuporting it.

Also, I find it hard to see how you can say that Juniper has standardized
on 0x88a8 since the outer Ethertype you get by default is:

- 0x9100 on the E series (ERX)
- 0x8100 on the M series

However, it is correct that the Juniper routers/interfaces which let
you configure double tagging also has the *option* of using 0x88a8 for
the outer Ethertype.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/