Attached there is a patch that fixes the used protocol (was udp - but
nobody was listening...) to icmp echo and added the extension, that
the dom0 and the other guest ips are also pinged.
Because of the many different scenarios (three nested loops) over
packet sizes, two guests and different ip addresses, one run of this
test case takes now about 4.5 minutes.
Signed-off-by: Andreas Florath <xen@flonatel.org>
if an additional parameter is given for the network-bridge
(e.g. netdev=eth1) The patch splits the network command into the
command name and its parameters to determine the netenv (bridge,
route, nat)
Signed-off-by: juergen.gross@fujitsu-siemens.com
In various places in documentation and code, IP addresses are provided
as examples, defaults, or dummy configuration. In general the
specific IP addresses used in Xen are not always appropriate. (For
example, 1.2.3.4 is used in a few places!)
The following addresses should be used:
* For examples and documentation, 192.0.2.0/24. (See RFC3330.)
* For defaults for private networks, a random network from RFC1918.
I have randomly selected 172.30.206.0/24 for this purpose and
documented this in at the only registry I know of,
www.ucam.org/cam-grin. This network should henceforth be used for
default configurations of local bridges, test networks, etc. in
Xen tools.
The following addresses should NOT be used:
* 10.0.*.*, 10.1.*.*, 192.168.0.*, 192.168.1.*, etc. Using these
addresses gives greatly increased likelihood of collision, as
ignorant network administrators and reckless middlebox vendors
often pick networks from the bottom of 10/8 and 192.168/16.
* 169.254.*.*. These are reserved for zeroconf (ad-hoc networking)
and should not be used for Xen private networks, bridges, etc.,
etc. Use of these addresses by Xen scripts causes trouble on hosts
(eg laptops) which find themselves in ad-hoc networking
environments. I think this is not hypothetical (!) since at least
one Linux distribution have specific code to detect this case and
cause Xen startup to fail iff the host already has an external
zeroconf address.
* 1.2.3.4. WTF !?
I have also used 127.0.255.255 in one place where apparently a dummy
address is needed (some Linux kernels won't accept a lack of an NFS
server address). If 127.0.255.255 is mistakenly used it is unlikely
to do any damage to real traffic even if it does escape into the
network at large.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
creating domains with networking very easy. This patch:
1) Adds new XenDevice class, with the XenNetDevice subclass. These
classes represent devices for xm-test and are tied to XenDomains.
This can eventually be used for block devices as well. Currently,
devices must be added to domains prior to starting the domain. The
attach and detach needs to be handled.
2) Adds a new NetConfig class to handle configuring the network
environment in which the tests run. This patch only handles ranges
of IPs in a bridged environment. DHCP needs to be added as well as
handling NAT and routed environments.
3) Modifies XenDomain class to handle XenDevices.
4) Adds new configuration options for defining a range of IPs, their
network address, and their netmask.
5) Removes the old Network.py and Network class.
6) Modifies the existing tests to use the new infrastructure.
7) Adds some documentation to help creating domains.
Signed-off-by: Daniel Stekloff <dsteklof@us.ibm.com>
Keir Fraser
Keir Fraser
James Bulpin
Tom Wilkie
Ewan Mellor
stekloff@dyn9047022152.beaverton.ibm.com