Age | Commit message (Collapse) | Author |
|
|
|
Replace the Flask micro-framework with FastAPI, in order to support
extensions to the API and OpenAPI 3.* generation. This change will
remain backwards compatible with previous versions. Notably, the
multipart forms version of requests remain supported; in addition
application/json requests are now natively supported.
|
|
|
|
This reverts commit d89455ee7f5dc21d00bbeddd57eaee2e32f45f99.
|
|
routing: T3217: Save configs of daemon per commit
|
|
Allows Dynamic DNS services with custom names to use the zone field if
the protocol is set to cloudflare
(cherry picked from commit 5ab6c20f8acd4dda1870b9a71fe73129d2f78b24)
|
|
|
|
If the script name is mangled, for any reason (e.g. missing support for
script arguments) checking against the exclude_set will yield a false
positive; check against the include_set, even if this is a longer
search.
|
|
|
|
|
|
util: T3419: Handle IP addresses with netmasks and subnet prefixes in strip-private
|
|
|
|
strip-private
|
|
ISIS: add VRF support
|
|
op-mode: T3403: Fix show pppoe sessions interupt
|
|
As we and FRR do not support multiple FRR process instances, there is no need
to make this configurable for a user. We rather rely on a solid default "VyOS".
|
|
|
|
We need to adjust the regex pattern for the default VRF as a trailing whitespace
is required due to an FRR issue: https://github.com/FRRouting/frr/issues/8300
|
|
|
|
|
|
The regex only validated interfaces according to the VyOS naming scheme, but
third party interfacs that are legit (e.g. exists within the kernel) failed
to validate.
The validator now also supports any kind of local interfaces attached to
the OS kernel.
|
|
Instead of multiple if/else paths, use a common vrf string variable which is
either populated or not. In addtion when interfaces are configured for a given
VRF, harden the regex for config reload.
|
|
VRF support can be tested using:
set vrf name red table 1000
set vrf name red protocols isis domain FOOO
set vrf name red protocols isis net 49.0001.1921.6800.1002.00
set vrf name red protocols isis interface eth1
|
|
As there can only be one running IS-IS process (FRR limitation) there is no need
in having a tagNode here. This adds artifical restrictions/limitations when
moving on to support VRFs for IS-IS protocol.
|
|
|
|
When NTP is executed inside a VRF context, we also must execute the op-mode
commands inside the given VRF.
This is a workaround until the op-mode programming library from T3402 is
available.
|
|
|
|
Turns out we still need it, else a MC7710 card won't work on an APU4 device.
This reverts commit f9e0fb6bffd41c143ff5454c3b73cca4a588ca86.
|
|
nat66: T2518: Correct the wrong logic
|
|
VyOS 1.2 (crux) rejected prefixes other then of site /64.
[ interfaces ethernet eth0 ipv6 address eui64 2006:ab00:abe1::2/127 ]
Error: Prefix lenght is 127. It must be 64.
Same should be done on VyOS 1.3 and newer
|
|
When leaking routes to a VRF ensure that the VRF we are leaking to exists.
|
|
Re-issuing the same iproute2 commands can lead to errors, simply ignore
them and not raise a Python exception.
|
|
During assembly of the required config changes we also must move the
interfaces_removed assignemnt to an earlier stage so the value is also populated
when the entire process is removed to cleanup all remaining OSPF process assigned
interfaces.
This was yet not the case and when deleting OSPF I still got my "interface eth0"
with the area key configured.
|
|
|
|
|
|
For nat66, the previous processing
of f0d0a572 (NAT: nat66: t2518: support operation...) has errors.
If there is no index 3, we think that this is not the record we need
|
|
|
|
|
|
T3354: Add strip-private script in Python
|
|
|
|
|
|
|
|
conf-mode: T2425: Add XML for policy-lists
|
|
pppoe: T3403: Fix show sessions interrupt for op-mode
|
|
VRF: support for dynamic routing protocols OSPF and BGP
|
|
|
|
Instead of having the dynamic routing protocols OSPF and BGP residing under
the "protocols vrf <name> [ospf|bgp]" nodes, rather move them directly under
the "vrf name <name> protocols [ospf|bgp]" node. Now all VRF related parts
are placed under the same root node.
This eases the verify steps tremendously, as we do not need to check wheter a
VRF eists or not, it will always exist as we operate under a child node.
|
|
nat66: T2518: Modify the command line description of NAT/NAT66
|
|
The following VyOS CLI config
vrf red {
bgp 100 {
neighbor 1.1.1.1 {
peer-group foo
}
peer-group foo {
passive
password bar
remote-as 200
}
}
}
Will generaste the FRR configuration:
!
router bgp 100 vrf red
no bgp ebgp-requires-policy
no bgp network import-check
neighbor foo peer-group
neighbor foo remote-as 200
neighbor foo password bar
neighbor foo passive
neighbor 1.1.1.1 peer-group foo
!
|
|
|