Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1314 > unrolled thread

iptables NAT forwarding adding 75-100ms

Started byMike Lovell <mike.lovell@null.local>
First post2012-04-29 17:42 -0500
Last post2012-05-09 14:05 +0200
Articles 5 on this page of 25 — 10 participants

Back to article view | Back to comp.os.linux.networking

Contents

  iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-29 17:42 -0500
    Re: iptables NAT forwarding adding 75-100ms ein <ein@no.spam> - 2012-04-30 11:06 +0200
      Re: iptables NAT forwarding adding 75-100ms ein <ein@no.spam> - 2012-04-30 11:08 +0200
      Re: iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-30 10:11 -0500
        Re: iptables NAT forwarding adding 75-100ms Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-05-01 02:21 +0200
          Re: iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-30 19:46 -0500
            Re: iptables NAT forwarding adding 75-100ms Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-05-01 03:01 +0200
              Re: iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-30 20:09 -0500
                Re: iptables NAT forwarding adding 75-100ms Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-05-01 03:55 +0200
                  Re: iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-30 21:07 -0500
                    Re: iptables NAT forwarding adding 75-100ms Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-05-01 10:46 +0200
                Re: iptables NAT forwarding adding 75-100ms Ralph Spitzner <rasp@spitzner.org> - 2012-05-04 09:30 +0200
          Re: iptables NAT forwarding adding 75-100ms Ian Zimmerman <itz@buug.org> - 2012-05-01 12:35 -0700
            Re: iptables NAT forwarding adding 75-100ms Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-05-02 00:06 +0200
          Re: iptables NAT forwarding adding 75-100ms ein <ein@no.spam> - 2012-05-02 07:43 +0200
          Re: iptables NAT forwarding adding 75-100ms Ralph Spitzner <rasp@spitzner.org> - 2012-05-04 09:22 +0200
    Re: iptables NAT forwarding adding 75-100ms Chris Davies <chris-usenet@roaima.co.uk> - 2012-04-30 10:34 +0100
      Re: iptables NAT forwarding adding 75-100ms Richard Kettlewell <rjk@greenend.org.uk> - 2012-04-30 11:15 +0100
        Re: iptables NAT forwarding adding 75-100ms Chris Davies <chris-usenet@roaima.co.uk> - 2012-04-30 23:59 +0100
      Re: iptables NAT forwarding adding 75-100ms Rick Jones <rick.jones2@hp.com> - 2012-04-30 18:33 +0000
        Re: iptables NAT forwarding adding 75-100ms ein <ein@no.spam> - 2012-05-02 07:51 +0200
          Re: iptables NAT forwarding adding 75-100ms Rick Jones <rick.jones2@hp.com> - 2012-05-02 19:07 +0000
    Re: iptables NAT forwarding adding 75-100ms Alastair Black <abqab.nemo@example.net> - 2012-04-30 06:40 -0600
      Re: iptables NAT forwarding adding 75-100ms Mike Lovell <mike.lovell@null.local> - 2012-04-30 10:12 -0500
    Re: iptables NAT forwarding adding 75-100ms Wolfram Gloger <wmglo@dent.med.uni-muenchen.de> - 2012-05-09 14:05 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1350

Fromein <ein@no.spam>
Date2012-05-02 07:51 +0200
Message-ID<jnqi1p$91m$1@node2.news.atman.pl>
In reply to#1332
On 04/30/2012 08:33 PM, Rick Jones wrote:
> Chris Davies <chris-usenet@roaima.co.uk> 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?

root@linux:~# time ping -c1 google.ch
PING google.ch (173.194.35.152) 56(84) bytes of data.
64 bytes from muc03s01-in-f24.1e100.net (173.194.35.152): icmp_req=1
ttl=49 time=48.5 ms

--- google.ch ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 48.550/48.550/48.550/0.000 ms

real    0m0.139s
user    0m0.001s
sys     0m0.001s
root@linux:~# time ping -c1 173.194.35.152
PING 173.194.35.152 (173.194.35.152) 56(84) bytes of data.
64 bytes from 173.194.35.152: icmp_req=1 ttl=49 time=47.1 ms

--- 173.194.35.152 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 47.155/47.155/47.155/0.000 ms

real    0m0.048s
user    0m0.000s
sys     0m0.001s

:D

[toc] | [prev] | [next] | [standalone]

#1353

FromRick Jones <rick.jones2@hp.com>
Date2012-05-02 19:07 +0000
Message-ID<jns0me$g69$3@usenet01.boi.hp.com>
In reply to#1350
ein <ein@no.spam> wrote:
> On 04/30/2012 08:33 PM, Rick Jones wrote:
> > 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?

> root@linux:~# time ping -c1 google.ch
> PING google.ch (173.194.35.152) 56(84) bytes of data.
> 64 bytes from muc03s01-in-f24.1e100.net (173.194.35.152): icmp_req=1
> ttl=49 time=48.5 ms

> --- google.ch ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 48.550/48.550/48.550/0.000 ms

> real    0m0.139s
> user    0m0.001s
> sys     0m0.001s
> root@linux:~# time ping -c1 173.194.35.152
> PING 173.194.35.152 (173.194.35.152) 56(84) bytes of data.
> 64 bytes from 173.194.35.152: icmp_req=1 ttl=49 time=47.1 ms

> --- 173.194.35.152 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 47.155/47.155/47.155/0.000 ms

> real    0m0.048s
> user    0m0.000s
> sys     0m0.001s

> :D

That is the overall difference in how long the ping command takes to
run, but there is no difference in the RTTs of the actual ICMP Echo
Request/Reply pairs.  IE, there is a DNS lookup before the ICMP Echo
Request is sent, and one after the ICMP Echo Reply is received, but
they are outside the timestamping inside ping to measure the RTTs.

Roughly speaking:

DNS lookup name
Get starting timestamp
Send ICMP Echo Request
...time passes...
Receive ICMP Echo Reply
Get ending timestamp
DNS lookup source IP of ICMP Echo Reply

So, DNS delays can cause even a well-written ping utility to take
longer to execute overall, but they will not cause the RTTs reported
by that utility to be longer.

rick jones
-- 
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
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...

[toc] | [prev] | [next] | [standalone]

#1323

FromAlastair Black <abqab.nemo@example.net>
Date2012-04-30 06:40 -0600
Message-ID<jnm181$k9$1@n102.xanadu-bbs.net>
In reply to#1314
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

[toc] | [prev] | [next] | [standalone]

#1327

FromMike Lovell <mike.lovell@null.local>
Date2012-04-30 10:12 -0500
Message-ID<slrnjptav2.gqh.mike.lovell@usenet.home.b0h0.com>
In reply to#1323
On 2012-04-30, Alastair Black <abqab.nemo@example.net> 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

[toc] | [prev] | [next] | [standalone]

#1375

FromWolfram Gloger <wmglo@dent.med.uni-muenchen.de>
Date2012-05-09 14:05 +0200
Message-ID<u4ehqtpnk3.fsf@md.dent.med.uni-muenchen.de>
In reply to#1314
Mike Lovell <mike.lovell@null.local> writes:

> The relevant forwarding/NAT rules are:
> 
> 
> #iptables -A FORWARD -i wan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

I find this rule strange.  Did you get it from any standard cookbook?
It will necessitate connection tracking for any packet routed back to
your LAN.  It's quite improbable that this can account for 100ms
delay, but could you just as an experiment replace this by:

iptables -A FORWARD -i wan0 -o eth0 -j ACCEPT

Regards,
Wolfram.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.networking

csiph-web