Sziasztok!
Tegnap jól elszórakoztam a MikroTik hEX routeremmel és a hálózattal.
Egészen addig, hogy a MikroTik rövid időn belül (0,5-1,5h) le tudja akasztani a Tkom HGW-jét (Sagem F@st 5670).
A jelenség: elmegy a Net, mert az Internet zöld LED-je kialszik, a telefon LED piros lesz, a többi LED marad zöld.
Ilyenkor még igazán switch-ként se működik a HGW. Egyetlen lehetőség: ki-bekapcs. Nem túl előnyös, ha azt
hiszem, hogy a Net egy infrastruktúra, mint pl. a villany és "sosem" áll le.
Előfordult ez máskor is, MikroTik nélkül, de lényegesen ritkábban. Nincs a szívem csücskében ez a HGW, bár nagyon
sokat tud, de az sw.-je ...
A Tkomnál addig rinyáltam minden féle formában, hogy szedjenek ki a CG-NAT mögül ÉS kapjak szűretlen IPv6-ot,
hogy beállították a modemet "valamibe". Elvileg bridzsbe, mert előtte router volt. Ez most nem egyértelmű, mert
most is van a HGW szerint PPP kapcsolat, de nem az előfizetési adataimmal. A HGW-ből tudom pingetni a saját
CG-nat-os (100.96) IP-met és a Tkom DNS1 és 2-es szerverét. Mindezt a HGW-ből. A default gw-t, ami 10.5 valami,
azt viszont nem.
Már itt nem értem az egészet, de nem ez a lényeg!
PPPoE passthrough be van kapcsolva.
Elvileg kapok 2 sessiont a Tkomtól. Igaz, hogy ez mellé felzárkózik most 3.-nak ez a fenti PPP-s kapcsolat, hogy
Tovább bonyolódjon a helyzet.
PPPoE session 1: a MikroTik terminálná. Ez az, ami vélhetően leakasztja a HGW-t.
PPPoE session 2: egy normál WiFi router, szintén egy PPPoE terminálással. Ez most működk kb. 1h-ja ...
A HGW-nek 1+4 portja van: 2,5G-s kék és 4 db. 1G-s sárga.
A kékbe lenne dugva a MikroTik ether1-es portja a bejövő Nethez. (jelenleg kihúzva)
A továbbiak:
WiFi router
RPi egyik interfésze.
A HGW LAN-ja a 192.168.1.1/24-et kapja defaulton hagyva. Ez a 192.168.1.0/24 amolyan DMZ LAN lenne, de
Nem a biztonság miatt, hanem köztes hálózat, ha vissza kell bontani mindent, hogy legyen Net, ha megmakacsolja
magát a HGW.
A MikroTik a 192.168.1.2
A WiFi router 192.168.1.3
Az RPi 192.168.1.4
Továbbiak 5-től jönnek, ha a HGW-hez WiFi-vel, vagy a maradék vezetékesen csatlakozik valami.
A WiFi router OWRT 15.0-ás, régi, gyári sw-vel, némileg felturbózva a gyártó dolgaival, de teljesen elérhető az
OWRT, csak nem friss!
A WiFi router az AP a hálóban (alapban), de nem ő DHCP szerver, hanem a Mikrotik.
Amivel igazán most bajban vagyok az a HGW leakadása (nem ez most a feladat igazán, bár érdekes, hogy
egész éjjel PPP(oE) baja volt, aztán a reggeli ki-bekapcsolás óta ez most elmúlt ...), hanem a default route!
Alapban a MikroTik lenne a default gw, hiszen ő terminálja a PPPoE-t.
De ha most a WiFi terminál, akkor neki kell lennie!
Kézzel meg tudom oldani a dolgot, de az összes eszközön nem!
Be kell vetni a dinamikus routolást? RIP, OSPF?
Lehet, hogy nem mindent írtam le, de ugye az én fejemben megvan a topológia.
Pl. jó lenne, ha lehetne állítani route-okat a HGW-n, ha másért nem, hogy ne kellejen az ő 192.168.1.0-ás
hálójába csatlakozni, ha el akarom érni, hogy állítgassam.
Köszönöm az együttgondolkozást!
Hozzászólások
Nekem többször kellett hívnom az ügyfélszolit, hogy rakjanak már vissza publikus tartományba, mert a fene sem kérte vissza a cg-natot. Legutóbb a mókamiki kitalálta, hogy ahhoz nekem fixip kell… már nem volt erőm vitatkozni, úgyhogy elengedtem… de kb 45 perc volt átadnia az ezáltal megváltozó loginnevet (helyesen). De máskor/máshol teljesen le kellett resetelni, hogy a központi módosítások aktiválódjanak is.
Én amúgy azt vettem észre, hogy a HGW portjai bridge-ben vannak, így nem komálja ha több kábelen is rá van kötve a hálózatra (loop): visszajön a pppoe interface-en, rouge dhcp-t ad (le lehet tiltani, de ez a köv sw update-ig él csak),stb.
Amúgy nem teljesen értem a topológiádat, miért nem a Hex mögé van fűzve az AP (+Rpi)?
"The only valid measurement of code quality: WTFs/min"
Nekem is ez a gyanús, csak azt nem értem, ha ez egy normális eszköz lenne (HGW), védekezne a loop ellen.
Persze most is ezt csinálja ... piros lámpa ...
Az a baj, hogy nem egységsugarú user-ként akarom használni a rendszert.
De egybként: hol a loop?
A kérdést nem igazán neked szegezem, de:
Az Rpi nem routol a két lába között! Tiltja valami, hogy két külön alhálózatból csatlakozhassak egy 2 interfészes eszközzel?
Üdv:
Ruzsi
hogyan éred el a HGW-t (egyáltalán mi ad neki ip-t?) és hogyan a Hex-et? Ott a 2 láb amit a HGW és a géped szépen összeköt…
Hogyan kapnak a wifi klienseid ip-t? Ott a rouge DHCP-d.
Nézz a mikrotiken logot, szerintem látszódni fog, sőt talán radvd bejegyzés is lesz ott.
Értem,hogy a mikrotik az új eszköz, de sztem annyira nem többletmeló a 2 régi eszköz utp-jét átdugni. De ha kiesik 1 óra az átállás miatt…sztem azt már rég elégetted. Ha meg tesztelni szeretnél, ne a hgw-re hanem a wifi routeredre kösd és pppoe helyett dhcp klienssel adj neki ip-t.
ez nekem azonos subnetnek tűnik avagy typo :)
"The only valid measurement of code quality: WTFs/min"
A HGW-t a LAN-ja felől támadom.
Gyári, default IP-je a LAN-on.
Az említett PPP kapcsolatot a Tkom konfigolta és CG-NAT-os (100.96.x.y) IP-je van. Az átjáró valami 10.5... és nem tudom pingetni.
DNS-nek a Tkom szabvány 2 IP-je jön a PPP-ből, ami pingethető (PPPoE nélkül is, ha jól emlékszem, de a pinget magából a HGW-ből indítom). Szerintem a HGW nem PPPoE-zik, annak konfigbeli megjelenését nem látom! Ha megy is, annak az optika felé kellene mennie, nem a LAN lábára.
A WiFi kliensek egy TP-Link AP-n keresztül a MikroTik-től kapnak IP-t, a MikroTik belső LAN-jából (ez az igazi otthoni LAN).
Tehát NEM a HGW ad IP-t ide.
Egy darabig a MikroTik-nek a WAN oldalára a HGW adott DHCP-n IP-t, de most ezt áttettem fix IP-re és a HGW+1 a címe.
radvd-nek nem láttam nyomát.
A kieséssel az a baj, hogy távolról nem tudom elérni! Ha otthon vagyok, akkor megy a ki-bekapcs, bár azért se vagyok oda.
A lényeg: a távoli elérés lenne!
A 192.168.1.0/24 a HGW LAN-ja. Azaz a MikroTik WAN oldala. Ezeken keresztül megy a PPPoE mint hordozó réteg.De ugye ez az oE lényege.
Ha működik az IPv6, nincs baj azzal, hogy ki hol van. Viszont az IPv4-nél az agyon port-forwardingolásból már elegem
lett! Ezért a cél az IPv6. Sajnos ugye minden dinamikus IP cím cserekor változik az IPv6 PD-m, de ezt eddig a MikroTik jól kezelte és szépen adta is a klienseknek.
Tehát:
Net->Tkom->HGW->MikroTik->belső LAN.
(Net->MikroTik->belső LAN, PPPoE-val).
Belső LAN ->AP -> WiFi
->vezetékes LAN.
Teljesen default konfig így.
Viszont jön az RPi, ami direktben csatlakozik egy interfésszel a HGW-re és olyan IP-t is kap, míg a másikkal a MikroTik belső LAN-jára csatlakozik (konkrétan a MikroTik-re) és onnan is kap IP-t (DHCP-vel). Tehát: RPi pl. eth0 192.168.1.x/24; eth1: 192.168.8.z/24.
Az RPi nem routol a két if. között!
Azon csodálkoznék, ha itt lehetne hurok! Nincs bridzs sem! Ha másnak nem is kéne szűrni, a MikroTik-nek igen!
Üdv:
Ruzsi
VS.
most akkor hány éves a kapitány? :)
szerk:
Jól értem, hogy így néz ki?
https://pasteboard.co/FJuuUKXUfvha.png
(Egyébként nem vagyok meggyőződve róla, hogy mindkét PPPoE sessiont indíthatod saját eszközről...)
"The only valid measurement of code quality: WTFs/min"
Kitűnő a rajzod!
Ez van és így is lenne jó! (bár a 2. PPPoE csak játék, jelenleg gyakorlati haszna nincs)
Nem feltétlenül CG-NAT, amit a rajzon jelöltél. Azt a Tkom kavarja időnként, amit én megreklamálok és utána visszacsinálja, majd go back.
A dupla PPPoE megy, külön publikus IP-vel (v4 -és v6), használható, addig, amíg valamitől a kedves HGW le nem akad.
Akkor vége van mindennek! Tehát nem csak a PPPoE-knak, hanem a LAN oldalán a switch-cselésnek, telefonnak, mindennek.
Kíváncsi lennék, hogy egy másik Tkom-os - akár más HGW-s eszközzel - földrajzi helyen felépített, az én előfizetési usernév+jelszó párosommal becsatlakozott PPPoE mennyire/meddig működne!?
A kapitány 1,5 éves. Akkor vitorlázott be az optikán. :-)
Üdv:
Ruzsi
rouge vs. rogue
Kifejtenéd?
Köszi!
Üdv:
Ruzsi
ez sztem nekem szólt :)
"The only valid measurement of code quality: WTFs/min"
Csak tippelek, mi van ha layer 2 szinten van a hiba , kapsz pl. egy "magic packetet", FF:FF:FF:FF:FF:FF” MAC cimmel , vagy valami multicast cimmel amit minden interface elfogad ?
Itt a routerek között ebben az esetben lehet loop, a két kábel miatt. Illetve STP a routerekben bekapcsolva ?
De ez csak egy tipp.
https://blog.claryel.hu
L2 network loop-nál is ez történik.
https://blog.claryel.hu
HGW-n nem tudom, de nem találtam ilyet eddig.
MikroTik-en nem állítottam.
TP-Link-en sem, de ott van ilyen lehtőség OWRT alatt.
A kérdés: ha loop van, akkor nem 05,15h-2 nap után jön ki - szerintem.
MikroTik log-ban nem láttam erre vonatkozó bejegyzést.
Tp-Link-et meg nem néztem.
Tegnap este óta csak a MikroTik csatlakozik a HGW-re.
Üdv:
Ruzsi
Van mikrotiken is STP, szerintem kapcsold be. Nem tudom , hogy mit csinálnak a routerek, ha "odatéved" egy multicast csomag (olyan , ami egy "ip4" nélküli csomag, nincs benne ip cím csak mac cim", tehát layer2-es csomag) Talán lesz aki tudja, de ha mikrotik kap egy ilyet , és ha visszaküldi HGW-nek, az meg újra visszaküldi mikrotiknek, akkor jöhet a kikapcs bekapcs. De ez tipp, nem vagyok ekkora májer.
https://i.ytimg.com/vi/-CDNyv-E4Ss/maxresdefault.jpg
https://blog.claryel.hu
Oké, köszönöm!
Az jó lenne, ha tudnánk, mi a baja, amikor leakadt! Pl. egy log-bejegyzés ... az utókornak.
Üdv:
Ruzsi
Kipróbáltam a loop-ot, egy mikrotik AP -be az eddigi utp mellé bedugtam mégegyet párhuzamosan, szóval 2 kábel TL-SG108PE menedzselhető switch-ból, (hasonlóan, mint nálad van)
ez a két kábel megy cAP ac -be. TPLink -ben loop prevention disabled, mikrotikban stp -spanning tree inaktív. Kábel bedug, de nem történt semmi, switchek ilyen esetben azonnal lefagynak, azt vártam, hogy azonnal lefagy, de nem.
(Mikrotik AP ben bridge-ben minden (eth1+eth2+wln1+wlan2)) .
Egy óra múlva megnéztem , nem volt net, de az AP-be, switchbe kicsit lassabban , de be tudtam jelentkezni. Kikapcs bekapcs, megismételtem ugyanez volt az eredmény egy óra múlva .
Mikrotik naplóban egy bejegyzés volt a sok másik mellet, warning kékkel:
ether1 excessive broadcasts/multicasts, probably a loop
https://blog.claryel.hu
Köszönöm, hogy vetted a fáradtságot!
A legutóbbi mindent lehúzok és csak a MikroTik maradt óta - még - nem akadt le a HGW! Ez napokkal ezelőtt volt, ami jó jel lehet!
Ennek ellenére nem igazán fér bele a tudományos világnézetembe ez a jelenség, de ha ettől a HGW-től akarok Netet, akkor megtanulok élni vele. Remélem, már nem sokáig,
bár a mobilnetes elérés se lesz sokkal könnyebb, megbízhatóbb.
Most úgy látom, hogy VPN-t kell kihúznom majd, de nem a megbízhatóság miatt, mert ha nincs hordozó réteg, akkor bármit csinálhatok, akkor se lesz kapcsolatom.
Üdv:
Ruzsi
Sok topik szól már erről a katyvaszról, amit összeállítottál ezekkel az eszközökkel.
Az eredeti célt kellene ismernünk ahhoz, hogy érdemben segíteni tudjunk.
Szerintem nem kell így jól működnie, ahogy most a leírásaid szerint össze van állítva. A HGW nem arra van, hogy LAN switch és router is legyen egyben. A PPPoE passthrough nem arra van, hogy egyszerre több eszköz csatlakozzon azonos adatokkal (így valószínű azonos IP-t kapva) az internet felé. Stb.
Szóval, mi az oka annak, hogy a felállás _nem_ a következő: internet->HGW(passthrough, egyéb funkció, csatlakozás nincs)->Mikrotik(PPPoE kliens, default GW)->switch->mindenmás?
1. Mert a MikroTik "új" a rendszerben és elállítva nem szerettem volna minden veszíteni!
Ezt most megoldja a Tkom eszköze. Mármint a leakadást.
2. Ne egy db. eszköz működése alapján kelljen eldöntenem, hogy megy-e a HGW.
Sajnos ezt se tudom így biztosan, mert ha kikattan a HGW, akkor switch-ként se hajlandó dolgozni. Csak és kizárólag a táp elvételével hajlandó újraindulni.
3. Mi tiltja elméleti alaponb, hogy ez a konfiguráció (hardveres huzalozás) működhessen?
4. Ki lehet próbálni, hogy mit jelent a dupla PPPoE, ha már adja a jó Tkom!
5. Miért kell csak és kizárólag sémákban gondolkozni?
6. Kitűnő kísérletezési lehetőség! Főleg azzal, amit a MikroTik tud.
A Sagem-et erősen minősíti, hogy az én felületemen nincs egy route állítási lehetőség ...
Egyébként: kipróbáltam és lehúztam mindent, kivéve a MikroTik-et. Így is sikerült piros lámpát kapnom
a HGW-n.
Az eredeti cél: IPv6 transzparens használta lakossági előfizetőként mindkét irányban!
A Sagem ennek is útját állja, mert a pin holing kritikán aluli. Egyszerűen sw hibás és nem az, hogy engedi, vagy sem a forgalmat,
hanem hogy pl. nem törölhető egy már beírt szabály ...
Ehhez jön a hirtelen kapott CG-NAT, de ebből kikecmeregtem.
Fix IPv4 felejtős még fizetés ellenében is, mert lakossági előfizető vagyok.
CG-NAT-ból kivéve, megjött a publikus IPv4, de ugrott vele együtt az IPv6.
Bonyolult dolog ez a hálózatosdi, főleg ekkora cégnél, bár mentségükre szóljon, végül sikerült az IPv6 és a CG-NAT is
eltűnt. Most van piros lámpa és HGW leakadás. Mindez egyetlen szó nélkül a logjában, hogy mi fáj neki, hogy esetleg
tehessek ellene.
Leginkább úgy tűnik,. a MikroTik-et rühelli.
Nem gondolnám, hogy dubla (2 eszközön) végződtetett PPPoE lenne itt az elméleti baj!
Az már persze kétséges, hogy maga a HGW miért megy CG-NAT-ba és miért van beállítva így egy 3. kapcsolat, ami
viszont már nem az én előfizetői név/jelszavamat használja (láthatóan Tkom-os usernév).
Ha bridzsben van az eszköz, akkor mi ez a 3. kapcsolat, ami PPP-n (nem PPPoE-n!) megy és minek?
Szóval a célt megfogalmaztam.
MikroTik úgy néz ki, veszi az IPv6 PD-s feladatot és intézi az IPv6-ot a belső LAN felé, de a HGW leakadással
már ő sem bír!
Értem, hogy ez egy katyvasz (tegnap előtt már nekem is le kellett rajzolnom, mit hová dugtam, de mág mindig tartom, hogy van egy köztes LAN-om, ami a HGW és a MikroTik között van és oda nem csak ők ketten csatlakoznak, hanem más is, igaz, azok nem látnak ki a Netre! Ez is jó feladat lenne, de majd akkor, ha már nem kapok piros lámpát a HGW-től.
(Egyébként érdekes, hogy HGW zöld Internet LED-je az aktív Netes forgalom ellenére se villog, azaz nem tudom, mit is
jelent a villogása, mert tud és szokott villogni. A Sagem leírása kb. 0, ahhoz képest, amit ez az eszköz tudna, ha az
sw-jét megcsinálták volna ...)
Sokkal jobb lenne, ha pl. egy MikroTik-kel terminálná a optikáját a Tkom egy SFP-s eszközön, még ha sok szempontból
kevesebbet is tudna.
Remélem, nem veszed kioktatásnak a fentieket, de úgy látom a Netes Tkom-os beírásokat, hogy nem én vagyok
az egyetlen, aki küzd ezzel a fekete dobozzal!
Szeretném, ha más nem szívna vele annyit, amennyit én már szívtam!
Gondolkozm, hogy átállok mobilnetre, de a Yettel-től jöttem az ő Huawei 4G-s dobozukról és dekraláltan nincs IPv6
és feltöltő kártyás elérésnék CG-NAT-ozni kell. Eredetileg OtthoNet-em volt és ott még adták a publikus IP-t.
Üdv:
Ruzsi
Én miért venném kioktatásnak? Te kérdeztél...
A Telekom (és a többi nagy ISP) mind GPON-t használ, amire nem lehet csak úgy rádugni egy ügyfél GPON SFP-t. Sajátot (mármint GPON SFP-t komplett HGW helyett) meg azért nem ad senki, mert nem akarják a support-ot adni mellé (ami kellene bőven, mert nagyjából senki nem érti, hogy megy ez a GPON és/vagy az SFP mibe működik és mibe nem). Így marad, hogy adnak egy saját GPON végberendezést, és azt vagy wifi router-ként használod, vagy modemként saját router elé. A vegyes használat sehol sem támogatott (nincs leírva, hogy nem tudja, de erre nem tesztelik és nem supportálják).
Erre kérded Te, hogy miért kellene sémákba gondolokodni, mindent oda kötsz ahová neked tetszik és úgy konfigolod ahogy gondolod. Azért kell sémákba gondolkodni, mert ez IT és hálózat, ez ilyen. Ha nem szereted a sémákat, akkor fess képeket vagy írj zenét ;-). Itt nem csinálhatsz bármit a kedved szerint, csak abban az esetben, ha az összes eszköz a Tiéd (te választottad, mert tudod, hogy tudja ami neked kell), és Te felelsz a rajta futó szoftverért és konfigért. Ez itt nem így van, mert a HGW kapásból a Telekomé, a gyárihoz képest is módosított szoftverrel, és tud amit tud, meg nem tudja amit nem tud.
Nekünk jópár helyen van Mikrotik (és másféle) router Telekom és Digi GPON eszköz mögött, amik mind PPPoE passthrough módban működnek, és soha semmilyen gondunk nem volt sehol, egyszer sem akadt le a net a HGW-t hibájából (semelyik típussal, nem csak ezzel a Te féléddel).
A CGNATról is megemlékeznék, mert lehet keveredik a szezon a fazonnal. A CGNAT egy ISP-k által használt NAT módszer, aminek annyi a specialitása, hogy 1) elvileg sehol máshol nem használt IP tartományon működik, hogy se az ügyfél belső címeivel, sem publikus címekkel ne ütközzön, 2) jellemzően determinisztikus, valam módon. A valóságban a 100.64.0.0/10 szabadon használható privát tartomány (nem tiltja semmi a használatát), és bármi felett üzemeltethető (akár PPPoE kapcsolaton, akár DHCP-vel, stb. osztható). Így sokszor a 100.64. tartományt látva sokan CGNAT-ra gondolnak, holott lehet csak IP szeparáció mindenféle NAT nélkül. A tartományt hívják sokan így az eredeti funkciója miatt.
A Telekom két PPPoE kapcsolatát úgy kell érteni, hogy van egy az ügyfél szabad felhasználására, meg van egy másik, arra az esetre, ha az elsőt az ügyfél használná, így a HGW a másodikon kapcsolódik az IPTV működétetése, meg a saját wifi működtetése okán. Ez utóbbi kettő lekapcsolható, ha nincs ilyenekre szükség. Szerintem nem lehet két ügyfél PPPoE. Azaz lehet műszakilag elindul, csak valószínű nem úgy viselkedik, ahogy gondolod/várod.
Ha szerinted a Mikrotik a gond az egészben, akkor cseréld ki egy másik fajta router-re, és teszteld, úgy jó-e minden. Tippem: szerintem pont ilyen rossz lesz.
Azt nem értem, miért ennyire fontos az otthoni IPv6, hogy ennyit küzdesz érte. Egy sima dinamikus publikus IPv4-gyel meg egy dyn. dns szolgáltatással mindent is meg lehet oldani. Ráadásul az kiosztott IPv6 sem fix, az is változhat...
A végére meg a fekete leves: többen leírtuk, hogy _szerintünk_ mi rossz. Ennek ellenére azt nem változtatod meg, hanem győzködsz mindenkit, hogy de ennek így mennie kellene, csak nem jössz rá a hibára, meg mi se.
1-2 állításra reagálnék:
Ha a Tkom minden (!) műszakis dolgozója és az ÜSz idevonatkozó emberei profi módon értenének az eszközeikhez, rendszereikhez, nem lenne baj, hogy azt adnak amit.
Ja és még egy: működne is!
A Netről - és ittnei megjegyzésekből - az derül ki, hogy nem felhőtlen a kapcsolat ezekkel a HGW-kkel. Ha csak a szabvány dolgokat akarod, akkor megy. Másokkal más sokkal kevésbé!
'But it works!' - ahogy felénk a Siemens-ről elhíresült.
Pilanatig nem vitatom, hogy máshol jól működik. De ez engem nem vígasztal! Attól én még nem tudom használni a cuccaimat otthon.
A CG-NAT-tal igazad lehet, vele nem igazán kerültem személyes kapcsolatba, leszámítva a szolgáltatókat, ha éppen azt adnak.
Az érdekelne, hogy egy ilyen háló mögött lévő LAN-ba hogyan jutsz be kintről, port forward nélkül. Illetve: hol is port forwardolsz?
A 2. PPPoE session pont annyira jól működik, mint amennyire a HGW nem akad le. Ha ő csinálja a dolgát, akkor megy mindkét PPPoE is. Ha meg leakadt, akkor semmi se megy, de ezen nem csodálkozom, hiszen minden rajta megy keresztül. Amíg másik kijáratom nincs a Netre, addig ez így lesz.
Attól, hogy más nem használja így, tiltva nincs, dokumnetálva szintén nincs, igaz az sem, hogy ez így van! Ezt is a Netről gyűjtöttem be. De nem ez a lényeg! Ha nem menne, attól még boldog Tkom felhasználó lennék.
Pillanatig se állítottam és nem is gondolom, hogy a MikroTik a hibás! A TP-Link pont ugyan így le tudja akasztani. Talán picit ritkábban, de nem biztos, hogy minden körülmény ugyan az
Az IPv6 azt fontos, mert kényelmesen nem tudok bejutni a saját rendszerembe, csak ha agyon port-forwardolom. CG-NAT-nál pedig már ez sincs! Maradna a bentről indított VPN, kín-keservesen, muszályból.
(és még ezt írtam, megint leakadt. Átálltam a mobilnetre ... semmi nem változott, egy notebook, semmi forgalommal, szövegbeírás közben ... először a telefont dobja le, majd PPP timeout után az Internet zöld ledjét is veszítettem)
Örülök, ha nem vitatkozuk, hanem gondolkozunk, véleményt cserélünk, ötletelünk, hátha találunk megoldást. Igaz, ez most leginkább nekem fontos, de mindenkinek hálásan köszönökminden beírásást, hiszen a legdrágabbját adja nekem: az idejét!
Ha lehetőségem lenne a HGW WAN portját shifferelni, akkor magam próbálnám megoldani a problémám, bár még akkor se tudnám megoldani, mert saját eszközzel nem tudom helyettesíteni a HGW-t, pedig ez volt az első ötletem, amihez kaptam eszközöket is. És nem azért próbálom, hogy kijátszam a szolgáltató rendszerét, hanem hogy használhassam 0-24-ben amiért fizetek.
Mi a véleményed a PPPoE-ről? Miért nem sima DHCP-vel kapom a beállításaimat? Minek kell a plusz terhelés a PPP-vel?
Üdv:
Ruzsi
9' hiján 2 napot bírt.
Üdv:
Ruzsi
Sehol, szolgáltatói NAT esetén (bármilyen IP tartományt használjon is) kintről nem lehet bejutni. Kintről nem látszol, a szolgáltató pedig nem port forwardol senkinek semmit. A CGNAT nem a CG- hanem a -NAT miatt nem jó az ügyfélnek (amennyiben be akar járni).
Publikus dinamikus IPv4-nél simán bejutsz kényelmesen. Kell egy dinamikus DNS hozzá (amire akár egy csomó más FQDN-t ráültethetsz CNAME rekordokkal), és már bent is vagy. Leginkább VPN-nel, és akkor nem kell csak a VPN-es porto(ka)t nyitni, semmi mást. Az IPv6 a mai napig csak kínlódás mindenkinek, pláne magán internet ügyfélnek. Mint írtam, az sem fix, változhat, ergo ugyan úgy kell dyndns mellé. Cserébe dupla overhead az IPv6 cím és a legtöbb MTU javaslat (amit a neten találsz) megbukik miatta pl.
Ráadásul ha ott épp nincs IPv6, ahonnan be akarsz jutni a rendszeredbe, akkor mi lesz? IPv4 nagyjából mindenhol van, ahol internet van...
Erre egyszerű a válasz, ha az ember ISP oldalon (is) dolgozik, meg akkor is könnyen kitalálható, ha nem:
DHCP layer2-ben működő IP forgalmat igényel. Nagyon bonyolult úgy felépíteni egy ISP méretű layer2 hálózatot, hogy IP alapon ne legyen túl sok a broadcast és egyéb parazita forgalom. Valamint a kliensek elszeparálása sem annyira triviális. Ráadásul ha nem dinamikus cím kell ügyfél oldalra (általában nem, mert sok a baj vele törvényi megfelelés oldalon, vagy épp publikus fix IP-t szeretne az ögyfél), akkor MAC címhez kötődik a DHCP bérlet, így szolgáltatói segítség kell pl. saját eszköz csere esetén (vagy MAC klónozás, ami az ügyfél oldalon igényel több hozzáértést). Ráadásul az ilyen rendszereket le tudja fektetni egy ügyfél oldalon elkövetett loop, amit megint nem olyan könnyű kivédeni.
PPPoE kapcsolatnál ugyan úgy layer2 kapcsolat kell a kliens és az AC között, ellenben csak kétféle (PPPoE-session és PPPoE-data) csomag mozog, semmi más (minden más csomagtípus eldobható az ügyfélhez legközelebb), így nem lesz "túl sok" ügyfél egy layer2-ben, mert nincs felesleges forgalom, zaj. Ezen felül a PPP megoldja az ügyfelek elszeparálását, egymással semmi módon nem tudnak kommunikálni, csak az AC-val és azon keresztül bármivel, amit ott engednek. Ráadásul ezen előnyei miatt ez terjedt el, így a naplózása, auditálása, követése sokkal kiforrottabb. PPPoE kapcsolatnál az ügyfél IP címe a név/jelszó alapján adatbázisból vehető, így teljesen mindegy, hogy honnan és milyen eszközzel kapcsolódik, a címe azonos lesz/lehet. Loop probléma nem igazán jelentkezik, mert nincsenek broadcast üzenetek a csatornában, a nem-PPPoE forgalom meg el van dobva az ügyfél edge oldalon.
Ritkán jársz Ázsiába, igaz? :)
Egészen pontosan nulla alkalommal. Terveim szerint így is marad, de nem az IPv4 - ezek szerinti - hiánya miatt. :-D
Nálunk sok éve elhatározták, hogy irány a v6 dual stack, aztán mindig volt valami sürgősebb feladat, szóval mondjuk úgy, hogy nagyon lassan halad. Pedig van szép nagy allokált címtartományunk, fel is lett nagy vonalakban osztva, hogy melyik részt merre, de nem igazán akar terjedni. Jelenleg is csak egyetlen dual-stack címünk van, az perdig a remote access, mert egy-két vezető néha keleti országokba is utazik, és onnan is szeretné elérni távolról a hálózatot, viszont elég sok helyen egyszerűen nincs IPv4.
Én azt látom így a hosszú évek alatt, hogy a dual stack full szopás.
Ha azt mondaná pl. valamelyik szolgáltató, hogy holnaptól nincsen nála, csak v6 (persze biztosítana 6-to4 gatewayt emelett), akkor már sokkal előrébb lennénk.
Másképp kell a tűzfalszabályokat csinálni: a v4-et NAT-olni kell, a v6-ot nem, két dhcp és/vagy routing advertisement. És akkor mindemellé még jön az, hogy ha valami nem megy vagy lassú, akkor mi a gond, v4 vagy v6, melyik nem megy, melyik szabály fogja meg, vagy épp a túlvégen van pl. szarul beállítva az egyik.
"Sose a gép a hülye."
Lehet szopás, lehet nem akkora szopás. Az, hogy csak v6-on szolgáltatsz, jelen állapotban nem lehetséges. Említed a 6to4-et, azzal ugyanúgy nem vagy kinn a vízből, tehát onnantól mindegy, hogy v6only+6to4 vagy dual-stack.
Felhasználóként vígan elvoltam a HE tunnellel (más kérdés, hogy nyilván korlátosabb a sávszélesség, nem lesz 1Gb-s letöltésem, de ez sokszor nem is kell), azért dobtam el, mert automatikusan külföld lettem, és ez néhány szolgáltatás igénybevételében okozott problémát. Ha az ISP ad egy v6-ot és egy CGNAT-ot, az ugyanúgy dualstack.
A NAT úgyis külön tábla a legtöbb esetben, (netfilter alatt a v4/v6 is), tehát az, hogy a v4-et NAT-olni kell (azt se minden esetben), a v6-ot meg nem, az nem külön probléma. A dhcp igen, érdekes lehet. A többi probléma amúgy is probléma külön v4 és v6 esetén is.
Viszont minél később indul el ténylegesen a v6, az általad említett problémák annál tovább maradnak meg.
Köszönöm a megerősítést!
GCE-be WireGuard-dal másik szolgáltató VM-jéről áthozott HE IPv6-ja vidáman működik.
Igen, sajnos így elveszítem a "helyi" jellegem, ami jó is és nem is, de eddig sem ez volt a bajom.
Jó lenne, ha nem csak ímmel-ámmal terjedne itthon az IPv6, hanem pl. valaki szolgáltatna helyi TB-ként, ha már az ihoni szolgáltatók csak nagy-nagy megkötéssel teszik, vagy nem is szolgáltatnak IPv6-on.
Áttérek Tkom dominó kártyára, CG-NAT-tal és VPN-nel, de legalább a saját kezemben lesznek az eszközök.
Jó lenne MikroTik LTE-s dobozkát használni mindenütt, de az a 40-50eFt/hely, erősen meghatározza a tudatom, így inkább más megoldást próbálok használni.
Most 4G-s eszközöket keresek, elfogadható áron.
Üdv:
Ruzsi
De "probléma", mert két külön protokollra kell a tűzfalat rendben tartani, ami nem mindig triviális és egyszerű.
Illetve az is probléma, hogy a v6 nem fix. Valahol már tárgyaltuk nem olyan rég: az előfizetői szerződésben, legalább úgy mint mondjuk a pppoe user+pass ott kéne lennie hogy mi a tartományod, mert az, hogy se egy otthoni NVR-nek, se egy nyomtatónak sem tudsz egy fix címet adni a tartományváltás miatt, az mindenkinek gáz. A v6 a jelenlegi felállásban azoknak az r=0.1 usereknek használható, akiknek van egy SSID, rákonnektálnak a telefonnal, van net semmi és egyéb nem kell. Mindenki másnak kb. semmire nem jó és/vagy csak teher.
"Sose a gép a hülye."
Ha nem egyszerű, és nem akarod, akkor ne csináld.
A nem fix v6 természetesen szívás és marhaság, remélem, erről leszoknak. Sajnos elég friss (bármennyire röhejes is 2024-ben) a v6 szolgáltatás, remélem, egy idő után erről leszoknak, és egy előfizetőnek az előfizetés tartama alatt megmarad a fix /54-es (legalább) tartománya. Ha nem, akkor bizony a v6 - előfizetőként - tényleg szopás. Én a korábbi v6-tal kapcsolatos hozzászólásomat nem elsősorban mint lakossági előfizető, hanem mint interneten megjelenő cég írtam, ott természetesen a fix v6 cím adott.
Persze, kinti szervernél nálam is van ~15 éve minden szervernek v6 címe is, de az megint más. Fix public v4, fix v6, nem kell NAT, nincs DHCP, és a tűzfal nagyjából egy port nyitásban kimerül, amit ha nyitsz akkor mindkettőn nyitod. Az egyetlen szívás, hogyha csak 1-1 ip-re kell engedélyezni, és mondjuk a tűzfal/frontend/akármi ezt nem tudja lekezelni (pl. az ip6tables/nf6tables felsír, amikor megpróbálja betolni az v4 src addresst), de kb. ez minden és betonstabilan megy.
"Sose a gép a hülye."
nft nem sír a v6 címtől sem, szóval nyugodtan lehet használni. Egyébként amikor a korábbi hozzászólást írtam a dual-stackről, akkor én is cég oldalról, a szolgáltatásról (is) beszéltem, na az nem/sem indult el globálisan nálunk.
Az a /54 csak eliras es nem /56 akar lenni? Amennyben valoban /54, miert?
De elírás. Köszönöm a kijavítást.
.
(CG)-NAT:
Erről beszélek.
Publikus, dinamikus:
Ezt mondom én is, de érdekelne pl. 2 WEB szervernek hogyan csinálsz automatikus tanúsítványt a Let's-től?
Van egyetlen IP címed és kezdhetsz SNI-vel variálni. Csináltam. Nem lehetetlen. Csak amikor a MikroTik-nek egyetlen paranccsorába került mindez saját magának (persze, volt publikus címe!), az azért más feeling!
És még mindig nem győztél meg a millió port-forwarding átláthatóságáról! Csináltam, kínlódtam.
Jött az IPv6 és huss, elillantak ezek a problémák. Persze lett más, mint pl. a dinamikus PD kezelés (érdekes, hogy a tunnel brokerek tudnak fix tartományt adni?). Kattog az IPv6-om és igen tudom, hogy nincs mindenütt, de eddig meg tudtam oldani, hogy a saját IPv6-os (ráadásul TB-s!) VM-ről el tudtam érni a belső gépeim.
Nem egyszerű, de is rossz az IPv6! Nem értem, miért állt le ennyire a használta, fejlődése.
A PPP/PPPoE magyarázatot köszönöm, meg tudom érteni így már miért ez van.
Üdv:
Ruzsi
Bárhány FQDN A rekordja mutathat ugyan arra az IP címre, dinamikus IP esetén meg bárhány CNAME rekord mutathat ugyan arra a dinamikus DNS A rekordra. És mindre lehet szóló (nem ömlesztett, SNI, egy certbe minden) certet kérni. Csupán kell a szolgáltatások elé mondjuk egy reverse proxy, aki minden kérésre a megfelelő certet használja és intézi a frissítésüket.
Én pl. úgy oldom meg, hogy vagy OPNsense fut, és azon ACME+HAproxy, vagy Docker-ben Nginx Proxy Manager. Mindkettő megoldja a reverse proxy-t, és ha van olyan szolgáltatás belül, aminek saját magának is kell a cert (mert pl. nem csak 443-on szolgáltatok vele), akkor mindkét megoldás cert frissítésébe befűzhető könnyen, hogy másik host-ra másolja a friss certet, és mondjuk indítson újra kapcsolódó szolgáltatást. Mindet simán működik egyetlen dinamikus publikus IPv4 mögött is, és minden FQDN-hez tartozó cert-ben csak az az egy (vagy max a vele releváns) FQDN-en szerepelnek.
Értem, hogy IPv6-nál mindenkinek van saját címe, de ez pl. dinamikusan osztott IPv6 tartomány esetén annyi dinamikus DNS macerálást is jelent egyben. Nem feltétlen egyszerűbb megcsinálni, és megcsinálás után mind a kettő működik magától, nem kell vele foglalkozni (jó esetben). Meg akkor a cert kezelés lesz minden gépen saját? Azt mind fel kell ügyfelni, karban kell tartani. Akkor még mindig ott marad, hogy ami nem jó IPv6-on (szomtalan berendetés a mai napig), annak kell IPv4 cím úgy is. Meg ami nem tud saját maga certet kezelni, annak úgy is meg kell oldani máshogy a cert dolgot. Szóval, az IPv6 vs. cert esetben legalább annyi plusz meló lesz, mint amennyi kényelmet nyersz a sok publikus címmel.
De persze nem akarlak az IPv6-ról lebeszélni, de ahogy írod is, messze nem olyan az elterjedtsége, és messze nem olyan az elterjedés üteme, hogy az csábító lenne bárkinek. Pl. nekem nem hívószó vele kapcsolatban semmi.
Az ISP-k azért nem adnak fix IPv6-ot lakosságiba, mert csak megnehezíti az életüket. Adminisztrálni kell, menedzselni kell. Ha lemondod újabb adminisztráció, stb. Pont mind IPv4 fix címnél, amit ugyan ezért nem adnak lakosságiba. Az üzleti előfizetések pont azért drágábbak, mert elérhetőek bennük olyan szolgáltatások, amivel macerája van a szolgáltatónak, és azt kell megfizetni pluszba. Nem az internet másabb üzletibe, hanem a körítés.
Ez a topológia így halva született ötlet. A Telekom eszköze semmi mást ne csináljon, mint "modem"-ként funkcionáljon. A Mikrotik eszközöd csatlakozzon a LAN1-es portba, és csak ennyi. A Mikrotik csatlakozzon be PPPoE-vel, minden más eszközöd a Mikrotik mögé kell kerüljön. A WiFi-t is tiltsd le a Telekom eszközében. Arra semmi más ne legyen csatlakoztatva. Kivétel: ha van IPTV. Akkor annak a set-top-box eszközei maradhatnak a Telekom eszközén vezetékkel. Sok ügyfelünk van Telekom eszközökkel, így működik, hogy egy technikai felhasználóval becsatlakozik az ő eszközük és ezzel megy az IPTV, a netet viszont úgy érjük el hogy a saját eszközünk csatlakozik be PPPoE-vel. Minden más elképzelésed hibás, olyat nem fogsz csinálni hogy egy hálózatban legyenek. Ha így "megerőszakolod", egyrészt valószínű loop lesz, másrészt pontosan ilyen stabilitási gondok lesznek. Onnantól hogy kiépítesz egy PPPoE kapcsolatot, onnantól az az eszköz nem lehet annak a kapcsolatnak a kliens oldali végére is betéve mint switch, ő egy teljesen másik hálózat eleme.
Gyanitom, h az IPTV miatt csinalja :)
En is xoptam ezzel, vegul elengedtem a Telekom IPTV-t es Sweet et hasznalok (minosegben gyengebb, de legalabb nem kell szorakozni vele)
Ha tenyleg ezert csinalod, akkor celravezetobb ha az ONT-ot vissza allitod normal mukodesre (nem kell meg PPPoE Passthrough sem) folveszel egy IP-t az ONT-on DMZ-be es azt allitod be a Mikrotiken WAN portra, fix IP-vel. Az IPTV-t igy mar at tod IGMP-Proxy-val huzni a mikrotik moge (tehat dughatod oda a belterit es akkor egy halozatban lesz a tobbi cuccodal es az IPTV is megy a Multicast forward miatt)
Persze lehet tok mas miatt akarod, csak tipp :)
Szerencsére nincs IPTV-m!
A "vezetékes" telefont azért sikerült rámerőltetni.
Üdv:
Ruzsi
teli a net hogy a pppoe kifingik az elegtelen cpu miatt. csinalja a ppp-zest a telekom eszkoze, ha nem tudja az elofizetett speedet az eszkoz akkor lehet csapkodni a telekom asztalt.
dupla nattal sincs semmi gond, evekig meg egy kkv (10-20 ember) ugy, semmi baj nem volt. a befele "portforward" is szepen ment a modemen (mikrotik) fixips dmz-vel. jah, es dualwan-nal.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Teljesen igazad van!
Hol van ez leírva a szolgáltatási szerződésben?
Hol a műszaki melléklet?
Miért nincs műszaki hotline? Aki ért is a hálózatokhoz. Pedig van hozzáértő, mert kitartó kereséssel találtam.
"Maga a második, aki a 10 éves gyakorlatom alatt ilyen kérdéseket tett fel." - most erre lehetek büszke is, meg igen szomorú is ...
De vele lehetett beszélni, értette amit mondott, amit mondtam.
Utána lettem kivéve a CG-NAT-ból.
Üdv:
Ruzsi
route-olás*
Először is kéne tudni, hogy mi a koncept. Én azt olvasom ki a számomra kissé zavaros leírásból, hogy a HGW és a Mikrotik ugyanazokat a funkciókat látja el, ezért akad össze.
Ha játszani szeretnél, akkor a Mikrotik Internet portját konfiguráld fix IP-vel. A LAN oldalon használj másik alhálózatot, pl. 192.168.2.0/24.
A Mikrotik-en a következő funkciókat kell konfigurálni:
- Routing a két alhálózat között
- Tűzfal szabályok+NAT az Internet láb felé
- DHCP szerver a LAN lábra, a 192.168.2.0/24-es hálózatra.
A Mikrotik mögötti eszközök a Mikrotiket fogják kapni, mint alapértelmezett átjáró, tehát ha egy eszközt át akarsz tenni a játszótérre csak csatlakozatod a mikrotik routerhez.
Ha ez megy akkor lehet menni bonyolultabb konfiguráció irányába. Dupla WAN, IPv6 stb.
Ha egyszerre akarsz mindent akkor beletörhet a bicskád. Legyen egy cél, amit el akarsz érni, és tervezd meg milyen lépésekben fogod azt elérni. A fenti konfiguráció lehet egy jó alap és ha csinálsz mentéseket az egyes fázisokról, akkor könnyű lesz visszaálni az utolsó, még működő konfigurációra.
Nem vitatkoznék azzal, amit leírtál.
Teljesen jó, de az alapfelállásra csak 1-2 magyarázatot kaptam eddig: miért akad le pontosan a HGW?
Most pl. kb. 2 napja megy. Tegnap egész este Neteztem rajta + a többi eszköz, ami ott figyel a MikroTik mögött.
Én is úgy szeretném, hogy van egy alapom.
A NAT miatt már elegem van a bújócskából, álarcosbálból, varázslásból!
Macerás egy Let's Enscript tanúsítványt kapni az eszközökre belülre, pedig el szeretném érni őket, sőt leginkább azokat!
A NAT kitűnő, amikor kifelé nézek csak. De befelé is kell, kellene!
Ezért kezdtem el kacsingatni az IPv6 felé, amivel vannak eredményeim, de mivel a szolgáltatói koncepció az, hogy mindenki kifelé akar csak látni, így szűrik helyettem a forgalmat. Jó, ezt lehet kérni, hogy ne legyen, de ha a szerencsétlen HGW ezt nem akarja tudni sw szinten, mert nem tesztelték, nem érdekelte aki tesztelte, így nem vagyok előbbre!
Próbáltam magam terminálni az optikát több cuccal, de nem sikerült.
Tudom, hogy oda ne akarjak bejutni, mert az a szolgáltató felelőssége, de akkor kérnék szépen pl. egy általuk üzemeltetett Cickó, MikroTik, akármi eszközt, ami megbízhatóan működik!
Szóval egy "buta" UTP csatlakozós Ethernet portot kérnék sima DHCP-vel, oszt' jónapot! A PPP időszaka már réges-régen lejárt!
Sokat modemeztem vele, de a világ túlhaladt rajta.
Nem tudom, a többi szolgáltató hogyan csinálja, de pl. a Digi-nél a Huawei sokkal butább, ritkán akad le (talán évente) és kicsit
többször IPv6-tal veszti el a fonalat, de működik! A mögötte lévő szervert 99%-ban el tudom érni.
Egyáltalán: miért lehet leakasztani egy dobozt normál forgalommal?
Tiltson le, üzenjen, szóljon, reklamáljon, de NE akadjon le! (Azt nem tudom, hogy ebben a leakadt állapotban a WAN oldalról el tudják-e érni? Ha nem, akkor jöjjenek ki ők ki-bekapcsolgatni.)
Üdv:
Ruzsi
én sem értem mit csinálsz, mert nekem pontosan ugyanez a setup van, Telekom wifi6-ot tudó valami openwrt locked down borzalom doboz, 2 pppoe-vel; a tévé/telefon egyik porton, internet a másikon; eddig mögötte Mikrotik hap ac^2 volt NAT-tal, dinamikus dns-sel (duckdns), fainul ment ipv4/6-on saját domainnel; raspberry pi-on letsencrypt + nginx + certbot dockerben, home assistantban egy gomb ami nyitja a mikrotiken a 80-as portot a tűzfalon, 2 perc alatt generál/frissít certet, nem értem a problémát; plusz vpn összes típusa működött a mikrotiken.
csak mivel a Mikrotik wifije legendásan F.O.S. még az új wireless package-dzsel is, így kidobtam az egész szarságot, Ubiquity-re cseréltem a routert, ap-ket, switcheket & lo and behold, 450/400 helyett 890/890mbit az átviteli sebesség WIFI-n IS, nemcsak kábelen az egész házban!
~ubuntu, raspbian, os x~
Én is ezt szeretném! Hogy menjen és ne kelljen ki-bekapcsolgatni.
Programozgatás nélkül elvagyok a 3 hónapos cert-tel, annyira nem fontos és nem sok munka megcsinálni, csak amikor 5-6 SSH portnak szükséges nem default portot kell nyitogatni a routeren,
előbb-utóbb elvesztem a fonalat.
Ráadásul a cég csak http+https-t enged ki, így megint egy macerával több hogy valamit be/kikapcsolj otthon.
De majd megoldom valahogy!
Üdv:
Ruzsi
off: miért nyomsz entert folyton a mondat közepén?
Bocsánat!
Nekem így tördelte, de majd próbálom nem csinálni.
Üdv:
Ruzsi
Felejtsd el ezt a borzalmat.
1. Hagyd meg a telekomos ezközt a pppoe tartásra, hw offload-dal, az a mikrotiknek nem túl izmos.
2. Egy DMZ IP-re tedd a mikrotiket, arra mehet minden port forward.
3/a. A mikrotik belső lábait szétszeded, és arra aggatod a különböző subnet eszközeit
3/b. VLAN-ozol belső oldalon.
"Sose a gép a hülye."
Mit jelent a "pppoe tartása"?
A HGW WAN oldalát nem én állítom, így nem kapcsolgathatok router/bridzs között. Max. kérhetem.
DMZ-be pl. nem jött a protocol 41 ... (IPv6 encap)
A 3-as pont tiszta.
Üdv:
Ruzsi
Úgy, hogy ha komolyabb tűzfal, wan failover, packet marking vagy hasonló kell, akkor ahhoz hogy jól menjen, ki kell kapcsolni a fasttrack-ot, és a mikrotik elkezdi erőből csinálni a pppoe-t, ami 100% cpu melett olyan 300Mbiten koppan.
Hát az IPv6-ot elfelejtheted, igen.
"Sose a gép a hülye."
Akkor egy helyzetjelentés:
Most akadt le megint!
2,5 órája kapott a PPPoE egy pofont tőlem, mert nem ment az IPv6, de ebből szépen felállt minden és eddig bírta!
Nincs semmi se a HGW-re csatlakoztatva CSAK a MikroTik WAN oldala és PON...
A jelenség a Net leállásával kezdődött, de akkor még az összes LED zöld volt és világított.
Aztán az Internet elaludt. Majd további idő után hozzá jött a telefon piros LED-je.
Az én oldalamon nincs hurok, nincs dupla PPPoE, mégis leakadt!
Azt hiszem, most hajítanám ki a francba az egészet, ha lenne alternatívám!
Üdv:
Ruzsi
Úgy gondolom, egy gonddal per-pillanat kevesebb lett!
Lemondtam az Internetet a Tkom-nál.
Megy a HGW vissza a feladónak!
Köszönöm a segítséget!
Üdv:
Ruzsi
Nem kovettem teljes reszletesseggel ezt a topikodat, mert elegge rabbit hole-nak tunt viszont a telekom/mikroik/te haromszogbol szerintem nem a telekom a "gond":)
Én is így gondolom.
A HGW. De már megy vissza a telephelyére.
Üdv:
Ruzsi