Path monitor setup using tunnel interface

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Path monitor setup using tunnel interface

L4 Transporter

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

 

image.png

1 accepted solution

Accepted Solutions

L4 Transporter

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

High Sticker

View solution in original post

2 REPLIES 2

L4 Transporter

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

High Sticker

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. 

  • 1 accepted solution
  • 1331 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!