Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
On Fri, Aug 25, 2023 at 04:20:04AM +0200, Alexander Zubkov wrote: > 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. I plan to add all keywords to kw_sym (through M4 macro) in some followup commit, so no need for manual definition. -- 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
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
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: hardware preference
Hoi I write a lot about (kernel and user space) routing performance on https://ipng.ch/s/articles/ including hardware and dataplane acceleration (with VPP and DPDK) on small (Fitlet2 or PCEngines), medium (Supermicro Xeon 1518D or Netgate 6100), and very large (Ryzen/Milan/Xeon Platinum) systems, from 100kpps and 1Gbit, all the way to 180Gbit/150Mpps. As a control plane, the choice of software be it Bird or FRR or OpenBGPd et al, is less relevant than your choice of kernel or dataplane acceleration. Please take a look and let me know what you think. Groet, Pim On Thu, 24 Aug 2023 at 19:33, Ömür Yavuz via Bird-users < bird-users@network.cz> wrote: > Hello community, I don't know if there is any obstacle for me to ask this > kind of question. Everything is fine in terms of software, but can I get a > hardware suggestion that millions of packages will pass through live with > the servant? Do you have experience with an intel cpu and chelsio t4 nic or > intel x5xx series? Which enterprise level devices can I use as hardware? > > > Ömür Yavuz > > -- Pim van Pelt PBVP1-RIPE - http://www.ipng.nl/
hardware preference
Hello community, I don't know if there is any obstacle for me to ask this kind of question. Everything is fine in terms of software, but can I get a hardware suggestion that millions of packages will pass through live with the servant? Do you have experience with an intel cpu and chelsio t4 nic or intel x5xx series? Which enterprise level devices can I use as hardware? Ömür Yavuz
Re: [PATCH] adding custom options in radv protocol, strict ipv6 regex
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. 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. 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. 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. -- 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 considers the VRF interface to be outside the VRF
On Tue, Jul 18, 2023 at 12:25:41PM +0200, Erin Shepherd wrote: > Bird only treats the interfaces enslaved to the VRF as part of the VRF, > but not the VRF virtual interface itself. This means that e.g. OSPF won't > pick up loopback addresses defined on the VRF interface itself. You have > to additionally add a dummy interfaces with the IPs attached, which seems > to cause some confusion of its own on the kernel side. > > Ideally the VRF interfaces would be considered to be in the VRF. > > I've attached a patch which fixes this; I don't think the design is quite > right, and its possible I introduced some bugs, but in testing it seems to > work fine Hi Sorry for late answer, i somehow missed/forgot your mail. You are right, VRF interfaces are supposed to be inside respective VRFs. One can see that from e.g. 'local' routes generated by the kernel for IP addresses of VRF ifaces. Your patch was mostly ok, there was just a minor issue that the code of if_in_vrf() you used would consider VRF interfaces both inside and outside VRFs (for protocols that are explicitly bound to 'main' VRF, called as if_in_vrf(x, NULL)). That was surprisingly complicated to fix, as one had to implement parsing interface type in Netlink to tell apart regular and VRF interfaces. The fixed code was merged: https://gitlab.nic.cz/labs/bird/-/commit/e3c0eca95642a846ab65261424a51dd99d954017 -- 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."
reset rx_limit/in_limit when routing table rt_count becomes less than these limits
Hi, Currently I see channel rx_limit/in_limit are reset during protocol reconfiguration or reload. Is it possible to call channel_reset_limit while withdrawing routes, when table route count becomes less than configured rx_limit/in_limit ? Regards, Bala.
Re: kernel: does not learn routes with RTPROT_KERNEL
Hello!
On first sight, this looks good. Gonna do some checks and tests and let
you know whether anything more is needed from you.
Thank you for your patch!
Maria
On 8/24/23 01:38, Pavel Šorejs via Bird-users wrote:
Here is first version - based on master
Pavel
---
doc/bird.sgml | 11 ++-
sysdep/linux/netlink.c | 2 +-
sysdep/unix/krt.Y | 7 ++-
sysdep/unix/krt.c | 15 +++
sysdep/unix/krt.h | 4
5 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/doc/bird.sgml b/doc/bird.sgml
index 29e12b7a..af87d5dc 100644
--- a/doc/bird.sgml
+++ b/doc/bird.sgml
@@ -3454,9 +3454,8 @@ on the ignored or accepted to our
table).
Note that routes created by OS kernel itself, namely direct routes
-representing IP subnets of associated interfaces, are not imported
even with
- to
-generate these direct routes.
+representing IP subnets of associated interfaces, are imported only with
+ If your OS supports only a single routing table, you can configure
only one
instance of the Kernel protocol. If it supports multiple tables (in
order to
@@ -3487,10 +3486,12 @@ channels.
Time in seconds between two consecutive scans of the kernel routing
table.
- learn
+ learn [
Enable learning of routes added to the kernel routing tables by
other
routing daemons or by the system administrator. This is possible
only on
- systems which support identification of route authorship.
+ systems which support identification of route authorship. By
default, routes
+ created by kernel (marked as "proto kernel") are not imported.
Use
+ option to import these routes.
kernel table
Select which kernel table should this particular instance of the
Kernel
diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c
index 1af78766..29446cab 100644
--- a/sysdep/linux/netlink.c
+++ b/sysdep/linux/netlink.c
@@ -1598,7 +1598,7 @@ nl_parse_route(struct nl_parse_state *s, struct
nlmsghdr *h)
case RTPROT_KERNEL:
krt_src = KRT_SRC_KERNEL;
- return;
+ break;
case RTPROT_BIRD:
if (!s->scan)
diff --git a/sysdep/unix/krt.Y b/sysdep/unix/krt.Y
index 95b54d65..f3eb1393 100644
--- a/sysdep/unix/krt.Y
+++ b/sysdep/unix/krt.Y
@@ -32,6 +32,7 @@ CF_DECLS
CF_KEYWORDS(KERNEL, PERSIST, SCAN, TIME, LEARN, DEVICE, ROUTES,
GRACEFUL, RESTART, KRT_SOURCE, KRT_METRIC, MERGE, PATHS)
CF_KEYWORDS(INTERFACE, PREFERRED)
+%type kern_learn
%type kern_mp_limit
CF_GRAMMAR
@@ -48,6 +49,10 @@ kern_proto_start: proto_start KERNEL {
kern_proto: kern_proto_start proto_name '{' ;
kern_proto: kern_proto kern_item ';' ;
+kern_learn:
+ bool { $$ = $1 ? KRT_LEARN_SOME : KRT_LEARN_NONE; }
+ | ALL { $$ = KRT_LEARN_ALL; }
+
kern_mp_limit:
/* empty */ { $$ = KRT_DEFAULT_ECMP_LIMIT; }
| LIMIT expr { $$ = $2; if (($2 <= 0) || ($2 > 255))
cf_error("Merge paths limit must be in range 1-255"); }
@@ -61,7 +66,7 @@ kern_item:
/* Scan time of 0 means scan on startup only */
THIS_KRT->scan_time = $3 S_;
}
- | LEARN bool {
+ | LEARN kern_learn {
THIS_KRT->learn = $2;
#ifndef KRT_ALLOW_LEARN
if ($2)
diff --git a/sysdep/unix/krt.c b/sysdep/unix/krt.c
index 9f95247f..3288fd0c 100644
--- a/sysdep/unix/krt.c
+++ b/sysdep/unix/krt.c
@@ -638,13 +638,14 @@ krt_got_route(struct krt_proto *p, rte *e, s8 src)
#ifdef KRT_ALLOW_LEARN
switch (src)
- {
- case KRT_SRC_KERNEL:
- goto ignore;
-
+ {
case KRT_SRC_REDIRECT:
goto delete;
+ case KRT_SRC_KERNEL:
+ if (KRT_CF->learn != KRT_LEARN_ALL)
+ goto ignore;
+ // fall through
case KRT_SRC_ALIEN:
if (KRT_CF->learn)
krt_learn_scan(p, e);
@@ -780,6 +781,12 @@ krt_got_route_async(struct krt_proto *p, rte *e,
int new, s8 src)
break;
#ifdef KRT_ALLOW_LEARN
+ case KRT_SRC_KERNEL:
+ if (KRT_CF->learn == KRT_LEARN_ALL)
+ {
+ krt_learn_async(p, e, new);
+ }
+ break;
case KRT_SRC_ALIEN:
if (KRT_CF->learn)
{
diff --git a/sysdep/unix/krt.h b/sysdep/unix/krt.h
index 18a206e6..694ebd34 100644
--- a/sysdep/unix/krt.h
+++ b/sysdep/unix/krt.h
@@ -27,6 +27,10 @@ struct kif_proto;
#define KRT_REF_SEEN 0x1 /* Seen in table */
#define KRT_REF_BEST 0x2 /* Best in table */
+#define KRT_LEARN_NONE 0 /* Don't learn */
+#define KRT_LEARN_SOME 1 /* Learn some routes (excluding
RTPROT_KERNEL) */
+#define KRT_LEARN_ALL 2 /* Learn all routes */
+
/* Whenever we recognize our own routes, we allow learing of foreign
routes */
#ifdef CONFIG_SELF_CONSCIOUS
--
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
