Missing IPv6 default route on protocol kernel and table master6
Hey *, I do not see a default route for IPv6 on the `kernel` protocol (or `table master6`), like with IPv4, therefor I'm unable to export it via `ospf`. I'm running bird 2.0.8 on OpenWRT 21.02, Kernel 5.4.154. At first I thought it's because I had `pppoe-wan` not covered in `proto device` and `direct`, but `proto kernel` uses `learn yes` and with IPv4 it makes `bird` aware of the default route, but not so with IPv6. (At least I assume so. Please correct me on possible misconceptions.) ``` root@cpe:~# birdc show route for 0.0.0.0 BIRD 2.0.8 ready. Table master4: 0.0.0.0/0 unicast [kernel_ipv4 08:16:19.473] * (10) via 62.155.247.X on pppoe-wan root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Network not found root@cpe:~# ip -6 route show default default from 2003:e4:bf24:XX00::/56 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from 2003:e4:bfff:XXXX::/64 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from fde6:a09a:b373:f0::/64 dev pppoe-wan metric 1024 pref medium default from fde6:a09a:b373:ff::/64 dev pppoe-wan metric 1024 pref medium ``` I have now: * `pppoe-wan` covered in `device` and `direct` * `kernel` with - `learn yes`, and - `import all`, and - `export filter { accept; };` * `ospf` even has `interface "pppoe-wan" { stub yes; };` and `export all`. But still ::/0 is not present in `bird`. Am I missing something (obvious) here? Thanks for advice and help. Bernd PS: Can I show/filter routes on `protocol kernel` which are "learned" and not "imported"?
I may should have had a look at the log before :/ ``` Thu Oct 6 09:32:51 2022 daemon.err bird: KRT: Received route ::/0 with strange next-hop fe80::f6cc:55ff:fe42:1a94 ``` But why is this a strange a next-hop? Routes with via Link-Local next-hop just work fine with OSPF and BGP, whats the issue here?
On Thu, Oct 06, 2022 at 11:37:18AM +0200, Bernd Naumann via Bird-users wrote:
I may should have had a look at the log before :/
``` Thu Oct 6 09:32:51 2022 daemon.err bird: KRT: Received route ::/0 with strange next-hop fe80::f6cc:55ff:fe42:1a94 ```
But why is this a strange a next-hop? Routes with via Link-Local next-hop just work fine with OSPF and BGP, whats the issue here?
Hi That error message means the next hop was not found in interface address ranges. I do not see why link-local next hops should not work. What is your output from command 'show interfaces'? -- 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."
On 2022-10-06 15:11, Ondrej Zajicek wrote:
On Thu, Oct 06, 2022 at 11:37:18AM +0200, Bernd Naumann via Bird-users wrote:
I may should have had a look at the log before :/
``` Thu Oct 6 09:32:51 2022 daemon.err bird: KRT: Received route ::/0 with strange next-hop fe80::f6cc:55ff:fe42:1a94 ```
But why is this a strange a next-hop? Routes with via Link-Local next-hop just work fine with OSPF and BGP, whats the issue here?
Hi
That error message means the next hop was not found in interface address ranges. I do not see why link-local next hops should not work. What is your output from command 'show interfaces'?
Hey Ondreh, Thanks for having a look. ``` root@cpe:~# ip -6 addr show dev pppoe-wan 35: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 inet6 2003:e4:bfff:XXXX:6c2f:796c:6521:7f54/64 scope global dynamic noprefixroute valid_lft 13960sec preferred_lft 1360sec inet6 fe80::6c2f:796c:6521:7f54/128 scope link valid_lft forever preferred_lft forever root@cpe:~# birdc show interfaces ... pppoe-wan up (index=35) PtP Multicast AdminUp LinkUp MTU=1492 93.206.5.X/32 (Preferred, opposite 62.155.247.65, scope univ) 2003:e4:bfff:XXXX:6c2f:796c:6521:7f54/64 (Preferred, scope univ) fe80::6c2f:796c:6521:7f54/128 (Preferred, scope link) ... ``` I assume you are only interested in the pppoe-wan interface right? I have to admit I have no clear knowledge about pppoe, but maybe this is related to my issue here. Because I do not have LLA with `/64` on pppoe-wan, but only `/128`. My LLA, and the GW LLA, is present as a host-route (`/128`). Thanks again. Bernd
Update: On 2022-10-06 20:39, Bernd Naumann via Bird-users wrote:
On 2022-10-06 15:11, Ondrej Zajicek wrote:
On Thu, Oct 06, 2022 at 11:37:18AM +0200, Bernd Naumann via Bird-users wrote:
I may should have had a look at the log before :/
``` Thu Oct 6 09:32:51 2022 daemon.err bird: KRT: Received route ::/0 with strange next-hop fe80::f6cc:55ff:fe42:1a94 ```
But why is this a strange a next-hop? Routes with via Link-Local next-hop just work fine with OSPF and BGP, whats the issue here?
This was bogus. I have tried to add a route explicit with `ip -6 route add default via LLA dev pppoe-wan` and forgot to remove it afterwards. (But the local LLA, and the peer LLA are still present as host routes.) If I use `protocol static`: If I add `route ::/0 via "pppoe-wan"` to `protocol static`, then the route is present in `master6` it gets exported to `protocol kernel`. This however works, **but** in case the PPP sessions fails, then the default route is still present. If I add the route to the Linux Routing Table: If I `ip -6 route add default dev pppoe-wan` then `protocol kernel` learns the route. But then I still need to check the pppoe session, and remove this route if the session is down. I would ratter prefer to understand why bird is unable to pick up the ipv6 default route on this pppoe device.
On Fri, Oct 07, 2022 at 11:29:33AM +0200, Bernd Naumann via Bird-users wrote:
Update:
I would ratter prefer to understand why bird is unable to pick up the ipv6 default route on this pppoe device.
Hi Does the pppoe-wan have link-local address range? Does BIRD know about it? What is What is the output from BIRD command 'show interfaces'? -- 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."
On 2022-10-07 18:32, Ondrej Zajicek wrote:
Does the pppoe-wan have link-local address range? Does BIRD know about it? What is What is the output from BIRD command 'show interfaces'?
I assume no. Like I have written, the LLA is `/128`. I do not see the gateway in the `neighbor` table, but local LLA and gateway LLA are present as host routes. I have reverted my changes: - No `ip -6 route add default dev pppoe-wan` - No `route ::/0 via "pppoe-wan"` on `protocol static` I have now: ``` root@cpe:~# ip addr show dev pppoe-wan 42: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 link/ppp inet 93.206.14.134 peer 62.155.247.65/32 scope global pppoe-wan valid_lft forever preferred_lft forever inet6 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 scope global dynamic noprefixroute valid_lft 13916sec preferred_lft 1316sec inet6 fe80::71b4:e83:65bb:a41f/128 scope link valid_lft forever preferred_lft forever root@cpe:~# ip -6 r | grep pppoe default from 2003:e4:bf20:6d00::/56 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from 2003:e4:bfff:20c2::/64 via fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan proto static metric 512 pref medium default from fde6:a09a:b373:f0::/64 dev pppoe-wan metric 1024 pref medium default from fde6:a09a:b373:ff::/64 dev pppoe-wan metric 1024 pref medium 2003:e4:bfff:20c2::/64 dev pppoe-wan proto bird metric 32 pref medium fe80::71b4:e83:65bb:a41f dev pppoe-wan proto kernel metric 256 pref medium fe80::f6cc:55ff:fe42:1a94 dev pppoe-wan metric 1 pref medium root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Network not found root@cpe:~# birdc show interfaces ... pppoe-wan up (index=42) PtP Multicast AdminUp LinkUp MTU=1492 93.206.14.134/32 (Preferred, opposite 62.155.247.65, scope univ) 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 (Preferred, scope univ) fe80::71b4:e83:65bb:a41f/128 (Preferred, scope link) ... ``` If I `ip route add fe80::/64 dev pppoe-wan` it makes *no* difference. If I delete the `/128` LLA and replace it with `/64` it is still not present in `master6` ``` root@cpe:~# ip -6 addr show dev pppoe-wan 42: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 inet6 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 scope global dynamic noprefixroute valid_lft 13837sec preferred_lft 1237sec inet6 fe80::71b4:e83:65bb:a41f/64 scope link valid_lft forever preferred_lft forever pppoe-wan up (index=42) PtP Multicast AdminUp LinkUp MTU=1492 93.206.14.134/32 (Preferred, opposite 62.155.247.65, scope univ) 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 (Preferred, scope univ) fe80::71b4:e83:65bb:a41f/64 (Preferred, scope link) root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Network not found ``` But even if that would work, I would dislike it as a solution. My question still stands: Why is the route not present in `master6`, *even* that I have `learn yes` for `protocol kernel`. What does make this ipv6 default route so special? I'm not sure how to proceed from here on.
On Sun, Oct 09, 2022 at 07:43:56PM +0200, Bernd Naumann via Bird-users wrote:
On 2022-10-07 18:32, Ondrej Zajicek wrote:
Does the pppoe-wan have link-local address range? Does BIRD know about it? What is What is the output from BIRD command 'show interfaces'?
I assume no. Like I have written, the LLA is `/128`. I do not see the gateway in the `neighbor` table, but local LLA and gateway LLA are present as host routes.
Oh, i missed that. In general, BIRD does check route next hops against IP ranges of local addresses, not against other routes (i.e. gateway LLA as host route or manually added /64 route), so if you have LLA as /128, then the next hop check for gateway LLA fails. It is true that this check is suboptimal and perhaps superfluous, we should reevaluate it.
If I `ip route add fe80::/64 dev pppoe-wan` it makes *no* difference.
Yes, same like with gateway LLA host route.
If I delete the `/128` LLA and replace it with `/64` it is still not present in `master6`
This is strange, i would predict that after this change it should start working. Perhaps there is some bug in caching of next-hop lookups. Could you try replacing LLA with /64, checking that there is still default route in kernel table, and then restarting BIRD?
``` root@cpe:~# ip -6 addr show dev pppoe-wan 42: pppoe-wan: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3 inet6 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 scope global dynamic noprefixroute valid_lft 13837sec preferred_lft 1237sec inet6 fe80::71b4:e83:65bb:a41f/64 scope link valid_lft forever preferred_lft forever
pppoe-wan up (index=42) PtP Multicast AdminUp LinkUp MTU=1492 93.206.14.134/32 (Preferred, opposite 62.155.247.65, scope univ) 2003:e4:bfff:20c2:71b4:e83:65bb:a41f/64 (Preferred, scope univ) fe80::71b4:e83:65bb:a41f/64 (Preferred, scope link)
root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Network not found
But even if that would work, I would dislike it as a solution. My question still stands: Why is the route not present in `master6`, *even* that I have `learn yes` for `protocol kernel`. What does make this ipv6 default route so special?
In short, it is special that LLA range for your address is /128 and therefore the next hop of default route is outside of it. -- 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."
Hey Ondrej, See my reply inline. On 2022-10-10 00:40, Ondrej Zajicek wrote:
On Sun, Oct 09, 2022 at 07:43:56PM +0200, Bernd Naumann via Bird-users wrote:
On 2022-10-07 18:32, Ondrej Zajicek wrote:
Does the pppoe-wan have link-local address range? Does BIRD know about it? What is What is the output from BIRD command 'show interfaces'?
I assume no. Like I have written, the LLA is `/128`. I do not see the gateway in the `neighbor` table, but local LLA and gateway LLA are present as host routes.
Oh, i missed that. In general, BIRD does check route next hops against IP ranges of local addresses, not against other routes (i.e. gateway LLA as host route or manually added /64 route), so if you have LLA as /128, then the next hop check for gateway LLA fails. It is true that this check is suboptimal and perhaps superfluous, we should reevaluate it.
If I `ip route add fe80::/64 dev pppoe-wan` it makes *no* difference.
Yes, same like with gateway LLA host route.
If I delete the `/128` LLA and replace it with `/64` it is still not present in `master6`
This is strange, i would predict that after this change it should start working. Perhaps there is some bug in caching of next-hop lookups.
Could you try replacing LLA with /64, checking that there is still default route in kernel table, and then restarting BIRD?
If I just change the mask from `/128` to `/64` and restart bird I see no change in behavior. I ensured that `fe80::/64 dev pppoe-wan` is present, too. ``` root@cpe:~# logread -f | grep ppp Mon Oct 10 09:35:54 2022 daemon.debug bird: direct1 < interface pppoe-wan goes up Mon Oct 10 09:35:54 2022 daemon.debug bird: direct1 < address 62.155.247.65/32 on interface pppoe-wan added Mon Oct 10 09:35:54 2022 daemon.debug bird: direct1 < address 2003:e4:bfff:1f4a::/64 on interface pppoe-wan added Mon Oct 10 09:35:54 2022 daemon.debug bird: direct1 < address fe80::/64 on interface pppoe-wan added Mon Oct 10 09:35:55 2022 daemon.debug bird: kernel_ipv6 < interface pppoe-wan goes up ``` If I add `ip -6 route add default dev pppoe-wan` the route is learned: ``` Mon Oct 10 09:39:26 2022 daemon.debug bird: kernel_ipv6: ::/0: [alien async] created Mon Oct 10 09:39:26 2022 daemon.debug bird: kernel_ipv6.ipv6 > added [best] ::/0 unicast Mon Oct 10 09:39:26 2022 daemon.debug bird: kernel_ipv6.ipv6 < rejected by protocol ::/0 unicast root@cpe:~# birdc show route for ::/0 BIRD 2.0.8 ready. Table master6: ::/0 unicast [kernel_ipv6 09:39:26.194] * (10) dev pppoe-wan ```
[...] What does make this ipv6 default route so special?
In short, it is special that LLA range for your address is /128 and therefore the next hop of default route is outside of it.
My uplink connection is from Deutsche Telekom and their "standard" offering called "Magenta". Its a VDSL2+(something). As I stated before, I have no deeper knowledge about PPPoE but I would have doubt that it is so special to have a `/128`. Because with IPv4 the local address is also not on the same range as the gateway address; its also only two host addresses. The only difference here is that for IPv4 the local and remote address pair is setup as `inet <addr> peer <addr>`, but with IPv6 its just the LLA and two host routes (for local and remote LLA). ``` Mon Oct 10 09:32:35 2022 daemon.notice pppd[24067]: pppd 2.4.8 started by root, uid 0 Mon Oct 10 09:32:36 2022 daemon.info pppd[24067]: PPP session is 1 Mon Oct 10 09:32:36 2022 daemon.warn pppd[24067]: Connected to f4:cc:55:42:1a:94 via interface eth0.7 Mon Oct 10 09:32:36 2022 kern.info kernel: [262398.389971] pppoe-wan: renamed from ppp0 Mon Oct 10 09:32:36 2022 daemon.info pppd[24067]: Renamed interface ppp0 to pppoe-wan Mon Oct 10 09:32:36 2022 daemon.info pppd[24067]: Using interface pppoe-wan Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: Connect: pppoe-wan <--> eth0.7 Mon Oct 10 09:32:36 2022 daemon.info pppd[24067]: Remote message: SRU=43976#SRD=109941# Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: PAP authentication succeeded Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: peer from calling number F4:CC:55:42:1A:94 authorized Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: local IP address 87.167.90.71 Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: remote IP address 62.155.247.65 Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: primary DNS address 217.237.149.205 Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: secondary DNS address 217.237.151.51 Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: local LL address fe80::2923:cb8b:f184:5087 Mon Oct 10 09:32:36 2022 daemon.notice pppd[24067]: remote LL address fe80::f6cc:55ff:fe42:1a94 ``` Thanks again for your time and input.
participants (2)
-
Bernd Naumann -
Ondrej Zajicek