Tested working on 1.3.0-rc6
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Aug 25 2021
+1 for 1.4
Aug 24 2021
Similar task T3360
[email protected]:~$ show interfaces vrrp Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down Interface IP Address S/L Description --------- ---------- --- ----------- eth1v10 10.1.1.1/24 u/u
Aug 23 2021
Aug 22 2021
Aug 21 2021
Confirmed fixed, static address is correctly assigned after resume. Tested with vyos-1.3-beta-202108192027-amd64.iso
Confirmed fixed, tested with vyos-1.3-beta-202108192027-amd64.iso
Aug 20 2021
The json file containing the system component version information was previously an artifact of the XML syntaxVersion implementation; with revisions to the latter in place for 1.4, and initial implementation removed for 1.3, the json file will now be dumped during migration.
Aug 19 2021
Another option (which I use) is to specify --sysctl net.ipv6.conf.lo.disable_ipv6=0 during the container startup.
Aug 18 2021
HI @Viacheslav, this works even in 1.3, your problem is that you need to merge it with isis['FOO'] and not isis.
+1
Sounds good to me.
I close the task, because it can't be reproducible in 1.3.0-rc5
Re-open it, if necessary with described step by step how to reproduce it.
Or open a new one.
from vyos.xml import defaults doesn't work for 1.3 correctly, for some reason it gets 2 isis process with same name "FOO"
https://github.com/sever-sever/vyos-1x/commit/7b0a33618bfa1d1ef99b9744ed1ded49a2c832af
[email protected]# compare [edit protocols] +isis FOO { + interface tun0 { + } + net 49.0001.0000.0011.0001.00 +} [edit] [email protected]# commit [ protocols isis FOO ] {'FOO': {'interface': {'tun0': {}}, 'net': '49.0001.0000.0011.0001.00'}, 'lsp_mtu': '1497'} Only one isis process can be defined
Aug 17 2021
Any news on this?
I haven't tested it directly but I haven't experienced this problem while working on the configuration changes. I don't have much time right now, so I can't test the exact scenario.
Not reproducible, tested on "1.3-beta-202108151336"
@Viacheslav Sorry for the long delay in replying.
- Bug, values on interfaces are overwritten after firewall global parameters.
By default:
[email protected]# sudo sysctl -a | grep "\.rp_filter" net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0 net.ipv4.conf.eth2.rp_filter = 0 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.vtun10.rp_filter = 0
Set value for the interface eth2 value "loose"
[email protected]# set interfaces ethernet eth2 ip source-validation 'loose' [edit] [email protected]# commit [email protected]# sudo sysctl -a | grep "\.rp_filter" net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 net.ipv4.conf.eth1.rp_filter = 0 net.ipv4.conf.eth2.rp_filter = 2 net.ipv4.conf.lo.rp_filter = 0 net.ipv4.conf.vtun10.rp_filter = 0
@Merijn Any updates?
@c-po Can we close it?
Not more actual for 1.3, as it used isc-dhcp-client/isc-dhcp-relay/isc-dhcp-server 4.4.1-2
I can't find in logs something like bad udp checksums
From the manual:
VyOS 1.3.0-rc6 (upcoming) and 1.4 have the following commands available:
Do we need to set this option configurable?
We have an option --disable-syslog so for enable logging it should be --enable-syslog
SA only with hub, output correct
vyos@spoke1:~$ show vpn ipsec sa
Connection State Uptime Bytes In/Out Packets In/Out Remote address Remote ID Proposal
------------ ------- -------- -------------- ---------------- ---------------- ----------- ----------------------------------
dmvpn up 16m24s 2K/2K 24/23 192.0.2.1 N/A AES_CBC_256/HMAC_SHA1_96/MODP_1024
vyos@spoke1:~$
vyos@spoke1:~$
vyos@spoke1:~$ sudo swanctl -l
dmvpn-NHRPVPN-tun100: #1, ESTABLISHED, IKEv1, 2bc867b1ca327379_i* c85b15462b657b03_r
local '100.64.1.11' @ 100.64.1.11[500]
remote '192.0.2.1' @ 192.0.2.1[500]
AES_CBC-256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
established 1001s ago, rekeying in 2400s
dmvpn: #1, reqid 1, INSTALLED, TRANSPORT, ESP:AES_CBC-256/HMAC_SHA1_96/MODP_1024
installed 1001s ago, rekeying in 505s, expires in 979s
in cb2b55ee, 3044 bytes, 24 packets, 91s ago
out cb3647d6, 2474 bytes, 23 packets, 91s ago
local 100.64.1.11/32[gre]
remote 192.0.2.1/32[gre]
vyos@spoke1:~$Tested on VyOS 1.3.0-rc5
Not reproducible update from 1.2.4 to 1.3-rc5
1.2.4 config
set interfaces ethernet eth1 bond-group bond0 set interfaces ethernet eth1 bond-group bond0 set interfaces bonding bond0 vif 29 address '192.168.159.167/31' set interfaces bonding bond0 vif 29 address 'fd12:45:fff:29::2/126' set interfaces bonding bond0 vif 29 description 'Point to Point - DMZ' set interfaces bonding bond0 vif 29 ip ospf dead-interval '20' set interfaces bonding bond0 vif 29 ip ospf hello-interval '10' set interfaces bonding bond0 vif 29 ip ospf priority '220' set interfaces bonding bond0 vif 29 ip ospf retransmit-interval '5' set interfaces bonding bond0 vif 29 ip ospf transmit-delay '1' set interfaces bonding bond0 vif 29 ipv6 dup-addr-detect-transmits '1' set interfaces bonding bond0 vif 29 ipv6 ospfv3 cost '1' set interfaces bonding bond0 vif 29 ipv6 ospfv3 dead-interval '20' set interfaces bonding bond0 vif 29 ipv6 ospfv3 hello-interval '10' set interfaces bonding bond0 vif 29 ipv6 ospfv3 instance-id '0' set interfaces bonding bond0 vif 29 ipv6 ospfv3 priority '220' set interfaces bonding bond0 vif 29 ipv6 ospfv3 retransmit-interval '5' set interfaces bonding bond0 vif 29 ipv6 ospfv3 transmit-delay '1' set interfaces bonding bond0 vif 29 mtu '1500' set interfaces loopback lo address 'fd12:45::14/128' set policy route-map OSPF-Filter description 'This route map will apply to outgoing routes sent via OSPF' set policy route-map OSPF-Filter rule 10 action 'permit' set policy route-map OSPF-Filter rule 10 description 'Only permit loopback interface' set policy route-map OSPF-Filter rule 10 match interface 'lo' set policy route-map OSPF-Filter rule 100 action 'deny' set policy route-map OSPF-Filter rule 100 description 'Default deny' set protocols ospfv3 area 0.0.0.0 interface 'lo' set protocols ospfv3 area 0.0.0.0 interface 'bond0.29' set protocols ospfv3 area 0.0.0.0 range fd12:45:fff:29::/126 set protocols ospfv3 parameters router-id '192.168.159.241' set protocols ospfv3 redistribute connected route-map 'OSPF-Filter'
Large-community and large-community-list it is different functions.
It seems all works fine
@darkdragon-001 It will be available in the next rolling release, can you test it?
Aug 16 2021
PR for current https://github.com/vyos/vyos-1x/pull/974
Might be good to have a workaround in VyOS in the mean time
Thank's for opening an upstream bug
Thank you for testing! The change was backported to 1.3 and 1.2.
Fixed, 1.3-beta-202108151336
[email protected]# run show conf com | match openvpn set interfaces openvpn vtun10 encryption cipher 'aes256' set interfaces openvpn vtun10 hash 'sha512' set interfaces openvpn vtun10 local-host '192.168.122.14' set interfaces openvpn vtun10 local-port '1194' set interfaces openvpn vtun10 mode 'server' set interfaces openvpn vtun10 persistent-tunnel set interfaces openvpn vtun10 protocol 'udp' set interfaces openvpn vtun10 server client client1 ip '10.10.0.10' set interfaces openvpn vtun10 server domain-name 'vyos.net' set interfaces openvpn vtun10 server max-connections '250' set interfaces openvpn vtun10 server name-server '172.16.254.30' set interfaces openvpn vtun10 server subnet '10.10.0.0/24' set interfaces openvpn vtun10 server topology 'subnet' set interfaces openvpn vtun10 tls ca-cert-file '/config/auth/ca.crt' set interfaces openvpn vtun10 tls cert-file '/config/auth/central.crt' set interfaces openvpn vtun10 tls dh-file '/config/auth/dh.pem' set interfaces openvpn vtun10 tls key-file '/config/auth/central.key' set interfaces openvpn vtun10 tls tls-version-min '1.0' set interfaces openvpn vtun10 use-lzo-compression [edit] [email protected]# [email protected]# set interfaces openvpn vtun10 authentication username foo [edit] [email protected]# commit
Aug 15 2021
I have just opened a GitHub issue for this at FRR as well: https://github.com/FRRouting/frr/issues/9405
Just checked, the behaviour for this bug is still the same.
Aug 14 2021
I can confirm that this works fine on the latest 1.3 nightly.
I cannot replicate this in 1.2.8 or 1.3.0-rc5. No matter how long vyos-router.service (even absurdly high times) stalls, ssh.service happily starts. This was probably resolved a long time ago, making this a ghost bug.