- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
01-23-2023 12:42 PM
Setting up a path monitor on a static route where source is a tunnel interface.
I am able to ping from CLI with tunnel interface IP as source. But the route does not get installed.
ping source 10.0.0.1 host 4.2.2.2
PING 4.2.2.2 (4.2.2.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 4.2.2.2: icmp_seq=280 ttl=57 time=21.4 ms
64 bytes from 4.2.2.2: icmp_seq=281 ttl=57 time=21.3 ms
64 bytes from 4.2.2.2: icmp_seq=282 ttl=57 time=21.5 ms
Remote side is Azure and doesn't support tunnel interface with an IP. And I don't want to rely on any single Azure resource IP which might get deleted by someone else bringing tunnel down.
With static route I would be able to use multiple remote IP's for monitoring.
And I need to monitor it so I can remove associated routes so traffic transfers to 2nd tunnel using another internet link
01-23-2023 03:37 PM
Hello @raji_toor
With the All condition you are saying that when there is no connectivity to 172.19.252. "and" 4.2.2.2.2.
Now the best recommendation is to ping at least 2 or 3 IPs from the other end. If the other end cannot place an IP on its tunnel interface, there is no problem, as long as that IP is allowed through the tunnel, i.e. through the interesting traffic of the IPSEC tunnel, there will be no problem if only from your source you ping the IP that you assign to your tunnel that is allowed in the tunnel.
Now if you have a route with metric 10 and with a path-monitoring, the idea is that when this failure condition occurs, the route will be removed from the FIB and the route will be added, the route to the same destination, but with metric 30 for example, will take the place.
Best regards
01-23-2023 03:37 PM
Hello @raji_toor
With the All condition you are saying that when there is no connectivity to 172.19.252. "and" 4.2.2.2.2.
Now the best recommendation is to ping at least 2 or 3 IPs from the other end. If the other end cannot place an IP on its tunnel interface, there is no problem, as long as that IP is allowed through the tunnel, i.e. through the interesting traffic of the IPSEC tunnel, there will be no problem if only from your source you ping the IP that you assign to your tunnel that is allowed in the tunnel.
Now if you have a route with metric 10 and with a path-monitoring, the idea is that when this failure condition occurs, the route will be removed from the FIB and the route will be added, the route to the same destination, but with metric 30 for example, will take the place.
Best regards
01-31-2023 10:58 AM
My mistake was I was not trying to ping IP on the other end of the tunnel. Instead just pinging a public IP. I was thinking if internet is down tunnel is down anyways. Pinging an IP across the tunnel within Azure works.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!