Deploying NEW-VRF-001 for Full Host Reachability
Short answer
D Include 'route-target both auto evpn' in the VRF configuration to automatically handle EVPN route import and export for full reachability.
Question
- 
Key Takeaways
The exam tests the ability to distinguish between global BGP EVPN configuration and per-VRF route-target policies required for cross-pod L2/L3 connectivity.
This question evaluates the configuration of VXLAN EVPN to ensure full host-to-host reachability across pods in a data center, specifically focusing on VRF and route-target settings. It establishes that 'route-target both auto evpn' is the critical command for enabling automatic import/export of routes within the VRF context.
Common mistake: Candidates often select 'advertise l2vpn evpn', which is a peering-level command used to advertise the EVPN address family to neighbors, rather than the VRF-specific policy needed for route exchange.
Expert Analysis
Why the Answer Is Correct
To achieve full reachability for all hosts regardless of pod location, the VRF must automatically import and export EVPN routes. The command route-target both auto evpn under the VRF configuration achieves this by generating a unique Route Distinguisher (RD) and Route Target (RT) based on the VRF name, ensuring consistent labeling across the fabric. This allows the EVPN control plane to correctly propagate MAC/IP reachability information between leaf switches.
Why the Other Options Are Wrong
host-reachability protocol bgp is not a standard Cisco NX-OS command for this purpose; reachability is handled via the EVPN signaling mechanism. address-family l2vpn evpn configures the router to participate in the EVPN address family but does not define how routes are imported or exported into the VRF. advertise l2vpn evpn is typically configured under the BGP neighbor/peer configuration to advertise the EVPN AFI/SAFI, not within the VRF definition itself.
Community Comment Notes
Community consensus strongly supports Option D. One commenter noted that while 'advertise l2vpn' is valid, it belongs under the peering configuration with spines, whereas the exhibit implies VRF context commands. Another user referenced official Cisco documentation confirming that VRF-based RT automation is key for multi-pod consistency. The majority correctly identified that the VRF needs its own routing policy to accept routes from other pods.
Official Reference
This link opens the official vendor documentation in a new tab.
Exam Strategy
Always check where the command is applied in the hierarchy. If the requirement is about VRF-specific route exchange (import/export), look for route-target commands inside the VRF configuration block, not global BGP or neighbor blocks.
Frequently Asked Questions
Why is 'advertise l2vpn evpn' incorrect for VRF deployment?
What does 'both auto evpn' do in the route-target command?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Discussion 3 contributions
Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.
From public community threads 3
-
CoAsT_x 👍 1 Answered DI will go with D. lurker mentions C, but the 'adevertise l2vpn' command is under peering with the spine in the link b44c199 shared. and the link b44c199 shared, D is listed under the vrf context configuration and the exhibit is missing these two commands.
-
b44c199 👍 1https://www.cisco.com/c/zh_tw/support/docs/ip/border-gateway-protocol-bgp/200952-Configuration-and-Verification-VXLAN-wit.html
-
lurker8000 👍 1I'll go with C.
Reader comments & corrections
No reader corrections yet — spotted an error or have a note? Share it below.