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
