×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Verification and troubleshooting for Dot1Q Tunneling at Customer Edge

Answered Question
Sep 2nd, 2014
User Badges:

Hi Guys, 

Is there any way we can verify dot1q tunnel besides, checking the arp tables or cdp nei, 

for example, if the tunnel goes down or having issue, how would you troubleshoot ? 

so I am wondering how can we verify and troubleshoot our setup ( e.g for IPSec and GRE, we do have verification )

Note: I am at the customer end (not interested in service provider network in this scenario)

Many thanks 

Muhammad

 

Correct Answer by Robert Correiro about 2 years 11 months ago

Hi muhammadrafi,

Here are a few commands which you may find useful. 

Command
 
Purpose
 

clear l2protocol-tunnel counters

 

Clear the protocol counters on Layer 2 protocol tunneling ports.

 

show dot1q-tunnel

 

Display IEEE 802.1Q tunnel ports on the switch.

 

show dot1q-tunnel interface interface-id

 

Verify if a specific interface is a tunnel port.

 

show l2protocol-tunnel

 

Display information about Layer 2 protocol tunneling ports.

 

show errdisable recovery

 

Verify if the recovery timer from a Layer 2 protocol-tunnel error disable state is enabled.

 

show l2protocol-tunnel interfaceinterface-id

 

Display information about a specific Layer 2 protocol tunneling port.

 

show l2protocol-tunnel summary

 

Display only Layer 2 protocol summary information.

 

show vlan dot1q tag native

 

Display the status of native VLAN tagging on the switch.

 

You can also refer to this config guide, which is the source of the above command table:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/... 

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
Robert Correiro Mon, 09/08/2014 - 13:47
User Badges:
  • Cisco Employee,

Hi muhammadrafi,

Here are a few commands which you may find useful. 

Command
 
Purpose
 

clear l2protocol-tunnel counters

 

Clear the protocol counters on Layer 2 protocol tunneling ports.

 

show dot1q-tunnel

 

Display IEEE 802.1Q tunnel ports on the switch.

 

show dot1q-tunnel interface interface-id

 

Verify if a specific interface is a tunnel port.

 

show l2protocol-tunnel

 

Display information about Layer 2 protocol tunneling ports.

 

show errdisable recovery

 

Verify if the recovery timer from a Layer 2 protocol-tunnel error disable state is enabled.

 

show l2protocol-tunnel interfaceinterface-id

 

Display information about a specific Layer 2 protocol tunneling port.

 

show l2protocol-tunnel summary

 

Display only Layer 2 protocol summary information.

 

show vlan dot1q tag native

 

Display the status of native VLAN tagging on the switch.

 

You can also refer to this config guide, which is the source of the above command table:

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/... 

Philip Olsson Tue, 09/09/2014 - 02:54
User Badges:

If you are the customer of this service the verification you can do is that you can pass the agreed types of data. Depending on the service provider you may or may not be allowed to pass some data types.

 

But a simple test to verify is to ping trough your connection and verify that you can pass the the agreed MTU with DF-bit set. 

For example,

 

PC -> switch tags packet ->  provider -> switch untags packet -> PC

and on windows: ping -l 1472 -f x.x.x.x 

is a basic test that you can pass "lan mtu 1500" across your infrastructure. This type of testing can be automated.

 

"Robert Correiro " s commands is targeted to the service provider.

Muhammad Rafi Wed, 09/10/2014 - 06:36
User Badges:

Hey Philip, 

 

Thanks for adding the comments, we normally we defined the mtu 1504, 4 byte extra for the additional vlan right ? so why are you pinging with 1472 ? 

Philip Olsson Wed, 09/10/2014 - 07:05
User Badges:

Hi,

When throwing MTU sizes around, you need to be specific on what you really talk about, in my example, its a ping on windows, where you define:

-l Size : Specifies the length, in bytes, of the Data field in the Echo Request messages sent.

You dont define the ethernet data field ( ip mtu, normally 1500 ) but the length of the data field of the icmp echo request. 

 

/ Philip

 

 

 

Muhammad Rafi Wed, 09/10/2014 - 07:54
User Badges:

Phil,

thank you for your further explanation, 

 

you are right my apology, I got confused myself, didnt see it from PC, 

 

so by defining the length of 1472 means, I should be able to go through with the 1500 mtu (8byte ICMP+ 20Bytes IP) but we have defined 1504 for our qinq setup 

 

so when I increase the length of the packet by adding 4 more byte and it showing me the expected error of fragmentation. 

C:\Users\mrafi>ping -l 1476 -f x.x.x.x

Pinging x.x.x.x with 1476 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

so how does this prove qinq is working ? 

 

 

Philip Olsson Wed, 09/10/2014 - 08:22
User Badges:

Your windows machine probably does not allow a larger MTU than 1500.

If you bump your MTU on the windows host you should be able to test 1476.

 

Or just use a external switch/environement to add the other 4 bytes.

Actions

This Discussion

Related Content