Nice. Looking forward to 6.1 ;)

Thaanks Alan 


Patrick Carroll  |  Technology Architect II 
L.L.Bean, Inc.(r) |  Double L St. |  Freeport ME 04033 
http://www.llbean.com | [email protected] | 207.552.2426 

CONFIDENTIALITY NOTICE: This e-mail and any attachments may contain 
confidential information that is legally privileged. The information is solely 
for the use of the intended recipient(s). Any disclosure, copying, 
distribution, or other use of this information is strictly prohibited. If you 
have received this e-mail in error, please notify the sender by return e-mail 
and delete this message.


-----Original Message-----
From: Linux on 390 Port [mailto:[email protected]] On Behalf Of Alan 
Altmark
Sent: Monday, April 04, 2011 5:03 PM
To: [email protected]
Subject: Re: VSWITCH and GRANT for VLAN

On Monday, 04/04/2011 at 02:59 EDT, Pat Carroll <[email protected]>
wrote:
> Darn security :) Glad you found it...
> I asked that question because when I implemented vlans a few years 
> ago,
the
> physical switch ports were tagging all frames. Since I was doing
something
> "new" it had to be me. Once we configured the physical switch to *not*
tag
> packets associated with the primary vlan, all was good.

In The Beginning, CP did not differentiate the Native VLAN ID of the switch 
from the Default VLAN id of the switch.  They were one and the same.  So if you 
granted a guest access to the default VLAN id, his traffic was treated as 
'native' and was emitted untagged.  <gag> Likewise, inbound untagged frames 
were associated by the VSWITCH with the default VLAN id.  <gag x 2>

Subsequently the NATIVE option was added to the DEFINE VSWITCH so that only 
guests assigned to the native VLAN id would have their traffic emitted 
untagged, and inbound untagged frames were associated with the NATIVE VLAN id 
specifications.  All Right and Proper.

But, wait!  Switches also have the idea of a "access VLAN" for trunk ports.  It 
is used when a trunk port receives untagged frames.  The default value is 
typically either the native VLAN id of the switch or VLAN
1 (which is also the typical default native VLAN id).  If you find yourself in 
this realm, then you need to change the NATIVE specification on DEFINE VSWITCH 
to match.  What you're really telling CP is what VLAN id should be emitted 
untagged.

And I've updated my Best Practice for VSWITCH definitions.  Please see my 
recent post to IBMVM.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
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/

----------------------------------------------------------------------
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/

Reply via email to