Hello, I am new to Bird and I am trying to set up a Looking-Glass. I have configured a iBGP-Session with a route-reflector to gather the needed routes. When I do a "show route". Every route I got via BGP is unreachable. xxx.xxx.xxx.xxx/24 unreachable [bgp_v4 13:32:40 from xxx.xxx.xxx.xxx] * (100/-) [ASxxxxxxi] The Log will give me the following: 2016-04-10 13:32:44 <WARN> Next hop address xxx.xxx.xxx.xxx resolvable through recursive route for xxx.xxx.xxx.xxx/24 When I add a static route via Bird for the unreachable prefix to the next hop the route is resolvable. route xxx.xxx.xxx.xxx/32 via xxx.xxx.xxx.xxx A static default gateway won't do the trick (route 0.0.0.0/0 via xxx.xxx.xxx.xxx;). the routes are still unreachable. Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop? Best regards, Marius
Found a typo... When I add a static route via Bird for the unreachable prefix to the next hop the route is resolvable. route xxx.xxx.xxx.xxx/24 via xxx.xxx.xxx.xxx Sorry for the inconvenience From: pandawithrobotlegs@outlook.com To: bird-users@network.cz Subject: iBGP unreachable Date: Mon, 11 Apr 2016 17:13:22 +0200 Hello, I am new to Bird and I am trying to set up a Looking-Glass. I have configured a iBGP-Session with a route-reflector to gather the needed routes. When I do a "show route". Every route I got via BGP is unreachable. xxx.xxx.xxx.xxx/24 unreachable [bgp_v4 13:32:40 from xxx.xxx.xxx.xxx] * (100/-) [ASxxxxxxi] The Log will give me the following: 2016-04-10 13:32:44 <WARN> Next hop address xxx.xxx.xxx.xxx resolvable through recursive route for xxx.xxx.xxx.xxx/24 When I add a static route via Bird for the unreachable prefix to the next hop the route is resolvable. route xxx.xxx.xxx.xxx/32 via xxx.xxx.xxx.xxx A static default gateway won't do the trick (route 0.0.0.0/0 via xxx.xxx.xxx.xxx;). the routes are still unreachable. Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop? Best regards, Marius
On 04/11/2016 05:13 PM, Panda RoboLegs wrote:
Hello, I am new to Bird and I am trying to set up a Looking-Glass.
I have configured a iBGP-Session with a route-reflector to gather the needed routes.
When I do a "show route". Every route I got via BGP is unreachable.
Is your IGP table correctly feeded?
Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop?
I assume that your iBGP sessions are multihop. Therefore at least your kernel should know where to connect … maybe you can add something like this (writing without looking into doc, typos may occur): protocol kernel { table igpt; import all; export none; learn; } protocol bgp { ... igp table igpt; } This assumes that your IGP table is feeded by another source than this running Bird. -- MQ
Hello, there is no IGP. I thought that I can resolve the BGP-Next-Hop via static default gateway (0.0.0.0/0). It seems that is not possible. Does anyone have a link where it is written that BGP next-hop is not resolvable via static default gw? But now the good news: I found an old mailing list entry with an snippet that solved my problem. filter test { gw = IP-directly-connected-next-hop; accept; } protocol bgp { ... import filter test; } So now every route has a directly connected default gw. every route is resolvable. The question above is still unanswered. why bgp can't resolve the next hop via default gw Further links will be appreciated. Best regards
Subject: Re: iBGP unreachable To: bird-users@network.cz From: jan.matejka@nic.cz Date: Mon, 11 Apr 2016 21:21:24 +0200
On 04/11/2016 05:13 PM, Panda RoboLegs wrote:
Hello, I am new to Bird and I am trying to set up a Looking-Glass.
I have configured a iBGP-Session with a route-reflector to gather the needed routes.
When I do a "show route". Every route I got via BGP is unreachable.
Is your IGP table correctly feeded?
Is there any posibility to solve ths problem without adding an IGP or a static route to every next hop?
I assume that your iBGP sessions are multihop. Therefore at least your kernel should know where to connect … maybe you can add something like this (writing without looking into doc, typos may occur):
protocol kernel { table igpt; import all; export none; learn; }
protocol bgp { ... igp table igpt; }
This assumes that your IGP table is feeded by another source than this running Bird. -- MQ
On Tue, Apr 12, 2016 at 11:21:15AM +0200, Panda RoboLegs wrote:
Hello,
there is no IGP. I thought that I can resolve the BGP-Next-Hop via static default gateway (0.0.0.0/0). It seems that is not possible. Does anyone have a link where it is written that BGP next-hop is not resolvable via static default gw?
Hi The default route could be used, but the problem here is that next hops are resolved by more specific routes that arrive through BGP, so you get a cycle. One solution is to put BGP routes to a different routing table than default route / IGP routes and use 'igp table' option in BGP protocols to specify the second table. Another workaround is just to override gw or bgp_next_hop in the import filter, as you already found. -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
I tried the configuration with a second table and the "igb table" in bgp protocol. And it is working fine. Thank you for your help and your explanation. Best regards
Date: Tue, 12 Apr 2016 15:25:00 +0200 From: santiago@crfreenet.org To: pandawithrobotlegs@outlook.com CC: bird-users@network.cz Subject: Re: iBGP unreachable
On Tue, Apr 12, 2016 at 11:21:15AM +0200, Panda RoboLegs wrote:
Hello,
there is no IGP. I thought that I can resolve the BGP-Next-Hop via static default gateway (0.0.0.0/0). It seems that is not possible. Does anyone have a link where it is written that BGP next-hop is not resolvable via static default gw?
Hi
The default route could be used, but the problem here is that next hops are resolved by more specific routes that arrive through BGP, so you get a cycle.
One solution is to put BGP routes to a different routing table than default route / IGP routes and use 'igp table' option in BGP protocols to specify the second table.
Another workaround is just to override gw or bgp_next_hop in the import filter, as you already found.
-- Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago@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."
participants (4)
-
Jan Matejka -
oleynikov_v＠ufanet.ru -
Ondrej Zajicek -
Panda RoboLegs