09-02-2014 04:32 AM
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
Solved! Go to Solution.
09-08-2014 01:47 PM
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
09-08-2014 01:47 PM
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
09-08-2014 01:56 PM
Many thanks Robert,
Looks perfect to me.
09-09-2014 02:54 AM
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.
09-10-2014 06:36 AM
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 ?
09-10-2014 07:05 AM
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
09-10-2014 07:54 AM
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 ?
09-10-2014 08:22 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide