Monthly Archives: October 2015

SWITCH 300-115 1.4 Configure and verify trunking

1.4.b dot1Q

SWITCH 300-115 1.4 Configure and verify trunking

1.4ab Trunking
I added this section for completeness.
   Cisco provides a number of means to facilitate trunking between switchports of different switches, one of which is ISL or inter-switch link which I am not going to discuss as it will be eventually deprecated altogether, someday.
   If you had 5 vlans on two switches each numbered 6 through 10, and port 6 on one switch was attached to port 6 on the neighbor switch, and each port 6 was a vlan 6 member, you would have communication between the 2 switches only through vlan 6 on those ports. Like wise for ports 7, 8, 9 and 10. It would therefore require 5 cables between the switches to support each vlan. This would be a very crude design and not very efficient. Or as it is said, this does not scale very well.
As seen here:
   A trunk allows the passing of multiple vlans between switches on the port or ports that have been configured as trunks, for all vlans by default, or a selection of  vlans.
   Cisco provides a number of means to facilitate trunking between the switchports of switches.
   With a trunk in place we can now use the ports 6 through 10 reserved for passing vlans to support hosts on both ends instead, as in this diagram depicting support for vlan 6:
   However, how will switch 2 know that the frame from switch 1 vlan 6 is destined for its vlan 6 through the trunk. Vlan tagging, or dot1q is that solution, but that’s the next segment. Back to trunking.
   Cisco provides a mechanism called DTP or Dynamic Trunking Protocol to automatically allow ports to become trunks. You could also manually configure the trunk on both ends without the need of DTP.
   DTP will negotiate a trunk if both sides are set for dynamic-desirable, or dynamic-desirable on one side and dynamic-auto on the other, but will not form a trunk if both sides are set for dynamic-auto because both sides want the other to make a move, and it won’t happen without at least one side being desirable. You can also set one side as trunk and the other to negotiate either desirable or auto and a trunk will form. Or you can forget all about neogiation by simply using trunk mode on both sides. This is  deterministic and foregoes the negotiation process, and also relieves the trunk of the burden of DTP traffic, as well as a particular type of attack known as vlan hopping.
   It goes without saying that a port set as access will never form a trunk no matter the condition of the other port. You can also set trunking to off, as well as nonegotiate. Off sets the port back to access, and nonegotiate means the port will not negotiate DTP and will set the operational mode to off.


See the video for examples:


SWITCH 300-115 1.4 Configure and verify trunking

1.4.ab Trunking

There is no specific reference to Trunking in the1.4 section of the switch blueprint, so I am adding my own; 1.4ab




SWITCH 300-115 1.6 Configure and verify spanning tree

1.6.a PVST+, RPVST+, MST


In order to facilitate a loop free topology a root switch is elected as a reference point for the entire tree. This is accomplished by establishing a BID (bridge id) for every switch in the diameter. A bridge ID is an 8 byte construct composed of 2 bytes of priority, and 6 bytes MAC address. Further, the priority is segmented into 4 bits priority and 12 bits extended system id, where the extended system id is the VLAN ID.


Spanning tree enabled protocol rstp

Root ID Priority 32778

Address 0009.b73f.ce80

Cost 12

Port 64 (Port-channel2)

Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)

32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1

here is the binary math with the example vlan 10

1000 0000 0000 1010

32768 + 8 + 2