On 02/15/2011 08:38 PM, Alan Altmark wrote: > >> Define vswitch vsw1 rdev 200.p1 250.p1 ETHERNET >> Define vswitch vsw2 rdev 204.p1 254.p1 IP vlan 58 porttype access nogvrp > > That's not how I recommend defining VLAN-aware VSWITCHes. See my previous > posts. > > DEFINE VSWITCH VSW1 RDEV 204.p1 254.p1 IP VLAN 666 NATIVE 1 > > Where '666' is an unused VLAN and '1' is the native VLAN id of the > physical switch.
Thanks, I will follow this advice. > > Why NOGVRP? That prevents CP from telling the switch about the VLANs in > use. Our network guys said they don't want that mainframe registers anything in their switches.. I'll have to talk to them again to check if they really knew what they were saying. :) > >> One port of two OSA cards (OSA-Express3 dual-port cards) are connected > to trunk >> ports of physical >> switches 1 and 2. >> So, actually, all the guests are connected to the external LAN via one > OSA port >> and one physical switch. > > I think what you're saying is that 200 and 204 are on port 1 of OSA#1 > (primary), and that 250 and 254 are on port 1 of OSA#2 (backup)? Exactly. Looking at the Q VSWITCH output, OSA#2 is active at the moment for both vsw1 and vsw2, because we tested redundancy with putting OSA#1 offline for a moment. > > "And the quarterback is toast!". The traffic on VSW1 will be untagged. > Untagged traffic on a trunk port will be assigned the native VLAN id of > the physical switch. You can bet it isn't VLAN 58 or 46 (probably VLAN > 1). No no, linux hosts do vlan tagging, their network interfaces are configured with vconfig, not ifconfig. And then vsw1, being vlan unaware, delivers vlan tags to and from the linux hosts without modifying them. This is how I understand this. I guess this is not a recommended way to configure this, but this is how it has been from the beginning. Vsw1 has been working well for three years now.. Our network guys said recently that they want linuxes to be vlan unaware and vswitches to take care of vlan tagging. I agreed. Vsw2 is the newcomer, as we are migrating LPAR mode VSEs onto VM and want to make their network connections redundant. > > But you can certainly get your switch techs to look at the traffic and see > what's happening. Yes, we have to cooperate for sure. These discussions will be interesting as I try to teach them the terminology related to VM vswitches and OSA cards, and they try to teach me how networks work. :) Juha Vuori sysprog Lindorff, Finland ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] 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/
