ZCIP Intallation

This discusses the first part of IPv4LinkLocalInstallation.

For IPv4LL, I recommend to use the zcip package. The author removed the download from http://zeroconf.sourceforge.net/?∞, due to Apple patent claims. However, these are not an issue. The IETF received three patent claims: two by Apple, one by Microsoft. Apple's patents have expired, and Microsoft clearly states that they grant royalty-free licences when it is adopted as a standard. The technology implemented by zcip is described in RFC 3927, so it is a standard, and there are no patent issues, as far as anyone is aware.

However it is still available from source as the Debian package: http://packages.debian.org/testing/source/zcip∞

Requirements

libnet 1.0.x is needed: http://www.packetfactory.net/libnet∞
Note that libnet 1.1.x is not compatible and should not be used.

For Debian:



For other distributions, compile by source:



Installed files are:

Local problems Chicago

Libnet-1.0.2a installation:
Installation was done from source using the procedure mentioned above.

For Suse 9.2 on Opteron(Prier)
We had some compile errors due the comment style used in libnet.h( lines 87-89). This was easily fixed.
We had to copy libnet-config to the /usr/bin directory.

For Debian on Itanium (Itanic)
We had to copy libnet-config to the /usr/bin directory.

ZCIP Installation

For Debian:


For other distributions, compile by source:



Do not apply the patch above (gunzip zcip_4-6.diff.gz; patch -d zcip-4 < zcip_4-6.diff). Though it does fix some warnings during compile time, it has some drawbacks (a) the resulting zcip program does give a segmentation fault, and (b)
the patch disables "IFF_MULTICAST". I'm not sure if that's good or bad, but it is something to keep into mind if mDNS (multicast DNS) is used later. I have the impression it is not related (the former is Ethernet multicast, the later IP multicast), but I'm not sure.

Warning: Always specify the interface using "zcip -i eth2" when running zcip, otherwise, it will pick eth0 and the host will not be reachable anymore.

Local problems Chicago

Red Hat Configuration

We should use a ifup-local script (in /sbin/), since this is automatically called as soon as an interface is up. I recommend that this script checks /etc/sysconfig/networking-scripts/local/ and executes the command in a (custom) configuration file there, specific for that interface (e.g. ifup-eth2). That command should be "zcip -i eth2".

Local problems Amsterdam

When eth2 is brought up, a lot of routes used at SC2004 were added. The routes were added by the ifup-local script, which configured all routes listed in /etc/sysconfig/networking-scripts/local/routes-eth2. The config file has been renamed, and this is fixed.

Debian Configuration

A good starting point on how to get it to work is: http://chrismetcalf.net/wiki/index.php/RendezvousForLinuxHacks∞

Network Tests

Test of IP collision avoidance

Setup 1: give vangogh7 the IP that vangogh8 always uses first (since the first try is based on the ethernet address). Then brought up vangogh8, and called zcip:



Result: it works!

Note that vangogh7 always gives an warning when statically configuring 169.254.0.0/16 adresses. However, this does not seem to result in any problems.



Setup 2: Keep vangogh8 up, with 169.254.27.68 as IP address. Then try to bring up vangogh7 with that IP address statically configured:



Result: OK. ZCIP wasn't tested, but at least the network remained stable.


Setup 3: configure vangogh7 with static IP address, and vangogh8 with the same IP address using zcip. Do NOT yet connect the links. Then, using the Calient OXC, connect the two links together:

Configuring interfaces:



Bringing up link does not result in anything. Apparently, since no traffic is sent, the hosts don't see each other, and thus don't detect a collision. Pinging a non-existant host on the link-local subnet from vangogh7 did result in action on vangogh8:




Result: it does work, but only after another hosts sends traffic, the host with zcip will detect the errourness situation and correct it. This seem good behaviour.


Setup 4: Two machines with zcip (to be filled in)


Setup 5: Setup 1 Using zeroconf instead of zcip package

zeroconf is a package, maintained at http://www.progsoc.org/~wildfire/zeroconf/∞, based on code by Arthur von Hoff.
zeroconf does not rely on external packages, but uses a script to call the /bin/ip (or /sbin/ip) tool to configure the IP addresses.

Give vangogh7 the IP that vangogh8 always uses first (since the first try is based on the ethernet address). Then brought up vangogh8, and called zcip:

The result of setup 1 is nearly the same with zeroconf as with zcip:


The RTNETLINK error is caused by the fact that zeroconf tries to deconfigure an IP address which wasn't there. It causes no harm.

Setup 6: Setup 3 Using zeroconf instead of zcip package

In here,

configure vangogh7 with static IP address, and vangogh8 with the same IP address using zcip. Do NOT yet connect the links. Then, using the Calient OXC, connect the two links together:

Configuring interfaces:



Bringing up link does not result in anything. At this moment, both vangogh7 (statically) and vangogh8 (uzing zeroconf) have the IP address 169.254.189.149. Pinging the hosts does not result in a response from vangogh8, neither from vangogh6 nor vangogh7:



Even after this traffic was sent, vangogh8 still keeps the 169.254.189.149 IP address. This, despite that zeroconf does seem to detect the conflicting ARP packets:



Note: 00:07:E9:1B:A5:43 is the MAC address of vangogh7, so vangogh8, who has MAC address 00:07:E9:1B:A5:3C but the same source IP 169.254.189.149, should regard this as a conflict. (Section 2.5 of the specification).

Result: zeroconf does not reconfigure after it's initial probe.

Categories

CategoryZeroconf