VPN Technologies

You are deploying a single-hub DMVPN. All spokes have formed their GRE tunnels but none of the spokes can register with the hub, and 'show ip nhrp' on the hub shows no dynamic mappings. The tunnel interfaces are up/up and ping to the hub's tunnel address fails. On a spoke you run 'debug nhrp' and see the message 'NHRP: Receive Registration Reply' is never generated, while the hub logs 'NHRP: Rejecting authentication error'. What is the most likely cause?

A network engineer has configured a single-hub DMVPN with two spokes. Spoke-to-spoke tunnels form correctly, but the engineer notices that after a spoke reboots, its dynamic NHRP mapping remains on the hub for far longer than expected, causing the hub to attempt forwarding traffic to an unreachable spoke before purging the entry. On the hub tunnel interface, the current configuration includes 'ip nhrp holdtime 7200'. Which action best resolves the delayed purging of stale spoke registrations?

You configured a single-hub DMVPN Phase 1 network. All spokes register successfully with the hub (show ip nhrp shows valid entries on the hub, and spokes list the hub NHS as 'up'). However, EIGRP over the tunnel fails to form neighbor adjacencies between the hub and any spoke. Static neighbor definitions are not used. Which hub tunnel configuration omission best explains the failure?

A network engineer is configuring a single-hub DMVPN. The hub tunnel interface is up, but a newly added spoke shows no NHRP registration on the hub (show ip nhrp lists no entries for the spoke). The spoke's tunnel interface is up/up and the underlying physical path to the hub NBMA address is reachable via ping. On the spoke, the relevant configuration is: interface Tunnel0 ip address 10.0.0.2 255.255.255.0 tunnel source GigabitEthernet0/0 tunnel mode gre multipoint ip nhrp network-id 100 ip nhrp nhs 10.0.0.1 The hub uses 'ip nhrp map multicast dynamic' and 'ip nhrp network-id 100'. What is the most likely cause the spoke fails to register with the hub?

You manage a single-hub DMVPN deployment with EIGRP running over the mGRE tunnels. Spokes register successfully with the hub, and spoke-to-hub and hub-to-spoke traffic works fine. However, you want spoke-to-spoke traffic to be forwarded directly between spokes instead of always transiting the hub, while keeping the hub's routing table summarized. Traffic between two spokes currently always passes through the hub. Which combination of NHRP configuration commands enables the desired direct spoke-to-spoke forwarding in this Phase 3 design?

A network engineer configures a single-hub DMVPN with mGRE only on the hub. Each spoke uses a point-to-point GRE tunnel to the hub and runs EIGRP over the overlay. Users report that traffic between two spokes works, but a packet capture shows all spoke-to-spoke traffic transiting the hub router rather than flowing directly between spokes. The engineer wants dynamic direct spoke-to-spoke tunnels. Which change is required to achieve this?

A network engineer deploys a Phase 2 DMVPN with a single hub and several spokes using EIGRP as the routing protocol. Spoke-to-spoke traffic is functional in some cases but fails in others. On a spoke, 'show ip route' displays remote spoke LAN subnets with the hub's tunnel IP as the next hop rather than the destination spoke's tunnel IP. What must be configured on the HUB tunnel interface to allow spokes to build direct spoke-to-spoke tunnels in this Phase 2 design?

A network engineer configures a single-hub DMVPN over the Internet with IPsec protection. Small pings across the tunnel succeed, and NHRP registration is up, but users report that large HTTP transfers and some application sessions hang or fail intermittently. A packet capture shows large TCP segments with the DF bit set being dropped along the path. Which configuration on the tunnel interface most directly resolves this issue?

A network engineer configures a single-hub DMVPN. On a spoke router, the tunnel interface uses 'tunnel source GigabitEthernet0/1' and 'ip nhrp nhs 172.16.0.1'. The spoke's tunnel line protocol is up, but 'show ip nhrp' on the hub shows no dynamic entry for this spoke, and 'show dmvpn' on the spoke lists the NHS state as 'NHRP'. The physical WAN interface Gi0/1 has connectivity to the hub's public address, and IPsec is not configured. What is the most likely cause of the failed registration?

A customer running a traceroute across your MPLS L3VPN backbone reports that the provider's P routers are visible as hops in the output, exposing internal core topology. The service provider policy requires that the MPLS core appear as a single hop to CE devices while normal traceroute still works within customer sites. Which configuration on the PE routers achieves this?

You are configuring MP-BGP on a PE router to exchange VPNv4 prefixes with a route reflector at 10.0.0.1. The neighbor is already defined and the IPv4 unicast session is established, but no VPNv4 prefixes are being exchanged. You have entered the following under the BGP process: router bgp 65000 neighbor 10.0.0.1 remote-as 65000 neighbor 10.0.0.1 update-source Loopback0 address-family vpnv4 exit-address-family Which additional configuration step is required to enable the exchange of VPNv4 routes with this neighbor?

A service provider PE router runs MP-BGP for an MPLS L3VPN. You capture the VPNv4 update advertised by this PE for customer prefix 10.1.1.0/24 in VRF CUST_A. In the standard MPLS L3VPN forwarding model, what does the VPN label carried in this VPNv4 NLRI tell the ingress (remote) PE to do?

An MPLS L3VPN service provider connects two sites of customer 'Acme' using eBGP as the PE-CE routing protocol. Both Acme sites use AS 65200. The provider PE routers redistribute customer routes into MP-BGP normally, and VPNv4 routes are exchanged between PEs with correct route targets. However, Site B never learns the prefixes originated at Site A. The PE at Site B shows the Site A prefixes in its BGP table but marks them as not received/denied by the CE. What is the most likely cause and fix?

A PE router (PE1) has VRF CUSTOMER-A configured with an eBGP session to the CE. PE1 successfully learns the CE's routes into the VRF and installs them in the VRF routing table. However, another PE router (PE2) in the same MPLS core never receives these customer prefixes as VPNv4 routes, even though the MP-BGP session between PE1 and PE2 is Established and other VRFs' prefixes exchange correctly. On PE1, 'show bgp vpnv4 unicast all' shows the CUSTOMER-A prefixes present locally. What is the MOST likely cause?

In a service provider MPLS L3VPN core, PE1 and PE2 exchange VPNv4 prefixes through a dedicated route reflector (RR) that is not in the data forwarding path. Customer routes appear in the BGP VPNv4 table on PE2 with the correct route target, but they never install into the customer VRF routing table on PE2. A show bgp vpnv4 unicast all reveals the routes are marked as inaccessible, and the next-hop of each VPNv4 prefix points to the RR's loopback rather than PE1's loopback. What is the most likely cause?

An MPLS L3VPN service provider has two customer sites for Customer-A connected to PE1 and PE2. The VRF 'CUST-A' on both PEs uses route-distinguisher 65000:100. On PE1 the VRF is configured with 'route-target export 65000:100' and 'route-target import 65000:100'. On PE2 the VRF is configured with 'route-target export 65000:200' and 'route-target import 65000:200'. BGP VPNv4 sessions are up between PE1 and PE2, and both PEs originate their local customer prefixes as VPNv4 routes. However, the customer sites cannot reach each other. What is the most likely cause?

A network engineer is documenting an MPLS L3VPN deployment for a service provider. A junior colleague asks about the difference between the route distinguisher (RD) and the route target (RT) configured under a VRF. Which statement correctly describes their distinct roles in the MP-BGP VPNv4 architecture?

A network engineer is provisioning a new MPLS L3VPN customer on a PE router. The PE-CE link uses interface GigabitEthernet0/1 with IP address 10.20.30.1/30 already configured. After creating the VRF and applying it with the command 'ip vrf forwarding CUST_A' under GigabitEthernet0/1, the engineer notices that OSPF adjacency to the CE has dropped and the interface no longer has an IP address in the global table. What is the cause of this behavior?

A service provider engineer is configuring a new customer VRF on a PE router and enters 'rd 65001:100' under the VRF definition. A junior colleague asks what functional role this route distinguisher value plays in the MPLS L3VPN control plane. Which statement correctly describes the purpose of the RD in this scenario?

A service provider runs an MPLS L3VPN backbone. Two customers, CustA and CustB, both use the overlapping prefix 10.1.1.0/24 within their own VRFs on the same PE router. The provider configures both VRFs with the same route distinguisher (RD) 65000:100 but with different route targets. After the configuration, CustB's site cannot reach several of its own prefixes, and the PE's BGP VPNv4 table appears to show only one instance of 10.1.1.0/24. What is the root cause of this problem?