In the neutron in the core of the story is abstract and physical network management. The original form of a conventional network server that hosts the operating system, the operating system some of the deployed upper layer functions (fire wall, application server, Database server). Is then passed through physical NIC traffic (the traffic) -> physical switch -> router.
When the virtualization technique appears, for utilization of physical devices becomes high. All of the above services can be deployed in a virtual machine. Communications between virtual machines need, so the concept of virtual network was born. For virtualization second floor: vswitch, vNIC.
Virtual network devices in Linux
(1)TAP/TUN/VETH
TAP / TUN is a team of virtual network devices linux kernel implementation, TAP work on the second floor, TUN work in three layers. Linux kernel given by the apparatus TAP / TUN space user device to send data state.
struct tun_struct { char name [ . 8 ]; // device names unsigned Long the flags; // distinguish tun and tap device struct fasync_struct * fasync; // file structure asynchronous notification wait_queue_head_t read_wait // wait queue struct the net_device dev; // the Linux device abstraction structure struct sk_buff_head TXQ; // network buffer struct net_device_stats stats; // NIC status information structure };
From the point of view of data structure definitions and tap tun is the same. But the work of the network layer is different. A data link layer protocol, tap corresponding to only one of: an Ethernet protocol. So tap, also known as virtual Ethernet device. Application uses read () / write () makes a tap to receive and send data to the network protocol stack linux.
tun device is a point to point network layer, linux native support of three tunnels. Also you need to configure the ip and so on.
VETH pair in pairs. Need to meet together with the namespace. Otherwise it makes no sense. To request transmission of data is always at one end emerges from the other end in the form of request acceptance. The user programs the device can not be operated directly, but is simple to use. After creating and correctly configured, to which one end of the input data, changes the orientation VETH data and sends it to the core network core, complete injection data. At the other end you can read this data.
(2)Bridge
It can be seen as a virtual Layer 2 switching devices. Other Linux network devices can be bound to the Bridge, as a slave device. These devices into virtual ports. From a physical point of view, what we put on the Bridge connection from the device.
In the kernel Lane, netdev_rx_handler_register () is called, a callback function for receiving data to be registered. After each time the data is received from this device will call this function can forward data to the Bridge. Bridge When receiving this data, br_handle_frame () is called, similar to the real world and a process switch: Category (Broadcast / single point) is determined packet, MAC lookup internal port mapping table, positioning destination port number, forward the data to a target port or discarded automatically updates the port mapping table to the internal MAC self-learning.
Bridge itself is a hidden mac address (directly accept data linux kernel stack) and hide the virtual NIC (bridge0) of. So we can give the bridge directly set ip. So mount the Bridge do not need to configure the device from ip, ip from devices exist before, if mounted, the mount after ip will fail. Network protocol stack can only see the top Bridge, its equipment mounted on the Bridge is hidden.
Find a map, as a virtual appliance workflow reference.
Detailed explanation: https://www.ibm.com/developerworks/cn/linux/1310_xiawc_networkdevice/index.html