nerdexam
Cisco

300-730 · Question #149

A network administrator is troubleshooting a FlexVPN tunnel. The hub router is unable to ping the spoke router's tunnel interface IP address of 192.168.1.2, even though the tunnel is showing up. The…

The correct answer is C. An IKEv2 authorization policy must be configured on the spoke router to advertise the interface route. The debug output shows the hub routing traffic for 192.168.1.2 out loopback2 instead of the dynamic VTI, indicating the spoke's tunnel interface route was never advertised to the hub via an IKEv2 authorization policy.

Troubleshooting VPNs

Question

A network administrator is troubleshooting a FlexVPN tunnel. The hub router is unable to ping the spoke router's tunnel interface IP address of 192.168.1.2, even though the tunnel is showing up. The output of the debug ip packet CLI command on the hub router shows the following entry: IP: tableid=0123456789 s=192.168.1.1 (local), d=192.168.1.2 (loopback2), routed via FIB. What must be configured to fix this issue?

Options

  • AA matching IKEv2 pre-shared key on the hub and spoke routers in the crypto keying configuration.
  • BAn outbound ACL on the dynamic VTI of the hub router that allows ICMP traffic to 192.168.1.2.
  • CAn IKEv2 authorization policy must be configured on the spoke router to advertise the interface route.
  • DA route map must be configured on hub router to set the next hop for 192.168.1.2 to the dynamic VTI.

How the community answered

(46 responses)
  • A
    17% (8)
  • B
    9% (4)
  • C
    67% (31)
  • D
    7% (3)

Why each option

The debug output shows the hub routing traffic for 192.168.1.2 out loopback2 instead of the dynamic VTI, indicating the spoke's tunnel interface route was never advertised to the hub via an IKEv2 authorization policy.

AA matching IKEv2 pre-shared key on the hub and spoke routers in the crypto keying configuration.

A mismatched IKEv2 pre-shared key prevents the IKEv2 SA from establishing at all, but the question explicitly states the tunnel is showing up, ruling out key mismatch as the root cause.

BAn outbound ACL on the dynamic VTI of the hub router that allows ICMP traffic to 192.168.1.2.

An outbound ACL on the dynamic VTI cannot fix a routing problem - the debug confirms traffic is being forwarded to loopback2, meaning packets never reach the VTI to be filtered by an ACL.

CAn IKEv2 authorization policy must be configured on the spoke router to advertise the interface route.Correct

In FlexVPN, the spoke uses an IKEv2 authorization policy to push interface routes to the hub after IKEv2 negotiation completes. Without this policy advertising the 192.168.1.2/32 prefix, the hub has no FIB entry pointing to the dynamic VTI for that destination and falls back to the incorrect loopback2 route, exactly matching the observed debug output.

DA route map must be configured on hub router to set the next hop for 192.168.1.2 to the dynamic VTI.

A route map overriding the next hop is a manual workaround that bypasses the proper FlexVPN mechanism; the correct fix is enabling the IKEv2 authorization policy on the spoke to natively advertise the interface route to the hub.

Concept tested: FlexVPN IKEv2 authorization policy spoke route advertisement

Source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ikevpn/configuration/xe-16/sec-ike-vpn-xe-16-book/sec-cfg-ikev2-flexvpn.html

Topics

#FlexVPN#IKEv2 authorization policy#DVTI#routing

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 300-730 Practice