| Age | Commit message (Collapse) | Author |
|---|
|
new CLI
|
|
|
|
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.
|
|
(cherry picked from commit 32822d5e1831dff5cd904c0cb5886f7d737afab6)
|
|
|
|
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
}
}
|
|
This commit provides the implementation of the OSPF CLI with a Jinja2 template
that is loaded by FRR reload.
|
|
|
|
|
|
|
|
|
|
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
|
|
When the 'powersave' option under 'system console' was defined but no actual
serial console device this cause the following error during migration:
Loading configuration from 'config.boot'
Traceback (most recent call last):
File "/opt/vyatta/etc/config-migrate/migrate/system/16-to-17", line 45, in <module>
for device in config.list_nodes(base + ['device']):
File "/usr/lib/python3/dist-packages/vyos/configtree.py", line 236, in list_nodes
raise ConfigTreeError("Path [{}] doesn't exist".format(path_str))
vyos.configtree.ConfigTreeError: Path [b'system console device'] doesn't exist
|
|
Boolean nodes have been removed b/c a boolean value makes less sense. The same
behavior can be achieved with the presence or absence of a node. Unfortunately
the 'autonomous-flag' node has been a negated one which did not migrate
it to 'no-autonomous-flag' if it was set to false previously.
|
|
Add new nodes for 'service dns forwarding domain':
'addnta': adds addNTA to lua-config-file
'recursion-desired': sets '+' before the zone in forward-zones-file
The migrator sets both options for all configured domains. This is
usually the desired config.
|
|
The previous implementation only supported disabling DHCP nameservers for
all interfaces, and was implemented improperly so it didn't work anyway.
This migrates it to name-servers-dhcp <interface>, which allows us to enable
just the interfaces we want to use for system DNS, identical in syntax to
'service dns forwarding dhcp <interface>'.
The migrator searches through all interfaces that have address 'dhcp(v6)?'
and adds them to the name-servers-dhcp list if disable-dhcp-nameservers is
not set, else it does nothing.
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
|
|
Support for Hayes modems has been long gone (1.2.x) and nobody cared. It was
removed in commit d582bbaf3 ("update console settings for systemd") of
vyatta-cfg-system.
So as there have been zero complaints - cleanup the CLI.
|
|
The current implementation only works once the system has been fully booted
up and the config nodes have been process. So there is no "early" kernel
debugging. It is started with priority 400 (after all network stuff) - thus it
has a questionable at all for Kernel debugging.
It would only make sense if the entire system is changed to supply the config
stuff to the Kernel commandline and then send it to a dedicated MAC address
target as network will be initialized late.
As there are zero Phabricator tasks available and we do not know any user using
this - the "feature" will be removed.
|
|
During testing it was discovered that there is a well known problem (we had for
ethernet interfaces) also in the serial port world. They will be enumerated and
mapped to /dev/ttyUSBxxx differently from boot to boot. This is especially
painful on my development APU4 board which also has a Sierra Wireless MC7710
LTE module installed.
The serial port will toggle between ttyUSB2 and ttyUSB5 depending on the
amount of serial port extenders attached (FT4232H).
The shipped udev rule (/usr/lib/udev/rules.d/60-serial.rules) partly solves
this by enumerating the devices into /dev/serial/by-id folder with their name
and serial number - it's a very good idea but I've found that not all of the
FT4232H dongles have a serial number programmed - this leads to the situation
that when you plug in two cables with both having serial number 0 - only one
device symlink will appear - the previous one is always overwritten by the
latter one.
Derive /usr/lib/udev/rules.d/60-serial.rules and create a /dev/serial/by-bus
directory and group devices by attached USB root port.
vyos@vyos:~$ find /dev/serial/by-bus/ -name usb* -exec basename {} \; | sort
usb0b1.3p1.0
usb0b1.3p1.2
usb0b1.3p1.3
usb0b2.4p1.0
usb0b2.4p1.1
usb0b2.4p1.2
usb0b2.4p1.3
So we have USB root 0 with bus 1.3 and port 1.0. The enumeration is constant
accross reboots.
|
|
|
