syn ack "felgyorsítása"

Linux-kezdő

Probléma:

ügyfél --> tűzfal --> loadbalancer --> célgép1 v. célgép2

Számosságot nem tudok mondani, de zavaró mértékben előfordul az, hogy az ügyfél gépéről jönnek a SYN csomagok, de nem megy rájuk vissza a célgép1 v. célgép2 -ről SYN-ACK csomag.

Mérések szerint a SYN csomagok eljutnak a célgépekig, tehát nem korábban vesznek el.

Az ügyfél próbálkozik, próbálkozik aztán egyszercsak a SYN-jére kap SYN-ACK -t és mindenki boldog.

Feltételezve, h a mi szerverünk nem ad vissza időben SYN-ACK-t (és feltételezve, h ez előfordulhat) és nekünk kell ezt megoldani vhogy, mivel érdemes próbálkozni?

Köszi!

  • 1347 megtekintés

( apal v | 2010. 11. 23., k – 11:43 )

es a syn-ack az hol ve'sz el? a loadbalancernel is van valamifele nat, ott is lehet gond. nem ertek annyira ehhez, de kiprobalnam egy udp-alapu szolgaltatassal, hogy ott milyen gyakran vesznek el a csomagok.

( Tyra3l | 2010. 11. 23., k – 14:00 )

nem lehet, hogy egyik gep rosszul van configolva, es az oda route-olt kereseket eldobalja? (martian-nak nezi)
milyen loadbalancert hasznaltok amugy?

Tyrael

A fő kérdésem még mindig az, h mi okozhatja, h érkező SYN-re nem megy vissza izibe ACK és mivel lehet ezt elhárítani.
de ha jol ertem, akkor ez localhost-on is elojon? mi a szolgaltatas? csak mert ha mar belso halon (lebutitva/leszedve mindenfele lb-t) is jelentkezik, akkor inkabb arrafele kene szaglaszni. a celgepeken tuzfal? rosszul megirt/konfigolt szerver? barmi lehet itt.

localhostra direkt nem próbáltuk. biztos lehetne értelme, de jelen helyzetben nem megvalósítható. a LB és a cél gépek között figyelve a forgalmat látszik, h jön a SYN de nem megy vissza SYNACK. A localhost figyelése sokat ezen nem segítene.

tűzfal: nincs

> rosszul megirt/konfigolt szerver? barmi lehet itt.

igen, pontosan ez a kérdés. hogy esetleg tud-e vki OS/kernel szintű tippet adni.

Ehhez akkor köze nincs se az internetnek, se a tűzfalnak, se az LB-nek.
Ha egy notebookot dugnál a magában álló szerverre, akkor is ezt tapasztalnád.

Lehetséges indokok:
- aszimmetrikus ethernet duplexitás probléma
- a szerveren futó tűzfal eldobálja a csomagokat
- a szerveren futó program bindol, de nem listenel
- a szerveren futó program input queue-ja betelik (ehhez baromi sok connection kell), és a program nem szabadítja fel (mondjuk mert single-threaded, és valami lefoglalja)

> - aszimmetrikus ethernet duplexitás probléma

erről bővebben tudsz vmit mondani?
szerk: ha etherchannel/bonding -ra gondolsz, akkor az itt most nem játszik.

> - a szerveren futó tűzfal ...

nincs tűzfal és "csak" kb. 5-10% -nyi a hiba, de jelen helyzetben ez is elfogadhatatlan

> - a szerveren futó program bindol, de nem listenel

listenel, mert a kérések többségét kiszolgálja

> - a szerveren futó program input queue-ja betelik (ehhez baromi sok connection kell),
> és a program nem szabadítja fel (mondjuk mert single-threaded, és valami lefoglalja)

OS szinten jelentéktelen számú *_WAIT-es státuszú kapcsolat van és az ESTABLISHED-ek sincsenek sokan ( < 1000). Vannak nagyobb terheléssel lazán szambázó vasaink...

erről bővebben tudsz vmit mondani?

Összedugsz két gépet/switchet/routert/akármit etherneten, az egyik half duplexre, a másik full duplexre áll be. Ennek az lesz az eredménye, hogy az egyik doboz azt hiszi, hogy ő bármikor szólhat, nem kell megvárnia, hogy a másik éppen szünetet tartson. A másik doboz pedig azt gondolja, hogy ha a túloldalsó beszél, akkor ő nem beszélhet, és ha meghallja a másikat, miközben beszél, akkor meg kell azonnal szakítania a csomag küldését. Ez látványosan működésképtelen tud lenni.
Felismerése: a half duplex oldalon a 'late collision' nevű counter nem 0. Általában ha az egyik oldal half duplex, az már eleve gyanús, mert mindenkinek full duplexnek kéne lennie, ha nem hubot használsz. Ha akármelyik Rx vagy Tx error counter nem nulla, az szintén gyanús.

- a szerveren futó program input queue-ja betelik (ehhez baromi sok connection kell),
és a program nem szabadítja fel (mondjuk mert single-threaded, és valami lefoglalja)

OS szinten jelentéktelen számú *_WAIT-es státuszú kapcsolat van és az ESTABLISHED-ek sincsenek sokan ( < 1000). Vannak nagyobb terheléssel lazán szambázó vasaink...

ezt az esetet (meg a tűzfalas előzőét is) a SYN_RCVD állapotban levő sok connection jelzi.

( egeresz | 2010. 11. 23., k – 14:30 )

a gep tulterhelt (cpu)
a gep tulterhelt (halokartya, nezz ra a dobott/error szamra)
tul keves az aktualis syn queu
tul kicsi az aktualis nyitott kapcsolatok megengedett szama (linux eseten a conntrack tud csunya trefat jatszani, high-load ip szerverre ne rakj conntracket)

kapcsold be a synccokie funkciot, ha tudja az oprendszer

egyebkent, a syn-ack azonnal visszajon, ahogy a tcp stackban megtortenhet a bejegyzes. ez viszonylag magas prioritassal megy, valami durva malor lehet, ha megsem.

Mennyi az aktiv tcp kapcsolatok szama? 


netstat --inet -an | awk '/^tcp/{print $6}' | sort | uniq -c

$ netstat --inet -an | awk '/^tcp/{print $6}' | sort | uniq -c
695 ESTABLISHED
16 LISTEN

$ cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024

$ cat /proc/sys/net/ipv4/tcp_synack_retries
5

$ cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
1614

$ cat proc/sys/net/ipv4/netfilter/ip_conntrack_max
conntack nincs

695 ESTABLISHED
kicsit soknak tunik. ha csak egy alkalmazas (processz, akar tobbszalon is) veszi fel ezt a sok kapcsolatot akkor lehet hogy egy-egy idopillanatban a processz altal maximalisan megnyithato filedescriptorok sza'ma meghaladja meghaladja az alapertelmezett 1024-et? (lasd me'g `ulimit -n`) ha a processz ma'st (mezei fileokat, pipe-okat, unix socket izeket) is nyitogat, akkor ebbe bele lehet futni viszonylag konnyen.

mondjuk kerdes hogy ipstack/inode szinten mikor kerul lefoglala'sra az filedescriptor maga. ha a peer a syn-t kuldi, vagy amikor az ack-ot? ha csak ezutobbiban, akkor nem biztos hogy itt van a gond.

$ ulimit -n
65536

$ cat /proc/sys/fs/file-nr
3060 0 6815744

---

> mondjuk kerdes hogy ipstack/inode szinten mikor kerul lefoglala'sra
> az filedescriptor maga. ha a peer a syn-t kuldi, vagy amikor az ack-ot?
> ha csak ezutobbiban, akkor nem biztos hogy itt van a gond.

ez jó kérdés, nem tudom...