iBGP RR IPv6 link-local next-hop not kept
Hello, I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>. I want to pass this information to my router, but what the router receive is always 2001:db8:db8::/56 via <global unicast addr of the DHCPv6 server>. Why would next-hop change if it's iBGP? Here is my DHCPv6 server's BIRD configuration: ipv6 table pd; protocol kernel dhcpv6_pd { learn; kernel table 20; scan time 1; ipv6 { table pd; import all; export none; }; } protocol bgp prefix_delegation { local <some global unicast addr> as 65535; neighbor <some global unicast addr> as 65535; direct; ipv6 { table pd; next hop keep; import none; export filter { if ( proto = "dhcpv6_pd" ) then { accept; } else reject; }; }; graceful restart; } Here is my router's BIRD configuration: protocol bgp prefix_delegation { local <some global unicast addr> as 65535; neighbor <some global unicast addr> as 65535; direct; ipv6 { import filter { if net.len = 48 then { accept; } else reject; }; export none; }; graceful restart; } Thanks for any suggestions!
On Tue, Feb 28, 2023 at 02:57:54PM -0500, Mirai Azayaka wrote:
Hello,
I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>. I want to pass this information to my router, but what the router receive is always 2001:db8:db8::/56 via <global unicast addr of the DHCPv6 server>. Why would next-hop change if it's iBGP?
Hello Because link-local address is not resolvable through IGP routing table then it does not really make sense to keep it when propagating through IBGP. I.e., the regular next-hop is valid through the whole local AS, so we can pass it unmodified through IBGP, but link-local next-hop is valid only on a specific link. Note that BIRD almost always keep bgp_next_hop attribute when it is set manually in the export filter, so if you use something like: bgp_next_hop = gw; in prefix_delegation export filter, it should keep the value, even if it is link-local. -- 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."
Wow, thank you so much! Setting bgp_next_hop = gw; works for me! (yeah I was worried that because link-local address is interface-dependent, my router wouldn't be able to know the interface. It seems my router (also running bird) chooses the same interface as the BGP session, which is what I want. On Tue, Feb 28, 2023 at 5:32 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Feb 28, 2023 at 02:57:54PM -0500, Mirai Azayaka wrote:
Hello,
I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>. I want to pass this information to my router, but what the router receive is always 2001:db8:db8::/56 via <global unicast addr of the DHCPv6 server>. Why would next-hop change if it's iBGP?
Hello
Because link-local address is not resolvable through IGP routing table then it does not really make sense to keep it when propagating through IBGP.
I.e., the regular next-hop is valid through the whole local AS, so we can pass it unmodified through IBGP, but link-local next-hop is valid only on a specific link.
Note that BIRD almost always keep bgp_next_hop attribute when it is set manually in the export filter, so if you use something like:
bgp_next_hop = gw;
in prefix_delegation export filter, it should keep the value, even if it is link-local.
-- 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, As far as I remember, you can set in your income filter the interface, then the gateway (in that order) to force the interface you want. On Wed, Mar 1, 2023, 02:18 Mirai Azayaka <azayaka@apernet.io> wrote:
Wow, thank you so much! Setting bgp_next_hop = gw; works for me! (yeah I was worried that because link-local address is interface-dependent, my router wouldn't be able to know the interface. It seems my router (also running bird) chooses the same interface as the BGP session, which is what I want.
On Tue, Feb 28, 2023 at 5:32 PM Ondrej Zajicek <santiago@crfreenet.org> wrote:
On Tue, Feb 28, 2023 at 02:57:54PM -0500, Mirai Azayaka wrote:
Hello,
I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>. I want to pass this information to my router, but what the router receive is always 2001:db8:db8::/56 via <global unicast addr of the DHCPv6 server>. Why would next-hop change if it's iBGP?
Hello
Because link-local address is not resolvable through IGP routing table then it does not really make sense to keep it when propagating through IBGP.
I.e., the regular next-hop is valid through the whole local AS, so we can pass it unmodified through IBGP, but link-local next-hop is valid only on a specific link.
Note that BIRD almost always keep bgp_next_hop attribute when it is set manually in the export filter, so if you use something like:
bgp_next_hop = gw;
in prefix_delegation export filter, it should keep the value, even if it is link-local.
-- 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 Mirai, On Tue, Feb 28, 2023 at 02:57:54PM -0500, Mirai Azayaka wrote:
I am trying to send routes from my DHCPv6 prefix delegation server to my router using iBGP. Those delegated prefix routes on the DHCPv6 server are installed in its kernel table, such as 2001:db8:db8::/56 via <client's link-local addr>.
Wow, that's actually a really interesting way to deploy DHCPv6 PD! I've been researching how to deploy PD outside of the proprietary vendor sandboxes recently (mainly still focusing on using DHCPv6 relays with route snooping), but haven't found any good free-software options so far. Perhaps your approach could be more viable for a small network like mine. Would you mind elaborating on your setup a bit more? Thanks, --Daniel (AS212704)
participants (4)
-
Alexander Zubkov -
Daniel Gröber -
Mirai Azayaka -
Ondrej Zajicek