In T1019#26665, @runar wrote:

Hmm, please enligthen me. Google BBR is a new way to handle congesition instead of the traditional way tcp deals with it. This functionallity needs to be enabled in the end host systems starting the tcp session to have any impact on troughput and congestion control.. as vyos is a router and are not responsible to start tcp sessions on behalf of any end system, what is the benefit of adding this functionallity?

Just to add extra info to this ticket, I had a openvpn-option that i wanted to add but it contained a single quote. I was not able to do this (in version 1.8.x this worked).

Hello,
how to test new versions of vyos
I can not download version 1.2 epa2
Thank you in advance for the information

all these commands show the same output:
show vpn ipsec sa
show vpn ipsec sa verbose
show vpn debug
sudo ipsec statusall

oj
~$ show vpn ipsec sa
Traceback (most recent call last):

File "/usr/libexec/vyos/op_mode/show_ipsec_sa.py", line 51, in <module>
  raise e
File "/usr/libexec/vyos/op_mode/show_ipsec_sa.py", line 45, in <module>

Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.19.4-amd64-vyos, x86_64):

uptime: 7 minutes, since Dec 06 15:06:21 2018
malloc: sbrk 2965504, mmap 0, used 1546144, free 1419360
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 48
loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent xcbc cmac hmac ctr ccm gcm curl attr kernel-netlink resolve socket-default connmark stroke vici updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs dhcp lookip error-notify certexpire led addrblock counters

Listening IP addresses:

it seems that vyos-kernel was disabled

👍 cool. Since we've confirmed that as a solution, I think it's safe to close.

adding a static route towards the vultr gateway fixes this, as @bswinnerton pointed out.

I ended up moving away from VyOS but the more that I think this problem, I wonder if it's due to mutihop being on and not having a route to the next hop.

• Does anyone actually need a graphical frame buffer for Vyos? I would expect it to run mostly headless.
• Is the frame buffer tied to or necessary to solve the EFI issues @c-po raised?

I just tested "show vpn ipsec sa" on latest rolling (vyos-1.2.0-rolling+201812050337) and get exactly the output of "sudo ipsec statusall"

This works fine for me on rc10. Thanks.

And in rc10 it is back to being sluggish with CONFIG_FB_VGA16=y :(

@dmbaturin Hello, sorry for delay. We tested rc10 today, it not crashed but still writing a lot of errors to logs (in the attach).

@kroy - I tried doing an upgrade to match all routers to the same version and it ended quite badly.. all four had their OSPF instance die.

Upgrade to 1.2.0-rc10 and BGP is still working fine. It starts at boot and loads all BGP peers and several full tables.

I'll add here that I've got a reasonably complex OSPF setup with around 10 hosts. I converted it over to VyOS when the first RC came out and I haven't seen this issue at all, and I'm constantly rebooting hosts. Currently upgraded the whole setup to RC10 and not a single host crashed. It's worth adding that I've had a bunch of Mikrotiks in the mix at a time and no problem there either.

Tested with 1.2.0-rolling+201812010337. Still many bugs, very hard to diagnostic it properly.
Minimal list TODO, for we can continue testing:

The vmware tools scripts work as expected, they are stopping and starting the network config as they are supposed to do, but are using debian defaults. So they are not executing the config. I'm going to check of we can extend it a little somewhere to execute the config again when 'resume' happens. In general that won't be an easy fix.

Setting destination port per VXLAN interface sound much more reasonable

I've tested this configuration again and it works for me, so I suppose it's fixed. If it reapprears, feel free to reopen.

@hagbard "show vpn ipsec sa verbose" is now a thin wrapper for "ipsec statusall" so it's not applicable there either. :)

...to be fair, I also think there should be a warning when trying to save a config on a livecd. We hear from people once in a while that they forgot they are running from a livecd and lose their config after reboot.

Clearly undesirable behaviour was caused by a combination of two issues: StrongSWAN starting even when IPsec is not present in the VyOS config, and /etc/ipsec.conf staying in place if config was commited but not saved.

The only remaining bit is the valid_address utility, which is much more difficult to remove because it's so pervasive (used by the "address" option in every interface type).

The root cause is that /config is not mounted on livecd anymore, due to the difference in startup scripts.

Ok, the issue is that StrongSWAN uses different format for SAs with zero and non-zero counters!

@jakevis This exact config works for me in rc9. Could you update and re-test?

This should have been resolved by https://github.com/vyos/vyos-build/commit/2896acaf144a6091576e10b65e477ea35243b3c2

I could not reproduce it, in its simplest form:

Pull Request to add the option

@begetan - it won't connect at all

This makes sense. As I understand it, it just installs another copy of the .efi file to a more “universal” location.

@hagbardI think we need remove or disable such behavior

@kroy @c-po your input needed here

Had been resolved already via https://phabricator.vyos.net/T1054 and is available via latest rolling release.

No problem. There is no hurry, I'm happy running RC5 for now.

I tested the shaper, but it seems to me that the Cisco-AVPair library is missing, it may be missing from my Radius server

I will provide a VyOS testing ISO somewhen next week, would be much appreciated if you can test.

Hi, The NICs are all present{F267310}

Correct

Certainly. I use this one as my home router so no problem. Is this the version you mean? https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso

@SteveP do you have time booting a Debian Buster (testing) ISO on your device and see if your NICs do appear?

https://github.com/vyos/vyos-1x/commit/a29898b2ea15b7d9cea7fade1b27d38967c52d52, will be available with the next latest rolling or via: http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.2.0-7_all.deb

Would also like to see this available for Wireguard interfaces as I'm hitting this when using PBR/NATing.

Yes it will be implemented as soon as it turns out that the switch from the old implementation was successful. We have seen kernel crashes every now and then with the shaper enabled, so I would be keen to know if that happens to you as well to investigate the root cause.

will implement the shaper for bandwidth control? or should I configure manually?

@c-po should we build the latest drivers, or what will be your idea around that?

Is it working at start and fails after some time, or not connection not establishing at all?

it's not so important, just a suggestion, is better concentrate in functions of extreme importance, as ipoe

That is already the case if you don't configure a SN on the server side. So I'm not sure if this setting is not more of a pain instead of a help.

i found using the command man accel-ppp
you can to find it in this link
https://github.com/xebd/accel-ppp/blob/master/accel-pppd/accel-ppp.conf.5
when use value 1, in flag accept-any-service, the server will accept any service name in client side, generally is in blank in client side.

left|rightprotoport has been removed from strongswan since version 5.1. %.6 is running on the latest rolling. Protocols can now be defined via left|rightsubnet (leftsubnet=fec1::1[udp/%any],10.0.0.0/16[%any/53]) .

Ooops X-fire. I grab the IP and prefix from the interface, that way I know it exists and can be removed and won't have to many test cycles. The subsystem needs to be rewritten at one point, but as you can imagine that is quite a task. DHCPv6 won't be affected since it uses always IP/prefix, but I haven't tested it yet.

This problem is fixed by the following pull request:
https://github.com/vyos/vyatta-cfg-system/pull/89

I did some further investigation on this topic, and it turned out that this is a more general problem, which does not just happen in the specific case I wrote above.
It basically happens anytime when an interface is first configured via DHCPv4 and then DHCPv4 is disabled later.

Actually it returns the IP allocated via DHCP, however the ip-normalize script needs a prefix for the regex, which is not set when dhcp was set.