Re: ibgp bird 1.6 vs 2.0
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
Re: ibgp bird 1.6 vs 2.0
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.
> 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 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.
>
> 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.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
Re: ibgp bird 1.6 vs 2.0
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:
router bgp 65000
bgp log-neighbor-changes
network 192.168.1.0
network 192.168.2.0
neighbor 192.168.1.1 remote-as 65001
neighbor 192.168.2.2 remote-as 65000
The routes are correctly sent from R2 to R3 (checked it with tcpdump and
routes are included in BGP updates)
M.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: ibgp bird 1.6 vs 2.0
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.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santi...@crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
ibgp bird 1.6 vs 2.0
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; }
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?
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.
According to the docs, iBGP should find route to NEXT_HOP IP address in
its routing table, so why are the routes marked as unreachable in bird2,
if the route is there?
Thank you and best regards,
M.
smime.p7s
Description: S/MIME Cryptographic Signature
