Age | Commit message (Collapse) | Author |
|
ConfigError messages
|
|
(cherry picked from commit f5051de4fc034bd95677ef142423e59eae47cd2f)
|
|
(cherry picked from commit 240f199cdfadbc12ce713dae74c8db3af44a398c)
|
|
Remove `service upnp` as it never worked as expected, nft rules do
not integrated and custom patches do not seem like a suitable
solution for now.
Security:
UPnP has been historically associated with security risks due to its automatic
and potentially unauthenticated nature.
UPnP devices might be vulnerable to unauthorized access or exploitation.
(cherry picked from commit 7c438caa2c21101cbefc2eec21935ab55af19c46)
|
|
When all the underlay links go down the PE no longer has access to the VxLAN
+overlay.
To prevent blackholing of traffic the server/ES links are protodowned on the PE.
A link can be setup for uplink tracking via the following configuration:
set interfaces ethernet eth0 evpn uplink
(cherry picked from commit 5565f27d15c5e7378e94aae8db8a894a12e25d7b)
|
|
bridge: T6317: add dependency call for wireless interfaces (backport #3430)
|
|
(cherry picked from commit d8ddd7191d3004e886fa45a2cf9bd8dd5e7f5e14)
|
|
(cherry picked from commit 431443ab3f663a6617008536d2d6d96407aebfcb)
|
|
(cherry picked from commit 31fc5372961547bb352c56eb2f4149fd195e9be1)
|
|
filtering
|
|
(cherry picked from commit 637a73e35ff716441df0430b2308d685707b2ca0)
|
|
The netns support currently available on the VyOS CLI is only a
proof-of-technology, we have no real support for any service behind it.
In order to not confuse anyone on the LTS branch we decided to remove the
netns option for interfaces until there is a proper usecase and implementation
available.
|
|
qos: T6225: Fix QoS random-detect policy (backport #3400)
|
|
bgp: T6189: L3VPN connectivity is broken after re-enabling VRF (backport #3392)
|
|
Fix default values for random-detect
Remove dsmakr qdisc from gred cofig because dsmark was deleted from kernel
(cherry picked from commit 0b54c1bc411a21833ec573031cf5ad98fe709a2f)
|
|
We have several config XML definitions that use the same python3
script `system_host-name.py`
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system_name-server.xml.in
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system_host-name.xml.in
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system_static-host-mapping.xml.in
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system_domain-name.xml.in
https://github.com/vyos/vyos-1x/blob/current/interface-definitions/system_domain-search.xml.in
Any change in these scripts calls to restart the `service snmpd`
The service `snmpd` should be restarted only if `host-name` or
`domain-name` was changed.
It is a good idea to rewrite it to `get_config_dict` in the future.
(cherry picked from commit 4f1db505791deed533dddf0c2f5bdedd6fba34b8)
|
|
After e7bb65894 ("vrf: T6189: render FRR L3VNI configuration when creating VRF
instance") we need to ensure that the VRF L3VNI configuration is removed in FRR
prior to removing the BGP VRF instance.
The reason is [1] where FRR only allows VRF BGP instance to be removed when
there is NO VNI configured anymore.
1: https://github.com/FRRouting/frr/blob/064c3494527b9e84260410006768ed38e57e1de7/bgpd/bgp_vty.c#L1646-L1650
(cherry picked from commit 7b46172a4aecc714d929aecb8768ab82633de3ba)
|
|
When adding and removing VRF instances on the fly it was noticed that the vni
statement under the VRF instance in FRR vanishes. This was caused by a race
condition which was previously designed to fix another bug.
The wierd design of a Python helper below the VRF tree to only generate the
VNI configuration nodes is now gone and all is rendered in the proper place.
(cherry picked from commit e7bb65894f86372dc0f6e8fd39b1628e0a224c68)
|
|
(cherry picked from commit 107ee099e82397b31fca8cf1ac3860cbf76f0596)
|
|
Check if the wireless device/modem exists in the system and the
module `ieee802111` was loaded
In cases where we do not have wireless devices, it prevents the
unexpected traceback
```
set interfaces wireless wlan0 address 192.0.2.5/32
commit
Traceback (most recent call last):
File "/usr/libexec/vyos/conf_mode/interfaces_wireless.py", line 269, in <modu>
c = get_config()
^^^^^^^^^^^^
File "/usr/libexec/vyos/conf_mode/interfaces_wireless.py", line 104, in get_cg
tmp = find_other_stations(conf, base, wifi['ifname'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/libexec/vyos/conf_mode/interfaces_wireless.py", line 54, in find_os
for phy in os.listdir('/sys/class/ieee80211'):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/sys/class/ieee80211'
```
(cherry picked from commit 09c302d7e57a0fdb6c51ae8f61d5ad6371a30b67)
|
|
Throwing Warning message instead of Error if interface which is
used in pppoe/ipoe does not exist.
(cherry picked from commit af7277c7d525c22749bc236ad2096bec5c08d998)
|
|
qos: T4248: Allow to remove the only rule from the qos class (backport #3316)
|
|
The join addresses within the multicast group 224.0.0.0/24 are
reserved and cannot be joined
FRR
```
r4(config)# interface eth2
r4(config-if)# ip igmp join 224.0.0.0 224.0.0.10
% Configuration failed.
Error type: validation
Error description: Groups within 224.0.0.0/24 are reserved and cannot be joined
r4(config-if)#
```
Add verify check
(cherry picked from commit c8f9acf5d91827b0d1266d3061a5e15a82628323)
|
|
(cherry picked from commit da40bd2b2a826986de128354ea1bfc041ada0016)
|
|
Not all FRR address-families compatibe with VRF
```
r4# conf t
r4(config)# router bgp 65001 vrf bgp
r4(config-router)#
r4(config-router)# address-family ipv4 flowspec
Only Unicast/Multicast/EVPN SAFIs supported in non-core instances.
r4(config-router)#
r4(config-router)# address-family ipv4 labeled-unicast
Only Unicast/Multicast/EVPN SAFIs supported in non-core instances.
r4(config-router)#
r4(config-router)# address-family ipv4 vpn
Only Unicast/Multicast/EVPN SAFIs supported in non-core instances.
r4(config-router)#
```
Add verify AFI for VRF
(cherry picked from commit a3713cd64f2f43f321a5138db94bb1a87edbffdd)
|
|
(cherry picked from commit 050f24770aec7a74c1a07ba64cf2cb83afb72f1a)
|
|
Fix for restoring default ip rule values after deleting VRF
Defult values:
```
$ ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
```
After adding and deleting a VRF we get unexpected values:
```
$ ip rule
1000: from all lookup [l3mdev-table]
2000: from all lookup [l3mdev-table] unreachable
32765: from all lookup local
32766: from all lookup main
32767: from all lookup default
```
(cherry picked from commit ce0bc35f8b5ff80a7b8fbfdf1b9ccc10c5c254fd)
|
|
(cherry picked from commit a88b3bd344cc4a682d16681ef536c1d20e2c2c42)
|
|
server certificates
(cherry picked from commit aafe22d08bb38a579dd5075fd27a1b88beeca791)
|
|
T5535: firewall: migrate command <set system ip disable-directed-broadcast> to firewall global-optinos (backport #3309)
|
|
(cherry picked from commit 9f9891a209957403dfa3ae9ec2cd56d8d9eedb86)
|
|
Check if DH is configured for OpenVPN but does not exist in the
PKI section
```
set pki dh dh-correct parameters 'xxxx'
set interfaces openvpn vtun10 tls dh-params 'dh-fake'
File "/usr/libexec/vyos/conf_mode/interfaces_openvpn.py", line 208, in verify_pki
pki_dh = pki['dh'][tls['dh_params']]
~~~~~~~~~^^^^^^^^^^^^^^^^^^
KeyError: 'dh-fake'
```
(cherry picked from commit 95cd743c24c6f7720af87450312fc111649db849)
|
|
to firewall global-optinos
(cherry picked from commit 76dcecafca977b640dd16d8e68c4a050ca1af4fb)
|
|
fails (#3296)
(cherry picked from commit 6d8336f5ad2d9c4e0f12b54681db2924d6998d2d)
|
|
(cherry picked from commit 6b5590ae3325320a2b6bbcb34086ddb178860160)
|
|
There are cloud environments available where the maximum supported ethernet
MTU is e.g. 1450 bytes, thus we clamp this to the adapters maximum MTU value
or 1500 bytes - whatever is lower.
(cherry picked from commit 8296cc727066e739c178918a91cfc11d20d26fe1)
|
|
Commit 1b364428f ("login: T5875: restore home directory permissions only when
needed") added logic to chown the users home directory if it's UID changes.
This might happen when a user account is deleted and re-added to the system.
Under rar e circumstances it was possible that the implementation triggered
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
KeyError: 'getpwuid(): uid not found: XXXX'
This has been fixed by re-arranging the code path with an additional try/except
if the PW database information could not be retrieved leading to an implicit
chown() of the home directory to the user beeing added.
(cherry picked from commit 1165bb497ec2d6d1b3b12d6c03435b0210efe9e5)
|
|
ipoe: T6205: error in migration script logic while renaming mac-address to mac node (backport #3263)
|
|
'upper'
Commit b30faa43c (container: T6208: rename "cap-add" CLI node to "capability")
added an AttributeError referencing an out of scope variable.
This has been fixed.
(cherry picked from commit 2463bd292f14e46fdb26116791a89ca2eb651d17)
|
|
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)
|
|
(cherry picked from commit 489e6fababa60d9c0fbfdb421305cbe563432499)
# Conflicts:
# src/migration-scripts/dhcp-server/9-to-10
# src/migration-scripts/dhcpv6-server/3-to-4
|
|
(cherry picked from commit d403117cdb5e7718c8590cfeb79a336cb5b67aac)
|
|
T6199: spring cleaning - drop unused Python imports (backport #3240)
|
|
found using "git ls-files *.py | xargs pylint | grep W0611"
(cherry picked from commit 274b2da242acd1f1f64ff1dee471e34295137c5f)
|
|
* Use interface_exists() outside of verify()
* Use verify_interface_exists() in verify() to drop common error message
(cherry picked from commit 4c7c168fe970b807750a05ceb66b70c0d8652535)
|
|
<high-availability>. Also, add <mode> parameter in order to configure active-active or active-passive behavior for HA.
|
|
T6192: allow binding SSH to multiple VRF instances (backport #3229)
|
|
The next evolutional step after adding get_config_dict(..., with_pki=True) is
to add a common verification function for the recurring task of validating SSL
certificate existance in e.g. EAPoL, OpenConnect, SSTP or HTTPS.
(cherry picked from commit 3b758d870449e92fece9e29c791b950b332e6e65)
|
|
Currently VyOS only supports binding a service to one individual VRF. It might
become handy to have the services (initially it will be VRF, NTP and SNMP) be
bound to multiple VRFs.
Changed VRF from leafNode to multi leafNode with defaultValue: default - which
is the name of the default VRF.
(cherry picked from commit e5af1f0905991103b12302892e6f0070bbb7b770)
|