A municipal 911 PSAP wants both header-based policy and reverse-path checks on the Internet edge. How do ACLs and uRPF complement each other?
Select an answer to reveal the explanation.
Short Explanation
ACLs are the written guest policy; uRPF is the "does your return address make sense?" check. Using both is layered security, not an either-or choice.
Full Explanation
A municipal 911 PSAP that wants both header-based policy and reverse-path checks on the Internet edge should treat ACLs and uRPF as complementary controls. ACLs enforce explicit permit/deny policy on addresses and ports, while uRPF drops packets whose sources fail FIB-based reverse-path checks. Together they provide layered spoof and policy protection: ACLs express civic intent for services and sources, uRPF catches many spoofed sources that might otherwise match a broad permit. Claiming uRPF replaces all ACLs so permit/deny entries become unnecessary once strict mode is on fails because RPF does not implement port/service policy such as allowing jump-host SSH while denying SMB. Asserting ACLs and uRPF cannot coexist on the same interface under any IOS release used in ENARSI fails conceptually—they are commonly combined on edge interfaces. Saying uRPF only filters TCP SYNs while ACLs only filter UDP fails because neither tool is restricted that way; both can affect broader traffic classes based on their respective mechanisms. Exam caveat: layered controls can double-drop traffic, complicating root cause—know whether a drop was ACL or RPF before changing civic edge policy under incident pressure. Operational check: deploy anti-spoof/service ACLs and appropriate uRPF mode for the path symmetry, verify both are active on the Internet edge, test legitimate PSAP flows, and use ACL counters plus RPF drop visibility to attribute failures correctly.