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.
smime.p7s
Description: S/MIME Cryptographic Signature
