Subnetting practice questions

The access list 'NAT' is incorrect; it should permit only specific hosts, not the entire subnet.

Why wrong: The access list 'NAT' is not the problem. In dynamic NAT, the ACL is used solely to identify which inside addresses are eligible for translation, and permitting the entire internal subnet is standard and correct when all internal hosts should have Internet access. Even if the ACL were narrowed to specific hosts, the router would still fail to translate return packets because the outside interface has not been designated with 'ip nat outside'. The ACL only controls which source addresses are translated, not whether NAT is applied on an interface.

The NAT configuration lacks the 'overload' keyword, so the pool is exhausted quickly.

Why wrong: The lack of the 'overload' keyword is a red herring here. Without overload, the router performs standard dynamic NAT, which still works correctly as long as the number of active inside addresses does not exceed the number of addresses in the pool. In the scenario, there are only 2 active translations and 11 addresses in the pool, so the pool is not exhausted and overload would not change the immediate outcome. The real issue is that the outside interface is not configured for NAT, and adding overload cannot compensate for that missing interface-level command.

The NAT pool 'POOL' has too few addresses; it should be expanded to a /24 subnet.

Why wrong: The NAT pool 'POOL' has 11 addresses, which is more than enough for the two active translations, so pool size is not causing the problem. Expanding the pool to a /24 subnet would only increase the maximum number of concurrent translations; it would not make the router process return traffic on the outside interface. Even with 254 public addresses available, the router would still not translate reply packets because the outside interface is not marked with 'ip nat outside'. The symptom of no replies is a direct result of missing interface NAT designation, not address exhaustion.

The interface is administratively down.

Why wrong: The interface status in the output reads 'up, line protocol is up', indicating that the interface is fully operational at both Layer 1 and Layer 2. An administratively down interface would instead show 'administratively down, line protocol is down' and would not generate any IPv6 traffic, including Router Advertisements. Since the router is actively advertising and the link-local address is present, the interface is clearly not shut down or disabled.

The MAC address of the interface is invalid, preventing EUI-64 from generating a proper address.

Why wrong: The link-local address FE80::21A:2BFF:FE3C:4D5E shown in the output is derived from the interface MAC address using EUI-64, which inserts FFFE in the middle and flips the U/L bit. The presence of this valid link-local address proves the MAC address is not invalid and EUI-64 generation succeeded. An invalid or all-zero MAC would prevent IPv6 from generating any link-local address, but the output clearly displays a properly formed one, so this option cannot be the cause.

The router is not sending Router Advertisements, so hosts cannot autoconfigure.

Why wrong: The output explicitly states 'ND router advertisements are sent every 200 seconds', which confirms the router is actively sending ICMPv6 Router Advertisements on this interface. Hosts would therefore be able to perform stateless address autoconfiguration (SLAAC) and learn the default router. However, the problem is that hosts cannot reach the router's own link-local address, which points to a missing or incorrectly configured IPv6 address on the router itself, not to a lack of RA messages.

Configure only a DNS server of 10.10.10.5.

Why wrong: Configuring only a DNS server of 10.10.10.5 gives the workstation the ability to resolve hostnames into IP addresses, but name resolution does not provide any forwarding path for traffic destined outside the local subnet. The workstation's routing table has no default route, so any packet with a destination IP outside 10.10.10.0/24 is dropped as unreachable. Even though the DNS server is reachable on the same subnet, the host still cannot reach the server at 10.10.20.x because there is no gateway to route that traffic. Thus, DNS alone is insufficient for inter-subnet communication.

Change the subnet mask to 255.255.0.0 to allow communication across subnets.

Why wrong: Altering the workstation's subnet mask to 255.255.0.0 (/16) would make it assume that all 10.10.x.x addresses are within the same local broadcast domain. As a result, it would attempt to resolve destinations like 10.10.20.5 via ARP rather than forwarding them to a router, but ARP is a Layer 2 broadcast that cannot cross a router. This not only fails to provide a path to other subnets but also breaks routing from the router's perspective, since the router's interface is still configured with a /24 mask and will treat the host's /16 view as a conflicting route. The proper solution requires a Layer 3 gateway, not an expanded subnet mask.

Configure a default gateway of 10.10.20.1 and a DNS server of 10.10.10.5.

Why wrong: This configuration fails because a default gateway must be directly reachable on the same IP subnet as the host. The gateway 10.10.20.1 is on the 10.10.20.0/24 network, while the workstation is on 10.10.10.0/24, so the host cannot ARP for it and will not be able to send any frames to that gateway. Even if the DNS server 10.10.10.5 is correct, the workstation will still be unable to communicate with any remote subnet because its default route points to an unreachable next hop. The host essentially has no valid gateway, so all non-local traffic is discarded.

Change the AP from Ethernet to PPP encapsulation.

Why wrong: PPP (Point-to-Point Protocol) is a WAN encapsulation used on serial or dial-up links, not on Ethernet LAN segments where access points typically connect. Changing the AP's encapsulation to PPP would not affect CAPWAP, which runs over UDP/IP and expects Ethernet framing on the local LAN. The exhibit gives no indication of a serial link or PPP requirement, so this action is unrelated to the AP's inability to join the controller.

Remove the AP IP address so it can obtain an IP address automatically via DHCP.

Why wrong: Removing the static IP and switching to DHCP does not address the root cause because the problem is a layer 3 reachability misconfiguration, not the method of address assignment. If the DHCP scope also provides the same incorrect default gateway, the AP will obtain a valid address but still be unable to reach the controller. Even a dynamically assigned address requires a correct gateway to forward CAPWAP traffic; the static IP itself is not preventing the AP from joining.

Disable DHCP on the controller for all APs.

Why wrong: Disabling DHCP on the controller globally is incorrect because the exhibit indicates that the problem is specific to this AP's default gateway, and other APs are already joining successfully. Such a global change would disrupt DHCP-based provisioning for all access points, including the healthy ones, without correcting the faulty gateway on the problematic AP. The issue lies in the AP's local IP routing configuration, not in the controller's DHCP service.

The SSID broadcast setting, because the client must not be joined correctly.

Why wrong: The SSID broadcast setting only controls whether the network name appears in probe responses, not whether an already-associated client can send or receive traffic. Because the client successfully joined and pulled an address from the correct subnet, it is not a join failure. If broadcast were disabled, the client would still be able to connect if it manually knew the SSID, and would not explain an application-specific issue.

The voice VLAN on the wired access port connected to the AP uplink.

Why wrong: The voice VLAN on the wired access port is used to separate VoIP traffic from data traffic on the wired infrastructure, and it does not affect how a wireless client forwards traffic after joining a WLAN. A client that has already received an address from the correct subnet is clearly operating on the data VLAN, not the voice VLAN, and general employee access works correctly. Since the problem is restricted to one application, changing the voice VLAN setting on the AP uplink would have no bearing on this scenario.

The OSPF router ID on the client device.

Why wrong: OSPF router IDs are used by routers participating in OSPF to identify themselves in link-state advertisements; end-client devices such as laptops or phones do not run OSPF and never exchange routing protocol information with the network. A client's network stack obtains an address via DHCP and uses a default gateway for off-subnet traffic, so OSPF router ID is irrelevant. The application-specific failure cannot be caused by a parameter that does not exist on the client device.

192.168.50.127

Why wrong: The address .127 is the broadcast address of the lower /25 subnet, 192.168.50.0/25, which spans from .0 to .127. However, the configured IP .130 belongs to the upper subnet (.128/25), so the lower subnet's broadcast is not applicable. For the subnet containing .130, the broadcast is .255, not .127.

192.168.50.128

Why wrong: The address .128 is the network address of the upper /25 subnet, not its broadcast. In 192.168.50.128/25, the network address has all host bits set to 0, yielding .128 as the identifier for the subnet itself. The broadcast address is the last address, .255, while .128 merely marks the starting boundary of that subnet.

192.168.50.254

Why wrong: The address .254 is the last usable host address in the 192.168.50.128/25 subnet. Usable host addresses are those between the network address (.128) and the broadcast address (.255), specifically .129 through .254. Since .255 is reserved as the broadcast, .254 cannot be the broadcast address; it is a valid host assignment.

The policy needs to match only one source subnet.

Why wrong: If the policy needs to match only a single source subnet, a standard access list using a wildcard mask like 0.0.255.255 fully satisfies that goal. Standard ACLs evaluate only the source address, so one permit or deny statement can identify the subnet without extra protocol or port granularity. This requirement does not require an extended ACL at all.

The ACL must be placed near the destination.

Why wrong: Placement near the destination is a recommended practice once an extended ACL is selected, because it limits extraneous traffic traversing the network. However, the physical or logical placement of an ACL does not determine whether a standard or extended ACL is required; a standard ACL can also be deployed, although it is typically positioned near the source. Therefore, this is a design guideline, not a selection premise.

The network uses IPv6 instead of IPv4.

Why wrong: Whether the network is IPv4 or IPv6 does not alter the fundamental limitation: a named IPv6 ACL is essentially equivalent to an extended ACL in capability, and the choice between standard-like and extended-like matching still depends on the need for granular match criteria. If the requirement is only to match a source subnet, either address family can use a simple source-only ACL. Thus, using IPv6 does not inherently force the extended ACL variant.

It is on the same local network because both addresses begin with 172.16.

Why wrong: Merely sharing the first two octets is insufficient to conclude that two hosts are on the same subnet. The network boundary is determined by the /23 prefix length, which includes 23 bits of the IP address. Performing a bitwise AND of 172.16.5.10 with 255.255.254.0 yields 172.16.4.0, whereas the same operation on 172.16.6.20 yields 172.16.6.0. Because these network addresses differ, the hosts are on different networks despite both starting with 172.16.

It is on the same local network because /23 covers all addresses in 172.16.5.x and 172.16.6.x

Why wrong: The /23 prefix does not encompass both 172.16.5.x and 172.16.6.x as a single network. A /23 subnet must align on an even boundary in the third octet; the block containing .5.x is 172.16.4.0/23 (hosts 172.16.4.1–172.16.5.254), while .6.x falls in the next /23 block, 172.16.6.0/23. Thus 172.16.5.10 and 172.16.6.20 are in different /23 subnets, so this option's claim is false.

It is on a different network, so ARP will resolve it across the router automatically

Why wrong: ARP (Address Resolution Protocol) operates only within the local broadcast domain and cannot resolve IP addresses across a router. When a host determines that a destination is on a different network, it does not send an ARP request for that remote address; instead, it forwards the packet to the configured default gateway (router). The router then uses its own ARP table or ARP requests to reach the next hop toward the final destination. Therefore, ARP will not 'resolve across the router' automatically.

192.168.30.64

Why wrong: .64 is the network address of the next /26 subnet (the block from .64 to .127). It is not part of the .0/26 subnet at all; it is the first address of the subsequent block. Therefore it cannot be the broadcast address for the .0/26 network.

192.168.30.255

Why wrong: .255 is the broadcast address for the entire /24 subnet (192.168.30.0/24), which contains four /26 subnets. A /26 broadcast must stay within its own 64-address block; since this /26 block ends at .63, .255 is outside that range and is the broadcast for the parent network, not for this subnet.

192.168.30.31

Why wrong: .31 would be the broadcast address if the prefix length were /27, which creates a block size of 32 addresses. The /26 block from .0 spans .0 through .63, so the last address is .63, not .31. A broadcast address must be the final address in the block defined by the prefix length and network address.

10.1.1.31

Why wrong: 10.1.1.31 is the broadcast address of the preceding /30 subnet, not the subnet containing 10.1.1.34. A /30 mask creates blocks of 4 addresses, so the valid subnet for 10.1.1.34 is 10.1.1.32 through 10.1.1.35. The address 10.1.1.31 belongs to the 10.1.1.28–10.1.1.31 block, making it a full network boundary away. The broadcast must be the last address within the same /30 block as the host, which is 10.1.1.35, so .31 is incorrect.

10.1.1.32

Why wrong: A /30 subnet provides only two usable host addresses, with the broadcast address being the last address in the block. For 10.1.1.34/30, the subnet is 10.1.1.32–10.1.1.35, so the broadcast is 10.1.1.35, not 10.1.1.32. This option is tempting because 10.1.1.32 is the network address (the first address), which a candidate might confuse with the broadcast when calculating a /30 range. It would be correct as the broadcast address only if the subnet were a /29, where 10.1.1.32 would be the last address of the 10.1.1.24–10.1.1.31 block.

10.1.1.36

Why wrong: 10.1.1.36 is the network address of the next /30 subnet, which spans 10.1.1.36 through 10.1.1.39. Since the host’s subnet is 10.1.1.32–10.1.1.35, the broadcast is the final address in that range, 10.1.1.35. Choosing .36 mistakenly adds 4 to the network address instead of recognizing that the broadcast is the last address before the next subnet’s network address. One past the broadcast, .36 begins a new subnet, so it cannot be the broadcast.

Both addresses are normal host addresses that can be assigned to users.

Why wrong: The network address and broadcast address are both reserved and cannot be assigned to end-user devices. The network address has all host bits set to 0, while the broadcast address has all host bits set to 1; only addresses strictly between these two endpoints are available as usable host addresses. Therefore, calling them normal host addresses misrepresents their reserved role in IPv4 subnetting.

The broadcast address always becomes the default gateway.

Why wrong: The default gateway is not the broadcast address; it is the IP address of a router interface that resides within the subnet and is a usable host address. A broadcast address is used to send packets to every host in the subnet and cannot serve as a unicast destination. A router might use one of the usable host addresses, but the broadcast address is never used as the default gateway.

These concepts exist only in IPv6 and not IPv4.

Why wrong: These concepts are specific to IPv4, not IPv6. IPv4 uses both network and broadcast addresses to define subnet boundaries, whereas IPv6 does not have a broadcast address at all; it relies on multicast for group communication. Thus the statement incorrectly reverses the existence of these address types between the two protocol versions.

192.168.10.0/25

Why wrong: The .0/25 subnet spans addresses .0 through .127, with network address .0 and broadcast .127. Since .129 is 2 addresses above that upper boundary, it cannot belong to the lower half. The /25 split of the /24 assigns the first 128 addresses to .0/25 and the second 128 to .128/25.

192.168.10.64/25

Why wrong: A /25 network must begin at a multiple of 128 in the last octet, which only yields .0 and .128 within this /24. 192.168.10.64 is not a valid network address for a /25 prefix because its host bits are not all zero; it would be a host address inside .0/25, not a subnet boundary. Therefore no host can be said to reside in a ".64/25" subnet.

192.168.10.192/25

Why wrong: 192.168.10.192/25 would, if it existed, cover .192–.255, which excludes .129 entirely. Moreover, /25 network boundaries within a /24 are limited to .0 and .128; .192 is not a legal starting address because it violates the alignment requirement of the 25-bit mask. The address .129 is already accounted for by the .128/25 subnet.

10.20.30.32

Why wrong: A /27 subnet divides the address space into blocks of 32 addresses, with network addresses at .0, .32, .64, .96, and so on. The address .95 is not in the range .32 through .63, because that range ends at .63. Therefore 10.20.30.32 is the network address for a different subnet that does not contain host .95, making it incorrect.

10.20.30.95

Why wrong: In a /27 subnet, the host bits are the last 5 bits of the address, and the host .95 has the binary form .01011111, with all host bits set to 1. An address with all host bits set to 1 is the broadcast address for that subnet, not the network address. The network address .64 has all host bits set to 0, so .95 cannot be the network identifier.

10.20.30.96

Why wrong: The subnet starting at .96 spans addresses .96 through .127, which begins immediately after the .64 block. Since the host .95 is the final address in the .64 subnet, it cannot belong to the .96 subnet. Additionally, .96 is a valid network address, but it identifies the next block, not the one containing .95, so it is wrong here.

1. Enable DHCP relay on the VLAN 20 interface. 2. Configure the DHCP pool for VLAN 10. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because DHCP relay should be configured after the DHCP server pool is set up. Enabling relay before the server is ready may cause clients to send requests that cannot be answered.

1. Exclude addresses from the pool. 2. Enable DHCP relay on the VLAN 20 interface. 3. Configure the DHCP pool for VLAN 10. 4. Verify DHCP operations.

Why wrong: This is incorrect because the DHCP pool must be created before excluding addresses. Exclusions are part of the pool configuration and cannot be applied before the pool exists.

1. Configure the DHCP pool for VLAN 10. 2. Enable DHCP relay on the VLAN 20 interface. 3. Exclude addresses from the pool. 4. Verify DHCP operations.

Why wrong: This is incorrect because exclusions should be configured before enabling relay. Although the pool is created first, exclusions are part of the pool configuration and should be done before moving to relay.

192.168.70.18 through 192.168.70.21

Why wrong: Starting the range at .18 would imply a network boundary at .18, but /30 subnets must begin at a multiple of 4 (i.e., .0, .4, .8, .12, .16, .20). The block 192.168.70.18 through .21 arbitrarily splits the real .16/.30 subnet and the following .20/.30 subnet, so it cannot represent a valid /30 addressing scheme. The host .18 belongs exclusively to the .16-.19 block.

192.168.70.12 through 192.168.70.15

Why wrong: 192.168.70.12 through .15 is the /30 subnet immediately preceding the one that holds .18, with network address .12 and broadcast .15. A /30 boundary occurs every four addresses, so the block containing .18 must start at .16, not at .12. Thus this range is too early to include 192.168.70.18.

192.168.70.20 through 192.168.70.23

Why wrong: The range 192.168.70.20 through .23 is the next sequential /30 subnet after the one containing .18. Since the network .16/.30 spans .16-.19, the address .18 is not part of the .20/.30 block. Choosing this range confuses the next network boundary with the actual subnet for this host.

Whether the switch should disable IP routing

Why wrong: Disabling IP routing on the switch would completely break the path between VLAN 10 and VLAN 20, because the switch's SVI would no longer forward packets between those subnets. The fact that the host can already ping its local SVI indicates that the switch's layer 3 interface is up and addressed correctly; the problem lies beyond the local subnet. To route between VLANs, IP routing must remain enabled—either on the switch (inter-VLAN routing) or on an external router—so disabling it is not a viable fix and would only worsen the situation.

Whether VLAN 10 should be the native VLAN

Why wrong: VLAN 10 being the native VLAN is irrelevant to this symptom. Native VLAN configuration only affects how frames are tagged on 802.1Q trunk links; frames on the native VLAN are sent untagged. The host's ability to ping its local SVI and then fail to reach a server in another VLAN points to layer 3 forwarding issues, not to the layer 2 trunk encapsulation or native VLAN mismatch. Checking native VLAN settings would be appropriate only if there were complete L2 connectivity failures, not selective inter-VLAN reachability.

Whether the host should use a /8 mask instead of /24

Why wrong: Changing the host's subnet mask from /24 to /8 would make the host assume the entire 10.0.0.0/8 address space is directly connected on its own VLAN. It would then attempt to ARP for the server's IP address instead of sending the packet to its default gateway, breaking communication even more. The given symptom—host can ping the local SVI—shows the host is already using a proper /24 mask and routing locally through its gateway; a /8 mask would create a completely different ARP-based failure, not resolve the current one.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. No need to enable IPv6 unicast-routing because it is on by default.

Why wrong: This is incorrect because IPv6 unicast-routing is not enabled by default on Cisco IOS; it must be explicitly configured with the 'ipv6 unicast-routing' global command. Without it, IPv6 packets will not be forwarded between interfaces.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64' (without eui-64) and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers.

Why wrong: This is incorrect because the question specifies that R1's G0/1 should use EUI-64. The command 'ipv6 address 2001:db8:1::/64' assigns a static address (the full /64 prefix as the interface ID), which is not what is required. The correct command includes the 'eui-64' keyword to generate the interface ID from the MAC address.

On R1, change the subnet mask on G0/0 from /24 to /30. On R1 G0/1, issue 'ipv6 address 2001:db8:1::/64 eui-64' and 'no shutdown'. Enable 'ipv6 unicast-routing' globally on both routers. Also, change the default gateway on PC1 to 2001:db8:1::1.

Why wrong: This is incorrect because the default gateway on PC1 should be the IPv6 address of R1's G0/1 interface. With EUI-64, the interface address is derived from the MAC address, not necessarily ::1. The question states that R1's G0/1 uses EUI-64, so the gateway address is not predetermined as ::1. The PCs already have correct gateways as per the existing explanation.

Configure a default gateway on PC-A with the IP address 192.168.10.1.

Why wrong: This is incorrect because PC-A has an APIPA address (169.254.23.45), which indicates it did not receive a DHCP lease. Manually setting a default gateway does not resolve the underlying issue of DHCP failure. The PC must first obtain a valid IP address via DHCP before a default gateway can be used.

Change the VLAN on SW1's interface connected to PC-A from VLAN 10 to VLAN 1.

Why wrong: This is incorrect because PC-A is configured for VLAN 10, and the DHCP pool is on subnet 192.168.10.0/24, which is associated with VLAN 10. Changing to VLAN 1 would place PC-A in a different subnet, preventing it from receiving a DHCP lease from R1's pool. The VLAN configuration is correct as is.

Add the 'ip helper-address' command on R1's interface connected to SW1.

Why wrong: This is incorrect because the DHCP server is on R1 itself, not on a remote server. The 'ip helper-address' command is used to forward DHCP broadcasts to a DHCP server on a different subnet. Since R1 is the DHCP server, no helper address is needed; the router will respond to DHCP requests on its directly connected interface.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.254, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because the default route points to 192.0.2.254, which is not R2's G0/0 IP (192.0.2.2), so IPv4 traffic will not be forwarded. Also, EUI-64 generates an interface ID from the MAC, which will not match the subnet expected by R2's static address 2001:db8:1::2/64.

Change R1 G0/0 subnet mask to /24, add a default route via 192.0.2.2, and configure a static IPv6 address 2001:db8:1::1/64 on G0/0.

Why wrong: This is incorrect because the subnet mask on R1's G0/0 remains /24, which does not match R2's /30. R1 will consider the subnet to be 192.0.2.0/24, while R2 uses 192.0.2.0/30, causing a mismatch that prevents direct communication.

Change R1 G0/0 subnet mask to /30, add a default route via 192.0.2.2, and keep the EUI-64 IPv6 address on G0/0.

Why wrong: This is incorrect because while the IPv4 issues are fixed, the IPv6 address generated by EUI-64 will not match the subnet expected by R2's static address 2001:db8:1::2/64. EUI-64 creates an interface ID based on the MAC, which is unpredictable and unlikely to be in the same subnet as R2's static address.

On R1, change the helper-address to 192.168.10.255 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set all ports as trusted.

Why wrong: This is incorrect because the helper-address should be the DHCP server's IP (192.168.10.1), not the broadcast address (192.168.10.255). Also, setting all ports as trusted defeats the purpose of DHCP snooping, as it would allow rogue servers on any port.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.254. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the excluded-address range excludes almost all addresses (192.168.10.1 through 192.168.10.254), leaving only the broadcast address for clients, which is not usable. Also, the port facing the DHCP server (R1) must be trusted, not untrusted.

On R1, change the helper-address to 192.168.10.1 and the excluded-address range to 192.168.10.1 192.168.10.10. On SW1, enable DHCP snooping globally and for VLAN 10, and set interface G0/1 as untrusted.

Why wrong: This is incorrect because the port facing the DHCP server (R1) must be trusted. Setting it as untrusted would cause DHCP snooping to drop DHCP server messages (OFFER, ACK) from R1, preventing clients from obtaining IP addresses.