镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

netlink: Dump routes in Linux FIB order and honor the dump family - #16765

Open
copybara-service[bot] wants to merge 1 commit into
masterfrom
test/cl1010782127
Open

copybara-service[bot] wants to merge 1 commit into
masterfrom
test/cl1010782127

Conversation

@copybara-service

Copy link
Copy Markdown

netlink: Dump routes in Linux FIB order and honor the dump family

Summary

RTM_GETROUTE dumps differ from Linux in two ways:

  1. Order. Netstack returns routes in its lookup order, longest prefix first. Linux dumps IPv4 routes by ascending destination, with longer prefixes first for the same destination (fib_table_dump()). IPv6 routes follow, in fib6 post-order (fib6_walk_continue()). So the default route comes first on Linux and last under gVisor. /proc/net/route has the same order problem.

  2. Family. The family in the request is ignored, so an AF_INET6 dump also returns IPv4 routes, and the other way round. RTM_GETADDR dumps have the same problem.

Scripts often take the first line of ip route. We found this with a container health check that runs ip route show default dev eth0 | awk '{print $3; exit}'. With iproute2 4.11, the first line under gVisor was fe80::/64 proto unspec scope link, so the script used unspec as the gateway. Fixing only the family is not enough here, because the first line then becomes the subnet route.

This PR sorts netstack's route table in Linux dump order and filters AF_INET and AF_INET6 route and address dumps by family. It also sets RTF_HOST for /32 routes in /proc/net/route, as fib_flag_trans() does.

Reproduction

This uses only the busybox image on Docker's default bridge network.

docker run --rm --runtime=runsc busybox:1.36.1 sh -c 'ip route; echo ---; ip -6 route'

busybox ip -6 route sends an AF_INET6 dump and prints every route it gets back.

Linux (runc):

default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2
---

runsc before this PR:

172.17.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 172.17.0.1 dev eth0 scope link
---
172.17.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 172.17.0.1 dev eth0 scope link

The default route is last, and ip -6 route lists the IPv4 routes.

runsc with this PR:

default via 172.17.0.1 dev eth0 scope link
127.0.0.0/8 dev lo scope link
172.17.0.0/16 dev eth0 scope link
---

The remaining differences in ip output (127.0.0.0/8 in the main table, scope link on the default route, no src) already exist and are unrelated to this PR.

Testing

  • New unit tests: TestRouteTableDumpOrder and TestDumpFamily.
  • New syscall tests: NetlinkRouteIpInvariantTest.DumpFiltersFamily and NetlinkRouteIpInvariantTest.GetRouteDumpOrder. They pass on Linux, on runsc, and on runsc with --network=host, and fail on runsc without this change.

FUTURE_COPYBARA_INTEGRATE_REVIEW=#16090 from cedriccchen:upstream-fix-netlink-route-dump-order 5f6df96

@copybara-service copybara-service Bot added the exported Issue was exported automatically label Oct 30, 2026
@copybara-service
copybara-service Bot force-pushed the test/cl1010782127 branch 8 times, most recently from 53db750 to 34a0f56 Compare November 3, 2026 01:11
## Summary

RTM_GETROUTE dumps differ from Linux in two ways:

1. **Order.** Netstack returns routes in its lookup order, longest prefix first. Linux dumps IPv4 routes by ascending destination, with longer prefixes first for the same destination (`fib_table_dump()`). IPv6 routes follow, in fib6 post-order (`fib6_walk_continue()`). So the default route comes first on Linux and last under gVisor. `/proc/net/route` has the same order problem.

2. **Family.** The family in the request is ignored, so an AF_INET6 dump also returns IPv4 routes, and the other way round. RTM_GETADDR dumps have the same problem.

Scripts often take the first line of `ip route`. We found this with a container health check that runs `ip route show default dev eth0 | awk '{print $3; exit}'`. With iproute2 4.11, the first line under gVisor was `fe80::/64 proto unspec scope link`, so the script used `unspec` as the gateway. Fixing only the family is not enough here, because the first line then becomes the subnet route.

This PR sorts netstack's route table in Linux dump order and filters AF_INET and AF_INET6 route and address dumps by family. It also sets RTF_HOST for /32 routes in `/proc/net/route`, as `fib_flag_trans()` does.

## Reproduction

This uses only the `busybox` image on Docker's default bridge network.

```
docker run --rm --runtime=runsc busybox:1.36.1 sh -c 'ip route; echo ---; ip -6 route'
```

busybox `ip -6 route` sends an AF_INET6 dump and prints every route it gets back.

Linux (runc):

```
default via 172.17.0.1 dev eth0
172.17.0.0/16 dev eth0 scope link  src 172.17.0.2
---
```

runsc before this PR:

```
172.17.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 172.17.0.1 dev eth0 scope link
---
172.17.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 172.17.0.1 dev eth0 scope link
```

The default route is last, and `ip -6 route` lists the IPv4 routes.

runsc with this PR:

```
default via 172.17.0.1 dev eth0 scope link
127.0.0.0/8 dev lo scope link
172.17.0.0/16 dev eth0 scope link
---
```

The remaining differences in `ip` output (127.0.0.0/8 in the main table, `scope link` on the default route, no `src`) already exist and are unrelated to this PR.

## Testing

- New unit tests: `TestRouteTableDumpOrder` and `TestDumpFamily`.
- New syscall tests: `NetlinkRouteIpInvariantTest.DumpFiltersFamily` and `NetlinkRouteIpInvariantTest.GetRouteDumpOrder`. They pass on Linux, on runsc, and on runsc with `--network=host`, and fail on runsc without this change.

FUTURE_COPYBARA_INTEGRATE_REVIEW=#16090 from cedriccchen:upstream-fix-netlink-route-dump-order 5f6df96
PiperOrigin-RevId: 1010782127
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

exported Issue was exported automatically

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant