Age | Commit message (Collapse) | Author |
|
Fix the bug where address external alocation was not rely on sequences
of the external IP addresses (if set)
|
|
|
|
suricata: T751: Initial support for suricata
|
|
|
|
|
|
|
|
reverse-proxy: T6370: Set custom HTTP headers in reverse-proxy responses
|
|
nat66: T6365: remove warnings for negated interface selections by name
|
|
current (#3508)
|
|
|
|
nat: T6365: remove warnings for negated interface selections by name
|
|
|
|
|
|
|
|
|
|
Allow to set multiple CGNAT internal pools
```
set nat cgnat pool internal int-01 range '100.64.0.0/28'
set nat cgnat pool internal int-01 range '100.64.222.11-100.64.222.14'
```
|
|
As PoC for CGNAT had a hard limit of using only one translation
rule for one internal pool.
Drop this limit and extend the usage number of the rules.
```
set nat cgnat rule 100 source pool 'int-01'
set nat cgnat rule 100 translation pool 'ext-01'
set nat cgnat rule 120 source pool 'vyos-int-02'
set nat cgnat rule 120 translation pool 'vyos-ext-02'
```
|
|
T6358: Container config option to enable host pid
|
|
|
|
|
|
T6351: CGNAT add verification if the pool exists
|
|
Add verification if the external/internal pools are exists before we
can use them in the source and translation rules
|
|
|
|
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.
|
|
ethernet: T6306: add support for EVPN MH uplink/core tracking
|
|
|
|
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
|
|
Bond: T6303: add system mac address on interfaces bond
|
|
|
|
|
|
|
|
|
|
Fix default values for random-detect
Remove dsmakr qdisc from gred cofig because dsmark was deleted from kernel
|
|
bgp: T6189: L3VPN connectivity is broken after re-enabling VRF
|
|
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
|
|
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.
|
|
pppoe-server: T6234: PPPoE-server pado-delay refactoring
|
|
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.
|
|
T6267: Check interface wireless module before apply config
|
|
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'
```
|
|
Throwing Warning message instead of Error if interface which is
used in pppoe/ipoe does not exist.
|
|
T6263: Groups 224.0.0.0/24 are reserved and cannot be joined
|
|
qos: T4248: Allow to remove the only rule from the qos class
|
|
|
|
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
|
|
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
|
|
|
|
T6221: Return default ip rule values after deleting VRF
|
|
|
|
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
```
|