I ran into an interesting requirement which (I believe) is not possible with the current path monitoring features for static routes. Here is my scenario...
First lets just remove dynamic routing from the equation. For this specific use case dyanamic routing isnt possible between R1, R2 and the PA. PA has a default route configured to R1. R1 is routing the 126.96.36.199/24 network to the PA, which is a network segment on a seperate DMZ. Hosts in this DMZ have a have depdance on resources beyond R2 however.
At first a path monitoring is configured on the next hop for the gateway (green). However this would only trigger if the link between R1 and the PA fails. Since the hosts in 188.8.131.52/24 have large dependancies on hosts beyond R2, we'd also like to tear down the default route to R1 if the connection to R2 fails (orange).
Since path monitoring in its current guise only montiors a path via the gateway configured in the static route itself, this isnt possible (AFAIK). This means that even if the R2 link went down, hosts in 184.108.40.206/24 would still respond to requests from hosts beyond R1. In this use case we do not want this to occur. Hence it would be advantageous in this scenario to be able to monitor a route in the FIB as a metric for tearing down a static route. Since if we could tear down the default route to R1 by monitoring R2, hosts beyond R1 would not get responses when querying hosts in 220.127.116.11/24.
I know this kind of function exists on dedicated router products (eg. Cisco).
Am I missing something? Or is this in fact not possible?
EDIT: Just thought I'd add. I'm pretty sure this scenario could be solved by introducing seperate virtual routers. But I'm trying to avoid this level of complexity in this case.
Solved! Go to Solution.
Yes. But the current function of the path monitor means that if I do that it tries to monitor 18.104.22.168 via 22.214.171.124 gateway configured in the static route in question, which instantly fails. This is confirmed if you A - check the status directly after a commit and B - performing a tx PCAP reveals ICMP requests going out of eth1/1.
On the other hand....
ping source 126.96.36.199 host 188.8.131.52
...works perfectly fine. But this is not the same, as a ping will use the FIB for determining the path. Whereas a path monitor ignores the FIB and uses the gateway defined in the static route no matter what you try to monitor.
I did also try this.
There is a validation error upon closing our the VR configuration.
Path Monitoring requires interface specified vr_local -> routing-table -> ip -> static-route -> asdasd -> path-monitor is invalid
Got it. You are probably right that this is not possible so far. I also played a little with PBF rules but I either end up with the same problem or some other limitations (for No-PBF rules it is not possible to configure a monitor IP).
This is confirmed if you A - check the status directly after a commit and B - performing a tx PCAP reveals ICMP requests going out of eth1/1.
This is ugly but what is R1 doing with this route monitor ping? Could R1 send back the ping to 184.108.40.206 out of the same interface where it received it and then the ping goes through the PA to R2 and then the way back to 220.127.116.11?
I tried this one as well. Even some uglier permutations using NAT.
Neither produced results unforatunety. The first one runs into problems with route asymmetry I think when the return packet comes from R2, but I didnt go so far as to confirm this.
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!