iptables NAT forwarding adding 75-100ms

I have a strange occurrence of lag on my local networking. I have a
cable modem that plugs into a Debian server, then that Debian server is
plugged into a switch that all other machines in the house connect to.

So something like:

wan0 -> wan
eth0 -> lan

The relevant forwarding/NAT rules are:


#iptables -A FORWARD -i wan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
#iptables -A FORWARD -i eth0 -o wan0 -j ACCEPT

#iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE


So pretty standard boring NAT.

Lag is occurring (between 75ms and 100ms) on all forwarding rules. Apart
from the lag they function fine (no connectivity issues).


Ping: LAN Machine -> Debian Router = ~0.7ms
Ping: Debian Router -> Google = ~20ms
Ping: LAN Machine -> Google = ~121ms !!!


The Debian server has plenty of free RAM, the load is showing as low,
it's (at this time) entirely dedicated to routing - Why is it
introducing 100ms of lag into forwarded traffic???

Anyone else seen similar to this???


I get great speed from LAN machines, just high latency.

~ Mike

On 04/30/2012 12:42 AM, Mike Lovell wrote:
> I have a strange occurrence of lag on my local networking. I have a
> cable modem that plugs into a Debian server, then that Debian server is
> plugged into a switch that all other machines in the house connect to.
>
> So something like:
>
> wan0 -> wan
> eth0 -> lan
>
> The relevant forwarding/NAT rules are:
>
>
> #iptables -A FORWARD -i wan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> #iptables -A FORWARD -i eth0 -o wan0 -j ACCEPT
>
> #iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE
>
>
> So pretty standard boring NAT.

How many FORWARD rules u have?
Do above rules are in beginning of FORWARD chain? If no, please switch
them as far of begin as u can. Is lag time changed?

> Lag is occurring (between 75ms and 100ms) on all forwarding rules. Apart
> from the lag they function fine (no connectivity issues).

How do u check that?

> Ping: LAN Machine -> Debian Router = ~0.7ms
> Ping: Debian Router -> Google = ~20ms
> Ping: LAN Machine -> Google = ~121ms !!!

Wrong! Please 'ping' nearest machine after your router for example your
ISP's gateway or ISP's DNS servers. Please have in mind that your ISP's
router have more important things to do, than respond to ICMP echo
request messages.

> The Debian server has plenty of free RAM, the load is showing as low,
> it's (at this time) entirely dedicated to routing - Why is it
> introducing 100ms of lag into forwarded traffic???

What version of Debian is it?
How much forward traffic u have?

> I get great speed from LAN machines, just high latency.

Do you have some QoS at this machine?

On 04/30/2012 11:06 AM, ein wrote:
>> So pretty standard boring NAT.
>
> How many FORWARD rules u have?
> Do above rules are in beginning of FORWARD chain? If no, please switch
> them as far of begin as u can. Is lag time changed?

I meaned as close of the FORWARD begin as possible.

In comp.os.linux.networking Mike Lovell <(E-Mail Removed)> wrote:
> Ping: LAN Machine -> Debian Router = ~0.7ms
> Ping: Debian Router -> Google = ~20ms
> Ping: LAN Machine -> Google = ~121ms !!!

Are you pinging by name or by address? If it's by name can you please
repeat the tests with IP addresses. (This will eliminate any delay caused
by slow DNS lookups.)

Chris

Chris Davies <chris-(E-Mail Removed)> writes:
> In comp.os.linux.networking Mike Lovell <(E-Mail Removed)> wrote:

>> Ping: LAN Machine -> Debian Router = ~0.7ms
>> Ping: Debian Router -> Google = ~20ms
>> Ping: LAN Machine -> Google = ~121ms !!!
>
> Are you pinging by name or by address? If it's by name can you please
> repeat the tests with IP addresses. (This will eliminate any delay caused
> by slow DNS lookups.)

The time= field in ping output measures the round trip of the ICMP
packet; it doesn't include the DNS lookup.

--
http://www.greenend.org.uk/rjk/

On 04/29/2012 04:42 PM, Mike Lovell wrote:
> I have a strange occurrence of lag on my local networking. I have a
> cable modem that plugs into a Debian server, then that Debian server is
> plugged into a switch that all other machines in the house connect to.
>
> So something like:
>
> wan0 -> wan
> eth0 -> lan
>
> The relevant forwarding/NAT rules are:
>
>
> #iptables -A FORWARD -i wan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
> #iptables -A FORWARD -i eth0 -o wan0 -j ACCEPT
>
> #iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE
>
>
> So pretty standard boring NAT.
>
> Lag is occurring (between 75ms and 100ms) on all forwarding rules. Apart
> from the lag they function fine (no connectivity issues).
>
>
> Ping: LAN Machine -> Debian Router = ~0.7ms
> Ping: Debian Router -> Google = ~20ms
> Ping: LAN Machine -> Google = ~121ms !!!
>
>
> The Debian server has plenty of free RAM, the load is showing as low,
> it's (at this time) entirely dedicated to routing - Why is it
> introducing 100ms of lag into forwarded traffic???
>
> Anyone else seen similar to this???
>
>
> I get great speed from LAN machines, just high latency.
>
> ~ Mike

Bad connection on an RJ-45 connector
between eth0 and LAN switch?

Also, do *not* rely on autosense in
switchers for any crossover/patch cable
detection. If you know it ought to be a
crossover, use a crossover cable.

Alastair

On 2012-04-30, ein <(E-Mail Removed)> wrote:
> How many FORWARD rules u have?
> Do above rules are in beginning of FORWARD chain? If no, please switch
> them as far of begin as u can. Is lag time changed?

Just rules for the NAT, that's it:

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level warning prefix "IPv4-forward "

> How do u check that?
>
>> Ping: LAN Machine -> Debian Router = ~0.7ms
>> Ping: Debian Router -> Google = ~20ms
>> Ping: LAN Machine -> Google = ~121ms !!!
>
> Wrong! Please 'ping' nearest machine after your router for example your
> ISP's gateway or ISP's DNS servers. Please have in mind that your ISP's
> router have more important things to do, than respond to ICMP echo
> request messages.

Interesting, much better:

--- 68.86.118.57 ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9017ms
rtt min/avg/max/mdev = 28.711/57.428/109.753/28.626 ms

>> The Debian server has plenty of free RAM, the load is showing as low,
>> it's (at this time) entirely dedicated to routing - Why is it
>> introducing 100ms of lag into forwarded traffic???
>
> What version of Debian is it?
> How much forward traffic u have?

squeeze

Even if I firewall all other traffic but a single test machine, I still
get the latency problem there.

>> I get great speed from LAN machines, just high latency.
>
> Do you have some QoS at this machine?

No


So, based on the better ping to the next hop after my router, why (how)
would something be distinguishing between the router carrying out the
ping, and something behind the router?

Can I mask it from doing so (if that's the problem)?


Thanks,

~ Mike

On 2012-04-30, Alastair Black <(E-Mail Removed)> wrote:
> Bad connection on an RJ-45 connector
> between eth0 and LAN switch?
>
> Also, do *not* rely on autosense in
> switchers for any crossover/patch cable
> detection. If you know it ought to be a
> crossover, use a crossover cable.

But ping/connectivity *to* the router (eth0) from the LAN is fine. The
problem only occurs when going through NAT/FORWARDING to something
behind it.

Although it appear (from a previously suggested test) that it *Doesn't*
occur on the first hop after my router.

So something strange is happening...

--
Jews, Christians & Muslims
The content of your posts will show how much you
really believe God is looking over your shoulder

Chris Davies <chris-(E-Mail Removed)> wrote:
> Are you pinging by name or by address? If it's by name can you
> please repeat the tests with IP addresses. (This will eliminate any
> delay caused by slow DNS lookups.)

Is there a ping utility out there which puts a DNS lookup in the
timing between the sending of the ICMP Echo Request and the receipt of
the ICMP Echo Reply?

Sure, DNS lookups could delay sending the first or subsequent ICMP
Echo Requests, but any ping utility that sticks just about anything
between the sending of the request and the receipt of the reply is
doing something it shouldn't.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Richard Kettlewell <(E-Mail Removed)> wrote:
> The time= field in ping output measures the round trip of the ICMP
> packet; it doesn't include the DNS lookup.

Ooops, yes. I was thinking of the (really old) ping that (wrongly)
used to do this, despite knowing that recent ping utilities do it
right. I'm going to blame transient brain-fade on this one and hope
no-one objects :-/

Chris