> route add -net 169.229.40.0 tunl0
> route add -host gallia.cs.berkeley.edu gw 169.229.40.35 tunl0
> route del -net 169.229.40.0 netmask 255.255.255.0
> ifconfig tunl0 netmask 255.255.255.255
>
> Since I should be able to route to an arbitrary destination through a
> tunnel, it really shouldn't be checking if the destination is reachable
> using the normal logic. It checks to see if there is a path from tunl0
> to the destination host. This is incorrect because the packet passes
> through tunl0 onto eth0 and uses eth0's routing table. I do have a
> route from eth0 to 169.229.40.35.
You found correct workaround :-)
Rationale:
There are a lot of sorts of tunnels and routing code cannot
recognize all of them in any case. Besides that, user level routing
software is also confused by such bizarre routes.
So that, a new flag to route is added, forcing not to check nexthop
for on-link state. Unfortuantely, it is still not accessible
via route utility.
Alexey Kuznetsov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu