<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="generator" content="pandoc" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
<style>
html {
line-height: 1.2;
font-family: serif;
font-size: 0.9em;
color: black;
background-color: white;
}
body {
margin: 0;
margin-right: auto;
max-width: 36em;
padding: 1em;
hyphens: auto;
overflow-wrap: break-word;
text-rendering: optimizeLegibility;
font-kerning: normal;
}
@media print {
body {
background-color: transparent;
color: black;
font-size: 11pt;
}
p, h2, h3 {
orphans: 3;
widows: 3;
}
h2, h3, h4 {
page-break-after: avoid;
}
}
p {
margin: 1em 0;
}
a {
color: black;
}
a:visited {
color: black;
}
img {
max-width: 100%;
}
h1, h2, h3, h4, h5, h6 {
margin-top: 1.4em;
}
h5, h6 {
font-size: 1em;
font-style: italic;
}
h6 {
font-weight: normal;
}
ol, ul {
padding-left: 1.7em;
margin-top: 1em;
}
li > ol, li > ul {
margin-top: 0;
}
blockquote {
margin: 0.5em;
padding-left: 0.5em;
border-left: 2px solid #e6e6e6;
color: #444;
}
code {
font-family: 'Lucida Console', monospace;
font-size: 95%;
margin: 0;
}
pre {
margin: 1em 0;
overflow: auto;
max-width: unset;
width: fit-content;
}
pre code {
padding: 0;
overflow: visible;
overflow-wrap: normal;
max-width: unset;
white-space: pre-wrap;
}
pre code span {
white-space: pre;
}
.sourceCode {
background-color: transparent;
overflow: visible;
}
code.diff span.kw,
code.diff span.dt {
font-weight: bold;
}
code.diff span.va {
background-color: rgba(192, 255, 192, 64);
color: rgb(0, 64, 0);
}
code.diff span.st {
background-color: rgba(255, 192, 192, 64);
color: rgb(64, 0, 0);
}
pre.diff {
background-color: rgb(240, 240, 240);
padding: 0.4em;
border: 1pt solid grey;
}
hr {
background-color: black;
border: none;
height: 1px;
margin: 1em 0;
}
table {
margin: 1em 0;
border-collapse: collapse;
width: 100%;
overflow-x: auto;
display: block;
font-variant-numeric: lining-nums tabular-nums;
}
table caption {
margin-bottom: 0.75em;
}
tbody {
margin-top: 0.5em;
border-top: 1px solid black;
border-bottom: 1px solid black;
}
th {
border-top: 1px solid black;
padding: 0.25em 0.5em 0.25em 0.5em;
}
td {
padding: 0.125em 0.5em 0.25em 0.5em;
}
header {
margin-bottom: 4em;
text-align: center;
}
code{white-space: pre-wrap;}
span.smallcaps{font-variant: small-caps;}
span.underline{text-decoration: underline;}
div.column{display: inline-block; vertical-align: top; width: 50%;}
div.hanging-indent{margin-left: 1.5em; text-indent: -1.5em;}
ul.task-list{list-style: none;}
q { quotes: "„" "”" "»" "«"; }
.display.math{display: block; text-align: center; margin: 0.5rem auto;}
</style>
</head>
<body>
<p>¡Hola!</p>
<p>On Fri, Nov 21, 2025 at 01:37:57PM +0100, Maximilian Wilhelm via
Bird-users wrote:</p>
<blockquote>
<blockquote>
<blockquote>
<ul>
<li><ol start="2" type="a">
<li>filter output vs. export reality Independent of whether we filter on
“all best” or “all routes”, in the CLI the filter output shown does
include the route - if the filter does not match, it also should not
print it</li>
</ol></li>
</ul>
</blockquote>
<p>Well, if you do <code>show route filter xyz</code>, then you get all
routes matching that filter. Some protocols pick them. You can do
<code>show route export bgp_to_internet.ipv6</code> to explicitly re-run
the export filter in that context.</p>
<p>I know that it is kinda confusing, and we should probably improve our
documentation to show this properly.</p>
</blockquote>
<p>A <code>show route primary filter xyz</code> should also be
equivalent to what’s actually exported, right?</p>
</blockquote>
<p>Almost! It is, in that case, equivalent to what <em>should</em> be
exported if there was no preexport limitation. The most prominent case
is back-export to Pipe and BGP; these two protocols reject their own
routes, while others (e.g. Babel) accept them.</p>
<p>With that, you need this:</p>
<pre><code>show route primary filter xyz preexport bgp_to_internet.ipv6</code></pre>
<p>Starting with BIRD 3, some routes might be also export-pending
because BGP runs in different threads than the CLI. This isn’t reflected
in any output for now because that information is performance sensitive
and almost impossible to access ad-hoc safely.</p>
<p>We also expect to add protocol contexts, and as soon as this happens,
you would need something like</p>
<pre><code>show route primary filter xyz preexport bgp_to_internet.ipv6 context { ... }</code></pre>
<p>to match <code>show route export bgp_to_internet.ipv6</code>
output.</p>
<p>Last but not least, if you change your filters but call
<code>configure soft</code>, the affected channels do not reload at all,
and therefore to find out which routes were actually exported, you may
ask for</p>
<pre><code>show route exported bgp_to_internet.ipv6</code></pre>
<p>but if the export filter did any changes, it’s already lost because
the export filter is forgotten with the reconfiguration. Only if you
have <code>export table on</code>, then you may ask for</p>
<pre><code>show route export table bgp_to_internet.ipv6</code></pre>
<p>and it actually shows not only what has been exported but also it may
tell you what has been exported but not yet sent to the peer. Not only
that, in BIRD 3, this call works always, and with
<code>export table off</code>, it shows exactly the routes which have
not yet been sent into the TCP socket.</p>
<p>And that’s been quite an infodump which may have left you even more
confused but now at least it’s dumped.</p>
<p>We should definitely do some major updates to the documentation.</p>
<p>Maria</p>
<p>–<br />
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.</p>
</body>
</html>