Infrastructure Services practice questions

Configure a route distinguisher (RD) and route target (RT) under the VRF address family.

Why it fails: RD and RT are essential for MPLS L3VPN to identify VPN routes and control import/export, but they do not specifically prevent routing loops when redistributing OSPF into MP-BGP. The loop prevention is achieved by using the OSPF domain ID and the BGP extended community, which are separate from RD/RT configuration.

Enable OSPF sham link between PE routers to carry VPN traffic.

Why it fails: An OSPF sham link is used to create a backdoor link between VPN sites over the MPLS backbone to avoid routing through the hub site, but it does not prevent loops when redistributing OSPF into MP-BGP. Sham links are for optimal routing, not for loop prevention in redistribution.

Configure BGP cost community to influence path selection.

Why it fails: BGP cost community is used to influence best path selection, but it does not prevent routing loops during OSPF redistribution. The loop prevention mechanism for OSPF into MP-BGP is the OSPF domain ID carried as a BGP extended community, not the cost community.

IRDP

Why it fails: IRDP (ICMP Router Discovery Protocol) is a host-based discovery protocol that allows hosts to discover routers, but it does not provide a virtual IP address or first-hop redundancy in the same way as HSRP, VRRP, or GLBP. IRDP does not support the concept of a shared virtual IP, so it cannot satisfy the requirement of using the active router's real IP.

HSRP version 2

Why it fails: HSRP does not allow the virtual IP address to be the same as an interface IP address on the active router; doing so would cause an IP address conflict. HSRP uses a separate virtual MAC address and requires a distinct virtual IP. Immediate preemption can be configured, but the identical IP requirement is not supported, making HSRP unsuitable for this design.

GLBP

Why it fails: GLBP provides load balancing across multiple gateways, but it also requires a separate virtual IP address distinct from any physical interface IP. The requirement to use the same IP as the active router is not met. While GLBP supports preemption and immediate failover, the identical IP constraint rules it out for this design.

ipv6 address eui-64

Why it fails: The ipv6 address eui-64 command is used to configure a global IPv6 address with an EUI-64 interface identifier based on a specified prefix, but it does not affect the link-local address. Link-local addresses always use EUI-64 by default when IPv6 is enabled on an interface, unless manually overridden.

ipv6 address autoconfig

Why it fails: The ipv6 address autoconfig command enables stateless address autoconfiguration (SLAAC) to obtain a global IPv6 address from a router advertisement, but it does not control the generation of the link-local address. Link-local addresses are automatically generated when IPv6 is enabled, and EUI-64 is used by default unless manually configured otherwise.

ipv6 address link-local

Why it fails: The ipv6 address link-local command is used to manually configure a link-local address with a specific interface identifier, overriding the automatic EUI-64 generation. If the goal is to have the router automatically generate a link-local address using EUI-64, this command is not needed and would actually disable the automatic behavior.

OSPF route type

Why it fails: The OSPF route type extended community indicates whether the route was learned as intra-area, inter-area, or external. While it helps preserve the OSPF route type across the MPLS VPN, it does not by itself prevent routing loops. The domain ID is the primary mechanism for loop prevention when redistributing OSPF into BGP.

Route target

Why it fails: The route target extended community is used to control VPN route import and export between VRFs. While essential for MPLS L3VPN, it does not specifically prevent OSPF routing loops when redistributing OSPF into BGP. The route target identifies which VRFs can import the route, but the loop prevention for OSPF is handled by a different community.

Site of origin

Why it fails: The site of origin (SoO) extended community is used to prevent routing loops when a site is multihomed to multiple PEs and uses the same AS. However, for OSPF, the specific extended community used to prevent loops is not SoO but rather the OSPF domain ID or route type. SoO is more relevant for BGP or RIP scenarios.

Disable split horizon on the hub's tunnel interface.

Why it fails: Split horizon is a routing loop prevention mechanism, often relevant in DMVPN with EIGRP or RIP. Disabling it on the hub may be necessary for routing updates, but it does not directly enable spoke-to-spoke tunnel formation. The primary requirements are NHRP shortcut and matching network ID.

Ensure the tunnel interface is configured with a /24 subnet mask.

Why it fails: The subnet mask on the tunnel interface does not affect the formation of spoke-to-spoke tunnels. DMVPN typically uses a /24 or similar for the tunnel network, but the mask itself does not enable direct spoke communication. The critical factors are NHRP and routing configuration.

Enable NHRP redirect on the spokes.

Why it fails: NHRP redirect is typically configured on the hub, not the spokes. The hub sends redirect messages to spokes to inform them of a better path. Enabling redirect on spokes is unnecessary and may not have any effect. The spokes need shortcut, not redirect.

IPv6 Destination Guard

Why it fails: IPv6 Destination Guard filters traffic based on the destination address, ensuring that packets are only sent to addresses that are known in the binding table. It does not prevent rogue DHCPv6 servers from responding to client requests. It is used to mitigate address scanning and DoS attacks, not DHCPv6 server spoofing.

IPv6 Source Guard

Why it fails: IPv6 Source Guard uses the IPv6 snooping binding table to filter traffic based on source IPv6 addresses. It prevents address spoofing but does not block DHCPv6 server messages. It is not designed to prevent rogue DHCPv6 servers from assigning addresses; it only ensures that hosts use their assigned addresses.

IPv6 DHCP Guard

Why it fails: IPv6 DHCP Guard filters DHCPv6 server messages received on untrusted ports, but it does not prevent a rogue server from assigning addresses if the server is connected to a trusted port. It is primarily used to block DHCPv6 server replies on access ports. However, the question asks for a feature to prevent rogue servers, which typically requires designating trusted ports and enabling guard on untrusted ports.

Configure the spokes with the ip nhrp shortcut command on their multipoint GRE interfaces.

Why it fails: The ip nhrp shortcut command is used on spokes to enable them to use a shortcut path when they receive an NHRP redirect from the hub. However, the hub must first be configured to send redirects with ip nhrp redirect. Without the hub sending redirects, the spokes cannot initiate the shortcut process. Therefore, the hub configuration is the missing piece.

Enable split horizon on the hub's multipoint GRE interface to allow spoke advertisements.

Why it fails: Split horizon controls the advertisement of routes back out the same interface they were learned from. In DMVPN, split horizon must typically be disabled on the hub's mGRE interface to allow spokes to learn each other's routes, but this does not directly enable spoke-to-spoke direct communication. It only ensures routing information is propagated.

Configure the hub as a route reflector for the overlay routing protocol.

Why it fails: Route reflection is used in BGP to reduce the number of IBGP sessions and is not directly related to DMVPN spoke-to-spoke communication. While BGP can be used as the routing protocol in DMVPN, route reflection alone does not trigger NHRP resolution or direct spoke-to-spoke tunnels. The key missing component is NHRP redirect.

Enable Cisco Express Forwarding (CEF) globally with the ip cef command.

Why it fails: While CEF is required for MPLS forwarding and is enabled by default on most modern Cisco IOS routers, it is not a specific task to enable MPLS VPN functionality. The question asks for tasks required to enable MPLS VPNs; CEF is a prerequisite but is typically already enabled. Thus, it is not the best answer for the two required tasks.

Configure BGP with the address-family ipv4 vrf command for each VRF.

Why it fails: Configuring BGP with address-family ipv4 vrf is a common method to exchange routes between PE and CE routers, but it is not strictly required to enable MPLS VPN functionality. Other routing protocols (e.g., OSPF, EIGRP) can be used in the VRF. The essential tasks are enabling MPLS on core interfaces and configuring VRFs. BGP is often used but not mandatory for the VPN to function.

Enable MPLS LDP on all interfaces, including customer-facing interfaces.

Why it fails: MPLS LDP should be enabled on core-facing interfaces, not on customer-facing interfaces. Customer-facing interfaces are typically IP-only and not part of the MPLS core. Enabling LDP on customer interfaces could lead to unnecessary label distribution and potential security issues. Therefore, this is not a required task and is actually incorrect practice.

Configure 'ip forward-protocol udp bootps' globally.

Why it fails: The 'ip forward-protocol udp bootps' command enables forwarding of UDP port 67 (BOOTP server) broadcasts, but it is enabled by default. Disabling it would prevent DHCP relay, but the scenario does not indicate it was disabled. Therefore, this command is not required to make DHCP relay work; the default behavior already forwards these packets.

Configure a static route to the DHCP server.

Why it fails: A static route to the DHCP server is not required for DHCP relay to function, provided the router already has a route to reach 10.1.1.10. The 'ip helper-address' command causes the router to unicast DHCP requests to the server, and normal routing will handle delivery. If a route were missing, the router would drop the packets, but the scenario does not indicate a routing issue.

Apply an access list to permit UDP ports 67 and 68.

Why it fails: An access list is not required for DHCP relay to work; the router will forward DHCP packets by default if 'ip helper-address' is configured. An access list could block DHCP if applied incorrectly, but the scenario does not mention any ACL. Therefore, adding an ACL is unnecessary and could introduce complexity without solving the problem.

IPv6 Source Guard

Why it fails: IPv6 Source Guard is a security feature that prevents source address spoofing by validating the source IPv6 address of packets against the binding table. It does not inspect or filter Router Advertisement messages. Its focus is on source address legitimacy, not on controlling which devices can send RAs. Thus, it is not the correct choice for blocking rogue RAs.

IPv6 DHCP Guard

Why it fails: IPv6 DHCP Guard is designed to block DHCPv6 server messages from untrusted ports. It prevents rogue DHCPv6 servers from assigning addresses but does not filter Router Advertisement messages. While it is a valuable First Hop Security feature, it does not mitigate rogue RAs. Therefore, it does not meet the specific requirement of preventing rogue RA processing.

IPv6 Destination Guard

Why it fails: IPv6 Destination Guard is used to block traffic to unassigned destination addresses, mitigating reconnaissance and DoS attacks. It does not filter Router Advertisements. While it is part of the First Hop Security suite, it does not address rogue RA messages. Therefore, it is not relevant to the scenario of preventing rogue RA processing.

area 0 authentication message-digest

Why it fails: The 'area 0 authentication message-digest' command enables MD5 authentication for the entire OSPF area, but it must be configured on all routers in the area. While it is a valid method, it is not the interface-specific command. The question asks for the command required on the interface; the area command is configured in router configuration mode, not on the interface. However, if area authentication is enabled, the interface inherits it, but the interface command is still needed to set the key.

ip ospf message-digest-key 1 md5 cisco

Why it fails: The command 'ip ospf message-digest-key 1 md5 cisco' configures the MD5 key and password on the interface. While it is necessary for authentication, it does not by itself enable MD5 authentication. The interface must also have 'ip ospf authentication message-digest' to activate authentication. Without that command, the key is defined but not used for authentication.

ospf authentication message-digest

Why it fails: 'ospf authentication message-digest' is not a valid Cisco IOS command. The correct command to enable OSPF MD5 authentication on an interface is 'ip ospf authentication message-digest'. This distractor might confuse those who think authentication is configured in router mode, but interface-level authentication requires the 'ip ospf' prefix.

ip nhrp network-id 100

Why it fails: ip nhrp network-id is used to identify the NHRP network and must match on all routers in the DMVPN cloud. While it is required for NHRP to function, it is not specific to enabling spoke-to-spoke direct communication or redirects. It is a basic configuration parameter, not a Phase 3 feature. The question asks for commands required to support Phase 3 functionality, so this is not the correct choice.

ip nhrp shortcut

Why it fails: ip nhrp shortcut is configured on spoke routers, not the hub. It allows a spoke to use a shortcut path when it receives an NHRP redirect. The hub does not need this command; it needs ip nhrp redirect. Therefore, this command is not required on the hub for the described functionality.

ip nhrp registration no-unique

Why it fails: ip nhrp registration no-unique is used to allow multiple spokes to register with the same NHRP mapping, which is not typical in DMVPN. It is not a standard requirement for Phase 3 spoke-to-spoke communication. The hub does not need this command to send redirects or to enable direct tunnels. Therefore, it is not a correct choice.

ip forward-protocol udp 67

Why it fails: The 'ip forward-protocol udp' command modifies which UDP ports are forwarded by 'ip helper-address'. By default, UDP port 67 (DHCP server) is already forwarded, so this command is not required for basic DHCP relay. Its absence does not prevent DHCP relay from working. Therefore, it is not a critical command to verify.

ip dhcp pool VLAN10_POOL

Why it fails: A DHCP pool is only required if the router is acting as a DHCP server. In this scenario, the router is a relay agent forwarding requests to an external server. Configuring a pool is unnecessary and does not affect relay functionality. The engineer should not focus on this command for troubleshooting relay issues.

ip routing

Why it fails: The 'ip routing' command enables IP routing globally. While necessary for the router to route packets, it is not specific to DHCP relay. If the router is already routing other traffic, this command is likely already enabled. It is not a primary troubleshooting step for DHCP relay issues, although it is a prerequisite for any routing.

IPsec tunnel protection with dual hub redundancy

Why it fails: IPsec tunnel protection secures the mGRE tunnel but does not provide the redirection or shortcut capabilities required for spoke-to-spoke communication. Dual hub redundancy is a separate design, but without NHRP redirect, spokes cannot learn optimal paths dynamically.

NHRP with multiple NHS entries and dynamic mapping

Why it fails: NHRP with multiple NHS entries allows spokes to register with multiple hubs, but it does not inherently provide the hub with the ability to redirect spoke-to-spoke traffic or advertise a single public IP for dual ISPs. This is a basic NHRP feature that does not address the redundancy and redirection requirements.

BGP with multipath and DMVPN Phase 2

Why it fails: BGP multipath can provide load balancing, but DMVPN Phase 2 does not support dynamic spoke-to-spoke redirection by the hub. Phase 2 requires spokes to have a route to the hub for all destinations, which does not meet the requirement for dynamic redirection.

ip nhrp map multicast dynamic

Why it fails: The ip nhrp map multicast dynamic command enables dynamic multicast mapping for routing protocols over DMVPN, typically used on the hub to allow spokes to receive multicast traffic. It does not directly enable spoke-to-spoke direct tunnels; that requires NHRP redirect and shortcut.

ip nhrp network-id 1

Why it fails: The ip nhrp network-id command assigns an NHRP network ID to the interface, which must match on all DMVPN routers in the same cloud. It is a basic configuration requirement but does not by itself enable spoke-to-spoke direct communication; that functionality relies on NHRP redirect and shortcut.

ip nhrp shortcut

Why it fails: The ip nhrp shortcut command is configured on the spokes, not the hub, and allows the spoke to use a shortcut path when it receives an NHRP redirect. Without the hub sending redirects, shortcut alone does not enable spoke-to-spoke communication. Therefore, it is not the command needed on the hub.

Configure the spokes as point-to-multipoint network.

Why it fails: Setting the spokes to point-to-multipoint would make them treat the tunnel as a point-to-multipoint network, which does not use DR/BDR elections and sends OSPF packets as unicast. However, this would not match the hub's broadcast network type, potentially causing adjacency issues. The correct approach when the hub is broadcast and spokes are non-broadcast is to add neighbor statements, not change the network type.

Configure the hub as a point-to-multipoint network.

Why it fails: Changing the hub to point-to-multipoint would alter the OSPF network type on the hub, but the question specifies that the hub is configured as broadcast. The issue is on the spokes, which are configured as non-broadcast and need a neighbor statement. Changing the hub's network type would not address the spoke configuration and could introduce additional complexity. It is not the required change for the given scenario.

Configure the hub with a neighbor statement for each spoke.

Why it fails: Configuring neighbor statements on the hub is not necessary because the hub is broadcast and will send multicast hellos. The spokes, being non-broadcast, will not respond to multicast hellos unless they have a neighbor statement pointing to the hub. Therefore, adding neighbor statements on the hub alone would not resolve the issue; the spokes must be configured with the hub's address.

aaa authorization exec default group tacacs+ if-authenticated

Why it fails: This command configures authorization for EXEC commands to use TACACS+ and then, if the server is unreachable, to allow access if the user is already authenticated. However, the requirement is to allow EXEC commands with privilege level 1 when the server is down, not to bypass authorization based on authentication. The 'if-authenticated' keyword grants full access if the user authenticated, which may not restrict to privilege level 1.

aaa authorization commands 1 default group tacacs+ local

Why it fails: This command authorizes commands at privilege level 1 using TACACS+ and then local. However, the requirement is about EXEC commands, not specifically level 1 commands. EXEC authorization is separate and controls the initial privilege level upon login. This command would authorize individual commands after the user is already at a privilege level, which is not the primary need.

aaa authorization exec default group tacacs+ none

Why it fails: The 'none' keyword means that if TACACS+ is unavailable, authorization is bypassed entirely, granting the user full access without any authorization checks. This does not restrict the user to privilege level 1; it typically grants the default privilege level configured on the line, which could be higher. This does not meet the requirement of allowing only privilege level 1.

Configure the hub with a unique NHRP network ID and enable NHRP authentication.

Why it fails: A unique NHRP network ID and authentication are required for all DMVPN members to form the initial hub-and-spoke topology, but they do not provide the dynamic direct spoke-to-spoke capability of Phase 3. Those features are part of basic NHRP setup, not the redirect/shortcut mechanism.

Enable IPsec tunnel protection on the hub and configure IKEv2 with multiple proposals.

Why it fails: IPsec tunnel protection and IKEv2 proposals are necessary for encryption and authentication of the DMVPN tunnels, but they do not enable direct spoke-to-spoke communication. The key to Phase 3 is NHRP redirect and shortcut, which operate at the NHRP layer, independent of the IPsec configuration.

Configure the hub as a route reflector and enable BGP next-hop-self on all spokes.

Why it fails: Route reflectors and BGP next-hop-self are used for routing protocol scalability and path selection, but they do not trigger dynamic spoke-to-spoke tunnels in DMVPN. DMVPN Phase 3 relies on NHRP mechanisms, not BGP, to signal the availability of a direct path. BGP configuration alone will not create on-demand tunnels.

Set the OSPF domain ID to match the BGP autonomous system number.

Why it fails: The OSPF domain ID is used to prevent routing loops when redistributing OSPF into BGP and back, but it does not attach the necessary BGP extended community for VPNv4. It is a separate mechanism and not sufficient for route-target export.

Enable OSPF as a BGP network statement under the global BGP configuration.

Why it fails: Using a network statement in global BGP does not redistribute OSPF routes into BGP; it only advertises networks that are already in the IP routing table. Moreover, it does not apply the required extended community for VPNv4. Redistribution must be done under the VRF address family.

Configure a route-map to set the BGP extended community attribute to the route-target value.

Why it fails: While a route-map can set BGP extended communities, the route-target export is a specific extended community that is automatically attached when configured under the VRF address family. Manually setting it via route-map is possible but not the standard or necessary step; the correct method is to configure route-target export.

Under the VRF definition, configure 'route-target both 65000:100'.

Why it fails: The command 'route-target both 65000:100' is not valid syntax in Cisco IOS. The correct syntax requires separate 'route-target export' and 'route-target import' commands, or the use of 'route-target both' with a specific format? Actually, Cisco IOS does support 'route-target both' as a shorthand? Let me verify: In Cisco IOS, the command 'route-target both 65000:100' is not standard; you typically use 'route-target export' and 'route-target import'. Some platforms allow 'route-target both' but it is not universally supported. However, the question specifies Cisco IOS router, and the standard configuration uses separate commands. Therefore, this option is considered incorrect due to syntax or lack of clarity. To be safe, I'll state that the correct method is separate commands, and 'both' is not a valid keyword in this context. Actually, in Cisco IOS, you can use 'route-target both' under VRF? I think it's not available; it's available in some other vendors. So it's incorrect.

Under the BGP configuration, configure 'address-family ipv4 vrf CUSTOMER' and then 'redistribute connected'.

Why it fails: Redistributing connected routes into BGP for the VRF is necessary to advertise connected networks, but it does not control route targets. Without route targets, the redistributed routes would not be tagged with the correct extended community, and other VRFs would not know how to import them. Additionally, this does not prevent other routes from being imported into CUSTOMER. Thus, this configuration is incomplete and does not meet the requirements.

Under the VRF definition, configure 'rd 65000:100'.

Why it fails: The route distinguisher (RD) is used to make VPNv4 prefixes unique, but it does not control import or export of routes between VRFs. Configuring only an RD does not specify which route targets to use, so the VRF would not have any import or export policies. Without route targets, routes would not be imported or exported correctly, leading to connectivity issues. Therefore, this configuration alone is insufficient.