====== Networking ====== ---- [[http://wiki.xenproject.org/wiki/XenNetworking]] ---- ===== Terminology ===== ---- There are three types of server-side software objects which represent networking entities. * **PIF**, represents a **physical network interface** on a Xen Cloud Platform host. PIF objects have a name and description, a globally unique UUID, the parameters of the NIC that they represent, and the network and server they are connected to. * **VIF**, which represents a **virtual interface on a Virtual Machine**. VIF objects have a name and description, a globally unique UUID, and the network and VM they are connected to. * **Network**, which is a **virtual Ethernet switch** on a Xen Cloud Platform host. Network objects have a name and description, a globally unique UUID, and the collection of VIFs and PIFs connected to them. ---- ==== Networks ==== ---- Each Xen Cloud Platform host has one or more networks, which are virtual Ethernet switches. Networks without an association to a PIF are considered internal, and can be used to provide connectivity only between VMs on a given Xen Cloud Platform host, with no connection to the outside world. Networks with a PIF association are considered external, and provide a bridge between VIFs and the PIF connected to the network, enabling connectivity to resources available through the PIF's NIC. ---- ==== VLANs ==== ---- Virtual Local Area Networks (VLANs), as defined by the IEEE 802.1Q standard, allow a single physical network to support multiple logical networks. XenServer hosts can work with VLANs in multiple ways. All supported VLAN configurations are equally applicable to pools and standalone hosts, and bonded and non-bonded configurations. ---- ===== Initial Networking Configuration ===== ---- The Xen Cloud Platform host networking configuration is specified during initial host installation. Options such as IP address configuration (DHCP/static), the NIC used as the management interface, and hostname are set based on the values provided during installation. When a Xen Cloud Platform host has a **single NIC**, the following configuration is present after installation: * a single PIF is created corresponding to the host's single NIC * the PIF is configured with the IP addressing options specified during installation to enable management of the host * the PIF is set for use in host management operations * a single network, network 0, is created * network 0 is connected to the PIF to enable external connectivity to VMs When a host has **multiple NICs** the configuration present after installation depends on which NIC is selected for management operations during installation: * PIFs are created for each NIC in the host * the PIF of the NIC selected for use as the management interface is configured with the IP addressing options specified during installation * a network is created for each PIF ("network 0", "network 1", etc.) * each network is connected to one PIF * the IP addressing options of all other PIFs are left unconfigured In both cases the resulting networking configuration allows connection to the Xen Cloud Platform host by any management software running on separate machines via the IP address of the management interface. The configuration also provides external networking for VMs created on the host. The PIF used for management operations is the only PIF ever configured with an IP address.\\ **External networking for VMs is achieved by bridging PIFs to VIFs using the network object which acts as a virtual Ethernet switch.** ---- ==== Paravirtualised Network Devices ==== ---- A paravirtualised network device consists of a pair of network devices. The first of these (the frontend) will reside in the guest domain while the second (the backend) will reside in the backend domain (typically Dom0). A similar pair of devices is created for each virtual network interface. The frontend devices appear much like any other physical Ethernet NIC in the guest domain. Typically under Linux it is bound to the xen-netfront driver and creates a device ethN. Under NetBSD and FreeBSD the frontend devices are named xennetN and xnN respectively. The backend device is typically named such that it contains both the guest domain ID and the index of the device. Under Linux such devices are by default named vifDOMID.DEVID while under NetBSD xvifDOMID.DEVID is used. The front and backend devices are linked by a virtual communication channel, guest networking is achieved by arranging for traffic to pass from the backend device onto the wider network, e.g. using bridging, routing or Network Address Translation (NAT). {{ :hypervisor:base:network:basic.png?direct&200 |}} ---- ==== Emulated Network Devices ==== ---- As well as PV network interface fully virtualised (HVM) guests can also be configured with one or more emulated network devices. These devices emulate a real piece of hardware and are useful when a guest OS does not have PV drivers available or when they are not yet available (i.e. during guest installation). An emulated network device is usually paired with a PV device with the same MAC address and configuration. This allows the guest to smoothly transition from the emulated device to the PV device when a driver becomes available. The emulated network device is provided by the device model (DM[1]) (running either as a process in domain 0 or as a Stub Domain). When the DM runs as a process in domain 0 then the device is surfaced in the backend domain as a tap type network device. Historically these were named either tapID (for an arbitrary ID) or tapDOMID.DEVID. More recently they have been named vifDOMID.DOMID-emu to highlight the relationship between the paired PV and emulated devices. If the DM runs in a stub domain then the device surfaces in domain 0 as a PV network device attached to the stub domain. The stub domain will take care of forwarding between the device emulator and this PV device. ---- ==== MAC addresses ==== ---- Virtualised network interfaces in domains are given Ethernet MAC addresses. By default most Xen toolstacks will select a random address, depending on the toolstack this will either be static for the entire life time of the guest (e.g. Libvirt, XAPI or xend managed domains) or will change each time the guest is started (e.g. XL or xend unmanaged domains). In the latter case if a fixed MAC address is required e.g. for using with DHCP then this can be be configured using the mac= option to the vif configuration directive (e.g. vif = ['mac=aa:00:00:00:00:11']). See [[http://xenbits.xen.org/docs/unstable/misc/xl-network-configuration.html|XL Network Configuration]] for more details of the syntax. In case yo have to set a MAC address yourself, refer to [[http://wiki.xenproject.org/wiki/XenNetworking]] for indications on how to do that. ---- ==== Bridging ==== ---- The default (and most common) Xen configuration uses bridging within the backend domain (typically domain 0) to allow all domains to appear on the network as individual hosts. In this configuration a software bridge is created in the backend domain. The backend virtual network devices (vifDOMID.DEVID)) are added to this bridge along with an (optional) physical Ethernet device to provide connectivity off the host. By omitting the physical Ethernet device an isolated network containing only guest domains can be created. There are two common naming schemes when using bridged networking. In one scheme the physical device eth0 is renamed to peth0 and a bridge named eth0 is created. In the other the physical device remains eth0 while the bridge is named xenbr0 (or br0 etc). We shall use the eth0+xenbr0 naming scheme here. Of course you are free to use whatever names you like, including descriptive names (e.g. "dmz", "internal", "external" etc). {{ :hypervisor:base:network:network-bridge.png?direct&200 |}} ---- ==== Open vSwitch ==== ---- The Xen 4.3 release will feature initial integration of [[http://www.openvswitch.org/|Open vSwitch]] based networking. Conceptually this is similar to a bridged configuration but rather than placing each vif on a Linux bridge instead an Open vSwitch switch is used. Open vSwitch supports more advanced [[http://en.wikipedia.org/wiki/Software-defined_networking|Software-defined Networking (SDN)]] features such as [[http://www.openflow.org/|OpenFlow]]. ==== Software Bridge ==== In order to give network access to guest domains it is necessary to configure the domain 0 network appropriately. The most common configuration is to use a software bridge. It is recommended that you manage your own network bridge using the [[https://wiki.debian.org/BridgeNetworkConnections|Debian network bridge]]. The Xen wiki page [[http://wiki.xen.org/wiki/Host%20Configuration/Networking|Host Configuration/Networking]] also has some useful information. The Xen supplied network scripts are not always reliable and will be removed from a later version. They are disabled by default in Debian's packages. If you have a router that assigns ip addresses through dhcp, the following is a working example of the **/etc/network/interfaces** file using bridge-utils software. > cp /etc/network/interfaces /etc/network/interfaces.bak > nano /etc/network/interfaces # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet manual # Main bridge for Xen auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 #other possibly useful options in a virtualized environment #bridge_stp off # disable Spanning Tree Protocol #bridge_waitport 0 # no delay before a port becomes available #bridge_fd 0 # no forwarding delay A possible **static IP address** configuration would be as follow: # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface auto eth0 iface eth0 inet manual # Main bridge for Xen auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 10.0.7.215 netmask 255.255.255.0 broadcast 10.0.7.255 gateway 10.0.7.1 activate your changes like this: > ifdown eth0 > killall dhclient > ifup xenbr0 > brctl show bridge name bridge id STP enabled interfaces xenbr0 8000.xxxxxxxxxxxx no eth0 You should see your new IP address on ifconfig xenbr0, and you should still be able to ping out (e.g. ping 8.8.8.8 / and resolve: ping google.com). Note that if you are running a DHCP server on this machine, then you may need to change the xenbr0 interface to a static or manual IP address, as DHCP may not come up in time to provide an address otherwise. In case you are executing those changes from a remote ssh connection, you should execute the interface refresh commands in a sequence as you'll probably loose the connection after the first **ifdown**: > ifdown eth0 && killall dhclient : ifup xenbr0 ==== Disable Netfilter on Bridges ==== It is highly recommended, for performance and security reasons, that **netfilter is disabled** on all bridges by adding the following to **/etc/sysctl.conf**. > nano /etc/sysctl.conf ADD: net.bridge.bridge-nf-call-ip6tables = 0 net.bridge.bridge-nf-call-iptables = 0 net.bridge.bridge-nf-call-arptables = 0 Then, as root: > sysctl -p /etc/sysctl.conf ==== Open vSwitch ==== The configuration for openvswitch is persistent across reboots. Supposing that you want to create a bridge called 'xenbr0' and attach it to physical nic 'eth0', after installation you can use the following commands: > ovs-vsctl add-br xenbr0 > ovs-vsctl add-port xenbr0 eth0 xenbr0 will still need to be set up to acquire an IP address just as Linux bridging does; see above for examples on how to set this up. ===== WiFi Setup ===== You'll need to have a configured WiFi card before you attempt to make any WiFi connection from your install. Please refer to the [[https://wiki.debian.org/fr/WiFi|Debian documentation]] for more info on this.\\ To make sure you have a WiFi card recognized: > lspci -v (you could filter that with | grep -A 11 WiFi) The last line indicates which kernel module is in use: Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01) ... Kernel driver in use: rtl8192ce > lsmod | grep rtl8192ce ==== Scanning for SSIDs ==== > iwlist scan ==== Setup WiFi Parameters ==== > nano /etc/network/interfaces # my wifi device auto wlan0 iface wlan0 inet dhcp wireless-essid [ESSID] wireless-mode [MODE] This won't be enough if you're using WPA encryption (which is greatly recommended). You'll wpasupplicant package: > apt-get install wpasupplicant Restrict the permissions of /etc/network/interfaces, to prevent pre-shared key (PSK) disclosure: > chmod 0600 /etc/network/interfaces > nano /etc/network/interfaces Define appropriate stanzas for your wireless interface, along with the SSID and PSK. For example: auto wlan0 iface wlan0 inet dhcp wpa-ssid mynetworkname wpa-psk mysecretpassphrase The "auto" stanza will bring your interface up at system startup. If not desired, remove or comment this line. Bring your interface up. This will start wpa_supplicant as a background process. > ifup wlan0 Additional wpa-* options are described within /usr/share/doc/wpasupplicant/README.modes.gz, also refer to [[https://wiki.debian.org/WiFi/HowToUse#Command_Line]] for WPA-EAP and more. ==== Swithing WiFi Configuration Using Logical Interfaces ==== You can quickly switch between WiFi configurations using logical interfaces: > nano /etc/network/interfaces iface wlan_home inet dhcp wpa-ssid myhomessid wpa-psk mysecretpassphrase iface wlan_office inet dhcp wpa-ssid myofficessid wpa-psk mysecretpassphrase > ifdown wlan0 > killall dhclient > ifup wlan0=wlan_home ==== Configure Wireless Bridge ====