[Click] Not routing via Click

Douglas S. J. De Couto decouto at csail.mit.edu
Wed Mar 3 13:51:12 EST 2004


> Thanks for your quick response. I tried running tcpdump on my wireless
> interface on all the machines (tcpdump -i eth1). Then I try pinging 
> again
> from A to D
>
> On all the nodes that A sees (B and C), its dumping an:
>
>> arp who-has D tell A
>
> with D and A replaced with their actual IP addresses.

This indicates that your ping is not actually travelling through the 
Grid protocol stack, and is instead using the regular Linux IP stack.  
Because Grid encapsulates the data packets in its own protocol, you 
should have seen unicast packets with the grid ethertype 0x7fff.

Check that you are using a different IP address for the Grid protocol 
than your interface is configured for, that way Linux will know to send 
outgoing packets to Grid instead of directly to the interface.

> There's also random grid packets (0x7fff) being broadcasted from time 
> to
> time.

That's normal, its the route broadcasts.

> Does thie mean that its not actually following the DSDVRouteTable ? Do 
> I
> need to set forwarding on any of the nodes to "1"
> (/proc/sys/net/ipv4/ip_forward) ?

No.  Grid does not use Linux routing tables.

> On Wed, 3 Mar 2004, Douglas S. J. De Couto wrote:
>
>> Your tun/tap setup is probably fine, since adjacent nodes have routes
>> to each other.  That means userlevel click is able to send and receive
>> packets to and from the interface.
>>
>> When you ping from A to D over the two-hop route, e.g. A-C-D, can you
>> verify the following by using tcpdump on the actual interface (eth0 or
>> whatever)?:
>>
>> - A is actually transmitting the outgoing ping packet, with C's
>> ethernet address as the destination
>> - C receives the outgoing ping packet
>> - C transmits the outgoing ping packet, with D's ethernet address as
>> the destination
>> - D receives the outgoing ping packet
>>
>> also, do the same for the ping responses from D to A.  The key is to
>> see where the packet is lost.  It may not be getting routed, or D may
>> not be sending the incoming ping to the kernel, therefore no ping
>> response.  Or, the ping response might be getting lost.
>>
>> d
>>
>>
>>> I'm currently running Click in USERLEVEL with the GRID extensions. I
>>> setup
>>> the DSDVroute table as it says on the webpage:
>>>
>>> http://www.pdos.lcs.mit.edu/grid/software.html
>>>
>>> and the nodes seem to be finding each other. The actual routing table
>>> itself is setting up quite nicely with no problems.
>>>
>>> However, it doesn't seem like Click is really doing any of the
>>> forwarding.
>>>
>>> For example, we have 4 nodes: A, B, C, D
>>>
>>> General Setup:
>>> Node A can ping B and C, but NOT D
>>> Nodes B and C both can ping D AND A
>>>
>>> After setting DSDV up utilizing the perl script
>>> /conf/make-dsdv-config.pl:
>>>
>>> The route table for A says it can reach B and C in 1 hop and D in 2
>>> hops.
>>> Looks good so far.
>>>
>>> However, when I try pinging D from A, it still says the host is
>>> "unreachable".
>>>
>> --
>> Douglas S. J. De Couto    <decouto at csail.mit.edu>
>>
>
> -- 
> Bow-Nan Cheng
> Senior Web Developer
> Nanwob Solutions
> Email: bcheng at nanwob.net
> Mobile: (201) 563-3875
> http://www.nanwob.net
>
>
--
Douglas S. J. De Couto    <decouto at csail.mit.edu>



More information about the click mailing list