On Wednesday, 06/02/2010 at 03:18 EDT, Offer Baruch <[email protected]> wrote: > Just to be clear... I think we are talking about different things... when > defining a port at the switch level you can define 1 or more VLANs in trunk > mode and 0-1 VLAN in access mode. I called the access mode VLAN as the > native VLAN...
Yes, terminology is extremely important. o There are *trunk* ports and *access* ports (Cisco terminology) o Access ports accept and emit only untagged frames. Every access port has an associated *port VLAN ID* (PVID) which is logically added to inbound frames and stripped from outbound frames. The default PVID is usually VLAN 1. So even if you don't explicitly assign a PVID, there is always exactly one VLAN ID associated with an access port. o Trunk ports accept and emit both tagged and untagged frames. Untagged traffic on a trunk port is associated with the *native* VLAN ID (default native VLAN ID is usually VLAN 1). o All trunked switches must have the same native VLAN ID. Hence, you must use the NATIVE keyword on DEFINE VSWITCH if the native VLAN id of the attached switch is not VLAN 1. When the native VLAN ID and all port PVIDs are 1 (the usual default configuration), you have what looks like a hub. All untagged traffic on any port, trunk or access, is in VLAN 1. There are some in the industry who think that is a Bad Thing, but it is what it is. > z/OS was working in access mode (not VLAN 1) before z/VM came into the > picture... Terminology: Software is either "VLAN aware" or "VLAN unaware". > when z/VM arrived new VLANs were added to the port in trunk > mode... VSWITCHs are only working with VLAN tagging... no host is using VLAN > 1 (as defined in all of our switches). > Do you still think an accident waiting to happen? If so please elaborate > some more... Yes. If z/OS is VLAN unaware, then z/OS is emitting untagged frames. That means they will be associated with the switch's native VLAN ID. I think that is a Bad Thing. SOME of the switch management protocols still operate on the *untagged* frames. IMO, you need to add a VLAN specification to z/OS and change the native VLAN ID back to 1 if you're going to share the OSA that way. People often ask me if they can share an OSA between a VSWITCH and something else. I say "You *can*, but you *shouldn't*." This is precisely why. z/OS and other VLAN-unaware entities can share an OSA. VLAN-aware entities *should not* unless they are simply replicants. That is, LPARs 1 and 2 both run z/VM with a VSWITCH called "INTRANET". It is ok to share an OSA because you have simply split the workload of a single INTRANET connection (VSWITCH) among two LPARs. Of course, you can't use Link Aggregation. But, IMO, HOST connections should not be mixed with VSWITCH connections. Hosts are not switches and there is a reason hosts are not plugged into trunk ports. Different rules, different expertise and training, different expectations, a different price to pay for misconfiguration. As I said, it's not about what you *can* do, it's about what you *should* (or should not) do. Alan Altmark z/VM Development IBM Endicott ---------------------------------------------------------------------- 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/
