gmane.network.bird.user

Re: Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Bao Nguyen — 2013-05-24T15:52:23

Interesting. Did you happen to test installing the route (in our case
default route from OSPF) to the kernel routing table from OSPF?

-bn
0216331C


On Fri, May 24, 2013 at 1:44 AM, Ondrej Zajicek <santiago< at >crfreenet.org>wrote:

Re: [PATCH RFC v2] Preserve BGP attributes from non-BGP protocols

Matthias Schiffer — 2013-05-24T08:22:58

Hmm, this is true, but the distinction becomes hard to define as soon as
you have BGP instances with different local AS# and propagate routes
between then... maybe it would be beneficial to add an (filter
readable/writable) attribute holding the remote AS# the route was
received from and use this to differentiate between iBGP and eBGP?

Matthias

Re: Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Ondrej Zajicek — 2013-05-24T08:44:36

Hello

Tested with 3.9.2 and worked for me with COMPAT_NETLINK_MESSAGES disabled,
so it is probably some different problem.

Re: [PATCH RFC v2] Preserve BGP attributes from non-BGP protocols

Ondrej Zajicek — 2013-05-23T21:36:26


Well, this is nice idea, but BGP standard (RFC 4271) specifies for route
propagation different behavior based on whether the route was received
originally from iBGP or from eBGP. So even if you want that non-BGP
routes should be handled like BGP ones, you would have to specify
whether like iBGP or like eBGP.

Re: erroneous "Netlink: File exists" ?

Ondrej Zajicek — 2013-05-24T07:16:09


Hello

What is your output of 'show route' from birdc?
Isn't there any other error message in log just after the start of BIRD?

Could you replicate the same behavior with just the static routes?

Is the problem the same with disabled 'learn' option?

Could you try to import some route created by 'ip route add'?

Re: Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Ondrej Zajicek — 2013-05-23T09:57:07

Well, this is a bit strange because this option is here since 2.6.32 and
it works for me with both 2.6.32 and 3.0 without this option.
I would check it with 3.8 to see if i get the same problem.

erroneous "Netlink: File exists" ?

Aragon Gouveia — 2013-05-23T22:10:45

Hi,

So I've seen this issue mentioned in past mailings, and the FAQ, but I 
think I might be experiencing a buggy form of it in Bird 1.3.10.

In debug mode I'm getting this:

May 23 23:59:06 wugpi bird: device1: Scanning interfaces
May 23 23:59:06 wugpi bird: CTWUG: HELLO packet sent via eth0
May 23 23:59:06 wugpi bird: kernel1: Scanning routing table
May 23 23:59:06 wugpi bird: kernel1: Pruning table master
May 23 23:59:06 wugpi bird: kernel1: 172.18.102.32/32: reinstalling
May 23 23:59:06 wugpi bird: Netlink: File exists
May 23 23:59:06 wugpi bird: kernel1: 172.18.102.160/28: reinstalling
May 23 23:59:06 wugpi bird: Netlink: File exists
May 23 23:59:06 wugpi bird: kernel1: 172.18.102.224/28: reinstalling
May 23 23:59:06 wugpi bird: Netlink: File exists
May 23 23:59:06 wugpi bird: kernel1: 172.18.102.240/28: reinstalling
May 23 23:59:06 wugpi bird: Netlink: File exists
May 23 23:59:06 wugpi bird: kernel1: 172.18.128.0/22: reinstalling
May 23 23:59:06 wugpi bird: Netlink: File exists
May 23 23:59:06 wugpi b

Re: [PATCH RFC v2] Preserve BGP attributes from non-BGP protocols

Matthias Schiffer — 2013-05-23T17:35:29

Yes, I saw that issue as well... so I guess I'll have to use patched
Bird versions till a major release includes this or something similar.

I think all routes should be handled the same way, without regard for
the source protocol. I'd like the BGP protocol to handle route
attributes which come from other protocols the same way attributes from
BGP protocol instances are handled, my use case is the following config
snippet, which works just like a eBGP peering (okay, I don't handle
things like MED and other attributes that shouldn't be distributed over
eBPG yet, but of course that can be added easily). Without my patch it
works only for routes that come from BGP, but not those from static
protocols and similar.

table ffhl;
table ffhh;
function bgp_peer(int import_as; int export_as) {
        if (!defined(bgp_path)) then bgp_path = +empty+;
        if (bgp_path ~ [= * import_as * =]) then return false;
        bgp_path.prepend(export_as);
        return true;
};
protocol pipe pipe_ffhl_ffhh {
        table ff

Re: OSPF: LSA disappeared

Bao Nguyen — 2013-05-22T18:13:56

Thanks for the update.

-bn
0216331C


On Wed, May 22, 2013 at 1:41 AM, Ondrej Zajicek <santiago< at >crfreenet.org>wrote:

Re: Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Bao Nguyen — 2013-05-22T17:29:49

Ondrej,

You are correct, the issue is not related to OSPF but related to BIRD's
ability to install a route into the kernel routing table. It look like the
issue was that the new kernel doesn't have this option enabled (which is
hidden under the Kernel Wireless options)

CONFIG_COMPAT_NETLINK_MESSAGES=y

Enabling this option fixes the issue we were seeing. Reading up on this [1]
it seemed it's an very old mode.

"This option makes it possible to send different netlink messages to tasks
depending on whether the task is a compat task or not. To achieve this, you
need to set skb_shinfo(skb)->frag_list to the compat skb before sending the
skb, the netlink code will sort out which message to actually pass to the
task.

Newly written code should NEVER need this option but do compat-independent
messages instead!"



[1] http://cateee.net/lkddb/web-lkddb/COMPAT_NETLINK_MESSAGES.html


-bn
0216331C


On Wed, May 22, 2013 at 1:48 AM, Ondrej Zajicek <santiago< at >crfreenet.org>
wrote:
12.04
needed
only

Re: [PATCH RFC v2] Preserve BGP attributes from non-BGP protocols

Ondrej Zajicek — 2013-05-22T10:36:07

I agree with the point that BGP should not overwrite BGP attributes from
foreign routes exported to it. But the current behavior is both
established and consistent with other protocols (like OSPF, where the
situation is ever worse), so NACK for current minor releases. I plan to
do some major changes to attribute behavior to make it more consistent
and such change will be a part of it.

There is also a question of how BGP attribute on non-BGP route should be
interpreted by BGP protocol - either like BGP routes, or like non-BGP
routes with the attribute assigned by BGP export filter. I would prefer
the second behavior - the difference is in implicit modifications of
current attributes (like bgp_next_hop), in the first variant it would be
modified as it is from BGP route, in the second variant it is not
modified as all (because it is set as a local policy). Therefore if you,
e.g., originate a static route and export it to a BGP protocol, it
wouldn't make a difference if you modify BGP attributes in the import

Re: Flood of: Netlink: File exists

Ondrej Zajicek — 2013-05-22T09:43:53

Hello

See 'Netlink: File exists' here:
https://redmine.labs.nic.cz/projects/bird/wiki/FAQ

You could use 'debug {routes}' or 'debug all' for kernel protocol.

Re: Flood of: Netlink: File exists

Stanislav Datskevich — 2013-05-22T08:59:04

Try to enable BIRD debug and look at BIRD log - you will see tries to add
route with following error.


2013/5/22 Tapio Haapala <tapio.haapala< at >f-solutions.fi>

Flood of: Netlink: File exists

Tapio Haapala — 2013-05-22T08:53:36

Hello,
We get <WARN> Netlink: File exists message to bird log about 25 times in
minute.
I think it comes when bird try add some routes to kernel table what are
allready in table. Is there way to get more information what it try
insert to table so then I maybe can resolve that with filters. I think
it just get same routes from two different protocol.

Re: Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Ondrej Zajicek — 2013-05-22T08:48:40

I don't think the issue is related to OSPF, that would be strange. Most
probably to kernel protocol. But default scan time is 60 seconds, so
unless you have used 'scan time' option, it is probably related to
some route exports.

I see that you use 'ecmp', do you have ecmp support in kernel?

Could you enable 'debug all' for ospf and kernel protocols and send me a
log with netlink errors interleaved with trace messages from debug all?

Is your custom 3.8.13 Linux kernel just customly compiled, or some local
code modification?

Re: OSPF: LSA disappeared

Ondrej Zajicek — 2013-05-22T08:41:01

This issue (together with others related to OSPF flood) will be probably
resolved during current review of OSPF flood code.

BTW, this issue is mostly harmless, just annoying.

Running BIRD 1.3.4 on custom config Linux 3.8.13 kernel

Bao Nguyen — 2013-05-20T23:36:02

We testing BIRD on a custom 3.8.13 Linux kernel and seeing this message
every 20 seconds. We did not see this on 3.2 kernel release by Ubuntu 12.04
LTS release. Is there any chance that there's a kernel config that's needed
by BIRD that we are not aware of? I notice that the "wait 20" is the only
time that matches this interval in the log...

May 20 23:29:05 sja15 bird: Netlink: Invalid argument
May 20 23:29:26 sja15 bird: Netlink: Invalid argument
May 20 23:29:46 sja15 bird: Netlink: Invalid argument
May 20 23:30:06 sja15 bird: Netlink: Invalid argument
May 20 23:30:25 sja15 bird: Netlink: Invalid argument
May 20 23:30:45 sja15 bird: Netlink: Invalid argument
May 20 23:31:06 sja15 bird: Netlink: Invalid argument
May 20 23:31:26 sja15 bird: Netlink: Invalid argument


Here's our OSPF config.

protocol ospf {
  import filter import_OSPF;
  export filter export_OSPF;
  ecmp 4;

  area 0 {
    interface "eth0", "eth1" {
      cost 100;

      type broadcast;
      hello 10; retransmit 5; wait 20; dead 40;
    }

Re: OSPF: LSA disappeared

Bao Nguyen — 2013-05-20T23:29:27

Just want to add to this thread that I'm seeing this behavior on BIRD as
well, I'm seeing this on all the machines that I've installed. From the
timer, it appeared to happened every 5 seconds....

root< at >sje17:~# birdc -v
0001 BIRD 1.3.4 ready.

Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id:
10.25.206.123, Rt: 10.25.15.11)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id:
10.25.205.147, Rt: 10.25.15.17)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id:
10.25.15.3, Rt: 10.25.15.3)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0001, Id:
10.25.15.4, Rt: 10.25.15.4)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id:
10.25.202.1, Rt: 10.25.239.11)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id:
10.25.201.1, Rt: 10.25.239.10)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0002, Id:
10.25.201.13, Rt: 10.25.239.10)
Jan  8 02:34:30 sje17 bird: OSPF: LSA disappeared (Type: 0005, Id:
10.25.201.12, Rt: 10.25.10.4)

Re: OSPF HELLO wrong mask

Alexander V. Chernikov — 2013-05-19T11:34:28

It should be the first one, yes. The problem starts when the primary 
address gets removed.
I'm thinking of adding special flag to ifa_flags indicating that address 
is primary, and either
use RTM_NEWADDR to announce new primary address (sent before 
RTM_DELADDR) or completely
new message like RTM_PRIMADDR with the same data.

However, I probably can do this for FreeBSD only, and something has to 
be implemented for
other *BSD flavors..
It seems that platform-dependent code with addional constantly open 
socket calling SIOCGIFADDR on address change is the easiest hack^Wthing 
to do..

Re: OSPF HELLO wrong mask

Ondrej Zajicek — 2013-05-18T12:43:54

Well, this is mainly a consequence of the facts that primary address
selection is currently in platform independent code and on Linux
the order of addressess has no real meaning. Therefore it seemed
to be a good idea to make it more deterministic, i.e. independent
on the order in which the addresses appeared.

Perhaps the best idea would be to remove the whole primary address
selection (as it does more harm than good) and replace it by platform
dependent flag that this address is preferred for the interface
(and don't even use this flag on Linux).

We enumerate addresses on BSD using CTL_NET / NET_RT_IFLIST sysctl scan.
Does anyone know whether is a reliable way to determine which one of
returned addresses is the primary one or whether we should just add an
another call of SIOCGIFADDR (as suggested by Alexander V. Chernikov)?
I would guess it is the first one, but i am not sure if that is specified
or just a coincidence.

Re: OSPF HELLO wrong mask

Alexander V. Chernikov — 2013-05-17T15:13:50

I've got the following patch, which works for CARP instances, and should 
work in your case.


diff --git a/sysdep/bsd/krt-sock.c b/sysdep/bsd/krt-sock.c
index e970d6b..202255e 100644
--- a/sysdep/bsd/krt-sock.c
+++ b/sysdep/bsd/krt-sock.c
< at >< at > -594,6 +594,45 < at >< at > krt_read_addr(struct ks_msg *msg)
     ifa_delete(&ifa);
 }
 
+#ifndef IPV6
+struct ifa *
+kif_get_primary_ip(struct iface *i)
+{
+  struct ifreq ifr;
+  int fd, res;
+  struct sockaddr_in *sin;
+  ip_addr addr = IPA_NONE;
+  struct ifa *a = NULL;
+
+  fd = socket(AF_INET, SOCK_DGRAM, 0);
+
+  if (fd == -1)
+    return NULL;
+
+  memset(&ifr, 0, sizeof(ifr));
+
+  strcpy(ifr.ifr_name, i->name);
+
+  res = ioctl(fd, SIOCGIFADDR, (char *)&ifr);
+  close(fd);
+
+  if (res == -1)
+    return NULL;
+
+  sin = (struct sockaddr_in *)&ifr.ifr_addr;
+  memcpy(&addr, &sin->sin_addr, sizeof(ip_addr));
+  ipa_ntoh(addr);
+
+  WALK_LIST(a, i->addrs)
+    {
+      if (a->ip == addr)
+return a;
+    }
+
+  return NULL;
+}
+#endif
+
 
 void
 krt_read_msg(struct proto