| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit 2dc11253e46b945adb392c5946fd9ad43f391d86)
|
|
(cherry picked from commit b64b45c6a5b66b8d6b07ab5a03fccaeabb3677a9)
|
|
|
|
IPv6 enable can be considered once the ipv6 node is present!
|
|
Commit a2ac9fac ("vyos.template: T2720: always enable Jinja2 trim_blocks
feature") globally enabled the trim_blocks feature. Some templates still used
in-line trim_blocks "{%"- or "-%}" which caused miss-placed line endings.
This is fixed by removing all in-line trim_block statememnts of Jinja2 templates.
|
|
DHCPv6 client was not started as it used the old dict keys.
|
|
|
|
Commit 65fa21f5e ("ifconfig: T2653: move pppoe interface to get_config_dict()")
directly takes the configuration keys from the CLI config and thus the keys
used for template generation have not been updated appropriately.
|
|
Commit 03fb97 (pppoe: ipv6: T2681: script bugfix after get_config_dict() migration )
After the PPPoE link is reset, dhcp6c cannot be restarted,
which may cause the prefix delegation of IPv6 to fail to restart.
This submission will restart dhcp6c after the IPv6 of PPPoE is up again
|
|
Commit 65fa21f5 ("ifconfig: T2653: move pppoe interface to get_config_dict()")
did not rename the Jinja2 template vars as required as they are not retrieved
directly as dict from the config backend.
|
|
|
|
|
|
|
|
Commit 8dcf042a7f5 ("pppoe: T2219: move adding of default route to ip-(up|down)
script") wrongly tried to open a file called autoconfigure which infact
should be autoconf
|
|
|
|
Rename the CLI nodes for prefix delegation from "dhcpv6-options delegate
<interface>" to "dhcpv6-options prefix-delegation interface <interface>".
The change is required to add the possibility to request for specific prefix
sized via the CLI. That option was not possible with the old configuration
tree.
|
|
|
|
|
|
|
|
As PPP can be used to establish a connection on-demand it manages the Kernel
default route. This can not be used when using VRFs which are managed by
the ip-up.d and ip-down.d scripts - thus those options are now mutially
exclusive.
The best fix would be adding support for VRFs into PPP.
|
|
|
|
|
|
As PPPoE interfaces should be part of a VRF it is required that the default
can also be set into the specified VRF. The default way of PPP by setting the
"defaultroute" option does not take a VRF into account. In this case PPP
installs a Kernel route forwarding all default traffic over this interface.
This change installs a static route with metric 1 instead into the routing
table via FRR. This is not the same as a Kernel route in terms of metric 1
compared to 0 but it should do the trick.
|
|
This makes the actual code which generates the configs much more human
readable.
|
