* icmp_ratelimit seems to be too low (related to NAT?)
@ 2003-05-05 9:35 Christian Hammers
2003-05-05 14:53 ` Randy.Dunlap
0 siblings, 1 reply; 2+ messages in thread
From: Christian Hammers @ 2003-05-05 9:35 UTC (permalink / raw)
To: linux-kernel
Hello
icmp_ratelimit has, as of kernel 2.4.20, a default of 100 (which unit
btw?). This seems to be too low as I have packet loss when doing two
"mtr" to the same 4 hops away host simultaneously. As this suggerates
packet loss on the network to the administrator, a too low limit will
certainly annoy network admins as it gives wrong information.
My tests gave the following results:
src. linux --> SNAT'ing linux router --> cisco1 --> cisco2 --> dst. linux
On the src linux host I opened _two_ mtr at the same time and watched
the packet loss at the first host after 30 rounds (seconds).
icmp_ratelimit | loss at hop1 for both mtr
0 0
10 0
20 0
40 0
80 34% and 37%
100 44% and 57% (default)
160 64% and 75%
320 87% and 83%
999 100% and 100%
For 2*(4*icmp_request + 4*icmp_timeexceeded/reply) = 16 packets per
second the loss seems to be a bit high at the default value of 100.
Is this related to any other setting? Maybe NAT?
My /proc/net/ip_conntrack only has 1200 lines and the max in
/proc/sys/net/ipv4/ip_conntrack_max is 32767.
bye,
-christian-
--
Christian Hammers WESTEND GmbH | Internet-Business-Provider
Technik CISCO Systems Partner - Authorized Reseller
Lütticher Straße 10 Tel 0241/701333-11
ch@westend.com D-52064 Aachen Fax 0241/911879
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: icmp_ratelimit seems to be too low (related to NAT?)
2003-05-05 9:35 icmp_ratelimit seems to be too low (related to NAT?) Christian Hammers
@ 2003-05-05 14:53 ` Randy.Dunlap
0 siblings, 0 replies; 2+ messages in thread
From: Randy.Dunlap @ 2003-05-05 14:53 UTC (permalink / raw)
To: Christian Hammers; +Cc: linux-kernel
On Mon, 5 May 2003 11:35:23 +0200 Christian Hammers <ch@westend.com> wrote:
| Hello
|
| icmp_ratelimit has, as of kernel 2.4.20, a default of 100 (which unit
| btw?). This seems to be too low as I have packet loss when doing two
| "mtr" to the same 4 hops away host simultaneously. As this suggerates
| packet loss on the network to the administrator, a too low limit will
| certainly annoy network admins as it gives wrong information.
icmp_ratelimit is init to 1 * HZ (where HZ == 100 most likely),
so I'll guess that unit is jiffies (100ths of a second).
| My tests gave the following results:
|
| src. linux --> SNAT'ing linux router --> cisco1 --> cisco2 --> dst. linux
|
| On the src linux host I opened _two_ mtr at the same time and watched
| the packet loss at the first host after 30 rounds (seconds).
|
| icmp_ratelimit | loss at hop1 for both mtr
| 0 0
| 10 0
| 20 0
| 40 0
| 80 34% and 37%
| 100 44% and 57% (default)
| 160 64% and 75%
| 320 87% and 83%
| 999 100% and 100%
|
| For 2*(4*icmp_request + 4*icmp_timeexceeded/reply) = 16 packets per
| second the loss seems to be a bit high at the default value of 100.
|
| Is this related to any other setting? Maybe NAT?
| My /proc/net/ip_conntrack only has 1200 lines and the max in
| /proc/sys/net/ipv4/ip_conntrack_max is 32767.
Only other value that I see related to it is
icmp_ratemask, which has a default value of 0x1818.
>From net/ipv4/icmp.c:
/*
* Configurable global rate limit.
*
* ratelimit defines tokens/packet consumed for dst->rate_token bucket
* ratemask defines which icmp types are ratelimited by setting
* it's bit position.
*
* default: [for ratemask -RDD]
* dest unreachable (3), source quench (4),
* time exceeded (11), parameter problem (12)
*/
--
~Randy
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-05-05 14:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-05 9:35 icmp_ratelimit seems to be too low (related to NAT?) Christian Hammers
2003-05-05 14:53 ` Randy.Dunlap
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).