| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* set protocols ospf aggregation timer <seconds>
* set protocols ospf summary-address x.x.x.x/x [tag 1-4294967295]
* set protocols ospf summary-address x.x.x.x/x no-advertise
|
|
|
|
The previous implementation did not iterate over the communit list, so only
one match criteria was supported.
set policy route-map FOO rule 10 action 'permit'
set policy route-map FOO rule 10 set extcommunity rt '1111:2222222'
worked but on the other hand this failed:
set policy route-map FOO rule 20 action 'permit'
set policy route-map FOO rule 20 set extcommunity rt '6500:24 6500:23 192.168.0.1:111 192.168.0.1:222'
|
|
|
|
|
|
T5283: ipoe-server: add more flexibility in subnet parameter.
|
|
... this is a step towards a new and better implementation that will utilize
VPP.
|
|
|
|
Create migration and bump package version from 0 -> 1 for dynamic dns
|
|
Apply next round of configuration tree updates to 'service dns dynamic'
with the following changes:
- Migrate `service dns dynamic interface <interface> [use-web]`
to `service dns dynamic address <interface>`
or `service dns dynamic address web [web-options]`
This communicates the intent that dynamic dns IP address is detected
in only one way - using the `<interface>` or using an external web
request, not both.
- When using external web request, (`service dns dynamic address web`),
external url is optional (`web-options url`). Ddclient defaults are
used when unspecified,
- Rename all config `login` to `username` for consistency and also to
align better with alternative ddclient backends in consideration.
- Apply global 'ipv6-enable' to per service 'ip-version: ipv6'. Selecting
usage of IPv4 or IPv6 (or both simultaneously) is now at per service
(protocol) level instead of global level. This allows more control on
the ability to select IPv4 in some cases and IPv6 in some other cases
wherever supported by the underlying ddclient protocol.
- While the IP address (and by extension, the detection mechanism) is
global, the way it is applied to a particular ddclient protocol depends
on whether it supports IPv4 or IPv6 or both.
- Related to the above, this also prevents generating incorrect config
file (`ddclient.conf`) with multiple global sections leading to an
unpredictable behavior of ddclient.
- Implement provider (protocol) specific custom tweaks whenever possible
(e.g., `zone`, `username`, `server` are not necessary in all cases).
- Move service name from a combination of 'protocol' (with protocol
config autodetected) and custom (with protocol config specified) to a
single 'service' key. This allows for consisent setup of multiple
config for the same ddclient protocol (with different options and
credentials). This also avoid ambiguity with usual networking term
'protocol' and ddclient specific term 'protocol' (and can change with
a move to a different backend).
- Apply upfront XML constraints and validations consistently wherever
applicable.
- RFC2136 specific change: Rename rfc2136 config `record` to `host-name`
for consistency.
- Cloudflare specific change: While ddclient still supports authenticating
with email and global auth key, skipping `username` in config will
indicate the intent to use API token authentication (with special
'token' literal as `username`).
|
|
|
|
and frr bgp jinja template.
|
|
Improve and refactoring "load-balancing reverse-proxy"
- replace 'reverse-proxy server <tag>'
=> 'reverse-proxy service <tag>'
- replace 'reverse-proxy global-parameters tls <xxx>'
=> 'reverse-proxy global-parameters tls-version-min xxx'
=> 'reverse-proxy global-parameters ssl-bind-ciphers xxx'
- replace 'reverse-proxy service https rule <tag> set server 'xxx'
=> 'reverse-proxy service https rule <tag> set backend 'xxx'
'service https rule <tag> domain-name xxx' set as multinode
|
|
T5222: Add load-balancing for web traffic
|
|
|
|
|
|
Make host-name constraints consistent across all definitions
|
|
Use a single ip-address validator to combine and replace ipv4-address
and ipv6-address validators.
|
|
When enabling identity-based-config, users can add arbitrary config keys
that are processed by ocserv. The user "must know" what he is been doing, as
invalid config option will make the ocserv daemon go ... whoop!
Thus add a warning and inform the user about this setting.
|
|
ocserv: T3896: add CLI options to configure ocserv config-per-user/group
|
|
Add RADIUS accounting-interim-interval option for L2TP-server
Specifies interval in seconds to send accounting information
(may be overridden by radius Acct-Interim-Interval attribute)
set vpn l2tp remote-access authentication radius accounting-interim-interval '120'
|
|
syslog: T2778: T2769: refactoring and VRF support
|
|
Add RADIUS accounting-interim-interval option for PPPoE/IPoE/SSTP
servers.
Specifies interval in seconds to send accounting information
(may be overridden by radius Acct-Interim-Interval attribute)
set service pppoe-server authentication radius accounting-interim-interval '60'
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit bfe57cf80f4c71236f0885408d704a69575f0b30.
|
|
Changes the node name from config-per-x to identity-based-config, as a result the j2 templates and vpn_openeconnect.py has been refactored to update the node name when accessing it's child nodes.
|
|
|
|
|
|
|
|
It is possible to install a route-map which filters the routes between routing
daemons and the OS kernel (zebra)
As of now this can be done by e.g.
* set protocols ospf route-map foo
* set protocols ospfv3 route-map foo
* set protocols bgp route-map foo
Which in turn will install the following lines into FRR
* ip protocol ospf route-map foo
* ipv6 protocol ospf6 route-map foo
* ip protocol bgp route-map foo
The current state of the VyOS CLI is incomplete as there is no way to:
* Install a filter for BGP IPv6 routes
* Install a filter for static routes
* Install a filter for connected routes
Thus the CLI should be redesigned to close match what FRR does for both the
default and any other VRF
* set system ip protocol ospf route-map foo
* set system ipv6 protocol ospfv3 route-map foo
* set system ip protocol bgp route-map foo
* set system ipv6 protocol bgp route-map foo
The configuration can be migrated accordingly. This commit does not come with
the migrator, it will be comitted later.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This would allow using custom ports in name server operating on non-
default port for forwarding zones.
This is a follow-up to T5113 for sake of completeness and having
consistent treatment of all name servers configured in PowerDNS recursor.
Additionally, migrate `service dns forwarding domain example.com server`
to `service dns forwarding domain foo3.com name-server` for consistency
and reusability.
|
|
|
|
|
|
|
|
Support custom port for name-server forwarders that would allow using
custom ports in name server forwarders to enable forwarding to
alternative name servers (unbound, stubby, dnscrypt-proxy etc.)
operating on non-default port.
This would also allow using DNS Over TLS in PowerDNS Recursor 4.6 onwards
(pdns doesn't support certificate check for validity yet) by enabling
'dot-to-port-853'. This is set by default if compiled in with DoT support.
See: https://doc.powerdns.com/recursor/settings.html#dot-to-port-853
This also partially implements T921, T2195 (DoT without certificate check).
Implementation details:
- In 'dns/forwarding' configuration, 'name-server' now allows optional
'port' (defaults to 53).
- Instead of modifying 'name-server-ipv4-ipv6.xml.i' to add optional
'port', a new file 'name-server-ipv4-ipv6-port.xml.i' has been used
to avoid impacting other places where it is reused because not all of
them honor ports (mostly VPN related).
- The `host:port` entries to be used by PowerDNS recursor config are
normalized eagerly at the point of loading VyOS `Config` instead of
doing them lazily while rendering the Jinja2 template to keep the
implementation less intrusive. The alternative would entail making
quite a bit of change in how 'vyos-hostsd' processes 'static'
'name_servers' entries or persists their runtime states.
|
|
regex
|
