PPP problemen

[Ard van Breemen]

Ben ik de enige voor wie PPP er weer eens langdurig regelmatig uitligt?
Het hoeste even vanochtend, waarbij ik meestal weer verbinding kreeg met de ppp server, maar nu geen enkele reactie meer op discovery.
In augustus lag het er al een week uit.

De vdsl2 lijn zelf is goed, het lijkt echt de connectie te zijn tussen de ppp server en mijn lijn.

Voor de goede orde: dit is in purmerend weidevenne, vdsl2.

[Miquel van Smoorenburg]

Post by Ard van Breemen
Ben ik de enige voor wie PPP er weer eens langdurig regelmatig uitligt?
Het hoeste even vanochtend, waarbij ik meestal weer verbinding kreeg met
de ppp server, maar nu geen enkele reactie meer op discovery.
In augustus lag het er al een week uit.
De vdsl2 lijn zelf is goed, het lijkt echt de connectie te zijn tussen
de ppp server en mijn lijn.

Op het stuk van de BRAS (ppp server) naar de DSLAM lopen
natuurlijk een boel PPP sessies naast elkaar. Als die er ook
allemaal uitvallen, dan kan er iets fout zijn op dat traject.
Maar dat soort dingen komen weinig voor en vallen nogal op, dus
dat wordt snel opgelost.

Als je echter de enige bent met een probleem, dan kan het
alleen zijn tussen de DSLAM en je modem. Het hoeft niet de lijn
zelf te zijn; het kan ook een gaar modem zijn, of een hikkende
poort of kaart in de DSLAM.

Mike.

[Rob]

Post by Miquel van Smoorenburg

Post by Ard van Breemen
Ben ik de enige voor wie PPP er weer eens langdurig regelmatig uitligt?
Het hoeste even vanochtend, waarbij ik meestal weer verbinding kreeg met
de ppp server, maar nu geen enkele reactie meer op discovery.
In augustus lag het er al een week uit.
De vdsl2 lijn zelf is goed, het lijkt echt de connectie te zijn tussen
de ppp server en mijn lijn.

Op het stuk van de BRAS (ppp server) naar de DSLAM lopen
natuurlijk een boel PPP sessies naast elkaar. Als die er ook
allemaal uitvallen, dan kan er iets fout zijn op dat traject.
Maar dat soort dingen komen weinig voor en vallen nogal op, dus
dat wordt snel opgelost.
Als je echter de enige bent met een probleem, dan kan het
alleen zijn tussen de DSLAM en je modem. Het hoeft niet de lijn
zelf te zijn; het kan ook een gaar modem zijn, of een hikkende
poort of kaart in de DSLAM.

Toen ik laatst een hikkende lijn had merkte ik ook dat er kennelijk
een situatie kan ontstaan waarin PPPoE maar blijft stuiteren terwijl
het stabiel wordt als je de hele boel een paar minuten uitzet.

(ik gebruik een setup waar de PPPoE client niet kan zien dat DSL down is)

Ik geloof dat je dat wel eens hebt uitgelegd hier.

[Ard van Breemen]

Post by Miquel van Smoorenburg
Op het stuk van de BRAS (ppp server) naar de DSLAM lopen
natuurlijk een boel PPP sessies naast elkaar. Als die er ook
allemaal uitvallen, dan kan er iets fout zijn op dat traject.
Maar dat soort dingen komen weinig voor en vallen nogal op, dus
dat wordt snel opgelost.
Als je echter de enige bent met een probleem, dan kan het
alleen zijn tussen de DSLAM en je modem. Het hoeft niet de lijn
zelf te zijn; het kan ook een gaar modem zijn, of een hikkende
poort of kaart in de DSLAM.

En dat is de reden waarom ik hier klaag 8-D. De laatste grote storing die ik had bij xs4all kon ook alleen door jou gefixt worden ;-). (Als 1 van de laatste met een cistron profile.... dat begreep de helpdesk ook niet denk ik).

Zo ziet het er vandaag voor mij uit.
https://pastebin.com/faSe2GjZ

Ik zie ook PPPoE PADI's de deur uit gaan.
De vraag is, kan er naar de poort op mijn dslam gekeken worden?
Ik ben lange tijd geleden overgestapt naar tweak als mijn main vdsl2 provider, omdat de xs4all lijn wel altijd connectie had, maar de ppp gedeelte stil bleef. Na 10 minuten gaat het dan opeens weer wel.
Het rebooten van mijn modem heeft daarop totaal geen effect.

Eh, ja, ik heb dus tweak vdsl2 en xs4all vdsl2, allebei met een vigor 130 op dezelfde switch. De tweak draait dus heel stabiel, de xs4all niet zo...
Ik ga er van uit dat ze ook op dezelfde dslam zitten. Alhoewel dat niet zo hoeft te zijn :-).

https://pastebin.com/VMK9xNeB

In de tijd dat ik dit tik is het dus een paar keer gestuiterd.

@Rob : de issue is dat de vdsl2 modem gewoon aangeeft dat er vdsl2 wise niks down is... Alles werkt. Alleen komt er niks binnen.

De tweak en de xs4all modem staan in principe in dezelfde configuratie: bridgen van de vdsl2+ lijn.

Mischien is het zo dat de dslam op een gegeven moment in de war raakt, en dan een nieuwe setup nodig heeft om het hele pad op te zetten. Bij tweak gaat dat met dhcp. Of anders... Miquel weet daar vast het fijne van 8-D.
Anyway, ik heb de modem gereboot, nadat ik eerst de tweak modem had gereboot... (ziet er allemaal uit als 1 pot nat de webinterface :-) ).

[Rob]

Post by Ard van Breemen
@Rob : de issue is dat de vdsl2 modem gewoon aangeeft dat er vdsl2 wise niks down is... Alles werkt. Alleen komt er niks binnen.
De tweak en de xs4all modem staan in principe in dezelfde configuratie: bridgen van de vdsl2+ lijn.
Mischien is het zo dat de dslam op een gegeven moment in de war raakt, en dan een nieuwe setup nodig heeft om het hele pad op te zetten. Bij tweak gaat dat met dhcp. Of anders... Miquel weet daar vast het fijne van 8-D.
Anyway, ik heb de modem gereboot, nadat ik eerst de tweak modem had gereboot... (ziet er allemaal uit als 1 pot nat de webinterface :-) ).

Mijn probleem is dat de router niet weet dat de DSL retrained is (anders
dan door een timeout op de connectie) en dus gewoon doorgaat met de vorige
verbindin over de nieuwe DSL sessie. Dan komt er een timeout en gaat ie
een nieuwe sessie starten en kennelijk is er in het traject dan nog iets
wat die oude sessie geregistreerd heeft ofzo. Die nieuwe sessie komt dan
wel op maar die gaat na een minuutje ook weer down. Omdat er ergens iets
de boel reset ofzo. En dat liedje herhaalt zich dan tot ik het modem
even uit zet en na 2 minuten ofzo weer aan. Dan is het weer stabiel.

Als ik hier weer tegenaan loop ga ik eens een sessie capture van die
PPPoE layer doen om te weten wat er nou precies gebeurt.
(ik heb nu alleen logs uit de PPPoE client en daar blijkt niet veel uit)

Maar met de door XS4ALL geleverde modem/router combinaties is dit probleem
er niet omdat de DSL laag meteen aan de PPP laag meldt als de link eruit
vliegt.

[Miquel van Smoorenburg]

Post by Ard van Breemen
Zo ziet het er vandaag voor mij uit.
https://pastebin.com/faSe2GjZ
Ik zie ook PPPoE PADI's de deur uit gaan.
De vraag is, kan er naar de poort op mijn dslam gekeken worden?

Ik kan via een b2b interface naar wat waardes op de
DSLAM kijken. Daar staat:

Service Stability RISKY
Last status change 20180913132956

Lijkt toch echt op een klapperlijn op DSL nivo. Misschien
zie je het aan jouw kant niet, maar aan deze kant wel.

Mike.

[Ard van Breemen]

Post by Miquel van Smoorenburg
Ik kan via een b2b interface naar wat waardes op de
Service Stability RISKY
Last status change 20180913132956
Lijkt toch echt op een klapperlijn op DSL nivo. Misschien
zie je het aan jouw kant niet, maar aan deze kant wel.

Thanks!
Dat betekend dus hetzij de modem, hetzij de dslam poort.
Ik zal een spare vigor bestellen, en dan jou vragen om nog een keer te peeken 8-D.
Als het dan nog steeds slecht is, dan moeten we ergens anders kijken :-(.
De status change klopt trouwens wel met de modem reboot die ik er tegenaan heb gegooid.
Maar linksom of rechtsom, ik moet zowiezo een spare modem op de plank hebben liggen.

[Miquel van Smoorenburg]

On Thursday, September 13, 2018 at 2:53:07 PM UTC+2, Miquel van

Post by Miquel van Smoorenburg
Service Stability RISKY

Thanks!
Dat betekend dus hetzij de modem, hetzij de dslam poort.

.. of het koper ertussen. Misschien zit er ergens een slechte las.

Ik zal een spare vigor bestellen, en dan jou vragen om nog een keer te peeken 8-D.

Je had toch 2 dezelfden? Kan je ze niet gewoon omwissellen.

Mike.

[Ard van Breemen]

Hoi,

Post by Miquel van Smoorenburg

Post by Ard van Breemen

Post by Miquel van Smoorenburg
Service Stability RISKY

Thanks!
Dat betekend dus hetzij de modem, hetzij de dslam poort.

.. of het koper ertussen. Misschien zit er ergens een slechte las.

Meeh :-(

Post by Miquel van Smoorenburg

Post by Ard van Breemen
Ik zal een spare vigor bestellen, en dan jou vragen om nog een keer te peeken 8-D.

Je had toch 2 dezelfden? Kan je ze niet gewoon omwissellen.

Eh... ik ben een uebernerd... Er moet minstens 1 lijn op blijven! Daarom vind ik het ook geen probleem om een spare vigor te bestellen :-).

Als puntje bij paaltje komt, vind ik het zelfs geen probleem eenmalig een groot bedrag neer te leggen om consumenten glasvezel hier te krijgen. Maar bij mijn bezoekje aan reggefiber bleek dat mijn voorstel van verglazing te klein was voor hun... 100 woningen vs 40k woningen waar ze voor wilde komen.
En daarna was het door KPN overgenomen, en sindsdien ligt het zelfs officieel stil hier :-(.

[Ard van Breemen]

Post by Ard van Breemen
Hoi,

Post by Miquel van Smoorenburg

Post by Ard van Breemen
Ik zal een spare vigor bestellen, en dan jou vragen om nog een keer te peeken 8-D.

Je had toch 2 dezelfden? Kan je ze niet gewoon omwissellen.

Eh... ik ben een uebernerd... Er moet minstens 1 lijn op blijven! Daarom vind ik het ook geen probleem om een spare vigor te bestellen :-).

Ok, ik ben ook ueberlui. 11 november massaal storing gehad, en eigenlijk de hele afgelopen week.
Ik heb een dual pack vigor 130 besteld (2% korting!). Ik had de modem ook nog met modem5 DSP firmware laten lopen, dan traint ie op 64Mb/s, en is de RTT 14ms, maar de disconnects bleven.
Met de nieuwe modem sinds gister getest: eerst met de default modem5, weer max 64Mb/s, dus toen nog even modem8 geflasht.
Die ging redelijk snel naar 100Mb/s . En ik heb nu al 24 uur geen disconnect \0/.

Ik had eerder ook al de mtu1500 gefixt, want de vigor moet een beetje meesnoopen op het ppp verkeer om een mtu van 1508 te gaan doen aan de lan kant.

Anyway, progress. Ik hoop dat van de centrale kant de lijn er nu ook beter uit ziet.

Groetjes,
Ard

[Rob]

Post by Ard van Breemen
Ok, ik ben ook ueberlui. 11 november massaal storing gehad, en eigenlijk de hele afgelopen week.
Ik heb een dual pack vigor 130 besteld (2% korting!). Ik had de modem ook nog met modem5 DSP firmware laten lopen, dan traint ie op 64Mb/s, en is de RTT 14ms, maar de disconnects bleven.
Met de nieuwe modem sinds gister getest: eerst met de default modem5, weer max 64Mb/s, dus toen nog even modem8 geflasht.
Die ging redelijk snel naar 100Mb/s . En ik heb nu al 24 uur geen disconnect \0/.
Ik had eerder ook al de mtu1500 gefixt, want de vigor moet een beetje meesnoopen op het ppp verkeer om een mtu van 1508 te gaan doen aan de lan kant.

Interessant, ik had een tijdje geleden ineens problemen met mijn Draytek 130
en toen heb ik de Fritzbox er weer tussen gezet.
Ik gebruikte altijd modem4 omdat dit sneller was dan modem5.

Nu heb ik modem8 er in gezet en de problemen zijn weer voorbij en de oude
snelheid komt weer terug zo te zien. Sneller dan de Fritzbox.

Het is nog niet wat het geweest is, vroeger had ik >100 Mbit/s met modem4
maar dat zakte toen ineens in naar 46 ofzo en met de Fritzbox was het 82.6.
Nu met modem8 heb ik inmiddels:

---------------------- ATU-R Info (hw: annex A, f/w: annex A/B/C) -----------
Running Mode : 17A State : SHOWTIME
DS Actual Rate : 87274000 bps US Actual Rate : 16883000 bps
DS Attainable Rate : 91010188 bps US Attainable Rate : 34632000 bps

Merk op dat de "US Actual Rate" niet klopt in deze modems.
Hij geeft daar altijd de initiele waarde, niet de langzaam opklimmende
waarde zoals bij DS. De "US Attainable Rate" klimt wel op. Als je dan
een speedtest doet meet je snelheden die boven die afgebeelde Actual rate
liggen!

Bug wel gemeld maar niet voorbij die koppige Nederlandse importeur te
krijgen en bugs in Taiwan melden werkt ook niet, die verwijzen altijd
meteen terug naar die importeur. Misschien moet je het ook eens melden...

Ik laat dit even draaien voor ik weer met mijn SFP ga testen.

[Coen]

Post by Ard van Breemen
Ik had eerder ook al de mtu1500 gefixt, want de vigor moet een beetje meesnoopen op het ppp verkeer om een mtu van 1508 te gaan doen aan de lan kant.

Kan je dit ietwat toelichten?

Ik kom hier na veel zoeken niet verder dan een MTU van 1496 op de ppp
verbinding. Dat is voorbij de reguliere overhead van pppoe, maar
eigenlijk 4 bytes te weinig.

Mogelijk zit het in de vlan tag maar de oorzaak kan ik niet vinden.

Ik doe tagged verkeer naar de Linux server toe en heb daar een voldoende
grote mtu op de ethernet kaart.

Ik gebruik trouwens de 3.8.3_m8 firmware. Die geeft hier de beste
verbinding (111 down, 33 up) alhoewel hij wel bijna elke dag een keer
opnieuw moet syncen. Maar met andere firmwares wordt dat niet beter en
soms blijft de verbinding dan zelfs down totdat het modem gereset wordt.

gr,
Coen

[Rob]

Post by Coen

Post by Ard van Breemen
Ik had eerder ook al de mtu1500 gefixt, want de vigor moet een beetje meesnoopen op het ppp verkeer om een mtu van 1508 te gaan doen aan de lan kant.

Kan je dit ietwat toelichten?
Ik kom hier na veel zoeken niet verder dan een MTU van 1496 op de ppp
verbinding. Dat is voorbij de reguliere overhead van pppoe, maar
eigenlijk 4 bytes te weinig.
Mogelijk zit het in de vlan tag maar de oorzaak kan ik niet vinden.
Ik doe tagged verkeer naar de Linux server toe en heb daar een voldoende
grote mtu op de ethernet kaart.

Je moet in de Vigor de VLAN tag instellen op de VDSL verbinding (Customer
tag 6 prio 0, geen Service tag), dan kun je aan de ethernet kant untagged
werken en een MTU van 1500 gebruiken.

Post by Coen
Ik gebruik trouwens de 3.8.3_m8 firmware. Die geeft hier de beste
verbinding (111 down, 33 up) alhoewel hij wel bijna elke dag een keer
opnieuw moet syncen. Maar met andere firmwares wordt dat niet beter en
soms blijft de verbinding dan zelfs down totdat het modem gereset wordt.

Dit varieert hier een beetje, soms is ie weken up en dan weer een paar
keer een reset per dag.

[Coen]

Post by Rob

Post by Coen
Ik doe tagged verkeer naar de Linux server toe en heb daar een voldoende
grote mtu op de ethernet kaart.

Je moet in de Vigor de VLAN tag instellen op de VDSL verbinding (Customer
tag 6 prio 0, geen Service tag), dan kun je aan de ethernet kant untagged
werken en een MTU van 1500 gebruiken.

De vigor kant staat precies zo ingesteld.
De pppoe gebruikt eth3. Dus geen vlan tag zoals ik eerder zei.
(pty "pppoe -I eth3")

eth3.6 is er nog wel maar niet in gebruik.
Mtu op ppp0 is 1496. Ik kan hem wel hoger instellen maar die 4 bytes
extra komen niet over de verbinding heen.

Een soort halve RFC4638 dus :)

[Rob]

Post by Coen

Post by Rob

Post by Coen
Ik doe tagged verkeer naar de Linux server toe en heb daar een voldoende
grote mtu op de ethernet kaart.

Je moet in de Vigor de VLAN tag instellen op de VDSL verbinding (Customer
tag 6 prio 0, geen Service tag), dan kun je aan de ethernet kant untagged
werken en een MTU van 1500 gebruiken.

De vigor kant staat precies zo ingesteld.
De pppoe gebruikt eth3. Dus geen vlan tag zoals ik eerder zei.
(pty "pppoe -I eth3")
eth3.6 is er nog wel maar niet in gebruik.
Mtu op ppp0 is 1496. Ik kan hem wel hoger instellen maar die 4 bytes
extra komen niet over de verbinding heen.
Een soort halve RFC4638 dus :)

Je client moet wel RFC4638 doen he! Dat is niet "de MTU op 1500 zetten".
Ik gebruik pppd al jaren niet meer dus ik weet niet of daar een optie
voor nodig is.

Bij mij werkt het, met de MikroTik router en Draytek 130, in ieder geval
feilloos.

[Coen]

Post by Rob
Je client moet wel RFC4638 doen he! Dat is niet "de MTU op 1500 zetten".
Ik gebruik pppd al jaren niet meer dus ik weet niet of daar een optie
voor nodig is.

Zonder RFC4638 zou ik geen 1496MTU kunnen halen volgens mij.
Zou dan ergens bij 1452 of 1492 moeten blijven steken.
Dus ergens heb ik het vermoeden dat dat deel wel goed gaat. Maar
bewijzen kan ik het niet.

[Rob]

Post by Coen

Post by Rob
Je client moet wel RFC4638 doen he! Dat is niet "de MTU op 1500 zetten".
Ik gebruik pppd al jaren niet meer dus ik weet niet of daar een optie
voor nodig is.

Zonder RFC4638 zou ik geen 1496MTU kunnen halen volgens mij.
Zou dan ergens bij 1452 of 1492 moeten blijven steken.
Dus ergens heb ik het vermoeden dat dat deel wel goed gaat. Maar
bewijzen kan ik het niet.

Er zijn aanwijzingen dat XS4ALL dan wel hun apparatuur fabrikant
zich niet helemaal aan de RFC's houdt voor wat betreft de MTU/MRU.

Als je een MRU van 1500 opgeeft terwijl je geen RFC4638 doet dan zou
dit genegeerd moeten worden en terug gebracht naar 1492. Echter dat
lijkt niet te gebeuren.

Dus als je pppd niet die RFC4638 optie voor de uitgebreide MTU stuurt
maar je zet wel de MTU hoger dan kan het inderdaad raar reageren.