En waarom niet?
Zou denken dat het precies de reden kan zijn dat daarin nu juist het probleem zit?

Het is het enige onderdeel als verschil in die twee netwerkstructuren wat hetzelfde is gebleven.
Eerder gebruikt als VDSL connectie, en nu achter glasvezel hetzelfde probleem met hetzelfde apparaat.

Test eens een andere router achter glasvezel (KPN).  Wat levert dat op?

Jij neemt aan dat ik de Fritzbox als router/firewall gebruik, maar dat is niet zo.

Bij de VDSL gebruikte ik hem alleen als VDSL “modem” (PPPoE passthrough), nu met glasvezel heb ik ‘m niet meer nodig en staat hij uit.

De router/firewall is een Linux machine die ik zelf ingericht heb. Ik heb daar nu zo’n dertig jaar ervaring in, dus dat zit op zich wel goed.

Helaas zien we bij G.PON (XGS.PON) aansluitingen wel vaker dat de verbinding even wegvalt.

KPN zal je waarschijnlijk gaan vragen om ter test de Experia/KPN Box aan te sluiten om te kijken of de verbrekingen van de pppoe verbinding dan ook optreedt.

Zo kwam het bij mij wel over met wat je eerder beschreef:
 

Zit die dan nu rechtstreeks achter de glasconverter (zonder gebruik van een Fritzbox)
en heb je daar dan nu ook die PPPoE problemen mee?

Dat wil ik best doen, maar verklaart niet waarom ik dat met VDSL óók al had!

Ja. “Firewall verplaatst van Fritzbox naar glasconverter”.

Dit heet testing by deduction. In dit geval dus door het uitsluiten van de oorzaak binnen het KPN domein. Als de Experia/KPN Box geen verbrekingen geeft weet je vrij zeker dat je de oorzaak in jouw eigen linux router moet zoeken. Geeft die ook verbrekingen dan is de kans groot dat KPN aan de bak moet.

Dan heb je het in feite over de pppd (p-p-p-daemon), die over de hele wereld in miljoenen routers gebruikt wordt (in ieder geval in de Fritzbox, waarschijnlijk ook wel die KPN Box, is van Sagem zag ik, weet niet of daar ook Linux op draait, maar die kans is wel groot).

Het heeft niks te maken met de feitelijke packet filtering (wat een firewall doet) of routering, ik zie gewoon dat er op een gegeven moment absoluut geen PPPoE pakketten meer binnenkomen vanaf DSL of glasvezel, zelfde situatie. Die situatie gaat pas over als ik een nieuwe PPPoE sessie initieer. Zou een bug in de pppd kunnen zijn, maar die kans is niet zo heel groot. En dus is de kans veel groter dat het “iets” bij KPN is. Fritzbox/KPN box/Linux firewall staat er helemaal los van.

Ik denk dat de bekende “boxen” (Fritzbox en KPN Box) dit weten te maskeren door heel snel een nieuwe sessie op te zetten. Dat zou ik ook kunnen doen, de vraag is alleen hoe zij dan detecteren dat de sessie weg is. Je kunt toch moeilijk continu een ping laten lopen, vind ik niet zo netjes.

Je kunt toch, neem ik aan, eenvoudig een keep-alive definiëren voor jouw pppoe sessie.

Overigens is de.laatste keer dat bij mij de pppoe sessie verbroken werd ruim 9 maanden terug en dat was tijdens regulier onderhoud (nieuwe firmware) van mijn EdgeRouter 4.

Mijn advies zou zijn om toch maar eens te kijken of die onderbrekingen ook optreden als je een Experia/KPN Box gebruikt.

Ik schreef al “Ik heb eerder al LCP_ECHO aangezet in ppp met een timeout, maar dat helpt helemaal niet. Kennelijk blijven de echo pakketten gewoon verstuurd worden.”

Helaas kan dat dus kennelijk niet zoals het “hoort” bij PPPoE.

Hoe zie jij hoe lang je sessie up is? Ik denk namelijk dat er eens in de zoveel tijd gewoon een nieuwe sessie wordt opgezet zonder dat je het doorhebt. De vraag is dan hoe jouw router vaststelt dat de huidige sessie niet meer werkt (en daardoor best snel een nieuwe sessie kan opzetten).

Door in de log te kijken en dan te zien dat de laatste keer dat de pppoe sessie opgezet is meer dan 9 maanden terug is.

Ik krijg zin om bij jou een packet capture the draaien om te zien wat er nou eigenlijk gebeurt wat anders is dan bij mij 

Eigenlijk hoop ik hier iemand tegen te komen die dezelfde problemen heeft (of nog beter: had, en de oplossing weet...)

Ik ga nog wel weer eens stoeien met lcp_echo en dan een capture mee laten lopen.

KPN kan gelukkig ook precies inzien wanneer PPPoE sessies gestart en gestopt zijn door de RADIUS-server uit te lezen. Als je bijvoorbeeld de router van KPN een weekje aansluit kan er daarna direct gekeken worden of de problemen daarbij ook bestaan of dat het toch in de eigen apparatuur ligt. Let wel, dit uitlezen kan alleen van de huidige actieve verbinding. Het uitlezen van de VDSL-verbinding die niet meer bestaat zal bijvoorbeeld niet meer kunnen.

Ik gebruik zelf ook een eigen router op glasvezel (AON, geen PON) en ook hier geen enkele problemen met verbroken PPP-sessies behalve als ik zelf weer eens wat aanklooi. Ik kijk hier zelf niet in mijn router-logs maar direct in de systemen van KPN.

Mijn pppoe link is momenteel 77 dagen up en de reden dat het niet langer is komt doordat ik de router heb herstart. Sterker nog, de enige pppoe link downs heb ik geconstateerd bij geplande werkzaamheden (of eigen gerommel). De verbinding is gpon.

Ik verwacht dan ook geen structureel probleem aan de kant van de ppp server.

Ik heb maar eens een (permanente) packet capture aangezet, alleen LCP packets, anders krijgt hij het wel erg druk. Ik zie tot nu toe alle LCP_ECHO requests van mijn kant netjes beantwoord worden door de Huawei aan de andere kant. Afgelopen week achter elkaar sessie weg, nu draait het al weer een dag goed, dus wie weet wordt het een lange adem project, maar ik heb geduld .

Hopelijk binnenkort dan een keer een heterdaadje met packet capture. Misschien is de ethernet nic wel het probleem, wie weet...

Allemaal leuk en aardig, maar zoals eerder gesteld:
 

Huh, welke Huawei? KPN heeft geen Huawei in het vaste netwerk zitten naar mijn weten. PON-verbindingen draaien op Nokia OLT's in een switch van Alcatel-Lucent. De core switch daar achter is dan wel weer Huawei dacht ik (@LaurensZalm?) maar die ga je op geen enkele manier voorbij zien komen in enige traceroutes of ping requests.

Zoals ik al eerder aangaf ben ik het eens met het meermaals geopperde idee om het eens een weekje met een KPN-modemrouter te proberen om zaken uit te kunnen sluiten. Als er problemen zijn met wegvallende verbindingen die blijven bestaan, ook na een dragerwissel dan moet dit echt in het thuisnetwerk gezocht worden.

Zie bold, mac adres van de PPPoE peer hieronder. Dat is toch echt Huawei.

Frame 16846: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface vlan6, id 0
    Interface id: 0 (vlan6)
        Interface name: vlan6
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr  8, 2022 10:58:26.388130990 CEST
    STime shift for this packet: 0.000000000 seconds]
    Epoch Time: 1649408306.388130990 seconds
    eTime delta from previous captured frame: 0.000990821 seconds]
    sTime delta from previous displayed frame: 0.000990821 seconds]
    1Time since reference or first frame: 63191.428349610 seconds]
    Frame Number: 16846
    Frame Length: 60 bytes (480 bits)
    Capture Length: 60 bytes (480 bits)
    0Frame is marked: False]
    mFrame is ignored: False]
    aProtocols in frame: eth:ethertype:pppoes:ppp:lcp]
Ethernet II, Src: HuaweiTe_ee:dc:c5 (68:8f:84dc:c5), Dst: RealtekS_68:08:66 (00:e0:4c:68:08:66)
    Destination: RealtekS_68:08:66 (00:e0:4c:68:08:66)
        Address: RealtekS_68:08:66 (00:e0:4c:68:08:66)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: HuaweiTe_ee:dc:c5 (68:8f:84dc:c5)
        Address: HuaweiTe_ee:dc:c5 (68:8f:84dc:c5)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0xc96a
    Payload Length: 10
Point-to-Point Protocol
    Protocol: Link Control Protocol (0xc021)
PPP Link Control Protocol
    Code: Echo Reply (10)
    Identifier: 169 (0xa9)
    Length: 8
    Magic Number: 0xae795c4c
 

Dat zou ik met alle liefde doen maar:

• dat betekent dat ik hier in huis alles kan gaan aanpassen, en ja dat is een flink karwei, het moet in die tijd ook gewoon blijven werken natuurlijk, niet alleen kwestie van “even” testen.
• grote kans dat het dan wel blijft werken, maar dan weet ik nog niks, ik wil weten wat er fout gaat zodat ik het kan oplossen. Zou fijn zijn als iemand van KPN er even wat logs bij zou kunnen pakken, maar ik weet al heel lang dat de service aan de klant bij lange na niet zover strekt.
• ik beheer en richt netwerken in sinds een jaar of dertig, ik denk dat je even van me moet aannemen dat het probleem niet in het “thuisnetwerk” zit. Ik zie overduidelijk dat een PPPoE sessie unresponsive wordt, heeft dus niks te maken met wat daar “achter” zit. Het enige (eventuele) verschil tussen een KPN (of xs4all) router op dit niveau is de afhandeling van PPPoE zelf en daar probeer ik achter te komen.

Overigens, alsof de duvel ermee speelt, het blijft nu achter elkaar draaien. Ik moet zeggen dat ik laatst had dat de “link up” van de NTU uit was, ik heb toen het kastje (met SC-connector er aan vast...) even losgehaald, even de stroom er af en weer er op en eigenlijk gaat het sindsdien goed. Toch een mechanisch probleempje misschien? Het zit allemaal wel heel erg gammel aan elkaar.

Kern van mijn vraag is nu eigenlijk al beantwoord: nee, dit fenomeen is niet bij anderen bekend dus. Geen mensen die PPPoE hebben gedebugged en rare dingen hebben gezien of dingen waar je op moet letten. De packet capture blijft gewoon lopen hier en ik ben benieuwd, mocht het weer optreden dan zal ik toch iets moeten zien nu.

Ik heb echt geen idee hoe ik zoiets moet lezen maar vreemd vind ik het wel bijzonder dat er Huawei omhoog komt, jouw verbinding komt zoals ik al zei uit een Nokia OLT in een Nokia ISAM (hiervoor noemde ik foutief Alcatel Lucent maar dat is AON). Pas daar achter ergens hangt er wel een Huawei data-center switch die de verbinding met het verdere netwerk regelt. Mogelijk dat ie de RADIUS-server pakt hiermee, dat zou nog wel eens kunnen maar zo diep in de KPN backbone zit ik ook niet, mijn werkveld stopt bij de ISAMs in de wijkcentrale op AON en op de patchframes met PON.

Ik zie “de andere kant” van de PPPoE sessie. Die wordt getunneld naar de BRAS en kennelijk staat die al bij de provider zelf. Tot vorige week was dat voor mij een Juniper router, toen was ik nog “native” xs4all, nu ben ik gemigreerd naar KPN en nu zie ik een er van Huawei. Kan dus buiten de tunnel allerlei merken apparatuur tussen zitten zonder dat ik daar iets van zie.

Kans is klein maar niet onmogelijk dat Nokia OUI’s van Huawei heeft overgenomen en dat die informatie nog niet overal is bijgewerkt, maar dat heb ik eigenlijk nog nooit gezien. Of dat er in de Nokia machines uiteindelijk IC’s (bijvoorbeeld MAC) van Huawei zitten en dat men bij Nokia niet de moeite heeft genomen eigen OUI’s daar in te programmeren. Vergelijkbaar mijn eigen NIC die van TP-link is, maar een mac adres van Realtek heeft.

Overigens heb ik zeer waarschijnlijk GPON (helaas doet KPN daar nogal geheimzinnig over). Kan ook XG-PON zijn, omdat het echt net afgelopen maanden is aangelegd. Ik was erbij toen ze de NT aansloten en ze hebben de vezel meteen gemeten, loss van 0.2 dB, dat is heel netjes. Vandaar dat ik geen problemen met de vezel verwacht.

Aah, duidelijk. Dan zit het inderdaad ergens in het core-netwerk en dat zou best wel eens een Huawei kunnen zijn inderdaad.

Mwah, KPN is er volledig open over, moet ook in het kader van de vrije ONT-keuze. Via de tool kan je inzien welk type netwerk je hebt: https://servicetools.kpn.com/v2/#/voip-credentials.

XG-PON zal het sowieso niet zijn, die technologie wordt bij KPN niet gebruikt, het is GPON (Nokia ONT) of XGS-PON (Genexis ONT).

Bij iedere servicevraag aan KPN is dat wel een van de vereisten ben ik bang.

Ik verwacht ook niet dat de klantenservice ook zomaar even bij die logs kan, dan zit je echt bij het netwerkbeheer en dat ligt bij een hele andere tak. De enige manier waarop dit mogelijkerwijs bij hen terecht zou kunnen komen is als je de randapparatuur van KPN gebruikt, als de problemen dan blijven bestaan dan zal er verder gekeken worden. Je kan natuurlijk ook tijdelijk het KPN-modem aansluiten op de glasverbinding en in een dual-NAT setup werken. Niet ideaal maar als daar al wat zaken mee uitgesloten kunnen worden.

Met het thuisnetwerk doel ik hier ook op de router. Zoals ik het nu lees bestond dit probleem bij VDSL van XS4ALL, VDSL van KPN en een FttH-lijn van KPN. Dan is de enige constante het lokale netwerk. Ik heb nog nooit meegemaakt dat een PPP-sessie unresponsive wordt.

Dat is het nadeel van GPON-ONT's bij KPN. Het is een ‘lapmiddel’ geweest omdat toen GPON bij KPN geïntroduceerd werd er nog geen XGS-PON ONT's beschikbaar waren die paste op de FTU. Vandaar dat er ook na nog geen twee jaar alweer afscheid van genomen is en KPN het liefst iedere klant over zet naar XGS-PON.

 Nee, het issue is mij op deze manier niet bekend. Ik heb wel problemen gezien met PPP-verbrekingen om de 3 minuten maar toen waren de problemen veelal opgelost met het vervangen van een NTU, modem of SFP. Als alles tussen ISAM en klantlocatie is uitgesloten dan opent de mogelijkheid om het verder in het netwerk te zoeken, ook voor ons als monteurs. Dit issue zoals jij het beschrijft ben ik nog niet eerder tegengekomen maar ik ben er wel vrij zeker van dat het in de eigen router gezocht moet worden aangezien er al velen zijn die lange tijd zonder problemen met eigen routers werken aan de glasvezel.

Interessante link, moet je ook maar net weten. Maar ik vind ‘m wel wat vreemd.

De benamingen van de onderdelen zie ik nogal eens veranderen, ik houd aan volgens https://nl.wikipedia.org/wiki/Fiber_termination_unit

• FTU = waar de glasvezel (ruw) uitkomt, aan de onderkant zit een female SC connector,  vergelijkbaar met ISRA-punt
• NTU = media converter, SC in, RJ45 ethernet uit.

Ze hebben het nog over een ONT, maar het is me niet helemaal duidelijk wat ze daarmee bedoelen. De naam suggereert dat hetzelfde is als de FTU.

Bij mij (glasvezel) zeggen ze enerzijds dat je de media converter (NTU) niet mag verwijderen, maar je mag wel een “modem” aansluiten. Dat slaat toch nergens op? Die NTU ís het modem! Dus in feite mag je alleen je eigen router aansluiten, niet modem, dat slaat hier nergens op. Maar als je een eigen router wilt aansluiten heb je heel andere gegevens nodig. Zoals VLAN tags, PPPoE configuratie...

Maar die NTU kun je prima verwijderen zonder schade aan te brengen, dat zit met SC connectors aan elkaar, die zijn behoorlijk robuust. Volgens mij bedoelen ze dat je de FTU niet mag openmaken. Dat kan ik me voorstellen, maar dat zeggen ze niet.

Los daarvan zou je NTU toch niet kunnen vervangen, ook al zou je het willen, want dan mis je het downstream encryptie.

Beetje warrig dus allemaal.

Maar ik weet nu dus wel dat ik XGS-PON heb, goed om te weten, daar kon ik eerder niet achter komen. Thx!!!

Even lang verhaal kort:

• je wilt niet weten wat er allemaal in mijn firewall gebeurt, wat niet kan als hij achter een “box” van een provider zou hangen. Dat zal écht de allerlaatste mogelijkheid zijn mocht het echt een drama worden.
• het enige wat functioneel kan verschillen tussen een “box” en mijn firewall is, zoals gezegd, het proces wat de PPPoE doet en de netwerk-kaart. De rest (de hele firewall functionaliteit en routering zelf) zit als schakel achter die link er niet ertussen.

Maar vooralsnog ben ik nog even happy met gewoon de capture laten lopen totdat het een keer fout gaat. Hopelijk vind ik iets wat ik kan fixen, PPPoE configuratie of hardware probleem.

Die zou je best kunnen vervangen met een eigen media-converter. Of dat zin heeft is te betwijfelen.

Er zijn ook routers met een optische WAN aansluiting. Die je zonder gebruik van een NTU met een glasvezel patchkabeltje met de juiste connectoren rechtstreeks kunt verbinden met de FTU.