<div dir="ltr">Maybe I'm getting confused...<br><br>But in other engines I basically use MED as an inheritance from igp_metric.<br>Combine that with cumulative med, and that's all I've needed to get by so far.<br>I honestly don't remember ever looking at igp_metric as something other than MED.<br><br>But maybe that's an overly simplistic view on my part.</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Em sex., 14 de mar. de 2025 às 06:58, Maria Matejka via Bird-users <<a href="mailto:bird-users@network.cz">bird-users@network.cz</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg-4583489013993869145"><u></u>


  
  
  
  

<div>
<p>Dear BIRD users,</p>
<p>we’d like to do a public survey about naming things. In short, there
are two different route attributes in BIRD 2:</p>
<ul>
<li>The whole route’s total metric from here to the destination, if set
explicitly by <code>igp_metric = N</code> in filters. I.e., a generic
alternative to protocol-specific IGP metrics like
<code>ospf_metric1</code> or <code>babel_metric</code>.</li>
<li>Metric of the route’s part between here and
<code>bgp_next_hop</code>, determined by recursive next hop resolution.
I.e., from<br>
that route which resolved the recursive next hop, the value in the first
meaning of <code>igp_metric</code> is taken and stored here.</li>
</ul>
<p><strong>Both of these two attributes are internally named
<code>igp_metric</code> in BIRD 2.</strong> However, only the first one
is accessible by filters. When rewriting the attribute handling code for
BIRD 3, I merged them together. This is technically not a bug per se and
for now, yet it behaves weirdly in corner cases and confuses people.</p>
<p>We plan to split these attributes back in BIRD 3, but we don’t want
(and technically also can’t) use the same name any more.</p>
<p><strong>How to name these two attributes better?</strong></p>
<p>Looking forward to your suggestions and opinions.</p>
<p>Happy routing!<br>
Maria and the BIRD Team</p>
<hr>
<p>Follows longer explanation on IGP metric, feel free to skip that.</p>
<p>What’s the IGP metric? Let’s consider an iBGP route, received from a
BGP peer in the same AS, via a multihop session. This route’s next hop
is often not locally known and has to be resolved by finding a matching
route (let’s call that route an IGP route) and using that route’s
nexthop, as expected by RFC 4271, section 5.1.3. We call such a
situation “recursive nexthop”.</p>
<p>Such a route pair then may look like follows (shortened):</p>
<pre><code>2001:db8:2::/48      unicast [ibgp3 <removed> from 10.1.4.1] * (100/40) [AS65532i]
        via fe80::386c:8fff:feb8:206c on ve1
        hostentry: via 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9 table master6
        bgp_next_hop: 2001:db8:1:13::2 fe80::585b:d3ff:febd:1dd9
        igp_metric: 40
        source: BGP
2001:db8:1:13::/64   unicast [ospf6 <removed>] * I (150/40) [10.0.1.4]
        via fe80::386c:8fff:feb8:206c on ve1
        ospf_metric1: 40
        source: OSPF</code></pre>
<p>The <code>bgp_next_hop</code> attribute is non-local, and there is
another route able to resolve that attribute to the local next hop. That
route’s metric is transferred to the BGP route as
<code>igp_metric</code>. In BIRD 2, that’s just an internal value,
displayed on the first line as (100/40), which is preference (100) and
the IGP metric (40).</p>
<p>But you may also have a static route instead of the OSPF one:</p>
<pre><code>protocol static {
    ipv6;
    route 2001:db8:1:13::/64 via fe80::386c:8fff:feb8:206c dev ve1 { igp_metric = 40; };
}</code></pre>
<p>Here the <code>igp_metric</code> semantics is the whole route’s
metric. This metric can then be used in next hop resolution and applied
to the BGP route. And in the BGP route, there will be this
<code>igp_metric</code> attribute copied, representing only the metric
from here to <code>bgp_next_hop</code>.</p>
<p>–<br>
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</div>

</div></blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>