Route Monitoring. Possible FR?

[El-ahrairah]

Hi

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 3.3.3.0/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 3.3.3.0/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 3.3.3.0/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 3.3.3.0/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?

Cheers

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.

[Remo]

Hi @El-ahrairah

Did you try to simply configure a pathmonitoring destination of 2.2.2.2 for the default route pointing to 1.1.1.2?

[El-ahrairah]

Hi @Remo 

Yes. But the current function of the path monitor means that if I do that it tries to monitor 2.2.2.2 via 1.1.1.2 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 1.1.1.1 host 2.2.2.2
...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.

[Remo]

This is also the case if you do not specify an interface in the static route? And maybe even choose the IP 2.2.2.1 as source?

[El-ahrairah]

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

[Remo]

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).

---

@El-ahrairah wrote:

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 2.2.2.2 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 1.1.1.2? 

[El-ahrairah]

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.

[El-ahrairah · Accepted solution]

I've managed to get a feature request raised for this.

11524