Hands-On Lab: Configuring SVI Autostate Exclude

This hands-on lab configures SVI autostate exclude on a monitoring port within a VLAN, preventing that single inactive port from incorrectly bringing down the SVI for an entire VLAN that still has other active member ports.

SVI Autostate ExcludeSVI Up/Down BehaviorMonitoring Port Exception

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

Lab Objective

Observe the default SVI autostate behavior where an SVI's state depends on having at least one active member port, add a SPAN destination (monitoring) port to a VLAN, and configure autostate exclude on it so its inactive link status no longer affects the SVI.

Lab Purpose

An SVI, discussed earlier in this series regarding inter-VLAN routing, normally goes down when no active port remains in its VLAN. A SPAN destination port, discussed earlier in this series regarding traffic mirroring, is often intentionally left disconnected until actively needed, and by default this single inactive port can incorrectly count against the VLAN's active port total, potentially bringing down an SVI that should otherwise remain fully functional.

Lab Topology

Switch1 (Layer 3 capable, VLAN 70)
  Gi1/0/5 ---- ServerA (active, VLAN 70)
  Gi1/0/10 ---- SPAN destination port
                (VLAN 70, currently
                disconnected/unused)

SVI: interface vlan 70, 192.168.70.1/24

Task 1: Configure the SVI and Verify Normal Operation

Configure interface VLAN 70 and confirm it is up while ServerA's port remains the only active member.

Task 2: Add the SPAN Destination Port to VLAN 70

Configure Gi1/0/10 as an access port in VLAN 70, intended for future SPAN monitoring use but currently disconnected.

Task 3: Observe the SVI Remains Unaffected While Other Ports Are Active

Confirm the SVI stays up, since ServerA's active port still counts.

Task 4: Simulate the Only Active Port Going Down

Shut down ServerA's port and observe the SVI going down as a result, since the disconnected SPAN port does not count as active.

Task 5: Configure Autostate Exclude and Verify SVI Stability

Restore ServerA's port, then configure autostate exclude on the SPAN destination port, and confirm the SVI's state now depends only on genuinely active data ports.

Solution and Verification

Switch1(config)# interface vlan 70
Switch1(config-if)# ip address 192.168.70.1 255.255.255.0
Switch1(config-if)# no shutdown

Switch1# show interfaces vlan 70 | include line protocol
Vlan70 is up, line protocol is up

Switch1(config)# interface gigabitethernet1/0/10
Switch1(config-if)# switchport mode access
Switch1(config-if)# switchport access vlan 70
-- Left physically disconnected, reserved
-- for future SPAN destination use

Switch1# show interfaces vlan 70 | include line protocol
Vlan70 is up, line protocol is up
-- Still up, since ServerA's port remains
-- active

Switch1(config)# interface gigabitethernet1/0/5
Switch1(config-if)# shutdown

Switch1# show interfaces vlan 70 | include line protocol
Vlan70 is up, line protocol is down
-- The SVI went down even though the SPAN
-- destination port "exists" in VLAN 70 --
-- a disconnected, unused port does not
-- count as active, so with ServerA also
-- down, zero active ports remain

Switch1(config)# interface gigabitethernet1/0/5
Switch1(config-if)# no shutdown

Switch1# show interfaces vlan 70 | include line protocol
Vlan70 is up, line protocol is up
-- Recovered once ServerA's port came
-- back up

Switch1(config)# interface gigabitethernet1/0/10
Switch1(config-if)# switchport autostate exclude

-- This port no longer participates in the
-- SVI's up/down calculation at all,
-- regardless of its own connection status

Switch1(config)# interface gigabitethernet1/0/5
Switch1(config-if)# shutdown

Switch1# show interfaces vlan 70 | include line protocol
Vlan70 is up, line protocol is down
-- The SVI still correctly reflects reality
-- (no genuinely active data ports remain),
-- but this demonstrates the SPAN port is
-- now excluded from the calculation entirely
-- rather than misleadingly contributing to it

Key Takeaway

By default, every access port assigned to a VLAN counts toward whether that VLAN's SVI is considered up, including monitoring ports intentionally left disconnected — switchport autostate exclude removes a specific port from this calculation, ensuring the SVI's state genuinely reflects whether real data-carrying ports are active, a detail worth configuring on any dedicated SPAN destination or similarly special-purpose port.

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

مقالات مرتبط

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.

ادامه