|
The Error:
Topology: HUB & SPOKE (single HUB, Dual HUB or DUAL region)
Note: Shortcut establishment depends on the routing decisions made by the Hub.
An issue may happen if there is no overlay stickiness configured in environment with two different flavor of underlay transport (Internet and MPLS) or multiple links.
Stages of ADVPN shortcut formation:
- Shortcut is triggered by data flowing through the HUB.
- Shortcut negotiation is orchestrated by the HUB (note: all the shortcut talks is via HUB until a direct tunnel is negotiated between the two spokes)
- Shortcut is established.
Breakdown:
- spokeA talks to spokeB via HUB.
- HUB sent 'shortcut offer' to spokeA ('shortcut offer' contains a message saying spokeB can be reached directly on IP address x.x.x.x).
- 'shortcut query' is then sent from spokeA to spokeB via the HUB.
- 'shortcut reply' is sent from spokeB to spokeA (response to spokeA's shortcut query).
- shortcut negotiation is completed.
At the time of this issue, below are found:
send shortcut-offer to LAB-HUB1-LINK1_0 <- LAB-HUB1-LINK1_0 is the DIALUP tunnel on the HUB towards the SPOKEA which initiated traffic to SPOKEB (via HUB).
LAB-HUB1-LINK1_0: recv shortcut-query 1415679766915920136 178bd0dbb69188e5/0000000000000000 10.109.20.118 192.168.1.1:2048->192.168.2.161:0.
- HUB receives shortcut query from SPOKEA (the traffic initiator). Note that SPOKEA cookie is already provided, while SPOKEB's is pending (all zeros).
- IP address 10.109.20.118 is the WAN IP of SPOKEA, and 192.168.1.1 is the user on SPOKEA LAN which initiate traffic to 192.168.2.161 (SPOKEB LAN).
LAB-HUB1-LINK1_1: forward shortcut-query 1415679766915920136 178bd0dbb69188e5/0000000000000000.
- 10.109.20.118 192.168.1.1->192.168.2.161.
- HUB forwards the query to SPOKEB on the HUB tunnel to SPOKEB (LAB-HUB1-LINK1_1).
LAB-HUB1-LINK1_1: recv shortcut-reply 1415679766915920136 178bd0dbb69188e5/320bfa4d89ca3f1e 10.109.21.110 to 192.168.1.1.
- HUB received first response (shortcut-reply) for the shortcut-query forwarded to SPOKEB by the HUB over the tunnel to SPOKEB (LAB-HUB1-LINK1_1)
LAB-HUB1-LINK1: if 20 192.168.2.161->192.168.1.1 0 route lookup oif 20 LAB-HUB1-LINK1 gwy 100.100.100.12
ike V=root:0: shared dev tunnel lookup, tun-id=100.100.100.12
ike V=root:0:LAB-HUB1-LINK1_1: no matching query found, drop
- The incoming interface (iif) for the flow (192.168.2.161->192.168.1.1) is interface with index 20 (index=20), and the outgoing interface (oif) is same (index=20), which is basically LAB-HUB1-LINK1 gwy 100.100.100.12 (SPOKEA, as 192.168.1.1 resides on SPOKEA LAN). So routing lookup is done correctly.
- However, the error no matching query found, drop appears. This is because the HUB cannot find a match for this transaction (it has timed out - the HUB has 10 seconds to delete this transaction or entry, if it is not concluded within this time).
Possible causes and fixes:
- Check if there is deterioration on the concerned internet link that could cause unusual delay in packet delivery.
- This is the least likely possibility.
- Check for misconfigurations or configuration errors on the HUB/s and concerned SPOKEs, e.g. a phase-1 name that is too long.
- If there is a case with a long phase1 name, a log similar to the following may be seen on one or both of the SPOKEs.
- Configure overlay stickiness on the HUB/s to avoid cross overlay transactions.
Overlay stickiness is a PBR (Policy Based Route) and can be configured as shown below (this example has 2 overlays):
config router policy
edit 1
set input-device LAB-HUB1-LINK1
set output-device LAB-HUB1-LINK1
next
edit 2
set input-device LAB-HUB1-LINK2
set output-device LAB-HUB1-LINK2
next
end
- Upgrade to 7.2.11 GA and above if option 1 and 2 above are not the issue; especially if this happens in an ADVPN design with dual regions. There is a known issue reported in dual region environments where this error is seen despite all configurations being valid.
|
