Telekom GPON + KAON PG2141N WAN bontás router mögött 20–30 mp után

Hálózatok egyéb

Sziasztok,
 

Telekom GPON infrastruktúrán futó One optikai előfizetéssel kapcsolatban kérnék tapasztalatot.
ONT: KAON PG2141N
Környezet: intézményi hálózat, Debian alapú kétlábas gateway (WAN DHCP, LAN 10.0.0.0/24), NAT a gateway-en. IPTV aktív az ONT egyik LAN portján.
 

A gateway WAN interfésze DHCP-n IP-t kap a KAON-tól (pl. 192.168.1.5/24), default route beáll, külső ping működik, lease idő több órás. Az L3 kapcsolat tehát felépül.
Viszont ~20–30 másodperc után a WAN kapcsolat megszakad. Nem lease expiry, nem fizikai link hiba, nem route hiány. A jelenség reprodukálható.
 

Más szolgáltatói vonalon ugyanaz a gateway évek óta stabilan működik.
Találkozott már valaki Telekom GPON + KAON PG2141N kombinációban:
 

router-behind-router detekcióval,
WAN session policinggel,
OLT provisioning profil miatti bontással?
 

Érdekelne, hogy ismert viselkedés-e, illetve Huawei ONT-val stabilabb-e hasonló topológiában.
 

Köszönöm, Antal

  • 908 megtekintés

( Ebcsont | 2026. 02. 25., sze – 21:06 )

Ez a cucc egy ipari hulladék..

Az optikai kábel dugaljból a legkisebb mozdulatra is ki tud lazulni/esni a csatlakozó. Egy évet kínlódtam vele, utána átmentem a T-hez. Azóta minden működik baj nélkül.

Röviden nincs. Hosszabban eddig egyedül ennél találkoztam ilyen gagyi megoldással optikai csatlakozás címén. Nagyjából ugyanúgy csatlakozik az optika, mint a sima ethernet, tehát nincs hozzá vezetékrögzítési fül és süllyesztve sincs a csati. Eredmény a legkisebb mozdulatra is elmozdul a csatlakozó, és még ha a helyén van, akkor is dobálja a kapcsolatot, pont úgy ahogy a topiknyitó leírta. 

( kallaics | 2026. 02. 26., cs – 12:31 )

Ezzel itt jó eséllyel nem fogunk tudni, mit kezdeni. Az eszköz se mai darab. Ennél valami előremutató megoldás felé javasolt vinni a dolgot.

One-nál bejelentetted már? Lehet kimennek, szó nélkül cserélik az eszközt,  probléma megoldva. 

Sziasztok.
 

Jelenleg itt tart az ügy.Gyalázatos az eljárás eddig sajnos.

Tisztelt One Üzleti Műszaki Támogatás!

A tájékoztatásukban szereplő pontokat (bridge mód optikai környezetben nem támogatott, illetve a Huawei OptiXstar HG8147X6-10 ezen a csomagon nem elérhető) tudomásul vettük.

Szeretnénk jelezni, hogy a megkeresésünk lényege nem a bridge mód igénye és nem egy konkrét gyártóhoz való ragaszkodás, hanem az, hogy a szolgáltatás intézményi környezetben – IPTV szolgáltatás megtartása mellett – stabilan, folyamatosan használható legyen a meglévő intézményi hálózati felépítésben (saját gateway mögött).

A jelzett probléma: a kapcsolat DHCP-n felépül (192.168.1.x, default gateway beáll), rövid ideig működik, majd kb. 20–30 másodperc után megszakad. Ez a jelenség a távdiagnosztikai mérésekből nem feltétlenül látható, mivel a fizikai link és az ONT alap elérhetősége közben rendben maradhat.

Kérjük ezért az alábbiak egyikében szíveskedjenek állást foglalni:

1) Biztosítanak-e a jelenlegi „Üzleti Internet 1000 vario” csomaghoz olyan, kompatibilis ONT eszközt (nem feltétlen Huawei-t), amely intézményi gateway mögött, IPTV mellett stabilan működik (router mód / NAT mögötti használatban is), vagy

2) Amennyiben kizárólag „technológia/csomag váltás” lehetséges, kérjük ennek írásos, részletes feltételeit megküldeni:

- pontos csomag/technológia megnevezése,

- egyszeri és havi költségek,

- hűségidő / szerződésmódosítás feltételei,

- biztosított végberendezés típusa,

- és annak megerősítése, hogy az új csomag/technológia stabilan támogatja az intézményi gateway mögötti üzemet IPTV megtartása mellett.

Célunk a szolgáltatás rendeltetésszerű, üzembiztos intézményi használata, és a megoldás mielőbbi kijelölése.

Válaszukat kérjük írásban megküldeni.

Ez itt így néz ki:

Laptopot közvetlen a KAON-ra dugva (DHCP 192.168.1.x) stabilan működik az internet, tehát klasszikus „home” üzemmódban jónak tűnik.
Erősen úgy néz ki, mintha router-behind-router detektálás, WAN session policing vagy OLT provisioning policy bontaná a kapcsolatot, ha intézményi gateway kerül az ONT mögé.

Nem valószinű, hogy a ONE Helpdesken van élő ember, aki ilyesmire választ tud adni, ráadásul ez úgy tűnik, hogy Telekomos terület, nem vagyok biztos abban, hogy egyáltalán kellene-e legyen ott a kérdés megválaszolására alkalmas szakember.

Hogy kerültél Telekomos területen a ONE-hoz?

Szia.

Úgy kerültem oda hogy vagyok olyan galád hogy próbálnék üzemeltetni ügyfélnek még.One azt csinálja most jelenleg új üzleti előfizetésnél hogy már nem fejleszt hálózatot hanem bérli azt.Rettenetes a helyzet mostanában és ilyen förmedvényeket tesznek ki helyszínre.

Nekem meglepően jó tapasztalataim voltak a személyes kontaktal az egyik üzletükben és már nem először. Amennyiben, mint üzleti ügyfél nincs személyes kontaktotok, én bepróbálkoznék egy One üzletben lehetőleg nyitás után, mert akkor még frissek az alkalmazottak és nincsenek túl a sokadik alapvető kérdésen és a sokadik kávén, vagy energiaitalon.

Ha ez nem lehetséges kérni kell a telefonvonal végén egy technikai kollégát, mert a probléma annyira mély technikai tudást igényel,  hogy azt az L1 nem tudja megoldani. Röviden el lehet mondani nekik is, aztán úgyis belátják,  hogy ez nem az ő felelősségi körük. 

Egy ilyen hibánál a levelezést hagynám utoljára, mert mindenhol a leglassabb megoldás a korábbi tapasztalatok alapján. Most nem tudom milyen válaszidővel mennek a dolgok, de régen hetekbe is telt egy válasz.

Remélem mihamarabb megoldódik a probléma. 

Egyetértek. Előtte mindenesetre benéznék a Telekomhoz is, hátha egy szolgáltatóváltással megoldható a dolog. Simán elképzelhetőnek tartom, hogy a ONE-nál nincs élő ember, aki értené, hogy a Telekom mit csinál a bérbeadott hálózaton (illetve aki tudja, az soha nem lesz HelpDesk számára elérhető).

( anthony_ v | 2026. 02. 27., p – 21:25 )

Szerintetek lehet eredmény stabilitás szempontjából hogyha növelem a TTL értéket +1-el?

iptables -t mangle -I POSTROUTING 1 -o enp1s0 -j TTL --ttl-inc 1

Megkerülhetem vele a router szűrést vagy túl gondolom az egészet és valóban egy fizikai csatlakozási hibára utal ez a viselkedés?

( wpeople v | 2026. 02. 28., szo – 19:01 )

pár észrevétel: a Kaon gateway-ben 99.9% h meg lehet nézni a PPPoE session állapotát és az optikai jelszintet.
Ha a csatlakozás sz.r - akkor a PPPoE is leszakad, talán még azt is mutatja a CPE, hogy mióta van online az optikai hálózaton (ez nem a PPPoE session "számlálója")

A Telekom ad a saját hálózatán Multicast IPTV-t (külön VLAN-ban). Az nekem újdonság, hogy a One - Telekom optikán - ad szintén multicast IPTV-t, bár műszakilag van lehetőség rá.

 

One azt csinálja most jelenleg új üzleti előfizetésnél hogy már nem fejleszt hálózatot hanem bérli azt

Szerintem ez így ebben a formában nem igaz. A One is használja a Telekom optikai hálózatát - mint sok más szolgáltató. Nyilván, ott, ahol van sajátja - ott azon fog szolgáltatást adni.
Még arra sem tenném a nyakam, hogy ahol elérhető a One (ex fibernet) koax hálózat - de elégedetlen vagy vele - és emellett ott a Telekom optika - van lehetőséged Ügyfélként azt mondani, h Te márpedig a másik hálózaton szeretnéd kapni a netet...

Köszi a visszajelzést! A KAON-on az optikai link/uptime és a PPPoE státuszok valóban ellenőrizhetők, és a szolgáltató távdiagnosztikája szerint „minden zöld” is.
Nálunk viszont a konkrét gond ez: Debian gateway WAN-ja a KAON LAN-ra kötve DHCP-n kap 192.168.1.x-et, default gw 192.168.1.1 beáll, ping kifelé (pl. 1.1.1.1) megy, majd ~20–30 mp után a forgalom megszűnik. Link nem esik le, lease több órás, tehát nem DHCP/optikai szakadás jelleg.
IPTV csak annyiban releváns, hogy működik és maradnia kell; a kérdés nálunk a stabil L3 internet port gateway mögött.
Ha van ötlet, mi okozhat ilyen időzített bontást (CPE policy/router-behind-router, MAC/TTL alapú detektálás, provisioning), szívesen veszem.

amikor tesztelt, tökjó volna, ha nem egyben az egész átviteli utat tesztelnéd ping-el,hanem
a) mtr -t használnál
b) sorban ellenőriznéd a dolgokat

utóbbihoz: sorban pingeled a router belső címét (192.168.1.1) majd külső címét.
Amennyiben a belső elérhető - a külső nem -> le van szakadva a netről.
Ha ez még mindíg megy - akkor a szolgáltató koncentrátorát (a PPPoE remote IPcíme lesz az), majd szolgáltatói DNS pl, stb stb...

Nincs véletlenül több szolgáltatótól is netetek rákötve a saját routeretekre?

Ilyen esetben láttam olyan konfig problémát, hogy 
- pfsense-ben healtcheck -nél megadott dns szolgáltatós ip címet használtak. Ez viszont static routeként felveszi, hogy mindig azon az interfacen megy ki, amit healtcheckel, így a másik felé nem mehet forgalom olyan címre. Ha az az interface le van húzva, akkor nem lesz elérhető a cím.
- hogy mikrotik routeren egy pipa benn marad, ami miatt rossz interfacen át is ment net felé adat, amire a válasz ezért sosem talált vissza, amikor már nem ugyanarra a netkapcsolatra volt dugva mindkét hálózat, amire kapcsolódott az eszköz.

Sziasztok.

Nálunk nincs multi-WAN / több szolgáltató egyszerre, nincs pfSense-féle DNS healthcheck, és nem Mikrotik a gateway (Debian 12 gateway, LAN 10.0.0.0/24). Sima laptop közvetlenül az ONT/KAON LAN2 portján stabilan kap DHCP-t és van net; viszont amikor ugyanarra a portra a gateway WAN kerül (switchen keresztül is próbálva), rövid idő után megszakad/instabillá válik a forgalom, miközben a link up marad. Emiatt szolgáltatói/ONT oldali port-/policy/session kezelést gyanítunk, és a One műszaki egyeztetését várjuk. (A velük egyeztetett, rögzített hívás alapján vállalt 12:00–16:00 kiszállás sajnos értesítés nélkül elmaradt, így a helyszíni bevizsgálás csúszik.)

( Imo | 2026. 03. 01., v – 08:47 )

Egy sima laptopot rádugva is megáll a forgalom?