VPN Technologies practice questions

The tunnel IP addresses are in different subnets.

Why it fails: If the tunnel IP addresses were in different subnets, the routers would not have a common subnet for OSPF neighbor establishment, but the scenario gives only R1's tunnel IP. There is no indication of a subnet mismatch. Moreover, OSPF can form adjacency over point-to-point links even with different subnets if network type is point-to-point, so this is not definitive.

The tunnel interface is configured as passive under OSPF.

Why it fails: If the tunnel interface were passive, OSPF would not send hellos on it, preventing adjacency. However, the scenario does not mention OSPF passive-interface configuration, and the tunnel is up/up. Without evidence of passive configuration, this is speculative and not the most likely cause.

The tunnel destination IP address is not reachable via the underlay network.

Why it fails: If the destination were unreachable, the tunnel interface would typically be down/down because GRE relies on the underlay route to the destination. The scenario states the tunnel is up/up, so reachability is not the issue. This option is a common first check but does not explain the up/up state with failed OSPF.

Add 'ip nhrp map' entries for all remote spokes on each spoke.

Why it fails: Static NHRP map entries are used in Phase 1 or for specific purposes, but they are not required for Phase 3 shortcut switching. In fact, static mappings can prevent dynamic shortcut resolution. The issue is more likely due to missing redirect/shortcut commands, not the absence of static maps.

Configure 'ip nhrp network-id' to match on all routers.

Why it fails: Matching network IDs is required for NHRP registration and resolution to work at all. If mismatched, spokes would not register with the hub, and the DMVPN would not form. However, the scenario states that spoke-to-spoke traffic goes through the hub, implying basic connectivity is working, so the network ID is likely already correct.

Enable 'ip nhrp map multicast dynamic' on the hub.

Why it fails: This command enables the hub to replicate multicast packets to all spokes dynamically, which is used for routing protocols like EIGRP or OSPF. It does not affect spoke-to-spoke shortcut switching or NHRP resolution for unicast traffic, so it will not resolve the issue of traffic still traversing the hub.

Configure BGP with the default-originate command in the global routing table.

Why it fails: Using BGP default-originate in the global table would inject a default route into BGP, but it does not automatically leak that route into a VRF. VRFs have separate BGP instances or address families. To leak routes between VRF and global, you need specific import/export policies or static routes with the global keyword. This command alone does not achieve the desired selective access.

Configure route leaking from the global routing table to CUSTOMER_A using a static route with the global keyword.

Why it fails: This configuration would leak routes from the global table into CUSTOMER_A, which is the opposite direction. While it might allow CUSTOMER_A to learn global routes, it does not allow CUSTOMER_A to initiate traffic to the global table unless return routes exist. The requirement is for CUSTOMER_A to reach the global table, so leaking from global to VRF is not sufficient; you need the VRF to have a route to the global next-hop.

Configure a default route in CUSTOMER_B pointing to the global routing table.

Why it fails: Adding a default route in CUSTOMER_B to the global table would allow CUSTOMER_B to reach the global table, which violates the requirement that CUSTOMER_B remains isolated. The scenario specifies that only CUSTOMER_A should have access to the global table, so this would be incorrect.

Group Member (GM)

Why it fails: Group Members (GMs) are the routers that actually encrypt and decrypt traffic using the group policy received from the Key Server. They do not distribute keys to other members; instead, they register with the KS to obtain the policy. While GMs can be configured to act as secondary KSs for redundancy, the primary responsibility for key distribution lies with the KS, not the GMs.

Group Domain of Interpretation (GDOI) server

Why it fails: GDOI is the protocol used by the Key Server to communicate with Group Members, not a separate server component. The GDOI server function is integrated into the Key Server. Saying a GDOI server is responsible for key distribution is misleading because GDOI is the mechanism, not the entity. The Key Server is the actual component that implements GDOI to distribute keys.

Certificate Authority (CA)

Why it fails: A Certificate Authority (CA) issues digital certificates used for authentication between the Key Server and Group Members. While GET VPN can use certificates for device authentication, the CA does not distribute the group encryption keys or security policy. Its role is limited to identity verification, not key management. The actual key distribution is performed by the Key Server after authentication succeeds.

Configure the spokes with ip nhrp redirect.

Why it fails: NHRP redirect is a Phase 3 feature and is configured on the hub, not the spokes. In Phase 2, spoke-to-spoke tunnels are built based on routing information and NHRP resolution, without redirect messages. Configuring redirect on spokes would have no effect and is not the correct command for Phase 2.

Enable split horizon on the hub's tunnel interface.

Why it fails: Split horizon prevents a router from advertising a route back out the interface it was learned on. Enabling split horizon on the hub would prevent the hub from advertising routes learned from one spoke to other spokes, breaking reachability. It does not help form spoke-to-spoke tunnels; in fact, it would hinder routing in a DMVPN Phase 2 network.

Set the hub as the NHRP next hop server and configure the spokes as clients.

Why it fails: In DMVPN, the hub acts as the next hop server (NHS) and spokes as next hop clients (NHC), but this is already the default configuration. The issue is not the NHS/NHC roles but the tunnel interface type and subnet. Spokes must have multipoint GRE interfaces on the same subnet to allow direct spoke-to-spoke communication.

ip nhrp redirect

Why it fails: The ip nhrp redirect command is configured on the hub, not on spokes. It enables the hub to send NHRP redirect messages to spokes when it detects that traffic is being routed through the hub to another spoke. Spokes do not need this command; they need ip nhrp shortcut to act on redirects. Configuring redirect on spokes is unnecessary and does not contribute to spoke-to-spoke tunnels.

ip nhrp network-id <id>

Why it fails: The ip nhrp network-id command is required on all DMVPN routers (hub and spokes) to identify the NHRP network. However, it is a basic NHRP parameter that must match across the DMVPN cloud. While it is necessary for NHRP to function, it is not specifically required for spoke-to-spoke communication in Phase 2; it is a general requirement. The question asks for configurations specifically to enable spoke-to-spoke tunnels, so this is not the best choice.

ip nhrp map multicast dynamic

Why it fails: The ip nhrp map multicast dynamic command is used on the hub to enable dynamic multicast mapping for spokes. It allows the hub to replicate multicast traffic to dynamically registered spokes. On spokes, this command is not typically used; instead, spokes use ip nhrp map multicast <hub-nbma> to send multicast to the hub. Therefore, this is not required on spokes for spoke-to-spoke communication.

Create a crypto ACL that matches VRF-A traffic and apply it to the physical interface with 'crypto map'.

Why it fails: A crypto ACL alone does not bind the tunnel to a VRF. Without the 'set vrf' command, the crypto map may not correctly associate with VRF-A's routing table, and traffic might not be encrypted or might leak between VRFs. The ACL defines interesting traffic but not the VRF context.

Use 'ip vrf forwarding VRF-A' on the tunnel interface and apply the crypto map to the physical interface.

Why it fails: Configuring the tunnel interface with 'ip vrf forwarding' places the tunnel interface itself in VRF-A, but the crypto map is applied to the physical interface. This can work in some designs, but the question asks for mapping the IPsec tunnel to VRF-A, which is achieved via 'set vrf' in the crypto map. Without that, the crypto map may not select the correct VRF for encryption.

Apply the crypto map to the tunnel interface and specify 'vrf forwarding VRF-A' under the crypto map.

Why it fails: VRF forwarding is not configured under the crypto map. The crypto map is applied to the physical interface or tunnel interface, but VRF selection is typically done via the 'set vrf' command in the crypto map or by using a VRF-aware crypto map. Simply specifying 'vrf forwarding' under the crypto map is invalid syntax.

Use a separate crypto keyring for each VRF and bind it to the crypto map.

Why it fails: While keyrings can be used for authentication, they alone do not enable VRF-aware IPSec. The critical command is set vrf under the crypto map, which directs the IPSec tunnel to use the specified VRF's routing table. Keyrings are optional and do not provide the VRF binding required for overlapping IP addresses.

Apply the crypto map to the VRF interface and specify the VRF under the crypto map.

Why it fails: Applying a crypto map to a VRF interface is not sufficient. In Cisco IOS, VRF-aware IPSec requires that the crypto map be applied to the physical interface or tunnel interface, and the VRF must be specified in the crypto map using the set vrf command. Applying it directly to a VRF interface without the set vrf command will not correctly associate the IPSec tunnel with the VRF, leading to routing and encryption failures.

Enable VRF-aware IPSec globally with the crypto vrf command.

Why it fails: There is no global crypto vrf command in Cisco IOS. VRF-aware IPSec is configured per crypto map using the set vrf command. A global command does not exist, and relying on such a command would result in incomplete configuration and failure to establish IPSec tunnels within the VRF.

ip nhrp shortcut

Why it fails: `ip nhrp shortcut` is configured on spoke routers, not the hub, to allow them to install shortcut routes learned from NHRP redirect messages. While it is necessary for spoke-to-spoke communication, the scenario states the hub is missing a configuration; without the hub sending redirects, the spoke cannot use shortcut. Thus this command alone on the hub would not resolve the issue.

ip nhrp map multicast dynamic

Why it fails: `ip nhrp map multicast dynamic` is already configured according to the scenario. It allows the hub to dynamically learn spoke multicast mappings for routing protocols. It does not enable spoke-to-spoke direct tunnels; that requires NHRP redirect on the hub and shortcut on spokes. Therefore this command is not the missing piece.

ip nhrp network-id 100

Why it fails: The network-id is already configured and matches on spokes, as registration succeeded. The network-id is a logical identifier for the NHRP domain; if mismatched, spokes would not register at all. Since the hub can ping spokes and registrations work, this command is correctly set and not the cause of the spoke-to-spoke failure.

Verify that the hub router has `ip nhrp map multicast dynamic` configured on its tunnel interface.

Why it fails: `ip nhrp map multicast dynamic` is used to enable dynamic multicast mapping for routing protocols over DMVPN. While it is important for multicast traffic, it does not directly affect spoke-to-spoke unicast communication in Phase 3. The issue described is about unicast spoke-to-spoke traffic, so this command is not the primary fix.

Verify that the spoke routers have `ip nhrp map multicast dynamic` configured on their tunnel interfaces.

Why it fails: `ip nhrp map multicast dynamic` is typically configured on the hub, not on spokes, to allow dynamic multicast mapping for routing protocols. On spokes, it is not used and would not affect spoke-to-spoke unicast communication. Therefore, this action would not resolve the Phase 3 spoke-to-spoke issue.

Check that the tunnel interface on the hub is configured with `ip nhrp network-id` matching the spokes.

Why it fails: While matching `ip nhrp network-id` is necessary for NHRP registration and basic DMVPN operation, it is not the specific cause of spoke-to-spoke failure in Phase 3. If the network-id mismatched, spokes would not register with the hub at all, and the entire DMVPN would fail, not just spoke-to-spoke direct communication. Thus, it is not the most likely fix for the described issue.

Spokes must have ip nhrp shortcut configured to enable direct spoke-to-spoke tunnels.

Why it fails: The ip nhrp shortcut command is used in DMVPN Phase 3, not Phase 2. In Phase 2, spokes automatically create direct tunnels when they receive routing updates that point to another spoke's tunnel IP, and NHRP resolution is triggered. The shortcut command is not required and is typically not configured in a pure Phase 2 deployment. Its presence would not harm, but it is not a requirement for Phase 2 operation.

The hub must be configured with ip nhrp redirect to allow spokes to establish direct tunnels.

Why it fails: While ip nhrp redirect is used in DMVPN Phase 3 to signal spokes about a better path, Phase 2 does not use redirects. In Phase 2, spokes discover each other's tunnel addresses through NHRP resolution triggered by routing updates. The hub does not need ip nhrp redirect; instead, it must have ip nhrp map multicast dynamic to forward multicast (e.g., EIGRP hellos) to all spokes. Therefore, this statement is false for Phase 2.

Spokes must have ip nhrp map multicast dynamic configured to receive EIGRP multicast updates.

Why it fails: The ip nhrp map multicast dynamic command is configured on the hub, not on spokes. It enables the hub to dynamically map multicast traffic to the NBMA addresses of registered spokes. Spokes use ip nhrp map multicast <hub-nbma> to send multicast to the hub. Placing this command on spokes would not work because they do not act as multicast replicators for other spokes in a Phase 2 DMVPN.

Enable NHRP redirect on the hub.

Why it fails: NHRP redirect is used in DMVPN Phase 3 to signal better paths. In Phase 2, the hub does not send redirects; instead, it relies on routing protocol next-hop preservation so spokes can directly resolve each other. Enabling redirect on the hub in a Phase 2 network would not solve the missing route issue and could cause unexpected behavior.

Configure the hub's tunnel interface as a point-to-multipoint network type for OSPF.

Why it fails: OSPF network type on the hub's tunnel interface affects adjacency and DR election, but it does not directly enable spoke-to-spoke route learning. In DMVPN Phase 2, the hub must not change the next-hop address when advertising routes to spokes. This is achieved by disabling next-hop-self or using a route-map to preserve the next hop, not by changing OSPF network type.

Disable split horizon on the hub's physical interface.

Why it fails: Split horizon prevents routing updates from being sent back out the same interface they were received on. In DMVPN, the hub's tunnel interface is typically a multipoint GRE interface. Disabling split horizon on the physical interface does not affect routing updates over the tunnel. The issue is related to next-hop preservation, not split horizon.

DH group

Why it fails: The Diffie-Hellman group is used in IKE Phase 1 to establish the shared secret key, not in the IPsec proposal for Phase 2. For IPsec SA, perfect forward secrecy (PFS) may use a DH group, but if PFS is not configured, the DH group is not part of the IPsec proposal.

IKE version

Why it fails: The IKE version (IKEv1 or IKEv2) is used to establish the Phase 1 SA. Since Phase 1 is already up, the IKE version is already agreed upon. It is not a parameter of the IPsec proposal that is negotiated in Phase 2.

Authentication method

Why it fails: Authentication method (pre-shared key or certificates) is negotiated in IKE Phase 1, not in the IPsec proposal. Since Phase 1 is already up, the authentication method has already been agreed upon and is not a factor in Phase 2 negotiation.

Enable NHRP redirect and NHRP shortcut on the hub tunnel interface.

Why it fails: Enabling both redirect and shortcut on the hub is not the correct configuration. NHRP shortcut belongs on the spokes to allow them to establish direct tunnels. The hub should only have redirect enabled. Having shortcut on the hub does not contribute to spoke-to-spoke tunnel creation and may cause unexpected behavior.

Enable NHRP shortcut on the hub tunnel interface.

Why it fails: NHRP shortcut is typically configured on spoke routers to allow them to dynamically create direct tunnels to other spokes upon receiving a redirect. Configuring shortcut on the hub is not the standard design and does not enable the hub to create spoke-to-spoke tunnels. The hub's role is to redirect, not to shortcut.

Enable NHRP redirect on the hub tunnel interface.

Why it fails: NHRP redirect is used in DMVPN Phase 3 to signal the spoke that a more optimal path exists, but it does not by itself enable spoke-to-spoke tunnel creation. Without NHRP shortcut on the spokes, the redirect alone will not allow direct spoke-to-spoke communication. Therefore, enabling only redirect on the hub is insufficient for the stated requirement.

The PE router must use a separate BGP session for each VRF to exchange VPNv4 routes.

Why it fails: MP-BGP uses a single BGP session to exchange VPNv4 routes for all VRFs. The VPNv4 address family allows multiple VRFs to share the same BGP session by using the RD to differentiate routes. Creating a separate BGP session per VRF is not required and would be inefficient and unscalable.

The PE router must configure a route target (RT) import on the VRF to control which routes are accepted from other PE routers.

Why it fails: Configuring an import RT is necessary to accept routes into a VRF, but the question asks for two true statements regarding MP-BGP operation. The import RT is indeed used to determine which routes are imported into a VRF, but the export RT is what controls which routes are advertised. Both import and export RTs are important, but the export RT is specifically mentioned in option B as controlling advertisement. Option E is a true statement but not one of the two best answers that directly explain the issue of not receiving routes; the issue could be due to missing import RT, but the question likely expects RD and export RT as the two correct answers. However, since the question asks for two true statements, and both B and E are true, there is ambiguity. To avoid ambiguity, the question should be revised. But given the constraints, the intended correct answers are A and B.

The PE router must enable the VPNv4 address family under the BGP routing process to exchange VPNv4 routes.

Why it fails: While the VPNv4 address family must be enabled under BGP to exchange VPNv4 routes, this is a basic requirement and not a statement about the operation that is specifically true in the context of the problem. The question asks for true statements regarding MP-BGP operation; enabling the address family is necessary but does not address the core mechanisms of RD and RT. Moreover, the option is not incorrect, but it is not one of the two best answers that explain why routes might not be received. The issue described is about not receiving routes for a particular VRF, which is directly related to RD and RT configuration.

Group members use IPsec in tunnel mode to encapsulate original IP packets, preserving the original IP header for routing.

Why it fails: GET VPN uses IPsec in tunnel mode, but it encapsulates the entire original IP packet, including the original IP header, which is not used for routing within the group. Instead, the original IP header is preserved for end-to-end addressing, but routing is based on the outer IP header. The statement is misleading because it implies the original header is used for routing, which is not the case.

GET VPN requires the use of GRE tunnels between group members to transport encrypted traffic.

Why it fails: GET VPN does not use GRE tunnels; it uses native IPsec encapsulation. The original IP packet is encrypted and encapsulated with a new IP header, but no GRE is involved. GRE is used in DMVPN, not GET VPN. This distinction is important for understanding GET VPN's overlay-independent nature.

Group members can communicate directly with each other without the need for a central key server after initial key distribution.

Why it fails: While group members can communicate directly using the TEK after receiving it from the key server, they still rely on the key server for periodic rekeys and policy updates. The key server remains essential for key management and cannot be eliminated after initial distribution. Thus, the statement is false.

ip nhrp map multicast dynamic

Why it fails: The ip nhrp map multicast dynamic command is used in DMVPN to dynamically map multicast traffic to spokes' NBMA addresses. It is not applicable to a simple point-to-point GRE tunnel and does not enable multicast routing. This command is specific to NHRP and mGRE environments, and its presence on a point-to-point GRE tunnel would have no effect or could cause errors. It is not the correct command for enabling multicast on a GRE tunnel.

ip multicast-routing

Why it fails: The ip multicast-routing command enables multicast routing globally on the router, which is a prerequisite. However, it is not configured on the tunnel interface; it is a global configuration command. While necessary, it alone does not enable multicast forwarding on the tunnel interface. The interface must also have PIM enabled to actually forward multicast traffic. Therefore, this command is not the one required on the tunnel interface.

tunnel mode gre multipoint

Why it fails: The tunnel mode gre multipoint command configures the tunnel as a multipoint GRE (mGRE) interface, typically used in DMVPN. For a simple point-to-point GRE tunnel, the default tunnel mode is gre ip, which is sufficient for multicast. Changing to multipoint is not required for multicast forwarding and would alter the tunnel's behavior, potentially breaking the point-to-point configuration. It does not enable multicast forwarding by itself.

Enable VRF-aware IPsec globally with the crypto vrf command.

Why it fails: There is no global crypto vrf command in Cisco IOS. VRF-awareness is configured per crypto map using the set vrf command. The global command does not exist. The engineer must specify the VRF in each crypto map that requires it.

Configure the crypto map under the VRF-aware ISAKMP profile.

Why it fails: While ISAKMP profiles can be used for VRF-aware IPsec, the crypto map itself must still specify the VRF using the set vrf command. Configuring the crypto map under an ISAKMP profile is not a valid configuration step; ISAKMP profiles are referenced in the crypto map, not the other way around.

Apply the crypto map to the VRF interface instead of the physical interface.

Why it fails: Crypto maps are applied to physical or tunnel interfaces, not to VRF interfaces. In VRF-aware IPsec, the crypto map is still applied to the outgoing interface, and the VRF is specified within the crypto map using the set vrf command. Applying to a VRF interface is not a supported configuration.

Ensure the ipsec sa policy includes the correct transform set and that the KS and GMs use the same TEK rekey parameters.

Why it fails: While transform set and rekey parameters are important for IPsec SA establishment, the scenario states Phase 1 and Phase 2 are operational and the policy was pushed, implying those parameters are correct. The issue is traffic being dropped despite successful policy distribution, so the problem likely lies elsewhere, such as with the IPsec SA or routing.

Confirm that the GMs are using the same IPsec SA and that the KS is configured with the correct rekey authentication, and ensure the GMs have the ip route for the remote subnet pointing to the tunnel.

Why it fails: GET VPN does not use a tunnel interface; it encrypts traffic based on ACLs and routing. The concept of a tunnel interface route is incorrect for GET VPN. While rekey authentication is important, the scenario suggests the KS has already pushed policy successfully, so the issue is not likely rekey authentication but rather the data plane encryption or routing.

Verify that the GMs have the same IPsec SA and that the KS has distributed the TEK, and check if the GMs are using the correct ACL for the traffic.

Why it fails: The administrator already verified ACLs match. While checking IPsec SA and TEK is relevant, the scenario indicates Phase 2 is complete, meaning TEK distribution occurred. This option does not address the specific drop despite operational phases, and it partially repeats already-verified checks, making it less likely to be the root cause.

crypto map map-name 10 ipsec-isakmp match address acl-name

Why it fails: The 'match address' keyword specifies the ACL that defines interesting traffic, but it does not bind the crypto map to a VRF. Without VRF association, the crypto map would apply to the global table, causing conflicts with overlapping addresses. Therefore, it is insufficient for VRF-aware IPsec.

crypto map map-name 10 ipsec-isakmp

Why it fails: Without the 'vrf' keyword, the crypto map is applied to the global routing table, not to a specific VRF. This would not support overlapping IP addresses per customer, as all traffic would be matched against the global crypto ACL. Therefore, it does not meet the requirement.

crypto map map-name 10 ipsec-isakmp local-address Loopback0

Why it fails: The 'local-address' keyword specifies the local endpoint address for the IPsec tunnel, but it does not associate the crypto map with a VRF. It is used to define the source address for IKE negotiations, not for VRF selection. Thus, it does not solve the overlapping address space issue.