This will be the logical topology being created for R1 – R4 to communicate over Trunks!
Some things to get out of the way right off out of the gate regarding Trunks:
- 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.
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.
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:
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
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.
This is entirely explained in the Trunk Mode and Encapsulation DEEP DIVE post!
Now for the correct configuration for this type of Trunk is to set the encapsulation first:
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
So you notice the interface bounced, as now that one side is initiating the Trunk, this unconfigured side that is in “Dynamic Auto” by default negotiates with SW1 and forms a Trunk!
So lets take a look at our switch lights now:
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 🙂
The DEVNET GRIND! 