BIRD - iBGP between both RS - invalid NEXT-HOP notification.

[Javor Kliachev]

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 all
BIRD 1.4.2 ready.
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
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/3296da2a/attachment.html>