My system takes 6 minutes to boot, and it only has two DHCP servers and about 12 interfaces.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 3 2020
I'll wait to test until the reload fix is merged
Definitely confirmed as of yesterday's rolling. Still occurs on three different VMs.
Confirmed fixed in a newer rolling.
Jan 2 2020
Dec 30 2019
@Dmitry Can confirm I was able to upgrade without any errors now. This problem appears to be fixed
Rolling built on 201912301711 seems to have a different issue. Same config as above.
Will confirm later this afternoon when I am on site and let you know.
Seems like this is the same issue as in T1918 @Dmitry
Dec 28 2019
I agree this should be killed.
Dec 23 2019
A reboot seems to have fixed it.
Can confirm. Problem seems to be fixed now.
Dec 21 2019
So I guess the key to duplication here is to:
Maybe even just the action of sudo systemctl restart radvd.service is enough to fix it? It seems to maybe be the case
It seems like maybe something doesn't exist, or permissions aren't working right on a freshly upgraded system, until you manually do something to create it?
So the problem went away until I upgraded to the latest rolling. VyOS 1.3-rolling-201912211124
Dec 20 2019
My output there basically matches yours.
And I don't know if it's relevant, but the syslog output is definitely different depending on whether I restart it, or it gets restarted on boot
Upgraded to lastest official rolling:
Maybe it's because I have multiples? Or on vlans (not that that should matter)
Dec 19 2019
After some more testing, after a reboot, a tcpdump -n -i interface icmp6 on a client machine shows nothing until restarting the radvd service on the routers.
Dec 18 2019
Dec 11 2019
T1846 fixes this
Dec 10 2019
@hagbard Confirmed fix. Migration worked perfectly.
Dec 9 2019
Related to T1844, which should correct the original problem in this ticket
Dec 6 2019
Trying to apply the fix manually:
Built a fresh rolling. It failed with:
Okay, so this problem just got a LOT more bizarre.
Dec 5 2019
When the config was gone, the processes still seemed to be running
Dec 4 2019
It actually does work, if only by accident
This should be all of the relevant configs from the ASA side
Nov 21 2019
I guess I'd ask the question of whether we have any complaints of performance type issues that perf could pinpoint? I don't know if I've ever seen any of those kind of complaints in the circles I hang out in.
Nov 18 2019
PR166 should fix this.
Oct 31 2019
Complete
Oct 30 2019
Oct 27 2019
This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py
Oct 25 2019
Oct 24 2019
This pull request rewrites all the functionality of ioctl.pm and lays the framework for the rest of Interface.pm
Attached
VyOS 1.2-rolling-201910210211 boots perfectly.
Oct 22 2019
Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg
Superseded by T1759
Oct 21 2019
Oct 15 2019
Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).
Oct 14 2019
To be fair, that’s what prompted this. The logs go to a different file already.
This PR should address those concerns
Oct 1 2019
This is going to become more and more of a problem as wireguard adoption continues. Most major Wireguard VPN services provide a FQDN as their endpoint, not IP:
This should be reverted, as the change is breaking. After more testing, I found some problems due to things like static routing being applied before wireguard now. So the wireguard tunnel works, but in some cases any routing that shouldbe going over the tunnel does not work.
Sep 30 2019
Yep. Changing the priority fixes the issue completely
@runar This isn't a routing issue though.
Changing when the tunnel comes up isn’t an option? For whatever reason the tunnel comes up before DNS resolution works. Using a hostname when the system is running works perfectly
Sep 29 2019
Guess? Wireguard coming up before vyos-hostsd?
Sep 24 2019
Can confirm. All my routing tables now have 0.0.0.0/0, no matter what the device is. This is just in 1.2.3.
Sep 23 2019
At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.
Sep 20 2019
PR132 fixes this problem
Sep 19 2019
Sep 18 2019
Sep 16 2019
There are a number of strange things going on here, and I suspect there are multiple bugs: