OSPF Type 5 LSA route install behavior difference
Hi Bird users, I am seeing different behavior with respect to OSPF type 5 LSA routes. The setup contains two routers R1,R2 as shown below. OSPF is running on eth2 of both routers R1,R2. R1 router eth1 interface is in OSPF passive mode. We are configuring a static route on R1 and it is getting advertised into the OSPF domain. The static route configured on R1 is: 33.0.0.0/8 gateway 172.19.13.1 (eth1:172.19.13.128/24) R1 (eth2:55.55.55.100/24 ) <--> (eth2: 55.55.55.200/24) R2 CASE 1: When Static routes first get added on R1, after that eth1 interface added to OSPF on R1. We can see the Static route always present on R2 as a type 5 route and there is no impact of removing eth1 from OSPF on the R1 router. CASE 2: When eth1 added as OSPF interface on R1 first, then static route added later. Deletion eth1 from OSPF on R1 , deletes static route also from R2. Incase of Case 2, the behavior we observe is a bug ? Case 1, 2 bird logs are attached. Regards, Bala. //working one (eth1:172.19.13.128/24) R1 (eth2:55.55.55.100/24 ) --- (eth2: 55.55.55.200/24) R2 33.0.0.0/8 gw 172.19.13.1 Feb 05 04:34:24 bird: ospfv2_1: HELLO packet sent via eth2 Feb 05 04:34:30 bird: ospfv2_1: HELLO packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:31 bird: ospfv2_1: LSUPD packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:31 bird: ospfv2_1: length 64 Feb 05 04:34:31 bird: ospfv2_1: router 1.1.1.1 Feb 05 04:34:31 bird: ospfv2_1: LSA Type: 0005, Id: 33.0.0.0, Rt: 1.1.1.1, Seq: 809a, Age: 1, Sum: e3f8 Feb 05 04:34:31 bird: ospfv2_1: Installing LSA: Type: 4005, Id: 33.0.0.0, Rt: 1.1.1.1, Seq: 809a, Age: 1 Feb 05 04:34:31 bird: ospfv2_1: Scheduling routing table calculation Feb 05 04:34:31 bird: ospfv2_1: LSUPD packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:31 bird: ospfv2_1: length 76 Feb 05 04:34:31 bird: ospfv2_1: router 1.1.1.1 Feb 05 04:34:31 bird: ospfv2_1: LSA Type: 0001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c00, Age: 1, Sum: 2e3a Feb 05 04:34:31 bird: ospfv2_1: Installing LSA: Type: 2001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c00, Age: 1 Feb 05 04:34:31 bird: ospfv2_1: LSACK packet sent via eth2 Feb 05 04:34:31 bird: ospfv2_1: length 64 Feb 05 04:34:31 bird: ospfv2_1: router 11.11.11.11 Feb 05 04:34:31 bird: ospfv2_1: LSA Type: 0005, Id: 33.0.0.0, Rt: 1.1.1.1, Seq: 809a, Age: 1, Sum: e3f8 Feb 05 04:34:31 bird: ospfv2_1: LSA Type: 0001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c00, Age: 1, Sum: 2e3a Feb 05 04:34:32 bird: ospfv2_1: Starting routing table calculation Feb 05 04:34:32 bird: ospfv2_1: Starting routing table calculation for area 0.0.0.0 Feb 05 04:34:32 bird: ospfv2_1: Starting routing table calculation for inter-area (area 0.0.0.0) Feb 05 04:34:32 bird: ospfv2_1: Starting routing table calculation for ext routes Feb 05 04:34:32 bird: ospfv2_1: Starting routing table synchronization Feb 05 04:34:32 bird: ospfv2_1.ipv4 > added [best] 33.0.0.0/8 unicast Feb 05 04:34:32 bird: kernel1.ipv4 < added 33.0.0.0/8 unicast Feb 05 04:34:34 bird: ospfv2_1: HELLO packet sent via eth2 Feb 05 04:34:40 bird: ospfv2_1: HELLO packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:44 bird: ospfv2_1: HELLO packet sent via eth2 Feb 05 04:34:50 bird: ospfv2_1: HELLO packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:54 bird: ospfv2_1: HELLO packet sent via eth2 Feb 05 04:34:56 bird: ospfv2_1: LSUPD packet received from nbr 1.1.1.1 on eth2 Feb 05 04:34:56 bird: ospfv2_1: length 88 Feb 05 04:34:56 bird: ospfv2_1: router 1.1.1.1 Feb 05 04:34:56 bird: ospfv2_1: LSA Type: 0001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c01, Age: 1, Sum: 5f21 Feb 05 04:34:56 bird: ospfv2_1: Installing LSA: Type: 2001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c01, Age: 1 Feb 05 04:34:56 bird: ospfv2_1: Scheduling routing table calculation Feb 05 04:34:56 bird: ospfv2_1: LSACK packet sent via eth2 Feb 05 04:34:56 bird: ospfv2_1: length 44 Feb 05 04:34:56 bird: ospfv2_1: router 11.11.11.11 Feb 05 04:34:56 bird: ospfv2_1: LSA Type: 0001, Id: 1.1.1.1, Rt: 1.1.1.1, Seq: 8c01, Age: 1, Sum: 5f21 Feb 05 04:34:57 bird: ospfv2_1: Starting routing table calculation Feb 05 04:34:57 bird: ospfv2_1: Starting routing table calculation for area 0.0.0.0 Feb 05 04:34:57 bird: ospfv2_1: Starting routing table calculation for inter-area (area 0.0.0.0) Feb 05 04:34:57 bird: ospfv2_1: Starting routing table calculation for ext routes Feb 05 04:34:57 bird: ospfv2_1: Starting routing table synchronization Feb 05 04:34:57 bird: ospfv2_1.ipv4 > added [best] 172.19.13.0/24 unicast Feb 05 04:34:57 bird: kernel1.ipv4 < added 172.19.13.0/24 unicast Feb 05 04:35:00 bird: ospfv2_1: HELLO packet received from nbr 1.1.1.1 on eth2 Feb 05 04:35:04 bird: ospfv2_1: HELLO packet sent via eth2 Feb 05 04:35:05 bird: kernel1: 0.0.0.0/0: [alien] ignored Feb 05 04:35:05 bird: kernel1: 1.1.1.1/32: seen Feb 05
Fwd: reset rx_limit/in_limit when routing table rt_count becomes less than these limits
Hi, This query is regarding config options 'import limit', 'receive limit' under channel . Currently BIRD doesn't have any alarm generation sent asynchronously to interested processes. Users have to either look at logs or query through bird cli. Question is if the BLOCK action is chosen with 'import or receive limit', bird can block the import of routes once limit is reached, but when withdrawal of routes happens, bird also withdraw routes and we can observe these routes removed from the kernel also. Now the imported route count is less than the configured limit, But bird doesn't clear the HIT flag and when routes come, these routes are still blocked though received route count is within the configured limit. User intervention is needed to clear the HIT flag as mentioned in user documentation. As there is already route count in a table tracked, can this HIT flag be cleared when route count reaches below the configured import/receive limit for that route table? Regards, Bala. -- Forwarded message - From: Bala Sajja Date: Thu, Aug 24, 2023 at 8:10 PM Subject: reset rx_limit/in_limit when routing table rt_count becomes less than these limits To: 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: BGP: connect delay timer vs connect retry timer
: bgp_10: State changed to stop
Line 228: Aug 29 14:03:59 bird: bgp_10: Down
Line 229: Aug 29 14:03:59 bird: bgp_10: State changed to flush
Line 230: Aug 29 14:03:59 bird: bgp_10: State changed to down
Line 231: Aug 29 14:03:59 bird: bgp_10: Initializing
Line 232: Aug 29 14:03:59 bird: bgp_10: Starting
Line 233: Aug 29 14:03:59 bird: bgp_10: State changed to start
Line 235: Aug 29 14:03:59 bird: bgp_10: Started
Line 236: Aug 29 14:03:59 bird: bgp_10: Connect delayed by 5 seconds
Line 246: Aug 29 14:04:04 bird: bgp_10: Connecting to 10.220.152.55
from local address 10.220.152.53
Line 253: Aug 29 14:04:27 bird: bgp_10: Connecting to 10.220.152.55
from local address 10.220.152.53
Line 274: Aug 29 14:04:54 bird: bgp_10: Connecting to 10.220.152.55
from local address 10.220.152.53
Line 283: Aug 29 14:05:12 bird: Restarting protocol bgp_10
Line 284: Aug 29 14:05:12 bird: bgp_10: Shutting down
Line 285: Aug 29 14:05:12 bird: bgp_10: Shutdown requested
Line 286: Aug 29 14:05:12 bird: bgp_10: State changed to stop
Line 290: Aug 29 14:05:12 bird: bgp_10: Down
Line 291: Aug 29 14:05:12 bird: bgp_10: State changed to flush
Line 292: Aug 29 14:05:12 bird: bgp_10: State changed to down
Line 293: Aug 29 14:05:12 bird: bgp_10: Initializing
Line 294: Aug 29 14:05:12 bird: bgp_10: Starting
Line 295: Aug 29 14:05:12 bird: bgp_10: State changed to start
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)
Line 385: Aug 29 14:07:00 bird: bgp_10: Connect delayed by 5 seconds
Line 388: Aug 29 14:07:05 bird: bgp_10: Connecting to 10.220.152.55
from local address 10.220.152.53
Line 395: Aug 29 14:07:36 bird: bgp_10: Connection lost (Connection timed out)
Line 396: Aug 29 14:07:36 bird: bgp_10: Connect delayed by 5 seconds
Line 422: Aug 29 14:07:41 bird: bgp_10: Connecting to 10.220.152.55
from local address 10.220.152.53
On Tue, Aug 29, 2023 at 5:45 PM Ondrej Zajicek wrote:
>
> 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 = >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."
BGP: connect delay timer vs connect retry timer
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 ?
bgp_active(struct bgp_proto *p)
{
int delay = MAX(1, p->cf->connect_delay_time);
struct bgp_conn *conn = >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);
}
Regards,
Bala.
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: OSPF v3 DR - intra-area-prefix LSA generation
Thanks Ondrej. Regards, Bala. On Sun, Nov 15, 2020 at 9:08 PM Ondrej Zajicek wrote: > On Thu, Nov 12, 2020 at 07:03:13PM +0530, Bala Sajja wrote: > > I am running bird 2.0.7. Seeing issue with respect to ipv6 address > > add/delete on DR. This added/deleted ipv6 address prefix convergence is > not > > happening till LSA refresh timer fires . > > Hi > > Thanks for the bug report, makes sense. Will check 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." >
OSPF v3 DR - intra-area-prefix LSA generation
I am running bird 2.0.7. Seeing issue with respect to ipv6 address add/delete on DR. This added/deleted ipv6 address prefix convergence is not happening till LSA refresh timer fires . Topology contains 3 routers connected to a switch. Say IPV6 addresses configured on Routers R1(::100/64), R2(:200/64),R3(::300/64). If we are deleting ipv6 addresses other than DR, I could see intra-area-prefix generated by DR and all routers converged with respect to add/deleted ipv6 addresses. With the below change, I could see intra-area-prefix LSA generated on DR also when ipv6 address added/deleted on DR. Please advise if this fix is correct ? --- a/bird-2.0.7/proto/ospf/iface.c +++ b/bird-2.0.7/proto/ospf/iface.c @@ -1187,6 +1187,8 @@ ospf_ifa_notify3(struct proto *P, uint flags, struct ifa *a) /* RFC 5340 4.4.3 Event 5 - prefix added/deleted */ ospf_notify_link_lsa(ifa); ospf_notify_rt_lsa(ifa->oa); + if(ifa->state == OSPF_IS_DR) + ospf_notify_net_lsa(ifa); } } Regards, Bala.
