[ Am sa fac topposting pentru a nu sterge totusi continutul mailului ] Raspunsul, pe scurt, este ca Cisco FWSM nu suporta SACK. Poate va mira ca o facilitate inventata acum 11 ani nu este implementata intr-un echipament din zilele noastre, dar se pare ca se intampla si la case mai mari...
De fapt SACK nu functioneaza daca pe FWSM a fost activata optiunea de a schimba in mod aleator numerele de secventa. Spre exemplu, daca A trimite pachetele numerotate 1000-2000, odata cu trecerea prin FWSM ele vor ajunge drept 1666-2666 la B. In cazul in care un pachet a fost pierdut, intervine mecanismul SACK si in loc sa fie retransmis intregul window, B trimite un pachet SACK in care spune ca pachetele 1666-2050 si 2052-2666 au fost corect receptionate. Partea proasta e ca FWSM-ul nu mai corecteaza numerele inapoi astfel incat A primeste SACK pentru pachete pe care nici macar nu le-a trimis !?! Pana ajung A si B din nou la intelegere bineinteles ca se consuma timp pretios si astfel rata de transfer scade dramatic. Workaround-urile sugerate de Cisco sunt: - dezactivarea optiunii de modificare a seq. no. - ceea ce e o idee proasta pentru ca tocmai asta e rolul FWSM-ului: imbuntatirea securitatii - dezactivarea SACK-ului pe server astfel incat sa nu mai foloseasca deloc optiunea asta. Nici asta nu e o solutie buna pentru ca SACK-ul a fost inventat tocmai pentru a creste eficienta in cazul unui mediu cu erori. Algoritmul de evitare a congestiei e si el important si are influenta asupra conexiunii pentru ca in functie de rata erorilor se modifica marimea window-ului si se ajunge uneori la o folosire ocazionala a SACK-ului. O observatie delicata pe care o mai pot face legata de aceasta problema ar fi "de ce Windows si FreeBSD functioneaza bine in aceleasi conditii desi au SACK activat ?". Raspunsul este simplu: "pentru ca desi optiunea este activa (sackON prezent la negocierea conexiunii) de fapt ea nu este deloc folosita in cazul aparitiei erorilor". Long live the Linux TCP stack ! Cool, eh ? Mihai On Thursday 10 May 2007 10:38:22 Mihai Maties wrote: > Salut, > > Odata cu instalarea unui Cisco FWSM [1] intr-un switch Catalyst 6500 am > observat o scadere dramatica a ratei de transfer de la un server aflat in > spatele acestui firewall. Eram pe cale sa chem un preot specialist in > exorcizare intrucat in urma mai multor teste nu am putut trage nicio > concluzie clara. > > Pentru ca m-am chinuit cu treaba asta ceva vreme si vreau sa-mi testez > (in)competenta va dau datele problemei, iar in cazul in care nimeni nu > gaseste explicatia pana la sfarsitul zilei am sa v-o prezint eu :) > > Se dau: > > A - serverul din spatele firewall-ului (eth gigabit) > B - un server de cealalta parte a FW (placa fast ethernet) > C - un laptop (si el de cealalta parte a FW - switch-ul este de 100Mbps) > > Rate de transfer obtinute cu optiunile default ale stivei TCP din sistemele > de operare respective: > > A.linux -> B - ~50 Mbps > A.linux -> C - ~35 Mbps > A.windows -> B,C - ~92 Mbps > A.freebsd -> B,C - ~92 Mbps > B, C -> A.* - ~92 Mbps > > In caz ca e cineva interesat, kernelul de linux de pe A este > 2.6.18-4-amd64, dar aceleasi perfomante le-am obtinut si cu 2.6.9 sau > 2.6.21. > > Sunt excluse problemele hardware pe A intrucat daca A.linux se scoate din > spatele FWSM-ului totul merge bine. > > Am inceput sa fac tuning la stiva TCP de pe A si am obtinut urmatoarele > rezultate: > > 1) schimband protocolul de evitare a congestiilor > (net.ipv4.tcp_congestion_control): > > A.linux.bic -> B - ~50 Mbps > A.linux.cubic -> B - ~50 Mbps > A.linux.reno -> B - ~91 Mbps > A.linux.westwood -> B - ~91 Mbps > ... > > > 2) dezactivand selective acknowledgements de pe A (net.ipv4.tcp_sack) > > A.linux.sack -> B - ~50 Mbps > A.linux.no_sack -> B - ~92 Mbps > A.linux.sack -> C - ~35 Mbps > A.linux.no_sack -> B - ~92 Mbps > > la adresa http://anubis.xcyb.org/fwsm/ am pus 4 capturi ale traficului > dintre A si B cu SACK activat/dezactivat din punct de vedere > sender/receiver. > > Windows-ul si FreeBSD-ul au SACK activat implicit asa ca nu am mai refacut > testele intrucat rata de transfer initiala era indeajuns de buna. > > 3) setand explicit bufferele de send/receive la o anumita valoare in > aplicatia cu care faceam teste am obtinut ~92 Mbps. Valoarea ideala a fost > stabilita experimental. > > In urma acestor teste si date pe care le-am oferit, care considerati ca e > problema ? Mentionez ca acest caz a ajuns la Cisco support si abia ei au > reusit sa ma lumineze. > > > Mihai > > [1] http://www.cisco.com/en/US/products/hw/modules/ps2706/ps4452/index.html > > PS: Ii rog pe cei carora le-am comunicat raspunsul sa nu-l divulge :) > > _______________________________________________ > RLUG mailing list > [email protected] > http://lists.lug.ro/mailman/listinfo/rlug _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
