Understood, it just means for now I have no option of running 1.4-rolling.
Just a heads up that the latest rolling is still broken. I can’t use/test/report back on 1.4 for quite some time now.
Is there something up and coming that will fix the issue?
Wanted to add a +1 to this, I am currently experiencing the same issue in my vSphere 7 environment where it is impractical to enable promiscuous mode.
Looking forward to seeing a fix in 1.4 Rolling Release.
Cheers!
Has the cause of this problem been identified and is there news on when a fix is coming.
I am a happy supporter of the project via Patreon but not been able to run 1.4-rolling for almost 6 months, and there’s no update provided.
1 Like
Hi @Dmitry,
Just to add my 2 cents, I am unable to get this working even with promiscuous mode enabled. I have tried enabling promiscuous mode, forged transits, and mac changes just for good measure. I have tried both a regular VLAN port group (tagging on the vSwitch, like an access port) as well as a trunked port group (allowing VLANs 1-4094, tagging on the vyos machine) and have had the same behaviour with both.
Above are my 4 x VMXNET3 interfaces on my 1.4 rolling VM.
Here are the relevant MAC addresses:
PS /Users/kanecharles> Get-VM a-vrouter-01 | Get-NetworkAdapter | select name, type, macaddress
Name Type MacAddress
---- ---- ----------
Network adapter 1 Vmxnet3 00:50:56:ad:89:ab
Network adapter 2 Vmxnet3 00:50:56:ad:3c:1b
Network adapter 3 Vmxnet3 00:50:56:ad:4a:03
Network adapter 4 Vmxnet3 00:50:56:ad:8c:26
Based on the console screenshot of my vyos vm, you can see that the link/ether value for all of the NICs are correct but the permaddr value is all over the place:
-
eth0in vyos is showing as having thepermaddrofNetwork adapter 4 -
eth1in vyos is showing as having thepermaddrofNetwork adapter 1 -
eth2in vyos is showing as having thepermaddrofNetwork adapter 2 -
eth3in vyos is showing as having thepermaddrofNetwork adapter 3
As a tie over until this is fixed in the codebase, can you please advise on what other changes would need to be made to allow them to work with the promiscuous mode workaround?
I can’t go back to 1.3 as I require a bunch of VRF capabilities currently only present in the 1.4 releases.
Cheers,
Kane.
@phillipmcmahon do you have a copy of the 1.4-rolling-202104300710 ISO?
I was unable to find it for download, hoping you might be able to upload it if you’ve got it still.
Cheers,
Kane.
Sorry, but no longer have any older versions. I figured as 1.4 is broken beyond that there is no point to store them.
I moved back to 1.3.
Maybe @Dmitry can help locate that version if they keep such archives?
@Dmitry is there an update on what we can do to get 1.4 back up and running, or when a fix is coming? Happy to help in whatever way.
Happy to help if you want more info from my side, changes to be made etc. etc. Looking forward to being able to use the 1.4 branch.
Hello @phillipmcmahon, we found a couple of bugs with interface renaming in 1.4 rolling. It relates to code rewriting and I think we will fix it as soon as it possible.
Sounds like a good start.
It’s been broken a few months now, surprised it hasn’t impacted more people but that’s a good thing.
Any suggestion of an ETA, days, weeks or even months sort of thing?
1 Like
I am seeing what I believe is similar issues (there is multiple presented over all the posts with different people here) but I do not get a default route, my WAN is DHCP and I have static routes defined.
I may be less impacted with the interface renaming issue as I run “router on a stick” via one interface only that does all my vlans. With my 40G equipment this works great and easy to control vlans instead of a VMXNET3 per vlan so I am happy with this solution.
I must note here I am not using promiscuous mode or forged transmits. I switched to MAC learning on the firewall port group a little bit ago and loving it. Can highly recommend!
Have a read it, I noticed some people were not able to turn it on (security policy or otherwise) but this works fine with VLANS as well as VRRP.
Sounds hopeful, now there is some traction on the problem finding
How can I help out, please do let me know?
have the fixes made it into a rolling release yes, keen to deploy and test?
It’s quite some time since this has been broken and I am a little conflicted as to what supporting the project via Patreon at $25/month ($475 to date - backer since May 2020) should bring, especially when I didn’t take the route of paying once getting access to LTS downloads and cancelling. Maybe my expectations are off, genuinely not sure.
Hello @phillipmcmahon sorry for the delay. We had a few meetings and actively discussed this issue. Unfortunately, it is still not resolved but we resolve it in 3-5 days.
Hello @phillipmcmahon ,PR to fix this issue already proposed. I believe the new ISO with improvements will be available tomorrow. You can also download the latest 1.4 with improvements by the following link https://cdn.vyos.io/test-releases/VyOS-1.4-test-net-names.iso
Will download to test this evening and let you know whether that’s a success.
Sadly no joy. Seems to be losing my eth0 interface, take a look at the attached screens. Let me know what I can do to provide more information. It’s a little bit of a pain as I can only access via the vmware console app which doesn’t support cut&paste.
Did you do update the system? Please, edit sudo nano /config/config.boot and delete all entry hwid in the config file. Then reboot router. As ea example
vyos@vyos:~$ sudo nano /config/config.boot
interfaces {
ethernet eth0 {
}
ethernet eth1 {
}
ethernet eth2 {
}
ethernet eth3 {
}
loopback lo { }
}
Keep other params from, just need to delete hw-id and macs hw-id "xx:xx:xx:xx:xx:xx"