UPC kontra SSH

Web, mail, IRC, IM, hálózatok

Valamilyen sajátos csomagszűrést használ a UPC?
Mert a fix IP címes üzleti előfizetés ellenére rendszeresen megszakad az SSH kapcsolat a UPC internetes gépekkel.

  • 7610 megtekintés

Ebben az a furcsa, hogy a komplett infrastruktúra korábban Digi hálózatról problémamentesen ment. Gyakorlatilag semmi nem változott. Ugyanaz a router és mögötte ugyanazok a gépek mentek UPC hálózatra. A routeren PPPoE lett átírva dhcp-re, mert a UPC-nél az van. Ezt leszámítva semmi nem lett átállítva.
Wifi csak az én oldalamon van a gép a router között, de sehol máshol nincs ilyen probléma az ssh kapcsolattal. Ezért feltételezem, hogy a UPC lehet a hibafaktor.

( gelei v | 2015. 01. 21., sze – 21:23 )

> Valamilyen sajátos csomagszűrést használ a UPC?

Nem, semmi ilyesmit.

( wpeople v | 2015. 01. 21., sze – 21:25 )

van végpont ahol előfordul, van ahol nem. szerintem jelents le hibára.

( oszfer | 2015. 01. 21., sze – 21:37 )

Sokan szidják az UPC kókányságát: http://itcafe.hu/tema/upc_magyarorszag_kft/hsz_10901-10950.html

Sajnos mi is ezzel küzdünk, a nyomorult kábelnetes modemjük, mióta 250 Mbites kapcsolatra váltottunk, csak NAT-olva működik (korábban bridge módban nem bontotta az élő kapcsolatokat).

Megoldás, tudtommal, nincs.

Az SSH-t ugyan keepalive csomagokkal életben lehet tartani, a HTTP meg eleve észre sem veszi (valószínűleg a kedves UPC azt gondolja, hogy csak a HTTP fontos). Viszont a levelezőprogramokkal (IMAP/SMTP) folyamatos az agybaj.

Vátottunk 250-ről 500-ra, az üzleti 500 -as csomagon újra bridge módban van a kínai csodamodem, előtte a Cisco bizony NAT-olt, ez megint nem.
Az SSH ugyanugy f*s, sőt még rosszabb, most úgy tűnik az SSH Keepalive beállítása sem segít :(
Egy idő után ez van ha nem nyúlok a prompthoz, de vaolt hogy úgy dobott ki, hogy épp csináltam valamit és otthagyta konzol nélkül a processzemet. valami nagyon nem jó így.
Timeout, server *****.com not responding.

( ncc1701 | 2015. 01. 21., sze – 21:39 )

Ugyan ssh-t nem próbáltam, h szakad-e, vagy sem, de vpn elég stabil.

( gergelykiss | 2015. 01. 21., sze – 21:53 )

UPC, Budapest XI. ker - SSH sosem dobál le, ellenben az OpenVPN-kapcsolatok fél perccel kapcsolódás után szinte mindig lebontanak (akkor is, ha van aktivitás). Újracsatlakozás után akár órákig működik gond nélkül, akkor is ha nem forgalmazok semmi adatot a tunnel-en. Sosem értettem, miért van ez, de annyira nem zavar, hogy utánajárjak.

Technicolor (aka Thomson) modemet kaptam, korábban ő volt a gateway, de már egy ideje csak szimpla bridge-ként használom, és így is előjön a jelenség. Rejtélyes...

( BandiG v | 2015. 01. 21., sze – 22:13 )

Osregi sztori, a megoldas (openssh eseten):

ssh -oServerAliveInterval=20 user@server

Persze ez mehet konfig fileba is...

( Benjamin v | 2015. 02. 05., cs – 15:58 )

Nekem is volt ilyen gondom, UPC Technicolor modem(TC7200) bridge üzemmódban, pár perc inaktivitás után dobta az aktív tcp kapcsolatokat. Ügyfélszolgálatot felhívtam, elmondtam a panaszom, kapcsoltak tech kollégát, ő sem értette szerintem mi a gondom, aztán abban maradtunk, hogy biztosan rossz a modem, küldenek valakit hogy kicserélje.
Most egy Ubee műanyag doboz van, ezzel megszűnt a probléma.

Szerintem próbáld te is ezt az utat, bár üzleti felhasználókhoz elvileg Cisco modem kerül, korábban olyannal is volt dolgom, de nem tapasztaltam a jelenséget bridge módban.

-----
“Firefox, you say? No I don't play Pokémon”

( Endruu | 2015. 02. 05., cs – 16:59 )

Probald ki, hogy az ssh portot elrakod a 22-rol mondjuk 57822-re (barmi, csak random) - anno egy pirosbetus mobilszolgaltato L7 csomagszurese szeretett tul boszen szurni es ez volt a workaround.

( Fisher v | 2015. 02. 06., p – 13:28 )

Adalék, talán segítség is, hogy most ssh-val bejelentkeztem meg vissza meg ide-oda és elmentem ebédelni. Az összes session életben maradt, TCPKeepAlive yes mellett. Szóval aligha globális UPC probléma.

( crypton | 2015. 02. 24., k – 11:44 )

Három hét szenvedés és több mérés, DOCSIS RF mérés, debugging, tcpdump elemzése, UPC részére elküldés és várakozás után az derült ki hogy nagy valószínűséggel a csodás kínai Hitron modem eldobálja a TCP kapcsolatokat, random - tehát nem mindet egy időben, hanem tetszőlegeset akár ugyanoda nyitott sessionök küzül is - és a TCP kapcsolatok eldobálása sokkal gyakoribb mikor többen használjuk mint mondjuk hétvégén. A dolog nem csak az SSH-t érinti, hanem Skype, XMPP, HTTP kapcsolatokat is. Minden TCP alapú kapcsolatot. Szóval valamilyen szoftveres / hardveres probléma van a Hitron modemekkel. Elképzelhető hogy nem tudják lekezelni a sok párhuzamosan nyitott kapcsolatot. Ez abból is látszani vélik, hogy újraindítás után jó egy darabig, de idővel egyre használhatatlanabb lesz a modem, egy nap után egy weblap betöltése közben is megszakad a TCP, gyakporlatilag használhatatlanná válik a net, míg a modemen keresztül nyitott UDP OpenVPN nagyszerűen működik (kis lassulás tapasztalható).
A UPC mást nem tud adni 500-as csomaghoz, ezért kénytelenek vagyunk visszaváltani 250-es csomagra és a "stabilan" működő (legalább is a TCP kapcsolatokat nem eldobáló) előző Cisco modemre.
Az a konklúzió ebből, hogy a kínai Hitron modemek ugyan mérések alapján is tudják a 250Mbit feleti sebességeket kezelni, de sajnos a sok párhuzamos TCP sessiöntől meghalnak, valószínűleg a gyenge CPU/memória/NAT/tervezés hiánya miatt.

Szofisztikáltabb eszközöknél láttunk már olyat, hogy vagy azért, mert valaki lendületből volt ügyes: problémás -- egyébként udp, radius -- sessionöknél kivette a definícióból az idle-timeoutot, az eszköz defaultja meg nulla volt, aztán az idők folyamán feltelt ilyen szarokkal a session tábla, illetve busy cuccoknál olyat is láttunk, hogy a direkt égbe állított timeoutok miatt telt fel ilyesmi (megspékelve némi szarul implementált monitoringgal, ami hagyott egy rakás half open sessiont), és akkor nem nyitott újat. Aztán nyilván a felszabadulások függvényében volt ilyen hol megy, hol nem érzés. Mondjuk az nem dobált el kapcsolatot random, de persze nem is kínai vacak volt. De azért ha bele lehet nézni a modem beállításaiba meg diagnosztikájába, lehet, hogy meg lehet találni a gondot, persze csak ha még nem ment el a hajó.

Nem torrentezik "senki" (nincs tiltva, akár lehet is), kis csapat vagyunk csak épp mindenünk a "clodban" van, szóval eléág intenzív a net használata. Btw, még ha torrenteznénk is, szvsz. akkor is el kellene bírnia egy 500-as WAN-al rendelkező routernek/modemnek a pár ezer párhuzamos TCP sessiont probléma nélkül.

Koszi a leirast, es Zellernek is, hogy idevezetett
http://hup.hu/node/128012?comments_per_page=9999#comment-1841041

Egy darabig csak ugy hetente halt le, de most kb. egy honapja szinte naponta :(
Mi is visszakertuk a regi Cisco modemet, azota nincs gond.
Vagy 30 ember vegre rendesen tud dolgozni....

En csak egyvalamit nem ertek: eredetileg router modban hasznaltuk, teljes DMZ-vel. Megprobaltuk bridge modba atrakni, akkor is ugyanezt produkalta. Ha bridge, akkor ugye (elvileg) csak egy egyszeru erosito vagy hasonlo maximum, se tcp, se ip szinten nem mukodik, csak mint egy modem, a kabelen jovo analog jelet max. atalakitja diitalisra, vagy ennyit sem. _Elvileg_ koze sem lehet a tcp kapcsolatokhoz, nem natol, szoval a fenti gond nem johetne elo, ha csak egy kis router lenne bridge modban.

A problemak viszont ugynugy elojottek. Lehet, hogy tokmindegy milyen modban hasznalod, mert egyszeruen hw szinten olyan gagyi, hogy maximum macskadobalasra alkalmas ?

--
http://www.micros~1
Rekurzió: lásd rekurzió.

( tovis v | 2015. 02. 25., sze – 14:03 )

subscribe

* Én egy indián vagyok. Minden indián hazudik.

( crypton | 2015. 02. 26., cs – 09:22 )

A UPC saga folytatódik: már másodszorra vártam hogy jön a szerelő és kicseréli a Hitron -t (este bentmaradtam, me bejöttem reggel korábban) a régi Cisco-nkra. Pesze nem jött egyszer sem. Hívtam őket mindkét esetben, természetesen máshol csörgött, más vette fel, és csak pislogtak hogy "a rencerük visszadobta a munkalapot, mert a Hitront nem kell cserélni, elviszi a 250-et". Hiába mondtam nnekik hogy nem ez a baj, csak pislognak mint a vaktyúk. Az agyam kezd eldurranni tőlük. Direkt azért váltottam vissza, hogy eltakaítsák innét ezt a szemét kínai vackot, hitegettek mikor visszavátottunk hogy le fogják cserélni váltás után, erre most meg megragad a dolog a technikusoknál, hogy nem lehet. Áááááááááá

csak egy kis adalék ahhoz, hogy mi mehet a UPC-nél:

ma pontosan 3 hete és 1 napja felhívtuk a UPC-t, hogy szeretnénk üzleti internetet egy irodába. szuper nagyon örülnek, 2-3 napon belül be tudják kötni, mondjam az adatokat. címhez érünk, visszakérdeznek, A vagy B lépcsőház? mondom sajnos erre nem tudok válaszolni, a bérleti szerződésben sem szerepel ilyen, de megkérdezem az üzemeltetőt, és jelentkezem másnap. ó, majd ők visszahívnak, hogy ugyanahhoz az ügyintézőhöz kerüljek.
másnap nem hívtak, rá egy napra felhívtam őket én, elmondtam, hogy az üzemeltető sem tud A és B lépcsőházról. de az ő rendszerükben így szerepel az irodaház, nincs mit tenni, 4-5 munkanapon belül kiküldenek valakit felmérni, aztán utána majd valakit külön, aki beköti (a bekötés 2-3 munkanap lett volna, erre azt mondták más alvállalkozó. ok). azt nem lehetne, hogy kijönnek bekötni, és itt helyben majd kitalálják, hogy milyen címre írjuk a szerződést? azt nem, mert lehet nem is tudnak oda intertetet bekötni, "fel kell mérni"!
eltelt másfél hét, hírüket sem hallottuk, felhívtuk őket újra, hogy mégis mi a helyzet. azt mondják látják, hogy elindult a felmérési folyamat, akkor milyen netet szeretnék, és melyik épületbe. mély levegő, udvarias hangnem, hölgyem, pontosan arról szól a felmérés, hogy megmondják, hogy ez az önök rendszerében az A vagy B épület, mert senki más nem különbözteti meg ezt látszólag. akkor most már biztosan hamarosan érkeznek, elnézést kér.
másnap csörög a telefon, tiszteletem, a upc-től telefonálok, úgy látom a rendszerben önök internetet szeretnének beköttetni, melyik csomagot, pontosan milyen címre... (nem viccelek)
gondoltam, mielőtt agyvérzést kapok, átadom a probléma menedzselését másnak a cégen belül. úgy tudom a mai álláspont az, hogy megrendeltünk két szolgáltatást az A és B épületbe is külön-külön, aztán az egyiket majd sajnos nem fogják tudni kiépíteni. nevetséges.

fun fact: a kábel ott lóg a falból, és tudjuk, hogy az előző bérlőnek is UPC volt bekötve.

( seferbt v | 2015. 02. 26., cs – 15:11 )

UPC üzleti szolgáltatásairól tudunk valamit? :)

Konkrétan az érdekelne, hogy az is ilyen fosch-e, mint a lakossági szolgáltatásuk, és halálba fogom szopni magam velük, vagy esetleg van rá remény, hogy természetes lesz, hogy a net az VAN, mint a víz meg az áram?
Egyik helyen (Bp. 12. ker.)ők voltak azok, akik egy ajánlatkérésre egyáltalán reagáltak, a T-nek 1,5 hét alatt sem sikerült, a többieknek meg a környéken nincs hálózat. :/ Nesze neked piaci verseny...

Szerk: légkábeles optikát vagy mikrót tudnának adni, 50Mbps körüli sávszélt kértem tőlük lefelé és felfelé is.

Az üzleti szolgáltatásukkal is jelentkeznek ugyanezek a problémák, igazából nincs biztosítás arra, hogy az "üzleti" csomag jelent annyi stabilitást pluszban, amennyi egyébként elvárható lenne. Ami biztos, hogy túl nagy csomagra nem érdemes előfizetni (250, 500), mert nem fogja elbírni a modem/router, amit biztosítanak.

azért ne keverjük a FiberPower Business-t és a Business Internet csomagokat, főleg ne a médiát.
Amennyiben a média közös (koax) úgy ha sz*r van a palacsintában, mindenkire kihat válogatás nélkül.
(értsd egy vacak TV ami visszapofázik a hálózatra, etc)

Ha optikai (esetleg mikró) kapcsolatot veszel igénybe, nagyobb az SLA (talán 98% vs 99.5% ?)
ha nincs vágás (esetleg hibás metro-ethernet switch) akkor nincs gubanc. Ha ilyen kapacitású mikrón kapnád, akkor jó eséllyel pont-pont a minőség ott is jó lehet (bár ha nem túl nagy a különbség, én az üveget kérném)

( crypton | 2015. 02. 26., cs – 19:01 )

Végül kicserélték az előző Cisco-ra a Hitront, kemény menet volt, de most stabil a net azóta. (Btw. Üzleti 250, Cisco 3925) A technikus mondta hogy alapjában véve elégedettek a vevők a Hitronnal, ezért nem érti miért kell a lassabb Cisco nekünk. Mikor elmondtam neki a problémánkat, azt mondta "mindent értek" majd elmesélte hogy az elején mekkora szívások voltak a Hitronnal es szerinte is maximum otthoni felhasznalasra jo par userig.