EBGP Multihop /w Directly Connected Peer

[Anthony Hoppe]

OK, playing around with the config a bit and it seems removing my
interface filtering for protocol direct is the best way to go.  I
realized that I actually do not need to restrict it anyway as the
import/export filters on the kernel and BGP side of things takes care
of ensuring only the routes I expect are installed on the host and
advertised to its peers.

Thank you for the help!

~ Anthony

On Tue, Apr 8, 2025 at 10:21 AM Anthony Hoppe <ahoppe at backblaze.com> wrote:
>
> Apologies for the response delay!  Somehow I missed your reply.  I'll
> play around with your suggestions and see what happens and, of course,
> report back.  Thanks!
>
>
>
> On Thu, Apr 3, 2025 at 5:50 AM Alexander Zubkov <green at qrator.net> wrote:
> >
> > The problem might be that bird does not have direct routes for the nexthop of incoming routes. You can try to drop the interface filter from "protocol direct". And if you do not want to export routes of other interfaces - you can reject them in filters. Or alternatively you can add a "generic" direct protocol for the means of having direct routes in your table, and another direct protocol with interface filter, so you can match routes just by protocol name. And there is one more option, I think you can import those direct options in "proto kernel" with "learn all" option.
> >
> > On Wed, Apr 2, 2025 at 7:54 PM Anthony Hoppe <ahoppe at backblaze.com> wrote:
> >>
> >> I do have "protocol direct" in my configuration, but am only allowing
> >> loopback and dummy interfaces as I only want BIRD to advertise the
> >> prefixes assigned to these interfaces.  Below is my configuration.
> >> The intention here is to accept a default route from its peer (the
> >> access switch it's connected to) and to advertise /32's and/or /128's
> >> assigned to a loopback and/or dummy interface.  The switch and host
> >> are on the network fd00:feed::/64 with the switch at fd00:feed::1 and
> >> the host at fd00:feed::3cec:efc4:177a.
> >>
> >> If I remove the interface filters under protocol direct, it does seem
> >> that BIRD automatically resolves the next-hop using link-local
> >> addressing.
> >>
> >> If I leave "protocol direct" as is, and assign the switch
> >> fd00:abcd::1/128 and add:
> >>
> >> protocol static {
> >>         ipv6;
> >>         route fd00:abcd::1/128 via fd00:feed::1;
> >> }
> >>
> >> And adjust the configuration to peer with fd00:abcd::1, this also works.
> >>
> >> However, the preferred configuration if possible is to peer with the
> >> switch via the directly connected address fd00:feed::1 and also keep
> >> it as the next-hop.
> >>
> >> ----------
> >>
> >> log syslog all;
> >>
> >> router id 10.245.0.57;
> >>
> >> protocol device {
> >> }
> >>
> >> protocol direct {
> >> ipv4;
> >> ipv6;
> >> interface "lo*", "dummy*";
> >> }
> >>
> >> protocol kernel {
> >> ipv4 {
> >>       import none;
> >>       export all;
> >> };
> >> }
> >>
> >> protocol kernel {
> >> ipv6 {
> >> import none;
> >> export all;
> >> };
> >> }
> >>
> >> template bgp Upstream_Peers {
> >> local as 65920;
> >> hold time 30;
> >> multihop 2;
> >> ipv4 {
> >> extended next hop;
> >> import filter {
> >> if ( net ~ [ 0.0.0.0/0 ] ) then accept;
> >> reject;
> >> };
> >> export filter {
> >> if ( net ~ [ 0.0.0.0/0{32,32} ] ) then accept;
> >> reject;
> >> };
> >> };
> >> ipv6 {
> >> import filter {
> >> if ( net ~ [ ::/0 ] ) then accept;
> >> reject;
> >> };
> >> export filter {
> >> if ( net ~ [ ::0/0{128,128} ] ) then accept;
> >> reject;
> >> };
> >> };
> >> }
> >>
> >> protocol bgp access_switch_1 from Upstream_Peers { neighbor
> >> fd00:feed::1 as 65921; }
> >>
> >> ----------
> >>
> >> ~ Anthony
> >>
> >>
> >>
> >>
> >> On Mon, Mar 31, 2025 at 4:46 PM Alexander Zubkov <green at qrator.net> wrote:
> >> >
> >> > 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.
> >>
> >> --
> >> 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.

-- 
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.