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

[MrBr @ GMail]

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>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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20140408/5023d4cf/attachment-0001.html>