Problem Description
===================
A routing metric is a quantitative value used to evaluate the path cost.
But neutron can't specify a different metric with the same destination address,which is useful to realize FRR(Fast Reroute) in Telecoms and NFV scenario.
There is no optional argument for metric:
root@ubuntudbs:/home/dbs# neutron router-update --help
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
usage: neutron router-update [-h] [--name NAME] [--description DESCRIPTION]
[--admin-state-up {True,False}]
[--distributed {True,False}]
[--route destination=CIDR,nexthop=IP_ADDR | --no-routes]
ROUTER
root@ubuntudbs:/home/dbs# openstack router set --help
usage: openstack router set [-h] [--name <name>] [--description <description>]
[--enable | --disable]
[--distributed | --centralized]
[--route destination=<subnet>,gateway=<ip-address>]
[--no-route] [--ha | --no-ha]
[--external-gateway <network>]
[--fixed-ip subnet=<subnet>,ip-address=<ip-address>]
[--enable-snat | --disable-snat] [--tag <tag>]
[--no-tag]
<router>
Proposal
========
A new optional argument metric can be added to set the metric for the routes.
This value can be set by the user or have a default value.
Command Line Client Impact
--------------------------
::
openstack router set [--route destination=<subnet>,
gateway=<ip-address>,
metric=<metric>] <router>
neutron router-update [--route destination=CIDR,
nexthop=IP_ADDR,
metric=METRIC | --no-routes] ROUTER
Argument metric is optional.
REST API Impact
---------------
A new API extension to the routes resource is going to be introduced.
Set the metric for the routes :
.. code-block:: python
PUT /v2.0/routers/{router_id}
Accept: application/json
{
"router": {
"routes": [
{
"destination": "179.24.1.0/24",
"nexthop": "172.24.3.99"
"metric": "100"
}
]
}
}
References
==========
.. [1] api-ref for the neutron router,
https://developer.openstack.org/api-ref/network/v2/index.html#routers-routers
That means we may owns multiple routes with different Routers, one link down, the backup one can hold on. I think it is valid in real case, but for namespaced baesd reference implementation, it's hard to find some good usecases. Could u provider some more usecases? Do you use other L3 backend? :)