> 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 vswitch (and vice versa).
In my original question I changed the names of vswitches and virtual machines.
This one will have the real names which are not as self-explanatory because I'm
using what is available. Here are more details on the setup:
AL070009 (141.202.59.44/02-00-C2-00-01-3A) - <ALBL07> - TOMRH61 (runs bridge) -
<INTRA59> - AL07000A (141.202.59.45/02-00-C2-00-01-3B)
I ran a ping from AL070009
PING 141.202.59.45 (141.202.59.45) 56(84) bytes of data.
64 bytes from 141.202.59.45: icmp_seq=1 ttl=64 time=1.40 ms
64 bytes from 141.202.59.45: icmp_seq=2 ttl=64 time=0.426 ms
And three TCP dumps:
First one at the interface on AL070009:
03:21:01.089237 02:00:c2:00:01:3a (oui Unknown) > 02:00:c2:00:01:3b (oui
Unknown), ethertype IPv4 (0x0800), length 98: 141.202.59.44 > 141.202.59.45:
ICMP echo request, id 2040, seq 1, length 64
Second one on the bridge (TOMRH61):
03:21:01.089304 02:00:c2:00:01:3a (oui Unknown) > 02:00:c2:00:01:3b (oui
Unknown), ethertype IPv4 (0x0800), length 98: 141.202.59.44 > 141.202.59.45:
ICMP echo request, id 2040, seq 1, length 64
And third one at the interface at the destination guest (AL07000A):
03:21:01.090045 02:00:c2:00:01:3a (oui Unknown) > 02:00:c2:00:01:3b (oui
Unknown), ethertype IPv4 (0x0800), length 98: 141.202.59.44 > 141.202.59.45:
ICMP echo request, id 2040, seq 1, length 64
As sanity check I have saved the results of CP Q VSWITCH ACT for both vswitches
and verified that ALBL07 (private vswitch) does not have 02-00-C2-00-01-3B
registered and that INTRA59 (public vswitch) does not have 02-00-C2-00-01-3A
registered:
+ grep 02-00-C2-00-01-3A dumps/private_switch.act
02-00-C2-00-01-3A IP: 141.202.59.44
+ grep 02-00-C2-00-01-3B dumps/private_switch.act
+ grep 02-00-C2-00-01-3A dumps/public_switch.act
+ grep 02-00-C2-00-01-3B dumps/public_switch.act
02-00-C2-00-01-3B IP: 141.202.59.45
As a second sanity check I have revoked access of AL07000A from all vswitches
except for INTRA59 which left the Linux machine with a single active NIC with
MAC 02-00-C2-00-01-3B (I used another vswitch for SSH access). I was still able
to ping in that scenario.
>From this I think that sending MAC addresses unknown to a vswitch is possible
>and the vswitch will not block it. A frame with src mac address
>02-00-C2-00-01-3A which is only known on ALBL07 gets received by a guest only
>connected to INTRA59 which does not know the source mac address. I do not
>think we have duplicate MAC addresses on the whole z/VM system.
The bridge software I use is this:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge which
they say implements a subset of ANSI/IEEE 802.1d.
I hope we are not developing on top of a bug exploit. Let me know if I should
add more details about the setup.
Thanks,
Tomas
----------------------------------------------------------------------
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/
