I'm pretty sure it's my failure to correctly handle an edge case. I'll look into it today, should be simple enough.

Clearly a workaround is the fastest way to "fix" VyOS, but the backend code should be fixed, too. This is either ipaddrcheck https://github.com/vyos/ipaddrcheck or libcidr.

i'm wondering if this is the right approach.
This works as a workaround, but this needs to be added to the ipaddrcheck validator as an allowed host-address and not be done in a shell script

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

https://phabricator.vyos.net/T2578

Proposed validator for host https://github.com/vyos/vyos-1x/blob/current/src/validators/ipv4-host

Do I need to do more to get the PR merged?

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

@alexandrestein Vyos1.3 's npt is temporarily unavailable, but vyos1.3 basically supports dhcpv6-pd,. If there is no special reason, you can consider using a global address instead of ULA, to obtain the delegation prefix directly from ISP and distribute it to the client (via RA), instead of using ULA+NPT.

Sorry.
It had some kind of persistency and I had to turn it on again to have it working.

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

NPTv6 is available in VyOS 1.2 (crux) and currently not implemented in 1.3 (equuleus) as nftables package should be updated to 0.9.5 to make use of netmap.

@zsdc can you please have a look? CHanges to FRR show commands introduced here: https://github.com/vyos/vyos-1x/commit/6492541b

@alexandrestein To be honest, I don't understand why NPTs work in your configuration. It seems to have nothing to do with NPTs.

You are right.

I suppose the problem is related to T2546 and the the op-mode: T2546: migrate show interfaces tunnel,input,pseudo-ethernet,… github commit

In fact, according to official comments and my retrospection of nptv6 code, vyos has not generated any code for nptv6 at present.

I made this works.

https://github.com/xebd/accel-ppp/issues/133

In T2321#66700, @c-po wrote:

@daniil that would work of course. You tested it manuslly that this works?

In this case, SSTP daemon trying to allocate RAM for ipv6 pool and router does not have enough RAM. Dynamic memory allocation is not implemented for ip-pools.
Maybe, in this case, we need to calculate before commit, and show commit fail message with reason?
Calculating:
2^64 bit = 18446744073709551616 bit or 2305843009213693952 byte
2305843009213693952 * 64 (structure size byte) = 147573952589676412928 byte or 137438953472 GB
Correct me if my calculation wrong.

Successfully able to create the vif-s 1234 per the above example without any issues on VyOS 1.3-rolling-202006070117:

This one works good too

Seems like this might be VRF related

@daniil that would work of course. You tested it manuslly that this works?

Can use systemd module file override?

Changed this around a bit to load the modules automatically if necessary. Only adds about half a second to initial execution

@jjakob. to clarify two points (for my sake as well), there are cases where config fails to the point where the config session can not be initialized, such that one can not enter a config session: here's an example --- say. during development, someone forgets to import a module in an early conf_mode script; config initialization is completely screwed --- this had occurred ages ago, and the only way I found it was that I had happened to be looking at their code a few moments previously and noticed ... that's what vyos-config-debug is for, and why it is hidden on a boot flag. You are talking about a much more reasonable case, where (I imagine) a specific configuration causes a partial failure, but one can still enter a config session. The checks in subtask T2568 may help restore the ability to debug by config/load/commit. Those checks are needed anyway.

https://github.com/vyos/vyos-1x/compare/current...jestabro:config-checks.patch

I think we can safely remove it indeed.

A Serial/IPMI interface would be much more suited for kernel debugging.

This has been on my extended todo list for a long time now, but there were always higher priority issues. I'm glad someone is working on it!

PR https://github.com/vyos/vyos-1x/pull/446
Note: gw-ip-address necessary define for [radius] or [chap-secrets] sections.

@c-po I have not tried this previously, but if it works well, I would like to keep it for kernel debugging on bare-metal devices.

I think the old interface sequence number can confuse on this device

@c-po these changes will take effect only for the newly installed system, HW-ID in config has more priority.

Overview of the effort:

T2551 has now been fixed and confirmed working.

@c-po I can now confirm that as of vyos-1.3-rolling-20200607117 this issue is now fixed!

This will move eth0 to eth7 - is there a config migrator? Or is it yet not used in "production"?

PR https://github.com/vyos/vyos-build/pull/106