Re: kernel: does not learn routes with RTPROT_KERNEL
On Thu, Aug 24, 2023 at 01:38:12AM +0200, Pavel Šorejs via Bird-users wrote: > Here is first version - based on master Hi Seems like your patch is mangled (likely lines wrapped by e-mail client). Could you send it as an attachment? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Re: BGP: connect delay timer vs connect retry timer
On Mon, Aug 28, 2023 at 05:02:40PM +0530, Bala Sajja wrote:
> Hi,
>It seems where BGP connect retry timer to be kicked in use cases
> also, connect delay timer gets kicked in. In the below function,
> though bgp_setup_conn(p, conn) sets connect_timer to connect retry
> timer, later it's over written by bgp_start_timer(conn->connect_timer,
> delay) which sets connect_timer to connect delay timer. Is this right
> ? Could we make the connect retry timer work properly ?
Hi
I am not sure what do you mean. The timer connect_timer is used for two
purposes, for connect_delay_time before we try to connnect (in the state
BS_ACTIVE), and for connect_retry_time while we try to connect (in the
state BS_CONNECT). The first is initialized in bgp_active(), the second
in bgp_connect(). The call bgp_setup_conn(p, conn) just allocates the
timer, but it does not sets it to any interval.
>
> bgp_active(struct bgp_proto *p)
> {
> int delay = MAX(1, p->cf->connect_delay_time);
> struct bgp_conn *conn = &p->outgoing_conn;
>
> BGP_TRACE(D_EVENTS, "Connect delayed by %d seconds", delay);
> bgp_setup_conn(p, conn);
> bgp_conn_set_state(conn, BS_ACTIVE);
> bgp_start_timer(conn->connect_timer, delay);
> }
--
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: kernel: does not learn routes with RTPROT_KERNEL
Here it is
On 8/29/23 14:02, Ondrej Zajicek wrote:
On Thu, Aug 24, 2023 at 01:38:12AM +0200, Pavel Šorejs via Bird-users wrote:
Here is first version - based on master
Hi
Seems like your patch is mangled (likely lines wrapped by e-mail client).
Could you send it as an attachment?
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 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 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
Re: BGP: connect delay timer vs connect retry timer
Hi Ondrej, OK. understood. We can configure connect-retry-interval in the range 1..65535. We are trying to test this with different values as pasted below with logs. Things work as expected till the 1..25 seconds range. After that we always see the connection delay timer getting triggered, connect retry timer config has no impact. Below are the logs with different values of connect-retry-interval //connect-retry-interval 1 Line 35: Aug 29 14:01:21 bird: bgp_10: Started Line 36: Aug 29 14:01:21 bird: bgp_10: Connect delayed by 5 seconds Line 38: Aug 29 14:01:25 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 61: Aug 29 14:01:50 bird: Restarting protocol bgp_10 Line 62: Aug 29 14:01:50 bird: bgp_10: Shutting down Line 63: Aug 29 14:01:50 bird: bgp_10: Shutdown requested Line 64: Aug 29 14:01:50 bird: bgp_10: State changed to stop Line 68: Aug 29 14:01:50 bird: bgp_10: Down Line 69: Aug 29 14:01:50 bird: bgp_10: State changed to flush Line 70: Aug 29 14:01:50 bird: bgp_10: State changed to down Line 71: Aug 29 14:01:50 bird: bgp_10: Initializing Line 72: Aug 29 14:01:50 bird: bgp_10: Starting Line 73: Aug 29 14:01:50 bird: bgp_10: State changed to start Line 75: Aug 29 14:01:50 bird: bgp_10: Started Line 76: Aug 29 14:01:50 bird: bgp_10: Connect delayed by 5 seconds Line 87: Aug 29 14:01:55 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 88: Aug 29 14:01:56 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 89: Aug 29 14:01:57 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 90: Aug 29 14:01:58 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 91: Aug 29 14:01:59 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 92: Aug 29 14:02:00 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 93: Aug 29 14:02:01 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 95: Aug 29 14:02:01 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 96: Aug 29 14:02:02 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 //connect-retry-interval 5 Line 101: Aug 29 14:02:03 bird: Restarting protocol bgp_10 Line 102: Aug 29 14:02:03 bird: bgp_10: Shutting down Line 103: Aug 29 14:02:03 bird: bgp_10: Shutdown requested Line 104: Aug 29 14:02:03 bird: bgp_10: State changed to stop Line 108: Aug 29 14:02:03 bird: bgp_10: Down Line 109: Aug 29 14:02:03 bird: bgp_10: State changed to flush Line 110: Aug 29 14:02:03 bird: bgp_10: State changed to down Line 111: Aug 29 14:02:03 bird: bgp_10: Initializing Line 112: Aug 29 14:02:03 bird: bgp_10: Starting Line 113: Aug 29 14:02:03 bird: bgp_10: State changed to start Line 115: Aug 29 14:02:03 bird: bgp_10: Started Line 116: Aug 29 14:02:03 bird: bgp_10: Connect delayed by 5 seconds Line 126: Aug 29 14:02:07 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 128: Aug 29 14:02:12 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 130: Aug 29 14:02:15 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 131: Aug 29 14:02:19 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 134: Aug 29 14:02:24 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 135: Aug 29 14:02:28 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 //connect-retry-interval 20 Line 141: Aug 29 14:02:31 bird: Restarting protocol bgp_10 Line 142: Aug 29 14:02:31 bird: bgp_10: Shutting down Line 143: Aug 29 14:02:31 bird: bgp_10: Shutdown requested Line 144: Aug 29 14:02:31 bird: bgp_10: State changed to stop Line 148: Aug 29 14:02:31 bird: bgp_10: Down Line 149: Aug 29 14:02:31 bird: bgp_10: State changed to flush Line 150: Aug 29 14:02:31 bird: bgp_10: State changed to down Line 151: Aug 29 14:02:31 bird: bgp_10: Initializing Line 152: Aug 29 14:02:31 bird: bgp_10: Starting Line 153: Aug 29 14:02:31 bird: bgp_10: State changed to start Line 155: Aug 29 14:02:31 bird: bgp_10: Started Line 156: Aug 29 14:02:31 bird: bgp_10: Connect delayed by 5 seconds Line 167: Aug 29 14:02:36 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 185: Aug 29 14:02:53 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 191: Aug 29 14:03:12 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 195: Aug 29 14:03:30 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 Line 214: Aug 29 14:03:48 bird: bgp_10: Connecting to 10.220.152.55 from local address 10.220.152.53 //connect-retry-interval 30 Line 221: Aug 29 14:03:59 bird: Restarting protocol bgp_10 Line 222: Aug 29 14:03:59 bird: bgp_10: Shutting down Line 223: Aug 29 14:03:59 bird: bgp_10: Shutdown requested Line 224: Aug 29 14:03:59 bird: b
Re: Bird is bringing down bgp connection upon receiving Admin Down
On Wed, Aug 09, 2023 at 06:57:29AM +, Sunnat Samadov wrote: > > > > This is the detailed explanation of the previously raised issue. > > > > We are using BIRD https://gitlab.nic.cz/labs/bird/-/tags/v2.0.11. And there > > is an issue with respect to BFD + BGP as described below. > > > > When Peer device ( Cisco ASR router) sends an BFD admin down, Bird is > > bringing down the BGP connection which is using BFD mode ON, which is not > > correct. The expected behavior is upon receiving BFD admin down from peer > > device, Bird should fall back to the Normal BGP mode of working. > > Hi, > > Is there any update on this issue? Hi Just fixed that issue, thanks for the bugreport and sorry for the late answer. https://gitlab.nic.cz/labs/bird/-/commit/aa70e14c9e4cfeb70d2dc9cee497c40057dc105e -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Re: BGP: connect delay timer vs connect retry timer
On Tue, Aug 29, 2023 at 09:11:27PM +0530, Bala Sajja wrote: > Hi Ondrej, > OK. understood. We can configure connect-retry-interval in the > range 1..65535. We are trying to test this with different values as > pasted below with logs. Things work as expected till the 1..25 seconds > range. After that we always see the connection delay timer getting > triggered, connect retry timer config has no impact. This is really unrelated to connection delay timer. You get this behavior because besides our connect retry timer there is also OS-level timer for TCP connections. If our retry timer is small, it timeouts and we retry the connection. If our timer is large, we get socket error from OS first (that is the log message 'Connection lost (Connection timed out)'), which leads to complete restart of BGP state machine, including going through the initial connection delay time. It is true that we could likely avoid full restart from socket error when we are still in the CONNECT state, and wait for our connect retry timer. First case: > Line 167: Aug 29 14:02:36 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 185: Aug 29 14:02:53 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 191: Aug 29 14:03:12 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 195: Aug 29 14:03:30 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 214: Aug 29 14:03:48 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 Second case: > Line 297: Aug 29 14:05:12 bird: bgp_10: Started > Line 298: Aug 29 14:05:12 bird: bgp_10: Connect delayed by 5 seconds > Line 308: Aug 29 14:05:16 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 348: Aug 29 14:05:48 bird: bgp_10: Connection lost (Connection timed out) > Line 349: Aug 29 14:05:48 bird: bgp_10: Connect delayed by 5 seconds > Line 351: Aug 29 14:05:52 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 360: Aug 29 14:06:24 bird: bgp_10: Connection lost (Connection timed out) > Line 361: Aug 29 14:06:24 bird: bgp_10: Connect delayed by 5 seconds > Line 363: Aug 29 14:06:28 bird: bgp_10: Connecting to 10.220.152.55 > from local address 10.220.152.53 > Line 384: Aug 29 14:07:00 bird: bgp_10: Connection lost (Connection timed out) -- 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."
