>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
One area I would include would be SLAs and how quickly for recovery in a DR
or OR (Operational Recovery) situation. As well as type of tasks (web,
BYOD, B2B, etc). Your decisions should be around your company environment.
If it is okay for a task to complete in Days then either platform works.
Hello Everyone,
Firstly, I just want to say that I'm new to this list and have been
impressed with the great information I've seen from the list so far.
My employer is trying to establish if they should continue to invest in
mainframe technology or migrate to a virtualized x86 platform (virtual
se
On Thursday, 02/20/2014 at 09:33 EST, "Pavelka, Tomas"
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 sent packets
> 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 LIN
> 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
On Thursday, 02/20/2014 at 03:08 EST, "Pavelka, Tomas"
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) - - (LINUXBR) -
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 wrote:
> This setup won't work, because Linux negotiates its mac
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 N
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
Thanks, this means a big change to our plans ;-) Do you know if there are any
public docs (or source code) that we could look at to understand how the
negotiation works?
Tomas
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Carsten
Otte
Sent: Th
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 develo
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) - - (LINUXBR) - - OSA - gateway
The problem is that in this setup we cannot ping the
13 matches
Mail list logo
