| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
Commit dafb0da2 ("static: T4883: add a description field for routing tables")
added an iproute2 description table but lacked checking if the key exists.
This has been fixed and also converted to Jinja2 to keep the "common" style
inside the routing protocols. It might feel overengineered indeed.
|
|
|
|
present for DHCP
VyOS 1.4 still leverages PPPd internals on the CLI.
pppd supports three options for a default route, none, auto, force.
* none: No default route is installed on interface up
* auto: Default route is only installed if there is yet no default route
* force: overwrite any default route
There are several drawbacks in this design for VyOS and the users. If auto is
specified, this only counted for static default routes - but what about dynamic
ones? Same for force, only a static default route got replaced but dynamic ones
did not got taken into account.
The CLI is changed and we now re-use already existing nodes from the DHCP
interface configuration:
* no-default-route:
On link up no default route is installed, same as the previous
default-route none
* default-route-distance:
We can now specify the distance of this route for the routing table on the
system. This defaults to 210 as we have for DHCP interfaces. All this will be
migrated using a CLI migration script.
|
|
|
|
|
|
|
|
|
|
An ISC DHCP hook script is used to install the received default route into FRR
by simple calls to vtysh. By moving to frr-reload.py the DHCP default route
was deleted as it was not found in the running config.
This commit checks all interfaces if DHCP is enabled and if so - will dynamically
add the route to the generated FRR configuration.
|
|
|
|
|
|
|
|
Removing the Zebra/Linux Kernel route-map added by "set protocols static route-map"
was not removed once applied. This was because the removal must happen within
the zebra daemon and not staticd.
|
|
The introduction of key_mangling=('-', '_') when working with get_config_dict()
caused more harm then good. This commit extends common helpers and adds new
helpers when verifying the existence of route-maps, access-lists or prefix-lists.
|
|
|
|
|
|
When leaking routes to a VRF ensure that the VRF we are leaking to exists.
|
|
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.
|
|
With commit 015651a8 ("T2638: Enable more debugging in the FRR library") a
global debug mechanism was added by creating a file named /tmp/vyos.frr.debug.
With this change we can drop the duplicated debug code from every protocol.
|
|
new CLI
|
