mirror/labs-bird
1
0
Fork 0
mirror of https://gitlab.labs.nic.cz/labs/bird.git synced 2024-05-11 16:54:54 +00:00
Code Releases Activity

Do not initialize route metrics in import_control hook

Browse Source 
During route export, the receiving protocol often initialized route
metrics to default value in its import_control hook before export filter
was executed. This is inconsistent with the expectation that an export
filter would process the same route as one in the routing table and it
breaks setting these metrics before (e.g. for static routes directly in
static protocol).

The patch removes the initialization of route metrics in import_control
hook, the default values are already handled in rt_notify hook called
after export filters.

The patch also changed the behavior of OSPF to keep metrics when a route
is reannounced between OSPF instances (to be consistent with other
protocols) and the behavior when both ospf_metric1 and ospf_metric2
are specified (to have more expected behavior).
This commit is contained in:
Ondrej Zajicek (work)
2018-05-24 14:51:05 +02:00
parent b24b781117
commit feae132e0f
5 changed files with 47 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
doc/bird.sgml
View File

@@ -1618,9 +1618,7 @@ regarded as empty bgppath/*clist for most purposes.
The optional attribute that can be used to specify a distance to the
network for routes that do not have a native protocol metric attribute
(like <cf/ospf_metric1/ for OSPF routes). It is used mainly by BGP to
compare internal distances to boundary routers (see below). It is also
used when the route is exported to OSPF as a default value for OSPF type
1 metric.
compare internal distances to boundary routers (see below).
</descrip>
<p>There also exist protocol-specific attributes which are described in the
@@ -3536,8 +3534,15 @@ protocol ospf [v2|v3] &lt;name&gt; {
with internal <cf/metric/, a <cf/metric of type 2/ is always longer than any
<cf/metric of type 1/ or any <cf/internal metric/. <cf/Internal metric/ or
<cf/metric of type 1/ is stored in attribute <cf/ospf_metric1/, <cf/metric type
2/ is stored in attribute <cf/ospf_metric2/. If you specify both metrics only
metric1 is used.
2/ is stored in attribute <cf/ospf_metric2/.
When both metrics are specified then <cf/metric of type 2/ is used. This is
relevant e.g. when a type 2 external route is propagated from one OSPF domain to
another and <cf/ospf_metric1/ is an internal distance to the original ASBR,
while <cf/ospf_metric2/ stores the type 2 metric. Note that in such cases if
<cf/ospf_metric1/ is non-zero then <cf/ospf_metric2/ is increased by one to
ensure monotonicity of metric, as internal distance is reset to zero when an
external route is announced.
<p>Each external route can also carry attribute <cf/ospf_tag/ which is a 32-bit
integer which is used when exporting routes to other protocols; otherwise, it