Securing Switch Interfaces for Wireless Monitoring Appliances

The scenario presents a conflict between the security requirement for traffic segregation and the connectivity needs of three specific network services: Cisco Spaces Connector, Cisco ISE, and Catalyst Center. The key constraint is that these services require both management access and telemetry data connectivity, while management and user (or telemetry) traffic must be segregated.

Option B suggests assigning the management VLAN as the native VLAN on trunk ports. While trunks do allow multiple VLANs to traverse a single interface, using the management VLAN as the native VLAN is a significant security anti-pattern. The native VLAN carries untagged traffic; if any device sends untagged frames, they would be placed into the management VLAN by default. This creates a risk of management plane exposure and violates the principle of least privilege and strict segregation. Furthermore, best practices dictate that the native VLAN should be an unused, dedicated VLAN for control protocols (like CDP/LLDP), not the active management VLAN.

Option D proposes configuring all interfaces as access ports in the management VLAN. An access port belongs to only one VLAN. If the switch interface connects to a server or appliance that needs to send/receive traffic in multiple VLANs (e.g., management VLAN for SSH/SNMP and a separate Telemetry/VLAN for streaming data), a single access port cannot accommodate this. The appliance would need to be isolated to just the management VLAN, meaning it couldn't receive telemetry data from other segments unless routed, which complicates the direct connection model implied here. However, looking closer at the specific requirements: "management and telemetry connectivity." If the telemetry data is destined for the same management IP but tagged differently, or if the appliance has multiple NICs, the switch port configuration changes. But typically, a single physical connection to a switch requires either trunking (if one NIC handles multiple VLANs via sub-interfaces or VLAN-aware OS) or multiple access ports (if multiple NICs are used).

Let's re-evaluate based on standard Cisco certification logic for this specific exam (350-101). The question asks what the engineer must use. The comment suggests B is correct because trunks allow separation. However, the native VLAN aspect is dangerous. Is there a better option? Option A (PortFast) helps with convergence but doesn't solve VLAN segregation. Option C (PAgP) is deprecated and rarely required.

Actually, the critical insight lies in how these specific appliances connect. Cisco Catalyst Center, ISE, and Cisco Spaces Connector are often deployed as virtual machines or appliances that might have a single network interface card (NIC) configured to handle multiple VLANs (VLAN tagging) OR they have separate NICs for Management and Data/Telemetry. If they have separate NICs, each NIC connects to an access port. If they share a NIC, they need a Trunk. The prompt says "connect... to the switch infrastructure" and "segregation of management and user traffic." It does not explicitly say the telemetry traffic is 'user' traffic, but rather 'telemetry'.

If we look at Option D again: "Configure all the interfaces as access ports in the management VLAN." If the telemetry traffic is considered part of the management plane for these monitoring tools, or if the telemetry is collected via a separate path not requiring VLAN traversal on the same link, this could be valid. But usually, telemetry is distinct.

Let's look at the "Native VLAN" trap in Option B. Using the management VLAN as the native VLAN is almost always incorrect in security-focused exams. It allows untagged traffic to bypass segmentation policies. Therefore, B is likely a distractor designed to look like a technical solution (trunking) but fails on security policy.

What about Option D? If the switch interfaces connect to the appliances, and the appliances are managed solely via the management VLAN, and telemetry is pulled from them (not pushed through a trunk to the switch for distribution), then access ports are sufficient. However, if the telemetry comes from clients/users to the collector, the collector needs visibility.

Wait, let's reconsider the wording. "Segregation of management and user traffic." If the telemetry is from users, it must be separated. If the switch port is an Access port in the Mgmt VLAN, it cannot carry User/Traffic VLANs. So the appliance would not see user traffic. This implies the appliance needs a Trunk to see both. But B is insecure. Is there a missing option? No.

Let's look at Option D more charitably. Perhaps the "telemetry connectivity" refers to the switch sending telemetry to the Catalyst Center via e.g., gRPC or SNMP over the Management VLAN. In many modern deployments, the management interface is the only one needed for the controller/collector to pull stats. The user traffic stays in its own VLANs. The Catalyst Center sits in the Mgmt VLAN and polls the devices. It does not need to bridge user traffic. Therefore, the switch interfaces connecting to these appliances only need to carry the Management VLAN. Configuring them as Access ports in the Mgmt VLAN ensures that no other VLANs (like Guest/User) can accidentally leak into the management plane through those ports. This satisfies the security mandate perfectly. Trunking (B) introduces the risk of VLAN hopping or native VLAN mismatches exposing the mgmt plane. PortFast (A) is irrelevant to segregation. PAgP (C) is irrelevant.

Therefore, Option D is the most secure and operationally sound choice for connecting management/telemetry collectors that primarily pull data, ensuring strict isolation of the management plane from user data planes on the access layer.