Do we need to set this option configurable?
We have an option --disable-syslog so for enable logging it should be --enable-syslog
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
Feed All Stories
All Stories
All Stories
Aug 17 2021
Aug 17 2021
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
Viacheslav changed the status of T690: Allow OpenVPN servers to push routes with custom metric values from Open to Needs testing.
@darkdragon-001 It will be available in the next rolling release, can you test it?
GitHub <noreply@github.com> committed rVYOSONEX6707322f7547: Merge pull request #974 from sever-sever/T690 (authored by c-po).
Aug 16 2021
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
c-po reopened T3734: Move EVPN VRF up in FRR config, a subtask of T3728: FRR not respect configured RD and RT for L3VNI, as On hold.
zsdc closed T3735: Configuration with multiple network addresses of firewall network-group via colud-init fails as Resolved.
Thank you for testing! The change was backported to 1.3 and 1.2.
Viacheslav moved T3738: openvpn fails if server and authentication are configured from Need Triage to Finished on the VyOS 1.3 Equuleus board.
Fixed, 1.3-beta-202108151336
vyos@r4-1.3# 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] vyos@r4-1.3# vyos@r4-1.3# set interfaces openvpn vtun10 authentication username foo [edit] vyos@r4-1.3# commit
Not sure that it is a good idea for this format.
The syntax between versions (1.3/1.4 bgd/isisd) is changed. With every syntax change you should also change and section "service https API ... bgp"
My point API must have a full access to all configuration options.
Aug 15 2021
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.
GitHub <noreply@github.com> committed rVYOSONEX0dd9037036c6: Merge pull request #973 from sever-sever/T3702 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEXc244c2e99519: Merge pull request #972 from erkin/current (authored by c-po).
c-po updated the task description for T3757: OSPF: add support to configure the area at an interface level.
c-po updated the task description for T3757: OSPF: add support to configure the area at an interface level.
c-po added a project to T3757: OSPF: add support to configure the area at an interface level: VyOS 1.4 Sagitta.
c-po changed the status of T3757: OSPF: add support to configure the area at an interface level from Open to In progress.
c-po committed rVYOSONEX69ec102365ee: wireguard: T3756: fix generated qr code header (authored by bmanojlovic).
GitHub <noreply@github.com> committed rVYOSONEXd3ae6304a3ea: wireguard: T3756: fix generated qr code header (authored by bmanojlovic).
GitHub <noreply@github.com> committed rVYOSONEX2e15f551713f: Merge pull request #944 from sever-sever/T3702 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEXedcf31d23968: Merge pull request #970 from jack9603301/T3648 (authored by c-po).
GitHub <noreply@github.com> committed rVYOSONEX43fcc0db006a: conntrack: T3275: migrate 'disable' syntax to 'enable' syntax for the new… (authored by erkin).
Aug 14 2021
Aug 14 2021
c-po committed rVYOSONEXceb623bbd658: openvpn: T3738: Disable authentication option for server mode (authored by Viacheslav).
c-po closed T3745: op-mode IPSec show vpn ipse sa sorting, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, as Resolved.
more amount of generalisation as we would not only want to use it for DHCp but all kind of services
Well the commit you outlined alters file ins src/conf_mode - that directory is reserved for CLI configuration scripts.
erkin closed T1083: Implement persistent/random address and port mapping options for NAT rules, a subtask of T2198: Rewrite NAT in new XML/Python style, as Resolved.
erkin closed T1083: Implement persistent/random address and port mapping options for NAT rules, a subtask of T3710: Upgrade the kernel in 1.3 to 5.10, as Resolved.
erkin closed T1083: Implement persistent/random address and port mapping options for NAT rules as Resolved.
I can confirm that this works fine on the latest 1.3 nightly.
c-po moved T3753: frr: upgrade to stable/8.1 release train from Open to Backlog on the VyOS 1.4 Sagitta board.
c-po moved T3755: ospf: adjust to new FRR 8 syntax where "no passive-interface " moved to interface section from Open to Backlog on the VyOS 1.4 Sagitta board.
c-po moved T3745: op-mode IPSec show vpn ipse sa sorting from Open to In Progress on the VyOS 1.4 Sagitta board.
c-po changed the status of T3745: op-mode IPSec show vpn ipse sa sorting, a subtask of T2816: Rewrite IPsec scripts with the new XML/Python approach, from Open to Needs testing.
c-po changed the status of T3745: op-mode IPSec show vpn ipse sa sorting from Open to Needs testing.
erkin closed T521: Network services may fail if vyatta-router.service startup takes longer than a few seconds as Resolved.
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.
Thanks, that makes sense. Do you think the current outstanding change could be merged in? It's not resulting in any incompatibilities (that I'm aware of), and while it doesn't fix the problem entirely on its own (doesn't include infrastructure work), it improves the code under test.
That is a noble idea. There are some build time tests available here: https://github.com/vyos/vyos-1x/tree/current/src/tests - maybe this helps
As far as I can tell (from README), smoke tests are meant more to be integration than unit tests:
that feels like you wan't to achieve the same goal as https://github.com/vyos/vyos-1x/blob/current/smoketest/scripts/cli/test_service_dhcp-server.py
I think the easiest way would be to just extend the smoketest with your tests that you find missing.
I managed to make the DHCP configuration testable, although the code has some hardcoded paths which I didn't want to mess with too much, so my addition may be suboptimal.