Age | Commit message (Collapse) | Author |
|
|
|
Background information [1]. Specifies whether an external control plane
(e.g. ip route encap/EVPN) or the internal FDB should be used.
[1]: https://legacy.netdevconf.info/2.2/slides/prabhu-linuxbridge-tutorial.pdf
|
|
|
|
Commit ee80d0aebd ("vyos.ifconfig: T2738: do not remove OS assigned IP
addresses from interface") addressed an issue with IP addresses added to
interfaces by daemons and not by the CLI. The solution in this commit for IP
address removal unfortunately did not cover VLAN (802.1q and 802.1ad) IP address
removal in the same way as it is done for non VLAN interfaces. The code was
missing.
(cherry picked from commit 91898b8bd876af6b4d7fae54981e78400f57e008)
|
|
T562: Config syntax for defining DNS forward authoritative zones
|
|
|
|
|
|
pppoe-server: T3006: Add range to regex generator
|
|
|
|
netns: T3829: Ability to configure network namespaces
|
|
|
|
to avoid confusing 'v' in GENEVE interface prefix ('gnv')
with a "vXXX" part of a VRRP interface
|
|
remote: T4037: Follow HTTP redirects
|
|
|
|
|
|
|
|
T3753 - CLI adjustments for FRR8.1
|
|
As a result to some frr-reload bugs workarounded in commit 3800ea91 or fe0038c2
this commit adds the workaround in general.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Interface will still be visible to the operating system.
|
|
Improve commend in WWANIf.remove() - remove() was implemented in commit d588a968
("wwan: T3620: place interface in A/D state when removed").
|
|
(cherry picked from commit 61e4d75abb1129f63df5a47b9c9bf0553850d893)
|
|
interfaces
(cherry picked from commit a032d73f1d405f3bae269791e9064026faa491d9)
|
|
pki: T3970: Allow op-mode PKI commands in a config session to install directly
|
|
|
|
This fixes an indention bug and a wrong if-statememnt from commit 05aa22dc
("protocols: static: T3680: do not delete DHCP received routes")
|
|
|
|
An ISC DHCP hook script is used to install the received default route into FRR
by simple calls to vtysh. By moving to frr-reload.py the DHCP default route
was deleted as it was not found in the running config.
This commit checks all interfaces if DHCP is enabled and if so - will dynamically
add the route to the generated FRR configuration.
|
|
Generic get_removed_vlans() function replaced the entire config dict when any
QinQ vif-c subinterface was deleted.
|
|
(cherry picked from commit 01ed77040ec9493e4ca1cf868ff3c22847da4487)
|
|
There are not any reason to enable only DHCP or only static address
on interface at the same time
It is possible to have both.
|
|
T3937: rewrite the "show system memory" script in Python
|
|
In addition to commit 0b414bcd ("vyos.ethtool: T3874: do not throw exception
if adapter has issues with autoneg") we should also not care too strict when
locating the driver name.
This might cause false positives.
|
|
|
|
(cherry picked from commit c1015d8ce0013719eb898b60b14ffec192b8141c)
|
|
|
|
It makes less to zero sense to blend in the default values of an interface when
it is about to be deleted from the system anyways - this makes the entire dict
just cleaner and easier to debug.
|
|
It seems not all systems have eth0 - get a list of all available Ethernet
interfaces on the system (without VLAN subinterfaces) and then take the
first one.
|
|
We can not pass None as VRF name, this raises an exception.
OSError: [Errno 255] failed to run command: ip link set dev eth2 master None
(cherry picked from commit e687502b1cf4a3e15c562a3662afcbe0776b1fe7)
|
|
Instead of throwing an exception when an adapters autoneg capabilities can not
be detected, just pretend it does not support autoneg.
|
|
|
|
Commit 081e23996f (vyos.ifconfig: get_mac_synthetic() must generate a stable
"MAC") calculated a "stable" synthetic MAC address per the interface based on
UUID and the interface name. The problem is that this calculation is too stable
when run on multiple instances of VyOS on different hosts/hypervisors.
Having R1 and R2 setup a connection both via "tun10" interface will become the
same "synthetic" MAC address manifesting in the same link-local IPv6 address.
This e.g. breaks OSPFv3 badly as both neighbors communicate using the same
link-local address.
As workaround one can:
set interfaces tunnel tun1337 address 'fe80::1:1337/64'
set interfaces tunnel tun1337 ipv6 address no-default-link-local
This commit changes the way in how the synthetic MAC address is generated. It's
based on the first 48 bits of a sha256 sum build from a CPU ID retrieved via
DMI, the MAC address of eth0 and the interface name as used before. This should
add enough entropy to get a stable pseudo MAC address.
|
|
|
|
Commit dd2eb5e5686655 ("dhcp: T3300: add DHCP default route distance") changed
the logic on how the DHCP process is going to be started. The systemd unit was
always "started" even if it was already running. It should rather be re-started
to track changes in e.g. the DHCP hostname setting.
|
|
|