| Age | Commit message (Collapse) | Author |
|---|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
(cherry picked from commit 0229645c8248decb5664056df8aa5cd5dff41802)
|
|
Not all interface drivers have the ability to change the speed and duplex
settings. Known drivers with this limitation are vmxnet3, virtio_net and
xen_netfront. If this driver is detected, an error will be presented to the
user.
(cherry picked from commit cc742d48579e4f76e5d3230d87e22f71f76f9301)
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
|
|
An analysis of the code base from VyOS 1.2 -> 1.3 -> 1.4 revealed the following
"root-cause"
VyOS 1.2 uses the "old" node.def file format for:
* Generic Segmentation Offloading
* Generic Receive Offloading
So if any of the above settings is available on the configuration CLI, the
node.def file will be executed - this is how it works.
By default, this CLI option is not enabled in VyOS 1.2 - but the Linux Kernel
enables offloading "under the hood" by default for GRO, GSO... which will boost
the performance for users magically.
With the rewrite in VyOS 1.3 of all the interface related code T1579, and
especially T1637 this was moved to a new approach. There is now only one handler
script which is called whenever a user changes something under the interfaces
ethernet tree. The Full CLI configuration is assembled by get_interface_dict() -
a wrapper for get_config_dict() which abstracts and works for all of our
interface types - single source design.
The problem now comes into play when the gathered configuration is actually
written to the hardware, as there is no GSO, GRO or foo-offloading setting
defined - we behave as instructed and disable the offloading.
So the real bug originates from VyOS 1.2 and the old Vyatta codebase, but the
recent XML Python rewrites brought that one up to light.
Solution:
A configuration migration script will be provided starting with VyOS 1.3 which
will read in the CLI configuration of the ethernet interfaces and if not
enabled, will query the adapter if offloading is supported at all, and if so,
will enable the CLI nodes.
One might say that this will "blow" the CLI configuration but it only represents
the truth - which was masked in VyOS 1.2.
|
|
As IS-IS is a new feature and the CLI configuration changed from 1.3 -> 1.4
(required by T3417) it makes sense to synchronize the CLI configuration for
both versions. This means backporting the CLI from 1.4 -> 1.3 to not confuse
the userbase already with a brand new feature.
As 1.3.0-epa1 is on the way and should not contain any CLI changes afterwards,
this is the perfect time.
|
|
|
|
It is easier to backport the entire vyos.ifconfig library from 1.4 instead of
backporting single pieces which are required to add new feature to the tunnel
interface section.
In addition that both libraries are now back in sync it will become much easier
to backport any other new feature introduced in VyOS 1.4!
|
|
|
|
(cherry picked from commit e24e35e1ac11a0771b15417af191694fd0b88022)
|
|
(cherry picked from commit d20dd7a0e6af08a80c7c911e7b151f28e4666173)
|
|
(cherry picked from commit c2a1c071e7d0a9ca754d7f5016eed7db188b3d1a)
|
|
Commit c17f259d ("router-advert: T3561: add support for specific routes") used
tabs over spaces in the Migration script which triggered a TabError (inconsistent
use of tabs and spaces in indentation").
(cherry picked from commit acc701bac3483a3242c77a2e00c076890e27eea9)
|
|
Co-authored-by: Mark Royds <mark.royds@vitaminit.co.uk>
(cherry picked from commit c17f259d09abd2bf632d09400fe8deb4c2781d32)
|
|
(cherry picked from commit d96336a808e500934fc4fd9423345d0b965d35ac)
|
|
(cherry picked from commit 91130ca7c386ecba291694ff08e521438d352e78)
|
|
|
|
Commit 0f8beae7426 ("system: T2486: migrate disable-dhcp-nameservers to
name-servers-dhcp") added a migration script for moving the name-servers.
A small glitch was introduced when referencing vif-c interfaces unter a vif-s
interface where a variable got referenced which was not defined.
(cherry picked from commit 89108f629ec8cc6990473468c1c67ffa8742b884)
|
|
If the RPKI cache name equals the configured address, renaming is not possible,
as rename expects the new path to not exist.
(cherry picked from commit af2a22fb114b7d00f50fb32dc64b49e132ccca61)
|
|
|
|
(cherry picked from commit 32822d5e1831dff5cd904c0cb5886f7d737afab6)
|
|
Migrate from
ethernet eth1 {
offload-options {
generic-receive on
generic-segmentation on
scatter-gather on
tcp-segmentation on
udp-fragmentation on
}
}
to
ethernet eth1 {
offload {
ufo
tso
sg
gso
gro
}
}
|
|
|
|
|
|
|
|
IPv6 enable can be considered once the ipv6 node is present!
|
|
When VyOS boots the first time with the default configuration there it actually
no "interface ethernet" node present in the config, thus we must exit the
migrator.
Without this change vyos.configtree.ConfigTreeError: Path [b'interfaces ethernet']
doesn't exist will be thrown.
|
|
By design a CLI node should not be named by its plural but rather describe it
as singular.
|
|
After migrating the ethernet interfaces from the good old Perl days the
smp-affinity node yet has no effect anymore as the code is still missing (my
bad, sorry).
Drop the smp-affinity node and rather use tuned instead with the
network-throughput or network-latency profile.
- network-throughput: Profile for throughput network tuning. It is based on the
throughput-performance profile. It additionaly increases kernel network buffers.
- network-latency: Profile for low latency network tuning. It is based on the
latency-performance profile. It additionaly disables transparent hugepages,
NUMA balancing and tunes several other network related sysctl parameters.
I'd set network-throughput as the default on a new set system option performance
<throughput | latency> CLI node which is present in the default configuration.
https://access.redhat.com/sites/default/files/attachments/201501-perf-brief-low-latency-tuning-rhel7-v2.1.pdf
|
|
definition
|
|
|
|
As VyOS vrux (1.2.7) requires a mirgator (1-to-2) for the MPPE node change
(T2829) we need to shift all other migrators in 1.3 by one.
As migrators probe the existance of nodes no negative side-effects are
expected.
|
|
|
|
A test statement was still present in the production code introduced in commit
efeac80f8 ("pppoe-server: T2829: migrate 'ppp-options mppe' to leafNode").
This has been fixed.
|
|
Required to get a common CLI for all services provided by Accel-PPP. Once the
CLI for each service is consitent - Jinja2 templates can be reused together
with get_config_dict().
|
|
* move "network-settings gateway-address" to "gateway-address"
* move "network-settings client-ip-settings" to "client-ip-pool"
|
|
Preparation before using get_config_dict() and common Jinja2 templates.
|
|
In order to reuse as much as possible before migrationg to get_config_dict()
and re-use Jinja2 snippets the name-server node must be moved one level up to
'set vpn sstp name-server'.
|
|
|
|
|
|
|
|
|
|
Both PPPoE and WWAN interfaces are dialer interfaces handled by ppp, but use
different CLI nodes for the same functionality. PPPoE has "connect-on-demand"
to initiate an "on-demand" dialing and WWAN uses "ondemand" for this purpose.
Rename WWAN "ondemand" node to "connect-on-demand".
|
|
In the past we had to provide the ethertype value used for the VLAN
protocol (0x88A8 -> 802.1ad or 0x8100 -> 802.1q).
This should be changed to a more user friendly CLI node (protocol over
ethertype) and 802.1ad over it's raw value 0x88A8. There is no need in
presenting RAW information from the ethernet header to the user. Also iproute2
calls it protocol which makes way more sense over the "raw" value.
|
|
|
|
The current CLI did not support multiple prefix-delegations per interface. Some
ISPs only send one /64 to a client per prefix-delegation request, but they
allow the customer to request multiple prefixes.
The 'dhcpv6-options prefix-delegation' node has been renamed and converted to a
tag node named 'dhcpv6-options pd'. The tag node specifies a PD request (>=0).
In the past the user needed to know what prefix will be assigned and required
to calculate the sla-len by himself. The 'sla-len' node was dropped and is now
calculated in the background from the 'dhcpv6-options pd 0 length' node.
It is no longer mandatory to supply the 'sla-id' node, if sla-id is not
specified it is 'guessed' by counting upwards.
Example configuration:
----------------------
ethernet eth1 {
address dhcpv6
dhcpv6-options {
pd 0 {
length 56
interface eth2 {
address 1
}
}
}
}
This will request a /56 assignment from the ISP and will delegate a /64 network
to interface eth2. VyOS will use the interface address ::1 on the delegate
interface (eth2) as its local address.
|
|
Migration files on the storage should be done one time by a migration script
instead of every time the configuration changes. Moving this to an older
migration script is fine as this is around for a long time and all rolling
releases are already up2date. It only affects updates from VyOS 1.2 series.
|
|
As of now when adding new credentials for any SNMPv3 user we submit the
credential either plaintext or encrypted. A plaintext credential will be hashed
by SNMPd in the background and then passed back into the CLI so it's not stored
in cleartext. This feels like the wrong way in changing the CLI content with
data produced by a 3rd party daemon which implements the service.
It feels like the tail wiggles the entire dog.
This should be changed in the following way:
- After retrieving the plaintext password from CLI, use Python to hash the key
in advance
- Re-populate the encrypted key into the CLI and drop the plaintext one
- Generate service configuration and continue startup of SNMPd
This also fixes a race condition when SNMPd started up but not properly
provided the hasehd keys in the configuration resulting in a ConfigurationError.
Now as we also support binding SNMPd to a VRF this fixes a deadlock situation
on bootup as we can only bind late to the VRF and require up to 5 restarts of
the service - but the service will never start.
|
|
When migrating the conf from VyOS 1.2 to 1.3 a configuration error could appear
if the user specified "info" as loglevel instead of "INFO". There was no input
validation done in 1.2 but this is now enforced in 1.3.
In VyOS 1.3 loglevel will be always lowercase on the CLI and when migrating the
config this is transformed. Also VyOS 1.2 accpeted any arbitrary loglevel. If
an invalid loglevel is found it will be set to info.
|
|
By implementation misstake we exited the migrationscript if no VXLAN interface
was found but this was wrong as the same loop is used on pseudo-ethernet
interfaces. The Migrator previously only worked on pseudo-ethernet when
also a VXLAN interface was present. This has been corrected.
|
|
T2486: DNS, vyos-hostsd fixes
|
