Addressing and Subnet Formats practice questions

It is a global unicast address used for internet routing.

Why it fails: FE80::/10 is the reserved prefix for link-local addresses, not global unicast. Global unicast addresses are routable across the public internet, whereas link-local addresses are restricted to the local network segment. Using this address for internet routing would cause immediate packet failure as it is non-routable externally.

It is a multicast address for neighbor solicitation.

Why it fails: Multicast addresses begin with FF00::/8. FE80::1 is a unicast address assigned to a specific interface. Confusing link-local unicast addresses with multicast addresses is a common error, but it is incorrect because unicast addresses identify a single interface, whereas multicast addresses are used for traffic delivery to multiple hosts.

It is a unique local address for internal enterprise use.

Why it fails: Unique local addresses (ULA) fall within the FC00::/7 range. FE80::/10 is exclusively for link-local communication. Categorizing the address incorrectly can lead to severe misconfigurations in routing protocols, as the scope of link-local addresses is significantly more limited than that of unique local addresses in an enterprise network.

255.255.255.224

Why it fails: This mask corresponds to a /27 prefix. The decimal 224 is derived from 11100000. It is smaller than 248, meaning it provides a larger network size. Confusing these values is a common error that leads to incorrect subnetting, causing overlapping networks and routing failures throughout the entire enterprise routing table.

255.255.255.240

Why it fails: This mask corresponds to a /28 prefix. The decimal 240 is derived from 11110000. While close to 248, it is not the correct equivalent for a /29. Using an incorrect mask will cause host-to-gateway communication issues, as the host will calculate a different network boundary than the router interface.

255.255.255.252

Why it fails: This mask corresponds to a /30 prefix. The decimal 252 is derived from 11111100. This is the standard mask for point-to-point links. It is incorrect for a /29, and using it would severely restrict the available host addresses compared to the requirements of a /29 network segment in your configuration.

11.0.0.0/8

Why it fails: This range is part of the public Class A address space and is not reserved for private use by RFC 1918. Using these addresses internally can cause significant routing conflicts if the business ever needs to communicate with the actual owners of these public addresses over the global internet.

10.0.0.0/8

Why it fails: While this is a valid private range, it provides over 16 million addresses, which far exceeds the requirement of 65,536. Although it would function correctly, it is typically reserved for large enterprise environments that require massive scalability across many different geographic locations and numerous complex subnets.

169.254.0.0/16

Why it fails: This range is reserved for Automatic Private IP Addressing, commonly known as APIPA. These addresses are automatically assigned by operating systems when a DHCP server is unavailable. They are not intended for manual configuration or permanent use in a planned business network infrastructure requiring stable internal routing.

8.8.8.8

Why it fails: This is a well-known public unicast IP address owned by Google for their public DNS service. It is fully routable across the internet and is intended to be assigned to a specific service to handle global requests, making it the opposite of a reserved internal or diagnostic address.

192.0.2.1

Why it fails: While this address is part of the TEST-NET-1 range reserved for documentation and examples, it is often confused with standard reserved functional addresses. However, in the context of this question, 127.0.0.1 and 169.254.x.x are the primary functional reserved addresses used for system diagnostics and auto-configuration.

172.31.255.254

Why it fails: This is a usable private unicast address within the RFC 1918 Class B range. While it is private and not routable on the public internet, it can be assigned as a standard host address within a private internal network, unlike loopback or APIPA addresses which have specific functional roles.

The interface is administratively shut down.

Why it fails: If the interface were administratively shut down, the Status column would explicitly display 'administratively down'. In this exhibit, the status is 'up', indicating that the technician has already issued the 'no shutdown' command and the physical hardware is detecting a carrier signal from the connected device.

The IP address 192.168.1.254 is a duplicate on the network.

Why it fails: A duplicate IP address usually results in a log message or the interface being marked as 'up/up' but experiencing intermittent connectivity. It does not typically cause the line protocol to stay in a 'down' state unless specific security features like IP Source Guard or ARP inspection are actively blocking the port.

The cable is completely disconnected from the port.

Why it fails: If the cable were completely disconnected, the 'Status' column would show 'down' instead of 'up'. The 'up' status in the exhibit confirms that the physical layer is operational and receiving a link signal, which narrows the problem down to the logical protocol configuration or communication parameters.

The subnet mask on both routers is incorrectly configured as 255.255.255.252.

Why it fails: A /30 mask (255.255.255.252) is the standard and correct mask for point-to-point links, providing exactly two usable host addresses. Using this mask on both routers is not an error; it is the recommended configuration. Therefore, this is not the cause of the link failure. The issue lies elsewhere, such as an incorrect IP assignment or an interface state problem.

The IP addresses assigned to Router A and Router B are in different subnets.

Why it fails: With a /30 mask, the subnet is 192.168.100.0/30, which includes addresses 192.168.100.1 and 192.168.100.2. Both assigned addresses fall within the same subnet, so they are not in different subnets. This option is incorrect because the addresses are correctly placed in the same subnet. The problem must be something else, like a physical layer issue or misconfiguration of the interface.

One of the IP addresses is a network address.

Why it fails: In a /30 subnet, the network address is the first address (e.g., 192.168.100.0 or 192.168.100.4), and the broadcast address is the last (e.g., 192.168.100.3 or 192.168.100.7). The addresses 192.168.100.1 and 192.168.100.5 are usable host addresses, not network addresses. Therefore, this is not the cause of the link failure. The issue is that the addresses are in different subnets, preventing direct communication.

The server is on the same subnet and should be reachable.

Why it fails: With the given mask, the host and server are not on the same subnet. The host is in 192.168.1.64/26, and the server is in 192.168.1.128/26. Therefore, they cannot communicate directly without a router. This option contradicts the subnet calculation and is incorrect.

The subnet mask on the host is incorrect.

Why it fails: The subnet mask 255.255.255.192 (/26) is valid and correctly configured if the network design uses /26 subnets. There is no indication that the mask is wrong; the problem is that the server is in a different subnet. Changing the mask would not solve the issue unless the entire network is re-addressed, which is not suggested.

The host has an incorrect default gateway.

Why it fails: While a missing or incorrect default gateway could prevent communication with remote subnets, the question states the host is unable to communicate with the server, and the server is on a different subnet. The default gateway is necessary, but the primary issue is that the server is not on the same subnet. Without a router, even a correct gateway would not help if the router is not configured to route between subnets.

Loopback address

Why it fails: The IPv6 loopback address is ::1, and it is used by a host to send traffic to itself. It cannot be assigned to a physical interface for network communication. Configuring it on an interface would cause errors, as it is reserved for internal testing and is never used for global reachability.

Multicast address

Why it fails: Multicast addresses in IPv6 start with FF00::/8 and are used to send traffic to a group of interfaces, such as FF02::1 for all nodes. They are not assigned to a single host interface as a unicast address for global communication. They serve group communication functions, not individual host addressing.

Anycast address

Why it fails: Anycast addresses are assigned to multiple interfaces, often on different devices, and traffic is delivered to the nearest one. They are not used as a typical host unicast address for global communication. While anycast is valid in IPv6, it is not a standard host interface address type for general reachability.

255.255.248.0

Why it fails: A /21 mask (255.255.248.0) provides 11 host bits, yielding 2046 usable hosts. This greatly exceeds the requirement and wastes a large amount of address space, reducing the total number of subnets that can be created from the /16. It is not the most efficient choice.

255.255.252.0

Why it fails: A /22 mask (255.255.252.0) provides 10 host bits, yielding 1022 usable hosts. While it supports more than 500 hosts, it allocates a larger block than necessary, wasting address space and reducing the total number of subnets available. The engineer wants to minimize subnets, but not at the cost of overallocation.

255.255.255.0

Why it fails: A /24 mask (255.255.255.0) provides only 8 host bits, yielding 254 usable hosts. This is insufficient for 500 hosts, so it fails the requirement. The engineer must use a mask with at least 9 host bits to accommodate 500 hosts.

10.0.0.1

Why it fails: 10.0.0.1 is a private IP address within the 10.0.0.0/8 range, which is defined in RFC 1918 for private networks. It is not routable on the public Internet and is suitable for internal management. However, the question asks for an address that is not routable, and 10.0.0.1 meets that criterion. But among the options, there is another private address that is more commonly used for management, so this is not the best choice.

8.8.8.8

Why it fails: 8.8.8.8 is a public IP address owned by Google and used for their DNS service. It is routable on the public Internet and should not be used for internal management because it would cause routing conflicts and is not private. Using a public address internally can lead to reachability issues and is against best practices for private networks.

172.16.0.1

Why it fails: 172.16.0.1 is also a private IP address within the 172.16.0.0/12 range, defined in RFC 1918. It is not routable on the public Internet and can be used for management. Like 10.0.0.1, it is a valid private address, but the question asks for a specific address that is not routable, and both are valid. However, the most commonly used private address for management is in the 192.168.0.0/16 range, making this less ideal.

2001:DB8:CAFE:1::/64

Why it fails: 2001:DB8:CAFE:1::/64 is a valid /64 subnet, but it is not the only valid one. The question asks for a valid subnet prefix, and both A and D are valid. However, D is less specific because it omits the leading zeros in the subnet ID but is still correct. Since A is more explicit and follows the standard notation, D is not the best answer, but technically it is also valid. In multiple-choice, the best answer is the one that is both correct and conventional.

2001:DB8:CAFE:1:2::/64

Why it fails: 2001:DB8:CAFE:1:2::/64 has more than 16 bits used for subnetting. The /48 prefix allows the next 16 bits for subnets, but this address uses an additional 16 bits (the '1:2' portion) beyond the first 16, resulting in a /64 that is not a direct subnet of the /48. It effectively creates a subnet of a subnet, which is not valid for the given assignment without further hierarchy.

2001:DB8:CAFE:1::/48

Why it fails: 2001:DB8:CAFE:1::/48 has a prefix length of /48, not /64. The question requires a /64 subnet for each LAN segment. While the address is within the assigned /48, using a /48 on a LAN interface would not provide the standard 64-bit interface identifier and is not typical for LAN segments. It also does not represent a subnet of the /48 but rather a different prefix length.

db8:acad

Why it fails: The hextets db8 and acad are part of the network prefix, specifically the second and third hextets. They help identify the global routing prefix and subnet, but they do not represent the interface identifier. The interface identifier is in the last 64 bits.

2001:db8

Why it fails: The first two hextets 2001:db8 are the global routing prefix assigned by the ISP or registry. They indicate the overall network block, not the specific interface. The interface identifier is the lower 64 bits of the address, which in this case is ::1.

2001:db8:acad:1

Why it fails: The first four hextets (2001:db8:acad:1) make up the network prefix in a /64 subnet. The prefix identifies the subnet, not the individual interface. The interface identifier is the latter half of the address, which uniquely identifies the host within the subnet.

The loopback address in IPv6 is represented as ::1, and it can be assigned to multiple interfaces on the same device.

Why it fails: The loopback address ::1 is used for local testing and is assigned to the loopback interface. It cannot be assigned to multiple interfaces; it is a single logical interface. Assigning it to multiple interfaces would cause conflicts and is not allowed.

A double colon (::) can be used multiple times in an address to represent consecutive groups of zeros.

Why it fails: The double colon (::) can appear only once in an IPv6 address to represent one or more groups of 16 bits of zeros. Using it multiple times would create ambiguity about how many zero groups each instance represents, making the address invalid.

The subnet mask in IPv6 is represented in dotted decimal notation, similar to IPv4.

Why it fails: IPv6 does not use subnet masks in dotted decimal notation. Instead, it uses prefix length notation (e.g., /64) to indicate the network portion. This is a fundamental difference from IPv4, and using dotted decimal is incorrect.

/25

Why it fails: A /25 mask provides 126 usable host addresses. While this satisfies the requirement for 25 hosts, it is inefficient because it consumes too many addresses for a single subnet when smaller masks could suffice, failing the requirement for the most efficient use of address space.

/26

Why it fails: A /26 mask provides 62 usable host addresses. Although this supports 25 hosts, it is less efficient than a /27 mask. In networking, efficiency is defined by minimizing unused IP addresses within a subnet to maximize the total number of subnets available from the parent block.

/28

Why it fails: A /28 mask provides only 14 usable host addresses after subtracting the network and broadcast addresses. This is insufficient to support 25 hosts, as it would cause an addressing conflict or force hosts to be disconnected from the subnet due to the lack of available IP addresses.

The double-colon (::) can be used multiple times in a single IPv6 address to shorten it.

Why it fails: Using a double-colon more than once in an IPv6 address creates ambiguity regarding how many zero bits are being suppressed. The rule strictly dictates that the shorthand may be used exactly once per address to ensure that the total bit count remains fixed at 128 bits.

An IPv6 address must always be written in full 32-character hexadecimal format.

Why it fails: Requiring a full 32-character representation ignores the standard compression rules designed for human readability. Cisco IOS accepts compressed formats, and forcing a full representation is unnecessary and prone to manual input errors during device configuration, which could result in connectivity issues across the network infrastructure.

Trailing zeros in a 16-bit field can be omitted.

Why it fails: Only leading zeros in a 16-bit field can be omitted. Trailing zeros are significant because they represent the numerical value of the field. Omitting them would change the value of the address, resulting in an incorrect logical identifier that prevents communication between the intended network devices.

The subnets overlap, causing a routing conflict.

Why it fails: The subnets are 172.16.5.0/28, 172.16.5.16/28, and 172.16.5.32/28. These blocks start at increments of 16, ensuring that each subnet is distinct. Since the ranges do not overlap, there is no routing conflict, and the device can effectively route traffic between these segments without packet loss.

The configuration will fail because the IP addresses are not on the same network.

Why it fails: Interfaces on a router can belong to different subnets simultaneously. The router acts as the gateway for these distinct networks. As long as the physical layer is operational and the subnets are logically separated, the router will successfully route packets between these different network segments as expected.

The mask /28 is invalid for these specific IP addresses.

Why it fails: A /28 mask is a valid CIDR representation for an IPv4 address. It corresponds to a subnet mask of 255.255.255.240. The assignment of these addresses is mathematically sound and adheres to standard subnetting rules for IPv4, allowing the router to calculate network boundaries correctly for local packet forwarding.

/25

Why it fails: A /25 mask corresponds to 255.255.255.128. This value is derived from having one bit set in the last octet (10000000). The decimal 128 is significantly different from 224, indicating this is the incorrect CIDR equivalent for the provided subnet mask in the question stem.

/26

Why it fails: A /26 mask corresponds to 255.255.255.192. This is calculated by having two bits set in the last octet (11000000). Comparing 192 to 224 shows that this option is incorrect, as the number of bits in the mask is lower than what is required for 224.

/28

Why it fails: A /28 mask corresponds to 255.255.255.240. This is calculated by having four bits set in the last octet (11110000). Since 240 is greater than 224, this option is incorrect, as it represents a subnet mask that accommodates fewer host addresses than the requested 255.255.255.224 mask.

127.0.0.0/8

Why it fails: The 127.0.0.0/8 range is reserved for loopback testing. It is not a private address range in the context of RFC 1918, but rather a diagnostic range used for testing the internal protocol stack of a host. Sending traffic to this range remains local to the device itself.

224.0.0.0/4

Why it fails: The 224.0.0.0/4 range is designated for multicast traffic. It is not a private unicast range. Using these addresses for standard host configuration would prevent the intended network functionality, as multicast traffic is handled differently than standard unicast data packets in a routed Cisco environment.

/24

Why it fails: A /24 mask provides 254 usable addresses. For a point-to-point link, this is highly inefficient, as it wastes 252 IP addresses that could have been used elsewhere. Network design best practices dictate using the smallest prefix necessary to minimize address exhaustion and maintain clean, hierarchical routing tables.

/28

Why it fails: A /28 mask provides 14 usable addresses. While it is smaller than a /24, it is still far too large for a simple point-to-point connection between two routers. Excessively large subnets increase the complexity of routing tables and contribute to inefficient management of limited IPv4 address spaces.

/29

Why it fails: A /29 mask provides 6 usable addresses. Although smaller than a /28, it still leaves four unused IP addresses on the link. In large-scale network deployments, this type of inefficiency adds up, potentially requiring the use of additional address blocks sooner than necessary, which is a poor design choice.

The MAC address of the destination device.

Why it fails: The MAC address is a 48-bit hardware address used for Layer 2 delivery on a local network segment. The subnet mask is a Layer 3 concept that functions independently of the physical hardware address. Confusing these two layers is a fundamental error in networking diagnostics and troubleshooting.

The default gateway for the host.

Why it fails: A default gateway is a specific IP address assigned to a router interface, not a function of the subnet mask. While the mask is used to determine if a destination is local or remote, it does not define the identity or existence of the default gateway device itself.

The TCP port number for the application.

Why it fails: TCP port numbers are Layer 4 identifiers used to distinguish between different services or applications running on a host. The subnet mask is strictly a Layer 3 addressing tool. Mapping a subnet mask to port numbers is a category error that ignores the fundamental separation of protocol layers.