Hi Alan

Thank you
This solved the problem

Thank you 


Jan de Wet
Deployment (Business Connexion), Services Building, Midrand, South
Africa
Cell:   +27 (0)82 902 1996
Office: +27 (0)11 990 1695
Fax:    +27 (0)86 572 5720

e-mail: jan.de...@bcx.co.za
Jesus Christ is my Lord

-----Original Message-----
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Alan Altmark
Sent: 19 March 2009 14:29 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: VSWITCH not working with VLANs

On Wednesday, 03/18/2009 at 09:21 EDT, Jan de Wet - Business Connexion 
<jan.de...@bcx.co.za> wrote:

> I have been called  back to VM to help with a problem VLANs and
VSWITCH
>  
> we have a z/VM 5.4  system with a VSWITCH through which VM and a some 
Linux 
> systems talk
> The OSA card is connected to a Cisco 2950
> On the 2950 the link is defined as an accessport for VLAN 13
> On the VSWITCH all users are defined with VLAN 13 and the VSWITCH is 
also 
> defined with VLAN  13
> everything works
>  
> Now they want to let one of the Linux systems talk on VLAN 305
>  
> Our first step was to change the Cisco link to a trunk allowing vlan
13 
and 305
> Nothing was changed on the VM side
> Now NO communication goes through

What you originally did was tell the switch that the VSWITCH will NOT
send 
VLAN tags (defined as access port), but you told CP that he WILL be
using 
VLAN tags (by specifying the VLAN option).  You got lucky because the 
NATIVE vlan will default to the DEFAULT vlan.  Any guest that is
assigned 
to the NATIVE VLAN id will have their packets go out WITHOUT VLAN tags. 
That works because the Port VLAN ID on your switch was set to 13.

The moment they enabled trunk mode, the world changed.  The assigned
port 
VLAN ID (13 in your case) is no longer used.  Now those untagged frames 
come into the switch and are associated with the NATIVE VLAN ID (Cisco 
defaults to VLAN 1).  So those frames aren't going anywhere useful.

To fix the problem, make CP and the switch agree:
DEFINE VSWITCH VSW1 VLAN 13 NATIVE 1

This creates a default guest assignment to VLAN 13, but defines the
native 
VLAN ID on the switch as 1.  (Both ends of a trunk need to have the same

native VLAN ID.)  This has the effect of causing VLAN 13 traffic to be 
tagged by CP.  The switch will now properly route the traffic. 

Alan Altmark
z/VM Development
IBM Endicott

Reply via email to