- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
All Stories
Aug 10 2021
Aug 9 2021
PR for Equuleus https://github.com/vyos/vyos-1x/pull/959
- Backport configquerry.py [Done]
https://github.com/vyos/vyos-1x/commit/2aa75521a829712256c3c34685e60a9d36b33791
Need to implement in customer, if I can help in something, please don't hesitate to ask.
Maybe with FRR 8.1
In any case, we'll do more tests.
It's upgrade on FRR planned?
https://github.com/vyos/vyatta-cfg-vpn/commit/2cec760601a6e85ca8e0b6a30c173196a97a777a
Back-ported the dhcp ip check loop to 1.3
In T3728#99683, @Viacheslav wrote:It is possible this bug.
https://github.com/FRRouting/frr/issues/9181
It is possible this bug.
https://github.com/FRRouting/frr/issues/9181
Take a look to:
@dtoux Did you test it in 1.3.0-rc5?
@xrobau As I mentioned before, peer-group can't exist without peer-as/remote-as in your case remote-as should be internal. It can exist without remote-as but with "route-reflector-client" it shouldn't
You can check it with vtysh FRR:
Tested on 1.3-rc5, all works properly
set vpn ipsec esp-group ESP_DEFAULT compression 'disable' set vpn ipsec esp-group ESP_DEFAULT lifetime '3600' set vpn ipsec esp-group ESP_DEFAULT mode 'tunnel' set vpn ipsec esp-group ESP_DEFAULT pfs 'dh-group19' set vpn ipsec esp-group ESP_DEFAULT proposal 10 encryption 'aes128' set vpn ipsec esp-group ESP_DEFAULT proposal 10 hash 'sha256' set vpn ipsec ike-group IKEv2_DEFAULT close-action 'none' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection action 'hold' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection interval '30' set vpn ipsec ike-group IKEv2_DEFAULT dead-peer-detection timeout '120' set vpn ipsec ike-group IKEv2_DEFAULT ikev2-reauth 'no' set vpn ipsec ike-group IKEv2_DEFAULT key-exchange 'ikev2' set vpn ipsec ike-group IKEv2_DEFAULT lifetime '10800' set vpn ipsec ike-group IKEv2_DEFAULT mobike 'disable' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 dh-group '19' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 encryption 'aes128' set vpn ipsec ike-group IKEv2_DEFAULT proposal 10 hash 'sha256'
Flow served QAT
vyos@R2-QAT# run show system acceleration qat device qat_dev0 flows +------------------------------------------------+ | FW Statistics for Qat Device | +------------------------------------------------+ | Firmware Requests [AE 0]: 60046 | | Firmware Responses[AE 0]: 60046 | +------------------------------------------------+ | Firmware Requests [AE 1]: 112720 | | Firmware Responses[AE 1]: 112720 | +------------------------------------------------+ | Firmware Requests [AE 2]: 219657 | | Firmware Responses[AE 2]: 219657 | +------------------------------------------------+ | Firmware Requests [AE 3]: 60046 | | Firmware Responses[AE 3]: 60046 | +------------------------------------------------+ | Firmware Requests [AE 4]: 112722 | | Firmware Responses[AE 4]: 112722 | +------------------------------------------------+ | Firmware Requests [AE 5]: 219657 | | Firmware Responses[AE 5]: 219657 | +------------------------------------------------+
Interrupts
vyos@R2-QAT# run show system acceleration qat interrupts 140: 44039 0 0 0 0 0 0 0 IR-PCI-MSI 524288-edge qat0-bundle0 141: 0 42358 0 0 0 0 0 0 IR-PCI-MSI 524289-edge qat0-bundle1 142: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524290-edge qat0-bundle2 143: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524291-edge qat0-bundle3 144: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524292-edge qat0-bundle4 145: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524293-edge qat0-bundle5 146: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524294-edge qat0-bundle6 147: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524295-edge qat0-bundle7 148: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524296-edge qat0-bundle8 149: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524297-edge qat0-bundle9 150: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524298-edge qat0-bundle10 151: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524299-edge qat0-bundle11 152: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524300-edge qat0-bundle12 153: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524301-edge qat0-bundle13 154: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524302-edge qat0-bundle14 155: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524303-edge qat0-bundle15 156: 0 0 0 0 0 0 0 0 IR-PCI-MSI 524304-edge qat0-ae-cluster
PR for 1.3 https://github.com/vyos/vyos-1x/pull/957
I closed it. Can't reproduce it.
Re-open it if necessary. Just attach your vpn configuration.
The same task T1375
Aug 8 2021
>>> from vyos.config import Config
>>> conf = Config()
>>> conf.get_config_dict(['service', 'ssh'])
{'ssh': {'disable-host-validation': {}, 'port': ['22']}}
>>> conf.get_config_dict(['service', 'non-existing'])
{}Checks the grub config rule by rule if ttyS/ttyUSB is used then updates the newly to be included grub template to the same.
Aug 7 2021
I'm also affected by this. My configuration has about 5k ip prefixes in network group for policy based routing.
Did more checks.....and noticed it *IS* properly sending the ping command:
I see these error in the openvpn log:
I don't think so the configuration is working, the interface is down. It is not assigning the ipv6 addresses to the tunnel interfaces.
It was enabled by commit https://github.com/vyos/vyatta-cfg-vpn/commit/993f5bf9f54bcb7af20d44e7618586b55064a372 quite a while ago and no one complains, so I assume it's not an issue anymore.
It's not a bug, it's simply a weird syntax. That command could never be used without the delete option, so your config example wouldn't work in 1.2 or 1.1.8 either.
Aug 6 2021
You COULD have a peer-group without remote-as, as you could apply that peer group to multiple remotes, and override the remote-as. But that is an edge case. The BETTER way to handle it is to enforce having a remote-as -- especially if you enable route-reflector-client
salt-minion in the debian buster tree is version 2016.11.2+ds-1+deb9u4
Seems like the repo's not needed anymore as my iso just built without it, twice, after a clean, and with a bunch of added stuff (tor, docker, systemd-nspawn, xtables-addons, hardened-malloc, a grsec kernel, etc) for which dependencies are also available without it.
Either way, probably a good idea to keep deps for anything third-party in the vyos repo itself since third parties can become hostile through buyouts or license changes any time and anywhere in these post-FOSS times.
salt-minion which depends on salt-common which may depend on a couple of other things:
What packages are we actually pulling from there? Any reason they're not in the VyOS repo itself?
I removed their repo entirely from the JSON config and my image built fine (apparently i now have to add a /debian suffix for all packages in our repo, but that's weirdness in the repo management stack):
Reading package lists... Building dependency tree... Reading state information... [2021-08-06 21:39:40] lb source P: Source stage disabled, skipping P: Build completed successfully
The procedure I usually end up using:
https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release looks wrong - shouldn't it read main at the end, instead of Release?
Trying to use their instructions from https://repo.saltproject.io/#debian i'm back to the certificate issue - repo is set to https://repo.saltproject.io/py3/debian/10/amd64/latest buster main and the custom GPG key has been added, but certificate checks still fail hard:
Reading package lists... W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/InRelease: No system certificates available. Try installing ca-certificates. W: https://repo.saltproject.io/py3/debian/10/amd64/latest/dists/buster/Release: No system certificates available. Try installing ca-certificates. E: The repository 'https://repo.saltproject.io/py3/debian/10/amd64/latest buster Release' does not have a Release file. E: An unexpected failure occurred, exiting... P: Begin unmounting filesystems... P: Saving caches... Reading package lists... Building dependency tree... Del nftables 0.9.6-1 [66.8 kB]
After cleaning the chroot and retrying, it now fails utterly with the '#' in there: