ibgp bird 1.6 vs 2.0

[Matěj Grégr]

On 30.04.2019 16:44, Ondrej Zajicek wrote:
> On Tue, Apr 30, 2019 at 04:02:36PM +0200, Matěj Grégr wrote:
>>
>>
>> On 30.04.2019 15:56, Ondrej Zajicek wrote:
>>> On Tue, Apr 30, 2019 at 03:34:59PM +0200, Matěj Grégr wrote:
>>>> Hello,
>>>>   we have encountered a different ibgp behavior between bird 1.6 and
>>>> bird2, and I am not sure if it's an intentional change in bird2 or a
>>>> bug. Let's consider the following topology:
>>>>
>>>>       192.168.1.0/24           192.168.2.0/24
>>>>  R1 ------- ebgp ------- R2 ------- ibgp ------- R3
>>>>    .2                 .1   .1                  .2
>>>>
>>>> R1 uses AS 65001, R2 and R3 uses AS 65000. R1 propagates some routes
>>>> (e.g. 10.10.10.0/24) via eBGP to R2, which sends them to R3 via iBGP.
>>>> bird2 config on R3:
>>>>
>>>> template bgp IBGP {
>>>>         local as 65000;
>>>>         direct;
>>>>         ipv4 {
>>>>                 next hop self;
>>>>                 import keep filtered on;
>>>>                 import all;
>>>>         };
>>>> }
>>>>
>>>> protocol bgp from IBGP { neighbor 192.168.2.1 as 65000; }
>>>
>>> What bird is config on R2?
>>>
>>> I don't think there are any intentional changes w.r.t. your config.
>>>
>>
>> R2 is not running bird, but it's a cisco router, but we encounter the
>> same behavior with other vendors as well (HP). The config is pretty
>> simple on R2:
> 
> OK, the question is whether R2 is using something like 'next hop self'.
> Based on the config i assume that no, and therefore BGP_NEXT_HOP announced
> from R2 to R3 is probably 192.168.1.2.
> 

Yes, exactly.

>> Now there are two issues:
>>
>> 1) the bird on R3 reports "Invalid NEXT_HOP attribute" and doesn't learn
>> any R1 routes from R2. If the "direct" option is removed from the
>> config, R3 will learn R1 routes. However, if R3 runs bird1.6, it learns
>> all routes even with the direct option.
>>
>> According to the docs, "direct" is a check for directly connected
>> neighbors. The neighbor 192.168.2.1 is directly connected and in the
>> same subnet, so I don't understand, why there is an issue with NEXT_HOP
>> and why are routes silently dropped on R3?
> 
> 'direct' is not only the check for directly connected, but also specifies
> default value for 'gateway' option (direct vs. recursive). In 'gateway
> direct' mode we expect BGP_NEXT_HOP to be directly connected.

I always thought that direct and gateway are two different options. If
setting direct also alter gateway option, a note in the docs would be great.

> I checked the code and we have fallback in BIRD 1.6 that if BGP_NEXT_HOP
> is not directly connected, we silently ignore it and use IP address of
> the neighbor. We removed this fallback in BIRD 2.0 and instead report the
> error. So it was intentional change. You could workaround that by setting
> 'next hop self' (or equivalent) on R2.

Ah, good to know. Thanks!

>> 2) If direct is removed from the config, bird2 on R3 learns R1 routes,
>> but with status unreachable. Even if I send 192.168.1.0/24 from R2 to R3
>> so the route 192.168.1.0/24 is in R3's routing table and ping from R3 to
>> the NEXT_HOP IP address is successful. bird1.6 works without a problem
>> with or without direct option and all routes are learned and reachable.
> 
> This is a limitation in BIRD that it resolves recursive next hops (from
> multihop BGP) only through non-recursive routes (e.g. static or OSPF
> routes). So if you announce 192.168.1.0/24 through the same BGP session,
> it is not used for this purpose. But i am sure the same behavior was also
> in BIRD 1.6. The workaround is to have static/RIP/OSPF route for
> 192.168.1.0/24, or 'next hop self' on R2.
> 

Yes, probably the behavior is same in bird 1.6, but it was hidden with
the NEXT_HOP fallback you have in 1.6. bird 1.6 sees the routes as
reachable because it uses peer address as the next hop, not the IP
address from the NEXT_HOP attribute.

Anyway, thanks a lot for clarification! We will alter the config
accordingly.

Best regards,
M.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2929 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20190430/b1cf8ddf/attachment.p7s>