Thank you for the detailed explanation. I understand, since "multihop" was specified, it tried to resolve the gateway recursively - which didn't work because the matching routes were missing in the routing table.
When I deleted "multihop", the next hop was taken directly from "bgp_next_hop", which does not need lookup from the route table. This was at least possible for the next AS, for the further ones logically not anymore. All right, thanks a lot! On 23-07-2021 02:32, Ondrej Zajicek wrote: > On Thu, Jul 22, 2021 at 10:04:29PM +0200, Rainer Kulow wrote: > > Hello, > > > > Thank you very much for your response. > > Actually, this is just an extracted example from a larger setup to > > show the problem in a simpler way. Therefore, the use of BGP seems > > perhaps a bit superfluous here. > > > > In fact, you were absolutely right with your guess. > > everything works as desired. > > Hello > > Yes, there is the option 'gateway', which controls how immediate next hops are computed from bgp_next_hop attributes. It uses different defaults for direct or multihop sessions: > > https://bird.network.cz/?get_doc&v=20&f=bird-6.html#bgp-gateway > > For multihop, recursive mode is used and bpg_next_hop is resolved through local / IGP routes, so you need such routes in the routing table (e.g. from Direct or OSPF protocols). > > > > > >If I delete "multihop" and "next hop self" from the template, I > > > > >get all routes, but can only ever ping the closest AS. > > IMHO it should work without 'multihop' and 'next hop self' and that would be the natural approach. My first guess why you can ping only the closest AS is that you do not propagate /30 connecting networks, just /16 networks, and trying ping from the router is uses src IP from the /30 connecting range (unless explicitly forced to use different one using -I option), so the destination router cannot answer ping back because > it is missing the non-local /30 route. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'Santiago' Zajicek (email: [email protected]) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." >
smime.p7s
Description: S/MIME cryptographic signature
