Mikrotik en XS4ALL pppoe ipv4 werkt spontaan niet meer

[jeroen3]

Al een geruime tijd heb ik een Mikrotik hAP AC als router op mijn FTTH van XS4ALL.

Dit heeft ruim een jaar goed gewerkt. Sinds kort heb ik TV opgezegd.
En dus heb ik vlan4 uitgezet. Logisch. Direct ook routeros naar 6.46.4 gebracht.
Dit was februari.

Nu zit ik vandaag een ander apparaatje te configureren en kan ik niet naar 1.1.1.1 pingen. Huh gek?
Internet etc werkt verder wel, maar ik krijg alleen dns responses met ipv6 adressen terug als ik wat domeinen ping.

Ipv4 is dus al best wel een tijdje stuk nu ik in de logs kijk. De pppoe voor ipv4 is offline.


Ik heb even de ethernetpoort uit gehad, en nu zijn beide pppoe links weer connected.
Ooit heb ik dit gevolgd. https://netwerkje.com/config-internetv6

Hoe kan dat ineens? Is er iets gewijzigd bij xs4all?
Zit er in 6.46.4 ineens wat anders? Ik kwam van 6.45.6.

Het goede nieuws is dat ipv6 dus al best wel goed ingeburgerd is en heel veel internet dan nog gewoon werkt!

ik zet hier niet zomaar mijn config neer, kan deze wel via dm verstrekken indien nodig

[Thralas]

Wat is nu je vraag? Het werkt weer inmiddels?

Is je vraag waarom de PPPoE-link tijdelijk niet werkte? Dat probleem treedt bij KPN ook op, en is perfect reproduceerbaar: gewoon je MikroTik die de PPPoE-sessie opzet herstarten.

Ik vermoed dat het iets te maken heeft met het feit dat de andere zijde dusdanig is geconfigureerd dat je maar één sessie kunt hebben en er blijkbaar nog van overtuigd is dat deze nog steeds bestaat na een reboot aan jouw kant.

Oplossing is simpel: even de poort disable/enable togglen (mag ook softwarematig) op de switch die aan je NTU/FTU hangt, blijkbaar is dat voldoende om de sessie aan de andere kant te sluiten.

Geen idee wie er fout zit.

EDIT: welja, probeer ik het te reproduceren krijg ik het (1) slechts voor elkaar na een update (2) werkt het link en/disablen niet (3) loopt de packet capture in de soep. Misschien is het allemaal toch iets subtieler.

[ Voor 15% gewijzigd door Thralas op 09-03-2020 23:17 ]

[jeroen3]

Ja het werkt nog steeds. Wel gek dat dit zomaar optreed en niet hersteld.

Het is mij ook nog nooit gebeurt voor de update naar 6.45.6, en heb sindsdien wel af en toe wat issues zoals geen internet meer (geen werkende route), terwijl de VPN verbinding allemaal nog online waren. Die heb ik gewoon met een herstart het opgelost want ik had geen tijd om er diep in te gaan.
Wellicht is er toch iets fout in routeros...

[MDVej]

Ik heb hetzelfde probleem. Hadden jullie hier al een oplossing voor gevonden? Zojuist maar even terug gegaan naar de laatste "long term", wellicht lost dat iets op...

[jeroen3]

Ik heb een script gemaakt zie eth1 en de ppp’s offline trekt en in de juiste volgorde weer inschakelt.

Ik denk wel dat het een bug in de mikrotik is.

[ Voor 19% gewijzigd door jeroen3 op 03-07-2020 12:16 ]

[MDVej]

zojuist op een andere xs4all verbinding (en dus andere locatie) gedaan; ppp uit, interface uit, interface aan, ppp aan, maar werkt nog niet. Mogelijk werkt het pas na een reboot? Of moet ik lang wachten met interface uit/aan? Zou je jouw script kunnen delen?

[Thralas]

Ik heb net geüpgradet naar v6.47 met een port mirror om te zien wat er nu foutgaat. Zoals die dingen dan gaan: dat werkt probleemloos.

In de capture zie ik hem ook netjes de PPP-verbinding sluiten (eerst PPP LCP terminate, dan PADT). Ik blijf van mening dat de meest waarschijnlijke oorzaak is dat dat niet altijd netjes gebeurt. Misschien een raceconditie bij het rebooten?

Lijkt me dat als je PPP disablet voordat je reboot (zodat hij netjes terminate) het sowieso goed zou moeten gaan. Aangenomen dat je upgradet vanaf LAN lijkt me dat werkbaar.

MDVej schreef op vrijdag 3 juli 2020 @ 19:55:
zojuist op een andere xs4all verbinding (en dus andere locatie) gedaan; ppp uit, interface uit, interface aan, ppp aan, maar werkt nog niet. Mogelijk werkt het pas na een reboot? Of moet ik lang wachten met interface uit/aan? Zou je jouw script kunnen delen?

Mja, daar liep ik dus met mijn eerdere poging ook tegenaan. Ik denk dat het dis/enablen van de interface toch niet betrouwbaar werkt, en dan is het enige dat rest wachten op de timeout aan de kant van KPN. Dat duurt soms een paar minuten.

[jeroen3]

Je moet 30 seconden wachten na uitzetten eth1.