| Age | Commit message (Collapse) | Author |
|---|
|
nat: T6365: remove warnings for negated interface selections by name
|
|
|
|
|
|
|
|
Add the ability to show port allocation per external or internal address
With huge entries, it is necessary to filter it by specific
external/internal IP address
|
|
T6364: CGNAT drop hard limit that allows only one translation rule
|
|
|
|
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'
```
|
|
op mode: T6348: SNAT op-mode fails with flowtable offload entries
|
|
T6358: Container config option to enable host pid
|
|
|
|
|
|
T6350: CGNAT add op-mode to show allocation
|
|
T6351: CGNAT add verification if the pool exists
|
|
|
|
T6347: CGNAT fix error if pool contain dashes in the name
|
|
Add op-mode command `show nat cgnat allocation` to get CGNAT
allocations (internal address, external address, port-range)
|
|
T6335: Add/Update EVPN op commands
|
|
Add verification if the external/internal pools are exists before we
can use them in the source and translation rules
|
|
|
|
Converted completion helpers from python to bash for performance
Previous commit:
Added the following commands:
show evpn
show evpn es
show evpn es <es-id>
show evpn es detail
show evpn es-evi
show evpn es-evi detail
show evpn es-evi vni <num>
show evpn vni
show evpn vni detail
show evpn vni <num>
Updated the following commands:
show evpn access-vlan
show evpn arp-cache
show evpn mac
show evpn next-hops
show evpn rmac
|
|
Added the following commands:
show evpn
show evpn es
show evpn es <es-id>
show evpn es detail
show evpn es-evi
show evpn es-evi detail
show evpn es-evi vni <num>
show evpn vni
show evpn vni detail
show evpn vni <num>
Updated the following commands:
show evpn access-vlan
show evpn arp-cache
show evpn mac
show evpn next-hops
show evpn rmac
|
|
|
|
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
|
|
T6329: firewall: add a patch for op-mode command <show firewall group>
|
|
|
|
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
|
|
|
|
|
|
|
|
bgp: T6082: Allow the same local-as and remote-as in one peer group
|
|
|
|
|
|
show interfaces bonding lacp detail
show interfaces bonding <bondif> lacp detail
show interfaces bonding <bondif> lacp neighbors
Co-authored-by: l0crian1 <ryan.claridge13@gmail.com>
|
|
Fix default values for random-detect
Remove dsmakr qdisc from gred cofig because dsmark was deleted from kernel
|
|
ntp: T4909 rewrite NTP op mode in the new format
|
|
|
|
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
|
|
T6287: Config-sync add the ability to configure API port
|
