| Age | Commit message (Collapse) | Author |
|---|
|
This PR adds an config option to enable/disable IGMP/MLD snooping.
```
set interfaces bridge brN igmp snooping
```
|
|
Error introduced by commit 85d6c8f7c ("vyos.configdict: T4391: enable
get_interface_dict() ti be used with ConfigTreeQuery()"). Reason was the
still in use relative path on calls to node_changed(), these got
replaced with absolute config paths and the new implementation if
is_node_changed().
|
|
Commit a2ab95ff68b ("pppoe: T4384: replace default-route CLI option with common
CLI nodes already present for DHCP") had an issue as the PPPoE interface options
and also DHCP interface options did not honor the no-default-route option.
This has been fixed.
|
|
|
|
|
|
* Refactor nftables clean-up code
* Adds policy route test for using firewall groups
|
|
|
|
firewall: T478: Add support for nesting groups
|
|
|
|
|
|
Firewall: T3907: add log-level options in firewall
|
|
firewall: T970: Add firewall group domain-group
|
|
|
|
|
|
|
|
|
|
Domain group allows to filter addresses by domain main
Resolved addresses as elements are stored to named "nft set"
that used in the nftables rules
Also added a dynamic "resolver" systemd daemon
vyos-domain-group-resolve.service which starts python script
for the domain-group addresses resolving by timeout 300 sec
set firewall group domain-group DOMAINS address 'example.com'
set firewall group domain-group DOMAINS address 'example.org'
set firewall name FOO rule 10 action 'drop'
set firewall name FOO rule 10 source group domain-group 'DOMAINS'
set interfaces ethernet eth0 firewall local name 'FOO'
nft list table ip filter
table ip filter {
set DOMAINS {
type ipv4_addr
flags interval
elements = { 192.0.2.1, 192.0.2.85,
203.0.113.55, 203.0.113.58 }
}
chain NAME_FOO {
ip saddr @DOMAINS counter packets 0 bytes 0 drop comment "FOO-10"
counter packets 0 bytes 0 return comment "FOO default-action accept"
}
}
|
|
|
|
http-api: T4442: Add action reset
|
|
Add action 'reset' (op-mode) for HTTP-API
http://localhost/reset
curl --unix-socket /run/api.sock -X POST -Fkey=mykey \
-Fdata='{"op": "reset", "path": ["ip", "bgp", "192.0.2.14"]}' \
http://localhost/reset
|
|
The configs bgp_bfd_communities and bgp_big_as_cloud reveal a
counterexample to the independence of component migration scripts:
quagga migration scripts must precede those of bgp; explicitly reorder
from lexical order.
|
|
|
|
|
|
Firewall: T990: Add snat and dnat connection status on firewall
|
|
ConfigTreeQuery()
When VyOS is booting and an interface is brought up (PPPoE) which requires a
user callback script that is executed asynchronously when the interface is up
we can not use Config(). The problem is, Config() is not available when
the system starts and the initial commit is still processed.
We need to move to ConfigTreeQuery() which was build for this exact same
purpose. TO reduce side effects and also dependencies on the entire
vyos.configdict library the set_level()/get_level() calls got eliminated
from within the library. All calls to functions like:
* get_removed_vlans()
* is_node_changed()
* leaf_node_changed()
* is_mirror_intf()
* ...
Now require that the full config path to the node is passed.
|
|
T4361: refactor and simplify vyos.config.exists()
|
|
|
|
Fix logic for verify traffic-policy in def verify_mirror_redirect
It checks just "traffic_policy.in" and should also checks if
'mirror' or 'redirect' exists in config
|
|
present for DHCP
VyOS 1.4 still leverages PPPd internals on the CLI.
pppd supports three options for a default route, none, auto, force.
* none: No default route is installed on interface up
* auto: Default route is only installed if there is yet no default route
* force: overwrite any default route
There are several drawbacks in this design for VyOS and the users. If auto is
specified, this only counted for static default routes - but what about dynamic
ones? Same for force, only a static default route got replaced but dynamic ones
did not got taken into account.
The CLI is changed and we now re-use already existing nodes from the DHCP
interface configuration:
* no-default-route:
On link up no default route is installed, same as the previous
default-route none
* default-route-distance:
We can now specify the distance of this route for the routing table on the
system. This defaults to 210 as we have for DHCP interfaces. All this will be
migrated using a CLI migration script.
|
|
|
|
|
|
node is added"
This reverts commit c685c0f762ea054c7a220bde625fdab549bbbdd2.
|
|
leaf_node_changed()"
This reverts commit 1a1094c28e32c3d6d072cf14a38aa631d51b8aee.
|
|
|
|
static routes
Issue is identical to the problem in T3680 (05aa22dcb4ce) which was for DHCP
based routes. Once a static route is added to the system, the PPPoE
auto-installed default route is lost.
|
|
set interfaces vxlan vxlan0 parameters ip df <set|unset|inherit>
set interfaces geneve gnv0 parameters ip df <set|unset|inherit>
|
|
Commit c685c0f7 ("vyos.configdict(): T4369: leaf_node_changed() must return True
when node is added") added a code path then a node was newly added to the CLI.
Unfortunately it turned out that this introduced a regression:
File "/usr/lib/python3/dist-packages/vyos/ifconfig/wireguard.py", line 230, in update
super().update(config)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/interface.py", line 1428, in update
for addr in list_diff(config['address_old'], new_addr):
File "/usr/lib/python3/dist-packages/vyos/configdict.py", line 105, in list_diff
return [item for item in first if item not in second]
TypeError: 'bool' object is not iterable
The execution order of the if statements is essential and the new check was
moved to the bottom to not interfere with the existing logic.
|
|
added
|
|
|
|
|
|
|
|
The check for existence of value(s) in config.exists relied solely on
return_value, causing the return of a false negative on multi-valued
nodes; this is corrected. Also, config.exists_effective did no check for
existence of values; this is added.
|
|
|
|
|
|
Certain NICs seem to fail to report that they don't support speed/duplex setting,
so they look as if it's supported, but the command fails in practice.
It's probably better to preserve a working config in that case.
|
|
|
|
|
|
|
|
|
|
|
