arp querier/responder for multiple ip addrs on multiple networks using the same interface

[Eric Freudenthal]

For our application, we need to build a router between multiple networks
that are transported on the same media.  Up till now, after filtering etc.,
we've been passing all packets to linux for forwarding (thus letting linux
handle arp).  However, we've seen inconsistent latency - varying wildly
between 10 and 100+ms when the traffic is just one host sending 1 ping per
second. The ping transport latency only seems to be unstable for large click
configs like the one I wrote about earlier.  As I indicated in a previous
note, we are considering moving the full router implementation (including
arp) into click.

For our application, the same network interface will clearly need to have
multiple ip address, each on another net.  I scanned the click doc, and it
appears that arpResponder and arpQuerier don' know about multiple
ipaddr/nets.

The only solution I see is pretty ugly: I would create an arpResponder &
arpQueryer for each address, and route incoming arp packets by their ip addr
field  to the appropriate responder/queryer using Classifiers.

Are we barking up the wrong tree?  If not, does this seem like a good
approach?

Thanks, Eric

Eric Freudenthal  // Courant Institute // New York University
719 Broadway, Room 712 // New York, NY // 10003
office: 212-998-3345 // cell: 917-279-6208

-----Original Message-----
From: Eric Freudenthal [mailto:eric.freudenthal at nyu.edu]
Sent: Thursday, February 28, 2002 6:10 PM
To: click at amsterdam.lcs.mit.edu
Subject: RE: (RESEND w/ correct reply-to) click bug report (help needed)

Thanks Eddie.  We now see the proper number of /proc files.  However, this
config runs far slower than expected (varied ping forwarding latencies on an
otherwise unloaded system of 10-200ms).

Please advise if we're doing something inappropriate:

We want to emulate a system of multiple networks that are all slower than
Ethernet.  The idea is that we build simulated network & inter-network link
emulators using classifiers for inter-simulated-net routing.  When a packet
is rec'd from the real network interface, a click Classifier selects by src
addr the appropriate simulated network emulator chain that imposes latency &
bw restrictions.   Whenever a packet leaves a simulated network chain, it is
routed via a Classifer (by dst addr), either back to the appropriate network
interface (via ToLinux) or to another bw/latency chain that terminates in
another click-simulated network emulator chain.

Each of the click-simulated network emulator chains & inter-network link
chains is implemented as a chain with inputs & outputs either attached to
classifiers or other chains:

in_dcc_dce :: Queue(256)
 -> in_dcc_dce_RATE :: BandwidthShaper(100000000)
 -> SetTimestamp
 -> out_in_dcc_dce :: DelayUnqueue(0.001000s);

We let linux handle arp & packet forwarding to the appropriate interface?
We could implement the entire router in click (mostly we'd need to add arp
handling), but thought that linux's forwarding would be fine.  Is this a
likely cause for our troubles?

Thanks, Eric

Eric Freudenthal  // Courant Institute // New York University
719 Broadway, Room 712 // New York, NY // 10003
office: 212-998-3345 // cell: 917-279-6208

-----Original Message-----
From: Eddie Kohler [mailto:kohler at icir.org]
Sent: Thursday, February 28, 2002 3:52 PM
To: eric.freudenthal at nyu.edu; taozhao at cs.nyu.edu
Cc: click at amsterdam.lcs.mit.edu
Subject: Re: (RESEND w/ correct reply-to) click bug report (help needed)

I gave Tao a call. FYI for others:

> Also: when this config is installed, click requires 260k of memory,
> which kmalloc() is unable to fulfill.  We hacked our kernel to support
> this.  Any reason to not use vmalloc() instead?

vmalloc() is inappropriate for small objects, since it uses at least one
page per memory request. But the vmalloc/kmalloc thing is an issue we might
address in future releases.

> the following click config file misbehaves on our system.  It contains
> about 200 counters, all named with the suffix  _counter.  Only 56 of
> them seem to be visible in our proc file system, and the behavior of
> the resulting system is pretty screwy.

The way to fix this is to increase the value of the PROC_NDYNAMIC symbol in
LINUXDIR/include/linux/proc_fs.h . It limits the number of /proc files that
are allowed.

Eddie