vyos-1x.git/data/templates/pppoe/ip-up.script.tmpl, branch feature/T9082-codeql-cppVyOS command definitions, scripts, and utilities (mirror of https://github.com/vyos/vyos-1x.git)
https://git.amelek.net/vyos/vyos-1x.git/atom?h=feature%2FT9082-codeql-cpp2022-05-01T18:27:07+00:00pppoe: T4353: fix Jinja2 linting errors2022-05-01T18:27:07+00:00Christian Poessingerchristian@poessinger.com2022-05-01T18:27:07+00:00urn:sha1:644a0fe475b137185ada36a6b7a0ca43259f1d0avyos.template: T2720: fix remaining in-line time_block syntax2020-11-28T07:25:39+00:00Christian Poessingerchristian@poessinger.com2020-11-28T07:25:39+00:00urn:sha1:c87ad948999c28c3c9449f98d60b545481ea29d5
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.
pppoe: T2585: use cleaner template expression2020-07-08T18:30:59+00:00Christian Poessingerchristian@poessinger.com2020-07-08T18:30:59+00:00urn:sha1:1c6ea07e995f22949205c15b884287fc174f0998pppoe: T2585: fix template for on-demand dialing2020-07-08T18:27:56+00:00Christian Poessingerchristian@poessinger.com2020-07-08T18:26:20+00:00urn:sha1:17e9f97cbbc713bd01876296ed2c5505909b7766
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.
ifconfig: T2653: move pppoe interface to get_config_dict()2020-07-01T17:06:56+00:00Christian Poessingerchristian@poessinger.com2020-06-30T14:52:00+00:00urn:sha1:65fa21f5e79114fa861d99eae154baad35ce2f11pppoe: T2502: fix Jinja2 template indention2020-05-26T19:16:31+00:00Christian Poessingerchristian@poessinger.com2020-05-26T19:16:31+00:00urn:sha1:4519918bb9bf65f042e280281692e816e4566ef4pppoe: T2502: "default-route none" option had no effect2020-05-26T15:04:49+00:00Christian Poessingerchristian@poessinger.com2020-05-25T19:19:12+00:00urn:sha1:76d87858be1fc2a261f7bc94d915c08b47b49e92pppoe: T2248: connect-on-demand and vrf are mutually exclusive2020-04-10T11:31:18+00:00Christian Poessingerchristian@poessinger.com2020-04-10T11:28:46+00:00urn:sha1:927c98f23a6317e2e3565032023d68b753d71037
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.
pppoe: T2219: support adding default route to VRF2020-04-04T16:52:15+00:00Christian Poessingerchristian@poessinger.com2020-04-04T16:52:15+00:00urn:sha1:6e0e210920de7984ec4e655cd679ab8c66dfebe5pppoe: T2219: move adding of default route to ip-(up|down) script2020-04-04T11:46:38+00:00Christian Poessingerchristian@poessinger.com2020-04-04T11:46:38+00:00urn:sha1:8dcf042a7f58dfac590b28174dc1d9b87ce5a893
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.