Halacs

3 órája, uzman írta:

Ha van lehetőséged, tennék próbát hasonló (akár szoftveres GRE szerverrel is) és egy teljesen más, pl SoftEther-el is.

Én azt gondolom, hogy a szolgáltató nem szól bele, hogy milyen csomagokat forgalmazol, lehet az akár titkosított vagy nem. Vannak országok, ahol törvény alapján blokkolják a VPN szolgáltatókat, hazánk szerencsére nem tartozik az ilyen helyek közé, így elvileg mennie kellene akár a saját szervered felé vagy bármilyen VPN szolgáltató felé.

Igen, most ezt tervezem. Ahogy a gyerek engedi

Tök jó lenne itt valaki akinek lenne ezzel kapcsolatban megosztható tapasztalata.

4 órája, uzman írta:

Én csak arra tudok gondolni, hogy az MTU vagy a tűzfalszabályok környékén lesz valami.

Arra van lehetőséged, hogy a hardveres megoldás helyett, átmenetileg valamilyen szoftveres VPN-el megpróbálod összekapcsolni a két oldalt és úgy csinálsz egy speedtest-et (pl openvpn, softether, stb)?

Van rá lehetőségem igen: ami linuxon fut azt meg tudom próbálni.

Annyi, hogy mindenképp GRE (és lehetőleg +IPsec) alapú protokoll kellene Layer2-ben. SoftEther-t nézegettem eddig én is, de annál ilyen protokollt nem láttam. Az OpenVPN az saját TCP/UDP alapú protokollt használ.

Azért lenne szerintem fontos a közel azonos protokoll használata, hogy a Telekomos forgalom alakítást is ki lehessen zárni egyúttal.

A SoftEther amúgy tetszik, mert úgy látom az http fölött viszi át a VPN-t. Jó lenne ha menne Mikrotiken is. HTTP(s)-t nem igen fognak korlátozni sose, míg torrent-el, vpn-el, egyebekkel ez könnyedén előfordulhat ahogy mobilnet esetén már nyíltan teszik is.

Ekkor: 4/21/2021 at 12:40, b10up írta:

Mikrotiken én úgy oldottam ezt meg, hogy simán átviszi a hgw vlanját mint egy switch, és a boxoknak dedikált port van a távolabbi switcheken. 
Egyébként lehetne IGMP proxyt is csinálni vele, ehhez úgy tudom, a multicast nevű csomagot kell letölteni a mikrotik honlapjáról, és az npk fájlt winboxban feltölteni, majd újraindítás után beállítani

Melyik HGW-s VLAN ID-t kell kirakni a boxnak? Nekem perpill nem kell ugyan IP TV, de egyszer már passzoltuk a T-s IP TV-t pont ilyen bajok miatt, aztán fene tudja mit hoz a jövő.

Nekem itthon minden hálózati elem (routerek, switchek) mikrotik.

Publikus IP a routeren alap, de esetleg majd TV is kellhet. Gonodlom a PPPOE akkor is megy ha van IP TV. Ugye?

Egyelőre még koax van végig húzva a házban de lassacskán ideje lesz megszabadulni tőle és UTP-t tenni csak a TV-hez mert csak a baj van a koaxal.

8 perce, uzman írta:

Nekem az MTU értékek a gyanúsak, de nem vagyok expert a gyártó saját protokolljában. Én anno OpenVPN-el gyengébb routerekkel is magasabb sebességeket tudtam elérni, ez alapján azt gondolom, hogy nincs korlátozás - a szolgáltató csak "bután" routolja a csomagokat.

Az eszközökön nem magas a CPU terhelés (>50%)? Szükség van a mangle szabályra? Akár az is megnövelheti a feldolgozási időt, ezzel csökkentve az átviteli sebességet.

A CPU terhelés 10% alatt van folyamatosan másolás közben is, pedig az egyik routeren van radius server is. Néztem core-onként is a CPU használatot, úgy az egyik core magasabb (0-100% közt mászkál) de csak időnként ugrik fel magasra aztán "visszanyugszik".

Az MTU-val én is rengeteget játszottam. Mikrotik manual alapján épp 1500 -as MTU-t állítottam be a tunel-re, mondván hogy a tunnelben semmiképpen se legyen a csomag újra fregmentálva de nem segített.

Ha nincs mangle szabály akkor nem mennek a TCP kapcsolatok szinte egyáltalán, hiába van ott a tunnelen a "Clamp TCP MSS". Hasonló gondolatmenet vezérelt amikor a két host gép MTU -ját kézzel levittem 1250-re de attól se lett gyorsabb hiába számítottam erre.

1 órája, b10up írta:

Szia,

Én inkább a samba protokollban keresném a problémát vagy annak a környékén. Ilyen sávszél limitet én csak mobilnetnél láttam, ami tényleg aktív is volt T-nél, vezetékes neten nem. Ettől függetlenül nem lehetetlen, csak értelmét nem látnám.

Ha eltérő alhálók között másolok VPN-en, nekem is lassú az SMB alapú. Ami gyorsan szokott menni az az FTP, ha nagy fájlokról van szó, de az sem mindig. Ettől függetlenül ha belső szerveren speedtestelek (HTML5 alapú), akkor látható, hogy egyébként a VPN-t nem fogja meg a szolgáltató.

Ha samba protokol helyett HTTP-t használok (ugyanúgy VPN felett) akkor kicsivel gyorsabb, de még így is csak 100 Mbps -re kúszik fel a sebesség.

Layer 2-es a VPN és 192.168.0.0/16 subnetben van minden gép a hálózaton.

Ha routerek közti speedtestet csinálok, azaz érdekes, hogy 1300 byte méretű UDP csomagokkal van 400 Mbps körüli speed, TCP-vel viszont már csak az a fentebb is említett 100 Mbps körüli jön ki. Nem értem hol van a kutya elásva.

37 perce, uzman írta:

Szia

Mennyi a max sávszélesség, amit elér a VPN kapcsolat?

Ahhoz, hogy 1Gbit legyen a natív átvitel, a tunnel magasabb effektív sávszélességet is igényel.

Szia!

Jelen pillanatban 30 Mbps körüli a tunnel forgalom miközben egy nagy fájlt másolok keresztül rajta Windows fájlmegosztáson (smbd) keresztül egyik Ubuntu gépről a másikra. Ha egy 500 Mbps körüli átvitelt látnék már boldog lennék.

Eddig a saját VPN beállításokban kerestem a hibát (lehet ott is van), de a fenti idézet felkeltette az érdeklődésemet.

Pár technikai adat hátha valamiből kilóg a lóláb hogy én vagyok a ludas és nincs forgalom alakítás Telekom oldalon (adná az ég):

• Eszközök:
  • Mikrotik RB4011iGS+RM
  • Mikrotik CCR1009-7G-1C-1S+PC
  • IPsec hardveres támogatás mindkét oldalon
• Tunnel beállítások (mindkét oldal azonos):
  • Mikrotik EoIP (GRE + IPsec) IPv4 fölött
  • "Clamp TCP MSS" bekapcsolva
  • Tunnel MTU: 1300
  • Change MSS mangle firewall rule: 1250
    • Tunnelen bellül VLAN trunk megy
• Aktuális IPsec settings:
  • Auth.Algorithm: sha256
  • Encr.Algorithm: aes cbc
  • Encr. Key size: 256
• Telekom eszközök bridge módban
  • Optika esetén PPPOE kapcsolódás
  • Koax esetén sima bridge DHCP klienssel

Sziasztok!

Családon belüli kommunikációhoz és napi otthonról történő munkához is használunk VPN kapcsolatokat.

Adott két lakás Telekomos internettel. Az egyikben optika a másikban koax van.

Azt tapasztaljuk hogy a VPN kapcsolatok lassúak. Az egyik fajta VPN-ről biztosan tudjuk, hogy a Mikrotik EoIP protokollját használja ami egy GRE+IPsec alapú saját protokollja a Mikrotiknek.

Kezd egyre gyanúsabb lenni, hogy a Telekomnak van valami sávészélesség korlátozás (forgalom alakítás) beállítva ezekre a protokollokra. Hiába kéne 1Gbps -el menni a másolásnak egyik lakásból a másikba az kb sose történik meg VPN-en keresztül. VPN nélkül is több szál szükséges a teljes sebességhez, míg lakáson belül nincs semmi probléma ezzel.

A hup.hu -n pl van épp egy a Telekomot érintő hálózat semlegességes topic ahol linkeltek is egy elég durva kijelentését a Telekomnak. Igaz, az mobil hálózatokra vonatkozik.

https://hup.hu/node/174291

"Jó ha tudod, hogy a Gigaerős Net és Gigaerős Net + csomagok esetén a Peer-to-peer jellegű fájl megosztás és letöltés (különösen Bittorrent), illetve egyéb folyamatos, hálózati túlterhelést jelentő forgalomtípusok használata esetén a letöltési/feltöltési sebesség 2/0,2 Mbit/s. Virtuális magánhálózat (VPN) használata vagy egyéb titkosított csatornákon keresztül történő forgalmazás (pl. SSH) esetén 10/5 Mbit/s."

Tud erről bárki bármit? Az egyéb titkosított csatornákon keresztüli forgalmazásba már ennek az oldalnak a látogatása is belefér a https miatt. Az általános titkosítás ma már elég alap úgy általában az interneten.

38 perce, e.tamas írta:

@sipsza

Szia!

Ugyanezzel a problémával küzdök én is. Eltöltöttem pár órát, mire rájöttem, hogy nem MTU/MSS probléma van, hanem a PPPoE headerben rossz payload length értékek jönnek a válasz ACK-kban és magában a válasz üzenetben is, amiket így a router (vagy a Sagemcom ONT) eldob, attól függően, hogy ki terminálja a PPPoE-t.

Van (még) egy ***** kábeles netem is, amin ez eddig tökéletesen működött, ott ugye nincs PPPoE. Viszont az ***** felmondta a szolgáltatást, úgyhogy most próbálnám átrakni a HE 6in4 tunnelemet a T-s kapcsolatra. (Mert a T egyelőre nekem nem adott még natív IPv6-ot. Talán 2 éve kérdeztem őket erről, azt mondták fokozatosan vezetik be, majd sorra kerülök. Erre szerintem még várhatok egy darabig :-) )

Először azt gondoltam, hogy az ONT-s NAT környékén lehet valami gond, bár furcsa volt, hogy a ping és UDP megy, csak TCP-vel van baj. Megkértem a PPPoE passthrough beállítást az ügyfélszolgálattól, és mostmár a routerem végződteti a PPPoE-t. Ekkor találtam meg a valódi problémát, amikor az ONT felé menő porton sniffeltem a forgalmat.

Nem igazán tudom mit tudok tenni. SagemCom 5655v2 a home gw, és SG3G10000604 firmware van már rajta, és így sem működik. Márpedig meg szeretném oldani, mielőtt megszűnik az Invi netem :-)

Őszintén nem is értem, hogy hogyan tud belegányolni a PPPoE headerbe a hgw ilyen módon, ha a PPPoE-t az én routerem végződteti. Szóval az is lehet, hogy nem a hgw-vel van probléma, hanem a BRAS oldalon? De az meg hogy a pékbe rontja el a payload length-et az IP 6in4-be foglalt IPv6-on belüli TCP valamilyen attribútuma alapján, hogy csak a válasz ACK és a tényleges válasz csomagok sérülnek így? Vagy lehet, hogy csak a csomag hosszától függően romlik el?

Bár ahogy írtad, nálad az ONT csere megoldotta a hibát, szóval akkor mégis ONT hiba lehet?

Mindenesetre guglizva az invalid PPPoE payload length kulcsszavakra, azért én is találtam pár bejegyzést, ahol ugyanezt a hibát írják le, ezen a fórum bejegyzésen kívül is, szóval a probléma nem egyedi :-(.

Érdemes bejelentenem a problémát az MT ügyfélszolgálaton? Gyanítom a first line-on túl kellene jutnom valahogy, hogy érdemben tudjak beszélni erről valakivel :-)) pcap file-t tudok prezentálni nekik, amiben egyértelmű a hiba oka.

Szerintem mindenképp érdemes jelezni a hibát és szerintem érdemes azt is elmondani, hogy a dolog nem egyedi és itt ezen a fórumon van róla több infó. Ez szerintem segít átlendíteni az első szintű supporton és egyúttal segít annak is kitalálni mi a fene van aki azátn ténylegesen meg tudja esetleg oldani hiszen így nem veszik el és nem torzul a szakmai infó. Sanszos egyébként, hogy elsőre pikk-pakk le fogják zárni a hibát, de ha nem oldják meg vagy nem adnak érdemi választ akkor a My Telekom (vagy mi a hóhér a neve) oldalra belépve a hibajegyeknél megtalálod és kommenttel újra lehet nyitni aminek biztos örülni fognak de ha szakmailag korrekt meg illedelmes a dolog akkor ez így fer

6 órája, sipsza írta:

Sziasztok!

Egy ideje már kint van az SG3G10000604 firmware a Sagemcom ONT-re, de még semmilyen közleményt nem láttam a javított hibákról.
Valaki le tudná nekem ellenőrizni, hogy megoldódott-e a probléma?

Az én ONT-met időközben visszacserélték a Huawei-re (fw.: V3R017C10S150), amivel gond nélkül tudok 6in4 tunnelt használni, de valószínűleg újból egy Sagemcomot kapok, ha egy  nagyobb csomagra váltok.

Szia!

Nekem szerencsém van mert voltak olyan jó fejek annó és nekem külön bekapcsolták hogy nálam működjön a dual stack, de rövid ideig most  vissza kapcsoltam a HE tunnel interfészt a routeremben.

Eredmény:

- tunnel interfész azt mondja magáról hogy "enabled" meg hogy "running"

- ugyanakkor a ping nem megy: ping 2a00:1450:4016:801::200e interface=HE-IPv6-broker --> no route to host

Megeshet, hogy valamit én szúrok el, most nincs agyam utána gondolni, de ez alapján nem megy és ha jól emlékszem nekem is Sagemcom ONT-m van ebben a lakásban.

Azt még gyorsan megnéztem, hogy a HE oldalán a client IP az stimmel azzal amim van - script frissíti időnként úgy fest azóta is

8 órája, vagika írta:

Szia,

Csatoltam, melyik poolbol gondolod, a mindeket oldarla felvetelt /60? Probalkoztam mar mindehogy, plusz masik routerrel is, de nem igazan mukszik...

BTW, ha jol gondolom, neked 1 subneted van, es egybol amikrotik kapja a /56ot bridge miatt, nalam viszont IPTV miatt a Kaon kapja, es /60at ad tovabb.

mikro_sets.txt

Igen, nekem egy prefixem van ami /56-os és én abból osztok /64-eket. Ezek szerint neked kisebb van, de attól még lehet menni fog. Kipróbálnám aztán kiderül

A konfigod alapján van egy DHCPv6 kliensed ami csinál neked egy defaultv6 nevű IPv6 poolt. Ez a prefixed ugye ami neked /60 és nálam /56.

/ipv6 dhcp-client add add-default-route=yes default-route-distance=2 dhcp-options=hostname interface=ether5 pool-name=defaultv6 prefix-hint=::/58 request=prefix use-peer-dns=no

Ha jól látom te kézzel vetttél fel IP-t több interfészedre is. Ezeket én kitörölném és az alábbi módon vennék fel a defaultv6 IPv6 poolból címet.

Nem bogarásztam nagyon végig a konfigod, de úgy látom az ether5 lehet a WAN portod és a többi egyforma LAN portok L2-be switchelve.

/ipv6 address add advertise=no from-pool=defaultv6 interface=ether5
/ipv6 address add from-pool=defaultv6 interface=ether1

Ha minden oké akkor szerintem ezek utána ha megnézed az IPv6 címeidet a /ipv6 address print paranccsal akkor kell majd legyen a WAN és a LAN interfészeden is egy-egy /64-es cím a szolgáltatódtól kapott prefixel. A LAN oldalon ha van kliensed akkor az SLAAC-al kap is majd rögtön címet.

1 órája, vagika írta:

Sziasztok!

Ismet vannak fejlemenyek, de eredmenyt meg nem sikerult felmutatnom, igy ismet segitsegert folyamodom, hatha...

Kaptam egy Kaon CG3000-et, amivel diketben szinten megy a V6, csak ugye a DNS. Viszont, mar szepen kapok egy /60 prefixet a mikrotikra, wan IFen a /56bol kapott /64el is mukodik:

[admin@MikroTik] > /tool traceroute 2001:4860:4860::8888
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST STD-DEV STATUS
 1 2001:4c4c:12b0:5c00:92f8:91ff...   0%   23   0.3ms     0.8     0.2     1.6     0.4
 2                                  100%   23 timeout
 3 2001:4c48:200:2500::1:2            0%   23   9.8ms     8.7     3.6    17.4     2.7
 4 2001:4c48:bec::1                   0%   23   7.6ms     7.3     4.1    11.1     1.5
 5 2001:4c48:bec::5                 8.7%   23 timeout     7.5     3.1    10.4     2.3
 6 2001:4c48:200:6100::2:2            0%   23   9.9ms     8.8     5.1    15.2     2.7
 7 2001:4860:0:a::1                   0%   22   7.3ms     8.2     2.8    15.6     3.5
 8 2001:4860:0:1::2919                0%   22   8.1ms     7.7     3.3    11.9     1.8
 9 2001:4860:4860::8888               0%   22   6.2ms     7.3     3.6    12.8     2.2

viszont LAN oldalrol elvesznek a csomagok a /60 bol tovabbosztottal:

C:\WINDOWS\system32>tracert -6 index.hu

Tracing route to index.hu [2a02:730::1870]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  2001:4c4c:12b0:5cf0::3
  2     6 ms    <1 ms    <1 ms  20014C4C12B05C0092F891FFFE55719F.catv.pool.telekom.hu [2001:4c4c:12b0:5c00:92f8:91ff:fe55:719f]
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.

Kiprobaltam egy masik routerrel, DD-WRTvel, az is szepen kapott prefixet, viszont az eredmeny ugyanaz. Nem tudom, hogy a Kaon nyeli-e le, vagy a halo mogotte...

Tud esetleg barki segiteni ebben? Barkinek van tapasztalata router bodu HGW-el, vagy akinek sikerult, bridge-ben volt?

Elore is koszi a segitseget!

WAN és LAN oldalra is vettél fel IP-t a kapott prefixel (poolból) ?

Ha igen, esetleg egy config exportot csinálhatnál terminálból és azt feltölthetnéd természetesen a szenzitív adatokra vigyázva: /export hide-sensitive terse

1 órája, kopa írta:

Nem térség függő, eszköz függő. Most még csak 8245H-ra van kiengedve, Sagemen csak pár embernek próbaként (és pont én intézhettem a te egri ügyedet ) mert még elég bugos. Türelem, hamarosan kint lesz tömegesen ha jön új FW.

Ja és lehetőleg ezért lehetőleg ne kérjetek eszközcserét, nem nagyon szeretjük az indokolatlan eszközcserét... Plusz 150M felett csak Sagemet szerelhetnünk fel mostmár.
És a fenti weblapon is világosan le van írva:

"Az alábbiakban találhatja azon eszközöket, platformokat amelyek jelenleg támogatják az IPv6-os technológiát:

GPON:

• Huawei HG850
• Huawei HG850a
• Huawei HG8245H"

Köszi a kommentet és a segítséget is a háttérből ha te oldottad meg a problémám

2 órája, btz írta:

Pontosan így van. Ha a HGW / ONT rendelkezik prefixel, onnantól tiéd a pálya, hogy beállítod az alhálózatot a saját eszközre, kapcsolódott kliensekre. 

Munkaidő végeztével gyorsan át is állítottam mind a két helyen a routereket, hogy csak prefixet kérjen és kézzel vettem fel WAN és LAN oldalra is a v6 címeket a DHCPv6 poolból. Minden faín DNS-t nem néztem adnak e, mert az DNS over TLS alapon megy más szolgáltatótól, de ez nem is olyan fontos tulajdonképpen.

Szóval megerősíthetem: Eger térségében optikai hálózaton és Budapesten koaxon is megy a dual stack IPv6 DHCPv6-al Telekom hálózaton. Eger térségében úgy értettem a kollégát telefonon, hogy csak engem vettek le a területi IPv6 tiltásról ami az előfizetési IPv6 beállítástól független.

Így akkor már tényleg csak annyi maradt, hogy egyformán legyen beállítva a Telekom oldalán is, hogy DHCPv6-on lehet e címet is kérni vagy csak prefixet, egyébként stimmel úgy néz ki minden. Pacsi nekik!

Ami még szerintem tök jó lenne (hátha olvassa valaki a Telekomtól is), hogy lehetne egy oldaluk ahol leírják, hogy melyik térségbe és melyik technológián működik már az IPv6 és hol nem. Ha odaírják mi a terv az plusz piros pont, bár tudjuk a terv és a valóság sokszor nem esnek egybe ilyen-olyan okokból (pl COVID).

5 perce, sipsza írta:

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.

Lehet tudnék osztani abból valóban. Mivel koaxon így ment így állítottam be és azóta is megy szépen. Este tudom csak megpróbálni, hogy a routerem internet felé néző lábára is ugyanabból a prefixből vegyek fel címet, de bárhogyis szerintem egyformán lenne praktikus működni mindenhol.

Koaxon ezt mondja a DHCPv6 kliens:

[admin@mydomain] > /ipv6 dhcp-client print value-list
               interface: ether1-gateway
                  status: bound
                    duid: 0x00030001744d288d2f30
          dhcp-server-v6: fe80::2ca:e5ff:fe3d:d419
                 request: address,prefix
       add-default-route: yes
  default-route-distance: 1
            use-peer-dns: no
               pool-name: wan-pool
      pool-prefix-length: 64
             prefix-hint: ::/0
            dhcp-options:
                  prefix: 2001:4c4c:1ee0:xxxx::/56, 1w2d1h17m59s
                 address: 2001:4c4c:202:xx:xxxx:xxxx:xxxx:xxxx, 1w2d1h17m59s

Ö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.

59 perce, vagika írta:

Sziasztok,

HFCn van egy csodalatos f@st 3890V3 HGWm, mely moge egy mikrotik HEXet szeretnek hegeszteni. V4 OK DMZben, de V6 prefixet nem kapok. (V6IPt kap, ha azt kerek, de ugye az igy sok mindenre nem jo.) Mukodik valakinek ezzel a HGWvel DHCP6PD?

Lehet en vagyok lama, de a DOCSIS3 -as fasszal mukodott.

Koszi!

Szia!

Nálam ez a helyzet:

- Budapest, koax, mikrotik router, DHCPv6-on cím és prefix is OK, tudok v6 címet osztani tovább.

- Eger körzet, optika, mikrotik router, PPPoE, DHCPv6-on se cím se prefix. PPPoE-n link local cím sincs (fe80...). Erre a címre vonatkozólag lásd a korábbi bejegyzésemben az összefoglalót.

Szombaton jeleztem a T hibabejelentőjén a problémát, szerdán felhívott egy hozzáértő kolléga, hogy tájékoztasson területi eltérések vannak az IPv6-ot illetően: Eger térségében még nincs aktiválva az IPv6 protokoll, ezért nem kapok IPv6 címet.

A hibabejelentőn azt látják csak, hogy az előfizetésre aktiválva van, de azt már nem látják, hogy a területre ahol az előfizetés van nincs.

Kizárólag azokra az előfizetésekre nincs aktiválva az IPv6 ahol ezt külön kérték hogy ne legyen.

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.

Eger térségében várhatóan az ősszel lesz az IPv6 aktiválva. Eredetileg a nyáron akarták volna, de a COVID miatt ez most várhatóan három hónapot csúszik, mert nem mindent sikerült/lehet home officeból kellő alapossággal megvalósítani.

Ami még hasznos infó, hogy az IPv6 aktiváltsága független attól, hogy optika vagy koax a vivőközeg amit használunk.

Ezek az infók amiket kaptam a T-től. 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

4 órája, Halacs írta:

@sipsza

gateway-t vettél fel bármit? Ez van most beállítva nálam.

Ok, nincs gateway gond. Az tréfált meg, hogy ha routeren belül a LAN oldali interfészen próbálok publikus címet pingelni az nem megy, de másik LAN oldali gépről jó. Bocsi

@sipsza

gateway-t vettél fel bármit? Ez van most beállítva nálam.

A koaxos T előfizetésen úgy látom kicsit elhamarkodott volt az öröm, ugyanis ha a mikrotiken terminálból a WAN interfészen pingelem a google.com-ot v6-on akkor arra van válasz, ha viszont a helyi interfészen akkor ott no route to host. Ami érdekes, hogy előtte HE tunnellel minden szépen ment ezen az előfizetésen/routeren.

DHCPv6-on prefixete kérek, rapid commit = yes, add default route = yes, pool prefix length = 64. Kapott prefix /56. Belső intefészre vettem csak fel IP-t, a kapott pool-ból ::1/64-el.

Ez gyanús hogy nem a T-nél hiba, de nem esik le akkor mi a baj.

@sipsza

Hátha mások is küzdeni fognak hasonlóval ezért leírom:

- D optika és szintén PPPoE esetén DHCPv6-al megy remekül. Létrejön a PPPoE interfészen az fe80-as cím. /64-es prefixet kapok DHCPv6-al.

- Telekom és koax esetén PPPoE nélkül de szintén DHCPv6-al szintén megy és az ether1-en (WAN) itt is van fe80-as cím. /56-os prefixet kapok DHCPv6-al.

- Telekom optika és PPPoE esetén a Telekomnál dolgoznak a hibán, lévén nincs PPP IPV6CP válasz a Telekomtól.

Amire még ma rájöttem és fontos: IPv6 firewall-ban engedélyezni kell az input, src:547/udp csomagokat a DHCPv6-hoz. Ez nekem egyik helyen se volt eddig. Miután engedélyeztem már csak a Telekom optikán nem működik, de ezen meg elvileg dolgozik a support

@sipsza

Ééés tényleg! Ha jól sejtem a képen látható szűrés mellet látnom kellene a választ is ha van. Ugye?

Megpróbálok egy modem áramtalanítást, router újraindítást hátha (bár nem sok reményt fűzök hozzá), aztán megy a csere kérés.

15 órája, sipsza írta:

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.

Szia!

Ezek mind megvannak. A PPPoE kapcsolatom él, a profile neve default aminél meg is adtam hogy use-ipv6=yes de mégsincs a PPPoE interfészre fe80-as link local cím az ipv6 címek közt. Ennek amúgy nem kéne felvevődnie a Telekomtól függetlenül? A telekom azt mondja hogy engedélyezve van az ipv6 ("látok egy ipv4 és egy ipv6 címet").

Ekkor: 3/15/2020 at 22:00, sipsza írta:

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.

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!

Én is ezzel küdtök. Sikerült jutnod valamire? A csomag méreteket nem néztem még, de nálam a következő van.

Adott két lakás, mindkettőben Telekom. Az egyik ("A" lakás) Telekom optikával, a másik ("B" lakás) Telekom de koaxon. Mindkét helyen Mikrotik router van.

A "B" lakásban a HE 6in4 tunnel remekül megy, míg a másik lakásban ping6 rendben, de TCP kapcsolat (curl -vv6 http://google.com) már nem megy rendesen. A konfigurációban nem találtam különbséget a két lakás közt, sőt mi több úgy emlékszek mielőtt Telekomra váltottam volna *****-vel működött is frankón minden.

Természetesen IPv4 esetén semmi probléma nincs.

Ha megnézem a router HE tunnel interészét akkor azt látom, hogy kimennek a csomagok, még a kapcsolat is felépül de mikor a HTTP payload kimegy már nem jön többet ACK ezért indul a retransmisson majd kapcsolat bontás (FIN,ACK majd RST).