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