Multiple static routes for failover

How can I setup multiple static routes for a specific subnet for failover purposes?

Background: We have a high-speed radio wireless link which we’d like to use to carry the IP traffic most of the time, but when it fails (due to weather & distance) we need traffic to traverse our slower, much more stable link.

Looking at the config it seemed like you should be able to put in two routes to the same subnet with different gateways and distances, however I can’t get this to work for the life of me!

route 192.168.15.0/24 {
next-hop 192.168.1.5 { <---- gateway over faster, less stable link
distance 1
}
next-hop 192.168.2.5 { <---- gateway over slower, stable link
distance 2
}
}

At first I thought it was because the physical interface was up (since the link to the wireless equipment was good, but the RF link would go down) . . . but after a firmware updat on the wireless P2P link they added an option to down the ethernet link if the RF link went down. Recently the RF link went down and sure enough the Vyatta router showed the interface as u/D but still wouldn’t route traffic for 192.168.15.0/24 to 192.168.2.5 like it should:

Interface IP Address S/L Description


eth2 192.168.1.4/29 u/D P2P_fast_link
eth4 192.168.2.4/29 u/u P2P_slow_link

I’ve been running Vyatta CE for almost 2 years and know my way around pretty well but can’t seem to find a simple way to accomplish this.

We have some other routers that will check the remote gateway and automatically disable the static route if that gateway is unreachable but I can’t find an equivalent command in Vyatta/VyOS.

I can’t belive it’s that hard! Why have the distance metric in there if it can only use the one??? It feels like I’m missing something easy and obvious, but after hours of searching I can’t find much on it.

Thanks in advance for any help you can offfer!

–Andrew

That’s a little bit strange. I’m using configuration just like your and it works fine, changing the route just in a moment.

Could you provide some more information?

  1. The Vyatta’s version you’re running
  2. Output of “show ip route” for both links up and when one of the link is down
  3. Full configuration of “protocol” and “interface” sections
  4. Output of “show ip route table XX” in case you’re using routing policy

I think it’s a shenanigans of a little pretty devil who lives in the wires :slight_smile:

BTW, VyOS has “wan load-balancing” subsystem which can test remote nodes via ping (or something else) and switch routes in case of node became unreachable even if physical link still stays up.

Well, that’s what I thought too which is why I’ve been tearing my hair out over this!

Could you provide some more information?

1. The Vyatta’s version you’re running I’m pretty sure it’s VC6.6 but when I do a show version on that box it only says: “Version: 999.master.07120436” which I can’t find any reference to. I’m pretty sure it was installed from the same media I used for my other vyatta router that reports VC6.6.

2. Output of “show ip route” for both links up and when one of the link is down – This router is in production as our core router so I can’t fail the link just to grab the output but I’ll grab if next time the link fails before I manually disable the first route. This is what looks like right now:

vyatta@r01:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

S>* 0.0.0.0/0 [1/0] via 172.16.32.105, eth0
C>* 172.16.32.104/30 is directly connected, eth0
S 192.168.0.2/32 [2/0] via 192.168.2.5
S>* 192.168.0.2/32 [1/0] via 192.168.1.5, eth2
S>* 192.168.15.0/24 [1/0] via 192.168.0.2 (recursive via 192.168.1.5)

3. Full configuration of “protocol” and “interface” sections – I’ll work on sanitizing the config.

4. Output of “show ip route table XX” in case you’re using routing policy – No routing policies

In my original post I did remove the recursive routing that is in the config to simplify things. In my troubleshooting I did remove the recursive routing and the problem persisted without it. (but as we have 20 different subnets running over this link, it’s much easier to use recursive routing to specify multiple routes.

BTW, VyOS has “wan load-balancing” subsystem which can test remote nodes via ping (or something else) and switch routes in case of node became unreachable even if physical link still stays up.

I looked at the wan load-balancing feature briefly, but since this isn’t on the WAN side I wasn’t sure it was the best route to go. I also wasn’t sure if I could use the wan load-balancing for balancing several sets of links. Also, I was looking for fail-over, not load balancing, but I’ll look into it more.

Thanks!

–Andrew

This route (via 192.168.2.5) is misconfigured. It seems that none of the interfaces has an address in network 192.168.2.xxx. It should looks like the line below (with interface name specified after gateway)

I think the problem is in interfaces configuration.

It can do failover switching (look at failover keyword in rule specification). It’s very useful when physical links are remaining UP during failure. If physical links are going down then it’s much simplier to use weighted routes.

What you’re saying seems logical however there is an (up) interface with an IP in that subnet.

Show interfaces:
eth4 192.168.2.4/29 u/u

Also, I can ping 192.168.2.5 from this router and traceroute confirms it is directly connected.

I will do more digging into WAN load balancing with failover for this link.

Again, thanks for your continued help.

I have another good idea :slight_smile:

If the interface configuration is ok and all gateways are pingable, then…

Here! It’s not a VC6.6. It’s something else. Vyatta/VyOS version is printed in this form only for a development build. The word “master” indicates the git branch it was build from. If you look to repository you’ll find, that “master” branch is very-very old, it’s dated by 2010 year.

It’s possible that quagga you’re running doesn’t support recursive propagation of route changes at all.

Vyatta 6.6 and VyOS are running quagga 0.99.20.1.
You can verify your version via:

sudo zebra -v

Yep? :slight_smile:

Again, good idea but I don’t think that’s it as the build is from July 2013. I have no idea how I got a development build on that router, but that would make sense as I couldn’t find a reference to that “version” number anywhere. Must have been shortly before Brocade did a find & replace on the source code to replace Vyatta references :slight_smile:

vyatta@r01:~$ sudo zebra -v
zebra version 0.99.20.1

Copyright 1996-2005 Kunihiro Ishiguro, et al.
vyatta@r01:~$ show version
Version: 999.master.07120436
Description: 999.master.07120436
Copyright: 2006-2013 Vyatta, Inc.
Built by: unofficial@vyattawiki.net
Built on: Fri Jul 12 11:30:06 UTC 2013
Build ID: 1307121130-ffd8033
System type: Intel 64bit
Boot via: image

While I doubt it’s the root of the problem I’ll try to upgrade it to a VC6.6 R1 during the next maintenance window.

Again, Thanks for your ideas.