I have a tunnel setup, one end sits within the 196.xxx.xxx.yyy address
space, it doesn't have any policy routing in place and it has a main
routing table entry sending 196.xxx.xxx.240/29 down the tunnel
interface.
This the end of the tunnel I'm not having much success with has a policy
routing entry:
$ /sbin/ip addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
link/ether 00:04:95:71:7b:c1 brd ff:ff:ff:ff:ff:ff
inet 62.xxx.xxx.0/24 brd 62.xxx.xxx.255 scope global eth0
4: ipip240@NONE: <POINTOPOINT,NOARP,UP> mtu 1480 qdisc noqueue
link/ipip 62.xxx.xxx.123 peer 196.xxx.xxx.12
inet 196.xxx.xxx.240/29 scope global ipip240
inet 196.xxx.xxx.241/29 scope global secondary ipip240:1
inet 196.xxx.xxx.242/29 scope global secondary ipip240:2
inet 196.xxx.xxx.243/29 scope global secondary ipip240:3
inet 196.xxx.xxx.244/29 scope global secondary ipip240:4
inet 196.xxx.xxx.245/29 scope global secondary ipip240:5
inet 196.xxx.xxx.246/29 scope global secondary ipip240:6
inet 196.xxx.xxx.247/29 scope global secondary ipip240:7
$ /sbin/ip tunnel
ipip240: ip/ip remote 196.xxx.xxx.12 local 62.xxx.xxx.123 ttl 32
$ /sbin/ip route show table 100
default dev ipip240 proto static scope link
$ /sbin/ip rule show
0: from all lookup local
100: from 196.xxx.xxx.240/29 lookup 100
32766: from all lookup main
32767: from all lookup 253
Unicast UDP/TCP works great, ping work great, tcpdumps on the tunnel and
on the outer IPIP remote/local route at both ends look just perfect in
these cases.
However traceroute from the end of the tunnel that has policy routing in
place doesn't work. It seems to construct a raw packet and summits it
to the eth0 driver direct, bypassing the routing table(s)/rule (even
though the traceroute man page implies you have to actual set an option
to get this behaviour). I have also tried without the '-i iface'
option, but this doesn't change the way it behaves.
I would expect:
$ /usr/sbin/traceroute -i ipip240 -s 196.xxx.xxx.240 196.xxx.xxx.1
to find the 1st hop as being the remote tunnel interface, the 2nd hop as
being 196.xxx.xxx.1 itself (since it it connected just beyond the
tunnel).
Traceroutes coming in from the other direction work just great, as I
would expect traceroutes working through this end of the tunnel too
also. Traceroutes whos origin is on this machine that has policy routing
don't obey policy routing. I appreciate that "policy routing" maybe
"policy forwarding" and since this is the origin machine there is no
forwarding taking place, but shouldn't "-i ipip240" work as well.
Would it be technically possible to re-write an alternative traceroute
implementation which would do what I expected? Or is what I'm asking no
possible?
Also does anyone know what the purpose of the format "ipip240@NONE"
is/means? Why the @NONE?
Traceroute version info:
$ /usr/sbin/traceroute -h
Version 1.4a5
Usage: traceroute [-dFInrvx] [-g gateway] [-i iface] [-f first_ttl] [-m
max_ttl]
[ -p port] [-q nqueries] [-s src_addr] [-t tos] [-w waittime]
host
[packetlen]
Traceroute implementation info:
... [ SNIPPED ] ...
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 4
getuid32() = -1 ENOSYS (Function not
implemented)
getuid() = 0
setuid(0) = 0
getpid() = 2701
setsockopt(4, SOL_SOCKET, SO_SNDBUF, [38], 4) = 0
setsockopt(4, SOL_IP, IP_HDRINCL, [1], 4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 5
ioctl(5, SIOCGIFCONF, 0xbffff4a8) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
brk(0x8050000) = 0x8050000
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
brk(0x8051000) = 0x8051000
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
brk(0x8052000) = 0x8052000
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
ioctl(5, SIOCGIFFLAGS, 0xbffff4d0) = 0
ioctl(5, SIOCGIFADDR, 0xbffff4d0) = 0
ioctl(5, SIOCGIFNETMASK, 0xbffff4d0) = 0
close(5) = 0
... [ SNIPPED ] ...
gettimeofday({979137724, 99186}, {0, 0}) = 0
sendto(4, "E\0&\0\212\216\0\0\1\21\242\315\302\317\360\360\302\317"...,
38, 0, {sin_family=AF_INET, sin_port=htons(0),
sin_addr=inet_addr("196.xxx.xxx.1")}}, 16) = 38
gettimeofday({979137724, 100125}, {0, 0}) = 0
select(4, [3], NULL, NULL, {4, 999061}) = 1 (in [3], left {4, 920000})
recvfrom(3,
"E\0\0008\5u\0\0\365\1\10\355>1\305q\302\317\360\360\v\0"..., 512, 0,
{sin_family=AF_INET, sin_port=htons(55489),
sin_addr=inet_addr("62.xxx.xxx.113")}}, [16]) = 56
gettimeofday({979137724, 187574}, {0, 0}) = 0
... [ SNIPPED ] ...
Thanks,
--
Darryl Miles
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
