Definitely seems to me a op-mode command to trigger a container rebuild would be appropriate.

How can I re-trigger the build of the container when I have changed the file?

HI @Viacheslav, this works even in 1.3, your problem is that you need to merge it with isis['FOO'] and not isis.

For example,

To wit, I already had this working with multiple networks (I had named them podman0/1/2/3/4/etc), but I wanted to simplify the initial PR here.

In T3766#100640, @Viacheslav wrote:

Network re-creates every time after reboot and gets configuration from "container network" section.
https://github.com/vyos/vyatta-cfg/blob/242f5685159f615ff79312041d3dde2063e5579a/scripts/init/vyos-router#L273-L277
So there is podman decide how to name this network.

In a different case, it tried to create a network which already been created.

Network re-creates every time after reboot and gets configuration from "container network" section.
https://github.com/vyos/vyatta-cfg/blob/242f5685159f615ff79312041d3dde2063e5579a/scripts/init/vyos-router#L273-L277
So there is podman decide how to name this network.

PR975

From conf mode I get error VyOS 1.4-rolling-202108130117

vyos@vyos-oobm# loadkey vyos scp://vyos@192.168.122.11:/etc/ssh/ssh_host_rsa_key.pub
Global symbol "$generate" requires explicit package name (did you forget to declare "my $generate"?) at /opt/vyatta/sbin/vyatta-load-user-key.pl line 162.
Execution of /opt/vyatta/sbin/vyatta-load-user-key.pl aborted due to compilation errors.
[edit]
vyos@vyos-oobm#

+1

The latest rolling 1.4-rolling-202108180805 should have it all.

Sounds good to me.

I close the task, because it can't be reproducible in 1.3.0-rc5
Re-open it, if necessary with described step by step how to reproduce it.
Or open a new one.

from vyos.xml import defaults doesn't work for 1.3 correctly, for some reason it gets 2 isis process with same name "FOO"
https://github.com/sever-sever/vyos-1x/commit/7b0a33618bfa1d1ef99b9744ed1ded49a2c832af

vyos@r4-1.3# compare 
[edit protocols]
+isis FOO {
+    interface tun0 {
+    }
+    net 49.0001.0000.0011.0001.00
+}
[edit]
vyos@r4-1.3# commit
[ protocols isis FOO ]
{'FOO': {'interface': {'tun0': {}}, 'net': '49.0001.0000.0011.0001.00'},
 'lsp_mtu': '1497'}
Only one isis process can be defined

@c-po Thanks!!! :)

thanks for pushing and testing this featureset. Your requested changes will make it into the rolling image the next couple of days!

Any news on this?

I haven't tested it directly but I haven't experienced this problem while working on the configuration changes. I don't have much time right now, so I can't test the exact scenario.

Not reproducible, tested on "1.3-beta-202108151336"

@Viacheslav Sorry for the long delay in replying.

1. Bug, values on interfaces are overwritten after firewall global parameters.

By default:

vyos@r4-1.3# sudo sysctl -a | grep "\.rp_filter"
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.vtun10.rp_filter = 0

Set value for the interface eth2 value "loose"

vyos@r4-1.3# set interfaces ethernet eth2 ip source-validation 'loose'
[edit]
vyos@r4-1.3# commit
vyos@r4-1.3# sudo sysctl -a | grep "\.rp_filter"
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth2.rp_filter = 2
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.vtun10.rp_filter = 0

@Merijn Any updates?

@c-po Can we close it?

Not more actual for 1.3, as it used isc-dhcp-client/isc-dhcp-relay/isc-dhcp-server 4.4.1-2
I can't find in logs something like bad udp checksums

From the manual:

VyOS 1.3.0-rc6 (upcoming) and 1.4 have the following commands available: