Xen FAQ Networking
|
Needs Refactor
This document may benefit being merged with relevant questions from XenFAQ2 and other larger documents in Category:FAQ. |
Networking Issues
What is veth, vif or xenbr0?
You should read XenNetworking http://wiki.xensource.com/xenwiki/XenNetworking
Why can't I ssh into or ping a newly created domain?
In the default configuration we rely on the Linux bridge-utils in domain 0 to set up virtual networking. After you've created a new domain (e.g., domain 1) you should be able to run ifconfig in domain 0 and see an interface with a name like vif1.0; you should also be able to check that bridging is working by typing brctl show xen-br0. Finally, you can check the IP confiuration in the new domain by logging into it via the console (xm console) and running standard tools such as ifconfig and route.
Why does my new domain receive no network traffic until after it initiates an outgoing connection?
This is an issue that occurs under the following circumstances:
- You do not specify the domain's MAC address, causing a random MAC address to be selected at domain creation time
- The upstream router has a local ARP cache
When a domain is destroyed, the host system's ARP cache is purged of addresses for the defunct virtual NIC. If the domain is recreated it is likely to be allocated a different random MAC address. This is no problem for the host machine, but the external switch/router still knows the "old" MAC address. The switch/router requires an outbound packet to the outside world to implicitly eradicate the old ARP-cache entry. This is not really Xen's fault at all, just a property of the implementation of ARP resolution.
Fixes: Either manually declare the MAC address in your VM config file, or upgrade to the 2.0-testing tree where the problem is fixed. This fix will also find its way into the forthcoming 2.0.4 maintenance release.
How do I fix MTU issues resulting in "Received packet needs 8 bytes more headroom" in dmesg or /var/log/message output ?
See: http://lists.xensource.com/archives/html/xen-devel/2005-12/msg00226.html
You can work around the bug by reducing the MTU of eth0 in the dom0 e.g. "ifconfig eth0 mtu 1400". Put this in your networking scripts (e.g.: /etc/sysconfig/network/ifcfg-eth0 for RH/RPM systems or /etc/network/interfaces for Debian/Deb systems). See: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/ref-guide/s1-networkscripts-interfaces.html for RH syntax, 'man interfaces' for Debian.
This bug is understood and a fix has been applied to the testing tree.
It only effects dom0 kernels built with the -xen config rather than -xen0.
Basically, the -xen kernel config turns on so much stuff that the area reserved for the max possible header length is too big. This causes a netfront slow-path to be exercised that copies the SKB. Unfortunately, this path hadn't been exercised before, and guess what, it was subtly broken for checksum-offloaded packets.
TCP and UDP checksum errors, ping but nothing else, ipsec tunnels don't form, DNAT translation doesn't work
Try running the following command in each domU:
ethtool -K eth0 tx off
This command disable TX checksumming
To check checksum problems, you can use tcpdump:
tcpdump -vv -n -i eth0
Read http://lists.xensource.com/archives/html/xen-users/2006-04/msg00032.html
This may or may not work.
Xen and Shorewall
There is a document about configuring Shorewall in Dom0 at http://www.shorewall.net/Xen.html
http://www1.shorewall.net/XenMyWay.html can be useful also.
Too many vethX and vif0.X
By default, 8 vethX and vif0.X are created. These interfaces are "cheap" but clutter list of interfaces. If you want to allocate only the necessary number, pass netloop.nloopbacks=NUMBER parameter to kernel command line.
I can't use more than 3 network interfaces in domU
This is a limitation in Xen 3. Xen 3.1 supports 8 network interfaces.
