| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
If we have link-local static address and vrf, for example:
set interfaces ethernet eth2 address 'fe80::5200:ff:fe55:222/64'
set interfaces ethernet eth2 vrf 'foo'
This IPv6 address was assigned before vrf, as result after
attaching the intreface to vrf we lose this static linklocal
address
DEBUG/IFCONFIG cmd 'ip addr add fe80::5200:ff:fe55:222/64 dev eth2'
DEBUG/IFCONFIG cmd 'ip link set dev eth2 master foo'
DEBUG/IFCONFIG cmd 'ip addr add fe80::5208:ff:fe13:2/64 dev eth2'
This commit fixes this, the address is assigned after vrf assign
|
|
|
|
not none
We have a lot of boiler plate template code like
{% if config.interface is defined and config.interface.remote_as is defined
and config.interface.remote_as is not none %}
...
{% endif %}
This can be stripped down using a custom test to:
{% if config.interface.remote_as is vyos_defined %}
...
{% endif %}
In addition the new vyos_defined test supports comparison
{% if foo.bar.baz is vyos_defined('zoo') %}
...
{% endif %}
So the above will only evaluate to true if the variable foo.bar.baz is defined
and its content is zoo
This is inspired from https://github.com/aristanetworks/ansible-avd/ which make
heavy use of it.
All new templates should be written in this new style.
|
|
This extends the fix from 53e20097 ("vyos.ifconfig: T4330: bugfix changing MTU
when IPv6 is disabled") by ordering the execution in a way the Kernel does not
complain.
|
|
Commit f8b3d8999c ("ipv6: T4319: do not configure IPv6 related settings if it's
disabled") moved the MTU configuration part under the code path which is only
run if IPv6 is enabled on the system.
This prevented MTU changes on IPv6 disabled systems.
|
|
|
|
|
|
|
