Route Monitoring. Possible FR?

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.

Route Monitoring. Possible FR?

L3 Networker

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.

 

4D83FE9B-261E-45EA-9969-1C48BD460C9F 4.png

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

4D83FE9B-261E-45EA-9969-1C48BD460C9F 6.png

 

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.

1 accepted solution

Accepted Solutions

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

11524

View solution in original post

7 REPLIES 7

L7 Applicator

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?

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.

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?

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

 


@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? 

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.

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

11524

  • 1 accepted solution
  • 4307 Views
  • 7 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!