- User Since
- May 22 2016, 4:44 AM (225 w, 6 d)
Jul 12 2020
Jul 11 2020
After upgrading, the entire NAT section is gone
Error when upgrading to 1.3
Jun 14 2020
Confirmed fixed, thanks @c-po!
There's a regression here, I can not 'delete system console' in the current rolling build, I get this:
May 13 2020
Apr 13 2020
Mar 16 2020
Reopened, confirmed broken again.
Jan 21 2020
Turns out that 'destination-interface any' works, and I just hadn't read the help.
Dec 15 2019
Nov 12 2019
Nov 10 2019
Nov 5 2019
Confirmed fixed in
vyos@mke-fw1:~$ show version Version: VyOS 1.2-rolling-201911051339 Built by: firstname.lastname@example.org Built on: Tue 05 Nov 2019 13:39 UTC Build UUID: 3863567b-039d-4fdd-90cc-eda2e1b11bc6 Build Commit ID: 33c865b2ada281
After adding the missing command set high-availability vrrp sync-group sync member int1, we have a new error when starting conntrackd
Nov 3 2019
Confirmed still present in VyOS 1.3-rolling-201911030242
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP group default qlen 1000 link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 9000 qdisc mq master bond0 state UP group default qlen 1000 link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff 4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP group default qlen 1000 link/ether 08:07:06:05:04:03 brd ff:ff:ff:ff:ff:ff inet6 fe80::a07:6ff:fe05:403/64 scope link valid_lft forever preferred_lft forever
Oct 30 2019
My hypothesis is that Interface.set_mac is being called AFTER the bond is applied, which sets the mac of the interface back to what it was originally. Probably adding a check to see if it's a bond member may solve it
Basic config that duplicates this problem
To summarise, the MACs of interfaces that are bonded should all be the same (and should also match the mac of the bond interface). This works correctly in the older July build. However, this no longer works *on boot* in the latest builds. The screenshot above shows eth0, eth1, and bond0 all having different MACs which is why it's not working.
On the old image, the macs are set correctly
OH. MY. GLOB. I just figured it out.
This appears to be a bug in that intel driver - there's people reporting the same issues here: https://sourceforge.net/p/e1000/bugs/649/
This is getting more and more crazy the more time I spend on it, as this is a niggly issue that shouldn't be this hard to figure out.
Oct 29 2019
Oh, just to emphasize that it's a startup-config issue, if I disable and re-enable the ethernet port in the switch, it is still broken. The only way to get it working is to delete the member, commit, and re-add the member inside vyos.
While it was booting, it responded to three pings, and then nothing
It looks like the problem occurs when both interfaces are present when the machine boots. I can remove either one, reboot the machine, and it works.
Working 1.2.0-rolling config (with the different bonding syntax)
1.2.0 complete bond0 output
Oct 19 2019
Out of curiosity, I tried 201910170117, and it was fine (at least for booting). The 20191018 image may be broken - should it be pulled?
Jul 22 2019
Sep 23 2018
UEFI is not difficult.
Jul 31 2017
Jul 30 2017
I simply symlinked it to work around the problem.