AW: Problems configuring multihop BGP setup

[Rainer Kulow]

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: 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."
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6007 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20210723/a4d300b4/attachment.p7s>