difference between "ping -I INTERFACE" and "ping -I IPADDRESS" ?

09-28-2011, 12:30 PM

(sorry if this mail arrive in this list once more, I sent it
by mistake cca 90 minutes ago from unregistered e/mail address)

hello Fedora networking gurus,

I always thought that using ping with specifying source interface is
exact equivalent as specifying its IP address - but it is evidently
not true. What I'm getting on my Linux Fedora 14 i686 box:

# ping -I 10.128.254.2 -c 3 -nn 90.183.38.60; echo -e '

';
> ping -I eth1 -c 3 -nn 90.183.38.60
PING 90.183.38.60 (90.183.38.60) from 10.128.254.2 : 56(84) bytes of data.
64 bytes from 90.183.38.60: icmp_req=1 ttl=56 time=4.66 ms
64 bytes from 90.183.38.60: icmp_req=2 ttl=56 time=12.7 ms
64 bytes from 90.183.38.60: icmp_req=3 ttl=56 time=4.50 ms

--- 90.183.38.60 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.502/7.310/12.769/3.861 ms

PING 90.183.38.60 (90.183.38.60) from 10.128.254.2 eth1: 56(84) bytes of data.
>From 10.128.254.2 icmp_seq=1 Destination Host Unreachable
>From 10.128.254.2 icmp_seq=2 Destination Host Unreachable
>From 10.128.254.2 icmp_seq=3 Destination Host Unreachable

--- 90.183.38.60 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 1999ms
pipe 3

Interface eth1 has IP address 10.128.254.2 :
# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:30:4f:39:4b:49 brd ff:ff:ff:ff:ff:ff
inet 10.128.254.2/29 brd 10.128.254.7 scope global eth1
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:c7:25:c7:53 brd ff:ff:ff:ff:ff:ff
inet 10.3.60.10/24 brd 10.3.60.255 scope global eth2
4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:c7:19:3b:94 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.254/24 brd 10.0.1.255 scope global eth3
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1e:8c:94:05:cd brd ff:ff:ff:ff:ff:ff
inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 90.187.57.21 peer 78.103.210.66/32 scope global ppp0

At all interfaces are only IPv4 addresses, they have not any IP aliases,
iptables are stopped. eth1 is NATed 1:1 to public IP at ISP site.
Know anyone why ping (from iputils-20100418-3.fc14.i686 package)
behaves in such way? May this be somehow related with system routin tables?

Thanks, Franta
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-29-2011, 05:29 AM

yes it is always related with routing.
it would be helpful to see your routing table
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-29-2011, 07:56 AM

Kernel Guardian wrote:
> yes it is always related with routing.
> it would be helpful to see your routing table

I think it is some combination of routing rules and different ping
behavior when with "-I" switch is used interface name or interface IP.
But I have no idea why ping behaves differently.

So there are some clarifications:
- kernel 2.6.35.14-96.fc14.i686.PAE and ping from iputils-20100418

- from ppp0 (other interface to internet) both variants works fine.

- from eth2 (third iface to internet, its private IP is 1:1 NATed
at ISP site to public IP) both "ping -I" variants works when eth2
is (system, in table main) default route.

- when setting eth1 as system default route, situation reversed:
both "ping -I" variants works on eth1, and on eth2 only when its
IP is used with ping -I. Likely expected, as routing tables & rules
are symmetric for both eth1 and eth2.

- from outside (from internet) is possible without problem ping to
all three IPs/FQDNs corresponding with eth1/eth2/ppp0 and connect
to services on this Linux box.

- above behavior is the same independently to whether iptables are
stopped or active.

- ip routing tables and rules (made according to LARTC HOWTO):
# ip rule show
0: from all lookup local
32763: from 90.187.57.21 lookup adsl
32764: from 10.3.60.10 lookup wifibudka
32765: from 10.128.254.2 lookup wifismrk
32766: from all lookup main
32767: from all lookup default

# ip route list
90.187.57.21 dev ppp0 scope link src 90.187.57.21
78.103.210.66 dev ppp0 proto kernel scope link src 90.187.57.21
10.128.254.0/29 dev eth1 proto kernel scope link src 10.128.254.2
10.3.60.0/24 dev eth2 proto kernel scope link src 10.3.60.10
10.0.1.0/24 dev eth3 proto kernel scope link src 10.0.1.254
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.254
169.254.0.0/16 dev eth1 scope link metric 1002
169.254.0.0/16 dev eth2 scope link metric 1003
169.254.0.0/16 dev eth3 scope link metric 1004
169.254.0.0/16 dev eth0 scope link metric 1005
default via 10.3.60.1 dev eth2

# ip route list table wifismrk
90.187.57.21 dev ppp0 scope link
10.128.254.0/29 dev eth1 scope link src 10.128.254.2
10.3.60.0/24 dev eth2 scope link
192.168.0.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 10.128.254.1 dev eth1

# ip route list table wifibudka
90.187.57.21 dev ppp0 scope link
10.128.254.0/29 dev eth1 scope link
10.3.60.0/24 dev eth2 scope link src 10.3.60.10
192.168.0.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 10.3.60.1 dev eth2

# ip route list table adsl
90.187.57.21 dev ppp0 scope link src 90.187.57.21
10.128.254.0/29 dev eth1 scope link
10.3.60.0/24 dev eth2 scope link
192.168.0.0/24 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default dev ppp0 scope link

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether 00:30:4f:39:4b:49 brd ff:ff:ff:ff:ff:ff
inet 10.128.254.2/29 brd 10.128.254.7 scope global eth1
3: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:c7:25:c7:53 brd ff:ff:ff:ff:ff:ff
inet 10.3.60.10/24 brd 10.3.60.255 scope global eth2
4: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:c7:19:3b:94 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.254/24 brd 10.0.1.255 scope global eth3
5: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:1e:8c:94:05:cd brd ff:ff:ff:ff:ff:ff
inet 192.168.0.254/24 brd 192.168.0.255 scope global eth0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 90.187.57.21 peer 78.103.210.66/32 scope global ppp0

Any idea?

Thanks, Franta Hanzlik
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-29-2011, 01:23 PM

Frantisek Hanzlik <franta <at> hanzlici.cz> writes:

> ...

Just a wild guess if you want to try.

Turn off ICMP redirect:
# echo "0' > /proc/sys/net/ipv4/conf/all/accept_redirects
# echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects

Flush arp cache:
# ip neigh flush all

Flush the route cache:
# ip route flush cache

Now try *separate* entries:
# ping -n -c 2 -I source_ip target_ip
# ping -n -c 2 -I source_if target_ip

JB

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-30-2011, 01:19 AM

On 29 September 2011 09:56, Frantisek Hanzlik <franta@hanzlici.cz> wrote:

How are you create rules? (maybe there is a problem?)
what do you want to achieve with wifi* adsl table, load balancing or
splitting access?
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-30-2011, 05:28 PM

JB wrote:
> Frantisek Hanzlik <franta <at> hanzlici.cz> writes:
>
>> ...
>
> Just a wild guess if you want to try.
>
> Turn off ICMP redirect:
> # echo "0' > /proc/sys/net/ipv4/conf/all/accept_redirects
> # echo "0" > /proc/sys/net/ipv4/conf/all/send_redirects
>
> Flush arp cache:
> # ip neigh flush all
>
> Flush the route cache:
> # ip route flush cache
>
> Now try *separate* entries:
> # ping -n -c 2 -I source_ip target_ip
> # ping -n -c 2 -I source_if target_ip
>
> JB

It is the same. My opinion was ping in case of "-I netdev" gets
interface address (when it have only one, as in this case, this should
not be a problem) and things further come in same manner as if I give
"-I IPAddr" But ping behaves somehow else - for exact findings it would
be necessary overview its souce code. Maybe it not specify source IP
address - when I "ping -I eth1 target_ip", then I see at eth1 ARP
requests for target_ip (although it not belong to eth1 network segment).

OTOH: traceroute behaves fine and its syntax is IMO more obvious,
both "traceroute -i eth1 target_ip" and
"traceroute -i source_ip target_ip"
works fine and packets goes thru proper interface. And it can specify
separatelly to which device use and which source address use.

Franta
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-30-2011, 06:22 PM

Kernel Guardian wrote:
> On 29 September 2011 09:56, Frantisek Hanzlik <franta@hanzlici.cz> wrote:
>
> How are you create rules? (maybe there is a problem?)
> what do you want to achieve with wifi* adsl table, load balancing or
> splitting access?

I tried create rules with Fedora convention - via appropriate files in
/etc/sysconfig/network-scripts/rule-NETDEV and
/etc/sysconfig/network-scripts/route-NETDEV

But, I not know how "in Fedora manner" set some more complicated things
as load balancing:

ip route add default scope global nexthop via 10.128.254.2 dev eth1 weight 1
nexthop via 10.3.60.1 dev eth2 weight 1 nexthop dev ppp0 weight 1

etc. Reading /etc/sysconfig/network-scripts/ scripts it see as there is
possible custom post-initialization things with created /sbin/ifup-local
program/script, but it is called at end of device init - and there are
things which is suitable/necessary do after all interface starts, at end
of whole network initialization. Which probably isn't possible solve in
existing Fedora framework.

Regarding what I want achieve with networking at this Linux machine:
no great matter, DSL link is backup, and two wireless are main internet
connection. There are some light-loaded services accessed via different
links by their different FQDN (e.g. ftp.mydomain is one link,
mail.mydomain second). eth0 is LAN interface with several clients, maybe
sometimes there will be outcomming traffic splitted with some netfilter
packet marking.

All things on Linux machine works well, thus there is no need this case.
All is about as I until now was thinking, that "-I netdev" == "-I IP",
nothing else. And it isn't true.
(not sure when i clearly explain all, excuse my terrible english grammar)

Franta
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

09-30-2011, 06:57 PM

Frantisek Hanzlik <franta <at> hanzlici.cz> writes:

> ...

Suggestions:

1. use -R option to see routing (like ping plus traceroute in one)
Perhaps it will give you some clue about how it travels.
# ping -R -n -c 2 -I source_ip target_ip
# ping -R -n -c 2 -I source_if target_ip

You may try with -B option as well, just in case.
# ping -B -R -n -c 2 -I source_ip target_ip
# ping -B -R -n -c 2 -I source_if target_ip

2. install an older F13 or a newer F15 client on the same network, or perhaps
you would be able to remove on F14 the iputils package and replace it by
e.g. F13's iputils.
Then run the tests again to see if it is a case of ping regression.

3. play with -Q tos option (man ping)

4. get in touch with your ISP and ask them for co-testing with you (capturing
your ping's on the way out and on the way back).
I guess 'tcpdump' or similar net tool would allow them to see both ICMPs
(request and echo).
They could test the target_ip from their net too.

JB

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines

10-01-2011, 01:08 AM

JB wrote:
> Frantisek Hanzlik <franta <at> hanzlici.cz> writes:
>
>> ...
>
> Suggestions:
>
> 1. use -R option to see routing (like ping plus traceroute in one)
> Perhaps it will give you some clue about how it travels.
> # ping -R -n -c 2 -I source_ip target_ip
> # ping -R -n -c 2 -I source_if target_ip
>
> You may try with -B option as well, just in case.
> # ping -B -R -n -c 2 -I source_ip target_ip
> # ping -B -R -n -c 2 -I source_if target_ip
>
> 2. install an older F13 or a newer F15 client on the same network, or perhaps
> you would be able to remove on F14 the iputils package and replace it by
> e.g. F13's iputils.
> Then run the tests again to see if it is a case of ping regression.
>
> 3. play with -Q tos option (man ping)
>
> 4. get in touch with your ISP and ask them for co-testing with you (capturing
> your ping's on the way out and on the way back).
> I guess 'tcpdump' or similar net tool would allow them to see both ICMPs
> (request and echo).
> They could test the target_ip from their net too.
>
> JB

Hello JB,
I vote for ending this case - "ping -I source_ip" works as I expected,
traceroute works as I expected. "ping -I source_if" for some reason
behaves differently (it seems as it tries find target at source_if
segment, according to ARP requests), but I have not time for further
discovery. Linux box works fine, and it is crucial for me.
IMO right way would be ping sources overview and eventually some its
debugging.

Thanks, Franta
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines