[c-nsp] QinQ config sample on Cisco 7600/6500

[Jon Harald Bøvre]

Hi
To add up with complete configurations:

define a transport vlan:
vlan 1285
name qinq-transport

configure QinQ port. Increase mtu (7600 does not inherit system mtu when 
configuring qinq port)
If any layer 2 transport required, configure this.
interface GigabitEthernet4/2
  description QinQ accessport
  switchport
  switchport access vlan 1285
  switchport mode dot1q-tunnel
  mtu 2200
  no cdp enable
  l2protocol-tunnel cdp
  l2protocol-tunnel stp
  l2protocol-tunnel vtp

Trunk transport vlan out of switch, and all the way to the other end of 
the tunnel: (all switches in between)
interface GigabitEthernet1/20
  description trunk
  switchport
  switchport trunk encapsulation dot1q
  switchport trunk allowed vlan 1285
  switchport mode trunk
  mtu 2200

and finally, if desired:

no mac-address-table learning vlan 1285



Jon






Den 8/26/2011 12:41 AM, skrev Peter Rathlev:
> On Thu, 2011-08-25 at 23:37 +0200, "Rolf Hanßen" wrote:
>> nobody an idea about this ?
>> Cannot be i am the first one trying to run/built such setup or migrating
>> from a platform that can do it. ;)
> Okay then, I'll bite. :-)
>
> On Wed, 2011-08-24 at 18:46 +0200, "Rolf Hanßen" wrote:
>> All I can find is several howtos saying to configure something like that
>> here on the customer port:
>> switchport
>> switchport mode dot1q-tunnel
> That sounds right.
>
>> When trying to set the above commands I get that error:
>> Gi4/48 doesn't support 802.1q tunneling.
>> My linecard is a WS-X6548-GE-TX, does that mean I cannot use QinQ here or
>> is there another way ?
> You can't AFAIK. There's no alternative that I know of, and the URL Stig
> posted describes the limitation. It's probably a limitation in the
> hardware ASICs. You would need another card, like the WS-X6748-GE-TX.
>
>> Same config on a WS-X6724-SFP is accepted.
>>
>> What I cannot find is where to set the vlan id that I use on my router
>> (i.e. the outer tag like 123 in the Froundry config).
>> Do I need to configure it like an access port or is there a setting
>> somewhere else ?
> You use "switchport access vlan<ID>". The naming might seem illogical
> but considering how Catalyst switches forward traffic it does make
> sense.
>
>> Port towards my equipment will be on a WS-X6704-10GE card.
>>
>> Furthermore I read about setting "vlan dot1q tag native" to support
>> forwarding of untagged frames.
>> How does this work if I do not know the vlans used by my custimer and
>> therefore cannot set an ID for untagged ?
> The "vlan dot1q tag native" has no effect on the customer facing port.
> It's on your core links it matters. (It's a global command though.)
> Cisco's "native VLAN" for a trunk is normally a VLAN that is untagged.
> There can of course be only one of these on a trunk. Untagged traffic
> received on a port is assumed to be in this VLAN.
>
> If you were to transport customer traffic in a VLAN that is used as a
> native VLAN on one of your trunks you could end up having the traffic go
> places you don't expect. Always tagging all traffic, even the "native"
> VLAN, would work around this problem. Always using a native VLAN not
> used for anything else would give you the same result.
>
>> Is untagged traffic dropped then or does it work anyway?
> The command means that untagged traffic is dropped on your core links,
> i.e. all trunks. Untagged traffic from a customer would carry only one
> tag but still be forwarded. The dot1q-tunnel ports are not considered
> trunks but access ports.
>
>> Concerning the MTU:
>> Do I need to increase the ports manually or is there a setting like
>> "aggregated-vlan" on some Foundrys that increases all MTUs for QinQ ?
> You would need to configure each switchport with a higher MTU, using
> something like:
>
> interface GigabitEthernet9/4
>   mtu 1508
> !
>
>> Does increasing the interface MTUs have some side-effects to take care
>> about if I do not touch the vlan mtu and the MTUs of the Layer3 vlan
>> interfaces ?
> I can't think of any side-effects. We always adjust the MTU of (non
> customer) links to whatever max the interface supports.
>
> You would only adjust the (physical) interface MTU. VLAN MTU (i.e. the
> "mtu<#>" command in vlan-config-mode) is irrelevant here; take a look
> at this page for an explanation (the "Note: There is no relationship
> between ..." section):
>
> http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml#cc4
>
> Do you have any L3 VLAN interfaces (SVIs) on these customer tunnel
> VLANs? That doesn't make sense to me, but maybe I misunderstand.
>
>> Concerning learning of MAC-adresses:
>> On Foundry (MLX/XMR) you can turn off learning of MAC-adresses on vlans
>> with only 2 ports ("transparent-hw-flooding") to save ressources.
>> Is there an equivalent that should be used on Cisco ?
> You can use "no mac-address-table learning vlan<#>". You can use it on
> a VLAN with more than one port, but it does mean that every frame is
> flooded.
>
>> Software used is 15.1(2)S, devices are only used for usual switching +
>> routing (OSPF+BGP, MTU 1500, no MPLS) at the moment.
> Caveat: My experience is almost exclusively with the 6500, not the 7600.
> But this specific use is probably the same, bar any software quirks.
>