A civic data center prefers readable ACL names such as BLOCK-GUEST-SMB on WAN routers instead of only numeric lists. What is the main operational trade-off highlighted by named extended ACLs?
Select an answer to reveal the explanation.
Short Explanation
Names are sticky notes on the clipboard—same rules, easier for the next engineer to read at 2 a.m. They don't unlock secret powers numbered ACLs lack.
Full Explanation
A civic data center that prefers readable ACL names such as BLOCK-GUEST-SMB on WAN routers instead of only numeric lists should understand that named ACLs improve operational clarity and editing workflow while still providing the same permit/deny matching semantics as numbered extended ACLs. The main operational trade-off highlighted is human factors and maintainability—not a different forwarding engine. Named lists make intent obvious during incidents and simplify remarking/editing without changing how top-down match and implicit deny behave. Claiming named ACLs uniquely enable IPv4 filtering while numbered ACLs cannot match TCP ports fails because numbered extended ACLs have long matched TCP ports. Asserting named ACLs disable the implicit deny so operators must never add deny statements fails conceptually: named ACLs retain implicit deny. Saying numbered ACLs alone support time-ranges while named ACLs cannot reference clocks fails because time-ranges can be referenced from named ACEs as well. Exam caveat: readability does not prevent shadowing or wrong direction—named ACLs can still be misordered or misapplied on civic edges. Operational check: migrate critical extended policies to descriptive named ACLs, preserve identical ACE order and application points, verify hit counters after cutover, and document names so on-call engineers can identify BLOCK-GUEST-SMB without decoding list numbers at 2 a.m.