BIRD - iBGP between both RS - invalid NEXT-HOP notification.
Javor Kliachev
jkliachev at neterra.net
Tue Apr 8 14:46:45 CEST 2014
Hello,
Many thanks for your working solution!!!
As per your advise I've changed it and now everything is fine with the
prefixes learned via iBGP.
root at bird-test-RS1:~# birdc show route table T65535 78.130.178.0/24 all
BIRD 1.4.2 ready.
78.130.178.0/24 via 10.0.0.22 on eth1 [R0_200 15:35:14 from
10.0.0.200] * (100) [AS29030i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 29030
BGP.next_hop: 10.0.0.22
BGP.med: 1000
BGP.local_pref: 100
BGP.community: (1,1) (1,1023) (64700,29030) (65400,0) (65400,65400)
via 10.0.0.21 on eth1 [R0_200 15:35:14 from
10.0.0.200] (100) [AS45007i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 45007
BGP.next_hop: 10.0.0.21
BGP.med: 1000
BGP.local_pref: 100
BGP.community: (1,1) (1,1087) (64700,45007) (65400,0) (65400,65400)
The prefix now is with status "*reachable" :)
*
Best~
On 04/08/2014 03:28 PM, MrBr @ GMail wrote:
> Hi Javor
> Had same problem
> Use "direct" instead of "gateway direct""
>
>
> On Tue, Apr 8, 2014 at 12:16 PM, Javor Kliachev <jkliachev at neterra.net
> <mailto:jkliachev at neterra.net>> wrote:
>
> Hello,
>
> Thanks for your detailed explanation.
>
> Today I tried the new version of BIRD with the current one setup
> with add path rx & rx but I'm observing the following things:
>
> 1) With adding: add paths rx|tx, at first time it looks works
> fine. Already more than one route path is advertised via iBGP session.
> All members learned properly it.
>
> 2) Till this moment I used the option "gateway direct" but with
> the new version I see the following output to return to CLI:
>
> root at bird-test-RS1:~# birdc configure
> BIRD 1.4.2 ready.
> Reading configuration from /usr/local/bird-patched/etc/bird.conf
> */usr/local/bird-patched/etc/AS65535, line 21: Multihop BGP cannot
> use direct gateway mode*
>
> Is this no longer supported with this combination or I trying to
> do something wrong.
>
> Here is my current config:
>
>
> /table T65535//
> //
> //protocol pipe P65535 from iBGP_PIPES {//
> // description "RS2";//
> // peer table T65535;//
> // export where RS_PIPE_OUT();//
> //}//
> //
> //protocol bgp R0_200 from iBGP {//
> // description "0.200_iBGP_RS1";//
> /
> / source address 10.0.0.100;//
> // neighbor 10.0.0.200 as 65535;/
> /
> // import all;//
> // export all;//
> // passive off;//
> // table T65535;//
> // route limit 10000;//
> /
> / add paths tx;//
> // add paths rx;//
> //# gateway direct;//
> //}//
> /
>
> 3) With the new version over established iBGP session between two
> RS all prefixes comes with
> status "unreachable" but nevertheless, the routes are distributed
> properly to the other members RIBs. This is strange.
>
> Here is output about given IPv4 prefix:
>
> root at bird-test-RS1:~# birdc show route table T65535
> 78.130.178.0/24 <http://78.130.178.0/24> all
> BIRD 1.4.2 ready.
> 78.130.178.0/24 <http://78.130.178.0/24> *unreachable* [R0_200
> 12:02:41 from 10.0.0.200] * (100/-) [AS29030i]
> Type: BGP unicast univ
> BGP.origin: IGP
> BGP.as_path: 29030
> BGP.next_hop: 10.0.0.22
> BGP.med: 1000
> BGP.local_pref: 100
> BGP.community: (1,1) (1,1023) (64700,29030) (65400,0)
> (65400,65400)
> *unreachable* [R0_200 12:02:41 from 10.0.0.200] (100/-) [AS45007i]
> Type: BGP unicast univ
> BGP.origin: IGP
> BGP.as_path: 45007
> BGP.next_hop: 10.0.0.21
> BGP.med: 1000
> BGP.local_pref: 100
> BGP.community: (1,1) (1,1087) (64700,45007) (65400,0)
> (65400,65400)
>
> I would like to know if that is normal behavior?
>
> Thanks in advance!
>
> Best~
>
>
> On 03/25/2014 11:57 PM, Ondrej Zajicek wrote:
>> On Thu, Mar 20, 2014 at 11:20:20AM +0200, Javor Kliachev wrote:
>>> Hello,
>>>
>>> Unfortunately, I still have no response from anybody. The messages
>>> continue to come into our logs.
>>> The iBGP session is UP since more than 1 week and till this moment we
>>> don't have complaints by some member.
>>>> Here is part of my bird.log:
>>>> 07-03-2014 14:19:41 R0_29: Invalid NEXT_HOP attribute in route
>> This message means that BIRD tries to send a route with NEXT_HOP attribute
>> X to a neighbor with IP address X.
>>
>> That happens because both iBGP and RS eBGP do not change NEXT_HOP,
>> so if you have neighbor N connected to both:
>>
>> RS1 --- RS2
>> \ /
>> \ /
>> \ /
>> N
>>
>> And it propagates the same route to both RS1 and RS2, then you have the
>> same route both times in RS1 and RS2. Usually the directly received is
>> prefered, but if for some reason the one received through IBGP is
>> preferred (perhaps N sends a withdraw, which is propagated first to RS1
>> so directly received route disappears but the one received from RS2 by
>> iBGP is still in RS1 for a moment), then it is scheduled for propagation
>> back to N, but the check for NEXT_HOP denies it.
>>
>> I am not sure now whether this is some non-standard situation or the
>> check should be silent. Generally i would advise against connecting
>> route servers through IBGP. You get most routes two times, therefore
>> double memory requirements. Another reason is that IBGP (unless with
>> ADD-PATH extension) will silently eliminate non-preferred routes,
>> which would cause hidden unexpected problems.
>>
>
> --
> ---
> Find out about our new Cloud service - Cloudware.bg
> <http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link&utm_campaign=newwebsite>
> Access anywhere. Manage it yourself. Pay as you go.
> ------------------------------------------------------------------------
> *Javor Kliachev*
> IP Engineer
>
> Neterra Ltd.
> Telephone: +359 2 975 16 16 <tel:%2B359%202%20975%2016%2016>
> Fax: +359 2 975 34 36 <tel:%2B359%202%20975%2034%2036>
> www.neterra.net <http://www.neterra.net>
>
>
>
--
---
Find out about our new Cloud service - Cloudware.bg
<http://cloudware.bg/?utm_source=email&utm_medium=signature&utm_content=link&utm_campaign=newwebsite>
Access anywhere. Manage it yourself. Pay as you go.
------------------------------------------------------------------------
*Javor Kliachev*
IP Engineer
Neterra Ltd.
Telephone: +359 2 975 16 16
Fax: +359 2 975 34 36
www.neterra.net <http://www.neterra.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140408/3a0ee502/attachment-0001.html>
More information about the Bird-users
mailing list