Re: [BIRD] Upgrade Debian

[Maria Matejka via Bird-users]

Hello Jakub,

running BIRD 1 is not recommended anymore as the team has moved to supporting 
BIRD 2 and the upcoming BIRD 3. We can't help you with possible problems and 
you aren't getting any new features since 2019.

The best way forward here is to upgrade to BIRD 2(.15.1). 

Best regards,
Maria



On 13 October 2024 18:35:39 CEST, Jakub Osuch  wrote:
>Dear BIRD community
>I would like to upgrade Debian with BIRD. 10 to 11 and finally to 12.
>
>I have several VM Debian  machines without BIRD   and this tutorial works
>for me.
>https://www.cyberciti.biz/faq/update-upgrade-debian-11-to-debian-12-bookworm/
>
>Can I upgrade my servers Debian 10 with BIRD 1.6.6 to new Debian and BIRD
>1.6.8 without problems ?
>
>
>-- 
>Jakub Osuch
>mobile +48501203739
>www.techgroup.pl

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: case & string

[Maria Matejka via Bird-users]

Hello,

On Thu, Oct 10, 2024 at 07:30:10PM +0300, Mikhail Mayorov wrote:
 
> I was try configure dynamic peers . But I can't known context of which the
> filter is executed. I need to identify the neighbor with whom I have a
> session.
> 
> To do this, I was forced to abandon dynamic neighbors and create a separate
> config for each neighbor. This is certainly not difficult, but very
> inconvenient. Moreover, the filtering process is also very important for
> marking routes by different communities. I didn't find any mechanisms to do
> this with dynamic neighbors. Probably this option is not very popular with
> the community and it is rarely used. Or maybe I'm just being stupid. :)

Neither of the proposed reasons. It's quite hard to include this feature
in the filters properly to not make BIRD slower for the largest IXPs like
DE-CIX, or ix.br just by implementing that.

Also, it's easy to include _something_ to resolve among different
protocols, and there is known demand for such a feature. Yet,
implementing it the easy way now induces painful years of maintaining
the dirty hack afterwards because people start using it. And I love my
future self enough to not do this intentionally. It's enough with all
the compromise solutions we have to come up with in the regular
development.

Considering all of that, there are basically two major options how to
get this feature into BIRD:

- put a substantial amount of your time into developing it yourself the
  proper way, while consulting it on the way with the core team
- getting enough companies to pay for BIRD Support to let the team grow
  and as a consequence do this faster

Last but not least, we may implement this anyway quite soon, as the
MRT+BMP in BIRD 3 (not yet merged into thread-next) now passes basic
tests and there is some code review in progress. This, and several bugs
reported earlier (thank you all for testing!) is what blocks us from
releasing BIRD 3, and nothing in the queue looks like imposing another
year of work on us.

As soon as BIRD 3 gets released as stable, a substantial part of the
team is probably going to switch attention to new features, also made
easier by the refactored and reconstructed BIRD's Nest. And you may be
completely sure that we are very very tired now from doing all of the
invisible stuff on optimizations and performance improvements, so we'll
happily pick any opportunity to do something nice, new and shiny.

Happy routing! 
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD is not prepending ASN on EBGP export.

[Maria Matejka via Bird-users]

Hello,

you basically want one router to prepend two ASNs for one hop,
if I understand correctly. That's not an intuitive / default-worthy
behavior.

On Thu, Oct 10, 2024 at 10:20:51AM +, Ochalski, Radoslaw via Bird-users 
wrote:

> Here you have same route exported via Juniper border, local ASN 20940 is 
> prepended by default:
> 
> inet.0: 955317 destinations, 2138917 routes (950415 active, 218793 holddown, 
> 14419 hidden)
>   Prefix  Nexthop  MED LclprefAS path
> * 20.135.0.0/16   Self20940 8075 I
> 
> vs bird:
> 
> BGP.as_path: 8075
> 
> [truncated]

BIRD shows the route after filters but _before_ BGP applies the export
modifications, which includes prepending the local AS to the AS path iff
the session is EBGP. I expect that Juniper is showing the route
as-it-goes-to-the-wire.

BIRD 2 doesn't allow showing routes that way; this is possible in BIRD 3
with `export table on` by showing routes from the export table.

If you capture tcpdump from BIRD, you'll see the AS prepended.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Link-local address change in Blackhole routing

[Maria Matejka via Bird-users]

Hello,

iirc setting bgp_next_hop to something new should discard the LL address 
altogether. (Sitting at a meeting, not checking.)

M


On 4 October 2024 12:41:24 CEST, ushi...@ate-mahoroba.jp wrote:
>Hi
>
>I am aware that IPv4 next-hop / IPv6 next-hop global can be achieved by 
>changing bgp_next_hop when Blackhole Community is applied.
>I believe that if we notify the next-hop of only global, the link-local in the 
>FIB will remain the same as the peer's address even though the RIB has 
>changed, resulting in unintended behavior, and I believe that the link-local 
>address needs to be changed.
>
>Is it possible to change the link-local address in Bird?
>
>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Paths Limit for Multiple Paths in BGP

[Maria Matejka via Bird-users]

>> After reading the draft, I understand that the actual algorithm on how
>> to choose the set of paths to be sent, is outside the scope of the
>> document. I consider this a major problem which may lead to hard-to-fix
>> long-term traffic loops between differing implementations.
>
>That mostly depends on usage pattern, and if the set of announced paths
>contains the best path, then routing loops would be transient, like
>if you send just one path.

… until the best path gets discarded by a filter on the receiving side, and 
then the result is completely random.

>> There are thoughts on actually implementing this in BIRD. 
>> Regarding the current development priorities, this is expected to be
>> implemented (if it actually happens) in BIRD 3 only, and only after we
>> implement some more structural changes in the route storage. Otherwise,
>> this is going to be a performance nightmare.
>
>Well, it is not really much different from 'secondary' option - have some
>ordering of available paths, announce the first N paths vs. announce the
>first path that pass filters.

There is already a performance problem if the total number of paths is too big, 
as reloading one single path has avg linear cache misses in the number of other 
paths for that prefix just to find the old record. And adding R paths for one 
prefix to the sorted table is now avg O(R²) in comparisons.

With exports, let's consider the best route flap slowly. This induces one 
withdraw, one update from the tail in O(R) cache misses, and then one update 
(the best one being added) and one withdraw from the tail, again with O(R) 
cache misses.

If, instead of a flap, ROA status changes and all the export filters have to be 
recalculated, we are in the quadratic orders again.

I'm not saying it's impossible, i'm concerned about implementing this in v2, 
and would prefer an efficient implementation for v3 later.

Maria


-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Paths Limit for Multiple Paths in BGP

[Maria Matejka via Bird-users]

Hello Donatas!

On Wed, Oct 02, 2024 at 02:29:40PM +0300, Donatas Abraitis wrote:

> I hope this is the right place to ask for feature requests.

Yes, it is!

> Would you mind adding this [1]draft  to your TODO (/ feature) list?

After reading the draft, I understand that the actual algorithm on how
to choose the set of paths to be sent, is outside the scope of the
document. I consider this a major problem which may lead to hard-to-fix
long-term traffic loops between differing implementations.

With that, there should be _some_ definition of how to choose the paths
to send, to avoid getting straightforward implementations sending
"just some" N routes they find. One option is like this:

- while `N > 0`:
  - run the standard best route selection algorithm
  - remove the selected route from the original set
  - if the selected route passes export filters:
- put the selected route into the final set
- `N -= 1`

This can result in announcing up to N routes when 1 route gets updated,
so one has to expect some funny behavior with this feature. But it is
stable, can be reasonably tested, and it won't yield random funny
network mess dependent on the order of announcement arrival.

There are thoughts on actually implementing this in BIRD. 
Regarding the current development priorities, this is expected to be
implemented (if it actually happens) in BIRD 3 only, and only after we
implement some more structural changes in the route storage. Otherwise,
this is going to be a performance nightmare.

> I've heard some [2]people are already missing (= would benefit) this draft.

Maybe the first suggestion for them is to reach out to us with the
underlying problem which they are trying to solve, as there may be
different solutions than implementing a not-well-defined feature.

Thank you for your message, have a nice day! 
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: router_id or source neighbor in import/export filter for dynamic BGP peers

[Maria Matejka via Bird-users]

On Fri, Sep 27, 2024 at 06:05:47PM +0200, Alexander Zubkov via Bird-users wrote:

> It seems to me that Mikhail wants to know the protocol information, in
> context of which the filter is executed. And he also wants it in the export
> filter, to know protocol/peer/etc.

Yeah, it looks like this, and sadly, we don't have such information
easily available for now.

Implementing this is in our backlog and we are basically overwhelmed
with other overdue tasks (like finalizing the multithreading, EVPN or
TCP-AO). It is expectable to get this somewhere around BIRD 3.2 or 3.3
(take me with a grain of salt please).

It is quite easy to expose _something_ by some hacks but it would mean
polluting the filters and configuration by yet another inconsistent
feature which we then would have to maintain for much longer than
acceptable.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: router_id or source neighbor in import/export filter for dynamic BGP peers

[Maria Matejka via Bird-users]

Hello,

On Fri, Sep 27, 2024 at 02:48:07PM +0300, Mikhail Mayorov wrote:

> I use dynamic BGP peers in my RR. It's very simple and comfortable.
> import/export filters are same for all dynamic neighbors. How to determine a
> neighbor? Using what variables?

I would expect that in common cases, the neighbor would be also in the
`bgp_next_hop` attribute. Is that not this case?

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: interface to BGP

[Maria Matejka via Bird-users]

Hello!

Your config only _allows_ this prefix to be exported but doesn't load it from 
anywhere.

If any address of 192.0.2.0/24 is assigned to a local interface, you may 
generate the route by "protocol direct".

If you added the route to kernel by hand, you can use "learn" inside the 
"protocol kernel" block.

Last but not least, you may just create the route with "protocol static".

Maria

On 19 September 2024 22:17:57 CEST, alpha_one_x86 
 wrote:
>Hi, I try export 192.0.2.0/24 to BGP into a test env. Why not work?
>
>I attach my config file
>
>root@fake-asn1:~# birdc show protocol all
>BIRD 1.6.8 ready.
>name proto    table    state  since   info
>kernel1  Kernel   master   up 20:08:35
> Preference: 10
> Input filter:   ACCEPT
> Output filter:  ACCEPT
> Routes: 0 imported, 0 exported, 0 preferred
> Route change stats: received   rejected   filtered    ignored   accepted
>   Import updates:  0  0  0  0  0
>   Import withdraws:    0  0    ---  0  0
>   Export updates:  0  0  0    ---  0
>   Export withdraws:    0    ---    ---    ---  0
>
>device1  Device   master   up 20:08:35
> Preference: 240
> Input filter:   ACCEPT
> Output filter:  REJECT
> Routes: 0 imported, 0 exported, 0 preferred
> Route change stats: received   rejected   filtered    ignored   accepted
>   Import updates:  0  0  0  0  0
>   Import withdraws:    0  0    ---  0  0
>   Export updates:  0  0  0    ---  0
>   Export withdraws:    0    ---    ---    ---  0
>
>IXP  BGP  master   up 20:08:40    Established
> Preference: 100
> Input filter:   (unnamed)
> Output filter:  (unnamed)
> Routes: 0 imported, 0 exported, 0 preferred
> Route change stats: received   rejected   filtered    ignored   accepted
>   Import updates:  0  0  0  0  0
>   Import withdraws:    0  0    ---  0  0
>   Export updates:  0  0  0    ---  0
>   Export withdraws:    0    ---    ---    ---  0
> BGP state:  Established
>   Neighbor address: 172.23.0.1
>   Neighbor AS:  65501
>   Neighbor ID:  172.23.0.1
>   Neighbor caps:    refresh enhanced-refresh restart-aware llgr-aware AS4
>   Session:  external AS4
>   Source address:   172.23.1.0
>   Hold timer:   128/240
>   Keepalive timer:  8/80
>
>root@fake-asn1:~# route -n -4
>Kernel IP routing table
>Destination Gateway Genmask Flags Metric Ref    Use Iface
>172.23.0.0  0.0.0.0 255.255.0.0 U 0  0    0 eth0
>192.0.2.0   0.0.0.0 255.255.255.0   U 0  0    0 ethFAKE
>
>-- 
>alpha_one_x86/BRULE Herman
>Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and 
>server management
>IT, OS, technologies, research & development, security and business department

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Info about eBGP/iBGP

[Maria Matejka via Bird-users]

Hello Grzegorz,

On Thu, Sep 19, 2024 at 06:11:18PM +, Ponikierski, Grzegorz via Bird-users 
wrote:

> According to my knowledge letter “i” in “[AS201701i]” means “IGP”. “e” is for 
> “EGP” and “?” is for “INCOMPLETE”. This is for BGP origin code.
> 
> Other method to check eBGP vs iBGP is to check which protocol learned
> given route and then verify configuration of protocol or do `show
> protocol all` to figure out if it was eBGP or iBGP session. It works
> but it is indirect method which requires extra steps. It would be
> useful and timesaving that `show route` shows this information
> directly. Is it problem with proper “print” function for “show route”
> or Bird just don’t keep such info together with route due to
> performance issues or memory saving?

BIRD doesn't keep this information with the route as it can be derived
from the protocol importing it.

Please note that it is the user who specifies which session is eBGP or
iBGP, and thus you can include this fact directly in the protocol name
to reflect this difference.

Also, after introducing our new API (not yet existing), this can be done
easily in the client just by loading both the protocol and route dump
and combining them to get you anything you want.

Happy Routing! 
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: xxxx.ipv4: Automatic RPKI reload not active for import

[Maria Matejka via Bird-users]

On Wed, Sep 11, 2024 at 11:07:52AM +0900, ushi...@ate-mahoroba.jp wrote:

> Thank you, as always, for your quick answers!
> 
> Currently using RPKI functionality and calls roa_check().
> 
> Allowing the output of warning messages and
> 
> RPKI reload is ON and import table on is not defined.
> 
> I am thinking of doing this.
> Is this a problem?

You simply won't get the autoreload as the warning says. To get the
autoreload for BGP, you need import table on. Thus, if ROA changes, it's
your responsibility to manually request route refresh from possibly
all your peers.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: xxxx.ipv4: Automatic RPKI reload not active for import

[Maria Matejka via Bird-users]

> > Therefore you can use import table, the only problem will be that if you
> > show routes from the import table, you should disregard what is shown as
> > the local nexthop.
> 
> The logs “Cannot reconfigure channel  .ipv4” and “Cannot
> reconfigure channel  .ipv6” that are output when the import table
> on <-> import table off setting is changed and the logs ” Restarting
> protocol ” logs, but does it mean that when the import table
> setting is changed, a restart is performed?

Yes. You have to fill the table with something, and although it could be
technically possible to refill it just by requesting route refresh, it
seems that nobody actually implemented this fast track, so it's resolved
by restarting the peer.

It should not be too difficult to implement, yet with the BIRD 3
upcoming (where the import table is implemented differently) this may
get a little bit trickier. If there is anybody willing to do it, just
let us know please to get some hints and directions.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: xxxx.ipv4: Automatic RPKI reload not active for import

[Maria Matejka via Bird-users]

Hello!

On Fri, Sep 06, 2024 at 10:18:34PM +0900, ushi...@ate-mahoroba.jp wrote:

> The warning log is outputting something like “ .ipv4: Automatic 
> RPKI reload not active for import”.
> 
> I am using roa_check() and rpki_reload switch is set to default (on).
> 
> The help page on “rpki reload switch” says that the BGP channel requires 
> import table for automatic reload, so I am aware that if I add the definition 
> of “import table on”, this warning will no longer appear.
> 
> However, in the help section on “import table switch
> Note that currently the import table breaks routes with recursive nexthops 
> (e.g. ones from IBGP, see gateway recursive (p. 47)), they are not properly 
> updated after next hop change.
> and we have not been able to fully determine the contents of this message.

This applies to the import table contents where the recursive nexthops
don't get updated properly. The main table contents is not affected.

Therefore you can use import table, the only problem will be that if you
show routes from the import table, you should disregard what is shown as
the local nexthop.

> Is there any way around this warning other than “import table switch”?

You can switch off rpki autoreload but this is not recommended at all.
It's better to enable the import table.

Happy routing!

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

RE: Bird 2.14 Starts but Won't Bind to Port 179

[Maria Matejka via Bird-users]

You are missing the

protocol kernel { ipv6 { export all; }; }

bit to actually do the synchronization with the kernel.


On 1 August 2024 22:35:14 CEST, Eric Robinson  wrote:
>It’s not quite working yet. The bird console shows the default route…
>
>[root@fw9b ~]# birdc
>BIRD 2.14 ready.
>bird> show route
>Table master4:
>0.0.0.0/0unicast [isp1 13:29:52.523] * (100) [AS23222i]
>via 4.4.92.130 on red0
> unicast [isp2 13:29:52.491] (100) [AS23222i]
>via 4.4.92.131 on red0
>bird>
>
>…but it does not show up to the OS, and the outside world is not pingable.
>
>[root@fw9b ~]# ip route
>192.168.5.0/24 dev green0 proto kernel scope link src 192.168.5.10
>4.4.92.128/28 dev red0 proto kernel scope link src 4.4.92.140
>
>
>From: Maria Matejka 
>Sent: Thursday, August 1, 2024 3:23 PM
>To: Eric Robinson ; bird-users@network.cz
>Subject: RE: Bird 2.14 Starts but Won't Bind to Port 179
>
>It looks like working. It accepts the default route while refusing to export 
>it back which is expected to happen.
>
>
>Maria
>
>On 1 August 2024 21:48:36 CEST, Eric Robinson 
>mailto:eric.robin...@psmnv.com>> wrote:
>I added that and it listens now!
>
>I’m not sure what to make of the log notices, though.
>
>2024-08-01 12:43:15.036  isp2: Started
>2024-08-01 12:43:15.036  isp2: Connect delayed by 5 seconds
>2024-08-01 12:43:15.036  isp1: Started
>2024-08-01 12:43:15.036  isp1: Connect delayed by 5 seconds
>2024-08-01 12:43:19.073  isp1: Connecting to  from local 
>address 
>2024-08-01 12:43:19.074  isp1: Connected
>2024-08-01 12:43:19.074  isp1: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:19.078  isp1: Connection lost (Connection reset by 
>peer)
>2024-08-01 12:43:19.078  isp1: Connect delayed by 5 seconds
>2024-08-01 12:43:19.287  isp2: Connecting to from local 
>address 
>2024-08-01 12:43:19.288  isp2: Connected
>2024-08-01 12:43:19.288  isp2: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:19.494  isp2: Got OPEN(as=23005,hold=180,id=)
>2024-08-01 12:43:19.494  isp2: Sending KEEPALIVE
>2024-08-01 12:43:19.495  isp2: Got KEEPALIVE
>2024-08-01 12:43:19.495  isp2: BGP session established
>2024-08-01 12:43:19.495  isp2: State changed to up
>2024-08-01 12:43:19.495  isp2: Sending END-OF-RIB
>2024-08-01 12:43:19.536  isp2: Got UPDATE
>2024-08-01 12:43:19.536  isp2.ipv4 > added [best] 0.0.0.0/0 0L 2G 
>unicast
>2024-08-01 12:43:19.536  isp2.ipv4 < rejected by protocol 0.0.0.0/0 0L 
>2G unicast
>2024-08-01 12:43:23.578  isp1: Connecting to  local address 
>
>2024-08-01 12:43:23.578  isp1: Connected
>2024-08-01 12:43:23.578  isp1: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:23.782  isp1: Got OPEN(as=23005,hold=180,id=)
>2024-08-01 12:43:23.782  isp1: Sending KEEPALIVE
>2024-08-01 12:43:23.783  isp1: Got KEEPALIVE
>2024-08-01 12:43:23.783  isp1: BGP session established
>2024-08-01 12:43:23.783  isp1: State changed to up
>2024-08-01 12:43:23.783  isp1.ipv4 < filtered out 0.0.0.0/0 0L 2G 
>unicast
>2024-08-01 12:43:23.783  isp1: Sending END-OF-RIB
>2024-08-01 12:43:23.788  isp1: Got UPDATE
>2024-08-01 12:43:23.788  isp1.ipv4 > added [best] 0.0.0.0/0 0L 3G 
>unicast
>2024-08-01 12:43:23.788  isp2.ipv4 < filtered out 0.0.0.0/0 0L 3G 
>unicast
>2024-08-01 12:43:23.788  isp1.ipv4 < rejected by protocol 0.0.0.0/0 0L 
>3G unicast
>2024-08-01 12:43:29.463  isp2: Got UPDATE
>2024-08-01 12:43:29.463  isp2: Got END-OF-RIB
>2024-08-01 12:43:33.765  isp1: Got UPDATE
>2024-08-01 12:43:33.765  isp1: Got END-OF-RIB
>2024-08-01 12:44:09.966  isp2: Sending KEEPALIVE
>2024-08-01 12:44:18.548  isp1: Sending KEEPALIVE
>2024-08-01 12:44:29.465  isp2: Got KEEPALIVE
>2024-08-01 12:44:33.766  isp1: Got KEEPALIVE
>2024-08-01 12:44:57.910  isp2: Sending KEEPALIVE
>
>It seems to add the default route, then reject it?
>
>-Eric
>
>From: Eric Robinson
>Sent: Thursday, August 1, 2024 2:26 PM
>To: Maria Matejka mailto:maria.mate...@nic.cz>>; 
>bird-users@network.cz; 
>bird-users@network.cz
>Subject: RE: Bird 2.14 Starts but Won't Bind to Port 179
>
>I do not. Following is the whole config. (The IPs and ASNs are bogus.)
>
>Our need is simple. We don’t need to advertise any routes. We just need to get 
>the default route from the ISP and ignore everything else.
>
>[root@fw9b etc]# cat bird.conf
>log "/var/log/bird.log" all;
>
>router id 4.4.92.140;
>
>protocol bgp isp1 {
>description "BGP with ISP Router 1";
>local as 65111;
>neighbor 4.4.92.130%red0 as 23222;
>debug all;
>ipv4 {
>import filter {
>if net = 0.0.0.0/0 then accept;
>reject;
>};
>export none; # Do not export any routes to ISP
>next hop self;
>};
>}
>
>protocol bgp isp2 {
>description "BGP with ISP Router 2";
>local as 65111;
>neighbor 4.4.92.131%red0 as 2

RE: Bird 2.14 Starts but Won't Bind to Port 179

[Maria Matejka via Bird-users]

It looks like working. It accepts the default route while refusing to export it 
back which is expected to happen. 


Maria

On 1 August 2024 21:48:36 CEST, Eric Robinson  wrote:
>I added that and it listens now!
>
>I’m not sure what to make of the log notices, though.
>
>2024-08-01 12:43:15.036  isp2: Started
>2024-08-01 12:43:15.036  isp2: Connect delayed by 5 seconds
>2024-08-01 12:43:15.036  isp1: Started
>2024-08-01 12:43:15.036  isp1: Connect delayed by 5 seconds
>2024-08-01 12:43:19.073  isp1: Connecting to  from local 
>address 
>2024-08-01 12:43:19.074  isp1: Connected
>2024-08-01 12:43:19.074  isp1: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:19.078  isp1: Connection lost (Connection reset by 
>peer)
>2024-08-01 12:43:19.078  isp1: Connect delayed by 5 seconds
>2024-08-01 12:43:19.287  isp2: Connecting to from local 
>address 
>2024-08-01 12:43:19.288  isp2: Connected
>2024-08-01 12:43:19.288  isp2: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:19.494  isp2: Got OPEN(as=23005,hold=180,id=)
>2024-08-01 12:43:19.494  isp2: Sending KEEPALIVE
>2024-08-01 12:43:19.495  isp2: Got KEEPALIVE
>2024-08-01 12:43:19.495  isp2: BGP session established
>2024-08-01 12:43:19.495  isp2: State changed to up
>2024-08-01 12:43:19.495  isp2: Sending END-OF-RIB
>2024-08-01 12:43:19.536  isp2: Got UPDATE
>2024-08-01 12:43:19.536  isp2.ipv4 > added [best] 0.0.0.0/0 0L 2G 
>unicast
>2024-08-01 12:43:19.536  isp2.ipv4 < rejected by protocol 0.0.0.0/0 0L 
>2G unicast
>2024-08-01 12:43:23.578  isp1: Connecting to  local address 
>
>2024-08-01 12:43:23.578  isp1: Connected
>2024-08-01 12:43:23.578  isp1: Sending 
>OPEN(ver=4,as=65526,hold=240,id=d8735c8c)
>2024-08-01 12:43:23.782  isp1: Got OPEN(as=23005,hold=180,id=)
>2024-08-01 12:43:23.782  isp1: Sending KEEPALIVE
>2024-08-01 12:43:23.783  isp1: Got KEEPALIVE
>2024-08-01 12:43:23.783  isp1: BGP session established
>2024-08-01 12:43:23.783  isp1: State changed to up
>2024-08-01 12:43:23.783  isp1.ipv4 < filtered out 0.0.0.0/0 0L 2G 
>unicast
>2024-08-01 12:43:23.783  isp1: Sending END-OF-RIB
>2024-08-01 12:43:23.788  isp1: Got UPDATE
>2024-08-01 12:43:23.788  isp1.ipv4 > added [best] 0.0.0.0/0 0L 3G 
>unicast
>2024-08-01 12:43:23.788  isp2.ipv4 < filtered out 0.0.0.0/0 0L 3G 
>unicast
>2024-08-01 12:43:23.788  isp1.ipv4 < rejected by protocol 0.0.0.0/0 0L 
>3G unicast
>2024-08-01 12:43:29.463  isp2: Got UPDATE
>2024-08-01 12:43:29.463  isp2: Got END-OF-RIB
>2024-08-01 12:43:33.765  isp1: Got UPDATE
>2024-08-01 12:43:33.765  isp1: Got END-OF-RIB
>2024-08-01 12:44:09.966  isp2: Sending KEEPALIVE
>2024-08-01 12:44:18.548  isp1: Sending KEEPALIVE
>2024-08-01 12:44:29.465  isp2: Got KEEPALIVE
>2024-08-01 12:44:33.766  isp1: Got KEEPALIVE
>2024-08-01 12:44:57.910  isp2: Sending KEEPALIVE
>
>It seems to add the default route, then reject it?
>
>-Eric
>
>From: Eric Robinson
>Sent: Thursday, August 1, 2024 2:26 PM
>To: Maria Matejka ; bird-users@network.cz; 
>bird-users@network.cz
>Subject: RE: Bird 2.14 Starts but Won't Bind to Port 179
>
>I do not. Following is the whole config. (The IPs and ASNs are bogus.)
>
>Our need is simple. We don’t need to advertise any routes. We just need to get 
>the default route from the ISP and ignore everything else.
>
>[root@fw9b etc]# cat bird.conf
>log "/var/log/bird.log" all;
>
>router id 4.4.92.140;
>
>protocol bgp isp1 {
>description "BGP with ISP Router 1";
>local as 65111;
>neighbor 4.4.92.130%red0 as 23222;
>debug all;
>ipv4 {
>import filter {
>if net = 0.0.0.0/0 then accept;
>reject;
>};
>export none; # Do not export any routes to ISP
>next hop self;
>};
>}
>
>protocol bgp isp2 {
>description "BGP with ISP Router 2";
>local as 65111;
>neighbor 4.4.92.131%red0 as 23222;
>debug all;
>ipv4 {
>import filter {
>if net = 0.0.0.0/0 then accept;
>reject;
>};
>export none; # Do not export any routes to ISP
>next hop self;
>};
>}
>
>From: Maria Matejka mailto:maria.mate...@nic.cz>>
>Sent: Thursday, August 1, 2024 2:18 PM
>To: bird-users@network.cz; Eric Robinson 
>mailto:eric.robin...@psmnv.com>>; 
>bird-users@network.cz
>Subject: Re: Bird 2.14 Starts but Won't Bind to Port 179
>
>Hello,
>
>do you have
>protocol device {}
>in your config?
>
>Maria
>
>On 1 August 2024 20:41:23 CEST, Eric Robinson 
>mailto:eric.robin...@psmnv.com>> wrote:
>
>Bird starts, and claims that it is waiting for the upstream routers to become 
>neighbors…
>
>2024-07-31 06:25:25.774 isp1: Initializing
>2024-07-31 06:25:25.774 isp2: Initializing
>2024-07-31 06:25:25.774 isp1: Starting
>2024-07-31 06:25:25.774 isp1: State changed to start
>2024-07-31 06:25

Re: Bird 2.14 Starts but Won't Bind to Port 179

[Maria Matejka via Bird-users]

Hello,

do you have
protocol device {}
in your config?

Maria

On 1 August 2024 20:41:23 CEST, Eric Robinson  wrote:
>Bird starts, and claims that it is waiting for the upstream routers to become 
>neighbors...
>
>2024-07-31 06:25:25.774 isp1: Initializing
>2024-07-31 06:25:25.774 isp2: Initializing
>2024-07-31 06:25:25.774 isp1: Starting
>2024-07-31 06:25:25.774 isp1: State changed to start
>2024-07-31 06:25:25.774 isp2: Starting
>2024-07-31 06:25:25.774 isp2: State changed to start
>2024-07-31 06:25:25.774 Started
>2024-07-31 06:25:25.775 isp2: Waiting for 4.4.92.131 to become my neighbor
>2024-07-31 06:25:25.775 isp1: Waiting for 4.4.92.130 to become my neighbor
>
>...however, I can see in tcpdump that bird is refusing BGP connections...
>
>08:50:31.055601 IP 4.4.92.130.34302 > 4.4.92.140.179: Flags [S], seq 
>733565924, win 16384, options [mss 1424,wscale 0,nop,sackOK,eol], length 0
>08:50:31.056685 IP 4.4.92.140.179 > 4.4.92.130.34302: Flags [R.], seq 0, ack 
>733565925, win 0, length 0
>
>...and that's because bird is not listening...
>
>[root@fw9b log]# netstat -ant
>Active Internet connections (servers and established)
>Proto Recv-Q Send-Q Local Address Foreign Address State
>tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
>tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
>tcp 0 0 127.0.0.1:8953 0.0.0.0:* LISTEN
>tcp6 0 0 :::1013 :::* LISTEN
>tcp6 0 0 :::444 :::* LISTEN
>tcp6 0 0 :::81 :::* LISTEN
>
>Bird is running...
>
>[root@fw9b log]# ps ax|grep bird
>20738 pts/0 S+ 0:00 grep bird
>29732 ? Ss 0:00 /usr/sbin/bird
>Strace shows that it is not binding to the port.
>
>I read a full thread about this exact symptom here: 
>https://bird.network.cz/pipermail/bird-users/2020-September/014824.html
>
>Unfortunately, I'm brand new to bird and I was unable to follow some of it.
>
>-Eric
>
>
>Disclaimer : This email and any files transmitted with it are confidential and 
>intended solely for intended recipients. If you are not the named addressee 
>you should not disseminate, distribute, copy or alter this email. Any views or 
>opinions presented in this email are solely those of the author and might not 
>represent those of Physician Select Management. Warning: Although Physician 
>Select Management has taken reasonable precautions to ensure no viruses are 
>present in this email, the company cannot accept responsibility for any loss 
>or damage arising from the use of this email or attachments.

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird 1.6 Debian 10 update to Debian 12

[Maria Matejka via Bird-users]

No such tool exists as it's not simple to make an algorithm do it. Also we 
expected that people had already upgraded as there are better filters and 
overall more features in BIRD 2.

Anyway, there has been a talk recently about how to do that, you may start 
there probably.

https://ripe87.ripe.net/archives/video/1135/

Maria



On 27 July 2024 20:54:26 CEST, Jakub Osuch  wrote:
>Do You have a tool to change config from 1.6.8 to 2.5.1 ?
>
>Jakub Osuch
>mobile +48501203739
>www.techgroup.pl
>
>
>
>W dniu sob., 27.07.2024 o 20:45 Maria Matejka 
>napisał(a):
>
>> Hello Jakub,
>>
>> there are apparently still bird 1.6.8 packages available even for trixie
>> but please note that you are running a discontinued version.
>>
>> Upgrade to 2.15.1 is recommended.
>>
>> Maria
>>
>>
>> On 27 July 2024 20:00:01 CEST, Jakub Osuch 
>> wrote:
>>
>>> Hi
>>> Now I use Debian 10 with Bird 1.6
>>> Can I upgrade Debian 10 to 12 ?
>>>
>>>
>>>
>>> --
>> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird 1.6 Debian 10 update to Debian 12

[Maria Matejka via Bird-users]

Hello Jakub,

there are apparently still bird 1.6.8 packages available even for trixie but 
please note that you are running a discontinued version.

Upgrade to 2.15.1 is recommended.

Maria


On 27 July 2024 20:00:01 CEST, Jakub Osuch  wrote:
>Hi
>Now I use Debian 10 with Bird 1.6
>Can I upgrade Debian 10 to 12 ?
>
>
>
>-- 
>Jakub Osuch
>mobile +48501203739
>www.techgroup.pl

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: EVPN IRB - RFC 9135 support

[Maria Matejka via Bird-users]

Hello Erik,

On Fri, Jul 12, 2024 at 01:30:06PM +0200, Erik Stomp via Bird-users wrote:

> If I don't miss anything, the current EVPN implementation does't support
> EVPN IRB as described in RFC 9135.
> Since I only want to use BIRD EVPN in a lab, this is not a big problem for
> me. Of course I could use FRR, which supports IRB, but since I use BIRD
> everywhere, it would be nice if I could also use it in the EVPN lab.

Honestly, I'm now unaware of what is exactly supported as it's still in
development but Santiago should know, cc-ing him.

> So my question is: Are there any plans to implement RFC 9135 in the
> foreseable future? I know, this isn't a 5 minute task and fully understand
> if it's not planned due to low priority.

Basically the EVPN implementation depends on companies requesting this
feature while having BIRD Support. This way, if you were into persuading
your employer to migrate from FRR to BIRD …

… contact me off-list with more details and a quote for BIRD Support.

Have a nice weekend! 
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: if Birdc have hook when bgp &/bfd failover

[Maria Matejka via Bird-users]

Hello!

On Fri, Jun 14, 2024 at 05:50:41PM +, LIU Chris via Bird-users wrote:

> Now I want to write application, which could get inform/posted when bgp/bfd 
> failover, Is there hook or event?

No. Mechanisms like this are currently in a design and prototyping
phase. Also, we are very much first aiming to implement a working API
for route dumps as this is the most critical thing requested from us by
most of the customers of BIRD Support.

It's not easy to implement these hooks properly without impeding
performance on hot paths. It also takes a lot of time and effort to
design it all maintainable for the next, let's say, another 25 years.

We're very thankful for every company willing to get BIRD Support. These
companies are moving the development forward while also getting direct
line for resolving their technical problems discreetly and with
priority.

The most convenient way for now is to set `debug { states };` in the bfd
and bgp and then just parse logs by some ugly regexes.

Hoping that this helps.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: IPv6 BFD interop with Huawei, checksum 0 UDP

[Maria Matejka via Bird-users]

Hello!

On Wed, Jun 12, 2024 at 06:32:10PM +0700, Ville O wrote:

> At least some Huawei devices use a checksum of 0 for all IPv6 BFD UDP
> packets after finishing Poll/Final.
> All packets sent with states other than Up or with flags other than C
> have the correct checksums.
>
> [...]
> 
> This issue could be worked around on the BIRD side at least on the
> Linux platform.
> RFC6936 allows [3] for hosts to enable accepting IPv6 UDP with a
> checksum of 0 and this is implemented in Linux kernels from 3.16 with
> sockopt "UDP_NO_CHECK6_RX".
> I have tested that this indeed works: checksum 0 packets are received
> to AF_INET6, SOCK_DGRAM sockets when it is enabled.
> 
> I wonder if it would be acceptable to enable this option on the IPv6
> socket(s) used for BFD in BIRD, if supported by the platform?

Patches welcome. It should be configurable and off by default. For more
information on how to contribute, see the contributing guidelines:

https://gitlab.nic.cz/labs/bird/-/blob/master/CONTRIBUTING.md

Thank you for raising awareness about this issue.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: [Routing Issue] There are two same net range routing on routing table.

[Maria Matejka via Bird-users]

Hello!

Which version of BIRD and Linux kernel are you running?
Could you please share your configuration file and
dump of `show route all`?

Thanks,

Maria

On Mon, Jun 03, 2024 at 10:31:25AM +0900, 이재용 wrote:
> Hello,
> 
> We use BIRD for communication with servers with higher-level switches.
> 
> But recently we came across the following case:
> server run as a ecmp routing.
> 10.171.0.0/24 proto bird
> nexthop via 10.171.0.25 dev p0 weight 1
>     nexthop via 10.171.1.25 dev p1 weight 1
> For a change higher-level switches, we adjusted our ibgp LP value to flow 
> traffic as a one path.  As we expected, servers routing are changed as one 
> path routing 
> 10.171.0.0/24 proto bird
> but, one server has a two same net range routing. like this sample
> case1) 
> 10.171.0.0/24 proto bird10.171.0.0/24 proto bird metric 32
> nexthop via 10.171.0.25 dev ${interface1} 
>     nexthop via 10.171.1.25 dev ${interface2} 
> case2 )
> 10.171.0.0/24 proto bird metric 3210.171.0.0/24 proto bird
> nexthop via 10.171.0.25 dev ${interface1} 
>     nexthop via 10.171.1.25 dev ${interface2} 
> in case1, there was any problem , but in case 2 it had. (flow packet as two 
> paths)in my thought, pervious routing not deleted. So, two same range is now 
> avaliable.if there are someone who have same problem, would you advise for 
> this problem? 
> 

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: bird BFD is DOWN

[Maria Matejka via Bird-users]

Hello!

On first sight this looks like Fortinet ignoring the packets. Maybe (wild 
guess) you have a firewall rule in place dropping them in the Fortinet?

Maria

On 7 June 2024 21:51:28 CEST, LIU Chris via Bird-users  
wrote:
>Classified as: {Hitachi Rail – Public}
>
>My setup :
>Linux running bird， Peer:  Fortinet Firewall
>
>In bird, configure bfd as below:
>
>protocol bfd BFD_SD_01 {
>interface "*" {
>   min rx interval 100 us;
>   min tx interval 100 us;
>  idle tx interval 100 ums;
>  multiplier 3;
>};
>neighbor 192.168.0.1 local 192.168.0.2;
>}
>
>Fortinet side, biasally same, also set rx intrva: 1000 ms, tx interval: 
>1000ms,  multiplier: 3
>However, both side show bfd DOWN。
>Catpure tcpdump in Fortinet side,  Fortinet IP: 192.168.0.1
>   Time source  destination protocolinfo
>1  0.00 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>6  0.756375 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>11 1.519796 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>14 2.351177 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>19 3.225686 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>24 3.852938 192.168.0.1 192.168.0.2 BFD Control Diag: Control Detection Time 
>Expired, State: Down, Flags: 0x00
>25 3.981126 192.168.0.2 192.168.0.1 BFD Control Diag: No Diagnostic, State: 
>Down, Flags: 0x00
>
>from Fortinet neighbour information, it seems cannot receive control message 
>from Peer, why? I don't have any block port. Why get detection time: 1500ms 
>after neighboation
>Below is fortinet bfd neighbor information
>OurAddress NeighAddress State Interface LDesc/RDesc
>192.168.0.1 192.168.0.2 DOWN STN2-SD-A 1/0/M
>Local Diag: 1, Demand mode: no, Poll bit: unset
>MinTxInt: 1000, MinRxInt: 1000, Multiplier: 3
>Received: MinRxInt: 0 (ms), MinTxInt: 0 (ms), Multiplier: 3
>Transmit Interval: 6500 (ms), Detection Time: 1500 (ms)
>Rx Count: 0, Rx Interval; (ms) min/max/avg 0/0/0
>Tx Count: 10287, Tx Interval (ms) min/max/avg 5000/5030/5000, last: 2350 (ms) 
>ago
>Registered protocols: Static BGP
>
>Is this bird issue or fortinet?  I suspect 80% caused by Fortiet, but I just 
>want to get some suggestion/proposal from bird expert.
>
>With Best Regards,
>Chris LIU
>
>Hitachi Rail – Public
>
>
>{Hitachi Rail – Public}

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: bird BGP debug issue

[Maria Matejka via Bird-users]

Hello!

On Fri, May 31, 2024 at 11:29:12PM +, LIU Chris via Bird-users wrote:

> I configured BGP with peer, which is Fortinet device. Both of sides show BGP 
> status established, however, there is no route exchanged.
> Start bird daemon with -D log_file, but only see some keepalive, no other 
> debug message come out.
> 
>   1.  Is it possible to increase debug level, see more logs to figure out the 
> root cause ?
>   2.  Generally how to debug this kind of BGP issue, any suggestion is 
> appreciated ?
>
> ```
> protocol bgp BGP_INSTANCE {
>   debug all;
> }
> ```

You may want also `ipv6 { … debug { routes }; };`

Also you have to set up your filters on both sides.

If you share your `show proto all` CLI command output and/or your full
config file, we may help you better.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BGP Confederation Internal ASN Filtering and is_bogon() Functionality in New BIRD Version

[Maria Matejka via Bird-users]

Hello Brandon,

On Thu, May 30, 2024 at 09:52:53PM +0800, Brandon Zhi wrote:
 
> I am writing to inquire about the capabilities of the new version of BIRD
> regarding BGP Confederation internal ASNs. Specifically, I would like to
> know:
> 
> 1. Can the new BIRD version filter BGP Confederation internal ASNs?
> 2. Does it support calculating the total AS path length, including internal
> ASNs within a BGP Confederation?

You are probably looking for something like `bgp_path.filter()` or
`bgp_path.len`, or maybe `for int p in bgp_path do { … }`

> Additionally, I have encountered an issue while using the `is_bogon()`
> function. It currently filters a route with the AS path (65000) 398741. I
> suspect this is because (65000) is being treated as a BOGON ASN.
>
> Below is the `define BOGON_ASNS` I am using:
> 
> ```plaintext
> define BOGON_ASNS = [
> 0,  # RFC 7607
> 23456,  # RFC 4893 AS_TRANS
> 64496..64511,   # RFC 5398 and documentation/example ASNs
> 64512..65534,   # RFC 6996 Private ASNs
> 65535,  # RFC 7300 Last 16 bit ASN
> 65536..65551,   # RFC 5398 and documentation/example ASNs
> 65552..131071,  # RFC IANA reserved ASNs
> 42..4294967294, # RFC 6996 Private ASNs
> 4294967295  # RFC 7300 Last 32 bit ASN
> ];
> ```

Yes, this includes 65500. I can't see your `is_bogon()` function
definition though so I can't help you more.

Hoping that this helps.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: use TCP_NODELAY on TCP sockets?

[Maria Matejka via Bird-users]

Hello Douglas,

just a really fast response, we aren't going to implement BGP over QUIC
at all, at least when TLS is a required part of QUIC.

There are some thoughts about BGP 5 being encoded as CBOR and sent over
something like QUIC, anyway it doesn't make any sense to introduce QUIC
to BGP now.

Maria

On Thu, May 16, 2024 at 09:45:56AM -0300, Douglas Fischer wrote:

> I'm not a programmer, and I know almost nothing about it...
> 
> But reading this thread, I remembered this draft about BGP-over-QUIC.
> https://datatracker.ietf.org/doc/draft-retana-idr-bgp-quic/
> 
> I'm not sure what I'm going to say, but I have the impression that the
> session closure control method that will be chosen may have something to do
> with this BoQ idea.
> 
> I don't even know if what I'm saying makes any sense or not.
> But if you do, it may be something that you have to take into consideration
> when choosing the method.
> 
> And besides, there are many other "ifs"...
> We don't even know if this Draft will actually become an RFC. And if it
> becomes RFC, we don't even know if it will have traction.
> We also don't know if the IBRD project will adhere to this protocol, etc...
> 
> But, I thought it was opportune to mention.
> 
> Em qui., 16 de mai. de 2024 às 07:59, Ondrej Zajicek 
> escreveu:
> 
> > On Wed, May 15, 2024 at 06:37:18PM +0200, Job Snijders via Bird-users
> > wrote:
> >
> > > Dear BIRD people,
> > >
> > > On most systems RFC 896 TCP congestion control is used, also known as
> > > "Nagle's algorithm". This algorithm is intended to help coalesce
> > > consecutive small packets from userland applications (like BIRD) into a
> > > single larger TCP packet. The idea being it reduces bandwidth because
> > > there is less TCP overhead if data is bundled into fewer packets.
> > > ...
> > > I think using TCP_NODELAY is interesting to consider, because it seems
> > > sensible to try to deliver BGP messages as fast as possible. OpenBGPD
> > > and FRR set the TCP_NODELAY socket option.
> >
> > Hi
> >
> > Yeah, i think that using TCP_NODELAY for BGP makes sense, considering
> > there is already non-trivial framing and we write individual BGP messages
> > with one write().
> >
> > --
> > Elen sila lumenn' omentielvo
> >
> > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
> > "To err is human -- to blame it on a computer is even more so."
> >
> 
> 
> -- 
> Douglas Fernando Fischer
> Engº de Controle e Automação

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Cannot locate output from "birdc dump"

[Maria Matejka via Bird-users]

Hello Christian,

On Mon, May 13, 2024 at 11:06:03PM +0200, christian2 wrote:
> I would like to inspect BIRD's neighbor cache with "birdc dump
> neighbors". However, I can see no ouput. There are appearances of
> " CLI: dump neighbors" in the configured log file but no actual
> dumps. This is also true for "dump resources" and "dump protocols"
> (even though "show protocols" does list several protocols). What am I
> missing? This is for BIRD 2.15.1.

This output goes to the debug file which has to be enabled on startup by
the -D or -d option.

Sadly, we don't have any means to enable it in runtime. This is probably
going to change in future and these dumps may go probably to a file
which name you would have to supply. But it is not there yet.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: bird2 doesn't negotiate with gobgp over ipv6

[Maria Matejka via Bird-users]

You may wish to have v6 nexthops for v4 prefixes though – to enable these, set 
"extended next hop" in the BGP channel config.

Maria


On 5 May 2024 09:45:32 CEST, Vladimir Pouzanov  wrote:
>On Sun, May 5, 2024 at 7:35 AM Maria Matejka  wrote:
>
>> The error message actually means "you requested direct connection but i
>> can't see the right interface to use because there is no interface with
>> this range assigned".
>>
>
>Thanks, that was it!
>
>I must have missed the note in the docs on that, because with ipv4 I just
>had the same subnet, but with ipv6 I don't have a public address assigned
>on the bird side. `multihop 1` Fixed the negotiation issue. I got a few
>more, but those seem to be related to either gobgp sending malformed
>updates (Invalid NEXT_HOP attribute - mismatched address family
>(2a01:xx:yy:zz:4746:92e9:327c:d930 for ipv4)), or the bird configuration
>not being able to parse a `-` in the interface name. Both unrelated to this
>particular issue at hand.

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: bird2 doesn't negotiate with gobgp over ipv6

[Maria Matejka via Bird-users]

Then i was totally wrong with that, sorry.

Now i checked once again the log, and there are actually two different neighbor 
addresses, one ending :fb71, another :d930. This may be some discrepancy in 
your ipv6 settings.

The error message actually means "you requested direct connection but i can't 
see the right interface to use because there is no interface with this range 
assigned".

Maria



On 4 May 2024 17:59:21 CEST, Vladimir Pouzanov  wrote:
>I actually started with my /64 and then expanded to ::/0 to the same result.
>
>On Sat 4 May 2024 at 16:54, Maria Matejka  wrote:
>
>> Not at my computer, just a wild guess – would you try please, instead of
>> ::/0, narrowing the range, e.g. like 2000::/3? I haven't seen the code
>> recently but this may help.
>>
>> Maria
>>
>>
>> On 4 May 2024 17:16:21 CEST, Vladimir Pouzanov 
>> wrote:
>>
>>> Hi!
>>>
>>> I'm running bird 2.15.1 and I'm trying to make it talk to cilium that
>>> uses gobgp under the hood. I can negotiate the session over ipv4 with no
>>> issues, but due to a bug in the cilium implementation, the ipv6 routes
>>> aren't advertised properly. The suggestion from cilium was to negotiate the
>>> session over ipv6, but this creates issues for bird.
>>>
>>> I have a config that looks somewhat like this:
>>>
>>> protocol bgp {
>>>   local port 179 as 65100;
>>>   neighbor range 0::/0 port 179 as 65100 internal;
>>>
>>>   dynamic name "GW6_";
>>>   direct;
>>>   passive;
>>>
>>>   ipv4 {
>>> import all;
>>>   };
>>>
>>>   ipv6 {
>>> import all;
>>>   };
>>> }
>>>
>>> protocol bgp {
>>>   local port 179 as 65100;
>>>   neighbor range 10.0.0.0/8 port 179 as 65100 internal;
>>>
>>>   dynamic name "GW4_";
>>>   direct;
>>>   passive;
>>>
>>>   ipv4 {
>>> import all;
>>>   };
>>>
>>>   ipv6 {
>>> import all;
>>>   };
>>> }
>>>
>>> When I connect to bird over ipv4, gobgp sends a packet like this:
>>>
>>> Frame 4: 154 bytes on wire (1232 bits), 154 bytes captured (1232 bits) on
>>> interface vmbrdev, id 0
>>> Ethernet II, Src: 22:fc:7f:47:6b:f4 (22:fc:7f:47:6b:f4), Dst:
>>> 6e:82:6c:1b:e9:95 (6e:82:6c:1b:e9:95)
>>> Internet Protocol Version 4, Src: 10.224.129.15, Dst: 10.224.129.1
>>> Transmission Control Protocol, Src Port: 39201, Dst Port: 179, Seq: 1,
>>> Ack: 1, Len: 88
>>> Border Gateway Protocol - OPEN Message
>>> Marker: 
>>> Length: 88
>>> Type: OPEN Message (1)
>>> Version: 4
>>> My AS: 65100
>>> Hold Time: 90
>>> BGP Identifier: 10.224.129.15
>>> Optional Parameters Length: 59
>>> Optional Parameters
>>> Optional Parameter: Capability
>>> Parameter Type: Capability (2)
>>> Parameter Length: 57
>>> Capability: Route refresh capability
>>> Type: Route refresh capability (2)
>>> Length: 0
>>> Capability: FQDN Capability
>>> Type: FQDN Capability (73)
>>> Length: 12
>>> Hostname Length: 10
>>> Hostname: dev-master
>>> Domain Name Length: 0
>>> Domain Name:
>>> Capability: Unknown capability 75
>>> Type: Unknown (75)
>>> Length: 13
>>> Unknown: 0c476f4247502f332e32332e30
>>> Capability: Multiprotocol extensions capability
>>> Type: Multiprotocol extensions capability (1)
>>> Length: 4
>>> AFI: IPv4 (1)
>>> Reserved: 00
>>> SAFI: Unicast (1)
>>> Capability: Multiprotocol extensions capability
>>> Type: Multiprotocol extensions capability (1)
>>> Length: 4
>>> AFI: IPv6 (2)
>>> Reserved: 00
>>> SAFI: Unicast (1)
>>> Capability: Support for 4-octet AS number capability
>>> Type: Support for 4-octet AS number capability (65)
>>> Length: 4
>>> AS Number: 65100
>>> Capability: Extended Next Hop Encoding
>>> Type: Extended Next Hop Encoding (5)
>>> Length: 6
>>> AFI: IPv4 (1)
>>> SAFI: Unicast (1)
>>> Next hop AFI: IPv6 (2)
>>>
>>> Which is followed up by OPEN from bird2 and they establish the session.
>>> The logs say:
>>>
>>> May 04 14:47:02 ammy bird[7755]: bgp2: Incoming connection from
>>> 10.224.129.15 (port 39201) accepted
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Initializing
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Starting
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: State changed to start
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Started
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Got
>>> OPEN(as=65100,hold=90,id=10.224.129.15)
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Sending
>>> OPEN(ver=4,as=65100,hold=240,id=0ae08101)
>>> May 04 14:47:02 ammy bird[7755]: GW4_1: Sending KEEPALIVE
>>> Ma

Re: bird2 doesn't negotiate with gobgp over ipv6

[Maria Matejka via Bird-users]

Not at my computer, just a wild guess – would you try please, instead of ::/0, 
narrowing the range, e.g. like 2000::/3? I haven't seen the code recently but 
this may help.

Maria

On 4 May 2024 17:16:21 CEST, Vladimir Pouzanov  wrote:
>Hi!
>
>I'm running bird 2.15.1 and I'm trying to make it talk to cilium that uses
>gobgp under the hood. I can negotiate the session over ipv4 with no issues,
>but due to a bug in the cilium implementation, the ipv6 routes aren't
>advertised properly. The suggestion from cilium was to negotiate the
>session over ipv6, but this creates issues for bird.
>
>I have a config that looks somewhat like this:
>
>protocol bgp {
>  local port 179 as 65100;
>  neighbor range 0::/0 port 179 as 65100 internal;
>
>  dynamic name "GW6_";
>  direct;
>  passive;
>
>  ipv4 {
>import all;
>  };
>
>  ipv6 {
>import all;
>  };
>}
>
>protocol bgp {
>  local port 179 as 65100;
>  neighbor range 10.0.0.0/8 port 179 as 65100 internal;
>
>  dynamic name "GW4_";
>  direct;
>  passive;
>
>  ipv4 {
>import all;
>  };
>
>  ipv6 {
>import all;
>  };
>}
>
>When I connect to bird over ipv4, gobgp sends a packet like this:
>
>Frame 4: 154 bytes on wire (1232 bits), 154 bytes captured (1232 bits) on
>interface vmbrdev, id 0
>Ethernet II, Src: 22:fc:7f:47:6b:f4 (22:fc:7f:47:6b:f4), Dst:
>6e:82:6c:1b:e9:95 (6e:82:6c:1b:e9:95)
>Internet Protocol Version 4, Src: 10.224.129.15, Dst: 10.224.129.1
>Transmission Control Protocol, Src Port: 39201, Dst Port: 179, Seq: 1, Ack:
>1, Len: 88
>Border Gateway Protocol - OPEN Message
>Marker: 
>Length: 88
>Type: OPEN Message (1)
>Version: 4
>My AS: 65100
>Hold Time: 90
>BGP Identifier: 10.224.129.15
>Optional Parameters Length: 59
>Optional Parameters
>Optional Parameter: Capability
>Parameter Type: Capability (2)
>Parameter Length: 57
>Capability: Route refresh capability
>Type: Route refresh capability (2)
>Length: 0
>Capability: FQDN Capability
>Type: FQDN Capability (73)
>Length: 12
>Hostname Length: 10
>Hostname: dev-master
>Domain Name Length: 0
>Domain Name:
>Capability: Unknown capability 75
>Type: Unknown (75)
>Length: 13
>Unknown: 0c476f4247502f332e32332e30
>Capability: Multiprotocol extensions capability
>Type: Multiprotocol extensions capability (1)
>Length: 4
>AFI: IPv4 (1)
>Reserved: 00
>SAFI: Unicast (1)
>Capability: Multiprotocol extensions capability
>Type: Multiprotocol extensions capability (1)
>Length: 4
>AFI: IPv6 (2)
>Reserved: 00
>SAFI: Unicast (1)
>Capability: Support for 4-octet AS number capability
>Type: Support for 4-octet AS number capability (65)
>Length: 4
>AS Number: 65100
>Capability: Extended Next Hop Encoding
>Type: Extended Next Hop Encoding (5)
>Length: 6
>AFI: IPv4 (1)
>SAFI: Unicast (1)
>Next hop AFI: IPv6 (2)
>
>Which is followed up by OPEN from bird2 and they establish the session. The
>logs say:
>
>May 04 14:47:02 ammy bird[7755]: bgp2: Incoming connection from
>10.224.129.15 (port 39201) accepted
>May 04 14:47:02 ammy bird[7755]: GW4_1: Initializing
>May 04 14:47:02 ammy bird[7755]: GW4_1: Starting
>May 04 14:47:02 ammy bird[7755]: GW4_1: State changed to start
>May 04 14:47:02 ammy bird[7755]: GW4_1: Started
>May 04 14:47:02 ammy bird[7755]: GW4_1: Got
>OPEN(as=65100,hold=90,id=10.224.129.15)
>May 04 14:47:02 ammy bird[7755]: GW4_1: Sending
>OPEN(ver=4,as=65100,hold=240,id=0ae08101)
>May 04 14:47:02 ammy bird[7755]: GW4_1: Sending KEEPALIVE
>May 04 14:47:02 ammy bird[7755]: GW4_1: Got KEEPALIVE
>May 04 14:47:02 ammy bird[7755]: GW4_1: BGP session established
>
>When I try to establish the connection over ipv6, gobgp sends an OPEN
>that's exactly the same sans being transferred over ipv6:
>
>Frame 15: 174 bytes on wire (1392 bits), 174 bytes captured (1392 bits) on
>interface vmbrdev, id 0
>Ethernet II, Src: 22:fc:7f:47:6b:f4 (22:fc:7f:47:6b:f4), Dst:
>6e:82:6c:1b:e9:95 (6e:82:6c:1b:e9:95)
>Internet Protocol Version 6, Src: 2a01:xxx:xxx:xxx:xxx:xxx:xxx:d930, Dst:
>fd00::53
>Transmission Control Protocol, Src Port: 58663, Dst Port: 179, Seq: 1, Ack:
>1, Len: 88
>
>and then bird just stalls the connection. The logs say:
>
>May 04 14:49:17 ammy bird[7755]: bgp1: Incoming connection from
>2a01:4f8:173:fe11:6f81:e7cd:2787:fb71 (port 35581) accepted
>May 04 14:49:17 ammy bird[7755]: GW6_1: Initializing
>May 04 14:49:17 ammy bird[7755]: GW6_1: Starting
>May 04 14:49:17 ammy bird[7755]: GW

BIRD at RIPE 88 (May 2024, Kraków)

[Maria Matejka via Bird-users]

Dear BIRD users,

On Sat, Mar 02, 2024 at 02:05:38PM +0100, Maria Matejka via Bird-users wrote:

>  * I'm going to remotely participate at IETF 119 (mid-March). If you
>wanna direct me to any specific working group which I should join,
>feel free to send me a pointer.

I was participating and you may find my discussion points recorded in
various working group recordings, notably IDR and CBOR.

>  * We're planning to attend Euro-IX 40th Forum and RIPE 88 in person
>(more info later).

We're indeed going to be both at Euro-IX 40th Forum and RIPE 88. If you
wish to meet me at RIPE 88 in Kraków, please send me an off-list e-mail,
I'm open for meetings.

Also I'd like to reiterate:

> We're just a small busy team, we can't be everywhere. We very much
> appreciate when anybody presents about using BIRD in any setup. Also, if
> there are any meetings with remote attendance possible where BIRD talks
> happen, or even just recordings, please let us know – we love all the
> feedback! We occasionally get some links. Thank you for all of that!
> 
> Also if you really wish us to be at some meeting, please let us know. As you
> probably can see, we are now trying the cover the main meetings of North
> America and Europe. There are some thoughts about covering other regions,
> not realized yet, with no definitive timelines.
 
With all that, have a nice time and hopefully see you soon!

Happy routing!

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Large communities indicating RPKI VALID status

[Maria Matejka via Bird-users]

Hello Nigel,

you can always store this information to custom attributes which are faster 
than communities, auto-ignored on export and can't leak to your peers.

BTW that guide looks quite outdated (regarding e.g. the support of autoreload) 
and will be even more outdated with BIRD 3 optimized import tables and 
selective autoreload. Noting that we shall look into updating this guide.

Maria

On 27 April 2024 05:05:35 CEST, Nigel Kukard via Bird-users 
 wrote:
>Hi all,
>
>I was busy reading https://bgpfilterguide.nlnog.net/guides/reject_invalids/ 
>and noticed the following text...
>
>Note: REALLY DONT store the validation state inside a bgp_community or 
>bgp_large_community or bgp_ext_community variables. It can cause CPU & memory 
>overload resulting in convergence performance issues.
>
>I was wondering if this is still an issue and if it would still be a bad idea 
>to indicate that RPKI was VALID using communities on multiple full BGP feeds?
>
>Is anyone doing this at present? are you seeing significant load?
>
>Kind Regards
>Nigel
>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird 3 Status

[Maria Matejka via Bird-users]

Hello Marcelo,

On Thu, Apr 18, 2024 at 09:40:52AM -0300, Marcelo Balbinot wrote:

> Could you give us a brief update on the status of version 3 ?

We found some grave bugs in BGP export implementation (which had to be
rewritten to support asynchronous Adj-RIP-Out / export table dumps) so
basically it's delayed by this.

We also did some refactoring, and partially, we had to include the new
features from version 2 which also slowed the process.

>  Do you have any expected dates for a new release !?

For the next release? As soon as we fix the BGP export table, there
should be 3.0alpha3.

For stable? Well, we're postponing it a lot, last estimation for stable
version was December 2023 and as you can see, we aren't there yet.

The problems which we're fixing generally don't manifest when running
BIRD on light loads, but in some corner cases and with high loads, it
either behaves weirdly or crashes. And we want long-term stability, not
that you have to restart your routing layer every other day.

Hoping that this helps you at least a bit.

Have a nice day!

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Current bird via bookworm-backports?

[Maria Matejka via Bird-users]

Hello Oliver,

On Thu, Apr 18, 2024 at 11:24:31AM +0200, Oliver Seufer via Bird-users wrote:

> Hello,
> 
> The version 2.0.12 included in Debian Bookworm unfortunately lacks a few
> current features. I would therefore greatly appreciate it if a Debian package
> with the latest version could be provided. Either through bookworm-backports 
> or
> directly through bird.network.cz

Please try this repository: https://pkg.labs.nic.cz/doc/?project=bird

It should have everything you need.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Fwd: Re: babel RTT metric false samples

[Maria Matejka via Bird-users]

(mistakenly sent off-list)


 Original Message 
From: Maria Matejka 
Sent: 13 April 2024 18:18:05 CEST
To: Erin Shepherd 
Subject: Re: babel RTT metric false samples

Just quick thought – I think both approaches (timestamping in kernel and in 
userspace) are actually useful for different purposes. Thus, we shall support 
both.

Transferred to our internal issue: https://gitlab.nic.cz/labs/bird/-/issues/61

Maria


On 13 April 2024 16:38:47 CEST, Erin Shepherd  
wrote:
>I guess it might not fit with bird's abstractions (or perhaps the Babel 
>protocol), but has thought been given to using SO_TIMESTAMPING to have the 
>kernel compute TX/RX timestamps? 
>
>- Erin
>
>
>On Sat, 13 Apr 2024, at 16:14, Maria Matejka via Bird-users wrote:
>> Hello Stephanie, Toke and list,
>> 
>> On Fri, Apr 12, 2024 at 04:22:50PM +0200, Toke Høiland-Jørgensen via 
>> Bird-users wrote:
>> 
>>> Stephanie Wilde-Hobbs via Bird-users bird-users@network.cz writes:
>>> 
>>>> The babel RTT metric measurements provided by bird appears suspect for my 
>>>> setup. The metric through a tunnel with a latency of about 5ms is shown in 
>>>> babel as 150+ms.
>>>> 
>> […]
>> 
>>>> Debug logs show many RTT samples with approximately correct timestamps 
>>>> (4-6ms) then the occasional IHU with 800-1200ms calculated instead. 
>>>> Calculating the RTT metric by hand using babel packet logs shows that the 
>>>> calculations are correct. By correlating two packet dumps (the machines 
>>>> have <1ms NTP timekeeping) I can also see that the packets for which high 
>>>> RTT is calculated have similar transit times through the tunnel as other 
>>>> packets. Hence, I suspect the accuracy of the packet timestamps recorded 
>>>> by bird. Is the current packet timestamping system giving correct 
>>>> timestamps if the packet arrives while babel is processing another event?
>>>> 
>>> Hmm, so Babel implementation in Bird tries to get a timestamp as early as 
>>> possible after receiving the packet, and set it as late as possible before 
>>> sending out the packet. However, the former in practice means after 
>>> returning from poll(), so if the packet has been sitting around in the OS 
>>> buffer for a while before Bird gets around to process it, the timestamp is 
>>> not set until Bird is done processing it. Likewise, if the packet sits 
>>> around in a socket buffer (or in a lower-level buffer on the sending side) 
>>> after Bird has sent it out, that time will also be counted as part of the 
>>> RTT.
>>> 
>> I would suspect that the kernel table prune routine may be the case. It just 
>> runs from begin to end synchronously.
>> 
>> I have just fast-tracked Babel in its own thread for BIRD 3, it may be worth 
>> checking. (There should be also artifacts from the build process for 
>> download available.) This should get you rid of most of the cases of 
>> suspiciously high RTT.
>> 
>> `https://gitlab.nic.cz/labs/bird/-/tree/babel-in-threads`
>> Just to be noted, updating a route in BIRD 3 is still a locking process so 
>> it may still tamper the RTT measurements. At least it should happen only in 
>> cases where Babel is doing the update. Anyway, with BIRD 3 internals, it 
>> should be possible to easily *detect* such situations and disregard these 
>> single measurements as unreliable. (Not implemented, though.)
>> 
>> There are even some thoughts on implementing lockless import queues for 
>> routing tables, yet now we have to prioritize BIRD 3 stabilization to 
>> actually release it as a stable version. Import queues must wait.
>> 
>> Also with this testing, feel free to report any weird behavior, notably 
>> crashes of BIRD 3, as bugs. That would be very helpful with stabilizing BIRD 
>> 3. Thanks a lot!
>> 
>> Maria
>> 
>> – Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>> 
-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: babel RTT metric false samples

[Maria Matejka via Bird-users]

Hello Stephanie, Toke and list,

On Fri, Apr 12, 2024 at 04:22:50PM +0200, Toke Høiland-Jørgensen via
Bird-users wrote:

> Stephanie Wilde-Hobbs via Bird-users  writes:

> > The babel RTT metric measurements provided by bird appears suspect
> > for my setup. The metric through a tunnel with a latency of about
> > 5ms is shown in babel as 150+ms.

[...]

> > Debug logs show many RTT samples with approximately correct
> > timestamps (4-6ms) then the occasional IHU with 800-1200ms
> > calculated instead.  Calculating the RTT metric by hand using babel
> > packet logs shows that the calculations are correct. By correlating
> > two packet dumps (the machines have <1ms NTP timekeeping) I can also
> > see that the packets for which high RTT is calculated have similar
> > transit times through the tunnel as other packets. Hence, I suspect
> > the accuracy of the packet timestamps recorded by bird. Is the
> > current packet timestamping system giving correct timestamps if the
> > packet arrives while babel is processing another event?
> 
> Hmm, so Babel implementation in Bird tries to get a timestamp as early
> as possible after receiving the packet, and set it as late as possible
> before sending out the packet. However, the former in practice means
> after returning from poll(), so if the packet has been sitting around
> in the OS buffer for a while before Bird gets around to process it,
> the timestamp is not set until Bird is done processing it. Likewise,
> if the packet sits around in a socket buffer (or in a lower-level
> buffer on the sending side) after Bird has sent it out, that time will
> also be counted as part of the RTT.

I would suspect that the kernel table prune routine may be the case. It
just runs from begin to end synchronously.

I have just fast-tracked Babel in its own thread for BIRD 3, it may be
worth checking. (There should be also artifacts from the build process
for download available.) This should get you rid of most of the cases of
suspiciously high RTT.

https://gitlab.nic.cz/labs/bird/-/tree/babel-in-threads

Just to be noted, updating a route in BIRD 3 is still a locking process
so it may still tamper the RTT measurements. At least it should happen
only in cases where Babel is doing the update. Anyway, with BIRD 3
internals, it should be possible to easily *detect* such situations and
disregard these single measurements as unreliable. (Not implemented,
though.)

There are even some thoughts on implementing lockless import queues for
routing tables, yet now we have to prioritize BIRD 3 stabilization to
actually release it as a stable version. Import queues must wait.

Also with this testing, feel free to report any weird behavior, notably
crashes of BIRD 3, as bugs. That would be very helpful with stabilizing
BIRD 3. Thanks a lot!

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: memcpy uses value of mls (mpls label stack) instead of address

[Maria Matejka via Bird-users]

Hello Ramanathan,

On Fri, Apr 12, 2024 at 10:09:34AM +0530, Ramanathan Selvamani wrote:

> [...]
>
> memcpy(mls.stack, &a->nh.label[a->nh.labels - mls.len], mls.len * 
> sizeof(u32));
>
> > Here the "mls.stack" is passed directly instead of its address in memcpy.

- `a->nh.label` is of type `u32 []`, thus `&a->nh.label[foo]` is of type `u32 
*`.
- `mls.stack` is of type `u32 []`, and even though we definitely *could*
  write `&mls.stack[0]`, it's not worth the bytes, and it means the same

The code is correct, works properly and is regularly tested.

> > I have tried to use mpls_label_stack to keep some meta data for each route.
> > But the values of meta data were not copied correctly.

You should *not* do it in *any situation*, unless these are MPLS labels.
And if MPLS labels are behaving weirdly, please report a bug (here),
including how to reproduce it.

For keeping some custom metadata about routes, use custom attributes
instead.

Also if you are modifying BIRD 2 source code, please be aware that
there is BIRD 3 upcoming with substantial modifications of the core,
allowing for multithreaded execution and better extendability. Notably,
the placement of MPLS label stack has changed there. That development is
mostly happening in the branch `thread-next`, and even though there has
been a significant delay since BIRD 3.0alpha2, the development is pretty
much active and we hope to release alpha3 soon.

Last but not lest, regarding your modifications, feel free to send your
changes upstream, we'll consider including them. How to do it?

- you can just send patches to the list
- you can publish your forked repo and send just its URL and the commit
  hash to the list

Or, if you can't publish your changes, I very much recommend you to
consider having a support contract to ensure that we either don't break
or let you know advance about changes in our internal API. Ask me
off-list for more information.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: The bird wikis is broken

[Maria Matejka via Bird-users]

Oh I see, it was hidden behind a login (worked for me when logged in).
Don't know why it was set this way but now it should work, please check
if you can.

Maria

On Sat, Apr 06, 2024 at 04:20:32PM +0800, zx--- via Bird-users wrote:

> Hello,
> 
> The link gives a 404 Not Found error.
> 
> 
> 
> z...@zxinc.org
>  
> From: Maria Matejka via Bird-users
> Date: 2024-04-06 16:03
> To: bird-users
> Subject: Re: The bird wikis is broken
> Hello!
> 
> If you meant this wiki
> https://gitlab.nic.cz/labs/bird/-/wikis/home
> it's still there, just quite old.
> 
> Could you please share with us what you were looking for and on which links? 
> Without that, we can't move forward.
> 
> Thanks,
> Maria
> 
> 
> On 6 April 2024 09:30:16 CEST, chan alfie  wrote:
> I am a newbie on bird, found some useful info through google which redirect 
> to bird's wikis, but the wikis seems broken, any possbile to bring it back?
> -- 
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: The bird wikis is broken

[Maria Matejka via Bird-users]

Hello!

If you meant this wiki
https://gitlab.nic.cz/labs/bird/-/wikis/home
it's still there, just quite old.

Could you please share with us what you were looking for and on which links? 
Without that, we can't move forward.

Thanks,
Maria


On 6 April 2024 09:30:16 CEST, chan alfie  wrote:
>I am a newbie on bird, found some useful info through google which redirect to 
>bird's wikis, but the wikis seems broken, any possbile to bring it back?

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: [2.14] show route not showing all tables (rpki)

[Maria Matejka via Bird-users]

Hello Elmar,

On 2024-03-22 08:40, Elmar K. Bins via Bird-users wrote:

santi...@crfreenet.org  (Ondrej Zajicek) wrote:

The command 'show route' by default shows the first table for each
network type. Use 'show route table all' if you want all tables.

Nonetheless, this is bizarre and unexpected behaviour.
I suppose there is a good reason for it?


The original reasons for this are historical, carried from BIRD 1 where 
show routewithout tableoption showed only the mastertable.


For BIRD 2, we extrapolated that to show at most one table per network 
type. These design choices are always some kind of looking for 
equilibrium – if you have 1K+ tables, you typically don'ŧ want to dump 
them all. OTOH, in your case, it would make better sense to show all of 
them. Where is the boundary?


While writing this and thinking about it, what if we made it 
configurable, to let you say for each table whether show by defaultor not?


Best regards,
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Fresh Install Bird 2.14

[Maria Matejka via Bird-users]

Hello,

the same way you install any version, you can also downgrade. If it 
doesn't work, please share more details.


Thanks,
Maria

On 2024-03-13 16:23, Ilham Maulana wrote:

Hello,

Is there any step by step tutorial how to downgrade from Bird 2.15 to 
Bird 2.14?


or maybe fresh install Bird 2.14?

I have tried these 3 command, and failed.

*$ ./configure*
*$ make*
*# make install*


Thank You.
1973a0d2-1aec-4f70-a81a-20c4946d1b2c 


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: [PATCH] BSD: macOS Support

[Maria Matejka via Bird-users]

Hello Zhang,

thank you for your contribution. This looks includable, however I'd like 
to ask you about maintainability of this patch. It may quite quickly rot 
away. Is there an easy (and legal) way to have automatic macOS build and 
basic run testing, without a need to maintain a physical Mac?


Thanks,
Maria

On 2024-03-13 03:02, Zhang Maiyun via Bird-users wrote:

Dear all,

This patch makes bird build and run on macOS with `sysconfig=bsd`.
It is mainly modifying preprocessor directives.

I have tested it on macOS 14.3.1 and it is able to establish BGP sessions
and at least exchange IPv4 routes.

Kind regards,
Maiyun Zhang

Signed-off-by: Zhang Maiyun
---
  sysdep/bsd/krt-sock.c | 6 ++
  sysdep/bsd/sysio.h| 6 +-
  sysdep/unix/io.c  | 3 +++
  sysdep/unix/random.c  | 2 +-
  4 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c
index d13e20a3..afb66cb3 100644
--- a/sysdep/bsd/krt-sock.c
+++ b/sysdep/bsd/krt-sock.c
@@ -635,6 +635,7 @@ krt_read_route(struct ks_msg *msg, struct krt_proto *p, int 
scan)
  krt_got_route_async(p, e, new, src);
  }
  
+#ifndef __APPLE__

  static void
  krt_read_ifannounce(struct ks_msg *msg)
  {
@@ -661,6 +662,7 @@ krt_read_ifannounce(struct ks_msg *msg)
  
DBG("KRT: IFANNOUNCE what: %d index %d name %s\n", ifam->ifan_what, ifam->ifan_index, ifam->ifan_name);

  }
+#endif
  
  static void

  krt_read_ifinfo(struct ks_msg *msg, int scan)
@@ -725,7 +727,9 @@ krt_read_ifinfo(struct ks_msg *msg, int scan)
  
if (fl & IFF_UP)

  f.flags |= IF_ADMIN_UP;
+#ifndef __APPLE__
if (ifm->ifm_data.ifi_link_state != LINK_STATE_DOWN)
+#endif
  f.flags |= IF_LINK_UP;  /* up or unknown */
if (fl & IFF_LOOPBACK)/* Loopback */
  f.flags |= IF_MULTIACCESS | IF_LOOPBACK | IF_IGNORE;
@@ -873,9 +877,11 @@ krt_read_msg(struct proto *p, struct ks_msg *msg, int scan)
  case RTM_CHANGE:
krt_read_route(msg, (struct krt_proto *)p, scan);
break;
+#ifndef __APPLE__
  case RTM_IFANNOUNCE:
krt_read_ifannounce(msg);
break;
+#endif
  case RTM_IFINFO:
krt_read_ifinfo(msg, scan);
break;
diff --git a/sysdep/bsd/sysio.h b/sysdep/bsd/sysio.h
index b6b42b1e..85081c07 100644
--- a/sysdep/bsd/sysio.h
+++ b/sysdep/bsd/sysio.h
@@ -32,7 +32,7 @@
  #endif
  
  
-#ifdef __NetBSD__

+#if defined(__NetBSD__) || defined(__APPLE__)
  
  #ifndef IP_RECVTTL

  #define IP_RECVTTL 23
@@ -49,6 +49,10 @@
  #define TCP_MD5SIGTCP_SIGNATURE_ENABLE
  #endif
  
+#ifdef __APPLE__

+#define TCP_MD5SIG TCPOPT_SIGNATURE
+#endif
+
  
  #undef  SA_LEN

  #define SA_LEN(x) (x).sa.sa_len
diff --git a/sysdep/unix/io.c b/sysdep/unix/io.c
index 9b499020..81e09888 100644
--- a/sysdep/unix/io.c
+++ b/sysdep/unix/io.c
@@ -12,6 +12,9 @@
  #ifndef _GNU_SOURCE
  #define _GNU_SOURCE
  #endif
+#ifdef __APPLE__
+#define __APPLE_USE_RFC_3542
+#endif
  
  #include 

  #include 
diff --git a/sysdep/unix/random.c b/sysdep/unix/random.c
index 4e64e56b..7d68c482 100644
--- a/sysdep/unix/random.c
+++ b/sysdep/unix/random.c
@@ -16,7 +16,7 @@
  #include "sysdep/config.h"
  #include "nest/bird.h"
  
-#ifdef HAVE_GETRANDOM

+#if defined(HAVE_GETRANDOM) || (defined(__APPLE__) && defined(HAVE_GETENTROPY))
  #include 
  #endif
  


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: iBGP and next hop - bird router

[Maria Matejka via Bird-users]

Hello Skanda,

there are multiple solutions to this:

 * you can just ignore the "unreachable" and use "bgp_next_hop"
   attribute for display
 * you can set "ipv6 table it6; ipv4 table it4;" on top-level, "igp
   table it6; igp table it4;" in the bgp channel and …
 o either re-generate the underlying routes for next hops by static
   routes
 o or load the next hop routes by another BGP / OSPF / Babel / RIP
   session from the edge router as well

If you wish to get a more elaborate answer and a proper technical 
support with guaranteed timelines, please check our support packages at 
https://bird.nic.cz/en/commercial-services/ and/or send me an off-list 
e-mail to get a customized quote. Moreover, by getting a commercial 
support package, you're keeping the project running.


Happy routing!
Maria

On 2024-03-02 15:21, skanda wrote:


Hi Bird users,

Any assistance or guidance on the issue below ? your help will be 
appreciated.


Regards,

Skanda Arasalingam

*From:*Bird-users  *On Behalf Of 
*ska...@tpg.com.au

*Sent:* Thursday, 29 February 2024 1:01 PM
*To:* bird-users@network.cz
*Subject:* iBGP and next hop - bird router

Hi Bird users,

I need your kind assistance. We are running bird router in container 
and peering with one of the edge routers using iBGP. This for a 
looking glass.


All the routes are becoming unreachable due to next hops since the 
bird router is not feed with all the next hops in the network. How can 
get the issue resolved ? I want to the change the next hop on the bird 
router(I don’t want the peering router to be next-hop-self.). Sofar, I 
am unsuccessful.  By hashing out disable under the protocol, we see 
the interfaces in the routing table.


I have done so far following things and unsuccessful.

protocol direct {

#disabled; # Disable by default

ipv4;    # Connect to default IPv4 table

ipv6;    # ... and to default IPv6 table

}

filter looking_glass

if ( net ~ [ 0.0.0.0/0{0,32} ] ) then

{

bgp_next_hop = 10.252.40.X; (tried both VM or gateway address for VM. 
Not successful sofar)


  accept;

}

Please kindly advise for a working solution.

Regards,
Skanda Arasalingam

PS: first time Bird user


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

BIRD at various meetings (until Jun 2024)

[Maria Matejka via Bird-users]

Dear BIRD users,

I'd like to share our preliminary meeting schedule with you.

 * I was talking at NANOG 90 in Charlotte, NC, USA, about lossless
   prefix aggregation for forwarding. See the recording here:
   https://www.youtube.com/watch?v=35xgLPoQags
 * Ondřej Zajíček is going to talk about our development state at the
   upcoming Euro-IX Route Server Workshop (not public, afaik)
 * I'm going to remotely participate at IETF 119 (mid-March). If you
   wanna direct me to any specific working group which I should join,
   feel free to send me a pointer.
 * We're planning to attend Euro-IX 40th Forum and RIPE 88 in person
   (more info later).
 * We may attend NANOG 91 and IETF 120 remotely.

We're just a small busy team, we can't be everywhere. We very much 
appreciate when anybody presents about using BIRD in any setup. Also, if 
there are any meetings with remote attendance possible where BIRD talks 
happen, or even just recordings, please let us know – we love all the 
feedback! We occasionally get some links. Thank you for all of that!


Also if you really wish us to be at some meeting, please let us know. As 
you probably can see, we are now trying the cover the main meetings of 
North America and Europe. There are some thoughts about covering other 
regions, not realized yet, with no definitive timelines.


With all that, have a nice time and hopefully see you soon!
Happy routing!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Error: Hold timer expired

[Maria Matejka via Bird-users]

Hello!

You probably hit the architectural limits of single thread routing. Try BIRD 3 
(alpha).

Also with this load, it's very much recommended to have a BIRD Support package 
to have us booked for resolving high load problems. It's a time-consuming and 
very fiddly job for experienced developers. Please see 
https://bird.nic.cz/en/commercial-services/ for more details, and/or contact me 
off-list for a customized quote.

Happy routing!
Maria


On 29 February 2024 10:08:56 CET, "mx.avanttel.ru via Bird-users" 
 wrote:
>hello my friend, all the peers lose their connection at once, at different 
>times, the server of 1500,000 networks and 300 routes, where to look for 
>what to adjust, I ask for help, the server itself does not fall, the service 
>does not fall either
>
>
>
>]
>Feb 27 05:02:45 bgp-01 bird: bgpMSKIX: Error: Hold timer expired
>Feb 27 05:03:29 bgp-01 bird: bgpRFET2: Error: Hold timer expired
>Feb 27 05:03:36 bgp-01 bird: bgpGLFW: Error: Hold timer expired
>Feb 27 05:03:40 bgp-01 bird: Kernel dropped some netlink messages, will resync 
>on next scan.
>Feb 27 05:03:45 bgp-01 bird: bgpKOMP: Error: Hold timer expired
>Feb 27 05:03:58 bgp-01 bird: I/O loop cycle took 5094 ms for 6 events
>Feb 27 05:04:29 bgp-01 bird: bgpZap: Error: Hold timer expired
>Feb 27 05:04:44 bgp-01 bird: bgpSAL: Received: Hold timer expired
>Feb 27 05:04:56 bgp-01 bird: bgpRKN2: Received: Hold timer expired
>Feb 27 05:04:56 bgp-01 bird: bgpFIT: Error: Hold timer expired
>Feb 27 05:05:02 bgp-01 bird: bgpGLIX1: Error: Hold timer expired
>Feb 27 05:05:05 bgp-01 bird: Kernel dropped some netlink messages, will resync 
>on next scan.
>Feb 27 05:05:16 bgp-01 bird: bgpRFET1: Received: Hold timer expired
>Feb 27 05:05:19 bgp-01 bird: bgpRKN1: Received: Hold timer expired

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: segfault on running "show mem" command with bird-3.0alpha2

[Maria Matejka via Bird-users]

Hello Prem,

Could you please try out the current thread-nextbranch, i.e. this one? 
https://gitlab.nic.cz/labs/bird/-/tree/thread-next/ This is the 
development branch which will become 3.0alpha3 soon and if your report 
is still relevant for this branch, I'll try to fix it before releasing.


It's really a pleasure to read that v3 is stable with 1K connections 
without major issues outside our testing setup. BTW in our testing 
setup, we managed to run it with 5K connections as well and I suppose we 
could handle at least 10K … just if I was't so lazy to setup larger 
tests. It's actually a good question how many connections we can handle 
at once. With v2, the architectural limitation occurs somewhere around 
1.5K BGP connections, but with v3 and e.g. 32 threads, I would suppose 
that 40K connections should still be OK-ish. We should do such testing 
in future, just for fun, to find out how far we can stretch BIRD with 
the new internal architecture.


Also, and especially if you are our happy user on such a large scale, 
please consider getting our BIRD Support Package to get exclusive 
services (config optimization, training, custom development …) and also 
to ensure continuous BIRD development in the future. See 
https://bird.nic.cz/en/commercial-services/and/or send me an off-list 
e-mail to get a customized quote.


Thank you for reporting.
Have a nice day!
Maria

On 2024-02-26 16:45, Prem Anand wrote:

Hi All,
I am seeing this segfault with bird-3.0alpha2 on trying to run the "show mem" 
command. Not sure if it is a known issue. Just thought of reporting it.

By the way, bird-3.0 though in alpha, looks really stable. Was able to scale 
upto 1K BGP Sessions without any major issues. Eagerly looking for a 3.0 stable 
release soon.

Regards
Prem

Thread 1 "bird" received signal SIGSEGV, Segmentation fault.
0x555841c3 in rmemsize (res=) at lib/resource.c:271
271   if (!r->class->memsize)
(gdb) bt
#0  0x555841c3 in rmemsize (res=) at lib/resource.c:271
#1  cmd_show_memory () at nest/cmds.c:122
#2  0x5560c03e in cf_parse.isra.0 () at nest/config.Y:640
#3  0x5556a523 in cli_parse (c=0x7fffd920) at conf/conf.c:179
#4  0x555837fd in cli_command (c=c@entry=0x556bb338) at 
nest/cli.c:273
#5  0x55583b3c in cli_event (data=0x556bb338) at nest/cli.c:302
#6  0x555786cb in ev_run_list_limited (l=0x55681000 
, limit=4294967294) at lib/event.c:331
#7  0x55566e14 in io_loop () at sysdep/unix/io.c:2216
#8  main (argc=, argv=) at sysdep/unix/main.c:972
(gdb) f 1
#1  cmd_show_memory () at nest/cmds.c:122
122   struct resmem total = rmemsize(&root_pool);
(gdb) print root_pool
$3 = {r = {n = {next = 0x0, prev = 0x0, list = 0x0}, class = 0x0}, inside = {first = 
0x55685360, last = 0x556bb630}, domain = 0x55680e40 
, name = 0x55656735 "Root"}
(gdb) print root_pool->r->class
$5 = (const struct resclass *) 0x0
(gdb)


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Adding support for an experimental IPv6 Hop By Hop Extension header

[Maria Matejka via Bird-users]

Hello Paul,

I'm afraid that this topic may be out of BIRD's primary scope. If I 
assess your needs correctly, this is maybe more to do in NetworkManager 
or something like that, or maybe even in-kernel. But I may be wrong.


If you could describe what exactly you're trying to achieve (even 
off-list of you don't like publishing the details now), I may try to 
give you a direct pointer where to look at, or help you find out whether 
this task matches your skills. Also there may be some collab possibility 
between us and you, if we conclude that this thing actually fits into 
our needs as well.


Looking forward to hearing back from you.
Maria

On 2024-02-19 12:08, Mccherry, Paul (Postgraduate Researcher) wrote:


I am a Phd Researcher at Lancaster university researching the security 
of the UK Internet infrastructure.


I need to add support for a proposed experimental IPv6 Hop By Hop 
Extension Header to a routers Kernel to test my theories. I am more a 
server/network engineer and researcher than I am a programmer but I am 
able to write in Python and use scripting languages. Can anyone 
recommend tools and Router emulation software where one could add 
support for an experimental IPv6 Hop By Hop Extension Header in order 
to test the methodology ? The new extension header requires changes to 
the IFindex table (an additional field) and a new ACL to make routing 
decisions on the new field within the IFindex table. It also will need 
to provide the capability of allowing an installation engineer to make 
changes to this field on initial setup.


If Bird is unable to provide such a testbed, can anyone recommend 
another solution. ? However, I do think a capability to provide 
researchers with an easy method to test new IPv6 Extension headers 
would be really useful considering the takeup of IPv6 and the future 
of the internet.



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Add random number

[Maria Matejka via Bird-users]

In all cases, I'd appreciate a detailed description of the exact use case we 
are trying to solve. We may then come up with an appropriate solution, a 
workaround or a well-defined feature request.

Thank you for your understanding.
Maria

On 11 February 2024 09:30:50 GMT-05:00, Alexander Zubkov via Bird-users 
 wrote:
>Maybe not random, but some sorta hash will be useful here? And it
>should not break the invariant mentioned by Maria. But for the hash we
>still need some means to convert IP addresses to integer numbers,
>because including IP into the hash seems to be reasonable.
>
>On Sun, Feb 11, 2024 at 3:12 PM Max Tulyev  wrote:
>>
>> In our case no. We use the route reflector, so it should export the random 
>> route to other routers, not just use it by itself.
>>
>> On Sun, 11 Feb 2024 08:55:02 -0500
>> "Darren O'Connor"  wrote:
>>
>> > Isn't this a problem for multipath/add path to fix?
>> >
>> > On Sun, Feb 11, 2024, 08:43 Max Tulyev  wrote:
>> >
>> > > Yes, that's correct. I have same routes come from different routers, and 
>> > > I
>> > > want to spread the traffic between them, but if one router fails - keep 
>> > > it
>> > > working using anothers.
>> > >
>> > > Okay, is it possible to get the variable as the result of the shell
>> > > script? Like
>> > >
>> > > localpref = `cat prefpeer`
>> > >
>> > > On Sun, 11 Feb 2024 18:04:18 +0800
>> > > Brandon Zhi  wrote:
>> > >
>> > > > I think the only usage for random number is for loading balance.
>> > > >
>> > > > *Brandon Zhi*
>> > > > HUIZE LTD
>> > > > www.huize.asia  <https://huize.asia/>| www.ixp.su | Twitter
>> > > >
>> > > > This e-mail and any attachments or any reproduction of this e-mail in
>> > > > whatever manner are confidential and for the use of the addressee(s)
>> > > only.
>> > > > HUIZE LTD can’t take any liability and guarantee of the text of the 
>> > > > email
>> > > > message and virus.
>> > > >
>> > > >
>> > > > Maria Matejka via Bird-users 于2024年2月11日
>> > > 周日06:03写道：
>> > > >
>> > > > > Hello!
>> > > > >
>> > > > > No, it's not possible and it makes the filters non-deterministic 
>> > > > > which
>> > > > > would break a critical invariant in BIRD's internal algorithms.
>> > > > >
>> > > > > If you better clarify what you are trying to achieve, we may find
>> > > another
>> > > > > way for you to do it, or at least convert it to a viable feature
>> > > request.
>> > > > >
>> > > > > Thank you for your understanding
>> > > > > Maria
>> > > > > On 2024-02-10 20:56, Max Tulyev wrote:
>> > > > >
>> > > > > Hi All,
>> > > > >
>> > > > > is it possible to add a random number to some variable in the filter?
>> > > > >
>> > > > > For example, like this:
>> > > > >
>> > > > > filter myfilter
>> > > > > {
>> > > > > if net ~ 192.168.11.0/24 then preference = preference +
>> > > random(10);
>> > > > >
>> > > > > ...
>> > > > >
>> > > > > --
>> > > > > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>> > > > >
>> > > > >
>> > >
>> > >
>>
>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Add random number

[Maria Matejka via Bird-users]

Multipath is the way to go, yes.

Introducing external values and variables may become gradually possible with 
BIRD 3 in future. Not promising anything, but if any of you has any feature 
request regarding this, feel free to state it, ideally including some explicit 
use cases for that.

We're currently thinking e.g. about adding custom variables to protocols 
(accessible then from the filters, ofc).

Maria

On 11 February 2024 14:55:02 CET, Darren O'Connor  
wrote:
>Isn't this a problem for multipath/add path to fix?
>
>On Sun, Feb 11, 2024, 08:43 Max Tulyev  wrote:
>
>> Yes, that's correct. I have same routes come from different routers, and I
>> want to spread the traffic between them, but if one router fails - keep it
>> working using anothers.
>>
>> Okay, is it possible to get the variable as the result of the shell
>> script? Like
>>
>> localpref = `cat prefpeer`
>>
>> On Sun, 11 Feb 2024 18:04:18 +0800
>> Brandon Zhi  wrote:
>>
>> > I think the only usage for random number is for loading balance.
>> >
>> > *Brandon Zhi*
>> > HUIZE LTD
>> > www.huize.asia  <https://huize.asia/>| www.ixp.su | Twitter
>> >
>> > This e-mail and any attachments or any reproduction of this e-mail in
>> > whatever manner are confidential and for the use of the addressee(s)
>> only.
>> > HUIZE LTD can’t take any liability and guarantee of the text of the email
>> > message and virus.
>> >
>> >
>> > Maria Matejka via Bird-users 于2024年2月11日
>> 周日06:03写道：
>> >
>> > > Hello!
>> > >
>> > > No, it's not possible and it makes the filters non-deterministic which
>> > > would break a critical invariant in BIRD's internal algorithms.
>> > >
>> > > If you better clarify what you are trying to achieve, we may find
>> another
>> > > way for you to do it, or at least convert it to a viable feature
>> request.
>> > >
>> > > Thank you for your understanding
>> > > Maria
>> > > On 2024-02-10 20:56, Max Tulyev wrote:
>> > >
>> > > Hi All,
>> > >
>> > > is it possible to add a random number to some variable in the filter?
>> > >
>> > > For example, like this:
>> > >
>> > > filter myfilter
>> > > {
>> > > if net ~ 192.168.11.0/24 then preference = preference +
>> random(10);
>> > >
>> > > ...
>> > >
>> > > --
>> > > Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>> > >
>> > >
>>
>>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Add random number

[Maria Matejka via Bird-users]

Hello!

No, it's not possible and it makes the filters non-deterministic which 
would break a critical invariant in BIRD's internal algorithms.


If you better clarify what you are trying to achieve, we may find 
another way for you to do it, or at least convert it to a viable feature 
request.


Thank you for your understanding
Maria

On 2024-02-10 20:56, Max Tulyev wrote:

Hi All,

is it possible to add a random number to some variable in the filter?

For example, like this:

filter myfilter
{
if net ~ 192.168.11.0/24 then preference = preference + random(10);

...


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Doc suggestion - clarifying behaviour when routes are moving between protocols

[Maria Matejka via Bird-users]

Hello Mark,

you are having a lot of useful suggestions. There are even more thoughts 
alike yours, regarding documentation. And indeed you are right that our 
documentation is kinda good as a reference manual but it kinda sucks if 
you are a newbie.


The thing is, we have quite a long backlog and some technological debt 
to resolve (see e.g. multithreading or our still-non-existent API), and 
all of these are very time-consuming. Writing good documentation, or 
better to say, creating good paedagogical materials for self-learning, 
is time-consuming as well. And even though we are very much in favor of 
having better documentation, the aforementioned problems have somehow 
higher priority than documentation (money being the main reason).


Anyway, I'll later try to split your suggestions into independent pieces 
and create our internal issues for each of them, to not lose them.


Now to the suggestions (inline):

On 2024-02-09 06:13, Mark Shuttleworth wrote:


Admittedly I am not a networking specialist, but perhaps that makes my 
feedback useful in terms of gaining new users and bringing Bird to a 
wider audience. My previous experience has been playing with Babel for 
this same personal project, and Bird is obviously a step up in 
complexity given its support for many different protocols. As an 
aside, it's great to see Babel support in Bird :)
This is actually a very good position to read the docs and see what 
makes you confused. I'm very happy that you didn't freak out.


At the time, here's what I struggled with. Hopefully some of this will 
be helpful in shaping docs for new users.


It would be useful early in the doc to have a visualisation of the 
relationship between a table such as master4 and a protocol, like 
kernel or ospf. I found drawing a picture for myself helped to make 
import vs export clear. Perhaps the docs can have a picture like that! 
My suggestion would be to make that visualisation include multiple 
protocols such as the kernel protocol and one of the routing protocols 
like RIP or OSPF, so that it can help explain how a route might move 
between routers (OSPF) and into the local machine routing table. I 
would walk through a full example, showing movement of routes in both 
directions from both protocols. Describe, step by step, how a kernel 
route would be learned and imported into a table like ipv4, and then 
exported by OSPF, and vice versa. Perhaps this is obvious to a routing 
expert but it wasn't obvious to me as someone playing with a proper 
routing daemon for the first time.
We indeed don't have many pictures in the documentation and we shall add 
some. Anyway, this reminds me of … you are a visual learner, more than a 
textual one, aren't you? Would you appreciate a video tutorial, 
explaining these things step by step?


The multi-protocol case (kernel protocol and ospf protocol) may be 
less interesting to someone who's focused on BGP or OSPF across many 
routers, but it seems to me to be critical to the new user experience. 
A new user is likely to have one, two or three routers, and they need 
to move routes between them AND get those routes installed into the 
kernel, so they have to understand the multi-protocol interaction 
dynamics. This is where things like preference, which are not things 
one can learn about just by reading about OSPF or RIP, come into play.


The part of the doc you refer to is critical - it covers the main deal 
which is 'which routes from the various protocols will move into 
position where they can be actioned', but it's also very terse, and 
it's just a paragraph or two in a long stretch of detail. It also uses 
the term 'preference' twice, and I'm not sure those two uses refer to 
the same thing. It says 'Preferences of the routes are compared' and 
'Source protocol instance preferences are compared' but neither 'route 
preference' nor 'source protocol instance preference' has been defined 
before this text. I'm still not sure how I would go and look at a 
setup with birdc and find out easily what the route preference or 
source protocol instance preference would be.


So I think all of this warrants a section on its own, early in the 
overall documentation, that walks through the behaviours of protocols, 
channels, and tables, and how they interact. It's notable that other 
people have found a need to try and explain this more clearly 
themselves - digging around to compose this email I found another 
example at https://blog.kintone.io/entry/bird which may be helpful to you.
This probably needs much more rewriting, considering that there are also 
MPLS rules now, EVPN upcoming … good point from you.


It would also help if logging of decisions wrt import or export 
captured more of the rationale for the decision. As I dug into this I 
saw messages like 'route rejected by protocol', but no rationale for 
that rejection (it turned out to be the preference).  Because the 
relationship between tables and protocols, import and export 

Re: bird 2.14 segfault

[Maria Matejka via Bird-users]

Hello!

Transfered to our internal issue tracker as a possible bug, gonna check 
it later. Thank you for reporting!


https://gitlab.nic.cz/labs/bird/-/issues/30

Maria

On 2024-02-08 10:26, ico wrote:


I wanted to upgrade bird on router A from 1.6 to 2.14. As soon as new 
bird started up on A, almost all of B, C, etc. started crashing. Today 
I started to look into this. I found out I messed up the configuration 
on router A, I didn't filter out all routes from BGP and all those 
prefixes (IPv4 only, ~100k) were exported to OSPF. The bird on router 
A handled it quite OK, but routers B, C, etc. segfaulted after few 
seconds of exporting all those prefixes to kernel. And that happened 
repeatedly after bird started again. And again..


In bird's log file I found nothing. In system log were 2 lines for 
each segfault:


[Thu Feb  1 01:51:10 2024] bird[23724]: segfault at 7ffe0e092ff8 ip 
7f2c4fb219a7 sp 7ffe0e093000 error 6 in 
libc-2.33.so[7f2c4fabe000+15e000]
[Thu Feb  1 01:51:10 2024] Code: 48 89 d9 49 8b 7f 28 49 8b 5f 30 48 
39 df 73 bf 48 29 fb 4c 39 f3 49 0f 47 de 48 83 fb 14 76 a3 48 89 ce 
48 89 da 48 89 0c 24  f4 c8 f9 ff 48 8b 0c 24 49 89 47 28 48 01 d9 
eb 90 0f 1f 80 00


I will try again to upgrade router A without all those prefixes 
exported to OSPF, that should work I believe.


I am not good at this, but maybe someone could use this information to 
find a bug somewhere in bird. Maybe I can help and try something with 
the same failing setup?


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 18:23, Alexander Zubkov wrote:

On Thu, Jan 25, 2024 at 6:11 PM Maria Matejka  wrote:

On 2024-01-25 17:08, Alexander Zubkov wrote:

But I think the problem with no filters is bigger when the RTR server is out. 
It is not just the short period of time when the peer can announce anything. If 
rpki autoreload is on it will cause all bad announces that was rejected before 
to pass the filter now. And if we turn rpki autoreload off, it might work like 
a classical filter, but than we cannot do additional actual origin validation 
using rpki.

On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users 
 wrote:

On 2024-01-25 11:55, Erin Shepherd wrote:

Spitballing slightly here, but could you avoid this problem by adding 
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?

Obviously the disadvantage here is that if your IRR RTR server goes down you're 
basically unfiltered, but it at least avoids the availability problem

With this, you can just go like

 if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, peerasn) != 
ROA_VALID then reject;

which should do the work, iirc.

I may have not written it completely. I would add the "::/0+ as 0", or "::/0+ as 
65535" if AS0 is too shady, to the IRR RTR feed itself, not as a static record.

This way, if the RTR feed fails, the first roa_check fails and the second one 
is not performed at all, therefore nothing is rejected. OTOH, if the RTR feed 
works, the first roa_check is always true and the second one matters.

Do I miss something?

I think the idea was that (::/0+ AS0) is addet to RTR. Then every
valid tuple (prefix, ASN) will return VALID, and others will fall at
least under ::/0+ and because of AS0 will return INVALID. When the
feed is off, the rpki check will return UNKNOWN.


Oh yes, that should work as well, good idea!

Maria



On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:


On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via Bird-users wrote:

a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json  - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 17:08, Alexander Zubkov wrote:
But I think the problem with no filters is bigger when the RTR server 
is out. It is not just the short period of time when the peer can 
announce anything. If rpki autoreload is on it will cause all bad 
announces that was rejected before to pass the filter now. And if we 
turn rpki autoreload off, it might work like a classical filter, but 
than we cannot do additional actual origin validation using rpki.


On Thu, Jan 25, 2024, 14:41 Alexander Zubkov  wrote:

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users
 wrote:

On 2024-01-25 11:55, Erin Shepherd wrote:

Spitballing slightly here, but could you avoid this problem
by adding 0.0.0.0/0+ <http://0.0.0.0/0+> ::0/0+ AS0 RoAs to
the table and accepting ROA Unknowns?

Obviously the disadvantage here is that if your IRR RTR
server goes down you're basically unfiltered, but it at least
avoids the availability problem


With this, you can just go like

    if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr,
net, peerasn) != ROA_VALID then reject;

which should do the work, iirc.

I may have not written it completely. I would add the "::/0+ as 0", or 
"::/0+ as 65535" if AS0 is too shady, to the IRR RTR feed itself, not as 
a static record.


This way, if the RTR feed fails, the first roa_check fails and the 
second one is not performed at all, therefore nothing is rejected. OTOH, 
if the RTR feed works, the first roa_check is always true and the second 
one matters.


Do I miss something?

Maria






- Erin

On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:

On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via
Bird-users wrote:
> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field
like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help
with
aggregation.

More importantly, a risk I perceive with overloading RTR
functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the
lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID)
then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route
servers have a
very hard dependency on the IRR RTR session being up in
order to accept
routes (fail closed), whereas how the RPKI-derived data is
used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as
"if ROAs
exist, all BGP routes that do not match any of the ROAs are
invalid"
(following the RFC 6811 algorithm), but for IRR route/route6
objects
such a definition was never established, those predate the
RFC 6811
algorithm.

Kind regards,

Job

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Maria Matejka via Bird-users]

On 2024-01-25 11:55, Erin Shepherd wrote:
Spitballing slightly here, but could you avoid this problem by adding 
0.0.0.0/0+ ::0/0+ AS0 RoAs to the table and accepting ROA Unknowns?


Obviously the disadvantage here is that if your IRR RTR server goes 
down you're basically unfiltered, but it at least avoids the 
availability problem


With this, you can just go like

    if roa_check(irr, ::/0, 0) = ROA_VALID && roa_check(irr, net, 
peerasn) != ROA_VALID then reject;


which should do the work, iirc.

Maria





- Erin

On Thu, 25 Jan 2024, at 11:41, Job Snijders via Bird-users wrote:
On Thu, Jan 25, 2024 at 11:13:51AM +0100, Jeroen Massar via 
Bird-users wrote:

> a quick stab at generating the slurm file:

why use SLURM though? SLURM doesn't have a 'maxLength' field like the
regular JSON input formatted in this style has:
https://console.rpki-client.org/rpki.json - which might help with
aggregation.

More importantly, a risk I perceive with overloading RTR functionality
to load IRR data into routers is in the realm of fail-safes:

For RPKI-derived data, most ISPs do something along the lines of:

   if (roa_check(rpki, net, bgp_path.last) = ROA_INVALID) then reject;

For IRR-derived data, you'd have to do:

   if (roa_check(irr, net, peerasn) != ROA_VALID) then reject;

The above means that suddenly your EBGP routers/route servers have a
very hard dependency on the IRR RTR session being up in order to accept
routes (fail closed), whereas how the RPKI-derived data is used is in a
'fail open' fashion.

The above friction goes back to RPKI ROAs being defined as "if ROAs
exist, all BGP routes that do not match any of the ROAs are invalid"
(following the RFC 6811 algorithm), but for IRR route/route6 objects
such a definition was never established, those predate the RFC 6811
algorithm.

Kind regards,

Job


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Defines for mixed IPv6/IPv4

[Maria Matejka via Bird-users]

On 25 January 2024 08:34:36 CET, Jeroen Massar  wrote:
>
>
>> On 24 Jan 2024, at 11:08, Maria Matejka  wrote:
>> 
>> 
>> 
>> On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users 
>>  wrote:
>>> 
>>> 
 On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users 
  wrote:
 
 
 Hello bird users,
 
 I am wondering how you handle matching both IPv6 and IPv4 prefixes
 efficiently.
 
 We have tons of blocks in our config like these:
>>> 
>>> Generate the configs.
>> 
>> Not only that, please split IPv6 and IPv4 filters, at least if these are 
>> prone to frequent changes.
>> 
>>> Especially when doing IRR filtering, one simply lets bgpq4 generate the 
>>> filters
>>> and then drop those definitions into a bird include file, and generate the 
>>> peers parts too.
>> 
>> When doing IRR filtering, please export it as JSON and load it through RTR 
>> mechanism. We support multiple ROA tables and this is exactly the use case 
>> for it
>
>Mmm... do you mean IRR data (what bgpq4 generates from RPSL) or RPKI data 
>(what rpki-client generates from ROAs) ?
>
>As yes, RPKI data we generate into a JSON file and then pass that to a RTR 
>which serves it up to bird; but IRR data becomes filter statements ("bgpq4 -b" 
>;) )

Of course I mean IRR data. You setup two caches, one for actual RPKI data, and 
another one for IRR data, feed it by SLURM, load both by two "protocol rpki" 
instances into two different "roa[64] table"s and call "roa_check()" twice.

This way, you don't have to reload BIRD config every so often, and what is 
more, as soon as BIRD 3 comes out, when something changes in IRR, only the 
possibly affected routes are actually going to be reloaded.

If you wanna know a bit more, there is a tutorial talk at the last RIPE where I 
speak (not only) about that. And it still was just the tip of the iceberg. If 
you wish to get more tips, tricks, optimization help and much more, contact me 
off-list for paid support options.

Have a nice day!
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Defines for mixed IPv6/IPv4

[Maria Matejka via Bird-users]

On 24 January 2024 08:53:19 CET, Jeroen Massar via Bird-users 
 wrote:
>
>
>> On 23 Jan 2024, at 14:13, Nico Schottelius via Bird-users 
>>  wrote:
>> 
>> 
>> Hello bird users,
>> 
>> I am wondering how you handle matching both IPv6 and IPv4 prefixes
>> efficiently.
>> 
>> We have tons of blocks in our config like these:
>
>Generate the configs.

Not only that, please split IPv6 and IPv4 filters, at least if these are prone 
to frequent changes.

>Especially when doing IRR filtering, one simply lets bgpq4 generate the filters
>and then drop those definitions into a bird include file, and generate the 
>peers parts too.

When doing IRR filtering, please export it as JSON and load it through RTR 
mechanism. We support multiple ROA tables and this is exactly the use case for 
it.

Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

BIRD at CSNOG and NANOG

[Maria Matejka via Bird-users]

Dear BIRD Users,

during the next week, you may expect our presence at CSNOG in Zlin, 
Czechia, where also Ondrej Zajicek is going to present about upcoming 
EVPN and MPLS capabilities of BIRD. This talk is expected to be in Czech.


I'm also going to attend NANOG 90 in Charlotte, NC, USA; if you wish to 
meet me there, just catch me … or send me an e-mail in advance to 
arrange a meeting. Please note that we probably aren't attending NANOG 
91 in Kansas City in person.


See you in Zlin or in Charlotte!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Version numbers

[Maria Matejka via Bird-users]

Hello Ray and list,

thank you for pointing at this. We actually intend to do kinda the 
semantic versioning, we only didn't see any reason to add a trailing zero.


Regarding your case, I'd suggest to _not_ rely on the versioning being 
x.y.z; what we can promise (and probably should document) is that every 
new version is lexicographically after any older one and doesn't contain 
whitespace. We can even promise that it matches the regex [0-9.-a-z]+ … 
but not much more – if you ever get in a situation where you need to 
check a development version due to some bug, you're screwed with strict 
x.y.z checks.


Also please note that we are not doing strictly the semantic versioning 
as it is described on the website, there are some differences, notably 
in what is considered a reason to bump the major version number.


Have a nice weekend!
Maria

On 2024-01-12 13:08, Ray Bellis wrote:

Hi BIRD folks!

Could you please consider using consistent semantic versioning in your 
release numbers? (see semver.org)


Up until 2.13 all releases used the x.y.z format, with a trailing .0 
for the first release in each minor release.  However the the 2.13 and 
2.14 releases did not - they just used x.y


This broke our deployment code that uses semantic version aware checks 
to tell whether the running daemon is not the same as the available 
package.


A formally adopted (and documented) version numbering policy would be 
of great use to system administrators.


thanks,

Ray


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Exporting a larger prefix if a smaller prefix is being exported

[Maria Matejka via Bird-users]

Sorry, sent this off-list by mistake.

Maria

On 13 January 2024 18:11:07 CET, Maria Matejka  wrote:
>Hello!
>
>This will be possible in version 3, maybe not fully automatic in the first 
>stable versions. There is some code (indirectly) enabling this, waiting for 
>some finishing touches amd merging. You may expect to have an opportunity to 
>test it with the next alpha version of BIRD 3.
>
>With BIRD 2, to some extent it may be also possible directly with the upcoming 
>prefix aggregation feature. Not yet available now.
>
>Maria 
>
>On 13 January 2024 01:56:50 CET, Lukas Haase via Bird-users 
> 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
>>
>>
>
>-- 
>Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Inject default route via OSPF, but only to specific OSPF peer and contingent on BGP session established

[Maria Matejka via Bird-users]

Hello!

TL;DR: That's currently not possible. But there are other options.

On 2024-01-10 00:28, Lukas Haase via Bird-users wrote:

Hi,

I have two "border gateways"; each establishes a BGP session to the outside 
world. An internal router connects to each of the border gateways and uses OSPF to 
exchange routes. (Note, other OSPF links may exist as well).

Both border gateways act as default gateways for the internal router. In order 
to create redundancy, each border gateway should send the default route via 
OSPF to the internal router. However, the default route should not be sent to 
any other device (otherwise it would mess up everything, incl tunnels).


First, if sending a default route through OSPF breaks stuff, you should 
probably filter that route out on these devices where it's unwanted. 
Just to be safe if somebody misconfigures something. And with that, you 
can then just send the default route to the whole OSPF.


Another approach would be filtering between areas in OSPF, which is 
quite fragile and not supported by BIRD anyway, but you can 
theoretically run two OSPF instances, one for the "with-default" 
network, and another one for the other network. This is very much a 
crazy setup which I do not recommend to go with unless you are sure that 
no better approach is available.


And finally, what may be even better, if your two uplinks are two 
different AS's … you can link the internal router to iBGP as well, 
balancing the traffic between the uplinks and failing to send all data 
over one uplink if the other fails.



Additionally, injecting the default route should be contingent on having the 
BGP session established successfully (only then I can assume the route to the 
internet is good).


In BIRD v2, there will be a possibility to do prefix aggregation added 
this year, and it looks like the configuration can be bent enough to 
actually generate "just the default route" from it. Not supported for now.


In BIRD v3, there will be more possible methods to generate default 
route, anyway, no one of them is merged even into thread-next yet.


I hope that I have at least pointed you the right way.

Have a nice day!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird is not adding routes into kernel anymore

[Maria Matejka via Bird-users]

Hello!

Thank you for confirming that Calico still runs BIRD 1.6… and also it's nice to 
know that it's not our bug.

Happy holidays!
Maria

On 26 December 2023 11:27:24 CET, Nico Schottelius via Bird-users 
 wrote:
>
>And again. So this is my Christmas present of stupidity to everyone out
>there - I hope you are not running into the same issue ever in your
>life.
>
>If you do, you might be as stupid as me and have a misplaced calico CNI
>installed on the same node that happens to have a BGP configuration
>without peers and that happens to also run bird (albeit version 1.6).
>
>If you read previous mails and you felt like "this sounds awfully as if
>there are two routing daemons competing for the route table", well then
>you were right, that was exactly the problem.
>
>Happy holidays to everyone!
>
>Nico
>
>--
>Sustainable and modern Infrastructures by ungleich.ch

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: notification scripts ?

[Maria Matejka via Bird-users]

On 2023-12-14 14:17, Douglas Fischer wrote:
Well... If it will be really yang modeled, sounds "not that hard" for 
an external daemon doing that translation.
Not that hard on first sight, anyway with the current state of BGP YANG 
drafts, we may very easily get forced to divert from the IETF YANGs 
massively due to semantic (!) reasons. And then … good luck.

To me, this is good news! Thank you all the involved!


Actually, this is a collab between BIRD and Alice-LG, so many thanks go 
also to Annika Hannig.



And an extra curiosity:
Is BMP related to this "machine-friendly interface"?


No, it isn't. Some internal parts may be similar and we checked some 
rough edges when merging BMP, but this API is a completely different 
(and much more massive) story.


Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: notification scripts ?

[Maria Matejka via Bird-users]

the machine-friendly interface will be a YANG-defined API encoded in CBOR

gRPC and gNMI are no-go because of HTTP/2; won't go that direction; if 
there is such a need, a separate (standalone) daemon may be created to 
handle translations between BIRD API and gRPC / gNMI but it isn't in our 
plans; it can be quite easy to do it though; regarding telemetry, it 
should work well but i would not expect much from such a connection for 
controlling though – we are keeping our model of daemon only reading 
config, not writing it


Maria

On 2023-12-14 13:19, Douglas Fischer wrote:

"also subscribing to various notifications."
Are we talking about gRPC?
If no, maybe some external tool running in same host of bird could use 
this "machine-friendly interface"

to get it from bird and supply those data as gRPC?

gNMI is on the table in some way?

--
Douglas Fernando Fischer
Engº de Controle e Automação


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: notification scripts ?

[Maria Matejka via Bird-users]

On 2023-12-13 11:28, Nigel Kukard wrote:



On 12/13/23 10:14, Maria Matejka via Bird-users wrote:


Hello!

On 2023-12-13 10:19, Kees Meijs | Nefos wrote:

Hi,

On 12-12-2023 17:20, Maria Matejka via Bird-users wrote:
We're prototyping a machine-friendly interface which should 
include, in some later versions, also subscribing to various 
notifications.


Hear hear! Probably asked before, but being integrated (albeit with 
a shim) in SNMP would be lovely.


We are finishing some SNMP support as well but mostly we're trying to 
have a YANG-defined API encoded in CBOR. And because this is quite a 
new technology, we may create some relevant tools during the process; 
if anybody is interested in some specifics, we may keep you informed 
about the development.


Any API interface that can acquire the data available with birdc 
commands would be very greatly appreciated. Even if the commands just 
hand an option to return results were in some machine readable format 
like JSON. I currently have a python daemon that connects to the 
control socket which is rather tedious in terms of parsing all the 
command outputs. :)


No JSON and no XML will get into mainline BIRD, it's a performance 
nightmare. I admit that we are taking our time to introduce the 
CBOR/YANG API, OTOH we wanna make it good enough to last for some … 
decades? without substantial changes.


Thank you for your patience.
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: notification scripts ?

[Maria Matejka via Bird-users]

Hello!

On 2023-12-13 10:19, Kees Meijs | Nefos wrote:

Hi,

On 12-12-2023 17:20, Maria Matejka via Bird-users wrote:
We're prototyping a machine-friendly interface which should include, 
in some later versions, also subscribing to various notifications.


Hear hear! Probably asked before, but being integrated (albeit with a 
shim) in SNMP would be lovely.


We are finishing some SNMP support as well but mostly we're trying to 
have a YANG-defined API encoded in CBOR. And because this is quite a new 
technology, we may create some relevant tools during the process; if 
anybody is interested in some specifics, we may keep you informed about 
the development.


Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: notification scripts ?

[Maria Matejka via Bird-users]

Hello,

there is no such mechanism in current BIRD, your best option is probably 
hooking on logs and parsing them.


We're prototyping a machine-friendly interface which should include, in 
some later versions, also subscribing to various notifications.


Maria

On 2023-12-12 16:19, Jérôme Loyet wrote:

Hello,

i'm using bird as BGP/BFD client and I'd like to exec some command 
when something happens in bird. Like up/down script or something like 
that.


Is there something close to that or another notification mechanism 
that exists ?


Thanks
++ jerome


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD meetup on Tue [not Thu] 07 Nov 2023, Prague, 19:00

[Maria Matejka via Bird-users]

Thank you for the fixup!

Also, the venue is Spojka Karlín, Pernerova 697/35. If you are attending MANET 
wg, just follow me then.

See ya soon.
Maria

On 6 November 2023 03:11:39 CET, Ondrej Zajicek  wrote:
>Hi
>
>Fixed day of week in the subject.
>
>On Sat, Nov 04, 2023 at 11:14:58AM +0100, Maria Matejka via Bird-users wrote:
>> … we decided on Tuesday evening, beginning around 19:00, in some pub nearby.
>> The exact location is still TBD. ICS attached.
>
>-- 
>Elen sila lumenn' omentielvo
>
>Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
>OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
>"To err is human -- to blame it on a computer is even more so."

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

BIRD meetup on Thu 07 Nov 2023, Prague, 19:00

[Maria Matejka via Bird-users]

On 2023-10-31 16:14, Maria Matejka via Bird-users wrote:
if you wish to meet us, please let us know preferably during this week 
and we may do some BIRD meetup.


… we decided on Tuesday evening, beginning around 19:00, in some pub 
nearby. The exact location is still TBD. ICS attached.


See you all soon!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.


bird-meetup.ics
Description: application/extension-ics

BIRD and IETF 118

[Maria Matejka via Bird-users]

Hello!

Just a short reminder for those attending IETF 118 – we aren't 
officially attending, anyway, if you wish to meet us, please let us know 
preferably during this week and we may do some BIRD meetup.


Have a nice journey to Prague and remember, we have the 2nd best[1] 
public transportation network in the world, no need for taxi here ;o)

Maria

[1] https://www.timeout.com/travel/best-public-transport-in-the-world

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Seminar on BIRD 3 internals (CZ only) [Was: BIRD presence on meetings until end of 2023]

[Maria Matejka via Bird-users]

Hello Jim,

there will be quite some written dev doc created based on this session 
(that's basically why the session is going to be recorded) – and this 
doc will be in english, ofc. So if you would mostly listen in on the 
discussions, you may stay assured that you'll have the opportunity to 
get all the information from this future doc. As the core team are all 
czech (well, and slovak) native speakers, it's much more efficient to do 
this in-person meeting in cz/sk, though. For spoken discussions, we're 
regularly attending various meetings where it's possible to find some 
devs (mostly me) and ask complex questions.


We have also other thoughts on how to do better education about BIRD; 
however these aren't clear enough yet to be propagated.


So that's it. Stay tuned!

Maria

On 2023-10-30 20:53, babydr DBA James W. Laferriere wrote:
Hello Maria ,  I for one would be quite interested in EN based ,  
Not exactly in classes ,  but to just listen in on the discussions .

    Tia ,  JimL

On Mon, 30 Oct 2023, Maria Matejka via Bird-users wrote:


Dear BIRD Users,

on Tuesday Dec 19, we're having a day-long seminar of how BIRD 3 
architecture looks like. This event is primarily intended to brief 
the whole team on this topic but we found out that we can easily open 
it publicly. Thus, if anybody is interested in being briefed with the 
BIRD Team, please see the following link.


https://akademie.nic.cz/akademie/course/247/detail/

This event is Czech only (sorry). Anyway, if there is any demand for 
any other courses about BIRD (CZ or EN), please say it and we may 
open some based on your requests.


Also, please see updates on my previous announcements.

On 2023-10-13 10:46, Maria Matejka via Bird-users wrote:


  * NANOG 89 in San Diego, October 16 to 18,

If anybody wants to meet me there, let me know or just find me 
there. I'll check my mailbox (and twitter) regularly during the event.


This event is also gone. I threw just a short notice about BIRD 1 EOL 
there. You may see the recording on YouTube: 
https://www.youtube.com/watch?v=ZC1mymVMCfU



  * Euro-IX 39th Forum in Prague, November 19 to 22,

On Monday Nov 20 afternoon, there will be a talk called "Route 
filtering optimization in BIRD", so if you are a member of Euro-IX, 
don't forget to come.


  * RIPE 87 in Rome, November 27 to December 1.

We got approved a tutorial on Monday Nov 27 morning (9 am). If 
you're interested in details about BIRD 1 EOL, how to migrate to 
BIRD 2 and how to optimize your configurations with new features not 
available with BIRD 1, this is a unique opportunity. If you have any 
request for contents of this tutorial, just let us know, we'll 
consider it.


I have already started working on this and it will be massive. It's 
definitely worth amending your plans and arriving on Sunday, if you 
have already planned otherwise.


See you!
Maria





--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Seminar on BIRD 3 internals (CZ only) [Was: BIRD presence on meetings until end of 2023]

[Maria Matejka via Bird-users]

Dear BIRD Users,

on Tuesday Dec 19, we're having a day-long seminar of how BIRD 3 
architecture looks like. This event is primarily intended to brief the 
whole team on this topic but we found out that we can easily open it 
publicly. Thus, if anybody is interested in being briefed with the BIRD 
Team, please see the following link.


https://akademie.nic.cz/akademie/course/247/detail/

This event is Czech only (sorry). Anyway, if there is any demand for any 
other courses about BIRD (CZ or EN), please say it and we may open some 
based on your requests.


Also, please see updates on my previous announcements.

On 2023-10-13 10:46, Maria Matejka via Bird-users wrote:


  * NANOG 89 in San Diego, October 16 to 18,

If anybody wants to meet me there, let me know or just find me there. 
I'll check my mailbox (and twitter) regularly during the event.


This event is also gone. I threw just a short notice about BIRD 1 EOL 
there. You may see the recording on YouTube: 
https://www.youtube.com/watch?v=ZC1mymVMCfU



  * Euro-IX 39th Forum in Prague, November 19 to 22,

On Monday Nov 20 afternoon, there will be a talk called "Route filtering 
optimization in BIRD", so if you are a member of Euro-IX, don't forget 
to come.


  * RIPE 87 in Rome, November 27 to December 1.

We got approved a tutorial on Monday Nov 27 morning (9 am). If you're 
interested in details about BIRD 1 EOL, how to migrate to BIRD 2 and 
how to optimize your configurations with new features not available 
with BIRD 1, this is a unique opportunity. If you have any request for 
contents of this tutorial, just let us know, we'll consider it.


I have already started working on this and it will be massive. It's 
definitely worth amending your plans and arriving on Sunday, if you have 
already planned otherwise.


See you!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Is it possible to set an IP address to an interface?

[Maria Matejka via Bird-users]

Hello Robért,

BIRD basically doesn't set IP addresses to interfaces. This is a design 
choice of the current team. Please use external tooling for this.


To elaborate a bit more, because we get these kinds of questions 
repeatedly → Implementing of this feature would open a huge can of 
worms, or a very large rabbithole (choose your best option) of features:


 * setting tunnel endpoint IPs
 * implementing DHCP client
 * implementing VRRP
 * creating and destroying tunnel interfaces
 * setting interfaces up and down
 * setting up wireguard links
 * …

Yes, we could become another NetworkManager … and to be honest, I 
sometimes wish to go this way when seeing how badly NM is handling some 
specific corner cases. Anyway, it's a lot of work. A LOT of work. An 
absurdly huge pile of hard work to get there.


Of course, if there is demand for this, and we are closely monitoring 
what the users think and wish, we may rethink this design choice.


Thank you for your understanding
Maria

On 2023-10-24 17:29, Robért Guhr wrote:

Hi,

is it possible to set an ipv4 address (e.g. "10.186.100.11/32 
" ) via bird on a dummy interface called 
"anycast"?

I mean via the bird config not via bgp/ospf pushes.

Background:

I have setup four DNS server in two sites. All these DNS servers
announces 10.186.100.11/32  (and
10.186.100.12/32 ) up to the routers to
create an anycast environment.
Currently 10.186.100.11/32  (and
10.186.100.12/32 ) are set fixed on the
dummy interface. Bird just imports these IP addresses.

We would like to use 10.186.100.11/32 
and 10.186.100.12/32  as resolver in
/etc/resolv.conf
But if we stop the local DNS server then the dns resolution is no
longer possible because the addresses are hardcoded on the local
interface and the other three dns server will not be used.


Idee was to set the ip addreses via bird so that when we stop Bird
and the local DNS server, we automatically forward the DNS
requests to the other three servers.


I was hoping the direct protocol converts a route also to an ip 
address but this seems not to be the case.
With the kernel protocol I can export the route to the kernel routing 
table but that is not was I was want.


pns-b2-ns02 ~ # cat /etc/bird.conf
# Ansible managed

router id 10.186.244.12;

protocol device {
  scan time 10;
}

protocol direct {
  ipv4 {
    import none;
    export all;
  };
  interface "anycast";
}

protocol static {
  ipv4 {
    import all;
    export all;
  };
  route 10.186.100.11/32  via "anycast";
}

protocol kernel {
  ipv4 {
    import none;
    export all;
  };
}





pns-b2-ns02 ~ # birdc show route; echo; ip a show dev anycast; echo; 
ip r | grep 10.186.100


BIRD 2.13.1 ready.
Table master4:
10.186.100.11/32      unicast [static1 
17:22:18.282] * (200)

dev anycast

4: anycast:  mtu 1500 qdisc noqueue state 
UNKNOWN group default qlen 1000

    link/ether 8e:b5:2b:bf:0d:5e brd ff:ff:ff:ff:ff:ff
    inet 10.186.100.9/32  scope global 
noprefixroute anycast          # <- here should also be the 
address 10.186.100.11/32 

       valid_lft forever preferred_lft forever

10.186.100.11 dev anycast proto bird scope link metric 32



Regards,
Robért


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: bird control socket response

[Maria Matejka via Bird-users]

Hello!

We could do it as length+text kinda easily but for historical reasons it 
isn't there. Please note that this kind of interface has become 
impossible to maintain. We won't extend this interface to include 
length, mostly bc. it would just be another hack in an already 
insufficient and slow protocol.


You may expect not only a completely new protocol based on CBOR and YANG 
to communicate with BIRD, but also a quite fast discontinuation of the 
current interface.


I hope this information somehow helps you in your long-term planning.

Maria

On 2023-10-18 23:26, Alexander Zubkov via Bird-users wrote:

Hi,

You can find some information about it here:

https://bird.network.cz/?get_doc&v=20&f=prog-2.html#ss2.10 



I think (IMHO) the reason why it is not implemented as "length+text" 
is because for that you need to prepare the whole response in some 
buffer first to calculate its size. In the current approach you can 
put the things out without the intermediate buffer.


Regards,
Alexander

On Wed, Oct 18, 2023 at 11:17 PM LIU Chris via Bird-users 
 wrote:


Classified as: {OPEN}

I don’t think so.

In fact, nothing wrong, just wondering the reason.

{OPEN}

*From:*netravnen+birdl...@gmail.com

mailto:netravnen%2bbirdl...@gmail.com>>
*Sent:* Wednesday, October 18, 2023 2:06 PM
*To:* LIU Chris 
*Cc:* bird-users@network.cz
*Subject:* Re: bird control socket response




You don't often get email from netravnen+birdl...@gmail.com. Learn
why this is important 



LIU,

Can the use case be covered by SNMPd agentx support?

https://gitlab.nic.cz/labs/bird/-/blob/master/doc/roadmap.md

On Wed, 18 Oct 2023 at 19:19, LIU Chris via Bird-users
 wrote:

Classified as: {OPEN}

I want to implement an application to talk to bird daemon,
basically like birdc/birdcl.

The control socket is TCP stream, it is fine. But the response
from bird daemon adds some headers for each line

I understand server want to make a boundary/delimiter for
stream. Just wondering why not just add how many bytes in the
beginning of response, instead of this inconvenient way (have
to decode line by line). I am not question bird
implementation, just wondering J

Current format like below

Show protocols

0001 BIRD 2.0.10 ready.

2002-Name _Proto_ Table  State  Since Info

1002-device1    Device ---    up

 static_bgp Static master4    up

 kernel1 Kernel master4    up



With Best Regards,

Chris LIU

{OPEN}


/Thales is in the process of carving out its Transportation
activity (GTS) from other Thales’ activities. In order to
prepare this internal restructuring, a new e-mail address has
been adopted and your GTS contacts now use
urbanandmainlines.com . Please
note that their Thales e-mail address remains also valid./


/Thales is in the process of carving out its Transportation
activity (GTS) from other Thales’ activities. In order to prepare
this internal restructuring, a new e-mail address has been adopted
and your GTS contacts now use urbanandmainlines.com
. Please note that their Thales
e-mail address remains also valid./


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Proper use of graceful restart functionality

[Maria Matejka via Bird-users]

Hello!

The -R option basically prohibits local forwarding table cleanup before 
the BGP settles. It tries to not break your local routing by simply 
starting BIRD.


Maria

On 2023-10-16 18:44, Pavlos Parissis wrote:

Hi all,

I am using latest 2.x version of Bird and I have a question about  graceful 
restart.

I have  `graceful restart on` for BGP protocol and I currently perform below 
steps when I want to utilize it:
1. birdc graceful restart
2. systemctl start bird.service

According to the documentation I need `-R` command-line option, thus I have 
adjusted systemd unit file accordingly:
```
ExecStart=/usr/sbin/bird -R -f -u bird -g bird
```

How does the aforementioned command-line option behave when `birdc graceful 
restart` is not issued?
I scanned the code to understand it and I think bird is smart enough to know 
that a graceful restarted was
not requested and it doesn't do anything during the startup.

While I was testing graceful restart functionality, I noticed that even without 
the aforementioned command-line
option the upstream peer does not remove the routes until restart timeout 
expires. So, I was wondering if that
option is real needed thus the question.


Regards,
Pavlos



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Low voltage server for bird.

[Maria Matejka via Bird-users]

Hello!

In this category, I'd opt instead for running 2x (or more) Turris Omnia or 
something like that.

As we release Turris Omnia Enterprise, it would be much better solution for you 
but it's not available for end-user purchase yet.

I don't answer your question, yet it may be worth considering.

Maria

On 15 October 2023 11:38:17 BST, Mike Neo  wrote:
>Hello,
>
>I am looking for a 1U rack platform with 2x PSU with low power consumption
>for a bird-based bgp router (Ubuntu). The supported traffic is expected to
>be ~1-2Gbps. Can anyone recommend a tested solution?
>
>Thank you in advance.
>Mike

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD tutorial at RIPE (was: Re: BIRD presence on meetings until end of 2023)

[Maria Matejka via Bird-users]

Hello!

The RIPE tutorials are typically recorded, yes. We won't hand out the 
słydes in advance (lots of last-minute changes expected) but i assume 
that these will be available for download on the website afterwards, 
together with the recording.


Maria

On 2023-10-14 15:58, Darren O'Connor wrote:


Hopefully this is recorded:)


On Sat, Oct 14, 2023, 09:41 Maximilian Wilhelm  wrote:

Hi Maria,

Anno domini 2023 Maria Matejka via Bird-users scripsit:

> >   * RIPE 87 in Rome, November 27 to December 1.
> >
> We got approved a tutorial on Monday Nov 27 morning (9 am). If
you're
> interested in details about BIRD 1 EOL, how to migrate to BIRD 2
and how to
> optimize your configurations with new features not available
with BIRD 1,
> this is a unique opportunity. If you have any request for
contents of this
> tutorial, just let us know, we'll consider it.

This is brilliant! <3

I sadly won't be able to attend RIPE this time, however would be
highly interested to see the slides (assuming there will be some). If
you'll make some, will you publish them somewhere? :)

Thanks and best regards,
Max


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Transition from BIRD 1 to 2

[Maria Matejka via Bird-users]

Hello!

I'd recommend doing some templating, and even reconsider whether the 
pipe and auxiliary table is really needed. With BIRD 2 and import table 
/ export table BGP setting, the pipes are just unnecessary burden in 
most cases.


More on this in Rome (Nov 27, RIPE 87).

Maria

On 2023-10-13 21:11, Alexander Zubkov via Bird-users wrote:

Hi,

You can try to still have separate IPv4/IPv6 daemons and that may help
not to repeat the protocol sections. But simple include might not help
still, as the syntax requires you sometimes to specify "ipv4"/"ipv6"
for tables and channels for example. Some templating might be helpful
here though.

Regards,
Alexander

On Fri, Oct 13, 2023 at 5:10 PM Robert Sander
  wrote:

On 10/13/23 16:58, Nico Schottelius wrote:

Hello Robert,

Robert Sander  writes:


Hi,

please help me understand the configuration logic for BIRD2.

In BIRD 1 we have a config file common.conf that gets included from
bird.conf and bird6.conf. It holds common configuration applicable to
both IPv4 and IPv6 like this:

I believe you might be using a side effect of the include (i.e. a config
snippet being usable in both contexts), that now with only one config
will not help you anymore.

Yes. For example with the OSPF configuration we only had to define the
interfaces with their weights once and could include that in both
protocol configurations.

Now I have to double that which makes maintenance harder.

Maybe I have to play a little bit more with the include option.

Regards
--
Robert Sander
Heinlein Consulting GmbH
Schwedter Str. 8/9b, 10119 Berlin

https://www.heinlein-support.de

Tel: 030 / 405051-43
Fax: 030 / 405051-19

Amtsgericht Berlin-Charlottenburg - HRB 220009 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD presence on meetings until end of 2023

[Maria Matejka via Bird-users]

Dear BIRD Users,

On 2023-09-26 10:56, Maria Matejka wrote:


I'd like to let you know that we're planning to visit several meetings 
before this year ends:


  * LinuxDays in Prague, October 7 (presentation in Czech),

This event is gone. The presentation was targeted on non-users of BIRD 
on (kinda) entry level of knowledge. It has been recorded so if anybody 
understands Czech or wants to practice … 
https://www.youtube.com/watch?v=9s0C39PZuWE&list=PLlTxFw5y5UZubG8itPk-QBbhmW-ssb52I&index=21



  * NANOG 89 in San Diego, October 16 to 18,

If anybody wants to meet me there, let me know or just find me there. 
I'll check my mailbox (and twitter) regularly during the event.



  * Euro-IX 39th Forum in Prague, November 19 to 22,
  * RIPE 87 in Rome, November 27 to December 1.

We got approved a tutorial on Monday Nov 27 morning (9 am). If you're 
interested in details about BIRD 1 EOL, how to migrate to BIRD 2 and how 
to optimize your configurations with new features not available with 
BIRD 1, this is a unique opportunity. If you have any request for 
contents of this tutorial, just let us know, we'll consider it.


See you!
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD 2.14

[Maria Matejka via Bird-users]

On 2023-10-08 23:06, Ondrej Zajicek wrote:

On Sun, Oct 08, 2023 at 10:18:24PM +0200, Maria Matejka via Bird-users wrote:

Hello Robert,

On 2023-10-08 21:40, Robert Scheck wrote:

Unfortunately, building BIRD 2.14 on CentOS/RHEL 7 fails like this:


sysdep/linux/netlink.c: In function 'rta_get_via':
sysdep/linux/netlink.c:499:11: error: dereferencing pointer to incomplete type 
'struct rtvia'
 switch(v->rtvia_family) {
 ^~

While I assume that the kernel in CentOS/RHEL 7 is simply too old to
support the desired functionality in BIRD, is at least possible to have
the change #ifdef'ed (or so), that it builds without the new feature?

Sorry, support for CentOS / RHEL 7 has been discontinued due to a too old
kernel version and backwards-incompatible Netlink changes. I think the
easiest way would be to add a dependency on a newer kernel, e.g. kernel-lt
which is now afaik 5.4 (supported).

Or you can try to revert commit d61505b039bf0aa6697e28b2a4e07907c89ba1fb. I
can't guarantee it working out of the box, though.

Or rather f8bcb037b5b71a19209f1b63d52895c8c34c675b


Oh sorry, messed up two commits from the same person, mea culpa. You're 
right, disregard my hash, please.


Thank you for correcting me.
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD 2.14

[Maria Matejka via Bird-users]

Hello Robert,

On 2023-10-08 21:40, Robert Scheck wrote:

Unfortunately, building BIRD 2.14 on CentOS/RHEL 7 fails like this:


sysdep/linux/netlink.c: In function 'rta_get_via':
sysdep/linux/netlink.c:499:11: error: dereferencing pointer to incomplete type 
'struct rtvia'
switch(v->rtvia_family) {
^~

While I assume that the kernel in CentOS/RHEL 7 is simply too old to
support the desired functionality in BIRD, is at least possible to have
the change #ifdef'ed (or so), that it builds without the new feature?


Sorry, support for CentOS / RHEL 7 has been discontinued due to a too 
old kernel version and backwards-incompatible Netlink changes. I think 
the easiest way would be to add a dependency on a newer kernel, e.g. 
kernel-lt which is now afaik 5.4 (supported).


Or you can try to revert commit 
d61505b039bf0aa6697e28b2a4e07907c89ba1fb. I can't guarantee it working 
out of the box, though.


Rober

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Possibly a way to match Kernel.source field?

[Maria Matejka via Bird-users]

Hello!

On 2023-09-30 22:33, Nigel Kukard via Bird-users wrote:

On 9/30/23 20:31, Alexander Zubkov wrote:

Hi,

I'm sure one of the attributes mentioned in the documentation fits 
your need:
https://bird.network.cz/?get_doc&v=20&f=bird-6.html#ss6.7 



Can't believe I am so blind, thanks! :)

To make it easier, in BIRD 3 (in alpha now), the attributes are named 
exactly the same in the show route output and in filters.


We won't backport this to BIRD 2; it breaks looking glasses.

Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: BIRD presence on meetings until end of 2023

[Maria Matejka via Bird-users]

Hi Douglas,

thank you for pointing at Semana Infra BR – for this year, we can't fit 
this event into our planning. Please feel free to inform me about any 
future events – our schedule isn't fixed and if some event happens to 
fit, we may decide to come.


Also, don't worry, we are meeting people from nic.br quite often, they 
are being taken care of.


Maria

On 2023-09-26 12:16, Douglas Fischer wrote:

Brazil? 😥😫🙏
What about the biggest case of BIRD in the World?
https://nic.br/semanainfrabr/


Em ter., 26 de set. de 2023 às 06:02, Maria Matejka via Bird-users 
 escreveu:


Dear BIRD Users,

I'd like to let you know that we're planning to visit several
meetings before this year ends:

  * LinuxDays in Prague, October 7 (presentation in Czech),
  * NANOG 89 in San Diego, October 16 to 18,
  * Euro-IX 39th Forum in Prague, November 19 to 22,
  * RIPE 87 in Rome, November 27 to December 1.

Feel free to approach us with any questions you have. We are
usually pretty busy, so if you'd like to have some time with us
guaranteed, we can plan an in-person meeting with you in advance.
If you wish to get a Support Package for your BIRD deployment,
these are perfect opportunities to discuss your needs with us.

There is also IETF 118, November 4 to 10, in Prague. If anyone of
you comes to Prague these days and would like to meet us, you're
welcome, just let me know in advance and we'll arrange the meeting.

And even if you come to Prague outside these dates, don't hesitate
to contact us – we can meet anyway.

Looking forward to seeing you.
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.




--
Douglas Fernando Fischer
Engº de Controle e Automação


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

BIRD presence on meetings until end of 2023

[Maria Matejka via Bird-users]

Dear BIRD Users,

I'd like to let you know that we're planning to visit several meetings 
before this year ends:


 * LinuxDays in Prague, October 7 (presentation in Czech),
 * NANOG 89 in San Diego, October 16 to 18,
 * Euro-IX 39th Forum in Prague, November 19 to 22,
 * RIPE 87 in Rome, November 27 to December 1.

Feel free to approach us with any questions you have. We are usually 
pretty busy, so if you'd like to have some time with us guaranteed, we 
can plan an in-person meeting with you in advance. If you wish to get a 
Support Package for your BIRD deployment, these are perfect 
opportunities to discuss your needs with us.


There is also IETF 118, November 4 to 10, in Prague. If anyone of you 
comes to Prague these days and would like to meet us, you're welcome, 
just let me know in advance and we'll arrange the meeting.


And even if you come to Prague outside these dates, don't hesitate to 
contact us – we can meet anyway.


Looking forward to seeing you.
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Path Attribute Attack

[Maria Matejka via Bird-users]

Hello!

Can't open that link for whatever reason, anyway the last problem with sending 
an invalid path attribute in BGP, killing some sessions repeatedly, didn't 
affect BIRD at all.

Anyway, BIRD transferred this attribute (as unknown transitional) through the 
whole Internet, so we are now working on adding a possibility to delete (or 
also set) any BGP attribute, even unknown.

Hope that helps.
Maria


On 18 September 2023 15:41:32 CEST, Michael Lambert  
wrote:
>As outlined in https://kb.cert.org/vuls/id/347067, there is an attack that 
>uses specially crafted Path Attributes in a BGP UPDATE message to disrupt 
>peering sessions. I don’t recall seeing any discussions of this attack on this 
>list. Is BIRD susceptible?
>
>Thanks,
>Michael
>
>

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute

[Maria Matejka via Bird-users]

Hello!

On 8/29/23 00:13, Daniel Gröber wrote:

On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote:

I've read the whole discussion, and I'm still not clear what advantages
the proposed route attribute has over having one interface per peer.  Is
it because interfaces are expensive in the Linux kernel?  Or is there some
other reason why it is better to run all WG tunnels over a single interface?

Off the top of my head UDP port exhaustion is a scalability concern here,


For enterprise setups, this very easily _can_ get a scalability concern 
fairly easily.



One wg-device per-peer means we need one UDP port per-peer and since
currently binding to a specific IP is also not supported by wg (I have a
patch pending for this though) there's no good way to work around this.
There is a theoretical frankenstein approach, running a virtual machine 
(maybe netns is enough) for each of the public IP address, and connect 
them by veth. You do not want to do this, but theoretically, it should 
work.

Frankly having tons of interfaces is just an operational PITA in all sorts
of ways. Apart from the port exhaustion having more than one wg device also
means I have to _allocate_ a new port for each node in my managment system
somehow instead of just using a static port for the entire network. This
gets dicy fast as I want to move in the direction of dynamic peering as in
tinc.


Even with my 6 machines running in weird locations, it's a mess.


All of that could be solved, but I would also like to get my wg+babel VPN
setup deployed more widely at some point and all that friction isn't going
to help with that so I'd rather have this supported properly.


All in all, I would also like to see this setup deployed worldwide. If 
we could somehow help on the BIRD side, please let us know.


Thank you for bringing this up.

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Pending bird patches and discussions for proto/babel

[Maria Matejka via Bird-users]

Lastly my v5 route selection patch should also be ready, all threads of
discussion should be resolved and there are no known bugs. However I've not
received any testing reports, hint, hint peeps °>°

OK, will look at it as well. Please send me an owl, a pigeon or another
avian carrier compatible with RFC 1149 if we don't react in a reasonable
time (est. a fortnight).

Just a reminder on this :)

I humbly beseech thee to consider deinself reminded again :3


Oopsie, obviously got distracted by something else. Will check and 
possibly merge in several days, hopefully. Sorry for that.


Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: kernel: does not learn routes with RTPROT_KERNEL

[Maria Matejka via Bird-users]

Hello!

On first sight, this looks good. Gonna do some checks and tests and let 
you know whether anything more is needed from you.


Thank you for your patch!
Maria

On 8/24/23 01:38, Pavel Šorejs via Bird-users wrote:

Here is first version - based on master


Pavel

---
 doc/bird.sgml  | 11 ++-
 sysdep/linux/netlink.c |  2 +-
 sysdep/unix/krt.Y  |  7 ++-
 sysdep/unix/krt.c  | 15 +++
 sysdep/unix/krt.h  |  4 
 5 files changed, 28 insertions(+), 11 deletions(-)

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 29e12b7a..af87d5dc 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -3454,9 +3454,8 @@ on the ignored or accepted to our

 table).

 Note that routes created by OS kernel itself, namely direct routes
-representing IP subnets of associated interfaces, are not imported 
even with
- to

-generate these direct routes.
+representing IP subnets of associated interfaces, are imported only with
+ If your OS supports only a single routing table, you can configure 
only one
 instance of the Kernel protocol. If it supports multiple tables (in 
order to

@@ -3487,10 +3486,12 @@ channels.
 Time in seconds between two consecutive scans of the kernel routing
 table.

-    learn 
+    learn [
 Enable learning of routes added to the kernel routing tables by 
other
 routing daemons or by the system administrator. This is possible 
only on

-    systems which support identification of route authorship.
+    systems which support identification of route authorship. By 
default, routes
+    created by kernel (marked as "proto kernel") are not imported. 
Use 
+    option to import these routes.

 kernel table 
 Select which kernel table should this particular instance of the 
Kernel

diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c
index 1af78766..29446cab 100644
--- a/sysdep/linux/netlink.c
+++ b/sysdep/linux/netlink.c
@@ -1598,7 +1598,7 @@ nl_parse_route(struct nl_parse_state *s, struct 
nlmsghdr *h)


 case RTPROT_KERNEL:
   krt_src = KRT_SRC_KERNEL;
-  return;
+  break;

 case RTPROT_BIRD:
   if (!s->scan)
diff --git a/sysdep/unix/krt.Y b/sysdep/unix/krt.Y
index 95b54d65..f3eb1393 100644
--- a/sysdep/unix/krt.Y
+++ b/sysdep/unix/krt.Y
@@ -32,6 +32,7 @@ CF_DECLS
 CF_KEYWORDS(KERNEL, PERSIST, SCAN, TIME, LEARN, DEVICE, ROUTES, 
GRACEFUL, RESTART, KRT_SOURCE, KRT_METRIC, MERGE, PATHS)

 CF_KEYWORDS(INTERFACE, PREFERRED)

+%type  kern_learn
 %type  kern_mp_limit

 CF_GRAMMAR
@@ -48,6 +49,10 @@ kern_proto_start: proto_start KERNEL {
 kern_proto: kern_proto_start proto_name '{' ;
 kern_proto: kern_proto kern_item ';' ;

+kern_learn:
+ bool { $$ = $1 ? KRT_LEARN_SOME : KRT_LEARN_NONE; }
+ | ALL { $$ = KRT_LEARN_ALL; }
+
 kern_mp_limit:
    /* empty */ { $$ = KRT_DEFAULT_ECMP_LIMIT; }
  | LIMIT expr  { $$ = $2; if (($2 <= 0) || ($2 > 255)) 
cf_error("Merge paths limit must be in range 1-255"); }

@@ -61,7 +66,7 @@ kern_item:
   /* Scan time of 0 means scan on startup only */
   THIS_KRT->scan_time = $3 S_;
    }
- | LEARN bool {
+ | LEARN kern_learn {
   THIS_KRT->learn = $2;
 #ifndef KRT_ALLOW_LEARN
   if ($2)
diff --git a/sysdep/unix/krt.c b/sysdep/unix/krt.c
index 9f95247f..3288fd0c 100644
--- a/sysdep/unix/krt.c
+++ b/sysdep/unix/krt.c
@@ -638,13 +638,14 @@ krt_got_route(struct krt_proto *p, rte *e, s8 src)

 #ifdef KRT_ALLOW_LEARN
   switch (src)
-    {
-    case KRT_SRC_KERNEL:
-  goto ignore;
-
+    {
 case KRT_SRC_REDIRECT:
   goto delete;

+    case KRT_SRC_KERNEL:
+  if (KRT_CF->learn != KRT_LEARN_ALL)
+    goto ignore;
+  // fall through
 case  KRT_SRC_ALIEN:
   if (KRT_CF->learn)
 krt_learn_scan(p, e);
@@ -780,6 +781,12 @@ krt_got_route_async(struct krt_proto *p, rte *e, 
int new, s8 src)

   break;

 #ifdef KRT_ALLOW_LEARN
+  case KRT_SRC_KERNEL:
+  if (KRT_CF->learn == KRT_LEARN_ALL)
+    {
+      krt_learn_async(p, e, new);
+    }
+  break;
 case KRT_SRC_ALIEN:
   if (KRT_CF->learn)
 {
diff --git a/sysdep/unix/krt.h b/sysdep/unix/krt.h
index 18a206e6..694ebd34 100644
--- a/sysdep/unix/krt.h
+++ b/sysdep/unix/krt.h
@@ -27,6 +27,10 @@ struct kif_proto;
 #define KRT_REF_SEEN    0x1    /* Seen in table */
 #define KRT_REF_BEST    0x2    /* Best in table */

+#define KRT_LEARN_NONE 0 /* Don't learn */
+#define KRT_LEARN_SOME 1 /* Learn some routes (excluding 
RTPROT_KERNEL) */

+#define KRT_LEARN_ALL 2 /* Learn all routes */
+
 /* Whenever we recognize our own routes, we allow learing of foreign 
routes */


 #ifdef CONFIG_SELF_CONSCIOUS


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: kernel: does not learn routes with RTPROT_KERNEL

[Maria Matejka via Bird-users]

Hello!

On 8/23/23 14:12, Pavel Šorejs via Bird-users wrote:
i have following problem - the kernel protocol ignores routes with 
RTPROT_KERNEL source. Is there some particular reason why this is so?
IIRC it simply was there in the beginning and nobody did any change. It 
should be possible to implement it cleanly in BIRD 3 (now in alpha 
stage), or kinda messily in BIRD 2 (but the current implementation is 
messy anyway so who cares).


Why am i asking? I use BIRD in linux container orchestration context 
(Kubernetes) in conjunction with cilium project (https://cilium.io/). 
Lately they discovered, that systemd likes to mess with their routes 
and did a change to insert their routes with RTPROT_KERNEL source 
flag. This way, systemd doesn't try to mess with their routes. Side 
effect of this is that my installation got broken as BIRD ignores such 
routes. Now i don't know where to start - either they are wrong with 
using RTPROT_KERNEL flag in the first place, or BIRD is wrong by 
ignoring such routes. So i am trying here first.


Probably everybody is wrong in some way.

BIRD should have an option to load also RTPROT_KERNEL routes and mark 
them as flags appropriately.


Cilium should use their own flag (and define it in /etc/iproute2/rt_protos).

SystemD should not mess with routes unless configured so.


Do anybody have some suggestions?


You may, e.g.:

 * send us a messy patch for BIRD 2 (based on branch master)
 * send us a nicer patch for BIRD 3 (based on tag v3.0-alpha2)
 * update Cilium to insert their routes with a custom flag, like BIRD
   does – but not RTPROT_BIRD, please
 * fork Cilium to use BIRD instead of GoBGP
 * open a support request at bird-supp...@network.cz to pay us to do
   something of the above ;-)

Best Regards,
Maria Matejka

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Recursive nexthop via kernel route in proto static not working

[Maria Matejka via Bird-users]

Hello!

On 7/5/23 00:34, Daniel Gröber wrote:



There are some details in the recursive nexthop resolution algorithm
(preventing infinite resolution loops) which may apply to your case.

Can you point me to the right bits in the code so I can have a look?


The appropriate function is rt_update_hostentry()in nest/rt-table.c

Sorry for late answer.
Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Some version questions

[Maria Matejka via Bird-users]

Hello!

On 8/9/23 16:07, Kobayashi_Bairuo via Bird-users wrote:


We heard that BIRD is working on v3.0 and v2.14, what's new? Is 
support for MPLS on the agenda?


Version 3.0 is going to have at least one more alpha before releasing, 
and it's basically 2.x with multithreaded internals.


Version 2.14 is not certain yet; looking into Git and my memory, there 
may be some BMP fixes, some basic route aggregation (no prefix 
aggregation yet), major filter syntax updates, and Babel RTT metric. The 
list is not complete.


No MPLS improvements are to be merged any time soon. If you wish for a 
specific improvement in a defined timeframe, we may talk at 
bird-supp...@network.cz.


I hope I've answered your questions well.

Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Ouch , Been exceedingly quiet on this maillist ?

[Maria Matejka via Bird-users]

Hello!

It's summer in Europe, holiday time, and when not on holiday, we are also 
heavily working on finishing v3.0, v2.14, fixing bugs or expanding the team.

The list is up and running and sometimes a message goes through it. We have 
never been a large volume list and we hope that we never become like e.g. LKML.

Have we neglected some of your messages?

Maria

On 9 August 2023 01:34:20 CEST, "babydr DBA James W. Laferriere" 
 wrote:
>   Hello Ondrej &/or Maria ,  I am afraid the maillist died ?
>
>   Tia ,  JimL
>-- 
>+-+
>| James   W.   Laferriere| SystemTechniques | Give me VMS |
>| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
>| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
>+-+

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird does not prefer older eBGP route - RFC5004 and "older prefer on"

[Maria Matejka via Bird-users]

Well yes, the "prefer older" works only for eBGP, as stated in RFC 5004. 
With iBGP, this isn't invoked as you may run into some nasty routing 
loops. If you need this feature, feel free to send in a patch.


Maria

On 7/3/23 13:46, Mazur, Dariusz wrote:


Hello Maria,

Thanks for response. Attributes look the same. Maybe the problem is 
these routes are learnt via iBGP, what is not visible in "show route  all'


Our simplified topology looks like below:

1.Host_1 and Host_2 announces 172.232.160.0/19

2.Host_1 and Host_2 have different ASNs and they use eBGP to peer with 
ToRs


3.All tors are connected to r01.leaf over iBGP

Host1eBGPr01a.toriBGP-r01.leaf

       eBGPr01b.toriBGP

Host2eBGPr02a.toriBGP-r01.leaf

  eBGPr02b.toriBGP

Show route all from r01.leaf

172.232.160.0/19 unicast [192.168.196.1__r01a.tor106 2023-06-30] * 
(100) [AS4250627481?]


    via 192.168.196.1 on vlan.201

    Type: BGP univ

    BGP.origin: Incomplete

    BGP.as_path: 4250627481

    BGP.next_hop: 192.168.196.1

    BGP.med: 0

    BGP.local_pref: 400

    BGP.atomic_aggr:

    BGP.aggregator: 23.219.179.225 AS4250627481

    BGP.community: (63949,1000) (63949,1002) (63949,1004) 
(63949,1005) (65110,31107) (65310,31107) (65518,31107)


 unicast [192.168.196.3__r01b.tor106 2023-06-30] 
(100) [AS4250627481?]


via 192.168.196.3 on vlan.202

    Type: BGP univ

BGP.origin: Incomplete

    BGP.as_path: 4250627481

    BGP.next_hop: 192.168.196.3

    BGP.med: 0

    BGP.local_pref: 400

    BGP.atomic_aggr:

    BGP.aggregator: 23.219.179.225 AS4250627481

    BGP.community: (63949,1000) (63949,1002) (63949,1004) 
(63949,1005) (65110,31107) (65310,31107) (65518,31107)


 unicast [192.168.196.5__r02a.tor106 2023-06-30] 
(100) [AS4250627482?]


    via 192.168.196.5 on vlan.203

    Type: BGP univ

    BGP.origin: Incomplete

    BGP.as_path: 4250627482

    BGP.next_hop: 192.168.196.5

    BGP.med: 0

    BGP.local_pref: 400

    BGP.atomic_aggr:

    BGP.aggregator: 23.219.179.226 AS4250627482

    BGP.community: (63949,1000) (63949,1002) (63949,1004) 
(63949,1005) (65110,31107) (65310,31107) (65518,31107)


 unicast [192.168.196.7__r02b.tor106 2023-06-30] 
(100) [AS4250627482?


via 192.168.196.7 on vlan.204

    Type: BGP univ

BGP.origin: Incomplete

    BGP.as_path: 4250627482

    BGP.next_hop: 192.168.196.7

    BGP.med: 0

    BGP.local_pref: 400

    BGP.atomic_aggr:

    BGP.aggregator: 23.219.179.226 AS4250627482

    BGP.community: (63949,1000) (63949,1002) (63949,1004) 
(63949,1005) (65110,31107) (65310,31107) (65518,31107)


Thanks,

Dariusz

*From: *Maria Matejka via Bird-users 
*Reply-To: *Maria Matejka 
*Date: *Friday, June 30, 2023 at 12:53 PM
*To: *"bird-users@network.cz" 
*Subject: *Re: Bird does not prefer older eBGP route - RFC5004 and 
"older prefer on"


Hello!

I suspect that the routes either aren't all external, or are otherwise 
compared different before it comes to breaking ties. Could you please 
share the `show route all` output to see all the relevant BGP attributes?


Maria

On 6/30/23 11:43, Mazur, Dariusz via Bird-users wrote:

Hello Bird users,

Have you ever use RFC 5004 and “older prefer” knob. I am trying to
use it but it seems not to work:

*1.Router learns the same route from different ebgp peers, it
prefers route from r01a  and this route is exported to BGP peers*

172.232.160.0/19 unicast [192.168.196.129__r01a.tor106
2023-06-14] * (100) [AS4250627481?]

    via 192.168.196.129 on vlan.201

 unicast [192.168.196.131__r01b.tor106
2023-06-14] (100) [AS4250627481?]

    via 192.168.196.131 on vlan.202

 unicast [192.168.196.133__r02a.tor106
2023-06-14] (100) [AS4250627482?]

    via 192.168.196.133 on vlan.203

*2.Once we lose links to r01a  and r01b  route from r02a is
preferred and exported to BGP peers. It is expected*

172.232.160.0/19 unicast [192.168.196.133__r02a.tor106
2023-06-14] * (100) [AS4250627482?]

    via 192.168.196.133 on vlan.203

*3.When links to r01a  and r01b. are again online route, route
from r01a is pricked as primary and exported to BGP. It causes
route oscillation*

172.232.160.0/19 unicast [192.168.196.129__r01a.tor106
09:14:19.982] * (100) [AS4250627481?]

 

Re: typo in the documentation

[Maria Matejka via Bird-users]

Merged, thanks.

Maria

On 6/30/23 01:30, Alexander Zubkov via Bird-users wrote:

Hello,

I've found a typo in the documenation. The problem is the "/" symbol
in the prefix mask that finishes the formatting definition. The patch
is attached.

Best regards,
Alexander Zubkov


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird does not prefer older eBGP route - RFC5004 and "older prefer on"

[Maria Matejka via Bird-users]

Hello!

I suspect that the routes either aren't all external, or are otherwise 
compared different before it comes to breaking ties. Could you please 
share the `show route all` output to see all the relevant BGP attributes?


Maria

On 6/30/23 11:43, Mazur, Dariusz via Bird-users wrote:


Hello Bird users,

Have you ever use RFC 5004 and “older prefer” knob. I am trying to use 
it but it seems not to work:


*1.Router learns the same route from different ebgp peers, it prefers 
route from r01a  and this route is exported to BGP peers*


172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 2023-06-14] 
* (100) [AS4250627481?]


    via 192.168.196.129 on vlan.201

 unicast [192.168.196.131__r01b.tor106 2023-06-14] 
(100) [AS4250627481?]


    via 192.168.196.131 on vlan.202

 unicast [192.168.196.133__r02a.tor106 2023-06-14] 
(100) [AS4250627482?]


    via 192.168.196.133 on vlan.203

*2.Once we lose links to r01a  and r01b  route from r02a is preferred 
and exported to BGP peers. It is expected*


172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 2023-06-14] 
* (100) [AS4250627482?]


    via 192.168.196.133 on vlan.203

*3.When links to r01a  and r01b. are again online route, route from 
r01a is pricked as primary and exported to BGP. It causes route 
oscillation*


172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 
09:14:19.982] * (100) [AS4250627481?]


    via 192.168.196.129 on vlan.201

     unicast [192.168.196.131__r01b.tor106 
09:14:19.896] (100) [AS4250627481?]


    via 192.168.196.131 on vlan.202

 unicast [192.168.196.133__r02a.tor106 2023-06-14] 
(100) [AS4250627482?]


    via 192.168.196.133 on vlan.203

*4.I believe it is default behavior not to prefer older path. 
According to documentation RFC 5004 and "prefer older on" should fix 
my problem, but it does not work.*


Bird doc says:

/prefer older switch/

/Standard route selection algorithm breaks ties by comparing router 
IDs. This changes the behavior to prefer older routes (when both are 
external and from different peer). For details, see RFC 5004. Default: 
off./


*5. According to documentation RFC 5004 and "prefer older on" should 
fix my problem, but it does not work.*


*a) added "prefer older on", bgp flapped and routes were re-learnt*

172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 
09:22:12.949] * (100) [AS4250627481?]


    via 192.168.196.129 on vlan.201

     unicast [192.168.196.131__r01b.tor106 
09:22:13.527] (100) [AS4250627481?]


    via 192.168.196.131 on vlan.202

 unicast [192.168.196.133__r02a.tor106 
09:22:12.683] (100) [AS4250627482?]


    via 192.168.196.133 on vlan.203

*b) shut links to r01a and r01b*

*172.232.160.0/19 unicast [192.168.196.133__r02a.tor106 
09:22:12.683] * (100) [AS4250627482?]*


*    via 192.168.196.133 on vlan.203*

*c) unshut links to r01a and r01b, route from r01a is again  
preferred, so looks like "older" knob does not work*


172.232.160.0/19 unicast [192.168.196.129__r01a.tor106 
09:27:55.841] * (100) [AS4250627481?]


    via 192.168.196.129 on vlan.201

 unicast [192.168.196.131__r01b.tor106 
09:27:54.448] (100) [AS4250627481?]


    via 192.168.196.131 on vlan.202

 unicast [192.168.196.133__r02a.tor106 
09:22:12.683] (100) [AS4250627482?]. *---> this route is older*


    via 192.168.196.133 on vlan.203

Thanks,

Dariusz


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Recursive nexthop via kernel route in proto static not working

[Maria Matejka via Bird-users]

Hello Daniel,

this looks fishy. I tried a trivial config like this on my laptop as 
follows and it works. Could you please disclose the full table? There 
are some details in the recursive nexthop resolution algorithm 
(preventing infinite resolution loops) which may apply to your case. 
BTW, is there really no message in the log?


The config:

protocol device {}
protocol kernel {
  ipv6 { import all; export none; };
  learn;
}

protocol static {
  ipv6;
  route fdca:db8::/32 recursive ::;
}

The table:

Table master6:
::/0 unicast [kernel1 21:42:38.893] * (10)
    via fe80::feed:dee4:fe00:23d3 on wlo1
    Type: inherit univ
    Kernel.source: 9
    Kernel.metric: 600
2a00:1028:dead:beef::/64 unicast [kernel1 21:42:38.893] * (10)
    dev wlo1
    Type: inherit univ
    Kernel.source: 9
    Kernel.metric: 600
fdca:db8::/32    unicast [static1 21:42:38.891] * (200)
    via fe80::feed:dee4:fe00:23d3 on wlo1
    Type: static univ

Have a nice evening or any other part of the day!
Maria

On 6/27/23 18:03, Daniel Gröber wrote:

Hi Alexander,

On Tue, Jun 27, 2023 at 04:48:46PM +0200, Alexander Zubkov wrote:

Not sure, but I would guess it can be related to the local address. It
might try to pick the first interface with such network.
Could you try your setup with some route that has the nexthop from a
unique subnet configured on the interface? At least to check if it will
become reachable or not.

Ok, if I add a route like `2000::/64 dev enp1s0 via
fe80::fc00:3ff:fec7:cd05` to the kernel and recurse through that it does
work.

 protocol static static_export_kernel2 {
 ipv6;
 igp table master6;
 route 2001:db8::/64 recursive 2000::1234;
 }

 $ ip -6 route add 2000::/64 dev enp1s0 via fe80::fc00:3ff:fec7:cd05
 $ birdc show route protocol static_export_kernel2 all
 2001:db8::/64unicast [static_export_kernel2 16:01:20.131] * (200)
 via fe80::fc00:3ff:fec7:cd05 on enp1s0
 Type: static univ


Or it might be that routes imported from the kernel are marked as
recursive, so it does not resolve because Bird does not allow double
recursion.

If I remove the 2000::/64 route the recursive route goes back to
unreachable. So something seems to be preventing recursion through the
default route specifically, but it evidently doesn't have anything to do
with the route coming from the kernel.

 $ ip -6 route del 2000::/64 dev enp1s0 via fe80::fc00:3ff:fec7:cd05
 $ birdc show route protocol static_export_kernel2 all
 2001:db8::/64unreachable [static_export_kernel2 16:01:20.131] * 
(200)
 Type: static univ

Weird.

Thanks for your suggestions,
--Daniel


--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Maria Matejka via Bird-users]

Hello!

On 6/24/23 15:13, Ondrej Zajicek wrote:

On Thu, Jun 15, 2023 at 03:57:10AM +0200, Alexander Zubkov wrote:


Also, I think that the current realization in bird relies on the fact
that lexer would not have symbols parsed in advance, i.e. that further
mentions of the keyword should return CF_SYM_KNOWN. But if it is not
the case and the lexer parses forward for some reason (before the
parser creates the symbol for the keyword) it would not return
CF_SYM_KNOWN. I don't know the internals of the lexer and parser much,
maybe it is impossible situation (parser does not backtrack, etc.).
And there is no need to worry here.

Yes, it is kind of strange, in long-term, it would make more sense to move all
symbol processing from lexer to parser.


I was moving the symbol processing from parser to lexer several years 
ago due to Bison limitations. Flex afaik guarantees that it only parses 
one token at a time. The Bison-Flex boundary is a nasty can of worms and 
I'm afraid that the best way to get rid of it is to get rid of it 
altogether. Yet for now, I'd prefer keeping it as is.


BTW the new method-call code (branch mq-func-types) depends exactly on 
the fact that I can manipulate lexer state/context from parser 
immediately before parsing the following token.


Maria

--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Bird routing daemon memory segfault issue submission

[Maria Matejka via Bird-users]

Hello!

We'll try to reproduce it locally (which should be trivial) and fix this 
corner case. If any additional information is needed, we'll follow up.


Thank you for your report.
Maria

On 6/22/23 14:52, Kobayashi_Bairuo via Bird-users wrote:


Hello Bird Development Team:

We are AS140731, aka TOHUNET, we use bird as our routing program, we 
have a problem that may be related to the memory address of bird.


Here are the problem details:

We designed a function for anycast to balance the unequal length 
ASPATH between different upstreams and different nodes, it has this 
structure:


function anycast(int AS;int Region;int Country;int NodeID) {

   if net ~ [2406:840:eb8c::/48] then

   {

  case NodeID {

 1: {

case AS {

6939: {bgp_path.prepend(140731);bgp_path.prepend(140731);}

}

 }

  }

   }

}

Among them, AS represents the peer AS of this session, and NodeID 
represents the ID of this node. After the conditional statement in the 
case matches the peer AS, as you can see, it will execute 
bgp_path.prepend, and it works well when the curly braces of the 
conditional statement are not empty. But the aspath of some of our 
nodes is long enough that they don't need to be prepend, so we have 
the following configuration:


function anycast(int AS;int Region;int Country;int NodeID) {

   if net ~ [2406:840:eb8c::/48] then

   {

  case NodeID {

 1: {

case AS {

6939: {}

}

 }

  }

   }

}

Then the problem occurred. In our example, when the Session at 6939 
was established, the conditional statement matched 6939, but the 
content in the curly braces was empty. At this time, bird will be 
automatically killed and restarted by Linux due to a memory segment 
fault. The following is the information we get in journalctl:


kernel: bird[11433]: segfault at 0 ip 559bb2900c28 sp 
7ffcd21d1fc0 error 4 in bird[559bb2886000+9d000]


kernel: Code: 8b 7b 04 83 03 01 41 8d 4f ff 0f 1f 84 00 00 00 00 00 89 
cd 48 8d 44 6d 00 48 8d 14 c3 4c 8b a2 08 80 01 00 8b 82 10 80 01 00 
<41> 3b 04 24 0f >


systemd[1]: bird.service: Main process exited, code=killed, status=11/SEGV

The version number we are currently using is: v2.13-5-gf8ba8280 
debian11, but we have tried to roll back to v2.13 and update to 
v2.13-10-gf8bcb037, these problems still exist.



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Graceful shutdown request signal

[Maria Matejka via Bird-users]

Hello Alexander,

you're right, catching up with all the running session and restoring the 
full internal state would be a nightmare. I think it is doable but too 
difficult (and labour-costly) to get it right. Regarding the need for 
graceful restart support anyway, I don't see much of a good reason to 
prefer this over a regular graceful restart.


Maria

On 6/21/23 13:41, Alexander Zubkov wrote:

Hello Maria,

Regarding restarts, I think the killer feature might be some sort of 
restart, when bird execs a new binary, keeping all the file 
descriptors open and its state somehow. So the new instance could 
transparently catch up with all the running sessions, etc. It can 
serialize the internal state somehow and then reinitialize it from 
that. But I'm afraid it would require a great effort to implement 
something like that.


On Wed, Jun 21, 2023, 08:58 Maria Matejka via Bird-users 
 wrote:


Hello Daniel,

On 21 June 2023 01:03:50 CEST, "Daniel Gröber"
 wrote:
>Hi Erin,
>
>On Tue, Jun 20, 2023 at 08:20:50PM +0200, Erin Shepherd wrote:
>> I run bird on a system which uses systemd as a service
supervisor, and
>> would like to implement graceful restart in a way which works
well with
>> it.
>
>I'm also interested in getting this working. I'm wondering how
graceful
>restart is supposed to behave to begin with though. Last time I
just tried
>`birdc graceful restart` I was surprised that this actually makes
bird exit
>with rv=0 instead of ... well actually restarting.
>
>Is that normal or a bug in the Debian packaging/systemd service?

You're supposed to start BIRD again on your terms. It's a
misleading command wording, kind of. I don't know whether it's a
good idea to actually exec from the shutdown cycle. Will think
about it. It may be a nice feature.

>I suppose if you're supposed to use graceful restart just before
rebooting
>the system it makes sense but at the time I just wanted to do a full
>restart to update the running bird executable without causing traffic
>disruption and was rather surprised when it didn't come back up.

Yes, these two different use cases were what we were choosing from
when implementing this.


>> In particular, what I'd like to do is:
>>  • If I restart the bird service (e.g. for an upgrade), Bird
performs a graceful restart
>>  • If I manually stop bird (systemctl stop bird2), shutdown the
system, or any other action which is liable to cause a longer
period of downtime, perform a graceful restart (for BGP at least)
>
>When you want to tickle special behaviour out of systemd I found
it best to
>not try and do everything in one unit. Using the dependency
system you can
>stop another unit before bird.service gets stopped, this can then
call
>birdc graceful restart, like this:
>
>bird-graceful-restart.service:
>
>    [Unit]
>    After=bird.service
>    Requires=bird.service
>    [Service]
>    Type=oneshot
>    RemainAfterExit=yes
>    ExecStop=birdc graceful restart
>    [Install]
>    WantedBy=bird.service
>
>That way you can enable/disable system wide graceful bird restart by
>`systemctl enable bird-graceful-restart.service`.
>
>The BindsTo+After means stopping bird.service (which is part of
restart)
>will first stop bird-graceful-restart.service, which can then
casually
>signal bird to perform graceful restart without a race (I
>think). WanteBy=bird.service is needed as ExecStop will only run
when a
>service has actually been started.
>
>Also some special handling for the case where bird is already
gone (crashed
>or exited) and birdc would fail might be needed. Excercise for
the reader :)
>
>Doing some quick testing this actually seems to do what I want.
Somewhat
>unexpectedly `systemctl restart bird.servce` with the above
enabled does
>then actually do what you'd expect since restart is just
stop+start. Bird
>will exit on getting the graceful restart command so systemd
can't try to
>stop it some more but the subsequent start will make it come back
up. Neat.
>
>On system shutdown only the stop part will happen so bird exiting is
>actully useful now and that too should work as expected.

If there was somebody to implement this additional Systemd unit
and provide it as a patch, we'd happily merge it.

Thank you for all the ideas!
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.



--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.

Re: Graceful shutdown request signal

[Maria Matejka via Bird-users]

Hello Daniel, 

On 21 June 2023 01:03:50 CEST, "Daniel Gröber"  wrote:
>Hi Erin,
>
>On Tue, Jun 20, 2023 at 08:20:50PM +0200, Erin Shepherd wrote:
>> I run bird on a system which uses systemd as a service supervisor, and
>> would like to implement graceful restart in a way which works well with
>> it.
>
>I'm also interested in getting this working. I'm wondering how graceful
>restart is supposed to behave to begin with though. Last time I just tried
>`birdc graceful restart` I was surprised that this actually makes bird exit
>with rv=0 instead of ... well actually restarting.
>
>Is that normal or a bug in the Debian packaging/systemd service?

You're supposed to start BIRD again on your terms. It's a misleading command 
wording, kind of. I don't know whether it's a good idea to actually exec from 
the shutdown cycle. Will think about it. It may be a nice feature.

>I suppose if you're supposed to use graceful restart just before rebooting
>the system it makes sense but at the time I just wanted to do a full
>restart to update the running bird executable without causing traffic
>disruption and was rather surprised when it didn't come back up.

Yes, these two different use cases were what we were choosing from when 
implementing this.


>> In particular, what I'd like to do is:
>>  • If I restart the bird service (e.g. for an upgrade), Bird performs a 
>> graceful restart
>>  • If I manually stop bird (systemctl stop bird2), shutdown the system, or 
>> any other action which is liable to cause a longer period of downtime, 
>> perform a graceful restart (for BGP at least)
>
>When you want to tickle special behaviour out of systemd I found it best to
>not try and do everything in one unit. Using the dependency system you can
>stop another unit before bird.service gets stopped, this can then call
>birdc graceful restart, like this:
>
>bird-graceful-restart.service:
>
>[Unit]
>After=bird.service
>Requires=bird.service
>[Service]
>Type=oneshot
>RemainAfterExit=yes
>ExecStop=birdc graceful restart
>[Install]
>WantedBy=bird.service
>
>That way you can enable/disable system wide graceful bird restart by
>`systemctl enable bird-graceful-restart.service`.
>
>The BindsTo+After means stopping bird.service (which is part of restart)
>will first stop bird-graceful-restart.service, which can then casually
>signal bird to perform graceful restart without a race (I
>think). WanteBy=bird.service is needed as ExecStop will only run when a
>service has actually been started.
>
>Also some special handling for the case where bird is already gone (crashed
>or exited) and birdc would fail might be needed. Excercise for the reader :)
>
>Doing some quick testing this actually seems to do what I want. Somewhat
>unexpectedly `systemctl restart bird.servce` with the above enabled does
>then actually do what you'd expect since restart is just stop+start. Bird
>will exit on getting the graceful restart command so systemd can't try to
>stop it some more but the subsequent start will make it come back up. Neat.
>
>On system shutdown only the stop part will happen so bird exiting is
>actully useful now and that too should work as expected.

If there was somebody to implement this additional Systemd unit and provide it 
as a patch, we'd happily merge it.

Thank you for all the ideas!
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.