rhtyd commented on issue #3040: Broadcast URI not set to vxlan, but vlan URL: https://github.com/apache/cloudstack/issues/3040#issuecomment-440932002 @wido the current network model is not designed and implemented that way wrt KVM. The vlan/vxlan based isolation is for isolated/vpc networks implemented by the VR which does NAT-ing from public network end; and typically a bridge device is created where guest domain/VM's nic (via tap devices) are plugged and any vxlan tunnel end point (vtep) or vlan enable ethernet device is plugged to implement the (isolated/vpc-tier) network. With SG you get massive-scalable L3 isolation by having host-level firewall implemented/enforced by ebtables (firewall rules on bridge) rules and ipset config, and so there is no need of a VR to do network isolation (however VR does only provide dhcp and dns). What you've described is a new feature where you want the guest VMs to still receive public IPs and network access, but the (public) bridge device to provide isolation by plugging in a vxlan (or vlan) enabled ethernet device and carry public traffic over vxlan for a tenant. This means on your core router side, for all such guest networks isolation should terminate (vxlan). If there is no need of isolated network and guest networks are still shared, so the question is -- do you only want isolation between these shared networks which carry public traffic only in your datacenter? You already have L3/SGs isolation. I've not tested but you can try adding public address ranges with SG enabled and some isolation (vlan:// or vxlan:// tagging), dedicate that range to an account and see if that works. Lastly, L2/vlan isolation implementation and usage are quite **robust**, widely used in enterprise but not massively scalable.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
