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

[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.

-- 
Peter