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

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 1 of 2  [1] 2  Next page →

#1314 — 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

[toc] | [next] | [standalone]

#1318

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?

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

#1319

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. :)

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

#1326

On 2012-04-30, ein <ein@no.spam> 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

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

#1339

Hello,

Mike Lovell a écrit :
> On 2012-04-30, ein <ein@no.spam> wrote:
>>
>>> Ping: LAN Machine -> Debian Router = ~0.7ms
>>> Ping: Debian Router -> Google = ~20ms
>>> Ping: LAN Machine -> Google = ~121ms !!!
>>
>> Wrong!

What is 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.

Indeed. So why do you suggest to ping the ISP's gateway, which is a
router ? By the way, AFAICS, the OP did ping his own Debian router and
a Google server, not any ISP's router.

> Interesting, much better:

What is much better ?

> --- 68.86.118.57 ping statistics ---

What is that address ?

> 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 average RTT is still ~60 ms.

> So, based on the better ping to the next hop after my router,

Better than what ?

> why (how)
> would something be distinguishing between the router carrying out the
> ping, and something behind the router?

In the old days some ISPs have been known to try to detect multiple
hosts behind NAT with variations of the TTL in packets.

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

You can rewrite the TTL with iptables. Note that traceroute won't work
any more.

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

#1340

On 2012-05-01, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>> Interesting, much better:
>
> What is much better ?

Pinging the next hop as opposed to Google

>> --- 68.86.118.57 ping statistics ---
>
> What is that address ?
>
>> 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 average RTT is still ~60 ms.
>
>> So, based on the better ping to the next hop after my router,
>
> Better than what ?

Sorry, maybe that wasn't a good output.

I just pinging:

 te-1-2-ur03.nchicago.il.chicago.comcast.net

Which is the next hop, from my Debian router and a machine in the LAN.

Router avg 20.327
LAN avg 21.623

>> why (how)
>> would something be distinguishing between the router carrying out the
>> ping, and something behind the router?
>
> In the old days some ISPs have been known to try to detect multiple
> hosts behind NAT with variations of the TTL in packets.

Interesting

>> Can I mask it from doing so (if that's the problem)?
>
> You can rewrite the TTL with iptables. Note that traceroute won't work
> any more.

My friend, you are a genius...


sudo iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 56
sudo iptables -t mangle -A OUTPUT -j TTL --ttl-set 56


~$ ping -c 10 www.google.com
PING www.google.com (74.125.225.83) 56(84) bytes of data.
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=1
ttl=55 time=35.7 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=2
ttl=55 time=12.8 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=3
ttl=55 time=14.7 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=4
ttl=55 time=15.5 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=5
ttl=55 time=15.3 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=6
ttl=55 time=14.6 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=7
ttl=55 time=18.9 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=8
ttl=55 time=14.7 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=9
ttl=55 time=12.6 ms
64 bytes from ord08s07-in-f19.1e100.net (74.125.225.83): icmp_req=10
ttl=55 time=180 ms

--- www.google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 12.615/33.538/180.324/49.347 ms



So looks like those little darlings were to blame after all!

	~ Mike

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

#1341

Mike Lovell a écrit :
> On 2012-05-01, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>>> Interesting, much better:
>> What is much better ?
> 
> Pinging the next hop as opposed to Google

Better ping a host than a router. As ein wrote, "routers have more
important things to do, than respond to ICMP echo request messages".

> My friend, you are a genius...

I wish I were...

> sudo iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 56
> sudo iptables -t mangle -A OUTPUT -j TTL --ttl-set 56

Note that the TTL of forwarded packets is decremented by 1 after the
PREROUTING chains, so you shouldn't set the same TTL in OUTPUT if you
want the same TTL when locally-generated and forwarded packets leave
your router.

Or you can set the TTL in POSTROUTING for both locally-generated and
forwarded packets.

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

#1342

On 2012-05-01, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> I wish I were...
>
>> sudo iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 56
>> sudo iptables -t mangle -A OUTPUT -j TTL --ttl-set 56
>
> Note that the TTL of forwarded packets is decremented by 1 after the
> PREROUTING chains, so you shouldn't set the same TTL in OUTPUT if you
> want the same TTL when locally-generated and forwarded packets leave
> your router.
>
> Or you can set the TTL in POSTROUTING for both locally-generated and
> forwarded packets.

Yer you're right, I jumped the gun.  It's gone back up now, must have
been a fluke.  It was lower right after coming up from a reboot.

So this would achieve the same TTL?

iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 57
iptables -t mangle -A OUTPUT -j TTL --ttl-set 56

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

#1343

Mike Lovell a écrit :
> On 2012-05-01, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
>>
>>> sudo iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 56
>>> sudo iptables -t mangle -A OUTPUT -j TTL --ttl-set 56
>> Note that the TTL of forwarded packets is decremented by 1 after the
>> PREROUTING chains, so you shouldn't set the same TTL in OUTPUT if you
>> want the same TTL when locally-generated and forwarded packets leave
>> your router.
>>
>> Or you can set the TTL in POSTROUTING for both locally-generated and
>> forwarded packets.
> 
> Yer you're right, I jumped the gun.  It's gone back up now, must have
> been a fluke.  It was lower right after coming up from a reboot.
> 
> So this would achieve the same TTL?
> 
> iptables -t mangle -A PREROUTING -i eth0 -j TTL --ttl-set 57
> iptables -t mangle -A OUTPUT -j TTL --ttl-set 56

I guess so. Or just :

iptables -t mangle -A POSTROUTING -o wan0 -j TTL --ttl-set 56

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

#1344

On 2012-05-01, Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
> I guess so. Or just :
>
> iptables -t mangle -A POSTROUTING -o wan0 -j TTL --ttl-set 56

Gah I definitely celebrated too soon.

Must have been (possibly) related to rebooting the Debian router, it's
returned to the same delay as before now (even with the TTL changes).

There's something else fishy here.

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

#1345

Mike Lovell a écrit :
> 
> Must have been (possibly) related to rebooting the Debian router, it's
> returned to the same delay as before now (even with the TTL changes).

Can you reproduce this ?

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

#1365

Mike Lovell wrote:
[....]
>
> Yer you're right, I jumped the gun.  It's gone back up now, must have
> been a fluke.  It was lower right after coming up from a reboot.

That's a hint.
I'm on 'Kabel Deutschland' and get about a zillion ARP requests
a day, sometimes this even f**ks up the cable modem (EPC3212).
I usually just 'reboot' the modem then....

	-rasp

-- 
See why I hate Windows users?
      All pain, no gain.
	-Howard Chu

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

#1347

Mike> why (how) would something be distinguishing between the router
Mike> carrying out the ping, and something behind the router?

Pascal> In the old days some ISPs have been known to try to detect
Pascal> multiple hosts behind NAT with variations of the TTL in packets.

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

Pascal> You can rewrite the TTL with iptables. Note that traceroute
Pascal> won't work any more.

Why the need for iptables?  Wouldn't it be simpler and safer to just
tweak the value in /proc/sys/net/ipv4/ip_default_ttl on each host
according to its hop distance from the router?

-- 
Ian Zimmerman
gpg public key: 1024D/C6FF61AD
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
http://www.gravatar.com/avatar/c66875cda51109f76c6312f4d4743d1e.png
Rule 420: All persons more than eight miles high to leave the court.

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

#1348

Ian Zimmerman a écrit :
> 
> Pascal> You can rewrite the TTL with iptables. Note that traceroute
> Pascal> won't work any more.
> 
> Why the need for iptables?

Because it is simple and effective.

> Wouldn't it be simpler and safer to just
> tweak the value in /proc/sys/net/ipv4/ip_default_ttl on each host
> according to its hop distance from the router?

Not simpler, as this has to be done on all hosts instead of one router.
Besides, it works only for Linux hosts, and some packets may not use the
default TTL.

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

#1349

On 05/01/2012 02:21 AM, Pascal Hambourg wrote:
> Hello,
> 
> Mike Lovell a écrit :
>> On 2012-04-30, ein <ein@no.spam> wrote:
>>>
>>>> Ping: LAN Machine -> Debian Router = ~0.7ms
>>>> Ping: Debian Router -> Google = ~20ms
>>>> Ping: LAN Machine -> Google = ~121ms !!!
>>>
>>> Wrong!
> 
> What is wrong ?

IMHO Mike's way to attempt to diagnose the problem.

>>> 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.
> 
> Indeed. So why do you suggest to ping the ISP's gateway, which is a
> router ? By the way, AFAICS, the OP did ping his own Debian router and
> a Google server, not any ISP's router.

Correlation is simple: more hops = more things can change while
connection or even while transmitting different packets to the same
machine in this connection. Each ICMP echo request message can go over
Internet with different path.

In my country small ISPs are usesd to queue everything and decide for u
what traffic is more important. ICMP "connections" are at the bottom of
list.

>> Interesting, much better:
> 
> What is much better ?

I still think the OP ISP is doing something nasty.

Mike: can u connect to your (while observing the latency problem)
router's WAN some other device for which u have access to?
It will divide the problem to smaller parts. It will answer u that the
problem is actually in forwarding at debian router.

br.

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

#1364

Pascal Hambourg wrote:
>
>> --- 68.86.118.57 ping statistics ---
>
> What is that address ?
Comcast Cable Communications, Inc. JUMPSTART-2 (NET-68-80-0-0-1) 
68.80.0.0 - 68.87.255.255
Comcast Cable Communications, Inc. COMCAST-16 (NET-68-86-64-0-1) 
68.86.64.0 - 68.86.127.255

As told by `whois` :-)

To the OP: It's always a good idea to ping an address you
a) know
b) know the distance to
c) maybe use `traceroute -n` instead

As the ghoul for instance has many IP addresses for the same
domai name, so the DNS is not the problem but just by pinging
e.g. google.com you're probably pinging a dozen different IP's...

No offense, just my 0.02 Drachmen :-P

	-rasp



-- 
See why I hate Windows users?
      All pain, no gain.
	-Howard Chu

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

#1320

In comp.os.linux.networking Mike Lovell <mike.lovell@null.local> 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

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

#1322

Chris Davies <chris-usenet@roaima.co.uk> writes:
> In comp.os.linux.networking Mike Lovell <mike.lovell@null.local> 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/

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

#1338

Richard Kettlewell <rjk@greenend.org.uk> 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

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

#1332

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?

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...

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web