Page MenuHomeVyOS Platform

FRR: Add interface name for static routes
Closed, ResolvedPublicFEATURE REQUEST

Description

In FFRouting we have ability to set interface for static routes, for example:

ip route 10.170.16.0/24 10.170.16.1 eth1

But in VyOS CLI this function is not exist, so we can configure only one of two type of static routes - interface OR next-hop:

ip route 10.170.16.0/24 10.170.16.1
OR
ip route 10.170.16.0/24 eth1

This option is necessary for fully-functional usage of VyOS on some of Cloud providers.

So, we need to add something like:

vyos@test# set protocols static route 10.170.16.0/24 next-hop 10.170.16.1 
Possible completions:
   disable      Disable IPv4 next-hop static route
   distance     Distance value for this route
   next-hop-interface     Next-hop interface

vyos@test# set protocols static route 10.170.16.0/24 next-hop 10.170.16.1 next-hop-interface eth1

Details

Difficulty level
Normal (likely a few hours)
Version
-
Why the issue appeared?
Will be filled on close

Event Timeline

Why not use a combination of two?

set protocols static interface-route 1.2.3.4/32 next-hop-interface eth0
set protocols static route 0.0.0.0/0 next-hop 1.2.3.4 distance 10

So default traffic is sent via 1.2.3.4 and it is reached via eth0

Unfortunately, this works only for default route, but not for any other.

syncer changed the task status from Open to Confirmed.Feb 27 2019, 12:34 PM
syncer triaged this task as High priority.

@zsdc How quickly needs that to be resolved? It requires quite some work on the backend for the cli.

hagbard renamed this task from Add interface name for static routes to FRR: Add interface name for static routes.Mar 11 2019, 10:32 PM

@zsdc would the below help you?

set protocols static route 10.100.100.1/32 next-hop 10.1.1.1 distance '100'
set protocols static route 10.100.100.1/32 next-hop 10.1.1.1 next-hop-interface 'lo'

in FRR:

Current configuration:
!
frr version 7.1-dev
frr defaults traditional
hostname t1267
service integrated-vtysh-config
!
ip route 0.0.0.0/0 10.0.2.2 210
ip route 10.100.100.1/32 10.1.1.1 lo 100
!
line vty
!
end
hagbard changed Difficulty level from Unknown (require assessment) to Normal (likely a few hours).Mar 13 2019, 8:29 PM

@zsdc it's in http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.19.1+vyos2+current8_all.deb, but you better wait until the rolling release is working again, there were some frr dependencies added, which makes the packge not backward compatible. If you need it urgently, I can compile you a working one which works on the older releases (it's really only a dependency issue). So far I have it only implemented for IPv4 routes, let me know if you need it for route6 as well. I planned to start with the backend rewrite for frr asap.

hagbard changed the task status from Confirmed to Needs testing.Mar 13 2019, 10:41 PM

@hagbard @zx2c4 rolling should be ok now
please test and we need to backport this to the crux

@syncer @zsdc tested the rolling from tonight, works as far as i can tell, however it looks like 'delete protocols static ip' doesn't work. Not sure if it was always broken or not, I have a look into it asap.

Issue verified, new bug ticket or shall we use this one to resolve the issue. Looks like it's been broken for a while.

set protocols static route 10.100.100.0/24 next-hop 10.1.1.1 next-hop-interface eth1

[...]
S>* 10.100.100.0/24 [1/0] via 10.1.1.1, eth1, 00:01:05
[...]

del protocols static route 10.100.100.0/24

Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 0.0.0.0/0 [210/0] via 10.0.2.2, eth0, 00:34:35
C>* 10.0.2.0/24 is directly connected, eth0, 00:34:35
C>* 10.1.1.0/24 is directly connected, eth1, 00:34:04
S>* 10.100.100.0/24 [1/0] via 10.1.1.1, eth1, 00:01:52

@zsdc Can you please test your use case? thx.

@hagbard solution works. Please, add it also to the stable branch and to the set protocols static table section.

hagbard changed the task status from Needs testing to In progress.May 13 2019, 4:17 PM

I found an issue which prevents the implementation:

set protocols static route 10.100.100.1/32 next-hop 10.100.1.1 next-hop-interface eth2
set protocols static route 10.100.100.1/32 next-hop 10.100.1.1 next-hop-interface eth1

protocols {

static {
    route 10.100.100.1/32 {
        next-hop 10.100.1.1 {
            next-hop-interface eth1
        }
    }
}

}

That brings the cli line with frr out of sync:

ip route 10.100.100.1/32 10.100.1.1 eth2
ip route 10.100.100.1/32 10.100.1.1 eth1
!
line vty
!
end

It would require to know the old value and remove it. I think this has to wait until T1288 has been accomplished as a PoC. Furthermore I think it will also require different syntax, distance and the next-hop interface need to be in a tag node together.

hagbard changed the task status from In progress to On hold.May 13 2019, 5:25 PM
hagbard changed the task status from On hold to In progress.May 13 2019, 7:39 PM

@zsdc Is that even require in table, doesn't the below work?

set protocols static table 100 interface-route 10.100.100.1/32 next-hop-interface eth3 distance 100

This is not the same.

set protocols static table 100 interface-route 10.100.100.0/24 next-hop-interface eth1

generate:

test-06# show running-config staticd 
Building configuration...

Current configuration:
!
frr version 7.1-dev-20190423-08-ge400cd8
frr defaults traditional
hostname test-06
log syslog informational
service integrated-vtysh-config
!
ip route 10.100.100.0/24 eth1 table 100
ip route 10.100.200.1/32 eth1 table 100
!
line vty
!
end
test-06# show ip route table 100
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 10.100.100.0/24 [1/0] is directly connected, eth1, 00:01:37
S>* 10.100.200.1/32 [1/0] is directly connected, eth1, 00:03:53

But, we need:

test-06# show running-config staticd 
Building configuration...

Current configuration:
!
frr version 7.1-dev-20190423-08-ge400cd8
frr defaults traditional
hostname test-06
log syslog informational
service integrated-vtysh-config
!
ip route 10.100.100.0/24 10.100.200.1 eth1 table 100
ip route 10.100.200.1/32 eth1 table 100
!
line vty
!
end
test-06# show ip route table 100
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, D - SHARP,
       F - PBR, f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

S>* 10.100.100.0/24 [1/0] via 10.100.200.1, eth1 onlink, 00:00:17
S>* 10.100.200.1/32 [1/0] is directly connected, eth1, 00:08:05
cli:

set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 distance '100'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.100 next-hop-interface 'eth3'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 distance '200'
set protocols static table 100 route 10.100.100.1/32 next-hop 10.100.100.101 next-hop-interface 'eth2'

frr:
ip route 10.100.100.1/32 10.100.100.100 eth3 100 table 100
ip route 10.100.100.1/32 10.100.100.101 eth2 200 table 100

(https://github.com/vyos/vyatta-cfg-quagga/commit/1b620792f687f42b600a2d2330e71e9e3860c1d9)
or:
http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-quagga/vyatta-cfg-quagga_0.19.1+vyos2+current9_all.deb
or:
latest rolling after March 15th.

WYSIWYG - please note that you can't set multiple route distances on the same path with different next-hop-ifnterfacess, that's the only limitation right now, the rest should work as you requested, if not let me know.

hagbard changed the task status from In progress to Needs testing.May 14 2019, 8:14 PM

@hagbard, everything works fine now. Thank you!

Awesome, thx for letting me know.