Re: ip_conntrack table
Hallo Micha, * Micha Beyer [EMAIL PROTECTED] [20051203 13:25]: Welcher Wert steht denn bei Dir in /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established? Bei mir stand da was von 5 Tagen, in Sekunden natürlich. Ich habe dann die Zeit auf 10 Minuten runtergesetzt. Hmmm gehe ich richtig in der Annahme, dass das die Zeit ist, nach der eine Verbindung aus der conntrack-table gelöscht wird wenn der Router keine Pakete mehr gesehen hat, /obwohl/ sie im Zustand ESTABLISHED ist? Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage einen Tabellen-Eintrag? Kann mir jemand sagen, was die Motivation für einen derart hohen Default-Wert ist? Grüße, Felix -- | /\ ASCII Ribbon | Felix M. Palmen (Zirias)http://zirias.ath.cx/ | | \ / Campaign Against | [EMAIL PROTECTED] encrypted mail welcome | | XHTML In Mail | PGP key: http://zirias.ath.cx/pub.txt | | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 | signature.asc Description: Digital signature
Re: ip_conntrack table
Also sprach Felix M. Palmen [EMAIL PROTECTED] (Sun, 4 Dec 2005 10:22:34 +0100): * Micha Beyer [EMAIL PROTECTED] [20051203 13:25]: Welcher Wert steht denn bei Dir in /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established? Bei mir stand da was von 5 Tagen, in Sekunden natürlich. Ich habe dann die Zeit auf 10 Minuten runtergesetzt. Hmmm gehe ich richtig in der Annahme, dass das die Zeit ist, nach der eine Verbindung aus der conntrack-table gelöscht wird wenn der Router keine Pakete mehr gesehen hat, /obwohl/ sie im Zustand ESTABLISHED ist? Eine Regel wird established und bleibt dann fuer diese Zeit in diesem Zustand aufrechterhalten, /es sein denn/ die Verbindung wird zurueckgesetzt. Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage einen Tabellen-Eintrag? ip_conntrack_udp_timeout Wie schon erkannt, ist udp stateless (keine established Verbindung). Kann mir jemand sagen, was die Motivation für einen derart hohen Default-Wert ist? Find ich ganz praktisch: ich hole mir ein Prorgamm vom schnellen Desktop auf den alten/langsamen Libretto, suspende ihn, und wenn ich ihn einen Tag spaeter wieder aufwecke laesst sich (meist) weiterarbeiten. Brauch ich dieses feature nicht, kann man/frau ja das timeout runtersetzen - und im Falle von andauernten nmap's durchs Netz, kann ich einen kleineren Wert nur empfehlen, da sonst der table ordentlich anwaechst. sl ritch
Re: ip_conntrack table
On Sun, 4 Dec 2005 12:18:21 +0100, Richard Mittendorfer [EMAIL PROTECTED] wrote: Also sprach Felix M. Palmen [EMAIL PROTECTED] (Sun, 4 Dec 2005 10:22:34 +0100): Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage einen Tabellen-Eintrag? ip_conntrack_udp_timeout Wie schon erkannt, ist udp stateless (keine established Verbindung). Wenn ich mich richtig erinnere, hat Netfilter bei klassischem Frage-Antwort-UDP einen recht kurzen Timeout, der bei Beobachtung eines zweiten Antwort-Pakets drastisch erhöht wird. So erhofft man, Streaminganwendungen zu erkennen. Bei Amanda fällt dieses Verfahren auf die Schnauze, weil dort im ersten Paket drin steht schick mir mal eine Schätzung für die Größe Deines Dateisystems /usr, in der Antwort steht Ja, in Ordnung, und wenn dann zehn Minuten später die eine Seite mit der Schätzung fertig ist, ist die Session auf dem Paketfiler längst ausgetimed und das Paket mit der richtigen Antwort zerschellt. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: ip_conntrack table
Also sprach Marc Haber [EMAIL PROTECTED] (Sun, 04 Dec 2005 14:01:37 +0100): On Sun, 4 Dec 2005 12:18:21 +0100, Richard Mittendorfer [EMAIL PROTECTED] wrote: Also sprach Felix M. Palmen [EMAIL PROTECTED] (Sun, 4 Dec 2005 10:22:34 +0100): Was ist dann bei UPD-Verbindungen, die ja keinen dedizierten Abbau-Mechanismus haben? Blockieren die alle für mindestens 5 Tage einen Tabellen-Eintrag? ip_conntrack_udp_timeout Wie schon erkannt, ist udp stateless (keine established Verbindung). Wenn ich mich richtig erinnere, hat Netfilter bei klassischem Frage-Antwort-UDP einen recht kurzen Timeout, der bei Beobachtung eines zweiten Antwort-Pakets drastisch erhöht wird. So erhofft man, Streaminganwendungen zu erkennen. Bei Amanda fällt dieses Verfahren auf die Schnauze, weil dort im ersten Paket drin steht schick mir mal eine Schätzung für die Größe Deines Dateisystems /usr, in der Antwort steht Ja, in Ordnung, und wenn dann zehn Minuten später die eine Seite mit der Schätzung fertig ist, ist die Session auf dem Paketfiler längst ausgetimed und das Paket mit der richtigen Antwort zerschellt. Da scheint wohl ip_conntrack_udp_timeout_stream zu helfen? Nein - tut es nicht. Hab mir das nun genauer angesehen: Ein UDP-Link wird einige Zeit mit einem kurzen timeout (default 30s) gehalten, und bei Bedarf (aka falls es als stream erkannt wird) obiges timeout_stream (180s) verwendet. Gehen aber zu wenige Packete/Zeit zum Sender retour, wird das nicht als stream erkannt und ip_ct_udp_timeout greift. sl ritch
Re: ip_conntrack table
On Sun, 4 Dec 2005 14:32:59 +0100, Richard Mittendorfer [EMAIL PROTECTED] wrote: Also sprach Marc Haber [EMAIL PROTECTED] (Sun, 04 Dec 2005 14:01:37 +0100): Bei Amanda fällt dieses Verfahren auf die Schnauze, weil dort im ersten Paket drin steht schick mir mal eine Schätzung für die Größe Deines Dateisystems /usr, in der Antwort steht Ja, in Ordnung, und wenn dann zehn Minuten später die eine Seite mit der Schätzung fertig ist, ist die Session auf dem Paketfiler längst ausgetimed und das Paket mit der richtigen Antwort zerschellt. Da scheint wohl ip_conntrack_udp_timeout_stream zu helfen? Damals musste man halt zähneknirschend incoming UDP erlauben, inzwischen gibt es ein amanda-conntrack-Modul. Das hab ich allerdings noch nie benutzt. Grüße Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: ip_conntrack table
Am Samstag, 3. Dezember 2005 20:05 schrieb Simon Neumeister: Dann fährst du deine Netzwerkschnittstellen jeden Tag hoch und runter, also entlädst / lädst du deine Module? Die Module fürs Netzwerk bleiben geladen, nur die Iptables fliegen raus. Die Schnittstellen werden automatisch runtergefahren wenn die Telekom nach 24 Stunden trennt. Der Reconnect fährt sie dann ja wieder hoch, und in der Zeit brauch ich nicht wirklich ne Firewall, weils ja sowieso keine Verbindung gibt. -- MfG usw. Werner Mahr registered Linuxuser: 303822 pgpDZMxJmJKxb.pgp Description: PGP signature
Re: ip_conntrack table
Am Sonntag, 4. Dezember 2005 19:57 schrieb Werner Mahr: Die Module fürs Netzwerk bleiben geladen, nur die Iptables fliegen raus. Die Schnittstellen werden automatisch runtergefahren wenn die Telekom nach 24 Stunden trennt. Der Reconnect fährt sie dann ja wieder hoch, und in der Zeit brauch ich nicht wirklich ne Firewall, weils ja sowieso keine Verbindung gibt. ja klar, das macht Sinn. Wenn du eh nach 24h getrennt wirst Ist halt bei mir nicht der Fall: bin in einem WAN, in dem der Server mit den Diensten 24/7 errecihbar sein soll. Das heißt der Rechner ist bis auf Wartungsarbeiten immer online und entsprechend sollte natürlich auch die Firewall passend den Dienst verrrichten :-) Aber trotzdem Danke für die Idee ! -- MfG usw. Werner Mahr registered Linuxuser: 303822 -- Grüße, Simon
Re: ip_conntrack table
Am Mittwoch, 30. November 2005 18:09 schrieb Simon Neumeister: ich bekomme seit neuestem von meinem NAT-Router die Meldung: 'ip_conntrack: table full, droping packet' Macht es Sinn die Tabelle in /proc einfach zu vergrößern ? (WEnn ich das richtig sehe könnte ich das mit '/proc/sys/net/ipv4/ip_conntrack_max' machen ???) Oder gibt es bessere Lösungen ? Die Lösung ist schon okay, ich mache das hier auch so seitdem ich derartige Probleme hatte. Mal abgesehen davon, dass mich die Ursache auch brennend interessieren würde Welcher Wert steht denn bei Dir in /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established? Bei mir stand da was von 5 Tagen, in Sekunden natürlich. Ich habe dann die Zeit auf 10 Minuten runtergesetzt. -- Mfg, Michael
Re: ip_conntrack table
Am Samstag, 3. Dezember 2005 13:25 schrieb Micha Beyer: '/proc/sys/net/ipv4/ip_conntrack_max' machen ???) Oder gibt es bessere Lösungen ? /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established? Bei mir stand da was von 5 Tagen, in Sekunden natürlich. Ich habe dann die Zeit auf 10 Minuten runtergesetzt. Ich hab beides schon probiert gehabt, und mittlerweile die einfachste Lösung gefunden. Da die Firewall sowieso im if-up und if-down drinsteht, werden die Module einfach auch in den Scripten ge- bzw. entladen, und schon sind die tables wieder leer. Funktioniert natürlich nur wenn man das Glück hat, dass die Tables länger als 24 Stunden brauchen zum volllaufen. -- MfG usw. Werner Mahr registered Linuxuser: 303822 pgphYCZHpTkiq.pgp Description: PGP signature
Re: ip_conntrack table
Am Samstag, 3. Dezember 2005 13:25 schrieb Micha Beyer: Welcher Wert steht denn bei Dir in /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established? sokrates:/tmp# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 432000 sokrates:/tmp# also auch 5 Tage Bei mir stand da was von 5 Tagen, in Sekunden natürlich. Ich habe dann die Zeit auf 10 Minuten runtergesetzt. War das Problem dann 'gelöst' ? Habs bei mir mal auf 86400 also 1h runtergesetzt und werd das mal beobachten. -- Mfg, Michael -- Grüße, Simon
Re: ip_conntrack table
Am Samstag, 3. Dezember 2005 14:54 schrieb Werner Mahr: Ich hab beides schon probiert gehabt, und mittlerweile die einfachste Lösung gefunden. Da die Firewall sowieso im if-up und if-down drinsteht, werden die Module einfach auch in den Scripten ge- bzw. entladen, und schon sind die tables wieder leer. Funktioniert natürlich nur wenn man das Glück hat, dass die Tables länger als 24 Stunden brauchen zum volllaufen. Dann fährst du deine Netzwerkschnittstellen jeden Tag hoch und runter, also entlädst / lädst du deine Module? Ist für mich etwas unpraktisch. Ich müsste ja dann entsprechend alle ca. 18h meine SChnittstellen rauf und runter fahren damit die Table geleert wird -- MfG usw. Werner Mahr registered Linuxuser: 303822 -- Grüße, Simon
Re: ip_conntrack table
Am Samstag 03 Dezember 2005 19:59 schrieb Simon Neumeister: sokrates:/tmp# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 432000 sokrates:/tmp# also auch 5 Tage Ah ja, das kenne ich doch schon irgendwoher. Zeit auf 10 Minuten runtergesetzt. War das Problem dann 'gelöst' ? Habs bei mir mal auf 86400 also 1h runtergesetzt und werd das mal beobachten. Bei mir traten dann keine Probleme mehr wegen packet drop und so. -- Mfg, Michael
Re: ip_conntrack table
Am Samstag 03 Dezember 2005 19:59 schrieb Simon Neumeister: Habs bei mir mal auf 86400 also 1h runtergesetzt und werd das mal beobachten. Wieso eigentlich 86400 Sekunden? Das ist ein voller Tag und nicht eine Stunde wie Du schriebst! -- Mfg, Michael -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack table
Am Samstag, 3. Dezember 2005 23:12 schrieb Micha Beyer: Wieso eigentlich 86400 Sekunden? Das ist ein voller Tag und nicht eine Stunde wie Du schriebst! ach du *mist*! Das sollte ich ändern. Danke für den Hinweis !! -- Mfg, Michael -- Grüße, Simon
ip_conntrack table
HI ich bekomme seit neuestem von meinem NAT-Router die Meldung: 'ip_conntrack: table full, droping packet' Das kommt zeitlich mit einem Kernel 'upgrade hin': habe meinen 2.4.29er neu kompiliert um qos und fair queueing als module zu integrieren. Der Zusammenhang ist mir zwar schleierhaft, aber möglich ist ja bekanntlich vieles. Macht es Sinn die Tabelle in /proc einfach zu vergrößern ? (WEnn ich das richtig sehe könnte ich das mit '/proc/sys/net/ipv4/ip_conntrack_max' machen ???) Oder gibt es bessere Lösungen ? Mal abgesehen davon, dass mich die Ursache auch brennend interessieren würde -- Grüße, Simon
Re: ip_conntrack table
Hallo Simon, Simon says: HI ich bekomme seit neuestem von meinem NAT-Router die Meldung: 'ip_conntrack: table full, droping packet' [...] Macht es Sinn die Tabelle in /proc einfach zu vergrößern ? (WEnn ich das richtig sehe könnte ich das mit '/proc/sys/net/ipv4/ip_conntrack_max' machen ???) Oder gibt es bessere Lösungen ? Also das wäre eine Lösung, dass du die Anzahl der Verbindungen erhöhst. Aber die Grund für das volle Table wäre durchaus interessant. Mal abgesehen davon, dass mich die Ursache auch brennend interessieren würde Oft wird ein solches Überlaufen durch P2P-Clients verursacht, die schlichtweg zu viele Verbindungen öffnen. Trifft das auf dich zu? MfG, Claus -- Claus Malter [EMAIL PROTECTED] Blog: http://claus.freakempire.de Web: http://freakempire.de ICQ: 105226435 GnuPG-ID: 0xC252C3D0 http://wwwkeys.de.pgp.net -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack table
Am Mittwoch, 30. November 2005 18:18 schrieb Claus Malter: Hallo Simon, Hi Claus ! Simon says: HI ich bekomme seit neuestem von meinem NAT-Router die Meldung: 'ip_conntrack: table full, droping packet' [...] Macht es Sinn die Tabelle in /proc einfach zu vergrößern ? (WEnn ich das richtig sehe könnte ich das mit '/proc/sys/net/ipv4/ip_conntrack_max' machen ???) Oder gibt es bessere Lösungen ? Also das wäre eine Lösung, dass du die Anzahl der Verbindungen erhöhst. Aber die Grund für das volle Table wäre durchaus interessant. Meine Rede. Mal abgesehen davon, dass mich die Ursache auch brennend interessieren würde Oft wird ein solches Überlaufen durch P2P-Clients verursacht, die schlichtweg zu viele Verbindungen öffnen. Trifft das auf dich zu? NEIN. Bin nur mit einem Rechner hinter der NAT-Box, und der Traffic der darüber geht ist zu 99% E-Mail, HTTP, FTP, NNTP. Auf der Kiste laufen allerdings noch ein paar andere Services: Apache, Tomcat Mysql, Ldap, Nfsd, Rsync proftpd Sollte das damit in Zusammenhang stehen ? MfG, Claus -- Grüße, Simon
Re: ip_conntrack table
Am Mittwoch 30 November 2005 18:30 schrieb Simon Neumeister: Am Mittwoch, 30. November 2005 18:18 schrieb Claus Malter: Bin nur mit einem Rechner hinter der NAT-Box, und der Traffic der darüber geht ist zu 99% E-Mail, HTTP, FTP, NNTP. Auf der Kiste laufen allerdings noch ein paar andere Services: Apache, Tomcat Mysql, Ldap, Nfsd, Rsync proftpd Sollte das damit in Zusammenhang stehen ? Hmm, wirf doch mal ethereal oder so an um zu schauen, was da läuft. Gruß Chris PS: etwas weniger Zitat tuts auch. -- A: because it distrupts the normal process of thought Q: why is top posting frowned upon
Problem mit ip_conntrack: table full, dropping packet
Hi Leute, ich hab ein Problem mit ip_conntrack: und zwar bleiben bei mir nach dem Wechsel der IP-Adresse (die Box hängt hinterm DSL) dutzende connection-trackings liegen, die auch nicht wieder zugehen (oder es dauert einfach viel zu lange). Mittlerweile hat sich das schon auf jenseits 12k angestaut, wo mein Limit liegt. Somit wird bei mir jeglicher Traffic extrem instabil (es scheint sogar ICMP zu beeinträchtigen). Im syslog krieg ich o.g. Fehlermeldung. Freilich kann ich das Limit einfach bis ultimo hochsetzen, aber löst doch das Problem nicht. Wie kann ich alte Verbindungen (meinetwegen auch ganz bestimmte) oder evtl. auch alle auf einmal rauskicken ? thx -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- -
Re: Problem mit ip_conntrack: table full, dropping packet
Hello Enrico, On Tue, 1 Nov 2005 13:11:14 +0100 Enrico Weigelt [EMAIL PROTECTED] wrote: Hi Leute, ich hab ein Problem mit ip_conntrack: und zwar bleiben bei mir nach dem Wechsel der IP-Adresse (die Box hängt hinterm DSL) dutzende connection-trackings liegen, die auch nicht wieder zugehen (oder es dauert einfach viel zu lange). Mittlerweile hat sich das schon auf jenseits 12k angestaut, wo mein Limit liegt. Somit wird bei mir jeglicher Traffic extrem instabil (es scheint sogar ICMP zu beeinträchtigen). Im syslog krieg ich o.g. Fehlermeldung. Freilich kann ich das Limit einfach bis ultimo hochsetzen, aber löst doch das Problem nicht. Wie kann ich alte Verbindungen (meinetwegen auch ganz bestimmte) oder evtl. auch alle auf einmal rauskicken ? Die brutale Methode wäre das conntrack-Modul zu entladen und wieder neu zu laden. Vielleicht genügt es aber auch die Lebenszeit von Verbindungen zu verkürzen. Entweder dauerhaft auf einen kleinen Wert oder um die Table zu clearen nur mal kurzzeitig. sysctl -a | grep conntrack könnte hierzu einige Anregungen bieten. Jörg -- Jörg Schütter http://www.schuetter.org/joerg [EMAIL PROTECTED]http://www.lug-untermain.de/
Re: Problem mit ip_conntrack: table full, dropping packet
Enrico Weigelt [EMAIL PROTECTED] wrote: [ip_conntrack] Freilich kann ich das Limit einfach bis ultimo hochsetzen, aber löst doch das Problem nicht. Wie kann ich alte Verbindungen (meinetwegen auch ganz bestimmte) oder evtl. auch alle auf einmal rauskicken ? Mache es doch einfach so indem Du neue Werte bezüglich Dauer und Anzahl der Verbindungen setzt. echo 600 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established echo 8192 /proc/sys/net/ipv4/ip_conntrack_max -- Mfg, Michael
ip_conntrack: table full, dropping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Kann jemand etwas zu folgender Fehlermeldung sagen? Ursache? Feb 4 07:20:22 mygateway kernel: ip_conntrack: table full, dropping packet. Kam an besagtem Datum mal eine ganze Nacht lang. Ich musste den Rechner (Server) neustarten, weil er aus offensichtlichem Grund nicht mehr per SSH reagiert hat. Nur woher und warum kam diese Meldung? ~ Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAJOP0ZY86bR8HqNwRAhjcAKCBNop9URJPNBmHjiY/vg+dOZK2JACcDd0K jAlegCcnwe3IQIPbgVkGMkY= =hhD7 -END PGP SIGNATURE- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
Joachim Förster wrote: Kann jemand etwas zu folgender Fehlermeldung sagen? Ursache? Feb 4 07:20:22 mygateway kernel: ip_conntrack: table full, dropping packet. Das hatte ich auch. Die internen IPs müssen in die externe IP übersetzt werden. Hierzu hat der Kernel eine Tabelle mit allen aktiven Verbindungen, mit der die Packete richtig weitergegeben werden. Die Anzahl der Einträge in dieser Tabelle sind begrenzt. Du kannst den Wert mittels folgender Zeile in der /etc/sysctl.conf ändern oder mit dem Befehl sysctl manuell setzten. (siehe man Pages) net/ipv4/ip_conntrack_max = 8192 Der Standardwert ist imho 4096. Normalerweise hat man nicht so viele Verbindungen. Aber mit Filesharing etc. kann man diese Grenze schon überschreiten. Ich würde die Änderung in der Datei vornehmen, da sie dann beim nächsten Reboot auch wieder aktiv ist. Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Frank Agerholm schrieb: | Anzahl der Einträge in dieser Tabelle sind begrenzt. Du kannst den Wert | mittels folgender Zeile in der /etc/sysctl.conf ändern oder mit dem | Befehl sysctl manuell setzten. (siehe man Pages) | | net/ipv4/ip_conntrack_max = 8192 | | Der Standardwert ist imho 4096. Normalerweise hat man nicht so viele | Verbindungen. Wo kann ich die momentane Anzahl der Verbindungen sehen? Danke, ~ Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAJO44ZY86bR8HqNwRAsG0AJ9EZVmGEDtgvDwvpi4QKxeI/5HaqgCfbBM/ 59cRbz7P1qs5OhuBqMltCCU= =OiFk -END PGP SIGNATURE- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
Joachim Förster wrote: Wo kann ich die momentane Anzahl der Verbindungen sehen? sysctl net.ipv4.ip_conntrack_max -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Frank Agerholm schrieb: |Wo kann ich die momentane Anzahl der Verbindungen sehen? | | | | sysctl net.ipv4.ip_conntrack_max ? Ich meinte die momentane Anzahl nicht die maximale Anzahl. Also wie viele Verbindung er in einem bestimmten Moment hat. ~ Joachim -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAJP3mZY86bR8HqNwRAnjmAKC2phhWgVFWKAEQxLzYHqCnnm97AACeKKul u0egY07GlTTQJnrd4evVeHk= =tm5y -END PGP SIGNATURE- -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
Frank Agerholm wrote: Joachim Förster wrote: Wo kann ich die momentane Anzahl der Verbindungen sehen? sysctl net.ipv4.ip_conntrack_max Das stimmt nicht, es wurde nach der momentanen Anzahl gefragt: 'wc -l /proc/net/ip_conntrack' -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
Bjoern Schmidt wrote: Das stimmt nicht, es wurde nach der momentanen Anzahl gefragt: Ups. Da hab ich wohl zu schnell gelesen. sorry. Frank -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: ip_conntrack: table full, dropping
Hallö! On Sat, 2004-02-07 at 16:01, Joachim Förster wrote: |Wo kann ich die momentane Anzahl der Verbindungen sehen? | | | | sysctl net.ipv4.ip_conntrack_max ? Ich meinte die momentane Anzahl nicht die maximale Anzahl. Also wie viele Verbindung er in einem bestimmten Moment hat. cat /proc/net/ip_conntrack | wc -l Übrigens: $ cat /proc/sys/net/ipv4/ip_conntrack_max 20472 Das ist bei mir der Default-Wert. Gruß Sven -- Sven Lauritzen mailto: the minus pulse at gmx dot net pub 1024D/95C9A892 sub 1024g/D30E490F ABCDEFGHIJKLM Fp 2FA9 FC9B 078C 5BC7 87DC 0B0D 2329 94F6 95C9 A892 NOPQRSTUVWXYZ signature.asc Description: This is a digitally signed message part
Re: ip_conntrack: table full, dropping
am Sat, dem 07.02.2004, um 16:13:13 +0100 mailte Sven Lauritzen folgendes: Hallö! On Sat, 2004-02-07 at 16:01, Joachim Förster wrote: |Wo kann ich die momentane Anzahl der Verbindungen sehen? | | | | sysctl net.ipv4.ip_conntrack_max ? Ich meinte die momentane Anzahl nicht die maximale Anzahl. Also wie viele Verbindung er in einem bestimmten Moment hat. cat /proc/net/ip_conntrack | wc -l Übrigens: $ cat /proc/sys/net/ipv4/ip_conntrack_max 20472 Das ist bei mir der Default-Wert. Der Wert richtet sich nach der Größe des RAMs. Hab da mal eine Berechnungsformel gelesen. Man kann ihn aber, wie oben schon gesagt, manipulieren. Andreas -- Diese Message wurde erstellt mit freundlicher Unterstützung eines freilau- fenden Pinguins aus artgerechter Freilandhaltung. Er ist garantiert frei von Micro$oft'schen Viren. (#97922 http://counter.li.org) GPG 7F4584DA Was, Sie wissen nicht, wo Kaufbach ist? Hier: N 51.05082°, E 13.56889° ;-) -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
