Tests in der internen Testumgebung

  Bei den ersten Versuchen, mit MIP-Version 1.0 die eigene Testumgebung in Betrieb zu nehmen, fielen vor allem Implementierungsfehler auf. So funktionierte die Registrierung des Mobile Node im fremden Netz nur dann, wenn auf dem MN gleichzeitig ein tcpdump-Prozeß lief, der das Netzinterface in den ,,promiscous mode`` versetzte und damit für Ethernet-Pakete, die an andere Interfaces adressiert waren, empfänglich machte. Der promiscous mode läßt sich auch mit ifconfig eth0 promisc einschalten. Dies war in den Folgeversionen nicht mehr notwendig.

Applikationsverbindungen wie telnet wurden beim Umstecken des MN vom Heimatnetz ins fremde Netz oder umgekehrt abgebrochen. Beim Umstecken vom fremden Netz ins Heimatnetz mußte zusätzlich der MIP-Daemon des MN neu gestartet werden (nip restart), da der Daemon den Routingeintrag zum Foreign Agent nicht löschte und auch die ursprüngliche Defaultroute nicht wieder herstellte. Dies trat ab Version 1.1 nicht mehr auf.

In MIP-Version 1.2 hat Thomas Lopatic (Uni München) die Option ,,bidirektionales Tunneling`` nach [MON96] eingebaut. Sie soll dafür sorgen, daß IP-Pakete, die vom Mobile Node kommen, denselben Weg über einen Tunnel zwischen Foreign Agent und Home Agent nehmen, wie Pakete, die an den MN gesendet werden. In [PER96], das der verwendeten MIP-Implementierung zu Grunde liegt, ist dagegen vorgesehen, daß der MN Pakete auf normalem Wege ohne Tunnel versendet.

Beim Betrieb in der internen Testumgebung hat dies keine praktische Bedeutung, im Gegensatz zum Betrieb im realen Internet, wie die Tests mit den Partnern in Bristol zeigten (siehe Abschnitt ). Ein ping vom MN auf beliebige andere Rechner innerhalb oder außerhalb des Universitätsnetzes außer dem HA funktionierte, egal ob ,,bidirektionales Tunneling`` eingeschaltet war oder nicht. Allerdings scheinen in der Implementierung noch Fehler vorzuliegen, denn die Antwortpakete wurden meistens am FA dupliziert. Ein ping vom MN auf zeus.cip ergibt:

PING 129.187.214.129 (129.187.214.129): 56 data bytes
64 bytes from 129.187.214.129: icmp_seq=0 ttl=253 time=13.3 ms
64 bytes from 129.187.214.129: icmp_seq=0 ttl=253 time=16.8 ms (DUP!)
64 bytes from 129.187.214.129: icmp_seq=1 ttl=253 time=19.0 ms
64 bytes from 129.187.214.129: icmp_seq=1 ttl=253 time=20.6 ms (DUP!)
64 bytes from 129.187.214.129: icmp_seq=2 ttl=253 time=19.0 ms
64 bytes from 129.187.214.129: icmp_seq=2 ttl=253 time=20.7 ms (DUP!)
64 bytes from 129.187.214.129: icmp_seq=3 ttl=253 time=22.0 ms
64 bytes from 129.187.214.129: icmp_seq=3 ttl=253 time=23.5 ms (DUP!)
64 bytes from 129.187.214.129: icmp_seq=4 ttl=253 time=11.8 ms
64 bytes from 129.187.214.129: icmp_seq=4 ttl=253 time=22.6 ms (DUP!)

--- 129.187.214.129 ping statistics ---
5 packets transmitted, 5 packets received, +5 duplicates, 0% packet loss

Ein tcpdump auf dem FA zeigt:

10:18:40.738687 pchegering4.nm.informatik.uni-muenchen.de > \
  zeus.cip.informatik.uni-muenchen.de: icmp: echo request
10:18:40.748687 zeus.cip.informatik.uni-muenchen.de > \
  pchegering4.nm.informatik.uni-muenchen.de: icmp: echo reply
10:18:40.748687 zeus.cip.informatik.uni-muenchen.de > \
  pchegering4.nm.informatik.uni-muenchen.de: icmp: echo reply

Ein weiterer Fehler wurde mit Version 1.2 offenbar neu eingeführt: Verbindungen zwischen MN und HA kamen in den Versionen 1.0 und 1.1 zustande, in Version 1.2 nicht. Ein ping-Test vom HA zum MN ergab, nur das erste Paket wurde beantwortet, bei aktivem bidirektionalem Tunnel dupliziert, danach kamen keine Antworten mehr an, bis die Registrierung erneuert wurde. Die Registrierung kam aber nicht zustande, wenn der ping nicht abgebrochen wurde.

Hier die Registrierungsmeldungen des HA:

pchegering2(robert):~ % cat /proc/net/mip_dev 
Address         FA  HA  Busy Adv-interval Lifetime NextSeqno
129.187.214.42  Yes Yes No              1      255       231

pchegering2(robert):~ % cat /proc/net/mip_reg 
Type UsrRef Regno State Home addr       HA addr         Care-of addr    \\
HA   1      10    4     129.187.214.44  129.187.214.42  192.168.214.109 \\

Registration ID   Lifetime MNport RCT36 Bcast Bi-Tunnel
00000015-B81AFF31      120    434     2 No    Yes

Das erste, duplizierte Paket:

pchegering2:~# ping 129.187.214.44
PING 129.187.214.44 (129.187.214.44): 56 data bytes
64 bytes from 129.187.214.44: icmp_seq=0 ttl=63 time=13.4 ms
64 bytes from 129.187.214.44: icmp_seq=0 ttl=63 time=14.5 ms (DUP!)

Auf dem umgekehrten Weg, einem ping vom MN zum HA, zeigt tcpdump auf dem HA duplizierte Antwortpakete:

11:46:40.346313 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request
11:46:40.346313 pchegering2.nm.informatik.uni-muenchen.de > \
  pchegering4.nm.informatik.uni-muenchen.de: icmp: echo reply
11:46:41.206313 pchegering2.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]
11:46:41.346313 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request
11:46:41.346313 pchegering2.nm.informatik.uni-muenchen.de > \
  pchegering4.nm.informatik.uni-muenchen.de: icmp: echo reply
11:46:41.346313 pchegering2.nm.informatik.uni-muenchen.de > \
  pchegering4.nm.informatik.uni-muenchen.de: icmp: echo reply
11:46:42.206313 pchegering2.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]

die im FA verlorengegangen sind:

10:26:34.308687 pchegering9.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]
10:26:34.978687 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request
10:26:35.308687 pchegering9.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]
10:26:35.978687 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request

Ist bidirektionales Tunneling nicht eingeschaltet, wird die Antwort nicht dupliziert:

pchegering4:~# ping 129.187.214.42
PING 129.187.214.42 (129.187.214.42): 56 data bytes
64 bytes from 129.187.214.42: icmp_seq=0 ttl=62 time=11.0 ms

aber der HA antwortet nicht:

21:26:21.223269 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request
21:26:21.793269 pchegering2.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]
21:26:22.213269 pchegering4.nm.informatik.uni-muenchen.de > \
  pchegering2.nm.informatik.uni-muenchen.de: icmp: echo request
21:26:22.793269 pchegering2.nm.informatik.uni-muenchen.de > \
  255.255.255.255: icmp: type-#9 [tos 0x10] [ttl 1]

Der Autor der MIP-Software, Yunzhou Li, hat bei eigenen Tests keine Beobachtungen dieser Art gemacht. Eine Lösung, evtl. mit der nächsten MIP-Version, steht noch aus.