@Viacheslav but that sounds more of a decent FRR bug. We could still consider adding EIGRP support for 1.4
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jul 11 2021
Backported fix from T3637
Jul 10 2021
oh good grief this is an old problem.. Just found a reference here while researching: https://community.ui.com/questions/DHCP-Failover-Configuration-Multiple-VLAN-interfaces/da7a0f03-2c4e-4d9f-9924-c2297db177db
I can confirm this on the latest rolling versions, seems to be a problem with the IPSec rewrite/move to swanctl.conf.
This seems to work now.
Jul 9 2021
It is a feature request.
So we don't have a "large-comm-list" for set in our CLI. It is incorrect to compare "large-community" with "large-comm-list"
The option "delete" is preset only for the "lists"
I can't reproduce it in 1.3-rc5
set interfaces wireguard wg0 address '10.1.0.3/24' set interfaces wireguard wg0 address 'cafe:c01d:c01a::2/64' set interfaces wireguard wg0 description 'VPN-to-wg-PEER01-192.0.2.1' set interfaces wireguard wg0 ipv6 ospfv3 cost '24' set interfaces wireguard wg0 ipv6 ospfv3 dead-interval '40' set interfaces wireguard wg0 ipv6 ospfv3 hello-interval '10' set interfaces wireguard wg0 ipv6 ospfv3 instance-id '0' set interfaces wireguard wg0 ipv6 ospfv3 priority '1' set interfaces wireguard wg0 ipv6 ospfv3 retransmit-interval '5' set interfaces wireguard wg0 ipv6 ospfv3 transmit-delay '1' set interfaces wireguard wg0 peer PEER01 address '192.0.2.1' set interfaces wireguard wg0 peer PEER01 allowed-ips '0.0.0.0/0' set interfaces wireguard wg0 peer PEER01 allowed-ips '10.0.3.0/24' set interfaces wireguard wg0 peer PEER01 allowed-ips '::/0' set interfaces wireguard wg0 peer PEER01 port '12345' set interfaces wireguard wg0 peer PEER01 pubkey 'Cpqy8=' set interfaces wireguard wg0 port '54321' set protocols ospf area 0 network '10.1.0.0/24' set protocols ospf passive-interface 'default' set protocols ospf passive-interface-exclude 'wg0' set protocols ospfv3 area 0 interface 'wg0'
In the latest rolling release all works fine without any changes
vyos@r1-roll:~$ show version
The issue seems still present in Vyos 1.3.0-rc5
Jul 8 2021
It seems there were changes in squid , but not in our code.
It is not used /var/log/frr anymore T2061
Please backport this to 1.3. Thanks.
trae@cr01a-vyos# show system config-management commit-archive { location sftp://cr01a-vyos.int:<somePassword>@stor01z-rh8.int.trae32566.org:/int/cr01a-vyos source-address lo } commit-revisions 10000
Jul 7 2021
vpn rsa-keys migrated: https://github.com/vyos/vyos-1x/pull/912
@trae32566 I can't replicate this. Can you post your config?
This is still broken on the most recent rolling release:
trae@cr01a-vyos# commit Using source address lo Archiving config... sftp://stor01z-rh8.int.trae32566.org:/int/cr01a-vyos Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python3/dist-packages/vyos/remote.py", line 315, in upload upload_sftp(local_path, url.hostname, url.path, username, password, port, source, progressbar) File "/usr/lib/python3/dist-packages/vyos/remote.py", line 190, in upload_sftp transfer_sftp('upload', *args, **kwargs) File "/usr/lib/python3/dist-packages/vyos/remote.py", line 162, in transfer_sftp sock.connect((hostname, port)) OSError: [Errno 22] Invalid argument [edit protocols bgp]
Jul 6 2021
@sdev , Thank you. I will test and confirm, once the new rolling version is released.
Thanks for the confirmation
Jul 5 2021
Hi @c-po i've been testing the added command.
yes , but when you use 'set protocols static route 10.0.0.0/8 next-hop 1.1.1.1 next-hop-vrf red' it doesn't install the prefix in the default table :
@tjh If you have a test lab, can you check conntrack-sync in the latest 1.3?
Jul 4 2021
@dongjunbo this is a very very basic PR for VyOS 1.4 with the goal to implement this into the main VyOS release.
Jul 3 2021
Commands are implemented.
Jul 2 2021
Thanks Chris I'll test it once available and let you know!!
Added command set service conntrack-sync interface <intrerface> port <port>
Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540
Fixed for 1.3 in commit https://github.com/vyos/vyos-1x/commit/21527ef4551613fe9b7eed9e4b2ce33ad46fe540 and T3535
I'm seeing the same behavior for the OSPF v2 configuration on the 1.4 train for an image built on April 26th 2021. Just a heads up.
Source NAT Rules went Out of Range in VyOS 1.4-rolling-202107010320
Hi @c-po I hope you're doing great!
Should be resolved in PR: https://github.com/vyos/vyos-1x/pull/903