cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2294
Views
0
Helpful
7
Replies

Verification and troubleshooting for Dot1Q Tunneling at Customer Edge

Muhammad Rafi
Level 1
Level 1

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

 

1 Accepted Solution

Accepted Solutions

Robert Correiro
Level 1
Level 1

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/release/12-2_35_se/configuration/guide/scg1/swtunnel.html 

View solution in original post

7 Replies 7

Robert Correiro
Level 1
Level 1

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/release/12-2_35_se/configuration/guide/scg1/swtunnel.html 

Muhammad Rafi
Level 1
Level 1

Many thanks Robert,

 

Looks perfect to me.

Philip Olsson
Level 1
Level 1

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.

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 ? 

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

 

 

 

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 ? 

 

 

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: