ISL only when enabling Q-in-Q and NAM monitor ports?

[rlortiz]

We were told that there is an issue (overlapping register usage) when you enable Q-in-Q and NAM Monitor ports and also use dot1q encapsulation that can cause traffic to stop flowing.

We had heard that you need to use ISL trunking instead of dot1q trunking for the service provider trunks.

We need to know whether or not we absolutely have to use ISL for the service provider trunking.

Can anyone verify and know of supporting documentation of this supposed restriction.

We've searched high & low and can't find anything to verify/support this.

The system environment is 6509s SUP720-3B 12.2(18)SXF and 12.2(33)SXI

NAM-2 running 4.0(1)

[Giuseppe Larosa]

Hello Richard,

not sure about NAM.

for 802.1 Q in Q on the service provider side you can force tagging of native vlan.

the only reason to use ISL in this context is that missing the native vlan concept you avoid the risk to expose the inner customer vlan tag.

forcing native vlan tagging allows to use 802.1Q external tags without this risk.

I would look at 12.2(33)SXI relase notes for suggestions.

you can find it (huge wen page..)

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html

I've found

CSCsu75546

but it is about span to NAM from port channel

CSCsv75511 applies to a NAM in standby chassis in a VSS pair

CSCsq85139 again in VSS

CSCso46210 again in VSS

CSCsk81396 : very important possible crash in 12.2(18)SXf

fixed in 12.2(18)SXF12

this has to be verified

CSCsk24272: as the one above to be verified fixed in 12.2(18)SXF12

CSCsd75273: cisco NAM vulnerability

solved in 12.2(18)SXF5

CSCse52951: as the one above

CSCsi11382: diag failures of NAM

solved in 12.2(33)SXH

I don't see a known bug related to QinQ and NAM module

Hope to help

Giuseppe