Page MenuHomeVyOS Platform

policy based routing not working
Not ApplicablePublicBUG

Description

set protocols static table 1 route 0.0.0.0/0 dhcp-interface 'eth1'

set policy route source-route rule 10 description 'bulk data via charter'
set policy route source-route rule 10 destination group port-group 'bulk-data' 
set policy route source-route rule 10 protocol 'tcp'
set policy route source-route rule 10 set table '1'
set policy route source-route rule 10 source address '0.0.0.0/0'

set interfaces ethernet eth0 policy route 'source-route'

That fails to route the bulk data transfers over eth1.

Details

Version
yOS 1.4-rolling-202104062128
Is it a breaking change?
Behavior change
Issue type
Unspecified (please specify)

Event Timeline

I have not built vyos since 2018, so my last production version was 201803051831.

I don't have a test environment for that feature, but I could build one sometime next week.

Maybe related task T3505 which deletes the default route for DHCP in the commit.

PBR works if we change the static route to:

set protocols static table 1 route 0.0.0.0/0 next-hop 35.129.96.1

Of course, that assumes that dhcp won't change our cable isp ip address. For now, I can work around that.

did you try
set protocols static table 1 route 0.0.0.0/0 interface 'eth1'

instead of "dhcp-interface"?

PBR is running fine for me like this with dynamic IP

I just tried that and it fails. We get

show ip route table 1
VRF default table 1:
S>* 0.0.0.0/0 [1/0] is directly connected, eth1, weight 1, 00:00:40

but it tries to arp for addresses:

08:45:29.102045 ARP, Request who-has 38.64.93.21 tell 35.129.96.135, length 28
08:45:30.126084 ARP, Request who-has 38.64.93.21 tell 35.129.96.135, length 28
0

The cable modem here is in bridge mode, so it won't respond to those arps.

I don't fully understand your scheme
What interrelation between arp and tcp policy?

Unknown Object (User) subscribed.Jan 18 2022, 4:05 PM

Looks like I see the same issue for 1.3.0. Reproducing steps:

set interfaces ethernet eth1 address 'dhcp'
set protocols static table 1 route 0.0.0.0/0 dhcp-interface eth1

After commit it will return the following output:

vyos@vyos# commit
[ protocols static table 1 route 0.0.0.0/0 dhcp-interface eth1 ]
dc: can't open '0x7fffffff': No such file or directory
iptables v1.8.2 (nf_tables): option "--set-mark" requires an argument
Try `iptables -h' or 'iptables --help' for more information.

[[protocols static]] failed
Commit failed
Viacheslav claimed this task.
Viacheslav moved this task from Open to Finished on the VyOS 1.4 Sagitta board.
This comment was removed by Viacheslav.
dmbaturin set Issue type to Unspecified (please specify).

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I no longer have a vyos router. I am now retired with just a consumer
grade cable modem. No AS#, no IP6 tunnels, no bgp :)

-----BEGIN PGP SIGNATURE-----

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCZasL/hUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsEaCQCfQiGVJFSL5uKIPXMcI/1gO2ZDGsQA
n0ZH4WSq3HX7zIlf+YbT7A1ZZh+B

rxSS

-----END PGP SIGNATURE-----

Viacheslav changed the task status from Open to Needs testing.Feb 13 2024, 6:02 PM
dmbaturin removed a subscriber: carl.byington.

Just in case it helps, after a migration from 1.3 to 1.4.0-epa2, the migrated config ends up as:-

set policy route outviajt interface 'eth0.20'
set policy route outviajt rule 10 description 'Internal Traffic'
set policy route outviajt rule 10 destination group network-group 'internaladdresses'
set policy route outviajt rule 10 set table 'main'
set policy route outviajt rule 10 source group network-group 'outviajt'
set policy route outviajt rule 20 description 'Out via JT'
set policy route outviajt rule 20 set table '1'
set policy route outviajt rule 20 source group network-group 'outviajt'
set policy route outviajt rule 30 description 'Normal Traffic'
set policy route outviajt rule 30 set table 'main'
set protocols static table 1 route 0.0.0.0/0 interface pppoe0

which works and correctly policy routes.

This seems to look quite similar to the config in the original report.

@matthewr Thanks for confirming!
Closing it as resolved now. Feel free to reopen or create a new one if this bug remains again.