Re: TSM backup LAN connection problem
Thank's for the tips, did thought about that, but: Yes we have to LPARs in an SSI and they have unique MACPREFIX. I did a new tcpdump running while I tried to connect using telnet 1.2.3.4 1500 And this time there was no trace of any request for mac-address, as it was last time. Just one short test but it indicates that query is not getting through. Will have to have the network guys start some trace on the switches I think. The workaround for the moment is to have the s390x server ping the x86 server each 2 minute. That keeps the ip-address - mac-address entry in the arp cache in the x86 server. BR /Tore Tore Agblad zOpen, IT Services Volvo Group Headquarters Corporate Process & IT SE-405 08, Gothenburg Sweden E-mail: tore.agb...@volvo.com http://www.volvo.com/volvoit/global/en-gb/ -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mauro Souza Sent: den 10 februari 2016 4:59 To: LINUX-390@VM.MARIST.EDU Subject: Re: TSM backup LAN connection problem Any chance you have more than one LPAR, and they have the same MACPREFIX? We had some strange issues here too, when two machines can contact every single other, but cannot contact themselves, and on certain times of the day they simply dropped out of the network, just to be available minutes later without any error message. We joked about it, saying it was a burnt MAC. We found out that the LPARs had the same MACPREFIX, and those two machines ended up having the same MAC address. The switch got confused, and sent packets to the wrong port. Mauro http://mauro.limeiratem.com - registered Linux User: 294521 Scripture is both history, and a love letter from God. 2016-02-10 12:53 GMT-02:00 Agblad Tore : > Thank you, good tips but had no effect. > > I set that to 1 (it was 0) and checked all announces: > > root@zlintcp2:/home/tore# sysctl -a|grep announce > net.ipv4.conf.all.arp_announce = 1 > net.ipv4.conf.default.arp_announce = 0 > net.ipv4.conf.lo.arp_announce = 0 > net.ipv4.conf.eth0.arp_announce = 0 > net.ipv4.conf.eth1.arp_announce = 0 > net.ipv4.conf.eth2.arp_announce = 0 > > This however had no effect, but since there also was a specification of 0 > for eth2 (my backupLan) I wondered which one takes precedence here? > So I fixed that one as well: > > root@zlintcp2:/home/tore# sysctl -w net.ipv4.conf.eth2.arp_announce=1 > net.ipv4.conf.eth2.arp_announce = 1 > root@zlintcp2:/home/tore# sysctl -a|grep announce > net.ipv4.conf.all.arp_announce = 1 > net.ipv4.conf.default.arp_announce = 0 > net.ipv4.conf.lo.arp_announce = 0 > net.ipv4.conf.eth0.arp_announce = 0 > net.ipv4.conf.eth1.arp_announce = 0 > net.ipv4.conf.eth2.arp_announce = 1 > > Still no effect. > I will take some more tcpdump on all interfaces as you suggested. > > > BR /Tore > > > Tore Agblad > zOpen, IT Services > > Volvo Group Headquarters > Corporate Process & IT > SE-405 08, Gothenburg Sweden > E-mail: tore.agb...@volvo.com > http://www.volvo.com/volvoit/global/en-gb/ > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Robert J Brenneman > Sent: den 9 februari 2016 5:14 > To: LINUX-390@VM.MARIST.EDU > Subject: Re: TSM backup LAN connection problem > > 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' > > see also: > > http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP > > On Tue, Feb 9, 2016 at 9:04 AM, Grzegorz Powiedziuk > > wrote: > > > Is it only telnet acting like this? What about ping, netcat (nc)? Does > it > > respond promptly? > > usually delays with logins (ssh but I think telnet does the same thing) I > > have caused by messed up DNS and reverse lookup entries. But here it is > > different because it works fine after first try. > > > > I think the default timeout for arp entries in linux is 60 sec > > (cat /proc/sys/net/ipv4/neigh/default/gc_stale_time) > > you can run "arp -n" to see if it is still there > > > > Did you double check ip configuration and make sure that network, subnet > > and broadcast addresses are correct? > > > > Regards > > Gregory > > > > 2016-02-09 4:04 GMT-05:00 Agblad Tore : > > > > > Hi, just a long shot perhaps, checking if anyone else have had this > > > problem and solved it: > > > > > > Two Linux servers running TSM(backup server) software, one x86 and on > > > s390x (RHEL 6.7) >
Re: SSI guest best practice
We implemented something like DHCP, bound to the guest name, not the MAC
address. It's working for 3 years now, and it's very low maintenance.
We had a USER CONFIG file on a MAINT630 disk, and every guest can link that
disk. The USER CONFIG is a simple text file containing this info:
GUEST IPADDRESSNETMASK GATEWAY HOSTNAME
LNX101 192.168.0.10 255.255.255.0 192.168.0.1 lnx101
Every time the guest boots(we have a rc.local entry for this), it looks for
the /etc/sysconfig/network/routes file. If the file is not found, we run
the following script:
chccwdev -e 191 2>&1 > /dev/null
udevadm settle
DISK=/dev/disk/by-path/ccw-0.0.0191
sleep 1
USERID=`vmcp q userid | awk '{print $1}'`
DATA=`cmsfscat -d $DISK -a user.config | grep $USERID`
if ! cmsfscat -d $DISK -a user.config | grep -q $USERID ; then
# request timeout, retry
chccwdev -d 191
sleep 1
chccwdev -e 191 2>&1 > /dev/null
udevadm settle
DISK=/dev/disk/by-path/ccw-0.0.0191
sleep 1
USERID=`vmcp q userid | awk '{print $1}'`
DATA=`cmsfscat -d $DISK -a user.config | grep $USERID`
fi
IP=`echo $DATA | awk '{print $2}'`
NETMASK=`echo $DATA | awk '{print $3}'`
GW=`echo $DATA | awk '{print $4}'`
HOSTNAME=`echo $DATA | awk '{print $5}'`
if [ "X$HOSTNAME" == "X" ] ; then
# hostname not found, abort
exit 1
fi
sed -i /etc/sysconfig/network/ifcfg-eth0 -e "s/^IPADDR=.*/IPADDR='$IP'/" -e
"s/^NETMASK.*/NETMASK='$NETMASK'/"
echo "default $GW - -" > /etc/sysconfig/network/routes
echo $HOSTNAME > /etc/HOSTNAME
reboot
This will run only once, on the first boot. When we create the machine, we
update the USER CONFIG file and xautolog it. Our template does not have the
/etc/sysconfig/routes, so every cloned guest will exec it.
Our automation does this differently. We use xcat (the community one, not
IBM's) and PHP IP Admin (phpipam). We can automatically detect all used IPs
on the network, assign one, and write it direct to the config files during
the provisioning.
Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.
2016-01-25 18:13 GMT-02:00 Mark Post :
> All,
>
> Just FYI, but here at SUSE we're contemplating creating a systemd unit
> file and associated scripts so that our systems running on various
> hypervisors can do whatever sort of "cleanup" each one might require to
> exploit the features of that hypervisor. For example, in the z/VM case,
> one of those things would be to detach all the CMS disks to be eligible for
> LGR.
>
> Of course, whatever we wind up devising would be better with input from
> the people that will ultimately be using it (or not), assuming it actually
> makes it into the product. (We hope so, but as everyone knows "stuff"
> happens.)
>
> So, if you have any thoughts on what those various items might be for the
> various hypervisors you run, let us know. We can discuss it here, with
> this thread, start a new one, whatever makes the most sense for the most
> people.
>
>
> Mark Post
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
Re: TSM backup LAN connection problem
The arp request is leaving the system that initiates the session somehow - it is probably leaving over the wrong interface. tcpdump ALL the interfaces and filter for L2 ARP requests/replies to see where it is going and make sure it is leaving through the correct interface - then you can work with the network people to make sure it gets to the target system, and do the same to the ARP reply there to make sure it goes back in the right direction. On Thu, Feb 11, 2016 at 3:25 AM, Agblad Tore wrote: > Thank's for the tips, did thought about that, but: > Yes we have to LPARs in an SSI and they have unique MACPREFIX. > I did a new tcpdump running while I tried to connect using telnet 1.2.3.4 > 1500 > And this time there was no trace of any request for mac-address, as it was > last time. > Just one short test but it indicates that query is not getting through. > Will have to have the network guys start some trace on the switches I > think. > The workaround for the moment is to have the s390x server ping the x86 > server each 2 minute. That keeps the ip-address - mac-address entry in the > arp cache in the x86 server. > > BR /Tore > > > Tore Agblad > zOpen, IT Services > > Volvo Group Headquarters > Corporate Process & IT > SE-405 08, Gothenburg Sweden > E-mail: tore.agb...@volvo.com > http://www.volvo.com/volvoit/global/en-gb/ > > > -Original Message- > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > Mauro Souza > Sent: den 10 februari 2016 4:59 > To: LINUX-390@VM.MARIST.EDU > Subject: Re: TSM backup LAN connection problem > > Any chance you have more than one LPAR, and they have the same MACPREFIX? > > We had some strange issues here too, when two machines can contact every > single other, but cannot contact themselves, and on certain times of the > day they simply dropped out of the network, just to be available minutes > later without any error message. We joked about it, saying it was a burnt > MAC. We found out that the LPARs had the same MACPREFIX, and those two > machines ended up having the same MAC address. The switch got confused, and > sent packets to the wrong port. > > Mauro > http://mauro.limeiratem.com - registered Linux User: 294521 > Scripture is both history, and a love letter from God. > > 2016-02-10 12:53 GMT-02:00 Agblad Tore : > > > Thank you, good tips but had no effect. > > > > I set that to 1 (it was 0) and checked all announces: > > > > root@zlintcp2:/home/tore# sysctl -a|grep announce > > net.ipv4.conf.all.arp_announce = 1 > > net.ipv4.conf.default.arp_announce = 0 > > net.ipv4.conf.lo.arp_announce = 0 > > net.ipv4.conf.eth0.arp_announce = 0 > > net.ipv4.conf.eth1.arp_announce = 0 > > net.ipv4.conf.eth2.arp_announce = 0 > > > > This however had no effect, but since there also was a specification of 0 > > for eth2 (my backupLan) I wondered which one takes precedence here? > > So I fixed that one as well: > > > > root@zlintcp2:/home/tore# sysctl -w net.ipv4.conf.eth2.arp_announce=1 > > net.ipv4.conf.eth2.arp_announce = 1 > > root@zlintcp2:/home/tore# sysctl -a|grep announce > > net.ipv4.conf.all.arp_announce = 1 > > net.ipv4.conf.default.arp_announce = 0 > > net.ipv4.conf.lo.arp_announce = 0 > > net.ipv4.conf.eth0.arp_announce = 0 > > net.ipv4.conf.eth1.arp_announce = 0 > > net.ipv4.conf.eth2.arp_announce = 1 > > > > Still no effect. > > I will take some more tcpdump on all interfaces as you suggested. > > > > > > BR /Tore > > > > > > Tore Agblad > > zOpen, IT Services > > > > Volvo Group Headquarters > > Corporate Process & IT > > SE-405 08, Gothenburg Sweden > > E-mail: tore.agb...@volvo.com > > http://www.volvo.com/volvoit/global/en-gb/ > > > > -Original Message- > > From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of > > Robert J Brenneman > > Sent: den 9 februari 2016 5:14 > > To: LINUX-390@VM.MARIST.EDU > > Subject: Re: TSM backup LAN connection problem > > > > 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' > > > > see also: > > > > > http://kb.linuxvirtualserver.org/wiki/Using_arp_announce/arp_ignore_to_disable_ARP > > > > On Tue, Feb 9, 2016 at 9:04 AM, Grzegorz Powiedziuk < > gpowiedz...@gmail.com > > > > > wrote: > > > > > Is it only telnet acting like this? What about ping, netcat (nc)? Does > > it > > > respond promptly? > > > usually delays with logins (ssh but
Re: TSM backup LAN connection problem
On Tuesday, 02/09/2016 at 04:16 GMT, Robert J Brenneman
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
alan_altm...@us.ibm.com
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
Re: TSM backup LAN connection problem
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: tore.agb...@volvo.com
http://www.volvo.com/volvoit/global/en-gb/
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
Altmark
Sent: den 11 februari 2016 4:43
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TSM backup LAN connection problem
On Tuesday, 02/09/2016 at 04:16 GMT, Robert J Brenneman
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
alan_altm...@us.ibm.com
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}
Re: TSM backup LAN connection problem
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 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: tore.agb...@volvo.com
> http://www.volvo.com/volvoit/global/en-gb/
>
>
> -Original Message-
> From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
> Alan Altmark
> Sent: den 11 februari 2016 4:43
> To: LINUX-390@VM.MARIST.EDU
> Subject: Re: TSM backup LAN connection problem
>
> On Tuesday, 02/09/2016 at 04:16 GMT, Robert J Brenneman
> 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
> alan_altm...@us.ibm.com
> 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 tha
