Hello Ondrej, Thanks for quick response. Additional option to ignore link-local BGP next hops would help us a lot. We use bird as routing demon for router, and our software does not install BGP routes with link-local next hops in ASIC. 1.“gw=bgp_next_hop” does not work for us because like you mentioned we don’t have flat network and over iBGP we receive some routes with dummy next hop which later should resolved by local static route, “gw=bgp_next_hop ” reject these routes saying “<ERR> filters, line 2827: Invalid gw address” 2. I tried bgp_next_hop= bgp_next_hop in local import filter. Like you said it does not work. My remote iBGP is juniper and we set next hop in export filter, it still does not fix problem on local router. router> show configuration policy-options policy-statement INTX-FRA13-EXPORT … term SET-NEXT-HOP_v6 { from family inet6; then { next-hop 2600:1488:6081:106::a; next term; } } Thanks, Dariusz On 9/20/22, 6:11 PM, "Ondrej Zajicek" <santiago@crfreenet.org> wrote: On Mon, Sep 19, 2022 at 01:23:28PM +0000, Mazur, Dariusz via Bird-users wrote: > Hello, > In my setup I have iBGP session with peer , and I learn v6 route. It is iBGP so we have 2 next hops global and link-local. By default bird uses link-local when route is exported to kernel. Is there any command to change this behavior and use global v6 address as BGP next hop when we export routes to kernel ? Hello The dual next hop for IPv6 routes is kind of hack and not really reflected in filter code, which means that bgp_next_hop attribute represents just global address. Therefore, you can do: bgp_next_hop = bgp_next_hop; in remote IBGP export filter to reset bgp_next_hop attribute to just its global address. I think it would not work in local IBGP import filter - we assign recursive immediate next hop based on bgp_next_hop when route is received before import filter, so later change of bgp_next_hop in IBGP import filter would not affect existing immediate next hop. You can also change immediate next hop (route attribute 'gw'), either in local IBGP import filter, or Kernel protocol export filter: gw = bgp_next_hop; but that would work only if you have flat network and there is no intermediate hop between local system and bgp_next_hop. We probably should just add option to ignore link-local BGP next hops ... > Table master6: > fc00:2001:100:12::/64 unicast [2001:4878:c225::1:3:2__r02.ien.labkrk01.sdn 12:57:29.076] * (100) [i] > via 2001:4878:c225::1:3:2 on eth-1\1\4 > Type: BGP univ > BGP.origin: IGP > BGP.as_path: > BGP.next_hop: 2001:4878:c225::1:3:2 fe80::1:3:2 > BGP.local_pref: 400 > BGP.community: (20940,550) > > Thanks, > Dariusz -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."

Hi, In documentation part it is written that the default for the option is "disabled". But in the code I see it chooses the value based on "gw_mode":

Different default for next_hop_prefer

Am I missing something or there is a typo? On Mon, Oct 10, 2022 at 5:44 AM Ondrej Zajicek via Bird-users <bird-users@network.cz> wrote:

On Wed, Sep 21, 2022 at 08:47:03AM +0000, Mazur, Dariusz wrote:

...

Hello Ondrej, Thanks for quick response. Additional option to ignore link-local BGP next hops would help us a lot.

Hello

Done, here is a commit with BGP channel option 'next hop prefer global', which makes BIRD to use global next hop instead of link-local:

https://gitlab.nic.cz/labs/bird/-/commit/8f79e6b93e32a4eb7e4dda9bd4a9d04400b...

...

On 9/20/22, 6:11 PM, "Ondrej Zajicek" <santiago@crfreenet.org> wrote:

On Mon, Sep 19, 2022 at 01:23:28PM +0000, Mazur, Dariusz via Bird-users wrote: > Hello, > In my setup I have iBGP session with peer , and I learn v6 route. It is iBGP so we have 2 next hops global and link-local. By default bird uses link-local when route is exported to kernel. Is there any command to change this behavior and use global v6 address as BGP next hop when we export routes to kernel ?

Hello

The dual next hop for IPv6 routes is kind of hack and not really reflected in filter code, which means that bgp_next_hop attribute represents just global address. Therefore, you can do:

bgp_next_hop = bgp_next_hop;

in remote IBGP export filter to reset bgp_next_hop attribute to just its global address.

I think it would not work in local IBGP import filter - we assign recursive immediate next hop based on bgp_next_hop when route is received before import filter, so later change of bgp_next_hop in IBGP import filter would not affect existing immediate next hop.

You can also change immediate next hop (route attribute 'gw'), either in local IBGP import filter, or Kernel protocol export filter:

gw = bgp_next_hop;

but that would work only if you have flat network and there is no intermediate hop between local system and bgp_next_hop.

We probably should just add option to ignore link-local BGP next hops ...

> Table master6: > fc00:2001:100:12::/64 unicast [2001:4878:c225::1:3:2__r02.ien.labkrk01.sdn 12:57:29.076] * (100) [i] > via 2001:4878:c225::1:3:2 on eth-1\1\4 > Type: BGP univ > BGP.origin: IGP > BGP.as_path: > BGP.next_hop: 2001:4878:c225::1:3:2 fe80::1:3:2 > BGP.local_pref: 400 > BGP.community: (20940,550) > > Thanks, > Dariusz

-- Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago@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."

Hello,

We probably should just add option to ignore link-local BGP next hops ... I would also like to see a configuration option for this. At the moment we use the "gw = bgp_next_hop" workaround. In our situation the upstream provider has a redundant setup, where the session is moved between two routers. Both have the same global IPv6 address, but different link-lokal addresses.

So when the providers switches to the other node the routes have the old link-lokal from the other side and then the routes are not working anymore. With the "gw = bgp_next_hop" workaround we have fixed this. Best regards, Oliver