Ugrás a tartalomhoz
  • Szeretne hasonló avatart használni? A profilképként felhasználható avatarokat az alábbi linkről tudja letölteni.

    image.jpegimage.jpegimage.jpegimage.jpegimage.jpegimage.jpeg

Gergely Egerváry

Tag
  • Tartalmak

    5
  • Csatlakozás időpontja

  • Utolsó látogatás

Profil megtekintések

Nem engedélyezted ezt a funkciót, ezért nem látod, hogy ki tekintette meg a profilodat a közelmúltban.

Gergely Egerváry eredményei

  1. Gergely Egerváry

    Wifi sebesség

    Szia, a Telekom csomagban lévő 300 megabites letöltési sebesség elvileg elérhető, sőt, mivel a hálózati profilt szokás egy kicsit magasabbra korlátozni, az is lehet, hogy (gigabites ethernet porton csatlakozva) valamivel 300 megabit feletti értékeket is tudsz mérni. A WiFi esetén viszont egészen más a helyzet. Ha a WiFi kártyára az van írva, hogy 300 megabit... az valójában nem az a 300 megabit, amire Te gondolsz. Az egy olyan, elméleti szintű sebesség, amit gyakorlatban megközelíteni sem tudsz. Ez nem "hiba", hanem "ez ilyen". Ez a WiFi működési elvéből, az általa használt jel-modulációból és protokollból ered. Úgy szoktunk számolni, hogy tökéletes jelerősség (szakszerűbben: jel-zaj arány) esetén nagyjából a fele, vagy valamivel több, mint a fele érhető el. Ha egy 300 megás WiFi eszközzel 150 megabitet, vagy valamivel még többet ténylegesen ki tudsz forgalmazni, az egy csodálatosan jó érték. A jel-zaj arány viszont gyakran nem tökéletes, pláne a 2,4GHz-es sávban. Az 50-70 megabit körüli mért értéket tipikusnak lehet nevezni. Tényleges 300 megabitet a jelenleg kapható eszközökkel csak 5GHz-es frekvencia sávban, "AC"-s protokollal lehet elérni, leginkább olyan WiFi eszközzel, amire legalább 700-900 megabit van írva a katalógusban.
  2. Szia, a tunnelben közlekedő adatok nagy része alkalmazás-szinten (Layer 7) már titkosítva van. Az érzékenynek nevezhető adatok mind. Ha maga a tunnel is titkosítva van, akkor az nagyrészt kétszeres titkosítást jelent. A kétszeres titkosítás első hallásra nem lenne nagy baj (a biztonságot nem lehet eléggé fokozni) ugyanakkor a titkosítás-nélküliségnek is megvan a maga oka: - a plusz titkosítás növeli a késleltetést (latency) és jittert okoz, amit pl. a VoIP határozottan utál, - a plusz titkosítás további 50-80 bájtot ad az IP fejlécekhez, így borzasztó alacsony lesz az MTU, amit az UDP alapú szolgáltatások egy része nem tolerál, - gigabites kapcsolatról beszélünk, aminek a titkosításával egy felsőbb kategóriás router is vért izzad... sőt, meg sem tudja csinálni... az én routerem kb. 430 megabitnél vérzik el teljesen, - van olyan tunnelem, aminek a túlvégén olyan partner van, akinek a rendszere nem támogat titkosítást, azzal nem tudok mit kezdeni. Ebből leginkább a legutolsó jelenti most a problémát. Igazából a díjcsomag-váltással én arra számítottam, hogy a sávszélesség profil módosításán túl más nem fog történni. Ehhez képest, mintha egy teljesen más infrastruktúrára kerültem volna. üdv.
  3. Gergely Egerváry

    Sagemcom 5655 probléma

    Szia, a részletek ismerete nélkül csak tippelni tudok. Az IPTV úgynevezett multicast technológiát használ, aminek a korrekt kezeléséhez menedzselhető switchek szükségesek. (Pontosabban: olyan switch kell, ami képes a multicast IGMP nevű protokolljának kezelésére... ami leginkább csak menedzselhető switchekben van.) Ha neked nem menedzselhető switcheid vannak, akkor azok a multicast forgalmat broadcasttá alakítják, ami nem optimális, túlterheli/bedugítja a hálózatot. Ezt normális esetben - alacsony hálózati forgalom mellett - nem feltétlenül veszed észre, de ha mellette elkezdesz másolni a gépek között "ahogy a csövön kifér", akkor annak már csúnya hatásai lehetnek. Kérlek próbáld ki a másolást úgy, hogy az IPTV nincs használatban. Akkor elvileg nem kellene lerohadnia a hálózatnak. További gebaszt okozhat még az ethernet "flow control" technológiája, ami nem menedzselhető switchek esetén fixen be van kapcsolva, és nem tudsz ellene mit tenni. A flow control rém rondán le tudja rohasztani a hálózatot, ha eltérő sebességű eszközök vannak a hálózatban. Megoldási javaslat: próbáld szeparálni egymástól az IPTV-t és a nem menedzselhető switcheket a hálózatban. üdv.
  4. Gergely Egerváry

    Sebesség probléma 2000/500 !

    Szia, két darab 1 gigás ethernet link aggregációja nem jelenti azt, hogy egy adatfolyammal tudsz 2 gigát forgalmazni. Egy adatfolyam soha nem fog 1 gigabit fölé menni. Egy adatfolyam csak egy hálókártyán tud menni. Vagy egyiken, vagy másikon. Az aggregáció csak szétosztja az egyes adatfolyamok forgalmát a kártyák között. Csak több adatfolyammal (pl. több szálas letöltés) tudod kihasználni a két gigabitet, és azzal is csak akkor, ha a szétosztás eredményeképp az egyes adatfolyamok más és más kártyára esnek. (Ez függ a szétosztás módjától, lásd: Layer 2, Layer 3, Layer 4 szintű szétosztás.) Létezik olyan, nem szabványos(!) ethernet aggregálási technológia, ami képes egy adatfolyamon is két gigát forgalmazni azon az elven, hogy az egyes adatcsomagokat felváltva küldi a két kártya között, de ehhez a kábel mindkét végén olyan eszközre van szükség, ami ezt tudja. Pl. Linux alapú eszközzel tudsz ilyet csinálni. A dolog ráadásul nem is túl jó, mert ennek a korrekt működéséhez az kellene, hogy a felváltva elküldött adatcsomagok jó sorrendben érkezzenek meg a túloldalra, márpedig két független összeköttetés (két hálókártya és kábel) esetén ezt semmi sem garantálja.
  5. Sziasztok... vannak itt Telekom hálózatos kollégák? Meglévő GPON végpontomon díjcsomagot váltottam 30/5-ről 1000/1000-re. Ehhez új végberendezést kaptam, a Huawei HG850a helyett egy Sagemcom F@st 5655v2 formájában. Szerencsére a firmware frissítés után megérkezett bele a PPPoE passthru lehetőség, tehát a PPPoE kapcsolatot a korábbival azonos módon én terminálom a saját Cisco routeremen. Látszólag tehát technikailag semmi nem változott, csak az elérhető sebesség lett nagyobb. Az átállás óta azonban komoly gondom van: a munkahelyemmel egy GRE tunnelen tartom a kapcsolatot, amiben IPv4 és IPv6 egyaránt utazik. Az IPv4 tökéletesen működik, az IPv6 azonban nem: adatsérülést tapasztalok. Tehát: az adatsérülés a GRE tunnelbe enkapszulált adatban történik! Valami belenyúl a GRE payloadba... csak az IPv6 csomagokba! Ha a GRE tunnel alá rakok IPSec titkosítást, egyből lőn tökéletes működés... "érdekes" módon egyből sértetlenek a csomagok. Ezt mivel érdemeltem ki? Ha valami központi szűrés, akkor eddig miért nem volt? Először a Sagemcom-ra gyanakodtam, de a PPPoE csomagokon nincs checksum hiba. Előre is köszönöm a válaszokat.
×
×
  • Új...