Cisco 200-301 Practice Test 63
Question 620
A router's OSPF interface state is EXSTART for a long period, and peer MTU values differ. Which likely problem should be tested?
- The NTP server's stratum is higher than 10
- A different local router ospf process number
- The router's DNS domain suffix differs from its peer
- OSPF database-description exchange can stall because of MTU mismatch
Explanation
Correct Answer
D:OSPF neighbors in EXSTART negotiate database-description exchange parameters before progressing toward FULL adjacency. On many implementations an interface MTU mismatch can cause database-description packets to be rejected, leaving the adjacency stuck around EXSTART or EXCHANGE. Compare the actual MTU reported on both peer interfaces and inspect adjacency logs or packet captures; correct the transport MTU discrepancy before considering exceptions such as ip ospf mtu-ignore. Ensure area and timers also agree, but the provided differing MTUs are the strongest clue.
Incorrect Answers
A:NTP stratum is related to the distance of a time source from its reference and does not govern OSPF adjacency database-description exchange. A high-stratum clock might make log timing less trustworthy, but it would not explain a neighbor pair stuck in EXSTART with different interface MTUs. Inspect OSPF neighbor debugging and interface parameters first.
B:OSPF process IDs in traditional IOS are locally significant and need not match across neighbors for an adjacency to form. Matching area, network type, timers and other relevant parameters matters, but a different local process number alone is not the stated EXSTART cause. Focus on the documented MTU disagreement rather than copying a neighbor's arbitrary process identifier.
C:A router's DNS suffix helps resolve short names and is unrelated to exchanging OSPF database-description packets between IP neighbors. OSPF runs directly over IP protocol 89 and establishes adjacencies using protocol and interface conditions, not host naming suffixes. A DNS domain mismatch cannot diagnose the specified MTU difference during adjacency negotiation.
Question 621
An engineer adds a fifth physical member to an existing LACP bundle; its speed differs from all four original ports. What should be checked?
- Whether the member ports all have different native VLANs
- Compatible speed and duplex across participating EtherChannel member ports
- Whether the members have unique OSPF area identifiers
- Whether the firewall's HTTP proxy has a matching hostname
Explanation
Correct Answer
B:LACP EtherChannel member links must satisfy platform compatibility rules, including suitable matching speed and duplex characteristics, before being bundled as one logical interface. A fifth link that negotiates a different speed from the four active members may be rejected, suspended or left outside the channel depending on platform behavior. Compare physical interface speed, duplex, channel-group configuration and bundle status with show etherchannel summary. Fix member compatibility rather than assuming LACP can normalize arbitrary physical line rates.
Incorrect Answers
A:All members of an EtherChannel trunk should use compatible VLAN and native VLAN settings, not intentionally different native VLANs. A mismatch can lead to suspended members or misclassified untagged frames, but making each member unique would worsen consistency. The reported problem is a fifth link with a different physical speed, so link aggregation compatibility is the first concern.
C:OSPF areas define where router adjacencies and link-state databases operate, not whether physical switchports may participate in one Ethernet channel. An EtherChannel might carry routed traffic above its link aggregation, but its member eligibility is checked at the Ethernet and aggregation layers. Changing area identifiers cannot correct a 25-gigabit port mixed with incompatible slower members.
D:An HTTP proxy hostname affects application-layer requests passing through a proxy and has no relationship to switch member port speed or LACP partner negotiation. Firewall management could be relevant if the channel carries user traffic after establishment, but not to the physical ability to aggregate a new member. Check the channel's local and peer port status first.
Question 622
A RIP route learned for 172.20.9.0/24 reaches a hop-count metric of 16 after a failure. What does that value mean in RIP route selection?
- It is the strongest possible route because high hop count means higher bandwidth
- It can be used normally as long as the administrative distance is 120
- RIP treats metric 16 as unreachable, so the route cannot serve as a valid forwarding candidate
- The routing table must load-balance through sixteen next hops
Explanation
Correct Answer
C:RIP defines a hop count of 16 as infinity, meaning the learned destination is unreachable through that path. A valid RIP path normally has a metric from 1 through 15; the value 16 is used in route poisoning and convergence behavior after failure. Do not install or prefer that path merely because it is present in an update. Verify timers, alternate reachable paths and possible routing loops when troubleshooting the failed destination.
Incorrect Answers
A:RIP uses hop count as its metric, with a lower count preferred among reachable destinations. A value of sixteen is not an indication of extra bandwidth or better service; it is the protocol's defined infinity. Interpreting it as superior would choose a route RIP is signaling as unavailable.
B:Administrative distance 120 is a typical Cisco IOS preference value for RIP compared with other sources, but it does not make an unreachable RIP metric valid. RIP's internal metric 16 marks the destination unusable regardless of the source's distance. The device needs a surviving valid route, a lower-metric update or another routing source.
D:The numeral sixteen is RIP's unreachable metric threshold and has no relationship to the number of equal-cost next hops the router must use. Load balancing is a separate behavior subject to qualifying route costs and platform limits. An unreachable advertisement cannot compel forwarding through sixteen interfaces.
Question 623
An interface is assigned the IPv6 prefix 2001:db8:ab:cd::/64 and must communicate with neighbor 2001:db8:ab:cd::78. Which comparison shows they are on the same /64 link?
- The two interfaces must share the same MAC address
- Their first 128 bits must be exactly the same
- Their last 64 bits are identical to all hexadecimal zeroes
- Their first four hexadecimal hextets match the 64-bit network prefix
Explanation
Correct Answer
D:An IPv6 /64 network prefix covers the first 64 bits, exactly four 16-bit hexadecimal hextets. Both addresses start with 2001:db8:ab:cd, so their high 64 bits match while the interface identifiers can differ, making them candidates for the same on-link subnet. Confirm the interface prefix length and correct Layer 2 attachment; matching an address prefix alone does not establish physical reachability or authorize a firewall to pass traffic.
Incorrect Answers
A:Ethernet MAC addresses identify link-layer interfaces and usually differ between neighboring devices; they need not be identical for two IPv6 addresses to belong to one subnet. A host can use Neighbor Discovery to learn the other device's MAC while retaining unique Layer 2 identities. Compare the IPv6 network prefix, not the underlying hardware addresses.
B:Requiring all 128 address bits to match would describe the exact same IPv6 address, potentially causing a duplicate, not two distinct hosts sharing a subnet. A /64 subnet reserves the high 64 bits as network prefix while the low 64 bits identify interfaces. The two devices can communicate on-link with different interface IDs under the same prefix.
C:The last 64 bits are the interface-identifier portion in this ordinary /64 example and are allowed to differ between neighbors. An all-zero interface ID is not a requirement for on-link adjacency; both endpoints normally need unique unicast addresses. The question supplies ::78 for one neighbor, disproving the proposal that all low bits must be zero.
Question 624
A Cisco access port learns the first legitimate endpoint MAC and should retain that address as a sticky secure MAC. Which configuration element fits?
- switchport trunk native vlan 1
- switchport port-security mac-address sticky
- router ospf 1 area 0
- ip arp inspection trust
Explanation
Correct Answer
B:switchport port-security mac-address sticky enables sticky secure-MAC learning on an appropriately configured Cisco access interface. The switch takes the observed source MAC and records it as a sticky secure entry that can become part of the running configuration, subject to platform support. Save the configuration if persistence across reload is required, and verify switchport port-security plus the maximum allowed addresses. The first learned address must be authorized; sticky learning alone does not validate endpoint identity.
Incorrect Answers
A:switchport trunk native vlan 1 selects the VLAN used for untagged frames on a compatible trunk; it does not learn or retain a source MAC as a port-security entry. A workstation-facing access port usually has an access VLAN rather than needing this trunk setting. The objective is persistence of a legitimate learned secure identity, so inspect port-security controls.
C:An OSPF router process manages Layer 3 route advertisement and adjacency state; it is not a switchport security mode and cannot remember source MAC addresses. Even when a multilayer switch runs OSPF, port-security sticky entries remain a separate Layer 2 access control feature. Configuring dynamic routing would not satisfy retention of the first endpoint MAC.
D:ip arp inspection trust treats ARP traffic received on a port as trusted for Dynamic ARP Inspection, typically used on appropriate infrastructure uplinks. That does not make a MAC sticky secure or impose the intended source-MAC limit. Trusting an ordinary user-facing port can weaken ARP spoofing defenses rather than protect the port's legitimate endpoint identity.
Question 625
A network operator changes a policy in the central controller, but packets still follow old paths on one switch. What boundary should be checked?
- The number of users reading the controller's marketing webpage
- Whether every host has an identical MAC address
- Reconciliation between controller intent and the device's actually installed forwarding state
- Whether the interface description matches the DNS zone file
Explanation
Correct Answer
C:A central controller expresses intended network policy, but the switch still forwards according to configuration and tables actually installed locally. Verify the control-plane update reached this switch, was accepted, and produced the expected forwarding entries or policy enforcement; inspect controller job status and the device's operating state. Check for version mismatch, failed push, offline management connectivity or delayed convergence. Desired state in a portal is not evidence the data plane has changed.
Incorrect Answers
A:The number of readers on a marketing webpage has no functional connection to applying a controller's policy to switch forwarding hardware. Management visibility might be healthy while a device fails to accept a configuration change. Investigate delivery acknowledgments, device configuration and installed forwarding state rather than a public information site's popularity.
B:Assigning every host the same MAC address would create MAC-learning instability and possible misdelivery rather than synchronize the controller with network equipment. Devices must retain appropriate distinct Layer 2 identities for switching. A stale path after a policy change indicates a control-to-device update or reconciliation issue, not a requirement for identical endpoint MACs.
D:An interface description is freeform administrative text and need not match a DNS zone file for the switch to forward packets correctly. Such descriptions can aid inventory and troubleshooting, but editing them does not reconcile stale controller intent or route tables. Compare active device policy and forwarding information to the central desired configuration instead.
Question 626
A branch router's WAN Ethernet interface must obtain a provider-assigned IPv4 lease rather than use a hardcoded address. Which client command is appropriate?
- ip address dhcp on the relevant routed interface
- ip helper-address 0.0.0.0 as the router's own address
- ip dhcp excluded-address 0.0.0.0 255.255.255.255
- switchport access vlan dhcp under a routed port
Explanation
Correct Answer
A:On a supported routed Cisco IOS Ethernet interface, ip address dhcp configures the router to request an IPv4 address and lease options from an upstream DHCP server instead of using a static interface address. The WAN port needs a viable link to the provider's DHCP service and should not simultaneously retain an incompatible hardcoded address. Verify the acquired address, mask, route information and lease status after configuration; additional security or routing settings may be necessary for Internet reachability.
Incorrect Answers
B:ip helper-address is used on a receiving Layer 3 interface to relay suitable broadcast services, including DHCP client requests, toward a configured server. It is not the syntax to obtain the router's own WAN IPv4 lease. Setting a relay target to 0.0.0.0 does not turn an interface into a DHCP client and may be invalid or ineffective.
C:ip dhcp excluded-address controls addresses the router's own DHCP server must not hand to clients from configured scopes. It neither turns the WAN port into a client nor requests an address from the provider. Excluding every possible address would also be an inappropriate pool policy for a branch serving local DHCP clients.
D:switchport access vlan configures a Layer 2 switch access interface, while the question specifies a routed WAN Ethernet port requiring DHCP client operation. The word dhcp is not a VLAN identifier or supported access-VLAN mode. Use the routed interface's IPv4 DHCP client command rather than attempting to convert it to Layer 2.
Question 627
A static route is configured using a destination IP that is not aligned to its /26 mask, and the CLI normalizes the prefix. What should be confirmed?
- The route's DNS search suffix contains 26 characters
- The source port's EtherChannel LACP mode matches the mask length
- The installed route's normalized network prefix matches the intended destination block
- The DHCP lease lifetime equals the last octet of the host address
Explanation
Correct Answer
C:A /26 network has 64-address boundaries, so a configured destination with nonzero host bits may be normalized to the containing network address. Check the actual show ip route static entry and compare its installed prefix with the subnet the engineer intended to reach. For example, an address within a 64-address block identifies that block, not an arbitrary host-only destination. Also verify next-hop reachability; an accepted command is not proof the correct network was targeted.
Incorrect Answers
A:A DNS search suffix affects how unqualified names are resolved, not how IOS normalizes a static-route destination against its subnet mask. The digit 26 in /26 denotes the number of prefix bits and has no required relationship to the count of hostname characters. Verify the installed network prefix and next hop, not the DNS domain text.
B:LACP mode controls member-port negotiation for an Ethernet channel and does not need to numerically match a static route's prefix length. Even if the next-hop link traverses an EtherChannel, prefix normalization is handled by IP network masks, independent of the aggregation protocol. Diagnose the intended destination and mask before changing switch bundle settings.
D:DHCP lease duration expresses how long a client can use assigned configuration and is unrelated to the network bits of a static-route destination. Matching a lease timer to an IP address's final octet would be coincidental and operationally meaningless. The correction must concern the /26 bitmask and its corresponding network boundary.
Question 628
An alternate STP port stops receiving BPDUs because of a unidirectional failure, risking a loop. Which feature is designed for missing expected BPDUs?
- Changing the routed SVI IP address
- Loop Guard on the appropriate non-designated STP link
- Increasing NTP poll intervals on both switches
- BPDU Filter to suppress additional neighbor BPDUs permanently
Explanation
Correct Answer
B:Loop Guard can protect appropriate non-designated STP ports that should continue receiving BPDUs, such as alternate or root roles. If expected BPDUs disappear without an orderly topology change, it can place the port in a loop-inconsistent condition instead of allowing an unsafe transition to forwarding. Enable it only where the topology calls for this protection, verify compatibility with the STP mode and distinguish it from Root Guard, which handles superior BPDUs on designated ports.
Incorrect Answers
A:Changing the IP address of an SVI modifies Layer 3 gateway behavior and does not detect missing spanning-tree BPDUs on an alternate or root port. A unidirectional failure can create dangerous Layer 2 loop conditions even when VLAN interfaces retain valid addresses. The protective feature must monitor expected STP control messages at the affected link.
C:NTP polling controls time synchronization intervals and cannot observe whether STP configuration BPDUs are missing because a fiber path became unidirectional. Reliable time is valuable for correlating spanning-tree logs but cannot enforce a loop-inconsistent state. Use STP-specific guard features and physical-layer fault detection rather than adjusting unrelated time-server schedules.
D:BPDU Filter suppresses BPDU processing or transmission in supported configurations, potentially hiding topology messages rather than recognizing their unexpected absence. It can be hazardous when applied to an interswitch link because STP depends on BPDUs to prevent loops. Loop Guard is the feature designed to react to a link that stops delivering BPDUs where they should be received.
Question 629
An IPv6 interface identifier is built using modified EUI-64 from MAC address 00:1A:2B:3C:4D:5E. Which 64-bit interface identifier is produced?
- 001a:2bff:fe3c:4d5e (insert FF:FE but leave the universal/local bit unchanged)
- 021a:2bff:fe3c:4d5e (insert FF:FE and flip the universal/local bit)
- 001a:2b3c:4d5e:0000 (append zeros without the required insertion)
- 021a:2b3c:4d5e:0000 (flip one bit but omit FF:FE)
Explanation
Correct Answer
B:Split the MAC into the first three and last three octets, insert ff:fe between them and invert the universal/local bit in the first octet. For 00:1A:2B:3C:4D:5E, that changes the leading 00 to 02 and produces 021a:2bff:fe3c:4d5e. This is the conventional modified EUI-64 identifier, which can be combined with a suitable /64 prefix. Modern operating systems may instead use privacy or stable-random identifiers, so the calculation describes this specific method rather than every host's address behavior.
Incorrect Answers
A:This candidate inserts the correct ff:fe bytes between the first and last MAC segments but leaves the first octet 00 unchanged. Modified EUI-64 also inverts the universal/local bit in that first octet, converting 00 to 02. Without the bit flip, this 64-bit sequence does not represent the conventional modified identifier for the given MAC.
C:Simply appending sixteen zero bits to the 48-bit MAC can produce a 64-bit value, but it does not insert ff:fe in the standard middle position. It also leaves the universal/local bit unchanged. The numerical length alone is insufficient to establish the required modified EUI-64 mapping.
D:The leading 02 correctly shows a flipped universal/local bit, but this candidate merely appends zeros and omits the inserted ff:fe pair. Conventional modified EUI-64 requires both transformations applied in the right positions. Getting only the first-octet adjustment correct still yields a different identifier.
Question 630
An engineer must insert a permit ACE before an existing deny in a named IPv4 ACL. What feature supports this without deleting the entire list?
- Reboot clients until ACL rules randomly reorder
- Assign the router's default gateway to the user's MAC address
- Reconfigure the OSPF router ID to a lower number
- Use sequence numbers to insert the ACE at the desired match position
Explanation
Correct Answer
D:Cisco named IPv4 ACLs can use sequence numbers to place a new permit ACE before an existing deny rather than deleting and rebuilding the entire list. Choose an available sequence value that falls between the relevant entries, then confirm with show ip access-lists that permit precedes the deny. Because ACLs are evaluated top-down on first match, placement is critical; if numbering gaps are exhausted, use the platform's resequence capability to create room safely.
Incorrect Answers
A:ACL evaluation follows explicit rule order; rebooting clients cannot randomly reorder access-control entries in a reliable or appropriate way. Depending on the device, a client reboot might refresh a session but does not insert a new ACE before an existing deny. The operator must edit the named ACL itself using supported line ordering.
B:A default gateway is a Layer 3 next-hop IP address and cannot meaningfully be assigned to a user's MAC address as an ACL sequence rule. MAC-to-IP neighbor mapping is separate from IPv4 policy ACE order. This proposed change would not affect which permit or deny statement is evaluated first for matching packets.
C:OSPF router ID identifies a routing process participant and can influence OSPF elections, not the ordering of named IPv4 ACL entries. Changing it risks routing protocol disruption without adding the requested permit. Policy matching will continue to follow ACL entry sequence until the ACL itself is edited.