User Details
- User Since
- Dec 10 2016, 3:58 AM (404 w, 20 h)
Jan 19 2024
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
May 17 2021
I just tried that and it fails. We get
May 7 2021
PBR works if we change the static route to:
May 6 2021
I have not built vyos since 2018, so my last production version was 201803051831.
Apr 15 2021
ipv6 address autoconf works here. It does pick up a v6 address from the RA - I had an error in the config on the router issuing the RA announcements, and thought that autoconf was not working, but it does. Perhaps this issue should be closed?
Apr 9 2021
I cannot reproduce this on VyOS 1.4-rolling-202104062128. Instead, on that version, ipv6 address autoconf commits, but the interface never picks up a v6 address.
Apr 8 2021
Oops, I did not see that. Thanks.
I modified bgp.frr.tmpl, but systemctl restart vyos-configd did not seem to do anything. Rebooting the router produces the correct config:
Apr 7 2021
May 2 2018
From a 1.2 build last night:
May 1 2018
There is a vyos-open-vm-tools git repo. The 'make iso' installs that package. In the process of building the iso (Setting up open-vm-tools-dkms) it tries to rebuild a kernel module. If we don't rebuild that there are two issues:
Dec 5 2017
Dec 4 2017
trivial patch
attached. I am running 1.2.0 "current" with this.Dec 1 2017
Nov 30 2017
Nov 29 2017
Ah, I missed the -t raw. I thought maybe the ULOG target needs uacctd running first on netlink group 2, so I started it:
Nov 28 2017
No, ULOG is there:
duplicate of T296, this one can be deleted.
I was not able to create a patch for vyos-build since I am missing something in my understanding of submodules. There should be some way to generate a git patch that adds submodules. But this works:
Nov 22 2017
The nightly builds started working again on the 16th, so this task should be moved to 'finished'.
I have a script that builds all (well, almost all) the vyos packages from source, including the kernel, and then builds an iso with those rebuilt packages.
Nov 21 2017
patch attached{F27881}
Nov 14 2017
Nov 13 2017
I don't have a setup to test this, but it seems that if it works at all for outgoing connections, it should also work for incoming connections. Suppose you have been assigned external::1111/64 as your ipv6 address, and you have an internal network running on internal::/64, with nptv6 converting from internal::/64 to external::/64. Now a machine on internal::1234 will appear to be external::1234, and your router will send the outgoing packets to the external gateway. But when the response packets come back, the ISP will need to do neighbor discovery to find your external::1234. If that works at all, it should also work for incoming connections.
Nov 9 2017
Does "set nat nptv6" not work for you? You can configure your inside interface with a private /64 block, then prefix translate that to the /64 obtained set nat nptv6 rule 10 inside-prefix