>
> </delurk>
>
> On Mon, 12 Oct 2009, Rob Townley wrote:
>
>> On Mon, Oct 12, 2009 at 3:09 AM, Aric Aasgaard <aric@omahax.com> wrote:
>>>
>>> The interface isn't on the network your trying to ping.
>>
>> Maybe i don't understand what you are saying, but eth0's ip address is
>> 4.3.2.8 and when 4.3.2.8 is passed as the interface, it works. When
>> eth0 is passed as the interface name, ping fails. So it isn't a
>> problem with the network or routing rules or routing tables, it is a
>> problem in being able to address a device alias.
>
> Actually - not completely. The main problem is that when you call ping with
> the -I eth0 then you also are invoking your rule 32762 because when the ping
> command goes to use the interface it then runs through the rule set and as
> 32762 is the lowest rule it is invoked and your ping packet goes out through
> eth0 to the default gateway of table nic0:
>
> /sbin/ip route show table nic0
> default via 4.3.2.1 dev eth0
>
> And I suspect that cannot get to the device you want to ping.
>
> On the other hand when you specify -I 4.x.x.x to the ping command then the
> packet goes out from lo0 using that source address and is routed by the
> default rule "from all lookup main" which means it gets routed out the eth1
> interface but with the 4.x address.
>
> Do you see the difference?
>
> What gives this away is the following:
>
> 1: The ping utility is from iputils (Alexey's utility set) and thus behaves
> according to the policy structure in the kernel which _does_ differentiate
> between IP address assignments and mere network interfaces. Remember - the
> IP address DOES NOT belong to an interface and does not even need to be
> bound to such in order to function in a Linux kernel.
>
> 2: When you said "All exhibit the issue that ethX can't be used as an
> interface name when the default gateway isn't reached thru ethX."
>
> That told me that you were slightly confusing the way in which -I works in
> Alexey's ping utility. It is confusing considering that you must understand
> the difference between interface sourcing and ip address sourcing.
>
> In summary -
>
> -I <interface> will use the primary IP address of the named interface AND
> act as though it had been sourced from that interface which triggers any
> relevant rules, routes, etal.
>
> -I <IP addr> merely sets the Source address of the packet but then sources
> the packet from lo0 and this would invoke the default routing
>
> Sense?
>
> Let me know. Thanks!!
>
> P.S. I am considering starting work on a second edition as I now am back
> working in the IT field...
>
> mgm
>
>>> How are you attempting to get from one NIC to the other? Not via the same
>>> switch I hope.
>>
>> Both of these nics in all examples are in the same machine. Some have
>> ip_forward = 1 and some don't. All exhibit the issue that ethX can't
>> be used as an interface name when the default gateway isn't reached
>> thru ethX. Even machines with two nics behind the same switch and
>> therefore have the same default gateway on each interface exhibit a
>> problem referencing the interface by ethX -- however by IP address
>> works just fine. So some are behind the same switch and some use
>> totally different paths to the internet - either way it is broken.
>>
>>>
>>> May I ask what you are trying to do? There might be an easier way.
>>
>> i have a bunch of machines with 2 or more nics (HP and Dell Server
>> Class) that i will use for many types of projects. The easiest way is
>> for ping and tracert to be fixed. it is the first tool in network
>> assurance and debugging and it is very broken. i suspect this would
>> cause problems for users of VPNs, wireless, and other multi nic
>> scenarios.
>>
>>>
>>> As far a multi NIC BSD systems, yeah I got a few pfsense boxes, it is
>>> BSD.
>>> I started using pfsense when I couldn't get multi WAN Linux to work.
>>
>> i wish i would have known to give up 2-3 years ago - i knew i wasn't
>> that stupid as i have only been using ping for 20 years. i also had
>> problems with ping on dd-wrt and as this busybox mailing list shows, i
>> am not the only one. Note, these busybox guys didn't test this too
>> well because their examples never ping an ip on the other side of a
>> wire, but it is the exact same problem.
>>
http://lists.busybox.net/pipermail/busybox/2009-July/069972.html
>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From:
olug-bounces@olug.org [mailto:olug-bounces@olug.org] On Behalf Of
>>> Rob
>>> Townley
>>> Sent: Sunday, October 11, 2009 12:32 PM
>>> To: Omaha Linux User Group
>>> Subject: Re: [olug] Ping Is Broken
>>>
>>> On Sat, Oct 10, 2009 at 8:17 PM, Aric Aasgaard <aric@omahax.com> wrote:
>>>>
>>>> Does
>>>> traceroute -i eth0 -I 208.67.222.222
>>>> using ICMP
>>>
>>> eth0 = 4.3.2.8, the default gateway is thru eth1.
>>> tracert -i eth0 -I 208.67.222.222 FAILS
>>> tracert -s 4.3.2.8 -I 208.67.222.222 WORKS
>>> tracert -i eth0 208.67.222.222 FAILS
>>> tracert -s 4.3.2.8 208.67.222.222 WORKS
>>>
>>> There is a still a great deal of heated argument on the netdev list on
>>> how to make network device naming better. Some want to name
>>> interfaces in the order of MAC address, others in the name of bus
>>> enumeration, some think symbolic links will make things more
>>> complicated, others want it. Please test using the following script.
>>> Anybody have a multinic BSD system up that would care to test this.
>>> OSX?
>>>
>>> #!/bin/bash
>>> #The following is a script to test source routing thru the network
>>> interface alias vs ip address.
>>> #Put in your own IP addresses here.
>>> ip0=4.3.2.8
>>> ip1=192.168.168.155
>>> for interface in eth0 $ip0 eth1 $ip1; do echo testing $interface; ping
>>> -I $interface 208.67.222.222; done;
>>>
>>>>
>>>> or using UDP
>>>> traceroute -i eth0 208.67.222.222
>>>>
>>>> Work?
>>>>
>>>> -----Original Message-----
>>>> From:
olug-bounces@olug.org [mailto:olug-bounces@olug.org] On Behalf Of
>>>
>>> Rob
>>>>
>>>> Townley
>>>> Sent: Friday, October 09, 2009 11:45 AM
>>>> To:
netdev@vger.kernel.org
>>>> Cc: CentOS mailing list; Omaha Linux User Group
>>>> Subject: Re: [olug] Ping Is Broken
>>>>
>>>> ping -I is broken
>>>>
>>>> The following deals with bug in ping that made it very difficult to set
>>>> up
>>>
>>> a
>>>>
>>>> system with two gateways.
>>>>
>>>> Demonstration that *ping -I is broken*. When specifying the source
>>>> interface using -I with an *ethX* alias and that interface is not the
>>>> default gateway
>>>> interface, then ping fails. When specifying the interface as an ip
>>>
>>> address,
>>>>
>>>> ping works. Search for "Destination Host Unreachable" to find the bug.
>>>>
>>>>
>>>> eth*0* = 4.3.2.8 and the default gateway is accessed through a different
>>>> interface eth*1*.
>>>> eth*1* = 192.168.168.155 is used as the device to get to the default
>>>> gateway.
>>>> *FAILS *: ping *-I eth0* 208.67.222.222
>>>> *WORKS*: ping *-I 4.3.2.8* 208.67.222.222
>>>> *WORKS*: ping *-I eth1* 208.67.222.222
>>>> *WORKS*: ping *-I 192.168.168.155* 208.67.222.222
>>>>
>>>> The following are actual results which can be reproduced from an
>>>
>>> up-to-date
>>>>
>>>> Fedora 11 or CentOS 5.3 box. Caused a very very long episode of
>>>
>>> frustration
>>>>
>>>> when setting up multi gatewayed systems.
>>>>
>>>>
>>>> * ping using eth0 *:
>>>>
>>>> ping -c 2 -B -I eth0 208.67.222.222
>>>> PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 eth0: 56(84) bytes of
>>>> data.
>>>> From 4.3.2.8 icmp_seq=1 Destination Host Unreachable
>>>> From 4.3.2.8 icmp_seq=2 Destination Host Unreachable
>>>>
>>>> --- 208.67.222.222 ping statistics ---
>>>> 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time
>>>> 999ms
>>>> , pipe 2
>>>>
>>>> --------------------------------------
>>>> The Following all WORK:
>>>> * ping using 4.3.2.8 *:
>>>>
>>>> ping -c 2 -B -I 4.3.2.8 208.67.222.222
>>>> PING 208.67.222.222 (208.67.222.222) from 4.3.2.8 : 56(84) bytes of
>>>> data.
>>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=55 time=562 ms
>>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=55 time=642 ms
>>>>
>>>> --- 208.67.222.222 ping statistics ---
>>>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>>>> rtt min/avg/max/mdev = 562.546/602.400/642.255/39.862 ms
>>>>
>>>>
>>>> * ping using eth1 *:
>>>>
>>>> ping -c 2 -B -I eth1 208.67.222.222
>>>> PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 eth1: 56(84)
>>>> bytes of data.
>>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=270 ms
>>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=629 ms
>>>>
>>>> --- 208.67.222.222 ping statistics ---
>>>> 2 packets transmitted, 2 received, 0% packet loss, time 1000ms
>>>> rtt min/avg/max/mdev = 270.128/449.766/629.405/179.639 ms
>>>>
>>>>
>>>> * ping using 192.168.168.155 *:
>>>>
>>>> ping -c 2 -B -I 192.168.168.155 208.67.222.222
>>>> PING 208.67.222.222 (208.67.222.222) from 192.168.168.155 : 56(84)
>>>> bytes of data.
>>>> 64 bytes from 208.67.222.222: icmp_seq=1 ttl=54 time=585 ms
>>>> 64 bytes from 208.67.222.222: icmp_seq=2 ttl=54 time=554 ms
>>>>
>>>> --- 208.67.222.222 ping statistics ---
>>>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>>>> rtt min/avg/max/mdev = 554.098/569.655/585.212/15.557 ms
>>>>
>>>> My source route policy rules:
>>>>
>>>> /sbin/ip rule show
>>>> 0: from all lookup 255
>>>> 32762: from 4.3.2.8 lookup nic0
>>>> 32763: from 192.168.168.155 lookup nic1
>>>> 32764: from 192.168.168.155 lookup nic1
>>>> 32765: from 4.3.2.8 lookup nic0
>>>> 32766: from all lookup main
>>>> 32767: from all lookup default
>>>>
>>>>
>>>>
>>>> Print out routing tables using /sbin/ip route show table TABLENAME:
>>>> routing table nic0 :
>>>> /sbin/ip route show table nic0
>>>> default via 4.3.2.1 dev eth0
>>>>
>>>> routing table nic1 :
>>>> /sbin/ip route show table nic1
>>>> default via 192.168.168.1 dev eth1
>>>>
>>>> routing table main :
>>>> /sbin/ip route show table main
>>>> 4.3.2.1/27 dev eth0 proto kernel scope link src 4.3.2.8
>>>> 192.168.168.0/24 dev eth1 proto kernel scope link src 192.168.168.155
>>>> 169.254.0.0/16 dev eth1 scope link
>>>> default via 192.168.168.1 dev eth1
>>>>
>>>> routing table default :
>>>> /sbin/ip route show table default
>>>>
>>>>
>>>>
>>>>
>>>> NOTES: cat /etc/iproute2/rt_tables to get your own table names.
>>>>
>>>> ping Maintainer YOSHIFUJI Hideaki / USAGI/WIDE Project
>>>> http://www.skbuff.net/iputils/
>>>> Mailing List
netdev@vger.kernel.org
>>>>
>>>> man ping:
>>>> -I interface address
>>>> Set source address to specified interface address.
>>>> Argument may be *numeric IP address or name of device*.
>>>> When pinging IPv6 link-local address this option is
>>>> required.
>>>>
>>>> ping -V returns the latest available on CentOS and Fedora and the
>>>> maintainers website:
>>>> ping utility, iputils-ss020927
>
> --------------------------------------------------
> Matthew G. Marsh
> Special Email Addr for OLUG ;-}
> Phone: (402) 932-7250
> Email:
olug4mgm@paktronix.com
> WWW: http://www.paksecured.org
> --------------------------------------------------
