Re: Extended communities ASN wildcard, extraction of eclist.

[Alexander Zubkov via Bird-users]

As extended communities have more complex structure than small or large
communities. It would be great to hear suggestions how such extractors
could look like. At least I do not have much experience with them.

On Wed, Jul 3, 2024 at 12:01 PM Ochalski, Radoslaw 
wrote:

> Thanks Alexander.
>
>
> I think it would be useful to have such extractors in place, like we do
> for lc lists.
>
>
>
> *Kind Regards,*
>
>
>
> Radek
>
>
>
>
>
> *From: *Alexander Zubkov 
> *Date: *Tuesday, July 2, 2024 at 7:42 PM
> *To: *"Ochalski, Radoslaw" 
> *Cc: *"bird-users@network.cz" 
> *Subject: *Re: Extended communities ASN wildcard, extraction of eclist.
>
>
>
> Hi,
>
>
>
> I think you can use "for" loop to work with a list of communities. But for
> ec there are currently no operators to access its inner components. I think
> partly because nobody has suggested such operators and their semantics yet.
>
>
>
> Regards,
>
> Alexander
>
>
>
> On Tue, Jul 2, 2024 at 1:17 PM Ochalski, Radoslaw via Bird-users <
> bird-users@network.cz> wrote:
>
> Since we are missing a way to apply a wildcard on ASN for extended
> community, is there a way to extract value from ec list? Like for lc list.
>
>
>
> 2024-07-02 11:00:05.579  Ext community(eclist (ro, 20940, value))
>
>
>
> I would like to match all ASNs by value, not by ASN.
>
>
>
> *Kind Regards,*
>
>
>
> *Radoslaw Ochalski*
>
>
> *Network Engineer Senior*
>
> *MON - FRI 08:00AM to 4:00 PM UTC*
>
> [image: cid72*image015.png@01DA1C68.FE26C0A0]
>
> Connect with Us:
>
> [image: cid72*image009.png@01DA1C68.FE26C0A0]
> <https://community.akamai.com/> [image:
> cid72*image016.png@01DA1C68.FE26C0A0] <http://blogs.akamai.com/> [image:
> cid72*image017.png@01DA1C68.FE26C0A0]
> <https://urldefense.com/v3/__https:/twitter.com/akamai__;!!GjvTz_vk!XMttgAB4-OEdY3PhzaD64Da6EsFgFcIYdWBtxvhe9rJ5UhN0XpHdCnKi9y75KQGYosylLPbxT3Loxg$>
>  [image: cid72*image018.png@01DA1C68.FE26C0A0]
> <https://urldefense.com/v3/__http:/www.facebook.com/AkamaiTechnologies__;!!GjvTz_vk!XMttgAB4-OEdY3PhzaD64Da6EsFgFcIYdWBtxvhe9rJ5UhN0XpHdCnKi9y75KQGYosylLPaRAvDuWQ$>
>  [image: cid72*image019.png@01DA1C68.FE26C0A0]
> <https://urldefense.com/v3/__http:/www.linkedin.com/company/akamai-technologies__;!!GjvTz_vk!XMttgAB4-OEdY3PhzaD64Da6EsFgFcIYdWBtxvhe9rJ5UhN0XpHdCnKi9y75KQGYosylLPb323UnRA$>
>  [image: cid72*image020.png@01DA1C68.FE26C0A0]
> <https://urldefense.com/v3/__http:/www.youtube.com/user/akamaitechnologies?feature=results_main__;!!GjvTz_vk!XMttgAB4-OEdY3PhzaD64Da6EsFgFcIYdWBtxvhe9rJ5UhN0XpHdCnKi9y75KQGYosylLPaKx6YSvw$>
>
>
>
>
>
>
>
>

Re: Extended communities ASN wildcard, extraction of eclist.

[Alexander Zubkov via Bird-users]

Hi,

I think you can use "for" loop to work with a list of communities. But for
ec there are currently no operators to access its inner components. I think
partly because nobody has suggested such operators and their semantics yet.

Regards,
Alexander

On Tue, Jul 2, 2024 at 1:17 PM Ochalski, Radoslaw via Bird-users <
bird-users@network.cz> wrote:

> Since we are missing a way to apply a wildcard on ASN for extended
> community, is there a way to extract value from ec list? Like for lc list.
>
>
>
> 2024-07-02 11:00:05.579  Ext community(eclist (ro, 20940, value))
>
>
>
> I would like to match all ASNs by value, not by ASN.
>
>
>
> *Kind Regards,*
>
>
>
> *Radoslaw Ochalski*
>
>
> *Network Engineer Senior*
>
> *MON - FRI 08:00AM to 4:00 PM UTC*
>
> [image: cid72*image015.png@01DA1C68.FE26C0A0]
>
> Connect with Us:
>
> [image: cid72*image009.png@01DA1C68.FE26C0A0]
>  [image:
> cid72*image016.png@01DA1C68.FE26C0A0]  [image:
> cid72*image017.png@01DA1C68.FE26C0A0]
> 
>  [image: cid72*image018.png@01DA1C68.FE26C0A0]
> 
>  [image: cid72*image019.png@01DA1C68.FE26C0A0]
> 
>  [image: cid72*image020.png@01DA1C68.FE26C0A0]
> 
>
>
>
>
>
>
>

Re: IPv6 BFD interop with Huawei, checksum 0 UDP

[Alexander Zubkov via Bird-users]

Great!

And how about it:

>  What do you think about changing bfd flags and/or socket flags to
bit fields too, as it was done with other flags recently?

I could try to prepare the patches, but only if such changes are welcomed.
I've checked the codebase and it seems there were not that much of
those as I remembered. :) I'm saying about those:

https://gitlab.nic.cz/labs/bird/-/commit/eb937358c087eaeb6f209660cc7ecfe6d6eff739#bc29837e5151fd51b826e385e6a10bd1584066ea_453_448
https://gitlab.nic.cz/labs/bird/-/commit/6b95353ebdaa724252492f941ebe75f80e9e545a#aa0b6ef7f4f7e5b9ffe1c80813d128cb4568fa53_140_140

On Thu, Jun 27, 2024 at 4:08 PM Ondrej Zajicek  wrote:
>
> On Thu, Jun 27, 2024 at 10:26:17AM +0200, Alexander Zubkov via Bird-users 
> wrote:
> > Hi all,
> >
> > Slightly modified the patch (names & description) in spite of the
> > checksum verify semantics.
>
> Hi, i already updated and merged your previous patch:
>
> https://gitlab.nic.cz/labs/bird/-/commit/8a40bccffe9e28e211fe996845658f87f5cc60e9
>
> --
> 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: IPv6 BFD interop with Huawei, checksum 0 UDP

[Alexander Zubkov via Bird-users]

Hi all,

Slightly modified the patch (names & description) in spite of the
checksum verify semantics.

On Wed, Jun 26, 2024 at 9:03 AM Ville O  wrote:
>
> Hello All,
>
> On Tue, Jun 25, 2024 at 9:05 PM Alexander Zubkov via Bird-users
>  wrote:
> > On Tue, Jun 25, 2024 at 3:04 PM Ondrej Zajicek  
> > wrote:
> > > Seems to me (from cursory look at the kernel code, as it seems to be an
> > > undocumented option) that the socket option UDP_NO_CHECK6_RX does not
> > > disable UDP checksum verification in general, just allows to accept UDP
> > > packets with zero checksum, while UDP packets with invalid non-zero
> > > checksums would still be rejected. Which fits better to what we need for
> > > this.
> >
> > I've grepped the kernel source and I agree, it seems to only accept
> > zero checksums. Then maybe some phrases need to be reworded and the
> > configuration option to be renamed?
> >
>
> This is the impression I, too, got while doing research into this matter
> and looking at the patches [1] that implemented this feature.
> The commit message is very clear: only a checksum of 0 is
> special-case accepted.
>
> By the way it seems the patch has been backported by RH at least
> as far back as EL7 kernel version 3.10.0.
>
> And I have an update on my problem that started all this:
>
> The peer managed to update their devices to the latest Huawei OS
> version and this fixed IPv6 BFD checksums.
> Unfortunately the peer could not give me the old/current versions so I
> cannot give information on which versions are broken and which are
> fixed. I tried to get more detailed information but it just was not
> possible; I can only say "latest version".
>
> Since the problem was fixed with the Huawei update I then regret
> that I am unable to usefully test the diff.
> I tested the new UDP socket option simply with scapy and maybe
> something similar could work for functional testing if required.
>
> A big thank you to everyone!
>
>
> Regards,
>
> V O
>
> [1]: 
> https://github.com/torvalds/linux/commit/1c19448c9ba6545b80ded18488a64a7f3d8e6998
>
commit 7932431fa14478648bce14249b6b110741731daf
Author: Alexander Zubkov 
Date:   Sat Jun 22 19:32:48 2024 +0200

BFD: add option to allow zero checksum for rx IPv6 UDP packets

Some vendors do not set the checksum for IPv6 UDP packets.
For interopertability with such implementations one can set UDP_NO_CHECK6_RX
socket option on Linux, in order to allow a zero checksum.

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8035ec18..50bfe9bc 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -2499,6 +2499,7 @@ milliseconds.
 
 protocol bfd [name] {
 	accept [ipv4|ipv6] [direct|multihop];
+	allow udp6 zero checksum rx switch;
 	interface interface pattern {
 		interval time;
 		min rx interval time;
@@ -2541,6 +2542,12 @@ protocol bfd [name] {
 	to configure separate BFD protocol instances for IPv4 and for IPv6
 	sessions.
 
+	allow udp6 zero checksum rx 
+	When enabled, this option configures the rx socket to allow an unset (zero)
+	IPv6 UDP checksum on the systems, which support such socket option
+	(ex. UDP_NO_CHECK6_RX). It is needed for interoperability with some
+	vendors that do not set the checksum. Default: disabled.
+
 	strict bind 
 	Specify whether each BFD interface should use a separate listening
 	socket bound to its local address, or just use a shared listening socket
diff --git a/lib/socket.h b/lib/socket.h
index 231c10d8..b3ffadad 100644
--- a/lib/socket.h
+++ b/lib/socket.h
@@ -131,6 +131,8 @@ extern int sk_priority_control;		/* Suggested priority for control traffic, shou
 #define SKF_HDRINCL	0x400	/* Used internally */
 #define SKF_PKTINFO	0x800	/* Used internally */
 
+#define SKF_UDP6_NO_CSUM_RX	0x1000	/* Allow zero checksum for incoming UDP6 */
+
 /*
  *	Socket types		 SA SP DA DP IF  TTL SendTo	(?=may, -=must not, *=must)
  */
diff --git a/proto/bfd/bfd.c b/proto/bfd/bfd.c
index 4f8499ba..cd78884a 100644
--- a/proto/bfd/bfd.c
+++ b/proto/bfd/bfd.c
@@ -1149,7 +1149,8 @@ bfd_reconfigure(struct proto *P, struct proto_config *c)
   (new->accept_ipv6 != old->accept_ipv6) ||
   (new->accept_direct != old->accept_direct) ||
   (new->accept_multihop != old->accept_multihop) ||
-  (new->strict_bind != old->strict_bind))
+  (new->strict_bind != old->strict_bind) ||
+  (new->udp6_no_checksum_rx != old->udp6_no_checksum_rx))
 return 0;
 
   birdloop_mask_wakeups(p->loop);
diff --git a/proto/bfd/bfd.h b/proto/bfd/bfd.h
index 847c6b14..2792ba92 100644
--- a/proto/bfd/bfd.h
+++ b/proto/bfd/bfd.h
@@ -48,6 +48,7 @@ struct bfd_config
   u8 accept_direct;
   u8 accept_multihop;
   u8 strict_bind;
+  u8 udp6_no_checksum_rx;
 };
 
 struct bfd_iface_config
diff --git

Re: IPv6 BFD interop with Huawei, checksum 0 UDP

[Alexander Zubkov via Bird-users]

Hi,

On Tue, Jun 25, 2024 at 3:04 PM Ondrej Zajicek  wrote:
>
> On Sat, Jun 22, 2024 at 07:44:34PM +0200, Alexander Zubkov via Bird-users 
> wrote:
> > Hello,
> >
> > Nobody has done it yet, so I've tried to implement it. The patch is
> > attached. Of course feel free to alter naming, wording, add credits
> > for the reported, etc. as you wish.
>
> Hello
>
> Thanks for the patch, will merge it.
>
> Seems to me (from cursory look at the kernel code, as it seems to be an
> undocumented option) that the socket option UDP_NO_CHECK6_RX does not
> disable UDP checksum verification in general, just allows to accept UDP
> packets with zero checksum, while UDP packets with invalid non-zero
> checksums would still be rejected. Which fits better to what we need for
> this.

I've grepped the kernel source and I agree, it seems to only accept
zero checksums. Then maybe some phrases need to be reworded and the
configuration option to be renamed?

>
> --
> 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: IPv6 BFD interop with Huawei, checksum 0 UDP

[Alexander Zubkov via Bird-users]

Hello,

Nobody has done it yet, so I've tried to implement it. The patch is
attached. Of course feel free to alter naming, wording, add credits
for the reported, etc. as you wish.

Ville, could you check that it works for you?

PS.
1) I also noticed there is "strict bind" example is missing in BFD
template config in the documentation.
2) What do you think about changing bfd flags and/or socket flags to
bit fields too, as it was done with other flags recently?

Regards,
Alexander


On Wed, Jun 12, 2024 at 3:14 PM Maria Matejka via Bird-users
 wrote:
>
> 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.
commit 2fcc6b08a96e45d49bb2ba901e7d1873a6564312
Author: Alexander Zubkov 
Date:   Sat Jun 22 19:32:48 2024 +0200

BFD: add option to ignore checksum for rx IPv6 UDP packets

Some vendors do not set the checksum correctly for IPv6 UDP packets.
For interopertability with such implementations one can set UDP_NO_CHECK6_RX
socket option on Linux, in order not to verify the checksum.

diff --git a/doc/bird.sgml b/doc/bird.sgml
index 8035ec18..ac5dd8fc 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -2499,6 +2499,7 @@ milliseconds.
 
 protocol bfd [name] {
 	accept [ipv4|ipv6] [direct|multihop];
+	check udp6 checksum rx switch;
 	interface interface pattern {
 		interval time;
 		min rx interval time;
@@ -2541,6 +2542,12 @@ protocol bfd [name] {
 	to configure separate BFD protocol instances for IPv4 and for IPv6
 	sessions.
 
+	check udp6 checksum rx 
+	This options when disabled configures the rx socket not to verify
+	the IPv6 UDP checksum on the systems, which support such socket option
+	(ex. UDP_NO_CHECK6_RX). It is needed for interoperability with some
+	vendors that do not set the checksum correctly. Default: enabled.
+
 	strict bind 
 	Specify whether each BFD interface should use a separate listening
 	socket bound to its local address, or just use a shared listening socket
diff --git a/lib/socket.h b/lib/socket.h
index 231c10d8..4f50fb3e 100644
--- a/lib/socket.h
+++ b/lib/socket.h
@@ -131,6 +131,8 @@ extern int sk_priority_control;		/* Suggested priority for control traffic, shou
 #define SKF_HDRINCL	0x400	/* Used internally */
 #define SKF_PKTINFO	0x800	/* Used internally */
 
+#define SKF_UDP6_NO_RX_CSUM	0x1000	/* Do not verify checksum for incoming UDP6 */
+
 /*
  *	Socket types		 SA SP DA DP IF  TTL SendTo	(?=may, -=must not, *=must)
  */
diff --git a/proto/bfd/bfd.c b/proto/bfd/bfd.c
index 4f8499ba..4ce4bf5a 100644
--- a/proto/bfd/bfd.c
+++ b/proto/bfd/bfd.c
@@ -1149,7 +1149,8 @@ bfd_reconfigure(struct proto *P, struct proto_config *c)
   (new->accept_ipv6 != old->accept_ipv6) ||
   (new->accept_direct != old->accept_direct) ||
   (new->accept_multihop != old->accept_multihop) ||
-  (new->strict_bind != old->strict_bind))
+  (new->strict_bind != old->strict_bind) ||
+  (new->udp6_no_rx_checksum != old->udp6_no_rx_checksum))
 return 0;
 
   birdloop_mask_wakeups(p->loop);
diff --git a/proto/bfd/bfd.h b/proto/bfd/bfd.h
index 847c6b14..dfc7d696 100644
--- a/proto/bfd/bfd.h
+++ b/proto/bfd/bfd.h
@@ -48,6 +48,7 @@ struct bfd_config
   u8 accept_direct;
   u8 accept_multihop;
   u8 strict_bind;
+  u8 udp6_no_rx_checksum;
 };
 
 struct bfd_iface_config
diff --git a/proto/bfd/config.Y b/proto/bfd/config.Y
index 39e7577f..112576e5 100644
--- a/proto/bfd/config.Y
+++ b/proto/bfd/config.Y
@@ -24,7 +24,7 @@ CF_DECLS
 CF_KEYWORDS(BFD, MIN, IDLE, RX, TX, INTERVAL, MULTIPLIER, PASSIVE,
 	INTERFACE, MULTIHOP, NEIGHBOR, DEV, LOCAL, AUTHENTICATION,
 	NONE, SIMPLE, METICULOUS, KEYED, MD5, SHA1, IPV4, IPV6, DIRECT,
-	STRICT, BIND)
+	STRICT, BIND, CHECK, UDP6, CHECKSUM)
 
 %type  bfd_neigh_iface
 %type  bfd_neigh_local
@@ -51,6 +51,7 @@ bfd_pro

nl_allow_replace check for primary key

[Alexander Zubkov via Bird-users]

Hi all,

I've noticed this patch:
https://gitlab.nic.cz/labs/bird/-/commit/00b139bd25c77b401d2065283cb970d9d8c1aa02

It says that "(net, metric) is the primary key". But for my
understanding the primary key in linux routing table also includes
tos. It seems that BIRD currently does not support routes with tos, so
it is not relevant now. But anyway the statement in code misses it,
and this rifle might shoot in the future if tos support is added.

Here is an example showing that tos is treated as a part of the primary key:

# ip route add 192.168.2.0/24 via 192.168.0.2 metric 10 tos 0x10
# ip route add 192.168.2.0/24 via 192.168.0.3 metric 10 tos 0x20
# ip -N route show 192.168.2.0/24
192.168.2.0/24 tos 0x20 via 192.168.0.3 dev eth0 metric 10
192.168.2.0/24 tos 0x10 via 192.168.0.2 dev eth0 metric 10
# ip ro replace 192.168.2.0/24 via 192.168.0.4 metric 10
# ip -N route show 192.168.2.0/24
192.168.2.0/24 tos 0x20 via 192.168.0.3 dev eth0 metric 10
192.168.2.0/24 tos 0x10 via 192.168.0.2 dev eth0 metric 10
192.168.2.0/24 via 192.168.0.4 dev eth0 metric 10
# ip ro replace 192.168.2.0/24 via 192.168.0.5 metric 10 tos 0x10
# ip -N route show 192.168.2.0/24
192.168.2.0/24 tos 0x20 via 192.168.0.3 dev eth0 metric 10
192.168.2.0/24 tos 0x10 via 192.168.0.5 dev eth0 metric 10
192.168.2.0/24 via 192.168.0.4 dev eth0 metric 10

Regards,
Alexander

Re: bird BFD is DOWN

[Alexander Zubkov via Bird-users]

Hi,

Could it be issue with a source port? It is described in the documentation,
btw:

https://bird.network.cz/?get_doc=20=bird-6.html#ss6.3

On Sat, Jun 8, 2024, 03:51 Maria Matejka via Bird-users <
bird-users@network.cz> wrote:

> 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 <
> bird-users@network.cz> 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: [Routing Issue] There are two same net range routing on routing table.

[Alexander Zubkov via Bird-users]

Hi,

Do you alter krt_metric in you kernel protocol export filter? That could
cause such problem. There was recently a question about it in this mailing
list.

Regards,
Alexander

On Mon, Jun 3, 2024, 03:40 이재용  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 bird
>
> 10.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 32
>
> 10.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?
>
>

Re: Route matching filter not exported

[Alexander Zubkov via Bird-users]

Say you have router A having routes with localpref 50, and router B with
localpref 100. When A receives a prefix from B, it will be the best in A's
table. Router A will not try to propagate routes with localpref 50, because
only the best route are propagated (usually). And as the best route is that
was received from B, then B will get nothing back.

On Fri, May 17, 2024, 19:16 Nico Schottelius 
wrote:

>
> I've a question to the list in regards to iBGP behaviour:
>
> - the router in question imports all routes with a bgp_local_pref of 50 [A]
> - the other routers import eBGP routes with a bgp_local_pref of 100 [B]
> - my assumption would be that the lower preference route would
>propagated via iBGP, however that is not the case
> - the above router also receive the higher preference routes via iBGP
>
> Is the default iBGP behaviour to *not* export routes with lower
> preference to other routers? That would explain the behaviour I see.
>
> Best regards,
>
> Nico
>
> --
> Sustainable and modern Infrastructures by ungleich.ch
>

Re: Route matching filter not exported

[Alexander Zubkov via Bird-users]

That looks different from the output in the first email. There best routes
were received not only from ibgp, but from the same peer, so it seems ok
that they were not sent back.
For this output you have now session with your ibgp peer eatablished, but
it still do not see the routes.
Localpref should not affect exporting directly, yes. It can alter the best
route, which will be considered for exporting.

On Fri, May 17, 2024, 18:36 Nico Schottelius 
wrote:

>
> Hello Alexander,
>
> the route is received via eBGP and should be redistributed via iBGP:
>
> bird> show route all 49.14.107.0/24
> Table master4:
> 49.14.107.0/24   unicast [outgoing_server120 16:13:14.594] * (100)
> [AS45271i]
> via 2a0a:e5c0:31:4::1 on tun1
> Type: BGP univ
> BGP.origin: IGP
> BGP.as_path: 209898 15576 3356 55644 45271
> BGP.next_hop: 2a0a:e5c0:31:4::1 fe80::2010:be9e:ed5f:ea08
> BGP.local_pref: 50
> BGP.atomic_aggr:
> BGP.aggregator: 10.100.230.241 AS65010
> BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502)
> (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000)
> BGP.otc: 209898
>  unicast [outgoing_server121 16:13:14.700] (100)
> [AS45271i]
> via 2a0a:e5c0:32:4::1 on tun0
> Type: BGP univ
> BGP.origin: IGP
> BGP.as_path: 209898 15576 3356 55644 45271
> BGP.next_hop: 2a0a:e5c0:32:4::1 fe80::5cd3:b71c:f90a:b469
> BGP.local_pref: 50
> BGP.atomic_aggr:
> BGP.aggregator: 10.100.230.241 AS65010
> BGP.community: (3356,2) (3356,22) (3356,100) (3356,123) (3356,502)
> (3356,903) (3356,2112) (15576,100) (15576,102) (15576,1000)
> BGP.otc: 209898
>
> The only difference to other routers is that the bgp local preference is
> 50, but from my understanding it should still be exported via iBGP.
>
> BR,
>
> Nico
>
> Alexander Zubkov  writes:
>
> > OK, I see that routes you showed have best from protocol ibgp. So I
> suppose they received from ibgp peer, and your are
> > sending them to ibgp peer too. That is not allowed by default.
> >
> > On Fri, May 17, 2024, 17:00 Nico Schottelius <
> nico.schottel...@ungleich.ch> wrote:
> >
> >  Ciao Alexander,
> >
> >  Alexander Zubkov  writes:
> >
> >  > Hello,
> >  >
> >  > Just curious. You've done "reload out" to your session after changing
> >  > the filter, right?
> >
> >  this is a very good point, but in this case the whole bird daemon is
> >  restarted, so this should not be an issue.
> >
> >  BR,
> >
> >  Nico
>
> --
> Sustainable and modern Infrastructures by ungleich.ch
>

Re: Route matching filter not exported

[Alexander Zubkov via Bird-users]

OK, I see that routes you showed have best from protocol ibgp. So I suppose
they received from ibgp peer, and your are sending them to ibgp peer too.
That is not allowed by default.

On Fri, May 17, 2024, 17:00 Nico Schottelius 
wrote:

>
> Ciao Alexander,
>
> Alexander Zubkov  writes:
>
> > Hello,
> >
> > Just curious. You've done "reload out" to your session after changing
> > the filter, right?
>
> this is a very good point, but in this case the whole bird daemon is
> restarted, so this should not be an issue.
>
> BR,
>
> Nico
>
>
>
>

Re: Route matching filter not exported

[Alexander Zubkov via Bird-users]

Hello,

Just curious. You've done "reload out" to your session after changing
the filter, right?

Regards,
Alexander

On Fri, May 17, 2024 at 4:45 PM Nico Schottelius via Bird-users
 wrote:
>
>
> Hello bird users,
>
> I've a strange case in which a router does not export routes that are
> matched by the export filter. I am using the filter "static_and_bgp"
> inside our iBGP sessions:
>
> 
> bird> show protocol all   ibgp_server137
> Name   Proto  Table  State  Since Info
> ibgp_server137 BGP---up 2024-05-12Established
>   BGP state:  Established
> Neighbor address: 2a0a:e5c0:0:b::89
> Neighbor AS:  199553
> Local AS: 199553
> Neighbor ID:  91.194.139.7
> Local capabilities
>   Multiprotocol
> AF announced: ipv4 ipv6
>   Route refresh
>   Extended next hop
> IPv6 nexthop: ipv4
>   Graceful restart
>   4-octet AS numbers
>   Enhanced refresh
>   Long-lived graceful restart
> Neighbor capabilities
>   Multiprotocol
> AF announced: ipv4 ipv6
>   Route refresh
>   Extended next hop
> IPv6 nexthop: ipv4
>   Graceful restart
>   4-octet AS numbers
>   Enhanced refresh
>   Long-lived graceful restart
> Session:  internal AS4
> Source address:   2a0a:e5c0:0:b::91
> Hold timer:   197.601/240
> Keepalive timer:  4.476/80
>   Channel ipv6
> State:  UP
> Table:  master6
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  static_and_bgp
> Routes: 204647 imported, 2 exported, 204647 preferred
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:6285634  0  0   3097
> 6282537
>   Import withdraws:  3559063  0---189
> 3558874
>   Export updates:67680676387362  37995--- 
> 342710
>   Export withdraws:  3370586--------- 
> 334365
> BGP Next hop:   2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c
> IGP IPv6 table: master6
>   Channel ipv4
> State:  UP
> Table:  master4
> Preference: 100
> Input filter:   ACCEPT
> Output filter:  static_and_bgp
> Routes: 947321 imported, 3 exported, 947318 preferred
> Route change stats: received   rejected   filteredignored   
> accepted
>   Import updates:   22332349  0  0   2202   
> 22330147
>   Import withdraws: 15475598  0---343   
> 15475255
>   Export updates:   24213451   22602108  0---
> 1611343
>   Export withdraws: 14527850---------
> 1598351
> BGP Next hop:   2a0a:e5c0:0:b::91 fe80::2f0:cbff:fefe:b70c
> IGP IPv4 table: master4
> IGP IPv6 table: master6
> 
>
> As you can see, the router in question only exports 2 IPv6 routes and 3
> IPv4 routes and uses the filter "static_and_bgp".
>
> When I check the route count matching the filter, the numbers look very
> different:
>
> 
> bird> show route filter static_and_bgp count
> 2841971 of 2841971 routes for 947325 networks in table master4
> 613945 of 613983 routes for 204686 networks in table master6
> Total: 3455916 of 3455954 routes for 1152011 networks in 2 tables
> bird>
> 
>
> And looking at some routes in detail:
>
> 
> bird> show route filter static_and_bgp
> Table master4:
> 0.0.0.0/0unicast [ibgp_server137 11:03:59.224 from 
> 2a0a:e5c0:0:b::89] * (100/?) [AS209898i]
> via fe80::3eec:efff:fed2:d1e4 on eth0
>  unicast [outgoing_server120 08:53:28.568] (100) 
> [AS209898i]
> via 2a0a:e5c0:31:4::1 on tun1
>  unicast [outgoing_server121 08:55:44.577] (100) 
> [AS209898i]
> via 2a0a:e5c0:32:4::1 on tun0
> 49.14.107.0/24   unicast [ibgp_server137 11:03:59.224 from 
> 2a0a:e5c0:0:b::89] * (100/?) [AS45271i]
> via fe80::3eec:efff:fed2:d1e4 on eth0
>  unicast [outgoing_server120 08:55:43.482] (100) 
> [AS45271i]
> via 2a0a:e5c0:31:4::1 on tun1
>  unicast [outgoing_server121 08:55:44.577] (100) 
> [AS45271i]
> via 2a0a:e5c0:32:4::1 on tun0
> 181.123.200.0/22 unicast [ibgp_server137 11:03:59.224 from 
> 2a0a:e5c0:0:b::89] * (100/?) [AS23201i]
> via fe80::3eec:efff:fed2:d1e4 on eth0
>  unicast [outgoing_server120 

Re: " bfd1: Socket error: Destination address required"

[Alexander Zubkov via Bird-users]

Hi,

You do not need to define neighbors for BGP sessions explicitly in
your BFD config. They are created automatically for BGP sessions with
BFD enabled. In that case, I suppose, you won't get errors for the
missing neighbors.

Regards,
Alexander

On Mon, Apr 29, 2024 at 1:16 PM Fran via Bird-users
 wrote:
>
> Hello there,
>
> I get the error message:
>
> " bfd1: Socket error: Destination address required"
>
> (ubuntu 22.04, bird via ppa 2.15.1) running BFD and MP-BGP via IPv6 over
> wireguard interfaces. Not all BGP neighbors are reachable.
>
> Relevant (I hope) config:
>
> log "/var/log/bird/bird.log" all;
>
> protocol device {
> }
>
> protocol bfd {
>accept ipv6 direct;
>interface "wg_blue*";
>interface "wg_green" {
>  multiplier 3;
>  interval 500 ms;
>};
>neighbor 2001:db8:f000::2 dev "wg_green" local 2001:db8:f000::1;
>neighbor 2001:db8:f000:::2 dev "wg_blue2" local
> 2001:db8:f000:::1;
>neighbor 2001:db8:f000:fffc::5 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::4 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::3 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
>neighbor 2001:db8:f000:fffc::2 dev "wg_blue1" local
> 2001:db8:f000:fffc::1;
> }
>
>
> protocol bgp EXAMPLE {
>local as 65001;
>neighbor 2001:db8:f000::2 as 65044;
>direct;
>med metric yes;
>ipv4 {
>  ...
>};
>ipv6 {
>  ...
>};
>bfd on;
> }
>
>
> If I remove the BFD config for the non-established BGP neighbors, the
> error message disappears (although there are still non-established BFD
> sessions for established BGP neighbors (BFD not yet confed on the other
> end)).
>
> At first I did not create neighbor statements for BFD, then I added
> "dev" and "local" options - no improvement.
>
> No revelations with "debug protocols all".
>
> Any ideas? Thanks a lot!
>
> Best,
>
> fran

Re: Problem with uplink network announcment in IPv6

[Alexander Zubkov via Bird-users]

Hello,

It would be helpful if you showed "ip route show" instead of "ip route
get" for your routes, so that one could see actual routes you have in
the routing table. Please also show you bird configuration.

Regards,
Alexander

On Fri, Mar 29, 2024 at 8:53 AM Yasen Atanasov  wrote:
>
> Hello,
>
> I've experienced a strange problem when implementing IPv6 connectivity.
>
> My ISP gave me /126 for connection between bgp routers and uplink 
> connectivity. A lot of(but not all) routes couldn't be inserted in the 
> kernel. After some experimentation we realized that administrative route that 
> is created buy the kernel for local networks was overridden by the bird and 
> after that no new routes were inserted in the kernel table.
>
> ~# ip r get x::y
> x::y from :: via x::y dev eth6 proto bird src x::z metric 32 pref medium
> vs
> x::y from :: dev eth6 proto kernel src x::z metric 256 pref medium
>
> Where x::y is uplink BGP peer and x::z our BGP router.
>
> Filtering /126 network from imports resolved the problem
>
> Is this normal behavior for Bird or some misconfiguration from our side?  
> Should I report that as misconfiguration to my ISP?
>
> I'm using bid 2.0.12 from Devuan 5 repos.
>
> Any input will appreciated.
>
> Yasen
>

Re: Adding a downstream ebgp connection. How to keep it separate?

[Alexander Zubkov via Bird-users]

Hi,

I think you need to start with explaining why do you want to keep
customer and upstream routes in separate tables.

Regards,
Alexander

On Tue, Mar 19, 2024 at 1:39 PM LU  wrote:
>
> Hello.
>
> I have two BGP routers with bird 2.4. Each router maintains some eBGP 
> connections to upstreams where I announce my prefixes. These routers have an 
> iBGP connection between themselves to exchange routes learned from those eBGP 
> connections.
>
> I do some filtering on the eBGP connections (like setting local preference, 
> as path prepending, setting an internal bgp community so that I know which 
> routes originate from which eBGP connection, etc.)
>
> So far this is simple, works great for my own traffic/prefixes and have no 
> trouble maintaining this.
>
> But now a need arose that I will be adding a downstream eBGP connection 
> (customer). This means transiting a foreign prefix over my BGP routers and 
> exporting some routes to it.
>
> How do I approach this the cleanest and simplest way possible?
>
> I suppose I should have two routing tables (currently under Linux/Bird 
> everything is under the default routing/main table):
>
> - main table (keep for my own traffic)
> - customer table
>
> But I am unsure what to do with my existing upstream eBGP connections since I 
> do some filtering on them for my own use cases.
>
> Should I have a separate Bird table for each upstream eBGP connection? Then 
> use the pipe protocol to put the routes in the main and customer table 
> separately?
>
> Then I could place the current filtering of eBGP connections that I use for 
> myself in the pipe protocol that feeds my main table?
>
> The customer table will then be piped the raw routes from the eBGP 
> connections.
>
> Is my thinking correct? Or this can be done better/differently?
>
> Are there perhaps any presentations and/or sample configs of such setups? I 
> am sure this situation comes up quite often.
>
> Thanks!
>
>
>
>

Re: [PATCH] BSD: macOS Support

[Alexander Zubkov via Bird-users]

Hi,

Maybe Darwin would be enough for testing this? It seems to me, that is
should contain all the necessary staff used by bird. Although, I do
not have experience with Darwin.

Regards,
Alexander

On Wed, Mar 13, 2024 at 2:34 PM Tom Herbers  wrote:
>
> Hi,
>
> GitHub offers free macOS Runners via GitHub Actions for all public
> repositories [1].
>
> That would be a legal of testing on macOS.
>
> Now, of course, someone would have to put together a suitable workflow.
>
>
> Kind regards,
> Tom
>
>
> [1]
> https://docs.github.com/de/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#standard-github-hosted-runners-for-public-repositories
>
> Am Mittwoch, dem 13.03.2024 um 11:11 +0100 schrieb 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_MD5SIG TCP_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
> > >
> > >
> >
>
>

show bfd sessions

[Alexander Zubkov via Bird-users]

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.

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] [|""]

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

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.

Regards,
Alexander

Re: non-persistent route via birdcl

[Alexander Zubkov via Bird-users]

Hi Robert,

You can import route from the kernel table and apply blackhole policy
based on its parameters like krt_metric or something else. You can
also import such routes from non-default kernel table and add it there
temporarily.

Regards,
Alexander

On Thu, Mar 7, 2024 at 5:10 PM Robert Blayzor via Bird-users
 wrote:
>
> Is there any possible way to interact with bird, ie: birdcl to add a
> non-persistent route into a routing table or is modifying the config and
> reload the only way?
>
> Using some mitigation tools and need to add some external blackhole
> routes and today it seems the only way to do that is via adding them to
> a static route config file and reloading.
>
> --
> inoc.net!rblayzor
> XMPP: rblayzor.AT.inoc.net
> PGP:  https://pgp.inoc.net/rblayzor/

Re: Injecting OSPF learned routes (only)

[Alexander Zubkov via Bird-users]

Hi all,

Maybe it can be solved by having those kernel routes in the bird
itself? So that it knows about them and choose them as the "best". In
that case it will not reexport them back to the kernel. Recent
addition of "learn all" option to kernel protocol should be helpful
here. Haven't tried such solution myself, though.

Regards,
Alexander

On Tue, Feb 27, 2024 at 9:10 AM ico  wrote:
>
> Hello Nico,
>
> I wrestled with this too. The reason you see those routes is this: If
> you configure an interface in OSPF, OSPF uses its own mechanism for
> learning link routes (direct routes?) from kernel. Those routes get into
> some bird's routing table together with all other routes from OSPF. And
> everything is exported into kernel.
>
> So my solution is to use differences between routes learned from
> neighbors and local link routes: link routes don't have a gateway.
> So I filter out all routes without gateway in export filter like this:
>
> protocol kernel krnl4 {
>  ipv4 {
>  export filter {
>  # export to kernel only routes with gateway
>  if gw.mask(0) = 0.0.0.0 then accept;
>  reject;
>  };
>  import filter {
>  # no default gw from kernel, want default gw from ospf
>  if net = 0.0.0.0/0 then reject;
>  accept;
>  };
>  };
>  learn;
> }
>
> I don't know how to filter routes with a gateway properly, but
> "gw.mask(0) = 0.0.0.0" works for me. Maybe there is some better way to
> do this?
>
> I hope this helps you.
>
> ico
>
> On 27. 2. 2024 4:30, Nico Schottelius via Bird-users wrote:
> >
> > Good morning bird users,
> >
> > I am a bit puzzled about properly adding OSPF learned routes into the
> > kernel and let me show you why:
> >
> > If I use a filter such as:
> >
> > filter static_and_bgp_and_ospf {
> >if(source = RTS_STATIC || source = RTS_BGP || source = RTS_OSPF) then 
> > accept;
> >reject;
> > }
> >
> > And configure the kernel to use it like this:
> >
> > protocol kernel kernel_v4 {
> >  ipv4 { export filter static_and_bgp_and_ospf; };
> > }
> >
> > protocol kernel kernel_v6 {
> >  ipv6 { export filter static_and_bgp_and_ospf; };
> > }
> >
> >
> > Then I get route duplications in the kernel:
> >
> > [04:29] server123.place10:~# ip r | grep 147.78.195.224/27
> > 147.78.195.224/27 dev eth1 proto kernel scope link src 147.78.195.254
> > 147.78.195.224/27 dev eth1 proto bird scope link metric 32
> >
> > The reason for that semes:
> >
> > - server123 has the route because of an interface address
> > - other hosts in the network also have an interface in that network
> >
> > While this is not necessarily a big problem, it seems wrong to inject
> > the route, because we learned it from OSPF, even though we already had
> > it in the first place.
> >
> > How do you usually handle inserting OSPF learned routes? Do you just
> > have them duplicate or do you have some logic that resembles..
> >
> >   "If I already have that route and I receive it again from outside
> >(such as OSPF), do not inject it again"
> >
> > ?
> >
> > Looking forward to read how you handle this logic!
> >
> > Best regards from Seoul,
> >
> > Nico
> >
> > --
> > Sustainable and modern Infrastructures by ungleich.ch

Re: Take Specific Value Inside BGP Community

[Alexander Zubkov via Bird-users]

Hi,

This statement is wrong:

peeras = ([(65535, 1000, *)].data2);

You try to pick "data2" from the communty set (= comunity filter). Filter
itself does not contain values. You need to apply it to some community list
first. Still you'll get a community list as a result. But you can pick
"data2" only from a single community. If you have or expect only one
community matching the filter and can ignore other values, you can use
min/max operators to take a single community from the list. But be aware
that an empty list will yield you an error here, so you need to check fist
that there is something there. Please also pay attention that you use a
legacy syntax for definition of block variables and function.

Not sure that I fully got you idea, but you can check this piece of code:

if (bgp_large_community ~ [(65535, 1000, *)]) then {
int peeras = filter(bgp_large_community, [(65535, 1000, *)]).min.data2;
bgp_large_community.delete([(65535, *, *)]);
bgp_large_community.add(( 64512, 101, peeras ));
accept; # not sure if it is good to accept/reject in a function
}

Regards,
Alexander


On Tue, Feb 20, 2024 at 9:12 AM Ilham Maulana 
wrote:

> Hi,
>
> Thanks for the reply.
>
> Here's what i'm going to do.
> --
> function is_to_some_ixp_comm()
> int *peeras*;
> {
> peeras = ([(65535, 1000, *)]*.data2*);
>
> if bgp_large_community ~ ([( 65535,1000,*peeras*)]) then {
> bgp_large_community.delete([(65535,*,*)]);
> bgp_large_community.add (( 64512,101,*peeras* ));
> accept;
> }
> }
> -
> i want to copy third community value from if statement, and adding it
> another community.
> but that function gives me error.
>
>  *No methods defined for type set*
>
> is that possible using bird?
>
> Thanks.
>
> On 20/02/2024 07:45:30, Erin Shepherd  wrote:
> It's a bit non-obvious, but you can do this with a loop. For example we
> basically replicate the Euro-IX routeserver announcement control
> communities inside our network, and we use the following function to
> translate them when exporting routes to a (supporting) route server
>
> # Translate Euro-IX common communities for use by a route server
> function translate_routeserver_communities(
>   int dest_asn
> )
> {
>   lclist announce_controls = filter(bgp_large_community, [(OURAS, 0..1,
> *)]);
>   for lc c in announce_controls do {
> bgp_large_community.add((dest_asn, c.data1, c.data2));
>   }
>
>   lclist prepends = filter(bgp_large_community, [(OURAS, 101..103, *)]);
>   for lc c in prepends do {
> bgp_large_community.add((dest_asn, c.data1, c.data2));
>   }
> }
>
> (I think we could combine those into one with a filter(bgp_large_community,
> [(OURAS, 0..1, *), (OURAS, 101..103, *)])? This code originally looked
> slightly different and at the time combining these wasn't posible.
>
> Note that this doesn't strip the input communities - we do that as a
> separate step later where we strip all non-informational communities
>
> - Erin
>
> On Tue, 20 Feb 2024, at 00:30, Ilham Maulana wrote:
>
> Hi,
>
>
> Is it possible in bird to copy specific value inside BGP Community?
>
> Example:
>
> Route 1, Community (a,b,*c*) -> inbound
> Route 2, Community (a,b,*d*) -> inbound
> --
> Route 1, Community (k,l,*c*) -> outbound
> Route 2, Community (k,l,*d*) -> outbound
>
> The specific value I want to preserve is c and d, and it is dynamic
> variable.
>
> whatever c and d inbound, copy to c and d outbound.
>
> Thanks.
> Ilham
> [image: 5f622eb5-c189-4e05-8584-e4a1d2071a6b]
>
>
> [image: 6e8681c1-f1d3-45a8-97bb-365e7ee8f797]

Re: point to point connection but no routes imported.

[Alexander Zubkov via Bird-users]

Hi,

The information you provide is a bit cryptic. For example you showed
logs from r1 and r2, but the protocol names mentioned there do not
correspond to the provided configs.
As I understand, you want to export full view from R2 to R1, it is
supposedly via protocol bgp ccre1_ipv4_1, which has export filter
bgp_export. Which seems not allow ipv4 networks other than
1.1.1.184/29. The same does import filter on R1.

Regards,
Alexander

On Sat, Feb 17, 2024 at 3:32 PM Benoit Chesneau
 wrote:
>
> So I have checked the log and I get this from the one that is supposed to 
> received the full view:
>
> ```
> 2024-02-17 14:26:39.745  ccre1_ipv4_1: State changed to up2024-02-17 
> 14:26:39.745  ccre1_ipv4_1.ipv4 < added 1.1.1.184/29 0L 5G blackhole
> 2024-02-17 14:26:39.745  ccre1_ipv4_1.ipv4 < filtered out 1.1.1..85/32 
> 9L 9G unicast
> 2024-02-17 14:26:39.745  ccre1_ipv4_1.ipv4 < filtered out 
> 1.1.1..200/31 9L 9G unicast
> 2024-02-17 14:26:39.745  ccre1_ipv4_1.ipv4 < filtered out 10.99.1.0/24 
> 7L 8G unicast
> 2024-02-17 14:26:39.745  ccre1_ipv4_1: Sending UPDATE
> 2024-02-17 14:26:39.745  ccre1_ipv4_1: Sending END-OF-RIB
> 2024-02-17 14:26:39.749  ccre1_ipv4_1: Got UPDATE
> 2024-02-17 14:26:39.749  ccre1_ipv4_1.ipv4 > added [best] 0.0.0.0/0 0L 
> 10G unicast
> 2024-02-17 14:26:39.749  ccre1_ipv4_1.ipv4 < rejected by protocol 
> 0.0.0.0/0 0L 10G unicast
> 2024-02-17 14:26:50.944  KRT: Error sending route 1.1.1..85/32 to 
> kernel: File exists
>
> ```
>
> Atter that no routes are sent. I don't really see what's wrong. R2 seems to 
> correctly send the routes :
>
> ```
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 72.11.128.0/19 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 190.5.224.0/22 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 203.146.227.0/24 
> 0L 15G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 156.0.64.0/23 0L 
> 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 154.63.140.0/24 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 102.190.36.0/22 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 87.221.202.0/24 
> 0L 15G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 201.124.8.0/23 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 170.247.208.0/22 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 180.150.14.0/23 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 190.52.76.0/24 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 109.239.96.0/20 
> 0L 16G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 192.12.54.0/24 
> 0L 15G unicast
> 2024-02-17 14:17:25.838  home_65001_ipv4.ipv4 < added 36.138.206.0/24 
> 0L 15G unicast
> ```
>
> Is there any template I could use to send the full view to  peer connected to 
> the router directly using a vlan?
>
> Benoît
>
> On Saturday, February 17th, 2024 at 11:49, Alexander Zubkov 
>  wrote:
>
> > Hi,
> >
> > Just to be sure. 1.1.1.1 and 1.1.1.2 are not in the single /31.
> > Please also provide more details. What protocol output do you show? What 
> > route do you want from R2 to R1. Please look at things like these:
> > show route all 
> > show route all export  
> > show route all protocol  
> >
> > On Sat, Feb 17, 2024, 00:21 Benoit Chesneau  
> > wrote:
> >
> > > Hi all,
> > >
> > >
> > > I have an issue witth the route import onbetween two machine. They are 
> > > connected to each others by a vlan and at each end ana /31 is setup. I 
> > > can ping between each end.
> > >
> > > R1: VLAN330(1.1.1.1) > R2 : VLAN330(1.1.1.2)
> > >
> > >
> > > R2( 1.1.1.2) is connected to upstreams transit and collect correctly the 
> > > routes. But when I do the following config on this rouyer (R2):
> > >
> > > R2 is showing some exported routes but R1 received nothing:
> > >
> > > ```
> > > Route change stats: received rejected filtered ignored accepted
> > > Import updates: 1 0 0 0 1
> > > Import withdraws: 0 0 --- 0 0
> > > Export updates: 934590 27 0 --- 934563
> > > Export withdraws: 18 --- --- --- 18
> > > ```
> > >
> > > What could be the issue ?
> > >
> > >
> > >
> > >
> > > I have the following configuratiosn:
> > >
> > >
> > > R1:
> > > ```
> > > define

Re: point to point connection but no routes imported.

[Alexander Zubkov via Bird-users]

Hi,

Just to be sure. 1.1.1.1 and 1.1.1.2 are not in the single /31.
Please also provide more details. What protocol output do you show? What
route do you want from R2 to R1. Please look at things like these:
show route all 
show route all export  
show route all protocol  

On Sat, Feb 17, 2024, 00:21 Benoit Chesneau 
wrote:

> Hi all,
>
>
> I have an issue witth the route import onbetween two machine. They are
> connected to each others  by a vlan and at each end ana /31 is setup. I can
> ping between  each end.
>
> R1: VLAN330(1.1.1.1) > R2 : VLAN330(1.1.1.2)
>
>
> R2( 1.1.1.2)  is connected to upstreams transit  and collect correctly the
> routes. But when I do the following config on this rouyer (R2):
>
> R2 is showing some  exported routes but R1 received nothing:
>
> ```
> Route change stats: received   rejected   filteredignored
>  accepted
>   Import updates:  1  0  0  0
> 1
>   Import withdraws:0  0---  0
> 0
>   Export updates: 934590 27  0---
>  934563
>   Export withdraws:   18---------
>18
> ```
>
> What could be the issue ?
>
>
>
>
> I have the following configuratiosn:
>
>
> R1:
> ```
> define AS65001_IPV4 = [1.1.1.184/29{29,32}
> 
> ];
>
>
> filter ebgp_home_as65001_import {
> if (net.type = NET_IP4 && ! (net ~ AS65001_IPV4)) then reject;
> accept;
> }
>
> filter ebgp_home_as65001_export {
>
> protocol bgp home_65001_ipv4 {
>   local 1.1.1.2 as 209823;
>   neighbor 1.1.1.1 as 65001;
>   default bgp_med 0;
>   default bgp_local_pref 400;
>   ipv4 {
> import keep filtered;
> import filter ebgp_home_as65001_import;
> export all;
> next hop self on;
>   };
> };
> ```
>
> R2:
>
> ```
> router id 1.1.1.1;
>
> log syslog all;
>
> log "/var/log/bird.log" all;
> debug protocols all;
>
>
> watchdog warning 5 s;
> watchdog timeout 30 s;
>
>
> protocol device {
>   scan time 30;
> }
>
> protocol direct {
>   ipv4;
>   ipv6;
>   check link yes;
> }
>
>
> protocol kernel kernel4 {
>   ipv4 { import all; export where source != RTS_DEVICE; };
>   learn off;
>   scan time 300;
> }
>
> protocol kernel kernel6 {
>   ipv6 { import all; export where source != RTS_DEVICE; };
>   learn off;
>   scan time 300;
> }
>
> protocol static static4 {
>   ipv4 { export all; };
>   # Reject default route
>  route 0.0.0.0/0 unreachable;
>
>   # main route
>   route 1.1.1.184/29 blackhole;
> }
>
>
>
> filter bgp_export {
>   if (net.type = NET_IP4 && ! (net ~ [ 1.1.1.184/29 ])) then reject;
>
>   accept;
> }
>
> template bgp T_GW4 {
>   local 1.1.1.1 as 65001;
>   default bgp_med 0;
>   default bgp_local_pref 400;
>   multihop;
>   ipv4 { import keep filtered; import all; export filter bgp_export; next
> hop self on; };
> }
>
> protocol bgp ccre1_ipv4_1 from T_GW4 { neighbor 1.1.1.2 as ; };
> ```
>
> Benoît Chesneau, Enki Multimedia
> —
> t. +33608655490
>
> Sent with Proton Mail secure email.
>
>

Re: Multiple ebgp neighbours to the same peer

[Alexander Zubkov via Bird-users]

Hi,

For example if you want to establish several sessions over different
pathes. Also my use-case is to export routes to a BGP monitoring
system, that have fixed remote IP, but I want to send "views" from my
several upstreams, each over a separate session.

On Thu, Feb 8, 2024 at 9:47 AM Bernd Naumann  wrote:
>
> Good Morning,
>
> Could someone explain[1] to me the use-case(s) why I would need to
> establish two or more BGP session between the same to peers, please?
>
> Thanks in advance!
> Best,
> Bernd
>
> [1] Or point me to some resources.

Re: Add random number

[Alexander Zubkov via Bird-users]

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

Re: upgrade from 2.13 to 2.14

[Alexander Zubkov via Bird-users]

Hi Marek,

Yes, there is a change of syntax in 2.14. The notifications show you
that the return type of the function was automatically inferred.

https://gitlab.nic.cz/labs/bird/-/blob/v2.14/NEWS?ref_type=tags#L19

> User-defined filter functions that return values now should have return type
> statements. We still accept functions without such statement, if they could be
> properly typed.

Regards,
Alexander

On Thu, Feb 8, 2024 at 7:53 PM Marek Zarychta via Bird-users
 wrote:
>
> Dear List,
>
> today, after 299 days of machine uptime I broke 7-months lasting BGP
> sessions and upgraded both: FreeBSD and BIRD on our router from
> 13.2-STABLE to 14.0-STABLE. Now bird2-netlink-2.14 is installed and it
> seems to be working fine, though surprising notifications showed up in
> the log file:
>
> bird: /usr/local/etc/bird.conf:114:57: Inferring function
> check_import_v4 return type from its return value: bool
> bird: /usr/local/etc/bird.conf:162:58: Inferring function
> check_import_v6 return type from its return value: bool
>
> These lines are respectively:
> if (net.len < 8) || (net.len > 24) then return false;
> and
> if (net.len < 16) || (net.len > 48) then return false;
>
> I believe the warnings are harmless since  "configure check" passes, but
> please let me know if anything is wrong with this syntax.
>
> Cheers
>
> --
> Marek Zarychta
>

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

[Alexander Zubkov via Bird-users]

Hi Mark,

Actually the best route selection algorithm can be found here:
https://bird.network.cz/?get_doc=20=bird-2.html#ss2.1

And the preference is clearly noticed there. Have you looked for it in
some other place? If you describe how did you try to find it, I
believe it might help the developers to better structure the
documentation.

Best regards,
Alexander

On Thu, Feb 8, 2024 at 11:41 AM Mark Shuttleworth
 wrote:
>
> Hi folks
>
> Thank you for Bird, I have enjoyed working with it over the holidays for a 
> personal project routing between offices. Along the way I got stuck on an 
> issue that might catch other people as well, so I thought to describe it here 
> in the hope that docs are updated to make the behaviour more clear.
>
> I have a metropolitan area network between a few sites. Each of those sites 
> has its own internet connection, but the MAN is much faster, so my goal was 
> to route traffic to whichever exit point had the best bandwidth, using the 
> different sites as backup internet gateways. At each site, I was testing the 
> local connectivity (looking beyond simple link up to whether I could reach 
> common sites) and then, if the link was good, adding a static route out from 
> that location.
>
> I wanted to use Bird to export and distribute those static routes to other 
> sites, with custom metrics to prioritise the gateways that had the best 
> bandwidth.
>
> The expected behaviour for me was that a local, statically defined default 
> route would be imported and have the custom metric set based on its 
> bandwidth, and that the 'best' route would then win and be distributed by 
> OSPF to the other sites.
>
> The problem I ran into was that the implicit protocol preference comparison 
> prevented the local route from even being considered at all. So once a route 
> had propagated to a site with Bird, it could not be displaced by a 'better' 
> static route, because of the relative preferences.
>
> I ended up with a config like this, where the explicit preference solved the 
> issue:
>
> protocol kernel {
> learn;  # Learn alien routes from the kernel
> ipv4 {  # Connect protocol to IPv4 table by channel
> import filter {
> if net = 0.0.0.0/0 then { # We only want default 
> routes added manually to this machine
> ospf_metric2 = 1000;
> preference = 150;
> accept "Accepted default route from kernel";
> }
> reject;
> };
> export all; # Install all Bird routes in kernel
> };
> }
>
> I couldn't find any documentation that explained the role of 'preference' in 
> the import process, so I was stuck on this for an embarrassing amount of time 
> :blush: In the end, this blog https://mk16.de/blog/bird-preference/ and some 
> tangential comments in mailing lists led me to try the explicit preference, 
> and that solved the issue. Apologies if I missed this in the docs, but if it 
> isn't already covered, perhaps a more detailed explanation of the way routes 
> are compared for import into a table would help others.
>
> Again, thank you for Bird! I think we might build it into Ubuntu in some 
> interesting ways :)
>
> Mark

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

[Alexander Zubkov via Bird-users]

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.

>
> 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)

[Alexander Zubkov via Bird-users]

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 <
> bird-users@network.cz> 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.
>>
>> 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: Overloading RTR to load IRR (Was: Defines for mixed IPv6/IPv4)

[Alexander Zubkov via Bird-users]

AFAIK in RPKI AS0 means implicit invalid.

On Thu, Jan 25, 2024, 14:31 Maria Matejka via Bird-users <
bird-users@network.cz> 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.
>
> 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

[Alexander Zubkov via Bird-users]

Hi,

I want to also show some example of configuration generation:
https://gitlab.com/qratorlabs/example-automatic-filters
There are also a couple of links to other similar projects. Jeroen,
thanks for the reference to kees, I've added it to the list there too.

Regards,
Alexander

On Wed, Jan 24, 2024 at 11:14 AM Maria Matejka via Bird-users
 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.
>
> Maria
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
>

Re: Bug in bfd implementation: Wrong TTL on bfd control packets (was: Re: BFD sessions with FFR (VyOS) won't establish)

[Alexander Zubkov via Bird-users]

Hi Lukas,

Actually I saw support for TTL security in BFD code:
https://gitlab.nic.cz/labs/bird/-/blob/master/proto/bfd/packets.c#L496

And I see in your config example that you use multihop BFD, but RFC
you refer is talking about single-hop BFD usage. So it does not seem
like a bug here. Maybe the other side does not consider this BFD
sessions multihop and thus applying the TTL security policy?

Regards,
Alexander

On Sat, Jan 20, 2024 at 11:18 AM Lukas Haase  wrote:
>
> Hi,
>
> After long debugging I finally figured out why Bird's bfd cannot establish a 
> session with FRR (VyOS): Packets are sent with TTL 64. However, according to 
> https://datatracker.ietf.org/doc/rfc5881/, Section 5: "If BFD authentication 
> is not in use on a session, all BFD Control packets for the session MUST be 
> sent with a Time to Live (TTL) or Hop Limit value of 255".
>
> This is the reason why FRR just drops packets received from bird and the 
> session never establishes.
>
> As a quick workaround, I could get it working with:
>
> sysctl -w net.ipv4.ip_default_ttl="255"
>
> However, bird should set TTL appropriately.
>
> Is this something that was missed or is there an setting I am missing?
>
> Thanks,
> Luke
>
>
>
>
>
> > Gesendet: Mittwoch, 17. Januar 2024 um 01:24 Uhr
> > Von: "Lukas Haase via Bird-users" 
> > An: "Alexander Zubkov" 
> > Cc: bird-users@network.cz
> > Betreff: Re: BFD sessions with FFR (VyOS) won't establish
> >
> > Hi Alexander,
> >
> > Thanks. I have tried
> >
> > sysctl -w net.ipv4.ip_local_port_range="49152 65535"
> >
> > but unfortunately no change.
> > What I do not understand is that Interval and Timeout is wrong on the 
> > non-working peer:
> >
> > # birdc show bfd sess
> > BIRD 2.0.8 ready.
> > bfd1:
> > IP addressInterface  State  Since Interval  
> > Timeout
> > 172.20.215.130---Up 2024-01-16  0.100
> > 0.500
> > 172.20.215.131---Init   2024-01-16  1.000   
> > 10.000
> >
> > Do these parameters need to be identical among peers, similar as with OSPF? 
> > Note, they are identical to my knowledge but could there be any implicit 
> > setting that causes discrepancy between the peers and would cause a 
> > connection being stuck in "Up"? For example, in bird I have "idle tx 
> > interval 500 ms" but I could not find a corresponding option in VyOS/FFR.
> >
> > Could you think of any tcpdump/netcat debug?
> >
> > Thanks,
> > Luke
> >
> >
> >
> > > Gesendet: Mittwoch, 17. Januar 2024 um 00:35 Uhr
> > > Von: "Alexander Zubkov" 
> > > An: "Lukas Haase" 
> > > Cc: bird-users@network.cz
> > > Betreff: Re: BFD sessions with FFR (VyOS) won't establish
> > >
> > > Hi,
> > >
> > > There were reports here in the list that some BFD peers do not allow
> > > connections from non-standard ports and bird do not choose source port
> > > specifically. So you might need to tune your sysctl like that:
> > >
> > > net.ipv4.ip_local_port_range = 49152 65535
> > >
> > > Not sure if this is the case, but I would try that first.
> > >
> > > Regards,
> > > Alexander
> > >
> > > On Tue, Jan 16, 2024 at 9:15 AM Lukas Haase via Bird-users
> > >  wrote:
> > > >
> > > > Hello,
> > > >
> > > > My BFD session between bird work fine but the ones but the ones to VyOS 
> > > > (which uses FFR) just won't connect:
> > > >
> > > > # birdc show bfd sess
> > > > BIRD 2.0.8 ready.
> > > > bfd1:
> > > > IP address Interface State Since Interval Timeout
> > > > 172.20.215.131 --- Init 10:39:14.183 1.000 10.000
> > > > 172.20.215.130 --- Up 10:42:03.901 0.100 0.500
> > > >
> > > > 172.20.215.131 is here a VyOS box and its FFR config looks like:
> > > >
> > > > !
> > > > bfd
> > > > peer 172.20.215.129 multihop local-address 172.20.215.131
> > > > detect-multiplier 10
> > > > transmit-interval 100
> > > > receive-interval 100
> > > > exit
> > > > !
> > > > exit
> > > > !
> > > > end
> > > >
> > > >
> > > > For reference, my bird config is trivially:
> > > >
> > > > protocol bfd
> > > > {
> > > > interface "local-ibgp" {
> > > > min rx interval 100 ms;
> > > > min tx interval 100 ms;
> > > > idle tx interval 500 ms;
> > > > multiplier 10;
> > > > };
> > > > neighbor 172.20.215.130 local 172.20.215.129 multihop;
> > > > neighbor 172.20.215.131 local 172.20.215.129 multihop;
> > > > }
> > > >
> > > >
> > > > I have turned off firewall. What else could go wrong?
> > > >
> > > >
> > > > Thanks,
> > > > Luke
> > >
> >
> >

Re: BFD sessions with FFR (VyOS) won't establish

[Alexander Zubkov via Bird-users]

Hi,

There were reports here in the list that some BFD peers do not allow
connections from non-standard ports and bird do not choose source port
specifically. So you might need to tune your sysctl like that:

net.ipv4.ip_local_port_range = 49152 65535

Not sure if this is the case, but I would try that first.

Regards,
Alexander

On Tue, Jan 16, 2024 at 9:15 AM Lukas Haase via Bird-users
 wrote:
>
> Hello,
>
> My BFD session between bird work fine but the ones but the ones to VyOS 
> (which uses FFR) just won't connect:
>
> # birdc show bfd sess
> BIRD 2.0.8 ready.
> bfd1:
> IP address Interface State Since Interval Timeout
> 172.20.215.131 --- Init 10:39:14.183 1.000 10.000
> 172.20.215.130 --- Up 10:42:03.901 0.100 0.500
>
> 172.20.215.131 is here a VyOS box and its FFR config looks like:
>
> !
> bfd
> peer 172.20.215.129 multihop local-address 172.20.215.131
> detect-multiplier 10
> transmit-interval 100
> receive-interval 100
> exit
> !
> exit
> !
> end
>
>
> For reference, my bird config is trivially:
>
> protocol bfd
> {
> interface "local-ibgp" {
> min rx interval 100 ms;
> min tx interval 100 ms;
> idle tx interval 500 ms;
> multiplier 10;
> };
> neighbor 172.20.215.130 local 172.20.215.129 multihop;
> neighbor 172.20.215.131 local 172.20.215.129 multihop;
> }
>
>
> I have turned off firewall. What else could go wrong?
>
>
> Thanks,
> Luke

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

[Alexander Zubkov via Bird-users]

On Mon, Jan 15, 2024, 10:15 Lukas Haase  wrote:

> Hi Alexander,
>
> Thank you so much!
> Debian has bird2 package as well so I migrated and indeed it works!!
> There must be a bug in bird1 that causes recursive routes in static
> protocol not to resolve...


> As just a minor change to your solution, I changed the export filter in
> the bgp protocol to:
>
> if(net ~ [192.0.2.0/24{24,32} <http://192.0.2.0/24%7B24,32%7D>]) then
> accept;
>
> because I actually want to export the sub prefixes AND the /24.
>

Sure, if you need those. It is slightly out of scope of the topic, so I did
not included them in my filter. :) BTW ”x.x.x.x/24{24,32}” id equivalent to
”x.x.x.x/24+”.


> Sorry, there is just one last thing: Currently I define my /24 like this:
>
> protocol static static_bgp
> {
>   ipv4;
>   route 192.0.2.0/24 via Public-Ip-As-Seen-By-Peer;
> }
>
> How do I make sure that whatever route is sent has the public IP as
> next-hop? Since I am using recursive now, I do not have control over it.
> Will this be set automatically to what I set as "source address" in the
> bgp peer definition?
> Or should I explicitely add "next hop self"? Or should I explicitly modify
> "bgp_next_hop = ..." in the export filter of the bgp peer?
>

You can check the docs for the defaults. "next hop self" might be the
default for eBGP, but I do not remember exactly. You can set it explicitly
also. And yes, you can either use this option or override the next hop in
the effort filter.


> Thanks,
> Luke
>
> > Gesendet: Montag, 15. Januar 2024 um 00:11 Uhr
> > Von: "Alexander Zubkov" 
> > An: "Lukas Haase" 
> > Cc: bird-users@network.cz
> > Betreff: Re: Exporting a larger prefix if a smaller prefix is being
> exported
> >
> > Hi,
> >
> > I cannot tell for bird1, unfortunately. It might not work there at
> > all. Here is working example for bird2, I tested it and it seems
> > valid. I export smaller routes to a separate table, so that static
> > protocol use only those routes for recursive resolution, otherwise it
> > will also try to use default route and itself too. I also put static
> > routes to a separate table and pipe from it and filtering out the
> > unreachable ones. Because otherwise an unreachable route could be
> > selected the best (they all have the same metric) and not exported to
> > bgp. So check for unreachable in bgp export does not work well
> > actually, if there are more than one static route to choose from.
> > For bird1 please note, that it is announced EOL already. And it is
> > highly recommended to migrate to bird2.
> >
> > ipv4 table aggr_src;
> > ipv4 table aggr;
> >
> > protocol bgp test
> > {
> > local as 64512;
> > source address 10.55.55.251;
> > ipv4 {
> > import none;
> > export filter {
> > if(net = 192.0.2.0/24) then accept;
> > reject;
> > };
> > };
> > neighbor 10.55.55.250 as 65534;
> > password "xyz";
> > multihop 2;
> > }
> >
> > protocol static prefix_aggregation
> > {
> > ipv4 { table aggr; };
> > igp table aggr_src;
> > route 192.0.2.0/24 recursive 192.0.2.207;
> > route 192.0.2.0/24 recursive 192.0.2.208;
> > route 192.0.2.0/24 recursive 192.0.2.209;
> > }
> >
> > protocol device {}
> > protocol direct { ipv4; }
> >
> > protocol pipe pipe_aggr_src
> > {
> > table master4;
> > peer table aggr_src;
> > export filter {
> > if (net ~ [192.0.2.0/24{25,32}
> <http://192.0.2.0/24%7B25,32%7D>]) then accept;
> > reject;
> > };
> > import none;
> > }
> >
> > protocol pipe pipe_aggr
> > {
> > table master4;
> > peer table aggr;
> > export none;
> > import where dest != RTD_UNREACHABLE;
> >
> > }
> >
> > On Mon, Jan 15, 2024 at 8:59 AM Lukas Haase  wrote:
> > >
> > > Hi Alexander
> > >
> > > > Gesendet: Sonntag, 14. Januar 2024 um 23:03 Uhr
> > > > Von: "Alexander Zubkov" 
> > > > An: "Lukas Haase" 
> > > > Cc: bird-users@network.cz
> > > > Betreff: Re: Re: Exporting a larger prefix if a smaller prefix is
> being exported
> > > >
> > > > Hi Lukas,
> > > &

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

[Alexander Zubkov via Bird-users]

Hi,

I cannot tell for bird1, unfortunately. It might not work there at
all. Here is working example for bird2, I tested it and it seems
valid. I export smaller routes to a separate table, so that static
protocol use only those routes for recursive resolution, otherwise it
will also try to use default route and itself too. I also put static
routes to a separate table and pipe from it and filtering out the
unreachable ones. Because otherwise an unreachable route could be
selected the best (they all have the same metric) and not exported to
bgp. So check for unreachable in bgp export does not work well
actually, if there are more than one static route to choose from.
For bird1 please note, that it is announced EOL already. And it is
highly recommended to migrate to bird2.

ipv4 table aggr_src;
ipv4 table aggr;

protocol bgp test
{
local as 64512;
source address 10.55.55.251;
ipv4 {
import none;
export filter {
if(net = 192.0.2.0/24) then accept;
reject;
};
};
neighbor 10.55.55.250 as 65534;
password "xyz";
multihop 2;
}

protocol static prefix_aggregation
{
ipv4 { table aggr; };
igp table aggr_src;
route 192.0.2.0/24 recursive 192.0.2.207;
route 192.0.2.0/24 recursive 192.0.2.208;
route 192.0.2.0/24 recursive 192.0.2.209;
}

protocol device {}
protocol direct { ipv4; }

protocol pipe pipe_aggr_src
{
table master4;
peer table aggr_src;
export filter {
if (net ~ [192.0.2.0/24{25,32}]) then accept;
reject;
};
import none;
}

protocol pipe pipe_aggr
{
table master4;
peer table aggr;
export none;
import where dest != RTD_UNREACHABLE;

}

On Mon, Jan 15, 2024 at 8:59 AM Lukas Haase  wrote:
>
> Hi Alexander
>
> > Gesendet: Sonntag, 14. Januar 2024 um 23:03 Uhr
> > Von: "Alexander Zubkov" 
> > An: "Lukas Haase" 
> > Cc: bird-users@network.cz
> > Betreff: Re: Re: Exporting a larger prefix if a smaller prefix is being 
> > exported
> >
> > Hi Lukas,
> >
> > Two questions.
> > You add dummy interface on another node that propagates it via ospf to
> > your border?
>
> I do not, it's added locally. Same machine as bird is running. I just need
>
> interface "dum0" { stub yes; };
>
> to bring it into bird's routing table. I could also use protocol "direct" but 
> to simulate it as close as possible to my actual use case (where the possible 
> smaller prefixes will come over OSPF) I wanted to use OSPF.
>
> But in my understanding, it shouldn't matter where the route comes from.
>
> > And the most important one - you use bird version 1?
>
> Yes, it's the version included in Debian/Ubuntu stable. As long as I am not 
> hitting a huge roadblock I'd really like to keep it.
>
> Thanks,
> Luke
>
> > On Mon, Jan 15, 2024 at 6:23 AM Lukas Haase  wrote:
> > >
> > > Hi Alexander,
> > >
> > > Thank you again, this is really promising and I think I get the gist of 
> > > it.
> > > I have just one issue left: The /24 prefix keeps showing as unreachable.
> > >
> > > I have set up a test peer (both sides) to verify that routes come through.
> > >
> > > Here is my config:
> > >
> > > protocol bgp test
> > > {
> > > local as 64512;
> > > source address 10.55.55.251;
> > > import none;
> > > export filter {
> > > # announce all of our sub-prefixes
> > > if(net ~ [192.0.2.0/24{25,32}]) then accept;
> > >
> > > # if at least one of them is reachable, announce the 
> > > entire /24
> > > if(net = 192.0.2.0/24 && dest != RTD_UNREACHABLE) then 
> > > accept;
> > >
> > > reject;
> > > };
> > > neighbor 10.55.55.250 as 65534;
> > > password "xyz";
> > > multihop 2;
> > > }
> > >
> > > protocol static prefix_aggregation
> > > {
> > > route 192.0.2.0/24 recursive 192.0.2.0;
> > > route 192.0.2.0/24 recursive 192.0.2.1;
> > > route 192.0.2.0/24 recursive 192.0.2.2;
> > > route 192.0.2.0/24 recursive 192.0.2.3;
> > > route 192.0.2.0/24 recursive 192.0.2.4;
> > > route 192.0.2.0/24 recursive 192.0.2.5;
> > > route 192.0.2.0/24 recursive 192.0.2.6;
> > > route 192.0.2.0/24 recursive 192.0.2.7;
> > > route 192.0.2.0/24 recurs

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

[Alexander Zubkov via Bird-users]

88;
> route 192.0.2.0/24 recursive 192.0.2.189;
> route 192.0.2.0/24 recursive 192.0.2.190;
> route 192.0.2.0/24 recursive 192.0.2.191;
> route 192.0.2.0/24 recursive 192.0.2.192;
> route 192.0.2.0/24 recursive 192.0.2.193;
> route 192.0.2.0/24 recursive 192.0.2.194;
> route 192.0.2.0/24 recursive 192.0.2.195;
> route 192.0.2.0/24 recursive 192.0.2.196;
> route 192.0.2.0/24 recursive 192.0.2.197;
> route 192.0.2.0/24 recursive 192.0.2.198;
> route 192.0.2.0/24 recursive 192.0.2.199;
> route 192.0.2.0/24 recursive 192.0.2.200;
> route 192.0.2.0/24 recursive 192.0.2.201;
> route 192.0.2.0/24 recursive 192.0.2.202;
> route 192.0.2.0/24 recursive 192.0.2.203;
> route 192.0.2.0/24 recursive 192.0.2.204;
> route 192.0.2.0/24 recursive 192.0.2.205;
> route 192.0.2.0/24 recursive 192.0.2.206;
> route 192.0.2.0/24 recursive 192.0.2.207;
> route 192.0.2.0/24 recursive 192.0.2.208;
> route 192.0.2.0/24 recursive 192.0.2.209; # <-- this one should be reachable
> route 192.0.2.0/24 recursive 192.0.2.210;
> route 192.0.2.0/24 recursive 192.0.2.211;
> route 192.0.2.0/24 recursive 192.0.2.212;
> route 192.0.2.0/24 recursive 192.0.2.213;
> route 192.0.2.0/24 recursive 192.0.2.214;
> route 192.0.2.0/24 recursive 192.0.2.215;
> route 192.0.2.0/24 recursive 192.0.2.216;
> route 192.0.2.0/24 recursive 192.0.2.217;
> route 192.0.2.0/24 recursive 192.0.2.218;
> route 192.0.2.0/24 recursive 192.0.2.219;
> route 192.0.2.0/24 recursive 192.0.2.220;
> route 192.0.2.0/24 recursive 192.0.2.221;
> route 192.0.2.0/24 recursive 192.0.2.222;
> route 192.0.2.0/24 recursive 192.0.2.223;
> route 192.0.2.0/24 recursive 192.0.2.224;
> route 192.0.2.0/24 recursive 192.0.2.225;
> route 192.0.2.0/24 recursive 192.0.2.226;
> route 192.0.2.0/24 recursive 192.0.2.227;
> route 192.0.2.0/24 recursive 192.0.2.228;
> route 192.0.2.0/24 recursive 192.0.2.229;
> route 192.0.2.0/24 recursive 192.0.2.230;
> route 192.0.2.0/24 recursive 192.0.2.231;
> route 192.0.2.0/24 recursive 192.0.2.232;
> route 192.0.2.0/24 recursive 192.0.2.233;
> route 192.0.2.0/24 recursive 192.0.2.234;
> route 192.0.2.0/24 recursive 192.0.2.235;
> route 192.0.2.0/24 recursive 192.0.2.236;
> route 192.0.2.0/24 recursive 192.0.2.237;
> route 192.0.2.0/24 recursive 192.0.2.238;
> route 192.0.2.0/24 recursive 192.0.2.239;
> route 192.0.2.0/24 recursive 192.0.2.240;
> route 192.0.2.0/24 recursive 192.0.2.241;
> route 192.0.2.0/24 recursive 192.0.2.242;
> route 192.0.2.0/24 recursive 192.0.2.243;
> route 192.0.2.0/24 recursive 192.0.2.244;
> route 192.0.2.0/24 recursive 192.0.2.245;
> route 192.0.2.0/24 recursive 192.0.2.246;
> route 192.0.2.0/24 recursive 192.0.2.247;
> route 192.0.2.0/24 recursive 192.0.2.248;
> route 192.0.2.0/24 recursive 192.0.2.249;
> route 192.0.2.0/24 recursive 192.0.2.250;
> route 192.0.2.0/24 recursive 192.0.2.251;
> route 192.0.2.0/24 recursive 192.0.2.252;
> route 192.0.2.0/24 recursive 192.0.2.253;
> route 192.0.2.0/24 recursive 192.0.2.254;
> route 192.0.2.0/24 recursive 192.0.2.255;
> }
>
> I then set up a dummy device (and add it to OSPF so that it lands in birds 
> routing table):
>
> # ip link add dum0 type dummy
> # ip addr add 192.0.2.209/28 dev dum0
> # ip link set dev dum0 up
> # ping -c1 192.0.2.209
> PING 192.0.2.209 (192.0.2.209) 56(84) bytes of data.
> 64 bytes from 192.0.2.209: icmp_seq=1 ttl=64 time=0.022 ms
>
> --- 192.0.2.209 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 0.022/0.022/0.022/0.000 ms
>
> But then:
>
> # birdc show route | grep '^192\.0\.2\.'
> 192.0.2.208/28 dev dum0 [ospf 04:57:58] * I (150/10) [14x.xxx.223.80]
> 192.0.2.0/24   unreachable [prefix_aggregation 04:57:57] * (200)
> #
>
> The 192.0.2.208/28 shows up in the routing table, so it IS reachable and 
> hence at least one of the 192.0.2.0/24 route entries much be reachable. Yet, 
> 192.0.2.0/24 shows up as unreachable.
>
>
>
> Thanks,
> Luke
>
>
>
>
>
>
> > Gesendet: Sonntag, 14. Januar 2024 um 00:24 Uhr
> > Von: "Alexander Zubkov" 
> > An: "Lukas Haase" 
> > Cc: bird-users@network.cz
> > Betreff: Re: Exporting a larger prefix if a smaller prefix is being exported
> >
> > Hi Lukas,
> >
> > On Sun, Jan 14, 2024 at 6:23 AM Lukas Haase  wrote:
> > >
> > > Hi Alex,
> > >
> > > > Gesendet: Samstag, 13. Januar 2024 um 06:31 Uhr
> > > > Von: "Alexander Zubkov" 
> > > > An: "Lukas Haase" 
> > > > Cc: bird-users@network.cz
> > > > Betreff: Re: Exporting a larger prefix if a smaller prefix is being 
> > > > ex

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

[Alexander Zubkov via Bird-users]

Hi Lukas,

On Sun, Jan 14, 2024 at 6:23 AM Lukas Haase  wrote:
>
> Hi Alex,
>
> > Gesendet: Samstag, 13. Januar 2024 um 06:31 Uhr
> > Von: "Alexander Zubkov" 
> > An: "Lukas Haase" 
> > Cc: bird-users@network.cz
> > Betreff: Re: Exporting a larger prefix if a smaller prefix is being exported
> >
> > Hi,
> >
> > You cannot do "direct" prefix aggregation to a lager prefix in Bird
> > yet. But there are some ways to workaround it. You can define a static
> > route with recursive nex-hop like 192.0.2.x, and filter it out when it
> > is not reachable, but for any subprefix in /24 you would need to
> > define 256 of such static routes. So it is up to you how practical it
> > is.
>
> Interesting idea, this would be practical for me but I do not completely 
> understand yet what you mean.
> Which routes would I define and what would be the next hop ("like 192.0.2.x")?
>
> As an example, suppose the following prefixes are in my routing table and are 
> directly or indirectly reachable: 192.0.2.208/28, 192.0.2.250/31, 
> 192.0.2.184/29, 192.0.2.254/31, 192.0.2.176/29.
>
> Are you proposing?
>
> protocol static prefix_aggregation
> {
>   route 192.0.2.0/24 via 192.0.2.209;
>   route 192.0.2.0/24 via 192.0.2.250;
>   route 192.0.2.0/24 via 192.0.2.285;
>   route 192.0.2.0/24 via 192.0.2.254;
>   route 192.0.2.0/24 via 192.0.2.177;
> }

Yes, something like that. But it needs to be "recursive" not "via".
And your routes need not to be recursive already (for example iBGP
makes such routes by default), because double recursion won't work.

>
> If so, how do I avoid that 192.0.2.0/24 will be exported five times?

Yes, you'll have multiple similar routes. But if you do not have
add-path on your BGP session, only one of them will be exported. Also
in the recent version there is some aggregation support of same-net
prefixes, it can be helpful here too.

> And how do I set up an export filter on "next-hop is not reachable"?

You need to check the corresponding attribute of the prefix. See the
example later.

>
> By the way, the sub-prefixes, would I just export via a filter like this?

Yes, this filter seems to cover the sub-prefixes. But not sure what is
the nature of this question.

>
> export filter {
> if (net ~ [192.0.2.0/24{25,32}]) then {
> accept;
> }
> reject;
> }
>

Here is a config example I can imagine, not tested it at all.
Something like that works for us. But I would test it first that it
correctly adds/reverts the "aggregated" prefix. It adds static
prefixes in a separate table, but it can also be done in the main
table and reachability tested in bgp export filter for example.


ipv4 table aggr;

protocol static prefix_aggregation
{
  ipv4 { table aggr4; };
  route 192.0.2.0/24 recursive 192.0.2.209;
  ...
}

protocol pipe pipe_aggr
{
  table master4;
  peer table aggr;
  export filter {
if (net ~ [192.0.2.0/24{25,32}]) then {
  accept;
}
reject;
  };
  import filter {
if dest = RTD_UNREACHABLE then reject;
if (net = 192.0.2.0/24) then accept;
reject;
  };
}



> Thanks,
> Luke
>
>
>
> > You can also make some external daemon watching your kernel routes
> > and adding/deleting the aggregate route to the table.
> >
> > Regards,
> > Alexander
> >
> > On Sat, Jan 13, 2024 at 2:05 AM Lukas Haase via Bird-users
> >  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
> > >
> > >
> >

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

[Alexander Zubkov via Bird-users]

Hi,

You cannot do "direct" prefix aggregation to a lager prefix in Bird
yet. But there are some ways to workaround it. You can define a static
route with recursive nex-hop like 192.0.2.x, and filter it out when it
is not reachable, but for any subprefix in /24 you would need to
define 256 of such static routes. So it is up to you how practical it
is. You can also make some external daemon watching your kernel routes
and adding/deleting the aggregate route to the table.

Regards,
Alexander

On Sat, Jan 13, 2024 at 2:05 AM Lukas Haase via Bird-users
 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
>
>

Re: BGP,MRTDump: Dumps and Graceful restart

[Alexander Zubkov via Bird-users]

Hello,

Graceful restart allows not to flush the routes until the sessions are
reestablished and converged, it does not save bgp internal state. And
when the session is reestablished, the peers do initial exchange of
their routes as with a fresh start, what you can see in your mrtdump.
That is expected way of how things work.
You might want the peers to somehow remember the state before the old
BGP session disconnects and continue updates from that point later.
But as far as I know, there are no standard mechanisms for that.

Regards,
Alexander

On Fri, Jan 5, 2024 at 9:56 AM Ioannis Paterakis  wrote:
>
> Hello,
>
>
>
> I have a bird setup with graceful restart enabled on kernel and bgp 
> protocols. It seems to work fine.
>
>
>
> My wonder is that despite the fact that graceful restart functionality 
> persists the route tables during a broken bgp session, when the bgp session 
> gets re-established the mrtdump protocol which is enabled as well dumping 
> updates on a file gets filled with all the routes that are already present. 
> Is there a way to prevent this from happening ?
>
>
>
>
>
> Best wishes to everyone for 2024!
>
> IP

Re: BGP: Only possible to set neigbor once

[Alexander Zubkov via Bird-users]

Hi,

>From my understanding, there can be only one neighbor here, but you can set
different parts of it with multiple directives, i.e.:

neighbor 10.0.1.1;
neighbor as 65000;

But two different IPs would be two neighbors and you must have two separate
bgp protocols for that. Or a dynamic protocol that spawns specific
protocols.

Regards,
Alexander

On Sat, Dec 30, 2023, 14:42 Nico Schottelius via Bird-users <
bird-users@network.cz> wrote:

>
> Hello again,
>
> in the bird documentation for BGP it says:
>
>
> 
>  neighbor [ip | range prefix] [port number] [as number] [internal|external]
>
> ...
> Like local parameter, this parameter may also be used multiple times
> with different sub-options.
> ...
>
>
> 
>
> That is however not possible, as can be seen :
>
>
> 
> blind:/home/nico# bird -c ./bird.conf
> bird: ./bird.conf:3:28 Only one neighbor per BGP instance is allowed
> blind:/home/nico# cat bird.conf
> protocol bgp client1  {
> neighbor 10.0.1.1 as 65000;
> neighbor 10.0.1.2 as 65000;
>
> ipv4;
> }
>
> 
>
> So my question is, is
>
>  - a) the documentation wrong
>  - b) the code wrong or
>  - c) the reader wrong?
>
> Best regards,
>
> Nico
>
> p.s.: tested on bird 2.14
>
> --
> Sustainable and modern Infrastructures by ungleich.ch
>

Re: Multiple ebgp neighbours to the same peer

[Alexander Zubkov via Bird-users]

Hi,

Let's resurrect this question. :) I've made a patch to illustrate what
I mean about the wildcard address in the lock object.

Regards,
Alexander

On Tue, Jan 24, 2023 at 8:22 AM Alexander Zubkov  wrote:
>
>
>
> On Mon, Jan 23, 2023 at 3:17 PM Alexander Zubkov  wrote:
>>
>>
>>
>> On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek  
>> wrote:
>>>
>>> On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
>>> > Hi all,
>>> >
>>> > A quick try to fix the problem. But I'm not sure in complete correctness
>>> > though.
>>>
>>> Hi
>>>
>>> That looks more-or-less OK, will merge.
>>>
>>> > -ipa_equal(x->addr, y->addr);
>>> > +ipa_equal(x->addr, y->addr) &&
>>> > +ipa_equal(x->addr2, y->addr2);
>>>
>>> I think undefined addr2 should work like wildcard, i.e. the condition 
>>> should be:
>>>
>>
>> Maybe. I do not know well how this lock works. If different lock keys can 
>> affect another. And in this case it is probably better to fix "local" role 
>> for that second address and reflect it in its name.
>
>
> I think even better to call this wildcard_addr, for example. So if something 
> else needs this wildcard feature, it is clear which addr to use in the lock 
> object.
>
>>
>>
>>>
>>>  ipa_equal(x->addr, y->addr) &&
>>>  (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2, 
>>> y->addr2));
>>>
>>> (Undefined local ip will be resolved to some ip and may collide with
>>> defined ones.)
>>>
>>> --
>>> 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."
diff --git a/nest/locks.c b/nest/locks.c
index 812a6534..3d54f0f4 100644
--- a/nest/locks.c
+++ b/nest/locks.c
@@ -39,6 +39,11 @@
 static list olock_list;
 static event *olock_event;
 
+static inline int ipa_equal_wildcard(ip_addr x, ip_addr y)
+{
+  return ipa_zero(x) || ipa_zero(y) || ipa_equal(x, y);
+}
+
 static inline int
 olock_same(struct object_lock *x, struct object_lock *y)
 {
@@ -48,7 +53,8 @@ olock_same(struct object_lock *x, struct object_lock *y)
 x->vrf == y->vrf &&
 x->port == y->port &&
 x->inst == y->inst &&
-ipa_equal(x->addr, y->addr);
+ipa_equal(x->addr_strict, y->addr_strict) &&
+ipa_equal_wildcard(x->addr_wildcard, y->addr_wildcard);
 }
 
 static void
@@ -91,7 +97,7 @@ olock_dump(resource *r)
   struct object_lock *l = (struct object_lock *) r;
   static char *olock_states[] = { "free", "locked", "waiting", "event" };
 
-  debug("(%d:%s:%I:%d:%d) [%s]\n", l->type, (l->iface ? l->iface->name : "?"), l->addr, l->port, l->inst, olock_states[l->state]);
+  debug("(%d:%s:%I:%I:%d:%d) [%s]\n", l->type, (l->iface ? l->iface->name : "?"), l->addr_strict, l->addr_wildcard, l->port, l->inst, olock_states[l->state]);
   if (!EMPTY_LIST(l->waiters))
 debug(" [wanted]\n");
 }
diff --git a/nest/locks.h b/nest/locks.h
index 37026c68..e68321ae 100644
--- a/nest/locks.h
+++ b/nest/locks.h
@@ -25,7 +25,8 @@
 
 struct object_lock {
   resource r;
-  ip_addr addr;		/* Identification of a object: IP address */
+  ip_addr addr_strict;	/* Identification of a object: IP address (strict compare) */
+  ip_addr addr_wildcard;	/* ... another IP address (allow zero IP wildcard) */
   uint type;		/* ... object type (OBJLOCK_xxx) */
   uint port;		/* ... port number */
   uint inst;		/* ... instance ID */
diff --git a/proto/babel/babel.c b/proto/babel/babel.c
index 4187d258..113781d4 100644
--- a/proto/babel/babel.c
+++ b/proto/babel/babel.c
@@ -1932,7 +1932,7 @@ babel_add_iface(struct babel_proto *p, struct iface *new, struct babel_iface_con
 
   struct object_lock *lock = olock_new(ifa->pool);
   lock->type = OBJLOCK_UDP;
-  lock->addr = IP6_BABEL_ROUTERS;
+  lock->addr_strict = IP6_BABEL_ROUTERS;
   lock->port = ifa->cf->port;
   lock->iface = ifa->iface;
   lock->hook = babel_iface_locked;
diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
index 9d4671af..33e869d4 100644
--- a/proto/bgp/bgp.c
+++ b/proto/bgp/bgp.c
@@ -1615,7 +1615,8 @@ bgp_start(struct proto *P)
*/
   struct object_lock *lock;
   lock = p->lock = olock_new(P->pool);
-  lock->addr = p->remote_ip;
+  lock->addr_strict = p->remote_ip;

Re: logging via udp

[Alexander Zubkov via Bird-users]

Hi,

Thank you!

On Wed, Dec 13, 2023 at 2:35 PM Ondrej Zajicek  wrote:
>
> On Wed, Dec 13, 2023 at 11:50:42AM +0100, Alexander Zubkov wrote:
> > Hi,
> >
> > Thanks! I looked throught your version and it is unclear to me if the
> > sk is still added to the io loop list (sock_list) or not. It seems
> > that sk_insert() still should be called on log udp socket, because I
> > see no exception for it.
>
> Hi
>
> I use SKF_THREAD (like in your patch), so it is not inserted intoo sock_list.

Huh, now I see it clearly. :) Oversaw it, sorry.

>
> > And could you, please, also explain another moment:
> > https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179
> > Here your free the sk resource. Maybe this is done exactly because of
> > the io loop list, but I cannot find how sk_free() would remove the
> > socket from sock_list. It seems to me it would still refer the socket
> > after it is freed.
>
> sk_free() calls rem_node(>n) for non-SKF_THREAD sockets, so it would
> remove it from sock_list anyway.

As it is SKF_THREAD, it is not relevant yet. But I see here fd is set
to -1 before rfree():
https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179
And sk_free() will not call rem_node() in this case:
https://gitlab.nic.cz/labs/bird/-/blob/2c7555cf2ac8439713dd9148b348128c57222a38/sysdep/unix/io.c#L834
I worry it can lead to a hidden error in the future.

>
> The socket structure is freed because it is no longer needed,
> as the fd is tracked by the rfile structure anyway.

Yes, it seems OK. I just wasn't sure it is cleared properly.

>
> --
> 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: logging via udp

[Alexander Zubkov via Bird-users]

Hi,

Thanks! I looked throught your version and it is unclear to me if the
sk is still added to the io loop list (sock_list) or not. It seems
that sk_insert() still should be called on log udp socket, because I
see no exception for it. Didn't you have the same problem with reloads
as I had? I unfortunately do not remember exactly how it looked like,
but I'll try to retest it.
And could you, please, also explain another moment:
https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38#bc490dc797778621d2345fabe1fb0b59fce18264_141_179
Here your free the sk resource. Maybe this is done exactly because of
the io loop list, but I cannot find how sk_free() would remove the
socket from sock_list. It seems to me it would still refer the socket
after it is freed.
I would appreciate if you could explain thar to me for better
understanding the code.

Regards,
Alexander

On Wed, Dec 13, 2023 at 4:11 AM Ondrej Zajicek  wrote:
>
> On Sun, Jan 02, 2022 at 04:58:33PM +0100, Alexander Zubkov wrote:
> > Updated my last patch. I found a problem with that version, it hang on
> > reconfigure sometimes. It turned out that birdsocks are added to the
> > loop poll and it caused problems. Fixed that with SKF_THREAD flag, but
> > that may be a bit tricky. Also found myself that there is already a
> > structure for log config. And I also now do not abuse sk_write()
> > function for this patch, because it may be not suitable for that.
>
> Hi
>
> Finally got to merge that patch. :-)
>
> Replaced the unformatted output with RFC 3164 syslog format, so it is
> properly parsed by rsyslog (and hopefully others), also made some
> cleanups, restructuring and bugfixes.
>
> https://gitlab.nic.cz/labs/bird/-/commit/2c7555cf2ac8439713dd9148b348128c57222a38
>
>
> > On Sun, Jan 2, 2022 at 2:35 PM Alexander Zubkov  wrote:
> > >
> > > Hi,
> > >
> > > Is there reason agains adding udp log destination in bird? I have in
> > > attachmealsont a reworked version of the patch.
> > > This version does not use direct socket interface, but extends
> > > birdsock API for its needs. It also should not call (and possibly
> > > block) getaddrinfo() in case when plain IP is specified.
> > > It is a bit hacky - it uses birdsock to bind and connect the socket,
> > > then "steals" its file descriptor for rfile. But it shoud close
> > > correctly as I understand.
> > > And I'm not sure about my implementation using "log_udp_cfg" variable
> > > in the parser to gather configuration. Maybe it is not "safe" and it
> > > should not be global, but some space in pool should be allocated for
> > > it each time.
> > > There are other decisions, I'm not sure about. So if anything is bad -
> > > I can try to update it.
> > >
> > > On Wed, Dec 18, 2019 at 8:15 PM Alexander Zubkov  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Dec 18, 2019 at 1:01 PM Ondrej Zajicek  
> > > > wrote:
> > > > >
> > > > > On Wed, Dec 18, 2019 at 09:14:43AM +0100, Alexander Zubkov wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Made some dirty patch for myself to allow bird to send logs via udp.
> > > > > > But it may be useful not only for me, so posting it here. It could 
> > > > > > be
> > > > > > useful when server experiencing high IO-load. As syslog and file
> > > > > > operations in bird are blocking, it can be blocked on writing to it
> > > > > > for indefinite time, which could lead to various problems like
> > > > > > protocol timeouts. So udp logging comes in handy here. The tradeoff 
> > > > > > is
> > > > > > that we can miss some logs if they are not processed in time.
> > > > > > You can specify udp log destination like that:
> > > > > > log udp [host IP|"hostname"] [port NUMBER|"portname"] ...
> > > > >
> > > > > Hello
> > > > >
> > > > > Is this compatible with some standard for UDP logging or with other
> > > > > infrastructure (log deamons), or you just collect it using netcat?
> > > >
> > > > Not sure if it is standard now. And message format could be relatively
> > > > easily converted into one. That is one of the reasons the patch is
> > > > dirty. :)
> > > > From my experience syslog servers are mostly ok with non formatted
> > > > plain text udp messages with some issues, which are mor

Re: notification scripts ?

[Alexander Zubkov via Bird-users]

Hello,

Depending on the type of events needed, besides logs or active
monitoring with birdc, one can also do things like exporting routes to
some kernel table and monitoring them using netlink. Or setup a
"monitoring" bgp (or other protocol) sessions with something like
exabgp.

Regards,
Alexander

On Tue, Dec 12, 2023 at 5:25 PM Maria Matejka via Bird-users
 wrote:
>
> 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: wireguard + multihop BGP = route rejected, but route created

[Alexander Zubkov via Bird-users]

Hi,

Looks like it is the check that the route is not returned to the
session where it was received from.

Regards,
Alexander

On Sun, Dec 10, 2023 at 2:32 PM Ivan Agarkov  wrote:
>
> Hello!
>
> I'm creating a BGP lab for my students and found interesting and unexpected 
> behavior.
>
> I'm getting reject message when receiving route:
> 2023-12-10 15:10:53.724  isp1.ipv4 > added [best] 10.200.0.0/16 0L 4G 
> unicast
> 2023-12-10 15:10:53.724  isp1.ipv4 < rejected by protocol 
> 10.200.0.0/16 0L 4G unicast
>
> But then the route appears in ip route:
> 10.200.0.0/16 dev 201 proto bird scope link metric 32
>
> I've dug into the source code and found that the reject is happening here:
> proto/bgp/attrs.c:1641 if (src == p) return -1 into bgp_preexport function.
>
> The question is: what is happening and does it look valid/expected?
>
> Wireguard configuration is the same on all peers:
>
> [Interface]
> Address=10.10.10.201/32
> PrivateKey=**
> Table=off
>
> [Peer]
> Endpoint=***
> PublicKey=*
> PersistentKeepalive=25
> AllowedIPs=0.0.0.0/0
>
> My configuration for BIRD peers:
>  local bird.conf 
> log stderr all;
> router id 10.10.10.201;
>
> protocol device {
> scan time 10;
> }
>
> protocol kernel {
> ipv4 {
>  import all;
>  export all;
> };
> learn;
> }
>
> protocol static {
> ipv4;
> route 10.201.0.0/16 via "wlp41s0"; # wifi device
> route 10.10.10.0/24 via "201"; # wireguard device
> }
>
> protocol bgp isp1 {
> router id 10.10.10.201;
> local 10.10.10.201 as 65201;
> neighbor 10.10.10.200 as 65200;
> source address 10.10.10.201;
> multihop;
> ipv4 {
> import filter {
> if net ~ 10.0.0.0/8 then accept;
> else reject;
> };
> export filter {
> if net ~ 10.201.0.0/16 then accept;
> else reject;
> };
>
> };
> debug all;
> }
>  /client bird.conf 
>
>  remote bird.conf 
> log stderr all;
>
> protocol kernel {
> learn; # Learn all alien routes from the kernel
> persist; # Don't remove routes on bird shutdown
> scan time 20; # Scan kernel routing table every 20 seconds
> import all; # Default is import all
> export all; # Default is export none
> # kernel table 5; # Kernel table to synchronize with (default: main)
> }
>
> protocol device {
> scan time 10;
> }
>
> protocol static {
> export all;
> route 10.10.10.0/24 via "200"; # wireguard device
> route 10.200.0.0/16 via 10.200.200.200; # virtual network
> }
>
> template bgp cpr_ne {
> local as 65200;
> router id 10.10.10.200;
> multihop;
> source address 10.10.10.200;
> import filter {
> if net ~ 10.201.0.0/16 then accept;
> else if net ~ 10.202.0.0/16 then accept;
> else if net ~ 10.203.0.0/16 then accept;
> else if net ~ 10.204.0.0/16 then accept;
> else if net ~ 10.205.0.0/16 then accept;
> else if net ~ 10.206.0.0/16 then accept;
> else if net ~ 10.207.0.0/16 then accept;
> else if net ~ 10.208.0.0/16 then accept;
> else reject;
> };
> export filter {
> if net ~ 10.200.0.0/16 then accept;
> else reject;
> };
> }
>
> protocol bgp cpr201 from cpr_ne {
> neighbor 10.10.10.201 as 65201;
> }
> protocol bgp cpr202 from cpr_ne {
> neighbor 10.10.10.202 as 65202;
> }
> protocol bgp cpr203 from cpr_ne {
> neighbor 10.10.10.203 as 65203;
> }
> protocol bgp cpr204 from cpr_ne {
> neighbor 10.10.10.204 as 65204;
> }
> protocol bgp cpr205 from cpr_ne {
> neighbor 10.10.10.205 as 65205;
> }
> protocol bgp cpr206 from cpr_ne {
> neighbor 10.10.10.206 as 65206;
> }
> protocol bgp cpr207 from cpr_ne {
> neighbor 10.10.10.207 as 65207;
> }
> protocol bgp cpr208 from cpr_ne {
> neighbor 10.10.10.208 as 65208;
> }
>  remote bird.conf 

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

[Alexander Zubkov via Bird-users]

Hi Daniel,

On Mon, Nov 20, 2023, 03:05 Daniel Gröber  wrote:

> Hi Erin, Juliusz,
>
> On Sat, Nov 18, 2023 at 11:21:57AM +0100, Erin Shepherd wrote:
> > On Sat, 18 Nov 2023, at 03:19, Daniel Gröber wrote:
> > > That would be a problem as I specifically want to tie the source
> address
> > > filtering to this too. I'll have a look at the internals (if and) when
> I
> > > get around to starting work on this.
> >
> > Is tying source address filtering to the routing table the right thing to
> > do here? It seems to me that it would cause issues similar to those we
> > see more generally with Unicast Reverse Path Filtering
>
> IMO not providing a way to do source address filtering at the routing level
> was the original sin :)
>
> There is certianly the multihoming challange to be overcome as traditional
> BCP38 style filtering doesn't cut it in the general case. I have some ideas
> on how to deal with this.
>
> I've done some experiments and found that in Linux multi-nexthop routes
> actually match reverse path lookups (using nftables "rt") for _any_ of the
> source interfaces involved. I think this can be used to build RFC 3704
> style Feasible Path Reverse Path Forwarding when the routing daemon
> involved supports ECMP.
>
> This experiment is what got me interested in having via-wgpeer in the
> routing table in the first place, once we have that we can apply the above
> idea not just at the interface level but at the wg peer level. Neat.
>
> Can you think of a use-case where fpRPF isn't enough?
>

Yes. IMHO, the problem with RPF is that routing table doesn't reflect the
network topology, but only a subset of it. I mean in topologies where
multiple pathes are possible, you can choose to use or even learn only a
subset of those pathes. And that does not mean that there are no other
legitimate pathes exist, that other actors may choose to reach you.
In that sense might be yes, the original sin is that the routing table
doesn't reflect all the topology, not only the pathes we choose for egress.
Not sure though if it is a sin, in that case routing table would be too
overcomplicated.
If I understand correctly, such fpRPF approach works only if you both learn
all possible pathes and use all of them in a multi-nexthop route. But for
example in the Internet with its advanced BGP announcement policies it is
not true at all.
So from my point of view it is good to split the topology definition
(ingress decapsulation) and the chosen pathes (egress routing). Because it
is related, but still different processes. So the system can be more
flexible. Although we need to repeat common things and keep ingress and
egress consistent/synced.
At the same time we can use single protocol/configuration as a source of
information to setup both of those processes in cases when it is ok to
sacrifice flexibility for simplicity. Or for example the ingress part can
be configured to use routing table as a source of topology information.
Actually, when we turn on the RPF, we do something like that. But my point
is that RPF (with its variations too) has its bounds and cannot be a
universal solution, there is no silver bullet here.


> It's also noteworthy that once we have this support for via-wgpeer it'd be
> possible to apply ip-rule policy to the filtering decision. Perhaps that
> gives some additional power for more fun use-cases :)
>
> On Sat, Nov 18, 2023 at 01:22:03PM +0100, Juliusz Chroboczek wrote:
> > Issues are caused by the kernel performing filtering that the routing
> > protocol is not aware of: it causes the routing daemon's routing table to
> > no longer match the effective forwarding table (the kernel's routing
> > table).  That's the reason why uRPF breaks most routing protocols, that's
> > the reason why we have trouble making Wireguard work with Babel, and also
> > the reason behind https://github.com/jech/babeld/issues/111.
>
> Right on the money as always. This idea has been on my mind too.
>
> > Contrariwise, we can teach Babel to explicitly take into account the
> > kernel features that we're interested in using.  Thus, Babel could be
> > aware of the restrictions placed on a wireguard interface, and
> collaborate
> > with Wireguard so that the routing table and the forwarding table remain
> > congruent.  I haven't looked at the issue in detail, but I believe that
> > would be an interesting (short-term) research project, one that I would
> be
> > glad to collaborate with (but not necessarily lead, at least not right
> now).
>
> Sounds interesting do you have a funding source in mind?
>
> > For the specific case of source address filtering, Babel already has an
> > (implemented) extension to deal with source addresses, and I encourage
> you
> > to consider whether it can be used to deal with the issue at hand.
> Please
> > see https://arxiv.org/pdf/1403.0445.pdf and RFC 9079.
>
> I don't think I mentioned this to you yet, but I have another one of my
> crazy ideas of doing something vaguely similar to BGP flowspec 

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

[Alexander Zubkov via Bird-users]

Hello all,

I heard recently about the lightweight tunnel infrastructure in Linux
kernel (ip route ... encap ...). And I think this might be helpful in
the context of this thread. Linux kernel allows already to add
encapsulation parameters to the route entry in its table. So you do
not need to create tunnel devices for that. And wireguard
encapsulation and destination might be added there too. But as I
understood the technology, it works only in one way (for outgoing
packets) and the decapsulation should be processed separately, for
example in case of VXLAN and MPLS they have their own tables.

Regards,
Alexander Zubkov
Qrator Labs


On Mon, Sep 11, 2023 at 5:46 PM Maria Matejka via Bird-users
 wrote:
>
> 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: bird control socket response

[Alexander Zubkov via Bird-users]

Hi,

You can find some information about it here:

https://bird.network.cz/?get_doc=20=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 <
bird-users@network.cz> wrote:

> Classified as: {OPEN}
>
>
>
> I don’t think so.
>
> In fact, nothing wrong, just wondering the reason.
>
>
>
>
>
>
>
> {OPEN}
>
> *From:* netravnen+birdl...@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 <
> bird-users@network.cz> 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-device1Device ---up
>
>  static_bgp Static master4up
>
>  kernel1Kernel master4up
>
> 
>
>
>
>
>
>
>
> 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.*
>

Re: Transition from BIRD 1 to 2

[Alexander Zubkov via Bird-users]

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
>

Re: BIRD 2.14

[Alexander Zubkov via Bird-users]

Hi,

I want to add that I had the same problem with building bird master
branch some time ago for our Arista switches. I also found that
reverting f8bcb037b5b71a19209f1b63d52895c8c34c675b helps and maked the
build successful. But we did not try it in production yet.
Unfortunately, upgrading the kernel is not an option there, as the
whole system is proprietary. As far as I know it is based on some
Fedora and we have 4.9.* kernel there.

Regards,
Alexander

On Mon, Oct 9, 2023 at 12:19 AM Ondrej Zajicek  wrote:
>
> On Sun, Oct 08, 2023 at 11:47:42PM +0200, Robert Scheck wrote:
> > > >>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.
> >
> > https://gitlab.nic.cz/labs/bird/-/commit/f8bcb037b5b71a19209f1b63d52895c8c34c675b
> > let's the build succeed. As there is no MPLS support in CentOS/RHEL 7...do
> > you treat reverting this commit only for this build target as very risky or
> > problematic (without an in-depth analysis, just from your feeling)?
>
> Reverting this patch for CentOS is safe.
>
> --
> 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: Possibly a way to match Kernel.source field?

[Alexander Zubkov via Bird-users]

Hi,

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

Regards,
Alexander Zubkov

On Sat, Sep 30, 2023, 22:20 Nigel Kukard via Bird-users <
bird-users@network.cz> wrote:

> Hi there fellow BIRD users,
>
> Does anyone perhaps know if there is a way to match this field?
>
> I'm trying to create a filter to prevent these from being imported into my
> one table which I feed into OSPF6.
>
> I've tried, Kernel.source and kernel.source sadly with no luck. This item
> corresponds to the "ip route" protocol field.
>
> Kind Regards
> Nigel
>

Re: BGP best path algorithm in RR environment

[Alexander Zubkov via Bird-users]

Hello Dariusz,

On Wed, Sep 13, 2023 at 3:19 PM Mazur, Dariusz  wrote:
>
> Hello Aleksander,
> Prepends does not work for me because I would prepending on every leaf so 
> as-path still will be the same from perespective r01.leaf108

If you prepend announces from every leaf to the spine, then
r01.leaf108 in your example will see the announce from the spine with
one extra prepend and from its tor witout extra prepends. Or not?

> Looks like AIGP is not for me too because we don’t have IGP inside network. 
> Every iBGP session is established over directly connected p2p links.

Take a look at the description of the next option, following "aigp". I
don't think IGP dynamic routing is required to use aigp metric in BGP.
The question is if you can setup costs and metrics as you need. I
haven't used this feature myself, so I would not help with specific
configs. But it seems to me that it could be used with BGP sessions
only.

> cost number
> When BGP gateway mode is recursive (mainly multihop IBGP sessions), then the 
> distance to BGP next hop is based on underlying IGP metric. This option 
> specifies the distance to BGP next hop for BGP sessions in direct gateway 
> mode (mainly direct EBGP sessions).

>
> I was thinking to increase BGP preference (not bgp local pref) on leafs to 
> prefer routes from tor and not to compare them with the same routes from 
> spine (I don’t like this workaround)
>
>
> Thanks,
> Dariusz
>
> On 9/13/23, 2:17 PM, "Alexander Zubkov"  <mailto:gr...@qrator.net>> wrote:
>
>
> Hi Dariusz,
>
>
> Will ASPATH prepends work for you?
> Or this feature might help you:
> https://urldefense.com/v3/__https://bird.network.cz/?get_doc=20=bird-6.html
>  
> <https://urldefense.com/v3/__https://bird.network.cz/?get_docv=20f=bird-6.html>*bgp-aigp__;Iw!!GjvTz_vk!Xxvtj4yzVIakFfyFYALg5qiCWoJ-VfKsSyJy2aYMXvIoY5myyvsy41XQPC862yoN5iLL7GvrlmJ2$
>
>
> Regards,
> Alexander Zubkov
> Qrator Labs
>
>
> On Wed, Sep 13, 2023 at 11:43 AM Mazur, Dariusz via Bird-users
> mailto:bird-users@network.cz>> wrote:
> >
> > Hello Bird Users,
> >
> > Have a question about bgp best path algorithm in Route Refletector 
> > environment and possible fix:
> >
> >
> >
> >
> >
> > Topology ( we use only iBGP with multiply RR):
> >
> > r01a.tor - r01.leaf.105---r01.spiner01.leaf108-r09a.tor
> >
> >
> >
> > I announce the same block 172.232.0.0/19 from both tors
> >
> >
> >
> > r01.leaf108 receives 172.232.0.0/19 from r01.spine and r09a.tor, and treat 
> > them as equal path (multipath).
> >
> >
> >
> > All BGP attributes are equal except of BGP originator id and cluster-list
> >
> >
> >
> > r01.leaf108.ord02.fab> show route for 172.232.0.0/19 all
> >
> > 172.232.0.0/19
> >
> > unicast [192.168.226.56__r01.spine101 2023-09-06] * (100) [AS4250527481?]
> >
> > via 192.168.226.56 on vlan.101
> >
> > Type: BGP univ
> >
> > BGP.origin: Incomplete
> >
> > BGP.as_path: 4250527481
> >
> > BGP.next_hop: 192.168.226.56
> >
> > BGP.med: 0
> >
> > BGP.local_pref: 400
> >
> > BGP.atomic_aggr:
> >
> > BGP.aggregator: 23.192.121.225 AS4250527481
> >
> > BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) 
> > (65110,31107) (65310,31107) (65518,31107)
> >
> > BGP.originator_id: 23.205.212.134
> >
> > BGP.cluster_list: 23.205.212.8 23.205.212.112
> >
> >
> >
> > unicast [192.168.198.35__r09b.tor108 2023-09-06] (100) [AS4250827489?]
> >
> > via 192.168.198.35 on vlan.218
> >
> > Type: BGP univ
> >
> > BGP.origin: Incomplete
> >
> > BGP.as_path: 4250827489
> >
> > BGP.next_hop: 192.168.198.35
> >
> > BGP.med: 0
> >
> > BGP.local_pref: 400
> >
> > BGP.atomic_aggr:
> >
> > BGP.aggregator: 23.213.15.233 AS4250827489
> >
> > BGP.community: (63949,1000) (63949,1002) (63949,1004) (63949,1005) 
> > (65110,31107) (65310,31107) (65518,31107)
> >
> >
> >
> > Looks like Bird does not check cluster_list length to determine better 
> > route, is it intentional? Can you suggest any possible fix to prefer route 
> > from r09a.tor using cluster-list or anything what is local for router 
> > (local pref is not option because all routers are in the same asn and use 
> > iBGP)
> >
> > Thanks,
> >
> > Dariusz
> >
> >
> >
> >
> >
> >
>
>
>

Re: BGP best path algorithm in RR environment

[Alexander Zubkov via Bird-users]

Hi Dariusz,

Will ASPATH prepends work for you?
Or this feature might help you:
https://bird.network.cz/?get_doc=20=bird-6.html#bgp-aigp

Regards,
Alexander Zubkov
Qrator Labs

On Wed, Sep 13, 2023 at 11:43 AM Mazur, Dariusz via Bird-users
 wrote:
>
> Hello Bird Users,
>
> Have a question about bgp best path algorithm  in Route Refletector  
> environment and possible fix:
>
>
>
>
>
> Topology ( we use only iBGP with multiply RR):
>
> r01a.tor - r01.leaf.105---r01.spiner01.leaf108-r09a.tor
>
>
>
> I announce the same block 172.232.0.0/19 from both tors
>
>
>
> r01.leaf108 receives 172.232.0.0/19 from r01.spine and r09a.tor, and treat 
> them as equal path (multipath).
>
>
>
> All BGP attributes are equal except of  BGP originator id and cluster-list
>
>
>
> r01.leaf108.ord02.fab> show route for 172.232.0.0/19 all
>
> 172.232.0.0/19
>
> unicast [192.168.226.56__r01.spine101 
> 2023-09-06] * (100) [AS4250527481?]
>
> via 192.168.226.56 on vlan.101
>
> Type: BGP univ
>
> BGP.origin: Incomplete
>
> BGP.as_path: 4250527481
>
> BGP.next_hop: 192.168.226.56
>
> BGP.med: 0
>
> BGP.local_pref: 400
>
> BGP.atomic_aggr:
>
> BGP.aggregator: 23.192.121.225 AS4250527481
>
> BGP.community: (63949,1000) (63949,1002) (63949,1004) 
> (63949,1005) (65110,31107) (65310,31107) (65518,31107)
>
> BGP.originator_id: 23.205.212.134
>
> BGP.cluster_list: 23.205.212.8 23.205.212.112
>
>
>
>  unicast [192.168.198.35__r09b.tor108 2023-09-06] (100) 
> [AS4250827489?]
>
> via 192.168.198.35 on vlan.218
>
> Type: BGP univ
>
> BGP.origin: Incomplete
>
> BGP.as_path: 4250827489
>
> BGP.next_hop: 192.168.198.35
>
> BGP.med: 0
>
> BGP.local_pref: 400
>
> BGP.atomic_aggr:
>
> BGP.aggregator: 23.213.15.233 AS4250827489
>
> BGP.community: (63949,1000) (63949,1002) (63949,1004) 
> (63949,1005) (65110,31107) (65310,31107) (65518,31107)
>
>
>
> Looks like Bird does not check  cluster_list length to determine better 
> route, is it intentional? Can you suggest any possible fix to prefer route 
> from r09a.tor using cluster-list or anything what is local for router (local 
> pref is not option because all routers are in the same asn and use iBGP)
>
> Thanks,
>
> Dariusz
>
>
>
>
>
>

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

[Alexander Zubkov via Bird-users]

And I forgot to ask about kw_sym. "kw_sym: FROM_HEX" definition is not
needed? To provide fallback for someone using such name in config
already.

On Fri, Aug 25, 2023 at 3:55 AM Alexander Zubkov  wrote:
>
> Hi,
>
> Good news, thanks!
>
> On Thu, Aug 24, 2023 at 7:11 PM Ondrej Zajicek  wrote:
> >
> > On Thu, Jul 27, 2023 at 03:38:27PM +0200, Alexander Zubkov wrote:
> > > Hi,
> > >
> > > Have you had a chance to look at all this?
> >
> > Hi
> >
> > Sorry for keeping you wait, i finally got to this patchset and merged it.
>
> No problem, several days more and I would call it a birthday present. :)
>
> > I did some changes:
> >
> > 1) Removal of support for multiline string literals - the patch is simple
> > but it has an awkward consequence of making incomprehensible error messages
> > for unterminated strings. We discussed that and decided to drop it.
>
> OK. The idea was it could be possible, to insert long hexdumps as-is
> or base64 outputs. So it seemed multiline strings is a good idea. But
> yes, missing quote could lead to some fancy parsing. I also noticed I
> missed "ifs->lino++; ..." there.
>
> >
> > 2) Refactor of bstrhextobin() and bstrbintohex() to be more generic and
> > not depend bstrtobyte16(), which was removed. I never liked it anyway.
> > Also, there is an explicit string of allowed delimiters in bstrhextobin(),
> > for from_hex(), instead of ignoring everything that is not a letter.
>
> OK. I also wanted to give a more freedom here to fomatting the source
> string, because who knows what delimeters one would like to use, not
> counting various types of spaces - '\t', '\n', etc. For example
> current allowed delimeter set does not contain '.', which is used at
> least for Cisco's MAC address notation: "0011.2233.4455". Also one
> might want use various brackets to make his blob more human-readable.
> But sure it can be started with a stricter variant and expanded later
> if there is actual demand for it.
>
> >
> > 3) Change val_format() to not add 'hex:' prefix when printing bytestring.
> > It offers human readable, but not necessary back-parsable form (i.e more
> > like Scheme function 'display' than 'write'). That is consistent with its
> > behavior for strings, where quotation marks are also not added.
> >
> > 4) Use different approach for bytestring or string argument for password
> > keys, so the target expression can know which variant was used.
> >
> > For other details, see the commits.
> >
> > Thanks for the patchset. I especially like the cf_eval() / cf_eval_int()
> > changes.
>
> Thanks for reviewing and merging!
>
> >
> > --
> > 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

Hi,

Good news, thanks!

On Thu, Aug 24, 2023 at 7:11 PM Ondrej Zajicek  wrote:
>
> On Thu, Jul 27, 2023 at 03:38:27PM +0200, Alexander Zubkov wrote:
> > Hi,
> >
> > Have you had a chance to look at all this?
>
> Hi
>
> Sorry for keeping you wait, i finally got to this patchset and merged it.

No problem, several days more and I would call it a birthday present. :)

> I did some changes:
>
> 1) Removal of support for multiline string literals - the patch is simple
> but it has an awkward consequence of making incomprehensible error messages
> for unterminated strings. We discussed that and decided to drop it.

OK. The idea was it could be possible, to insert long hexdumps as-is
or base64 outputs. So it seemed multiline strings is a good idea. But
yes, missing quote could lead to some fancy parsing. I also noticed I
missed "ifs->lino++; ..." there.

>
> 2) Refactor of bstrhextobin() and bstrbintohex() to be more generic and
> not depend bstrtobyte16(), which was removed. I never liked it anyway.
> Also, there is an explicit string of allowed delimiters in bstrhextobin(),
> for from_hex(), instead of ignoring everything that is not a letter.

OK. I also wanted to give a more freedom here to fomatting the source
string, because who knows what delimeters one would like to use, not
counting various types of spaces - '\t', '\n', etc. For example
current allowed delimeter set does not contain '.', which is used at
least for Cisco's MAC address notation: "0011.2233.4455". Also one
might want use various brackets to make his blob more human-readable.
But sure it can be started with a stricter variant and expanded later
if there is actual demand for it.

>
> 3) Change val_format() to not add 'hex:' prefix when printing bytestring.
> It offers human readable, but not necessary back-parsable form (i.e more
> like Scheme function 'display' than 'write'). That is consistent with its
> behavior for strings, where quotation marks are also not added.
>
> 4) Use different approach for bytestring or string argument for password
> keys, so the target expression can know which variant was used.
>
> For other details, see the commits.
>
> Thanks for the patchset. I especially like the cf_eval() / cf_eval_int()
> changes.

Thanks for reviewing and merging!

>
> --
> 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: Remove all except one community

[Alexander Zubkov via Bird-users]

Hi,

That is exactly what "filter" function does. Something like this:
bgp_community.filter([(64511,*)]);


On Wed, Jul 19, 2023, 17:15 Marek Küthe  wrote:

> Hello,
>
> I recently discovered a new filter for myself on
> https://bgpfilterguide.nlnog.net/guides/many_communities/#bird. In my
> eyes it also makes sense to keep the routing table as small as
> possible. But now I don't want to delete all communities, but keep a
> single one. How can I implement something like that?
> ```
> function strip_too_many_communities() {
> if ( ( bgp_community.len + bgp_ext_community.len +
> bgp_large_community.len ) >= 100 ) then {
> bgp_community.empty.except((64511, *));
> bgp_ext_community.empty;
> bgp_large_community.empty;
> }
> }
> ```
>
> The background is that these serve in the
> [dn42](https://dn42.dev/howto/Bird-communities) as information, how
> good the connection to the destination is. Therefore I would like to
> keep these.
> Does anyone have any ideas on how to do something like this?
>
> Greetings
> Marek Küthe
>
> --
> Marek Küthe
> m...@mk16.de
> er/ihm he/him
>

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

[Alexander Zubkov via Bird-users]

Hi,

And the final patch for the bytestring documentation. Also slightly
modified radv documentation patch - added a semicolon in the end of
the example.
I actually would prefer the "binary" name for the type more than
"bytestring". Or maybe you have something else on your mind. So if you
would also like not to name it "bytestring", I can alter the pathes
for it.

On Fri, Jun 30, 2023 at 1:21 AM Alexander Zubkov  wrote:
>
> Patch for RAdv documentation for a new custom option.
>
> I was also thinking about the new bytestring type. I needed tho change
> BYTESTRING -> BYTETEXT to avoid collision. But probably the better
> variant would be to name the new type for example "binary", it might
> sound better. What do you think? As far as I see, the name
> "bytestring" has not been used yet outside of the code.
>
> Also found a small issue with my patches in "conf/confbase.Y" when
> compiling with relatively old gcc. It complains on the value
> definitions inside the switch statement:
>
>case T_STRING:
>  int len = strlen(val.val.s);
>  struct bytestring *bs = cfg_allocz(sizeof(*bs) + len);
>
> I can prepare a new set of patches or you can fix it ad-hoc.
>
> On Thu, Jun 29, 2023 at 1:59 PM Alexander Zubkov  wrote:
> >
> > On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov  wrote:
> > >
> > > On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov  wrote:
> > > >
> > > > On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek  
> > > > wrote:
> > > > >
> > > > > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > > > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > > > > Yes, the original idea there was to add bytestring as a data 
> > > > > > > > > type, make
> > > > > > > > > hex() a regular (filter) function instead of special 
> > > > > > > > > function-like
> > > > > > > > > syntax, and add equivalent of 'expr' grammar term for other 
> > > > > > > > > data types.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I see. I think I can look into preparing a patch for that too.
> > > > > > > > But for such variant I would suggest using function names like
> > > > > > > > "from_hex/base64" instead of "hex/base64", or something 
> > > > > > > > including
> > > > > > > > bytestring reference: "bs_hex". Because the simple variants 
> > > > > > > > could be
> > > > > > > > misleading when used not only in the limited set of scopes.
> > > > > > > > they can be thought of converting to hex/base64 representation 
> > > > > > > > too. Or they
> > > > > > > > could collide with "hex" function to convert from string to 
> > > > > > > > int, which
> > > > > > > > someone would need to implement in the future.
> > > > > > >
> > > > > > > Yes, that is true.
> > > > > > >
> > > > > > > You can try it if you are brave enough to add new f_val type.
> > > > > >
> > > > > > Take a look at the patch, please. Waiting for the critics and
> > > > > > improvement suggestions.
> > > > >
> > > > > Hi
> > > > >
> > > > > It looks pretty good. First, could you split it to at least four 
> > > > > patches?
> > > >
> > > > Sure. I'll provide split patches later.
> > > >
> > > > >
> > > > > 1) unrelated changes, like the newline-in-string-constant
> > > > > 2) preparatory changes (functions in lib/bytestring.c, change to 
> > > > > BYTESTRING lexer)
> > > > > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
> > >
> > > Added patches up to this point. There are also some fixes and
> > > modification. For example, I noted that 'bytestring' symbol for the
> > > type name conflicts with lexer's BYTESTRING id. So I had to rename
> > > lexer's BYTESTRING to BYTETEXT (like it is done for st

typo in the documentation

[Alexander Zubkov via Bird-users]

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
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 81568b95..577f9535 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -5389,8 +5389,8 @@ as the destination becomes adjacent again.
 (i.e., they can be used multiple times for a route, one time for each nexthop).
 Syntactically, they are not separate options but just parts of route 10.0.0.0/8 via 192.0.2.1 bfd weight 1 via 192.0.2.2 weight
+2; describes a route with two nexthops, the first nexthop has two per-nexthop
 options (

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

[Alexander Zubkov via Bird-users]

Patch for RAdv documentation for a new custom option.

I was also thinking about the new bytestring type. I needed tho change
BYTESTRING -> BYTETEXT to avoid collision. But probably the better
variant would be to name the new type for example "binary", it might
sound better. What do you think? As far as I see, the name
"bytestring" has not been used yet outside of the code.

Also found a small issue with my patches in "conf/confbase.Y" when
compiling with relatively old gcc. It complains on the value
definitions inside the switch statement:

   case T_STRING:
 int len = strlen(val.val.s);
 struct bytestring *bs = cfg_allocz(sizeof(*bs) + len);

I can prepare a new set of patches or you can fix it ad-hoc.

On Thu, Jun 29, 2023 at 1:59 PM Alexander Zubkov  wrote:
>
> On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov  wrote:
> >
> > On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov  wrote:
> > >
> > > On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek  
> > > wrote:
> > > >
> > > > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek 
> > > > >  wrote:
> > > > > >
> > > > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > > > Yes, the original idea there was to add bytestring as a data 
> > > > > > > > type, make
> > > > > > > > hex() a regular (filter) function instead of special 
> > > > > > > > function-like
> > > > > > > > syntax, and add equivalent of 'expr' grammar term for other 
> > > > > > > > data types.
> > > > > > > >
> > > > > > >
> > > > > > > I see. I think I can look into preparing a patch for that too.
> > > > > > > But for such variant I would suggest using function names like
> > > > > > > "from_hex/base64" instead of "hex/base64", or something including
> > > > > > > bytestring reference: "bs_hex". Because the simple variants could 
> > > > > > > be
> > > > > > > misleading when used not only in the limited set of scopes.
> > > > > > > they can be thought of converting to hex/base64 representation 
> > > > > > > too. Or they
> > > > > > > could collide with "hex" function to convert from string to int, 
> > > > > > > which
> > > > > > > someone would need to implement in the future.
> > > > > >
> > > > > > Yes, that is true.
> > > > > >
> > > > > > You can try it if you are brave enough to add new f_val type.
> > > > >
> > > > > Take a look at the patch, please. Waiting for the critics and
> > > > > improvement suggestions.
> > > >
> > > > Hi
> > > >
> > > > It looks pretty good. First, could you split it to at least four 
> > > > patches?
> > >
> > > Sure. I'll provide split patches later.
> > >
> > > >
> > > > 1) unrelated changes, like the newline-in-string-constant
> > > > 2) preparatory changes (functions in lib/bytestring.c, change to 
> > > > BYTESTRING lexer)
> > > > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
> >
> > Added patches up to this point. There are also some fixes and
> > modification. For example, I noted that 'bytestring' symbol for the
> > type name conflicts with lexer's BYTESTRING id. So I had to rename
> > lexer's BYTESTRING to BYTETEXT (like it is done for strings).
> > For the following patches it is better to decide the structure of the
> > new *eval* functions.
> >
> > > > 4) change to parser related to f_eval_val(), bytestring nonterminal and 
> > > > so on.
>
> Final patches to modify current f_eval_int() to generic approach. And
> for nonterminal bytestring.
> Again, waiting for comments/suggestions. Also feel free, of course, to
> fix naming/etc when applying.
> Next, I will be able to move forward with patches to the documentation.
>
> > > >
> > > > Some more comments:
> > > >
> > > > > It was needed to add another function like f_eval_int(), so I decided
> > > > > to do some more generic approach and replaced all occurences of
> > > > > f_eval_int() with it.
> > &

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

[Alexander Zubkov via Bird-users]

On Tue, Jun 27, 2023 at 2:13 AM Alexander Zubkov  wrote:
>
> On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov  wrote:
> >
> > On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek  
> > wrote:
> > >
> > > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek  
> > > > wrote:
> > > > >
> > > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > > Yes, the original idea there was to add bytestring as a data 
> > > > > > > type, make
> > > > > > > hex() a regular (filter) function instead of special function-like
> > > > > > > syntax, and add equivalent of 'expr' grammar term for other data 
> > > > > > > types.
> > > > > > >
> > > > > >
> > > > > > I see. I think I can look into preparing a patch for that too.
> > > > > > But for such variant I would suggest using function names like
> > > > > > "from_hex/base64" instead of "hex/base64", or something including
> > > > > > bytestring reference: "bs_hex". Because the simple variants could be
> > > > > > misleading when used not only in the limited set of scopes.
> > > > > > they can be thought of converting to hex/base64 representation too. 
> > > > > > Or they
> > > > > > could collide with "hex" function to convert from string to int, 
> > > > > > which
> > > > > > someone would need to implement in the future.
> > > > >
> > > > > Yes, that is true.
> > > > >
> > > > > You can try it if you are brave enough to add new f_val type.
> > > >
> > > > Take a look at the patch, please. Waiting for the critics and
> > > > improvement suggestions.
> > >
> > > Hi
> > >
> > > It looks pretty good. First, could you split it to at least four patches?
> >
> > Sure. I'll provide split patches later.
> >
> > >
> > > 1) unrelated changes, like the newline-in-string-constant
> > > 2) preparatory changes (functions in lib/bytestring.c, change to 
> > > BYTESTRING lexer)
> > > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
>
> Added patches up to this point. There are also some fixes and
> modification. For example, I noted that 'bytestring' symbol for the
> type name conflicts with lexer's BYTESTRING id. So I had to rename
> lexer's BYTESTRING to BYTETEXT (like it is done for strings).
> For the following patches it is better to decide the structure of the
> new *eval* functions.
>
> > > 4) change to parser related to f_eval_val(), bytestring nonterminal and 
> > > so on.

Final patches to modify current f_eval_int() to generic approach. And
for nonterminal bytestring.
Again, waiting for comments/suggestions. Also feel free, of course, to
fix naming/etc when applying.
Next, I will be able to move forward with patches to the documentation.

> > >
> > > Some more comments:
> > >
> > > > It was needed to add another function like f_eval_int(), so I decided
> > > > to do some more generic approach and replaced all occurences of
> > > > f_eval_int() with it.
> > >
> > > That is good approach, although it would be probably better to call this
> > > function like cf_eval(), associated macro as cf_eval_val, and keep some
> > > inline functions like cf_eval_int(), cf_eval_bs() and so on.
> > >
> > > Or perhaps cf_eval() could return f_val as return value, and have
> > > shorthand functions like:
> > >
> > > static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }
>
> I actually tried first to return the struct instead of modifying it by
> a reference. But for that we need to have "struct f_val" known in
> filter/filter.h, which is defined in filter/data.h. But that causes
> some circular dependencies problem. I didn't dig deep into it, but
> maybe it is possible to solve the conflict in a clean way.

Looked at it again. It seems safe to include filter/data.h into
filter/filter.h. I probably had problems when trying to incude it
somewhere else, until it all finalized into filter.h

>
> > >
> > > I will give more comments later.
> > >
> > > --
> > > Elen sila lumenn' omentielvo
> > >
> > > Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)

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

[Alexander Zubkov via Bird-users]

Also try to enable debugging. It might log something about why it
cannot resolve the recursive route.

On Tue, Jun 27, 2023 at 4:48 PM Alexander Zubkov  wrote:
>
> Hi,
>
> 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.
> 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.
>
> On Tue, Jun 27, 2023 at 4:22 PM Daniel Gröber  wrote:
> >
> > Hi,
> >
> > I'm trying to configure a static route that uses the system's default
> > router. The default router is out of my control and is announced via IPv6
> > RA. Since the MAC might not be stable I'd prefer not to hardcode the
> > router's link-local address. So I tried:
> >
> > protocol static static_export_kernel2 {
> > ipv6;
> > igp table master6;
> > route 2001:db8::/48 recursive ::;
> > }
> >
> > The thinking being that :: ought to be resolvable through the default route
> > imported from proto kernel:
> >
> > birdc show route for :: all
> > Table master6:
> > ::/0 unicast [kernel1 2023-03-22] * (10)
> > via fe80::fc00:3ff:fec7:cd05 on enp1s0
> > Type: inherit univ
> > Kernel.source: 9
> > Kernel.metric: 1024
> > Kernel.hoplimit: 64
> >
> > However the static route ends up being "unreachable":
> >
> > 2a0d:f302:114::/48   unreachable [static_export_kernel2 13:59:32.819] * 
> > (200)
> > Type: static univ
> >
> > Any ideas why this isn't working?
> >
> > Thanks,
> > --Daniel
> >
> > PS: The reason I have to create this static route when it's already covered
> > by the default route has to do with an esoteric policy routing setup and
> > multiple routing daemons ask for details at your own peril :)

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

[Alexander Zubkov via Bird-users]

Hi,

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

On Tue, Jun 27, 2023 at 4:22 PM Daniel Gröber  wrote:
>
> Hi,
>
> I'm trying to configure a static route that uses the system's default
> router. The default router is out of my control and is announced via IPv6
> RA. Since the MAC might not be stable I'd prefer not to hardcode the
> router's link-local address. So I tried:
>
> protocol static static_export_kernel2 {
> ipv6;
> igp table master6;
> route 2001:db8::/48 recursive ::;
> }
>
> The thinking being that :: ought to be resolvable through the default route
> imported from proto kernel:
>
> birdc show route for :: all
> Table master6:
> ::/0 unicast [kernel1 2023-03-22] * (10)
> via fe80::fc00:3ff:fec7:cd05 on enp1s0
> Type: inherit univ
> Kernel.source: 9
> Kernel.metric: 1024
> Kernel.hoplimit: 64
>
> However the static route ends up being "unreachable":
>
> 2a0d:f302:114::/48   unreachable [static_export_kernel2 13:59:32.819] * 
> (200)
> Type: static univ
>
> Any ideas why this isn't working?
>
> Thanks,
> --Daniel
>
> PS: The reason I have to create this static route when it's already covered
> by the default route has to do with an esoteric policy routing setup and
> multiple routing daemons ask for details at your own peril :)

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

[Alexander Zubkov via Bird-users]

On Mon, Jun 26, 2023 at 5:54 PM Alexander Zubkov  wrote:
>
> On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek  wrote:
> >
> > On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek  
> > > wrote:
> > > >
> > > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > > Yes, the original idea there was to add bytestring as a data type, 
> > > > > > make
> > > > > > hex() a regular (filter) function instead of special function-like
> > > > > > syntax, and add equivalent of 'expr' grammar term for other data 
> > > > > > types.
> > > > > >
> > > > >
> > > > > I see. I think I can look into preparing a patch for that too.
> > > > > But for such variant I would suggest using function names like
> > > > > "from_hex/base64" instead of "hex/base64", or something including
> > > > > bytestring reference: "bs_hex". Because the simple variants could be
> > > > > misleading when used not only in the limited set of scopes.
> > > > > they can be thought of converting to hex/base64 representation too. 
> > > > > Or they
> > > > > could collide with "hex" function to convert from string to int, which
> > > > > someone would need to implement in the future.
> > > >
> > > > Yes, that is true.
> > > >
> > > > You can try it if you are brave enough to add new f_val type.
> > >
> > > Take a look at the patch, please. Waiting for the critics and
> > > improvement suggestions.
> >
> > Hi
> >
> > It looks pretty good. First, could you split it to at least four patches?
>
> Sure. I'll provide split patches later.
>
> >
> > 1) unrelated changes, like the newline-in-string-constant
> > 2) preparatory changes (functions in lib/bytestring.c, change to BYTESTRING 
> > lexer)
> > 3) adding bytestring type to filter code (including FI_FROM_HEX inst)

Added patches up to this point. There are also some fixes and
modification. For example, I noted that 'bytestring' symbol for the
type name conflicts with lexer's BYTESTRING id. So I had to rename
lexer's BYTESTRING to BYTETEXT (like it is done for strings).
For the following patches it is better to decide the structure of the
new *eval* functions.

> > 4) change to parser related to f_eval_val(), bytestring nonterminal and so 
> > on.
> >
> > Some more comments:
> >
> > > It was needed to add another function like f_eval_int(), so I decided
> > > to do some more generic approach and replaced all occurences of
> > > f_eval_int() with it.
> >
> > That is good approach, although it would be probably better to call this
> > function like cf_eval(), associated macro as cf_eval_val, and keep some
> > inline functions like cf_eval_int(), cf_eval_bs() and so on.
> >
> > Or perhaps cf_eval() could return f_val as return value, and have
> > shorthand functions like:
> >
> > static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }

I actually tried first to return the struct instead of modifying it by
a reference. But for that we need to have "struct f_val" known in
filter/filter.h, which is defined in filter/data.h. But that causes
some circular dependencies problem. I didn't dig deep into it, but
maybe it is possible to solve the conflict in a clean way.

> >
> > I will give more comments later.
> >
> > --
> > 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."
From 41542bbffebe351b1df96210849a1a22b3c74474 Mon Sep 17 00:00:00 2001
From: Alexander Zubkov 
Date: Tue, 27 Jun 2023 00:53:05 +0200
Subject: [PATCH] Use more proper pointers to constant bytestrings

---
 conf/confbase.Y | 2 +-
 proto/radv/config.Y | 2 +-
 proto/radv/radv.h   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/conf/confbase.Y b/conf/confbase.Y
index 3e8f5807..3dd5fed7 100644
--- a/conf/confbase.Y
+++ b/conf/confbase.Y
@@ -94,7 +94,7 @@ CF_DECLS
   struct channel_limit cl;
   struct timeformat *tf;
   mpls_label_stack *mls;
-  struct bytestring *bs;
+  const struct bytestring *bs;
 }
 
 %token END CLI_MARKER INVALID_TOKEN ELSECOL DDOT
diff --git a/proto/radv/config.Y b/proto/radv/config.Y
index db683194..eeafe6f4 100644
--- a/proto/radv/config.Y
+++ b/proto/radv/c

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

[Alexander Zubkov via Bird-users]

On Mon, Jun 26, 2023 at 5:43 PM Ondrej Zajicek  wrote:
>
> On Mon, Jun 26, 2023 at 03:24:47AM +0200, Alexander Zubkov wrote:
> > On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek  
> > wrote:
> > >
> > > On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > > > Yes, the original idea there was to add bytestring as a data type, 
> > > > > make
> > > > > hex() a regular (filter) function instead of special function-like
> > > > > syntax, and add equivalent of 'expr' grammar term for other data 
> > > > > types.
> > > > >
> > > >
> > > > I see. I think I can look into preparing a patch for that too.
> > > > But for such variant I would suggest using function names like
> > > > "from_hex/base64" instead of "hex/base64", or something including
> > > > bytestring reference: "bs_hex". Because the simple variants could be
> > > > misleading when used not only in the limited set of scopes.
> > > > they can be thought of converting to hex/base64 representation too. Or 
> > > > they
> > > > could collide with "hex" function to convert from string to int, which
> > > > someone would need to implement in the future.
> > >
> > > Yes, that is true.
> > >
> > > You can try it if you are brave enough to add new f_val type.
> >
> > Take a look at the patch, please. Waiting for the critics and
> > improvement suggestions.
>
> Hi
>
> It looks pretty good. First, could you split it to at least four patches?

Sure. I'll provide split patches later.

>
> 1) unrelated changes, like the newline-in-string-constant
> 2) preparatory changes (functions in lib/bytestring.c, change to BYTESTRING 
> lexer)
> 3) adding bytestring type to filter code (including FI_FROM_HEX inst)
> 4) change to parser related to f_eval_val(), bytestring nonterminal and so on.
>
> Some more comments:
>
> > It was needed to add another function like f_eval_int(), so I decided
> > to do some more generic approach and replaced all occurences of
> > f_eval_int() with it.
>
> That is good approach, although it would be probably better to call this
> function like cf_eval(), associated macro as cf_eval_val, and keep some
> inline functions like cf_eval_int(), cf_eval_bs() and so on.
>
> Or perhaps cf_eval() could return f_val as return value, and have
> shorthand functions like:
>
> static inline cf_eval_int(..) { return cf_eval(.., T_INT).i; }
>
> I will give more comments later.
>
> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

On Sat, Jun 24, 2023 at 3:16 PM Ondrej Zajicek  wrote:
>
> On Sat, Jun 24, 2023 at 02:20:03AM +0200, Alexander Zubkov wrote:
> > > Yes, the original idea there was to add bytestring as a data type, make
> > > hex() a regular (filter) function instead of special function-like
> > > syntax, and add equivalent of 'expr' grammar term for other data types.
> > >
> >
> > I see. I think I can look into preparing a patch for that too.
> > But for such variant I would suggest using function names like
> > "from_hex/base64" instead of "hex/base64", or something including
> > bytestring reference: "bs_hex". Because the simple variants could be
> > misleading when used not only in the limited set of scopes.
> > they can be thought of converting to hex/base64 representation too. Or they
> > could collide with "hex" function to convert from string to int, which
> > someone would need to implement in the future.
>
> Yes, that is true.
>
> You can try it if you are brave enough to add new f_val type.

Take a look at the patch, please. Waiting for the critics and
improvement suggestions.

Some remarks:
It was needed to add another function like f_eval_int(), so I decided
to do some more generic approach and replaced all occurences of
f_eval_int() with it.
Bytestrings for password caused conflicts with strings on being
presented as symbol names. Insted of adding something like
"string_or_bytestring", I decided to allow bytestring term to be
derived from strings too.
I also used different approach from "expr", where it evaluates only
complex expressions. I decided that handling constants and symbols via
evalutation would be easier. So I have special case only for literals.
There is separate "term_bs" term, so that it is possible to use
"from_hex()" without outer brackets.
Again, added a new file in lib dir for bytestrings.
And I changed some struct bytestring pointers to const struct bytestring.

>
>
> > > > I think this should be quite good too, the only problem with it
> > > > is inability to mix "hex" symbol with hex("...") bytestrings.
> > >
> > > This is an issue with any keyword, so not a big thing.
> > >
> >
> > Yes. By the way what do you think about the patch that allows using
> > keywords and symbols together? Is it viable?
>
> Answered there.
>
>
> --
> 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."
commit 7cc6700c64e94019df1743de685c84dbca85b406
Author: Alexander Zubkov 
Date:   Mon Jun 26 02:38:54 2023 +0200

Conf: make bytestring a type

diff --git a/bird-gdb.py b/bird-gdb.py
index 3cf65a9c..262035dc 100644
--- a/bird-gdb.py
+++ b/bird-gdb.py
@@ -34,6 +34,7 @@ class BIRDFValPrinter(BIRDPrinter):
 "T_IP": "ip",
 "T_NET": "net",
 "T_STRING": "s",
+"T_BYTESTRING": "bs",
 "T_PATH_MASK": "path_mask",
 "T_PATH": "ad",
 "T_CLIST": "ad",
diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index 9025a84d..59b88bd5 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -256,37 +256,26 @@ WHITE [ \t]
 }
 
 ({XIGIT}{2}){16,}|{XIGIT}{2}(:{XIGIT}{2}){15,}|hex:({XIGIT}{2}(:?{XIGIT}{2})*)? {
-  char *s, *sb = yytext;
-  size_t len = 0, i;
+  char *sb = yytext;
+  size_t len = 0;
   struct bytestring *bytes;
-  byte *b;
 
   /* skip 'hex:' prefix */
   if (sb[0] == 'h' && sb[1] == 'e' && sb[2] == 'x' && sb[3] == ':')
 sb += 4;
 
-  s = sb;
-  while (*s) {
-len++;
-s += 2;
-if (*s == ':')
-  s++;
-  }
+  errno = 0;
+  len = bstrhextobin(sb, 0);
+  if (errno || len == (size_t)-1)
+cf_error("Invalid hex string");
+
   bytes = cfg_allocz(sizeof(*bytes) + len);
 
   bytes->length = len;
-  b = >data[0];
-  s = sb;
-  errno = 0;
-  for (i = 0; i < len; i++) {
-*b = bstrtobyte16(s);
-if (errno == ERANGE)
-  cf_error("Invalid hex string");
-b++;
-s += 2;
-if (*s == ':')
-  s++;
-  }
+  bstrhextobin(sb, bytes->data);
+  if (errno)
+cf_error("Invalid hex string");
+
   cf_lval.bs = bytes;
   return BYTESTRING;
 }
@@ -361,7 +350,6 @@ else: {
   quoted_buffer_init();
 }
 
-\n	cf_error("Unterminated string");
 <> cf_error("Unterminated string");
 ["]	{
   BEGIN(INITIAL);
@@ -370,7 +358,7 @@ else: {
   return TEXT;
 }
 
-.	BUFFER_PUSH(quoted_buffer) = yytext[0];
+(.|\n)	BUFFER_PUSH(

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

[Alexander Zubkov via Bird-users]

Hello!

On Sat, Jun 24, 2023 at 3:30 PM Maria Matejka  wrote:
>
> 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.

Yes, I see. There are two languages with different structure (config
and filter) in the same grammar. And that requires some tradeoffs to
be made, at least with its current parsing approach.

>
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

Attached the patch with the new syntax for custom options and to use WALK_LIST.

On Sat, Jun 24, 2023 at 3:32 PM Ondrej Zajicek  wrote:
>
> On Sat, Jun 24, 2023 at 02:03:08AM +0200, Alexander Zubkov wrote:
> > On Fri, Jun 23, 2023, 17:47 Ondrej Zajicek  wrote:
> > > The only objection from me is that 'other type' option name is kind of
> > > non-descriptive, does not indicate it is related to RA options (nor it is
> > > implicated by context). I do not really have a good idea for alternative,
> > > perhaps just 'custom option'? What do you think?
> > >
> >
> > Yes, I was thinking about "custom" too. But it introduces a new keyword. So
> > I tried too choose something suitable from available keywords. But if it is
> > not a problem, I would prefer "custom" too as more descriptive.
>
> I think 'custom option' would be ok. It has two arguments, thinking about
> it, BIRD style would be more like:
>
>   custom option type 10 value 12:34:56:78:12:34:56:78:12:34:56:78:12:34:56:78;
>
> instead of just:
>
>   custom option 10 12:34:56:78:12:34:56:78:12:34:56:78:12:34:56:78;
>
>
> > > Could you prepare a patch for documentation?
> > >
> >
> > Sure, just will wait for the final decision about the syntax ("other" vs
> > "custom").
>
> okay.
>
>
> > > BTW, why not to use WALK_LIST() in radv_prepare_custom()?
> > > (just noticed in now)
> > >
> >
> > That is a good question. Actually I just used the structure of the similar
> > function for the predefined option and didn't thought much about it. Now
> > that you pointed that out, I remember that macro from the other parts of
> > the code. And it seems reasonable to use it here, and probably in the
> > "source" function too. I can prepare a patch for that.
>
> Okay. I see the 'source' funcions has more complex structure (two nested
> whiles), so perhaps it does not fit to them.
>
>
> --
> 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."
diff --git a/proto/radv/config.Y b/proto/radv/config.Y
index 5c213d50..81dc415a 100644
--- a/proto/radv/config.Y
+++ b/proto/radv/config.Y
@@ -42,7 +42,7 @@ CF_KEYWORDS(RADV, PREFIX, INTERFACE, MIN, MAX, RA, DELAY, INTERVAL, SOLICITED,
 	RETRANS, TIMER, CURRENT, HOP, LIMIT, DEFAULT, VALID, PREFERRED, MULT,
 	LIFETIME, SKIP, ONLINK, AUTONOMOUS, RDNSS, DNSSL, NS, DOMAIN, LOCAL,
 	TRIGGER, SENSITIVE, PREFERENCE, LOW, MEDIUM, HIGH, PROPAGATE, ROUTE,
-	ROUTES, RA_PREFERENCE, RA_LIFETIME)
+	ROUTES, RA_PREFERENCE, RA_LIFETIME, CUSTOM, OPTION, VALUE)
 
 CF_ENUM(T_ENUM_RA_PREFERENCE, RA_PREF_, LOW, MEDIUM, HIGH)
 
@@ -50,6 +50,8 @@ CF_ENUM(T_ENUM_RA_PREFERENCE, RA_PREF_, LOW, MEDIUM, HIGH)
 
 CF_GRAMMAR
 
+kw_sym: CUSTOM | OPTION | VALUE ;
+
 proto: radv_proto ;
 
 radv_proto_start: proto_start RADV
@@ -71,7 +73,7 @@ radv_proto_item:
  | PREFIX radv_prefix { add_tail(_CFG->pref_list, NODE this_radv_prefix); }
  | RDNSS { init_list(_dns_list); } radv_rdnss { add_tail_list(_CFG->rdnss_list, _dns_list); }
  | DNSSL { init_list(_dns_list); } radv_dnssl { add_tail_list(_CFG->dnssl_list, _dns_list); }
- | OTHER TYPE expr BYTESTRING { radv_add_to_custom_list(_CFG->custom_list, $3, $4); }
+ | CUSTOM OPTION TYPE expr VALUE BYTESTRING { radv_add_to_custom_list(_CFG->custom_list, $4, $6); }
  | TRIGGER net_ip6 { RADV_CFG->trigger = $2; }
  | PROPAGATE ROUTES bool { RADV_CFG->propagate_routes = $3; }
  ;
@@ -136,10 +138,10 @@ radv_iface_item:
  | PREFIX radv_prefix { add_tail(_IFACE->pref_list, NODE this_radv_prefix); }
  | RDNSS { init_list(_dns_list); } radv_rdnss { add_tail_list(_IFACE->rdnss_list, _dns_list); }
  | DNSSL { init_list(_dns_list); } radv_dnssl { add_tail_list(_IFACE->dnssl_list, _dns_list); }
- | OTHER TYPE expr BYTESTRING { radv_add_to_custom_list(_IFACE->custom_list, $3, $4); }
+ | CUSTOM OPTION TYPE expr VALUE BYTESTRING { radv_add_to_custom_list(_IFACE->custom_list, $4, $6); }
  | RDNSS LOCAL bool { RADV_IFACE->rdnss_local = $3; }
  | DNSSL LOCAL bool { RADV_IFACE->dnssl_local = $3; }
- | OTHER LOCAL bool { RADV_IFACE->custom_local = $3; }
+ | CUSTOM OPTION LOCAL bool { RADV_IFACE->custom_local = $4; }
  ;
 
 radv_preference:
diff --git a/proto/radv/packets.c b/proto/radv/packets.c
index d1f86ec1..77c98794 100644
--- a/proto/radv/packets.c
+++ b/proto/radv/packets.c
@@ -264,9 +264,8 @@ radv_prepare_dnssl(struct radv_iface *ifa, list *dnssl_list, char **buf, char *b
 static int
 radv_prepare_custom(struct radv_iface *ifa, list *custom_list, char **buf, char *bufend)
 {
-  struct radv_custom_config *

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

[Alexander Zubkov via Bird-users]

On Fri, Jun 23, 2023, 18:30 Ondrej Zajicek  wrote:

> On Wed, Jun 14, 2023 at 12:40:47AM +0200, Alexander Zubkov wrote:
> > Hi,
> >
> > Please look at these patches:
> >
> > bytestring-hex-prefix.patch - syntax with "hex:" prefix
> > I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> > allowed. As there is a distinguishing prefix here, this should not be
> > a problem.
> > Empty bytestrings are allowed too: "hex:"
>
> Hi
>
> Merged:
>
> https://gitlab.nic.cz/labs/bird/-/commit/65d6a525944faa3f77041419991d77106d8f0a0d
>
> I have mixed opinion on mixed colons here :-)
>
>
> > bytestring-hex-function.patch - function-like hex("...") syntax (on
> > top of the other patch)
> > It wasn't too complex, but you might have wanted to do it some other
> > way.
>
> Yes, the original idea there was to add bytestring as a data type, make
> hex() a regular (filter) function instead of special function-like
> syntax, and add equivalent of 'expr' grammar term for other data types.
>

I see. I think I can look into preparing a patch for that too.
But for such variant I would suggest using function names like
"from_hex/base64" instead of "hex/base64", or something including
bytestring reference: "bs_hex". Because the simple variants could be
misleading when used not only in the limited set of scopes. For example
they can be thought of converting to hex/base64 representation too. Or they
could collide with "hex" function to convert from string to int, which
someone would need to implement in the future.


>
> > I think this should be quite good too, the only problem with it
> > is inability to mix "hex" symbol with hex("...") bytestrings.
>
> This is an issue with any keyword, so not a big thing.
>

Yes. By the way what do you think about the patch that allows using
keywords and symbols together? Is it viable?


>
> > There probably was a mistake in nest/config.Y with missing "|" here:
> > "kw_sym: MIN MAX ;"
>
> You are right there.
>
>
> > I also enabled TEXT literals to be multiline. Didn't know it was not
> > allowed already, so I think it should not break things, but allows to
> > be more flexible with binary strings.
>
> That is probably right.
>
>
> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

On Fri, Jun 23, 2023, 17:47 Ondrej Zajicek  wrote:

> On Mon, Jun 12, 2023 at 01:08:15PM +0200, Alexander Zubkov via Bird-users
> wrote:
> > Hi,
> >
> > Currently one can use only a predefined set of advertised options in radv
> > protocol, that are supported by bird's configuration. It would be
> > convenient to be able to specify other possible options at least manually
> > as a blob so one should not wait until it is supported in the code,
> > released, etc.
>
> Hi
>
> Merged:
>
>
> https://gitlab.nic.cz/labs/bird/-/commit/9c81250c04798fd274ae9d77380e93b941ac2d7f
>
> Hopefully there is no requirement for RA options to be sorted by type, at
> least i did not find it in RFC 4861.
>
> The only objection from me is that 'other type' option name is kind of
> non-descriptive, does not indicate it is related to RA options (nor it is
> implicated by context). I do not really have a good idea for alternative,
> perhaps just 'custom option'? What do you think?
>

Yes, I was thinking about "custom" too. But it introduces a new keyword. So
I tried too choose something suitable from available keywords. But if it is
not a problem, I would prefer "custom" too as more descriptive.


> Could you prepare a patch for documentation?
>

Sure, just will wait for the final decision about the syntax ("other" vs
"custom").


> BTW, why not to use WALK_LIST() in radv_prepare_custom()?
> (just noticed in now)
>

That is a good question. Actually I just used the structure of the similar
function for the predefined option and didn't thought much about it. Now
that you pointed that out, I remember that macro from the other parts of
the code. And it seems reasonable to use it here, and probably in the
"source" function too. I can prepare a patch for that.


> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

Hi,

Please give some feedback.

On Thu, Jun 15, 2023 at 3:57 AM Alexander Zubkov  wrote:
>
> Hi,
>
> While waiting for the fate of the previous patches, I was thinking
> about that thing about using keywords as symbols. So here is another
> longread. :)
>
> Now it is not possible to mix a keyword and a keyword as a symbol
> together. Here is what I mean. With current master bird if I use
> config:
>
> protocol device {}
> template bgp { local role peer; }
> function role() { int role = 1; return role; }
>
> It parses ok, because "role" keyword is used before it is converted
> into a symbol. But if it appears as a symbol before:
>
> protocol device {}
> function role() { int role = 1; return role; }
> template bgp { local role peer; }
>
> It returns an error:
>
> bird: t5.conf:3:22 IP address constant expected
>
> Because "role" is converted to a symbol and it is not possible to use
> it as a keyword anymore. I thought if something can be done about that
> and I probably have a solution. See the attached patch. It maybe not
> the best design, just to show the idea. I change the order of
> detecting symbol and keyword in the lexer, so it always returns a
> keyword for a keyword, and it is converted into a symbol only in the
> parser when it is used as a symbol. As we can hit such symbol keyword
> many times, I check if it has already been defined and create a new
> one if needed. Then I replace mentions of CF_SYM_KNOWN with
> symbol_known, which can be CF_SYM_KNOWN or kw_sym. So, with this patch
> applied, both configs are successfully parsed and work well.
> 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.
>
> Some additional notes.
>
> My previous remark regarding the missing "|" in "kw_sym: MIN MAX"
> seems to be correct, because current bird master fails on such config:
>
> protocol device {}
> function min() { return 0; }
>
> With the error:
>
> bird: t4.conf:2:13 syntax error, unexpected '(', expecting MAX
>
> And also there seems to be a bug with recently added syntax for
> variable definitions. When they are defined without initializing. This
> config is successfully loaded:
>
> protocol device {}
> function role() { int role; role = 1; return role; }
>
> But if I try to call "eval role()" from cli, I get an error: "runtime
> error", and the daemon logs this:
>
> bird: filters, line 2: Argument 1 of VAR_INIT must be of type int, got type 
> void
>
> So it looks like it tries to initialize it with the void value and
> fails to do it. I haven't tracked the source of this bug.
>
> On Wed, Jun 14, 2023 at 12:40 AM Alexander Zubkov  wrote:
> >
> > Hi,
> >
> > Please look at these patches:
> >
> > bytestring-hex-prefix.patch - syntax with "hex:" prefix
> > I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> > allowed. As there is a distinguishing prefix here, this should not be
> > a problem.
> > Empty bytestrings are allowed too: "hex:"
> >
> > bytestring-hex-function.patch - function-like hex("...") syntax (on
> > top of the other patch)
> > It wasn't too complex, but you might have wanted to do it some other
> > way. I think this should be quite good too, the only problem with it
> > is inability to mix "hex" symbol with hex("...") bytestrings.
> > I parse string in two steps. First to know the length of a binary
> > output. Current hex realization does the same anyway. I made a
> > separate function for it to reuse it for "classic" bytestrings and for
> > function-like syntax.
> > It ignores all non-alphanumeric symbols and requires that each byte
> > symbols go in pairs without delimiters.
> > I added a HEX keyword and added it to kw_sym, but this solution does
> > not allow to mix "hex" symbol and hex("...") bytestring in the same
> > config.
> > There probably was a mistake in nest/config.Y with missing "|" here:
> > "kw_sym: MIN MAX ;"
> > There is a "TODO" in the heading of strtobin.c, don't know what is
> > your policy regarding tha

Re: Graceful shutdown request signal

[Alexander Zubkov via Bird-users]

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 <
bird-users@network.cz> 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.
>
>

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

[Alexander Zubkov via Bird-users]

Hi,

While waiting for the fate of the previous patches, I was thinking
about that thing about using keywords as symbols. So here is another
longread. :)

Now it is not possible to mix a keyword and a keyword as a symbol
together. Here is what I mean. With current master bird if I use
config:

protocol device {}
template bgp { local role peer; }
function role() { int role = 1; return role; }

It parses ok, because "role" keyword is used before it is converted
into a symbol. But if it appears as a symbol before:

protocol device {}
function role() { int role = 1; return role; }
template bgp { local role peer; }

It returns an error:

bird: t5.conf:3:22 IP address constant expected

Because "role" is converted to a symbol and it is not possible to use
it as a keyword anymore. I thought if something can be done about that
and I probably have a solution. See the attached patch. It maybe not
the best design, just to show the idea. I change the order of
detecting symbol and keyword in the lexer, so it always returns a
keyword for a keyword, and it is converted into a symbol only in the
parser when it is used as a symbol. As we can hit such symbol keyword
many times, I check if it has already been defined and create a new
one if needed. Then I replace mentions of CF_SYM_KNOWN with
symbol_known, which can be CF_SYM_KNOWN or kw_sym. So, with this patch
applied, both configs are successfully parsed and work well.
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.

Some additional notes.

My previous remark regarding the missing "|" in "kw_sym: MIN MAX"
seems to be correct, because current bird master fails on such config:

protocol device {}
function min() { return 0; }

With the error:

bird: t4.conf:2:13 syntax error, unexpected '(', expecting MAX

And also there seems to be a bug with recently added syntax for
variable definitions. When they are defined without initializing. This
config is successfully loaded:

protocol device {}
function role() { int role; role = 1; return role; }

But if I try to call "eval role()" from cli, I get an error: "runtime
error", and the daemon logs this:

bird: filters, line 2: Argument 1 of VAR_INIT must be of type int, got type void

So it looks like it tries to initialize it with the void value and
fails to do it. I haven't tracked the source of this bug.

On Wed, Jun 14, 2023 at 12:40 AM Alexander Zubkov  wrote:
>
> Hi,
>
> Please look at these patches:
>
> bytestring-hex-prefix.patch - syntax with "hex:" prefix
> I allowed mixed colons with no-divider there, so hex:12:345678:90 is
> allowed. As there is a distinguishing prefix here, this should not be
> a problem.
> Empty bytestrings are allowed too: "hex:"
>
> bytestring-hex-function.patch - function-like hex("...") syntax (on
> top of the other patch)
> It wasn't too complex, but you might have wanted to do it some other
> way. I think this should be quite good too, the only problem with it
> is inability to mix "hex" symbol with hex("...") bytestrings.
> I parse string in two steps. First to know the length of a binary
> output. Current hex realization does the same anyway. I made a
> separate function for it to reuse it for "classic" bytestrings and for
> function-like syntax.
> It ignores all non-alphanumeric symbols and requires that each byte
> symbols go in pairs without delimiters.
> I added a HEX keyword and added it to kw_sym, but this solution does
> not allow to mix "hex" symbol and hex("...") bytestring in the same
> config.
> There probably was a mistake in nest/config.Y with missing "|" here:
> "kw_sym: MIN MAX ;"
> There is a "TODO" in the heading of strtobin.c, don't know what is
> your policy regarding that. The code is still based on the current
> BYTESTRING parser.
> I also enabled TEXT literals to be multiline. Didn't know it was not
> allowed already, so I think it should not break things, but allows to
> be more flexible with binary strings.
>
> On Tue, Jun 13, 2023 at 6:37 PM Ondrej Zajicek  wrote:
> >
> > On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> > > On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek  wrote:
> > >
> > > > We agreed on keeping existing format for suffiently long hex 
> > > >

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

[Alexander Zubkov via Bird-users]

Hi,

Please look at these patches:

bytestring-hex-prefix.patch - syntax with "hex:" prefix
I allowed mixed colons with no-divider there, so hex:12:345678:90 is
allowed. As there is a distinguishing prefix here, this should not be
a problem.
Empty bytestrings are allowed too: "hex:"

bytestring-hex-function.patch - function-like hex("...") syntax (on
top of the other patch)
It wasn't too complex, but you might have wanted to do it some other
way. I think this should be quite good too, the only problem with it
is inability to mix "hex" symbol with hex("...") bytestrings.
I parse string in two steps. First to know the length of a binary
output. Current hex realization does the same anyway. I made a
separate function for it to reuse it for "classic" bytestrings and for
function-like syntax.
It ignores all non-alphanumeric symbols and requires that each byte
symbols go in pairs without delimiters.
I added a HEX keyword and added it to kw_sym, but this solution does
not allow to mix "hex" symbol and hex("...") bytestring in the same
config.
There probably was a mistake in nest/config.Y with missing "|" here:
"kw_sym: MIN MAX ;"
There is a "TODO" in the heading of strtobin.c, don't know what is
your policy regarding that. The code is still based on the current
BYTESTRING parser.
I also enabled TEXT literals to be multiline. Didn't know it was not
allowed already, so I think it should not break things, but allows to
be more flexible with binary strings.

On Tue, Jun 13, 2023 at 6:37 PM Ondrej Zajicek  wrote:
>
> On Tue, Jun 13, 2023 at 05:34:18PM +0200, Alexander Zubkov wrote:
> > On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek  wrote:
> >
> > > We agreed on keeping existing format for suffiently long hex bytestrings,
> > > using hex: prefix for bytestrings of any length, and adding hex("...") /
> > > base64("...") as ordinary expressions.
> >
> > Hi,
> >
> > So full house. :) I can try to implement it. Do you need a hand?
>
> If you implement hex: prefix, we could easily merge that. The
> hex("...") / base64("...") is not priority and would require some
> nontrivial changes to be done properly.
>
> --
> 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."
commit a0d088b49510db8f968a99b7e1a5f7f1242e199d
Author: Alexander Zubkov 
Date:   Tue Jun 13 22:19:28 2023 +0200

Conf: allow to provide a bytestring of any length with 'hex:' prefix

diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index 9555949d..9025a84d 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -255,12 +255,17 @@ WHITE [ \t]
   return IP4;
 }
 
-{XIGIT}{2}((:{XIGIT}{2}){15,}|({XIGIT}{2}){15,}) {
-  char *s = yytext;
+({XIGIT}{2}){16,}|{XIGIT}{2}(:{XIGIT}{2}){15,}|hex:({XIGIT}{2}(:?{XIGIT}{2})*)? {
+  char *s, *sb = yytext;
   size_t len = 0, i;
   struct bytestring *bytes;
   byte *b;
 
+  /* skip 'hex:' prefix */
+  if (sb[0] == 'h' && sb[1] == 'e' && sb[2] == 'x' && sb[3] == ':')
+sb += 4;
+
+  s = sb;
   while (*s) {
 len++;
 s += 2;
@@ -271,7 +276,7 @@ WHITE [ \t]
 
   bytes->length = len;
   b = >data[0];
-  s = yytext;
+  s = sb;
   errno = 0;
   for (i = 0; i < len; i++) {
 *b = bstrtobyte16(s);
commit eead1fd2f7193bed2bbece8aeebfa04571030f6e
Author: Alexander Zubkov 
Date:   Wed Jun 14 00:08:23 2023 +0200

Conf: new bytestring syntax hex("..."), allow multiline strings

diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index 9025a84d..dd607380 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -256,37 +256,26 @@ WHITE [ \t]
 }
 
 ({XIGIT}{2}){16,}|{XIGIT}{2}(:{XIGIT}{2}){15,}|hex:({XIGIT}{2}(:?{XIGIT}{2})*)? {
-  char *s, *sb = yytext;
-  size_t len = 0, i;
+  char *str = yytext;
+  size_t len;
   struct bytestring *bytes;
-  byte *b;
 
   /* skip 'hex:' prefix */
-  if (sb[0] == 'h' && sb[1] == 'e' && sb[2] == 'x' && sb[3] == ':')
-sb += 4;
-
-  s = sb;
-  while (*s) {
-len++;
-s += 2;
-if (*s == ':')
-  s++;
-  }
+  if (str[0] == 'h' && str[1] == 'e' && str[2] == 'x' && str[3] == ':')
+str += 4;
+
+  errno = 0;
+  len = bstrhextobin(str, 0);
+  if (errno || len == (size_t)-1)
+cf_error("Invalid hex string");
+
   bytes = cfg_allocz(sizeof(*bytes) + len);
 
   bytes->length = len;
-  b = >data[0];
-  s = sb;
-  errno = 0;
-  for (i = 0; i < len; i++) {
-*b = bstrtobyte16(s);
-if (errno == ERANGE)
-  cf_error("Invalid hex string");
-b++;
-s += 2;
-if (*s == ':')
-  s++;
-  }
+  bstrhextobin(str, bytes->data);
+  if (errn

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

[Alexander Zubkov via Bird-users]

On Tue, Jun 13, 2023, 16:07 Ondrej Zajicek  wrote:

> On Mon, Jun 12, 2023 at 05:55:34PM +0200, Alexander Zubkov wrote:
> > BTW, if we put a string literal inside the brackets, we can mimic a
> > function call without dirty lexer/parser hacks:
> > hex("...")
> >
> > Or maybe you have already agreed on something?
>
> Hi
>
> We agreed on keeping existing format for suffiently long hex bytestrings,
> using hex: prefix for bytestrings of any length, and adding hex("...") /
> base64("...") as ordinary expressions.
>


Hi,

So full house. :) I can try to implement it. Do you need a hand?


> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

Some additional ideas for decorating binary strings so that they do
not resemble other statements:
@hex(...)
bin:hex(...)

BTW, if we put a string literal inside the brackets, we can mimic a
function call without dirty lexer/parser hacks:
hex("...")

Or maybe you have already agreed on something?


On Mon, Jun 12, 2023 at 4:02 PM Ondrej Zajicek  wrote:
>
> On Mon, Jun 12, 2023 at 03:32:20PM +0200, Maria Matejka wrote:
> > We can simply change the lexer state externally from the parser as soon as 
> > the hex( prefix is seen, and provide the result directly from the lexer.
> >
> > This way, we can allow all the syntaxes like hex(de-ad-be-ef), 
> > hex(de:ad:be:ef), hex(de ad be ef) or even hex(dea:db-eef) just by ignoring 
> > nonalnum characters altogether.
> >
> > Here I'd strongly prefer nicer user experience over setting the syntax to 
> > best fit our needs.
>
> Which would lead to syntax that is extremely confusing (i.e. hard to
> intuitively grasp the right mental model just from meeting examples),
> so i think hex(...) variant is also worse from user experience point.
> As a user, i always hated unexpected special cases in syntax, even if
> they might be expedient in some cases.
>
> > I don't think any user really cares about the lexer/parser difference.
>
> People came with some preconceptions based on knowledge of syntax of
> other programming / configuration (and also regular) languages, so they
> have (either explicit or intuitive) concept of elementary / compound
> statement. If there is someting that looks like existing compound
> statement, but is in fact something completely different, it is
> confusing.
>
> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

On Mon, Jun 12, 2023 at 3:17 PM Ondrej Zajicek 
wrote:

> On Mon, Jun 12, 2023 at 01:08:15PM +0200, Alexander Zubkov via Bird-users
> wrote:
> > Hi,
> >
> > The main concern is that a 6-byte bytestring conflicts with the MAC
> address
> > representation. Bird does not have the type for it currently, but who
> > knows, it might need it in the future. So we might need some new syntax
> for
> > bytestring in that case. Or it can be postponed to later time. In this
> case
> > introduction of MAC-address lexems would break configs that use 6-byte
> > bytestrings (if we want to care much about those).
>
> Hi
>
> I already added MAC-address lexem and shortened minimum bytestring length
> to 9 bytes in EVPN branch (to represent 10-byte ESI) :
>
>
> https://gitlab.nic.cz/labs/bird/-/commit/cf0661c9762090231c9f2d973968a7ce9f98407e
>
>
I was afraid to shorten non-colon variant, becuase somebody using the
variable name "feedfacecafebeef01" might get hurt. :)


> So i would keep it at that limit and used e.g. hex:XX:YY:... syntax
> for shorter ones.
>

But Maria has a good point, that it may be beneficial to be able to input
the blob with spaces or even line breaks, which requires some sort of
"brackets".


>
> --
> 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: [PATCH] adding custom options in radv protocol, strict ipv6 regex

[Alexander Zubkov via Bird-users]

On Mon, Jun 12, 2023 at 3:04 PM Toke Høiland-Jørgensen  wrote:

> Alexander Zubkov via Bird-users  writes:
>
> > Hello, Maria!
> >
> > You suggestion for blob syntax seems good to me. I think I can try to
> > prepare patches for that. Only one concern is that it could break some
> > current configuration files, if they have functions with such names.
> Maybe
> > it is better to use some other "brackets" to make it less possible to hit
> > something? hex or hex[deadbeef] maybe? Or even something exotic
> > like hex|deadbeef| ?
>
> How about just using the standard 0x prefix?
>

It is already taken for integers. :)


>
> I.e.:
>
> 0xfc00deadbeefcafe -> 8-byte byte string
> fc00:dead:beef:cafe -> IPv6 address
>
> -Toke
>

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

[Alexander Zubkov via Bird-users]

Hello!

I'm not sure if it is possible to parse something like:

hex(1234)

both as a function call and a special bytestring depending on the symbol
presense. I thought such bytestrings is needed to be defined in the lexer
as a single expression for the whole sequence, because if you pass it upper
to a parser as: HEX '('  ')' - you'll have problem with how to
parse that , because it should be context-dependent.

But I'm not that proficient with the parsing and I'm probably missing
something. So if you have any tips on how to do it, I will be glad if you
share them with me.

BTW that kw_sym workaround seems like it needs to contain much more
symbols. :)

On Mon, Jun 12, 2023 at 2:40 PM Maria Matejka  wrote:

> Hello!
>
> I think using hex() and base64() with adding these two tokens to the
> "kw_sym:" non-terminal. This way, no current config should break.
>
> Also it may be handy for both hex() and base64() to accept any number of
> whitespace inside the argument, to enable configs like hex(de ad be ef) or
> other direct pastes from hexdumps or base64 encoders. We could then e.g.
> add the SSH keys for RPKI inline to the config file.
>
> I'd prefer keeping the IPv6 and bytestrings as they are now, possibly even
> deprecating the current bytestring format in future. (Weak opinion on this.)
>
> Maria
> On 6/12/23 14:24, Alexander Zubkov wrote:
>
> Hello, Maria!
>
> You suggestion for blob syntax seems good to me. I think I can try to
> prepare patches for that. Only one concern is that it could break some
> current configuration files, if they have functions with such names. Maybe
> it is better to use some other "brackets" to make it less possible to hit
> something? hex or hex[deadbeef] maybe? Or even something exotic
> like hex|deadbeef| ?
>
> Would you like to keep my proposed changes for IPv6 and bytestrings too?
> Or just introduce the new syntax?
>
> On Mon, Jun 12, 2023 at 1:33 PM Maria Matejka 
> wrote:
>
>> Hello!
>>
>> This looks like a clever solution for such a problem. Thank you for the
>> patch!
>>
>> Regarding the bytestring syntax, what about adding some syntax like
>> hex(deadbeef12345678) or even base64(...) where the user could write byte
>> blob of any length?
>>
>> Maria
>> On 6/12/23 13:08, Alexander Zubkov via Bird-users wrote:
>>
>> Hi,
>>
>> Currently one can use only a predefined set of advertised options in radv
>> protocol, that are supported by bird's configuration. It would be
>> convenient to be able to specify other possible options at least manually
>> as a blob so one should not wait until it is supported in the code,
>> released, etc.
>>
>> This idea is inspired by presentation by Ondřej Caletka at CSNOG, in
>> which he noticed the lack of either PREF64 option or possibility to add
>> custom options in various software.
>>
>> Attached patch [radv-custom.patch] makes it possible to define such
>> options with the syntax:
>>
>> other type  
>>
>> I can also prepare a patch for documentation if it is to be merged.
>>
>> But it does solve the question with PREF64 completely. Because currently
>> bytestring minimal length is 16 bytes, but for PREF64 we need to provide a
>> 14-byte blob. And for minimal RA option, it have to be as short as 6 bytes.
>>
>> So another patch [bytestring-short.patch] allows bytestrings to be as
>> short as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I
>> kept the minimum size of 16 bytes without colons, because it can conflict
>> with some symbol names.
>>
>> The main concern is that a 6-byte bytestring conflicts with the MAC
>> address representation. Bird does not have the type for it currently, but
>> who knows, it might need it in the future. So we might need some new syntax
>> for bytestring in that case. Or it can be postponed to later time. In this
>> case introduction of MAC-address lexems would break configs that use 6-byte
>> bytestrings (if we want to care much about those).
>>
>> It is also not possible to define a 8-byte bytestring, because it
>> conflicts with IPv6 address, but we are introducing short bytestrings for
>> RA here, and 8-byte bytestrings are not strictly required for that, because
>> possible option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ...
>> So if one needs a 8-byte payload, he can easily pad it with extra zeroes
>> ":00" with the same on-the-wire result. But still, this gives one more
>> reason for an additional syntax for bytestrings.
>>
>> There also was possbility to explicitly allow only 6, 7, 9 and greater
>>

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

[Alexander Zubkov via Bird-users]

Hello, Maria!

You suggestion for blob syntax seems good to me. I think I can try to
prepare patches for that. Only one concern is that it could break some
current configuration files, if they have functions with such names. Maybe
it is better to use some other "brackets" to make it less possible to hit
something? hex or hex[deadbeef] maybe? Or even something exotic
like hex|deadbeef| ?

Would you like to keep my proposed changes for IPv6 and bytestrings too? Or
just introduce the new syntax?

On Mon, Jun 12, 2023 at 1:33 PM Maria Matejka  wrote:

> Hello!
>
> This looks like a clever solution for such a problem. Thank you for the
> patch!
>
> Regarding the bytestring syntax, what about adding some syntax like
> hex(deadbeef12345678) or even base64(...) where the user could write byte
> blob of any length?
>
> Maria
> On 6/12/23 13:08, Alexander Zubkov via Bird-users wrote:
>
> Hi,
>
> Currently one can use only a predefined set of advertised options in radv
> protocol, that are supported by bird's configuration. It would be
> convenient to be able to specify other possible options at least manually
> as a blob so one should not wait until it is supported in the code,
> released, etc.
>
> This idea is inspired by presentation by Ondřej Caletka at CSNOG, in which
> he noticed the lack of either PREF64 option or possibility to add custom
> options in various software.
>
> Attached patch [radv-custom.patch] makes it possible to define such
> options with the syntax:
>
> other type  
>
> I can also prepare a patch for documentation if it is to be merged.
>
> But it does solve the question with PREF64 completely. Because currently
> bytestring minimal length is 16 bytes, but for PREF64 we need to provide a
> 14-byte blob. And for minimal RA option, it have to be as short as 6 bytes.
>
> So another patch [bytestring-short.patch] allows bytestrings to be as
> short as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I
> kept the minimum size of 16 bytes without colons, because it can conflict
> with some symbol names.
>
> The main concern is that a 6-byte bytestring conflicts with the MAC
> address representation. Bird does not have the type for it currently, but
> who knows, it might need it in the future. So we might need some new syntax
> for bytestring in that case. Or it can be postponed to later time. In this
> case introduction of MAC-address lexems would break configs that use 6-byte
> bytestrings (if we want to care much about those).
>
> It is also not possible to define a 8-byte bytestring, because it
> conflicts with IPv6 address, but we are introducing short bytestrings for
> RA here, and 8-byte bytestrings are not strictly required for that, because
> possible option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ...
> So if one needs a 8-byte payload, he can easily pad it with extra zeroes
> ":00" with the same on-the-wire result. But still, this gives one more
> reason for an additional syntax for bytestrings.
>
> There also was possbility to explicitly allow only 6, 7, 9 and greater
> lengths of bytestrings. Or to move IPv6 regex definition before bytestring
> definition to make it more preferrable. I choose the second variant, but
> IPv6 regex is too loose now and match many things far from IPv6 notation.
> So I decided to provide a more strict regex definition for IPv6 addresses.
> Of course it is ugly, but I think it could be helpful anyway, because it
> does not conflict with other similar lexems, including MAC addresses.
>
> As a downside for this, in case of some typo in IPv6 address, there will
> not be a meaningful error about bad IPv6 address. So I added an additional
> regex there, to catch lexems with hex digits and at least 2 colons to show
> more meaningful error for that. But I'm not sure about it.
>
> If those changes for bytestrings are OK too, I also can prepare further
> patch for documentation.
>
> Have a nice day,
> Alexander Zubkov
>
> --
> Maria Matejka | BIRD Team Leader | CZ.NIC, z.s.p.o.
>
>

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

[Alexander Zubkov via Bird-users]

Hi,

Currently one can use only a predefined set of advertised options in radv
protocol, that are supported by bird's configuration. It would be
convenient to be able to specify other possible options at least manually
as a blob so one should not wait until it is supported in the code,
released, etc.

This idea is inspired by presentation by Ondřej Caletka at CSNOG, in which
he noticed the lack of either PREF64 option or possibility to add custom
options in various software.

Attached patch [radv-custom.patch] makes it possible to define such options
with the syntax:

other type  

I can also prepare a patch for documentation if it is to be merged.

But it does solve the question with PREF64 completely. Because currently
bytestring minimal length is 16 bytes, but for PREF64 we need to provide a
14-byte blob. And for minimal RA option, it have to be as short as 6 bytes.

So another patch [bytestring-short.patch] allows bytestrings to be as short
as 6 bytes, when colon-notation is used: "01:02:03:04:05:06". And I kept
the minimum size of 16 bytes without colons, because it can conflict with
some symbol names.

The main concern is that a 6-byte bytestring conflicts with the MAC address
representation. Bird does not have the type for it currently, but who
knows, it might need it in the future. So we might need some new syntax for
bytestring in that case. Or it can be postponed to later time. In this case
introduction of MAC-address lexems would break configs that use 6-byte
bytestrings (if we want to care much about those).

It is also not possible to define a 8-byte bytestring, because it conflicts
with IPv6 address, but we are introducing short bytestrings for RA here,
and 8-byte bytestrings are not strictly required for that, because possible
option sizes are 8, 16, ... with payloads 2 bytes less: 6, 14, ... So if
one needs a 8-byte payload, he can easily pad it with extra zeroes ":00"
with the same on-the-wire result. But still, this gives one more reason for
an additional syntax for bytestrings.

There also was possbility to explicitly allow only 6, 7, 9 and greater
lengths of bytestrings. Or to move IPv6 regex definition before bytestring
definition to make it more preferrable. I choose the second variant, but
IPv6 regex is too loose now and match many things far from IPv6 notation.
So I decided to provide a more strict regex definition for IPv6 addresses.
Of course it is ugly, but I think it could be helpful anyway, because it
does not conflict with other similar lexems, including MAC addresses.

As a downside for this, in case of some typo in IPv6 address, there will
not be a meaningful error about bad IPv6 address. So I added an additional
regex there, to catch lexems with hex digits and at least 2 colons to show
more meaningful error for that. But I'm not sure about it.

If those changes for bytestrings are OK too, I also can prepare further
patch for documentation.

Have a nice day,
Alexander Zubkov
commit 2b7908712dda313e0a97740751315e99ec0d06c0
Author: Alexander Zubkov 
Date:   Mon Jun 12 11:52:13 2023 +0200

RAdv: allow adding custom options with payload as hexadecimal string

Allows to send RA options that do not have specific configure commands
defined for it by specifying its plain payload manually.

diff --git a/proto/radv/config.Y b/proto/radv/config.Y
index 8d4a3ab9..5c213d50 100644
--- a/proto/radv/config.Y
+++ b/proto/radv/config.Y
@@ -25,6 +25,15 @@ static struct radv_dnssl_config this_radv_dnssl;
 static list radv_dns_list;	/* Used by radv_rdnss and radv_dnssl */
 static u8 radv_mult_val;	/* Used by radv_mult for second return value */
 
+static inline void
+radv_add_to_custom_list(list *l, int type, struct bytestring *payload)
+{
+  if (type < 0 || type > 255) cf_error("RA cusom type must be in range 0-255");
+  struct radv_custom_config *cf = cfg_allocz(sizeof(struct radv_custom_config));
+  add_tail(l, NODE cf);
+  cf->type = type;
+  cf->payload = payload;
+}
 
 CF_DECLS
 
@@ -52,6 +61,7 @@ radv_proto_start: proto_start RADV
   init_list(_CFG->pref_list);
   init_list(_CFG->rdnss_list);
   init_list(_CFG->dnssl_list);
+  init_list(_CFG->custom_list);
 };
 
 radv_proto_item:
@@ -61,6 +71,7 @@ radv_proto_item:
  | PREFIX radv_prefix { add_tail(_CFG->pref_list, NODE this_radv_prefix); }
  | RDNSS { init_list(_dns_list); } radv_rdnss { add_tail_list(_CFG->rdnss_list, _dns_list); }
  | DNSSL { init_list(_dns_list); } radv_dnssl { add_tail_list(_CFG->dnssl_list, _dns_list); }
+ | OTHER TYPE expr BYTESTRING { radv_add_to_custom_list(_CFG->custom_list, $3, $4); }
  | TRIGGER net_ip6 { RADV_CFG->trigger = $2; }
  | PROPAGATE ROUTES bool { RADV_CFG->propagate_routes = $3; }
  ;
@@ -82,6 +93,7 @@ radv_iface_start:
   init_list(_IFACE->pref_list);
   init_list(_IFACE->rdnss_list);
   init_list(_IFACE->dnssl_list);
+  init_list(_IFACE->custom_list);
 
   RADV_IFACE->min_ra_int = (u32

Re: Adding more then one bgp community at once

[Alexander Zubkov via Bird-users]

I think one can now write a custom function using "for" to obtain that
functionality.

On Fri, May 5, 2023 at 3:40 PM Ondrej Zajicek 
wrote:

> On Fri, May 05, 2023 at 01:10:10PM +0300, Mikhail Grishin wrote:
> > Hi,
> >
> > I tried the same at BIRD 2.13 . It reports  "Can't add set".
> >
> > At the same time in docs
> > --
> > |add(/C/,/P/)| adds pair (or quad) /P/ to clist /C/ and returns the
> result.
> > If item /P/ is already in clist /C/, it does nothing. /P/ may also be a
> > clist, in that case all its members are added; i.e., it works as clist
> > union.
>
> Hi
>
> The docs says "/P/ may also be a clist", but it cannot be a pair set,
> while the literal '[(1,1), (1,2)]' is a pair set literal. Unfortunately
> we do not have literals for clists.
>
> --
> 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 3.0alpha1

[Alexander Zubkov via Bird-users]

Hi Douglas,

Come to CSNOG 2023. Maria should give a presentation on Bird 3 there too! :)

On Mon, Apr 24, 2023 at 3:48 PM Douglas Fischer 
wrote:

> I was looking for a live stream of @Maria Matejka  
> presentation about Bird
> 3 on 38º Euro-IX.
> But I was not able to find anyone.
> This event was transmitted?
>
>
> https://www.euro-ix.net/en/events/fora/38th-euro-ix-forum/#:~:text=BIRD%20in%20muiltiple%20threads
>
> Em sex., 21 de abr. de 2023 às 04:24, Ondrej Filip 
> escreveu:
>
>> Dear BIRD Users,
>> we're presenting you a new alpha version of the Multithreaded BIRD.
>> Contrary to the previous version, you have to set your desired number
>> of threads in config by the threads N; option.
>>
>> Version 3.0alpha1 fixes a lot of bugs found in previous versions. Our
>> tests show that the overall performance may be about 3-8 times better
>> than v2.0.12; yet the real life always brings questions and problems
>> which the development can't anticipate fully.
>>
>> Please run your tests and we hope we get back to you soon with a
>> stable version. Looking forward to your reports.
>>
>> I thank my colleagues and namely Maria for this release!
>>
>> Cheers
>> Ondrej
>>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
>

Re: Is there any way to set different communities while importing prefixes?

[Alexander Zubkov via Bird-users]

Hi,

Just look at the docs:
https://bird.network.cz/?get_doc=20=bird-6.html#ss6.14


On Wed, Apr 12, 2023, 23:57 Valery Lutoshkin  wrote:

> Hi,
>
> I use Bird 2.0.9 to spread a special list of prefixes (about 100k) via BGP
> to an unknown list of users (around 1k).
>
> The prefixes are supposed to be marked by different communities (6 right
> now) and receivers should be able to filter them by those communities to
> use only prefixes they want.
>
>
> While only one community should be attached to the prefix, I use just 6
> different files with prefixes and attach the proper community in the import
> processes like this:
>
> protocol static importbgp_1 {
>
> ipv4 { import filter {bgp_community.add((65000,1)); accept;}; };
>
> include "/tmp/prefixes_1.txt";
>
> }
>
> Lines in the prefixes_1 file look like this:
>
> route 1.3.7.7/32 unreachable;
>
>
> But when I need to attach several communities to the prefixes, I have to
> create 2^6=64 different static protocols and generate 64 different files.
>
> And for 8 communities I will have to create 256 protocols and files.
>
>
> If I could add some marks to routes in the imported file, I would use
> those marks in the import filter to attach communities to the prefix.
>
>
> But if I’m not mistaken, there is no way of doing that.
>
>
> If there is a different solution to this issue that I’m unaware of, would
> you please let me know.
>
>
> Best regards,
>
> Valery
>

Re: Force bird to update bgp route configuration after X seconds

[Alexander Zubkov via Bird-users]

Hi,

If you mean you insert routes into the config file, than yes, you have to
call the configuration reload yourself. Bird doesn't reload the
configuration by itself as far as I know.


On Tue, Mar 28, 2023, 01:03 Pedro Henrique de Araújo Marques <
pedroa...@hotmail.com> wrote:

> Good evening, I'm doing some tests with BIRD for a while now and I would
> like some help with a problem I'm facing. I have the following BIRD
> configuration:
>
> *router id 10.0.0.128;*
>
> *ipv4 table master4;*
> *ipv6 table master6;*
> *flow4 table flowtab4;*
> *flow6 table flowtab6;*
>
> *filter subnet_group1{*
> *if(bgp_community.len = 0) then {*
> *bgp_community.add((555,555));*
> *accept;*
> *}*
> *else{ accept; }*
>
> *};*
>
> *protocol bgp uplink1{*
> *local as 129;*
> *neighbor 10.0.1.128 as 128;*
> *multihop 1;*
> *ipv4{*
> *import filter { accept; };*
> *export filter subnet_group1;*
> *};*
> *ipv6{*
> *import filter { accept; };*
> *export filter subnet_group1;*
> *};*
> *};*
>
> *protocol static blackhole_ipv4_routes{*
> *route 10.0.90.100/32  blackhole;*
> *route 10.0.90.99/32  blackhole;*
> *ipv4;*
> *};*
>
> I created a script that after some time it inserts some new routes into
> the  blackhole_ipv4_routes protocol defined above, let's say all of
> 10.0.0.0/24 for example. Is there an option that I could use in the
> config file to detect this change and update bird accordingly with the new
> table additions, or do I need to always call 'birdc -configure' after the
> script ends?
>

Re: Route attributes available when using export tables

[Alexander Zubkov via Bird-users]

Hi,

I remembered reading this thread. You might have the similar problem:
https://bird.network.cz/pipermail/bird-users/2022-October/016348.html

On Tue, Mar 7, 2023 at 9:14 PM Hugo Slabbert via Bird-users <
bird-users@network.cz> wrote:

> Hi folks,
>
> On bird 2.0.7. We've been debugging some export behaviour (ref subject
> "BIRD continues exporting routes but reports no exports"), and enabled
> export tables on ipv4 and ipv6 channels for some of our BGP sessions. When
> we did that, we found that the MED we were applying in our export filters
> were no longer being stamped on export.
>
> We're setting route preference on locally defined static routes, and then
> setting MED at export based on that route preference. Since the preference
> order is flipped between MED and BIRD's route preference (higher preference
> is better; lower MED is better), we transform that and bank it around 100,
> e.g. preference 100 -> MED 100; preference 99 -> MED 110, etc:
>
> ```
> function preference_to_med ()
> int tier;
> {
> tier = 100 - preference;
> return 100 + (tier * 10);
> }
> ```
>
> Best I can tell, it appears that the `preference` attribute is not
> available on routes when they're passed through export tables.
>
> I tried instead to just stamp igp_metric on the static routes right when
> they are defined, to the same value as we would have for the MED, and then
> just doing `bgp_med = igp_metric` in the export filter, but that also did
> not work as MED was still not being stamped on export.
>
> We can and do also set `bgp_med` on the static routes right at their
> initial definition time. But, they are defined in a different table and
> being pulled into the source table for the exports through a pipe (so e.g.
> defined in MY_CUSTOM_TABLE with bgp_med set, then imported via pipe to
> master4, and exported from master4 via BGP), and it appears that operation
> means the initial MED defined on the route is not retained on export after
> passing through the pipe and needing to be set again explicitly.
>
> Are these types of BIRD "internal" route attributes, e.g. preference,
> igp_metric, not present on routes when they're passed through export
> tables? I suppose we could instead use BGP communities on the route, and
> extract the value portion of the community, but we were trying to keep
> things to a native metric type value. I.e. we want to just pass this across
> the BGP session as something like MED rather than making the far end apply
> a function to extract a value from a community. We could still use
> communities purely *within* the local BIRD instance for that, using the
> function only locally and still stamping MED on export; I'm just trying to
> determine if that's the best path, as it feels a bit clunky to need to use
> communities for something that is only locally significant within the local
> BIRD instance.
>
>

Re: BIRD continues exporting routes but reports no exports

[Alexander Zubkov via Bird-users]

Hi,

It is documented in recent versions and on the bird's site too. Pay
attention to this:

[(import|export) table p.c]

On Fri, Mar 3, 2023, 18:32 Hugo Slabbert via Bird-users <
bird-users@network.cz> wrote:

> Right, so,
>
> I've gone ahead and enabled export tables on the channels for the relevant
> peers, per Alexander's suggestion for possibly getting additional
> visibility. I don't seem to spot any different views for route status,
> though. I don't see any particular docs on how to *view* export tables;
> does enabling export tables make a different view available to look at the
> export table contents specifically? Or does it just shift the behaviour so 
> `show
> route export ` displays the export table contents rather than a
> point-in-time evaluation of export filters for the specified neighbor?
>
> Snippet showing export tables config enabled for the peers:
>
> ```
> template bgp GATEWAY_v6 {
> hold time 6;
> startup hold time 20;
> connect delay time 3;
> connect retry time 6;
> error wait time 3, 12;
> med metric;
> allow local as 1;
>
> local fdff::4:2 as MENLO_ASN;
>
> ipv6 {
> export table on;
> import filter GATEWAY_IMPORT_v6;
> export filter GATEWAY_EXPORT_v6;
> };
> ipv4 {
> export table on;
> extended next hop on;
> add paths rx;
> import filter GATEWAY_IMPORT_v4;
> export filter GATEWAY_EXPORT_v4;
> };
> }
> # ...
> protocol bgp gw_085ea85_euwest2 from GATEWAY_v6 {
> neighbor fdff::8005:f4d1 as 65000;
> }
> ```
>
> I don't see any different behaviour on the affected hosts, though. E.g. a
> host that just had `configure` called once after setting the draining
> flag is showing these symptoms, showing nothing for `show route export
> `:
>
> ```
> bird> show route export gw_085ea85_euwest2
> bird>
> ```
>
> ...but still showing exports under the protocol details:
>
> ```
> bird> show protocols all gw_085ea85_euwest2
> Name   Proto  Table  State  Since Info
> gw_085ea85_euwest2 BGP---up 2023-03-03 16:33:43
>  Established
>   BGP state:  Established
> # ...
>   Channel ipv6
> State:  UP
> Table:  master6
> Preference: 100
> Input filter:   GATEWAY_IMPORT_v6
> Output filter:  GATEWAY_EXPORT_v6
> Routes: 2 imported, 2 exported, 1 preferred
> Route change stats: received   rejected   filteredignored
> accepted
>   Import updates:  3  0  1  0
>  2
>   Import withdraws:0  0---  0
>  0
>   Export updates:109  5 96---
>  8
>   Export withdraws:2---------
>  2
> BGP Next hop:   fdff::4:2
>   Channel ipv4
> State:  UP
> Table:  master4
> Preference: 100
> Input filter:   GATEWAY_IMPORT_v4
> Output filter:  GATEWAY_EXPORT_v4
> Routes: 12 imported, 1 exported, 0 preferred
> Route change stats: received   rejected   filteredignored
> accepted
>   Import updates: 12  0  0  0
> 12
>   Import withdraws:0  0---  0
>  0
>   Export updates: 39  4 31---
>  4
>   Export withdraws:0---------
>  1
> BGP Next hop:   fdff::4:2
> ```
>
> Note this is still on 2.0.7.  We've bumped some hosts to 2.0.10, but as
> indicated in the previous message, just a simple restart clears this issue
> from occurring.  We've enabled the export table config on both a 2.0.7 and
> a 2.0.10 host, to be able to possibly spot if this reoccurs on the 2.0.10
> host as well after a period. An example host on 2.0.7 showing this
> behaviour has been up for ~2 weeks. The box upgraded to 2.0.10 has had BIRD
> running for just ~16 hours at this point and is not yet showing any issues.
>
> On Thu, Mar 2, 2023 at 4:07 PM Hugo Slabbert <
> hugo.slabb...@menlosecurity.com> wrote:
>
>> A slight update on this:
>>
>> 3f477ccb
>> 
>> does appear to be in 2.0.7, which we're running, so if that's the issue
>> that may not be the problem.
>>
>> This looked to be successful initially when upgrading to 2.0.10. But, I
>> then checked a box that was still running 2.0.7 and where we could repro
>> it. I simply restarted bird there, and then could no longer repro it.
>>
>> So, just restarting bird at 2.0.7 was sufficient to clear the problem, at
>> least temporarily, and the bump to 2.0.10 then wasn't a clear test, given
>> that's obviously a fresh instance of bird running.
>>
>> We'll try to validate if the problem eventually returns on the 2.0.7
>> box(es) after a restart, and if it does *not* return on the 2.0.10
>> instance, but we 

Re: iBGP RR IPv6 link-local next-hop not kept

[Alexander Zubkov via Bird-users]

Hi,

As far as I remember, you can set in your income filter the interface, then
the gateway (in that order) to force the interface you want.

On Wed, Mar 1, 2023, 02:18 Mirai Azayaka  wrote:

> Wow, thank you so much! Setting bgp_next_hop = gw; works for me! (yeah
> I was worried that because link-local address is interface-dependent,
> my router wouldn't be able to know the interface. It seems my router
> (also running bird) chooses the same interface as the BGP session,
> which is what I want.
>
> On Tue, Feb 28, 2023 at 5:32 PM Ondrej Zajicek 
> wrote:
> >
> > On Tue, Feb 28, 2023 at 02:57:54PM -0500, Mirai Azayaka wrote:
> > > Hello,
> > >
> > > I am trying to send routes from my DHCPv6 prefix delegation server to
> > > my router using iBGP. Those delegated prefix routes on the DHCPv6
> > > server are installed in its kernel table, such as 2001:db8:db8::/56
> > > via . I want to pass this information to my
> > > router, but what the router receive is always 2001:db8:db8::/56 via
> > > . Why would next-hop change
> > > if it's iBGP?
> >
> > Hello
> >
> > Because link-local address is not resolvable through IGP routing table
> > then it does not really make sense to keep it when propagating through
> > IBGP.
> >
> > I.e., the regular next-hop is valid through the whole local AS, so we can
> > pass it unmodified through IBGP, but link-local next-hop is valid only on
> > a specific link.
> >
> > Note that BIRD almost always keep bgp_next_hop attribute when it is set
> > manually in the export filter, so if you use something like:
> >
> >   bgp_next_hop = gw;
> >
> > in prefix_delegation export filter, it should keep the value, even if it
> > is link-local.
> >
> > --
> > 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: Binding to some interfaces only for multihop bgp

[Alexander Zubkov via Bird-users]

Hi,

I doubt that strict bind option is incompatible with multihop. Do you have
some problems with it?

On Sun, Feb 19, 2023 at 4:17 PM Sebastian Hahn 
wrote:

> Hi,
>
> I would like bird to bind to some interfaces only, but use some multihop
> neighbours. Is there any easy way to achieve such a configuration? The
> strict bind option is incompatible with multihop, and I haven't seen
> anything where i can give a positive or negative list of interfaces to
> bind to / not to bind to.
>
> Thanks
> Sebastian
>

Re: BGP Route Aggregation - latest status ???

[Alexander Zubkov via Bird-users]

Hi,

With current bird's abilities you can try something like this (with correct
IPs of course):

protocol static aggr1 {
ipv4 { table master4; }
route 103.1035.59.0/24 recursive 103.1035.59.0;
route 103.1035.59.0/24 recursive 103.1035.59.1;
...
route 103.1035.59.0/24 recursive 103.1035.59.255;
}
filter export1 {
if dest = RDT_UNREACHABLE then reject;
if net ~ [ 103.1035.59.0/24{25,32} ] then reject;
...
}

And if you need to add some attributes (communities, etc.) than you need to
add some filter to the routes in the static protocol aggr1. You cannot
"inherit" attributes from more specific routes.

On Sat, Jan 28, 2023 at 2:35 AM Foo Weng Chan  wrote:

> Hi All,
>
>
>
> I’m using latest BIRD 2.0.12 but still not seeing availability of *BGP
> Route Aggregation* feature.
>
>
>
> May I know any update on this feature since the most recent post I can
> find per below :
>
> https://bird.network.cz/pipermail/bird-users/2021-February/015203.html
>
>
>
> My setup has a BGP border router receives multiple /32 prefixes from few
> internal IBGP peers. When advertise it our to EBGP peers, I need to
> aggregate it into a single /24 prefix as the upstream ISP does not accept
> any prefix smaller than /24. Also, when all IBGP peer stop announcing /32
> prefixes, I shall stop announcing /24 prefix to EBGP as well.
>
>
>
> Basically this is exactly what Cisco IOS router do with the following BGP
> command :
>
>
>
> aggregate-address 103.1035.59.0 255.255.255.0 summary-only
>
>
>
>
>
> Is that anyway to implement the above with BIRD ?
>
>
>
> Thanks & rgds,
>
> Chan
>
>
>
>
>

Re: [PATCH] feature to keep protocol's state while configuring

[Alexander Zubkov via Bird-users]

Further update. Do not write to the file the states of dynamic protocols as
it does not have much sence.

On Fri, Jan 27, 2023 at 2:53 AM Alexander Zubkov  wrote:

> Updated the patch for keeping state in the file. Moved the read/write
> functions to sysdep/unix/main.c and made better parsing. So it is not a
> draft anymore, but something more or less "stable". I can add documentation
> patch in case there is interest to include that into upstream.
>
> On Tue, Jan 24, 2023 at 8:03 AM Ondrej Zajicek 
> wrote:
>
>> On Mon, Jan 23, 2023 at 03:19:43AM +0100, Alexander Zubkov wrote:
>> > Hello,
>> >
>> > Not sure if those are forgotten or are unwanted modifications. Please
>> let
>> > me know.
>> >
>> > And I also have another idea regarding the subject. The idea is to
>> > configure the file where bird will keep the states of the protocols (I
>> mean
>> > enabled/disabled states). Then during loading the configuration it
>> alters
>> > the states to reflect the saved ones. So the states are persistent
>> during
>> > reconfiguration and also during restart of a daemon. The draft patch is
>> > attached. Please take a look.
>>
>> Hello
>>
>> Forgot about it, will check 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."
>>
>
commit 51272e90d6867a0a5604e13d7b1d6388249e89ef
Author: Alexander Zubkov 
Date:   Sun Jan 29 11:39:56 2023 +0100

Config: define file for keeping persistent protocol states

Persist protocols enabled/disabled states by keeping them in a file, if
its name is defined in the config file. Upon loading the config file
the states of the protocols are updated according to the file. The file
is rewritten when some protocol is enabled/disabled by CLI. The state of
dynamic protocols is not saved.

diff --git a/conf/conf.c b/conf/conf.c
index 4e31de29..da42a78a 100644
--- a/conf/conf.c
+++ b/conf/conf.c
@@ -287,6 +287,8 @@ config_do_commit(struct config *c, int type)
   if (old_config)
 old_config->obstacle_count++;
 
+  DBG("proto_states_read\n");
+  proto_states_read(c);
   DBG("filter_commit\n");
   filter_commit(c, old_config);
   DBG("sysdep_commit\n");
diff --git a/conf/conf.h b/conf/conf.h
index b409750e..ecbe9408 100644
--- a/conf/conf.h
+++ b/conf/conf.h
@@ -28,6 +28,7 @@ struct config {
 
   int mrtdump_file;			/* Configured MRTDump file (sysdep, fd in unix) */
   const char *syslog_name;		/* Name used for syslog (NULL -> no syslog) */
+  void *states_file;			/* Protocol states file (sysdep, FILE *) */
   struct rtable_config *def_tables[NET_MAX]; /* Default routing tables for each network */
   struct iface_patt *router_id_from;	/* Configured list of router ID iface patterns */
 
diff --git a/nest/proto.c b/nest/proto.c
index 885a0b75..4e70f585 100644
--- a/nest/proto.c
+++ b/nest/proto.c
@@ -21,6 +21,7 @@
 #include "nest/cli.h"
 #include "filter/filter.h"
 #include "filter/f-inst.h"
+#include "sysdep/unix/unix.h"
 
 pool *proto_pool;
 list STATIC_LIST_INIT(proto_list);
@@ -2105,6 +2106,7 @@ proto_cmd_disable(struct proto *p, uintptr_t arg, int cnt UNUSED)
   p->down_code = PDC_CMD_DISABLE;
   proto_set_message(p, (char *) arg, -1);
   proto_rethink_goal(p);
+  proto_states_write(p);
   cli_msg(-9, "%s: disabled", p->name);
 }
 
@@ -2121,6 +2123,7 @@ proto_cmd_enable(struct proto *p, uintptr_t arg, int cnt UNUSED)
   p->disabled = 0;
   proto_set_message(p, (char *) arg, -1);
   proto_rethink_goal(p);
+  proto_states_write(p);
   cli_msg(-11, "%s: enabled", p->name);
 }
 
diff --git a/sysdep/unix/config.Y b/sysdep/unix/config.Y
index 5c4b5bef..cc7813c8 100644
--- a/sysdep/unix/config.Y
+++ b/sysdep/unix/config.Y
@@ -101,6 +101,20 @@ mrtdump_base:
  ;
 
 
+conf: keep_states ;
+
+keep_states: KEEP STATES text ';' {
+if (!parse_and_exit)
+{
+  if (new_config->states_file) cf_error("Repeating definition of protocol states file");
+  struct rfile *f = rf_open(new_config->pool, $3, "a+");
+  if (!f) cf_error("Unable to open protocol states file '%s': %m", $3);
+  new_config->states_file = rf_file(f);
+}
+  }
+;
+
+
 conf: debug_unix ;
 
 debug_unix:
diff --git a/sysdep/unix/main.c b/sysdep/unix/main.c
index 627d7a4a..ba688cdf 100644
--- a/sysdep/unix/main.c
+++ b/sysdep/unix/main.c
@@ -389,6 +389,89 @@ cmd_reconfig_status(void)
   cli_msg(0, "");
 }
 
+/*
+ *	Protocol states reading/writing
+ */
+
+void
+proto_states_read(struct config *c)
+{
+ 

Re: [PATCH] feature to keep protocol's state while configuring

[Alexander Zubkov via Bird-users]

Updated the patch for keeping state in the file. Moved the read/write
functions to sysdep/unix/main.c and made better parsing. So it is not a
draft anymore, but something more or less "stable". I can add documentation
patch in case there is interest to include that into upstream.

On Tue, Jan 24, 2023 at 8:03 AM Ondrej Zajicek 
wrote:

> On Mon, Jan 23, 2023 at 03:19:43AM +0100, Alexander Zubkov wrote:
> > Hello,
> >
> > Not sure if those are forgotten or are unwanted modifications. Please let
> > me know.
> >
> > And I also have another idea regarding the subject. The idea is to
> > configure the file where bird will keep the states of the protocols (I
> mean
> > enabled/disabled states). Then during loading the configuration it alters
> > the states to reflect the saved ones. So the states are persistent during
> > reconfiguration and also during restart of a daemon. The draft patch is
> > attached. Please take a look.
>
> Hello
>
> Forgot about it, will check 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."
>
commit 65a25826c9b8678cbd97b4229714d5145b47c839
Author: Alexander Zubkov 
Date:   Fri Jan 27 02:19:39 2023 +0100

Config: define file for keeping persistent protocol states

Persist protocols enabled/disabled states by keeping them in a file, if
its name is defined in the config file. Upon loading the config file
the states of the protocols are updated according to the file. The file
is rewritten when some protocol is enabled/disabled by CLI.

diff --git a/conf/conf.c b/conf/conf.c
index 4e31de29..da42a78a 100644
--- a/conf/conf.c
+++ b/conf/conf.c
@@ -287,6 +287,8 @@ config_do_commit(struct config *c, int type)
   if (old_config)
 old_config->obstacle_count++;
 
+  DBG("proto_states_read\n");
+  proto_states_read(c);
   DBG("filter_commit\n");
   filter_commit(c, old_config);
   DBG("sysdep_commit\n");
diff --git a/conf/conf.h b/conf/conf.h
index b409750e..ecbe9408 100644
--- a/conf/conf.h
+++ b/conf/conf.h
@@ -28,6 +28,7 @@ struct config {
 
   int mrtdump_file;			/* Configured MRTDump file (sysdep, fd in unix) */
   const char *syslog_name;		/* Name used for syslog (NULL -> no syslog) */
+  void *states_file;			/* Protocol states file (sysdep, FILE *) */
   struct rtable_config *def_tables[NET_MAX]; /* Default routing tables for each network */
   struct iface_patt *router_id_from;	/* Configured list of router ID iface patterns */
 
diff --git a/nest/proto.c b/nest/proto.c
index 885a0b75..4e70f585 100644
--- a/nest/proto.c
+++ b/nest/proto.c
@@ -21,6 +21,7 @@
 #include "nest/cli.h"
 #include "filter/filter.h"
 #include "filter/f-inst.h"
+#include "sysdep/unix/unix.h"
 
 pool *proto_pool;
 list STATIC_LIST_INIT(proto_list);
@@ -2105,6 +2106,7 @@ proto_cmd_disable(struct proto *p, uintptr_t arg, int cnt UNUSED)
   p->down_code = PDC_CMD_DISABLE;
   proto_set_message(p, (char *) arg, -1);
   proto_rethink_goal(p);
+  proto_states_write(p);
   cli_msg(-9, "%s: disabled", p->name);
 }
 
@@ -2121,6 +2123,7 @@ proto_cmd_enable(struct proto *p, uintptr_t arg, int cnt UNUSED)
   p->disabled = 0;
   proto_set_message(p, (char *) arg, -1);
   proto_rethink_goal(p);
+  proto_states_write(p);
   cli_msg(-11, "%s: enabled", p->name);
 }
 
diff --git a/sysdep/unix/config.Y b/sysdep/unix/config.Y
index 5c4b5bef..cc7813c8 100644
--- a/sysdep/unix/config.Y
+++ b/sysdep/unix/config.Y
@@ -101,6 +101,20 @@ mrtdump_base:
  ;
 
 
+conf: keep_states ;
+
+keep_states: KEEP STATES text ';' {
+if (!parse_and_exit)
+{
+  if (new_config->states_file) cf_error("Repeating definition of protocol states file");
+  struct rfile *f = rf_open(new_config->pool, $3, "a+");
+  if (!f) cf_error("Unable to open protocol states file '%s': %m", $3);
+  new_config->states_file = rf_file(f);
+}
+  }
+;
+
+
 conf: debug_unix ;
 
 debug_unix:
diff --git a/sysdep/unix/main.c b/sysdep/unix/main.c
index 627d7a4a..c4a8ed42 100644
--- a/sysdep/unix/main.c
+++ b/sysdep/unix/main.c
@@ -389,6 +389,83 @@ cmd_reconfig_status(void)
   cli_msg(0, "");
 }
 
+/*
+ *	Protocol states reading/writing
+ */
+
+void
+proto_states_read(struct config *c)
+{
+  FILE *f = c->states_file;
+  if (!f) return;
+
+  log(L_INFO "Reading protocol states file");
+
+  /* Move to the start of the file */
+  fseek(f, 0, SEEK_SET);
+  fflush(f);
+
+  const char *fmt = "%" XSTR1(SYM_MAX_LEN) "s %u";
+  char buf[512];
+
+  /* Use longer buffer to check for too long names */
+  char name[SYM_MAX_LEN + 1];
+ 

SYM_MAX_LEN

[Alexander Zubkov via Bird-users]

Hi,

If I do not mistake, cf_new_symbol() has incorrect check of symbol length.
In other places where SYM_MAX_LEN is used, it is expected that leading zero
is counted in it. But the check in cf_new_symbol() allows symbol length
equal to SYM_MAX_LEN. This does not cause a problem (as I unederstand),
because the space is allocated anyway and this string is not copied later
to fixed size arrays. I attached a patch with the fix, there is also a
couple of bsprintf replaced with safer bsnprintf calls.
commit 9ecf13ebd196d06ce03b7c3fc84d70193cc4cfe9
Author: Alexander Zubkov 
Date:   Fri Jan 27 02:35:16 2023 +0100

fix symbol length check, use safer bsnprintf

diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index ceedee8a..65b5e941 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -582,7 +582,7 @@ cf_new_symbol(const byte *c)
   struct symbol *s;
 
   uint l = strlen(c);
-  if (l > SYM_MAX_LEN)
+  if (l >= SYM_MAX_LEN)
 cf_error("Symbol too long");
 
   cf_swap_soft_scope();
@@ -676,7 +676,7 @@ cf_default_name(char *template, int *counter)
 
   for(;;)
 {
-  bsprintf(buf, template, ++(*counter));
+  bsnprintf(buf, sizeof(buf), template, ++(*counter));
   s = cf_get_symbol(buf);
   if (s->class == SYM_VOID)
 	return s;
diff --git a/proto/bgp/bgp.c b/proto/bgp/bgp.c
index 2e442e16..5b0894b3 100644
--- a/proto/bgp/bgp.c
+++ b/proto/bgp/bgp.c
@@ -491,7 +491,8 @@ bgp_spawn(struct bgp_proto *pp, ip_addr remote_ip)
   struct symbol *sym;
   char fmt[SYM_MAX_LEN];
 
-  bsprintf(fmt, "%s%%0%dd", pp->cf->dynamic_name, pp->cf->dynamic_name_digits);
+  /* dynamic_name and _digits values are limited in the config parser */
+  bsnprintf(fmt, sizeof(fmt), "%s%%0%dd", pp->cf->dynamic_name, pp->cf->dynamic_name_digits);
 
   /* This is hack, we would like to share config, but we need to copy it now */
   new_config = config;

Re: rename symbols

[Alexander Zubkov via Bird-users]

Hi,

I did some more experimenting with making aliases from cli. As I
understand, cli has its own "config" structure and memory pool, where its
symbols are allocated. So I need to copy it to the current config, but I
did not find suitable functions for doing that. And I make a copy for
cf_new_symbol. Not sure though, that I did everything right. It would be
great if someone looked at it and gave me some advice.

I split the modifications into two parts: creating aliases in the config
and then creating it in the cli. I think this idea with aliases is not that
ugly. The solution is quite minimal and does not affect anybody who do not
touch aliases. So if somebody wants to be able to do renaming in their
setup - feel free to use/test the patches. And maybe in such form it would
be meaningful to include it into the upstream version, as it is not that
ugly anymore (at least from my point of view). :)

I also not sure wether I need to copy the "scope" field from the reference
symbol or keep it from aliased. I originally kept if from alias symbol and
it worked too, at least with "config"-aliases. Now I'm copying it from the
reference symbol and it also works.

On Tue, Jan 24, 2023 at 9:42 AM Alexander Zubkov  wrote:

>
>
> On Tue, Jan 24, 2023 at 8:12 AM Alexander Zubkov  wrote:
>
>>
>>
>> On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek 
>> wrote:
>>
>>> On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
>>> > >Hello
>>> > >
>>> > >I thing that the most elegant way how to handle renaming of objects
>>> > >during reconfiguration is to allow multiple names / aliases. There
>>> could
>>> > >be be more symbols pointing to given object (but the object points
>>> back
>>> > >to its primary name).
>>> > >
>>> > >Reconfiguration to rename objects could be done in two steps - in the
>>> > >first step, the user would add alias for the new name.  In the second
>>> step,
>>> > >the old name would be removed.
>>> >
>>> > I think this keeps the problem with protocol restart when the renaming
>>> > of "base name" is done.
>>>
>>> The primary problem of renaming is matching existing objects with
>>> definitions from the new config. If that can be done (by finding
>>> existing objects through aliases), it is just a reconfiguration of
>>> object property, like any other. I.e. implementation problem instead
>>> of conceptual problem.
>>>
>>>
>> Adding aliases is an interesting option. But for example now in
>> protos_commit() it uses WALK_LIST(oc, old->protos), so it walks around old
>> protos first and then searches for a new ones. So it is not enough to add
>> another name pointing to the protocol, you need to search for protocol name
>> and also its aliases in the new protocols, or "invert" walking the lists in
>> all such places.
>> Probably might work if it is done in several steps:
>> 1) name1
>> 2) name1 + alias name2
>> 3) name2 + alias name1
>> 4) name2
>>
>
> I've checked such modifications (in attached patch), and it seems to work
> too. The transition with those several steps goes without protocol
> interruption for changing the names of protocols and tables. The patch adds
> the config statement:
> link  to 
> It makes "alias" to reference the same entity as "symbol".
>
> In this case the transition process is longer, but less intervention in
> the code is required and it may be less ugly. As a plus, the transition can
> be done without additional CLI commands, only with a series of configs. On
> the other hand you can not do aliases CLI-only for the transition, you need
> them to be present in the new config while it is loading. You can do it in
> CLI for step 1->2, but for 2->3 it will not work. Renaming, though, needed
> intervention in the config too, to extend the symbol buffers.
>
> I also tried to also do a CLI command for aliasing. But it does not work
> in this variant, the new symbol does not appear in the table. Probably it
> is cleaned up after the command finishes. It is strange, because when I
> tried the same for "rename" version like that:
> CF_CLI(RENAME, CF_SYM_KNOWN CF_SYM_UNDEFINED,  , [[Rename
> symbol]])
> Then I just copied the name from the undefined symbol to the known symbol.
> And after that I saw multiple occurence of the name in "show symbols". So I
> thought the undefined one was left in the table. But now when I run "link"
> in the cli, I do not see the new symbol in the table afterwards.

Re: rename symbols

[Alexander Zubkov via Bird-users]

On Tue, Jan 24, 2023 at 8:12 AM Alexander Zubkov  wrote:

>
>
> On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek 
> wrote:
>
>> On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
>> > >Hello
>> > >
>> > >I thing that the most elegant way how to handle renaming of objects
>> > >during reconfiguration is to allow multiple names / aliases. There
>> could
>> > >be be more symbols pointing to given object (but the object points back
>> > >to its primary name).
>> > >
>> > >Reconfiguration to rename objects could be done in two steps - in the
>> > >first step, the user would add alias for the new name.  In the second
>> step,
>> > >the old name would be removed.
>> >
>> > I think this keeps the problem with protocol restart when the renaming
>> > of "base name" is done.
>>
>> The primary problem of renaming is matching existing objects with
>> definitions from the new config. If that can be done (by finding
>> existing objects through aliases), it is just a reconfiguration of
>> object property, like any other. I.e. implementation problem instead
>> of conceptual problem.
>>
>>
> Adding aliases is an interesting option. But for example now in
> protos_commit() it uses WALK_LIST(oc, old->protos), so it walks around old
> protos first and then searches for a new ones. So it is not enough to add
> another name pointing to the protocol, you need to search for protocol name
> and also its aliases in the new protocols, or "invert" walking the lists in
> all such places.
> Probably might work if it is done in several steps:
> 1) name1
> 2) name1 + alias name2
> 3) name2 + alias name1
> 4) name2
>

I've checked such modifications (in attached patch), and it seems to work
too. The transition with those several steps goes without protocol
interruption for changing the names of protocols and tables. The patch adds
the config statement:
link  to 
It makes "alias" to reference the same entity as "symbol".

In this case the transition process is longer, but less intervention in the
code is required and it may be less ugly. As a plus, the transition can be
done without additional CLI commands, only with a series of configs. On the
other hand you can not do aliases CLI-only for the transition, you need
them to be present in the new config while it is loading. You can do it in
CLI for step 1->2, but for 2->3 it will not work. Renaming, though, needed
intervention in the config too, to extend the symbol buffers.

I also tried to also do a CLI command for aliasing. But it does not work in
this variant, the new symbol does not appear in the table. Probably it is
cleaned up after the command finishes. It is strange, because when I tried
the same for "rename" version like that:
CF_CLI(RENAME, CF_SYM_KNOWN CF_SYM_UNDEFINED,  , [[Rename
symbol]])
Then I just copied the name from the undefined symbol to the known symbol.
And after that I saw multiple occurence of the name in "show symbols". So I
thought the undefined one was left in the table. But now when I run "link"
in the cli, I do not see the new symbol in the table afterwards.
diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index ceedee8a..6508a9cb 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -667,6 +667,16 @@ cf_localize_symbol(struct symbol *sym)
   return cf_new_symbol(sym->name);
 }
 
+void
+cf_alias_symbol(struct symbol *sym, struct symbol *alias)
+{
+  struct symbol tmp = *sym;
+  tmp.n = alias->n;
+  tmp.next = alias->next;
+  tmp.scope = alias->scope;
+  *alias = tmp;
+}
+
 struct symbol *
 cf_default_name(char *template, int *counter)
 {
diff --git a/conf/conf.h b/conf/conf.h
index b409750e..d7796c5c 100644
--- a/conf/conf.h
+++ b/conf/conf.h
@@ -192,6 +192,7 @@ struct symbol *cf_find_symbol(const struct config *cfg, const byte *c);
 struct symbol *cf_get_symbol(const byte *c);
 struct symbol *cf_default_name(char *template, int *counter);
 struct symbol *cf_localize_symbol(struct symbol *sym);
+void cf_alias_symbol(struct symbol *sym, struct symbol *alias);
 
 static inline int cf_symbol_is_local(struct symbol *sym)
 { return (sym->scope == conf_this_scope) && !conf_this_scope->soft_scopes; }
diff --git a/nest/cmds.c b/nest/cmds.c
index bcc8d6c2..a4536100 100644
--- a/nest/cmds.c
+++ b/nest/cmds.c
@@ -142,3 +142,10 @@ cmd_eval(const struct f_line *expr)
 
   cli_msg(23, "%s", buf.start);
 }
+
+void
+cmd_alias_symbol(struct symbol *sym, struct symbol *alias)
+{
+  cf_alias_symbol(sym, alias);
+  cli_msg(10, "ok");
+}
diff --git a/nest/cmds.h b/nest/cmds.h
index 194a9d7f..426501a1 100644
--- a/nest/cmds.h
+++ b/nest/cmds.h
@@ -19,3 +19,5 @@ void cmd_show_memory(void);

Re: Multiple ebgp neighbours to the same peer

[Alexander Zubkov via Bird-users]

On Mon, Jan 23, 2023 at 3:17 PM Alexander Zubkov  wrote:

>
>
> On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek 
> wrote:
>
>> On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
>> > Hi all,
>> >
>> > A quick try to fix the problem. But I'm not sure in complete correctness
>> > though.
>>
>> Hi
>>
>> That looks more-or-less OK, will merge.
>>
>> > -ipa_equal(x->addr, y->addr);
>> > +ipa_equal(x->addr, y->addr) &&
>> > +ipa_equal(x->addr2, y->addr2);
>>
>> I think undefined addr2 should work like wildcard, i.e. the condition
>> should be:
>>
>>
> Maybe. I do not know well how this lock works. If different lock keys can
> affect another. And in this case it is probably better to fix "local" role
> for that second address and reflect it in its name.
>

I think even better to call this wildcard_addr, for example. So if
something else needs this wildcard feature, it is clear which addr to use
in the lock object.


>
>
>>  ipa_equal(x->addr, y->addr) &&
>>  (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2,
>> y->addr2));
>>
>> (Undefined local ip will be resolved to some ip and may collide with
>> defined ones.)
>>
>> --
>> 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: rename symbols

[Alexander Zubkov via Bird-users]

On Tue, Jan 24, 2023 at 7:05 AM Maria Matejka via Bird-users <
bird-users@network.cz> wrote:

> Hello!
>
> > For example I may want to refactor the naming scheme for
> > protocols/tables in my bird config. But when I apply the new config with
> > the new names, such renamed protocols will be recreated or restarted,
> > which may be undesired. So if I could rename protocols/tables in advance
> > and then load the new config, I can hope than no changes would be found
> > and the there would be no interruptions.
>
> What I was thinking about some time ago, was not this kind of "renaming
> from CLI" but a special clause "renamed XYZ to ABC" which could be put
> at the end (!) of the new config. This would solve the problem with
> rewriting the symbol in-place which is ugly.
>

Yes, that is ugly and I would not run the "renamed" configuration long,
just for the transition. But it is the minimal intervention I figured out.
I was thinking about adding new symbols instead of changing the name
in-place, but there are too many places where you need to update the
pointers to the new names. And still you need to do something with the old
symbol. When I rename them in place, it updates the names automatically, as
they all point to the buffer inside symbol, as far as I understand.


>
> Yet there are problems (mostly in v3) where e.g. the protocol name is
> pre-formatted into other strings, effectively forcing us to walk through
> the code and find all these cases while renaming. We don't want BIRD to
> errorneously log about a protocol with its old name.
>

Could you explain it more, when will you need to change something more in
the code in my or your variant (with renamed statement)? As I udnerstand,
in my variant, it should not be possible to log the old name, because I
replace the string in-place. Only if it was copied somewhere. Anyway after
loading the new config it should go away. In your variant too, if you do
the second step and load the final config without "renamed" than there also
should not be the old names. I don't think we should care much about
logging during the transition.


>
> All in all, I'd not opposed to this idea, yet from my current POV, the
> changes needed are too high for now to have it a single patch or so.
>
> Thank you for your suggestion!
>
> Maria
>

Re: rename symbols

[Alexander Zubkov via Bird-users]

On Tue, Jan 24, 2023 at 7:59 AM Ondrej Zajicek 
wrote:

> On Tue, Jan 24, 2023 at 07:44:47AM +0100, Maria Matejka wrote:
> > >Hello
> > >
> > >I thing that the most elegant way how to handle renaming of objects
> > >during reconfiguration is to allow multiple names / aliases. There could
> > >be be more symbols pointing to given object (but the object points back
> > >to its primary name).
> > >
> > >Reconfiguration to rename objects could be done in two steps - in the
> > >first step, the user would add alias for the new name.  In the second
> step,
> > >the old name would be removed.
> >
> > I think this keeps the problem with protocol restart when the renaming
> > of "base name" is done.
>
> The primary problem of renaming is matching existing objects with
> definitions from the new config. If that can be done (by finding
> existing objects through aliases), it is just a reconfiguration of
> object property, like any other. I.e. implementation problem instead
> of conceptual problem.
>
>
Adding aliases is an interesting option. But for example now in
protos_commit() it uses WALK_LIST(oc, old->protos), so it walks around old
protos first and then searches for a new ones. So it is not enough to add
another name pointing to the protocol, you need to search for protocol name
and also its aliases in the new protocols, or "invert" walking the lists in
all such places.
Probably might work if it is done in several steps:
1) name1
2) name1 + alias name2
3) name2 + alias name1
4) name2

rename symbols

[Alexander Zubkov via Bird-users]

Hi all,

Some weird idea. I'm not sure it needs to be in the mainstream version, but
somebody might find it helpful.

For example I may want to refactor the naming scheme for protocols/tables
in my bird config. But when I apply the new config with the new names, such
renamed protocols will be recreated or restarted, which may be undesired.
So if I could rename protocols/tables in advance and then load the new
config, I can hope than no changes would be found and the there would be no
interruptions.

The attached patch solves the problem, by introducing such changes:

To rename some symbol one can use cli command:
rename  ""
The new name is in the form of the string, because symbol form requires
symbol to be created. I tried to use CF_SYM_UNDEFINED for the second
parameter. It works somehow, but leaves duplicate symbols in the table. If
there is some way to clean them after it, it could be more visually
pleasing option.

The other problem is that a symbol has the fixed buffer for the name bound
by its length. And one would not be able to rename it to a new name that is
longer. But to overcome that, I add a field to a symbol to remember the
length of the allocated buffer and allow the buffer to be bigger. This can
be controlled by config option:
symbols min 
Which sets minum length that will fit the buffer. But as symbols are
allocated while reading the config, you need to place this configuration
option to the top of your config, i.e. before all the symbols you want to
rename.

So you can load the old config with the old names and this option added, it
will allocate bigger buffers for the symbols. Then you can rename your
symbols to the new ones. And finally load the new config with the new names.

Of course you need the bird version with this patch applied in advace to do
the trick. :)
diff --git a/conf/cf-lex.l b/conf/cf-lex.l
index ceedee8a..92d81989 100644
--- a/conf/cf-lex.l
+++ b/conf/cf-lex.l
@@ -584,11 +584,13 @@ cf_new_symbol(const byte *c)
   uint l = strlen(c);
   if (l > SYM_MAX_LEN)
 cf_error("Symbol too long");
+  if (l < new_config->symbols_min)
+l = new_config->symbols_min;
 
   cf_swap_soft_scope();
 
   s = cfg_allocz(sizeof(struct symbol) + l + 1);
-  *s = (struct symbol) { .scope = conf_this_scope, .class = SYM_VOID, };
+  *s = (struct symbol) { .scope = conf_this_scope, .class = SYM_VOID, .len = l, };
   strcpy(s->name, c);
 
   if (!new_config->sym_hash.data)
@@ -667,6 +669,23 @@ cf_localize_symbol(struct symbol *sym)
   return cf_new_symbol(sym->name);
 }
 
+int
+cf_rename_symbol(struct symbol *sym, const char *name)
+{
+  if (sym->len < strlen(name))
+return 1;
+
+  if (cf_find_symbol(config, name))
+return 1;
+
+  strcpy(sym->name, name);
+
+  HASH_REMOVE2(config->sym_hash, SYM, config->pool, sym);
+  HASH_INSERT2(config->sym_hash, SYM, config->pool, sym);
+
+  return 0;
+}
+
 struct symbol *
 cf_default_name(char *template, int *counter)
 {
diff --git a/conf/conf.h b/conf/conf.h
index b409750e..581ced71 100644
--- a/conf/conf.h
+++ b/conf/conf.h
@@ -26,6 +26,8 @@ struct config {
   list tests;/* Configured unit tests (f_bt_test_suite) */
   list symbols;/* Configured symbols in config order */
 
+  int symbols_min;			/* Mimimal name length to fit symbol buffer */
+
   int mrtdump_file;			/* Configured MRTDump file (sysdep, fd in unix) */
   const char *syslog_name;		/* Name used for syslog (NULL -> no syslog) */
   struct rtable_config *def_tables[NET_MAX]; /* Default routing tables for each network */
@@ -116,6 +118,7 @@ struct symbol {
   struct sym_scope *scope;
   int class;/* SYM_* */
   uint flags;/* SYM_FLAG_* */
+  int len;/* Name buffer length */
 
   union {
 struct proto_config *proto;		/* For SYM_PROTO and SYM_TEMPLATE */
@@ -192,6 +195,7 @@ struct symbol *cf_find_symbol(const struct config *cfg, const byte *c);
 struct symbol *cf_get_symbol(const byte *c);
 struct symbol *cf_default_name(char *template, int *counter);
 struct symbol *cf_localize_symbol(struct symbol *sym);
+int cf_rename_symbol(struct symbol *sym, const char *name);
 
 static inline int cf_symbol_is_local(struct symbol *sym)
 { return (sym->scope == conf_this_scope) && !conf_this_scope->soft_scopes; }
diff --git a/nest/cmds.c b/nest/cmds.c
index bcc8d6c2..4dea7ebe 100644
--- a/nest/cmds.c
+++ b/nest/cmds.c
@@ -142,3 +142,24 @@ cmd_eval(const struct f_line *expr)
 
   cli_msg(23, "%s", buf.start);
 }
+
+void
+cmd_rename(struct symbol *sym, const char *name)
+{
+  if (!sym->class)
+{
+  cli_msg(8010, "symbol is void");
+  return;
+}
+
+  if (cf_find_symbol(config, name))
+{
+  cli_msg(8010, "symbol name is taken");
+  return;
+}
+
+  if (cf_rename_symbol(sym, name))
+cli_msg(8010, "runtime error");
+  else
+cli_msg(10, "ok");
+}
diff --git a/nest/cmds.h b/nest/cmds.h
index 194a9d7f..f4440a16 100644
--- a/nest/cmds.h
+++ b/nest/cmds.h
@@ -19,3 +19,5 @@ void cmd_show_memory(void);
 
 struct f_line;
 void cmd_eval(const struct 

Re: Multiple ebgp neighbours to the same peer

[Alexander Zubkov via Bird-users]

On Mon, Jan 23, 2023 at 3:06 PM Ondrej Zajicek 
wrote:

> On Mon, Jan 23, 2023 at 12:40:30AM +0100, Alexander Zubkov wrote:
> > Hi all,
> >
> > A quick try to fix the problem. But I'm not sure in complete correctness
> > though.
>
> Hi
>
> That looks more-or-less OK, will merge.
>
> > -ipa_equal(x->addr, y->addr);
> > +ipa_equal(x->addr, y->addr) &&
> > +ipa_equal(x->addr2, y->addr2);
>
> I think undefined addr2 should work like wildcard, i.e. the condition
> should be:
>
>
Maybe. I do not know well how this lock works. If different lock keys can
affect another. And in this case it is probably better to fix "local" role
for that second address and reflect it in its name.


>  ipa_equal(x->addr, y->addr) &&
>  (ipa_zero(x->addr2) || ipa_zero(y->addr2) || ipa_equal(x->addr2,
> y->addr2));
>
> (Undefined local ip will be resolved to some ip and may collide with
> defined ones.)
>
> --
> 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: [PATCH] feature to keep protocol's state while configuring

[Alexander Zubkov via Bird-users]

Hello,

Not sure if those are forgotten or are unwanted modifications. Please let
me know.

And I also have another idea regarding the subject. The idea is to
configure the file where bird will keep the states of the protocols (I mean
enabled/disabled states). Then during loading the configuration it alters
the states to reflect the saved ones. So the states are persistent during
reconfiguration and also during restart of a daemon. The draft patch is
attached. Please take a look.

On Thu, Jun 30, 2022 at 3:44 PM Alexander Zubkov  wrote:

> Hi,
>
> Could we continue with these modifcations?
>
> On Mon, Jan 3, 2022 at 2:10 PM Alexander Zubkov  wrote:
> >
> > Hi,
> >
> > Lets resurrect this one too. Please check the series of pathces in the
> > attachment.
> > 1) Convert reconfigure type variables to bitmask.
> > 2) Add flag to keep running state
> > 3) Add support in CLI
> >
> > Only the states of protocols are kept with this flag now. Anyone
> > interested can add support of keeping other interesting runtime
> > states, like Ondrej suggested.
> >
> > On Sun, Feb 10, 2019 at 11:23 PM Thomás S. Bregolin 
> wrote:
> > >
> > > Nice!
> > >
> > > Ondrej,
> > >
> > > I disagree somewhat with your first response, unless I misunderstand
> it. I don't think it makes sense at all to persist a whole bunch of
> settings and still do a soft reconfiguration.
> > >
> > > There is a very good, non-remote use case to keep the session up on
> reconfigurations regardless of the 'disabled' option on startup.
> > >
> > > Would you be able to point us to the way forward?
> > >
> > > Cheers,
> > >
> > > Thomás
> > >
> > > On Sun, Feb 10, 2019, 19:05 Alexander Zubkov  > >>
> > >> Hi,
> > >>
> > >> I had almost the same idea in my original patch. But Ondrej have
> > >> slightly better ideas regarding this.
> > >>
> > >> On Sun, Feb 10, 2019 at 6:59 PM Thomás S. Bregolin <
> thoms...@gmail.com> wrote:
> > >> >
> > >> > My attempt was a bit more crude:
> > >> >
> > >> > diff --git a/nest/config.Y b/nest/config.Y
> > >> > index aef5ed46..829bf96c 100644
> > >> > --- a/nest/config.Y
> > >> > +++ b/nest/config.Y
> > >> > @@ -64,7 +64,7 @@ proto_postconfig(void)
> > >> >
> > >> >  CF_DECLS
> > >> >
> > >> > -CF_KEYWORDS(ROUTER, ID, PROTOCOL, TEMPLATE, PREFERENCE, DISABLED,
> DEBUG, ALL, OFF, DIRECT)
> > >> > +CF_KEYWORDS(ROUTER, ID, PROTOCOL, TEMPLATE, PREFERENCE, DISABLED,
> KEEP_STATE, DEBUG, ALL, OFF, DIRECT)
> > >> >  CF_KEYWORDS(INTERFACE, IMPORT, EXPORT, FILTER, NONE, VRF, TABLE,
> STATES, ROUTES, FILTERS)
> > >> >  CF_KEYWORDS(IPV4, IPV6, VPN4, VPN6, ROA4, ROA6, FLOW4, FLOW6,
> SADR, MPLS)
> > >> >  CF_KEYWORDS(RECEIVE, LIMIT, ACTION, WARN, BLOCK, RESTART, DISABLE,
> KEEP, FILTERED)
> > >> > @@ -205,6 +205,7 @@ proto_name:
> > >> >  proto_item:
> > >> > /* EMPTY */
> > >> >   | DISABLED bool { this_proto->disabled = $2; }
> > >> > + | KEEP_STATE bool { this_proto->keep_state = $2 }
> > >> >   | DEBUG debug_mask { this_proto->debug = $2; }
> > >> >   | MRTDUMP mrtdump_mask { this_proto->mrtdump = $2; }
> > >> >   | ROUTER ID idval { this_proto->router_id = $3; }
> > >> > diff --git a/nest/proto.c b/nest/proto.c
> > >> > index d4a333d0..397d6fb2 100644
> > >> > --- a/nest/proto.c
> > >> > +++ b/nest/proto.c
> > >> > @@ -984,6 +984,8 @@ protos_commit(struct config *new, struct config
> *old, int force_reconfig, int ty
> > >> >  if (! force_reconfig && proto_reconfigure(p, oc, nc, type))
> > >> >continue;
> > >> >
> > >> > +nc->disabled = nc->keep_state ? p->disabled : nc->disabled;
> > >> > +
> > >> >  /* Unsuccessful, we will restart it */
> > >> >  if (!p->disabled && !nc->disabled)
> > >> >log(L_INFO "Restarting protocol %s", p->name);
> > >> > diff --git a/nest/protocol.h b/nest/protocol.h
> > >> > index 6c04071b..d984b4c2 100644
> > >> > --- a/nest/protocol.h
> > >> > +++ b/nest/protocol.h
> > >> > @@ -118,6 +118,7 @@ struct p