Differences between venet and veth - Revision history

217.116.177.34 at 10:17, 22 March 2012

2012-03-22T10:17:57Z

82.231.73.29 at 21:13, 6 October 2011

2011-10-06T21:13:32Z

78.53.214.83 at 20:38, 22 September 2011

2011-09-22T20:38:52Z

Kir: Reverted edits by 91.201.66.163 (Talk) to last revision by 64.65.78.18

2010-09-15T06:46:08Z

Reverted edits by 91.201.66.163 (Talk) to last revision by 64.65.78.18

91.201.66.163: vdLunJCeQSsC

2010-09-15T04:30:43Z

vdLunJCeQSsC

64.65.78.18 at 13:05, 24 February 2010

2010-02-24T13:05:56Z

Kir: HSP -> hosting

2009-02-25T11:30:11Z

HSP -> hosting

Dowdle: There were a few typos... and I changed veth to venet with regards to speed and the host node admin config.

2008-06-17T20:56:13Z

There were a few typos... and I changed veth to venet with regards to speed and the host node admin config.

Ginkyo: some cleaning (link, bold, italic, order, VE=>CT, misspelling)

2008-05-19T12:27:00Z

some cleaning (link, bold, italic, order, VE=>CT, misspelling)

Kir: removed extra |

2006-06-28T20:48:47Z

removed extra |

← Older revision		Revision as of 10:17, 22 March 2012
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.	+	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'' 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.

@@ Line 30: / Line 30: @@
 |-
 ! IPv6 ready
-| {{yes}} || {{no}}
+| {{yes}} || {{yes}}
 |-
 ! Performance

@@ Line 27: / Line 27: @@
 |-
 ! Can be used in bridges
 | {{yes}} || {{no}}
 |-

@@ Line 1: / Line 1: @@
-F2EB4Y http://ontogen.com
+OpenVZ provides [[veth]] (Virtual eTHernet) or [[venet]] (Virtual NETwork) devices (or both) for in-[[CT]] networking. Here we describe the differences between those devices.
-<a href="http://ontogen.com">online casino</a>
-[URL=http://ontogen.com]online casino[/URL]
+* ''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.

@@ 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.
+F2EB4Y http://ontogen.com
+<a href="http://ontogen.com">online casino</a>
-* ''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.
+[URL=http://ontogen.com]online casino[/URL]

@@ Line 1: / Line 1: @@
-OpenVZ provides you to use either  [[veth]] (Virtual eTHernet) or [[venet]] (Virtual NETwork) devices (or both) for in-[[CT]] networking. Here we describe the differences between those devices.
+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, so is not recommended in untrusted environments like for hosting. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. CT's user can actually ruin your ethernet network with such direct access to ethernet layer.
+* ''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.
@@ Line 23: / Line 23: @@
 |-
 ! Network security
-| style="background: #ffdddd" | Low <ref>Due to broadcasts, sniffing and possible IP collisions etc.</ref>
+| style="background: #ffdddd" | Low <ref>Independent of host.  Each CT must setup its own separate network security.</ref>
-| style="background: #ddffdd" | High
+| style="background: #ddffdd" | High<ref>Controlled by host.</ref>
 |-
 ! Can be used in bridges

@@ Line 3: / Line 3: @@
 * ''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, so is not recommended in untrusted environments like HSP. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. CT's user can actually ruin your ethernet network with such direct access to ethernet layer.
-* With ''veth'' device, only node administrator can assign an IP to a CT. With ''veth'' device, network settings can be fully done on CT side. CT should setup correct gateway, IP/netmask etc. and then a [[HN|node]] admin can only choose where your traffic goes.
+* 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.
-* ''veth'' device is a bit faster and more efficient.
+* ''venet'' device is a bit faster and more efficient.
 * With ''veth'' devices, IPv6 auto generates an address from MAC.

@@ Line 1: / Line 1: @@
-OpenVZ provides you to use either [[venet]] or [[veth]] devices (or both) for in-[[VE]] networking. Here we describe the differences between those devices.
+OpenVZ provides you to use either  [[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 VE, so you can use even a DHCP server inside a VE, or a samba server with domain broadcasts or other such stuff.
+* ''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, so is not recommended in untrusted environments like HSP. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. VE user can actually ruin your ethernet network with such direct access to ethernet layer.
+* ''veth'' has some security implications, so is not recommended in untrusted environments like HSP. This is due to broadcasts, traffic sniffing, possible IP collisions etc. i.e. CT's user can actually ruin your ethernet network with such direct access to ethernet layer.
-* With venet device, only node administrator can assign an IP to a VE. With veth device, network settings can be fully done on VE side. VE should setup correct gateway, IP/netmask etc. and then a [[HN|node]] admin can only choose where your traffic goes.
+* With ''veth'' device, only node administrator can assign an IP to a CT. With ''veth'' device, network settings can be fully done on CT side. 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 VEs with some VLAN eth0.X. In this case, these 2 VEs will be connected to this VLAN.
+* ''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.
+* ''veth'' device is a bit faster and more efficient.
-* With veth devices, IPv6 auto generates an address from MAC.
+* 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
+! Feature !! [[veth]] !! [[venet]]
 |-
 ! MAC address
 | {{yes}} || {{no}}
 |-
-! Broadcasts inside VE
+! Broadcasts inside CT
 | {{yes}} || {{no}}
 |-