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 <[email protected]> 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: [email protected] > http://www.volvo.com/volvoit/global/en-gb/ > > > -----Original Message----- > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > Mauro Souza > Sent: den 10 februari 2016 4:59 > To: [email protected] > 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 <[email protected]>: > > > 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: [email protected] > > http://www.volvo.com/volvoit/global/en-gb/ > > > > -----Original Message----- > > From: Linux on 390 Port [mailto:[email protected]] On Behalf Of > > Robert J Brenneman > > Sent: den 9 februari 2016 5:14 > > To: [email protected] > > 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 < > [email protected] > > > > > 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 <[email protected]>: > > > > > > > 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) > > > > > > > > Both have an extra NIC connected to a separate backup LAN, separate > OSA > > > > adapters + separate cables all the way. > > > > > > > > Connection test method: telnet ipaddress 1500 > > > > > > > > Connect from s390x via that vlan and port 1500 into the x86 server > > works, > > > > but takes 5-10 seconds first time. And again 5-10 seconds if no > traffic > > > for > > > > about 5 minutes. > > > > > > > > Connect from x86 same method does not work, unless a connection from > > > s390x > > > > was made the last 5 minutes. > > > > > > > > It seems the arp cache in the x86 server is updated and that server > > finds > > > > it way after that, but timeout is 5 minutes, so after that it does > not > > > find > > > > it's way. > > > > > > > > I took a tcpdump on that backup lan interface, got some help > > > understanding > > > > it using wireshark, and obviously the x86 connection tries does > > initiate > > > an > > > > arp query to the s390x server that also replies with its mac address, > > as > > > it > > > > should. Still this does not help. > > > > Route tables also looks as expected, should not cause a problem. > > > > > > > > Anyone having seen this problem ? > > > > If you also have the solution you will make my day :-) > > > > > > > > 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/ > > > > > > > > > ---------------------------------------------------------------------- > > > > 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/ > > > > ---------------------------------------------------------------------- > 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/
