Hi Daniel,

The mechanism for isolating L2 traffic is at the vSwitch level – there is no 
way to VLAN tag the at the NIC level for a VM in VMware. Your only other option 
is therefore to VLAN tag at the guest OS level which adds security issues + 
overhead, etc. 

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 15/08/2017, 13:05, "daniel.herrm...@zv.fraunhofer.de" 
<daniel.herrm...@zv.fraunhofer.de> wrote:

    Hi Dag,
    
    thank you for your answer. As far as I know, the end user never has direct 
access to the virtual router. I am not talking about adding a VLAN tag at the 
user VM, only at the VPR, where the limit most likely comes into play when 
creating a number of tiers in a VPC.
    
    We could do both: normal VMs require one interface per tier/network, which 
makes perfect sense. The router however could use VLAN tags at VM level, which 
could remove the limitation of having a maximum number of tiers connected to 
one VPC. It is only configured by CloudStack, the end user does not have access 
to the VPR.
    
    Regards
    Daniel
    
    Am 15.08.17, 13:27 schrieb "Dag Sonstebo" <dag.sonst...@shapeblue.com>:
    
        Hi Daniel,
        
        In theory that could work – but keep in mind we are working in a 
multi-tenant environment, where guest isolation must be guaranteed, hence 
cannot ever be exposed to normal users. The isolation method must be abstracted 
from the end user VMs – otherwise you would have a potential security issue 
where someone could tag traffic from their VM with  someone else’s tag. Doing 
tagging at VM level would also be a huge overhead.
        As a result we VLAN tag at the vSwitch or bridge level – which end 
users have no access to – the flipside of the coin being that this requires 
separate NICs for each tier.
        
        Regards,
        Dag Sonstebo
        Cloud Architect
        ShapeBlue
        
        On 15/08/2017, 11:07, "daniel.herrm...@zv.fraunhofer.de" 
<daniel.herrm...@zv.fraunhofer.de> wrote:
        
            Hi,
            
            we are hitting the same limitation, except that we can use 10 NICs 
on VMware.
            
            The fact that we also use the Private Gateway functionality addes 
another NIC, besides the management and outside NIC which is present as well.
            
            I wonder that is the reason for one NIC per tier? Why not just use 
one outside NIC, one management NIC and *one* NIC for the tiers, where the 
VLANs (or whatever isolation method is used) is trunked, for example just using 
subinterfaces and dot1Q tags? This would eliminate this limit for whatever 
hypervisor that supports trunk to it’s guests (I know for sure about VMWare, 
not so much about the other hypervisors).
            
            Regards
            Daniel
            
            Am 15.08.17, 10:52 schrieb "Dag Sonstebo" 
<dag.sonst...@shapeblue.com>:
            
                Hi Dennis,
                
                Any tier or network which is accessible and part of a VPC 
requires an interface on the VPC Virtual Router.
                
                What you can however do is create separate shared networks and 
connect these as secondary networks to your VMs – these shared networks get 
their own VR.
                
                Regards,
                Dag Sonstebo
                Cloud Architect
                ShapeBlue
                
                On 15/08/2017, 09:19, "Dennis Meyer" <snooop...@gmail.com> 
wrote:
                
                    Hi,
                    
                    im using xenserver as hypervisor so im limited to 7 nic's / 
vm, so the
                    router vm cant handle more than 7 nics which corresponds to 
7 networks
                    inside a vpc. I had created some networks for different 
drbd and corosync
                    stuff, they dont need a gateway, dhcp and a router vm. How 
should a network
                    offering look like which dont creates a network on the 
routervm but is
                    accessible by the vpc?
                    
                    Snooops
                    
                
                
                dag.sonst...@shapeblue.com 
                www.shapeblue.com
                53 Chandos Place, Covent Garden, London  WC2N 4HSUK
                @shapeblue
                  
                 
                
                
            
            
        
        
        dag.sonst...@shapeblue.com 
        www.shapeblue.com
        53 Chandos Place, Covent Garden, London  WC2N 4HSUK
        @shapeblue
          
         
        
        
    
    


dag.sonst...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Reply via email to