[Linux]Netwerk even down en weer up brengen

[mphilipp]

Ik draai een 2tal Linux servers waar een flink aantal mensen van buitenaf op connecten. Op de servers draait een klein progsel dat server speelt en de verbindingen, logon en de service regelt. Op zich werkt het prima, maar af en toe kapt ie ermee. Niet zo'n groot probleem, want ik heb een soort watchdog draaien, die 'm binnen 1 minuut weer herstart.

Dat herstarten gaat de laatste tijd minder goed. Dat komt door het aantal connecties. Het ding heeft even tijd nodig om te initialiseren, en ondertussen komen de requests alweer binnen. Ik bedacht me dat ik dit misschien kon verhelpen door in het watchdog script het volgende op te nemen:

code:

ifconfig eth0 down
start_server_commando
sleep 20
ifconfig eth0 up

Kan ik dat zomaar ongestraft doen? Ziet het programma de eth0 poort dan nog wel? Of is er een slimmere manier om eventjes de connecties op te houden? Tijdelijk de firewall rules aanpassen bv (alles dicht zetten en daarna de standaard rules weer aan).

[LinuX-TUX]

Geen idee hoe deze service van jou hierop gaat reageren. (Lees: hoe hij z'n netwerk kaart opneemt/interpreteerd alszijnde UP of AANWEZIG)

Goede kans dat hij het niet prettig vindt, daarom heb je ook de verschillende niveaus van opstarten bij linux z'n services. Eerst basics, niveau later alles wat ervan afhankelijk is.

Wat let je om het niet gewoon zo te doen:
• Service down
• ifconfig eth# down
• Sleep
• ifconfig eth# up
• Service start

???

[bobo1on1]

Het zou op zich moeten kunnen, maar niet als hij een socket probeert te binden op een interface die down is, als hij bind op alle interfaces kan het wel.

Je moet ook even uitkijken of hij zo niet het een en ander aan configuratie kwijt raakt, op Ubuntu bijvoorbeeld moet de gateway opnieuw ingesteld worden.

[ Voor 33% gewijzigd door bobo1on1 op 22-11-2008 20:39 ]

[frapex]

Huh? Je gaat daar je interface toch niet voor platgooien...
Gewoon het verkeer blocken met iptables voor een korte tijd?
Er zijn zelfs ratelimit rules te schrijven waarmee je het verkeer kan beperken.

[CyBeR]

Is dat progsel zelfgeschreven? Pas 't aan zodat 'ie pas na initialisatie z'n listening socket aanmaakt.

[mphilipp]

LinuX-TUX schreef op zaterdag 22 november 2008 @ 20:32:
Wat let je om het niet gewoon zo te doen:
• Service down
• ifconfig eth# down
• Sleep
• ifconfig eth# up
• Service start

Lijkt me hetzelfde resultaat geven. Het gaat juist om het starten

@frapex: ratelimit rules lijken we idd het meest geschikt. Ik ga dat eens proberen. Thnx!

[LinuX-TUX]

mphilipp schreef op zaterdag 22 november 2008 @ 21:16:
[...]

Lijkt me hetzelfde resultaat geven. Het gaat juist om het starten

@frapex: ratelimit rules lijken we idd het meest geschikt. Ik ga dat eens proberen. Thnx!

Dan lees je niet goed, ik start de service NADAT het netwerk echt up is IPV zodra het down is
Ben weer eens kortaf en verkouden. Je had het getest ?

Wie heeft die service geschreven en waarom laat het dan zoveel connecties open / idle / sleeping? Restarten van servers is een vieze workaround, nofi.

[ Voor 22% gewijzigd door LinuX-TUX op 22-11-2008 21:32 ]

[CyBeR]

LinuX-TUX schreef op zaterdag 22 november 2008 @ 21:27:
[...]

Dan lees je niet goed, ik start de service NADAT het netwerk echt up is IPV zodra het down is

Wat dus kansloos is. Je hebt dan niets aan het downbrengen van je netwerk. Dat werkt wel, het gaat om die service.

[frapex]

mphilipp schreef op zaterdag 22 november 2008 @ 21:16:
[...]

Lijkt me hetzelfde resultaat geven. Het gaat juist om het starten

@frapex: ratelimit rules lijken we idd het meest geschikt. Ik ga dat eens proberen. Thnx!

Als bonus uit mijn eigen firewall:

code:

# Limit rate to 5/sec, but also limit the rate to 2/sec per host
iptables -N LIMITFTP
iptables -A LIMITFTP -p tcp --dport 21 -m state --state NEW -m hashlimit --hashlimit 2/min --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name fw_ftp --hashlimit-htable-expire 600000 -j ACCEPT
iptables -A LIMITFTP -p tcp --dport 21 -m state --state NEW -m limit --limit 5/min --limit-burst 5 -j LOG --log-prefix "[FW] FTP flood: "
iptables -A LIMITFTP -p tcp --dport 21 -m state --state NEW -j REJECT --reject-with tcp-reset

[ Voor 3% gewijzigd door frapex op 22-11-2008 22:27 . Reden: correctie voorbeeld ]

[LinuX-TUX]

CyBeR schreef op zaterdag 22 november 2008 @ 21:31:
[...]


Wat dus kansloos is. Je hebt dan niets aan het downbrengen van je netwerk. Dat werkt wel, het gaat om die service.

Kansloos? Netwerk down en uppen refresht OOK de open idle en sleeping sessies die je kan bekijken met netstat -anp|grep <bin> (toch )

Die zitten hem in de weg bij het herstarten van de service toch. Correct me if I'm wrong

[CyBeR]

LinuX-TUX schreef op zaterdag 22 november 2008 @ 21:37:
[...]

Kansloos? Netwerk down en uppen refresht OOK de open idle en sleeping sessies die je kan bekijken met netstat -anp|grep <bin> (toch )

Die zitten hem in de weg bij het herstarten van de service toch. Correct me if I'm wrong

Ik had het idee dat nieuwe requests de initialisatie in de weg zitten. Wat dus overigens beter aangepast kan worden door 't programma eerst te laten initialiseren en dan pas netwerken, maar dat terzijde.

[mphilipp]

LinuX-TUX schreef op zaterdag 22 november 2008 @ 21:27:
[...]
Dan lees je niet goed, ik start de service NADAT het netwerk echt up is IPV zodra het down is
Ben weer eens kortaf en verkouden. Je had het getest ?

Wie heeft die service geschreven en waarom laat het dan zoveel connecties open / idle / sleeping? Restarten van servers is een vieze workaround, nofi.

Ooopss..ik had niet helemaal goed gelezen (bril op gehouden...). Ik las het andersom.

Wie die service geschreven heeft is niet zo spannend. Ik heb iig geen invloed op dat ding en zelf schrijven is geen optie. Als ik dat kon, had ik dit probleem niet. Punt is dat ie zich af en toe verslikt en ermee kapt. Niet zo erg, maar als ik 'm herstart, krijgt ie (volgens mij) de kans niet om goed te initialiseren, en start in een foute staat op. Dat wil ik voorkomen. Zo'n ratelimit lijkt me een goede optie. Ik kende dat nog niet, dus dat ga ik eens testen. Ik heb alleen geen echt testsysteem waar ik met die hoeveelheden kan testen. Dus dan maar met het live-systeem... Vandaar dat ik de knappe koppen even wilde raadplegen om een zo kansrijk mogelijke test te doen.

[message]Cyber schreef[/message]
Ik had het idee dat nieuwe requests de initialisatie in de weg zitten. Wat dus overigens beter aangepast kan worden door 't programma eerst te laten initialiseren en dan pas netwerken, maar dat terzijde.

De clients zijn 24/7 in de lucht en sturen elke 20sec iets naar de service die er iets mee moet en stuurt dan een antwoord terug. Die clients zijn nu redelijk talrijk en als de service ermee kapt, blijven zij zeuren. Als je 'm start, lijkt het erop dat ie meteen open staat voor connecties, terwijl ie ze nog niet kan afhandelen en zich vervolgens wéér verslikt. Alleen nu crashed ie niet, maar blijft in een foute staat doordraaien. En de clients krijgen geen antwoord.

[ Voor 23% gewijzigd door mphilipp op 23-11-2008 00:01 ]