Maybe I'm unimaginative, but I can't think of a network topology where the defaults make sense.
What is this set of defaults supposed to /make easier/ ? On Thu, Feb 11, 2016 at 11:10 AM, Agblad Tore <[email protected]> wrote: > Hehe, after reading this behavior posted here, that's about what I thought > as well when I saw all these zeroes as default. > I think I will use your hint here and make that change into our > clonebase(golden image) > > BR /Tore > > ________________________________________________ > Tore Agblad > zOpen, IT Services > > Volvo Group Headquarters > Corporate Process & IT > SE-405 08, Gothenburg Sweden > E-mail: [email protected] > http://www.volvo.com/volvoit/global/en-gb/ > > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > Alan Altmark > Sent: den 11 februari 2016 4:43 > To: [email protected] > Subject: Re: TSM backup LAN connection problem > > On Tuesday, 02/09/2016 at 04:16 GMT, Robert J Brenneman > <[email protected]> wrote: > > Multi homed linux seems to consider any MAC address as good as any other > > when responding to an ARP. The default seems to assume you have every > > ethernet port plugged to the same logical network. If you run tcpdump on > > all interfaces for both machines, I bet you see the target of the telnet > > request sometimes responding to the ARP out the wrong interface with the > > wrong MAC address. > > > > Try this - on both your Linux x86 and Linux s390x systems, set this > > variable in /etc/sysctl.conf > > net.ipv4.conf.all.arp_announce = 1 > > > > and make it effective with 'sysctl -p /etc/sysctl.conf' > > It's called "ARP Flux" and it's a nasty business. IMO, all distros should > ship with > net.ipv4.conf.all.arp_announce = 1 > net.ipv4.conf.all.arp_ignore = 1 > net.ipv4.conf.all.arp_notify = 1 > net.ipv4.conf.all.arp_filter = 1 > > Details below. I can't imagine how the kernel maintainers allowed such > changes to ever be made in the first place, and then why the distros > didn't override it back into sanity. > > Alan Altmark > > Senior Managing z/VM and Linux Consultant > Lab Services System z Delivery Practice > IBM Systems & Technology Group > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > [email protected] > IBM Endicott > > arp_filter - BOOLEAN > 0 - (default) The kernel can respond to arp requests with > addresses > from other interfaces. This may seem wrong but it usually > makes > sense, because it increases the chance of successful > communication. > IP addresses are owned by the complete host on Linux, not > by > particular interfaces [say, what?]. Only for more complex > setups like load- > balancing, does this behaviour cause problems. [I am SO > laughing right now.] > > 1 - Allows you to have multiple network interfaces on the > same > subnet, and have the ARPs for each interface be answered > based on whether or not the kernel would route a packet > from > the ARP'd IP out that interface (therefore you must use > source > based routing for this to work). In other words it allows > control > of which cards (usually 1) will respond to an arp > request. > > arp_filter for the interface will be enabled if at least > one of > conf/{all,interface}/arp_filter is set to TRUE, > it will be disabled otherwise > > 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} > > arp_notify - BOOLEAN > Define mode for notification of address and device > changes. > 0 - (default): do nothing > > 1 - Generate gratuitous arp requests when device is > brought up > or hardware address changes. > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO LINUX-390 or > visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ---------------------------------------------------------------------- > For more information on Linux on System z, visit > http://wiki.linuxvm.org/ > -- Jay Brenneman ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
