archiving

@c-po can you probably merge and close this one

@thinkl33t Can you please test?

Can you retest on the latest rolling and see if that repeats?

@c-po want to handle this yourself or need @dmbaturin participation?

@hagbard we need to remove all old stuff including lightttpd
we going to replace it with nginx as per T808

need to build kb article for process

Hello @danhusan!
How big is your configuration at all? Can you provide depersonalized config? Which hardware or virtual machine using for VyOS? Can you provide full log of booting?
We can't confidently reproduce this bug. Looks like configuration can't load quickly enough or something like this.

Bug confirmed. The problem is in FRRouting CLI (FRRouting 7.1-dev).
Will see what we can do with this.

Received the following commit error:

Hmm. That's weird, I tested some rolling releases and 1.2.0, directly connected and via 5 hops, I can't reproduce what you see. If your crypto is ok and you have the the interface up and running, there won't be an issue. I would also see way more bug tickets here. So , I still believe yoru setup is incorrect, however it's hard to say where it fails. If the wg interface has no incoming and outgoing traffic, it's most likely routing. If inside the wg interface traffic goes out but is not answered but received on the upstream interface, somet6hing is wrong with the crypto. In your sho interface output is shows that traffic is being sent, but nothing recveived, that means the traffic you receive on the WAN side can't be authenticated, so that is an crypto issue. Either the traffic can't be decrypted or there is no existing setup for this public key. If the public key fits, then you can always decrypt with with your private one.

In T1226#32251, @hagbard wrote:

@Maltahl That smells more like an issue with your key setup. The wg interface listens on any interface which is up and running. If the traffic inside the wg interface doesn't show anything, that means it can't decrypt the traffic with your private key.

Hello, @adestis!
You can use values from 5 to 100. 600 is unsupported in current FRRouting.

@Maltahl That smells more like an issue with your key setup. The wg interface listens on any interface which is up and running. If the traffic inside the wg interface doesn't show anything, that means it can't decrypt the traffic with your private key.

Hello, @MrXermon!
We can't reproduce this bug. Maybe, there are some other errors, which can affect route-maps?
If you have the old configuration, can you check update procedure with an update to 1.2.0-LTS and current rolling?

Ah, I misread, my apologies. Let me try.

Hello, @rizkidtn!
Is any problems still exist with your configuration or we can close this issue?

@ekim rephrased: remove the DHCP-interface option and only use and configure the local-address to 0.0.0.0.

Hello, @dongjunbo!
Can you check behavior with new versions? If the problem still exist show us an example of such big configuration, or at least count of objects and their types in this config.

Hello, @bjtangseng!
Can you recheck this with fresh versions? Seems that in 1.2.0-LTS and rolling everything is OK. Also, if there is no VPN logs at all (for example, VPN is not configured), you can see output like in first message and then this will be not a issue.

Hello, @TrueTechy!
As I understand, this situation can exist only if interface is in down state? Can you check this behavior with fresh VyOS version?

In T1218#32229, @kroy wrote:

@lbv2rus

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.

@hagbard i have tried removing all firewall rules on both routers and checked that the wireguard module was running. i have also tried allowing all traffic and also allowed udp for the wireguard port when it arrived.

I've also noticed these errors,
but inside the FRR (sudo vtysh -c "show run")
the commands are inserted normally in your case.

The system is a Supermicro SYS-5018D-FN8T with 2 x 240G Intel SSDs and 16G of RAM.

Can you describe the system and disks involved?

There must be something missing in the initrd image or something like that.

Even in a shut down peer, even with no route-map set, I still get that message.

No, neither fixed it.

This is not a Vyos issue - adding the same thing in vtysh does the same thing.

I encountered this same problem: I saw the output:

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

I booted sys-rescue-cd 6.0 in EFI mode from usb stick.

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.

In T1218#32227, @kroy wrote:

@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.

Removing that should bring back static routes.

@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.

Hi Syncer,

I can confirm, that fresh installed instance of 1.2 do not add static routes, include default route.
After deleting all "protocols static" section and recreating it manualy, only default route is added.
But, after reboot no default route is set.

I would consider adding EVPN support via FRR as soon as kernel support for the inter working between vxlan and bridge interfaces is more fleshed out. Maybe I should create a new task for that.

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.

Tested the config above with in 1.2, no issues found. Not sure what it is yet, but it looks like that either the traffic doesn't really reach the destination (aka endpoint) or vice versa. Awaiting some show output to check the key config etc.

No. The configuration 'dhcp-interface' and 'local-address' are mutually exclusive , so attempting to commit a configuration with both results in a commit error.

Can you try without dhcp-interface and set 0.0.0.0 as local-address?

@Maltahl You can use any rolling, I made an enhancement yesterday to disable peers, but other than that the code hasn't been touched for a while. If the rolling release works, I need to have a look into 1.2.0. I tested with your config above and everything was working as expected, but I'm around today so feel free to ping me on slack in 1hr.