Age | Commit message (Collapse) | Author |
|
* container: T6219: Add support for container sysctl / kernel parameters
(cherry picked from commit 717ea64e4c54a8be619ffc29c16c6203b29319dd)
* T6219: align with system sysctl and limit parameters to supported
(cherry picked from commit f030464952168b553b5b3e29b461d437c2642a9b)
---------
Co-authored-by: Ben Pilgrim <ben@pilgrim.me.uk>
Co-authored-by: Nicolas Vollmar <nvollmar@gmail.com>
|
|
>=5.0
random - In kernel 5.0 and newer this is the same as fully-random. In earlier
kernels the port mapping will be randomized using a seeded MD5 hash mix using
source and destination address and destination port.
https://git.netfilter.org/nftables/commit/?id=fbe27464dee4588d906492749251454
(cherry picked from commit 7fe568ca1672f1dfbd2b56ee3ef7a6ab48b03070)
|
|
(cherry picked from commit f5051de4fc034bd95677ef142423e59eae47cd2f)
|
|
ipoe: T6205: error in migration script logic while renaming mac-address to mac node (backport #3263)
|
|
Containers have the ability to add Linux system capabilities to them, this is
done using the "set container name <name> cap-add" command.
The CLI node sounds off and rather should be "set container name <name>
capability" instead as we use and pass a capability to a container and not
add/invent new ones.
(cherry picked from commit b30faa43c28b592febd83a7fd3a58247de6b27bc)
|
|
mac node
The problem was introduced in [1] but the config migrator part unfortunately
was added to the wrong version [2]. As IPoE config version 0 was only active
during the 1.3 development cycle and VyOS 1.3.0 was already released with config
version 1 we can safely drop the migrator 0-to-1 and move the code to 1-to-2 to
properly support upgrades from VyOS 1.3 -> 1.4 or newer.
1: https://github.com/vyos/vyos-1x/commit/05df2a5f021f0c7aab7c06db645d210858b6e98d#diff-08291bf77870abe3af8bbe3e8ce4bbf344fd0498b2c5c75a75aa7235d381c88eL168
2: https://github.com/vyos/vyos-1x/commit/05df2a5f021f0c7aab7c06db645d210858b6e98d#diff-b8bb58b75607d3653e74d82eff02442f9f3ab82698f160ba37858f7cdf6c79ccR44-R46
(cherry picked from commit a5ccc06c08d3a9696f1c03c8d0c7de78ce1fd3c5)
|
|
The option "passive-interface default" was set even if it was not present in
the previous version we are migrating from. Fix migration script to handle this
with a conditional path.
(cherry picked from commit ef8d9a73335bc685084e3ff97238836e452dfa8c)
|
|
(cherry picked from commit 259ef4740413b39da9b122db19c549eeec88114c)
|
|
|
|
|
|
EDB should be EGP for exterior gateway protocol
(cherry picked from commit 56654191613113764415d7eddadcbd8c97e126de)
|
|
(cherry picked from commit 354603398b693af06695d5d1a7602f17079f8350)
|
|
(cherry picked from commit 3bfbbef22954488541abd3cad262b1e196d4c240)
|
|
(cherry picked from commit 4d76e9ef3e7773ed96c037108021c292675b101c)
|
|
Migrate "bgp <ASN> neighbor <NEIGH> address-family ipv6-unicast peer-group"
to "bgp neighbor <NEIGH> peer-group"
(cherry picked from commit 9febed1344e93815dc3a94047daa69967c3af160)
|
|
(cherry picked from commit 495c3c3cc646c378746dc458f30da72c85f16dba)
|
|
We have not seen the adoption of the https virtual-host CLI option.
What it did?
* Create multiple webservers each listening on a different IP/port
(but in the same VRF)
* All webservers shared one common document root
* All webservers shared the same SSL certificates
* All webservers could have had individual allow-client configurations
* API could be enabled for a particular virtual-host but was always enabled on
the default host
This configuration tried to provide a full webserver via the CLI but VyOS is a
router and the Webserver is there for an API or to serve files for a local-ui.
Changes
Remove support for virtual-hosts as it's an incomplete and thus mostly useless
"thing". Migrate all allow-client statements to one top-level allow statement.
(cherry picked from commit d0d3071e99eb65edb888c26ef2fdc9e038438887)
|
|
(cherry picked from commit b0d0ac4a822b36e4f0cfae82db06ee71581de51f)
|
|
(cherry picked from commit a9201e77110ce0695e2ba879304aef41b7ac9a0c)
|
|
|
|
This complements commit f5e43b136 ("http: T5762: api: make API socket backend
communication the one and only default") so we have a consistent port CLI node
across VyOS components.
(cherry picked from commit 0e885f1bf01424130b6876e769cc42612b19351b)
|
|
Why: Smoketests fail as they can not establish IPv6 connection to uvicorn
backend server.
https://github.com/vyos/vyos-1x/pull/2481 added a bunch of new smoketests.
While debugging those failing, it was uncovered, that uvicorn only listens on
IPv4 connections
vyos@vyos# netstat -tulnp | grep 8080
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN -
As the CLI already has an option to move the API communication from an IP to a
UNIX domain socket, the best idea is to make this the default way of
communication, as we never directly talk to the API server but rather use the
NGINX reverse proxy.
(cherry picked from commit f5e43b1361fb59a9c260739bdb28729d5119507c)
|
|
IGMP and PIM are two different but related things.
FRR has both combined in pimd. As we use get_config_dict() and FRR reload it
is better to have both centrally stored under the same CLI node (as FRR does,
too) to just "fire and forget" the commit to the daemon.
"set protocols igmp interface eth1" -> "set protocols pim interface eth1 igmp"
(cherry picked from commit bc83fb097719f5c4c803808572f690fbc367b9e5)
|
|
Currently VyOS VXLAN implementation uses the Linux assigned port 8472 that
predates the IANA assignment. As Most other vendors use the IANA assigned port,
follow this guideline and use the new default port 4789.
Existing configuration not defining an explicit port number will be migrated
to the old default port number of 8472, keeping existing configurations work!
(cherry picked from commit 6db8d3ded19f652b99231be0d705d76b598ac72a)
# Conflicts:
# interface-definitions/include/version/interfaces-version.xml.i
|
|
|
|
|
|
|
|
|
|
Commit 0a802d20c - ("smoketest: add config with VRF BGP instance") added a
config from a VMware VM. When moving to QEmu we must reduce the network card
ring-bufer size from 4096 -> 256, as the tests failed with:
> Driver only supports a maximum RX ring-buffer size of "256" bytes!
|
|
Replica of a real network. BGP is realised inside a VRF. The BGP peering to the
outside world is done via WireGuard that is backed by a PPPoE link - shiver!
|
|
|
|
tc acccepts the bandwidth value/unit pairs as lowercase - so does the VyOS CLI
validator work, too.
|
|
|
|
|
|
|
|
qos config migration is tested using qos-basic example config file.
|
|
|
|
|
|
|
|
In addition to the rewrite to make use of get_config_dict() the CLI is
slightly adjusted as specified in T4703.
* Rename vlan-id and vlan-range to simply vlan
* Rename network-mode to simply mode
* Re-use existing common Jinja2 template for Accel-PPP which are shared
with PPPoE and SSTP server.
* Retrieve default values via defaultValue XML node
|
|
The initial Accel-PPP PPPoE implementation used:
set service pppoe-server interface <name> vlan-id <id>
set service pppoe-server interface <name> vlan-range <start-stop>
This is actually a duplicated CLI node.
|
|
|
|
|
|
|
|
This reverts commit fa91f567b7b5f009aaaed569b3f5e5db4b638d39.
|
|
This reverts commit c2fc87c02dd556dd1569ff2fd81c9e2485a80459.
|
|
HTTP and sstp cannot work together and in the test config
1.4-rolling-202106290839 we didnot have configurable port for
such services
So we shoud delete sstp from this smoketest config test
In fact it is never working at all 'smoketest/configs/pki-misc'
It commits without errors before but in the real life we get 3
services (https openconnect sstp) that bound the same port
|
|
Change openconnect port as both ocserv and sstp bind
by default the same port 443
|
|
After discussion with @zsdc this was decided the better long term fix
* Removes hourly logrotate cron in favour of systemd timer override
|
|
|