Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.

@dmbaturin can you explain why we schedule it to the next release and not to 1.2.1 for example? Are there any policies?

Curiously, I can't reproduce it in the latest rolling, even though the code hasn't changed. We need to test in latest crux builds.

The packages were out of sync with reality for some time. Should be fine now.

The packages were out of sync with reality, it should work as expected now.

@tomjepp Could you share the patch or tell us what and where you had to modify?

I want write an follow up.

@trae32566 Please test with http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyatta-cfg-system/vyatta-cfg-system_0.20.44+vyos2+current22_amd64.deb or the rolling release March26++

Code is now merged, please test in the next rolling release tomorrow

i've updated the code to handle <, > and probably other special characters. for now its waiting a merge on current/rolling and needs testing when merged

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

IPv4 ttl matching is missing too.
could this be copied to IPv4?
it's exactly same except the iptables module name called ttl

Working on interface-route. I think the best way is to stip that off as well, so basically interface-route has it's own script, set proto static route, route-map, table and so on too. Less likely to break when something needs top be changed, better code maintenance (at least that's what I hope for) and can be easily extended. Well, will test it out, so far there is a good performance benefit already.

Lets test it first :)

In T1309#34455, @runar wrote:

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

+1 on having this in 1.3 and not 1.2

VyOS 1.2.0 currently has this enabled, closing.

As i see it this is a fundamental change and should not be allowed into 1.2 LTS but it migth be added to 1.3 (just a opinion, not a decition)

seems so but:

Is this related to T20 ?

Confirmed it's still happening in VyOS 1.2.0 LTS

Ok, so I found it. host_name.py is being called when dhcp had been configured and the system rebooted. vyatta-cfg-system didn't call host_name.py when an interface is configured via dhcp, so when you configure dhcp for the first time and don't reboot /etc/resolv.conf stayed empty.
I need to test it in crux, but i think there is the same issue, therefore you would need 2 commit in crux, host_name.py and the one from the address node in vyatta-cfg-system.

There is still an issue with it, when the system is rebooted all is working as expected, but when you configure dhcp on the fly, hostname.py is still doing something weird and leaves resolv.conf broken.

arp - https://vyos.readthedocs.io/en/latest/routing.html#arp

cherry-picked (https://github.com/vyos/vyos-1x/commit/361a4419e0042369fae7eddf67f06a658372db93)

cherry-picked. (https://github.com/vyos/vyos-1x/commit/d0d044918ae10b2a5db1a4f218adef4187ca7e22)

Fixed in: 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 next rolling release.

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

@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.

stop spamming

Here is the current frr documentation:

Hi runar,

VyOS runs on 4.19.28 for a week now. Update can be used for both crux and current.

AS Curretn and Crux kernels and modules are build the same way, it's on @dmbaturin to use the packages. From the source side everything is there.