How about parallel loops?
https://metacpan.org/pod/Parallel::Loops

Both Routers running VyOS 1.2.3

This PR still needs to be merged: https://github.com/vyos/vyatta-cfg/pull/23

The above patch breaks sorting for other nodes that contain text, not a number. We'd need some way to distinguish different node types (text, IP, number,...) and chose different sorts depending on that.

This is only for interfaces, T2175 is for all frr related daemons .. other features need a ticket

In the current 1.3 branch the original issue was resolved and added STOP script support. It is necessary to test this and review the possibility to backport the solution into 1.2.

Is this only for interfaces or for other rewrites (NAT, Firewall, BGP) too? If so, I'll add all the related tasks.

Why we can't enable this feature by default.
A lot of customers don't use it, and announce their BGP prefix with "network x.x.x.x"
Imagine if you don't have configuration "redistribute connected" or "redistribute static".
If this feature enabled by default in the new release - you update the VyOS, reboot it and lose access to the router.
Because there are no routes /24 as directly connected. Also, you can use more-spec prefixes (/28 /29 /25), not /24.
Prefixes will disappear from the announcements ISPs.
It's impossible to figure out quickly what happened.

I tried adding it but failed miserably. This should best be done with the entire BGP rewrite.

Ok, as a workaround you can you.

set nat destination rule 102 source address !192.168.68.0/24

set nat destination rule 102 destination port '80'
set nat destination rule 102 inbound-interface 'eth2'
set nat destination rule 102 protocol 'tcp'
set nat destination rule 102 translation address '192.168.68.101'
set nat destination rule 102 translation port '80'

How will internal clients gain access to external sites if we forward all packets with dst port 80?
This is just one example.

One question, I don't understand why we can't use only port 80 without this dynamic WAN IP address. In any case, you have inbound interface and port, I think this will be enough.

What's the reason for enabling flow control by default? I'd have assumed disabled is more common and causes less problems. The node naming is not the best IMO as it has "disable-" in it, more reasonable would be to have a node called "flow-control" that enabled it if set, the default being disabled, and it could have sub-nodes to tweak the exact flow control settings.

I would check in main, before get_status, if a interface is disabled in config, then I'd just print "vtunX is disabled" and skip all other processing for that interface. If a interface is enabled but its status file isn't readable, print "Error: status file for vtunX is not readable" (I'd use try/except around the open in get_status, and return a exception so that main can print the error).

I can confirm the above commit fixes booting with interfaces that don't support flow control. I have no way of checking that it properly applies if the interface does support it.

After discussion on the PR it was determined this functionality wasn't needed.

I tested it today and it doesn't work yet.

@cpo is it what you have in mind:

Why must the operstate be up? I't rather check if the tunnel is configured (/opt/vyatta/etc/openvpn/status/vtun1.something) exists and then run the commands.
Thus if the tunnel is down due to remote end beeing offline it would not report it as operstate is down (if operstate is properly implemented in OpenVPN)

@jjakob if what you say is correct then the solution should look like. I can not test it tho (simply as I do not know how to setup OpenVPN and have no lab to make it work).

Successfully tested on 1.2.5-epa2 and 1.3-rolling-202003310117

Without source ip address from local prefix strongswan can't create route in table 220. I'm not sure that we need to check and decline a commit. But we can show warning message.
Interfaces on boot have more priority and it can guarantee that if in router exist ip address from local prefix, strongswan will create the route,
When interface configured after IPSec, need run restart vpn for add routes.
I propose to add the following code to https://github.com/vyos/vyatta-cfg-vpn/blob/current/scripts/vpn-config.pl#L670

my $check_local_route = qx(ip route show table 254 $ocalsubnet_object);
if (!$check_local_route){
    print "Warning: local prefix $localsubnet_object specified for peer \"$peer\"\n";
    print "is not configured on any interfaces\n";
}

@c-po do you have any updates?

+1, I'd also like if all failed commits were stored in a permanent log somewhere to make debugging easier, I can't find one right now.

The file exists on my system (1.3-rolling-202003291001):

-rw------- 1 root root 377 Mar 31 11:44 /opt/vyatta/etc/openvpn/status/vtun0.status

and show openvpn server works:

vyos@rt-home:~$ show openvpn server

I vote for this as well. I have a lot of addresses I need to add to a nat source address so I need to create one rule per IP. Because I have a specific rule numbering scheme, I'm running out of space in it so I had to break the scheme. The ability to use groups in nat source and destination addresses would greatly help.

Thank you for the assignment but I have not looked at or touched the OpenVPN code (and never used OpenVPN myself).
This issue with the op_mode, not config mode, so so it must have been there for a while.
I could change the code to check that the file exist, and prevent this fault but I am not sure it would be the right thing todo.

While you're looking at it, can you try to move it to a systemd service? I opened a task for discussion: T2185

I think I agree: at commit time, user's CLI edit level is irrelevant and should have no effect on the script behaviour.

If this is a duplicate of something, go ahead and close it

PR283 should fix this.

https://github.com/vyos/vyos-1x/pull/287

https://github.com/vyos/vyos-1x/pull/285

In IPv6 the next-hop interface is simply called interface to mimic the default IPv6 behavior of the Vyatta code.

Already fixed via https://github.com/vyos/vyos-1x/commit/3a46ad00f55873e1372f24a01f3c2698e6568623