So, If you make sure you have NATIVE NONE and keep track of your grants (just like PORTBASED) there is no real security concern... The guest is only allowed the vlans you grant it (just like PORTBASED) and he cant send any untagged frames. I would rather manage a USERBASED VSWITCH with trunks over managing ports with PORTBASED any day... It is much easier to make vlan mistakes with PORTBASED... USERBASED is much more intuitive, easy to manage and easy to view...
I agree you should close all the security holes before you do that... but that seems a better solution then PORTBASED. There are pro's and con's for everything but I would recommend USERBASED for security reasons and management reasons (assuming you know what you are doing). Offer Baruch On Apr 22, 2016 6:19 PM, "Alan Altmark" <alan_altm...@us.ibm.com> wrote: > On Friday, 04/22/2016 at 07:07 GMT, Offer Baruch <offerbar...@gmail.com> > wrote: > > Can you please explain what is the problem with linux working in trunk > mode? > > What security problem are you talking about? > > An untrusted server should not be on a trunk port. Ever. A trunk can > also carry untagged frames, and those frames will be associated with the > *native* VLAN of the switch. I can't get people to code "VLAN AWARE > NATIVE NONE", so they are getting "NATIVE 1". That means untagged frames > from a VLAN-aware guest will be placed on VLAN 1, which is the default for > most switch vendors, and is used to carry switch management traffic. And > to talk to other hosts attached to the default VLAN. > > I'm not sure if a physical switch port can have the native VLAN ID for > that port excluded from the allowed VLANs, or if that will raise an error. > NATIVE NONE causes untagged frames to be dropped on trunking vNICs. z/VM > 6.1 and earlier don't have that capability, so be careful. > > Trunks are for switches, not hosts. From the network's point of view, ALL > hosts are evil. Let us say that in order to save money, you are attaching > multiple hosts to a trunked OSA port. There are NO OSA controls on what > LPARs can use what VLANs, so it must be assumed that the host can attach > itself to any VLAN authorized for the port. > > In a VSWITCH, we don't have that problem. However, VLAN IDs can and do > change. You don't want a VLAN-aware host to be accidentally left on the > wrong VLAN. Network People don't expect hosts to be using trunks without > a Really Good Reason. > > Alan Altmark > > Senior Managing z/VM and Linux Consultant > Lab Services System z Delivery Practice > IBM Systems & Technology Group > ibm.com/systems/services/labservices > office: 607.429.3323 > mobile; 607.321.7556 > alan_altm...@us.ibm.com > IBM Endicott > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to lists...@vm.marist.edu 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 lists...@vm.marist.edu 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/
