Age | Commit message (Collapse) | Author |
|
This allows the operator to control the number of open file descriptors each
daemon is allowed to start with. The current assumed value on most operating
systems is 1024.
If the operator plans to run bgp with several thousands of peers then this is
where we would modify FRR to allow this to happen.
set system frr descriptors <n>
(cherry picked from commit 892c28ccf634173d4c4952c248cb03974c560793)
|
|
VyOS CLI
set protocols segment-routing srv6 locator bar prefix '2001:b::/64'
set protocols segment-routing srv6 locator foo behavior-usid
set protocols segment-routing srv6 locator foo prefix '2001:a::/64'
Will generate in FRR
segment-routing
srv6
locators
locator bar
prefix 2001:b::/64 block-len 40 node-len 24 func-bits 16
exit
!
locator foo
prefix 2001:a::/64 block-len 40 node-len 24 func-bits 16
behavior usid
exit
!
exit
!
exit
!
exit
(cherry picked from commit ca301cdd4746187f96ff84e411fda6a84e33f237)
|
|
set protocols bgp sid vpn per-vrf export '99'
set protocols bgp srv6 locator 'foo'
set protocols bgp system-as '100'
Will generate in FRR config
router bgp 100
no bgp ebgp-requires-policy
no bgp default ipv4-unicast
no bgp network import-check
!
segment-routing srv6
locator foo
exit
sid vpn per-vrf export 99
exit
(cherry picked from commit af46fe54e56cf85d13b62ee771bec3d80f225ac5)
|
|
and basic format
(cherry picked from commit 5acc655c316216122ba975f30df7b76f161cbf02)
|
|
configured. In this commit, check is fixed and rules are printed as expected.
(cherry picked from commit 3d3418d1585cbb6d3c2d1d81d310a3107e16c4aa)
|
|
PR https://github.com/vyos/vyos-1x/pull/2540 backported a migration script from
current to the equuleus LTS branch. As migration scripts are executed in order
to adjust the CLI for necessary improvements in future LTS releases we need to
change the versioning of the migration files to match the new "base" version
from the previous LTS release.
In theory this could break very ancient 1.4 rolling releases (from the early
days of the OSPF refactoring) - but those versions are considered very much
unstable.
Now this is the last chance to sync up the migration scripts before the 1.4 LTS
release.
(cherry picked from commit 98ca0984312257a09b57d4aac60ff4abf7f84e66)
|
|
Dynamic interfaces such as PPPoE/sstpc can not exist during
verification dns dynamic. As they added and removed dynamically.
Add interface_filter to exclude them from checks
(cherry picked from commit 0a1c9bc38440c86cbbc016fb6d8f7d6f36993652)
|
|
The initial version always enabled Google authenticator (2FA/MFA) support by
hardcoding the PAM module for sshd and login.
This change only enables the PAM module on demand if any use has 2FA/MFA
configured. Enabling the module is done system wide via pam-auth-update by
using a predefined template.
Can be tested using:
set system login user vyos authentication plaintext-password vyos
set system login user vyos authentication otp key 'QY735IG5HDHBFHS5W7Y2A4EM274SMT3O'
See https://docs.vyos.io/en/latest/configuration/system/login.html for additional
details.
(cherry picked from commit e134dc4171b051d0f98c7151ef32a347bc4f87e2)
|
|
T160: add NAT64 (backport #2578)
|
|
(cherry picked from commit 237b71a89160f28e5c603bacf707b1c235f01026)
|
|
ddclient: T5791: Update dynamic dns configuration path (sagitta backport)
|
|
(cherry picked from commit 57761a370d2217eeb79827e8c20384f6de649c66)
|
|
*pool* empty, this means that lease was granted by fail-over server. Also fix issue that <show dhcp server leases state all> print nothing.
(cherry picked from commit da83b3f96dcedaa8e4d926d9f5bdc963abd9a813)
|
|
- Update the base (rebase)
- Move include/nat64-protocol.xml.i => include/nat64/protocol.xml.i
- Delete unwanted `write_json`, use `write_file` instead
- Remove unnecessary deleting of default values for tagNodes T2665
- Add smoketest
Example:
```
set interfaces ethernet eth0 address '192.168.122.14/24'
set interfaces ethernet eth0 address '192.168.122.10/24'
set interfaces ethernet eth2 address '2001:db8::1/64'
set nat64 source rule 100 source prefix '64:ff9b::/96'
set nat64 source rule 100 translation pool 10 address '192.168.122.10'
set nat64 source rule 100 translation pool 10 port '1-65535'
```
(cherry picked from commit 336bb5a071b59264679be4f4f9bedbdecdbe2834)
|
|
Signed-off-by: Joe Groocock <me@frebib.net>
(cherry picked from commit 7d49f7079f1129c2fadc7f38ceb230804d89e177)
# Conflicts:
# debian/control
|
|
Mark 'dns dynamic name' as tag node to avoid unexpected nesting.
Also, fix file exec permission for migration script.
|
|
|
|
Modify the configuration path to be consistent with the usual dialects
of VyoS configuration (wireguard, dns, firewall, etc.)
This would also shorten the configuration path and have a unified
treatment for RFC2136-based updates and other 'web-service' based updates.
While at it, add support for per-service web-options. This would allow
for probing different external URLs on a per-service basis.
|
|
On VTI interface link down the link-local IPv6 address is removed. As soon as
the IPSec tunnel is online again, vti-up-down helper is called which only places
the interface in up state using iproute2 command
sudo ip link set vti0 up
This does not restore the IPv6 LL address. Instead use vyos.ifconfig to properly
re-initialize the VTI interface using the generic update() method.
(cherry picked from commit d90ca4415bed8ce99c854243dca3036e76497270)
|
|
|
|
|
|
ddclient: T5573,T5574,T5612,T5708: Backport ddclient related changes
|
|
Additionally, templatize system service override and move it to the
runtime path.
(cherry picked from commit eb906739047187c322b6ce9efe7c9479bed9a024)
|
|
Add additional smoketests for web-options validation.
Also, format error messages to optionally include protocol name.
|
|
Fix execution bit for migration script
|
|
- Migrate to ddclient 3.11.1 and enforce debian/control dependency
- Add dual stack support for additional protocols
- Restrict usage of `porkbun` protocol, VyOS configuration structure
isn't compatible with porkbun yet
- Improve and cleanup error messages
|
|
`web-options` is only applicable when using HTTP(S) web request to
obtain the IP address. Apply guard for that.
|
|
Time interval in seconds to wait between DNS updates would be a bit
more intuitive as `interval` than `timeout`.
|
|
Add support for per-service cache management for ddclient providers
via `wait-time` and `expiry-time` options. This allows for finer-grained
control over how often a service is updated and how long the hostname
will be cached before being marked expired in ddclient's cache.
More specifically, `wait-time` controls how often ddclient will attempt
to check for a change in the hostname's IP address, and `expiry-time`
controls how often ddclient to a forced update of the hostname's IP
address.
These options intentionally don't have any default values because they
are provider-specific. They get treated similar to the other provider-
specific options in that they are only used if defined.
|
|
Additional cleanup and refactoring for ddclient scripts including the
smotektests.
|
|
Adjust the validator and completion for ddclient to remove unsupported
or superfluous protocols.
Specifically,
- remove 'nsupdate' protocol from the list because there is a separate
config path for that protocol (rfc2136)
- remove 'cloudns' protocol from the list because it has non standard
configuration and is not supported by our configurator at this time
|
|
dyndns2 protocol in ddclient honors dual stack for selective servers
because of the way it is implemented in ddclient.
We formalize the well known servers that support dual stack in a list
and check against it when validating the configuration.
|
|
Enable TTL support for web-service based protocols in addition to
RFC2136 based (nsupdate) protocol.
Since TTL is not supported by all protocols, and thus cannot have a
configuration default, the existing XML snippet `include/dns/time-to-live.xml.i`
does not have common `<defaultValue>300</defaultValue>` anymore and is
instead added explicitly whenever necessary.
|
|
Fix VRF support interface definition and configuration mode for ddclient
to actually capture the VRF name and pass it to the template.
|
|
vxlan: T5759: change default MTU from 1450 -> 1500 bytes (backport #2503)
|
|
unless PAM auth is enabled for GraphQL
(cherry picked from commit 8c450ea7f538beb0b2cd21d35c05d18db49a1802)
|
|
This fixes the implementation in e062a8c11 ("pppoe: T5630: allow to specify MRU
in addition to already configurable MTU") and restores the bahavior that MRU
defaults to MTU if MRU is not explicitly set.
This was the behavior in VyOS 1.3.3 and below before we added ability to define
the MRU value.
(cherry picked from commit ffd7339e2ea3eafdd97ac0763ca4a3913fe71bf3)
|
|
Found an odd behavior on Linux and the VyOS CLI implementation. If adding VXLAN
interfaces using iproute2 the MTU differs depending on the creation syntax:
ip -4 link add vxlan100 type vxlan dstport 4789 external df unset tos inherit \
ttl 16 nolearning vnifilter local 172.16.33.201
ip -4 link add vxlan200 type vxlan id 200 dstport 4789 local 172.16.33.201 dev eth0
ip -6 link add vxlan300 type vxlan id 300 dstport 4789 local 2001:db8:1::1 dev eth0
132: vxlan300: <BROADCAST,MULTICAST> mtu 1430 qdisc noop state DOWN group default qlen 1000
link/ether 4e:fb:e3:f5:d9:59 brd ff:ff:ff:ff:ff:ff
133: vxlan200: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 0e:4e:f4:76:59:3f brd ff:ff:ff:ff:ff:ff
134: vxlan100: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ba:b6:b7:0c:b1:37 brd ff:ff:ff:ff:ff:ff
VyOS always sets a default MTU of 1450 bytes which is correct for IPv4 p2p links
or multicast, but invalid for IPv6 p2p. Also this will break EVPN deployments
as ethernet bridges with MTU < 1500 bytes are less fun.
Increase default MTU to 1500 bytes. Migrate old configurations to use 1450
bytes if not specified otherwise on the CLI.
(cherry picked from commit 4a163b016333e58fee9d6ec6b53a09e0160b3213)
|
|
In a service provider network a service provider typically supports multiple
bridge domains with overlapping vlans. One bridge domain per customer. Vlans in
each bridge domain are mapped to globally unique VXLAN VNI ranges assigned to
each customer.
Without the ability of VNI filtering, we can not provide VXLAN tunnels
with multiple tenants all requiring e.g. VLAN 10.
To Test:
set interfaces vxlan vxlan987 parameters external
set interfaces vxlan vxlan987 source-interface eth0
set interfaces vxlan vxlan987 parameters vni-filter
set interfaces vxlan vxlan987 vlan-to-vni 50 vni 10050
set interfaces vxlan vxlan987 vlan-to-vni 51 vni 10051
set interfaces vxlan vxlan987 vlan-to-vni 52 vni 10052
set interfaces vxlan vxlan987 vlan-to-vni 53 vni 10053
set interfaces vxlan vxlan987 vlan-to-vni 54 vni 10054
set interfaces vxlan vxlan987 vlan-to-vni 60 vni 10060
set interfaces vxlan vxlan987 vlan-to-vni 69 vni 10069
set interfaces bridge br0 member interface vxlan987
Add new op-mode command: show bridge vni
Interface VNI
----------- -----------
vxlan987 10050-10054
vxlan987 10060
vxlan987 10069
(cherry picked from commit 35f6033d21053fa420e837f157cd9377a4ccd26a)
|
|
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)
|
|
T5767: HTTPS API add reboot and poweroff endpoints (backport #2516)
|
|
Add ability to reboot and poweroff the system via API
curl -k --location --request POST 'https://vyos/reboot' \
--form data='{"op": "reboot", "path": ["now"]}' \
--form key='apikey'
curl -k --location --request POST 'https://vyos/poweroff' \
--form data='{"op": "poweroff", "path": ["now"]}' \
--form key='apikey'
(cherry picked from commit 36f3c329c2df0e78f2f5da933d9729a872fb2a11)
|
|
|
|
PAM: T5577: Backported PAM settings from circinus
|
|
T5763: fix imprecise check for remote file name (backport #2511)
|
|
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)
|
|
(cherry picked from commit fe9b08665367b8e7d9b906a0760d44efc9b5cafb)
|
|
This complements commit 5181ab60bb ("RADIUS: T5577: Added 'mandatory' and
'optional' modes for RADIUS") and commit 1c804685d0 ("TACACS: T5577: Added
'mandatory' and 'optional' modes for TACACS+"). As those new services
should also be cleaned during system boot.
|
|
After sources analysis, we found the next possible return statuses for PAM
modules:
1. pam_tacplus
Auth:
- PAM_AUTH_ERR
- PAM_AUTHINFO_UNAVAIL
- PAM_AUTHTOK_ERR
- PAM_BUF_ERR
- PAM_CRED_INSUFFICIENT
- PAM_PERM_DENIED
- PAM_SUCCESS
- PAM_USER_UNKNOWN
Account:
- PAM_AUTH_ERR
- PAM_AUTHINFO_UNAVAIL
- PAM_PERM_DENIED
- PAM_SUCCESS
- PAM_USER_UNKNOWN
Session:
- PAM_AUTHINFO_UNAVAIL
- PAM_SESSION_ERR
- PAM_SUCCESS
- PAM_USER_UNKNOWN
2. pam_radius_auth
Auth:
- PAM_ABORT
- PAM_AUTH_ERR
- PAM_AUTHINFO_UNAVAIL
- PAM_AUTHTOK_ERR
- PAM_BAD_ITEM
- PAM_BUF_ERR
- PAM_CONV_AGAIN
- PAM_CONV_ERR
- PAM_IGNORE
- PAM_NO_MODULE_DATA
- PAM_PERM_DENIED
- PAM_SUCCESS
- PAM_SYSTEM_ERR
- PAM_USER_UNKNOWN
Account:
- PAM_SUCCESS
Session:
- PAM_ABORT
- PAM_AUTHINFO_UNAVAIL
- PAM_BAD_ITEM
- PAM_BUF_ERR
- PAM_CONV_AGAIN
- PAM_CONV_ERR
- PAM_IGNORE
- PAM_NO_MODULE_DATA
- PAM_PERM_DENIED
- PAM_SUCCESS
- PAM_SYSTEM_ERR
- PAM_USER_UNKNOWN
PAM configurations were replaced with tuned versions to take this into account.
|
|
In CLI we can choose authentication logic:
- `mandatory` - if TACACS+ answered with `REJECT`, authentication must be
stopped and access denied immediately.
- `optional` (default) - if TACACS+ answers with `REJECT`, authentication
continues using the next module.
In `mandatory` mode authentication will be stopped only if TACACS+ clearly
answered that access should be denied (no user in TACACS+ database, wrong
password, etc.). If TACACS+ is not available or other errors happen, it will be
skipped and authentication will continue with the next module, like in
`optional` mode.
|