Cisco Certified Network Associate (CCNA) 200-301 Practice Test 46
Question 450
HSRP group 10 uses R1 priority 120 and R2 priority 100. R1 failed; R2 became Active. R1 is now healthy and configured with `standby 10 preempt` (after any configured preempt delay). What observation verifies that higher-priority failback worked?
- The tracked upstream interface remains down on R1, causing its effective priority to stay below R2.
- `show standby brief` reports R2 as Active indefinitely after R1 has fully recovered and preempt delay has elapsed.
- A single client ping to the virtual gateway works, without identifying which router currently owns the Active role.
- `show standby brief` shows R1 Active and R2 Standby after the recovery/preempt conditions are met, with client reachability sustained.
Explanation
Correct Answer
D:With preempt configured and effective R1 priority above the current Active member, R1 may reclaim Active after its delay/conditions are satisfied. Check both roles explicitly through HSRP status and verify traffic remains operational across the transition.
Incorrect Answers
A:Interface tracking can reduce effective HSRP priority while an upstream fault persists; this would not demonstrate takeover by a recovered higher-priority R1.
B:R2 remaining Active could be legitimate if preemption is off or delayed, but it does not prove the specified higher-priority R1 reclaim behavior once preemption conditions are satisfied.
C:The virtual gateway can respond through either router. Successful ping alone validates some gateway reachability, not a role transition back to the desired preferred Active router.
Question 451
A network acceptance test follows this reported failure: The active router loses its WAN uplink but keeps HSRP priority unchanged, trapping users behind a gateway with no upstream path. Which verification most specifically demonstrates the repaired function rather than checking an unrelated feature?
- The failed WAN router stays Active at full priority while users still cannot reach upstream services.
- `show standby` lists peers but no tracked object or priority change is observed when the WAN is shut.
- Only a VLAN DHCP lease is checked with no WAN failure or role transition test.
- Under a controlled WAN failure, interface/object tracking lowers the former Active router’s effective HSRP priority enough for the healthy peer to take Active, and clients retain upstream reachability.
Explanation
Correct Answer
D:Correct failure handling depends on an effective tracked priority decrement plus role transition. The test must cover the WAN outage that previously left a blackholing Active, not just powered-up peer routers.
Incorrect Answers
A:HSRP without effective tracking can leave a router Active after its upstream WAN path fails. Clients continue sending to a gateway unable to forward off-site; proving repair requires the priority change and standby takeover under a controlled uplink failure.
B:A displayed group alone does not prove WAN-aware failover.
C:Local addressing can succeed behind an unusable upstream gateway.
Question 452
A branch routing engineer is validating a repair. Earlier, two VRRP routers on separate sides of a newly pruned shared VLAN both claim the Master role; their VRRP advertisements no longer reach each other, even though both physical uplinks stay up. Which postchange check most directly establishes the specific problem is resolved?
- Both routers still report Master after a VLAN pruning change that blocks advertisements.
- After restoring the shared VLAN, both VRRP peers receive advertisements and show one Master with the other Backup for the same virtual gateway.
- Both physical Ethernet links are up but VRRP advertisements never cross the shared VLAN.
- Client DNS lookups succeed through a different route while VRRP group remains dual-Master.
Explanation
Correct Answer
B:The dual-Master condition resulted from missing peer advertisement connectivity across a pruned VLAN. One coherent role view, plus functioning virtual IP client forwarding, establishes synchronization.
Incorrect Answers
A:VRRP Master election requires routers in the same VRRP group to receive the relevant advertisements across the shared VLAN. Blocking those frames by trunk pruning can cause independent Master claims; two Masters after the change are not healthy failover.
C:Carrier does not guarantee necessary L2 virtual-router control reachability.
D:Unrelated traffic does not prove correct virtual gateway election.
Question 453
The earlier fault was recorded as follows: After HSRP failover, endpoints continue ARPing for a physical router MAC rather than the shared virtual MAC and experience gateway disruption. After corrective work, which observation provides direct evidence that the affected function now behaves correctly?
- Client ARP remains pinned to R1’s physical MAC and gateway connectivity drops when R2 takes Active.
- Client ARP for the virtual gateway IP now resolves to the correct HSRP virtual MAC on both sides of a controlled switchover, and gateway pings continue.
- The client still uses a different router physical IP as its gateway, but the VIP has no observed ARP entry.
- Only an OSPF neighbor reaches Full while the gateway ARP cache remains wrong.
Explanation
Correct Answer
B:The original problem was a stale physical-MAC mapping for the VIP. Correct ARP identity and continuity through a role change directly test the virtual address ownership handoff.
Incorrect Answers
A:In a correctly operating HSRP failover, clients should use the virtual gateway association rather than a physical R1-specific mapping. Retaining the former physical MAC after R2 becomes Active can strand forwarding and is evidence the ARP/gateway issue remains.
C:A physical-gateway configuration does not validate repair of the expected virtual-MAC mapping.
D:Dynamic routing adjacency does not establish host-to-FHRP virtual MAC mapping.
Question 454
Two HSRP routers for VLAN 40 both report Active, and hosts intermittently learn different gateway MAC observations. Trunk counters are healthy, but captures show HSRP Hello packets from R1 never arrive at R2 on VLAN 40. Which evidence should be investigated to find the actual split-brain cause?
- Only the client ARP cache, because matching the virtual IP to one virtual MAC proves both routers hear each other.
- Only `show vrrp`, because VRRP state always describes an HSRP group's election.
- Only the router's tracked uplink priority decrement, because lost Hellos cannot affect active role selection.
- HSRP Hello reachability, group state and VLAN 40 Layer 2 carriage between the two routers.
Explanation
Correct Answer
D:HSRP peers use Hellos on the shared VLAN to coordinate Active and Standby roles. If both say Active and captures show R1 Hellos missing at R2, investigate VLAN 40 presence, trunk allowed lists, group number/version, filtering and the actual Hello packets in each direction. Compare `show standby` state and captured messages from both routers, not just host ARP entries. Restoring the control-plane path is the immediate isolation task; the root cause may be a pruned VLAN or incompatible group configuration. Afterwards verify stable one-Active/one-Standby behavior, host gateway reachability and failover. A duplicate virtual-MAC observation is a symptom, whereas the lost Hello path is the decisive mechanism in this evidence.
Incorrect Answers
A:A host's ARP entry can reveal the gateway's virtual IP and associated MAC, but it does not establish whether both HSRP peers receive control-plane messages. The same virtual MAC can be presented by different routers in abnormal dual-active conditions. Correlate ARP evidence with HSRP group state and Hello traffic on the shared VLAN instead of treating a correct-looking ARP mapping as conclusive.
B:HSRP and VRRP are distinct first-hop redundancy protocols with different commands and message formats. A VRRP status command is not an authoritative view of an HSRP group's Active/Standby state. The question explicitly states HSRP is configured, so troubleshooting should inspect HSRP group state and corresponding Hello packets. A different protocol's healthy status cannot clear this HSRP issue.
C:Interface tracking can change priority and trigger a valid HSRP failover, but the scenario explicitly demonstrates Hellos failing to cross the shared VLAN. If peers do not hear each other's HSRP control traffic, each may independently believe it should be Active. Tracking data alone cannot explain or dismiss that observed adjacency break. Inspect whether VLAN transport, filtering or protocol mismatch interrupts the group messages.
Question 455
A network acceptance test follows this reported failure: Half the PCs use R1's interface IP and half the virtual IP; only PCs using the physical IP fail during an R1 outage. Which verification most specifically demonstrates the repaired function rather than checking an unrelated feature?
- All relevant client DHCP option-3 or static gateway settings now name the shared FHRP VIP, not R1’s physical IP, and affected clients continue working through R1 failure.
- Half the clients still use R1’s physical IP and lose access during the controlled failure.
- The router group is healthy, but no client gateway settings are checked before declaring success.
- Only a DNS server option is changed while DHCP option 3 continues handing out a physical gateway IP.
Explanation
Correct Answer
A:The previous outage affected only clients bypassing the virtual gateway. Confirm per-client default route, ARP and actual failover reachability, not just the HSRP Active/Standby display.
Incorrect Answers
B:The original misconfiguration remains on those hosts.
C:An FHRP group can work while hosts are configured to bypass it.
D:DNS options cannot correct the actual first-hop next-hop address.
Question 456
A server at 10.10.40.7 must be reachable externally at the fixed address 203.0.113.17. R1 has inside Gi0/0 and outside Gi0/1 interfaces. The public address is routed toward R1. Which translation should be configured for stable one-to-one inbound and outbound mapping?
- `ip nat inside source list 10 interface Gi0/1 overload` with no permanent address assignment for the server.
- `ip helper-address 203.0.113.17` on the server VLAN, with NAT disabled.
- `ip nat inside source static 10.10.40.7 203.0.113.17`, with the correct `ip nat inside` and `ip nat outside` interfaces.
- `ip route 10.10.40.7 255.255.255.255 Null0` to force inbound packets to the server.
Explanation
Correct Answer
C:Static inside-source NAT defines a stable mapping between an inside local IPv4 address and an inside global IPv4 address. The command `ip nat inside source static 10.10.40.7 203.0.113.17` gives external peers a predictable destination for the server, assuming the global address is properly routed to the NAT router and security policy permits the service. Mark the source-facing interface as inside and the provider-facing interface as outside. Validate static translation with `show ip nat translations` and test service access with correct return routing. A static mapping does not replace an ACL or make an unrouted public address reachable by magic.
Incorrect Answers
A:An overload configuration translates multiple inside hosts through a shared outside address and normally distinguishes sessions with ports. It is useful for outbound client access, but it does not by itself reserve the requested fixed 203.0.113.17 one-to-one mapping for inbound server connections. A dedicated static NAT statement matches the reachability requirement.
B:The `ip helper-address` command relays DHCP and certain UDP broadcasts across routed boundaries. It does not establish a NAT translation between a private server and a public IPv4 address. An external client still needs an actual routed global address mapped to the internal server, plus permitted traffic.
D:A Null0 route discards traffic matching its destination prefix; it cannot forward inbound packets to a private server. Routing 10.10.40.7/32 to Null0 would make that destination unreachable on R1. Static inside-source translation and valid forwarding are required rather than an intentional blackhole.
Question 457
A site translates inside source addresses from `10.20.0.0/16` to a finite pool of four public IPv4 addresses using dynamic NAT without overload. It must support 20 clients making simultaneous translations. Which design change fixes the capacity shortfall?
- Provide at least 20 available one-to-one pool addresses for 20 simultaneous inside-local mappings, or explicitly choose PAT if sharing addresses by ports is permitted.
- Leave the four-address dynamic NAT pool unchanged and assume every client shares it automatically without overload.
- Add more inside-local RFC1918 host addresses but leave the constrained public NAT pool unchanged.
- Change only the switch VLAN name and keep the same NAT pool and translation method.
Explanation
Correct Answer
A:Dynamic NAT without overload assigns a distinct inside-global address to each concurrent one-to-one mapping. A four-address pool cannot give 20 simultaneous clients unique public sources; PAT uses ports to multiplex when appropriate.
Incorrect Answers
B:Ordinary dynamic NAT requires free global IPs for simultaneous mappings; sharing one address across many flows needs overload/PAT.
C:The exhausted resource is global translation slots/addresses, not available private LAN addresses.
D:Layer 2 VLAN labeling does not add globally translated addresses or enable PAT.
Question 458
R1's Gi0/0 connects to private 10.1.20.0/24 clients, while Gi0/1 connects to a provider. An inside-source NAT statement exists, but translations never appear. The configuration accidentally marks Gi0/0 as outside and Gi0/1 as inside. Which correction restores the intended translation direction?
- Increase OSPF cost on Gi0/0 while leaving the NAT inside/outside roles reversed.
- Enable `ip helper-address` on the outside interface to translate all inside-source traffic.
- Mark Gi0/0 `ip nat inside` and Gi0/1 `ip nat outside`, then check translation counters while inside clients initiate new traffic.
- Change the private clients to 169.254.0.0/16 so no translation is needed.
Explanation
Correct Answer
C:Inside-source NAT relies on knowing which traffic enters the inside domain and exits through the outside domain. Reversed interface NAT roles cause a correct-looking translation rule to match the wrong direction or not match the expected packets. Label Gi0/0 as inside for 10.1.20.0/24 clients and Gi0/1 as outside toward the provider. Confirm the access list or static match also includes intended sources, then initiate fresh sessions and inspect `show ip nat translations` and statistics. This diagnoses the missing translations without changing working IP routes or DHCP configurations; valid routing is still required to reach the outside destination.
Incorrect Answers
A:OSPF path cost can influence which routing path a device uses, but it does not relabel which interface IOS treats as NAT inside or outside. The stated fault is an explicit role reversal in the NAT configuration. A different OSPF metric would not establish the correct translation direction.
B:A DHCP helper forwards selected UDP broadcasts, typically client address-configuration messages, between networks. It is not an address translator and cannot replace `ip nat inside` or `ip nat outside`. The router already has a NAT statement; the missing condition is correct interface role assignment.
D:169.254.0.0/16 is IPv4 link-local address space, generally not suitable for routing through a provider. Changing ordinary private LAN clients to APIPA would make their addressing less useful and would not repair reversed NAT roles. Keep the approved source prefix and configure the NAT boundaries correctly.
Question 459
A Cisco edge should apply source NAT only to IPv4 inside subnet `10.20.0.0/16`, not other campus prefixes. What standard ACL match correctly selects this source range?
- `access-list 10 permit 10.0.0.0 0.255.255.255` when only 10.20/16 should translate.
- `access-list 10 deny 10.20.0.0 0.0.255.255` as the sole selection line.
- `access-list 10 permit 10.20.0.0 0.0.255.255`, referenced by the intended `ip nat inside source list 10 ...` rule.
- `access-list 10 permit 10.20.0.0 255.255.0.0` as if the fourth field were a regular subnet mask.
Explanation
Correct Answer
C:The /16 subnet mask 255.255.0.0 has wildcard 0.0.255.255. A standard NAT selection ACL matches inside-local source addresses; correct scope matters before translations are created.
Incorrect Answers
A:The /8 match is much broader than the requested /16 and includes unrelated internal sources.
B:In standard ACL selection semantics for source NAT, denied traffic is not selected for that NAT rule.
D:An IOS standard ACL uses a wildcard/inverse mask in that field; 255.255.0.0 is not the /16 wildcard.
Question 460
A branch edge needs a static NAT publication for inside host 10.10.20.10 at public address 198.51.100.10. External SYNs arrive on the outside interface, but `show ip nat translations` has no corresponding static entry. Which configuration defect should be corrected first?
- Replace the server DNS TTL with zero even though the packet reaches the public IP.
- Increase the dynamic PAT overload pool for outbound client sessions.
- Adjust OSPF Hello timers on an unrelated transit network.
- Create or restore the intended static inside-source translation and verify inside/outside interface roles.
Explanation
Correct Answer
D:Without an installed static mapping, the edge cannot translate the published public destination to 10.10.20.10. Configure the expected static NAT binding and verify the matching interfaces and translation table.
Incorrect Answers
A:The inbound SYN already arrives at the correct edge public destination, so DNS TTL is not the missing static translation.
B:PAT for outbound client connections is a different translation use case from a fixed inbound service publication.
C:OSPF timer matching matters for router adjacency, not for populating the static NAT mapping on the edge.