Gergely Egerváry

Tag
  • Tartalmak

    5
  • Csatlakozás időpontja

  • Utolsó látogatás

Minden, amit Gergely Egerváry posztolt

  1. 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. 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.
  4. 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.
  5. 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.