Re: EVPN support in BIRD

[Ondrej Zajicek via Bird-users]

On Mon, May 06, 2024 at 12:24:07PM +0200, Tim Weippert via Bird-users wrote:
> Hi Ondrej, 
> 
> just a quick question, should bird2 announce type 2 prefixes 
> in this state?
> 
> i do some tests with an FRR EVPN network and add one bird2 evpn node. I
> receive evpn routes and see them in the appropriate tables (evpntab and
> etab), but while on the FRR side i get only the l2 parts of a type 2
> route if i interpret the output form FRR correctly:
>
> Also i'm wondering should bird2 also add the corresponding arp entries
> to the neigh table in kernel? 
> 
> Some hints for me where to look further on the issue?


Hi

First, thanks for testing EVPN in BIRD. We do not set IP part of type 2 and
do not use it to configure neigh table. That is optional part of EVPN not
yet supported in BIRD (while setting MAC part and configuring bridge table
is mandatory). Do you need this feature?

Anyway, what was your experience with EVPN in BIRD? Was it understandable
and accessible from user point? Is there anything you missed?

-- 
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."

Re: Large communities indicating RPKI VALID status

[Ondrej Zajicek via Bird-users]

On Sun, Apr 28, 2024 at 01:00:40PM +0200, Job Snijders wrote:
> On Sat, Apr 27, 2024 at 03:00:45PM +0200, Ondrej Zajicek via Bird-users wrote:
> > On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> > > There's internet draft describing in detail, why it's not a good idea to
> > > store RPKI validation state inside community variables at all..
> > > 
> > > https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html
> > 
> > Well, note that this draft is primarily about not announcing validation
> > state in transitive attributes to the whole internet.
> 
> Yes
> 
> > But there are good reasons for having validation state in
> > non-transitive BGP attributes (or communities properly filtered out on
> > AS egress). Validating RPKI and marking routes at AS ingress ensures
> > that all routers within AS have consistent routing state and thus
> > avoiding routing loops.
> 
> Perhaps I am missing something, but how does marking in itself help
> avoid routing loops?
> 
> I am under the impression that a requirement for intra-AS transitive
> marking follows from non-standard modifying of non-transitive local
> attributes (for example, 'weight' or 'preference') based on the
> validation state - which is not what I'd recommend to begin with.

Well, you are right. there are three ways how to define policy based on
RPKI status:

1) Validate RPKI for all routes and apply policy based on the validation
state on all routers.

2) Validate RPKI only for EBGP routes on border routers, mark result with
communities, then apply policy based on marks on all routers.

3) Validate RPKI only for EBGP routes on border routers, apply policy
based on validation state there and use (non-transitive) BGP attributes
for policy (like bgp_local_pref) to propagate it through AS.


The first approach is bad and can easily lead to inconsistent routing,
the second is better as marking ensures that different routers have
consistent view of validation states of routes, but the third approach is
even better and does not require explicit marking of validation states
(although one could argue that the validation state is implicitly encoded
in the policy-carrying BGP attributes).


> Merely rejecting RPKI-invalid routes at the AS ingress and *not*
> manipulating any other local or transitive path attributes will also
> ensure a consistent routing state.

Obviously.


> > Unfortunately large communities do not have transitive flag like
> > extended ones
> > so perhaps it would make sense to use extended community for this
> > purpose. Or perhaps there should be well-known extended community for
> > that ...
> 
> https://www.rfc-editor.org/rfc/rfc8097.html ?

Thanks, i was not aware of this.

-- 
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."

Re: How to set ospf as external route as ext1?

[Ondrej Zajicek via Bird-users]

On Sun, Apr 28, 2024 at 02:29:42PM +, chan alfie wrote:
> The default ospf ASE will be set as rts_ospf_ext2, how to change it, and set 
> the ospf ASE as rts_ospf_ext1?

Hi

Set ospf_metric1 route attribute in export filters.

-- 
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."

Re: Large communities indicating RPKI VALID status

[Ondrej Zajicek via Bird-users]

On Sat, Apr 27, 2024 at 08:18:18AM +0200, Daniel Suchy via Bird-users wrote:
> There's internet draft describing in detail, why it's not a good idea to
> store RPKI validation state inside community variables at all..
> 
> https://www.ietf.org/archive/id/draft-ietf-sidrops-avoid-rpki-state-in-bgp-00.html

Well, note that this draft is primarily about not announcing validation
state in transitive attributes to the whole internet. But there are good
reasons for having validation state in non-transitive BGP attributes (or
communities properly filtered out on AS egress). Validating RPKI and
marking routes at AS ingress ensures that all routers within AS have
consistent routing state and thus avoiding routing loops.

Unfortunately large communities do not have transitive flag like
extended ones, so perhaps it would make sense to use extended community
for this purpose. Or perhaps there should be well-known extended
community for that ...

-- 
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."

Re: IPv4 next-hops over IPv6

[Ondrej Zajicek via Bird-users]

On Fri, Apr 19, 2024 at 02:29:44PM -0500, Jay Hanke via Bird-users wrote:
> Has anyone implemented lab or production IPv4 next hops over an IPv6
> only IX vlan with BIRD as the route server?
> 
> I'm interested to hear your experiences. Specifically router vendor interop.

Note that there is an Euro-IX working group targetting this issue:

https://github.com/euro-ix/rfc8950-ixp

-- 
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."

Re: babel RTT metric false samples

[Ondrej Zajicek via Bird-users]

On Sat, Apr 13, 2024 at 04:38:47PM +0200, 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? 

Yeah, that is definitely a better solution.

-- 
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."

Re: OSPF bad packet

[Ondrej Zajicek via Bird-users]

On Mon, Apr 15, 2024 at 02:22:01PM +, Benoit Chesneau wrote:
> Hi Ondrej,
> 
> Not sure I undersand, these are the IPs of this router itself:
> 
> ```
> root@gw0:~ # ifconfig vlan600
> vlan600: flags=1008843 
> metric 0 mtu 9000
> description: backbone
> 
> options=1c680703
> ether fa:9b:80:06:d7:f9
> inet 198.19.4.33 netmask 0xffe0 broadcast 198.19.4.63
> inet6 fe80::f89b:80ff:fe06:d7f9%vlan600 prefixlen 64 scopeid 0x5
> inet6 2001:7f8::2:103::1 prefixlen 64
> groups: vlan
> vlan: 600 vlanproto: 802.1q vlanpcp: 0 parent interface: mce0
> media: Ethernet 25GBase-SR 
> status: active
> nd6 options=21
> ```
> 
> 
> I didn't find equivalent router id on the network. I also tried to uniquely 
> change the ID but the same error appears. Is there anything I could do to 
> debug this issue ? 

Hi

It seems like the OSPF receives its own packets back. There is a check
that should make them to be silently ignored:

  /* We want just packets from sk->iface. Unfortunately, on BSD we cannot filter
 out other packets at kernel level and we receive all packets on all 
sockets */
  if (sk->lifindex != sk->iface->index)
return 1;

But for some reason it does not work in your case, AFAIK it worked in
older BSDs. It should be harmless outside of spanning your logs.

-- 
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."

Re: BGP on /32 (/128) interfaces

[Ondrej Zajicek via Bird-users]

On Mon, Apr 15, 2024 at 12:10:05PM +0200, Daniel Gröber wrote:
> Hi Arzhel,
> 
> On Fri, Apr 12, 2024 at 11:57:38AM +0200, Arzhel Younsi wrote:
> > But for IPv6, it's cleaner to only require the router's link local address:
> > testvm2006:~$ ip -6 addr
> > inet6 2620:0:860:140:10:192:24:4/128 scope global
> > testvm2006:~$ ip -6 route
> > default via fe80::2022:22ff:fe22:2201 dev ens13 metric 1024 pref medium
> > 
> > In Bird:
> > neighbor fe80::2022:22ff:fe22:2201%ens13 external;
> > 
> > But then the link local address doesn't work with multihop (for obvious
> > reason).
> > bird: /etc/bird/bird.conf:22:1 Multihop BGP cannot be used with link-local
> > addresses
> 
> I use lladdrs for BGP endpoints in my network and that works fine. I think
> using `direct` instead of `multihop` in the v6-lladdr case would make it
> work for you.
> 
> One word of advice: don't use the %scope syntax, use the `interface`
> directive instead. I don't recall exactly why but I had some subtle problem
> with that.
> 
> As for your v4/32 problem, give `multihop 1` a try. That enforces no
> routers on the path to the peer like direct but allows off-subnet
> endpoints. Do keep in mind the docs recommend setting the source address
> explicitly when enabling multihop.

Hi

Note that using multihop fixes the issue with waiting for the address
range to appear, but there is still an issue with next hop resolution.
Multihop routes use recursive next hop resolution and in the case of /32
address ranges, there is no route for resolving neighbor IP announced as
next hop.

One would need a static route like:

route NBR-IP/32 via "IFACE";

So the next hop will be resolved.


Thinking about it, it makes sense to have something like direct mode that
works with unnumbered interfaces (or ones with /32 address).

-- 
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."

Re: 2.0 user's guide shows incorrect date format for passwords

[Ondrej Zajicek via Bird-users]

On Wed, Mar 27, 2024 at 11:25:12AM +, Pisilä Janne via Bird-users wrote:
> Hello,
> 
> The password protocol option section in user's guide 2.0
> https://bird.network.cz/?get_doc&v=20&f=bird-3.html#proto-pass
> incorrectly shows date format as dd-mm- when it should be -mm-dd in 
> BIRD v2.

Hello

Thanks, fixed.

-- 
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."

Re: 回复: How to config a ospf stub area?

[Ondrej Zajicek via Bird-users]

On Wed, Apr 10, 2024 at 02:48:11AM +, chan alfie wrote:
> rt3
> ```
> rt3# bird -c /etc/bird/lab/rt3.conf -p
> bird: /etc/bird/lab/rt3.conf:173:1 ASBR must be in non-stub area
> ```
> does it mean this router is an ASBR? but this router only connect to rt4. and 
> does not contain static route, here is the complete bird.conf

Yes. In BIRD, router is considered ASBR if the export filter of the OSPF
protocol is set to something different than 'none' (so it could export
external routes, regardless of whether it actually exported them).

That is also a reason why it does not allow it the area 172.16.34.0 to be
set as stub area (as ASBRs cannot be in stub areas).

Just do not set export filter in OSPF if you do not want to export external 
routes.

> protocol ospf v2 {
> ipv4 {
> import all;
> export all;
> };
> area 172.16.34.0 {
> stub;
> summary yes;
> interface "veth34" {
> type bcast;
> cost 10;
> hello 10;
> };
> interface "lo3" {
> stub yes;
> };
> };
> }

-- 
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."

Re: [PATCH] Build failure with parallel make

[Ondrej Zajicek via Bird-users]

On Mon, Apr 08, 2024 at 12:26:45PM +0100, Jim Hague via Bird-users wrote:
> Hi all,
> 
> While building a Buildroot project, I ran into an occasional Bird build
> failure. In a parallel make environment, nest can try to write proto-build.c
> to objdir/nest before that directory exists. I think this patch fixes:

Hi

It is already fixed:

https://gitlab.nic.cz/labs/bird/-/commit/23f3dd5cfbe8681b4e71c8d7345bdeaafc86e077

It seems that there is an old version of BIRD in the Buildroot project.

-- 
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."

Re: OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek via Bird-users]

On Sat, Apr 06, 2024 at 04:54:48PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej, Bird users,
> 
> TL/DR: Ondrej's patch works and allows Bird to use OSPFv3 with either
> completely unnumbered interfaces, where it 'borrows' a valid IPv4 address
> from a loopback device. It does so without breaking RFC5838!
> 
> I wrote up my findings on
> https://ipng.ch/s/articles/2024/03/06/vpp-ospf.html

Hi

Thanks for your wonderful blogposts.

-- 
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."

Re: OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek via Bird-users]

On Fri, Apr 05, 2024 at 04:27:27PM +0200, Pim van Pelt wrote:
> Hoi,
> 
> On 4/5/24 15:23, Ondrej Zajicek wrote:
> > I have almost implemented 'extended next hop' for OSPFv3. But then i
> > pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have
> > doubts about usefulness of 'extended next hop', as any IPv4 router needs
> > at one IPv4 address anyways (at least to be able to send ICMP messages)
> > and there is no need to put IPv4 addresses on links. Are there any good
> > arguments for it?
> In VPP, an interface that does not have an ip4 address, will not allow for
> ip4 traffic to enter it. In other words, there must be an ip4 address on the
> interface before forwarding is turned on.
> I know how to change that behavior in VPP, but it's not a problem in
> practice, because we can set 'unnumbered' interface and borrow an IPv4
> address from another interface, usually a loopback interface with a /32 ip4
> and /128 ip6.
> 
> I think it'd be super cool to use OSPFv3 without IPv4 transit networks and
> just reusing the loopback addresses, like so:
> 
> root@vpp0-2:~# ip -br a
> lo   UNKNOWN    127.0.0.1/8 ::1/128
> loop0    UNKNOWN    192.168.10.2/32 2001:678:d78:200::2/128
> fe80::dcad:ff:fe00:0/64
> e0   UP 192.168.10.2/32 2001:678:d78:200::2/128
> fe80::5054:ff:fef0:1120/64
> e1   UP 192.168.10.2/32 2001:678:d78:200::2/128
> fe80::5054:ff:fef0:1121/64
> *
> *However, up-thread (message of 2024-04-30, 16:04) I had that configuration,
> saw the LSAs but did not see Linux (nor VPP) pick up the routes.

Even if LSAs are here the question is whether OSPF generated such routes
(i.e. whether birdc show route would show them). In order for kernel to
pick them up, OSPF has to generate them and with 'onlink' flag on next
hop.

> My
> suspicion is that your commit will be inert in this scenario, because e0
> already has an IPv4 address, so loopback_addr_used will remain 0.

I think it might help, because even if loopback_addr_used will remain 0,
there is also this change in the patch:

https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8#da87cc518d8a6ca24bc804dfc6ad134504731a9c

That for OSPFv3-IPv4 removes next-hop-in-address-range check (and
automatically adds onlink flag), which caused rejection of such next
hops.

-- 
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."

Re: OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek via Bird-users]

On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,
> 
> On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> > Although one could have option that forces it to interpret as IPv6, i
> > would prefer to have 'extended next hop' option that allows to accept
> > both IPv4 and IPv6 next hops in Link-LSA.

> ps - even with IPv4 on the interface and RFC5838 as it was intended, I still
> don't see Bird emit the learned routes to the kernel (see my message to
> Benoit on 30.03.2024, 15:50); so I think even setting extended next hop
> aside, I cannot confirm that OSPFv3 with ipv4 channel works in that
> configuration.

Hi

I have almost implemented 'extended next hop' for OSPFv3. But then i
pivoted to supporting properly IPv4 loopback nexthop [*]. Now i have
doubts about usefulness of 'extended next hop', as any IPv4 router needs
at one IPv4 address anyways (at least to be able to send ICMP messages)
and there is no need to put IPv4 addresses on links. Are there any good
arguments for it?

[*] https://bird.network.cz/pipermail/bird-users/2024-April/017555.html

-- 
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."

Re: announce IPV4 loopback via an OSPF v3 backbone

[Ondrej Zajicek via Bird-users]

On Wed, Mar 27, 2024 at 09:08:35AM +, Benoit Chesneau wrote:
> Hi everyone,
> 
> I was reading  the ospv3 spec and this link 
> https://networklessons.com/ospf/ospfv3-for-ipv4- and  was wondering if such 
> features is supported in bird 2. Can we announce loopbacks via OSPFv3 and 
> remove the need to use OSPFv2 and ptp subnets ? 
> 
> I see it as a good opportunity to reduce the usage of the IPv4 addresses if 
> we can just advertise loopbacks...

Hi

This feature was not implemented in BIRD 2, i just implemented it yesterday:

https://gitlab.nic.cz/labs/bird/-/commit/280daed57d061eb1ebc89013637c683fe23465e8

If there is no IPv4 address on the iface, it chooses an IPv4 address from
another OSPF-managed iface (preferably /32 or stub) and announces that.

-- 
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."

Re: OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek via Bird-users]

On Tue, Apr 02, 2024 at 11:49:21PM +0200, Pim van Pelt via Bird-users wrote:
> Hoi Ondrej,

Hi


> On 02.04.2024 16:40, Ondrej Zajicek via Bird-users wrote:
> > Although one could have option that forces it to interpret as IPv6, i
> > would prefer to have 'extended next hop' option that allows to accept
> > both IPv4 and IPv6 next hops in Link-LSA.
> Did you mean that:
> 1) under normal circumstances, an ipv4 channel with an ipv6 ospfv3
> adjacency, will respect RFC5838 and overload the link-lsa with the ipv4
> address;
> 2) when `extended next hop` is active on the interface, an ipv4 channel with
> ipv6 ospfv3 adjacency, will use the ipv6 nexthop in the link-lsa?

Yes, if there is no IPv4 address or when forced (like your 'extended next hop
always').


> If so, (2) will make Bird break interoperability with any other RFC5838
> neighbor.

Yes, such option will break interoperability, but if you have no IPv4
address on the interface, what address put to Link-LSA anyway?


> Is an alternative perhaps, to make Bird choose the message neighbor as
> nexthop, and ignore the link-lsa value when `extended next hop` is set? Or
> is that gross?
> 
> Example: if neighbor fe80:foo::1234/64 sent the LSA with nexthop as
> c201.00* (192.0.2.1), AND `extended next hop` is set AND the interface
> doesn't have an IPv4 address, only then do we ignore the link-lsa but use
> fe80:foo::1234%iface instead.

There is an alternative way to get route nexthops, from (Hello packet)
source addresses stored in neighbor structures, indexed by neighbor's
router ID. That is probably what you mean by 'message neighbor'.

We use this for PtP/PtMP links in OSPFv2 and OSPFv3-IPv6. But it is
problematic on multi-access links, where you have adjacency just with
DR/BDR. It cannot be used for NBMA links (as you may have no
communication with other neighbors). On broadcast links, you have at
least Hello exchange with neighbors, but there are still some problematic
cases when multiple interfaces are used to connect to one network.


> Incidentally, if we decide to merge the babel patch I offered, we can
> further create analogous behavior by allowing `extended next hop always`
> which would use the message neighbor address even if an IPv4 address is
> present.
> 
> ps - even with IPv4 on the interface and RFC5838 as it was intended, I still
> don't see Bird emit the learned routes to the kernel (see my message to
> Benoit on 30.03.2024, 15:50); so I think even setting extended next hop
> aside, I cannot confirm that OSPFv3 with ipv4 channel works in that
> configuration.

Will check that both.

-- 
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."

Re: Coexistence of multiple babel daemons on the same host

[Ondrej Zajicek via Bird-users]

On Sun, Mar 31, 2024 at 11:34:43AM +0200, Daniel Gröber wrote:
> Hi Babelers,
> 
> I've just come across a reason I'd want to run babel with both bird and
> babeld on the same node and have them become neighbours. The details are
> tedious -- my usual disclamer applies ;)

If you want to have both bird and babeld on the same node and have them
neighbors, you could create veth pair, assign bird to one end and babeld
on the other end.

You probably should use different routing tables for each (as Juliusz
Chroboczek noted) and they should use different set of interfaces.

-- 
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."

Re: OSPF for IPv4 over IPv6 only?

[Ondrej Zajicek via Bird-users]

On Mon, Apr 01, 2024 at 04:14:51PM +0200, Sebastian Hahn wrote:
> > Sebastian - my interpretation of 5838 is slightly different, and I don't 
> > think it expressly forbids xAF nexthops:
> > > 2.5: Although IPv6 link local addresses could be used as next hops for 
> > > IPv4 address families, it is desirable to have IPv4 next-hop addresses.
> 
> My understanding came from this:
> 
> > In order to achieve this, the link's IPv4 address will be advertised
> > in the "link local address" field of the IPv4 instance's Link-LSA.
> > This address is placed in the first 32 bits of the "link local
> > address" field and is used for IPv4 next-hop calculations. The
> > remaining bits MUST be set to zero.
> 
> which to me reads like the statement about desirability just explains
> why the technical design doesn't allow IPv6 next hops. I would be
> happy to be wrong here.

Hi

Unfortunately, RFC 5838 chose the worst way to represent IPv4 in
Link-LSA, so there is no reliable way to know whether received Link-LSA
should be interpreted as IPv4 or IPv6.

Although one could have option that forces it to interpret as IPv6, i
would prefer to have 'extended next hop' option that allows to accept
both IPv4 and IPv6 next hops in Link-LSA.

We could use heuristic, like if first u32 is fe80, it is IPv6,
if remaining u32s are 0, it is IPv4, And hope that nobody uses both
fe80::0 and 254.128.0.0.

-- 
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."

Re: Export shows new filters after "configure soft" before any update

[Ondrej Zajicek via Bird-users]

On Fri, Mar 22, 2024 at 03:56:12PM +0100, Inrin via Bird-users wrote:
> Hiho,
> 
> I noticed that `birdc show route export ` after a `configure soft`
> shows the state with the new export filter, even if no update ocurred.
> The PCAP also shows, as long as no external update comes in, no updates
> are send out on the wire.
> 
> Using export tables makes it possible to see the "real" state.
> For example, until a new external update or a `reload out` it shows the
> "old filter" state.
> 
> For import filters it's different.
> It shows the "old" state until an external update comes in or `reload in` is
> used. With or without import tables or `keep filtered on`.
> 
> Since the help states:
> configure soft [""] [timeout []]Reload configuration and 
> ignore changes in filters
> it should be like for the import case and show the "old" state until an
> update comes in or `reload out` is used.
> 
> Finally to my question:
> Is this behaviour intentional?

Hi

It is intentional. Unless explicitly requested by 'show route import
table' or 'show route export table', we use data from regular routing
tables for this commands. Therefore, it shows routes that either
really are in the routing table (i.e. 'old' state when import filters
are changed), or compute current export filter for 'show route export'.
We have to use the current export filter, as after reconfigure we do
not keep the old one.


> Best would be to even make it possible to ignore the new filters until
> manual reload, but thats probably a bigger change ;)

Yes, that is something that would make more sense.

-- 
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."

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

[Ondrej Zajicek via Bird-users]

On Fri, Mar 22, 2024 at 03:57:23PM +0100, Maria Matejka via Bird-users wrote:
> 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?

Yes, i also thought about this and per-table option seems to
me like a reasonable approach.

-- 
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."

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

[Ondrej Zajicek via Bird-users]

On Thu, Mar 21, 2024 at 09:05:04PM +, Elmar K. Bins via Bird-users wrote:
> Hello folks,
> 
> we're running 2.14 on FreeBSD 13.3 (out of the current bird2-2.14 pkg).
> 
> A long time ago we set up RPKI feeds that put their routes into tables
> r4 and r6.
> 
> I've just added a second RPKI source that feeds into table r44 and r66.
> "show route count" does NOT include these tables:
> 
> ---
> bird> show route count
> 25524 of 25524 routes for 14191 networks in table master4
> 2775 of 2775 routes for 1808 networks in table master6
> 421637 of 421637 routes for 421637 networks in table r4
> 101571 of 101571 routes for 101571 networks in table r6
> Total: 551507 of 551507 routes for 539207 networks in 4 tables
> 
> bird> show route table r44 count
> 401463 of 401463 routes for 401463 networks in table r44
> 
> bird> shor route table r66 count
> No such command. Press `?' for help.
> ---
> 
> (ys, birdc has been fully restarted, just in case something was hanging).
> 
> Any idea why? Is this intentional, an oversight, or a bug?

Hi

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

-- 
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."

Re: 2.15, ospf is broken

[Ondrej Zajicek via Bird-users]

On Tue, Mar 19, 2024 at 08:50:22AM +0400, Dmitry Melekhov wrote:
> Hello!
> 
> Just upgraded and got:
> ...
> Downgrade to 2.14 solved problem.
> 
> Is there fix for this or workaround?

Hello

There are two issues, both caused by commit
31aa62ae6d2e111e87c08b4b27a16ead968f0689:

1) BIRD could generate ECMP routes with multiple dev-only nexthops,
which Linux kernel accepts only in IPv4 but not in IPv6 case.

2) The commit breaks the way how next hops are inherited during next
hop calculations.

Both issues are restricted to physical PtP links (including L3
tunnels like GRE). The first issue is limited to ECMP IPv6 and can
be workarounded by disabling ECMP, the second one has wider impact.

Soha Jin sent patches for both of this issues [*], but i am leaning
towards making a quick bugfix release that reverts the original
commit, so we can take more time to evaluate the change.

[*] Patches:
https://bird.network.cz/pipermail/bird-users/2024-March/017475.html
https://bird.network.cz/pipermail/bird-users/2024-March/017504.html

-- 
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."

Re: 2.15, ospf is broken

[Ondrej Zajicek via Bird-users]

On Tue, Mar 19, 2024 at 02:51:50PM +0400, Dmitry Melekhov wrote:
> 19.03.2024 13:15, Soha Jin пишет:
> > 
> > Hi All,
> > 
> > I have found the problem (inherit next hop from a pointopoint router)
> > and already drafted a patch. I will post the patch to the list once I
> > have tested it.
> > 
> 
> Problem is caused by some change , may be it is possible just revert it?

The change is commit 31aa62ae6d2e111e87c08b4b27a16ead968f0689, you could
revert it for yourself to get working BIRD.

But that commit solved some other problem in different setups, so we
would like to find a fix that works for the original issue and not
causing further problems.

-- 
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."

Re: RTBH (Remotely Triggered Black Hole) using Bird

[Ondrej Zajicek via Bird-users]

On Mon, Mar 18, 2024 at 09:57:22AM +, Mazur, Dariusz via Bird-users wrote:
> Hello Bird Users,
> I am trying to implement RTBH (Remotely Triggered Black Hole) in below setup:
> 
> 0.Simplified Topology:
> 
>   *   ebgp fabric
>   *   inside fabric we use only IPv6, so we announce IPv4 blocks with IPv6 
> next hop (extended next hop)
>   *   tor --- leaf --- spine---3xstem(3xborder_leaf) --- border
>   *   tor announces 192.168.66.1/32 tagged with (65535,666) up to border
> 
> 1.Border has static route:
> r04.border01.labkrk05.fab> show route for  23.0.0.255
> 23.0.0.255/32blackhole [DISCARD_ROUTE_v4 2024-01-08] * (200)
> 
> 2.Border learns 192.168.66.1/32.  In import filter I change next hop to 
> 23.0.0.255 to blackhole traffic to 192.168.66.1/32.
> I don’t see this change in “show route”   but I see this in “show route all”
> 
> Can you give me a tip how to change eBGP next hop in this scenario and 
> resolve it recursively via static route?

Hello

In BIRD, there is BGP Next Hop attribute (bgp_next_hop) and immediate
next hop (gw). In case of non-recursive next hop processing (like from
EBGP), gw is initialized from bgp_next_hop by BGP, but further changes to
the bgp_next_hop (in BGP import filter) does not change gw.

In recursive next hop processing, there is also an indirect next hop that
is initialized from bgp_next_hop by BGP and it is used for route table
lookups to compute gw. As in the non-recursive case, further changes to
the bgp_next_hop does not change the indirect next hop. And this indirect
next hop is not accessible from filters.

In your case i would suggest to avoid indirect resolving through the
blackhole route and instead to change received RTBH routes directly to
blackhole routes:

if ... then
  dest = RTD_BLACKHOLE;

-- 
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."

Re: show bfd sessions

[Ondrej Zajicek via Bird-users]

On Mon, Mar 11, 2024 at 11:27:34PM +0100, Alexander Zubkov via Bird-users wrote:
> Hi all,
> 
> I noticed in the new version 'show bfd sessions' was extended with
> 'all' option. But I also noticed that in case of 'show protocols',
> 'show ospf state|topology' this option comes before [name], but for
> 'show bfd sessions' it is the other way. I think it would be better to
> be consistent here and use 'all' keyword before [name] too.

Hi

In fact, for 'show bfd sessions' you can use the option 'all' either
before or after [name], as there is no fixed order of options for
this command.

In documentation, there is an order in which they appear, e.g.:

show bfd sessions [] [address ] [(interface|dev) ""] 
[ipv4|ipv6] [direct|multihop] [all]

but that is just simplification, they can be used in any order.


In general, there are commands that have a few options and depend on
fixed order (e.g. 'show protocols' or 'show ospf neighbors'), and there
are commands that have more complex options, use key/value scheme and
allow options in arbitrary order (e.g. 'show route', 'show ospf lsadb',
or 'show bfd sessions').

I think that the first scheme is lazy and non-extensible, and most
commands should be converted to the second scheme.


> I also noticed some incompleteness of the "Remote control"
> documentation now. I.e. it lists:
>   show protocols [all]
> When it is actually:
>   show protocols [all] [|""]

Yes, that is missing.


> Also "show route ... [options]" does not have clear description of
> what these options are.

Not sure if you mean interactive help or reference documentation, as
in the documentation they are described:

https://bird.network.cz/?get_doc&v=20&f=bird-4.html#cli-show-route

(but of course, it could always be improved.)


> It seems there are ways to improve this part of the documentation. I
> can offer a hand to examine it in more details what else might be
> missing and maybe prepare patches.

You are welcome.

-- 
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."

Re: BIRD 2.15

[Ondrej Zajicek via Bird-users]

On Mon, Mar 11, 2024 at 11:30:12AM +, Zagorski, Michal via Bird-users wrote:
> Hi,
> Looks like our build from sources with reconfiguration failed on static 
> routes config definitions.
> When configuring with ./configure --with-protocols="bgp static bmp pipe rpki" 
>  - static without bfd, 
> DEV keyword in proto/static/config.Y isn't recognized:
> $ make -j9

Thanks, merged.

-- 
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."

EVPN support in BIRD

[Ondrej Zajicek via Bird-users]

Hello

Recently, we made a beta release of EVPN support in BIRD:

https://gitlab.nic.cz/labs/bird/-/tree/evpn

(branch 'evpn' in BIRD git repository)

You are welcome to try it and give us your feedback and suggestions.

The primary documentation is still missing, but there are comprehensive
examples and comments here:

https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp
(especially bird_m11.conf and bird_m12.conf)

For filter expressions related to EVPN, see function t_net_evpn() in:
https://gitlab.nic.cz/labs/bird/-/blob/evpn/filter/test.conf

If you have any questions, feel free to ask here on the mailing list.

-- 
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."

Re: BIRD 2.15

[Ondrej Zajicek via Bird-users]

On Sun, Mar 10, 2024 at 10:13:56PM +0100, Pim van Pelt via Bird-users wrote:
> Hoi,
> 
> Thanks for the release! I was wondering about this one:
>o Static routes can have both nexthop and interface specified
> Could I not have already been able to set 'route 192.0.2.1/32 via
> 100.64.0.1%eth0 onlink' ? If this is different, can you share a canonical
> syntax ?

Hi

Yes, it is something that could already be done using the IPv6-scope
syntax, but that was both a hack (outside IPv6 link-local) and was
limited in allowed characters in interface name. Now you can use:

  route 192.0.2.1/32 via 100.64.0.1 dev "eth0" onlink;

https://bird.network.cz/?get_doc&v=20&f=bird-6.html#static-route-dev


For details, see this thread:

http://trubka.network.cz/pipermail/bird-users/2024-February/017411.html


> By the way, the following yields a crash upon startup of Bird 2.14 (perhaps
> in 2.15 also, I will check):
> 
> protocol static s1 {
>   ipv4 { export all; };
>   route 192.0.2.1/32 via 192.168.10.2%e0 *onlink bfd*;
> }


Will check that

-- 
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."

Re: bird not exporting OSPF route

[Ondrej Zajicek via Bird-users]

On Wed, Feb 28, 2024 at 04:15:32PM +0900, Nico Schottelius via Bird-users wrote:
> 
> Good morning,
> 
> after switching over to the following filter, as mentioned in the last
> mails:
> 
> filter static_and_bgp_and_ospf {
>   if(source = RTS_STATIC || source = RTS_BGP || source = RTS_OSPF) then 
> accept;
>   reject;
> }

Hi

OSPF generates routes with four source values:

RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1 and RTS_OSPF_EXT2.

(for internal, inter-area, type 1 external and type 2 external routes).

So in your case you just export internal OSPF routes, not the E2 route.

Also note you can write the condition using sets:

if source ~ [ RTS_STATIC, RTS_BGP, RTS_OSPF, RTS_OSPF_IA, RTS_OSPF_EXT1, 
RTS_OSPF_EXT2 ] then ...


> 
> bird> show route all for 2a0a:e5c0:2:a::b
> Table master6:
> 2a0a:e5c0:2:a::b/128 unicast [ospf6 2024-02-26] * E2 (150/10/1) 
> [147.78.194.129]
> via fe80::3eec:efff:fecb:d81a on eth0
> Type: OSPF-E2 univ
> OSPF.metric1: 10
> OSPF.metric2: 1
> OSPF.tag: 0x
> OSPF.router_id: 147.78.194.129


> 
> And is there actually a CLI syntax for
> verifying that a route is accepted by a filter?

  show route export 
  (for should be exported)

or

  show route exported 
  (for was exported)

-- 
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."

Re: L3VPN and BGP add-path

[Ondrej Zajicek via Bird-users]

On Sun, Feb 25, 2024 at 11:04:07PM +0100, Marcel Menzel via Bird-users wrote:
> Hello List,
> 
> I am running the new MPLS L3VPN feature for quite a while now, and it's
> working without issues so far for me, but I have one question:
> 
> I set "add paths on;" on my iBGP peer template in all SAFIs and while it was
> running successfully before the migration to L3VPN, the additional routes in
> the RIB are now gone, but the capabilities are still exchanged between
> peers.

Hello

I am not sure where these 'add paths on' are in your setup. On BGP
sessions ended inside VPNs? On BGP sessions between VPN routers,
with VPN SAFI or IP SAFI?

I am sure that existence of VPN SAFI should not affect functionality of
ADD-PATH on IP SAFI on the same BGP session. I did not test whether
ADD-PATH works for VPN SAFI, but i think it should.


> Furthermore, I can't set "add paths on;" property for any SAFI in the L3VPN
> protocol, this might be the reason why those additional routes are missing?

Yes, that is not supported.

L3VPN takes the best route for each IP prefix inside and convert it to
VPN route outside, and it takes best route for each (RD, IP prefix)
outside and convert it to IP route inside, so you can end with multiple
IP routes for the same prefix inside VPN, but they are due to different
RD, not due to ADD-PATH.


> My only question now is if this just hasn't been implemented yet with BIRD
> (I am just being curious hence I'm asking), my config is something missing
> or this being the general fact that add-path with MPLS L3VPN simply is not a
> thing with other vendors aswell (to be fair, I've never seen an L3VPN
> network with add-path enabled in production so far).

Well, in principle there is no reason why ADD-PATH should not work on BGP
with VPN SAFI, but they are partially overlapping features. If you want
to propagate into your internal network an IP prefix from multiple edge
routers, you need ADD-PATH to avoid best path selection in route reflector.
But if you want to propagate an IP prefix in one VPN, then each edge/PE
router would use different RD, so you do not need ADD-PATH.

Unless you already receive multiple paths to one IP prefix from CE to
your PE and want to propagate them all to other PEs, in that case
ADD-PATH would make sense.

-- 
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."

Re: bird and on-interface p2p routes

[Ondrej Zajicek via Bird-users]

On Thu, Jan 11, 2024 at 02:13:11PM +0500, Eugene M. Zheganin wrote:
> Hello,
> 
> On 11.01.2024 13:29, Alexander Zubkov wrote:
> > You mean exporting to the kernel? You can alter the routes in input
> > filters. Or pipe routes to another table, altering them in the pipe export
> > filter, and then export to the kernel from that other table.
> > 
> Nope, I need quite the opposite - I need to redistribute these into the
> OSPF; they are already present in the KRT. As far as I can see, bird just
> totally ignores these.

Yes, if you get 'strange next-hop' log message, then such route is
rejected during parsing of netlink sockets, so it cannot be changed
by filters.

-- 
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."

Re: [RESEND PATCH v3] Babel: allow choosing link quality estimation algorithm

[Ondrej Zajicek via Bird-users]

On Thu, Nov 09, 2023 at 11:25:10AM +0100, Toke Høiland-Jørgensen via Bird-users 
wrote:
> Nick Cao via Bird-users  writes:
>
> Sorry for missing this earlier, but it looks like with your patch bird
> will no longer honour the "wires" or "wireless" setting at all? Which
> will break old configs, so please don't do that.
> 
> The right way to do this is to have "wired" and "wireless" serve as
> "presets", and then have the link quality override that setting. So that
> just setting "wireless" will get the same settings as today, but setting
> "wired + etx" will get you just the ETX setting.

Agreed.

-- 
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."

Re: ABR sets E-bit (and B-bit) in router LSA

[Ondrej Zajicek via Bird-users]

On Fri, Jan 27, 2023 at 02:18:36PM +, Kenth Eriksson wrote:
> I have a setup as in the attached drawing. I can see that the bird ABR
> node (R2) sets the E-bit and the B-bit in the router LSA. The B-bit seems
> correct as it is the ABR, but it is not an ASBR.

Hi

It depends on config. if route export to OSPF is allowed, it is marked as
ASBR, even if no route is currently exported. See ospf_proto_finish():

  /* Route export or NSSA translation (RFC 3101 3.1) */ 

   |
  cf->asbr = (proto_cf_main_channel(this_proto)->out_filter != FILTER_REJECT) 
|| (nssa && cf->abr); 

-- 
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."

Re: bird-1.6.8: Withdrawals during an enhanced route-refresh process

[Ondrej Zajicek via Bird-users]

On Fri, Oct 14, 2022 at 01:28:27AM +0200, Garri Djavadyan via Bird-users wrote:
> Hello everyone,
> 
> I noticed that the legacy Bird version behaves strangely while it is in
> an enhanced route-refreshing process, but I am not sure whether it is a
> known/expected behaviour for version 1.6.8. Namely, right after a 1.6.8
> peers sends a BoRR message, it also sends withdrawals for the prefixes
> it received from that same peer. For example, below is the output from
> two Bird peers (1.6.8 and 2.0.10):
> 
> So, I am just curious if it is a bug or some architectural limitation
> of Bird-1.6. If I understand correctly, there are two problems here:

Hello

Yes, it is expected, although unnecessary. The route feeding code just
send updates or withdraws and does not consider whether it is initial
feed, regular route refresh, or enhanced route-refresh.

In BIRD 2.0.10, we keep a bitmap of routes that were announced, so we do
not send withdraws for ones that were not announced before, but we would
AFAIK send unnecessary withdraws during enhanced route-refresh (for routes
that were announced before).

-- 
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."

Re: Notification on network update (BABEL)

[Ondrej Zajicek via Bird-users]

On Fri, Oct 14, 2022 at 08:07:09AM +0200, Martin Vystrčil via Bird-users wrote:
> Good morning,
> 
> is there any possibility to be notified on network update. We are using bird
> to manage BABEL in our product (embedded system).
> 
> Main usage would be to send SNMP notification on BABEL network update.
> Prefered would be to execute any shell script, but any other method would be
> appreciated.

Hi

What do you mean by 'network update'? If that means changing routing
table (as a result of change in network topology), then you could just
monitor kernel routing table changes with netlink / 'ip monitor' command.

-- 
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."

Re: Bird 2.07: BFD with multiple BIRD processes

[Ondrej Zajicek via Bird-users]

On Thu, Oct 13, 2022 at 12:59:47AM +0100, Mihai via Bird-users wrote:
> Hi,
> 
> On the same server I am running two BIRD processes each configured with OSPF
> and iBGP (toward the same neighbors, using different local addresses).
> Should BFD for iBGP work on both processes?
> In my case all BFD sessions on the first processes are dropped when the
> second BIRD processes starts.
> In the documentation there is the "strict bind" option for BFD but I am not
> really sure how/where it should be configured as the configuration check
> fails when added under protocol bfd.

Hi

It should work with 'strict bind' BFD option. It is new in 2.0.10, so if
you use 2.0.7, it would fail. Your BGP should probably also use
'strict bind' option.

-- 
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."

Re: Bird 2.0.10: ipv6 static onlink route updates after each scan time

[Ondrej Zajicek via Bird-users]

On Wed, Oct 12, 2022 at 05:00:07PM +0200, Ondrej Zajicek via Bird-users wrote:
> On Wed, Oct 12, 2022 at 11:04:52AM +, Saklak, Marcin via Bird-users wrote:
> > Hi,
> > I have an issue with onlink static routes bird constantly remove and add 
> > them to kernel.
> > 
> > Is this expected behavior that for ipv6 onlink route bird after each scan 
> > time remove and add route? for other static routes bird update kernel once
> 
> Hello
> 
> Onlink flag is meaningful only with explicit next hops (IPs). I would
> check how it will behave with direct routes (like in your case), but that
> is not expected usage.

Fixed by this commit:

https://gitlab.nic.cz/labs/bird/-/commit/324252975004154cc70623c94f05083bff100209

The online flaw was ignored on routes without next hop

-- 
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."

Re: Bird 2.0.10: ipv6 static onlink route updates after each scan time

[Ondrej Zajicek via Bird-users]

On Wed, Oct 12, 2022 at 11:04:52AM +, Saklak, Marcin via Bird-users wrote:
> Hi,
> I have an issue with onlink static routes bird constantly remove and add them 
> to kernel.
> 
> Is this expected behavior that for ipv6 onlink route bird after each scan 
> time remove and add route? for other static routes bird update kernel once

Hello

Onlink flag is meaningful only with explicit next hops (IPs). I would
check how it will behave with direct routes (like in your case), but that
is not expected usage.


>route 2600:1408:c400::1234/128 via "eth-1_1_39_1" onlink; #update after 
> each scan time by remove and add
> 
>route 2600:1408:c400::/128 via "eth-1_1_39_1"; #update once


-- 
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."

Re: Link local vs global v6 next hop for BGP rotuer

[Ondrej Zajicek via Bird-users]

On Mon, Oct 10, 2022 at 11:25:23AM +0200, Alexander Zubkov wrote:
> Hi,
> 
> In documentation part it is written that the default for the option is
> "disabled". But in the code I see it chooses the value based on
> "gw_mode":
> > Different default for next_hop_prefer
> 
> Am I missing something or there is a typo?

Hi

The documentation is a remnant of the original design, where the option
was next_hop_prefer_global bool. Later i changed that to be more symmetric
(next_hop_prefer with NHP_GLOBAL / NHP_LOCAL), but forgot to update the
docs.

Note that for gw_mode == GW_DIRECT, even before the patch we prefererred
the global next hop to link-local (see bgp_apply_next_hop()), so that why
there is a different default based on gw_mode, but the second part
(switching next hop to link-local for gw_mode == GW_DIRECT) is not
implemented yet.


> On Mon, Oct 10, 2022 at 5:44 AM Ondrej Zajicek via Bird-users
>  wrote:
> >
> > On Wed, Sep 21, 2022 at 08:47:03AM +, Mazur, Dariusz wrote:
> > > Hello Ondrej,
> > > Thanks for quick response. Additional option to ignore link-local BGP 
> > > next hops would help us a lot.
> >
> > Hello
> >
> > Done, here is a commit with BGP channel option 'next hop prefer global',
> > which makes BIRD to use global next hop instead of link-local:
> >
> > https://gitlab.nic.cz/labs/bird/-/commit/8f79e6b93e32a4eb7e4dda9bd4a9d04400b79d45

-- 
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."

Re: Link local vs global v6 next hop for BGP rotuer

[Ondrej Zajicek via Bird-users]

On Wed, Sep 21, 2022 at 08:47:03AM +, Mazur, Dariusz wrote:
> Hello Ondrej,
> Thanks for quick response. Additional option to ignore link-local BGP next 
> hops would help us a lot.

Hello

Done, here is a commit with BGP channel option 'next hop prefer global',
which makes BIRD to use global next hop instead of link-local:

https://gitlab.nic.cz/labs/bird/-/commit/8f79e6b93e32a4eb7e4dda9bd4a9d04400b79d45


> On 9/20/22, 6:11 PM, "Ondrej Zajicek"  wrote:
> 
> On Mon, Sep 19, 2022 at 01:23:28PM +, Mazur, Dariusz via Bird-users 
> wrote:
> > Hello,
> > In my setup I have iBGP session with peer , and I learn v6 route. It is 
> iBGP so we have 2 next hops global and link-local. By default bird uses 
> link-local when route is exported to kernel. Is there any command to change 
> this behavior and use global v6 address as BGP next hop when we export routes 
> to kernel ?
> 
> Hello
> 
> The dual next hop for IPv6 routes is kind of hack and not really
> reflected in filter code, which means that bgp_next_hop attribute
> represents just global address. Therefore, you can do:
> 
>   bgp_next_hop = bgp_next_hop;
> 
> in remote IBGP export filter to reset bgp_next_hop attribute to just
> its global address.
> 
> I think it would not work in local IBGP import filter - we assign
> recursive immediate next hop based on bgp_next_hop when route is received
> before import filter, so later change of bgp_next_hop in IBGP import
> filter would not affect existing immediate next hop.
> 
> You can also change immediate next hop (route attribute 'gw'), either in
> local IBGP import filter, or Kernel protocol export filter:
> 
>   gw = bgp_next_hop;
> 
> but that would work only if you have flat network and there is no
> intermediate hop between local system and bgp_next_hop.
> 
> 
> We probably should just add option to ignore link-local BGP next hops ...
> 
> 
> > Table master6:
> > fc00:2001:100:12::/64 unicast 
> [2001:4878:c225::1:3:2__r02.ien.labkrk01.sdn 12:57:29.076] * (100) [i]
> > via 2001:4878:c225::1:3:2 on eth-1\1\4
> > Type: BGP univ
> > BGP.origin: IGP
> > BGP.as_path:
> > BGP.next_hop: 2001:4878:c225::1:3:2 fe80::1:3:2
> > BGP.local_pref: 400
> > BGP.community: (20940,550)
> > 
> > Thanks,
> > Dariusz

-- 
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."

Re: Missing IPv6 default route on protocol kernel and table master6

[Ondrej Zajicek via Bird-users]

On Sun, Oct 09, 2022 at 07:43:56PM +0200, Bernd Naumann via Bird-users wrote:
> On 2022-10-07  18:32, Ondrej Zajicek wrote:
> > Does the pppoe-wan have link-local address range? Does BIRD know about it?
> > What is  What is the output from BIRD command 'show interfaces'?
> > 
> 
> I assume no. Like I have written, the LLA is `/128`. I do not see the
> gateway in the `neighbor` table, but local LLA and gateway LLA are present
> as host routes.

Oh, i missed that. In general, BIRD does check route next hops against IP
ranges of local addresses, not against other routes (i.e. gateway LLA as
host route or manually added /64 route), so if you have LLA as /128, then
the next hop check for gateway LLA fails. It is true that this check is
suboptimal and perhaps superfluous, we should reevaluate it.


> If I `ip route add fe80::/64 dev pppoe-wan` it makes *no* difference.

Yes, same like with gateway LLA host route.


> If I delete the `/128` LLA and replace it with `/64` it is still not present
> in `master6`

This is strange, i would predict that after this change it should start
working. Perhaps there is some bug in caching of next-hop lookups.

Could you try replacing LLA with /64, checking that there is still
default route in kernel table, and then restarting BIRD?


> ```
> root@cpe:~# ip -6 addr show dev pppoe-wan
> 42: pppoe-wan:  mtu 1492 qdisc
> fq_codel state UNKNOWN group default qlen 3
> inet6 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 scope global dynamic
> noprefixroute
>valid_lft 13837sec preferred_lft 1237sec
> inet6 fe80::71b4:e83:65bb:a41f/64 scope link
>valid_lft forever preferred_lft forever
> 
> pppoe-wan up (index=42)
> PtP Multicast AdminUp LinkUp MTU=1492
> 93.206.14.134/32 (Preferred, opposite 62.155.247.65, scope univ)
> 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 (Preferred, scope univ)
> fe80::71b4:e83:65bb:a41f/64 (Preferred, scope link)
> 
> root@cpe:~# birdc show route for ::/0
> BIRD 2.0.8 ready.
> Network not found


> But even if that would work, I would dislike it as a solution.
> My question still stands: Why is the route not present in `master6`, *even*
> that I have `learn yes` for `protocol kernel`. What does make this ipv6
> default route so special?

In short, it is special that LLA range for your address is /128 and
therefore the next hop of default route is outside of it.

-- 
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."

Re: Missing IPv6 default route on protocol kernel and table master6

[Ondrej Zajicek via Bird-users]

On Fri, Oct 07, 2022 at 11:29:33AM +0200, Bernd Naumann via Bird-users wrote:
> Update:
> 
> I would ratter prefer to understand why bird is unable to pick up the ipv6
> default route on this pppoe device.

Hi

Does the pppoe-wan have link-local address range? Does BIRD know about it?
What is  What is the output from BIRD command 'show interfaces'?

-- 
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."

Re: Missing IPv6 default route on protocol kernel and table master6

[Ondrej Zajicek via Bird-users]

On Thu, Oct 06, 2022 at 11:37:18AM +0200, Bernd Naumann via Bird-users wrote:
> I may should have had a look at the log before :/
> 
> ```
> Thu Oct  6 09:32:51 2022 daemon.err bird: KRT: Received route ::/0 with
> strange next-hop fe80::f6cc:55ff:fe42:1a94
> ```
> 
> But why is this a strange a next-hop? Routes with via Link-Local next-hop
> just work fine with OSPF and BGP, whats the issue here?

Hi

That error message means the next hop was not found in interface address
ranges. I do not see why link-local next hops should not work. What is
your output from command 'show interfaces'?

-- 
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."

Re: New RIP MD5 interface option to avoid sequence check

[Ondrej Zajicek via Bird-users]

On Mon, Oct 03, 2022 at 04:20:51AM +0200, Olivier Benghozi via Bird-users wrote:
> Hello,
> 
> I'm currently using RIP/Ripng with md5 auth with some Cisco/Juniper and 
> Quagga gears.
> I'm looking to switch from quagga to Bird(2).
>
> I would have a feature request about the RIP MD5 sequence number check
> (RFC rule, implemented by BIRD, is: accept only increasing sequence
> numbers, or accept lower only if restarting at 0).
>
> In our current usecase, end-to-end interfaces are not contiguous, and
> it happens that some various cases (like powercuts at one end) can lead
> to a situation when one dead RIP speaker comes back to life before full
> end to end connectivity is restored BUT before route expiration at the
> other side: therefore the received seqnumber starts at something higher
> than 0 but lower than the previous known one, so the routing will just
> fail.

I see the issue. RIP assumes that implementations should keep their (and
neighbor's) sequence numbers persistenly so they are always monotonic,
but BIRD does not do that (and as it seems others neither). BIRD at least
try to use real time as basis for sequence numbers, so in most cases it
would use increasing sequence number even after restart.

One question - if u understand it correctly, if the situation you
described happens, BIRD just ignores received packets (with wrong CSN -
crypographic sequence number), which leads to timeout and removal of
neighbor entry, after that new neighbor entry is created, stored neighbor
CSN is reset and new CSN is accepted, so routing is reestablished.

Does this happen or does it end with persisten failure?


> Quagga doesn't check seqnumbers at all, Cisco gears don't seem to, and 
> Juniper gears have a hidden option to disable this check (no-check-sequence).
> So we would have use/need for a config option (probably at the interface 
> level), to avoid the received crypto sequence number check (therefore md5 is 
> just a way to avoid transmitting the clear password on the wire).
> 
> Apart for the new option definition, the actual check is in 
> master/proto/rip/packets.c, I guess that the check in current line 391 would 
> have to include an additional «&& new_option_isnt_defined» to avoid yelling 
> about a sequence number too low...
> line 391:   if ((rcv_csn < n->csn) && (rcv_csn || n->uc))
> 
> What about such an additional feature ?

Will look at it.

-- 
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."

Re: Netlink: No route to host

[Ondrej Zajicek via Bird-users]

On Mon, Oct 03, 2022 at 07:07:58PM +0200, Marek Küthe via Bird-users wrote:
> Hello,
> 
> I hope this is the right place to ask my question:
> 
> I used bird2.0.10 (from debian backports) since some time I get the
> message "Netlink: No route to host", however in the bird log it does
> not specify which host it is. Is there any way to find out?

Hello

This is most likely related to failure to push route to kernel, perhaps
with invalid/strange next hop or iface.

You can enable 'debug all' for kernel protocol. That would at least show
which routes it tries to send.

If you do 'show route', you see '!' for routes that failed to install
into the kernel table.

-- 
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."

Re: bgp keepalive and expired issues on bird 1.6.8

[Ondrej Zajicek via Bird-users]

On Wed, Sep 28, 2022 at 12:22:10PM +0900, 안상혁 via Bird-users wrote:
> Hello,
> 
> we have encountered some issues using bird 1.6.8
> 
> there are two issues :
> 
> 1) sometimes bird looks like doesn't handle neighbor's bgp keepalive
> messages.

It is good idea to check which are effective keepalive and hold timeouts
(in 'show protocols all'), they may be different from configured ones due
to negotiation. It was possible to configure BIRD to have shorter or
similar hold interval to keepalive interval.

Also did that happen during CPU/BIRD full load, or during regular operation?


> when we get bgp hold timer exprired issue,
> on tcpdump there are keepalive packets that neighbor physical router sent
> and the server replied.
> 
> but there is no "Got KEEPALIVE" messages on bird.log and bgp session closed
> after "Error: Hold timer expired" message.
> 
> 2) bgp session exprired less than bgp hold timer value.
> 
> we set BGP hold timer to 9 seconds, but bgp expired in 7 seconds

Note that BGP timers are randomized a bit (RFC 4271 section 10, although
RFC leaves out HoldTimer, we randomize it too), so that is expected.


> or we should upgrade to bird 2?

We would strongly suggest upgrading to bird 2.

-- 
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."

Re: EBGP ECMP w/o add paths capability

[Ondrej Zajicek via Bird-users]

On Tue, Sep 20, 2022 at 12:18:48PM +, Milovancevic, Nemanja via Bird-users 
wrote:
> Dear all,
> 
> Since some of our customers have devices which are not supporting EBGP
> add-path capability, I was wondering would there be  an option that BIRD
> announces also other “not only best” paths, since it looks like that now
> only the best one elected, based on (router-id) RID is announced to the
> other customers (customers have normally 2 devices connected and announce
> the same prefixes)

No, that is not supported. We may consider something like that in the
future, but definitely not before transition to BIRD 3.0.

-- 
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."

Re: BIRD Crashes

[Ondrej Zajicek via Bird-users]

On Fri, Aug 19, 2022 at 09:13:55AM +0100, Ian Chilton wrote:
> Hi Barry!
> 
> On Thu, 18 Aug 2022, at 6:08 PM, Barry O'Donovan (INEX) wrote:
> > As you're running Bird 2.0.8 this should be no longer necessary. Per 
> > 2.0.8's release logs:
> > > Version 2.0.8 (2021-03-18)
> > >  o Automatic channel reloads based on RPKI changes
> 
> Ah that's interesting! - so you've just removed that cron job on yours and 
> it's all fine? - nothing needed to enable that?
> 
> Maybe it's some conflict between doing a manual reload and the newly added 
> automatic stuff that's the issue. The odd thing is, all 3 of our crashes have 
> been on our 'rs1'. Thankfully, but oddly, 'rs2' has been fine, with the exact 
> same config/peers.

Hi

Just a clarification to automatic reload based on RPKI changes - it is
enabled by default (controlled by option 'rpki reload'), but for BGP it
requires 'import table', which is not enabled by default. If you filter
RPKI on pipe from one table to another, you do not need to enable
anything, but if you filter RPKI in BGP import filter, you have to enable
'import table' or do it manually as before.

https://bird.network.cz/?get_doc&v=20&f=bird-3.html#proto-rpki-reload

https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-import-table

-- 
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."

Re: Bird 2.0.9 Crash when 16K routes sent from our App to Bird module

[Ondrej Zajicek via Bird-users]

On Fri, Sep 23, 2022 at 02:38:59PM +, mukund via Bird-users wrote:
>  
>  Hi,
> We are using bird version 2.0.9.  We have IXIA traffic which is sending 16K 
> OSPF  routes to our App which we send to Bird. Issue is seen when we restart 
> our App. As part of our restart app handling, we restart Bird as well.We see 
> a crash  with following BT
> VT33-VT33_PRI:~/backup/cores/coredump_2022-09-20.20.31.33# gdb bird 
> core.bird.30975GNU gdb (GDB) Red Hat Enterprise Linux 
> 7.6.1-120.0.1.el7Copyright (C) 2013 Free Software Foundation, Inc.License 
> GPLv3+: GNU GPL version 3 or later This is 
> free software: you are free to change and redistribute it.There is NO 
> WARRANTY, to the extent permitted by law.  Type "show copying"and "show 
> warranty" for details.This GDB was configured as 
> "x86_64-redhat-linux-gnu".For bug reporting instructions, please 
> see:...Reading symbols from 
> /home/talariuser/backup/cores/coredump_2022-09-20.20.31.33/bird...done.[New 
> LWP 30975][Thread debugging using libthread_db enabled]Using host 
> libthread_db library "/lib64/libthread_db.so.1".Core was generated by 
> `/home/talariuser/bird/sbin/bird -f'.Program terminated with signal 8, 
> Arithmetic exception.#0  0x0047262e in sl_free (s=0x783170, 
> oo=0x76e1fc60) at /tn-build/src/thir!
 d_party/bird/lib/slab.c:315315     /tn-build/src/third_party/bird/lib/slab.c: 
No such file or directory.Missing separate debuginfos, use: debuginfo-install 
glibc-2.17-325.0.1.el7_9.x86_64 openssl-libs-1.0.2k-22.el7_9.x86_64 
zlib-1.2.7-19.el7_9.x86_64(gdb) bt#0  0x0047262e in sl_free 
(s=0x783170, oo=0x76e1fc60) at 
/tn-build/src/third_party/bird/lib/slab.c:315#1  0x00462e33 in 
fib_delete (f=0x75f508, E=0x76e1fc60) at 
/tn-build/src/third_party/bird/nest/rt-fib.c:479#2  0x00420915 in 
rt_sync (p=0x75f350) at /tn-build/src/third_party/bird/proto/ospf/rt.c:2104#3  
0x004218da in ospf_rt_spf.part.31 (p=0x75f350) at 
/tn-build/src/third_party/bird/proto/ospf/rt.c:1721#4  0x0041f403 in 
ospf_rt_spf (p=0x75f350) at 
/tn-build/src/third_party/bird/proto/ospf/rt.c:1692#5  0x0042fb8f in 
ospf_disp (timer=0x782f10) at 
/tn-build/src/third_party/bird/proto/ospf/ospf.c:482#6  0x004736cf in 
timers_fire (loop=0x74e0e0 ) !
 at /tn-build/src/third_party/bird/lib/timer.c:235#7  0x00408d0a in 
io_loop () at /tn-build/src/third_party/bird/sysdep/unix/io.c:2260#8  
0x00405af6 in main (argc=2, argv=0x7fffeb68) at 
/tn-build/src/third_party/bird/sysdep/unix/main.c:952
> Since all routes are newly passed and OSPF SPF calculation is done from 
> scratch, not sure why delete / free has an issue.
> Also issue is not seen when there are less routes say ~200. Seems to be 
> specific to huge number.If any pointers to this will be helpful
> Thanks in advance .

Hi

Could you send us core dump and bird binary? Also could you try 2.0.10?

-- 
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."

Re: Link local vs global v6 next hop for BGP rotuer

[Ondrej Zajicek via Bird-users]

On Mon, Sep 19, 2022 at 01:23:28PM +, Mazur, Dariusz via Bird-users wrote:
> Hello,
> In my setup I have iBGP session with peer , and I learn v6 route. It is iBGP 
> so we have 2 next hops global and link-local. By default bird uses link-local 
> when route is exported to kernel. Is there any command to change this 
> behavior and use global v6 address as BGP next hop when we export routes to 
> kernel ?

Hello

The dual next hop for IPv6 routes is kind of hack and not really
reflected in filter code, which means that bgp_next_hop attribute
represents just global address. Therefore, you can do:

  bgp_next_hop = bgp_next_hop;

in remote IBGP export filter to reset bgp_next_hop attribute to just
its global address.

I think it would not work in local IBGP import filter - we assign
recursive immediate next hop based on bgp_next_hop when route is received
before import filter, so later change of bgp_next_hop in IBGP import
filter would not affect existing immediate next hop.

You can also change immediate next hop (route attribute 'gw'), either in
local IBGP import filter, or Kernel protocol export filter:

  gw = bgp_next_hop;

but that would work only if you have flat network and there is no
intermediate hop between local system and bgp_next_hop.


We probably should just add option to ignore link-local BGP next hops ...


> Table master6:
> fc00:2001:100:12::/64 unicast [2001:4878:c225::1:3:2__r02.ien.labkrk01.sdn 
> 12:57:29.076] * (100) [i]
> via 2001:4878:c225::1:3:2 on eth-1\1\4
> Type: BGP univ
> BGP.origin: IGP
> BGP.as_path:
> BGP.next_hop: 2001:4878:c225::1:3:2 fe80::1:3:2
> BGP.local_pref: 400
> BGP.community: (20940,550)
> 
> Thanks,
> Dariusz

-- 
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."

Re: Garbage collection of unused dynamic BGP neighbours

[Ondrej Zajicek via Bird-users]

On Tue, Sep 20, 2022 at 09:32:31AM +0200, Tore Anderson via Bird-users wrote:
> Hi
> 
> Is it possible to garbage collect unused dynamic BGP neighbours?

Hi

i think that 'configure' CLI command should remove unused dynamic BGP
instaces as a side-effect of its unused protocols cleanup code, even if
there is no change in configuration.

-- 
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."