OVH Default Gateway and Route Tables

So, currently, I have VyOS dual-homed with routing tables (One using a normal IP network, the other with OVH’s famous failover configuration [/32 to a gateway not in your IP pool])

Currently, I have the following configured:
show proto static

 route 0.0.0.0/0 {
     next-hop 1.1.1.1 {
     }
 }
 table 10 {
     route 0.0.0.0/0 {
         next-hop 1.2.3.254 {
         }
     }
 }
 table 11 {
     route 0.0.0.0/0 {
         next-hop 1.1.1.1 {
         }
     }
 }

This, however, doesn’t add it to the linux routing table (since its a /32)

I saw this post on the OVH forums but I don’t see how to do it to my current configuration.

Would defining next-hop-interface be the right move here?

Can you explain what you’re trying to do?
ovh forum post doesn’t make clear (at least to me) what the problem was for this solution
your 3 routes shown are all default routes, and they will end up in different route tables.
sudo ip route show table 10
will show one of them
Always try to avoid next-hop-interface on eth ports. They rely on remote router doing proxy arp, and will generate huge arp tables when used for default route

The problem is how OVH handles IP Failover.

For example:
Dedicated host: 1.2.3.4
IP Pool: 2.3.4.5-2.3.4.9
Gateway: 1.2.3.254

Using this as an example, but it applies to any device.

If I don’t use next-hop-interface, it doesn’t actually populate table 10.

So basically, consider this VM being on two very different ISPs. I setup PBR so a subnet will use one network, meanwhile the other will use the other network (and also some DMZ and 1:1 NAT hosts.) The problem comes across how do I do the default route (with OVH’s custom routing) on the table, when linux looks at the route, and says “This isn’t on the net, denied”

Something like: (?)

route 0.0.0.0/0 {
     next-hop 1.1.1.1 {
     }
 }
 route 1.1.1.1/32 {
     next-hop-interface eth0 {
     }
 }

That doesn’t seem valid. (This is VyOS 1.3.0-epa3)

Yes. That entry is incomplete. Need to specify where to send / what to do with traffic desalinated to IP 1.1.1.1/32

So, realistically, this is the best way to do it:

table 10 {
     route 0.0.0.0/0 {
         next-hop 1.2.3.254 {
             next-hop-interface eth0
         }
     }
 }