Hi Lukas,
On Sun, Jan 14, 2024 at 6:23 AM Lukas Haase <lukasha...@gmx.at> wrote:
>
> Hi Alex,
>
> > Gesendet: Samstag, 13. Januar 2024 um 06:31 Uhr
> > Von: "Alexander Zubkov" <gr...@qrator.net>
> > An: "Lukas Haase" <lukasha...@gmx.at>
> > Cc: bird-users@network.cz
> > Betreff: Re: Exporting a larger prefix if a smaller prefix is being exported
> >
> > Hi,
> >
> > You cannot do "direct" prefix aggregation to a lager prefix in Bird
> > yet. But there are some ways to workaround it. You can define a static
> > route with recursive nex-hop like 192.0.2.x, and filter it out when it
> > is not reachable, but for any subprefix in /24 you would need to
> > define 256 of such static routes. So it is up to you how practical it
> > is.
>
> Interesting idea, this would be practical for me but I do not completely
> understand yet what you mean.
> Which routes would I define and what would be the next hop ("like 192.0.2.x")?
>
> As an example, suppose the following prefixes are in my routing table and are
> directly or indirectly reachable: 192.0.2.208/28, 192.0.2.250/31,
> 192.0.2.184/29, 192.0.2.254/31, 192.0.2.176/29.
>
> Are you proposing?
>
> protocol static prefix_aggregation
> {
> route 192.0.2.0/24 via 192.0.2.209;
> route 192.0.2.0/24 via 192.0.2.250;
> route 192.0.2.0/24 via 192.0.2.285;
> route 192.0.2.0/24 via 192.0.2.254;
> route 192.0.2.0/24 via 192.0.2.177;
> }
Yes, something like that. But it needs to be "recursive" not "via".
And your routes need not to be recursive already (for example iBGP
makes such routes by default), because double recursion won't work.
>
> If so, how do I avoid that 192.0.2.0/24 will be exported five times?
Yes, you'll have multiple similar routes. But if you do not have
add-path on your BGP session, only one of them will be exported. Also
in the recent version there is some aggregation support of same-net
prefixes, it can be helpful here too.
> And how do I set up an export filter on "next-hop is not reachable"?
You need to check the corresponding attribute of the prefix. See the
example later.
>
> By the way, the sub-prefixes, would I just export via a filter like this?
Yes, this filter seems to cover the sub-prefixes. But not sure what is
the nature of this question.
>
> export filter {
> if (net ~ [192.0.2.0/24{25,32}]) then {
> accept;
> }
> reject;
> }
>
Here is a config example I can imagine, not tested it at all.
Something like that works for us. But I would test it first that it
correctly adds/reverts the "aggregated" prefix. It adds static
prefixes in a separate table, but it can also be done in the main
table and reachability tested in bgp export filter for example.
ipv4 table aggr;
protocol static prefix_aggregation
{
ipv4 { table aggr4; };
route 192.0.2.0/24 recursive 192.0.2.209;
...
}
protocol pipe pipe_aggr
{
table master4;
peer table aggr;
export filter {
if (net ~ [192.0.2.0/24{25,32}]) then {
accept;
}
reject;
};
import filter {
if dest = RTD_UNREACHABLE then reject;
if (net = 192.0.2.0/24) then accept;
reject;
};
}
> Thanks,
> Luke
>
>
>
> > You can also make some external daemon watching your kernel routes
> > and adding/deleting the aggregate route to the table.
> >
> > Regards,
> > Alexander
> >
> > On Sat, Jan 13, 2024 at 2:05 AM Lukas Haase via Bird-users
> > <bird-users@network.cz> wrote:
> > >
> > > Hi,
> > >
> > > Is is somehow possible to export a larger prefix if one or more
> > > sub-prefixes (subnets) are exported ... but also remove that prefix if no
> > > smaller subnet exist any more?
> > >
> > > Example: As soon as 192.0.2.44/32 or 192.0.2.208/28 (or any other prefix
> > > inside 192.0.2.0/24) is exported via eBGP, also export prefix
> > > 192.0.2.0/24. If no sub-prefixes are left, also remove 192.0.2.0/24 from
> > > export.
> > >
> > > Background for my question is BGP. As is well known, the smallest prefix
> > > I can announce over eBGP is /24. I use bird as a border gateway and I
> > > announce various smaller prefixes via iBGP. The smaller prefixes will
> > > take precedence in my peering neighboring AS but the /24 is required to
> > > announce my network farther out.
> > >
> > > But why would I want that? Because there are actually two border
> > > gateways. If all internal links to one of these gateways breaks, the full
> > > subnet should not be announced any more (otherwise the traffic would be
> > > dropped). If at least one subnet is announced, I assume that the internal
> > > mesh is strong enough to find its way.
> > >
> > >
> > > Thanks,
> > > Luke
> > >
> > >
> >
