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
