Re: [PATCH v2] Lib: accept 240.0.0.0/4 as a valid range

[Neil Jerram]

FYI, and in as much as it constitutes a form of support for this, we at
Project Calico made a similar change to our BIRD 1.6 fork with these
commits.  (Of which the first is rather embarrassing...)
https://github.com/projectcalico/bird/commit/5cc183424d9ffb898171ef16360c400414f91bf0
https://github.com/projectcalico/bird/commit/4c6f0ce840456cc04483a820007b433721706c07
https://github.com/projectcalico/bird/commit/49d883ed225d8eb0310009a5a79b1c9ee0afbca9

We went for SCOPE_SITE.

Best wishes,
Neil


On Mon, Mar 14, 2022 at 9:35 AM Vincent Bernat  wrote:

> 240.0.0.0/4 is marked as reserved and considered invalid by BIRD. At
> work, we are using this range internally since all RFC 1918 are full
> and 100.64.0.0/10 is already used too. BIRD complains loudly for each
> interface using this range.
>
> This change makes it possible to use this range. I have used scope
> "universe". But I would be happy with "site" too. While widely
> discussed, I don't think 240/4 will become routable on the Internet
> one day.
>
> As a bonus, I added some comments and unrolled a condition for each
> block. I also have added some hints for the compiler to avoid using
> jumps in the hotpath (tested on Godbolt, see
> https://godbolt.org/z/rGjz336K3).
> ---
>  lib/ip.c| 28 +++-
>  sysdep/config.h |  5 +
>  2 files changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/lib/ip.c b/lib/ip.c
> index fcc72cafb4de..4d0dff636e17 100644
> --- a/lib/ip.c
> +++ b/lib/ip.c
> @@ -85,25 +85,19 @@ ip4_classify(ip4_addr ad)
>u32 a = _I(ad);
>u32 b = a >> 24U;
>
> -  if (b && b <= 0xdf)
> -  {
> -if (b == 0x7f)
> -  return IADDR_HOST | SCOPE_HOST;
> -else if ((b == 0x0a) ||
> -((a & 0x) == 0xc0a8) ||
> -((a & 0xfff0) == 0xac10))
> -  return IADDR_HOST | SCOPE_SITE;
> -else
> -  return IADDR_HOST | SCOPE_UNIVERSE;
> -  }
> -
> -  if (b >= 0xe0 && b <= 0xef)
> +  if (unlikely(b == 0x00))
> +return IADDR_INVALID;   /* 0.0.0.0/8   This
> network */
> +  if (unlikely(b == 0x7f))  /* 127.0.0.0/8 Loopback
> */
> +return IADDR_HOST | SCOPE_HOST;
> +  if ((b == 0x0a) ||/* 10.0.0.0/8
> Private-use */
> +  ((a & 0x) == 0xc0a8) ||   /* 192.168.0.0/16
> Private-use */
> +  ((a & 0xfff0) == 0xac10)) /* 172.16.0.0/12
>  Private-use */
> +return IADDR_HOST | SCOPE_SITE;
> +  if (unlikely(b >= 0xe0 && b <= 0xef)) /* 224.0.0.0/4 Multicast
> */
>  return IADDR_MULTICAST | SCOPE_UNIVERSE;
> -
> -  if (a == 0x)
> +  if (unlikely(a == 0x))/* 255.255.255.255 Limited
> broadcast */
>  return IADDR_BROADCAST | SCOPE_LINK;
> -
> -  return IADDR_INVALID;
> +  return IADDR_HOST | SCOPE_UNIVERSE;
>  }
>
>  int
> diff --git a/sysdep/config.h b/sysdep/config.h
> index b0531844af9f..4d73543c3894 100644
> --- a/sysdep/config.h
> +++ b/sysdep/config.h
> @@ -30,6 +30,11 @@
>   */
>  #include "sysdep/paths.h"
>
> +/* Likely/unlikely macros */
> +
> +#define likely(x)   __builtin_expect((x),1)
> +#define unlikely(x) __builtin_expect((x),0)
> +
>  /* Types */
>
>  #include 
> --
> 2.35.1
>
>

Re: Unable to get Bird 2 to listen on the BGP socket

[Neil Jerram]

I did look at https://dpaste.com/6P6NAUPNX, and saw that it had a template
but no actual peers.  I misinterpreted "& peer config:
https://dpaste.com/HJ3SNL8RH; as being the config for the BIRD at the other
end of the peering, and so didn't check that, as you say.

Anyway, your response is rather unkind, to someone who was trying to help
you.

On Thu, Sep 3, 2020 at 3:43 PM Skyler Mäntysaari  wrote:

> If you had taken the time to read the posted links,  you would see that it
> has peers,  using Link-Local addresses.
>
> On Thu, Sep 3, 2020, at 11:17, Neil Jerram wrote:
>
> Does your configuration have any BGP peers?  I've noticed that BIRD
> doesn't start listening until there is at least one BGP peer.
>
> On Thu, Sep 3, 2020 at 12:12 AM Skyler Mäntysaari  wrote:
>
> Hi there,
>
> I’m fairly certain that my issue is something rather small, or stupid but
> I’m unable to get Bird to listen on the 179 port.
>
> The other side has direct in the protocol definition which is correct, and
> I tried this side with that as well but it only says “as213021_hel_node:
> Waiting for fe80:10::1%wg1 to become my neighbor” so I don’t really have
> more clues.
>
> I did try to do strace and look for bind events, but couldn’t find any
> except for the control socket.
>
> My config can be seen here: https://dpaste.com/6P6NAUPNX & peer config:
> https://dpaste.com/HJ3SNL8RH
>
>

Re: Unable to get Bird 2 to listen on the BGP socket

[Neil Jerram]

Does your configuration have any BGP peers?  I've noticed that BIRD doesn't
start listening until there is at least one BGP peer.

On Thu, Sep 3, 2020 at 12:12 AM Skyler Mäntysaari  wrote:

> Hi there,
>
> I’m fairly certain that my issue is something rather small, or stupid but
> I’m unable to get Bird to listen on the 179 port.
>
> The other side has direct in the protocol definition which is correct, and
> I tried this side with that as well but it only says “as213021_hel_node:
> Waiting for fe80:10::1%wg1 to become my neighbor” so I don’t really have
> more clues.
>
> I did try to do strace and look for bind events, but couldn’t find any
> except for the control socket.
>
> My config can be seen here: https://dpaste.com/6P6NAUPNX & peer config:
> https://dpaste.com/HJ3SNL8RH
>
>

Re: IPv4 route via IPv6 next hop: Netlink: Network unreachable

[Neil Jerram]

On Wed, Apr 1, 2020 at 2:56 PM Ondrej Zajicek 
wrote:

> On Wed, Apr 01, 2020 at 02:56:54PM +0200, Nico Schottelius wrote:
> >
> > Hello,
> >
> > I'm running 2.0.7 on Linux 5.4.18-0-lts (Alpine)
> > and I receive the route 193.228.143.0/24 from
> > 2a0a:e5c0:1:9::2. However it is never set into the kernel, with the
> > error message "Netlink: Network unreachable" in syslog.
> >
> > Has anyone seen this problem recently? I'm not sure if this is really a
> > bird2 problem or not, to be honest:
>
> Hello
>
> BIRD 2.0.7 does not support properly putting IPv4 routes with IPv6 next
> hops to kernel, you can try git master branch (or apply commit
> 53401bef63013dfee01b65d071ffbd88e457539f to v2.0.7). Or wait for 2.0.8,
> which will be released hopefully this month.
>
> > The kernel reports many messages like this in dmesg:
> > [4541983.369058] netlink: 'bird': attribute type 5 has an invalid length.
> >
> > However, I am also puzzled that manually adding the route seems to fail:
>
> Probably older iproute2 tools?
>

Yes, you may be getting the Busybox implementation of 'ip'.  Try 'apk add
--no-cache iproute2'.

Best wishes,
  Neil

Re: Upgrade from Bird 1.3.6 to Bird 2.0.7

[Neil Jerram]

On Sat, 28 Mar 2020, 06:26 Fabiano D'Agostino, <
fabiano.dagostin...@gmail.com> wrote:

> Good morning Maria,
> but how can I guarantee business continuity? I mean can two versions of
> Bird running on the same host at the same time?
>

If running BIRD is important for your business, you should already have a
plan for updating the BIRD software when needed, even if it is only for a
small fix. In principle I would guess the same plan will work for the
bigger change from 1.6 to 2.0.

BTW, to me your questions sound a bit like "please will you do my homework
for me?"  I think you will need to do more of your own research to ramp up
on how BIRD works, so that you can then ask more precise questions.

Best wishes,
 Neil

Re: Kernel protocol

[Neil Jerram]

For example, a route reflector's job is to reflect routes between its
client peers.  Often a route reflector is not on the data path itself, and
so does not need to program those routes into its own box's kernel.

On Fri, Mar 20, 2020 at 9:50 AM Alexander Zubkov  wrote:

> Hi,
>
> It depends on what you are trying to achieve. Of course bird can
> function without an instance of the kernel protocol. But in that case
> it can not push any routes into the routing table of your os. If you
> need those routes only to spread them for some other reasons then it
> is probable that you do not need to use the kernel protocol.
>
> On Fri, Mar 20, 2020 at 9:07 AM Irene Lalioti 
> wrote:
> >
> > Hello guys!
> >
> > I would like to ask you what would you think the better practice would
> > be: Can we remove totally the kernel protocol?
> >
> > I thought no but we tested it and it works. Now we have on our linuxbox
> > set the static routes outside bird daemon, where we specify that the
> > caches we have are behind the border routers.
> >
> > Would it be safe to totally remove this from the system configs and only
> > use the Direct protocol as we said yesterday, and rely on the direct
> > protocol that it learns the connected network and the multihop of the
> > caches which reside behind the border routers?
> >
> > Thanks a lot!!
> >
> > Irene
> >
> > --
> > Irene Lalioti
> > Network Engineer
> > Fondation RESTENA
> > 2, avenue de l'Université
> > L-4365 Esch/Alzette
> >
> > Tel: +352 424409 1
> > Fax: +352 422473
> >
>
>

Re: Unwanted IPv6 static route flap

[Neil Jerram]

Hi Ondrej,

I've added my guesses below, about what the logs mean.  Would you mind
taking a look and commenting further?

[...]  Here is a case where node R was killed (-9) at 15:50:03 and
> restarted at 15:50:08.  Node M saw this route flap at 15:50:11:
>
> [2020-03-04T15:50:11.257106] Deleted fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122
> via 2001:20::2 dev eth0 proto bird metric 1024 pref medium
> [2020-03-04T15:50:11.257459] fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 via
> 2001:20::2 dev eth0 proto bird metric 1024 pref medium
>
> Here is the node M log with "debug all", for both v4 and v6, from when R
> restarted until the route flap:
>
> 2020-03-04T15:50:09.246741514Z KRT: Scanning routing table
> 2020-03-04T15:50:09.246805309Z BGP: connect_timeout
> 2020-03-04T15:50:09.246820405Z BGP: Closing connection
> 2020-03-04T15:50:09.246830788Z BGP: Connecting
> 2020-03-04T15:50:09.246843075Z bird: Mesh_172_17_0_2: Connecting to
> 172.17.0.2 from local address 172.17.0.3
> 2020-03-04T15:50:09.246852834Z KRT: Got 2001:20::/64, type=1, oif=36,
> table=254, prid=2, proto=kernel1
> 2020-03-04T15:50:09.246861952Z KRT: Got
> fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122, type=1, oif=36, table=254, prid=12,
> proto=kernel1
>

I presume this indicates this BIRD6 seeing that the e7c0 route is present
in the kernel routing table.


> 2020-03-04T15:50:09.246871442Z KRT: Got
> fd00:10:244:0:586d:4461:e980:a280/128, type=1, oif=6, table=254, prid=3,
> proto=kernel1
> 2020-03-04T15:50:09.246879832Z Running filter
> `calico_kernel_programming'...done (2)
> 2020-03-04T15:50:09.246889555Z KRT: Got
> fd00:10:244:0:586d:4461:e980:a280/122, type=6, oif=1, table=254, prid=12,
> proto=kernel1
> 2020-03-04T15:50:09.246898969Z KRT: Got
> fd00:10:244:0:58fd:b191:5c13:9cc0/122, type=1, oif=36, table=254, prid=12,
> proto=kernel1
> 2020-03-04T15:50:09.246908792Z Running filter
> `calico_kernel_programming'...done (2)
> 2020-03-04T15:50:09.24691778Z KRT: Got fe80::/64, type=1, oif=36,
> table=254, prid=2, proto=kernel1
> 2020-03-04T15:50:09.246927197Z KRT: Ignoring route - strange class/scope
> 2020-03-04T15:50:09.246935966Z KRT: Got fe80::/64, type=1, oif=6,
> table=254, prid=2, proto=kernel1
> 2020-03-04T15:50:09.246944298Z KRT: Ignoring route - strange class/scope
> 2020-03-04T15:50:09.247009224Z KRT: Got ::1/128, type=2, oif=1, table=255,
> prid=2, proto=(none)
> 2020-03-04T15:50:09.247065042Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247088778Z KRT: Got 2001:20::/128, type=4, oif=36,
> table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247115256Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247131555Z KRT: Got 2001:20::1/128, type=2, oif=36,
> table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247145697Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247159089Z KRT: Got fd00:10:96::ac35/128, type=2,
> oif=3, table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.24717877Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247192816Z KRT: Got fe80::/128, type=4, oif=36,
> table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247206392Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247219343Z KRT: Got fe80::/128, type=4, oif=6,
> table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247262729Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247279256Z KRT: Got fe80::42:acff:fe11:3/128, type=2,
> oif=36, table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247294287Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247307585Z KRT: Got fe80::ecee:eeff:feee:/128,
> type=2, oif=6, table=255, prid=2, proto=(none)
> 2020-03-04T15:50:09.247322176Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247335799Z KRT: Got ff00::/8, type=1, oif=36,
> table=255, prid=3, proto=(none)
> 2020-03-04T15:50:09.247349484Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.24736411Z KRT: Got ff00::/8, type=1, oif=2, table=255,
> prid=3, proto=(none)
> 2020-03-04T15:50:09.247378221Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247391919Z KRT: Got ff00::/8, type=1, oif=6,
> table=255, prid=3, proto=(none)
> 2020-03-04T15:50:09.247405262Z KRT: Ignoring route - unknown table 255
> 2020-03-04T15:50:09.247417972Z Running filter
> `calico_kernel_programming'...done (2)
> 2020-03-04T15:50:09.247439521Z KRT: Pruning table master
> 2020-03-04T15:50:09.247455481Z Running filter
> `calico_kernel_programming'...done (2)
> 2020-03-04T15:50:09.247554245Z Running filter
> `calico_kernel_programming'...done (2)
> 2020-03-04T15:50:09.247607455Z KRT: Pruning inherited routes
> 2020-03-04T15:50:09.247630001Z fd00:10:244:0:586d:4461:e980:a280/128:
> uptodate (metric=1024)
> 2020-03-04T15:50:09.24764445Z KRT: Scanning interfaces
> 2020-03-04T15:50:09.247654547Z bird6: device1: Scanning interfaces
> 2020-03-04T15:50:09.247664209Z BGP: Waiting for connect success
> 2020-03-04T15:50:09.247672821Z KRT: Scanning routing table
> 

Re: Unwanted IPv6 static route flap

[Neil Jerram]

On Tue, Mar 3, 2020 at 2:37 PM Ondrej Zajicek 
wrote:

> On Mon, Mar 02, 2020 at 05:35:01PM +0000, Neil Jerram wrote:
> > On Sat, Feb 29, 2020 at 1:05 PM Neil Jerram  wrote:
> >
> > > I am struggling to understand and ideally eliminate an unwanted flap
> (i.e.
> > > delete and re-add) of an IPv6 route on node M, when a neighbouring
> node R
> > > restarts, and R is configured to advertise that IPv6 route statically.
> [...]
> > >
> >
> > FYI I have just tried the same test again with DBG(...) statements
> compiled
> > in, in the hope that that might reveal strange timing in the static
> > protocol processing.  Unfortunately I don't think it revealed anything
> > suspicious.  There is a line with
>
> Hi
>
> I would guess that the issue is more in node M than in node R. The fact
> that it happens only for IPv6 can be explained by implementation of
> Kernel protocol, which uses replace operation for IPv4 (since 2.0.5), but
> only remove/add for IPv6. Technically, the kernel protocol should detect
> that the new route is the same as old one and avoid pushing it to the
> kernel, but perhaps for some reason it pushes it anyway and causes the
> flap.
>
> To debug this isse, it would be useful to enable 'debug { events, routes
> }' on BGP and Kernel on node M. One could see if there are any withdraws,
> or just updates.
>

Thanks Ondrej.  Here is a case where node R was killed (-9) at 15:50:03 and
restarted at 15:50:08.  Node M saw this route flap at 15:50:11:

[2020-03-04T15:50:11.257106] Deleted fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122
via 2001:20::2 dev eth0 proto bird metric 1024 pref medium
[2020-03-04T15:50:11.257459] fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 via
2001:20::2 dev eth0 proto bird metric 1024 pref medium

Here is the node M log with "debug all", for both v4 and v6, from when R
restarted until the route flap:

2020-03-04T15:50:09.246741514Z KRT: Scanning routing table
2020-03-04T15:50:09.246805309Z BGP: connect_timeout
2020-03-04T15:50:09.246820405Z BGP: Closing connection
2020-03-04T15:50:09.246830788Z BGP: Connecting
2020-03-04T15:50:09.246843075Z bird: Mesh_172_17_0_2: Connecting to
172.17.0.2 from local address 172.17.0.3
2020-03-04T15:50:09.246852834Z KRT: Got 2001:20::/64, type=1, oif=36,
table=254, prid=2, proto=kernel1
2020-03-04T15:50:09.246861952Z KRT: Got
fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122, type=1, oif=36, table=254, prid=12,
proto=kernel1
2020-03-04T15:50:09.246871442Z KRT: Got
fd00:10:244:0:586d:4461:e980:a280/128, type=1, oif=6, table=254, prid=3,
proto=kernel1
2020-03-04T15:50:09.246879832Z Running filter
`calico_kernel_programming'...done (2)
2020-03-04T15:50:09.246889555Z KRT: Got
fd00:10:244:0:586d:4461:e980:a280/122, type=6, oif=1, table=254, prid=12,
proto=kernel1
2020-03-04T15:50:09.246898969Z KRT: Got
fd00:10:244:0:58fd:b191:5c13:9cc0/122, type=1, oif=36, table=254, prid=12,
proto=kernel1
2020-03-04T15:50:09.246908792Z Running filter
`calico_kernel_programming'...done (2)
2020-03-04T15:50:09.24691778Z KRT: Got fe80::/64, type=1, oif=36,
table=254, prid=2, proto=kernel1
2020-03-04T15:50:09.246927197Z KRT: Ignoring route - strange class/scope
2020-03-04T15:50:09.246935966Z KRT: Got fe80::/64, type=1, oif=6,
table=254, prid=2, proto=kernel1
2020-03-04T15:50:09.246944298Z KRT: Ignoring route - strange class/scope
2020-03-04T15:50:09.247009224Z KRT: Got ::1/128, type=2, oif=1, table=255,
prid=2, proto=(none)
2020-03-04T15:50:09.247065042Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247088778Z KRT: Got 2001:20::/128, type=4, oif=36,
table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247115256Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247131555Z KRT: Got 2001:20::1/128, type=2, oif=36,
table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247145697Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247159089Z KRT: Got fd00:10:96::ac35/128, type=2,
oif=3, table=255, prid=2, proto=(none)
2020-03-04T15:50:09.24717877Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247192816Z KRT: Got fe80::/128, type=4, oif=36,
table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247206392Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247219343Z KRT: Got fe80::/128, type=4, oif=6,
table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247262729Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247279256Z KRT: Got fe80::42:acff:fe11:3/128, type=2,
oif=36, table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247294287Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247307585Z KRT: Got fe80::ecee:eeff:feee:/128,
type=2, oif=6, table=255, prid=2, proto=(none)
2020-03-04T15:50:09.247322176Z KRT: Ignoring route - unknown table 255
2020-03-04T15:50:09.247335799Z KRT: Got ff00::/8, type=1, oif=36,
table=255, prid=3, proto=(none)
2020-03-04T15:50:09.247349484Z KRT:

Re: Unwanted IPv6 static route flap

[Neil Jerram]

On Sat, Feb 29, 2020 at 1:05 PM Neil Jerram  wrote:

> I am struggling to understand and ideally eliminate an unwanted flap (i.e.
> delete and re-add) of an IPv6 route on node M, when a neighbouring node R
> restarts, and R is configured to advertise that IPv6 route statically. [...]
>

FYI I have just tried the same test again with DBG(...) statements compiled
in, in the hope that that might reveal strange timing in the static
protocol processing.  Unfortunately I don't think it revealed anything
suspicious.  There is a line with

static_add(fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122,2)

almost immediately after BIRD6 start-up, and 2 seconds before the "Graceful
restart done" log.  So it doesn't look - for example - like the static
processing is being deferred until after "Graceful restart done".  Possibly
interesting that I do not see any "Installing static route" line, but maybe
that is because that route was present in the kernel and so has already
been copied into the BIRD6 core by the kernel protocol.

The complete log is below, in case it reveals more clues to someone else!
As in the previous run, the unwanted route flap was observed on the other
node just after the BGP session reached state Up.  (I think
at 16:59:44.795, but have unfortunately lost the exact output now.)

Best wishes,
Neil

Merged (sorry) logs for BIRD and BIRD6:
2020-03-02T16:59:41.58460202Z Parsing configuration file
`/etc/calico/confd/config/bird.cfg'
2020-03-02T16:59:41.584628001Z Parsing configuration file
`/etc/calico/confd/config/bird6.cfg'
2020-03-02T16:59:41.585771719Z bird6: device1: Initializingbird:
2020-03-02T16:59:41.585818652Z bird6: direct1: Initializing
2020-03-02T16:59:41.58584128Z bird: direct1: Initializingbird6:
2020-03-02T16:59:41.585935985Z bird: Mesh_172_17_0_5: Initializingbird6:
2020-03-02T16:59:41.585981801Z bird: Mesh_172_17_0_3: Initializingbird6:
2020-03-02T16:59:41.586024543Z bird: done
2020-03-02T16:59:41.586130702Z bird6: Protocol start
2020-03-02T16:59:41.586193279Z bird: device1: Starting
2020-03-02T16:59:41.58709367Z bird6: IFA change notification (1) for
tunl0:192.168.110.128
2020-03-02T16:59:41.587183626Z bird6: device1: State changed to feeddevice1
reporting state transition HUNGRY/DOWN -> */UP
2020-03-02T16:59:41.587332806Z bird: device1: Connected to table
masterstatic_add(fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122,2)
2020-03-02T16:59:41.587408514Z bird: device1: State changed to feed
2020-03-02T16:59:41.587664691Z bird6: direct1: Starting
2020-03-02T16:59:41.587740399Z bird6: Kicking kernel1 up
2020-03-02T16:59:41.587822811Z bird6: direct1: State changed to feed
2020-03-02T16:59:41.587859128Z bird6: Mesh_2001_20__8: Starting
2020-03-02T16:59:41.587985681Z bird: bird6: direct1:
StartingMesh_2001_20__8: State changed to start
2020-03-02T16:59:41.588075077Z bird6: bird: Mesh_2001_20__1:
Startingdirect1: Connected to table master
2020-03-02T16:59:41.58826728Z bird: Mesh_2001_20__1 reporting state
transition HUNGRY/DOWN -> */START
2020-03-02T16:59:41.588285997Z direct1: State changed to feedbird6:
2020-03-02T16:59:41.588345781Z bird: Mesh_172_17_0_5: StartingKicking
Mesh_2001_20__3 up
2020-03-02T16:59:41.588385171Z bird6: Mesh_2001_20__3: StartingBGP: Startup.
2020-03-02T16:59:41.588520104Z bird: bird6: Mesh_172_17_0_5: State changed
to startMesh_2001_20__3: State changed to start
2020-03-02T16:59:41.588601958Z bird: Mesh_172_17_0_3: Startingbird6:
2020-03-02T16:59:41.588650567Z bird6: Started
2020-03-02T16:59:41.588713145Z bird: Mesh_172_17_0_3: State changed to start
2020-03-02T16:59:41.588776561Z bird: Announcing routes to new protocol
device1
2020-03-02T16:59:41.588838859Z bird6: olock: 56bb6b20 acquired
immediately
2020-03-02T16:59:41.58892183Z bird: Announcing interfaces to new protocol
static1
2020-03-02T16:59:41.588999773Z bird: Graceful restart startedFeeding
protocol static1 finished
2020-03-02T16:59:41.589046985Z bird: Announcing interfaces to new protocol
direct1
2020-03-02T16:59:41.589203429Z bird6: direct1: State changed to up
2020-03-02T16:59:41.589266566Z bird: BGP: Got lock
2020-03-02T16:59:41.589579174Z bird: direct1: State changed to up
2020-03-02T16:59:41.774914181Z bird6: Mesh_2001_20__8: Connected to table
master
2020-03-02T16:59:41.774983464Z bird6: Mesh_2001_20__8: State changed to wait
2020-03-02T16:59:42.372436086Z bird: Mesh_172_17_0_3: Connected to table
master
2020-03-02T16:59:42.372457597Z bird: Mesh_172_17_0_3: State changed to wait
2020-03-02T16:59:42.776392912Z bird6: Mesh_2001_20__3: Connected to table
master
2020-03-02T16:59:42.776416378Z bird6: Mesh_2001_20__3: State changed to wait
2020-03-02T16:59:43.081266214Z bird: Mesh_172_17_0_5: Connected to table
master
2020-03-02T16:59:43.081286329Z bird: Mesh_172_17_0_5: State changed to wait
2020-03-02T16:59:43.19352288Z bird: Mesh_172_17_0_4: Connected to table
master
2020-03-02T16:59:43.193545788Z bird: Mesh_172_17_0_4: State changed to wait
2020-03-02T16:59:

Unwanted IPv6 static route flap

[Neil Jerram]

I am struggling to understand and ideally eliminate an unwanted flap (i.e.
delete and re-add) of an IPv6 route on node M, when a neighbouring node R
restarts, and R is configured to advertise that IPv6 route statically.

Here is the config on R to advertise the route:

protocol static {
   # IP blocks for this host.
   route fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 blackhole;
}

BIRD6 on node R is killed (with -9) at 12:22:08, and restarts (with the -R
flag) at 12:22:14.

The flap (in the kernel routing table) is detected by running "ip -ts
monitor route" on the monitor node M.  It reports this at 12:22:17:

[2020-02-29T12:22:17.954263] Deleted fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122
via 2001:20::2 dev eth0 proto bird metric 1024 pref medium
[2020-02-29T12:22:17.954470] fd00:10:244:0:1cc0:b1ac:ad47:e7c0/122 via
2001:20::2 dev eth0 proto bird metric 1024 pref medium

Here is the BIRD6 log on R, from when it restarted, until it reached a
steady state.  R's peering to M is "Mesh_2001_20__1".

2020-02-29T12:22:14.214961381Z bird: device1: Initializing
2020-02-29T12:22:14.215018144Z bird: direct1: Initializing
2020-02-29T12:22:14.215035765Z bird: Mesh_2001_20__8: Initializing
2020-02-29T12:22:14.215047665Z bird: Mesh_2001_20__1: Initializing
2020-02-29T12:22:14.215057649Z bird: Mesh_2001_20__3: Initializing
2020-02-29T12:22:14.215144477Z bird: device1: Starting
2020-02-29T12:22:14.215369797Z bird: device1: Connected to table master
2020-02-29T12:22:14.215402544Z bird: device1: State changed to feed
2020-02-29T12:22:14.215431056Z bird: direct1: Starting
2020-02-29T12:22:14.215439899Z bird: direct1: Connected to table master
2020-02-29T12:22:14.215447877Z bird: direct1: State changed to feed
2020-02-29T12:22:14.215456544Z bird: Mesh_2001_20__8: Starting
2020-02-29T12:22:14.215523493Z bird: Mesh_2001_20__3: Starting
2020-02-29T12:22:14.215716006Z bird: Graceful restart started
2020-02-29T12:22:14.215742864Z bird: Started
2020-02-29T12:22:14.215757668Z bird: direct1: State changed to up
2020-02-29T12:22:14.215770554Z bird: device1: State changed to up
2020-02-29T12:22:14.948167365Z bird: Mesh_2001_20__3: Connected to table
master
2020-02-29T12:22:14.948234648Z bird: Mesh_2001_20__3: State changed to wait
2020-02-29T12:22:15.951638881Z bird: Mesh_2001_20__8: Connected to table
master
2020-02-29T12:22:15.951703218Z bird: Mesh_2001_20__8: State changed to wait
2020-02-29T12:22:16.953066987Z bird: Mesh_2001_20__1: Connected to table
master
2020-02-29T12:22:16.953132676Z bird: Mesh_2001_20__1: State changed to wait
2020-02-29T12:22:16.953154658Z bird: Graceful restart done
2020-02-29T12:22:16.95316785Z bird: Mesh_2001_20__8: State changed to feed
2020-02-29T12:22:16.953180658Z bird: Mesh_2001_20__1: State changed to feed
2020-02-29T12:22:16.953194942Z bird: Mesh_2001_20__3: State changed to feed
2020-02-29T12:22:17.953827137Z bird: Mesh_2001_20__8: State changed to up
2020-02-29T12:22:17.953880171Z bird: Mesh_2001_20__1: State changed to up
2020-02-29T12:22:17.953894204Z bird: Mesh_2001_20__3: State changed to up

(There could be some errors here, because I've manually separated logs from
both BIRD and BIRD6 that were going into the same file, and they both log
with prefix "bird:".)

And on M, from when R was killed, until reaching a steady state following R
restart.  M's peering to R is "Mesh_2001_20__2".

2020-02-29T12:22:08.943087384Z bird: Mesh_2001_20__2: State changed to start
2020-02-29T12:22:16.952861163Z bird: Mesh_2001_20__2: State changed to feed
2020-02-29T12:22:16.952950901Z bird: Mesh_2001_20__2: State changed to up

Can anyone help to explain why I get the IPv6 route flap on node M, and if
there is a way of eliminating it?  The peering config on R is

# Template for all BGP clients
template bgp bgp_template {
  debug { states };
  description "Connection to BGP peer";
  local as 64512;
  multihop;
  gateway recursive;
  import all;
  export filter calico_export_to_bgp_peers;
  source address 2001:20::2;
  add paths on;
  graceful restart;
  connect delay time 2;
  connect retry time 5;
  error wait time 5,30;
}
protocol bgp Mesh_2001_20__1 from bgp_template {
  neighbor 2001:20::1 as 64512;
}

and the same on M but with ::1 and ::2 swapped, and __2 instead of __1.

By the way, my setup also has exactly parallel IPv4 config and routes, and
I reliably do _not_ see a similar flap for the corresponding IPv4 route.

Many thanks,
Neil

Re: Understanding IPv6 next hops

[Neil Jerram]

On Fri, 7 Feb 2020, 11:28 Neil Jerram,  wrote:

> On Thu, Feb 6, 2020 at 3:22 PM Ondrej Zajicek 
> wrote:
>
>> On Thu, Feb 06, 2020 at 12:34:00PM +0000, Neil Jerram wrote:
>> > Good morning all!
>> >
>> > I'm debugging a situation where I'm seeing different IPv6 next hop
>> > behaviour in two setups with different versions of my team's software.
>> >
>> > In both setups:
>> > There are 3 routers A, B and C, all peered with another router X.
>> > They are all on the same L2 bridge, and have global IPv6 addresses in
>> the
>> > 2001:20::/64 subnet.
>> > A, B and C all export a route for fd00:10:96::/112
>> > ...
>> > Any ideas?  Can you advise where I should look or check next, to try to
>> > understand why the UPDATE message has two next hop addresses in one
>> setup,
>> > but only one in the other?
>>
>> Hi
>>
>> Check code in IPv6 version of bgp_create_update(). It depends on how
>> sender get the routes (local or received, were they received alredy with
>> link-local next hop, were the next hop modified) and whether it is IBGP or
>> EBGP and whether next hop is the same as sender.
>>
>> > Also, does the passing of two next hop addresses in setup #1 fully
>> explain
>> > why the ECMP routes programmed into the kernel use link-local gateway
>> > addresses?
>>
>> Yes, link-local next hop is preferered as direct gateway.
>>
>> > Also, are the routes with global next hops more correct in some sense
>> than
>> > those with link-local next hops; or vice versa?  Would you expect them
>> both
>> > to forward data correctly?
>>
>> Well, it is a bit strange quirk of IPv6 BGP. In general, both global and
>> link-local next hops should be sent when sender, receiver and global next
>> hop are on the same subnet. Global next hop is used for recursive next
>> hop evalulation, while link-local is used for forwarding.
>>
>
> Thank you very much Ondrej for all this.  I will work through
> understanding and checking the details that you have provided.
>
> Best wishes,
>Neil
>

Thanks again Ondrej, I found the root cause here, with your help. In both
of my setups the peers were in fact directly connected, but one of the
setups was configuring with "direct;" and the other setup with "multihop;".

Best wishes,
 Neil

Re: Understanding IPv6 next hops

[Neil Jerram]

On Thu, Feb 6, 2020 at 3:22 PM Ondrej Zajicek 
wrote:

> On Thu, Feb 06, 2020 at 12:34:00PM +0000, Neil Jerram wrote:
> > Good morning all!
> >
> > I'm debugging a situation where I'm seeing different IPv6 next hop
> > behaviour in two setups with different versions of my team's software.
> >
> > In both setups:
> > There are 3 routers A, B and C, all peered with another router X.
> > They are all on the same L2 bridge, and have global IPv6 addresses in the
> > 2001:20::/64 subnet.
> > A, B and C all export a route for fd00:10:96::/112
> > ...
> > Any ideas?  Can you advise where I should look or check next, to try to
> > understand why the UPDATE message has two next hop addresses in one
> setup,
> > but only one in the other?
>
> Hi
>
> Check code in IPv6 version of bgp_create_update(). It depends on how
> sender get the routes (local or received, were they received alredy with
> link-local next hop, were the next hop modified) and whether it is IBGP or
> EBGP and whether next hop is the same as sender.
>
> > Also, does the passing of two next hop addresses in setup #1 fully
> explain
> > why the ECMP routes programmed into the kernel use link-local gateway
> > addresses?
>
> Yes, link-local next hop is preferered as direct gateway.
>
> > Also, are the routes with global next hops more correct in some sense
> than
> > those with link-local next hops; or vice versa?  Would you expect them
> both
> > to forward data correctly?
>
> Well, it is a bit strange quirk of IPv6 BGP. In general, both global and
> link-local next hops should be sent when sender, receiver and global next
> hop are on the same subnet. Global next hop is used for recursive next
> hop evalulation, while link-local is used for forwarding.
>

Thank you very much Ondrej for all this.  I will work through understanding
and checking the details that you have provided.

Best wishes,
   Neil

Re: Follow up question on "next hop self"

[Neil Jerram]

On Tue, 7 Jan 2020, 00:39 Ondrej Zajicek,  wrote:

> On Mon, Jan 06, 2020 at 06:25:30PM +0000, Neil Jerram wrote:
> > On Sun, Dec 22, 2019 at 3:03 PM Ondrej Zajicek 
> > wrote:
> >
> > > On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
> > > > I have had a look at OSPF, but for our relatively simple network it
> > > > looks like an overkill. Do you have any other recommendations for
> > > > what to run the IGP with instead?
> > > >
> > > > The main reason I so far tried to stay on iBGP only is to reduce
> > > > complexity.
> > >
> > > Well, you can run just IBGP, if you use direct + 'next hop self'
> options,
> > > which should be OK in your simple topology.
> > >
> >
> > According to my understanding of the BIRD code, 'next hop self' is only
> > relevant when exporting a locally originated route to a BGP peer.  So,
> > assuming the original question was about what happens on R1 and R2, I
> would
> > not expect it to be relevant at all.   Is that right?
>
> Option 'next hop self' is relevant in both exporting locally originated
> route to a BGP (i.e. a route without existing bgp_next_hop attribute) and
> exporting route from BGP to another BGP (i.e. a route with existing
> bgp_next_hop attribute).
>

Thanks, yes, I should have mentioned the second case too.

But both cases are on export, so I think my point still stands that 'next
hop self' is not relevant to the question that began this thread. (Unless I
misunderstood that question.)

Best wishes,
Neil

Re: Follow up question on "next hop self"

[Neil Jerram]

On Sun, Dec 22, 2019 at 3:03 PM Ondrej Zajicek 
wrote:

> On Sat, Dec 21, 2019 at 12:39:43AM +0100, Nico Schottelius wrote:
> > I have had a look at OSPF, but for our relatively simple network it
> > looks like an overkill. Do you have any other recommendations for
> > what to run the IGP with instead?
> >
> > The main reason I so far tried to stay on iBGP only is to reduce
> > complexity.
>
> Well, you can run just IBGP, if you use direct + 'next hop self' options,
> which should be OK in your simple topology.
>

According to my understanding of the BIRD code, 'next hop self' is only
relevant when exporting a locally originated route to a BGP peer.  So,
assuming the original question was about what happens on R1 and R2, I would
not expect it to be relevant at all.   Is that right?

Re: More BIRD related software?

[Neil Jerram]

On Tue, Oct 29, 2019 at 4:46 PM Ondrej Zajicek 
wrote:

> Hi
>
> I just found another tool related to BIRD and updated and
> reorganized 'Related software' page on BIRD wiki:
>
> https://gitlab.labs.nic.cz/labs/bird/wikis/Related
>
> I wonder if you know more software worth mentioning there.
>

You might like to mention Project Calico, which includes BIRD in its
architecture as described here:
https://docs.projectcalico.org/v3.10/reference/architecture/

Best wishes,
Neil

Re: BGP graceful restart for software update only?

[Neil Jerram]

Hi Vincent,

On Thu, Oct 17, 2019 at 1:05 PM Vincent Bernat  wrote:

>  ❦ 17 octobre 2019 11:29 +01, Neil Jerram :
>
> > In my setup, an instance of BIRD runs all the time, except for when it
> > needs to be restarted for a software update.
> >
> > For that update scenario, I'd like BGP graceful restart to apply, so that
> > the stop-update-restart process does not cause the routes advertised by
> > this BIRD to be withdrawn from the rest of the BGP network.
> >
> > For all other scenarios, however, I don't want any graceful restart.
> > Specifically, if there's a break in connectivity to a BGP peer, I want to
> > detect that as quickly as possible (with BFD), locally to remove the
> routes
> > learned from that peer, and for that peer to remove routes learned from
> me,
> > all immediately.
> >
> > Is there some combination of configuration and procedure that can provide
> > both of those desires?
>
> You should look at the long lived graceful restart alternative. It will
> enable you to do software upgrades without impact without keeping routes
> around when a BGP session is cut unexpectedly, as long as you have
> alternative routes available.
>

I have indeed been looking at LLGR, and I'm very grateful for your blog
about it.

I'm not sure I'm persuaded by your argument, though, that LLGR is desirable
because BFD could generate a false negative.  Wouldn't it be better to
eliminate those false negatives by allowing BFD to run a more slowly and/or
with a larger multiplier?

IIUC, the benefit of GR, for a planned software update, is that it can
completely avoid any route flapping in the connected BGP peers - in terms
both of the data path and the BGP control plane.  With LLGR in that
scenario, I believe there will be BGP control plane traffic, and other
BIRDs updating their local kernel with least-preferred routes.  I suppose
it is still true that there is no data path flapping, but there *has* been
a lot of control plane churn, which traditional GR would have avoided.  Is
that understanding all correct?

Best wishes,
   Neil

BGP graceful restart for software update only?

[Neil Jerram]

In my setup, an instance of BIRD runs all the time, except for when it
needs to be restarted for a software update.

For that update scenario, I'd like BGP graceful restart to apply, so that
the stop-update-restart process does not cause the routes advertised by
this BIRD to be withdrawn from the rest of the BGP network.

For all other scenarios, however, I don't want any graceful restart.
Specifically, if there's a break in connectivity to a BGP peer, I want to
detect that as quickly as possible (with BFD), locally to remove the routes
learned from that peer, and for that peer to remove routes learned from me,
all immediately.

Is there some combination of configuration and procedure that can provide
both of those desires?

Many thanks,
 Neil

Re: next-hop-self for non-reflected routes only?

[Neil Jerram]

On Mon, Oct 14, 2019 at 3:07 PM Ondrej Zajicek 
wrote:

> On Mon, Oct 14, 2019 at 02:45:37PM +0100, Neil Jerram wrote:
> > > We implemented extension for next-hop-self in version 2.0.3 that allows
> > > to specify 'next hop self ebgp', this solves exactly this issue.
> > >
> > > For older versions, you would need to workaround that in filters,
> > > something like:
> > >
> > > if proto = "bgpX" then
> > >   bgp_next_hop = A.b.C.D;
> > >
> >
> > Thanks Ondrej.  Am I right in thinking that I should do this in the
> import
> > filter?  (From reading the code, it appears that "next hop self" takes
> > effect on import.)
>
> No, in the export filter. You import the route with the original next hop
> (e.g. one from AS 65001), but when exported to B,C it is reset to the
> local value.
>

Many thanks, I'll try this.

Neil

Re: next-hop-self for non-reflected routes only?

[Neil Jerram]

On Mon, Oct 14, 2019 at 2:10 PM Ondrej Zajicek 
wrote:

> On Mon, Oct 14, 2019 at 11:08:50AM +0100, Neil Jerram wrote:
> > Hi - I have a topology like this, using BIRD 1.6.7:
> >
> > I want BIRD-B to reflect routes within its own AS, but also propagate
> > routes to and from AS 65001.  So for the eBGP peering I have
>
> > My question is how to get the ideal next-hop-self behaviour, which I
> > think is
> >
> > - Do next-hop-self for routes from AS 65001 that are being passed on
> >   to Router B, C etc.  Otherwise those routes will be unreachable.
> >
> > - Don't do next-hop-self for reflected routes.  Next-hop-self isn't
> >   needed here, because the downstream Router B, C etc are already
> >   directly connected.
>
> Hello
>
> We implemented extension for next-hop-self in version 2.0.3 that allows
> to specify 'next hop self ebgp', this solves exactly this issue.
>
> For older versions, you would need to workaround that in filters,
> something like:
>
> if proto = "bgpX" then
>   bgp_next_hop = A.b.C.D;
>

Thanks Ondrej.  Am I right in thinking that I should do this in the import
filter?  (From reading the code, it appears that "next hop self" takes
effect on import.)

Best wishes,
Neil

next-hop-self for non-reflected routes only?

[Neil Jerram]

Hi - I have a topology like this, using BIRD 1.6.7:

   ---+  +--
AS 65001  |  | AS 65002
  |  |
  ++  |  | ++ iBGP
  | Router |---| Router |--- Router B
  | BIRD-A |  |  eBGP| | BIRD-B |--- Router C
  ++  |  | ++ .  .
  |  |.  .
  |  |
   ---+  +--

I want BIRD-B to reflect routes within its own AS, but also propagate
routes to and from AS 65001.  So for the eBGP peering I have

protocol bgp ra1 {
  description "Connection to BGP peer";
  local as 65002;
  gateway recursive;
  import all;
  export all;
  add paths on;
  connect delay time 2;
  connect retry time 5;
  error wait time 5,30;
  neighbor 172.31.1.2 as 65001;
}

and for the iBGP peerings

template bgp nodes {
  description "Connection to BGP peer";
  local as 65001;
  direct;
  gateway recursive;
  import all;
  export all;
  add paths on;
  graceful restart;
  connect delay time 2;
  connect retry time 5;
  error wait time 5,30;
  #next hop self;
}

protocol bgp node1 from nodes {
  neighbor 172.31.11.3 as 65001;
  rr client;
}

My question is how to get the ideal next-hop-self behaviour, which I
think is

- Do next-hop-self for routes from AS 65001 that are being passed on
  to Router B, C etc.  Otherwise those routes will be unreachable.

- Don't do next-hop-self for reflected routes.  Next-hop-self isn't
  needed here, because the downstream Router B, C etc are already
  directly connected.

Thanks in advance for any advice!

 Neil

Re: Debugging the RIP code

[Neil Jerram]

Hi Soan,

I'm afraid I don't have any experience myself with working on BIRD in
Windows; but probably it is possible, so I hope that other developers who
have done that will be able to help you.

Regards - Neil


On Fri, 18 May 2018, 10:12 Minh Soan Duong, <soa...@gmail.com> wrote:

> Hi Neil,
>
> Thank you very much for your reply.
>
> Actually, I would prefer to run it on Windows environment, which I am much
> familiar with. As far as my understanding, it does not matter if I just
> want to run a simple demo of a BIRD routing protocol. Am I correct?
>
> In case it is impossible to run on Windows, then yes, I can switch to
> Linux environment.
>
> Do you have any suggestion for me? And sorry for my dumb question.
>
> Best regards,
> Soan
>
> On Fri, May 18, 2018 at 6:57 PM, Neil Jerram <n...@tigera.io> wrote:
>
>> Hi Soan,
>>
>> Would it be possible for you to work on a GNU/Linux system instead?  I
>> believe that is what most BIRD developers do.
>>
>> Regards - Neil
>>
>>
>> On Fri, May 18, 2018 at 3:58 AM Minh Soan Duong <soa...@gmail.com> wrote:
>>
>>> Hi BIRD experts,
>>>
>>> My name is Soan Duong. I am a newbie of routing protocols, and of course
>>> of The BIRD internet routing daemon as well.
>>>
>>> I would like to get more understanding about one simple routing protocol
>>> (e.g. RIP) in BIRD by debugging the code step-by-step. However, I have got
>>> stuck at configuring the first step to run the code in Visual Studio C++.
>>>
>>> Could you guys please point me out how could I configure things in C++
>>> to starting debugging. Any help you have to offer would be greatly
>>> appreciated.
>>>
>>> Regards,
>>> Soan
>>>
>>> --
>>> DUONG Thi Minh Soan
>>> Skype: soan.duong
>>>
>>
>
>
> --
> DUONG Thi Minh Soan
> Computer Science Department,
> Faculty of Information Technology,
> Le Quy Don Technical University
>
> Vietnamese tel.: (+84) 0 983 588 613
> Skype: soan.duong
>

Re: Debugging the RIP code

[Neil Jerram]

Hi Soan,

Would it be possible for you to work on a GNU/Linux system instead?  I
believe that is what most BIRD developers do.

Regards - Neil


On Fri, May 18, 2018 at 3:58 AM Minh Soan Duong  wrote:

> Hi BIRD experts,
>
> My name is Soan Duong. I am a newbie of routing protocols, and of course
> of The BIRD internet routing daemon as well.
>
> I would like to get more understanding about one simple routing protocol
> (e.g. RIP) in BIRD by debugging the code step-by-step. However, I have got
> stuck at configuring the first step to run the code in Visual Studio C++.
>
> Could you guys please point me out how could I configure things in C++ to
> starting debugging. Any help you have to offer would be greatly appreciated.
>
> Regards,
> Soan
>
> --
> DUONG Thi Minh Soan
> Skype: soan.duong
>

Re: BIRD patches for IP-in-IP

[Neil Jerram]

And here are the patches :-)

On Tue, Sep 27, 2016 at 4:09 PM Neil Jerram <n...@tigera.io> wrote:

> Hi BIRD users!
>
> Attached are 3 patches that my team has been using for routing through
> IP-in-IP tunnels, rebased on 1.6.1.  I'd like to explain why we find them
> useful, and start a conversation about whether they or something like them
> could be upstreamed (or perhaps if there's some better way of achieving our
> aims).
>
> Calico [1] uses BIRD for BGP routing between the hosts in various cloud
> orchestration systems (Kubernetes, OpenStack etc.), to distribute routes to
> the pods/VMs/containers in those systems, each of which has its own IP.  If
> all the hosts are directly connected to each other, this is
> straightforward, but sometimes they are not.  For example GCE instances are
> not directly connected to each other: there is at least one router between
> them, that knows about routing GCE addresses, and to/from the Internet, and
> we cannot peer with it or otherwise tell it how to route pod/VM/container
> IPs.  So if we use GCE to create e.g. OpenStack compute hosts, with Calico
> networking, we need to do something extra to allow VM-addressed data to
> pass between the compute hosts.
>
> One of our solutions is to use IP-in-IP; it works as shown by this diagram:
>
>10.65.0.3 via 10.240.0.5 dev tunl0 onlink
>default via 10.240.0.1
>|
>  +-|--+ ++
>  | o  | ||
>  |   Host A   | ++  |   Host B   |
>  ||-| Router |--||
>  | 10.240.0.4 | ++  | 10.240.0.5 |
>  ||---. ||
>  ++|++
>^   ^   +---v---+|
>  src 10.65.0.2 |   |   | tunl0 ||
>  dst 10.65.0.3 |   |   +---+|
>|\  |v
>  +---+   ''   +---+
>  |   Pod A   |  src 10.240.0.4|   Pod B   |
>  | 10.65.0.2 |  dst 10.240.0.5| 10.65.0.3 |
>  +---+  --+---+
>  src 10.65.0.2
>  dst 10.65.0.3
>
> The diagram shows Pod A sending a packet to Pod B, using IP addresses that
> are unknown to the 'Router' between the two hosts.  Host A has an IP-in-IP
> device, tunl0, and a route that says to use that device for data to Pod B's
> address (10.65.0.3).  When the packet has passed through that device, it
> has a new outer IP header, with src 10.240.0.4 and dst 10.240.0.5, and is
> routed again according to the routing table - so now it can successfully
> reach Host B.
>
> So how is BIRD involved?  We statically program the local Pod route on
> each host:
>
> On Host A: 10.65.0.2 dev 
> On Host B: 10.65.0.3 dev 
>
> then run a BIRD BGP session between Host A and Host B to propagate those
> routes to the other host - which would normally give us:
>
> On Host A: 10.65.0.3 via 10.240.0.5
> On Host B: 10.65.0.2 via 10.240.0.4
>
> But we don't want those normal routes, because then the data would get
> lost at 'Router'.  So we enhance and configure BIRD as follows.
>
> - In the export filter for protocol kernel, for the relevant routes, we
> set an attribute 'krt_tunnel = tunl0'.
>
> - We modify BIRD, as in the attached patches, to understand that that
> means that those routes should have 'dev tunl0'.
>
> Then instead, we get:
>
> On Host A: 10.65.0.3 via 10.240.0.5 dev tunl0 onlink
> On Host B: 10.65.0.2 via 10.240.0.4 dev tunl0 onlink
>
> which allows successful routing of data between the Pods.
>
>
> Thanks for reading this far!  I now have three questions:
>
> 1. Does the routing approach above make sense?  (Or is there some better
> or simpler or already supported way that we could achieve the same thing?)
>
> 2. If (1), would the BIRD team accept patches broadly on the lines of
> those that are attached?
>
> 3. If (2), please let me know if the attached patches are already
> acceptable, or otherwise what further work is needed for them.
>
> Many thanks,
> Neil
>
>
From bed50e27dd14aa98a89a2c9e0e7a63a87bcaa830 Mon Sep 17 00:00:00 2001
From: Shaun Crampton <shaun.cramp...@metaswitch.com>
Date: Wed, 17 Jun 2015 16:14:41 -0700
Subject: [PATCH 3/3] D

BIRD patches for IP-in-IP

[Neil Jerram]

Hi BIRD users!

Attached are 3 patches that my team has been using for routing through
IP-in-IP tunnels, rebased on 1.6.1.  I'd like to explain why we find them
useful, and start a conversation about whether they or something like them
could be upstreamed (or perhaps if there's some better way of achieving our
aims).

Calico [1] uses BIRD for BGP routing between the hosts in various cloud
orchestration systems (Kubernetes, OpenStack etc.), to distribute routes to
the pods/VMs/containers in those systems, each of which has its own IP.  If
all the hosts are directly connected to each other, this is
straightforward, but sometimes they are not.  For example GCE instances are
not directly connected to each other: there is at least one router between
them, that knows about routing GCE addresses, and to/from the Internet, and
we cannot peer with it or otherwise tell it how to route pod/VM/container
IPs.  So if we use GCE to create e.g. OpenStack compute hosts, with Calico
networking, we need to do something extra to allow VM-addressed data to
pass between the compute hosts.

One of our solutions is to use IP-in-IP; it works as shown by this diagram:

   10.65.0.3 via 10.240.0.5 dev tunl0 onlink
   default via 10.240.0.1
   |
 +-|--+ ++
 | o  | ||
 |   Host A   | ++  |   Host B   |
 ||-| Router |--||
 | 10.240.0.4 | ++  | 10.240.0.5 |
 ||---. ||
 ++|++
   ^   ^   +---v---+|
 src 10.65.0.2 |   |   | tunl0 ||
 dst 10.65.0.3 |   |   +---+|
   |\  |v
 +---+   ''   +---+
 |   Pod A   |  src 10.240.0.4|   Pod B   |
 | 10.65.0.2 |  dst 10.240.0.5| 10.65.0.3 |
 +---+  --+---+
 src 10.65.0.2
 dst 10.65.0.3

The diagram shows Pod A sending a packet to Pod B, using IP addresses that
are unknown to the 'Router' between the two hosts.  Host A has an IP-in-IP
device, tunl0, and a route that says to use that device for data to Pod B's
address (10.65.0.3).  When the packet has passed through that device, it
has a new outer IP header, with src 10.240.0.4 and dst 10.240.0.5, and is
routed again according to the routing table - so now it can successfully
reach Host B.

So how is BIRD involved?  We statically program the local Pod route on each
host:

On Host A: 10.65.0.2 dev 
On Host B: 10.65.0.3 dev 

then run a BIRD BGP session between Host A and Host B to propagate those
routes to the other host - which would normally give us:

On Host A: 10.65.0.3 via 10.240.0.5
On Host B: 10.65.0.2 via 10.240.0.4

But we don't want those normal routes, because then the data would get lost
at 'Router'.  So we enhance and configure BIRD as follows.

- In the export filter for protocol kernel, for the relevant routes, we set
an attribute 'krt_tunnel = tunl0'.

- We modify BIRD, as in the attached patches, to understand that that means
that those routes should have 'dev tunl0'.

Then instead, we get:

On Host A: 10.65.0.3 via 10.240.0.5 dev tunl0 onlink
On Host B: 10.65.0.2 via 10.240.0.4 dev tunl0 onlink

which allows successful routing of data between the Pods.


Thanks for reading this far!  I now have three questions:

1. Does the routing approach above make sense?  (Or is there some better or
simpler or already supported way that we could achieve the same thing?)

2. If (1), would the BIRD team accept patches broadly on the lines of those
that are attached?

3. If (2), please let me know if the attached patches are already
acceptable, or otherwise what further work is needed for them.

Many thanks,
Neil

Re: Patch for IPv6 ECMP support?

[Neil Jerram]

Hi Mikhail,

I don't want to sound ungrateful, but that sounds a bit odd.  Is something
stopping you from posting the updated patch immediately?  I would really
appreciate it today, or as soon as possible after that.

Best wishes,
  Neil


On Sun, Aug 21, 2016 at 8:19 PM Mikhail Sennikovskii <
mikhail.sennikovs...@profitbricks.com> wrote:

> Hi Michael, Neil and all,
>
> Thanks for you interest in the patch. I'll try to post the updated patch
> version within the next few days.
>
> Mikhail
>
> 2016-08-20 2:55 GMT+03:00 Michael Elkins :
>
>> On Thu, Aug 18, 2016 at 06:39:24PM +0200, Arno Töll wrote:
>>
>>> Having that said, I am aware of at least another issue related to the
>>> route scan after an ECMP export, which we fixed internally in v3. In
>>> lack of interest, we did not bother to send it upstream so far.
>>> However, I will ask Mikhail to send it tomorrow, or I will do, so that
>>> other interested folks can at least find it on the list.
>>>
>>
>> Arno,
>>
>> I also wanted to voice interest in this work.  I've been testing the v2
>> patch, and I've encountered the bug you described (the multipath route gets
>> installed initially, but bird subsequently reports a sync error, and the
>> debug log indicates the multipath route is attempting to be reinstalled
>> indefinitely with error).
>>
>> Regards,
>>
>> Michael
>>
>>
>

Patch for IPv6 ECMP support?

[Neil Jerram]

Does anyone know what happened to this patch/discussion:
http://bird.network.cz/pipermail/bird-users/2016-February/010192.html

I believe it (or similar) is needed for IPv6 merge paths to work, and I'm
interested in that working.

Thanks,
 Neil

bird on Xenial doesn't restart after reboot

[Neil Jerram]

Is this the right place to report and discuss an apparent bug with
packaging in ppa:cz.nic-labs/bird ?  If not, please advise where would be
better.

If it is the right place...  I'd like to report that bird on Xenial doesn't
restart after a reboot, using bird version 1.6.0-1+xenial+1 from
http://ppa.launchpad.net/cz.nic-labs/bird/ubuntu xenial/main amd64.

It appears the package is a bit inconsistent in its init system handling:

- It installs init configuration files for SysV, upstart and systemd.

- Its postinst (install-time) script calls 'update-rc.d bird defaults' and
'invoke-rc.d bird start'.

On Xenial (which uses systemd), the invoke-rc.d call goes through to
systemd - or at least, systemctl status bird indicates running after an
'invoke-rc.d bird start', and inactive after an 'invoke-rc.d bird stop' -
but the update-rc.d call does not call on to 'systemctl enable bird'.
Hence the observation that bird is not restarted on reboot.

Thoughts?  From analogy with other packages (that are systemd-enabled when
installed), I think the fix may be as simple as:

- adding '--with systemd' to the dh invocation

- adding dh-systemd as a build dep.

Thanks,

 Neil