Cisco EPC3925 TCP timeout: 5 perc

Hálózati eszközök

Sziasztok!

T-Home telepített nálunk egy a címben említett csodát az IPTV-hez, amivel a következő problémáim adódtak:
- nagyon alacsony a maximum kapcsolatok száma ~1000 lehet szerintem
- nagyon alacsony a tcp timeout: 5 perc

A tv kábel eléggé a lakás sarkában jön be, eddíg ott volt a kábelmodem és egy dd-wrt-t futtató router-hez mentgy tőle a kábel. A legegyszerűbbnek az tűnt hogy a tv-s boxokat rákötöm az új kütyüre, és összekábelezem a régi routerrel azt dmz-nek beállítva. Így a cisco elintézi a qos-t a tv-nek és minden más ugyan úgy működik mint előtte...

Először nem tudtam mi okozza, de aztán kiderült hogy amint valaki elindít egy torrentet a házban gyakorlatilag leáll az internet... mint kiderült a kedves cisco összesen kb 1000 kapcsolatot hajlandó maximum kezelni. Ezt onnan tudom hogy a mögötte lévő dd-wrt kiírja az aktuális kapcsolatok számát (ő 4096-ra van limitálva)

Természetesen beállítani se lehet a limitet, viszont a kapcsolat figyelést sikerült az spi firewall opció kikapcsolásával kiütnöm, és megszüntek a mágikus leállások... és minden amit védeni akarok a dd-wrt mögött van így nyugodtan alszok :)

A másik problémám hogy kikisérleteztem :) 5 perc után dobja a tcp kapcsolatokat.. Namármost ennek nem kellett volna megszünnie a kapcsolat figyelés kikapcsolásával? Van valami ötletetek hogy lehetne ezen segíteni? Voltak másnak ilyen gondjai ezzel a kütyüvel?

( ufoka | 2011. 01. 28., p – 14:55 )

HUP :)

Ideiglenes megoldásként egyenlőre a gépemen beállítottam az ld-t hogy a libkeepalive.so-t [1] minden programhoz preloadolja, és a sysctl.conf-ba megadtam default keepalive időnek 3 percet. Így most stabilak a kapcsolatok.

[1]: http://libkeepalive.sourceforge.net/

Szia!

Ha minden igaz, akkor ez összefügg azzal a hiba jelenséggel, hogy pár perc után (amit Én nem 5-nek, hanem 2-3-nak érzek) behalnak az ssh termináljaim?
Sőt, az Sqlyog programom is, amelynek állandó kapcsolat kell, de nem bizergálom 2 percenként?

Magunk közt szólva hatalmas trágya az eszköz. Egy TP-Link WR1043 routert használtam, amíg ki nem hozták a T-Home által csak modemnek hívott modem-routert.
Még a szerelő se nagyon vágta, hogy 2 in 1 megoldással rukkoltak elő.
Nagyon rossz a wifi-je, össze-vissza kellett különféle, a neten olvasott trükköket alkalmaznom, amíg végre össze nem jött a legjobb kombináció ahhoz, hogy most már 1 percen belül képes a feleségem laptopja kapcsolódni, és az esetek 90%-ban nem is vágja ki Őt pár perc után. A LAN-os oldala is többször krepál be, vagy nem lehet elérni az admint, és szerintem elég kevés dolgot lehet konfigurálni,

Tény, hogy a TP-Link ezerszer jobb, felhasználóbarátabb, és stabilabb. A Cisco név nagyon leszerepelt előttem ...

Visszatérve az eredeti témához:
gondoltam Én is arra, hogy a két routert összekötöm, a Cisco szolgálná ki a két settopboxot, míg az összes többi kütyü a TP-Linkről menne, viszont a Te ideiglenes megoldásod egy hibalehetőséggel kevesebbet tartalmaz, és gyorsabb is, viszont nem tiszta a lényege. Ha jól értem, a libkeepalive library segítségével egy nyitott kapcsolat nyitva tartható oly módon, hogy pl. 3 percenként küld egy packetet a távoli gépnek? (legalábbis ezt vettem le az oldalukról)

Nos, időközben sikerült használatba hoznom a keepalive funkciót. Nem a sourceforge-os megoldást használom, hanem a kernel által nyújtott lehetőségeket (Ubuntu 10.10)
Itt van egy remek leírás: TCP keepalive Howto

Ennek alapján futásidőben beállítható az alábbi parancsokkal:
sysctl -w net.ipv4.tcp_keepalive_time=180 net.ipv4.tcp_keepalive_intvl=60 net.ipv4.tcp_keepalive_probes=20

Ha azt akarod, hogy újraindításkor is ezek legyenek az alapértelmezett értékek, az /etc/sysctl.d könyvtárban található valamelyik fájlba (vagy egy újonnan létrehozottba) írd be szintén:

net.ipv4.tcp_keepalive_time=180
net.ipv4.tcp_keepalive_intvl=60
net.ipv4.tcp_keepalive_probes=20

A beállítások ellenőrzése:
sysctl net.ipv4.tcp_keepalive_time net.ipv4.tcp_keepalive_intvl net.ipv4.tcp_keepalive_probes
vagy például:
cat /proc/sys/net/ipv4/tcp_keepalive_time

Az biztos, hogy 5 perc sok volt, viszont a keepalive miatt legalább a terminálban érkezett egy 'broken pipe' üzenet, azaz volt infóm, hogy történt valami. Idáig ez sem volt.
Levittem a javasolt 3 percre, és lám, máris működik.

Ezúton is köszönöm Ufókának, nélküle lövésem se lett volna a hiba okáról! (azon kívül, hogy egy nagy kalap trutymó ez a modem-router)

ehh, kicsit nem figyelek és hogy megindult ez a szál :)
Szval örülök hogy segíthettem!

Egy apró hozzáfűznivaló, hogy az én megoldásom is alapvetően a kernel-ben állítja be a keepalive-ot, csak én azt olvastam (nem próbáltam ki minden progira) amikor elkezdtem belemászni a témába, hogy a programoknak külön kérniük kell a shocket-re a keepalive-ot. Gondolom az ssh amivel elsősorban én is szívtam, ezt meg is teszi, de biztos ami biztos én feltelepítettem a libkeepalive.so-t. Ez minden app-hoz preload-olva arra való hogy felüldefiniálja azt a glibc hívást, ami a socket-et megnyitja, és minden glibc program által megnyitott shocket-en beállítja a keepalive-ot.

Sajnos a termékek háta mögé nagyon nem látok, nem ismerem a terméknevek mögötti nagyvállalati (és minőségi) összefüggéseket, múltakat.
Tulajdonképpen mint laikus a Cisco márkanévtől legalább olyan működést vártam, mint amilyet TP-Link-től kaptam.

Az a röhej, hogy például a wifi esetében elég lett volna egy sokkal barátságosabb default beállításokal forgalomba hozni.
Például ezeket állítottam be utólag, és innentől működik stabilan a wifis rész:

- Wireless configuration: Manual
- SPI Firewall : disable
- MTU Size: 1500
- IGMP Proxy: disable

Mai napig nemtom, hogy melyik beállítás volt a hasznos, és már nincs kedvem próbálgatni. Sok órám elment a kereséssel.
Ha megpróbáltok rákeresni a neten erre a modemre, szinte az összes találat a problémákról szól. Ezeken az oldalakon aztán lehetett találni elég javaslatot, és a fentiekre leszűkítve sikerült használható szintre hozni.

Az MTU méret 0 volt, erről csak egy helyen olvastam, viszont a tűzfal és a proxy kikapcsolását erősen javasolták. A Wireless csatlakozáshoz Én választottam a manuálisat.

Az a röhej, hogy például a wifi esetében elég lett volna egy sokkal barátságosabb default beállításokal forgalomba hozni.

Én bevallom, nem értem egészen a szituációt.

Ha bementél egy boltba, és vettél egy dobozt, akkor miért pont ezt választottad? Azért ilyen vásárlás előtt körbenézünk a neten.

Ha nem a boltban vetted, hanem a T-* hozta, de megvetted tőlük (mert annyira mondták, hogy milyen fasza lesz a szolgáltatáshoz), akkor miért a gyártóra panaszkodsz, miért nem a szar szolgáltatódra, aki szart sózott rád?

Ha meg nem is vetted meg, hanem a T-* vágta hozzád (a szolgáltatás árába építve), akkor miért a gyártóra panaszkodsz, miért nem a szar szolgáltatódra, aki nem állította be rendesen a szolgáltatásához?

Az utolsó szitu történt: igénybe akartam venni az IPTV-t, amire a T-* hozzám vágta az új modemet (routerrel egybeépítve), mondván csak azzal használhatom. Abban igazad van, hogy a T-* normálisabban is konfigolhatta volna, de a T-* gyalázása (ami napi szintű lehetne) már tényleg nem ide való.

Viszont az eszköz stabilitása és használhatósága csak a Cisco-ra tartozik, márpedig ezek kissé hiányosak. Hetente 3-4 reboot, admin nem elérhető, LAN eszköz nem tud kapcsolódni, keepalive probléma (és persze most már az egyik settopbox se tud kapcsolódni).

Ha esetleg azt gondolod, hogy a Cisco márkanevet pocskondiázom, akkor nemtom mit mondjak, mert magam sem tudom, hogy mit érzek. Igaz, hogy egy fillért sem adtam a modemért (bár a szolgáltatást fizetem havonta), egy laikus (mint Én) azt gondolja, hogy ha fizet, akkor legyen hozzá megfelelő teljesítés, nem pedig a mindennapos mérgelődés, szenvedés, és időtöltés a problémákkal ahelyett, hogy fontosabb dolgokkal foglalkozna.

A TP-Link mellett ilyesmi fel sem merült. A Cisco számomra erős márkanév volt (lehet, hogy csak a jó marketingnek köszönhetően), de a fentiek miatt inkább egyelőre visszasorolom a vállalati szegmensbe, és az otthoni felhasználói szinten inkább nem is gondolok rá.

( kea | 2012. 11. 07., sze – 12:20 )

Hozzánk tegnap este került be a cisco cucc (egy teljes hét üzemszünet után, mert a régi rézdrótról a tévékábelre való átállást a T-Home a jelek szerint nem tudja zökkenőmentesen bonyolítani).

Alapjáraton három ssh alagút üzemel:
/usr/bin/ssh -f -N -L 1143:localhost:143
mintára, IMAP, SMTP és http proxy elérése céljából.

Na, ezek elkezdtek igen gyorsan megdögleni, nem mértem, de kb. 2-3 perc lehetett. Az /etc/ssh/ssh_config file-ban az alábbi kiegészítéseket tettem a távoli gép vonatkozásában:

ServerAliveInterval=5
ServerAliveCountMax=12
Port=8192
TCPKeepAlive=no

Első benyomásaim szerint látványos javulás történt, az alagutak eddig még nem omlottak be.

Üdv:
KEA.