T1846 fixes this

@hagbard Confirmed fix. Migration worked perfectly.

Related to T1844, which should correct the original problem in this ticket

Trying to apply the fix manually:

Built a fresh rolling. It failed with:

Okay, so this problem just got a LOT more bizarre.

When the config was gone, the processes still seemed to be running

It actually does work, if only by accident

This should be all of the relevant configs from the ASA side

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.

PR166 should fix this.

Complete

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

This eliminates the redundant interfaces.py and merges the op_mode displaying code into ifconfig.py

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.

Example output. Note this is all programmatically generated in Python now instead of parsing the output of wg

Superseded by T1759

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

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

Okay, after working with this for a while, I believe the whole 'vyatta-webproxy` should be a candidate for deletion in equuleus (see T1732).

To be fair, that’s what prompted this. The logs go to a different file already.

This PR should address those concerns

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.

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

Guess? Wireguard coming up before vyos-hostsd?

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.

At this point I've moved all my ASAs to VyOS, and all my tunnels to Wireguard. Unfortunately I cannot test this setup anymore.

PR132 fixes this problem

There are a number of strange things going on here, and I suspect there are multiple bugs:

I took a look, but was unable to figure out how to finagle VyOS to fix it.

Attached are the pcap and debug logs from a simple setup as outlined above, two hosts. "Master" distributing the route.

Yep. Can confirm issue is fixed with the latest hot fix.

Strange. I’ve seen that error a lot. Every time it’s been when I’ve forgotten to checkout current after cloning the repo.

@Merijn make sure you git checkout currenton everything.

Can you describe the system and disks involved?

@jmlccdmd See the fix in T1120. Does changing the rootdelay to something longer fix it for you? Or turning off acpi as suggested?

Yeah, it wasn't really a workable solution for me either and I too had to roll back. But it would be good to confirm that is the problem.

@lbv2rus There might actually be a few problems here. We might have hacked out that it's the interface-route with the custom routing table that's causing the problem.

I’ll add that I think this is happening because of the .252 and .254 addresses. The 254 address connects, but the 252 address is marked in a constant state of connecting.

There might actually be a bit of a deeper problem here, somewhat conditional on some static interface routing. On an broken system, it does say something about staticd starting

And more info:

I tracked down what is causing this.

Too add, routes are present in FRR

THis shows up in the logs:

Unfortunately that seems to have made the problem worse. Before, at least each host was seeing one other host. Now most of them see no hosts.

Sure. I'll set a reminder to check it out tomorrow when I have a free minute. Thanks

Sorry. Spent the week restoring almost half a petabyte of data from backups due to a ZFS crash.

Yeah. I remove the initial vyos user and add an admin and an ansible user. The admin is just for consistency across different devices.

@hagbard I remove/change the vyos user too. So it's definitely a breaking change.

The latest rolling did seem to correct the base problem. That being cron scripts running breaking the ability to edit config afterwards.

@hagbard Note that a reboot does fix the ability to edit configuration again until the next time the cron script runs.

Okay, spent the whole day messing with this and I've tracked it down so it's reproducible.

Superseded by T1178

Seems to be a problem with just that build. I'll install a newer rolling when I get a chance and see if that corrects it.

Edit... actually I can't update anything:

I was mistaken. Seems to have lost the route again.