Re: Native VLAN for VSWITCH
Hi, In z/VM 5.3, we broke the native VLAN out from the default VLAN. So you can set a default and a native vlan id. DEFINE VSWITCH name RDEV rdev VLAN this_is_the_default NATIVE this_is_the_native. In z/VM 5.2, the native and the default vlan are the same. So DEFINE VSWITCH name RDEV rdev VLAN this_is_both_default_and_native. I hope that information helps you. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking http://www.vm.ibm.com/virtualnetwork/ From: "Burch, Aubrey Dennis CIV DISA GS4B" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Date: 06/24/2008 03:47 PM Subject: Native VLAN for VSWITCH Hello All I'm attempting to connect a TCPIP stack and some LINUX guests to a VSWITCH using 802.1Q trunking, and the network administrator sent me the following VLAN info as he configured it on the real switch: "Attached are the IP addresses you requested. I will put the trunk in place on core switch 2 tonight. I will trunk VLANs 390, 391, 393 and 389(new vlan for this project). I will use a native vlan of 499. Will that work for you?" I tentatively told him I thought it was OK, but I have not found a way to successfully configure the NATIVE VLAN (I *think* that's the problem). It appears there is a way to do this with the NATIVE option on the DEF VSWITCH command on z/VM 5.3, but I am at 5.2. If I issue the following: DEF VSWITCH VSW1 RDEV 9160 VLAN 499 SET VSWITCH VSW1 GRANT TCPIP VLAN 389 That combination allows me to ping the gateway on his switch, but I can go no further out. I cannot get to my TCPIP stack from outside the network either, as I expected. I have tried several permutations of VLAN identifiers on the DEF VSWITCH command, and the only way to reach the gateway is to use VLAN 499 or VLAN 1. I have left VLAN 389 on the SET VSWITCH VSW1 GRANT command for TCPIP for each attempt, as they requested the hosts go on VLAN 389. Before I go back to the network guys, does anyone know of a way to accommodate (on 5.2) the NATIVE VLAN configuration the network guy specified above? Thanks, Denny Burch z/VM and z/LINUX Systems DISA DECC Mechanicsburg 717 605-1181 (dsn) 430-1181
Re: New z/VM 5.3 VSWITCH Port Isolation function
Hi, Wolfgang, There is nothing in the VSWITCH that will come up by default to prevent guests from talking to each other. If you send me your configuration information, I can take a look and see what might be going on.The default for a VSWITCH in z/VM 5.2 is DEFINE VSWITCH vswitchname If that is all you specify, you will come up as a VLAN UNAWARE IP layer VSWITCH without OSA connectivity to the external network.Remember your guests have to be authorized and coupled to the virtual switch. The new support that Alan is talking about is enabled by issuing a MODIFY or SET VSWITCH vswitchname ISOL OFF|DROP|FORWARD and is not enabled by default. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking http://www.vm.ibm.com/virtualnetwork/ tie line - 620-5469 / (607-429-5469) Wolfgang Engel <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 04/22/2008 08:28 AM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: New z/VM 5.3 VSWITCH Port Isolation function Alan, the subject brought me to a question I have in mind for some time. There seems to be a feature on z/VM's (4.4 to 5.2) which prevents the guests on the same VSWITCH to talk to eachother. This is what happens on our system with every VSWITCH I create. Every guest can't talk to other guests by default and I don't know how to enable it. Is there something I have to enable ? Regards, Wolfgang On Sun, Apr 06, 2008 at 12:25:37PM -0400, Alan Altmark wrote: > [cross-posted to IBMVM and LINUX-390] > > I just want to bring to everyone's attention some new support for the > Virtual Switch. APAR VM64281 for z/VM 5.3 (only) provides a "port > isolation" function that prevents guests on the same VSWITCH or VLAN (if > the VSWITCH is VLAN-aware) from talking directly to each other. You can > decide what to do with packets destined for other guests on the LAN > segment: silently drop them or forward them, as-is, out to the switch. > > This new function became available on February 26th. > > For more information, see p.58 of the -05 edition of the z/VM Connectivity > book, http://publibz.boulder.ibm.com/epubs/pdf/hcsc9b21.pdf. > > If you have any questions, please post them to IBMVM. Thanks. > > Regards, > Alan > > Alan Altmark > Sr. Software Engineer > IBM z/VM Development -- With kind regards/Mit freundlichen Gruessen, your/Ihr SuSE Team Wolfgang Engel ([EMAIL PROTECTED]) - SUSE LINUX Products GmbH Tel: +49-911-74053-668 Maxfeldstr. 5 Fax: +49-911-7417755 90409 Nuernberg, Email: [EMAIL PROTECTED] Germany WWW: http://www.suse.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -
Re: Tracing VSWITCH - SAG broker problem
Hi, Hans, You should check out APAR PK25362 for IPFORMAT. I believe that should help with your error situation. Good luck. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking Hans Rempel <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 04/10/2007 07:17 PM Please respond to [EMAIL PROTECTED] To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tracing VSWITCH - SAG broker problem Thanks Tracy. I did find a webpage from Paul Giordano talking about tracing VSWITCH but ran into problem/time with IPFORMAT exec. I used sample ETC and Config files from IBM. ipformat debug file a 228 +++ 40 +++ DMSRTL2103E Error in compiled CMS system Rexx file; additional information: 4100 41 IPFORMAT EXEC 228 Ready(20041); T=0.27/0.27 17:50:09 Allan. Thanks for your comments. Nothing has changed or broke in production. We are trying to setup a test environment with new TCPIP stack and network server with new software. I would like to prove that the VSWITCH and OSA are not the problem because I use the same VSWITCH and OSA in the production TCPIP stack. The traces seem to show that data is heading onto the VSWITCH. Why the network folks don?t see it is a mystery to me. I have a few tests planned for Thursday morning which I hope will shed more light on the situation. Hans From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tracy J Adams Sent: April 10, 2007 2:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Tracing VSWITCH - SAG broker problem For more information on using the 'SNIFFER' support added in z/VM 5.2.0, please see the Troubleshooting a Virtual Switch or Guest LAN section of the z/VM Connectivity Guide. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking Alan Altmark/Endicott/[EMAIL PROTECTED] Sent by: The IBM z/VM Operating System 04/10/2007 02:04 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tracing VSWITCH - SAG broker problem On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel <[EMAIL PROTECTED]> wrote: > Hi all. Sorry for the lengthy post. > > I have a problem trying to get SAG broker in VSE to talk to SAG broker on a > windows platform. For legacy reasons we wish to keep the environment the same > so there is NO VSE TCPIP stack involved. This does make it more complicated but > that is how it has/is been running in production for 4 years. If it has been working, what changed? > 1)Is there some documentation/tools on reading QDIO traces to I can > analyze this captured trace? No. To get that level of help you need to open a PMR. > 2)Is there a trace I can setup to trace traffic leaving the VSWITCH to > the OSA card or trace certain channels (ports) on the OSA card? Currently one > LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by > DTCVSW1 userid. You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself is done exactly as your network guys are doing - with sniffers. Beware that OSA port sharing enables the OSA to "short cut" the packets if it recognizes the destination MAC or IP address as belonging to the OSA. And you know how I am about providing pictures, IP addys, and subnet masks. I can't tell if the various hosts are [supposed to be] in the same subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone configuration descriptions, particularly where shared OSAs come into play. :-D Alan Altmark z/VM Development IBM Endicott
Re: Tracing VSWITCH - SAG broker problem
For more information on using the 'SNIFFER' support added in z/VM 5.2.0, please see the Troubleshooting a Virtual Switch or Guest LAN section of the z/VM Connectivity Guide. Tracy (Bolinda) Adams [EMAIL PROTECTED] z/VM Development - Virtual Networking Alan Altmark/Endicott/[EMAIL PROTECTED] Sent by: The IBM z/VM Operating System 04/10/2007 02:04 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Tracing VSWITCH - SAG broker problem On Tuesday, 04/10/2007 at 12:39 AST, Hans Rempel <[EMAIL PROTECTED]> wrote: > Hi all. Sorry for the lengthy post. > > I have a problem trying to get SAG broker in VSE to talk to SAG broker on a > windows platform. For legacy reasons we wish to keep the environment the same > so there is NO VSE TCPIP stack involved. This does make it more complicated but > that is how it has/is been running in production for 4 years. If it has been working, what changed? > 1)Is there some documentation/tools on reading QDIO traces to I can > analyze this captured trace? No. To get that level of help you need to open a PMR. > 2)Is there a trace I can setup to trace traffic leaving the VSWITCH to > the OSA card or trace certain channels (ports) on the OSA card? Currently one > LPAR uses 0,1,2 and the second LPAR using 3,4,5. The VSWITCH is monitored by > DTCVSW1 userid. You can trace the *VSWITCH* by putting a Linux guest on the VSWITCH with sniffer (promiscuous mode) authority and gather a TCPDUMP. You'll see all the traffic on *that* VSWITCH. Tracing the traffic leaving the OSA itself is done exactly as your network guys are doing - with sniffers. Beware that OSA port sharing enables the OSA to "short cut" the packets if it recognizes the destination MAC or IP address as belonging to the OSA. And you know how I am about providing pictures, IP addys, and subnet masks. I can't tell if the various hosts are [supposed to be] in the same subnet or not. I get sleepy when I read ankle-bone-leg-bone-hip-bone configuration descriptions, particularly where shared OSAs come into play. :-D Alan Altmark z/VM Development IBM Endicott
Re: Unexpected DEFINE NIC Results
Check your directory for NICDEFs and your MVSXExx users for error messages. I suspect you have a NICDEF or Define NIC with devices greater than 3. For example you could have a NICDEF 1340 type qdio devices 6 CP SEND does not show you the error message on your console but instead over on MVSXE49's. So your define nic might have failed but your couple still succeeded in coupling the base nic address (1340) to your VSWITCH. The detach then destroyed the 1340 nic allowing the next define nic to succeed and you get the results you originally wanted. I'd be happy to look at this issue more if you want to send me your consoles or a snapshot of your directory, etc. Tracy (Bolinda) Adams z/VM Development - Virtual Networking "Scully, William P" <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 01/10/2007 01:37 PM Please respond to The IBM z/VM Operating System To IBMVM@LISTSERV.UARK.EDU cc Subject Unexpected DEFINE NIC Results Sometimes CP doesn't do what you expect. Here's an example where I needed the NIC for z/OS to be at address 1344 rather than 0D00. Not hard to fix dynamically... Let's try: q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 4Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; cp send cp mvsxe83 detach nic d00 Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 3Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; cp send cp mvsxe83 define nic 1344 type qdio Ready; cp send cp mvsxe83 couple 1344 system intrav6 Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 4Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 0D00 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; OK, one down, two to go, (now that I have my technique down pat): cp send cp mvsxe49 detach nic d00 Ready; cp send cp mvsxe62 detach nic d00 Ready; cp send cp mvsxe49 define nic 1344 type qdio Ready; cp send cp mvsxe62 define nic 1344 type qdio Ready; cp send cp mvsxe49 couple 1344 system intrav6 Ready; cp send cp mvsxe62 couple 1344 system intrav6 Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 4Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 1340 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 1340 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; Huh? Where did "1340" come from? Oh well, if at first you don't succeed: cp send cp mvsxe49 detach nic 1340 Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 3Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE62 NIC: 1340 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; cp send cp mvsxe49 define nic 1344 type qdio Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 4Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 1340 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE97 NIC: 4100 Name: UNASSIGNED Ready; cp send cp mvsxe49 couple 1344 system intrav6 Ready; q vswitch intrav6 details VSWITCH SYSTEM INTRAV6 Type: VSWITCH Connected: 4Maxconn: INFINITE PERSISTENT RESTRICTEDNONROUTER Accounting: OFF VLAN Unaware State: Defined IPTimeout: 5 QueueStorage: 8 Adapter Owner: MVSXE49 NIC: 1344 Name: UNASSIGNED Adapter Owner: MVSXE62 NIC: 1340 Name: UNASSIGNED Adapter Owner: MVSXE83 NIC:
