sipsza

8 perce, Halacs írta:

Örömmel jelentem, hogy valami történik IPv6 szinten optikán.

Pár perce hívtak a Telekomtól, hogy próbáljam meg újraindítani az ONT-t és a Mikrotikem és nézzük meg van e változás.

Odáig jutottunk, hogy link local címet már kapok a PPPOE interfészen, valamint DHCPv6-al prefixet is, címet viszont egyelőre nem. Koaxon címet is kapok ugyanígy, ezért jeleztem a kollégának, hogy már majdnem jó, de jó lenne ha egyformán tudna a kettő működni, ha egyformán tudnám a routeolást megcsinálni : address-t kapja a mikrotik és a kapott másik (prefix) subnetből kapnak a mikrotik mögötti gépek. Ezt ő továbbítja a megfelelő helyre.

Szóval örülünk, valami történik még akkor is ha ez egyelőre úgy fest nem általános változás csak az én előfizetésemre vonatkozik. Várjuk ki a végét, eddig nagyon biztató a dolog.

Miért kell külön cím is? A /56-os prefixből tudsz osztani magadnak mindenhova.

Szerintem koaxon is egy /56-os prefixből kapsz mindent.

@Halacs

"ONT csere nem segítene, ezt külön egyeztette a fejlesztőkkel (látta ezt a threadet). Ha nem lenne tiltva területileg az IPv6 akkor menne a nálam lévő ONT-vel is."
Az én (megalapozatlan) feltételezésem az volt, hogy ha nincs aktiválva a központban az IPv6, akkor egy új sorozatszámú ONT felregisztrálása aktiválja. Ha a központban minden jó, akkor az ONT nem akadály.

"Ezt követően jött az SMS, hogy ők nem találtak a saját hálózatukban hibát, ellenőrizzem a saját eszközeimet."
Nem értem ezt a hibajegy lezárási kényszert. Miért nem lehet nyitva hagyni, amíg ténylegesen meg nem oldódik a probléma?
Az őszi ETA nagyon kényelmes nekik, mert addigra a lezárt hibajegyedet már meg sem tudod nézni. Nem mintha lenne mire hivatkoznod, mert minden lényeges információt mellékcsatornákon kaptál tőlük. Így majd kezdhetsz mindent elölről.

Olyan érzésem van, hogy a Telekomnak az internet csak a webből (IPv4, TCP/UDP, DNS/HTTP(S)) áll. Ha ezeken kívül működik más is, érezd magad megtisztelve.

1 órája, Zoolesz írta:

Frankó akkor már legalább 2 hónapja dolgoznak rajta mert nekem azóta nem megy és akkor is erre hivatkoztak hogy valami gond van, de 1-2 hét és megoldják. Mondtam oké majd májusban érdeklődők, de elmaradt, nem vesztettem vele semmit. ? 

Nekem 3 hónapig mondogatták, hogy náluk minden rendben. Kértem, hogy nézze meg egy szerelő is, ha már nekem nem hisznek. Ő végül kicserélte az ONT-t (egy teljesen ugyanolyanra), és onnantól ment minden. Azóta többen is megkerestek, akiknél szintén csak az ONT csere volt a megoldás.

@Halacs

Igen, az ipv6cp filter mutatná a választ is.

Nem tudom, hogy egy sima újraindítás után letölti-e újra az ONT a konfigot. Biztos, ami biztos alapon csinálj egy factory resetet.

@Halacs

Az fe80-as címet nem a Mikrotik generálja, hanem a szolgáltatótól kellene kapnod IPV6CP-n (Point-to-Point Protocol IPv6 Control Protocol) keresztül.
Futtasd a Tools > Packet Sniffert a PPPoE interface-hez tartozó ethernet interface-en miközben újracsatlakozol. Azt fogod látni, hogy a routered küld egy IPV6CP konfigurációs kérést, de nem kap rá választ.

Ha az ONT reset nem segített, kérj ONT cserét.

4 órája, Halacs írta:

Szia @sipsza ! Nekem is Mikrotik rotuerem van ami PPPoE-vel kapcsolódik a Telekom optikához. Tudsz segíteni, hoyg hogyan tudnék IPv6 címet/poolt kapni? Köszi!

Szia!

Meddig jutottál el? Az első lépések nagy vonalakban:

•     a PPPoE kapcsolathoz tartozó PPP profilban engedélyezni kell az IPv6-ot (use-ipv6 = yes)
•     ezután már a PPPoE interface kapni fog egy v6 címet is, IPv6 > Addresses alatt tudod ellenőrizni, valószínűleg neked is fe80::b lesz
•     DHCPv6-on keresztül kell kérned egy prefixet. Csak prefixet, címet nem, mert különben nem kapsz választ.
•     ebből a prefixből kell címeket osztanod az eszközeidnek

Ha a PPPoE interface nem kap címet (nem kapsz választ az IPV6CP kérésre), akkor a T-nél lesz valami. Jelezd nekik, hogy szeretnél IPv6-ot használni. Miután beállították csinálj egy 30+ másodperces ONT resetet. Ha ezután sem lesz jó, kérj egy ONT cserét.
Az ONT elvileg nem befolyásol semmit, de az én esetemben a PPPoE szerverük addig nem akarta letölteni az új beállításokat, amíg egy másik ONT-t fel nem regisztráltak.

@Halacs

Szia!

Úgy néz ki, hogy a Broadcom pktrunner nevű kernelmoduljában van a hiba. (A Sagemcom ONT-ben Broadcom SoC van.) A Broadcom a hibát már rég javította, de hozzánk valahogy még nem ért el.

Írtam több emailt is a Telekomnak, bennük a hiba részleteivel és a feltételezett okkal. Egyikre sem kaptam választ.
Felhívtam az ügyfélszolgálatot. Ott azt mondták, hogy ha kapnak új firmware-t a Sagemcomtól, akkor azt egyből megkapjuk mi is, de jelezni nem fogják a hibát a Sagemcom felé.
Írtam a Sagemcomnak, hogy tudnak-e a hibáról, és, hogy a SG3G10000494-e a legújabb firmware. Megkérdezték, hogy ki a szolgáltatóm, majd ők sem válaszoltak többet.

Ez volt február elején, azóta semmi fejlemény.

19 órája, fgabor87 írta:

Sziasztok! Nem nyitnék új topicot a kérdésemnek, ha nem muszáj. Engem az érdekelne, hogy ugyan ebben a HGW-ben hogyan tudom beállítani, hogy ne gyorsítótárazza be a DNS kéréseket? Van egy felügyeleti szálam, ami DNS kérésekkel vizsgálja, hogy van-e internet. De ez most nem működik, mert ha leszakad a HGW a hálózatról, akkor is megy a DNS feloldás.

Szia!

Nem hiszem, hogy találsz ilyen beállítást.

Biztos vagy benne, hogy csak a HGW gyorsítótáraz, és pl. az oprendszered nem?
Lehet, hogy a HGW nem is a gyorsítótárat használja, hiába nincs interneted. Nálam az ONT akkor is válaszol a DNS lekérdezésekre (nem a cache-ből), ha nincs aktív PPPoE kapcsolat.

Az általad említett heurisztika mennyire fix? Lehetne esetleg?:

• Pingelni a DNS lekérdezés helyett.
• Egyből egy távoli DNS szervernek küldeni a lekérdezést.
• Alacsony TTL-lel rendelkező rekordot lekérni, remélve, hogy a HGW tiszteletben tartja azt. Például raw.githubusercontent.com -nál 30 másodperc a TTL, de sok másik CDN esetén is <1 perc.
• Olyan domaint lekérdezni, ami biztosan nincs a cache-ben. Pl. [minden alkalommal más random string].com, vagy ha az NXDOMAIN válasz nem jó, [minden alkalommal más random string].tumblr.com

@Tim András

Nálam optikán a bekötés óta (2016) működik a PPPoE passthrough, IPTV és VoIP mellett, nincs szükség dupla NAT-ra.

Api1977 problémáját szerintem VLAN-okkal lehet elegánsan megoldani:

• nem terheli a router processzorát, mint az IGMP Proxy, mert még a 10+ éves SOHO routerekben is van VLAN képes hardwares switch
• nem rakok egy olyan eszközt (az STB)  a tűzfallal védett belső hálózatomba, ami felett semmi kontrollom nincs
• kevésbé érzékeny arra, ha a szolgáltató módosít valami beállítást. Semmi sem garantálja, hogy a T holnaptól nem fogja az öt legnézettebb csatorna adását broadcaston küldeni.

A fentiek fényében szomorú, hogy a legtöbb SOHO routeren nem, vagy csak korlátozottan lehet hozzáférni a switch/VLAN beállításokhoz a gyári firmwarrel.

@McBelaba

Nálam Androidon van egy PPP interface a szolgáltató felől, és a wlan hotspot. Mindkettő ugyanabból a /64 prefixből használ egy-egy címet, és a hotspotra csatlakozott eszközöknek is ezt a prefixet hirdeti ki.

2 órája, Zoolesz írta:

Sagecom mint látszik csak link local címe van, win 10 és debian szerver kap IPv6-ot. A mikrotik se address-t se prefixet nem kap csak keres ahogy látszik (jelenleg csak címet kérnék neki). Minden a sagecomra van kötve jelenleg.

DHCPv6-on szerintem nem fogsz címet kapni, legfeljebb prefixet. Ha cím kell, akkor használj SLAAC-et, mint a Windows és a Debian.

Nekem PPPoE-n keresztül, Mikrotik routerrel stabilan megy az IPv6 (IPTV és Telefon mellett). Szívesen segítek, de sok apró beállítás kellhet, ezért jobb lenne, ha valósidőben tudnánk beszélni egymással.

Leellenőriztem az UDP portokat is.

Befele blokkolt:
520 - RIP
646 - MPLS LDP

Kifele blokkolt:
520 - RIP
646 - MPLS LDP
711 - MPLS Cisco TDP?
1985 - Cisco Hot Standby Router Protocol
3222 - Gateway Load Balancing Protocol
4791 - IP Routable RocE

A felsorolt protokollok egy részét a routerem nem is ismeri, de mindegy is, mert még azelőtt nézem csomagokat, hogy a tűzfal vagy egy protokoll daemon elkapná őket.

19 órája, btz írta:

Üdv!

Én leteszteltem most és megkapom minden gond nélkül.

Szerintem a 25-ös porton kívül nincs semmilyen portszűrés.

Köszönöm a választ!

Végigmentem a TCP portokon 1-65535 4 különböző helyről: DigitalOcean VPS, U_P_C, egyetemi (HBONE) és céges hálózat.
A következő portok egyik helyről sem elérhetőek.

Befele:
639 - MSDP
646 - MPLS LDP
711 - MPLS Cisco TDP
7547 - TR-069 CWMP
8085 - DSLForum CPE Management
30005 - TR-069 (nekem másra kell, de gondolom a TR-069 az oka)
51005
58000

Kifele:
25 - SMTP (ezt megértem)
646 - MPLS LDP
711 - MPLS Cisco TDP

Érdemes abban reménykednem, hogy kérésre feloldják a befele irányú blokkolást?

Sziasztok!

Más sem kapja meg a 30005/TCP-re érkező csomagokat? TCP 30004 és 30006 jó, de a 30005 nem.
A mindenkori blokkolt kimenő/bejövő portok listája elérhető valahol?

Sagemcom F@st 5655v2 AC ONT-t használok PPPoePassthrough módban, fw: SG3G10000494. Biztosan nem a routerem tűzfal/nat beállításaival van gond, mert még azok előtt, közvetlenül az ethernet interface-en nézem a csomagokat.

12 órája, McBelaba írta:

A Cisco eszközzel elméletileg kiváltható, csak csak nem szsereti a szolgáltató ha te a saját eszközödet használod az ővé helyett, mert azt tudja managelni, a tiedben meg letílthatod a tavoli manager funciót.
 

Azt azért érdemes lenne megemlíteni, hogy a szolgáltatók nem puszta kiszúrásból nem engedik, hogy saját ONT-t használj.
A GPON nem DSL, itt nincs egy dedikált vonalad a központig, hanem van egy gerincvonal, amire több tucat előfizető csatlakozik. A leagázásokat prizmákkal és tükrökkel oldjak meg, nincs semmi aktív védelem. A központi eszköz (OLT) mondja meg az ONT-nek, hogy mikor küldhetnek jelet, hogy egymást ne zavarják. Ha valaki egy inkompatibilis ONT-t próbálna használni, lehet, hogy az egész utcában szolgáltatáskiesést idézne elő.
Megjegyzem, nem tudom, hogy mekkora különbség van ONT és ONT között. Tekintve, hogy a Telekom is 2 féle ONT-t használ.

Én annak örülnék, ha a Telekom is moduláris CPE-t (pl.: Bell Home Hub 3000) adna. Így akinek nem kellene a körítés (a velük járó bugokkal együtt), annak lenne egy biztosan kompatibilis SFP ONT-je.

Frissítés 2.

Cseréltek nálam ONT-t (egy másik hiba miatt). A típusa és a fw nem változott, és sajnos a hiba sem.

Észrevettem, hogy a következő hibaüzenet jelenik meg a logok között az ONT-n, amikor megérkezik egy ACK a szervertől:
[ERROR pktrunner] add_fwd_commands,502: Unable to determine if the flow is routed/bridged (502)

Valaki meg tudná mondani, hogy milyen csatornán érdemes az ilyen jellegű hibákat bejelenteni?

3 órája, OldMike írta:

Ez a router képes az IGMP Snooping kezelésére. Itt van a használati útmutató vonatkozó részlete:

Az Enable IGMP Snooping opciót a Disable helyett Enable funkcióra kell állítani. Valószínűleg az előző eszközön ezt valaki beállította, azért működött az IPTV.

Ha a HGW és a STB más alhálón van, akkor elsősorban IGMP Proxyra lesz szükség. Az IGMP Snooping csak a többi eszközt védi a kéretlen multicasttól.

@Sanyi85
Ha nem feltétlenül akarod a STB-ot a LAN oldalra rakni, csak nem akarsz egy külön vezetéket húzni a HGW-ből, akkor érdemesebb a router egyik sárga portját átkapcsolni a WAN oldalra, és abba dugni a STB-ot.
Nem ismerem a te routeredet, de a VLAN (nem WLAN) vagy a switch beállításokat keresd.

Pontosan mi is akarna lenni ez a bridge mode? Nálam semmin nem változtat, PPPoE Passthrough ide vagy oda.

Nekem ezek a beállítások váltak be saját router használatához:
 - PPPoePassthrough: bekapcsolva
 - Log-In: üresen hagyva
 - Password: üresen hagyva
 - Connection Trigger: manual

Nem kellet hívnom az ügyfélszolgálatot, és az újraindítást is túléli.

Egy kis frissítés, hátha jól jön még valakinek.

Szereztem egy VPS-t natív IPv6-tal, hogy lássam, hogy a szerver melyik csomagokat kapja meg.
 - a 3-way handshake megtörténik sérülésmentesen, ha otthonról indítom a TCP kapcsolatot; de a fordított esetben nem kapom meg a VPS-töl az ACK-ot
 - a VPS minden csomagot megkap a klienstől
 - a PSH, RST, FIN csomagok megérkeznek a klienshez
 - az üres ACK-ok nem érkeznek meg a klienshez

Ezután megnéztem, hogy mi történik a router ONT felőli ethernet interfészén. (Nem tudom, hogy  ez korábban miért nem jutott eszembe.)
Az üres ACK-okat tartalmazó csomagok is megérkeznek, de a PPPoE headerben a csomagméret eltér a valóstól (pl.: 106 helyett 2123, 94 helyett 1915), ezért a router PPPoE drivere eldobja.

Kíváncsiságból csináltam egy pár GB-os IPv4 packet capturet, amiben volt web, torrent, tcp, udp, de a PPPoE header sehol sem volt sérült.

Megpróbáltam a Hurricane Electric helyett a VPS felé kiépíteni tunneleket:
 - 6in4 tunnel esetén az eddigi hibát tapasztalom
 - 4in4 = IPIP: minden ok
 - GRE-n belül nekem az IPv4 és az IPv6 is ok, mással ellentétben

Találtam valakit, akinek ugyanilyen problémája volt, de másik szolgáltatónál:
Problem with 6to4 inside PPPoE

Sziasztok!

Láttam, hogy itt már többen is próbálták a Hurricane Electric 6in4 tunneljét.
Én eddig tudok a tunnelen keresztül pingelni tetszőleges IPv6 címet, de az összetettebb TCP kapcsolatok (pl. tls) hamar megszakadnak.

Csatolok egy packet capture-t, ami a PPPoE interfészen készült egy https kapcsolatról.

Sagemcom F@st 5655v2 AC ONT-t használok PPPoePassthrough módban, fw: SG3G10000494. Az IPv6 dualstack az ügyfélszolgálat szerint nem aktiválható.
A 6in4 tunnelt és a tcp kapcsolatot már próbáltam indítani a következő eszközök összes lehetséges kombinációjáról: mikrotik router, openwrt router, linux pc, windows pc. Mindegyiken a legfrissebb szoftver van, ipv4/ipv6 tűzfal/nat/fastpath kikapcsolva.

A PPPoE kapcsolatom MTU-ja 1480, a 6in4 tunnel MTU-ját végigpróbáltam 1280-tól 1460-ig. A tcp MSS-t is próbáltam kicsire venni.
A tunnelen az 1460 byte-os ICMPv6 echo csomagok egészben átjutnak.

Találkoztatok már hasonló hibával?

Köszi,
Szabolcs