QinQ question on 3560

johnelliot6 · ‎02-24-2011

Hi,

We currently puchase ethernet services from a provider which are presented to us as vlans on trunk port:

interface GigabitEthernet0/51
description GIGE_ICAP_TO_PROV_A
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 128,133,182,241,243-247,316,352,403,420,421,423
switchport trunk allowed vlan add 425,426
switchport mode trunk
switchport nonegotiate
speed nonegotiate
mls qos trust dscp
storm-control broadcast level 20.00
storm-control action trap
no cdp enable
spanning-tree bpdufilter enable
spanning-tree guard root

NB - Client ethernet tails are not being tagged with these vlans by client equipment.

We have a new client that is wanting to run multiple vlans over a single eth access to us - The provider has indicated that we can provide this type of service(Not having to engage provider for each new vlan the client needs to add), if we convert our trunk port to QinQ - but they have not provided any further details.

My questions are:

- Does the 3560 support QinQ (I believe they do)

- Wouldn't converting our existing trunk access to QinQ "break" all the exsting client services being trunked across it? (Or is it possible to continue running the link as a trunk allowing those vlans, but also run it as a dot1q-tunnel?(Wouldnt think so?)

If anyone is doing something similiar to what the provider has suggested, would really appreciate more info on how it is done.

Thanks in advance.

Roman Rodichev · ‎02-24-2011

You can do QinQ on 3560, you could even do it on 3550

this is what your setup *COULD* look like, assuming VLAN 10 and 20 are your customer's vlans. VLAN 600 will be used to transport your customer's VLANs through your service provider.

(some switch : switchport mode trunk ) ===== trunk (vlan 10, 20) ===== (switchport mode dot1q-tunnel + switchport access vlan 600 : your CE switch that you showed config for : switchport mode trunk + switchport allowed vlan add 600 ) ======== trunk (bunch of vlans) ====== (service provider) ====== trunk (vlan 600, yes it needs to be a trunk) ==== (switchport mode trunk + switchport allowed vlan add 600 : CE Switch : switchport mode dot1q-tunnel + switchport access vlan 600) ===== trunk (vlan 10, 20) ===== (switch mode trunk : customer switch)

johnelliot6 · ‎02-24-2011

Thanks.

Our current setup(for these eth services) we are simply trunking them up to a 7200 for L3.

So its:

7200 dot1q subint --(trunk)-- 3560 --(trunk)-- provider_a --(access port)-- client edge

So in the above, Im a little unsure if it is possible to implement what the provider is suggesting without breaking existing client connections?

Roman Rodichev · ‎02-24-2011

on your side, can you build a second physical connection between 7200 and 3560

if you can't add another switch on the client side, you would need to ask your provider to enable QinQ on the access port. Provider might not be able to do it depending on the capabilities of their PE device.

it would look like this

7200 dot1q subint -- (trunk) --------------- 3560 --- (trunk) --- provider QinQ --- trunk --- client edge

dot1q subint -- (new trunk) -- QinQ /

Kishore Chennupati · ‎02-24-2011

Hi,

With dot1q tunneling , you would map your customer vlan to an own inner vlan and ship across the network.

Your Switch would connect to the client switch

===Your switch config

Sw-PE-1#sh run int f0/15
interface FastEthernet0/15
switchport access vlan 12
switchport mode dot1q-tunnel
l2protocol-tunnel cdp
l2protocol-tunnel vtp
no cdp enable
end

=====client switch config

Sw-CE-1#sh run int f0/18
interface FastEthernet0/18
switchport trunk encapsulation dot1
switchport trunk allowed vlan 34,10
switchport mode trunk <<<< This has to be a trunk port
end

Sw-PE-1(config)# interface gigabiethernet1/1/1   << your port going back into the core

Sw-PE-1(config-if)# switchport vlan mapping dot1q-tunnel 12 34 46  <<34 is the customer vlan and 46 is the inner
vlan you use in your network to ship the client vlan

HTH,

Regards,