@fcqpl any chance to test it in your environment?

@kroy can you please share your config? I used a minimal one and everything works without issues.

end: sudo sh -c "VYOS_TAGNODE_VALUE='$VAR(../../@)' ${vyos_conf_scripts_dir}/router-advert.py" would have to be in /opt/vyatta/share/vyatta-cfg/templates/interfaces/ethernet/node.tag/ipv6/router-advert/node.def
I can set that statically, which removes then the benefit for the use of other passes, IPv6 RAs can be sent over quite some interfaces.

Turns out that it might not be a smart move to keep it under interfaces, as it would have to implemented within the ethernet script or if it's a separate one, it needs to be called with VYOS_TAGNODE_VALUE, otherwise there won't be a way to find out what interface needs to be configured. If placed under service or any other path, it can be integrated into the config itself e.g. set service ipv6-ra interface eth0 <more options>, set service ipv6-ra interface eth1 <more options> etc.
That would only required to parse and compare configs for 2 interfaces which can be determined from the config.

https://vyos.readthedocs.io/en/latest/services/pppoe-server.html

https://github.com/vyos/vyos-1x/commit/b55b68f6246329468b4ab3450e127d5bab683bff or tomorrows rolling release will have it included. I keept the default 'replace' and you can chose between deny or disable, while disable removes the option entirely from the accel config, which I wouldn't recommend to do.

@leacho Sorry, I didn't have the time to look deeper into that, as far as I know we currently have no workaround for it.

per default session=replace is set and if I understand correctly you'd like to have to have the option to change it to deny don't set it at all. Is that correct?

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.

@sunser Can you please clarify if you still encounter that issue?

syslog is required by multiple targets and logs journald messages, stopping it works at the first commit, but the dependencies will start is automatically after reboot. the vyos config is being removed from rsyslog.d but the default rsyslog.conf will be used, which logs daemon, emerg (to console) and auth failures and would have to be changed in vyos-build if required.

Yeah I figured. vyos is being install into /dev/mdX, I can boot via live cd and mount mount it and it has everything in there, but there seems something wrong with writing the boot sector since I would see at least grub. Instead it is empty.

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1671
https://phabricator.vyos.net/T770
are all related to the same issue.

Looks like the vyos-1x images was not rebuilt from the crux branch before the new image was built. I manually checked out the crux branch and the commit ins backported in there, rebuilt the packages manually and everything needed is in there and working.

@kroy Please let me know if you still experience any issues (setting the port or migration).

tested with today rolling release. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912100217-amd64.iso)

@kroy please test with the latest rolling if https://phabricator.vyos.net/T1846 solves your issue.

@Dmitry Tested it with the latest 1.2 rolling, the issue is still present.

fixed in http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

FRR will serve RAs in the future.

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912061907-amd64.iso and later include the fix

@kroy I can't really reproduce it if I disable the peer first when multiple peers are defined on the same wg interface.
Can you please do a touch /tmp/vyos.ifconfig.debug and then run your commands and post it here?
It will show you the commands execute for each step like:

vyos@wg01# set  interfaces wireguard wg0 peer wg02 disable 
[edit]
vyos@wg01# commit
[ interfaces wireguard wg0 ]
DEBUG/wg0    write '1420' > '/sys/class/net/wg0/mtu'
DEBUG/wg0    write 'wg0' > '/sys/class/net/wg0/ifalias'
DEBUG/wg0    cmd 'wg set wg0 peer G1aA2KkyFyC8xsCUeENvuIW8HC5yDxwi902nR20592Y= remove'
DEBUG/wg0    cmd 'wg set wg0 listen-port 12345 fwmark 0 private-key /config/auth/wireguard/default/private.key peer hbwJSCu6SGUKIReNhWxlDIFRNCl5L7PaUSYOo2BF+Rg=  preshared-key /dev/null  allowed-ips 10.100.100.3/32 endpoint 10.1.1.203:12345 persistent-keepalive 0'
DEBUG/wg0    cmd 'ip link set dev wg0 up'

https://github.com/vyos/vyos-1x/commit/fde531d3791a3d71aa27f99244d7cbb3b3625bf0

looks like i had an old version, newer iso doesn't show that issue.

What were the steps you used when you upated the pubkey?

You can via https://github.com/vyos/vyos-1x/commit/dad110ce666edae42ac18c59a800bda503589f27, which just sets the completion help.
For T1845, yes it solves the issue with setting address:port _and_ moves protocol up from facility to host. Do you want me to revert and do 2 commits, which requires then 2 migrations, once for address:port and one to solve the logical issue with protocol. Right now you can set a different protocol for different facilities for the same host.

Will interfere with T1845, while I think T1845 should be the backport candidate. Facility is a tag node, protocol has been moved on level up and is host specific. Having the availability to set different port per facility doesn't really make sense.

Ah yes, it's taken entirely from the string, my fault I tested with the version you can only use an IP address.

Actually I found out that the address:port wasn't implemented at all even if you were able to set it, it never was used within the config. I have that fixed now (not pushed yet). I also moved that part within the nodes, so it's going to be:

If your node exists, you won't see that issue, only if it doesn't. The above PR should fix that, but I have requested a review from @dmbaturin to make sure I don't introduce something into it he doesn't want there.

https://github.com/vyos/vyos-1x/pull/172
should also fix https://github.com/vyos/vyos-1x/pull/171 which wouldn't be required then anymore

@dmbaturin

c.return_value('local-ip') &&  c.return_value(['local-ip'])

would work, shall I rewrite it to a single item list? conf.exists() does only accept s string as argument.

Yup, I tested almost all parameters we have currently in our cli, works all quite well. So, I'm going to implement it under service then?

I just tested frr sending RAs, setup manually which works quite well. So, now it needs the determined what path it should go (stay in interface or move out to service) and if we go with frr for it or stay with radvd. I would be in favor of frr.

You can announce multiple prefixes with different options. If you leave for each interface all the options need to be generated (like it is right now), or manually setup or generate for vyos-1x. Also you need to consider that you may send RAs on vif and stuff like that only. dup-addr-detect-transmits has not real anything to do with sending RAs.

very basic example (uses default paramaters):

 service {
+    ipv6-ra {
+        interface eth3 {
+            disable
+            prefix 2001:db8:cafe:beef::/64 {
+            }
+            prefix 2001:db8:dead:beef::/64 {
+            }
+        }
+    }

Hmm, that's actually a good point (http://docs.frrouting.org/en/latest/ipv6.html). I started with implementing it as service, it has the advantage that you don't have the duplicated template code. I would lean the towards implementing it for frr rather then using radvd. I currently have set service ipv6-ra interface eth3 ... as CLI path which I would stay with, or should it then be moved into protocol? I'll focus on implementing it for frr, since the CLI path is different the current as well as a new implementation could coexist for testing so we can find the best way out.

https://phabricator.vyos.net/T1228 sent the bug and I backported from upstream . The PR is in T1228 but needs to be merged into our package which I don't have permissions for.

After looking into this, the problem seems bigger than originally thought. If the syslog config is being removed from the config the syslog.py script is called and syslog stopped. However if the system is rebooted the init system starts syslog and the config is not calling the script since there is no 'system syslog' node in the config. systemctl disable rsyslog doesn't work some type of depend unit is starting it during reboot.

Yes, I think set service ra interface ... or something like that might be the best option. That would eliminate the template generator script all together and I was thinking to remove interface by interface from the generator, as the rewrite progresses.
Since it needs a migrator script for each interface then as well, even if the option are the same.