Trunking_Elephants

They even know to use redundant trunks, these elephants may just be future CCNP’s!

I will get default behaviors and some cable info out of the way immediately, now that we’ve had a nice glimpse into the beauty of nature Trunking out of love, and are back to CCNP SWITCH success and VLAN Trunking:

  • By default, a Trunk is in all VLANs, so it will allow ALL Data across its link (including Broadcasts that we want to minimize being sent)
  • Modern switches do not require a cross-over cable necessarily, they can auto-detect and adjust on newer models, so cabling “type” is not necessarily as issue
  • Port numbers don’t need to match between Trunks for them to work, so it is best practice absolutely, but not needed for the Trunk link to work
  • Interfaces in Trunks will not show in “sh vlan brief” output

I made the cabling point in bold as I tested a straight-through cable to connect two switches, and the ports came right up, so “officially” switches do require a cross-over cable but they really don’t.

I am not sure if they will test for that on exam day cause the only switch platforms that can run 15.x will probably work with any cable, so I can’t quite advise there.

So I took a picture of the front of the switches after adjusting cabling for the lab, and noticed that STP had put a not yet configured Trunk port into blocking (to prevent switching loops as STP does) and wanted to show a before and after picture here.

First, here is the “logical topology” I drew in Crayon on a napkin for the lab we are working with:

Trunking_Top

***If you haven’t worked with VLANs for awhile, note that each switch will have a single port in two different VLANs, not putting both ports in a single local VLAN on each side – I did this in a tired stupor and troubleshot it for longer than I should have***

So we (will) have Trunk links that will go between ports 10-10 and 20-20 between SW1 and SW2, and here is the current state of all port lights currently, STP shown blocking Port 20 on SW2 once the connections established:

20170818_225042

 

This is STP (Spanning Tree Protocol) at work putting a port in blocking, because the switches detect redundant paths / links between the two switches, and puts one into a mode called “blocking” to prevent switching loops while green ports are in “forwarding” mode – Much more on that to come.

Now to configure the trunks between the two switches and get a bit of lab work in!

There are two steps to getting trunks going, as if you go right for it you will get this error on the console line yelling at you:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/10
SW1(config-if)#switchport mode trunk
Command rejected: An interface whose trunk encapsulation is “Auto” can not be configured to “trunk” mode.
SW1(config-if)#switchport mode trunk ?
<cr>

So there are no more sub-commands there to remedy that error, it is in “switchport trunk …” sub-commands I’ll display here:

SW1(config-if)#switchport trunk ?
allowed Set allowed VLAN characteristics when interface is in trunking

mode

encapsulation Set trunking encapsulation when interface is in trunking mode

native Set trunking native characteristics when interface is in

trunking mode

pruning Set pruning VLAN characteristics when interface is in trunking

mode

SW1(config-if)#switchport trunk encap ?
dot1q Interface uses only 802.1q trunking encapsulation when trunking

isl Interface uses only ISL trunking encapsulation when trunking

negotiate Device will negotiate trunking encapsulation with peer on

interface

SW1(config-if)#switchport trunk encap dot
SW1(config-if)#switchport mode trunk
SW1(config-if)#
*Mar 1 01:02:39.472: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/10, changed state to down
ASR#2
[Resuming connection 2 to sw2 … ]

*Mar 1 01:02:30.705: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down

*Mar 1 01:02:31.704: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/10, changed state to down
*Mar 1 01:02:34.732: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/10, changed state to up
SW2#
*Mar 1 01:03:03.748: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up

This first set highlighted in red are the initial modifiers / sub-commands for the “switchport trunk …” configuration on an interface, as you can see you can allow / disallow VLANs and other characteristics of the trunk link.

The second set highlighted in blue is the output is what we needed, I chose to go with dot1q for my encapsulation, and it allowed “switchport mode trunk” to work without an issue.

A behavior to be aware of when creating new trunks is also highlighted in red

I saw the actual VLAN 1 interface bounce when I created the first trunk, and wasn’t sure if it was because I used Dot1Q encapsulation or what, or if it only bounced on the remote switch, etc.

It only seemed to do it when I activated that first trunk port on SW1, and on SW2 the actual interface for Vlan1 bounced, which I assume would bounce all users for a micro-second, so something to be aware of that I noticed.

So lets take a look at our switch lights now:

20170819_042705

One quick note I found in the output of a show run on SW1, I accidentally typed Fa1/0/1 instead of 10, and configured port 1 as a trunk. I removed “switchport mode trunk” however the configuration of the trunk stayed behind, so always confirm the entire configuration of something is gone before proceeding:

 

!
interface FastEthernet1/0/1
switchport access vlan 12
switchport trunk encapsulation dot1q

switchport mode access
!

So I fixed that up, lets send some pings around to see if everything is working:

From R1:

R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms
R1#ping 10.0.0.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.3, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#ping 10.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#

From R3:

R3#ping 10.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.4, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/2/4 ms
R3#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R3#ping 10.0.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R3#

Just to verify that everything is where it should be and so on, we will check out the VLAN “table” to make sure things look right there:

SW1#sh vlan br

VLAN Name Status Ports
—- ——————————– ——— ——————————-
1 default active Fa1/0/2, Fa1/0/4, Fa1/0/5
Fa1/0/6, Fa1/0/7, Fa1/0/8
Fa1/0/9, Fa1/0/11, Fa1/0/12
Fa1/0/13, Fa1/0/14, Fa1/0/15
Fa1/0/16, Fa1/0/17, Fa1/0/18
Fa1/0/19, Fa1/0/21, Fa1/0/22
Fa1/0/23, Fa1/0/24, Gi1/0/1
Gi1/0/2
12 VLAN0012 active Fa1/0/1

34 VLAN0034 active Fa1/0/3

1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup
SW1#

I just intuitively numbered the corresponding ports in the different VLANs, but it passed the ping test and looks good so I’ll check out “sh int trunk” for my missing ports in that list:

SW1#sh int trunk

Port Mode Encapsulation Status Native vlan
Fa1/0/10 on 802.1q trunking 1
Fa1/0/20 auto isl trunking 1

Port Vlans allowed on trunk
Fa1/0/10 1-4094
Fa1/0/20 1-4094

Port Vlans allowed and active in management domain
Fa1/0/10 1,12,34
Fa1/0/20 1,12,34

Port Vlans in spanning tree forwarding state and not pruned
Fa1/0/10 1,12,34
Fa1/0/20 1,12,34
SW1#

I decided to use two different encapsulations on the two trunks as can be seen above, and I will end this post here, as there is plenty more to discuss, and I am too tired to be absorbing anything I may learn going forward into the morning 🙂