| Age | Commit message (Collapse) | Author |
|---|
|
If ethernet interface is a bond memeber:
1. Allow for changing only specific parameters which are specified
in EthernetIf.get_bond_member_allowed_options function.
2. Added inheritable parameters from bond interface to ethernet
interface which are scpecified
in BondIf.get_inherit_bond_options.
Users can change inheritable options under ethernet interface
but in commit it will be copied from bond interface.
3. All other parameters are denied for changing.
Added migration script. It deletes all denied parameters under
ethernet interface if it is a bond member.
|
|
|
|
T5427: Fix migration script arguments len expects 2 args
|
|
Disabeled adding the peer with the same public key as the router has.
Added smoketest
|
|
The script's name is always provided as the first argument sys.argv[0]
Expected length for argv is 2 (script itself + config file)
Change: 'if (len(argv) < 1)' to 'if len(argv) < 2'
|
|
* T5195: move run, cmd, call, rc_cmd helper to vyos.utils.process
* T5195: use read_file and write_file implementation from vyos.utils.file
Changed code automatically using:
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import read_file$/from vyos.utils.file import read_file/g' {} +
find . -type f -not -path '*/\.*' -exec sed -i 's/^from vyos.util import write_file$/from vyos.utils.file import write_file/g' {} +
* T5195: move chmod* helpers to vyos.utils.permission
* T5195: use colon_separated_to_dict from vyos.utils.dict
* T5195: move is_systemd_service_* to vyos.utils.process
* T5195: fix boot issues with missing imports
* T5195: move dict_search_* helpers to vyos.utils.dict
* T5195: move network helpers to vyos.utils.network
* T5195: move commit_* helpers to vyos.utils.commit
* T5195: move user I/O helpers to vyos.utils.io
|
|
... this is a step towards a new and better implementation that will utilize
VPP.
|
|
Tunnel interface multicast settings can be "enabled or disabled". As we prefer
valueless nodes, and the linux kernel default is "disabled" we should add a
set interfaces tunnel tunXX enable-multicast
command
|
|
Replace links to the phabricator site from https://phabricator.vyos.net to
https://vyos.dev
|
|
sstp-client
|
|
* Also determines and maps to correct CA for migrated CRL
|
|
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.
|
|
This reverts commit 29efbf51efea559773f61703f11a77a8aee6de36.
|
|
This reverts commit 391ce22b76190309f81e048ebffab778b0fdee1d.
|
|
|
|
Migrating 1.2.8 -> 1.4-rolling-202201110811
vyos-router[970]: Waiting for NICs to settle down: settled in 0sec..
vyos-router[1085]: Started watchfrr.
vyos-router[970]: Mounting VyOS Config...done.
vyos-router[970]: Starting VyOS router: migrate
vyos-router[1490]: Traceback (most recent call last):
vyos-router[1490]: File "/opt/vyatta/etc/config-migrate/migrate/interfaces/5-to-6", line 112, in <module>
vyos-router[1490]: for if_type in config.list_nodes(['interfaces']):
vyos-router[1490]: File "/usr/lib/python3/dist-packages/vyos/configtree.py", line 236, in list_nodes
vyos-router[1490]: raise ConfigTreeError("Path [{}] doesn't exist".format(path_str))
vyos-router[1490]: vyos.configtree.ConfigTreeError: Path [b'interfaces'] doesn't exist
vyos-router[1455]: Migration script error: /opt/vyatta/etc/config-migrate/migrate/interfaces/5-to-6: Command
'['/opt/vyatta/etc/config-migrate/migrate/interfaces/5-to-6', '/opt/vyatta/etc/config/config.boot']'
returned non-zero exit status 1..
vyos-router[970]: configure.
vyos-config[979]: Configuration success
|
|
(cherry picked from commit c1015d8ce0013719eb898b60b14ffec192b8141c)
|
|
Required for the dhcp-interface migration
|
|
It makes no sense to have a parser for the ethtool values in ethtool.py
and ethernet.py - one instance ios more then enough!
|
|
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.
|
|
Deprecated in the Linux Kernel by commit 08a00fea6de277df12ccfadc21 ("net:
Remove references to NETIF_F_UFO from ethtool.").
(cherry picked from commit f5e46ee6cc2b6c1c1869e26beca4ccd5bf52b62f)
|
|
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.
(cherry picked from commit a515212f4efb08846df04405f31a828edcd63552)
|
|
VyOS 1.4 already had a migrator for interfaces 20 -> 21, but this is a different
one compared to the one in VyOS 1.3 - thus we bump every migration scripts
version by one to have the same 20-to-21 converter in both VyOS 1.3 and 1.4.
This is possible as VyOS 1.4 (sagitta) is still a highly experimental version
and expected to break from time to time :(.
|
|
The migrator from 20-to-21 is required as 19-to-20 on VyOS 1.3 - thus simply
rename/reorder the two migrators to not break things the hard way when
upgrading from 1.3 -> 1.4.
|
|
|
|
|
|
|
|
Also renames peer pubkey to public-key for consistency
|
|
As the new WWAN interface style is backported to VyOS 1.3 we also need to shift
the order of the interface migration scripts. so the same order from VyOS 1.4
also applies to VyOS 1.3.
In short, 21-to-22 is renamed to 18-to-19 and all other migrators are shifted
up one version.
|
|
|
|
|
|
|
|
A VTI interface also requires an IPSec configuration - VyOS 1.2 supported
having a VTI interface in the CLI but no IPSec configuration - drop VTI
configuration if this is the case for VyOS 1.4.
|
|
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").
|
|
Co-authored-by: Mark Royds <mark.royds@vitaminit.co.uk>
|
|
Rename CLI options local-ip to source-address and remote-ip to remote to
get a consistent CLI experience for the user.
|
|
Streamline the CLI configuration where we try to use remote on other interfaces
like vxlan, geneve.
|
|
Streamline the CLI configuration where we try to use source-address when
creating connections which are especially sourced from a discrete address.
|
|
The following list shows the mapping of VyOS tunnel encapsulation modes to the
corresponding Linux modes.
VyOS Linux
gre gre
gre-bridge gretap
ipip ipip
ipip6 ipip6
ip6ip6 ip6ip6
ip6gre ip6gre
sit sit
Besides gre-bridge this is pretty consistent. As bridge interfaces are also
called tap interfaces gre-bridge will be renamed to gretap to make the
post-processing much easier.
This means (in detail) that there are no more child classes of _Tunnel and
there will be now one geneirc TunnelIf class handling all sorts of encapsulation.
|
|
|
|
|
|
|
|
When per interface OSPF configuration is migrated into "protocols ospf interface"
we should cleanup and empty ip {} node unter the individual interface. This
makes the config look more nicely.
|
|
|
|
interface"
For easier maintenance and operability move the interface specific protocol
setting of OSPF to the OSPF protocol section. This is now also in-line with IS-IS.
This means to migrate:
ethernet eth0 {
vif 202 {
ip {
ospf {
authentication {
md5 {
key-id 10 {
md5-key vyosvyos
}
}
}
dead-interval 40
hello-interval 10
priority 1
retransmit-interval 5
transmit-delay 1
}
}
}
}
to
protocols {
ospf {
interface eth0.201 {
authentication {
md5 {
key-id 10 {
md5-key vyosvyos
}
}
}
dead-interval 40
hello-interval 10
priority 1
retransmit-interval 5
transmit-delay 1
}
}
|
|
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!
|
