A water utility runs overlapping RFC1918 spaces in separate VRFs that both need Internet egress. Why enable VRF-aware NAT?
Select an answer to reveal the explanation.
Short Explanation
Two departments both love 10.0.0.0/8 inside their own VRF bubbles—fine until they share an Internet door. VRF-aware NAT translates each bubble on the way out so the overlaps do not collide in the global outside world.
Full Explanation
Water-utility VRFs with overlapping RFC1918 space both needing Internet egress require VRF-aware NAT so each VRF’s overlapping addresses translate independently into unique outside addresses. VRF-aware NAT keeps identical inside spaces isolated while enabling safe egress without merging tables. That is precisely why the feature exists in multi-VRF civic designs.
Merging both VRFs into a single global table without NAT collides overlapping prefixes. Claiming overlapping addresses become impossible once VRFs exist misunderstands that VRFs isolate routing but do not invent unique addressing for NAT outside. Replacing IPsec with NAT as the only inter-VRF confidentiality mechanism confuses address translation with encryption.
Exam caveat: each VRF typically needs its own NAT configuration/pool or outside interface context; leaking routes between VRFs is a separate design choice. Operational check: place overlapping hosts in two VRFs, apply VRF-aware NAT, confirm distinct outside translations, and verify return traffic routes back to the correct VRF. Utility VRF-aware NAT pools must be sized and monitored per VRF so one department’s egress growth cannot exhaust translations for another overlapping space.