I gave up and looked at some code. :-) The x200C is generated when you try
to register a universal MAC address or one that potentially conflicts with a
MAC address CP might create.
That means you can only register additional MAC addresses that have MAC
prefixes that are outside the range
We have done more research and found out that the same problem as we have is
faced by virtualization software running under Linux. I have found a discussion
about a feature called secondary unicast address that would allow registering
multiple MAC addresses with a NIC. Here is a discussion that
On Wednesday, 02/26/2014 at 08:44 EST, Pavelka, Tomas
tomas.pave...@ca.com wrote:
The dbf trace shows that the l2 qeth driver code gets exercised and
leads to a
command called IPA_CMD_SETVMAC. The user mode call succeeds but I have
found
this error message in
I was talking to Carsten and he said that the MAC address gets registered with
the OSA card via calls from the Linux kernel drivers. He also mentioned that
KVM faces the same problem. We will attempt to do the registering of the extra
MAC addresses from a kernel module running on the bridge
so you must be performing MAC address translation such that you look more
like a a layer 2 router (a la OSA in layer 3 mode),
not an 802.1d bridge (I said 802.3 earlier; I meant 802.1d.) That is, all
guests on the PUBLIC vswitch have the same MAC
address as viewed by all hosts on the
On Friday, 02/21/2014 at 04:54 EST, Pavelka, Tomas
tomas.pave...@ca.com wrote:
I hope we are not developing on top of a bug exploit. Let me know if I
should
add more details about the setup.
Tomas, I did some more research and you are fine. Sort of. Unless you
have MACPROTECT ON (VMLAN
On 2/21/2014 at 02:42 PM, Alan Altmark alan_altm...@us.ibm.com wrote:
However, that only works for virtual machines -- you cannot act as a
bridge for external traffic. The reason is that CP allows only one
virtual NIC to be assigned a particular MAC address at one time. If the
bridge
On Friday, 02/21/2014 at 03:38 EST, Mark Post mp...@suse.com wrote:
On 2/21/2014 at 02:42 PM, Alan Altmark alan_altm...@us.ibm.com
wrote:
However, that only works for virtual machines -- you cannot act as a
bridge for external traffic. The reason is that CP allows only one
virtual NIC to
This setup won't work, because Linux negotiates its mac address with the
OSA, and cannot send frames from another mac. You could use ip forwarding,
and have Linux route on layer 3. This should work, as long as you use the
OSA
in layer 2 mode.
with kind regards
Carsten Otte
System z firmware
: Thursday, February 20, 2014 9:35 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Layer 2 frames passing through a Linux bridge get dropped before
leaving the mainframe box
This setup won't work, because Linux negotiates its mac address with the OSA,
and cannot send frames from another mac. You could
Another question that comes to mind is, if there is negotiation with OSA, how
does Linux tell that there is a real OSA involved? My assumptions (which may be
false ;-)) were that Linux as a z/VM guest should not be able to tell whether a
NIC is real or virtual. And in our case the NIC is always
On Thu, 20 Feb 2014 09:44:45 +, Pavelka, Tomas wrote:
Another question that comes to mind is, if there is negotiation with
OSA, how does Linux tell that there is a real OSA involved? My
assumptions (which may be false ;-)) were that Linux as a z/VM guest
should not be able to tell whether a
I did not really try, but what you probably could do, is using MAC
Masquerading with ebtables on your LINUXBR machine.
http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html
Berthold
On Thu, 20 Feb 2014 09:35:00 +0100
Carsten Otte co...@de.ibm.com wrote:
This setup won't work, because Linux
On Thursday, 02/20/2014 at 03:08 EST, Pavelka, Tomas
tomas.pave...@ca.com wrote:
We have a problem where frames that pass through a Linux bridge do not
reach
the gateway outside of the mainframe box. We have set up an experiment
that
reproduces the problem, which looks like this:
(LINUX1) -
What is LINUXBR doing for you that the VSWITCH cannot do for you?
We are in the business of porting software that works on top of a Linux bridge.
We have a kernel driver that hooks into the Linux bridge and filters layer 2
frames based on rules. We got it working on Xen, VMware and inside z/VM
Further, the VSWITCH is already acting as an IEEE 802.3 layer 2 bridge and
its filtering database will drop unicast frames destined for unknown MAC
addresses.
One thing I forgot to mention: We have successfully sent packets between two
vswitches connected to a Linux bridge (LINUX1 and
On Thursday, 02/20/2014 at 09:33 EST, Pavelka, Tomas
tomas.pave...@ca.com wrote:
Further, the VSWITCH is already acting as an IEEE 802.3 layer 2 bridge
and
its filtering database will drop unicast frames destined for unknown MAC
addresses.
One thing I forgot to mention: We have successfully
so you must be performing MAC address translation such that you look more like
a a layer 2 router (a la OSA in layer 3 mode), not an 802.1d bridge (I said
802.3 earlier; I meant
802.1d.) That is, all guests on the PUBLIC vswitch have the same MAC address
as viewed by all hosts on the PRIVATE
On Mon, 2011-06-27 at 14:25 -0500, Dave Jones wrote:
Here is what is in the ifcfg-eth0 file:
# IBM QETH
DEVICE=eth0
BOOTPROTO=static
VSWITCH=1
OPTION=(layer2=1)
IPADDR=xxx.yyy.www.zzz
NETMASK=255.255.255.0
NETTYPE=qeth
TYPE=Ehternet
ONBOOT=yes
HWADDR=02:00:00:00:00:07
Hi, Ursula.
Yes, that fixed the problem; many thanks! I didn't need the HWADDR and
VSWITCH settings and I specified the OPTIONS statement incorrectly (it's
OPTIONS and not just OPTION).
Have a good one.
DJ
On 06/28/2011 03:24 AM, Ursula Braun wrote:
On Mon, 2011-06-27 at 14:25 -0500, Dave
On 6/27/2011 at 03:25 PM, Dave Jones d...@vsoft-software.com wrote:
HWADDR=02:00:00:00:00:07
I would try removing this from the ifcfg-eth0 file. There's usually not a good
reason for a guest to be setting (or expecting) a particular MAC address for
it's virtual NIC.
Mark Post
Hi, Mark.
I've tried it without the HWADDR value and now the error is eth0 does
not seem to be present.
Thanks.
DJ
On 06/27/2011 02:32 PM, Mark Post wrote:
On 6/27/2011 at 03:25 PM, Dave Jones d...@vsoft-software.com wrote:
HWADDR=02:00:00:00:00:07
I would try removing this from the
You need to either remove the specification of the MAC in ifcfg-eth0 -- or
specify it in the z/VM directory entry for the guest so that it matches.
It's likely best to just remove it and let it default unless you have a
real need to specify it.
Scott Rohling
On Mon, Jun 27, 2011 at 1:25 PM,
On 6/27/2011 at 03:41 PM, Dave Jones d...@vsoft-software.com wrote:
I've tried it without the HWADDR value and now the error is eth0 does
not seem to be present.
Rats. Is there a file for the NIC in /etc/sysconfig/hardware? If so, is
there any sort of MAC specification in there? I would
On Monday, 06/27/2011 at 03:53 EDT, Mark Post mp...@novell.com wrote:
On 6/27/2011 at 03:41 PM, Dave Jones d...@vsoft-software.com
wrote:
I've tried it without the HWADDR value and now the error is eth0 does
not seem to be present.
Rats. Is there a file for the NIC in
Drop the TYPE= and VSWITCH= as well as HWADDR= ..
Scott Rohling
On Mon, Jun 27, 2011 at 1:41 PM, Dave Jones d...@vsoft-software.com wrote:
Hi, Mark.
I've tried it without the HWADDR value and now the error is eth0 does
not seem to be present.
Thanks.
DJ
On 06/27/2011 02:32 PM, Mark
Hi, Scott.
Removing the VSWITCH=1 and TYPE=Ethernet values from ifcfg-eth0 does not
help matters at allI still receive the eth0 device is not present
Thanks, though.
DJ
On 06/27/2011 02:51 PM, Scott Rohling wrote:
Drop the TYPE= and VSWITCH= as well as HWADDR= ..
Scott Rohling
Realistically, is there a reason why ANY error code from an OSA should
not
issue a meaningful message? I mean, after all, you (IBM) control the
error
code set, and it's not like cryptic error messages are a virtue, even
in the
Unix world...
David,
I agree with you. But most of the error
On 3/17/2009 at 5:41 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote:
-snip-
3. 0x4e
If you have a scenario to run into 0x4e, we should analyze this in
detail.
See the attached z/VM console log.
Mark Post
--
For
On 3/18/09 4:44 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote:
Realistically, is there a reason why ANY error code from an OSA should
not
issue a meaningful message?
I agree with you. But most of the error codes indicate programming
errors, which should be reported to us.
I guess I buy
Mark,
some comments on the qeth IDX terminate cause codes mentioned in this
thread:
1. 0xf6 layer2/layer3 mismatch error
short term solution: recent qeth patch to come up with a meaningful
message
discussed long term solution: let qeth choose the appropriate layer;
Such a solution would require
some comments on the qeth IDX terminate cause codes mentioned in this
thread:
1. 0xf6 layer2/layer3 mismatch error
short term solution: recent qeth patch to come up with a meaningful
message
Realistically, is there a reason why ANY error code from an OSA should not
issue a meaningful
On 3/12/2009 at 3:37 PM, Alan Altmark alan_altm...@us.ibm.com
wrote:
On Thursday, 03/12/2009 at 02:40 EDT, Mark Post mp...@novell.com
wrote:
I get an IDX TERMINATE with cause code 0xf6, which I have read some
of
the archives that said that was a layer2/layer3 mismatch error.
I'm pretty
On 3/13/2009 at 4:29 AM, Ursula Braun ubr...@linux.vnet.ibm.com wrote:
-snip-
Cause code 0xf6 has been caught in qeth recently:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff
;h=fc9c24603c4b93d84160e14c0a98a754d4328d15
I am going to discuss with z/VM
Is there a reason why it can't go one step further? You know it's layer
capabilities obviously, just use it in the manner it is supposed to be
rather than having the administrator code something?
Marcy
This message may contain confidential and/or privileged information. If
you are not the
/etc/sysconfig/hardware directory has a file for the nic
(hwcfg-qeth-bus-ccw-0.0. )
Add QETH_LAYER2_SUPPORT=1
To it.
Marcy
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not
One gotcha I ran into was in the PROFILE TCPIP in VM, the LINK statement for
the VSWITCH needed to be changed to specify ETHERNET from IP. IP is the default.
May not have anything to do with this error but something to check.
Bobby Bauer
Center for Information Technology
National Institutes of
You should remove PORTT TRUNK from the definition of the vswitch.
The PORTTYPE is the default virtual NIC port type *not* the type of
port on the real switch that the OSA port attaches to. The default
virtual NIC port type is ACCESS, so removing PORTT TRUNK will change
the default virtual NIC
On 3/12/2009 at 1:58 PM, Bruce Hayden bjhay...@gmail.com wrote:
You should remove PORTT TRUNK from the definition of the vswitch.
The PORTTYPE is the default virtual NIC port type *not* the type of
port on the real switch that the OSA port attaches to. The default
virtual NIC port type is
On Thursday, 03/12/2009 at 02:40 EDT, Mark Post mp...@novell.com wrote:
I get an IDX TERMINATE with cause code 0xf6, which I have read some of
the archives that said that was a layer2/layer3 mismatch error.
I'm pretty sure that would be a 0x4e error, since I just deliberately
caused
that
The Novell starter system? Humm, I didn't know if that was
recommended or supported on that system. I guess we have to find out
what she really wants to do. But anyway, I'd rather connect a guest
to multiple vlans via multiple nics and vswitches rather than using
802.1q.
On Thu, Mar 12, 2009
On 3/12/2009 at 3:37 PM, Alan Altmark alan_altm...@us.ibm.com wrote:
On Thursday, 03/12/2009 at 02:40 EDT, Mark Post mp...@novell.com wrote:
I get an IDX TERMINATE with cause code 0xf6, which I have read some of
the archives that said that was a layer2/layer3 mismatch error.
I'm pretty
On 3/12/2009 at 3:34 PM, Bruce Hayden bjhay...@gmail.com wrote:
The Novell starter system? Humm, I didn't know if that was
recommended or supported on that system. I guess we have to find out
what she really wants to do. But anyway, I'd rather connect a guest
to multiple vlans via
Here's a document on installing using layer2 on RHEL:
http://kbase.redhat.com/faq/docs/DOC-10539
For an installed guest, change /etc/sysconfig/network-scripts/ifcfg-eth0:
remove the line: ARP=no
add the line: OPTIONS=layer2=1
And as Marcy noted, if using VSWITCH, make sure it's defined with
Also just a note
You need to use at least RHEL4.6 to install layer2 rh. There's a bug
in pripy released that does not recognize layer2 in anaconda. 4.6
fixed this
William Carroll,
Sent from my iPhone 3G
On Dec 1, 2008, at 2:19 PM, Brad Hinson [EMAIL PROTECTED] wrote:
Here's a document on
Paul,
From a linux point of view, the only difference (SuSE 9 and 10 anyways)
is having to set in /etc/sysconfig/hardware/hwcfg-qeth...
QETH_LAYER2_SUPPORT=1..
Everthing else is the same.
From the VM pov, the vswitch gets ethernet.
We're almost totally moved in order to LACP, and this really
Clovis,
What do you mean by ..let VM do the work?
The problem as I understand it is DHCPD requires the VSWITCH to use Layer 2 due
to the guest OS needing to accept broadcasts.
On Mon, Aug 18, 2008 at 12:31 PM, in message
[EMAIL PROTECTED], Clovis
Pereira [EMAIL PROTECTED] wrote:
Ryan,
What do you mean by ..let VM do the work?
VM TCPIP included a DHCP server at one point. I think it's been
deprecated, and might be removed in the future. It worked, but it wasn't
very easy to configure for some of the options that are needed in a
modern environment -- netbooting and PXE support
Van: Linux on 390 Port [mailto:[EMAIL PROTECTED] Namens Ryan McCain
Verzonden: maandag 18 augustus 2008 16:53
Aan: LINUX-390@VM.MARIST.EDU
Onderwerp: Layer 2 on the VSWITCH --Take 3
We have 2064 - z900, 2066 - z800 and 2084 - z990.Does this mean it's not
possible for us to run a DHCP
Support is right - I was at the t3 IN ENDICOTT and they emphasized it in
one of the presentations
'Where ever you go - There you are!! '
Richard (Gaz) Gasiorowski
Global Solutions Technology
Principal Lead Infrastructure Architect
845-773-9243 Work
845-392-7889 Cell
[EMAIL PROTECTED]
On Monday, 08/18/2008 at 10:55 EDT, Ryan McCain
[EMAIL PROTECTED] wrote:
--SNIP--
2. Another dependency is hardware. Layer 2 support is available only on
z890,
z990, and z9.Are you running one of these?
--SNIP--
We have 2064 - z900, 2066 - z800 and 2084 - z990.Does this
Ryan, I have DHCPD running on VM (not Linux) for years, since a G5 machine.
Why not let VM do the work?
Regards,
__
Clovis Pereira
zVM zOS Support - SWS
Maintenance and Technical Support Services
MTS Brazil
phone: 55-11-2132-3399
[EMAIL PROTECTED]
On 8/18/2008 at 11:17 AM, in message
[EMAIL PROTECTED], Alan
Altmark [EMAIL PROTECTED] wrote:
-snip-
The OSA-Express Customer Guide and Reference says this about Layer 2
support on p.13:
Hardware requirements
- z890 or z990 and above only
Would Layer 3 and the fake_ll headers option be a
From: Mark Post [mailto:[EMAIL PROTECTED]
On 8/18/2008 at 11:17 AM, Alan Altmark [EMAIL PROTECTED]
wrote:
-snip-
The OSA-Express Customer Guide and Reference says this about Layer 2
support on p.13:
Hardware requirements
- z890 or z990 and above only
Would Layer 3 and the
Yay!! It works it works it works!
Thank you Alan!!!
I'll buy you and Jay a beer in San Antonio! Your bonus points are in the
mail too.
Marcy
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you
Lee Stewart wrote:
Is there a way to tell if Layer 2 support is enabled -- OUTSIDE OF YAST.
Said another way, does anyone know what file(s) are updated when Layer
2 is enabled?
Lee, you can look in the /sys file system for the layer2 flag...
[EMAIL PROTECTED] ~]# cat
Thanks!! Just what I needed...
Vic Cross wrote:
Lee Stewart wrote:
Is there a way to tell if Layer 2 support is enabled -- OUTSIDE OF YAST.
Said another way, does anyone know what file(s) are updated when Layer
2 is enabled?
Lee, you can look in the /sys file system for the layer2 flag...
57 matches
Mail list logo
