Age | Commit message (Collapse) | Author |
|
(cherry picked from commit 74910564f82e2837cd7eb35ea21f07601e5f8f0d)
|
|
(cherry picked from commit 81dea053e7178b8fea836a85aacde2a38ffb9e09)
|
|
(cherry picked from commit d4d70929a81b2ee1f66a9412a3545911b3874a62)
|
|
address
ISC DHCP server expects a string: "prefix6 2001:db8:290:: 2001:db8:29f:: /64;"
where the IPv6 prefix/range must be :: terminaated with a delegated prefix
length at the end.
This commit changes the validator that the IPv6 address defined on the CLI must
always end with ::. In addition a verify() step is added to check that the
stop address is greater than start address.
|
|
This reverts the prefix start/stop address must be inside network part from
commit 4cde0b8ce778d269d3fe1d4f33ba5b2caf424181.
|
|
(cherry picked from commit e1450096b4c667a4c33a3fcd8f67ebf6a39d441d)
|
|
(cherry picked from commit 59781ff365a5e1b15ef6c4c2481f3d3815548b9d)
|
|
(cherry picked from commit 645c43ba60d29ca676a4323ccc5ca16c6bd8127a)
|
|
(cherry picked from commit 3870247517741ce23e2fcee8aaa1d194f0ad621b)
|
|
(cherry picked from commit 03eae30b27433055ddc10f09fc134b83e9bd6cec)
|
|
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)
|