ibgp bird 1.6 vs 2.0
Ondrej Zajicek
santiago at crfreenet.org
Tue Apr 30 16:44:55 CEST 2019
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: santiago at 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."
More information about the Bird-users
mailing list