Wednesday, February 1, 2017

TroubleShooting IEEE 802.1Q Trunks

                       As we continue to follow the path through our Switch infrastructure, we may need to troubleshoot our Trunks and in this topic, we wanna talk about troubleshooting IEEE 802.1Q Trunks infect Cisco puts little impasse on ISL Trunks
                         Cisco used to really push the Inter-Switch Link variety of Trunking that was a Cisco Proprietary Trunking type, it added 30 Bytes to every Trunked frame, contrast that with a DOT1Q Trunk, we call it DOT1Q for short
                      DOT1Q Trunk add 4 Tag Bytes to frame and those Tag Bytes can identify what Vlan a frame associated with it, there is an exception to that though and the exception is the Native Vlan, a Native Vlan is a Vlan that we can designate on a Trunk as being Untagged, frame that in Native Vlan do not get a tagged, let’s take a movement and talk about some of the common troubleshooting issues that might arise as were we following the path from one Switch to another Switch, Switches are often interconnected with Trunks because Trunks can carry traffic for multiple Vlans.
                    First up we might have mismatched Encapsulation type on each end of the frame, one end of the Trunk might be set to DOT1Q the other end might be set to ISL, that’s not gonna work, we might have Mismatched Trunk Modes in each end of the Trunk.
                          Do you remember how can Trunk dynamically be established on Cisco Catalyst Switches, we can use DTP to dynamically form a Trunk
                     We can be a Modes like Dynamic Desirable, Dynamic Auto, we could say that we just Trunking, no dynamic about we just Trunking and if we are for example, set to Dynamic Desirable we gonna be sending DTP frames to the devices at other end of the Trunk and that Port far end of the Trunk is set to a Dynamic Mode, Dynamic Desirable or Dynamic Auto it will Dynamically form a trunk, if we say that one end of the links is operating in Trunk Mode that mode will also send DTP frames to the far end and if the other end is set to Dynamic Desirable or Dynamic Auto then a Trunk is gonna be formed, i give you two scenarios where Trunk would not be formed
                   If either end of the link were set to an Access Mode a Trunk would not formed over that link, we use Access Mode when we say switchport is connecting out to End device like a PC for example, so Trunk is not gonna be formed if either or both ends of the link is set to Access Modes or both ends of the links might be set to Dynamically Auto
                     Dynamically Auto does not initiate DTP frames if it receives DTP frames its more than willing to form a Trunk but if doesn’t suggest it to the first place and if you got 2 dynamic Auto ports there are just sitting there waiting for somebody else to suggest that Trunk be formed and Trunk will never be formed
                    Those are couple of condition where the Trunk would not be formed another issue we could have is Mismatched Native Vlan, if the Native Vlan on one Switch is set to 1 and the Native Vlan on another Switch at the other end of the link is set to 100 that could be an issue, think about what would happen, if i send the traffic out of Switch A and I said that on Switch A is my Native Vlan was 1, since its being send out of the Native Vlan we would not add those 4 Tag Bytes to it it would be in untagged frame, when the far end Switch we call it Switch B when it received an untagged frame it would say Oh! by definition untagged frame is a member of my Native Vlan which is 100, we just did something called Vlan Hopping
                            We sent the Vlan 1 frame over a trunk and it was interpreted as a Vlan 100 frame because the Native Vlan did not match on our different Switch, something else that would prevent traffic from flowing over a trunk if we may have gone in and Pruned off specific Vlans, may be for performance reason or may be Security reason, we said here are the specific Vlans allow on the trunk and do not allow any other Vlans
                      Now the we reviewed some of the common troubleshooting targets for a DOT1Q trunk let’s go Switch interfaces and tackle the Trouble Ticket dealing with DOT1Q Trunk, let’s assume that we have a Trouble Ticket.
                         Telling us that PC1 cannot communicate out to rest of the network it’s connected into Switch Sw1 and let’s assume we already check to make sure that Switch Sw1 is learning the Mac-Addresses for PC1, we have checked to make sure that the ingress Port on Switch Sw1 does belong to Vlan 300, Vlan 300 does exist but we having a challenge getting from Sw1 down to Sw2, we should have a trunk and no Trunk is being formed that we need to troubleshoot, let’s begin by verifying that we have no Trunks
Ø  Sw1#show interfaces trunk
We have no Trunk on Sw1, let’s start investigating why we don’t
Ø  SW#show interfaces fastetherent 1/013 switchport
                It looks like our Administrative Trunking Encapsulation type is DOT1Q what about the other side, let’s go to Switch Sw2
Ø  Sw2#show interfaces fastetherent 0/3 switchport
               And it says our Administrative Trunking encapsulation is negotiate so, here we not hard coded it to be DOT1Q or ISL, we said when a trunk is negotiated, we negotiated with far end and the far end set to DOT1Q, that’s looks OK
And next thing we want to check out is the Trunking Mode
                    In here you will see that the Administrative Mode is set to Dynamic Auto, we willing to form a Trunk here on Switch Sw2 if we receive a DTP frame, let’s go to Switch Sw1 and let’s revisit its output and take a movement, you wanna pause for seconds and view this output and see if you see anything that somewhat concerning about this output
  

                  Did you notice this side of link is also has an Administrative Mode of Dynamic Auto both side are set to Dynamic Auto, both sides are willing to form a Trunk if they receive a DTP frame however, neither side will initiate the formation of a Trunk neither side will initiate the sending of DTP frames and as a result Trunk is not being formed that obviable an issue let’s fix that
Ø  SW1#interface fastethernet 1/0/13
Ø  Sw1(config-if)#switchport mode dynamic desirable
Let’s re-issue the command
Ø  SW1#show interfaces trunk
                  It’s says that we have a Trunk on fastetherent 1/0/13, our mode is Desirable we are Trunking, let’s go to Switch Sw2
Ø  SW2#show interface trunk
                    Here fastetherent 0/3 we are Trunk our Mode is Auto but that the valid combination notice, the encapsulation is Negotiate(N)-802.1Q, we are Trunking let’s imagine that we told that PC1 still not get out to the rest of the network.
                 We might want to check the couple of things for example, do we have Native Vlan mismatch, our Native Vlan is 1 on Switch Sw2, what about Switch Sw1 the Native Vlan is also 1, that’s good we don’t have Native Vlan mismatch but is there anything else, looking at the output on SW1 that concerning to you again you might pause
     

            Did you notice that here on Switch SW1 we have list of Vlans that are allowed on this Trunk, we are allowing Vlans 100 and 200, PC1 its belong to Vlan 300 do we have the same output on Switch Sw2?
                  No Switch Sw2 says we allow all the Vlans this tell that we must be doing some Vlan Pruning on that Trunk on Switch SW1, let’s look at the Configuration and see exactly what we did.
Ø  SW1#show run
                 Switchport trunk allowed vlan 100,200, here say we allowed Vlan 100 and 200 i am not allowing Vlan 300 explicitly, and therefore i am pruning Vlan 300 that would explain why PC1 is not able to send traffic over this Trunk from Sw1 to Sw2 because its traffic is being Pruned of the Trunk, let fix that
Ø  Sw1#interface fastetherent 1/0/13
Ø  Sw(config-if)#default switchport trunk allowed vlan
It will allow all Vlan’s now we should be allowing all of our Vlans, let’s once again say
Ø  Sw1#show interfaces trunk
                 This look much better, now it says all of the Vlan’s are allowed on the trunk and now we have a result of our Trouble Ticket, PC1 is now able to communicate from Sw1 down to Sw2


   If You Like the Post. Don’t forget 
            to “Subscribe/Share/Comment”. Thank You.

0 comments:

Post a Comment