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

Fri Mar 1 08:19:50 EST 2002

Hi Eric,

I'm not sure if this can fully solve your problem, but in the
documentation of arpresponder I see

 * ARPResponder(IP/MASK1 [IP/MASK...] ETH1, IP/MASK2 ETH2, ...)
 *
 * =s Ethernet
 *
 * generates responses to ARP queries
 *
 * =d
 *
 * Input should be ARP request packets, including the Ethernet header.
 * Forwards an ARP reply if we know the answer -- that is, if one of the
 * IPPREFIX arguments matches the requested IP address, then it outputs
an ARP
 * reply giving the corresponding ETH address. Could be used for proxy
ARP as
 * well as producing replies for a host's own address.
 *
 * The IP/MASK arguments are IP network addresses (IP address/netmask
pairs).
 * The netmask can be specified in CIDR form (`C<18.26.7.0/24>') or
dotted
 * decimal form (`C<18.26.7.0/255.255.255.0>').
 *
 * ARPResponder sets the device annotations on generated ARP responses
to the
 * device annotations from the corresponding queries.
 *
 * =n
 *
 * AddressInfo elements can simplify the arguments to ARPResponder. In
 * particular, if C<NAME> is shorthand for both an IP network address
(or IP
 * address) C<IP> and an Ethernet address C<ETH>, then
C<ARPResponder(NAME)> is
 * equivalent to C<ARPResponder(IP ETH)>. If C<NAME> is short for both
an IP
 * address and an IP network address, then ARPResponder will prefer the
IP
 * address. (You can say C<NAME:ipnet> to use the IP network address.)
 *
 * =e
 *
 * Produce ARP replies for the local machine (18.26.4.24)
 * as well as proxy ARP for all machines on net 18.26.7
 * directing their packets to the local machine:
 *
 *   c :: Classifier(12/0806 20/0001, ...);
 *   ar :: ARPResponder(18.26.4.24 18.26.7.0/24 00:00:C0:AE:67:EF);
 *   c[0] -> ar;
 *   ar ->
ToDevice(eth0);                                                                                                        

so here I see that ARPResponder can answer on different arp requests and
even with network masks.

For ARPQuerier, you could indeed add more elements  or write easily your
own element. I don't know exactly which config you have in mind for this
(now you seem to send everything to ToLinux) but I'm not very sure if
the IP address in ARPQuerier is effectively needed (basically you ask
for the MAC address of a destination IP address but your own IP address
doesn't play any role in this if the destination answers the ARP to the
source MAC address, these aren't IP packets, but not sure on this...).
You could do some tests with this.

e.g. with tcpdump
08:13:01.627766 0:a0:24:51:64:32 0:50:ba:c3:6a:0 0806 60: arp who-has
10.10.10.100 tell 10.10.10.12
08:13:01.627793 0:50:ba:c3:6a:0 0:a0:24:51:64:32 0806 42: arp reply
10.10.10.100 is-at 0:50:ba:c3:6a:0

you see in the arpreply from the other computer, the asking IP address
(10.10.10.12) doesn't play any role, except if the destination system
would have used its arptable to turn 10.10.10.12 in 0:a0:24:51:64:32. I
don't know if they do that or if they just use the sending MAC address.
(you can e.g. start with looking at arpresponder to see what click does
:-) ).

I'm just doing some brainstorming :-), so I'm not responsible for any
huge problems :-).

regards,
Brecht

Eric Freudenthal wrote:
> 
> 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