350-401 · Question #318
Refer to the exhibit. Which configuration allows Customer2 hosts to access the FTP server of Customer1 that has the IP address of 192.168.1.200?
The correct answer is A. ip route vrf Customerl 172.16.1.0 255.255.255.0 172.16.1.1 global. VRF Route Leaking Explanation Option A is correct because when a host in Customer2 needs to reach Customer1's FTP server (192.168.1.200), the router must know how to route back to the Customer2 network (172.16.1.0/24). The ip route vrf Customer1 172.16.1.0 255.255.255.0 172.16.1.
Question
Refer to the exhibit. Which configuration allows Customer2 hosts to access the FTP server of Customer1 that has the IP address of 192.168.1.200?
Exhibits
Options
- Aip route vrf Customerl 172.16.1.0 255.255.255.0 172.16.1.1 global
- Bip route vrf Customerl 172.16.1.0 255.255.255.0 172.16.1.1 Customer2
- Cip route vrf Customerl 172.16.1.0 255.255.255.0 172.16.1.1 Customerl
- Dip route vrf Customerl 172.16.1.1 255.255.255.255 172.16.1.1 global
How the community answered
(26 responses)- A77% (20)
- B8% (2)
- C4% (1)
- D12% (3)
Explanation
VRF Route Leaking Explanation
Option A is correct because when a host in Customer2 needs to reach Customer1's FTP server (192.168.1.200), the router must know how to route back to the Customer2 network (172.16.1.0/24). The ip route vrf Customer1 172.16.1.0 255.255.255.0 172.16.1.1 global command installs a static route inside Customer1's VRF pointing to the Customer2 subnet, using the global routing table as the exit path - this is the essence of VRF route leaking between a VRF and the global table.
- Option B is wrong because specifying
Customer2as the exit VRF would attempt to leak into Customer2's VRF, which is not where the return path needs to resolve. - Option C is wrong because pointing back to
Customer1itself creates a routing loop within the same VRF rather than leaking traffic out. - Option D is wrong because it specifies a /32 host route for the next-hop IP rather than the correct /24 network for the Customer2 subnet.
Memory Tip: Think of the
globalkeyword as a "bridge" between a VRF and the outside world - when traffic needs to cross VRF boundaries into the global table, always appendglobalto the static route command inside the originating VRF.
Topics
Community Discussion
No community discussion yet for this question.

