Discussion:
DHCPv6 PD
(te oud om op te antwoorden)
Rob
2017-01-11 10:02:02 UTC
Permalink
Hoe zit het nu precies met de afhandeling van DHCPv6 PD aan de kant
van XS4ALL? Als je een request doet via je PPPoE sessie dan krijg je
je prefix, maar ook wordt kennelijk pas DAN de IPv6 routing enabled.

Deze enabling geldt dan niet tot het moment dat die lease verloopt,
maar eindigt meteen als je de PPPoE sessie verbreekt. Dus als de
PPPoE sessie down/up gaat en de DHCPv6 client die dat niet weet nog
geen reden ziet om de lease te hernieuwen, dan ligt je IPv6 eruit.

Omdat de lease time 2 uur is betekent dit dat IPv6 er zomaar een uur
uit kan liggen. Het lijkt er op dat dit niet standards-compliant
is. Zijn er door AVM speciale hacks in de Fritzbox ingebouwd om de
lease te deleten als de PPPoE down/up gaat?
Is het niet mogelijk het aan de kant van XS4ALL zodanig aan te passen
dat de lease geldig blijft gedurende de periode waarvoor die is
uitgegeven?
Miquel van Smoorenburg
2017-01-11 10:27:18 UTC
Permalink
Post by Rob
Hoe zit het nu precies met de afhandeling van DHCPv6 PD aan de kant
van XS4ALL? Als je een request doet via je PPPoE sessie dan krijg je
je prefix, maar ook wordt kennelijk pas DAN de IPv6 routing enabled.
Yups.
Post by Rob
Deze enabling geldt dan niet tot het moment dat die lease verloopt,
maar eindigt meteen als je de PPPoE sessie verbreekt. Dus als de
PPPoE sessie down/up gaat en de DHCPv6 client die dat niet weet nog
geen reden ziet om de lease te hernieuwen, dan ligt je IPv6 eruit.
Dan is je DHCPv6 client niet goed geintegreerd met je router. DHCPv6
gaat over link-local, dus per definitie bevind die client zich op
dezelfde router.
Post by Rob
Omdat de lease time 2 uur is betekent dit dat IPv6 er zomaar een uur
uit kan liggen. Het lijkt er op dat dit niet standards-compliant
is. Zijn er door AVM speciale hacks in de Fritzbox ingebouwd om de
lease te deleten als de PPPoE down/up gaat?
Ik denk dat dat geen hack is, het is gewoon een robuuste implementatie.
Link komt op - PPP sessie wordt established - DHCP wordt gestart.

Het is op IPv4 exact hetzelfde en altijd zo geweest, en dat is
eigenlijk ook niet RFC compliant- maar op CPEs de industrie standaard.
Post by Rob
Is het niet mogelijk het aan de kant van XS4ALL zodanig aan te passen
dat de lease geldig blijft gedurende de periode waarvoor die is
uitgegeven?
Dit is gedrag van de BRAS en niet aan te passen- link down, lease weg.

Mike.
Rob
2017-01-11 12:17:16 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Hoe zit het nu precies met de afhandeling van DHCPv6 PD aan de kant
van XS4ALL? Als je een request doet via je PPPoE sessie dan krijg je
je prefix, maar ook wordt kennelijk pas DAN de IPv6 routing enabled.
Yups.
Post by Rob
Deze enabling geldt dan niet tot het moment dat die lease verloopt,
maar eindigt meteen als je de PPPoE sessie verbreekt. Dus als de
PPPoE sessie down/up gaat en de DHCPv6 client die dat niet weet nog
geen reden ziet om de lease te hernieuwen, dan ligt je IPv6 eruit.
Dan is je DHCPv6 client niet goed geintegreerd met je router. DHCPv6
gaat over link-local, dus per definitie bevind die client zich op
dezelfde router.
Ja maar volgens mij staat er nergens dat een DHCP client een lease
moet weggooien als de link down gaat. Dat is in DHCP land ook niet
gebruikelijk.
Post by Miquel van Smoorenburg
Post by Rob
Omdat de lease time 2 uur is betekent dit dat IPv6 er zomaar een uur
uit kan liggen. Het lijkt er op dat dit niet standards-compliant
is. Zijn er door AVM speciale hacks in de Fritzbox ingebouwd om de
lease te deleten als de PPPoE down/up gaat?
Ik denk dat dat geen hack is, het is gewoon een robuuste implementatie.
Link komt op - PPP sessie wordt established - DHCP wordt gestart.
Het is op IPv4 exact hetzelfde en altijd zo geweest, en dat is
eigenlijk ook niet RFC compliant- maar op CPEs de industrie standaard.
Het probleem is dat als de link down geweest is de router de lease
probeert te renewen maar dat lukt niet, er moet echt een nieuwe lease
worden aagevraagd. Zelfs bij een reboot gaat dat zo: de renew van
de lease die nog geldig in de router staat lukt niet. Dit lijkt me
niet standaards compliant, maar kennelijk is het industrie standaard?

Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.

Echter, helaas kan ik (nog) geen script actie aan het opkomen van de
PPPoE interface koppelen dus moet ik hier een netwatch object van maken,
dwz er wordt iedere minuut een ping gedaan naar een in te stellen adres
en als dat weer lukt (na een tijdje niet of na een reboot) wordt die
script actie uitgevoerd. Dan werkt het wel maar fraai is anders.

Ik denk dat de Fritzbox de lease nooit zelf bewaart en probeert te
renewen maar altijd een nieuwe vraagt, dan werkt het wel.
Philip Homburg
2017-01-11 15:47:19 UTC
Permalink
Post by Rob
Het probleem is dat als de link down geweest is de router de lease
probeert te renewen maar dat lukt niet, er moet echt een nieuwe lease
worden aagevraagd. Zelfs bij een reboot gaat dat zo: de renew van
de lease die nog geldig in de router staat lukt niet. Dit lijkt me
niet standaards compliant, maar kennelijk is het industrie standaard?
Het is helemaal niet gek bij een nieuwe link een nieuwe lease aan te
vragen (of op z'n minst maar heel kort een renew te proberen).

Helaas is dit allemaal erg slecht gespecificeerd. Men doet wat en dan
doet de andere kant wat en voor je weet heb je een standaard die nergens
op papier staat.

De reden om een nieuwe lease aan te vragen is dat je in het algemeen niet
weet of de nieuwe link hetzelfde is als de oude. Neem een computer die
je van het ene ethernet naar het andere plugt.

Dan heeft het dus geen zin om lang te proberen toch je oude adres te
krijgen. Geen idee trouwens waarom de renew aan de xs4all kan niet werkt.
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Miquel van Smoorenburg
2017-01-11 20:01:14 UTC
Permalink
Post by Philip Homburg
Dan heeft het dus geen zin om lang te proberen toch je oude adres te
krijgen. Geen idee trouwens waarom de renew aan de xs4all kan niet werkt.
Aan de xs4all kant wordt de ingebouwde DHCPv6 server van de Juniper
gebruikt, en daar kan je niet zo heel veel aan instellen. Als het een
centrale DHCP server was, met DHCP relay op de BRAS, dan zou het
mogelijk wel werken, maar daar is niet voor gekozen.

Overigens is het inderdaad zo dat je bij het opzetten van een nieuwe
verbinding theoretisch uit kan komen op een andere BRAS, en die
heeft geen dhcp-lease-database-sync met de DHCPv6 servers op de
andere BRASsen (ok, niet vandaag, maar later dit jaar waarschijnlijk).

Mike.
Rob
2017-01-11 20:16:45 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Philip Homburg
Dan heeft het dus geen zin om lang te proberen toch je oude adres te
krijgen. Geen idee trouwens waarom de renew aan de xs4all kan niet werkt.
Aan de xs4all kant wordt de ingebouwde DHCPv6 server van de Juniper
gebruikt, en daar kan je niet zo heel veel aan instellen. Als het een
centrale DHCP server was, met DHCP relay op de BRAS, dan zou het
mogelijk wel werken, maar daar is niet voor gekozen.
Overigens is het inderdaad zo dat je bij het opzetten van een nieuwe
verbinding theoretisch uit kan komen op een andere BRAS, en die
heeft geen dhcp-lease-database-sync met de DHCPv6 servers op de
andere BRASsen (ok, niet vandaag, maar later dit jaar waarschijnlijk).
Maar wat is eigenlijk de reden dat je geen IPv6 routing hebt als je geen
lease hebt gevraagd? Meestal is een lease toch alleen ter informatie,
maar nu heeft die kennelijk side-effects. Daar is in het ontwerp van
DHCP denk ik geen rekening mee gehouden want dan had men niet zo'n vaste
geldigheidstermijn voor een lease bedacht zonder daarin extra opties zoals
"maar een lease geldt alleen tot de interface down gaat" ingebouwd.

Is dit een vrijwillige keuze of kan het zonder lease gewoon niet werken?
Miquel van Smoorenburg
2017-01-11 21:26:19 UTC
Permalink
Post by Rob
Maar wat is eigenlijk de reden dat je geen IPv6 routing hebt als je geen
lease hebt gevraagd?
"zo werkt het nu eenmaal op de Juniper MX". Er is geen knopje
voor, en ik heb de source code niet.
Post by Rob
Meestal is een lease toch alleen ter informatie,
maar nu heeft die kennelijk side-effects.
Da's vrijwel altijd zo op dit soort routers. Dat XS4ALL met
vaste IPs werkt is de uitzondering, de rest van de wereld werkt
met dynamische adressen. En als die van een externe DHCP
server komen, dan is de enige manier voor de BRAS om het IP of
de prefix die aan de klant uitgedeeld is te weten door de
DHCP packets te sniffen (makkelijk, het gaat toch door de DHCP
relay op die doos heen).

Mike.
Rob
2017-01-11 21:47:38 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Maar wat is eigenlijk de reden dat je geen IPv6 routing hebt als je geen
lease hebt gevraagd?
"zo werkt het nu eenmaal op de Juniper MX". Er is geen knopje
voor, en ik heb de source code niet.
Ah er stond me iets van bij dat dit ooit eens veranderd was dus ik
dacht wellicht is het een setting...
Miquel van Smoorenburg
2017-01-12 09:16:06 UTC
Permalink
Post by Rob
Post by Miquel van Smoorenburg
Post by Rob
Maar wat is eigenlijk de reden dat je geen IPv6 routing hebt als je geen
lease hebt gevraagd?
"zo werkt het nu eenmaal op de Juniper MX". Er is geen knopje
voor, en ik heb de source code niet.
Ah er stond me iets van bij dat dit ooit eens veranderd was dus ik
dacht wellicht is het een setting...
Dat herinner je je correct! Maar dat was toen we de hardware hebben
geupgrade van Juniper E-series naar Juniper MX-series.

De E-series zijn geen echte Junipers- kwam uit een overname. Dat
draaide software genaamd "Junos-E", maar dat had niks met
Junos te maken. De config en CLI waren ook volledig verschillend.

Mike.
Rob
2017-01-12 09:31:27 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Rob
Post by Miquel van Smoorenburg
Post by Rob
Maar wat is eigenlijk de reden dat je geen IPv6 routing hebt als je geen
lease hebt gevraagd?
"zo werkt het nu eenmaal op de Juniper MX". Er is geen knopje
voor, en ik heb de source code niet.
Ah er stond me iets van bij dat dit ooit eens veranderd was dus ik
dacht wellicht is het een setting...
Dat herinner je je correct! Maar dat was toen we de hardware hebben
geupgrade van Juniper E-series naar Juniper MX-series.
De E-series zijn geen echte Junipers- kwam uit een overname. Dat
draaide software genaamd "Junos-E", maar dat had niks met
Junos te maken. De config en CLI waren ook volledig verschillend.
Ah ok dat verklaart het.

Nou ja voor de mensen die mee lezen en die ook graag willen dat IPv6
het op hun MikroTik router zo snel mogelijk weer doet na een reboot
of een PPPoE link reset (modem re-train ofzo), de workaround die ik
nu gebruik is:

/tool netwatch
add comment="Reset IPv6 when PPPoE comes up" host=194.109.6.8 up-script=\
"/ipv6 dhcp-client release [find interface=pppoe-xs4all]"

De interface daarin (pppoe-xs4all) moet worden aangepast aan de naam
die je gekozen hebt voor de PPPoE interface (default is pppoe-out1).

Ik hoop er op dat men nog een up-script functionaliteit aan de PPPoE
interface zelf toevoegt zodat deze lelijke ping niet nodig is en het ook
beter zal werken (deze oplossing detecteert een interface reset mogelijk
niet als deze korter dan een minuut duurt omdat de pings om de minuut
zijn, en als er per ongeluk een ping mist wordt meteen daarna die lease
gereleased en opnieuw aangevraagd waardoor IPv6 wellicht hapert)
Casper H.S. Dik
2017-01-12 09:37:45 UTC
Permalink
Post by Rob
Ik hoop er op dat men nog een up-script functionaliteit aan de PPPoE
interface zelf toevoegt zodat deze lelijke ping niet nodig is en het ook
beter zal werken (deze oplossing detecteert een interface reset mogelijk
niet als deze korter dan een minuut duurt omdat de pings om de minuut
zijn, en als er per ongeluk een ping mist wordt meteen daarna die lease
gereleased en opnieuw aangevraagd waardoor IPv6 wellicht hapert)
Ben ik nou gek of zou dit gewone functionaliteit van een OS moeten zijn?

Link weg & terug -> nieuw DHCP request?

(Werkt natuurlijk niet als de DHCP client niet degene is die de link
kan zien; ik denk dat ook de reden is dat mijn Cisco kabel modem
bij een nieuwe link de ethernet link uit en aan gaat.

Casper
Rob
2017-01-12 09:49:07 UTC
Permalink
Post by Casper H.S. Dik
Post by Rob
Ik hoop er op dat men nog een up-script functionaliteit aan de PPPoE
interface zelf toevoegt zodat deze lelijke ping niet nodig is en het ook
beter zal werken (deze oplossing detecteert een interface reset mogelijk
niet als deze korter dan een minuut duurt omdat de pings om de minuut
zijn, en als er per ongeluk een ping mist wordt meteen daarna die lease
gereleased en opnieuw aangevraagd waardoor IPv6 wellicht hapert)
Ben ik nou gek of zou dit gewone functionaliteit van een OS moeten zijn?
Link weg & terug -> nieuw DHCP request?
Er zijn OS'en die dat doen maar in Linux is dat niet gebruikelijk.
Bovendien, hij doet dan een "rebind" en dat ondersteunt die Juniper
kennelijk niet. Je moet een DHCP client zonder persistent storage
hebben, een die meteen met een "request" begint dus zonder terug te
verwijzen naar de eerdere lease die nog niet afgelopen is.
Daarom doe ik die release want dan doet deze client dat ook.
Udo
2017-02-24 16:34:19 UTC
Permalink
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?


Udo
Rob
2017-02-24 18:58:37 UTC
Permalink
Post by Udo
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?
Ja aan de client kant. Zoals vrij gebruikelijk in DHCP.
Maar de DHCP server in de routers van XS4ALL snapt dat niet, die wil
op een nieuwe verbinding alleen nieuwe leases uitgeven.
Udo
2017-02-25 06:14:23 UTC
Permalink
Post by Rob
Post by Udo
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?
Ja aan de client kant. Zoals vrij gebruikelijk in DHCP.
Maar de DHCP server in de routers van XS4ALL snapt dat niet, die wil
op een nieuwe verbinding alleen nieuwe leases uitgeven.
Kan ik niet gewoonweg de dhclient afschieten,
/var/lib/dhclient/dhclient6.leases weggooien of er een nullengte bestand
van maken en dan weer een lease aanvragen?
Dat releasen richting dhcp server doet toch nix...

Udo
Udo
2017-02-25 11:25:58 UTC
Permalink
Post by Udo
Kan ik niet gewoonweg de dhclient afschieten,
/var/lib/dhclient/dhclient6.leases weggooien of er een nullengte bestand
van maken en dan weer een lease aanvragen?
Dat releasen richting dhcp server doet toch nix...
Hmnee:

Feb 25 12:22:06 e dhclient[7909]: xid: rand init seed (0x9bfbeb34) built
using all available interfaces
Feb 25 12:22:07 e dhclient[7909]: Failure assembling a DUID.
Feb 25 12:22:07 e dhclient[7909]:
Feb 25 12:22:07 e dhclient[7909]: This version of ISC DHCP is based on
the release available
Feb 25 12:22:07 e dhclient[7909]: on ftp.isc.org. Features have been
added and other changes
Feb 25 12:22:07 e dhclient[7909]: have been made to the base software
release in order to make
Feb 25 12:22:07 e dhclient[7909]: it work better with this distribution.
Feb 25 12:22:07 e dhclient[7909]:
Feb 25 12:22:07 e dhclient[7909]: Please report for this software via
the Red Hat Bugzilla site:
Feb 25 12:22:07 e dhclient[7909]: http://bugzilla.redhat.com
Feb 25 12:22:07 e dhclient[7909]:
Feb 25 12:22:07 e dhclient[7909]: exiting.

Dus hoe fijn zit die software in elkaar?

dhclient6.leases terugzetten en het werkt weer.
timeouts voor dhclient over ipv6 zijn niet in te stellen (zie man page)
Dus ik bespaar nog steeds grofweg 59 minuten...


Udo
Udo
2017-02-25 11:35:16 UTC
Permalink
Post by Udo
Dus ik bespaar nog steeds grofweg 59 minuten...
Want release via de client doet dit:

Feb 25 06:46:32 e dhclient[1149]: xid: rand init seed (0x9cfbab24) built
using all available interfaces
Feb 25 06:46:32 e dhclient[1149]: XMT: Release on ppp0, interval 980ms.
Feb 25 06:46:33 e dhclient[1149]: XMT: Release on ppp0, interval 2050ms.
Feb 25 06:46:36 e dhclient[1149]: XMT: Release on ppp0, interval 4060ms.
Feb 25 06:46:40 e dhclient[1149]: XMT: Release on ppp0, interval 8400ms.
Feb 25 06:46:48 e dhclient[1149]: XMT: Release on ppp0, interval 16480ms.
Feb 25 06:47:04 e dhclient[1149]: XMT: Release on ppp0, interval 34170ms.
Feb 25 06:47:39 e dhclient[1149]: Max retransmission count exceeded.


Er komt dus geen reactie van xs4all.
En na deze grove minuut kan er gewoon vlot een verse lease gevraagd worden.

Udo
Rob
2017-02-25 12:58:53 UTC
Permalink
Post by Udo
Post by Rob
Post by Udo
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?
Ja aan de client kant. Zoals vrij gebruikelijk in DHCP.
Maar de DHCP server in de routers van XS4ALL snapt dat niet, die wil
op een nieuwe verbinding alleen nieuwe leases uitgeven.
Kan ik niet gewoonweg de dhclient afschieten,
/var/lib/dhclient/dhclient6.leases weggooien of er een nullengte bestand
van maken en dan weer een lease aanvragen?
Dat releasen richting dhcp server doet toch nix...
Ik weet niet hoe dat werkt in dhclient.
Tegenwoordig gebruik ik een MikroTik router die wel dat soort software
draait (ik weet niet of het precies deze client is) maar er zit een
laag overheen waardoor je niet zelf met de config van al die spullen
hoeft te rommelen.
Udo
2017-02-25 13:20:23 UTC
Permalink
Post by Rob
Ik weet niet hoe dat werkt in dhclient.
Als ik in /var/lib/dhclient/dhclient6.leases alleen de default-duid
regel overlaat werkrt dhclient gewoon en verkrijgt succesvol een lease.

Udo
Rob
2017-02-26 14:29:13 UTC
Permalink
Post by Udo
Post by Rob
Ik weet niet hoe dat werkt in dhclient.
Als ik in /var/lib/dhclient/dhclient6.leases alleen de default-duid
regel overlaat werkrt dhclient gewoon en verkrijgt succesvol een lease.
Udo
Ok, dan moet je dus nog zien te regelen dat ie dat doet als pppd een
nieuwe verbinding opzet. Want bij een nieuwe verbinding moet je de
oude lease dus vergeten, verlengen daarvan is wat het probleem geeft.
Udo
2017-02-27 15:02:06 UTC
Permalink
Post by Rob
Post by Udo
Als ik in /var/lib/dhclient/dhclient6.leases alleen de default-duid
regel overlaat werkrt dhclient gewoon en verkrijgt succesvol een lease.
Ok, dan moet je dus nog zien te regelen dat ie dat doet als pppd een
nieuwe verbinding opzet. Want bij een nieuwe verbinding moet je de
oude lease dus vergeten, verlengen daarvan is wat het probleem geeft.
Dat is ingeregeld in /sbin/adsl-start en /sbin/adsl-stop.
Rob
2017-02-27 15:17:44 UTC
Permalink
Post by Udo
Post by Rob
Post by Udo
Als ik in /var/lib/dhclient/dhclient6.leases alleen de default-duid
regel overlaat werkrt dhclient gewoon en verkrijgt succesvol een lease.
Ok, dan moet je dus nog zien te regelen dat ie dat doet als pppd een
nieuwe verbinding opzet. Want bij een nieuwe verbinding moet je de
oude lease dus vergeten, verlengen daarvan is wat het probleem geeft.
Dat is ingeregeld in /sbin/adsl-start en /sbin/adsl-stop.
En die wordt dan weer gestart door pppd neem ik aan?
Udo
2017-02-27 15:37:27 UTC
Permalink
Post by Rob
Post by Udo
Post by Rob
Ok, dan moet je dus nog zien te regelen dat ie dat doet als pppd een
nieuwe verbinding opzet. Want bij een nieuwe verbinding moet je de
oude lease dus vergeten, verlengen daarvan is wat het probleem geeft.
Dat is ingeregeld in /sbin/adsl-start en /sbin/adsl-stop.
En die wordt dan weer gestart door pppd neem ik aan?
adsl-start start pppd en wat daar bij hoort.
adsl-start wordt door `ifup ppp0` aangeroepen.


Udo
Udo
2017-02-27 15:02:17 UTC
Permalink
Post by Rob
Post by Udo
Als ik in /var/lib/dhclient/dhclient6.leases alleen de default-duid
regel overlaat werkrt dhclient gewoon en verkrijgt succesvol een lease.
Ok, dan moet je dus nog zien te regelen dat ie dat doet als pppd een
nieuwe verbinding opzet. Want bij een nieuwe verbinding moet je de
oude lease dus vergeten, verlengen daarvan is wat het probleem geeft.
Dat is ingeregeld in /sbin/adsl-start en /sbin/adsl-stop.
MM
2017-02-25 09:10:06 UTC
Permalink
Post by Udo
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?
Udo
Mikrotik heeft in hun RouterOS nu ook een mogelijkheid toegevoegd om bij
een verandering van de DHCP een script te kunnen draaien. Dit voor ISP
die DHCPv6 en DHCP nog weer anders gebruiken dan Xs4all.
Een erg mooie oplossingen geworden waar direct gebruik kan worden
gemaakt van variabelen zonder die eerste te hoeven defineren.

Voor Xs4all klanten kan het script draaien als de verbinding opnieuw
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.

Mikrotik timmert erg hard aan het moment aan RouterOS en je hebt echt
het gevoel dat er geluisterd wordt. Staan nog heel wat dingen uit voor
v7 en mijn indruk is dat dingen die voor v7 stonden gepland nu toch in
v6 zijn gekomen. :-)
Rob
2017-02-25 12:57:49 UTC
Permalink
Post by MM
Post by Udo
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
de lease en dan vraagt de DHCP client meteen een nieuwe lease ipv een
renew te doen. Dat helpt.
Hier nu ook...! (dank voor de tip, werkt hier op Fedora Linux met ISC dhcp)
Betekent dit dat ondanks dat de ppp verbinding plat lag er toch nog wel
info over de prefix lease aanwezig bleef?
Udo
Mikrotik heeft in hun RouterOS nu ook een mogelijkheid toegevoegd om bij
een verandering van de DHCP een script te kunnen draaien. Dit voor ISP
die DHCPv6 en DHCP nog weer anders gebruiken dan Xs4all.
Maar daar heb je in dit geval niets aan.
Je kunt echter ook een script draaien bij het opkomen van de PPPoE verbinding
en daarmee kun je het wel goed krijgen.

/ppp profile
add change-tcp-mss=no name=pppoe-xs4all on-up=\
"/ipv6 dhcp-client release [find interface=pppoe-xs4all-inet]" only-one=\
yes use-compression=no use-encryption=no use-mpls=no use-upnp=no
/interface pppoe-client
add add-default-route=yes allow=pap,mschap2 comment=\
"PPPoE-link XS4ALL-internet" default-route-distance=1 disabled=no \
interface=ether1 max-mru=1500 max-mtu=1500 mrru=1500 name=\
pppoe-xs4all-inet password=password profile=pppoe-xs4all user=user
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-xs4all-inet pool-name=\
xs4all-v6prefix request=prefix
/ipv6 address
add eui-64=yes from-pool=xs4all-v6prefix interface=bridge-local
MM
2017-02-25 21:47:12 UTC
Permalink
Post by Rob
Post by MM
Post by Rob
Ik heb nu een workaround: als de verbinding opkomt dan release ik eerst
knip
Post by Rob
Post by MM
Udo
Mikrotik heeft in hun RouterOS nu ook een mogelijkheid toegevoegd om bij
een verandering van de DHCP een script te kunnen draaien. Dit voor ISP
die DHCPv6 en DHCP nog weer anders gebruiken dan Xs4all.
Maar daar heb je in dit geval niets aan.
Je kunt echter ook een script draaien bij het opkomen van de PPPoE verbinding
en daarmee kun je het wel goed krijgen.
/ppp profile
add change-tcp-mss=no name=pppoe-xs4all on-up=\
"/ipv6 dhcp-client release [find interface=pppoe-xs4all-inet]" only-one=\
yes use-compression=no use-encryption=no use-mpls=no use-upnp=no
/interface pppoe-client
add add-default-route=yes allow=pap,mschap2 comment=\
"PPPoE-link XS4ALL-internet" default-route-distance=1 disabled=no \
interface=ether1 max-mru=1500 max-mtu=1500 mrru=1500 name=\
pppoe-xs4all-inet password=password profile=pppoe-xs4all user=user
/ipv6 dhcp-client
add add-default-route=yes interface=pppoe-xs4all-inet pool-name=\
xs4all-v6prefix request=prefix
/ipv6 address
add eui-64=yes from-pool=xs4all-v6prefix interface=bridge-local
Klopt en ik had dit ook vermeld maar is niet in jouw quote meegekomen. :-)
Post by Rob
Voor Xs4all klanten kan het script draaien als de verbinding opnieuw gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
Udo
2017-03-17 13:51:13 UTC
Permalink
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...

Udo
Rob
2017-03-17 14:17:55 UTC
Permalink
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...
Dat zag ik laatst ook ja. Dit is wellicht voor sommigen een verbetering
maar in andere gevallen is het juist een verslechtering. Met name als je
in de situatie zit van een lokaal onthouden lease die niet meer geldig is
duurt het nu langer voor dat zichzelf fixt.
Philip Homburg
2017-03-17 15:44:58 UTC
Permalink
Post by Rob
Dat zag ik laatst ook ja. Dit is wellicht voor sommigen een verbetering
maar in andere gevallen is het juist een verslechtering. Met name als je
in de situatie zit van een lokaal onthouden lease die niet meer geldig is
duurt het nu langer voor dat zichzelf fixt.
Helaas mist er nogal wat rond DHCPv6 PD. Dus het handigst is waarschijnlijk
om monitoring op te zetten (bijv. een ping naar ping.xs4all.nl) en als dat
faalt de lease te vernieuwen.

Voor docsis is er een extra protocol om dat te doen. Maar dat is buiten de
IETF ontwikkeld en geldt alleen voor kabelmodems.
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Rob
2017-03-17 16:07:58 UTC
Permalink
Post by Philip Homburg
Post by Rob
Dat zag ik laatst ook ja. Dit is wellicht voor sommigen een verbetering
maar in andere gevallen is het juist een verslechtering. Met name als je
in de situatie zit van een lokaal onthouden lease die niet meer geldig is
duurt het nu langer voor dat zichzelf fixt.
Helaas mist er nogal wat rond DHCPv6 PD. Dus het handigst is waarschijnlijk
om monitoring op te zetten (bijv. een ping naar ping.xs4all.nl) en als dat
faalt de lease te vernieuwen.
Nou volgens mij is de makke vooral dat de server leases uitgeeft met een
bepaalde geldigheid (tijdsduur) maar die geldigheid niet respecteert als
voor het verlopen van de tijdsduur de verbinding onderbroken wordt.

Als men dat zou fixen dan zou er geen probleem zijn met clients die op
de voor DHCP gebruikelijke manier werken (leases opslaan in nonvolatile
storage en als de link op komt de bestaande lease proberen te renewen).

Nu zijn er weer allerlei truuks nodig om de client te bewegen maar gewoon
een discover te laten doen.
Philip Homburg
2017-03-17 22:26:09 UTC
Permalink
Post by Rob
Nou volgens mij is de makke vooral dat de server leases uitgeeft met een
bepaalde geldigheid (tijdsduur) maar die geldigheid niet respecteert als
voor het verlopen van de tijdsduur de verbinding onderbroken wordt.
Als men dat zou fixen dan zou er geen probleem zijn met clients die op
de voor DHCP gebruikelijke manier werken (leases opslaan in nonvolatile
storage en als de link op komt de bestaande lease proberen te renewen).
Nu zijn er weer allerlei truuks nodig om de client te bewegen maar gewoon
een discover te laten doen.
Het probleem is dat de RFC waarin IA_PD gedefineerd wordt niets zegt over
de route naar die prefix. Dus als de router bij xs4all na een link down
die route weggooit dan is dat prima volgens de RFC.

Dus het kan best zijn dat je de lease technisch gezien nog hebt, maar dat
er gewoon geen route is. Dat is gemakkelijk te testen door te kijken of je
binnen de periode van de lease met een andere DUID dezelfde prefix
nog een keer kan krijgen.

En dan kan je wel naar Juniper stappen en zeggen dat het niet werkt, maar
als zij dan zeggen dat je na een link up maar een renew moet doen van de
lease om weer een route te krijgen, dan ben je waar je nu ook bent.
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Rob
2017-03-20 14:41:20 UTC
Permalink
Post by Philip Homburg
En dan kan je wel naar Juniper stappen en zeggen dat het niet werkt, maar
als zij dan zeggen dat je na een link up maar een renew moet doen van de
lease om weer een route te krijgen, dan ben je waar je nu ook bent.
Als dat nou zou werken...
Maar dat doet het niet. Een renew werkt niet. Je moet een discover doen.
Philip Homburg
2017-03-20 16:17:12 UTC
Permalink
Post by Rob
Post by Philip Homburg
En dan kan je wel naar Juniper stappen en zeggen dat het niet werkt, maar
als zij dan zeggen dat je na een link up maar een renew moet doen van de
lease om weer een route te krijgen, dan ben je waar je nu ook bent.
Als dat nou zou werken...
Maar dat doet het niet. Een renew werkt niet. Je moet een discover doen.
Ja, Juniper is buggy troep. Maar de alternatieven schijnen dat ook te zijn.
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
MM
2017-03-17 16:22:09 UTC
Permalink
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te
gebeuren...
Post by Udo
Udo
Bij mij staat nu de expire op 24 uur. Voorheen was dat 2 uur.
Rob
2017-03-20 14:41:46 UTC
Permalink
Post by MM
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn
bij
Post by Udo
Post by MM
Xs4all zijn geen probleem in de implementatie van DHCPv6 door
Mikrotik.
Post by Udo
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te
gebeuren...
Post by Udo
Udo
Bij mij staat nu de expire op 24 uur. Voorheen was dat 2 uur.
Ja dus om de 12 uur vernieuwen bij een normale implementatie.
Miquel van Smoorenburg
2017-03-20 17:05:11 UTC
Permalink
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...
We zijn maandenlang bezig geweest een bug op te sporen in JunOS
waar we veel last van hadden (te ingewikkeld om hier uit te leggen,
maar als je aansluiting via de dr15.d12 router loopt zou je het
best gemerkt kunnen hebben).

Uiteindelijk moest er een stukje config niet meer gebruikt worden
en dat lost het op. Alleen wat tot nu toe niemand opgevallen is,
is dat dat stukje ook noodzakelijk is om DHCP leasetimes anders dan
de standaard in te stellen. En nu hebben we geen last meer van de
bug, maar kunnen we ook de leasetijd niet meer instellen. Argh.

Mike.
Flibsy
2017-03-20 18:48:25 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...
We zijn maandenlang bezig geweest een bug op te sporen in JunOS
waar we veel last van hadden (te ingewikkeld om hier uit te leggen,
maar als je aansluiting via de dr15.d12 router loopt zou je het
best gemerkt kunnen hebben).
Uiteindelijk moest er een stukje config niet meer gebruikt worden
en dat lost het op. Alleen wat tot nu toe niemand opgevallen is,
is dat dat stukje ook noodzakelijk is om DHCP leasetimes anders dan
de standaard in te stellen. En nu hebben we geen last meer van de
bug, maar kunnen we ook de leasetijd niet meer instellen. Argh.
Dik balen. De vraag is nu wat erger is, de kwaal of het middel.
--
Flibsy
Miquel van Smoorenburg
2017-03-20 19:19:51 UTC
Permalink
Post by Flibsy
Post by Miquel van Smoorenburg
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...
We zijn maandenlang bezig geweest een bug op te sporen in JunOS
waar we veel last van hadden (te ingewikkeld om hier uit te leggen,
maar als je aansluiting via de dr15.d12 router loopt zou je het
best gemerkt kunnen hebben).
Uiteindelijk moest er een stukje config niet meer gebruikt worden
en dat lost het op. Alleen wat tot nu toe niemand opgevallen is,
is dat dat stukje ook noodzakelijk is om DHCP leasetimes anders dan
de standaard in te stellen. En nu hebben we geen last meer van de
bug, maar kunnen we ook de leasetijd niet meer instellen. Argh.
Dik balen. De vraag is nu wat erger is, de kwaal of het middel.
Oh, de kwaal is vele, vele vele malen erger. Dat betekent gewoon
"elke config wijziging, hoe minor ook, resulteert in het uitloggen
en weer inloggen van alle klanten en dat duurt meer dan een uur".

Het ziet er naar uit dat de volgende major versie van de software
het mogelijk maakt dit weer aan te zetten, en het plan is om
daar in de komende paar maanden naar te migreren. De eerste
testgroep vannacht, zelfs. Dan hebben we een oplossing waarbij
we niet de baby met het badwater hoeven weg te gooien.

Mike.
Flibsy
2017-03-20 19:48:39 UTC
Permalink
Post by Miquel van Smoorenburg
Post by Flibsy
Post by Miquel van Smoorenburg
Post by Udo
Post by MM
gestart wordt. De tussentijdse vernieuwingen (elke 2 uur) zijn bij
Xs4all zijn geen probleem in de implementatie van DHCPv6 door Mikrotik.
En sinds een dag of wat lijkt de vernieuwing elke 12 uur te gebeuren...
We zijn maandenlang bezig geweest een bug op te sporen in JunOS
waar we veel last van hadden (te ingewikkeld om hier uit te leggen,
maar als je aansluiting via de dr15.d12 router loopt zou je het
best gemerkt kunnen hebben).
Uiteindelijk moest er een stukje config niet meer gebruikt worden
en dat lost het op. Alleen wat tot nu toe niemand opgevallen is,
is dat dat stukje ook noodzakelijk is om DHCP leasetimes anders dan
de standaard in te stellen. En nu hebben we geen last meer van de
bug, maar kunnen we ook de leasetijd niet meer instellen. Argh.
Dik balen. De vraag is nu wat erger is, de kwaal of het middel.
Oh, de kwaal is vele, vele vele malen erger. Dat betekent gewoon
"elke config wijziging, hoe minor ook, resulteert in het uitloggen
en weer inloggen van alle klanten en dat duurt meer dan een uur".
Het ziet er naar uit dat de volgende major versie van de software
het mogelijk maakt dit weer aan te zetten, en het plan is om
daar in de komende paar maanden naar te migreren. De eerste
testgroep vannacht, zelfs. Dan hebben we een oplossing waarbij
we niet de baby met het badwater hoeven weg te gooien.
Kijk eens aan. Van plensregen via lichte drup naar de volle zon. Wat een
mooi vak had ik toch.
--
Flibsy
A. Dumas
2017-03-21 08:52:08 UTC
Permalink
Post by Flibsy
Kijk eens aan. Van plensregen via lichte drup naar de volle zon. Wat een
mooi vak had ik toch.
Boswachter? [heart eyes emoji]
Flibsy
2017-03-21 11:18:19 UTC
Permalink
Post by Flibsy
Kijk eens aan. Van plensregen via lichte drup naar de volle zon. Wat een
mooi vak had ik toch.
Boswachter? /
Neuh, lijkt me heel saai, de hele dag wachten op een bos.
/ [heart eyes emoji]
Omdat je het zo vriendelijk vraagt:

😍
--
Flibsy
Loading...