A municipal library consortium enables Guest Shell on compact Catalyst access switches and must avoid starving forwarding resources. Which operational concern is most important?
Select an answer to reveal the explanation.
Short Explanation
Guest Shell is a roommate on a small library switch—great until it eats all the groceries (CPU/RAM) and the switching stops. Set resource limits and keep its networking tidy so patrons still get packets.
Full Explanation
Library consortium Guest Shell on compact Catalyst access switches must not starve forwarding resources. Constraining IOx/Guest Shell CPU, memory, and networking so application hosting cannot deplete resources needed for switching and control-plane stability is the primary operational concern. Small access switches have limited headroom compared with larger aggregation platforms.
Maximizing Guest Shell to consume all DRAM and disabling CEF to free ASIC capacity endangers production forwarding. Bridging Guest Shell onto every user VLAN without rate limits or VRF separation expands blast radius and attack surface. Running continuous stress compiles during peak checkout hours invites outages.
Exam caveat: resource profiles and platform limits differ; a safe lab setting may still be unsafe on older access SKUs. Operational check: set explicit CPU/memory limits, place Guest Shell in a management VRF, baseline forwarding and control-plane CPU during script runs, and abort if thresholds exceed library SLOs. Prefer controller-side jobs when the work is not truly local. Record the chosen control and the rejected alternatives in the municipal change record so future on-call staff understand which failure modes were avoided for city services.