Hands-On Lab: Setting Switchports to Dynamic Trunking Modes

This hands-on lab configures switchport dynamic desirable and dynamic auto modes, demonstrating how Dynamic Trunking Protocol automatically negotiates whether a link becomes a trunk or remains an access port, and covers why relying on DTP is generally discouraged in production networks.

Dynamic Trunking ProtocolSwitchport Dynamic DesirableSwitchport Dynamic Auto

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure both dynamic desirable and dynamic auto switchport modes between two switches, observe which combinations successfully negotiate a trunk automatically via DTP, and identify the one combination that does not.

Lab Purpose

Before explicitly configuring switchport mode trunk, as done in earlier labs, engineers should understand how Dynamic Trunking Protocol (DTP) can negotiate this automatically — and, just as importantly, why most production environments disable DTP entirely in favor of explicit configuration for security and predictability.

Lab Topology

Switch1 ---- Gi1/0/24 ---- Gi1/0/24 ---- Switch2

Link currently has no explicit switchport
mode configured on either side

Task 1: Configure Dynamic Desirable on Both Sides

Set Gi1/0/24 on both switches to dynamic desirable, and verify whether a trunk forms.

Task 2: Configure Dynamic Auto on Both Sides

Change both sides to dynamic auto, and verify whether a trunk forms this time.

Task 3: Configure One Side Desirable and the Other Auto

Set Switch1 to dynamic desirable and Switch2 to dynamic auto, and verify the result.

Task 4: Identify the Non-Negotiating Combination

Explain which combination of dynamic modes does NOT result in a trunk forming, based on the pattern observed.

Solution and Verification

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport mode dynamic desirable

Switch2(config)# interface gigabitethernet1/0/24
Switch2(config-if)# switchport mode dynamic desirable

Switch1# show interfaces gigabitethernet1/0/24 switchport | include Mode

Administrative Mode: dynamic desirable
Operational Mode: trunk
-- Desirable + Desirable successfully negotiates
-- a trunk, since both sides actively offer

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport mode dynamic auto

Switch2(config)# interface gigabitethernet1/0/24
Switch2(config-if)# switchport mode dynamic auto

Switch1# show interfaces gigabitethernet1/0/24 switchport | include Mode

Administrative Mode: dynamic auto
Operational Mode: static access
-- Auto + Auto does NOT form a trunk -- neither
-- side actively initiates, so both remain
-- passively waiting and default to access mode

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport mode dynamic desirable

Switch2(config)# interface gigabitethernet1/0/24
Switch2(config-if)# switchport mode dynamic auto

Switch1# show interfaces gigabitethernet1/0/24 switchport | include Mode

Operational Mode: trunk
-- Desirable + Auto DOES form a trunk, since
-- the desirable side actively initiates and
-- the auto side responds when asked

Key Takeaway

DTP negotiation mirrors the PAgP negotiation logic covered in an earlier EtherChannel lab: Desirable+Desirable and Desirable+Auto both form a trunk, while Auto+Auto never does, since neither side takes the initiative. In practice, most security-conscious production networks disable DTP entirely (using switchport nonegotiate alongside explicit trunk or access mode), since relying on automatic negotiation on an access port an attacker could physically reach represents an unnecessary risk.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه