Re: Support for setting Aggregator IP/ASN in BGP Updates

[Ondrej Zajicek]

On Fri, Aug 16, 2019 at 12:21:18PM +0200, Clemens Mosig wrote:
> Hi all,
> 
> we are manually announcing and withdrawing prefixes by disabling and
> enabling a static protocol:
> E.g:
> 
> protocol static prefix{
>     ipv4;
>     route 1.2.3.0/24 blackhole;
> }
> 
> Is there a way to manually set the BGP AGGREGATOR IP address or ASN for
> the resulting announcements or withdraws?

Hi

I do not think there is a way to set BGP_AGGREGATOR attribute.

-- 
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: iBGP problem with full meshed routers

[Ondrej Zajicek]

On Mon, Aug 19, 2019 at 12:11:20AM +0200, Martin Bosner wrote:
> Hello Mike,
> 
> thank you for your reply. I also thought about that but since other routers
> (e.g. router E) can exchange routes with router A (routed over other BGPs)
> i don't think that we need static routes or OSPF. Or is that assumption
> wrong?

Routes received from multihop BGP must have BGP next hops resolvable through
non-recursive routes (e.g. static, OSPF or even direct BGP). So perhaps you
have appropriate direct BGP route on E, F, but not on G, H?


If you see this on G, H:
> > 223.230.128.0/22 unreachable [routerG_to_routerA 03:15:02.410 from
> > 153.92.124.4] * (100/-) [AS45609?]
> > ...
> > BGP.next_hop: 153.92.124.4

And this on E, F:

> > 223.230.128.0/22 unicast [routerE_to_routerA 02:42:58.878 from
> > 153.92.124.4] * (100/?) [AS45609?]
> > via 192.168.0.1 on external
> > ...
> > BGP.next_hop: 153.92.124.4

You should check 'show route for 153.92.124.4' on these machines to see
the route for BGP next hop.

-- 
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: Segmentation fault on 2.0.5

[Ondrej Zajicek]

On Sat, Aug 10, 2019 at 02:22:18PM +0300, Radu Anghel wrote:
> Hello,
> 
> I recently upgraded BIRD from 2.0.4 to 2.0.5 and with the same (pretty
> large) .conf I got Segmentation fault.
> 
> Until today I didn't have time to debug it, but here it goes:
> 
> With this simple .conf I get seg fault on 2.0.5 while 2.0.4 works as
> expected. (if I define myvar = true it doesn't crash on 2.0.5)
> 
> log syslog all;
> 
> define myvar = false;
> 
> function something () {
> if myvar then {
> return false;
> }
> 
> return true;
> }
> 
> protocol device DEVICE {
> 
> }
> 
> Could this be because of the new filter code or something else?

Hello

Thanks for bugreport. Yes, it is the new filter code, most likely
it is a bug in handling of statically eliminable (constant-false)
if statements without else branch.

Similar issue also happens for empty blocks:

  if true then { }

-- 
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: Anyone used 'missing lladdr' option?

[Ondrej Zajicek]

On Tue, Aug 06, 2019 at 10:10:58AM +0200, Milan Strakoš wrote:
> Hello,
> 
> we had problem with IPv6 prefixes exchanged from HP (or Huawei) router to
> linux router (BIRD) through IPv6 BGP RR (BIRD). And setting "missing lladdr
> ignore;" on the BGP RR on peer towards linux routers solved our problem.
> Otherwise the prefixes from HP/Huaweiu were not forwarded. And I didn't find
> how to configure HP/Huawei to fill lladdr in BGP updates.

This is case that would be OK as if we removed the option then we would
left the behavior on 'ignore'. But it makes me to realize that the
current default is 'drop' (for non-RS), so people who really need 'drop'
instead of 'ignore' likely do not know about it.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: IPsec (OSPFv3)

[Ondrej Zajicek]

On Mon, Jun 17, 2019 at 10:59:00AM +, Kenth Eriksson wrote:
> Hi!

Hi

Sorry for late reply, i finally got to answer some mails i missed in the
past due to my mail delivery issue:

https://bird.network.cz/pipermail/bird-users/2019-July/013549.html


> What is the plan for IPsec with regards to OSPFv3? Is it part of
> roadmap?

We do not have any plans for IPsec for OSPFv3. AFAIK, IPsec is not well
suited for multicast and RFC 7166 is a better solution for OSPFv3.

OTOH, it is something that seems to be easy to implement, as it is just
a few syscalls to configure manual SA entries. So patches are welcome.


> If not a roadmap item, what is the recommended way to get IPsec support
> for OSPFv3 with bird? libreswan?

Where was setkey command from ipsec-tools, which would likely allow
configuring manual SA entries necessary for OSPFv3, but it seems to be
abandoned.

I do not think that libreswan or other dynamic keying daemons are
applicable for OSPFv3 due to its multicast nature.

-- 
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: sets in bgpmasks ?

[Ondrej Zajicek]

On Tue, Aug 06, 2019 at 05:35:45PM +0200, Clemens Schrimpe wrote:
> 
> 
> > On 6. Aug 2019, at 17:04, Ondrej Zajicek  wrote:
> > 
> > I just added support for integer sets in bgpmasks (see attached patch).
> 
> Using this syntax:
> 
>   [= 123 [234, 345] * =]
> 
> ?

Yes, like regular integer sets.

-- 
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: sets in bgpmasks ?

[Ondrej Zajicek]

On Wed, Jul 31, 2019 at 10:34:48PM +0200, Clemens Schrimpe wrote:
> Hello all -
> 
> I wonder: Is there a "nice" syntax to have sets (lists of ASs) inside of 
> bgpmasks?
> 
> I.e.,
> 
>   [= 123 [234, 345] * =]
> 
> does not work (syntax error). Any other ideas?

Hello

I just added support for integer sets in bgpmasks (see attached patch).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
commit ef113c6f725349a2ab52f3cbef18403f82c84134
Author: Ondrej Zajicek (work) 
Date:   Tue Aug 6 16:58:13 2019 +0200

Filter: Allow to use sets in path masks

diff --git a/filter/config.Y b/filter/config.Y
index 8171a7c2..a67a72a8 100644
--- a/filter/config.Y
+++ b/filter/config.Y
@@ -801,6 +801,10 @@ bgp_path:
 bgp_path_tail:
NUM bgp_path_tail		{ $$ = f_new_inst(FI_CONSTANT, (struct f_val) { .type = T_PATH_MASK_ITEM, .val.pmi = { .asn = $1, .kind = PM_ASN, }, }); $$->next = $2;  }
  | NUM DDOT NUM bgp_path_tail	{ $$ = f_new_inst(FI_CONSTANT, (struct f_val) { .type = T_PATH_MASK_ITEM, .val.pmi = { .from = $1, .to = $3, .kind = PM_ASN_RANGE }, }); $$->next = $4; }
+ | '[' set_items ']' bgp_path_tail {
+   if ($2->from.type != T_INT) cf_error("Only integer sets allowed in path mask");
+   $$ = f_new_inst(FI_CONSTANT, (struct f_val) { .type = T_PATH_MASK_ITEM, .val.pmi = { .set = build_tree($2), .kind = PM_ASN_SET }, }); $$->next = $4;
+ }
  | '*' bgp_path_tail		{ $$ = f_new_inst(FI_CONSTANT, (struct f_val) { .type = T_PATH_MASK_ITEM, .val.pmi = { .kind = PM_ASTERISK }, }); $$->next = $2; }
  | '?' bgp_path_tail		{ $$ = f_new_inst(FI_CONSTANT, (struct f_val) { .type = T_PATH_MASK_ITEM, .val.pmi = { .kind = PM_QUESTION }, }); $$->next = $2; }
  | bgp_path_expr bgp_path_tail	{ $$ = $1; $$->next = $2; }
diff --git a/filter/test.conf b/filter/test.conf
index 9abd76f3..04074965 100644
--- a/filter/test.conf
+++ b/filter/test.conf
@@ -626,6 +626,7 @@ bgppath p2;
 	bt_assert(p2 !~ [8, ten..(2*ten)]);
 	bt_assert(p2 ~ [= * 4 3 * 1 =]);
 	bt_assert(p2 ~ [= (3+2) (2*2) 3 2 1 =]);
+	bt_assert(p2 ~ [= 5 [2, 4, 6] 3 [1..2] 1 =]);
 	bt_assert(p2 ~ mkpath(5, 4));
 
 	bt_assert(p2.len = 5);
diff --git a/nest/a-path.c b/nest/a-path.c
index a1b7c42f..4ee34cf4 100644
--- a/nest/a-path.c
+++ b/nest/a-path.c
@@ -740,6 +740,31 @@ pm_match(struct pm_pos *pos, u32 asn, u32 asn2)
   return 0;
 }
 
+static int
+pm_match_set(struct pm_pos *pos, struct f_tree *set)
+{
+  struct f_val asn = { .type = T_INT };
+
+  if (! pos->set)
+  {
+asn.val.i = pos->val.asn;
+return !!find_tree(set, );
+  }
+
+  const u8 *p = pos->val.sp;
+  int len = *p++;
+  int i;
+
+  for (i = 0; i < len; i++)
+  {
+asn.val.i = get_as(p + i * BS);
+if (find_tree(set, ))
+  return 1;
+  }
+
+  return 0;
+}
+
 static void
 pm_mark(struct pm_pos *pos, int i, int plen, int *nl, int *nh)
 {
@@ -824,13 +849,17 @@ as_path_match(const struct adata *path, const struct f_path_mask *mask)
 	  val2 = mask->item[m].to;
 	  goto step;
 	case PM_QUESTION:
+	case PM_ASN_SET:
 	step:
 	  nh = nl = -1;
 	  for (i = h; i >= l; i--)
 	if (pos[i].mark)
 	  {
 		pos[i].mark = 0;
-		if ((mask->item[m].kind == PM_QUESTION) || pm_match(pos + i, val, val2))
+		if ((mask->item[m].kind == PM_QUESTION) ||
+		((mask->item[m].kind != PM_ASN_SET) ?
+		 pm_match(pos + i, val, val2) :
+		 pm_match_set(pos + i, mask->item[m].set)))
 		  pm_mark(pos, i, plen, , );
 	  }
 
diff --git a/nest/attrs.h b/nest/attrs.h
index 4efcff79..a17b8c05 100644
--- a/nest/attrs.h
+++ b/nest/attrs.h
@@ -60,16 +60,18 @@ static inline struct adata *as_path_prepend(struct linpool *pool, const struct a
 #define PM_ASTERISK	2
 #define PM_ASN_EXPR	3
 #define PM_ASN_RANGE	4
+#define PM_ASN_SET	5
 
 struct f_path_mask_item {
   union {
 u32 asn; /* PM_ASN */
 struct f_line *expr; /* PM_ASN_EXPR */
+struct f_tree *set; /* PM_ASN_SET */
 struct { /* PM_ASN_RANGE */
   u32 from;
   u32 to;
 };
-  }; 
+  };
   int kind;
 };
 

Re: BIRD 2.0.5 build failures on RHEL/CentOS 6 and 7

[Ondrej Zajicek]

On Tue, Aug 06, 2019 at 12:37:49AM +0200, Robert Scheck wrote:
> Hello Ondrej,
> 
> On Mon, 05 Aug 2019, Ondrej Zajicek wrote:
> > I think we started to require newer bison (although it should be checked
> > by configure and complained there). We aim to be compatible with 5 year
> > old systems, but RHEL/CentOS 6 is too old even for that.
> 
> while this is a good pointer indeed, it's unfortunately wrong. Using bison
> 3.0.4 (same version like RHEL/CentOS 7 uses) still leads to the same error.
> 
> But following your pointer in general, I figured out that GCC 4.4.x causes
> the error, while GCC 4.8.x works. Looks like BIRD depends on a feature from
> GCC 4.5 (or newer, I didn't track this down further). Thanks though!

Yes, that is true. We probably should add some checks for that.


> > Not sure about that, it works on CentOS 7 in our Gitlab test build.
> > 
> > It seems like our configure script improperly adds -flto even if CFLAGS /
> > LDFLAGS are expliclty set, and it is incompatible with your flags.
> 
> Sounds like a bug in the configure script then, may you have a look to it,
> please?

Fixed, see attached patch.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
commit 8c42205e35e24537122a4c821bd3128d698abf1b
Author: Ondrej Zajicek (work) 
Date:   Tue Aug 6 14:53:02 2019 +0200

Configure: CFLAGS update

 - add -flto only to default CFLAGS
 - add -fno-strict-aliasing, -fno-strict-overflow always
 - remove -Wno-implicit-fallthrough

diff --git a/configure.ac b/configure.ac
index 14dbcd52..7e8578ab 100644
--- a/configure.ac
+++ b/configure.ac
@@ -137,27 +137,27 @@ if test "$enable_pthreads" != no ; then
   fi
 fi
 
+# This is assumed to be necessary for proper BIRD build
+CFLAGS="$CFLAGS -fno-strict-aliasing -fno-strict-overflow"
+
 if test "$bird_cflags_default" = yes ; then
   BIRD_CHECK_GCC_OPTION([bird_cv_c_option_wno_pointer_sign], [-Wno-pointer-sign], [-Wall])
   BIRD_CHECK_GCC_OPTION([bird_cv_c_option_wno_missing_init], [-Wno-missing-field-initializers], [-Wall -Wextra])
-  BIRD_CHECK_GCC_OPTION([bird_cv_c_option_fno_strict_aliasing], [-fno-strict-aliasing])
-  BIRD_CHECK_GCC_OPTION([bird_cv_c_option_fno_strict_overflow], [-fno-strict-overflow])
+
+  if test "$enable_debug" = no; then
+BIRD_CHECK_LTO
+  fi
+
+  if test "$bird_cv_c_lto" = yes; then
+CFLAGS="$CFLAGS -flto"
+LDFLAGS="$LDFLAGS -flto=4"
+  fi
 
   CFLAGS="$CFLAGS -Wall -Wextra -Wstrict-prototypes -Wno-parentheses"
   BIRD_ADD_GCC_OPTION([bird_cv_c_option_wno_pointer_sign], [-Wno-pointer-sign])
   BIRD_ADD_GCC_OPTION([bird_cv_c_option_wno_missing_init], [-Wno-missing-field-initializers])
-  BIRD_ADD_GCC_OPTION([bird_cv_c_option_fno_strict_aliasing], [-fno-strict-aliasing])
-  BIRD_ADD_GCC_OPTION([bird_cv_c_option_fno_strict_overflow], [-fno-strict-overflow])
 fi
 
-if test "$enable_debug" = no; then
-  BIRD_CHECK_LTO
-fi
-
-if test "$bird_cv_c_lto" = yes; then
-  CFLAGS="$CFLAGS -flto"
-  LDFLAGS="$LDFLAGS -flto=4"
-fi
 
 AC_MSG_CHECKING([CFLAGS])
 AC_MSG_RESULT([$CFLAGS])
@@ -387,9 +387,6 @@ if test "$enable_debug" = yes ; then
   AC_CHECK_LIB([efence], [malloc])
 fi
   fi
-else
-  BIRD_CHECK_GCC_OPTION([bird_cv_c_option_wno_implicit_fallthrough], [-Wno-implicit-fallthrough])
-  BIRD_ADD_GCC_OPTION([bird_cv_c_option_wno_implicit_fallthrough], [-Wno-implicit-fallthrough])
 fi
 
 CLIENT=birdcl

Re: BIRD 2.0.5 build failures on RHEL/CentOS 6 and 7

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 09:35:43PM +0200, Robert Scheck wrote:
> Hello all,
> 
> I'm seeing the following build failures with BIRD 2.0.5 on RHEL/CentOS 6,
> while BIRD 2.0.4 worked fine (just did a BIRD version bump, not more):

> --- snipp ---
> BUILDSTDERR: obj/conf/cf-parse.y: In function 'cf_parse':
> BUILDSTDERR: obj/conf/cf-parse.y:1918: error: unknown field 'asn' specified 
> in initializer
> BUILDSTDERR: obj/conf/cf-parse.y:1918: warning: missing braces around 
> initializer
> BUILDSTDERR: obj/conf/cf-parse.y:1918: warning: (near initialization for 
> '(anonymous).val.pmi.')

Hi

I think we started to require newer bison (although it should be checked
by configure and complained there). We aim to be compatible with 5 year
old systems, but RHEL/CentOS 6 is too old even for that.


> And even building on RHEL/CentOS 7 fails now (also just a BIRD version
> bump):
>
> --- snipp ---
> BUILDSTDERR: /usr/bin/ld: /tmp/ccZUW9JI.ltrans0.ltrans.o: relocation 
> R_X86_64_32 against `.rodata' can not be used when making a shared object; 
> recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: /tmp/ccZUW9JI.ltrans1.ltrans.o: relocation 
> R_X86_64_32 against hidden symbol `sk_class.61292' can not be used when 
> making a shared object
> BUILDSTDERR: /usr/bin/ld: /tmp/ccZUW9JI.ltrans2.ltrans.o: relocation 
> R_X86_64_32 against `.rodata' can not be used when making a shared object; 
> recompile with -fPIC
> BUILDSTDERR: /usr/bin/ld: /tmp/ccZUW9JI.ltrans3.ltrans.o: relocation 
> R_X86_64_32 against `.rodata' can not be used when making a shared object; 
> recompile with -fPIC
> --- snapp ---

Not sure about that, it works on CentOS 7 in our Gitlab test build.

It seems like our configure script improperly adds -flto even if CFLAGS /
LDFLAGS are expliclty set, and it is incompatible with your flags.

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


signature.asc
Description: PGP signature

Re: Option --runstatedir in BIRD 2.0.4 broken?

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 07:57:49PM +0200, Robert Scheck wrote:
> On Fri, 29 Mar 2019, Ondrej Zajicek wrote:
> > On Fri, Mar 29, 2019 at 01:08:18AM +0100, Robert Scheck wrote:
> > > + ./configure --build=x86_64-redhat-linux-gnu 
> > > --host=x86_64-redhat-linux-gnu --program-prefix= 
> > > --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr 
> > > --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> > > --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> > > --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> > > --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird
> > > BUILDSTDERR: configure: error: unrecognized option: 
> > > `--runstatedir=/run/bird'
> > 
> > Yes, you are right. Thanks for notifying us. Seems like releases 1.6.6
> > and 2.0.4 have configure scripts that were inadvertently generated with
> > older autoconf without 'runstatedir' option support.
> > 
> > Workaround is either to regenerate configure using 'autoreconf' from
> > proper autoconf tool, or just use older 'with-runtimedir' option.
> 
> I just wanted to let you know that this issue hasn't been fixed for 2.0.5,
> unfortunately.

Yes, i just noticed that after the release. Sorry, we missed that.
Unfortunately it is something that we cannot fix in advance in git (as
configure script is generated during release by autoconf), autoconf
developers cannot make a new release in 7 years, so in some distros there
is a patched autoconf (supporting runstatedir option) and in others there
is the original one. When the release is generated on such system, it
does not have this option.

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


signature.asc
Description: PGP signature

Re: BIRD 2.0.5 and 1.6.7

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 07:07:37PM +0200, Vincent Bernat wrote:
>  ❦  5 août 2019 18:28 +02, Ondrej Zajicek :
> 
> >> You mean I can do:
> >> 
> >> protocol bgp XXX {
> >>  neighbor;
> >>  interface eth0;
> >>  /* ... */
> >> }
> >> 
> >> ?
> >
> > No, you need to specify neighbor link-local address
> > (i probably misunderstood your point):
> >
> > protocol bgp XXX {
> >   neighbor fe80::1 external;
> >   interface eth0;
> > }
> 
> Oh, OK, not as convenient as specifying an interface. I wonder how FRR
> is getting the remote IP. Maybe it's automatically in the neighbor table
> due to neighbor advertisements?

For BGP autodiscovery, there are currently two drafts:

draft-acee-idr-lldp-peer-discovery-05
draft-xu-idr-neighbor-autodiscovery-10

One could also do some hacks like listening for router advertisements.

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


signature.asc
Description: PGP signature

Re: BIRD 2.0.5 and 1.6.7

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 06:03:53PM +0200, Vincent Bernat wrote:
>  ❦  5 août 2019 17:24 +02, Ondrej Zajicek :
> >> Notably:
> >> 
> >>  - establish a BGP session using an interface name and the associated
> >>link-local IPv6 address,
> >
> > This is already supported since long time.
> 
> You mean I can do:
> 
> protocol bgp XXX {
>  neighbor;
>  interface eth0;
>  /* ... */
> }
> 
> ?

No, you need to specify neighbor link-local address
(i probably misunderstood your point):

protocol bgp XXX {
  neighbor fe80::1 external;
  interface eth0;
}

or 

protocol bgp XXX {
  neighbor fe80::1%eth0 ;
}


For passive mode, you could probably use (since 2.0.5) dynamic BGP
with link-local addresses:

protocol bgp XXX {
  neighbor range fe80::/64 external;
  interface eth0;
}

(Although i did not test this feature with link-local addresses,
i thought more about IBGP route reflectors)

It is a bit ugly for a PtP link, It is true that a simple BGP protocol
that accept any peer IP from that interface could also makes sense.
I did not notice that.


> >>  - implement RFC5549 (IPv4 NLRI with an IPv6 next-hop)
> >
> > This is supported since 2.0.0 in BGP, but there is still no support
> > in Linux kernel (AFAIK) and in Kernel protocol.
> 
> Cumulus chose to implement it without support in the kernel by using
> link-local IPv4 addresses and static ARP entries. I don't know how
> standard and interoperable this is.

Hmm, that seems like an ugly hack with a lot of work in userspace.

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


signature.asc
Description: PGP signature

Re: BIRD 2.0.5 and 1.6.7

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 04:52:25PM +0200, Vincent Bernat wrote:
>  ❦  5 août 2019 09:54 +02, Ondrej Filip :
> 
> >   o BGP: Dynamic BGP
> >   o BGP: Promiscuous ASN mode
> 
> That's great! Is there a roadmap for additional features around that?

In future, I would like to implement automatic BGP neighbor discovery,
like draft-xu-idr-neighbor-autodiscovery-10.

> Notably:
> 
>  - establish a BGP session using an interface name and the associated
>link-local IPv6 address,

This is already supported since long time.

>  - implement RFC5549 (IPv4 NLRI with an IPv6 next-hop)

This is supported since 2.0.0 in BGP, but there is still no support
in Linux kernel (AFAIK) and in Kernel protocol.

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


signature.asc
Description: PGP signature

Anyone used 'missing lladdr' option?

[Ondrej Zajicek]

Hi

I just noticed that since transition to 2.0, BGP option 'missing lladdr'
is not implemented. I wonder if anyone used this option or whether we
should just remove it.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: BIRD 2.0.5 and 1.6.7

[Ondrej Zajicek]

On Mon, Aug 05, 2019 at 12:13:06PM +0400, Dmitry Melekhov wrote:
> 05.08.2019 11:54, Ondrej Filip пишет:
> > Dear BIRD users,
> > we just released two new versions - 1.6.7 and 2.0.5. Many thanks
> > to Santiago and Maria!
> > 
> > Version 1.6.7
> >o BFD: Support for VRFs
> >o Several bugfixes
> > 
> > Version 2.0.5
> >o OSPF Graceful restart (RFC 3623, RFC 5187)
> >o BGP: Dynamic BGP
> >o BGP: Promiscuous ASN mode
> >o BGP: Mandatory option for channels
> >o BFD: Support for VRFs
> >o Graceful restart command
> >o Redesigned filtering code
> >o Many bugfixes
> > 
> >Notes:
> > 
> > Previous version introduced an error in handling of OSPF NSSA-LSA,
> > causing compatibility issues with proper implementations. The error is
> > fixed in this version, therefore there are compatibility issues in
> > OSPF NSSA areas between this and previous version.
> > 
> 
> Hello!
> 
> Is bug in  OSPF NSSA-LSA fixed on both versions? Or only in 2.0?

Hello

The bug was introduced in 2.0.4 and fixed in 2.0.5, it does not appear
in 1.6.x branch.

There is a slight aberration in NSSA behavior in pre-2.0.4 versions
(including 1.6.x), but that does not seem to have compatibility issues.

-- 
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] RPKI: fix allocation of hostname when using an IPv6 address

[Ondrej Zajicek]

Thanks, merged.

-- 
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: segmentation fault

[Ondrej Zajicek]

On Sun, Jul 28, 2019 at 06:58:06PM +0500, Илья Шипицин wrote:
> hello,
> 
> I'm running bird git-master
> 
> ...
> on SIGHUP sometimes bird crashes
> 
> 
> (gdb) bt
> #0  _IO_vfprintf_internal (s=0x0, format=0x4ddaf9 "%s <%s> ",
> ap=ap@entry=0x7f9954af06d8)

...

> in case someone interested, please have a look

Hello

Thanks for the bugreport, could you send me a coredump and a binary?

-- 
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: Limitation on stubnet prefixes

[Ondrej Zajicek]

On Fri, Jul 26, 2019 at 03:32:04PM +0200, Andre Cunha wrote:
> Thanks Ondrej, that makes sense.  Is there a way to add routes on the
> fly then, instead of putting them all in the config file? Or any other
> suggestion on how I could generate 5 type-1 LSA. 

You can just add add them as static routes in the config file and use
reconfigure to add/remove on the fly, or you could learn them from
an auxiliary kernel table using kernel protocol (and add them on the
fly to the kernel routing table using ip command).

-- 
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: Limitation on stubnet prefixes

[Ondrej Zajicek]

On Fri, Jul 26, 2019 at 10:49:31AM +0200, Andre Cunha wrote:
> Hello, 
> 
> Is there a limit on the number of stubnet prefixes that we can configure?  I 
> have configured 5 stubnets but my router receives only 1084 routes. 

Hello

Yes, stubnet prefixes are announced as a part of the Router-LSA, with
12 B per prefix. With 16bit Router-LSA length, the limit is about 5400
Router-LSA entries (including other entries than just stubnets). But note
that having such large Router-LSA may cause many problems, including OSPF
packet fragmentation, so i would generally suggest to not have larger
Router-LSA than MTU, i.e. not more than ~100 entries.

This length limit is not enforced in BIRD, if you configure more
stubnets, the Router-LSA with length modulo 64k is generated, which
may be invalid. I should add some check and warning there.

External routers are announced as separate External-LSAs, so there is no
such limit for them.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."


signature.asc
Description: PGP signature

Re: OSPF MD5 Authentication Fails When Using Instance ID

[Ondrej Zajicek]

On Thu, Jul 25, 2019 at 06:46:01PM +, St. Hilaire, Joshua wrote:
> OSPF MD5 authentication appears to fail with an unknown auth type 1026
> when you specify an "instance ID" in BIRD, regardless of whether you
> specify the instance ID on the interface or not. Removing all occurrences
> of "instance ID" from bird.conf and re-committing the configuration
> appears to restore the correct auth type "cryptographic (2)". BIRD
> configuration and tcpdump info below.

Hi

See this: http://trubka.network.cz/pipermail/bird-users/2019-March/013218.html

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


signature.asc
Description: PGP signature

Debian packages for BIRD 2

[Ondrej Zajicek]

Hello

Several days ago i received info that BIRD 2.0.4 is now packaged
in Debian (unstable):

  https://packages.debian.org/sid/bird2

Thanks to Ondrej Sury and others.

-- 
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: NSSA translate TYPE7->TYPE5

[Ondrej Zajicek]

On Thu, Jul 18, 2019 at 03:07:21PM +0200, Konrad Kręciwilk wrote:
> Hello
> 
> In practice AREA6 contains much more routes (about 150), I send a small
> segment. The same router (R1) has other area NSSA - AREA61:

Hello

Could you build BIRD 1.6.6 with attached patch (which adds some more log
messages related to NSSA translation) and send me an output?

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/proto/ospf/rt.c b/proto/ospf/rt.c
index 368e3d05..7231dddb 100644
--- a/proto/ospf/rt.c
+++ b/proto/ospf/rt.c
@@ -1055,22 +1055,29 @@ decide_nssa_lsa(struct ospf_proto *p UNUSED4 UNUSED6, ort *nf, struct ospf_lsa_e
 
   if (!rt_is_nssa(nf) || !oa->translate)
 return 0;
+  log(L_INFO "NSSA   1");
 
   /* Condensed area network found */
   if (fib_route(>enet_fib, nf->fn.prefix, nf->fn.pxlen))
 return 0;
+  log(L_INFO "NSSA   2");
 
   if (!en || (en->lsa_type != LSA_T_NSSA))
 return 0;
+  log(L_INFO "NSSA   3");
 
   /* We do not store needed data in struct orta, we have to parse the LSA */
   lsa_parse_ext(en, ospf_is_v2(p), rt);
 
+  log(L_INFO "NSSA   X %I %x %x", rt->fwaddr, (uint) rt->propagate, (uint) rt->pxopts);
+
   if (rt->pxopts & OPT_PX_NU)
 return 0;
+  log(L_INFO "NSSA   4");
 
   if (!rt->propagate || ipa_zero(rt->fwaddr))
 return 0;
+  log(L_INFO "NSSA   5");
 
   return 1;
 }
@@ -1098,6 +1105,9 @@ check_nssa_lsa(struct ospf_proto *p, ort *nf)
 }
   }
 
+  if (rt_is_nssa(nf))
+log(L_INFO "NSSA net %I/%d %d", nf->fn.prefix, nf->fn.pxlen, nf->n.oa->translate);
+
   /* RFC 3103 3.2 (3) - originate the aggregated address range */
   if (anet && anet->active && !anet->hidden && oa->translate)
 ospf_originate_ext_lsa(p, NULL, nf, LSA_M_RTCALC, anet->metric,

Re: BIRD 2.0.4 and protocol RPKI in the config file

[Ondrej Zajicek]

On Fri, Jul 19, 2019 at 04:29:11PM +0200, Irene Lalioti wrote:
> Hello Maria!
> 
> I am coming back to you to just ask you what else we need except for the
> libssh enable in the spec file of bird in the rpm, so that we have the
> RPKI functionality in the 2.0.4.

Hello

You do not really need to explicitly enable it by configure option, it is
autodetected. What you really need is libssh header files during
compilation. You see whether libssh was found and RPKI support was compiled
in from the output of configure:

checking for libssh/libssh.h... yes
...
BIRD was configured with the following options:
...
Routing protocols:  bfd babel bgp mrt ospf perf pipe radv rip rpki 
static

But if you use --enable-libssh, then configure would fail if there are no
libssh headers.

> With my colleague we tried to build the rpm package after adding the
> enable libssh :
> 
> %build
> %configure --prefix=%{_prefix} \
>    --sysconfdir=%{_sysconfdir} \
>    --localstatedir=%{_localstatedir}
>    --enable-libssh

Note that you do not have backslash after --localstatedir option,
so i am not sure whether --enable-libssh option was passed to configure.


> and then we installed it.
> 
> Or maybe it is impossible to do it ourselves ? :)

And does it work?

-- 
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: bfd does not work in a vrf

[Ondrej Zajicek]

On Thu, Jul 18, 2019 at 04:23:00PM +0200, Alexander Zubkov wrote:
> Hi,
> 
> I have attached a patch to check if there are any vrf-base bfd
> protocols. And if there are none of them, then protocol non-vrf bfd
> protocols takes all sessions. Otherwise it takes only non-vrf
> sessions. I added a global option into config structure, but not sure
> if it is an approved way of doing things like that.

Hi

I would rather keep it in the current state until we would have some
better / generic solution. The issue with BFD is analogous with other
protocols, e.g. OSPF - if OSPF is configured for VRF on all interfaces,
then it is enabled for all interfaces inside the VRF, but when it is
configured without VRF on all interfaces, then it is enabled for all
interfaces, regardless whether they are a part of any VRF or not.

Therefore, we need a way to specify that a protocol is root/master/outer-VRF
only, e.g. 'vrf root' option. Implementation would be easy, just not sure
what is a proper term for that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: lib/printf regression on raspberry

[Ondrej Zajicek]

On Wed, Jul 17, 2019 at 10:33:32PM +0200, Maximilian Eschenbacher wrote:
> Hey everyone,
> 
> the following patch creates a testcase on top of the master branch for
> bsprintf with %lR which fails on both my raspberrys (Raspbian Buster,
> armv6l and armv7l, gcc version 8.3.0). I noticed it by looking at

Hi

Thanks for the bugreport, here is a patch that should fix the issue.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/lib/printf.c b/lib/printf.c
index c2065d9a..8f2cccb3 100644
--- a/lib/printf.c
+++ b/lib/printf.c
@@ -356,14 +356,14 @@ int bvsnprintf(char *buf, int size, const char *fmt, va_list args)
 			if (qualifier == 'l') {
 X = va_arg(args, u64);
 bsprintf(ipbuf, "%02x:%02x:%02x:%02x:%02x:%02x:%02x:%02x",
-	((X >> 56) & 0xff),
-	((X >> 48) & 0xff),
-	((X >> 40) & 0xff),
-	((X >> 32) & 0xff),
-	((X >> 24) & 0xff),
-	((X >> 16) & 0xff),
-	((X >> 8) & 0xff),
-	(X & 0xff));
+	 (uint) ((X >> 56) & 0xff),
+	 (uint) ((X >> 48) & 0xff),
+	 (uint) ((X >> 40) & 0xff),
+	 (uint) ((X >> 32) & 0xff),
+	 (uint) ((X >> 24) & 0xff),
+	 (uint) ((X >> 16) & 0xff),
+	 (uint) ((X >> 8) & 0xff),
+	 (uint) (X & 0xff));
 			}
 			else
 			{

Re: bfd does not work in a vrf

[Ondrej Zajicek]

On Wed, Jul 17, 2019 at 03:08:45PM +0200, Alexander Zubkov wrote:
> On Wed, Jul 17, 2019 at 2:47 PM Ondrej Zajicek  wrote:
> > Hello
> >
> > This would work, it is necessary to also set sk->vrf for bfd_open_tx_sk()
> > foir multihop BFD. It is not necessary to handle it in bfd_reconfigure(),
> > as VRF change is handled in generic code in proto_reconfigure().
> >
> > I also just implemented BFD request dispatch based on VRFs to handle 
> > multiple
> > VRFs and multiple BFD instances.
> 
> Oh! I was just trying to figure out it myself today too. See the
> attached patch. :)

Your patch is correct and mostly the same as mine [*]. There are just
two differences:

 - There was check in BFD code that forbade multiple BFD instances, that
   has to be removed.

 - I allowed request in VRF to be handled by BFD protocol in default/NULL VRF.
   That would make it compatible with one BFD and net.ipv4.udp_l3mdev_accept=1.

   Note that it was true that wildcard socket bind in default VRF blocked
   bind in other VRFs, so it would not be possible to run BFD in both
   default VRF and regular VRFs, but that was fixed in Linux kernel 5.0,
   so perhaps it would make sense to change it that BFD in default VRF
   only accept requests from default BFD, like in your patch.


[*] 
https://gitlab.labs.nic.cz/labs/bird/commit/cf7ff99513728e4e405508e5ccd7522289d4ec82

-- 
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: bfd does not work in a vrf

[Ondrej Zajicek]

On Wed, Jul 17, 2019 at 12:05:49PM +0200, Alexander Zubkov wrote:
> Hello,
> 
> I made small fix for myself, that allow bfd to work in one VRF,
> defined in the configuration:
> 
> --- a/proto/bfd/packets.c
> +++ b/proto/bfd/packets.c
> @@ -413,6 +413,7 @@ bfd_open_rx_sk(struct bfd_proto *p, int multihop, int af)
>sk->type = SK_UDP;
>sk->subtype = af;
>sk->sport = !multihop ? BFD_CONTROL_PORT : BFD_MULTI_CTL_PORT;
> +  sk->vrf = p->p.vrf;
>sk->data = p;
> 
>sk->rbsize = BFD_MAX_LEN;
> 
> It works, but I suppose vrf change should be handled somehow in
> bfd_reconfigure also. Not sure if reopening socket is enough or it

Hello

This would work, it is necessary to also set sk->vrf for bfd_open_tx_sk()
foir multihop BFD. It is not necessary to handle it in bfd_reconfigure(),
as VRF change is handled in generic code in proto_reconfigure().

I also just implemented BFD request dispatch based on VRFs to handle multiple
VRFs and multiple BFD instances.

-- 
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: bfd does not work in a vrf

[Ondrej Zajicek]

Hello

Yes, this is currently not implemented properly, i forgot about it.
Would require some substantial work. There are two possibilities:

- Multiple BFD instances, each in VRF, with proper dispatch of BFD
requests to instances based on VRF.

- One BFD instance, with multiple listening sockets, each with
appropriate VRF. That would require more work.

-- 
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: NSSA translate TYPE7->TYPE5

[Ondrej Zajicek]

> Hello,
>
> I have problem with selective no-translation TYPE7 LSA to TYPE5 LSA on ABR.
> Scheme: https://ibb.co/mhbxwmy


Hello

Just tested that, works for me (with routes from your example). What is
your output of 'show ospf state'? Don't you have any suspicious messages
in logs?

-- 
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-users] Optional attribute error peering BGP with FRR

[Ondrej Zajicek]

On Thu, Jul 11, 2019 at 04:23:18PM +0200, Ondrej Zajicek wrote:
> On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
> > Derrick,
> > 
> > Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)
> > 
> > > From the pcap this looks like FRR is sending an empty NLRI and
> > > according to RFC 2858:
> > > 
> > >An UPDATE message that carries no NLRI, other than the one encoded in
> > >the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
> > >If such a message contains the NEXT_HOP attribute, the BGP speaker
> > >that receives the message should ignore this attribute.
> > > 
> > > So the enclosed pcap looks correct too me as that we are sending a
> > > default route to our peer to be pointed back at us.
> > 
> > [0]: https://tools.ietf.org/html/rfc4760
> > 
> > Ondrej: Possible bird is checking for an NEXT_HOP field to be present in the
> > mentioned BGP Update Message?
> 
> Hi
> 
> BIRD is generally doing revised error handling per RFC 7606, so most
> attribute errors are treated by handled by treat-as-withdraw policy
> instead of optional attribute error.
> 
> By quick view i found only a few case that could generate optional
> attribute error: MP_REACH_NLRI / MP_UNREACH_NLRI of invalid (too small)
> length and NEXT_HOP (or next-hop part of MP_REACH_NLRI) of unrecognized
> length.
> 
> Is any of this in the pcap file? Could you send me a pcap file?

Sorry for confusion, i just checked the pcap file and it is definitely
the NEXT_HOP attribute missing with regular NLRI present.

While in BIRD 2.0.4 this is handled by treat-as-withdraw, in BIRD 2.0.2
it was still handled by Optional attribute error notification.

-- 
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-users] Optional attribute error peering BGP with FRR

[Ondrej Zajicek]

On Thu, Jul 11, 2019 at 04:01:19PM +0200, Hansen, Christoffer wrote:
> Derrick,
> 
> Donald is right. Ignore earlier comment. (rfc4760[0], p. 5)
> 
> > From the pcap this looks like FRR is sending an empty NLRI and
> > according to RFC 2858:
> > 
> >An UPDATE message that carries no NLRI, other than the one encoded in
> >the MP_REACH_NLRI attribute, should not carry the NEXT_HOP attribute.
> >If such a message contains the NEXT_HOP attribute, the BGP speaker
> >that receives the message should ignore this attribute.
> > 
> > So the enclosed pcap looks correct too me as that we are sending a
> > default route to our peer to be pointed back at us.
> 
> [0]: https://tools.ietf.org/html/rfc4760
> 
> Ondrej: Possible bird is checking for an NEXT_HOP field to be present in the
> mentioned BGP Update Message?

Hi

BIRD is generally doing revised error handling per RFC 7606, so most
attribute errors are treated by handled by treat-as-withdraw policy
instead of optional attribute error.

By quick view i found only a few case that could generate optional
attribute error: MP_REACH_NLRI / MP_UNREACH_NLRI of invalid (too small)
length and NEXT_HOP (or next-hop part of MP_REACH_NLRI) of unrecognized
length.

Is any of this in the pcap file? Could you send me a pcap file?

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

Mailing list delivery issue

[Ondrej Zajicek]

Hello

I just noticed that for about last 3 weeks, mails from bird-users mailing
list are not delivered to me. Still working on the issue. So excuse me
for not answering to your mails earlier.

-- 
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] Doc: fix typo in BGP dynamic names feature description

[Ondrej Zajicek]

Thanks, merged.

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

Which linux OS are you using?

[Ondrej Zajicek]

> Hi all and support,
> Which OS you prefer to install BIRD2.0?

Hi

It is mostly developed and tested on Debian, so i would recommend that.

Although BIRD supports both Linux and BSDs, Linux support is generally
better.

-- 
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] Add CLI command to test reconfiguration status

[Ondrej Zajicek]

On Thu, Jun 13, 2019 at 11:29:32AM +, Kenth Eriksson wrote:
> The reply text for reply code 3 (CONF_DONE) is "Daemon is up and
> running". Is that on purpose? I would have expected something like
> "Re-configuration done" or similar. 

Yes, because the same message is reported after start, when there is no
previous reconfiguration. Therefore "Re-configuration done" would be
confusing.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: [PATCH 2/3] Fix issue where cli socket buffer may get full

[Ondrej Zajicek]

On Wed, Jun 12, 2019 at 07:29:51AM +, Kenth Eriksson wrote:
> > Also, better way to handle 1/3 is to add condition on line io.c line
> > 2211, so that if we have full buffer, we do not try to check POLLIN,
> > so that we do not even call sk_read() in such case instead of try it
> > to handle from inside sk_read().
> > 
> Ok, I can update patch 1/3 so that is not included in the pollset if
> the io buffer is full. Will repost, so that you can review. But I still
> don't see reading 0 shall close the socket as reading 0 is not an
> error. Shall we combine the two patches to get a more robust solution?

My position is that sk_read() should depend on result of internal read()
and not on external information like POLLIN status.

But how to distinguish reading 0 as a result of socket close from other
cases? Also, the issue of empty buffer could be simply handled by return
0 from sk_read() just before the read(). If there is no space in buffer,
then there is no point to call read().

I will look at the patches and merge something reasonable.

-- 
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] Add CLI command to test reconfiguration status

[Ondrej Zajicek]

On Wed, Jun 12, 2019 at 11:08:36AM +, Kenth Eriksson wrote:
> > Hi
> > 
> > We could add this feature, but it should also report more cases
> > (the submitted patch covers just first two):
> > 
> >  - progress
> >  - done
> >  - progress+queued
> >  - config timeout running
> > 
> The first two could be added without any refactoring. I'm not sure the
> latter two can be done without some refactoring. But I can revisit
> later and see if it is possible. But at least having progress and done
> solves many issues since we want to know when reconfiguration is
> complete. Are you willing to let it go upstream with only the first two
> included?

Hi

I do not like merging partial implementations and revisiting that later,
as that often means changing user-visible behavior of existing features,
which is something we try to avoid.

Therefore, i just finished it [*]. Also, i did not use messages from
cmd_reconfig_msg(), as these are appropriate as answers to requests, but
not as status reports. But used the same reply codes, to ease parsing.

[*] see commit 9106a750cd76d4a76c7a60294ce3a43eede166c9

> > Also i am not 100% sure if separate 'configure status' command is
> > necessary, perhaps it could be part of 'show status'. But i have no
> > strong strong feeling one way or the other.
> > 
> Would prefer 'configure status', it makes sense to keep configure
> request command and its status together. Also the 'show status' is
> composed of lots of other stuff, making it harder to parse out when
> remote controlling bird.

OK

-- 
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: Code style?

[Ondrej Zajicek]

On Tue, Jun 11, 2019 at 01:37:42PM +, Kenth Eriksson wrote:
> Is there a code style guide to be used when submitting patches to bird?
> An emacs file, clang-format or similar would be useful. 

Hi

Well, historically different parts of BIRD used different coding styles,
now we try to converge on 2 columns per indentation, Allman style
(opening brace on new line). Canonical way to indent to X-th column is
by X/8 tabs and X%8 spaces.

For EMACS, it is:

(setq-default c-default-style "bsd")
(setq-default c-basic-offset 2)

-- 
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] Add CLI command to test reconfiguration status

[Ondrej Zajicek]

On Tue, Jun 11, 2019 at 02:58:33PM +0200, Kenth Eriksson wrote:
> This adds the CLI command 'configure status' so that it is possible to
> check if reconfiguration is done.

Hi

We could add this feature, but it should also report more cases
(the submitted patch covers just first two):

 - progress
 - done
 - progress+queued
 - config timeout running

Also i am not 100% sure if separate 'configure status' command is
necessary, perhaps it could be part of 'show status'. But i have no
strong strong feeling one way or the other.

-- 
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: radv/OpenWRT: "propagate routes yes" syntax error

[Ondrej Zajicek]

On Tue, Jun 11, 2019 at 07:33:45AM +0200, Marvin Gaube wrote:
> Hello,
> 
> I'm currently trying to run bird6 on a Gluon-Device (Gluon is build upon
> OpenWRT) to announce Router Advertisments. I need to announce more
> specific routes,
> ...
> Every time I'm trying to start bird with "propagate routes yes" it says
> that there's a syntax error in this line. Without - announcing only the
> default route - everything works fine.
> 
> The exact version is 1.6.3 on OpenWRT 18.02.
> 
> Has anyone an idea on how to solve this? I didn't found this as "known
> bug" yet.

Hello

The 'propagate routes' feature is supported since version 1.6.4, so not
available in your case.

-- 
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: Introduce Wireguard support to bird

[Ondrej Zajicek]

On Fri, Jun 07, 2019 at 06:21:42PM +, Janne Heß wrote:
> Hey everyone,
> 
> as advertised, I have completed the Wireguard support.
> You might see that I am not really a C expert, but I hope the code is good 
> enough.
> If you need me to change anything or have additional questions, just let me 
> know.

Hi

Could you explain what the Wireguard support broadly does (compared to
regular route update)?

-- 
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: adding MED to + bgp_med

[Ondrej Zajicek]

On Wed, Jun 05, 2019 at 11:30:25PM +0200, Łukasz Trąbiński wrote:
> 
> Hi again
> 
> I answer myself. "bgp_med = bgp_med + 100” works only when "rs client” is 
> set. Is it feature or bug?

Hi

It works the same in 1.6.4 and 1.6.6. But you are right that it does not
on regular EBGP sessions. That is a feature, as MED received from one AS
should not be propagated to another AS, therefore BIRD resets it before
BGP export filter (and new MED should be set there, if it is needed).

In BIRD 2.0, the behavior is slightly different - we do not reset MED
before export filter, but after export filter and only if it was not
modified in the filter. Therefore, your example would work there.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: How to determine when reconfiguration is complete?

[Ondrej Zajicek]

On Tue, Jun 04, 2019 at 09:04:39PM +0200, Cybertinus wrote:
> > Hi!
> > 
> > How can I tell when bird is done with reconfiguration? E.g. bird can
> > respond: "Reconfiguration in progress", but how do you know when it is
> > ready? Invoking configure again will trigger full re-configure again I
> > guess?

Hi

Yes, if you do configre again while in progress, then re-configure request is 
queued.

> Hello Kenth,
> 
> A line in the logging would be useful indeed :).

I do not know about interactive way, but there is a line in the log about that:

2019-06-05 01:40:57.531  Reconfiguring
2019-06-05 01:40:57.531  device1: Reconfigured
2019-06-05 01:40:57.531  direct1: Reconfigured
2019-06-05 01:40:57.531  bgp1: Reconfigured
2019-06-05 01:40:57.531  Reconfigured

The first line means reconfiguration started, the last line means it is
finished. There may still be some asynchronous work running (like
re-evaluating filters on routes if they were changed), but for all
purposes the new config is active and BIRD is in regular state.

-- 
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: Submitting code? (Wireguard)

[Ondrej Zajicek]

On Thu, May 30, 2019 at 09:16:42PM +, Janne Heß wrote:
> Hey everyone,
> 
> I wrote code that adds Wireguard support (new kernelspace VPN) to Bird 2.
> The problem is that with the cryptokey routing of Wireguard, it needs to know 
> which IPs are behind which peers.
> The patch does exactly that: If the interface is a wireguard interface, try 
> modifying the list of IPs.
> So my question is: How do I contribute that? I think the feature would be 
> useful for other people, so having it upstream would be nice.
> Should I just post the patch here? Or create a GitLab PR? PR would probably 
> be more convenient due to the discussion feature, but I'm unable to fork the 
> project because my project limit is at 0.
> Could you give me information on how to contribute the code?

Hi

Feature seems interesting.

Just post the patch to the mailing list, preferably 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: [PATCH] Fix an issue where bird may accidently close a socket

[Ondrej Zajicek]

On Mon, May 27, 2019 at 03:29:26PM +, Kenth Eriksson wrote:
> On Mon, 2019-05-27 at 17:12 +0200, Ondrej Zajicek wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> > 
> > 
> > On Mon, May 27, 2019 at 02:28:52PM +0200, Kenth Eriksson wrote:
> > > Datagram sockets may return 0 and stream sockets can return 0
> > > if the requested number of bytes to read is 0.
> > 
> > Hi
> > 
> > You mean that if count arg to read() is 0?
> > 
> > How that may happen?
> > 
> We have a client remote controlling bird using a socket that did get
> get POLLHUP, maybe due to that bird closed the socket. 
>
> Don't think checking for 0 is enough, from man page;  

Hi

Did you examine the possible causes of why BIRD closed the socket?
That could be done by adding log messages to sk_read(), perhaps limited
to cases when s->type == SK_UNIX. The man page describes two additional
cases, so it is a good idea to try to distinguish which one happened.

Also, i don't think that check for POLLHUP is correct, as that flag
generally means socket is closed for write, not that it is closed for
read (although some OSes are less consistent in this matter than others).

This is particularly fragile part of code, depends on OS API details, so
i would avoid to do changes there unless we are 100% sure that they are
proper fix for some confirmed condition.


> "When a stream socket peer has performed an orderly shutdown, the
> return value will be 0 (the traditional "end-of-file" return).
> 
> Datagram sockets in various domains (e.g., the UNIX and Internet
> domains) permit zero-length datagrams.  When such a datagram is
> received, the return value is 0.

Well, we open the socket as SOCK_STREAM and not SOCK_DGRAM, so i would
expect this case does not apply. (Although i have no idea what would happen
if the other side opens the socket with SOCK_DGRAM.)

And even if this case would happen, we should ignore it and not fall back
to call_rx_hook() path.


> The value 0 may also be returned if the requested number of bytes to
> receive from a stream socket was 0."

This case means that we called read() with (s->rpos == s->rbuf + s->rbsize),
buffer is full and last call_rx_hook() does not eat data from it. That
means something is wrong, e.g. an incomplete message filled the entire
buffer and without resizing buffer we would just end in endless loop,
therefore closing the connection with error is safest thing to do.

-- 
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] Fix an issue where bird may accidently close a socket

[Ondrej Zajicek]

On Mon, May 27, 2019 at 02:28:52PM +0200, Kenth Eriksson wrote:
> Datagram sockets may return 0 and stream sockets can return 0
> if the requested number of bytes to read is 0.

Hi

You mean that if count arg to read() is 0?

How that may happen?

-- 
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: Simple two bird BGPs two Uplinks one Peering Provider config

[Ondrej Zajicek]

On Mon, May 20, 2019 at 05:17:08PM +, Yves Illi wrote:
> Hi there,
> 
> I am really new to the complete topic of BGP. So please have a bit mercy with 
> me if I ask something very stupid. But I am trying to build that for the 
> first time ever and I am feeling like a donkey in front of a big mountain.
> 
> Last but not least it is currently running, but I guess its more luck than 
> something else. Like I said I am completely new to the topic of BGP. What I 
> don't get is how I configure them together so they work (as a HA-Cluster) and 
> currently I can only route a.b.c.249/29 instead of a.b.c.0/22.

Hi

> protocol static static_bgp {
>   ipv4;
>   route a.b.c.0/22 via d.e.f.124;
> }

I think this is the problem, as d.e.f.124 is your local address, then
this route is probably not allowed locally (because you should not have
route directing to a local address) and therefore likely not propagated
to BGP.

Simple solution is to have the static route defined as unreachable route:

  route a.b.c.0/22 unreachable;

You would have more specific routes in the routing table anyways and when
the unreachable route is propagated by BGP, the local address will be
attached as next hop automatically.

-- 
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 add paths to select only equal routes

[Ondrej Zajicek]

On Wed, May 15, 2019 at 07:51:55PM +0200, Alexander Zubkov wrote:
> Hello,
> 
> If "add paths" config option is enabled for a bgp protocol than it
> sends every route matching the filter on export. But I would like to
> have an option to send only the best route with routes similar to it
> (equal localpref, aspath length, ...). Like it is done in the kernel
> protocol and its "merge paths" option. So for example if I had 2
> routes for the same prefix with different bgp_local_pref or bgp_path
> length, than only the route with better attributes would be announced
> to the peer. Currently both routes would be announced.

Hello

That is true. For BGP ADD_PATH, all routes that pass filters are
exported. We prefer to not add more export modes (like one for "merge
paths") as that significantly complicates a part of code that is already
too complicated. We plan to do some redesign there that should make it
much simpler, so perhaps after that.

Also, how such mode should behave and how much should be configurable?
For example, "merge paths" applies to routes that are the same up to
(including) IGP metric, on the contrary a basic use case for BGP ADD_PATH
is to exchange feasible routes to/from route reflector and avoid issue
with inconsistency and route hiding due to IGP metric being different on
different speakers. For this case it would make sense to export routes
with inferior IGP metric (and less important attributes), but not ones
with inferior bgp_local_pref or bgp_path length.

-- 
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: Received route with strange next-hop

[Ondrej Zajicek]

On Wed, May 15, 2019 at 09:09:34AM +, Adrichem, N.L.M. (Niels) van wrote:
> Hello,
>
> Additionally, the bird.log file throws the following error:
> 2019-05-15 10:27:21.869  Started
> 2019-05-15 10:27:21.902  Missing broadcast address for interface vxlan0
> 2019-05-15 10:27:29.329  KRT: Received route 10.0.1.3/32 with strange 
> next-hop 10.0.1.4
> 

> It may be that kernel protocol rejects the route because the next-hop
> is not in the interface its regular netmask (which is set to /32), though
> I am not familiar enough with the source code to determine the exact
> cause except that the error gets thrown from sysdep/linux/netlink.c line
> 1643. However, I think the line should be accepted since there is another
> routing rule confirming that the next-hop is directly attached to device
> eth1. Given the explicit error I don't think this is a configuration
> error (though I am open to learn more), so I hope BIRD can be patched to
> solve this.

Hello

BIRD generally expects that next hop is resolvable through an address range
associated with interfaces, not just through another direct/device route.

This is limitation compared to the Linux kernel which allows next hop
resolvable through another direct/device route (but not through another
regular route with next-hop).

We have some plans to redesign it in a more generic manner, but it is not
a simple fix. As a workaround, attached patch (untested) should disable
next hop checking for all alien routes.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c
index d773743d..d5d64b6b 100644
--- a/sysdep/linux/netlink.c
+++ b/sysdep/linux/netlink.c
@@ -1632,7 +1632,7 @@ nl_parse_route(struct nl_parse_state *s, struct nlmsghdr *h)
 	  if ((i->rtm_family == AF_INET6) && ipa_in_netX(ra->nh.gw, (net_addr *) ))
 	return;
 
-	  if (i->rtm_flags & RTNH_F_ONLINK)
+	  if ((i->rtm_flags & RTNH_F_ONLINK) || (krt_src == KRT_SRC_ALIEN))
 	ra->nh.flags |= RNF_ONLINK;
 
 	  neighbor *nbr;

Re: show route for ... filtered (not working)

[Ondrej Zajicek]

On Mon, May 13, 2019 at 07:12:53AM -0700, Terra Nova wrote:
> Hi Alexander,
> 
> On Sun, May 12, 2019 at 12:21 AM Alexander Zubkov  wrote:
> 
> > Hi,
> >
> > I suppose it could happen because "for" is looking for an active route
> > for the given destination. And filtered routes would not be matched.
> >
> I was leaning in that direction as well, however in the canonical sense,
> using the keyword 'filtered' should have removed that constraint and
> returned the filtered + non-active route.  At this point, I don't know if
> current behavior is the intended behavior.

Hi

This seems to be unintended behavior, but it is hard to say what should
be the intended behavior. I see three possible behaviors:

1) Explicitly forbid this combination (like combination of 'filtered' and
'export' is forbidden).

2) Find and show longest-match between filtered routes.

3) Find longest-match between both valid and filtered routes,
show it only if it is filtered.

-- 
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: 'prefer older' does not work?

[Ondrej Zajicek]

On Mon, May 13, 2019 at 12:49:06PM +0300, Alexander Shikov wrote:
> Hello!
> 
> All of our BGP peers have 'prefer older' option enabled. 
> But I noticed that best route is not the oldest one:

Hi

The option 'prefer older' is a bit misnomer, it does not mean the one
with the oldest timestamp, but it means 'prefer current best route'.

So if route A was selected first, then route B was updated, and then route A
was updated again (so it has more recent timestamp), then route A is still
selected.

-- 
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: ibgp bird 1.6 vs 2.0

[Ondrej Zajicek]

On Tue, Apr 30, 2019 at 04:02:36PM +0200, Matěj Grégr wrote:
> 
> 
> On 30.04.2019 15:56, Ondrej Zajicek wrote:
> > On Tue, Apr 30, 2019 at 03:34:59PM +0200, Matěj Grégr wrote:
> >> Hello,
> >>   we have encountered a different ibgp behavior between bird 1.6 and
> >> bird2, and I am not sure if it's an intentional change in bird2 or a
> >> bug. Let's consider the following topology:
> >>
> >>   192.168.1.0/24   192.168.2.0/24
> >>  R1 --- ebgp --- R2 --- ibgp --- R3
> >>.2 .1   .1  .2
> >>
> >> R1 uses AS 65001, R2 and R3 uses AS 65000. R1 propagates some routes
> >> (e.g. 10.10.10.0/24) via eBGP to R2, which sends them to R3 via iBGP.
> >> bird2 config on R3:
> >>
> >> template bgp IBGP {
> >> local as 65000;
> >> direct;
> >> ipv4 {
> >> next hop self;
> >> import keep filtered on;
> >> import all;
> >> };
> >> }
> >>
> >> protocol bgp from IBGP { neighbor 192.168.2.1 as 65000; }
> > 
> > What bird is config on R2?
> > 
> > I don't think there are any intentional changes w.r.t. your config.
> > 
> 
> R2 is not running bird, but it's a cisco router, but we encounter the
> same behavior with other vendors as well (HP). The config is pretty
> simple on R2:

OK, the question is whether R2 is using something like 'next hop self'.
Based on the config i assume that no, and therefore BGP_NEXT_HOP announced
from R2 to R3 is probably 192.168.1.2.

> Now there are two issues:
> 
> 1) the bird on R3 reports "Invalid NEXT_HOP attribute" and doesn't learn
> any R1 routes from R2. If the "direct" option is removed from the
> config, R3 will learn R1 routes. However, if R3 runs bird1.6, it learns
> all routes even with the direct option.
>
> According to the docs, "direct" is a check for directly connected
> neighbors. The neighbor 192.168.2.1 is directly connected and in the
> same subnet, so I don't understand, why there is an issue with NEXT_HOP
> and why are routes silently dropped on R3?

'direct' is not only the check for directly connected, but also specifies
default value for 'gateway' option (direct vs. recursive). In 'gateway
direct' mode we expect BGP_NEXT_HOP to be directly connected.

I checked the code and we have fallback in BIRD 1.6 that if BGP_NEXT_HOP
is not directly connected, we silently ignore it and use IP address of
the neighbor. We removed this fallback in BIRD 2.0 and instead report the
error. So it was intentional change. You could workaround that by setting
'next hop self' (or equivalent) on R2.

> 
> 2) If direct is removed from the config, bird2 on R3 learns R1 routes,
> but with status unreachable. Even if I send 192.168.1.0/24 from R2 to R3
> so the route 192.168.1.0/24 is in R3's routing table and ping from R3 to
> the NEXT_HOP IP address is successful. bird1.6 works without a problem
> with or without direct option and all routes are learned and reachable.

This is a limitation in BIRD that it resolves recursive next hops (from
multihop BGP) only through non-recursive routes (e.g. static or OSPF
routes). So if you announce 192.168.1.0/24 through the same BGP session,
it is not used for this purpose. But i am sure the same behavior was also
in BIRD 1.6. The workaround is to have static/RIP/OSPF route for
192.168.1.0/24, or 'next hop self' on R2.

-- 
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: ibgp bird 1.6 vs 2.0

[Ondrej Zajicek]

On Tue, Apr 30, 2019 at 03:34:59PM +0200, Matěj Grégr wrote:
> Hello,
>   we have encountered a different ibgp behavior between bird 1.6 and
> bird2, and I am not sure if it's an intentional change in bird2 or a
> bug. Let's consider the following topology:
> 
>   192.168.1.0/24   192.168.2.0/24
>  R1 --- ebgp --- R2 --- ibgp --- R3
>.2 .1   .1  .2
> 
> R1 uses AS 65001, R2 and R3 uses AS 65000. R1 propagates some routes
> (e.g. 10.10.10.0/24) via eBGP to R2, which sends them to R3 via iBGP.
> bird2 config on R3:
> 
> template bgp IBGP {
> local as 65000;
> direct;
> ipv4 {
> next hop self;
> import keep filtered on;
> import all;
> };
> }
> 
> protocol bgp from IBGP { neighbor 192.168.2.1 as 65000; }

What bird is config on R2?

I don't think there are any intentional changes w.r.t. your config.

-- 
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: Full (regression) test suite?

[Ondrej Zajicek]

On Sat, Apr 27, 2019 at 10:53:44PM +0200, Robert Scheck wrote:
> Hello Ondrej,
> hello Maria,
> 
> On Fri, 26 Apr 2019, Ondrej Zajicek wrote:
> > The suite of basic unit tests can be run by 'make test'.
> 
> that one fails for BIRD 2.0.4 on RHEL/CentOS 7 on ppc64 (big endian) like
> this:
> 
> [...]
> obj/lib/fletcher16_test: t_fletcher16_compute[FAIL] 
> obj/lib/fletcher16_test: t_fletcher16_checksum   [FAIL] 
> obj/lib/fletcher16_test  [FAIL] 
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1532/34501532/build.log for
> build logs. https://koji.fedoraproject.org/koji/taskinfo?taskID=34501529 in
> case you would like to compare output of different architectures.
> 
> And: It also fails on Fedora 31 on s390x in the same way like for ppc64.
> 
> https://kojipkgs.fedoraproject.org//work/tasks/1613/34501613/build.log and
> https://koji.fedoraproject.org/koji/taskinfo?taskID=34501608 for details.
> 
> Just let me know if I can be helpful somehow in tracking them down, even my
> gdb knowledge is quite limited.

Hi

Seems like you compile it with your CFLAGS. There are compiler options
which we expect there to be: -fno-strict-aliasing -fno-strict-overflow

Although it probably is not relevant to this test, BIRD should always be
build with these.

Also, could you try run the test manually:

  ./obj/lib/fletcher16_test -vv

?

It is possible that it is just a bug in the test, we should add there
some explicit test vectors instead of comparison with straightforward
implementation.


Also, if you could add these options (which we usually use):

 -Wno-parentheses -Wno-pointer-sign -Wno-missing-field-initializers

It would eliminate plenty of irrelevant build warnings.

-- 
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] Nest: "Last route change" timestamp for routing tables

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 10:54:34AM +, Tom Petty wrote:
> I¹ve written a patch which adds a ³last route change² timestamp to the
> routing table statistics. This diff is against the Œmaarten¹ branch, where
> the code adding the ³show table statistics² command is currently located.

Hi

Seems like the patch was mangled by e-mail client, could you send it as 
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: static default route not always pushed to kernel (2.0.4)

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 03:46:09PM +, Kenth Eriksson wrote:
> On Mon, 2019-04-29 at 15:42 +0200, Ondrej Zajicek wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> > 
> > 
> > On Mon, Apr 29, 2019 at 01:01:13PM +, Kenth Eriksson wrote:
> > > > 'ip' tool, perhaps harder in other cases). It would be great if
> > > > there
> > > > existed sysctl option for default IPv4 route metric.
> > > > 
> > > 
> > > There is no overwrite involed here. The default route in the kernel
> > > here has metric 100. As you said, bird pushes with metric 32 so it
> > > should push again.
> > 
> > Well, i misread your mail. If i understand it correctly, the issue is
> > not that routes are not pushed into kernel, but that they are not
> > pushed into master table. I guess you have two routes for the same
> > network in one static protocol. That is not valid case, although
> > we are missing error checks for that configuration.
> > 
> > You could either use two separate static protocol instances, or you
> > could use this patch:
> > 
> > https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.labs.nic.cz%2Flabs%2Fbird%2Fcommit%2F9861dba5230da539e6ce7d2b6baa4f2631556d09data=02%7C01%7CKenth.Eriksson%40infinera.com%7C64122b5318634277203a08d6cca89074%7C285643de5f5b4b03a1530ae2dc8aaf77%7C1%7C0%7C636921421691874991sdata=pdNajX29Hwlbsdk5gfH%2BlYIzQaEidqw4qRuedW2%2BohI%3Dreserved=0
> > 
> 
> That patch did not work for me, still same issue. I had to add DISTANCE
> to the CF_KEYWORDS to make it compile. But is it anything else that is
> required?

Hi

The patch should be more-or-less all that is required, but it is not fully
ready for master branch, so it has a bit awkward behavior. Namely it requires
that preference is specified without '=', like in example i provided:

> >   route 0.0.0.0/0 via 10.210.137.1 { preference 220; };
> >   route 0.0.0.0/0 via 192.168.120.1 { preference 230; };

If you used the same config like without patch (i.e. with 'preference = XXX'),
it would not work.


> I thought two prefixes differing only on metric should be perfectly
> valid? The kernel accepts that, so why would bird not?

Mainly implementation reasons. In BIRD, preference is generally not part
of key, therefore route update for one network could replace a route for
route with different preference (which makes sense with filter-based
dynamic preference).

Traditionally BIRD supported in one routing table one route per network
and protocol instance. With BGP ADD_PATH extension the key was extended
with arbitrary u32 distinguisher, which in BGP case is the path ID value
from BGP ADD_PATH, but most other protocols does not use that. The patch
above uses preference as distinguisher in case of static routes.

-- 
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: RFC8203bis

[Ondrej Zajicek]

On Tue, Apr 30, 2019 at 01:24:50AM +0300, Alexander Azimov wrote:
> Hi all,
> 
> I've just submitted a two-line patch to make BIRD compliant with RFC8203bis
> :
> https://github.com/BIRD/bird/pull/5
> 
> Please let me know if you have any questions.

Thanks, will merge.

-- 
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: static default route not always pushed to kernel (2.0.4)

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 01:01:13PM +, Kenth Eriksson wrote:
> > 'ip' tool, perhaps harder in other cases). It would be great if there
> > existed sysctl option for default IPv4 route metric.
> > 
> 
> There is no overwrite involed here. The default route in the kernel
> here has metric 100. As you said, bird pushes with metric 32 so it
> should push again. 

Well, i misread your mail. If i understand it correctly, the issue is
not that routes are not pushed into kernel, but that they are not
pushed into master table. I guess you have two routes for the same
network in one static protocol. That is not valid case, although
we are missing error checks for that configuration.

You could either use two separate static protocol instances, or you could use 
this patch:

https://gitlab.labs.nic.cz/labs/bird/commit/9861dba5230da539e6ce7d2b6baa4f2631556d09

That allows multiple routes for the same network with different
preferences (with explicit preference parameter) in one static protocol
instance, e.g.:

  route 0.0.0.0/0 via 10.210.137.1 { preference 220; };
  route 0.0.0.0/0 via 192.168.120.1 { preference 230; };

-- 
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: RFC7772 Unicast RAdv Replies

[Ondrej Zajicek]

On Sun, Apr 28, 2019 at 06:14:58AM +0200, Martin Weinelt wrote:
> Hi all,
> 
> we're users of Birds RAdv implementation in a mesh networking project
> with many opportunistic WiFi users on mobile devices.
> 
> We and our users would likely profit from a reduced rate of router
> advertisments that we see as a result from high client turnover.
> 
> RFC7772¹ describes in 5.1:

Hi

Thanks for suggestion, will look into that. Unicast RADV responses
make sense.

-- 
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: Static dormant routes not shown

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 09:11:22AM +, Kenth Eriksson wrote:
> Hi!
> 
> Why does not static routes in dormant state show of up in the routing
> table? I expexted all routes to be visible in 'show route'. If the
> route is not installed into the kernel, then that should be some way
> (in bird case I believe that is the exclamation mark).

Hi

The original design is that only valid routes are in the routing table
and protocols are responsible for adding or removing routes when they
become or ceased to be valid. Later that was bit changed with recursive
BGP routes, which are there always and routing table is responsible
for recomputing next hops, but the basic design is still here for regular
routes.

I agree that it would make sense to have more uniform approach here, like
having routes with invalid / unreachable next hops in the routing table,
but not propagating them, and perhaps we will change to that in the
future. OTOH, there are other reasons why static routes are dormant -
next hop is reachable but iface is link-down, or route has BFD trigger
and assoicated BFD session is down.

The exclamation mark is more like route should be installed into kernel,
but installation failed. If route is not supposed to be installed (e.g.
rejected by kernel export), there is no exclamation mark.

-- 
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] BGP: Output Local AS number in show protocol

[Ondrej Zajicek]

On Mon, Apr 29, 2019 at 09:46:56AM +0200, Jan-Philipp Litza wrote:
> This eases the implementation of agents implementing the SNMP-BGP MIB,
> which requires the local AS of a session to be specified.

Thanks, will merge.

-- 
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 2.0.4 segfaulting on ARM

[Ondrej Zajicek]

On Fri, Apr 26, 2019 at 01:08:24PM +0200, lor...@irmhil.de wrote:
> Hello,
> 
> after a "make clean", "./configure" and "make" I got this compile-time
> warning:

Hello

Could you try to build it with "./configure --enable-debug" ?


> --- snip ---
> 
> sysdep/unix/io.c: In function ‘times_init’:
> sysdep/unix/io.c:135:45: warning: comparison is always false due to limited 
> range of data type [-Wtype-limits]
>if ((ts.tv_sec < 0) || (((s64) ts.tv_sec) > ((s64) 1 << 40)))
>  ^
> --- snap ---

This warning is OK.

-- 
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: Full (regression) test suite?

[Ondrej Zajicek]

On Fri, Apr 26, 2019 at 11:16:09AM +0200, Robert Scheck wrote:
> Hello Maria,
> 
> On Fri, 26 Apr 2019, Maria Matějka wrote:
> > We have a test environment (much limited) for running basic configuration 
> > patterns and a suite of basic unit tests. 
> 
> is somewhere documented how to run this one? For the very first step, I
> would like to run it as part of the RPM builds at Fedora and EPEL on all
> build architectures (currently i686, x86_64, armv7hl, aarch64, ppc64le
> and s390x) to see where we end up at the moment.

Hi

The suite of basic unit tests can be run by 'make test'.

-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Wed, Apr 24, 2019 at 01:10:31PM +, Joakim Tjernlund wrote:
> On Tue, 2019-04-23 at 21:03 +, Joakim Tjernlund wrote:
> > On Tue, 2019-04-23 at 19:33 +0200, Ondrej Zajicek wrote:
> > > On Tue, Apr 23, 2019 at 12:40:04PM +, Joakim Tjernlund wrote:
> > > > > I think the standard just does not consider the case of 'unnumbered'
> > > > > link with both local and remote address but without subnet and assumes
> > > > > 'real' unnumbered PtP link with no local IP address associated with
> > > > > the iface.
> > > > 
> > > > There is always some local address, in linux you have to assign it to 
> > > > the I/F,
> > > > but in others, like Cisco, you can assign an IP address to a dummy I/F 
> > > > and then
> > > > tell unnumbered I/Fs to use the dummy I/Fs' IP address.
> > > > There has to be some SRC IP address on pkgs sent by OSPF
> > > 
> > > Yes, but the way how the RFC is written it (IMHO) assumes the second case 
> > > -
> > > unnumbered ifaces using SRC IP from some dummy iface. Therefore stub
> > 
> > yes, the second case, agreed.
> > 
> > > node is associated with the dummy iface and not with the unnumbered PtP 
> > > iface.
> > 
> > No, this is a true unnumbered I/F(it has no local IP address) and will not 
> > generate
> > any stub route.
> > 
> > > 
> > > > Since Linux always has an local IP adress it is not possible to deduce 
> > > > if the
> > > > user intended the link to be unnumbered or not, unless one wants to add 
> > > > explicit
> > > > config "unnumbered", it would be best to assume unnumbered I think.
> > > 
> > > I do not understand what you mean in this article. Linux could have 
> > > active iface
> > > without any IP address and it can be used for PtP link (with SRC IP from 
> > > some
> > > other iface), but it is not implemented in BIRD.
> > 
> > I expressed myself badly, I meant if one want to have control over what SRC 
> > ip is used,
> > you need to have it on the local I/F. Maybe there is a way to do that these 
> > days differently
> > but I don't think any PtoP impl. on Linux uses that.
> > 
> > > It is true that even a link with local /32 IP without specified remote 
> > > peer could
> > > be used for OSPF PtP link. BIRD in this case assumes it is a stub /32 and 
> > > i am not
> > > sure whether it could be configured as regular PtP. I did not realized 
> > > before that
> > > this is a relevant case for PtP link.
> > 
> > This case is as close one gets to a true unnumbered I/F in Linux I think 
> > and pppd supports
> > such links. I think should treat /32 links as unnumbered even if there is 
> > an remote
> > IP address or make it configurable.
> > 
> > > > Consider the use case with many /32 ptp links, all with the same local 
> > > > IP, there would
> > > > be a lot of redundant host routes in the Router LSA. Better to let the 
> > > > user
> > > > add an explicit stub network for all PtoP's if one needs it.
> > > 
> > > Well, that is solvable by not putting the same stub multiple times in the
> > > Router LSA.
> > 
> > Maybe but since it is the remote ip one puts here you will only save 
> > "space" when
> > you have multiple ptop links between the same two routers.
> > 
> > > More debatable is a case like this:
> > > 
> > > eth0 10.0.0.1/24
> > > eth1 10.0.0.1/32 peer 10.0.1.1/32
> > > 
> > > 10.0.0.1 is already reachable by route for eth0 (either stub or network),
> > > so it is technically not necessary to have it in the Router LSA as
> > > a separate /32 stub. So it makes sense to me to have it configurable
> > > with three values: yes, no, if-not-covered.
> > 
> > Yes, this is what I was getting at too. Maybe have a conf option 
> > "unnumbered" to treat
> > eth1 as a "true" unnumbred I/F(no stub network).
> > Quietion is, what should be default?
> > What is default in current 2.0 Bird?
> > 
> >  Jocke
> > 
> 
> I have a hard time understanding the code for section 12.4.1.1 Option 1 and 
> Option 2:
> 
> /* Now we will originate stub area if there is no primary */
> if (net_lsa ||
>   (ifa->type == OSPF_IT_VLINK) ||
>   ((ifa->addr->flags & IA_PEER) && ! ifa->cf->stub) ||

Re: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Tue, Apr 23, 2019 at 12:40:04PM +, Joakim Tjernlund wrote:
> > I think the standard just does not consider the case of 'unnumbered'
> > link with both local and remote address but without subnet and assumes
> > 'real' unnumbered PtP link with no local IP address associated with
> > the iface.
> 
> There is always some local address, in linux you have to assign it to the I/F,
> but in others, like Cisco, you can assign an IP address to a dummy I/F and 
> then
> tell unnumbered I/Fs to use the dummy I/Fs' IP address.
> There has to be some SRC IP address on pkgs sent by OSPF

Yes, but the way how the RFC is written it (IMHO) assumes the second case -
unnumbered ifaces using SRC IP from some dummy iface. Therefore stub
node is associated with the dummy iface and not with the unnumbered PtP iface.


> Since Linux always has an local IP adress it is not possible to deduce if the
> user intended the link to be unnumbered or not, unless one wants to add 
> explicit
> config "unnumbered", it would be best to assume unnumbered I think.

I do not understand what you mean in this article. Linux could have active iface
without any IP address and it can be used for PtP link (with SRC IP from some
other iface), but it is not implemented in BIRD.

It is true that even a link with local /32 IP without specified remote peer 
could
be used for OSPF PtP link. BIRD in this case assumes it is a stub /32 and i am 
not
sure whether it could be configured as regular PtP. I did not realized before 
that
this is a relevant case for PtP link.


> Consider the use case with many /32 ptp links, all with the same local IP, 
> there would
> be a lot of redundant host routes in the Router LSA. Better to let the user
> add an explicit stub network for all PtoP's if one needs it.

Well, that is solvable by not putting the same stub multiple times in the
Router LSA.

More debatable is a case like this:

eth0 10.0.0.1/24
eth1 10.0.0.1/32 peer 10.0.1.1/32

10.0.0.1 is already reachable by route for eth0 (either stub or network),
so it is technically not necessary to have it in the Router LSA as
a separate /32 stub. So it makes sense to me to have it configurable
with three values: yes, no, if-not-covered.

-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Tue, Apr 23, 2019 at 10:28:46AM +, Kenth Eriksson wrote:
> > The second case is more complex. In OSPFv2, it always does not
> > propagate
> > /32 local addresses and it propagates /32 peer addresses only if
> > configured as stub. In OSPFv3, this is not implemented and neither
> > local
> > /32 address nor peer /32 address are propagated (as Linux IPv6 does
> > not
> > have PtP addresses and we missed that when done OSPFv3-IPv4). But
> > this we
> > should fix and it should behave as in OSPFv2.
> > 
> 
> Does the description you give here comply to the intent in section
> 12.4.1.1 of RFC2328? The following statement of the RFC makes the
> intent a bit unclear to me; "...a Type 3 link (stub network) should be
> added." 

The section 12.4.1.1 for 'unnumbered' case (Option 1) describes handling
of *peer* IP address, it is silent about handling of *local* IP address.


> > Another issue is whether local /32 *should* be propagated for
> > 'unnumbered' PtP links. We do not do that, but i think it should be
> > configurable, and perhaps default yes in cases the local IP is not
> > covered by range from other ifaces.
> 
> Configureable seems like a sensible thing to me. The default should be
> what the standard suggests.

I think the standard just does not consider the case of 'unnumbered'
link with both local and remote address but without subnet and assumes
'real' unnumbered PtP link with no local IP address associated with
the iface.

-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Mon, Apr 15, 2019 at 12:56:24PM +, Kenth Eriksson wrote:
> > > Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently
> > > from OSPFv2? 
> > 
> > Not in a significant way.
> > 
> 
> So a /32 shall be implicitly re-distributed in the OSPF area both for
> OSPFv2 and OSPFv3? I think that differs from how Quagga did it for
> unnumbered interfaces.

Well, we are mixing two cases here:

1) Just /32 (or /128) stub addresses (with no peer)

2) 'Unnumbered' PtP addresses with /32 local and /32 peer address.

The first case is always propagated in the OSPF area for both OSPFv2 and
OSPFv3 as any other prefix.

The second case is more complex. In OSPFv2, it always does not propagate
/32 local addresses and it propagates /32 peer addresses only if
configured as stub. In OSPFv3, this is not implemented and neither local
/32 address nor peer /32 address are propagated (as Linux IPv6 does not
have PtP addresses and we missed that when done OSPFv3-IPv4). But this we
should fix and it should behave as in OSPFv2.

Another issue is whether local /32 *should* be propagated for
'unnumbered' PtP links. We do not do that, but i think it should be
configurable, and perhaps default yes in cases the local IP is not
covered by range from other ifaces.

You say it differs from Quagga, what is their behavior?

-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Mon, Apr 15, 2019 at 12:21:12PM +, Kenth Eriksson wrote:
> On Fri, 2019-04-12 at 14:24 +0200, Ondrej Zajicek wrote:
> > CAUTION: This email originated from outside of the organization. Do
> > not click links or open attachments unless you recognize the sender
> > and know the content is safe.
> > 
> > 
> > On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
> > > Hello,
> > > 
> > > I've been playing around with BIRD and OSPF for a while now and ran
> > > across an error I don't quite understand, while trying to get BIRD
> > > to
> > > advertise ip addresses on the loopback interface on a debian 10
> > > server.
> > 
> > Fixed by attached patch.
> > 
> 
> Does this bug only apply to /32 addresses when running IPv4 over
> OSPFv3? Or is it also relevant for OSPFv2? 

Only to IPv4 over OSPFv3.

> Does OSPFv3 (RFC5340 / RFC5838) handle unnumbered (/32) differently
> from OSPFv2? 

Not in a significant way.

-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
> Hello,
> 
> I've been playing around with BIRD and OSPF for a while now and ran
> across an error I don't quite understand, while trying to get BIRD to
> advertise ip addresses on the loopback interface on a debian 10 server.

Fixed by attached patch.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/proto/ospf/topology.c b/proto/ospf/topology.c
index 7d5deca0..1579f496 100644
--- a/proto/ospf/topology.c
+++ b/proto/ospf/topology.c
@@ -1424,6 +1424,7 @@ prepare_prefix_rt_lsa_body(struct ospf_proto *p, struct ospf_area *oa)
   struct ospf_config *cf = (struct ospf_config *) (p->p.cf);
   struct ospf_iface *ifa;
   struct ospf_lsa_prefix *lp;
+  uint max = ospf_is_ip4(p) ? IP4_MAX_PREFIX_LENGTH : IP6_MAX_PREFIX_LENGTH;
   int host_addr = 0;
   int net_lsa;
   int i = 0;
@@ -1457,7 +1458,7 @@ prepare_prefix_rt_lsa_body(struct ospf_proto *p, struct ospf_area *oa)
 	  (a->scope <= SCOPE_LINK))
 	continue;
 
-  if (((a->prefix.pxlen < IP6_MAX_PREFIX_LENGTH) && net_lsa) ||
+  if (((a->prefix.pxlen < max) && net_lsa) ||
 	  configured_stubnet(oa, a))
 	continue;
 
@@ -1465,8 +1466,13 @@ prepare_prefix_rt_lsa_body(struct ospf_proto *p, struct ospf_area *oa)
 	  (ifa->state == OSPF_IS_LOOP) ||
 	  (ifa->type == OSPF_IT_PTMP))
   {
-	net_addr_ip6 net = NET_ADDR_IP6(a->ip, IP6_MAX_PREFIX_LENGTH);
-	lsab_put_prefix(p, (net_addr *) , 0);
+	net_addr net;
+	if (a->prefix.type == NET_IP4)
+	  net_fill_ip4(, ipa_to_ip4(a->ip), IP4_MAX_PREFIX_LENGTH);
+	else
+	  net_fill_ip6(, ipa_to_ip6(a->ip), IP6_MAX_PREFIX_LENGTH);
+
+	lsab_put_prefix(p, , 0);
 	host_addr = 1;
   }
   else
@@ -1482,7 +1488,7 @@ prepare_prefix_rt_lsa_body(struct ospf_proto *p, struct ospf_area *oa)
 if (!sn->hidden)
 {
   lsab_put_prefix(p, >prefix, sn->cost);
-  if (sn->prefix.pxlen == IP6_MAX_PREFIX_LENGTH)
+  if (sn->prefix.pxlen == max)
 	host_addr = 1;
   i++;
 }

Re: Reporting issues

[Ondrej Zajicek]

On Sat, Apr 06, 2019 at 01:11:32PM -0600, Brian Topping wrote:
> Hi all, I think I looked in all the regular places and inferred that 
> reporting issues might best be done here. The gitlab issue tracker shows no 
> issues.

Hi

Yes, this is proper place for reporting issues.


> The problem I have seen is where BIRD BGP is running a passive process. The 
> initiator peer is running the product at https://metallb.universe.tf 
> . This product can only initiate sessions. Due 
> to (what I assume) is a bug in the product, it was able to initiate a session 
> from a TCP socket source address that was not matched to the router ID. More 
> specifically, both BGP processes were running on the same host, with MetalLB 
> configured to take a router ID that was a secondary (internal / private) 
> interface and and BIRD using the primary interface address (so as to be able 
> to connect to other external peers). 
> 
> I believe the BIRD team would be interested in this because when BIRD BGP 
> accepted a connection with the same source address as it’s own Router ID, 
> even though the session provided a different router ID, it caused BIRD the 
> BIRD RIB and kernel exports to show the source of the route to be a 
> completely different BGP peer. In this case, the different peer was the 
> default route of a stub area, so incoming traffic to these addresses formed a 
> routing loop. It’s unclear to me whether this is a bug or a feature. 
> 
> If it is indeed a feature or unavoidable side effect that needs to be 
> supported all the same, what would have been desirable is if there was at 
> least some log message of the form “this is probably not what you want” when 
> a peer connected in this manner. More information can be found at 
> https://github.com/danderson/metallb/issues/422 
>  and the referenced PR.

Like Alexander Zubkov already noted, i also does not see any issue.

Mainly, the router ID and IP addresses are in general unrelated (although
BIRD defaults to using router ID based of one of its IP addresses when
router ID is not explicitly configured), so it is perfectly valid to have
session IP address different than router ID.


> Thanks for a great product!!

Thanks for the feedback.

-- 
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: Setting route destination for DNAT addresses

[Ondrej Zajicek]

On Sun, Apr 07, 2019 at 10:52:23PM -0600, Brian Topping wrote:
> The problem is when a service on the same host as the container needs
> to connect to the DNAT address presented for the container. Because the
> local kernel routing table is set to blackhole for an address, the
> traffic is immediately sunk instead of being offered to netfilter.
> Removing that dest line simply sets it to a default of RTD_UNREACHABLE,
> which does the same thing but politely tells the sender that it did so.

That is probably because BGP_NEXT_HOP reported in the route is not
resolvable though your local routing table.


> What I thought would work is to change the line to `ifname = “eno2”`, but 
> doing so generates a parse error. This seems to be a bug in the documentation 
> as the `ifname` attribute is not listed as read-only.

That was changed just recently. Do you have latest version of BIRD?

You can also set the direct next hop by setting 'gw'.

-- 
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, RPKI/RTR and issues with SSH

[Ondrej Zajicek]

On Thu, Apr 11, 2019 at 05:52:59PM -0700, Louis Poinsignon wrote:
> Hello everyone,
> I hope this mailing list is the correct place for my message.

Hello

Yes, it is correct place.


> While it's not impacting, when the RTR server returns a NO DATA, the client
> will bomb of requests as shown by a higher log level of GoRTR.
> 
> > gortr_1  | time="2019-04-11T21:40:13Z" level=debug msg="10.1.0.3:54874
> > (v1) / Serial: 0: Received PDU Reset Query v1"
> > gortr_1  | time="2019-04-11T21:40:13Z" level=debug msg="10.1.0.3:54874
> > (v1) / Serial: 0 > Request Cache"
> > gortr_1  | time="2019-04-11T21:40:13Z" level=debug msg="10.1.0.3:54874
> > (v1) / Serial: 0 < No data"
> > gortr_1  | time="2019-04-11T21:40:13Z" level=debug msg="10.1.0.3:54874
> > (v1) / Serial: 0: Received PDU Reset Query v1"
> > gortr_1  | time="2019-04-11T21:40:13Z" level=debug msg="10.1.0.3:54874
> > (v1) / Serial: 0 > Request Cache"
> 
> 
> I am not sure if I'm missing a timeout but I feel this may be a bug.

Yes, that is likely a bug.


> For ssh I am having another issue.
> The faulty configuration is the following:
> https://github.com/lspgn/compose-bird-gortr/blob/bird-rtr-ssh/bird/config_local/bird1.conf
> 
> With the statement:
> 
> > protocol rpki gortr {
> > debug all;
> > roa4 { table t_roa4; };
> > roa6 { table t_roa6; };
> > remote "10.1.0.4" port 8283;
> > transport ssh {
> > user "rpki";
> > bird private key "/etc/bird/id_rsa";
> > };
> > retry keep 90;
> > refresh keep 900;
> > expire keep 172800;
> > }
> 
> 
> > bird1_1  | bird: gortr: Lost connection: Failed to read private key:
> > /etc/bird/id_rsa

Do you have an SSH key in /etc/bird/id_rsa with appropriate rights?


-- 
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: BIRDv2 OSPF: Stub for loopback potentially broken: Invalid Prefix in LSA

[Ondrej Zajicek]

On Thu, Apr 11, 2019 at 08:38:44PM +0200, bauen1 wrote:
> Hello,
> 
> I've been playing around with BIRD and OSPF for a while now and ran
> across an error I don't quite understand, while trying to get BIRD to
> advertise ip addresses on the loopback interface on a debian 10 server.

Hi

It seems like a bug in handling of /32 IPv4 networks in OSPFv3 mode,
i will look into that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: Error msg on "make install"

[Ondrej Zajicek]

On Thu, Apr 04, 2019 at 05:14:45AM +, Toru Nozaki (tonozaki) wrote:
> Hi experts,
> 
> I’m trying to build Bird v2.0.4 on my environment.
> 
> Ubunts 16.4 LTS
> 
> $ uname -a
> Linux Y01-JUMP-01 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 
> 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
> In case of “#make install” , following error messages are displayed and can’t 
> build.
> 
> ---
> #make install
> /usr/bin/install -c -d //usr/local/sbin //usr/local/etc //usr/local/var/run
> for BIN in bird birdcl birdc ; do 
>   \
> /usr/bin/install -c ./$BIN //usr/local/sbin/$BIN ;  \
> done
> if ! test -f //usr/local/etc/bird.conf ; then 
>   \
> /usr/bin/install -c -m 644 ./doc/bird.conf.example 
> //usr/local/etc/bird.conf ;  \
> else  
>   \
> echo "Not overwriting old bird.conf" ;
>   \
> fi
> Not overwriting old bird.conf
> 
> ---
> 
> Does anyone help to solve this?

Hi

As already mentioned, this is not an error message, just the regular
output. If i remember correctly, this is not a first time someone
asked about it, so it seems it is a bit confusing, perhaps we should
clean up it a bit to make it clear that it finishes successfully.

-- 
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: Two IPv4s lead to "Missing broadcast address for interface"?

[Ondrej Zajicek]

On Fri, Mar 29, 2019 at 02:17:14AM +0100, Robert Scheck wrote:
> Hello folks,
> 
> since upgrading from BIRD 2.0.2 to 2.0.4 I'm seeing the message "Missing
> broadcast address for interface bond0" on one out of two systems in syslog
> e.g. when starting BIRD.
> 
> System cr0 with "Missing broadcast address for interface bond0" is:

It just reports it because it found IP address without associated brd
address (192.0.2.249/29). Considering it is secondary address, we
should propbably ignore that and do the check only for primary
addresses (which in your case have brd 192.0.2.255).

Also, the warning should note that is is for IP address on iface, not
just for interface.

> 
> [root@cr0 ~]# ip a s bond0
> 10: bond0:  mtu 1500 qdisc noqueue 
> state UP group default qlen 1000
> link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
> inet 192.0.2.251/29 brd 192.0.2.255 scope global bond0
>valid_lft forever preferred_lft forever
> inet 192.0.2.249/29 scope global secondary bond0
>valid_lft forever preferred_lft forever
> inet6 2001:db8::1/64 scope global nodad 
>valid_lft forever preferred_lft forever
> inet6 2001:db8::3/64 scope global 
>valid_lft forever preferred_lft forever
> inet6 fe80:::::/64 scope link 
>valid_lft forever preferred_lft forever
> [root@cr0 ~]# 

-- 
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: Option --runstatedir in BIRD 2.0.4 broken?

[Ondrej Zajicek]

On Fri, Mar 29, 2019 at 01:08:18AM +0100, Robert Scheck wrote:
> Hello folks,
> 
> when trying to use --runstatedir in BIRD 2.0.4, it looks like this here:
> 
> + ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu 
> --program-prefix= --disable-dependency-tracking --prefix=/usr 
> --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc 
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 
> --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib 
> --mandir=/usr/share/man --infodir=/usr/share/info --runstatedir=/run/bird
> BUILDSTDERR: configure: error: unrecognized option: `--runstatedir=/run/bird'

Yes, you are right. Thanks for notifying us. Seems like releases 1.6.6
and 2.0.4 have configure scripts that were inadvertently generated with
older autoconf without 'runstatedir' option support.

Workaround is either to regenerate configure using 'autoreconf' from
proper autoconf tool, or just use older 'with-runtimedir' option.

-- 
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 2.0.4 autodetects /30 as ptp

[Ondrej Zajicek]

On Tue, Mar 26, 2019 at 07:49:56AM +, Kenth Eriksson wrote:
> I can see the rationale of saying that a /30 network can run with OSPF
> interfaces in ptp mode since there are only 2 hosts on it. That said, I
> *believe* the Cisco routers defaults to broadcast mode for a /30 which
> would cause some interop issues with the default settings. I don't know
> the default values for other vendors. 
> 
> Is it possible to change the autodetect using a function in the bird
> configuration file? E.g. if the prefix length of the interface is 31 or
> 32 then use ptp mode else use broadcast mode.

No, you would have to edit the source code (function ospf_iface_classify_()
in proto/ospf/iface.c).

-- 
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: Import filter on 2nd ASN in AS path?

[Ondrej Zajicek]

On Thu, Mar 28, 2019 at 12:25:29AM +0100, Robert Scheck wrote:
> Hello Maria,
> hello Alexander,
> 
> first of all, thank you very much for your suggestions.
> 
> On Tue, 26 Mar 2019, Maria Matějka wrote:
> > Did you try using BGP path mask? Like
> > if (bgp.path ~ [= ? bogon bogon * =]) …
> 
> I didn't try this before, but I'm now also not sure how I could get my int
> set (BOGON_ASNS) properly into your example, because just

That is unfortuately not possible (only single ASNs or ASN ranges),
although it is a thing that makes perfect sense, so we should implement
it.

> > On March 26, 2019 10:34:39 AM GMT+01:00, Alexander Zubkov 
> >  wrote:
> 1 (rather "undefined" or failing). It starts to work properly when using
> 
> if (bgp_path.len >= 2 && delete(bgp_path, [ AS-TRANSIT1, AS-TRANSIT2 ]).first 
> ~ BOGON_ASNS) then { …
> 
> but it still leaves me with a list of transit ASNs to be fed (thus Maria's
> suggestion seems to be a more maintenance-friendly approach - if int sets
> could be used somehow).

What about: delete(bgp_path, bgp_path.first).first ?

-- 
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 import_table & graceful restart issue

[Ondrej Zajicek]

On Mon, Mar 25, 2019 at 06:35:43AM +, Arvin Gan wrote:
> Hi Ondrej,
> Thanks for your answer :).
> I checked the RFC 4271 and RFC 4274, maybe what you said it's correct 
> behavior based on RFC4271, " The phrase "the BGP connection is closed" means 
> the TCP connection has been closed, the associated Adj-RIB-In has been 
> cleared, and all resources for that BGP connection have been deallocated. 
> Entries in the Loc-RIB associated with the remote peer are marked as 
> invalid.The local system recalculates its best routes for the destinations of 
> the routes marked as invalid. Before the invalid routes are deleted from the 
> system, it advertises, to its peers, either withdraws for the routes marked 
> as invalid, or the new best routes before the invalid routes are deleted from 
> the system." 
> And RFC4274 said, "when the Receiving Speaker detects termination of the 
> TCP session for a BGP session with a peer that has advertised the Graceful 
> Restart Capability, it MUST retain the routes received from the peer for all 
> the address families that were previously received in the Graceful Restart 
> Capability and MUST mark them as stale routing information."
>   
> RFC4274 said  that retain the routes received from the peer .., my 
> understand is peer should retain routes in Adj-RIB-IN table and mark them as 
> stale. Normally, the BGP route in local-RIB or adj-RIB-out should come from 
> Adj-RIB-IN table.  The behavior of BIRD for GR, BGP route is  NOT  in 
> adj-RIB-in, but in local-RIB or adj-RIB-out, I think it's not a complete 
> behavior. What's your opinion ?

My opinion is that for proper graceful restart behavior, keeping FIB and
Loc-RIB is important. State of Adj-RIB-In is more or less irrelevant.
That is why it is not discussed in RFC 4724.

-- 
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 2.0.4 autodetects /30 as ptp

[Ondrej Zajicek]

On Mon, Mar 25, 2019 at 03:06:29PM +, Kenth Eriksson wrote:
> It seems as bird autodetects a /30 OSPF interface as ptp.  
> 
> bird> show ospf interface
> ospfv2_1:
> Interface eth0 (10.210.138.32/30)
> Type: ptp
> Area: 0.0.0.0 (0)
> State: PtP
> Priority: 0
> Cost: 10
> Hello timer: 10
> Wait timer: 40
> Dead timer: 40
> Retransmit timer: 5
> bird> 
> 
> Is this really correct behaviour? The peering Cisco router thinks the
> /30 network is a broadcast interface...

Well, OSPF RFC speaks about broadcast and ptp networks/interfaces, but it
is not really explicit about which networks are 'broadcast' and which are
'ptp'. One could think about medium types (ethernet vs. serial link),
physical topologies (star/bus vs. ptp link) or addressing (unnumbered
or 'ptp' addresses vs /30 vs wider prefix).

BIRD uses the third approach and autodetect unnumbered / ptp / /30 as
ptp, while wider prefix as broadcast (or PtMP / NBMA if the interface
does not support multicast). That is because in such cases it is not
possible to have more than two nodes in the same L3 network, so it is not
necessary to use the more complicated and error prone broadcast mode.

There is RFC 5309 that discusses this issue, which implies that was
perhaps meant more in the first sense (medium types).

It is possible that other implementations use other heuristics, which
causes compatibility issues in default setting. Perhaps we could change
it (in some major release) if there is a clear consensus about the proper
behavior.

-- 
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: How to ignore OSPF MTU checking?

[Ondrej Zajicek]

On Mon, Mar 25, 2019 at 07:23:02AM +, Kenth Eriksson wrote:
> > On Fri, Mar 22, 2019 at 09:24:58PM +0100, Piotr Marciniak wrote:
> > > Cisco switches require this for proper OSPF operation, if MTU is
> > > set
> > > different on equipment. But afaik it does not hit Bird. We have
> > > such
> > > sessions between Cisco and Bird. And works fine without this
> > > setting on
> > > Bird. But maybe therr is scenario we have never met but Kenth
> > > did?Best
> > > wishes,Peter
> > 
> > We have a bug in older versions of BIRD that it does not verify that
> > MTU
> > of both sides is the same. We fixed that in the latest versions.
> > 
> 
> How does bird handle transmission of OSPF packets packets larger than
> the link MTU? Does it rely on IP fragmentation? Or can it split into
> multiple protocol packets?

BIRD splits OSPF traffic to packets smaller than link MTU when possible.
If it is not possible (e.g. one LSA larger that MTU), larger packet is
used and we rely on OS to do fragmentation. We also suppose that OS
assembles incoming packets transparently. AFAIK that happens in Linux,
not sure about BSD.

> What is the expected bird behaviour if the link mtu is different of the
> two sides?

Expected behavior (specified by OSPF RFC) is to forbid an association to
be established.

-- 
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: How to ignore OSPF MTU checking?

[Ondrej Zajicek]

On Fri, Mar 22, 2019 at 09:24:58PM +0100, Piotr Marciniak wrote:
> Cisco switches require this for proper OSPF operation, if MTU is set
> different on equipment. But afaik it does not hit Bird. We have such
> sessions between Cisco and Bird. And works fine without this setting on
> Bird. But maybe therr is scenario we have never met but Kenth did?Best
> wishes,Peter 

We have a bug in older versions of BIRD that it does not verify that MTU
of both sides is the same. We fixed that in the latest versions.

-- 
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: OSPF authentication problem between Cisco and Bird

[Ondrej Zajicek]

On Sat, Mar 23, 2019 at 06:25:47PM +0100, Jérémie Vandeville wrote:
> Hi everyone
> 
> I apologise in advance, english is not my native language...
> 
> For study purpose, I'm trying to setup OSPFv2 between Bird 1.6.6 and a
> Cisco router.
> 
> protocol ospf test {
> instance id 42;
> area 0.0.0.0 {
> interface "eth*" {
> hello 2;
> dead count 3;
> authentication simple;
> password "azerty";
> };
> };
> export all;
> }

> 17:13:38.012494 IP (tos 0xc0, ttl 1, id 21850, offset 0, flags [none],
> proto OSPF (89), length 64)
> 192.168.42.43 > 224.0.0.5: OSPFv2, Hello, length 44
> Router-ID 192.168.42.43, Backbone Area, Authentication Type: simple (1)
> Simple text password: azerty
> 
> 17:13:38.012792 IP (tos 0xc0, ttl 1, id 7301, offset 0, flags [none], proto
> OSPF (89), length 72)
> 192.168.42.73 > 224.0.0.5: OSPFv2, Hello, length 52
> Router-ID 1.1.1.1, Backbone Area, Authentication Type: unknown (10753)
> 
> 
> Can you tell me what I'm doing wrong ? If I try the "none" authentication,
> Bird send the code 10752 and the problem is the same...

Hi

This is expected behavior, RFC 6549 redefined authentication type field
from 16bit to 8bit, and is using higher 8bit as 'instance id'.

For compatibility with older implementations just do not set 'instance id'.
It has to be set on both sides to the same value anyways.

-- 
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: IGP Metric to MED

[Ondrej Zajicek]

On Fri, Mar 22, 2019 at 02:56:21PM -0500, Corban Johnson wrote:
> > If you want, i can send you patch to fix
> > that.
> 
> That would be very helpful, thank you :)

Attached (untested).

It adds read-only integer property nh_cost to access that.

The name of the property is horrible (that is why the patch is not
commited), i would be glad for a better idea. Unfortunately, 'igp_metric'
cannot be used (as it represent the original property of OSPF routes,
which is technically a different property with a different access
code).

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
diff --git a/filter/config.Y b/filter/config.Y
index 02de3416..7941500b 100644
--- a/filter/config.Y
+++ b/filter/config.Y
@@ -408,7 +408,7 @@ CF_KEYWORDS(FUNCTION, PRINT, PRINTN, UNSET, RETURN,
 	SET, STRING, BGPMASK, BGPPATH, CLIST, ECLIST, LCLIST,
 	IF, THEN, ELSE, CASE,
 	TRUE, FALSE, RT, RO, UNKNOWN, GENERIC,
-	FROM, GW, NET, MASK, PROTO, SOURCE, SCOPE, DEST, IFNAME, IFINDEX,
+	FROM, GW, NET, MASK, PROTO, SOURCE, SCOPE, DEST, IFNAME, IFINDEX, NH_COST,
 	PREFERENCE,
 	ROA_CHECK, ASN, SRC,
 	IS_V4, IS_V6,
@@ -867,6 +867,7 @@ static_attr:
  | DEST{ $$ = f_new_static_attr(T_ENUM_RTD,   SA_DEST,	1); }
  | IFNAME  { $$ = f_new_static_attr(T_STRING, SA_IFNAME,	1); }
  | IFINDEX { $$ = f_new_static_attr(T_INT,SA_IFINDEX,	0); }
+ | NH_COST { $$ = f_new_static_attr(T_INT,SA_NH_COST,	0); }
  ;
 
 term:
diff --git a/filter/filter.c b/filter/filter.c
index 37cf16a3..e6464a10 100644
--- a/filter/filter.c
+++ b/filter/filter.c
@@ -949,6 +949,7 @@ interpret(struct f_inst *what)
   case SA_DEST:	res.val.i = rta->dest; break;
   case SA_IFNAME:	res.val.s = rta->nh.iface ? rta->nh.iface->name : ""; break;
   case SA_IFINDEX:	res.val.i = rta->nh.iface ? rta->nh.iface->index : 0; break;
+  case SA_NH_COST:	res.val.i = rta->igp_metric; break;
 
   default:
 	bug("Invalid static attribute access (%x)", res.type);
diff --git a/filter/filter.h b/filter/filter.h
index a8c33287..4f9a5bbe 100644
--- a/filter/filter.h
+++ b/filter/filter.h
@@ -260,6 +260,7 @@ void val_format(struct f_val v, buffer *buf);
 #define SA_DEST	 7
 #define SA_IFNAME  	 8
 #define SA_IFINDEX	 9
+#define SA_NH_COST	 10
 
 
 struct f_tree {

Re: LSA type-3

[Ondrej Zajicek]

On Sun, Mar 17, 2019 at 05:32:12PM +, Ticlea Alexandru wrote:
> Hello
> Is a way to control what subnets are sent by ABR to another area in LSA 
> type3? 
> I can use "hidden" to declare what subnets must not be propagated, but I want 
> to do it in oppositeside. 
> 
> Area 0.0.0.10 contains subnets in A.B.0.0/16 and I want to prevent the 
> propagation of others, like A.C.D.0/24. 
> Is a way other than listing many subnets (/8 and /16)  as hidden?

Hello

I think it should work if you configure A.B.0.0/16 as summary.

-- 
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 import_table & graceful restart issue

[Ondrej Zajicek]

On Thu, Mar 21, 2019 at 05:54:00AM +, Arvin Gan wrote:
> Hi All,

>  I am using BIRD 2.0.4, the configuration of bgp.ipv4  for import
> table and graceful restart are yes . when BGP remote peer is restarting,
> the graceful restart is detected by the local peer, using "show route
> protocols bgp1" on local peer, the route related with the restarting peer
> are exist, I think it's correct. But when I using "show route import
> table bgp1.ipv4" to show route for local peer Adj-RIB-In , the route is
> empty,  correct ?   After the remote peer is restarted done, the local
> import table can be recovered.
>
> As RFC4274 description:
> "when the Receiving Speaker detects termination of the TCP session for
>a BGP session with a peer that has advertised the Graceful Restart
>Capability, it MUST retain the routes received from the peer for all
>the address families that were previously received in the Graceful
>Restart Capability and MUST mark them as stale routing information."

Hi

After graceful restart, BIRD retains the routes, but only in the master
table, not in the import table. That is intended and IMHO correct
behavior.

-- 
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: IGP Metric to MED

[Ondrej Zajicek]

On Fri, Mar 22, 2019 at 12:54:57PM -0500, Corban Johnson wrote:
> Hello,
> I am trying to set MED on a BGP route using the metric value from OSPF, but 
> the attributes of the next-hop route do not seem to be available in filter 
> evolution. Am I missing something?
> 
> The problem seems to be that filters may only access attributes of the
> route currently processed, and the 'gateway recursive’ channel directive
> only calculates next-hop without passing any route attributes of that
> next-hop through.

Hello

Yes, that is true, the value is even stored with the route, it is just
not accessible from filters. If you want, i can send you patch to fix
that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: bird version 2.0.4 - peering with cisco version ios xe 16.3.5 - invalid open message

[Ondrej Zajicek]

On Mon, Mar 11, 2019 at 09:44:16AM +0100, Marco van Tol wrote:
> Hi
> 
> > What version of Cisco is that?
> 
> What I wrote in the subject and the first message, ios xe 16.3.5 :-)
> If you need more info in this area let me know.  I have close to no 
> experience with Cisco, but I have someone around who does.

Hi

It is likely this Cisco bug:

https://quickview.cloudapps.cisco.com/quickview/bug/CSCva92216

https://www.reddit.com/r/Cisco/comments/7lm3pj/avoid_denali_1635_bug_cscva92216/

Seems like specific for 16.3.5 and 16.4, while 16.3.4 should work.

-- 
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: BFD multihop with Junos

[Ondrej Zajicek]

On Tue, Mar 12, 2019 at 01:04:28PM -0400, Arzhel Younsi wrote:
> Bingo! As soon as I the system TTL to 255, the session went up. Thanks a lot!
>
> Now that we know where to look, we started to dig a bit in the code to not 
> have to change the TTL system wide but only for Bird.
> 
> It seems like there a TODO to make the TTL value customizable: 
> https://github.com/BIRD/bird/blob/master/proto/bfd/packets.c#L453
> And in some (so far unknown) cases, it sets the TTL to 255 
> https://github.com/BIRD/bird/blob/master/proto/bfd/packets.c#L456

That is for single-hop BFD cases. As i wrote in the previous e-mail:

> For single-hop BFD sessions, the RFC 5880 requires TTL security
> mechanism and therefore BIRD specifies outgoing TTL 255.

You can just change it to "sk->ttl = 255;" and recompile.

Is this 'min-recv-TTL 254' some special setting in Juniper, or its
default BFD behavior? If the second case, then perhaps it would be best
to make a bugreport to Juniper as they have packet checks that are not
requested by BFD specifications.

-- 
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: all protocol state debug

[Ondrej Zajicek]

On Mon, Mar 11, 2019 at 08:41:19PM +0500, Eugene M. Zheganin wrote:
> Hello,
> 
> 
> I want to log all protocols state changes, and I have a question:
> 
> debug all { states }
> 
> is valid in birdc, but why
> 
> debug all {
>     states
> };
> 
> 
> is invalid in bird.conf ?

Hello

I cannot say *why* it is that, but you can use:

  debug protocols all { states };

in bird.conf file to do that.

-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."

Re: bird version 2.0.4 - peering with cisco version ios xe 16.3.5 - invalid open message

[Ondrej Zajicek]

On Mon, Mar 11, 2019 at 09:44:16AM +0100, Marco van Tol wrote:
> > What version of Cisco is that?
> 
> What I wrote in the subject and the first message, ios xe 16.3.5 :-)
> If you need more info in this area let me know.  I have close to no 
> experience with Cisco, but I have someone around who does.
> 
> > Could you try if you get the same result with 1.6.6?
> 
> The sessions come up with version 1.6.4.  Is that good enough or do you need 
> me to try with 1.6.6?

Yes, i would like 1.6.6, because 1.6.4 is in this matter matching 2.0.2 (which 
worked).

> > Could you save the failed session initiation attempt by tcpdump?
> > (e.g. tcpdump -s 0 -w file.pcap ...)
> 
> I can but I would like to exchange the file personally rather than on this 
> list.
> Do you have a proposal on how to exchange the file?

Send it directly to my personal e-mail instead of mailing list?

-- 
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: BFD multihop with Junos

[Ondrej Zajicek]

On Thu, Mar 07, 2019 at 07:13:58PM -0500, Arzhel Younsi wrote:
> Thanks for your reply Ondrej,
> 
> I changed the port range as suggested, confirmed that BFD packets were 
> leaving from a correct port, but the BFD session still stays down.

208.80.153.77Down 0.000 1.0003
 Client BGP, TX interval 0.300, RX interval 0.300
 Local diagnostic None, remote diagnostic None
 Remote state AdminDown, version 1
 Replicated
 Session type: Multi hop BFD
 Min async interval 0.300, min slow interval 1.000
 Adaptive async TX interval 2.000, RX interval 2.000
 Local min TX interval 2.000, minimum RX interval 0.300, multiplier 3
 Remote min TX interval 0.000, min RX interval 0.000, multiplier 0
 Local discriminator 3556, remote discriminator 0
 Echo mode disabled/inactive, no-absorb, no-refresh
 Multi-hop min-recv-TTL 254, route table 0, local-address 208.80.153.192

Perhaps there is an issue with 'min-recv-TTL 254'. For single-hop BFD
sessions, the RFC 5880 requires TTL security mechanism and therefore
BIRD specifies outgoing TTL 255. For multi-hop BFD there is no such
requirement and therefore BIRD uses OS default TTL, which is AFAIK 64
on Linux.

You can check that with tcpdump and perhaps disable the check on Juniper
or set /proc/sys/net/ipv4/ip_default_ttl on Linux.

-- 
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 version 2.0.4 - peering with cisco version ios xe 16.3.5 - invalid open message

[Ondrej Zajicek]

On Fri, Mar 08, 2019 at 04:09:58PM +0100, Marco van Tol wrote:
> Op 8 mrt. 2019, om 14:45 heeft Ondrej Zajicek  het 
> volgende geschreven:
> > On Fri, Mar 08, 2019 at 01:51:31PM +0100, Marco van Tol wrote:
> >> Hi,
> >> 
> >> So I replaced bird 2.0.4 for which I downloaded the rpm from your site 
> >> with bird 2.0.2 which I installed using yum on a centos 7 system.
> >> 
> >> I noticed 2 things:
> >> - The Centos 7 2.0.2 rpm makes the bird daemon drop privileges and resumes 
> >> as user bird
> >> - The 2.0.4 package from your site, when started with the supplied 
> >> .service file, remains as root, with the exact same bird.conf
> > 
> > Hi
> > 
> > That is defined by cmdline options, so they are probably missing in the 
> > .service file.
> 
> Ah right, okay thanks.
> 
> >> - Version 2.0.2 has no issues to peer with the cisco router, it peers fine.
> >> 
> >> So now I'm curious how worried I should be about the "import bgp fixes" in 
> >> the 2.0.4 release notes. :-)
> > 
> > That is unlikely as that does not change OPEN message.
> > 
> > Could you try 2.0.4 with 'long lived graceful restart off;' option?
> 
> Hi,
> 
> This fixed it.  I added this option only to the cisco neighbors which made 
> them accept peering.
> 
> Much appreciated, and let me know when you need more information from me.

Hi

What version of Cisco is that?

Could you try if you get the same result with 1.6.6?

Could you save the failed session initiation attempt by tcpdump?
(e.g. tcpdump -s 0 -w file.pcap ...)

-- 
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: Showing local router ID for BGP protocols

[Ondrej Zajicek]

On Fri, Mar 08, 2019 at 03:32:29PM +, Marcin Dulinski wrote:
> show status?
> 
> On 08/03/2019 13:46, Jakub Nowacki wrote:
> > Hi,
> >
> > I'm trying to find a command that will allow me to verify router ID
> > being used for particular BGP session.
> > When using 'show protocols all ' it shows verbose
> > info, but it doesn't show Local Router ID. I know it shows 'Source
> > address' but this is not the same.
> > Is there a command to verify that?

Hi

The command 'show status' shows global router id, but it is possible to
override it on per-protocol basis. The command 'show protocols all' shows
per-protocol router id, but only if it is different than the global
router id.

-- 
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 version 2.0.4 - peering with cisco version ios xe 16.3.5 - invalid open message

[Ondrej Zajicek]

On Fri, Mar 08, 2019 at 01:51:31PM +0100, Marco van Tol wrote:
> Hi,
> 
> So I replaced bird 2.0.4 for which I downloaded the rpm from your site with 
> bird 2.0.2 which I installed using yum on a centos 7 system.
> 
> I noticed 2 things:
> - The Centos 7 2.0.2 rpm makes the bird daemon drop privileges and resumes as 
> user bird
> - The 2.0.4 package from your site, when started with the supplied .service 
> file, remains as root, with the exact same bird.conf

Hi

That is defined by cmdline options, so they are probably missing in the 
.service file.

> - Version 2.0.2 has no issues to peer with the cisco router, it peers fine.
> 
> So now I'm curious how worried I should be about the "import bgp fixes" in 
> the 2.0.4 release notes. :-)

That is unlikely as that does not change OPEN message.

Could you try 2.0.4 with 'long lived graceful restart off;' option?

-- 
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 version 2.0.4 - peering with cisco version ios xe 16.3.5 - invalid open message

[Ondrej Zajicek]

On Fri, Mar 08, 2019 at 12:35:30PM +0100, Marco van Tol wrote:
> Hi there,
> 
> I'm trying to setup iBGP peering with a cisco router which is giving me an 
> "invalid open message" that I can't seem to fix.
> 
> - The same router is peering with Juniper and other bird 1.6.3 routers 
> without issues.

Hi

You mean the same BIRD rotuer or the same Cisco router?

> - The router is also doing IPv6 based peering with all the other routers, 
> which gives the exact same scenario as with IPv4.
> -< cut here >-
> 
> The debug messages I'm getting are these:
> -< cut here >-
> 2019-03-08 11:02:33.199  peer_type1a_v4: Incoming connection from 
> 10.0.0.2 (port 18581) accepted
> 2019-03-08 11:02:33.199  peer_type1a_v4: Sending 
> OPEN(ver=4,as=64512,hold=240,id=0a01)
> 2019-03-08 11:02:33.200  peer_type1a_v4: Got 
> OPEN(as=64512,hold=180,id=10.0.0.2)
> 2019-03-08 11:02:33.200  peer_type1a_v4: Sending KEEPALIVE
> 2019-03-08 11:02:33.201  peer_type1a_v4: Received: Invalid OPEN message
> 2019-03-08 11:02:33.201  peer_type1a_v4: State changed to stop
> 2019-03-08 11:02:33.201  peer_type1a_v4: Down
> -< cut here >-
> 
> My suspicion is that the ipv6 like address representation in the sent open 
> message router id might confuse the cisco.
> So the opening message we're sending seems to be having the router id 
> represented in hex form, like 32 bits of an IPv6 address.

That is just a textual representation in logs, there is no difference in
the packet. For some historical reasons there is a different formatting
for 'Sending OPEN' and 'Got OPEN' log messages.

Could you try the 2.0.2 or 2.0.3 versions if they work with the Cisco
router?

-- 
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: BFD multihop with Junos

[Ondrej Zajicek]

On Tue, Mar 05, 2019 at 05:21:44PM -0500, Arzhel Younsi wrote:
> Hi,
> 
> I'm trying to setup BFD multihop session between Bird 1.6.3 and a Juniper MX 
> router to fast failover eBGP multihop sessions.

Hi

I guess this could be strict src port checking in Juniper, see
https://bird.network.cz/?get_doc=16=bird-6.html#ss6.2 :

  BFD packets are sent with a dynamic source port number. Linux systems use
  by default a bit different dynamic port range than the IANA approved one
  (49152-65535). If you experience problems with compatibility, please
  adjust /proc/sys/net/ipv4/ip_local_port_range

And also: https://bird.network.cz/pipermail/bird-users/2015-August/009846.html

-- 
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: Route redistribution between OSPF instances

[Ondrej Zajicek]

On Mon, Mar 04, 2019 at 04:54:10PM +0300, Yaroslav Dronskii wrote:
> Hello, I need some help in understanding bird. Route redistribution between
> ospf instances doesn't work for me.
> I tried everything I could think of short of debugging source code, and
> narrowed it down to route type.
> If it's RTS_OSPF_IA, ospf_metric2 is set to LSINFINITY.

Hello

This seems like a bug in BIRD. OSPF generated routes other than E2 (type
2 external) have attribute ospf_metric2 set to LSINFINITY, but when a
route is exported to OSPF and have ospf_metric2 set (even to LSINFINITY),
then it is generated as E2 with given metric. We should generate
ospf_metric2 attribute only for E2 routes.

There is a simple workaround: In OSPF export filter, use this command:

  unset(ospf_metric2);

That would generate E1 routes from IA routes. Or just set ospf_metric2 to
a sane value to generate E2 routes.


> How route is seen:
> Imported from other vm host via ospf:
> bird> show route table table_ospf_0 10.20.5.135/32 all
> Table table_ospf_0:
> 10.20.5.135/32   unicast [ospf_vm 13:52:53.209] IA (150/20)
> [10.255.10.129]
> via 10.133.146.12 on ospf0-br
> Type: OSPF-IA univ

This seems like another bug, there should be list of OSPF attributes.

-- 
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: OSPF authentication supported for IPv6 / OSPFv3?

[Ondrej Zajicek]

On Mon, Mar 04, 2019 at 08:56:10PM +0100, Cybertinus wrote:
> Hello Bird users,
> 
> I'm trying to get authentication enabled on my OSPF sessions. I'm running
> Bird 1.6.4 on Debian 9.8. I have the following config in my ospf.conf:

Hi

OSPFv3 in base spec does not have authentication. BIRD Implements RFC
7166 extension (Authentication trailer for OSPFv3) since version 2.0.3,
so it is not available in 1.6.4.

> When I check https://bird.network.cz/?get_doc=16=bird-6.html#ss6.8 I see
> the following:

This seems like a bug in documentation, where some patch intended for
BIRD 2.0 leaked also to 1.6 branch.

-- 
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: show route output explained

[Ondrej Zajicek]

On Fri, Mar 01, 2019 at 05:35:30PM +0500, Eugene M. Zheganin wrote:
> Hello,
> 
> Since the documentation doesn't specify the exact output format, could
> anyone please explain it to me ?
> 
> 
> 0.0.0.0/0  via 192.168.57.60 on re0 [ospfv4 11:17:31] ! E2
> (150/10/1) [192.168.100.254]
>    via 90.150.180.20 on ng0 [kernel1 11:12:08] (10)
> 
> 
> I understand most of it, but not in detail.
> 
> 1) What, for example, the exclamation mark means ? Bird mimics Juniper
> notation, but Juniper doesn't have exclamation mark in it, only +/-/*.
> (Since bird mimics the Juniper notation it would be cool if it would also
> print the mark meanings, like JunOS or Cisco IOS does)

Failure to push the route into kernel routing table.
> 
> 2) What is the triplet (150/10/1) ? I understand these are probably
> metric/cost/preference, but which is what ? Juniper here uses single metric.

protocol preference / OSPF distance / OSPF external distance

> 3) When it comes to internal OSPF area, this field output changes to
> double-field one:
> 
> 
> 192.168.57.0/24    dev re0 [direct1 11:12:08] * (240)
>    dev re0 [ospfv4 11:17:31] I (150/10) [192.168.100.254]
> 
> 
> again, which field in (150/10) is what ?

protocol preference / OSPF distance

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