ME3400E - 802.1ad, QinQ, EVC

Mark Pace Balzan · ‎09-23-2013

Hi,

Ive been reading through documentation and posts in the forum about L2 tunneling EVC etc.. but some items are still confusing so if some people out there can shed some light would be great.

Im using 7600 with ES+ cards and ME3400E, Aim is to setup a L2 tunnel for a customer over an SP network (I run the SP network)

Q1. Am I correct in saying that QinQ is proprietary version of the technology while 802.1ad is the standardised version but they essentially achieve the same thing (abit like ISL and dot1q vlans) and you would use either one or the other ?

For QinQ config like this on the customer facing port should do it

int g0/1

switchport mode dot1q tunnel <-- (setup the l2 tunnel for C tagged frames and apply S vlan)

switchport access vlan 5 <-- the S vlan to apply as the second outer tag

l2 protocol tunnel <-- tunnel not process L2 control frames like STP, CDP

For 802.1ad we achieve the same by saying:

int g0/1

ethernet dot1ad uni s-port <-- (setup the l2 tunnel for C tagged frames and apply S vlan)

switchport access vlan 5 <-- the S vlan to apply as the second outer tag

l2 protocol forward <-- tunnel not process L2 control frames like STP, CDP

Q2. 8021.ad uses a different ethertype 0x88a8 instead of the standard 0x8100 for QinQ which is also used by v802.1q tagged frames - what are the advantages of using a different ethertype, and also what are the advantages of using dot1.ad compared to QinQ ethertype aside ? Im aware that 0x8100 frames arriving on a 0x88a8 port are considered untagged. Im just not seeing the reason to deploy with 0x88a8. Would apreciate any feedback from people using this in their daily operations and some pointers to any useful docs.

Q3. The above config are lets say a more traditional config approach. I see that it is possible to also do this with EVC and service instances.

Would something like the below achieve the same as what I mention in Q1 above ?

int g0/1

service instance 1

encapsulation dot1q

bridge domain 5

Is this functionally equivalent to QinQ since we match all tagged frames, we do not pop the vlan tag, but place in bridge domain 5 for forwarding where vlan 5 can be considered as the S vlan ?

Likewise the 802.1ad equivalent would be:

int g0/1

ethernet dot1ad uni s-port

service instance 1

encapsulation dot1q

bridge domain 5

thanks

Mark

patrick.demuynck · ‎12-18-2013

I'm far from an expert in Metro Ethernet, but I was facing similar questions

as you (see also https://supportforums.cisco.com/thread/2200327), so let me give a try :

> Q1. Am I correct in saying that QinQ is proprietary version of the
> technology while 802.1ad is the standardised version but they
> essentially achieve the same thing (abit like ISL and dot1q vlans) and
> you would use either one or the other ?

I would agree with that.

> Q2. 8021.ad uses a different ethertype 0x88a8 instead of the standard
> 0x8100 for QinQ which is also used by v802.1q tagged frames - what are
> the advantages of using a different ethertype, and also what are the
> advantages of using dot1.ad compared to QinQ ethertype aside ? Im
> aware that 0x8100 frames arriving on a 0x88a8 port are considered
> untagged. Im just not seeing the reason to deploy with 0x88a8. Would
> apreciate any feedback from people using this in their daily
> operations and some pointers to any useful docs.

The advantage of 0x88a8 is compatibility with non-Cisco equipment,

especially if that equipment doesn't have a 'Cisco compatibility'

feature to use 0x8100 for the S-tag. The Metro Ethernet forum

(MEF) always consistently mentions 0x88a8 for the outer

encapsulation (S-tag).

You can also check out a Cisco document, namely

http://www.cisco.com/en/US/docs/switches/metro/me3600x_3800x/software/design/guide/CE2.0_certification_v1.pdf

From what I see there, the 7600 and ASR9000 can interface to unknown Metro Ethernet

via dot1ad. I believe that the ME3800X cannot, have seen no options for "dot1ad"

or "0x88a8" (I mean that probably they can only use 0x8100 for outer tag and you

can't interface them to non-Cisco equipment).

> Q3. The above config are lets say a more traditional config approach.
> I see that it is possible to also do this with EVC and service
> instances.

Agreed.

I will follow this post, please add to this post if you learn something new.

Patrick