| Age | Commit message (Collapse) | Author |
|---|
|
migrate from old vyatta-cfg-system / Perl implementation.
|
|
|
|
dhcp6.name-servers is a comma-delimited, multi-value list of name-servers that
should only appear once in the dhcpdv6.conf file.
(cherry picked from commit b05201724022d1a50a51d150abb4f444b2e1555e)
|
|
|
|
Closing bracked "}" was placed on the wrong line inside the template leading
to an invalid configuration syntax.
|
|
|
|
|
|
|
|
|
|
|
|
Commit 4f9aa30f ("vrf: bgp: T3523: add route-map support for kernel routes")
added the possibility to also filter BGP routes towards the OS kernel, but the
smoketests failed. Reason was a non working CLI command applied to bgpd.
Thus the VRF route-map and the BGP configuration is now split into two templates,
one to be used for each daemon (zebra and bgpd).
Nevertheless one more bug was found in vyos.frr which currently does not suppoort
calling modify_section() inside a configuration "block". See [1] for more info.
[1]: https://phabricator.vyos.net/T3529
|
|
|
|
|
|
|
|
A + simply adds the value, but a ~ will convert the variable to a string
first.
|
|
|
|
dns: T3277: DNS Forwarding - reverse zones for RFC1918 addresses
|
|
|
|
|
|
This commit has a dependecy on https://github.com/FRRouting/frr/issues/8403,
thus support will be "commented out" by default.
|
|
|
|
|
|
This commit is a cleanup and refinement of the container hosting implementation.
- Renamed CLI node ipv4-prefix -> prefix so both IPv4 and IPv6 prefix can be
supplied in the future. This is currently limited to IPv4 only as when using
IPv6 networks in combination with IPv4 the IPv4 prefix is altered randomly
- De-nested if clauses
- Use "for foo, bar in baz.items()" to more easily iterate of dictionary
values, this means "bar" can be used to access "baz[foo]"
|
|
This reverts commit 619c518bfc904b060b5b59180940a804fe1beafd.
|
|
|
|
When rendering a dynamic routing protocol ensure the context, e.g. "router bgp"
or "router ospf" is proberly exited before applying any zebra route-map.
|
|
|
|
The following options one can specify in a route-map not got rendered as they
have been missed out:
* set comm-list
* set community
* set extcommunity (both route-target and site-of-origin)
* set table
|
|
get_config_dict()
|
|
|
|
In this commit we add more address families within
BGP. This should bring VyOS the ability to enable
the rest of the capabilities within FRR.
Co-authored-by: Cheeze_It <none@none.com>
|
|
containers: T2216: Add podman for containers
|
|
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols rip route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not ripd.
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols isis route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not isisd.
|
|
|
|
set vrf name red protocols bgp address-family l2vpn-evpn advertise ipv4 unicast
|
|
This is a fix for commit 6f6f45c5 ("bgp: T3463: change no-ipv4-unicast order
when applying configuration") as this changed the handling of the "else" path,
which lead to failing smoketests as the "no bgp ebgp-requires-policy" option
was no longer set.
|
|
The "no bgp default ipv4-unicast" option must be applied to FRR before adding
any neighbor to the system. If this is not the case, neighbors will start
exchanging v4 routes over v6 peers.
|
|
Commit 548d9057e3e (vrf: T3344: move dynamic routing protocols under "vrf name
<name> protocols") temporary removed the possibility to specify the VNI for a
given VRF to to changing of the CLI configuration nodes.
As VNI is set inside zebra, we can re-use the now widely deployed frr python
library to configure and change the configuration without any interference to
other FRR daemons.
|
|
Instead of having a dedicated ERSPAN interface type, rather move the specifics
into "interface tunnel". A migrator is not needed as there is yet no LTS release
with this feature and this is considered experimental.
|
|
Sometimes a modem might give a local IP before it retrieves a WAN IP.
This can be an issue with failover routes,
since the default route will get overridden.
|
|
Every time when set configuration bgp, you need set AS number. There is very
less benefit in this system so the AS number is moved from a tagNode level down
to a leafNode with the name "local-as", same as on the neighbor or peer-group
level.
This changes the CLI configuration from:
set protocols bgp 100 neighbor 10.10.1.2 remote-as 200
to
set protocols bgp local-as 100
set protocols bgp neighbor 10.10.1.2 remote-as 200
|
|
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.
|
|
vyos-configd now supports calling a script with a passed argument;
re-include the conf_mode scripts that were excluded in ba251b3f2c.
|
|
processing
vyos-configd does yet not support calling a script with a passed argument, thus
we will exclude the routing protocols during this time from the vyos-configd
processing.
|
|
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".
|
|
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.
|
|
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.
|
