Yes, if you do “show ip route” from the vyos cli, you should see something like "recursive is directly connected, eth0). I am not sure why that happens, and it seems wrong to me. Perhaps interface-routes only work on point to point links.
However, that config would only work if 126.96.36.199 could respond to an arp from 188.8.131.52 on eth0. Vyos needs to do that arp to find the mac address of 184.108.40.206. And the “recursive directly connected” will cause Vyos to arp for everything - which would be ok if 220.127.116.11 is setup to do proxy arp, although it will cause a lot of arp traffic.
Well, what is the configuration on 18.104.22.168 - what ip address does have for your end of the link? What sort of device is that, and do you have control of it, or it that something provided by your upstream?
doing that will be better than editing /etc/networks/interfaces with this?
post-up route add 22.214.171.124 dev eth0
post-up route add default gw 126.96.36.199
pre-down route del 188.8.131.52 dev eth0
pre-down route del default gw 184.108.40.206
This file will be stored in config.boot?
HellMind did you get this to work? I’m trying to setup VyOS on the Runabove cloud. It uses the same weird addressing system as OVH. I tried everything. There is a bug listed on this page as well: http://blog.vyos.net/post/99607428923/1-1-0-release
I think it’s still unfixed. Is there somebody with a solution for recursive routing not working with a gateway in a different subnet?
I’m using the latest version and it’s still not working properly. Using Online.net (which from my understanding have a similar setup as OVH) the following will work as a workaround in /config/scripts/vyatta-postconfig-bootup.script:
sudo ip route add 62.210.x.1/32 dev eth2
sudo ip route add default via 62.210.x.1
However it would be nice if we could get an ETA for a proper solution for this problem[/php]