| Age | Commit message (Collapse) | Author |
|---|
|
This reverts commit 806f35b5856c3f8dae634718a6a9e82cc90bb63a.
Unfortunately this did not work our in the attempt to bridge a station to a
bridge "brX" interface. Also adjusting the wireless interface during operation
cause several exceptions and the feature is removed again as it was never in any
production system.
|
|
bridge: T3042: Better fix implementation errors
|
|
In #601, I provided a basic patch. Under this patch, I rely on vif to
detect the vlan id range that the bridge should flow through,
which may lead to greater redundancy in the configuration,
so I am considering detecting effective vlan filters In setting the range
of vlan id that is required to flow through the bridge,
I use set() to complete the deduplication of this vlan id
and set it to the bridge uniformly (at the same time,
I slightly modified the smoke test script)
|
|
Revert "T2802: Tunnel interface does not apply EUI-64 IPv6 Address"
|
|
|
|
interfaces"
|
|
Generate an IPv6 Link Local address for wireguard interfaces.
|
|
T3068: Automatic generation of IPv6 link local addresses for tunnel interfaces
|
|
|
|
We had two places were the is_ip, is_ipv4 and is_ipv6 helpers had been defined.
All places now have been converged into vyos.template as they are used both
in the Jinja2 templates and also in our scripts.
|
|
|
|
Better implementation to assign link local addresses automatically because address only assigned to interfaces which supports IPv6 addresses.
|
|
Tunnel interfaces hot having any IPv6 Link Local address because Linux Kernel does not assign address due to missing MAC. I have implemented a function to generate a linl local address and assign it to the interface. Link local address is required for OSPF and other protocols.
|
|
1. Due to the previous focus on the implementation of VLAN filter, it was not considered to include MTU settings, which will lead to MTU setting errors in some cases
2. In order to make VLAN aware of the work of the bridge, it is necessary to specify the allowed VLAN ID range for the bridge itself, and forget to join it before
|
|
|
|
|
|
|
|
|
|
Re-organize the template code and add addtitional Jinja2 filters for processing
the ifconfig-pool statement. This reverts the changes from commit 7e546be9
("openvpn: T2994: temporary revert to 1.2 crux behavior for client pools").
|
|
Remove workaround which split (local|remote)_address and also subnet keys into
individual keys for the assigned IP address family (4/6).
During template rendering check IP version by introducing new ipv4 and ipv6
Jinja2 filters {% if foo | ipv4 %} or {% if bar | ipv6 %} options.
|
|
|
|
|
|
|
|
Renamed using snippet below:
----------------------------
for file in $(find . -name "*.py")
do
sed -i "s/vyos_dict_search/dict_search/" $file
done
|
|
accel: T2631: Add option for radius disable-accounting
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The current wversion unfortunately will raise a KeyError:
>>> data = {}
>>> vyos_dict_search('foo', data)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3/dist-packages/vyos/util.py", line 685, in vyos_dict_search
return dict[path]
KeyError: 'foo'
|
|
almost every interface can be part of a bridge thus the code for changing STP
cost is best part of the Interface() base class itself.
Commit b5ef10cf ("ifconfig: T2985: support on demand bridge creation")
implemented this change but the STP file was not removed on the test devices
causing tests to pass.
|
|
The current implementation for bridge based interfaces has an issue which is
caused by priority inheritance. We always assumed that the bridge interface will
be created last, but this may not be true in all cases, where some interfaces
will be created "on demand" - e.g. OpenVPN or late (VXLAN, GENEVE).
As we already have a bunch of verify steps in place we should not see a bridge
interface leak to the underlaying infrastructure code. This means, whenever an
interface will be member of a bridge, and the bridge does yet not exist, we will
create it in advance in the interface context, as the bridge code will be run
in the same commit but maybe sooner or later.
This will also be the solution for T2924.
|
|
|
|
We must use XML node style (hyphen over underscore).
|
|
Commit 5db3d631 ("ifconfig: mtu: disallow MTU < 1280 bytes when IPv6 is enabled
on the interface") checked the "mtu" key for it's value and the test only passed
if mtu was larger then the required 1280 bytes when IPv6 address have
been configured on the link.
wireless (WiFi) interfaces have no MTU node - thus this always resulted in a
Python KeyError.
|
|
|
|
Sometimes (PPPoE server is one of them) a simple defaultValue in the XML is not
enough - several values should be set. In order to support a list of
defaultValues you can now simply list them as a whitespace separated string.
Example:
<defaultValue>pap chap mschap mschap-v2</defaultValue>
will generate a Python list ['pap', 'chap', 'mschap', 'mschap-v2'] when
retrieved by vyos.xml.defaults()
|
|
Every interface knows if it is part of a bridge or not - except a VLAN (VIF)
interface. Also VLANs should be aware of its master bridge.
Add a testcase to ensure when VIFs on an interface change the bridge does not
loos one of it's members.
|
|
We must use exists() as get_config_dict() will always return {} - even when an
empty interface node like
+macsec macsec1 {
+}
exists.
|
|
Using an MTU less then the required 1280 bytes (as per RFC) on an interface
where IPv6 is not explicitly disabled by:
- set interfaces ethernet eth1 ipv6 address no-default-link-local
- not having any other IPv6 address configured
Will now trigger a commit error via verify() instead of raising
FileNotFoundError!
|
|
Currently the MTU size of an interface is only checked when entered via CLI but
if the interface supportes the configured MTU at all is not verified at all.
New helper functions get_min_mtu(), get_max_mtu() and verify_mtu() have been
added to provide a central API for validation.
|
|
|
|
>>> from vyos.ifconfig import Interface
>>> tmp=Interface('eth0')
>>> tmp.get_min_mtu()
60
>>> tmp.get_max_mtu()
9000
|
|
When configuring DHCPv6-PD it is mandatory to also specify at least one
interface where the newly delegated prefix will be used. Without this setting
DHCPv6-PD makes no sense at all.
|
|
|
|
As we already check that a bond/bridge member interface is not a member of any
other bridge or bond, the check must be extended. We also need to ensure that
the bond member interface is not used as a source-interface to pppoe, macsec,
tunnel, pseudo-ethernet, vxlan interfaces.
|
|
|
|
When removing e.g. a macsec interface and also its associated member interface
from the bridge, it will happen that the macsec interface instance is long gone
before we reach the code in the bridge interface which will remove it from the
bridge itself.
When this is the case, we can not call BridgeIf.del_port() as it will throw an
exception that the interface does not exist. We now only remove a bridge member
if the interface in question is still available in the kernel.
|
