Re: SLES 11 strange behavior network
Hi all, i do a lot of tests here, with no sucessful yet... i tryed do it: set vswitch like this: DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 VLAN 666 SET VMLAN MACPROTECT ON SET VSWITCH VSWSVC01 GRANT DB2P101 VLAN 218 SET NIC USER DB2P101 0800 MACPROTECT ON I get one victory, make linux comes up with correct vlan without load 802.1q on linux... but after logoff, the sles tries get another mac address just like Ursula says... and then mac protection comes up: .doneeth0 name: OSA Express Network card (0.0.0800) eth.aafb9d: 0.0.0800: MAC address 02:61:01:00:00:29 is not authorized TNETLINK answers: Unknown error 18446744073709486085 annot enable interface eth0. nterface eth0 is not up eb 3 15:24:44 ftpp102 ifup: Cannot enable interface eth0. eb 3 15:24:44 ftpp102 ifup-route: interface eth0 is not up eb 3 15:24:44 ftpp102 SuSEfirewall2: SuSEfirewall2 not active eth0 .failedWaiting for mandatory devices: eth0 __NSC__ 0 29 28 27 26 Feb 3 15:24:48 ftpp102 kernel: qeth.aafb9d: 0.0.0800: MAC addres 02:61:01:00:00:29 is not authorized 5 24 23 22 21 i'm a little lost here about this... about do force arp response like Ursula says i understandig this is a bad choice based on comments from Mark, correct? there is another workaround that i can try? we are running z/vm 6.1 by the way :) Thanks again. On Wed, Feb 2, 2011 at 5:32 PM, Marcy Cortes marcy.d.cor...@wellsfargo.comwrote: Channel bonding would be another. But even then, I wouldn't pick something that is in CP's range to assign. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Alan Altmark Sent: Wednesday, February 02, 2011 10:46 AM To: LINUX-390@vm.marist.edu Subject: Re: [LINUX-390] SLES 11 strange behavior network On Wednesday, 02/02/2011 at 01:29 EST, David Boyes dbo...@sinenomine.net wrote: Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? Are all the MAC-level takeover HA solutions gone? I thought some workload sprayers used MAC spoofing to perform transparent workload transfers. The only other reason I can think of to overwrite the MAC is in order to get a specific DHCP reservation (not the same as static IP). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- 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/ -- 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: SLES 11 strange behavior network
On 2/3/2011 at 02:42 PM, Rogério Soaresrogerio.soa...@gmail.com wrote: Hi all, i do a lot of tests here, with no sucessful yet... i tryed do it: set vswitch like this: DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 VLAN 666 SET VMLAN MACPROTECT ON SET VSWITCH VSWSVC01 GRANT DB2P101 VLAN 218 SET NIC USER DB2P101 0800 MACPROTECT ON I get one victory, make linux comes up with correct vlan without load 802.1q on linux... but after logoff, the sles tries get another mac address just like Ursula says... and then mac protection comes up: .doneeth0 name: OSA Express Network card (0.0.0800) eth.aafb9d: 0.0.0800: MAC address 02:61:01:00:00:29 is not authorized Just to be clear, do you have LLADDR= specified in the /etc/sysconfig/network/ifcfg-* file, or not? If not, and z/VM is giving you a new MAC address and then telling you the guest is not authorized for it, then a PMR is in order. If you do have LLADDR= specified, remove it. 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/
Re: SLES 11 strange behavior network
yes Mark, i have, i will remove it :) Sorry for this confusion. cat ifcfg-eth0 BOOTPROTO='static' IPADDR='10.210.57.26/24' BROADCAST='10.210.57.255' STARTMODE='onboot' LLADDR='02:61:01:00:00:27' NAME='OSA Express Network card (0.0.0800)' ftpp102:/etc/sysconfig/network # On Thu, Feb 3, 2011 at 6:10 PM, Mark Post mp...@novell.com wrote: On 2/3/2011 at 02:42 PM, Rogério Soaresrogerio.soa...@gmail.com wrote: Hi all, i do a lot of tests here, with no sucessful yet... i tryed do it: set vswitch like this: DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 VLAN 666 SET VMLAN MACPROTECT ON SET VSWITCH VSWSVC01 GRANT DB2P101 VLAN 218 SET NIC USER DB2P101 0800 MACPROTECT ON I get one victory, make linux comes up with correct vlan without load 802.1q on linux... but after logoff, the sles tries get another mac address just like Ursula says... and then mac protection comes up: .doneeth0 name: OSA Express Network card (0.0.0800) eth.aafb9d: 0.0.0800: MAC address 02:61:01:00:00:29 is not authorized Just to be clear, do you have LLADDR= specified in the /etc/sysconfig/network/ifcfg-* file, or not? If not, and z/VM is giving you a new MAC address and then telling you the guest is not authorized for it, then a PMR is in order. If you do have LLADDR= specified, remove it. 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: SLES 11 strange behavior network
Rogerio,
z/VM assigns MAC-addresses for virtual NICs. I assume the MAC-address
assigned to your SLES11 virtual NIC has changed after LOGOUT and this
change is not propagated to your network. If this is correct, I see 2
options to work around this problem:
1. Overwrite the z/VM-assigned MAC-address with a user-defined
MAC-address using an LLADDR-definition line
in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not
change after LOGOUT.
2. Run an arping-command after ifup:
/sbin/arping -q -A -c 1 -I ${REALDEVICE} ${IPADDR}
to update your neighbours.
Regards,
Ursula Braun, IBM Germany
On Tue, 2011-02-01 at 15:49 -0200, Rogério Soares wrote:
Guys, i get another ghost on my enviroment...
i set up my vswitch to use port group, and give grant permission to guest
sles 11 Sp1..
all works okay, but if i give LOGOUT on machine, network not comes back,
until i give some network request FROM this machine.. this request can be a
ping for example...
instantly i give a ping, the nework wake up... anybody already see this
behavior ? any clue?
this behavior not happens if i give a simple reboot command :-/
here is my definitions of vswitch and port group:
00242 VMLAN MACPREF 026101
00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0
00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01
00245
00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101
on linux, we are currentily using vlan
--
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: SLES 11 strange behavior network
On Tuesday, 02/01/2011 at 12:50 EST, Rogério Soares rogerio.soa...@gmail.com wrote: i set up my vswitch to use port group, and give grant permission to guest sles 11 Sp1.. all works okay, but if i give LOGOUT on machine, network not comes back, until i give some network request FROM this machine.. this request can be a ping for example... instantly i give a ping, the nework wake up... anybody already see this behavior ? any clue? this behavior not happens if i give a simple reboot command :-/ here is my definitions of vswitch and port group: 00242 VMLAN MACPREF 026101 00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0 00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 00245 00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101 on linux, we are currentily using vlan Let's look at some switch theory Switches are smart; they learn what ports own what MAC addresses. In this way, they convert an all-stations broadcast to a single-station (port) broadcast. If they don't see the traffic for a while, they will forget what they learned and go back to an all-stations broadcast. Then, upon seeing an ARP response, they now know what port to send traffic on. In fact, any outbound (from the host) traffic will cause the switch to, uh, switch the MAC-port association. The problem arises when you move a guest from one physical port to another before that forget timer pops. If the guest does not generate any traffic, inbound traffic will go to the wrong port. So, what should Linux do? When Linux brings an interface up, he's supposed to issue an unsolicited (gratuitous) ARP response. When operating in layer 3 mode (VSWITCH or OSA), CP or the OSA issues the grat ARP on your behalf. There are reasons, and ways, to suppress the grat ARP, but that doesn't come into play unless you're doing IP takeover. That is, stealing an IP address from another (failed) adapter. Make sure you do NOT have ARP=no in your Linux network config scripts. I don't know what release of z/VM you are running, but you can also check out http://www.vm.ibm.com/virtualnetwork/mntlvl.html to see if anything applies. I vaguely remember some old APARs dealing with VSWITCHes and grat ARPs. As an aside, one of us is missing something. If you are using VLANs on Linux (vconfig), then I would expect you to have GRANTed PORTTYPE TRUNK VLAN xxx. If you're not using vconfig, then you are not using VLANs inside Linux. You have granted DB2P101 access to the default VLAN (VLAN 1) which is also the default NATIVE VLAN id (which you did not specify). That means the traffic leaves the VSWITCH *untagged* and the physical switch is applying the native VLAN id to the traffic (even if it isn't VLAN 1!). This is not how the VSWITCH is intended to be used. If someone changes the native VLAN id of the switch, you're in a lot of trouble. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- 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: SLES 11 strange behavior network
On Wed, 2011-02-02 at 10:40 -0500, Alan Altmark wrote: The problem arises when you move a guest from one physical port to another before that forget timer pops. If the guest does not generate any traffic, inbound traffic will go to the wrong port. So, what should Linux do? When Linux brings an interface up, he's supposed to issue an unsolicited (gratuitous) ARP response. When operating in layer 3 mode (VSWITCH or OSA), CP or the OSA issues the grat ARP on your behalf. We have opened Novell bugzilla 617373 to address the problem of the missing unsolicited (gratuitous) ARP response in SLES11 SP1. Regards, Ursula Braun, IBM Germany -- 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: SLES 11 strange behavior network
On 2/2/2011 at 04:51 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote: 1. Overwrite the z/VM-assigned MAC-address with a user-defined MAC-address using an LLADDR-definition line in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not change after LOGOUT. I would strongly recommend _not_ doing this on a z/VM guest. One of my IBM contacts reported to me that this caused a network outage for z/VM's TCP/IP (random victim, but an important one). Apparently CP doesn't (always?) check to see if a MAC address is in use before handing it out (because Hey, I'm the only one handing them out, right?) and a Linux guest had saved the LLADDR it had been given previously. When TCP/IP started up, then both the Linux guest and TCP/IP were claiming the same MAC. Not good. A PMR has been opened with z/VM support, but I don't know where that stands. For my part, I opened up a bug with SLES development to not save the MAC automatically on a z/VM guest. 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/
Re: SLES 11 strange behavior network
On Wednesday, 02/02/2011 at 11:42 EST, Mark Post mp...@novell.com wrote: On 2/2/2011 at 04:51 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote: 1. Overwrite the z/VM-assigned MAC-address with a user-defined MAC-address using an LLADDR-definition line in /etc/sysconfig/network/ifcfg-ethx. Thus the MAC-address does not change after LOGOUT. I would strongly recommend _not_ doing this on a z/VM guest. I was probably remiss in not pointing out that z/VM 6.1 now has the ability to lock down the MAC address assigned to a guest. VMLAN MACPROTECT ON and CP SET NIC USER *|userid vdev MACPROTECT ON When you engage it, the guest can set only the assigned MAC address in the virtual adapter, whether it is set dynamically by CP or statically via the MACID option on the virtual device. That makes overwriting the MAC impossible. For completeness, a new VMLAN USERPREFIX option has been introduced so that you can use different MAC prefixes for static MACIDs. Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- 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: SLES 11 strange behavior network
On 2/2/11 11:39 AM, Mark Post mp...@novell.com wrote: Apparently CP doesn't (always?) check to see if a MAC address is in use before handing it out (because Hey, I'm the only one handing them out, right?) and a Linux guest had saved the LLADDR it had been given previously. While I feel for the guy who took the outage, this is IMHO exactly what CP *should* do -- assign a random MAC unless explicitly told what one to use, and if explicitly instructed, the consequences are on the user to keep them unique. This problem exists with user-managed MAC addresses everywhere, and the solution is either to not use user-managed MACs or make them guaranteed unique. You manually told it to do something dumb, and it did exactly what it was told. Good CP. Take a donut. For my part, I opened up a bug with SLES development to not save the MAC automatically on a z/VM guest. Right solution. Linux should not be doing this unless you (the user) really mean to use user-managed MAC addresses and are prepared to manage them properly. In fact, why limit this to just Z? It seems an odd thing to do on any platform. Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? -- db -- 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: SLES 11 strange behavior network
On Wednesday, 02/02/2011 at 01:29 EST, David Boyes dbo...@sinenomine.net wrote: Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? Are all the MAC-level takeover HA solutions gone? I thought some workload sprayers used MAC spoofing to perform transparent workload transfers. The only other reason I can think of to overwrite the MAC is in order to get a specific DHCP reservation (not the same as static IP). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- 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: SLES 11 strange behavior network
Channel bonding would be another. But even then, I wouldn't pick something that is in CP's range to assign. Marcy -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Alan Altmark Sent: Wednesday, February 02, 2011 10:46 AM To: LINUX-390@vm.marist.edu Subject: Re: [LINUX-390] SLES 11 strange behavior network On Wednesday, 02/02/2011 at 01:29 EST, David Boyes dbo...@sinenomine.net wrote: Aside from DECnet and SNA support, what still needs the ability to overwrite the MAC address of an interface these days? Are all the MAC-level takeover HA solutions gone? I thought some workload sprayers used MAC spoofing to perform transparent workload transfers. The only other reason I can think of to overwrite the MAC is in order to get a specific DHCP reservation (not the same as static IP). Alan Altmark z/VM and Linux on System z Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 alan_altm...@us.ibm.com IBM Endicott -- 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/
SLES 11 strange behavior network
Guys, i get another ghost on my enviroment... i set up my vswitch to use port group, and give grant permission to guest sles 11 Sp1.. all works okay, but if i give LOGOUT on machine, network not comes back, until i give some network request FROM this machine.. this request can be a ping for example... instantly i give a ping, the nework wake up... anybody already see this behavior ? any clue? this behavior not happens if i give a simple reboot command :-/ here is my definitions of vswitch and port group: 00242 VMLAN MACPREF 026101 00243 MOD PORT GROUP GRPSRV01 JOIN 1D00.P0 1E00.P0 00244 DEFINE VSWITCH VSWSVC01 ETHERNET RDEV 0800.P0 GROUP GRPSRV01 00245 00246 MODIFY VSWITCH VSWSVC01 GRANT DB2P101 on linux, we are currentily using vlan -- 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/
