A fleet-garage PE is at risk of exhausting memory because one chatty CE floods excessive prefixes into its VRF. What control best protects the PE while keeping the L3VPN design intact?
Select an answer to reveal the explanation.
Short Explanation
A chatty CE is a firehose aimed at PE memory. A maximum-prefix limit is the shutoff valve — keep the VRF, keep the VPN, just refuse the flood. Collapsing into the global table or killing MP-BGP "solves" nothing useful for the garage design.
Full Explanation
PE memory and control-plane stability depend on bounding how many routes a VRF accepts from a CE or into the VRF RIB. For a fleet-garage PE facing a chatty CE, configuring a VRF maximum-prefix or PE-CE maximum-prefix limit rejects excess routes or dampens the session while keeping the L3VPN design intact. That guardrail is standard PE-CE hygiene.
Removing the VRF and moving the CE into the global table so prefix counts “no longer matter” destroys isolation. Disabling MP-BGP on that PE so VPNv4 cannot accumulate harms the whole VPN role of the PE. Identical RDs across garage VRFs so duplicates collapse do not provide controlled flood protection and break uniqueness.
Exam caveat: maximum-prefix is the right conceptual control for noisy CEs—do not “solve” scale by collapsing VRFs or killing MP-BGP.
Operational check: set appropriate maximum-prefix thresholds and actions, alert on approaches to the limit, test with a route burst in a lab window, and keep the garage VRF and MP-BGP design unchanged. 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.