Cisco Certified Network Associate (CCNA) 200-301 Practice Test 9
Question 80
A branch administrator proposes these source networks for hosts that must remain within RFC 1918 private IPv4 space. Which list contains only RFC 1918 private address blocks?
- 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16
- 10.0.0.0/8, 172.32.0.0/12, and 192.168.0.0/16
- 10.0.0.0/8, 169.254.0.0/16, and 192.168.0.0/16
- 100.64.0.0/10, 172.16.0.0/12, and 192.168.0.0/16
Explanation
Correct Answer
A:RFC 1918 reserves exactly three IPv4 private ranges: 10/8, 172.16/12, and 192.168/16. The /12 range covers 172.16.0.0 through 172.31.255.255, not every 172.x address. These prefixes can be routed internally but are not intended to be advertised as ordinary publicly reachable Internet routes. When a private host reaches an external public IPv4 service, an appropriate translation or another legitimate upstream addressing design is generally required. The proposed three-prefix list correctly describes the private blocks. Operators can verify addresses by applying the mask to the binary prefix, not by memorizing that all addresses beginning with 172 are private.
Incorrect Answers
B:172.32.0.0 falls outside the RFC 1918 172.16.0.0/12 interval, which ends at 172.31.255.255. The presence of the correct 10/8 and 192.168/16 blocks does not make 172.32/12 private. Using this as an internal private-only addressing plan can collide with legitimately allocated public space or create routing surprises. Always test the second octet boundary for 172 addresses.
C:169.254.0.0/16 is IPv4 link-local addressing, often seen when a client cannot obtain a DHCP lease. It is not one of the three RFC 1918 private blocks and is not a substitute for a routed enterprise subnet. A host using 169.254/16 generally has only local-link communication and may lack a default gateway. Treating it as an RFC 1918 pool conceals the actual addressing failure.
D:100.64.0.0/10 is shared address space specified for carrier-grade NAT and similar service-provider uses, not RFC 1918 private address space. The 172.16/12 and 192.168/16 members of this choice are valid private ranges, but all members must satisfy the condition. Deploying shared address space in an enterprise is a separate design decision with different interoperability concerns. It cannot replace 10/8 in an enumeration of the exact RFC 1918 blocks.
Question 81
Clients in `10.20.0.0/16` must browse public IPv4 services through an edge router with Internet-facing public address `203.0.113.9`. What edge mechanism allows many private clients to share the routable address?
- Configure appropriate inside/outside interfaces and NAT overload (PAT) translating eligible 10.20.0.0/16 source flows to the public interface address.
- Advertise 10.20.0.0/16 globally without translation and rely on Internet routers to accept the private source.
- Change only the campus switch STP root and assume it rewrites IPv4 source addresses.
- Configure NAT on an access switch without a Layer 3 egress or translation path.
Explanation
Correct Answer
A:RFC1918 private source addresses are not generally forwarded across the public Internet. PAT can distinguish simultaneous sessions by translated transport ports while presenting a globally routable source; correct inside/outside marking and match scope are essential.
Incorrect Answers
B:Public networks generally filter RFC1918 sources; the internal prefix should not be exposed as a public source.
C:STP controls Layer 2 loops and forwarding, not source NAT translations at the Internet edge.
D:NAT is performed by a capable routed device in the forwarding path; a purely Layer 2 switch VLAN designation cannot provide the requested public source translation.
Question 82
A Windows laptop is normally configured through DHCP. After lease attempts fail, it self-assigns `169.254.14.22/16` and cannot access remote IPv4 networks. How should this address be classified?
- It is one of the RFC1918 private ranges and proves the corporate DHCP server issued a correct lease.
- It is a globally routable address that should be advertised to the Internet as a public host.
- It is IPv4 link-local/APIPA fallback, not a normal RFC1918 DHCP lease with a routable default gateway.
- It is an IPv6 link-local address because it begins with a 169 octet.
Explanation
Correct Answer
C:Windows can use IPv4 link-local addressing from 169.254.0.0/16 when automatic configuration fails. Such addresses are intended for local-link operation and do not by themselves supply a default gateway for off-link access.
Incorrect Answers
A:RFC1918 identifies 10/8, 172.16/12 and 192.168/16; 169.254/16 is separate link-local space and is not evidence of a successful DHCP lease.
B:169.254.0.0/16 is reserved for IPv4 link-local behavior, not public routing.
D:IPv6 link-local uses fe80::/10; the displayed address is IPv4 dotted decimal.
Question 83
A firewall policy treats every address starting with 172 as private. A new host has address 172.32.10.7, while another has 172.20.10.7. Which correction matches RFC 1918 private-address boundaries?
- Only 172.16.0.0 through 172.31.255.255 is RFC 1918 private in that first-octet family; 172.32.10.7 is outside the private /12.
- All 172.0.0.0/8 addresses are private because the first octet is 172.
- The 172.20.10.7 address is globally routable because the second octet is above 16.
- 172.32.10.7 is APIPA link-local and therefore cannot ever appear in a public route.
Explanation
Correct Answer
A:RFC 1918 defines 172.16.0.0/12 as private address space, which covers second-octet values 16 through 31 inclusive. The sample 172.20.10.7 lies inside that block; 172.32.10.7 does not. A security filter that classifies the entire 172/8 range as private could misclassify legitimate destinations, breaking intended policy or obscuring Internet routing. Implement the precise network and prefix, then validate boundary cases such as 172.15.x.x and 172.32.x.x. Being outside RFC 1918 does not by itself prove a specific public address is allocated or reachable.
Incorrect Answers
B:The first octet 172 alone does not establish private addressing. Only the /12 block starting at 172.16.0.0 is RFC 1918. Broadening the match to all 172/8 erroneously includes second-octet values from 0 through 15 and from 32 through 255, which are not part of the private allocation.
C:An address within 172.16.0.0/12 is private regardless of its final two octets. The second octet 20 lies between 16 and 31, so 172.20.10.7 is part of the RFC 1918 range. Public/private classification requires a prefix comparison rather than a crude greater-than test.
D:APIPA IPv4 link-local addressing uses 169.254.0.0/16, not 172.32.0.0/16. The latter address is outside the RFC 1918 172.16/12 block, but its actual Internet reachability depends on allocation, routing and filtering. Calling it APIPA mixes two unrelated reserved-address mechanisms. Their addressing and forwarding behaviors must be assessed separately.
Question 84
An internal host `10.20.30.40` can reach its NAT edge, but an upstream packet capture shows outbound packets still using source `10.20.30.40` and no translation entries are created. What problem does that evidence reveal?
- The source is public because any 10.x.x.x address is Internet routable.
- The IPv4 host has no gateway because it already reached the NAT edge.
- The edge is failing to translate the matching RFC1918 inside source before sending traffic to the ISP.
- The DNS server must be wrong even if a captured packet already has a destination public IPv4 literal.
Explanation
Correct Answer
C:10.20.30.40 belongs to RFC1918 10/8. Without matching NAT/PAT configuration and correct inside/outside roles, private source packets can leave the edge untranslated and fail across public upstream networks.
Incorrect Answers
A:All of 10.0.0.0/8 is RFC1918 private address space, so this explanation contradicts the source address.
B:Local edge reachability shows a working path to the gateway; the upstream source capture identifies failure after that point.
D:DNS resolution is not needed to explain an already constructed outgoing IP packet with an untranslated private source.
Question 85
A Windows laptop configured for DHCP now shows 169.254.83.21/16, no ordinary default gateway, and cannot reach resources beyond its link. The switch link is up, but packet capture shows repeated DHCPDISCOVER frames without any DHCPOFFER. What fault should be investigated first?
- Failure to receive a usable DHCP lease from a server or relay, causing IPv4 link-local fallback.
- The ISP allocated a globally routed IPv4 address to the workstation.
- The router advertised the wrong IPv6 default route for the local subnet.
- A DNS AAAA record returned the wrong IPv6 address for the intranet service.
Explanation
Correct Answer
A:A 169.254/16 address typically indicates the client fell back to IPv4 link-local addressing after failing to obtain a configured lease. Repeated DISCOVER packets with no OFFER make DHCP reachability, scope availability, server responsiveness and any relay configuration the relevant checks. Follow the client VLAN to its Layer 3 relay or local server and confirm packet forwarding in both directions. A local link can remain operational while the host has no usable default gateway for remote networks. After repair, renew the lease and verify the expected IP, mask, gateway and DNS options.
Incorrect Answers
B:An ISP-assigned public address is not the usual explanation for a client automatically selecting 169.254.x.x. That prefix is the IPv4 link-local space, intended for limited same-link communication, not ordinary provider-routed access. The missing DHCPOFFER messages show failure of client address provisioning, not successful allocation of a public address.
C:IPv6 default-route problems can affect IPv6 destinations, but they do not explain why an IPv4 DHCP client transmits DISCOVER messages without receiving a DHCPOFFER. The observed 169.254/16 fallback occurs in the IPv4 address-assignment mechanism. First trace the DHCP exchange and any relay rather than changing IPv6 routing.
D:A wrong DNS AAAA record could cause applications to connect to the wrong IPv6 endpoint after address configuration succeeds. It cannot itself cause DHCPDISCOVER messages to go unanswered or make the IPv4 client adopt an automatic link-local address. Resolve the lease and gateway issue before testing hostname resolution.
Question 86
An enterprise address-classification script labels 100.64.16.10 as an RFC 1918 private address and assigns it to the same category as 10.0.0.8. The address is in the provider-facing pool used by carrier-grade NAT. Which classification correction is necessary?
- All 100.0.0.0/8 addresses are RFC 1918 private, so the script should widen its private pool.
- 100.64.16.10 is a routable public host address that must be announced across global ISP interconnects.
- 100.64.16.10 falls inside RFC 6598 Shared Address Space 100.64.0.0/10 for provider CGN use; it is non-globally routed but is distinct from the RFC 1918 private blocks.
- 100.64.16.10 is IPv4 link-local auto-configuration in 169.254.0.0/16, so DHCP must have failed.
Explanation
Correct Answer
C:RFC 1918 reserves 10/8, 172.16/12 and 192.168/16. RFC 6598 separately allocates 100.64/10 for shared provider/CPE addressing behind carrier-grade NAT. The fact that an address is not globally routed does not automatically make it a member of one of the three RFC 1918 networks.
Incorrect Answers
A:RFC 1918 does not list 100/8; the shared-use range is a narrower 100.64.0.0/10 reservation with distinct purpose.
B:RFC 6598 shared addresses are not meant to be forwarded across provider boundaries as globally unique sources/destinations.
D:IPv4 link-local addresses have 169.254/16 prefix; this address is in shared CGN space instead.
Question 87
An edge NAT fix should translate LAN source `10.20.30.40` on outbound traffic. Which acceptance check most directly proves that packets are no longer sent to the ISP with their private RFC1918 source?
- Generate a matching client flow and correlate the NAT translation entry with an outside capture showing the translated public source address.
- Ping the NAT router from a private LAN host and stop testing.
- Inspect only the configured ACL text without sending any traffic.
- Confirm the ISP sends a default route, without inspecting translated packet headers.
Explanation
Correct Answer
A:The relevant evidence is a live matching translation from private inside-local to public inside-global and an actual egress packet with the public source. A route or interface state alone cannot prove that source rewrite took place.
Incorrect Answers
B:LAN reachability to the edge does not establish that the outbound packet source was rewritten by NAT.
C:A configuration may contain a plausible match yet the flow may use the wrong interface direction or fail to create translations.
D:Routing can be healthy while NAT still forwards private source addresses and produces upstream drops.
Question 88
After restoring DHCP service for a Windows client that previously showed `169.254.18.9/16`, which client observation directly confirms it now has usable routed IPv4 settings?
- `ipconfig /all` shows a valid site-subnet lease, expected default gateway and DNS details; an off-subnet IPv4 probe succeeds via that gateway.
- The client still has only 169.254.18.9/16 and no default gateway but can ping itself.
- Only an Ethernet link-up icon appears, with no IPv4 address information.
- The router has a default static route, but no client lease or host configuration is inspected.
Explanation
Correct Answer
A:An APIPA 169.254/16 fallback usually signals missing usable DHCP configuration. A real lease with correct mask/gateway and successful off-link forwarding proves more than mere local link connectivity.
Incorrect Answers
B:Local self-ping does not demonstrate a DHCP lease or usable IPv4 route outside the link.
C:Layer 1/2 connectivity can exist while DHCP fails and the host still uses APIPA.
D:A router route cannot prove the client obtained proper IP and gateway values after its failed DHCP process.
Question 89
VLAN 10 is assigned IPv6 prefix `2001:db8:400:10::/64` in a lab. What routed SVI configuration directly gives clients an on-link IPv6 default gateway on that VLAN?
- Configure the SVI with `2001:db8:400:11::1/64` while VLAN 10 clients use `:10::/64`.
- Configure `fe80::1/64` as the only source of a global /64 advertisement to hosts.
- Configure the VLAN 10 SVI with `2001:db8:400:10::1/64` and enable IPv6 routing/required router-advertisement behavior.
- Configure an IPv4 DHCP relay without assigning any IPv6 address or forwarding capability to the SVI.
Explanation
Correct Answer
C:The SVI address must belong to the allocated VLAN 10 /64 and participate in IPv6 routing. IPv6 clients can learn router reachability through RA; merely installing an unrelated default route does not correct the SVI prefix.
Incorrect Answers
A:The SVI would treat a different /64 as on-link, leaving a prefix mismatch with the clients.
B:A link-local address is useful for neighbor and router signaling but is not a global unicast prefix for hosts.
D:IPv4 helper functionality cannot supply the required IPv6 routed interface and client prefix.
Question 90
R1 GigabitEthernet0/0 and R2 GigabitEthernet0/0 are on the same Ethernet segment. Each interface has a valid fe80::/10 link-local address but no global unicast IPv6 address. Operators need to test local Neighbor Discovery and reachability without configuring an IPv6 default route. Which approach can work?
- Forward the neighbor solicitation through a third router because fe80:: addresses have global scope
- Create an IPv4 default route so IPv6 Neighbor Discovery can reach the adjacent router
- Assign the same link-local address to both routers so the neighbor cache has one entry
- Use the adjacent router's link-local IPv6 address on the common link, specifying the outgoing interface scope when the diagnostic command requires it
Explanation
Correct Answer
D:IPv6 link-local addresses are valid within a single link even without global unicast prefixes or default routing. Each router can use ICMPv6 Neighbor Discovery to resolve the other router's link-layer address on their shared Ethernet segment. Because the same fe80:: value can appear on different links, a host or router diagnostic may require an explicit source or outgoing interface to identify the zone. A scoped same-link ping and an inspection of the IPv6 neighbor table demonstrate that adjacency exists. This tests local reachability, not the separate IOS static-route syntax that requires an interface when a link-local next hop is configured.
Incorrect Answers
A:This approach assumes IPv6 link-local packets traverse routers, which is not their defined scope. Router Solicitation, Router Advertisement, and Neighbor Solicitation operations are local-link functions, and a link-local destination is not forwarded as ordinary Internet-routable IPv6. In the stated Ethernet segment, both routers can exchange Neighbor Discovery messages directly. A third router adds no required reachability and would not extend the fe80:: neighbor scope.
B:An IPv4 default route changes how IPv4 packets are forwarded when no more-specific IPv4 route matches; it has no effect on the IPv6 Neighbor Discovery process. IPv6 uses ICMPv6 Neighbor Solicitation and Advertisement to associate local IPv6 neighbors with Layer 2 addresses. Both endpoints are already on one Ethernet segment and have link-local addresses, so adding an unrelated IPv4 gateway will not establish the targeted same-link IPv6 test.
C:IPv6 interface identifiers on the same link must be unique when both devices are active. Duplicating the fe80:: address would cause duplicate-address detection or neighbor-cache confusion rather than create valid adjacency. The objective is to reach the actual neighboring interface, not to invent a shared address for two separate routers. Keep distinct link-local addresses, and inspect the local neighbor entries after performing the diagnostic test.