The router does not automatically configure the prefix route that the client received. If you use the client's link-local address for the prefix route then everything works. The client also uses the dhcpv6-server link-local address for the default route.

https://github.com/vyos/vyos-1x/pull/1028 — though probably needs some tests developed?

@artooro Will be available in the next rolling release
Let us know, if you want some other capabilities

Sorry for the late reply, I've been waiting for a maintenance window to test this in. Again as this is a production device I only have limited debug info before having to roll back to the working version. I installed 1.4-rolling-202110150613 and on booting show interfaces does indeed show all the interfaces. The igb driver interfaces were showing as up (u/u). The i40e interfaces were showing as down (u/D).

PR https://github.com/vyos/vyos-1x/pull/1027

Maybe be added to gether with T1229

@maznu Can you create a PR?

Initial bug was Fixed, VyOS 1.4-rolling-202110130217

vyos@r1-roll# compare 
[edit container]
+name dns02 {
+    image ubuntu:focal
+    network dnsnet {
+        address 10.0.72.253
+    }
+}
+network dnsnet {
+    prefix 10.0.72.0/24
+}
-network net01 {
-    prefix 10.0.72.0/24
-}

Why not always move to decimal output and detect on demand if colons are present or not and adjust the string? Ne need for the user to take any action at all?

Yes, closing this ...

@c-po Is it already implemented with commit https://github.com/vyos/vyos-1x/commit/ae2dc55aa68679e828d4bb133fc515172c081d0f ?

Fixed, VyOS 1.4-rolling-202110130217

vyos@r1-roll:~$ show nat source rules 
Rule       Source                                             Translation                                        Outbound Interface
----       ------                                             -----------                                        ------------------
3          192.168.0.0/24                                     masquerade                                         eth0

Is a double task, it looks like the package is not update upstream.

Work in progress:
https://github.com/vyos/vyos-1x/compare/current...jestabro:linkstate
https://github.com/vyos/vyos-build/compare/current...jestabro:linkstate

Maybe, but if the effort is made in order to be able to configure log level, it would be good that it can be set in different levels.
I'm thinking in a mix scenario, where majority of rules may log with info/debug level (for example default accept rules), while other rules may need a warning/error level (some drop rules).

As for me, it should be configured in the global firewall log level, not per rule.

set firewall log-level x

PR https://github.com/vyos/vyos-1x/pull/1026

PR https://github.com/vyos/vyatta-cfg-system/pull/170

For this we create text files as the group-config includes (they contain route and other per group config directives, generally around security).

If I change the double-quotes to single-quotes for all the rules in that firewall, I get this (no changes detected):

@foxbox Will be fixed in the next rolling release.

PR https://github.com/vyos/vyos-1x/pull/1025

Messaged

@BiMW Can you re-check it?

Not reproducible, VyOS 1.4-rolling-202109300217

set service ipoe-server authentication radius dynamic-author key 'ssss'
set service ipoe-server authentication radius dynamic-author server '192.168.122.11'
set service ipoe-server authentication radius nas-ip-address '192.168.122.11'
set service ipoe-server authentication radius server 192.168.122.11 key 'ciscoradiuskey'
set service ipoe-server interface eth1 client-subnet '192.0.2.0/24'

@FileGo Can you replace double-quotes with single-quotes?

Fixed

sever@sever:~$ ssh [email protected]

PR: https://github.com/vyos/vyos-1x/pull/1024

@c-po in 1.3.0-epa1 works fine.

What about 1.3.0-epa1?

Re-opened, the same bug in VyOS 1.4-rolling-202109300217

sever@sever:~/docker$ ssh [email protected]

Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.

PR https://github.com/vyos/vyos-1x/pull/1022

@lucasec the reason for switching to the platform UUID instead of building up out own one was that it was not "unique".

I surveyed all the hardware I have to see what kind of UUIDs they report: