On 1/25/16 8:53 , [email protected] wrote: > ----- On Jan 25, 2016, at 11:04 AM, Robert Mustacchi [email protected] wrote: > >> On 1/25/16 5:38 , Humberto Ramirez wrote: >>> What would you say is the improvement over a standard vnic? Does it >>> approach a 10G link speed? >> >> An etherstub is a local virtual switch. VNICs can be created on top of >> it like they can be created on top of normal physical devices. >> >> When you're only focusing on loopback devices and virtio devices, link >> speed is a red herring and you should just ignore it. Link speed only >> matters when you have a physical device as that speed indicates the >> upper band of the data rate that it can put on the wire. >> >> If you've rigged everything up over an etherstub then you'll never go >> out over the physical device; however, devices will still show a link >> speed, because there's really no way not to. For example, a virtio >> device in a hardware virtualized guest has no way of knowing what the >> link speed of the device its going out over is. It could be 100 Mbit/s, >> 1 Gbit/s, 10 Gbit/s, or 40 Gbit/s, etc. and still only show the link >> speed in the guest as 1 Gbit/s. >> >> Practically, the limits of link speed for a VNIC are based on the >> underlying device or the kernel data path, so it can saturate a 10 >> Gbit/s device. On the flip side, due to how the hardware virtualization >> is currently implemented, it is unlikely that you will see speeds much >> higher than 1 Gbit/s. > > would you please give an example of how one would create an etherstub > (acting as a virtual switch) in such a way that the vms local to the > given smartos machine would leverage that, while vms on other smartos > machines would still be able to reach the vms connected to the etherstub?
Let me try to clarify how all this works. I don't think you've done anything wrong per se. Whenever you create a VNIC, you traditionally have to specify it as being over a specific physical device. Logically you can think of this like as every VNIC and every physical device are plugged into a switch and frames which don't match any devices on that switch (eg. other VNICs and the physical device itself) will be transmitted out over the wire of the physical device. Note, you never create this switch, nor can you manage it or configure. It's all set up by automatically for you. An etherstub is similar in concept. You can think of it like the physical device in the above example, except that if the destination MAC address is not a VNIC on the etherstub, then the frames will be dropped. The etherstub itself has no MAC address. So in this case, the only time I'd employ an etherstub is if I wanted to have a network that was local to the host itself. There are a couple reasons you might use this. The primary use case I see is that folks want to have one zone that acts as a router or firewall and all the rest are on their own private network that uses the one zone to get there. In this case, they'll put the router/firewall over both a physical device and an etherstub. Now, there's also no reason that you have to use etherstubs. For example, at Joyent, we don't use etherstubs at all, because there's nothing we have that we want to bind to the confines of a single host. Even when there are private networks, they span more than one physical host. Does that help clarify things at all? Robert ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
