An animal-control HQ PE should not import every extranet VPNv4 route advertised in the autonomous system. What control limits which VPN routes that PE accepts?
Select an answer to reveal the explanation.
Short Explanation
RT filtering is the bouncer at the PE door: if the route’s RT isn’t on the guest list, it does not get into the VRF. Animal-control HQ should not collect every extranet just because the RR has them. IGP metrics and PHP are the wrong tools for VPN membership.
Full Explanation
VPNv4 route acceptance at a PE is governed by whether a route’s extended-community RTs match the VRF’s import policy. Route-target filtering lets an animal-control HQ PE install only the extranets it is entitled to, conserving memory and enforcing topology instead of importing every VPNv4 route visible in the AS.
Lowering IGP metrics on PE loopbacks so unwanted VPNv4 paths become unreachable does not replace import-RT policy. Enabling PHP only on that PE so extranet labels drop before VRF installation misunderstands PHP and VPN membership. Assigning one RD for all extranets so duplicates suppress at the RR does not correctly limit which extranets a PE imports.
Exam caveat: RT import policy is the bouncer for VPN membership—IGP tricks and PHP are the wrong tools.
Operational check: configure explicit import RTs for animal-control HQ, show that non-matching extranets stay out of the VRF, monitor table size, and review RT filters whenever a new extranet is approved. For civic operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand which failure modes were avoided for citizen-facing services. Re-validate after the next platform or policy change.