STATIC ROUTE availability test

[MickeyDawson]

Meraki advise .When a route is configured as active while the next hop responds to ping, or active while a host responds to ping, the MX tracks the route. If the MX stops receiving ping responses for a period of time, the route will be removed from the routing table. The route is re-added when responses are received again.

I have a specific requirement where a static route is providing a route via a 2nd L3 device connected to a LAN port.

As such next hop testing will not detect if a L3 path failure occurs towards a destination using the static. 

Will 'while a host responds' provide route availability and detection for a distant host that sits behind a few hops?

Specifically here I am using the static 0.0.0.0/0 via next hop on a LAN port so as to use a next hop L3 device to route to the Internet. However if that device looses internet connectivity I need the 0.0.0.0/0 static removing to allow a dynamic 0.0.0.0/0 via the MX WAN interface. 

Does anyone think this scenario is possible?

Mike 

[PhilipDAth]

Try adding a static host route, like 8.8.8.8/32 via the next hop.

Then configure the ping to 8.8.8.8 and track it for your default route.  If there is any loss of connectivity to 8.8.8.8 along the path your default route will be withdrawn.

[MickeyDawson]

Philip a good pointer. I tried adding a static to 8.8.8.8/32 via my next hop 192.168.2.1 via LAN 3 port and testing availability to host 8.8.8.8

I then added a 2nd static route to 0.0.0.0/0 via my next hop 192.168.2.1

I checked that the static route was active via the Fortinet Firewall 192.168.2.1 and it was.

I then failed the WAN on the Fortinet to fail the 8.8.8.8 host test and the default route did not change it remained active on the Fortinet.

Not giving up but using your logic, I added a 2nd availability test onto the 0.0.0.0/0 static also to ping host 8.8.8.8

This worked when the 8.8.8.8 host test was associated with the Default static. When I failed the WAN interface on the next hop firewall the route then disappeared.

Now for the interesting bit.

So we have a static default via a 3rd party firewall and have the ability to remove the route if the test ping to 8.8.8.8 fails. 

My monitored pings to 8.34.34.34 and 88.221.170.233 both failed when the static default route disappears, however Internet connectivity is maintained by my test PC plugged into MX port 3 on a separate VLAN.

So the failover for Internet connectivity via the MX WAN port instead of the next hop worked 🙂 but the CMD pings stopped. I tired an additional CMD ping to a different destination 208.67.220.220 and that responded via the route MX WAN 1 however the original pings still showed Request Timed Out and again I still have internet connectivity.

So in my mind something is not timing out on the MX ARP around 8.34.34.34 / 88.221.170.233

I rebooted MX to see if pings would return and they did.

So  were 99% there but I am a little confused what is happening re the original test pings failing. p.s If I re enable the WAN port on the Fortinet the Static route becomes active again and the pings return.

Strange. What do we think is going on here is it the arp cache on the MX that's not timing out within my observation window?

####################

Below is a test I have just performed pinging the 3 destinations. The original two that failed and the new destination to OpenDNS. The picture below is what just happened after I disconnected the Fortigate WAN. Notice the OPenDNS ping remains but the only the original destinations which were established when the Static route was active fail.

Got to be something in my mind to do with arp caches 🙂

[PhilipDAth]

I'm guessing the MX, the test machine, and the default gateway to the Internet are in the same subnet.

If so then I'm guessing that the Fortinat is sending ICMP redirects.  If you can disable this then the problem will go away.

Another option is to put the default gateway to the Internet on a separate dedicated VLAN so that workstations are not in the same subnet.

[MickeyDawson]

Internet ADSL router gateway (VLAN1) (192.168.1.0/24)

MX WAN port (NAT) is on the same VLAN 1 / subnet as the Fortinet WAN port (192.168.1.0/24) NAT

Fortinet LAN interface used as  MX next hop =VLAN 2, 192.168.2.0/24

Test PC running CMD and Internet on VLAN 44 (172.16.44.0/24) connected to MX LAN port VLAN 44

Mike