January 27th, 2017, a Chilean customer reached Huawei TAC regarding
multiple tunnel instability for the NBMA to be implemented for final user’s
network connects the hub to the Internet using a wired connection and the
spokes using wireless connections such as 3G and 4G.
the IPSec Observingng List it is evidenced that the tunnels had been somehow
bouncing, reason why the customer reported instability:
upon customer’s evidence, it can be accepted that the IPSec tunnels have
already been set up, as per seen on the IKE Security Associations:
the tunnels are passing constant sessions without reflecting possible bounces:
couple of days after this was researched, we connected to the customer’s
networks via Team Viewer to provide remote support. As long as we were
connected, we noticed no bounce or no possible IKE trap regarding a VPN
bouncing or going down.
are 4 possible causes for a tunnel to bounce once the NHRP neighborship has
1. NHRP Shortcut.
This would apply if a DSVPN technology
would be used, since it’s designed to make the smart P2MP networks, then using
the information from the configured routing protocol, it will always attempt to
find the shortest route for its destination.
To be more precise, what this technology does is:
After spoke A is registered on the hub, the hub will forward
the traffic to any other spoke that the spoke A wants to communicate to (Figure 1).
Figure 1 Spoke to Hub to Spoke
Once the hub has forwarded this traffic, it will let spoke A
know how to reach the other spoke directly without having to query the hub to
reach it, and this will, therefore tear the original tunnel down (Figure 2) in
order to converge once again, but now Spoke to Spoke, calling this a Shortcut (Figure 3) Making further communications be able to, henceforth, communicate directly.
Figure 2 Spoke to Hub tear down
Figure 3 Spoke to Spoke smart stable convergence
2. Configuration modification or internal/external
Another fact that might impact the communication would be
human intervention by modifying the stable configurations, and also encryption
encapsulations through which the communication might go. For example, if the
tunnel is transported through a VPN tunnel formed by any external VPN gateway,
if there is any configuration modification on this latter tunnel (or any
configuration at all) , it may impact the original tunnel.
3. WAN network provisioning failure.
Now a days, many business networks have redundancy WAN service
providers regardless of the WAN network kind (dedicated links or Internet),
however, when the service goes down, or bounces, the tunnel for the NHRP
neighbor will bounce as well, and that will, either drop the service for the
whole branch, or, in case there is a redundancy, it will make it flap (and trigger traps). Configuration modification or internal/external tunnel
4. Non production traffic on the tunnel.
a normal behavior of the P2MP VPN, it is detected when there is no production
traffic passing through the tunnels, then tunnel is torn down. Since the tunnel
has no production traffic, there will of course be no impact.