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