- Samsung Galaxy Note20 Ultra - a tollnak nincs ellenfele
- Poco X3 Pro - hardverfrissítés
- Nokia 3210 - felélni az örökséget
- 2 nm-en készülhet az Exynos 2600
- Android alkalmazások - szoftver kibeszélő topik
- Samsung Galaxy A52s 5G - jó S-tehetség
- Poco X6 Pro - ötös alá
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Drágábban indíthat az új iPhone SE
- Mobil flották
Hirdetés
-
Sikeres volt a teszt, elpusztítja internetes műholdjait az Amazon
it Az Amazon szerint minden sikerrel zárult, ezért letéríti az internetes műholdprototípusokat a pályájukról a cég.
-
Megérkezett a legújabb és eddigi legátfogóbb 3DMark teszt
ph A Steel Nomad egy Light verziót is kap az igazi platformfüggetlenség jegyében.
-
Broken Roads teszt
gp Azt, hogy mi történt az atomháborút követően Amerikában, jól ismerjük a Falloutokból. A Broken Roads e történetet ausztrál szempontból meséli el – igencsak hasonló eszközökkel.
-
Mobilarena
DIGI internet Gyakran Ismételt Kérdések
(Kattints az Összefoglaló kinyitása feliratra!)
Utolsó frissítés: 2024. február
Új hozzászólás Aktív témák
-
dchard
veterán
válasz dchard #82452 üzenetére
Közben rájöttem, hogy butaságot írtam: 7km-en -17dBm az ONT vételi szint, 15.5km-en pedig -20dBm, mindkét esetben 64-es osztás mellett. Az OLT vételi szintek -20 és -24dBm. Látszik tehét, hogy visszirányban - elsősorban az ONT-k gyengébb adási képességei miatt - kisebb jelszintek mérhetőek.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82456 üzenetére
Nem lehet megtippelni (hacsak nem ismered a nyomvonal pontos hosszát az adott végpontig, és hogy C+ vagy B+ optika van-e az OLT oldalán), de nincs is jelentőssége, mivel ez nem kapacitás probléma az már világosan látszik.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82465 üzenetére
Ehhez nem kell NMHH-s mérődoboz. Meg kell mondani, hogy továbbra is szar, ha pedig nem hiszik, jöhetnek ki a saját embereik mérni. Én akkor fordulnék az NMHH-hoz, ha megpróbálják lezárni a hibajegyet. Természetesen ez utóbbit is csak nagyon alapos dokumentációval.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82494 üzenetére
A telekom topikban már leírtam egy párszor a pékes/ácsos sztorimat, kb. ezt tudom elképzelni itt is. Egyébként kábel és kábel között nagyon nagy különbség is lehet, Vannak alacsony hajlítási sugarú spéci kábelek, amik kis túlzással azt is kibírják, ha csomót kötsz rájuk. A Digi által bekötésre használt kábel nem ilyen, ott a 30mm betartása fontos, ez nem tűnik azért betarthatatlan dolognak. A kis mértékben túlhajlított kábel nem feltétlenül törik, viszont nagy mértékben nő rajta a csillapítás.
Hadd kérdezzem meg: a telepen milyen ONT-ket szórnak? Huát vagy ZTE-t?
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz qnadam #82503 üzenetére
Mondok jobbat: a saját részedet amit csináltatsz, kérd mindkét végén csatival, így a Digi csak a saját kábelére rak csatit, a kettőt meg egy toldóval össze tudod pattintani, és szét tudod szedni bármikor. APC SC csati kell mindenhova, erre figyelj, mert ez lényeges. Így a Diginek nem kell mást szerelnie, csak a saját kábelét (=nincs konfliktus a szerelővel). Arra érdemes még figyelni, hogy a két kábel kompatibilis legyen (belső mag és köpeny átmérő).
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82500 üzenetére
Két dolog jutott még eszembe ami kifejezetten az uplniket veri el:
1. Rouge ONT: nagyon nagyon ritkán előfordulhat, hogy egy ONT adó oldali lézere egyszerűen beragad és folyamatosan ad, nem pedig csak akkor amikor az OLT időrést oszt neki. Ezzel értelemszerűen szétveri a porton lévő többi ONT uplinkjét is. Az érzékelése nem egyszerű, de a legtöbb OLT-ben van funkció arra, hogy az egyes ONT-k adott időre teljesen lekapcsolódjanak, így egyessével meg lehet nézni, hogy melyik okozza a hibát.
2. Valaki vicces kedvében SR vagy LR optikát dugott valamelyik szabad portba, és az veri szét az uplinket (ugyanazon a frekin működik mint a GPON UL). De ez kevéssé valószínű.
A két hiba közös jellemzője, hogy csak egy porton lévő előfizetőket tud érinteni.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82521 üzenetére
Biztos hogy nem ilyen közepes méretű OLT-jük van, hanem a legnagyobb 16/24U-s. Egy port maximum 128 ONT-t tud kiszolgálni, de nem hinném, hogy bárki is erre tervez.
"Na most egy ilyen OLT alsó két vastag kártyája az uplink?"
Lényegében, de nem kizárólag. Általában rajtuk fut a vezérlő szoftver is, generálják az alarm-okat, SNMP-n kérdezik le őket és megy az adat a hálózat felügyeletbe, illetve a komplett L2 forwarding és QoS is bennük van. Nem véletlenül van belőle kettő A 2x4 darab port általában 10gigás, így összesen maximum 80Gbps aggregált kapacitást lehet összerakni CWDM-mel.
" Nem lenne logikusabb több kissebb OLT-t alkalmazni több helyen?"
Nem. A cél a nagy agrregált OLT lokációk létrehozása. Nyilván vidéken, ahol a távolságból és a célszerűen nagy osztási arányból relatíve kisebb áthidalható távolság jön ki, ott lehet más a helyzet, de alapvetően a nagy portszám és a nagy aggregált forgalom a cél így kevesebb lokációt kell fenntartani, klímázni, felügyelni, UPS/Agregátorral ellátni, mindezt karbantartani stb.
Ahogy korábban már írtam, lehet egy komplett kártya, de lehet hogy backplane (vagy egy része), de lehet az egyik uplink kártya egyik portja is, ami a terheléselosztás miatt kihat a teljes forgalomra.
"Szóval lehet hogy a kerület másik felében jó minden nálunk meg panel telep kapott egy kisebb külön OLT-t és azon valami nem frankó?"
Simán lehet a kerületben úgy is jó, hogy csak a telepet kiszolgáló 1-2 krátya a szar egy nagy OLT-ben.
Ezt a traceroute-olást felejtsd el. Egy MPLS vagy L2 tranziton nincsenek IP hopok, nem fogsz belőlük látni semmit. Nálunk pédlául L2 kapcsolatok vannak, így a user ha traceroute-ol, akkor az első IP a központi PPPoE szerver lesz, pedig kaddig is van pár "hop"... Diginél valószínűleg az OLT PPPoE szerverét használják Radius-on, tehát a 10.0.0.1 az az OLT-ben lesz. De utána még mindig lesz egy összetett L2 vagy MPLS tranzit, amiben nem fogod látni a hopokat.
Livius:
BME-VIK? Na ne röhögtess... Normális szinten modern router vagy switch architektúrákat egyébként sehol nem oktatnak, a modern - különösen telkó specifikus - protokolok is erősen hiányosak, egyeteme válogatja hogy hol mennyire... Nincs Magyarországon normális műszaki felsőoktatás, mert abba rengeteg pénzt kéne tolni.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Nem megkérdőjelezve, hogy érted a különbséget: az eszközök aljára írt V és A a lehető legrosszabb körülményt feltételezi, és nem a valós fogyasztás, inkább a táp méretezése szempontjából fontos (értsd: legalább 12V/1A-s tápot kell beledugnod hogy stabilan működjön minden körülmények között. Például ha egy ONT-n van egy darab USB port, akkor rögtön számolhatsz úgy, hogy abból a 12V/1A-ből (12watt), 5V/500mA minimum az USB-é. Természetesen ha mondjuk 2 USB van rajta, vagy az USB portok magasabb áramra hitelesítettek, akkor mégtöbbet le kell vonni
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82607 üzenetére
A lakótelep spéci helyzet: rövid távon nagy a népsűrűség. De láthattad, hogy senki nem gondolja a szerelőt is beleértve (nem mintha az ő véleménye különösen számítana), hogy lesz is rajta 128 előfizető. Inkább az volt a cél, hogy látják: a 64-es osztás ilyen helyen könnyen elfogy, és inkább úgy vannak vele, hogy a 64 fölött pár usert még bírjon el a technika. Ezt leírtam a korábbi hozzászólásomban is.
"-20,6dB volt ide és
-23,4dB volt vissza a jel"Hogy kábelmániát idézzem: a jelszintek megfelelőek
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #82623 üzenetére
"Jelre azt mondta - 30dB felett tökéletes"
Ez az OLT oldalra igaz, ha C+ modul van benne. Az ONT biztosan B+ (meg tudod nézni az alján), ott viszont -28dBm a határ, nem -30.
"Ha meg túl sok lenne az előfizető az OLT-nél kiveszik a kettes splitter és máris 64-es osztás lesz a max"
Mi is így csináljuk, annyi különbséggel hogy mi eleve 1:64-re tervezünk, és ebből lehet később 1:32-t csinálni forgalom függvényében
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz qnadam #82641 üzenetére
A GPON DS folyamatosan ad, szóval ha az ONT-ből kihúzod a kábelt és belenézel, akkor bizony csak a kábel/osztó csillapításától függ, hogy mekkora teljesítményű lézer fényt fogsz kapni. Szerencsére mondjuk egy 1:64-es osztás mellett -15dBm lehet a maximális jelszint amit a szemed kaphat, az nem annyira durva (bár így sem próbálnám ki).
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz qnadam #82646 üzenetére
Nem mondanám 100%-ra, de 98%-ra igen, hogy az ONT addig nem ad semmit, amíg a DS jel meg nincs (mivel adási jogot az OLT-től kap). Tehát veszély alapvetően az OLT irányából jöhet.
Kábelmodem amúgy ugyanez: amíg nincs DS lock, addig nincs pofázás a hálózat feléA kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz Intruder2k5 #82799 üzenetére
Be kellene már írni az összefoglalóba, hogy a Digi:
1. Nem ad "román" IP-t (jelentsen ez bármit is)
2. Nem viszi románián keresztül a magyar forgalmat.
3. Az IP címek nem pudvásak.Esetleg aki ezt az ostobaságot terjeszti (mostmár nem tudom hanyadjára), azt lehetne figyelmeztetésben részesíteni.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz 4Grider #82911 üzenetére
A tévedés az, hogy a Digi képtelen volt az összes portot össze bridge-elni a ZTE-n, mert pontosan plusz egy sor lett volna a preconfig XML-ben. És akkor mindegy lenne, hogy az ügyfél melyik portba dugja a saját routerét.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz pw12345 #82966 üzenetére
"Nem tudom ez működik-e"
Nem működik, ez csak a router és a géped közötti LAN IP címet kéri újra.
Intrudernek igaza van egyébként, és teljesen mindegy, hogy NAT-olnak-e vagy sem, és olyan sincs hogy "indiai" meg "román" stb. IP cím. És az IP címnek nem az első tagja a lényeg.
Ha a NAT-ből kikéred magad, akkor is csak annyi fog történni, hogy tudod "cserélgetni" az IP-det, és talán lesz olyan, amit a Tiktok által használt geoIP adatbázis jó országba rak, de ennek továbbra sincs semmi köze a Digihez.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz viktorhu #83114 üzenetére
A 200 körüli válaszidő az a Telekommal is ilyesmi lesz az tuti. Új Zéland 280-290ms. Egyszerűen a fiizkai távolság és a z elképesztően sok tranzit szolgáltató ezt teszi lehetővé.
Nyugat-európa egyébként kulturált, AM7, AMS-IX, Frankfurt stb. mind jó sebességgel jönnek csúcsban is. Nekünk AM7-ben van szolgáltatásunk, azzal van évekre visszamenő tapasztalatom, és mondhatom hogy jól működik.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz viktorhu #83118 üzenetére
Arra próbáltam célozni, hogy ez a Telekomnál is ilyen. Dél-amerikába és a távol-keletre senkinek nincs direkt peering-je, de még csak részesedése sem azokban a vállalatokban. Ergó sem a Telekom sem más hazai szolgáltató nem tud mondjuk Peruba jobb peeringet biztosítani a másiknál. De ajánlok egy kísérletet: mondj egy általad ismert perui host nevet vagy IP-t, csináljunk traceroute-ot, és hasonlítsuk össze
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz #42556672 #83219 üzenetére
"Ez egy szakmai fórum, fogalmazzunk már pontosan...."
Na igen. Természetesen szó nincs szintezésről, kevered a fogalmakat a koax világgal. Szintezni olyasmit lehet, aminek változtatható a kimenő teljesítménye. Az OLT-ben vagy az ONT-kben lévő optika nem ilyen. Az optikai hálózatot méretezni szokás.
"Ha az utolsó bekötés vagy akkor igen, nem mindegy, hogy 100m vagy 1000m a bekötés."
Egy tisztességesen méretezett optikai hálózatban is van legalább 2-3dB tartalék, tehát ha te vagy az utolsó, legtávolabbi előfizető, akkor is teljesen mindegy, hogy egy kilóméterrel több vagy kevesebb a kábelhossz.
"mi az hogy 1km kábelnél nincs jelveszteség?! "
Nincs számottevő jelveszteség. Akkora főleg nincs, ami befolyásolja a hálózat teljesítményét. Ugye az eredeti kérdés az volt, hogy maradhat-e 50 méter feltekert kábel a lakásban (például ha később majd át kell helyezni a végpontot), amire a válasz az, hogy igen, akár sokkal több is maradhat.
"64-es osztással Class C+ hálózat (32dB csillapítás mérleg) max 20km lehet"
Ez sem igaz, egy tipikus normális minőségben kiépített PON hálózat 64-es osztásnál 25-26km-t ki tud nyomni C+ optikával, és ebben már van némi tartalék is.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz viktorhu #83681 üzenetére
Azt hiszen kis további magyarázatra van szükség:
1. A QoS a GPON hálózatban L2-n van megoldva, ezt az OLT-ben konfigurálják, és az ONT-be ez az úgynevezett OMCI protokollon keresztül kerül alkalmazásra. A PPPoE kapcsolatnak ehhez semmi köze nincs. A PPPoE kapcsolat csak az IP kapcsolat felépítésében (IP cím, maszk, átjáró, névszerverek) játszik szerepet.
2. Az ONT-ben az éppen aktuális szolgáltató VLAN mappingjét (melyik VLAN-on jön a PPPoE, IPTV, IP telefon stb., illetve hogy melyik VLAN milyen prioritású) több féle módon is be lehet tölteni: az egyik, hogy az ONT-ben lévő alap mappinget használja a szolgáltató, a másik hogy XML profilt tölt le az ONT, de akár az első csatlakozáskor TR-069-en is történhet ennek a provisioning-je. Nagyobb megrendelés esetén a gyártó kérésre egyedi konfigurációval is tudja szállítani az ONT-ket.
3. Az effektív sebességet általában az OLT-n állítják be, de az az ONT úgynevezett UNI portján kerül alkalmazásra. Ebből is látszik, hogy az OLT és az ONT-k szerves logikai egységet alkotnak, ha úgy tetszik az ONT-k az OLT meghosszabbított részei, ezért sem lehet őket csere-berélni.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz YellowFlash #83773 üzenetére
Hát ilyen sem történik minden nap...
A holland peering partnerünk megerősítette, hogy náluk is volt több rövid flap a Level3 irányába, jelentős csomagvesztéssel. Ez az elmúlt 2 napból is sok mindent megmagyaráz...
Állítólag már megjavították, de azért a következő órákban még lehet meglepetés.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
"De biztos én nem értek hozzá..."
Minden paramétert látnak (a jelszinteknél sokkal többet), a kérdés inkább az, hogy hozzáférsz-e kompetens szakemberhez, aki ezeket értelmezni is tudja majd a szolgáltató oldaláról. A lakásra kiküldött szerelő a legkevésbé látja át a rendszer szintű működést. Maximum mér szintet (de ezt látnák a központi oldalon is, ha ezzel lenne gond), újrahegeszti a kábelt ha szükséges, kicseréli az ONT-t ha dölgődik. Ennyit tud tenni a szerelő. Összetett köponti hibát nem tud diagnosztizálni.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #84020 üzenetére
Pont erre céloztam, hogy ha szint probléma lenne, azt látnák belülről is. Az ONT persze lehet szar, de erre kicsi az esély. Ha pedig más központi hiba van, akkor kint az ügyfélnél nincs mit csinálni, minek menjen ki? Bentről nyugodt körülmények között nézegetheti a KPI-okat, és rájöhet a hiba okára.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #84022 üzenetére
Egy PON port az OLT-n általában maximum 128db ONT-t tud kiszolgálni. A 128-at nem tudod túllépni, ha megpróbálod akkor az ONT nem fog tudni range-elni (nem épül fel a PON OMCI kapcsolat). A 64-et túl lehet lépni abban az estben ha van elég tartalék a hálózatban, de azt látni kell, hogy ha a hálózat 64-es osztásra van méretezve (elsősorban a távolság miatt), akkor nem tudod egyetlen egy ügyféllel sem túllépni azt, mivel ahhoz újabb osztást kell berakni, amivel így kifutsz a tervezett optikai büdzséből (értsd: nem lesz elég a jelszint ha ezt a plusz utólagos osztást berakod). Az osztási számot alapvetően két dolog befolyásolja: 1. a távolság 2. a tervezett kapacitás. Például csak gigabites előfizetések mellett elég bátor dolog 128-as osztásra méretezni, de persze az is igaz, hogy a 128-as tervezési szám nem jelent effektíve 128 valódi előfizetőt.
A TV-re ez nem vontakozik, az külön hullámhosszon megy, és nagy teljesítményű EDFA lézerrel állítják elő, amit több ezer felé el lehet osztani. Többek között ez is előnye az IPTV-vel szemben. Például ha totlálisan bekotlik az OLT és nincs internet meg telefon, TV ettől még lesz Ennél picit részletesebben olvashatsz erről itt: [link] nemrég frissítettem a cikket, más érdekesség is van benne. A cikk születéséhez képest a PON jövője némiképp más irányt vett, azt majd később fogom átírni.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz tobi'' #84055 üzenetére
A 8 bájt a PPPoE overhead. Telekomnál is Diginél is ennyi, a valódi MTU-d így 1492 bájt.
A Windows-os PING uye minden overhead nélkül adja meg a méretet, tehát ha a -f -l 1472-t használod, akkor az 1500 bájtos IP csomagot jelent (20 bájt IP és 8 bájt ICMP overhead nincs benne az 1472-ben).
PPPoE mellett az MTU-d 1492 bájt, tehát a windows-os ping alkalmazásnál -f -l 1464 -et kell megadni.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
-
dchard
veterán
válasz tobi'' #84083 üzenetére
Azt a kérdést kellett volna feltenned, hogy a Digi optikán támogatja-e a baby jumbo frame-et, és akkor rögtön megkaptad volna a megfelelő választ: nem. Egyébként a Telekom sem.
A jól működő MSS clamp-hez a WAN MTU-t (ebben az esetben a PPPoE kapcsolatét) kell helyesen beállítani, utána jól fog működni. Ha nálad 1492 bájtos MTU mellett szarul működik, akkor reszelgetni kéne még picit a pfsense-et, vagy más probléma van.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz tobi'' #84093 üzenetére
Nem teljesen ország specifikus egyébként, hogy van-e vagy nincs. Tudok neked mutatni nem egy olyan ONT vendort (nem csak kínait), ahol még a legfrissebb 2020 júliusi firmware-ben sincs még baby jumbo támogatás sem a GPON interfészen... Mi sem tudtuk bevezetni többek között emiatt.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz adika4444 #84116 üzenetére
Dehogy ez a magyarázat...
Az alapvető logika diktálja azt, hogy cím ne lehessen valamiféle időkorlát nélkül kiosztva sehova sem úgy, hogy a kiszolgálónak ne legyen módja a hibás működés detektálására, és ilyen módon a cím felszabadítására. Ez a távközlési protokolok egyik alap tervezési paradigmájához vezet vissza aminek a lényege, hogy a szóbanforgó protokol (illetve a hozzá tartozó állapotgép) deadlock-free legyen, vagyis ne fordulhasson elő olyan állapot, amiből nincs kiút. Ezért is van minden protokol tele időzítőkkel és számlálókkal, amivel ellenőrizhető a helyes működés. Teljesen mindegy hogy PPPoE, vagy DHCP (mobilnetnél PDCP).
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz adika4444 #84125 üzenetére
"Szolgáltatói oldalról van az álláspont amit írtam"
Ez városi legenda, nem több. Az ÁSZF tiltja a szerver üzemeltetést, és kész. Ugyanúgy tiltja kábelnetnél is (DHCP), mint PPPoE-n. Sehol nem mondja a szolgáltató, hogy azért bontja 168 óránként (korábban 24 óránként), hogy te ne tudj szervert üzemeltetni (amiben ez egyébként nem akadályoz meg).
"De akkor DHCP-nél miért tudják megoldani, hogy a lejárati idő felénél megújul az IP, tehát közel soha nem szakad?"
Mert a DHCP protokol úgy működik, hogy a lease time lejártakor a kliens újrakéri ugyanazt a címet, amit már kiosztottak neki, és ha erre nyugtával válaszol a DHCP szerver, akkor megtarthatod a korábbi címedet ugyancsak a lease time erejéig. A legtöbb komolyabb DHCP szerverben van rá lehetőség, hogy ilyen esetben is kényszerítsék az új címet, mégsem bajlódik ezzel egy nagyobb szolgáltató sem. Itt is látszik, hogy a szerver üzemeltetős érvelés bukó. PPPoE-nél nincs lehetőség csak a címet megújítani, ez nem része az IPCP (Internet Protocol Control Protocol)-nek. Itt az időkeret a PPP kapcsolatrészhez tartozik LCP-n keresztül, mely magának a PPP kapcsolatnak az állapotáért felel. A PPPoE ugye több alapprotokol együtesséből áll össze (LCP és IPCP), előbbi a link állapotáért felel, utóbbi az IP kommunikációhoz szükséges feladatokat végzi (IP cím, átjáró, DNS szerverek alapvetően), tehát a dinamikus címzést nem DHCP szerver csinálja, és nem DHCP a protokol sem. Ez a hátránya a PPPoE-nek: a link kontrol és az IP kontrol nem különül el.
AKit érdekel, megnézheti protokol szinten: [link] wireshark kell a fájl megnyitásához. Látható, hogy a PPPoE részben nincs semmi a címzésel kapcsolatban, az az IPCP részben van, amihez viszont nem tartozik időzítő.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz MasterMark #84127 üzenetére
Nem fogalmazza meg pontosan, de a példa szempontjából ez mindegy is.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
Ugyan leszoktunk róla, de most érdemes mégis egy pillantást vetni a BIX statkóra:
Péntek óta átlagban 40%-kal nőtt a forgalom a BIX irányon. Ez azért nem kevés. Nyilván peering variálás lehet a háttérben, érdekes lenne megtudni, hogy mi változott. Interkonnektre érzékenyek most nézegethetik, hátha látnak valamit.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz TeeJay #84213 üzenetére
Titkosítás mellett nincs. DPI kell hozzá, ami ilyen forgalom mellett a UPC-nek sem érte meg annó, ki is vezették. Kizárt hogy egy budget szolgáltató ilyesmibe ruházna. Inkább azt tudom elképzelni, hogy ebben nem csak konzumer forgalom van, lehet adatcenterek között másolnak valamit.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz Borisz76 #85768 üzenetére
"Nincs dedikált ki és bemenet."
Pontosan. Az összes port egyforma, és mivel az összes internetes forgalom kétirányú, ezért a ki és bemenet fogalma nem értelmezhető. Minden port ki és bemenet egyszerre. Amit mpo jelezni akart, hogy mindegy hogy melyik portot hova dugja: egy port megy a HGW felé, a többi a kliens eszközök felé. Konfigurálni nem kell semmit.
mpo:
Amit linkeltél, az a feladatra teljesen megfelel, de nincs kimenete meg bemenete Egyenértékű portjai vannak, mint az összes switch-nek.
[ Szerkesztve ]
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz adika4444 #85811 üzenetére
A legjobb valóban Romániában hostolt IP-re 19ms a ping, az átlag 20-25ms. Ehhez képest te 10-11ms-ot mérsz a BIX-re. Semmi bizonyíték nincs mostmár sokadszorra, erre a nettó hülyeségre, hogy bármilyen hazai vagy nyugat-európai forgalom Románián keresztül menne.
Ami sokkal valószínűbb, hogy esetleg a székesfehérvári kábelátvágás nem csak regonális de tranzit útvonalat is érinthetett, ezért most más irányba, esetleg tartalék tranziton mennek a csomagok (nem Románián át természetesen). Ez magyarázza a megnőtt válaszidőt, és a csomag dobást is, mivel előfordul, hogy a tartalék útvonal nem képes a teljes forgalmat kiszolgálni. Az is előfordulhat, hogy a tartalék útvonal IPv6 routing-ja nem 100%-os. Ezek közül bárminek van esélye a román teóriával szemben. El kéne már felejteni ezt. Ahányszor eddig felmerült, annyiszor derült ki, hogy tévedés.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
-
dchard
veterán
válasz viktorhu #85820 üzenetére
Hogy mi volt 2006-ban, arra nem emlékszem. Kb. 10 éve foglalkozom ezzel, azóta biztosan nem volt Románián keresztül routolt forgalom (legalább is nem nyugatra). Pedig 3 havonta bedobja valaki Emlékezzél csak vissza az elmúlt egy évre. Volt itt minden a PPPoE szerver belső hálózati IP címét Debrecenbe rakó visual traceroute-tól addig hogy még a belföldi forgalmat is Románián át routolja a Digi.
A kitárulkozó idegenektől mindig elfog a hányinger. [Cornelius]
Új hozzászólás Aktív témák
Olvasd el az összefoglalót!
Társtopikok:
● DIGI kábel TV
● DIGI Mobil
● DIGI műholdas TV
● DIGI vezetékes telefon
Router kérdésekkel ezekbe a topikokba fáradjatok!
● Milyen routert?
● Router gondok
- DELL G15 5510 - 15,6"FHD IPS 120Hz - i5-10200H - 8GB - 512GB - GTX 1650 - Win11 - Garancia
- Ipad Pro 12.9" 3.Gen ( 2018 ) WIFI+ Cellular. 1 TB !!! , Üzletből, Garanciával, beszámitás
- Canon Powershot SX700 HS fényképező / kamera eladó! Választható tartozékok!
- Lenovo ThinkPad T490 14" FHD IPS i5-8365U 16GB DDR4 512GB NVMe ujjlolv., gar
- IPhone 13 256GB Green gyári független megkímélt akku 91%
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest