weird routing question

Jeffrey Ross jeff at bubble.org
Wed Nov 22 19:40:34 UTC 2006



fedora wrote:
> Andy Green wrote:
>> fedora wrote:
>>
>>> 10.XX.70.0   0.0.0.0    255.255.255.0     U       0       0      0  
>>> eth1
>>
>>> */# route del -net 10.XX.70.0 netmask 255.255.255.0 gw 10.XX.70.1 eth1 
>>
>> You don't need the gateway stuff, it is not on the line you want to 
>> delete.  Without the gateway part it should work.
>>
>>> SIOCDELRT: No such process/*
>>>
>>> Can anyone help me understand what I am doing wrong on the route del 
>>> command and also if it looks like I am moving in the right direction 
>>> to remove the latency issue?
>>
>> Latencies are very often DNS problems of some sort.  Check the 
>> /etc/resolv.conf nameservers, and do a dig on them by hand from the 
>> box in question
>>
>> dig google.com @ my.first.nameserver.ip
>>
>> and see what the latencies are like.  If the latencies are good, try a
>>
>> tcpdump -i eth1 port 53 -s0 -X
>>
>> and try to cause the delay, maybe you can get a clue.
>>
>> -Andy
>>
> Interesting - when I run tcpdump and try to connect on port 143 (IMAP 
> port) it shows the immediate connection to that specific port - in 
> other words, no latency on the server end - it appears to be on the 
> way back to the desktop to complete the connection that the latency 
> comes into play.  Here's what is interesting - when I kill the tcpdump 
> it shows the following:
> 392 packets received by filter
> 299 packets dropped by kernel
> I only ran this for approximately 30 seconds on our live system and 
> only about three or four users' computers connected during this 
> session.  Your thoughts - anyone.
> Doug
>
You're providing less than 1/2 the picture the number of packets 
received tells me nothing without knowing where they are going, where 
they are coming from and what else might be going on.

what do the dns queries show?  I'd suggest "tcpdump -i eth1 port 53 -s0 
-w/tmp/output.cap" and view the resulting data with wireshark.

You might want to go one step further and take a client machine that is 
exhibiting the problem and do the following:
"tcpdump -i eth1 -s0 \( host X.X.X.X and port 143 \) or port 53 -w 
/tmp/output.cap" 

What this will do assuming I got the syntax correct is capture any 
traffic from the (client) host at X.X.X.X to and from port 143 and any 
DNS traffic.  Afterwards you can review everything in wireshark 
(formally ethereal) and possibly get a better idea of what's going on.

Jeff




More information about the users mailing list