You are not logged in.
Hey there,
So I'm trying to set things up using some policy routing, and having some weird issues I can't really explain. Basically here's what I could reduce it to:
- create a new network namespace, create a pair of veth devices: one in there, one sent back to the original namespace
- I'm giving them IPs 10.4.0.1 (original namespace) & 10.4.0.2 (new namespace)
- in that new namespace, I'm trying to add a route to 10.4.0.1, but inside a new table. I also want a default route via 10.4.0.1 on the table main. It seems to work, only not really...
# after unshare -nm & remouting /proc & /sys
sh-4.4# ip rule add table 50 prio 50
sh-4.4# ip link add test type veth peer name test2
sh-4.4# ip addr add 10.4.0.2 dev test
sh-4.4# ip link set dev test up
sh-4.4# ip link set netns 1 dev test2
sh-4.4# # back in original namespace, we add 10.4.0.1 to test2 and bring it up
sh-4.4# ip route add 10.4.0.1 dev test table 50
sh-4.4# ip route add default via 10.4.0.1 dev test
sh-4.4# ip route flush cache
sh-4.4# ip rule
0: from all lookup local
50: from all lookup 50
32766: from all lookup main
32767: from all lookup default
sh-4.4# ip route show table 50
10.4.0.1 dev test scope link
sh-4.4# ip route get 10.4.0.1
10.4.0.1 via 10.4.0.1 dev test table local src 10.4.0.2
cache
sh-4.4# # !?? why isn't table 50 used. And why adding a rule "fixes" it :
sh-4.4# ip rule add prio 55555 # could also delete it right after, makes no difference
sh-4.4# ip route get 10.4.0.1
10.4.0.1 dev test table 50 src 10.4.0.2
cache
sh-4.4# # as said, deleting the new rule makes no difference. It's like it just triggered something (reload, cache flushed, ...)
sh-4.4# ip rule del prio 55555
sh-4.4# ip route get 10.4.0.1
10.4.0.1 dev test table 50 src 10.4.0.2
cache
Any idea as to why this is happening? Should this work as I expect it, or is there anything I'm doing wrong?
Thanks,
-j
Last edited by jjacky (2017-01-03 20:30:21)
Offline
Maybe you need "ip rule flush"?
Offline
So, for the record after inquiring on netdev, this turned out to be indeed a bug. A patch has been provided, and as a nice little workaround one can simply bring lo up (ip link set dev lo up) before touching rules/routes in the new namespace.
Offline