Re: Odd ping problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 02/27/2017 08:01 AM, Gary Stainburn wrote:
> On Friday 24 February 2017 18:51:54 Rick Stevens wrote:
>> The most common issue with this sort of thing is ARP and/or route
>> confusion. You have a machine with two interfaces on the same network.
>> Try doing this as root on zeppo (the machine with two interfaces):
>>
>> 	echo "1" >/proc/sys/net/ipv4/conf/all/arp_ignore
>> 	echo "2" >/proc/sys/net/ipv4/conf/all/arp_announce
>>
>> And try your pings again. If that solves your problem, add these lines
>> to your /etc/sysctl.conf file:
>>
>> 	# needed for two NICs on the same network
>> 	net.ipv4.conf.all.arp_ignore = 1
>> 	net.ipv4.conf.all.arp_announce = 2
>>
>> That will make them effective on a reboot. If that doesn't fix your
>> issue, reset the values via:
>>
>> 	echo "0" >/proc/sys/net/ipv4/conf/all/arp_ignore
>> 	echo "0" >/proc/sys/net/ipv4/conf/all/arp_announce
> 
> Thanks for the advice Rick. Unfortunately, that didn't work, but tidying up 
> the network settings did.  I changed the WiFi from DHCP to manual, and 
> removed the second LAN IP address, and the problem went away

That would clean it up, yes. What I recommended are settings we use
when we set up clusters of servers on load balancers using DSR (direct
server return). The main problem you had is that you had two different
physical NICs on the same network, without specifying a "master" NIC
that would respond to pings and such.

If you must have two NICs on the same network, have a look at this
kernel documentation:

arp_announce - INTEGER
	Define different restriction levels for announcing the local
	source IP address from IP packets in ARP requests sent on
	interface:
	0 - (default) Use any local address, configured on any interface
	1 - Try to avoid local addresses that are not in the target's
	subnet for this interface. This mode is useful when target
	hosts reachable via this interface require the source IP
	address in ARP requests to be part of their logical network
	configured on the receiving interface. When we generate the
	request we will check all our subnets that include the
	target IP and will preserve the source address if it is from
	such subnet. If there is no such subnet we select source
	address according to the rules for level 2.
	2 - Always use the best local address for this target.
	In this mode we ignore the source address in the IP packet
	and try to select local address that we prefer for talks with
	the target host. Such local address is selected by looking
	for primary IP addresses on all our subnets on the outgoing
	interface that include the target IP address. If no suitable
	local address is found we select the first local address
	we have on the outgoing interface or on all other interfaces,
	with the hope we will receive reply for our request and
	even sometimes no matter the source IP address we announce.

	The max value from conf/{all,interface}/arp_announce is used.

	Increasing the restriction level gives more chance for
	receiving answer from the resolved target while decreasing
	the level announces more valid sender's information.

arp_ignore - INTEGER
	Define different modes for sending replies in response to
	received ARP requests that resolve local target IP addresses:
	0 - (default): reply for any local target IP address, configured
	on any interface
	1 - reply only if the target IP address is local address
	configured on the incoming interface
	2 - reply only if the target IP address is local address
	configured on the incoming interface and both with the
	sender's IP address are part from same subnet on this interface
	3 - do not reply for local addresses configured with scope host,
	only resolutions for global and link addresses are replied
	4-7 - reserved
	8 - do not reply for all local addresses

	The max value from conf/{all,interface}/arp_ignore is used
	when ARP request is received on the {interface}
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital    ricks@xxxxxxxxxxxxxx -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-   Let us think the unthinkable. Let us do the undoable. Let us     -
-   prepare to grapple with the ineffable itself, and see if we may  -
-                      not eff it up after all.                      -
-                                                 -- Douglas Adams   -
----------------------------------------------------------------------
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux