RE: Received route with strange next-hop

2019-05-28 Thread Adrichem, N.L.M. (Niels) van
Hi Ondrej,

It took me a while to continue this work, but the patch works flawlessly. Our 
"alien" routing protocol removes nexthop routes which become unavailable so the 
behavior you implemented is correct for us.

Thanks for your help,
Niels

-Original Message-
From: Ondrej Zajicek  
Sent: Thursday, May 16, 2019 5:43 PM
To: Adrichem, N.L.M. (Niels) van 
Cc: bird-users@network.cz
Subject: Re: Received route with strange next-hop

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."
This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.




Re: Received route with strange next-hop

2019-05-16 Thread 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 *) &sit))
 	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;


Received route with strange next-hop

2019-05-15 Thread Adrichem, N.L.M. (Niels) van
Hello,

I'm trying to redistribute routes from another routing daemon through 
synchronization of the kernel table using the kernel protocol in BIRD 2.0.4. 
However, I run into some problems that not all routes are imported by the BIRD 
router.

The kernel routing table contains the following routing table:
# ip route
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.1
10.0.1.3 via 10.0.1.4 dev eth1 proto zebra metric 2
10.0.1.4 dev eth1 proto zebra scope link metric 1
10.0.4.0/24 via 10.0.0.2 dev eth0 proto bird metric 32

The interface eth1 has the address 10.0.1.1/32 in an ad-hoc routing domain, 
through OSPF-MDR (which is an extension of Quagga) it finds the direct neighbor 
10.0.1.4 which is added as "10.0.1.4 dev eth1 proto zebra scope link metric 1". 
The neighbor 10.0.1.4 advertises that it can forward to 10.0.1.3 which is added 
as "10.0.1.3 via 10.0.1.4 dev eth1 proto zebra metric 2". The routing of 
OSPF-MDR works, in the sense that 10.0.1.1 can reach 10.0.1.3 and 10.0.1.4.

However, when we try to import these routes from the protocol kernel into the 
Bird routing table, only the directly connected route to 10.0.1.4 shows while 
the route to 10.0.1.3 are not imported:
# birdc show route
BIRD 2.0.4 ready.
Table master4:
10.0.1.4/32  unicast [kernel1 10:27:29.329] (10)
dev eth1
10.0.4.0/24  unicast [babel1 10:27:23.461 from fe80::200:ff:feaa:4] 
(130/96) [00:00:00:00:0a:00:00:02]
via 10.0.0.2 on eth0
10.0.0.0/24  unicast [direct1 10:27:21.870] * (240)
dev eth0
 unicast [babel1 10:27:23.461 from fe80::200:ff:feaa:4] 
(130/96) [00:00:00:00:0a:00:00:02]
via 10.0.0.2 on eth0

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.

I have attached the bird.conf file, as well as an image of the example 
topology. Above snippets and config file are taken from node n1 which is 
running both the OSPF-MDR router based on Quagga and BIRD Router.

Any help would be much appreciated.

Thanks in advance,
Niels van Adrichem

[cid:image001.png@01D50B0D.4706B540]

This message may contain information that is not intended for you. If you are 
not the addressee or if this message was sent to you by mistake, you are 
requested to inform the sender and delete the message. TNO accepts no liability 
for the content of this e-mail, for the manner in which you use it and for 
damage of any kind resulting from the risks inherent to the electronic 
transmission of messages.


bird.conf
Description: bird.conf


Re: KRT: Received route with strange next-hop

2015-12-05 Thread Brian Rak

On 12/5/2015 9:54 AM, Ondrej Zajicek wrote:

On Sat, Nov 28, 2015 at 04:16:54PM -0500, Brian Rak wrote:

Sorry for late answer, 'device route' i call a route for directly
attached network prefix, with associated iface but without associated
gateway IP. Perhaps there is a better / more established term for such
routes.


Sorry, my spam filter was delaying this.

That's what I have I think?  I have the '45.63.4.188 dev veth0 scope link'
route, I'm not aware of any other way to add this (and it doesn't use a
gateway IP).


Well, the recommended way is to add ptp address:

ip addr add A.B.C.D peer 45.63.4.188 dev veth0

instead of just the route (when ptp address is added, the route is also
added by the kernel)

The host end of the interface does not have an IP address, so using 'ip 
addr add' won't really work. A peer address won't really work, this 
isn't a /30 (the 45.63.4.188 IP is assigned to a virtual machine, and is 
part of a bigger /23, we're using proxy ARP to get traffic to/from the VM).


Re: KRT: Received route with strange next-hop

2015-12-05 Thread Ondrej Zajicek
On Sat, Nov 28, 2015 at 04:16:54PM -0500, Brian Rak wrote:
> >Sorry for late answer, 'device route' i call a route for directly
> >attached network prefix, with associated iface but without associated
> >gateway IP. Perhaps there is a better / more established term for such
> >routes.
> >
> Sorry, my spam filter was delaying this.
> 
> That's what I have I think?  I have the '45.63.4.188 dev veth0 scope link'
> route, I'm not aware of any other way to add this (and it doesn't use a
> gateway IP).


Well, the recommended way is to add ptp address:

ip addr add A.B.C.D peer 45.63.4.188 dev veth0

instead of just the route (when ptp address is added, the route is also
added by the kernel)

-- 
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: Digital signature


Re: KRT: Received route with strange next-hop

2015-11-28 Thread Brian Rak



On 11/25/2015 5:51 AM, Ondrej Zajicek wrote:

On Thu, Nov 19, 2015 at 08:25:01AM -0500, Brian Rak wrote:

Generally, BIRD expects that the next hop address is reachable by
interface address prefix. In your case you just add device route for
45.63.4.188/32 instead of adding peer address of 45.63.4.188 to veth0. It
is true that for the kernel the difference does not matter in this
regard and that the warning is not important in this case.

What do you mean by 'device route'?  I'm not sure how that differs from what
I have, and not finding a lot of references to that phrase online.

Hi

Sorry for late answer, 'device route' i call a route for directly
attached network prefix, with associated iface but without associated
gateway IP. Perhaps there is a better / more established term for such
routes.


Sorry, my spam filter was delaying this.

That's what I have I think?  I have the '45.63.4.188 dev veth0 scope 
link' route, I'm not aware of any other way to add this (and it doesn't 
use a gateway IP).  Are you talking about the '216.155.132.254 via 
45.63.4.188 dev veth0 proto bird' route?  If so, I have no way to  
change that.  BIRD itself is adding that route based on information from 
BGP. AFAIK, there is no way to specify the next hop is an interface via BGP.


Re: KRT: Received route with strange next-hop

2015-11-25 Thread Ondrej Zajicek
On Thu, Nov 19, 2015 at 08:25:01AM -0500, Brian Rak wrote:
> >Generally, BIRD expects that the next hop address is reachable by
> >interface address prefix. In your case you just add device route for
> >45.63.4.188/32 instead of adding peer address of 45.63.4.188 to veth0. It
> >is true that for the kernel the difference does not matter in this
> >regard and that the warning is not important in this case.
> 
> What do you mean by 'device route'?  I'm not sure how that differs from what
> I have, and not finding a lot of references to that phrase online.

Hi

Sorry for late answer, 'device route' i call a route for directly
attached network prefix, with associated iface but without associated
gateway IP. Perhaps there is a better / more established term for such
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."


signature.asc
Description: Digital signature


Re: KRT: Received route with strange next-hop

2015-11-19 Thread Brian Rak



On 11/19/2015 2:52 AM, Ondrej Zajicek wrote:

On Wed, Nov 18, 2015 at 01:01:44PM -0500, Brian Rak wrote:

I'm trying to figure out why BIRD is throwing this error every time it scans
the kernel routing table:

 KRT: Received route 216.155.132.254/32 with strange next-hop
45.63.4.188
 Netlink: File exists

I have two routes relevant to this one:

# ip route | grep 45.63.4.188
45.63.4.188 dev veth0 scope link
216.155.132.254 via 45.63.4.188 dev veth0 proto bird

The 45.63.4.188 route was added by me (manually), the 216.155.132.254 was
added via BIRD (BIRD learned it via BGP).

Hi

Generally, BIRD expects that the next hop address is reachable by
interface address prefix. In your case you just add device route for
45.63.4.188/32 instead of adding peer address of 45.63.4.188 to veth0. It
is true that for the kernel the difference does not matter in this
regard and that the warning is not important in this case.


What do you mean by 'device route'?  I'm not sure how that differs from 
what I have, and not finding a lot of references to that phrase online.


Re: KRT: Received route with strange next-hop

2015-11-18 Thread Ondrej Zajicek
On Wed, Nov 18, 2015 at 01:01:44PM -0500, Brian Rak wrote:
> I'm trying to figure out why BIRD is throwing this error every time it scans
> the kernel routing table:
> 
>  KRT: Received route 216.155.132.254/32 with strange next-hop
> 45.63.4.188
>  Netlink: File exists
> 
> I have two routes relevant to this one:
> 
> # ip route | grep 45.63.4.188
> 45.63.4.188 dev veth0 scope link
> 216.155.132.254 via 45.63.4.188 dev veth0 proto bird
> 
> The 45.63.4.188 route was added by me (manually), the 216.155.132.254 was
> added via BIRD (BIRD learned it via BGP).

Hi

Generally, BIRD expects that the next hop address is reachable by
interface address prefix. In your case you just add device route for
45.63.4.188/32 instead of adding peer address of 45.63.4.188 to veth0. It
is true that for the kernel the difference does not matter in this
regard and that the warning is not important in this 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."


signature.asc
Description: Digital signature


KRT: Received route with strange next-hop

2015-11-18 Thread Brian Rak
I'm trying to figure out why BIRD is throwing this error every time it 
scans the kernel routing table:


 KRT: Received route 216.155.132.254/32 with strange next-hop 
45.63.4.188

 Netlink: File exists

I have two routes relevant to this one:

# ip route | grep 45.63.4.188
45.63.4.188 dev veth0 scope link
216.155.132.254 via 45.63.4.188 dev veth0 proto bird

The 45.63.4.188 route was added by me (manually), the 216.155.132.254 
was added via BIRD (BIRD learned it via BGP).


So, to me this looks like bird adding the route to the kernel, then 
getting confused why the route exists.  Aside from this warning, 
everything appears to be working fine.  Linux routes the traffic 
properly, BIRD readvertises this route properly.


Any thoughts here?  I think I can probably suppress this warning by 
removing the 'ng->scope == SCOPE_HOST' check from netlink.c, but I'm not 
entirely sure why that's there to begin with.