@c-po It makes sense
Need to try.
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Aug 14 2021
Aug 13 2021
Well test it tomorrow once it becomes available :)
They are all intermixed ;) - maybe I also missinterpreted the issue. Maybe you can retest the latest rolling which will be available by tomorrow? Image is currently build: https://ci.vyos.net/job/vyos-build/job/current/2195
Nvm I just noticed that the task number was mentioned in a commit, I have a feeling this won't solve the issue as this is related to the router bgp 123 vrf something rather than vrf something statements.
Very cool this has apparently been fixed already, I was reading through the vyos-1x commints and didn't see anything that looked related. What was the implemented change for this?
PR for current https://github.com/vyos/vyos-1x/pull/967
Aug 12 2021
Another bug.
From time to time I get errors in debug mode ("touch /tmp/vyos.frr.debug" and "sudo systemctl stop vyos-configd") when changing lsp-mtu size
vyos@r1-roll# set protocols isis lsp-mtu 1308 [edit] vyos@r1-roll# commit [ protocols isis ]
We have this problem in more then one case. The solution so gar is to use " as quote which we later on render in Jinja2
Sounds like a missing validator. Wo should prevent users from doing such things ;)
@Viacheslav, when we use a migrator we should enable the ipv4 afi for each and every ipv4 neighbor if its not configured explicitly. What do you think? If a peer group is configured for that neighbour, too - that will be no issue.
Aug 11 2021
Thanks for you comment ! it's good consider that options
Similar task T2315, also there is bug related T1976, etc.
It should be a migration script that determines ip/ipv6 neighbor and set neighbor to properly afi.
So there is one question, how to determine which afi we should to use if we see "peer-group" in configuration?
I don't think that we can implement it in 1.3 as it uses an old codebase.
Thank you for the quick fix!
I added a new neighbor belonging to the sub-AS 65031 to the existing bgp configuration:
Hello, @nyamada!
Really appreciated for such a detailed problem analysis! The regex is fixed in the 1.4 version now.
Could you test it, so we can backport changes safely to 1.2 and 1.3?
To reproduce in 1.4:
As Workaround in T3350 set raw option "config /path/to/config/file"
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
https://github.com/vyos/vyatta-cfg-vpn/commit/2cec760601a6e85ca8e0b6a30c173196a97a777a
Back-ported the dhcp ip check loop to 1.3
@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
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.