IP SLA Functionality for Static Route Removal in MS Switches - Need API?

[JasonSteig]

Hello All,

   I don't understand how the Meraki MS routing feature set doesn't include the IP SLA capability.  It severely hampers the ability to do failover from one firewall to another in two separate sites.  Basically, we have two main sites, each with its own MX firewall and internet provider.  If the MS core in one site loses connection to its firewall, then there is no way to get the Meraki MS to dynamically remove its static route to its own firewall.  This is fairly common and easy to do with Cisco IOS, with IP SLA and a floating static route.

   How can I achieve this with an API?  Can an API be made that continuously pings a destination from an MS425 stack, and if that ping fails then a static route is dynamically deleted from the table and another static route is added?  Then when the ping returns the new static route is deleted and the original is added?  How would I be able to do this?  thanks

Jason

[rhbirkelund]

Can you not utilize Warm Spare on your MXs?

[cmr]

Can you not use OSPF between the MX (advertising a route) and the MS (listening to it)?

[JasonSteig]

CMR,

  MX's as I was told don't by Meraki support, does not run OSPF on the inside interface.  It only is used for routing across VPN to other MX's.  It's just another case of Cisco limiting the feature set.  It's frustrating.  

[cmr]

I might be wrong, but this page https://documentation.meraki.com/MX/Site-to-site_VPN/Using_OSPF_to_Advertise_Remote_VPN_Subnets#:~:t.... suggests that the LAN does advertise routes as it says:

To confirm that the MX is sending OSPF updates, packet captures can be taken.

• MX in Routed mode - Captures must be taken on the LAN interface

[GIdenJoe]

That won't do  you any good.  The OSPF implementation on the MX is not used for internet bound traffic but only for SD-WAN.  And it will take in the routes and spread them to branch offices.  It will not advertise anything in the local network.

[GIdenJoe]

While MX'es do have routing possibilities that are dependent on a ping the MS'es do not which is indeed strange.

The most difficult part is that when your switch management interface loses it's uplink to dashboard you cannot push any new configs to it including a change to the static route.  So you would need to have that switch mgmt on an OOB network.

You could in theory have a machine in your network that does a continuous ping to the LAN interface of the primary MX site.  And then if that starts to fail a few times that it would run a script that calls the API to change the 0.0.0.0 route next hop on that L3 switch.  It is a long shot but it is worth a try.

[JasonSteig]

GldenJoe,

  how can I find a way to do this?  Are there any guides on this?  Thanks

Jason

[GIdenJoe]

I'll be blunt.  There is no quick and easy way to accomplish this if you don't have any programming knowledge where you can use your programming knowledge to use API calls.

If this is something you can spend some time on to work out I can start by pointing you to developer.cisco.com.

First step would be to create an account on postman and search the dashboard API for the necessary configuration calls.  This would be your PUT commands.  You will find that there is a logical tree structure of the API commands.  You can then experiment (preferably with a switch that is not in production ;p) if you can get it to change the route using the API call alone.

Only then can you start to find how you program this in your favorite programming language.  Then you need to have a script that runs at a fixed interval testing the uplink connectivity and then call the API function when it starts to fail.

I have no clue if this will work, but you can only try if time and resources allow.

[cmr]

Indeed, the static route being dependent on a next hop or final IP is what the MSs need.  I'm guessing that their much slower general processing power has historically precluded the overhead, but with the C9300s having a much better CPU, it might become a CS feature...?