@n.fort the config i would like to upload to this ticket has 43727 lines.. Its a text file of 1.3 Mbps. Its it possible to attach the file instead of paste it on the comments?

Hi, I'm sorry for the confusion but the configuration I uploaded is not from a production machine. It's just an example of a small configuration of a pre-production vyos that I was having trouble upgrading.
Tomorrow if I will upload one of the ones that take 25-30 minutes to boot on modern CPUs (xeon gold).

With shared config, I'm not getting high times while loading config (at least not that high as exposed in this task)

@n.fort Sorry yes this AC-1 vyos was on 1.2.1 I will a test tomorrow with a version 1.2.6-S1 to have the path i was mention..

Thanks for sharing.
It this ok?

@n.fort yes . This is an example os our AC-1 enviroment (the one i have used for the first test)

Can you share your config @daniel.arconada ?

tried also with vyos-1.4-rolling-202203070319-amd64.iso and same issue with the migration

Hi @Viacheslav I have tried this morning upgrading from vyos 1.2.6-S1 to vyos-1.4-rolling-202204060217-amd64.iso but something went wrong with the firewall config load and all the firewall rules and objets were removed from config so impossible to test.. :(

@daniel.arconada it should be fixed in 1.4
Can you check it?

Do we have any news when this feature (-n option) will be included? We have lot of vyos on 1.2.X with booting times between 20 and 40 minutes and commits about 3-5 minutes.

cherry-pick for 1.3 https://github.com/vyos/vyos-1x/pull/1271

Great.
In that case I suggest marking this invalid and close it

I've been testing , the feature works as expected . IPOE assigns different ip by dhcp using ip-pool :

vyos@ipoe:~$ show ipoe-server sessions
ifname     | username |    calling-sid    |     ip     | rate-limit | type | comp | state  |  uptime
---------------+----------+-------------------+------------+------------+------+------+--------+----------
 eth3.1000.140 |          | aa:bb:cc:00:60:00 | 10.10.10.0 |            | ipoe |      | active | 00:03:44
 eth3.1000.130 |          | aa:bb:cc:00:50:00 | 10.10.10.2 |            | ipoe |      | active | 00:

PR https://github.com/vyos/vyos-1x/pull/1267

@n.fort
I ve added this code in to the scrip and the issue resolved.
if [ "$(id -g -n)" != 'vyattacfg' ] ; then
exec sg vyattacfg -c "/bin/vbash $(readlink -f $0) $@"
fi

there is another possible to achieve the desired result , it's using this radius-option:

@m.korobeinikov
Does your configuration include this scripts corrections? https://docs.vyos.io/en/equuleus/automation/command-scripting.html#executing-configuration-scripts

My understanding of the requirement would be, say, T3758 in the case of op-mode. I consider this to require the refinement of op-mode firstly, as one wants per-command authorization.

op-mode endpoints for 'show', 'generate', 'image' have been a part of the REST API for a while, as I'm sure you are aware (just to be clear):

In T1610#110278, @jestabro wrote:

@adestis there were discussions on this in the past week --- I will be helping @dmbaturin with the task

1.3.0:
Still generating the same config

(VyOS 1.4)

1.3 PR: https://github.com/vyos/vyatta-cfg-system/pull/176
1.4 PR: https://github.com/vyos/vyatta-cfg-system/pull/177

@n.fort I have been able to reproduce this, it only occurs when installing for UEFI.

I can't add anything else unfortunately, it just doesn't work for me on a physical device whichever value I enter, it always takes the remainder of the free space for the root partition. Manually modifying it works fine.

@pvanberlo Can you share more info on how we can reproduce this issue?

I wasn't able to reproduce the issue.
I installed 3 times VyOS 1.3.0 version on Proxmox:

@Cheeze_It It is not hard https://github.com/vyos/vyos-1x/blob/current/op-mode-definitions/show-bgp.xml.in

@Viacheslav, hmmm, yeah that's a good point. I'll see what I can do to add the OP configs. I know I added the conf configs.

@Cheeze_It There is a task for op-mode T4265
Task for controller T4266

ISC will be decommissioning dhcpd at some point and continuing to work on Kea:

+1

PR https://github.com/vyos/vyos-1x/pull/1230

+1; versioning the API is also a best practice.

@anthr76 we have ready telegraf exporter, maybe it will work for you?
https://docs.vyos.io/en/latest/configuration/service/monitoring.html

Does anyone at least have an example of how to use the snmp exporter? For example a snmp.yml or generate one with the given mibs?

this is very similar to https://phabricator.vyos.net/T3657 , so it seems that this is going to be fixed in 1.4 ( proof https://forum.vyos.io/t/bgp-peering-with-ipv6-link-local-addresses/7309/14 ). Is this going to be backported to 1.3 ? Anyone is able to find the commit that introduced the feature on 1.4? Maybe it is something easy to patch

PR for equuleus https://github.com/vyos/vyos-1x/pull/1222

Sorry, it works properly only for not PD. Looks like is not backported to equuleus
Client-side configuration to reproduce

set interfaces ethernet eth0 address 'dhcpv6'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 address '1'
set interfaces ethernet eth0 dhcpv6-options pd 0 interface eth1 sla-id '0'
set interfaces ethernet eth0 dhcpv6-options pd 0 length '64'

On server-side we get the same backtrace

vyos@vyos# run show dhcpv6 server leases 
Traceback (most recent call last):
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 209, in <module>
    leases = get_leases(conf, lease_file, args.state, args.pool, args.sort)
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 142, in get_leases
    leases = sorted(leases, key = lambda k: int(ip_address(k['ip'])))
  File "/usr/libexec/vyos/op_mode/show_dhcpv6.py", line 142, in <lambda>
    leases = sorted(leases, key = lambda k: int(ip_address(k['ip'])))
  File "/usr/lib/python3.7/ipaddress.py", line 54, in ip_address
    address)
ValueError: '2001:db8:290::/64' does not appear to be an IPv4 or IPv6 address

Tested on VyOS version 1.3.0, works properly

vyos@vyos# run show version | match Version
Version:          VyOS 1.3.0
[edit]
vyos@vyos# run show dhcpv6 server leases 
IPv6 address        State    Last communication    Lease expiration     Remaining    Type           Pool         IAID_DUID
------------------  -------  --------------------  -------------------  -----------  -------------  -----------  -----------------------------------------------------------------
2001:db8:3456::187  active   2022/02/15 09:28:10   2022/02/15 21:28:10  11:58:28     non-temporary  VyOS-DHCPv6  00:00:00:00:00:04:79:76:62:99:23:ad:43:fb:9c:5b:1c:1e:59:4b:58:01

Hi @hensur , I'm sure that this code should be moved to python implementation, patches for the legacy vyatta-cfg-qos will be rejected.
First of all, need to create CLI XML definition
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#xml-used-for-cli-definitions
and then create backend in python to process CLI commands
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#configuration-script-structure-and-behaviour

I can confirm that the latest 202202140317 build fixes this issue, thanks.

I'd like to see cake in vyos as well. I don't think this has been implemented yet (at least not under the traffic-policy section in 1.4-rolling) ?

I can't get your configuration, how does should work without the declaration source or remote address?

I think I'm experiencing this same issue. I just tried upgrading a VPN server running 1.3-rolling-202001260217 to 1.3.0 LTS. As this is a production server (albeit a secondary/backup server) I've reverted to the old version of VyOS, and it looks like a fix is already on its way, so I just wanted to add my info to the ticket.

@Scoopta Can you check your configuration with the next rolling release?

I'm able to reproduce this with 1.4, using the new config structure:

I will close this. It turns out the root cause is related to this other bug I filed:

PR https://github.com/vyos/vyos-1x/pull/1133

PR https://github.com/vyos/vyos-1x/pull/1214

I checked in the OpenVPN network lab.
Version:

Version:          VyOS 1.3.0
Release train:    equuleus

Configuration:

vyos@vyos# show interfaces openvpn vtun0
set interfaces openvpn vtun0 encryption cipher 'aes256gcm'
set interfaces openvpn vtun0 hash 'sha512'
set interfaces openvpn vtun0 local-host '192.168.122.100'
set interfaces openvpn vtun0 local-port '1194'
set interfaces openvpn vtun0 mode 'server'
set interfaces openvpn vtun0 openvpn-option '--client-to-client'
set interfaces openvpn vtun0 openvpn-option '--verb 9'
set interfaces openvpn vtun0 openvpn-option '--mute 10'
set interfaces openvpn vtun0 openvpn-option '--dev vtun0'
set interfaces openvpn vtun0 openvpn-option '--ifconfig-pool-persist ipp.txt'
set interfaces openvpn vtun0 openvpn-option '--status openvpn2.log'
set interfaces openvpn vtun0 openvpn-option '--user nobody --group nogroup'
set interfaces openvpn vtun0 openvpn-option '--persist-key --persist-tun'
set interfaces openvpn vtun0 openvpn-option '--keepalive 10 120'
set interfaces openvpn vtun0 persistent-tunnel
set interfaces openvpn vtun0 protocol 'udp'
set interfaces openvpn vtun0 server max-connections '5'
set interfaces openvpn vtun0 server name-server '1.1.1.1'
set interfaces openvpn vtun0 server push-route 10.10.10.0/24
set interfaces openvpn vtun0 server subnet '10.10.20.0/24'
set interfaces openvpn vtun0 server topology 'subnet'
set interfaces openvpn vtun0 tls ca-cert-file '/config/auth/openvpn/ca.crt'
set interfaces openvpn vtun0 tls cert-file '/config/auth/openvpn/central.crt'
set interfaces openvpn vtun0 tls dh-file '/config/auth/openvpn/dh.pem'
set interfaces openvpn vtun0 tls key-file '/config/auth/openvpn/central.key'
set interfaces openvpn vtun0 use-lzo-compression

After rebooting, the OpenVPN configuration is saved:

@Scoopta I can't get your configuration, how does should work without the declaration source or remote address?
There is a template that generates OpenVPN site-to-site configuration https://github.com/vyos/vyos-1x/blob/9910020ae6ef37964c97bb28b6b1d84f8227650b/data/templates/openvpn/server.conf.tmpl#L143-L147

To reproduce in 1.4

set interfaces bridge br3 member interface vtun2
set interfaces openvpn vtun2 device-type 'tap'
set interfaces openvpn vtun2 mode 'site-to-site'
set interfaces openvpn vtun2 persistent-tunnel
set interfaces openvpn vtun2 shared-secret-key 'foo'
set pki openvpn shared-secret foo key '190696ff2244ca9ce8d5bef8718c58881fe8df8e3519c8bf6ede49108c97a5d9456db648d8c5ca953bb19d21978527a742497426313e614640d037ffffa4980be315e193727ebfb28f3725b779e2d3309ad6f8c939363f7fc14a0080c81e3faf4b053661c81c3003ddabeb87ac8611b81718956b7325f03978c74f502b39965f0d788b21b4370f6a625e3098f8d71ff3e653f50c54b424c511cba78871b38337237830a34266aa9558cd69c68ded89f7f0a82f94b5b87200c7ea05edb14a806e9e4998b00dc2895d976c0e506a6a06056745bca6ce1d2a5c95a51a1460e3080c7743eecbcee9d2c4f89d9e1b59f44484e43591f43bf713255b5de13ae8500620'
set pki openvpn shared-secret foo version '1'

Commit:

Traceback (most recent call last):
  File "/usr/libexec/vyos/conf_mode/interfaces-openvpn.py", line 663, in <module>
    verify(c)
  File "/usr/libexec/vyos/conf_mode/interfaces-openvpn.py", line 228, in verify
    if len([addr for addr in openvpn['local_address'] if is_ipv4(addr)]) > 1:
KeyError: 'local_address'

It can be fixed in thoses PR's:
https://github.com/vyos/vyos-1x/pull/1210
https://github.com/vyos/vyos-1x/pull/1211
T4230

For example, I have 300 routers in different timezones and I want to reboot 50% of routers via 1441min and the other 50% via 2881min

Hi @Viacheslav, I guess that, at least for our use cases, PR 9aad6f would allow the expected behavior.

Sorry, but I dont think this is fixed; I just attempted to upgrade my working 1.2.8 configuration to 1.3.

For 1.4 this feature was added in T2683

Fixed in 1.3

vyos@r4:~$ show interfaces counters 
Interface    Rx Packets   Rx Bytes     Tx Packets   Tx Bytes
dum0                  0          0              0          0
eth0                126       9952             76      10316
eth1                  4        280              5        523
eth2                 37       1924              0          0
lo                    6        300              6        300
vyos@r4:~$ 
vyos@r4:~$ clear interfaces ethernet eth1 counters 
Clearing eth1
vyos@r4:~$ show interfaces counters 
Interface    Rx Packets   Rx Bytes     Tx Packets   Tx Bytes
dum0                  0          0              0          0
eth0                182      14550            108      14340
eth1                  0          0              0          0
eth2                 42       2184              0          0
lo                    6        300              6        300
vyos@r4:~$

Good question. I missed this moment.
So, if you want to reload in some minutes, VYOS offered you two variants:

1. To choose between 1 and 99
2. To set time when you want to reload VYOS if 99 minutes too short for you (for example 10:00, 12:45, 23:59, and so on)

But descriptions of thees command doesn't have enough information about it.

Why is it 1-99?
If I want to reboot the router in 1500 min?

@johannrichard Hey sorry I didn't see your comment, I suggest we move the discussion to the dedicated task: https://phabricator.vyos.net/T4209

This is now implemented in 1.4