----- On Jan 25, 2016, at 1:10 PM, Robert Mustacchi [email protected] wrote:
> 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 it does indeed, and i appreciate the time you put into your response. it's also nice to know i haven't been limiting my bandwidth all this time. :) ------------------------------------------- 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
