RE: Trunk misconfiguration troubleshooting question

Show int trunk

Read the status codes above -

SW1#sh int trunk

Port Mode Encapsulation Status Native vlan
Gi1/0/5 on 802.1q trunking 999
Po1 on 802.1q trunking 999

You will have a trunking* for the mismatch.

You can also put your side in auto.

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of Andrew Thompson
Sent: Tuesday, September 11, 2012 10:49 AM
To: ccielab_at_groupstudy.com
Subject: Trunk misconfiguration troubleshooting question

Hi everyone,

I was going through some trunking labs and began to dig a little deeper into DTPs role in dynamically creating trunks. I found that DTP does not perform a negotiation in the true sense of the word. Each switch simply changes the port into a trunk if it receives a DTP frame with the right DTP status and type codes. Also I have found that the switches can give you a false trunk indication if incompatible encapsulation is used on either side.

An example this is when one end is configured as a static trunk with 802.1q and the other end is configured as a static trunk with ISL, they will both say they are in a trunking state even if no data is passing between the two switches due to the encapsulation mismatch. Also, I receive no error messages indicating the encapsulation mismatch.

I am trying to find out from a troubleshooting perspective, if you only have access to view the configuration on one end, how can you tell there is an encapsulaion mismatch? I believe the frames between the two switches are being dropped because of the encapsulation mismatch but don't know if a way to tell this is happening. Does anyone know of a debug or show command that can indicate the presence of an encapsulation mismatch on a statically trunked link?

I posted my findings on my wordpress site (
http://tweqouu.wordpress.com/2012/09/11/dynamic-trunking-protocol-dtp/) if anyone is interested.

Thanks for your time.

Regards,
Andrew

Blogs and organic groups at http://www.ccie.net
Received on Tue Sep 11 2012 - 15:35:05 ART