Sven Hirsch: More click router problems

Tue Jun 19 14:35:09 EDT 2001

------- Forwarded Message

Return-Path: hirschs at gmx.de
Delivery-Date: Tue Jun 12 07:18:02 2001
Return-Path: <hirschs at gmx.de>
Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14])
	by coyote.aciri.org (8.11.3/8.11.1) with ESMTP id f5CEI1Z38143
	for <kohler at coyote.aciri.org>; Tue, 12 Jun 2001 07:18:01 -0700 (PDT)
	(envelope-from hirschs at gmx.de)
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
	by wyvern.aciri.org (8.11.3/8.11.1) with SMTP id f5CEHxC61478
	for <kohler at aciri.org>; Tue, 12 Jun 2001 07:17:59 -0700 (PDT)
	(envelope-from hirschs at gmx.de)
Received: (qmail 9466 invoked by uid 0); 12 Jun 2001 14:17:53 -0000
Date: Tue, 12 Jun 2001 16:17:53 +0200 (MEST)
From: Sven Hirsch <hirschs at gmx.de>
To: kohler at aciri.org
Cc: kaden at fh-konstanz.de
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="========GMXBoundary16270992355473"
Subject: More click router problems
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0002257875 at gmx.net
X-Authenticated-IP: [141.37.34.7]
Message-ID: <16270.992355473 at www15.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001

This is a MIME encapsulated multipart message -
please use a MIME-compliant e-mail program to open it.

Dies ist eine mehrteilige Nachricht im MIME-Format -
bitte verwenden Sie zum Lesen ein MIME-konformes Mailprogramm.

- --========GMXBoundary16270992355473
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Eddie

We carried on with our work with click-router version 1.1 and the problems
we first contacted you about didn't appear again. But unfortunately more and
more other problems and questions arised.

Maybe we should give you a quick overview of what our goals are. We want to
build a testbed for quality of service. Because we are in a university and  
hardware resources are limited in the lab we are working, we thought to
'build' a huge network with just four computers. Each of the machines is equiped
with a 802.1q capable network card and we have two switches with 26 ports
each. By using the VLAN-technology we are able to set up several interfaces on
each computer and to use the ports of the switches as ports of the computers.
On each machine shall run several instances of the click router to simulate
the single routers in a real network.

In our first experiment we used one computer to run the click-router and two
others as hosts.

[1] The first problem we encountered was to remove the additional four
octets of the vlan tag between the mac and ip header. We first used the
Strip-Element which we still use to remove the mac header but which for some strange
reason failed when removing the vlan tags. We hacked the code in
/elements/userlevel/fromdevice.cc and it worked fine.

We could ping successfully from one host to the other and other applications
like ftp worked as well.

[2] Then we extended the topology and added a forth machine with another
click-router running. We realized that to each arp request we got two arp
responds. We think that one of the responds are generated by the linux
kernel and so we removed the arpresponder from the click-router. This solved it.

[3] Again we could ping from one host to another.  But when pinging to the
interface of an router we got strange behaviour again. The router tried to
resolve its own ip address and didn't got an answer. We found the
ICMPPingResponder and tried to add it to the click router. As you can see in
the attached config file the router is build as described in your thesis. To

add the ICMPPingResponder we thought to catch the packets which leave the
LookupIPRoute-Element at the 'toLinux' exit. [BTW we are confused about the
role the kernel is playing in a userlevel router. All the papers we have  
concentrate on the kernel module. Are there any papers about the interaction
between these two parts?]

As you can see we classify this packets and put echo requests into the
ICMPPingResponder. As expected it flips the source and dest address and sets
the echo respond flag. A surprise for us was that put back into the
LookupIPRoute-Element the packet was treated like no address-flipping
occured.
It was again released through the 'toLinux' exit and there dropped by our
classifier because the echo request flag was cleared.

Where do we have to place the PingResponder and what use is the 'toLinux'
exit in the userlevel router???

Hope you can help...

Torsten
Sven
Niko

- -- 
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a

- --
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
- --========GMXBoundary16270992355473
Content-Type: text/plain; name="conf.click"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="conf.click"

Ly8gdmxhbjAwMDQgMTAuNC4wLjI1NCAwMDowMTowMjpBRTo1Nzo5MQovLyB2bGFuMDAwNSAxMC41
LjAuMjU0IDAwOjAxOjAyOkFFOjU3OjkxCgoKLy8gUm91dGluZyB0YWJsZSB3aXRoIHN0YXRpYyBy
b3V0aW5nIGluZm9ybWF0aW9uIChTdWJuZXQvTWFzayBPdXRwdXQpCi8vIE91dHB1dCBtZWFucyB0
aGUgaW5kZXggb2YgdGhlIG1vZHVsZSBvdXRwdXQuCnJ0IDo6IExvb2t1cElQUm91dGUoCiAxMC40
LjAuMjU0LzMyIAkwLAogMTAuNS4wLjI1NC8zMiAJMCwKIDEwLjQuMC4wLzE2IAkxLAogMTAuNS4w
LjAvMTYgCTIsCiAwLjAuMC4wLzMyIAkwICk7CgoKLy8qKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCi8vKiAgICAgICAgICAgICAgICBTSEFS
RUQgSVAgSEFORExJTkcgQlJBTkNICQkgICAqCi8vKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgoKLy8gZHJvcHMgdGhlIE1BQy1IZWFkZXIg
YW5kIGNoZWNrcyB0aGUgSVAtSGVhZGVyCmlwIDo6IFN0cmlwKDE0KQogICAgICAtPiBDaGVja0lQ
SGVhZGVyKDEwLjQuMjU1LjI1NSAxMC41LjI1NS4yNTUpIAogICAgICAtPiBHZXRJUEFkZHJlc3Mo
MTYpCiAgICAgIC0+IE1hcmtJUEhlYWRlcigpCiAgICAgIC0+IFswXXJ0OwoKCi8vKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgovLyoJCSAg
IENPTkZJR1VSQVRJT04gT0YgREVWSUNFIDEJCSAgICoKLy8qKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCgovLyB0aGUgcGFja2V0cyBhcmUg
Y2xhc3NpZmllZCBhcyBhcnAgcXVlcnkgKDApLCBhcnAgcmVzcG9uc2UgKDEpLAovLyBpcCBwYWNr
ZXQgKDIpIG9yIGFueXRoaW5nIGVsc2UgKDMpCmNsYTEgOjogQ2xhc3NpZmllcigKIDEyLzA4MDYg
MjAvMDAwMSwKIDEyLzA4MDYgMjAvMDAwMiwKIDEyLzA4MDAsCiAtKTsKCi8vIHRoZSBvdXRwdXQg
cXVldWUgb2YgZGV2aWNlIDEKb3V0MSA6OiBRdWV1ZSgyMDApIAoJLT4gUHJpbnQob3V0MSwgNTAp
IAoJLT4gdG9kZXZpY2UxIDo6IFRvRGV2aWNlKHZsYW4wMDA0KTsKCi8vIHRoZSBhcnAgcmVzcG9u
ZGVyIHJlc3BvbnNpYmxlIGZvciBkZXZpY2UgMQphcjEgOjogQVJQUmVzcG9uZGVyKDEwLjQuMC4y
NTQgMDA6MDE6MDI6QUU6NTc6OTEpOwovLyB0aGUgYXJwIHF1ZXJpZXIgcmVzcG9uc2libGUgZm9y
IGRldmljZSAxCmFycHExIDo6IEFSUFF1ZXJpZXIoMTAuNC4wLjI1NCwgMDA6MDE6MDI6QUU6NTc6
OTEpOwoKLy8gdGhlIGlwIHBhY2tldHMgYXJlIGNsYXNzaWZpZWQgYXMgZWNobyByZXF1ZXN0ICgw
KSBvcgovLyBhbnl0aGluZyBlbHNlICgxKQpjaXAgOjogQ2xhc3NpZmllcigKIDIwLzA4LAogLSk7
CgovLyBlY2hvIHJlcXVlc3RzIGFyZSBoYW5kbGVkIGJ5IHRoZSBwaW5nIHJlc3BvbmRlcgpjaXBb
MF0gLT4gUHJpbnQoYmVmbywgNDApCiAgICAgICAtPiBJQ01QUGluZ1Jlc3BvbmRlcigpCiAgICAg
ICAtPiBQcmludChhZnRlLCA0MCkKICAgICAgIC0+IFswXXJ0OwovLyAgICAgLT4gWzBdYXJwcTE7
CgovLyBvdGhlciBwYWNrZXRzIGFyZSBkaXNjYXJkZWQKY2lwWzFdIC0+IFByaW50KFJfZmFpbCkg
LT4gRGlzY2FyZDsKCi8vIHRoZSByb3V0ZXIgYnJhbmNoIG9mIHRoZSBkZXZpY2UgMQoKLy8gZ2V0
cyBwYWNrZXRzIGZyb20gdGhlIGRldmljZSBhbmQgY2xhc3NpZmllcyB0aGVtCkZyb21EZXZpY2Uo
dmxhbjAwMDQpIC0+IFswXWNsYTE7Ci8vIGFycCBxdWVyaWVzIGFyZSBoYW5kbGVkIGJ5IHRoZSBh
cnAgcmVzcG9uZGVyCmNsYTFbMF0gLT4gYXIxIC0+IG91dDE7Ci8vIGFycCByZXNwb25kcyBhcmUg
aGFuZGxlZCBieSB0aGUgYXJwIHF1ZXJpZXIKY2xhMVsxXSAtPiBbMV1hcnBxMSAtPiBvdXQxOwov
LyBpcCBwYWNrZXRzIGFyZSBwYWludGVkIGFuZCBmb3J3YXJkZWQgdG8gdGhlCi8vIGlwIHBhY2tl
dCBoYW5kbGluZyBicmFuY2gKY2xhMVsyXSAtPiBQYWludCgxKSAtPiBpcDsKLy8gb3RoZXIgcGFj
a2V0cyBhcmUgZGlzY2FyZGVkCmNsYTFbM10gLT4gUHJpbnQoIERST1AsIDApIC0+IERpc2NhcmQ7
CgoKLy8gaXAgcGFja2V0IGNvbnRyb2wgYnJhbmNoCgovLyBicm9hZGNhc3RzIGFyZSBub3QgZm9y
d2FyZGVkIGludG8gb3RoZXIgc3VibmV0cwpydFsxXSAtPiBEcm9wQnJvYWRjYXN0cwogICAgICAt
PiBjcDEgOjogUGFpbnRUZWUoMSkKICAgICAgLT4gZ2lvMSA6OiBJUEdXT3B0aW9ucygxMC40LjAu
MjU0KQogICAgICAtPiBGaXhJUFNyYygxMC40LjAuMjU0KQogICAgICAtPiBkdDEgOjogRGVjSVBU
VEwKICAgICAgLT4gZnIxIDo6IElQRnJhZ21lbnRlcigxNDk2KQogICAgICAtPiBbMF1hcnBxMTsK
Ci8vIHBhY2tldHMgZm9yIHRoZSByb3V0ZXIgYXJlIGhhbmRlbGQgaGVyZQpydFswXSAtPiBQcmlu
dChJQ01QLCA1MCkgLT4gWzBdY2lwOwoKCi8vIGljbXAgbWVzc2FnZSBnZW5lcmF0aW9uCgovLyBo
YW5kbGUgcmVkaXJlY3QgZXJyb3JzCmNwMVsxXSAtPiBJQ01QRXJyb3IoMTAuNC4wLjI1NCwgNSwg
MSkgLT4gWzBdcnQ7Ci8vIGhhbmRsZSBiYWQgaXAgcGFyYW1ldGVyCmdpbzFbMV0gLT4gSUNNUEVy
cm9yKDEwLjQuMC4yNTQsIDEyLCAxKSAtPiBbMF1ydDsKLy8gaGFuZGxlIHRpbWUgdG8gbGl2ZSBl
cnJvcnMKZHQxWzFdIC0+IElDTVBFcnJvcigxMC40LjAuMjU0LCAxMSwgMCkgLT4gWzBdcnQ7Ci8v
IGhhbmRsZSBmcmFnbWVudGF0aW9uIGVycm9ycwpmcjFbMV0gLT4gSUNNUEVycm9yKDEwLjQuMC4y
NTQsIDMsIDQpIC0+IFswXXJ0OwoKCi8vCi8vIGNvbmZpZ3VyYXRpb24gb2YgZGV2aWNlIDIKLy8K
YzIgOjogQ2xhc3NpZmllcigxMi8wODA2IDIwLzAwMDEsCiAgICAgICAgICAgICAgICAgIDEyLzA4
MDYgMjAvMDAwMiwKCQkgIDEyLzA4MDAsCgkJICAtKTsKb3V0Mjo6IFF1ZXVlKDIwMCkgLT4gUHJp
bnQob3V0MiwgNTApIC0+IHRvZGV2aWNlMiA6OiBUb0RldmljZSh2bGFuMDAwNSk7CmFycHEyIDo6
IEFSUFF1ZXJpZXIoMTAuNS4wLjI1NCwgMDA6MDE6MDI6QUU6NTc6OTEpOwphcjIgOjogQVJQUmVz
cG9uZGVyKDEwLjUuMC4yNTQgMDA6MDE6MDI6QUU6NTc6OTEpOwoKRnJvbURldmljZSh2bGFuMDAw
NSkgLT4gWzBdYzI7CmMyWzBdIC0+IGFyMiAtPiBvdXQyOwpjMlsxXSAtPiBbMV1hcnBxMjsKYzJb
Ml0gLT4gUGFpbnQoMikgLT4gaXA7CmFycHEyWzBdIC0+IG91dDI7CgpydFsyXSAgLT4gRHJvcEJy
b2FkY2FzdHMKICAgICAgICAtPiBjcDIgOjogUGFpbnRUZWUoMikKICAgICAgICAtPiBnaW8yIDo6
IElQR1dPcHRpb25zKDEwLjUuMC4yNTQpCiAgICAgICAgLT4gRml4SVBTcmMoMTAuNS4wLjI1NCkK
ICAgICAgICAtPiBkdDIgOjogRGVjSVBUVEwKICAgICAgICAtPiBmcjIgOjogSVBGcmFnbWVudGVy
KDE0OTYpCiAgICAgICAgLT4gWzBdYXJwcTI7CgpkdDJbMV0gLT4gSUNNUEVycm9yKDEwLjUuMC4y
NTQsIDExLCAwKSAtPiBbMF1ydDsKZnIyWzFdIC0+IElDTVBFcnJvcigxMC41LjAuMjU0LCAzLCA0
KSAtPiBbMF1ydDsKZ2lvMlsxXSAtPiBJQ01QRXJyb3IoMTAuNS4wLjI1NCwgMTIsIDEpIC0+IFsw
XXJ0OwpjcDJbMV0gLT4gSUNNUEVycm9yKDEwLjUuMC4yNTQsIDUsIDEpIC0+IFswXXJ0OwpjMlsz
XSAtPiBQcmludCh4eDIpIC0+IERpc2NhcmQ7Cgo=

- --========GMXBoundary16270992355473--

------- End of Forwarded Message