| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
set interfaces vxlan vxlan0 parameters ip df <set|unset|inherit>
set interfaces geneve gnv0 parameters ip df <set|unset|inherit>
|
|
|
|
|
|
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
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VXLAN does support using multiple remotes but VyOS does not. Add the ability
to set multiple remotes and add their flood lists using "bridge" command.
|
|
In the past whenever a change happened to any interface and it was configured
as a DHCP client, VyOS always had a breif outage as DHCP released the old lease
and re-aquired a new one - bad!
This commit changes the behavior that DHCP client is only restarted if any one
of the possible options one can set for DHCP client under the "dhcp-options"
node is altered.
|
|
VLAN isolation can not be "set" when interface is of type wifi.
|
|
Ability to see interface type "input" ifbX from op-mode
|
|
* 'firewall' of https://github.com/sarthurdev/vyos-1x:
zone_policy: T3873: Implement intra-zone-filtering
policy: T2199: Migrate policy route op-mode to XML/Python
policy: T2199: Migrate policy route to XML/Python
zone-policy: T2199: Migrate zone-policy op-mode to XML/Python
zone-policy: T2199: Migrate zone-policy to XML/Python
firewall: T2199: Migrate firewall op-mode to XML/Python
firewall: T2199: Migrate firewall to XML/Python
|
|
Traffic-policy rules are generated by old Perl code
This commit prevents to unexpected override this code by python.
|
|
|
|
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
|
|
|
|
netns: T3829: Ability to configure network namespaces
|
|
to avoid confusing 'v' in GENEVE interface prefix ('gnv')
with a "vXXX" part of a VRRP interface
|
|
|
|
|
|
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)
|
|
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.
|
|
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)
|
|
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.
|
|
|
|
Move keepalived configuration from /etc/keepalived to /run/keepalived.
|
|
|
|
Commit b7d30137b1 ("vyos.ifconfig: provide generic get_mac_synthetic() method")
provided a common helper to generate MAC addresses used by EUI64 addresses for
interfaces not having a layer2 interface (WireGuard or ip tunnel).
The problem is that every call to the helper always yielded a new MAC address.
This becomes problematic when IPv6 link-local addresses are generated and
modified on the interface as multiple link-local (fe80::/64) addresses can
easily be added to the interface leaving ... a mess.
This commit changes the way how the "synthetic" MAC is generated, we generate a
UUID which is stable as it is based on the interface name. We take out the last
48 bits of the UUID and form the "MAC" address.
|
|
When IPv6 is disbaled on an interface also the sysfs files related to IPv6 for
this interface vanish. We need to check if the file exists before we read it.
|
|
When using VRRP on any given interface and performing an action against that
interface - be it even only changing the alias - will trigger a removal of the
VRRP IP address.
The issue is caused by:
# determine IP addresses which are assigned to the interface and build a
# list of addresses which are no longer in the dict so they can be removed
cur_addr = self.get_addr()
for addr in list_diff(cur_addr, new_addr):
When the script calls into the library - we will drop all IP addresses set on
the adapter but not available in the config dict.
We should only remove the IP addresses marked by the CLI to be deleted!
|
|
There is no need to alter interface parameters if they have not changed at all.
|
|
The key defaults to 0 and will match any policies which similarly do not have
a lookup key configuration. This means that a vti0 named interface will pull in
all traffic and others will stop working. Thus we simply shift the key by one
to also support a vti0 interface.
|
