| Age | Commit message (Collapse) | Author |
|---|
|
The original implementation of defaults, and workaround required, would
leave an entry {'dhcpv6_options': {'pd': {}}} in the interface_dict.
|
|
|
|
For those cases not covered by automatic merging of defaults in
get_config_dict(..., with_defaults=True), get_config_defaults should
take arguments consistent with those of get_config_dict, for ease of
merging results.
|
|
|
|
|
|
|
|
At boot, the util function check_port_availability can return False with
EADDRNOTAVAIL if the interface is not yet up; check explicitly for
address in use.
|
|
QoS DSCP match is skipped
Add it
set qos policy shaper test class 23 match 10 ip dscp 'network'
tc filter replace dev eth0 parent 1: protocol all u32 match ip dsfield 224 0xff flowid 1:17
|
|
T5296: Fix QoS class bandwidth calculation for auto and percent
|
|
tc filter exepcts protocol number for match instead of protocol name
|
|
|
|
There are wrong bandwidth calculations for the class
We shouldn't rely on interface speed but we should get this value
from 'shaper <tag> bandwidth xxx' if configured 'auto' or
bandwidth with '%'
Otherwise we can get unexpected rate for the class
% sudo cat /sys/class/net/eth0/speed
% -1
generated rate:
classid 1:17 htb rate -1000000
Fix this
|
|
config-mgmt: T5297: add check for changes under node between revisions
|
|
|
|
Do not handle rate via 'tc filter' directly but rather set the
'tc filter' to direct traffic to the correct tc class flow.
As it in 1.3.
It fixes random unexpected shapes, when you set for example 300mbit
but get 3-11mbit
Current implementation seems not correct as it uses rate limits
two times (in class and in filter):
tc class replace dev eth0 parent 1:1 classid 1:17 htb rate 250000000 \
burst 15k quantum 1514
tc filter replace dev eth0 parent 1: protocol all u32 match \
ip dst 192.168.122.11 action police rate 250000000 burst 15k flowid 1:17
The correct way after fix:
tc class replace dev eth0 parent 1:1 classid 1:17 htb rate 250000000 \
burst 15k quantum 1514
tc filter replace dev eth0 parent 1: protocol all u32 match \
ip dst 192.168.122.11 flowid 1:17
|
|
|
|
change speed/duplex settings
This is the same problem as reported in T4297. By definition it is not possible to change speed and duplex settings at SR-IOV virtual functions driven by ixgbevf driver. I think the solution is the same as well, that is to add 'ixgbevf' into _drivers_without_speed_duplex_flow in /usr/lib/python3/dist-packages/vyos/ethtool.py. It fixed the problem for me with Intel x520 NICs.
|
|
http-api: T5248: set/load config sections as JSON via API
|
|
... this is a step towards a new and better implementation that will utilize
VPP.
|
|
|
|
|
|
The function 'unsaved_commits' was added in config_mgmt to warn a user
of unsaved commits before commit-confirm, as that entails a possible
reboot. As it has other uses and no dependence on the object itself,
move to module scope. For general use, add simple check for live image
to avoid false positive, due to config migration reformatting.
|
|
Configtree functions delete/delete_value do not check return value of
libvyosconfig functions; raise error on non-zero return value.
|
|
|
|
process_named_running() was introduced in commit 16b2fc8fc4ca ("dns-forwarding:
T2298: fix path to control file") and thus remained more or less unchanged.
Smoketests use process_named_running() heavily and might spawn multiple
processes with the same name but ifferent options (e.g. dhcp6c or dhclient) and
it was yet not possible to properly filter on the "real-deal" like the process
bound to a given interface.
One can now optionally specify a string that is searched inside the command
line argument list of the process.
Example:
>>> process_named_running('dhcp6c', 'veth0')
['/usr/sbin/dhcp6c', '-D', '-k', '/run/dhcp6c/dhcp6c.veth0.sock', '-c',
'/run/dhcp6c/dhcp6c.veth0.conf', '-p', '/run/dhcp6c/dhcp6c.veth0.pid', 'veth0']
4215
>>> process_named_running('dhcp6c', 'veth1')
['/usr/sbin/dhcp6c', '-D', '-k', '/run/dhcp6c/dhcp6c.veth1.sock', '-c',
'/run/dhcp6c/dhcp6c.veth1.conf', '-p', '/run/dhcp6c/dhcp6c.veth1.pid', 'veth1']
4253
Where the debug list returned is the commandline searched.
|
|
If non_local=False (default), cli_defined returns True if the node is a
child of the path in interface-definitions; otherwise True if node is a
descendent of the path.
|
|
|
|
xml: T5218: revise vyos xml lib for bug fixes and extensions
|
|
Operations get_defaults and get_config_defaults return default values
only for nodes with parent in the config dict (get_config_defaults) or
at the path (get_defaults). To include default values of decendent
nodes, set option recursive=True.
|
|
|
|
Revert "veth: T3829: Allow moving veth into netns"
|
|
netns management for any Vyos interfaces doesn't work past the initial
creation, because Vyos always tries to recreate it/move it into the
netns even though it already exists. Until this is fixed, don't let
anyone even attempt to use this:
set interfaces virtual-ethernet veth10 peer-name 'veth100'
set interfaces virtual-ethernet veth100 netns 'ns01'
set interfaces virtual-ethernet veth100 peer-name 'veth10'
set netns name ns01
commit
vyos@r14# sudo ip netns exec ns01 ip link show
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
12: veth100@if13: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether ee:8f:0b:bd:a2:f8 brd ff:ff:ff:ff:ff:ff link-netnsid 0
[edit]
vyos@r14#
set interfaces virtual-ethernet veth100 description MyNetns
commit
Traceback (most recent call last):
File "/usr/libexec/vyos/conf_mode/interfaces-virtual-ethernet.py", line 111, in <module>
apply(c)
File "/usr/libexec/vyos/conf_mode/interfaces-virtual-ethernet.py", line 101, in apply
p.update(veth)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/interface.py", line 1413, in update
self.set_netns(config.get('netns', ''))
File "/usr/lib/python3/dist-packages/vyos/ifconfig/interface.py", line 552, in set_netns
self.set_interface('netns', netns)
File "/usr/lib/python3/dist-packages/vyos/ifconfig/control.py", line 183, in set_interface
return self._set_command(self.config, name, value)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/ifconfig/control.py", line 110, in _set_command
return self._command_set[name].get('format', lambda _: _)(self._cmd(cmd))
^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/ifconfig/control.py", line 52, in _cmd
return cmd(command, self.debug)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/vyos/util.py", line 161, in cmd
raise OSError(code, feedback)
PermissionError: [Errno 1] failed to run command: ip link set dev veth100 netns ns01
returned:
exit code: 1
noteworthy:
cmd 'ip link set dev veth100 netns ns01'
returned (out):
returned (err):
Cannot find device "veth100"
This reverts commit f5cc8453860568351cd9b3b7a05d06e1462460e8.
|
|
There is no need for the backend code to call ethtool and try to change speed or
duplex settings every time there is a change in the interface configuration,
but no change for the speed/duplex subnodes. This also makes the commit itself
faster when working with ethernet interfaces.
Bonus: no repeating CLI messages that the driver does not support speed/duplex
changes, as we do not change anything here.
Extension to commit f2ecc9710 ("ethernet: T3891: honor auto-negotiation support
per NIC")
|
|
This reverts commit dd59e375bee722c220c58b047ff5c6e533cc7a00.
|
|
vrrp: T5215: fix the commit error when health check is not configured
|
|
|
|
that was replaced with Humps in all sciprts
|
|
vyos.utils.dict.check_mutually_exclusive_options
on missing options error
|
|
|
|
veth: T3829: Allow moving veth into netns
|
|
This makes netns infinitely more useful as they can be chained together
in many ways to build complex network structures all on the host.
Signed-off-by: Joe Groocock <me@frebib.net>
|
|
vyos.utils: T5195: add vyos.utils.file
|
|
vyos.utils: T5195: add vyos.utils.convert
|
|
vyos.utils: T5195: add vyos.utils.io
|
|
|
|
|
|
|
|
|
|
Commit f2ecc9710d49 ("ethernet: T3891: honor auto-negotiation support per NIC")
added an if statement that always evaluated to True.
|
|
Not all drivers/NICs or combination of NIC + transceiver support auto-
negotiation. The current auto-negotiation capability is evaluated and taken
into account when applying spped/duplex settings. If auto-negotiation is
not supported - we skip the setting to avoid errors during configuration.
|
