| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It is not possible to change the VLAN encapsulation protocol "on-the-fly". For
this "quirk" we need to actively delete and re-create the VIF-S interface.
|
|
|
|
|
|
Removing a VLAN (VIF) interface from the CLI always deleted all interfaces the
kernel listed as "upper" in the /sys/class/net folder. This had the drawback
that when deleting a VIF, also the VRF interface was simply deleted - killing
all VRF related services.
|
|
Private VLAN, also known as port isolation, is a technique in computer
networking where a VLAN contains switch ports that are restricted such that
they can only communicate with a given "uplink". The restricted ports are
called "private ports".
Each private VLAN typically contains many private ports, and a single uplink.
The uplink will typically be a port (or link aggregation group) connected to a
router, firewall, server, provider network, or similar central resource.
Q: https://en.wikipedia.org/wiki/Private_VLAN
|
|
dhcp: T3300: add DHCP default route distance
|
|
When a VIF/VLAN interface is placed in admin down state but the lower
interface, serving the vlan, is moved from admin down -> admin up, all its
vlan interfaces will be placed in admin up state, too.
This is bad as a VLAN interface will become admin up even if its specified as
admin down after a reboot.
To reproduce:
set interfaces ethernet eth1 vif 20 disable
set interfaces ethernet eth1 disable
commit
delete interfaces ethernet eth1 disable
commit
Now check the interface state and it returns UP,LOWER_UP
7: eth1.20@eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:50:56:b3:09:07 brd ff:ff:ff:ff:ff:ff
inet6 fe80::250:56ff:feb3:907/64 scope link
valid_lft forever preferred_lft forever
|
|
Interface.get_config() was always a pure helper which exposed a "per interface
type" dictionary which was then fed by the caller to create interfaces by
iproute2 which required additional options during creation time.
Such interfaces had been:
* tunnel
* vxlan
* geneve
* macsec
* wifi
* macvlan / pseudo-ethernet
The code was always duplicated to convert from the VyOS CLI based get_config_dict()
to a dict which can be used to feed iproute2.
This path has been removed and we now always feed in the entire dictionary
retrieved by get_config_dict() or in the interfaces case, it's high-level wrapper
get_interface_dict() to the interface we wan't to create.
This also adds the - personally long awaited - possibility to get rid of the
derived tunnel classes for e.g. GRE, IPIP, IPIP6 and so on.
|
|
|
|
|
|
|
|
If dhcpv6-options is configured without requesting a DHCPv6 address or PD, the
dhcpv6pd variable is assigned an empty dict.
|
|
|
|
|
|
|
|
equipment
According to the consensus, the specific behavior of a VLAN aware bridge should conform
to the behavior of professional equipment. This commit makes a significant change to the
behavior of VLAN aware bridge, and has the following behaviors:
1. Disable `vif 1` configuration
2. When the VLAN aware bridge is enabled, the parent interface is always VLAN 1
3. When `native-vlan` is not configured, the default behavior of the device is `native-vlan 1`
4. The VLAN ids forwarded by the bridge are determined by `vif`
5. It has an `enable-vlan` node to enable VLAN awareness
6. VLAN configuration is allowed only when VLAN aware bridge is activated
|
|
After switching to iproute2 in commit 92f36735 ("ifconfig: T2653: use iproute2
commands for alias, mac and mtu set()/get()" it is necessary to return an empty
string as iproute2 returns None.
|
|
|
|
|
|
|
|
- remove redundant code paths apply_mirror() / apply_mirror_of_monitor()
- have single source available
|
|
is wrong
In e8957b5, we used json to parse the `tc qdisc` filter to determine whether it needs
to be deleted (reduction of exception mechanism), but now we find that the json output
by this command will output unparsed json in some cases,
so We have to go back to the processing of the exception mechanism
|
|
|
|
This reverts commit 9541355433e202fade4692851bffa33ba9d48f44.
|
|
|
|
|
|
Since the dependency problem has not been solved before,
if the monitoring interface does not exist when the
mirror rule is created, the execution will be abnormal
|
|
setting and streamline the code
|
|
|
|
of `bridge` should not be overwritten
|
|
`vlan_filter` to avoid redundant paths
|
|
|
|
|
|
mirror: T3089: support two-way traffic mirroring
|
|
|
|
This is the second attempt after commit d247736f ("vyos.ifconfig: T1579: do not
remove IPv6 link-local address on reconfiguration"). We only clean out link-local
IPv6 addresses left over after an interface MAC change.
|
|
reconfiguration"
This reverts commit d247736f67cc056062b75a4215a031bebcfee2ee.
We need to clean link-local IPv6 addresses on link reconfiguration to also drop
no longer existing link-local addresse son MAC address change.
|
|
|
|
vyatta-cfg-quagga
|
|
|
|
|
|
The MAC address is changed after we have set an IP address on the interface or
started dhclient. This will cause some users to receive the wrong IP address
on device startup.
Change to order of how parameters are set in the system. The interface MAC
address is now configured first.
|
|
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.
|
|
Renamed using snippet below:
----------------------------
for file in $(find . -name "*.py")
do
sed -i "s/vyos_dict_search/dict_search/" $file
done
|
|
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.
|
|
|
|
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.
|
|
|
