Commit Graph
8 Commits
Author SHA1 Message Date
Keir Fraser 9577157dc4 network-nat: Fix NAT scripts.
Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
2008-01-24 14:37:53 +00:00
Keir Fraser 7d25fcefa9 Revert network-nat script changes introduced by 16739:33dcf04d77152.
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
2008-01-18 13:40:22 +00:00
Keir Fraser aac518b954 tools/docs: Fix example and default IP addresses.
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>
2008-01-17 15:13:40 +00:00
Alastair Tse b2bfd9596f Switch hotplug scripts to use /bin/bash rather than /bin/sh.
Hotplug scripts include certain bash-isms that are not supported under
some distros' default shell (eg. Ubuntu 6.10's use of dash)

Signed-off-by: Alastair Tse <atse@xensource.com>
2007-01-04 14:25:58 +00:00
emellor@leeni.uk.xensource.com 5941ac94f2 Added DHCP server support, configured by a dhcp=yes parameter. This will write
the appropriate entries into dom0's DHCP server configuration file, allowing
that server to provide info for the guest when it starts.

If an IP address is not configured for vif-nat, invent one using the domain
ID and vif ID.

Fix the vif-nat script.

Signed-off-by: Ewan Mellor <ewan@xensource.com>
2005-11-29 14:55:48 +00:00
cl349@firebug.cl.cam.ac.uk b93e7f7e8b bitkeeper revision 1.1426.1.1 (4289cc8cPUM98bLJs4TV93NHY9LOKg)
Many files:
  Make interface to network/block scripts consistent:
  - output on stdout is returned to the script caller
  - output on stderr is logged at the error level, messages with a '-' prefix
    are logged at the debug level and messages with a '*' prefix are logged
    at the info level.
Signed-off-by: Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
2005-05-17 10:50:52 +00:00
iap10@firebug.cl.cam.ac.uk 6b55919bfa bitkeeper revision 1.1236.1.94 (423d8424xa3IjKUn_8z0s4Bbep3LKA)
Trivial nits in the network-nat script..
signed-off by Nivedita Singhvi (niv@us.ibm.com)
2005-03-20 14:09:40 +00:00
iap10@labyrinth.cl.cam.ac.uk 744d0bbffb bitkeeper revision 1.1159.223.53 (41fc0c19tGe1rM62SUQk8WYZjH-D1Q)
Add iptables modules to the default xen0 kernel, and add example configuration files for a NAT setup.
2005-01-29 22:20:09 +00:00