EBGP Multihop /w Directly Connected Peer

[Alexander Zubkov]

Hi,

As far as I remember, when multihop option is enabled it enables (or even
forces) "gateway recursive". So it changes the behaviour of how the nex hop
is selected. This might be your issue. Could you provide more details of
what you have? The result might depend on the routes you have in your
table. Do you have "protocol direct" in your config, for example?

Regards,
Alexander

On Thu, Mar 27, 2025 at 11:04 PM Anthony Hoppe via Bird-users <
bird-users at network.cz> wrote:

> Hello,
>
> I have a situation where I need to enable EBGP multihop even though the
> peer is directly connected.  Backstory: I have hosts running BIRD peered
> with MLAG paired switches and there are instances where BGP ECMP and LACP
> hashing don't align.  BGP packets destined to one peer (Switch A) will land
> on the other switch in the pair (Switch B).  In this case, the switch in
> which the packet landed (Switch B) will route the packet to the correct
> switch (Switch A) causing TTL to decrement.
>
> When I configure multihop in BIRD, it seems BIRD assumes that the next-hop
> address is unreachable and expects there to be a static route to the peer
> before it will consider accepted routes reachable.  I can't add a static
> route that points to itself, so in my testing environment I ended up adding
> a /128 to the loopback interface on both switches and configured BIRD peer
> with that address.  Then I was able to add the static route BIRD is
> expecting (and is now actually necessary), and multihop works fine.
>
> However, if possible, I'd like to avoid having to do this.  Is there a way?
>
> Thanks!
>
> ~ Anthony
>
>
> This email, including its contents and any attachment(s), may contain
> confidential and/or proprietary information and is solely for the review
> and use of the intended recipient(s). If you have received this email in
> error, please notify the sender and permanently delete this email, its
> content, and any attachment(s). Any disclosure, copying, or taking of any
> action in reliance on an email received in error is strictly prohibited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20250331/07d51705/attachment.htm>