Difference between revisions of "Differences between venet and veth"
(vdLunJCeQSsC) |
|||
(3 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | OpenVZ provides [[veth]] (Virtual ETHernet) or [[venet]] (Virtual NETwork) devices (or both) for in-[[CT]] networking. Here we describe the differences between those devices. | |
− | + | ||
− | + | * ''veth'' allows broadcasts in CT, so you can use even a DHCP server inside a CT, or a samba server with domain broadcasts or other such stuff. | |
+ | * ''veth'' has some security implications. It is normally bridged directly to the host physical ethernet device and so must be treated with the same considerations as a real ethernet device on a standalone host. The CT users can access a ''veth'' device as they would a real ethernet interface. However, the CT root user is the only one that has priviledged access to the ''veth'' device. | ||
+ | * With ''venet'' device, only OpenVZ host node administrator can assign an IP to a CT. With ''veth'' device, network settings can be fully done on CT side by the CT administrator. CT should setup correct gateway, IP/netmask etc. and then a [[HN|node]] admin can only choose where your traffic goes. | ||
+ | * ''veth'' devices can be bridged together and/or with other devices. For example, in host system admin can bridge ''veth'' from 2 CTs with some VLAN eth0.X. In this case, these 2 CTs will be connected to this VLAN. | ||
+ | * ''venet'' device is a bit faster and more efficient. | ||
+ | * With ''veth'' devices, IPv6 auto generates an address from MAC. | ||
+ | |||
+ | The brief summary: | ||
+ | {| class="wikitable" style="text-align: center;" | ||
+ | |+ '''Differences between veth and venet''' | ||
+ | ! Feature !! [[veth]] !! [[venet]] | ||
+ | |- | ||
+ | ! MAC address | ||
+ | | {{yes}} || {{no}} | ||
+ | |- | ||
+ | ! Broadcasts inside CT | ||
+ | | {{yes}} || {{no}} | ||
+ | |- | ||
+ | ! Traffic sniffing | ||
+ | | {{yes}} || {{no}} | ||
+ | |- | ||
+ | ! Network security | ||
+ | | style="background: #ffdddd" | Low <ref>Independent of host. Each CT must setup its own separate network security.</ref> | ||
+ | | style="background: #ddffdd" | High<ref>Controlled by host.</ref> | ||
+ | |- | ||
+ | ! Can be used in bridges | ||
+ | | {{yes}} || {{no}} | ||
+ | |- | ||
+ | ! IPv6 ready | ||
+ | | {{yes}} || {{yes}} | ||
+ | |- | ||
+ | ! Performance | ||
+ | | style="background: #ffdddd" | Fast | ||
+ | | style="background: #ddffdd" | Fastest | ||
+ | |- | ||
+ | |} | ||
+ | <references/> | ||
+ | |||
+ | |||
+ | [[Category: Networking]] |
Latest revision as of 10:17, 22 March 2012
OpenVZ provides veth (Virtual ETHernet) or venet (Virtual NETwork) devices (or both) for in-CT networking. Here we describe the differences between those devices.
- veth allows broadcasts in CT, so you can use even a DHCP server inside a CT, or a samba server with domain broadcasts or other such stuff.
- veth has some security implications. It is normally bridged directly to the host physical ethernet device and so must be treated with the same considerations as a real ethernet device on a standalone host. The CT users can access a veth device as they would a real ethernet interface. However, the CT root user is the only one that has priviledged access to the veth device.
- With venet device, only OpenVZ host node administrator can assign an IP to a CT. With veth device, network settings can be fully done on CT side by the CT administrator. CT should setup correct gateway, IP/netmask etc. and then a node admin can only choose where your traffic goes.
- veth devices can be bridged together and/or with other devices. For example, in host system admin can bridge veth from 2 CTs with some VLAN eth0.X. In this case, these 2 CTs will be connected to this VLAN.
- venet device is a bit faster and more efficient.
- With veth devices, IPv6 auto generates an address from MAC.
The brief summary:
Feature | veth | venet |
---|---|---|
MAC address | Yes | No |
Broadcasts inside CT | Yes | No |
Traffic sniffing | Yes | No |
Network security | Low [1] | High[2] |
Can be used in bridges | Yes | No |
IPv6 ready | Yes | Yes |
Performance | Fast | Fastest |