USG lijkt gedeeltelijk te crashen na overstap naar Cloud Key.

[Sandertjuhh]

Hallo allemaal,

Na een tijdje meelezen op het forum toch maar even een account gemaakt omdat ik tegen wat rare problemen aanloop waar ik zelf geen wijs uit wordt. Ik hoop dat jullie mij opweg kunnen helpen.

Mijn oude situatie was als volgt:
Unifi Controller in een Docker container, configuratie van de Controller / USG conform documentatie van Henk/Coolhva (https://github.com/coolhva/usg-kpn-ftth). Alles werkend, geen issues.

Nu wil ik overstappen op er Cloud Key gen 2+. Ik heb daarom een full backup gemaakt op huidige controller (Docker), incl alle history (no limit). Op de Cloud Key heb ik zowel de console als de Network Application volledig ge-update. De versies tussen de instantie in docker en op de Cloud Key zijn gelijk. Vervolgens heb ik de oude controller gestopt, de backup terug gezet op de Cloud Key en de USG opnieuw geadopteerd (d.m.v invoeren device wachtwoord).

Hierna leek alles te werken, echter merkte ik dat regelmatig (om de 15-45 minuten) mijn internet verbinding volledig weg valt. In de nieuwe UI zie op de Cloud key ik de USG dan als “getting ready” staan. Na een tijdje komt het internet weer volledig terug tot deze weer weg valt. In de Legacy UI zie ik alleen de expirience op 0% staan, dus b.v. niet dat die aan het provisionen is.

Als het internet weg valt heeft deze geen public IP meer op de PPPOE2, ook is mijn IPv6 op dat moment weg:

@ubnt:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description                 
---------    ----------                        ---  -----------                 
eth0         -                                 u/u  WAN                         
eth0.4       10.0.42.127/20                    u/u  IPTV                       
eth0.6       -                                 u/u                             
eth1         192.168.2.254/24                  u/u  LAN                         
eth2         -                                 A/D                             
lo           127.0.0.1/8                       u/u                             
             ::1/128

Als het internet het weer doet zijn deze beide terug:

@ubnt:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface    IP Address                        S/L  Description                 
---------    ----------                        ---  -----------                 
eth0         -                                 u/u  WAN                         
eth0.4       10.0.42.127/20                    u/u  IPTV                       
eth0.6       -                                 u/u                             
eth1         192.168.2.254/24                  u/u  LAN                         
             2a02:a450:1ca6:1:1ae8:29ff:fe44:cdb0/64
eth2         -                                 A/D                             
lo           127.0.0.1/8                       u/u                             
             ::1/128                         
pppoe2       86.89.*.*                      u/u

Dit gedrag zie ik ook terug bij een reboot omdat het KPN script van Henk het e.e.a. instelt (waarover het IPv6 adres). Het lijkt dus op een gedeeltelijke crash/reboot van de USG. Echter verlies ik op dat moment mij SSH verbinding maar de USG niet, waardoor ik denk dat het niet om een volledige crash gaat.

Zodra ik terug ga naar de oude controller in Docker (container opstarten, netwerk app op de Cloud Key stoppen, alle devices weer adopteer) blijft het als vanouds stabiel werken, zonder drops van het internet. Dit lijkt te wijzen op een controller issue.

Zaken die ik al gecheckt/geprobeerd heb:

• Inform URL op de USG naar de Cloud Key staat goed
• Force Provision
• Soft reboot
• Power cycle van de USG
• Forget en opnieuw adopten van de USG
• Gekeken naar events in de Legacy UI, maar hier staan geen issues m.b.t. provisioning etc in
• Reboot van de Cloud Key.

Ook dacht ik aan eventuele hardware issues op de USG (zoals versleten power adapter). Maar lijkt mij uiterst onwaarschijnlijk omdat ik met de oude controller deze issues niet heb.

Ik hoop dat jullie nog ideeën hebben over, ik kan het namelijk niet plaatsen omdat de config tussen de controllers gelijk zou moeten zijn (backup/restore) en het probleem zich alleen voordoet bij de Cloud Key en niet bij de Controller in Docker.

-Sander

 

[Eddie the Eagle]

Je hebt die KPN aanpassingen gedaan en combineert dat met een migratie van je controller. Dat is allemaal prima maar als het dan niet werkt wordt het zoeken naar een speld in een hooiberg. Al overwogen om opnieuw te beginnen ?

 

[Hofstede]

Je moet kijken in server.log of daar fouten gemeld worden tijdens het laden van de json file.

 

[Sandertjuhh]

Je hebt die KPN aanpassingen gedaan en combineert dat met een migratie van je controller. Dat is allemaal prima maar als het dan niet werkt wordt het zoeken naar een speld in een hooiberg. Al overwogen om opnieuw te beginnen ?

Wellicht niet helemaal duidelijk op te maken uit mijn opening, maar de KPN aanpassing heeft altijd (ruim een jaar) vlekkeloos gewerkt toen ik de controller in docker had draaien. In feite betreft het (zoals ik het zie) dus alleen een migratie van de controller. Of zie ik dit verkeerd en is er een feitelijk verschil tussen de Network Application op de Cloud Key en de versie die in Docker draaide?

Opnieuw beginnen is uiteraard een optie, maar wel mijn laatste optie gezien dat best wat werk omvat en ik hoopte dat je met een backup en restoren tussen controllers gewoon door kon werken.

Je moet kijken in server.log of daar fouten gemeld worden tijdens het laden van de json file.

Ik zie in de server.log geen zaken dat de json niet goed verwerkt kan worden. De enige fouten die ik tegen kom in de log zijn dat die caches (devicelist.json, lifecycle.json) niet bij kan werken en een firmware update kan checken omdat die geen internet heeft (logisch als de USG nog aan het opstarten is).

Ik zie geen fouten m.b.t. terugzetten van de backup in de server.log, wel dat de netjes de inform host update naar de cloud key en een re-provisioning scheduled.

Op de tijden dat de USG 'wegvalt' zie ik ook geen rare dingen in de log.


Ik vermoed dat de json gewoon valide is aangezien ik via de controller in Docker (altijd, zonder problemen) en via de Cloud Key (met regelmatige wegvallers) wel gewoon internet en TV heb.

Ook in de logs op de USG vind ik geen crashes o.i.d. die het gedrag dat ik ervaar kunnen verklaren.

Hopelijk zijn er nog meer plekken waar ik kan kijken (waarvan ik nog niet weet dat je daar moest kijken ;-)).

 

[Sandertjuhh]

Nog een aanvulling.

Ik heb de optie om volledig opnieuw te beginnen maar ter hand genomen, maar helaas zie ik daar exact hetzelfde gedrag. Exact iedere 15 minuten (op de seconde af) pusht de Cloud Key een commit naar de USG.

Dit is te zien in de logfile van het script dat in /etc/commit/post-hooks.d/ is geplaatst.

Wat zou dit gedrag kunnen verklaren?

 

[Hofstede]

De CloudKey pusht normaalgesproken alleen maar een commit naar de USG bij wijzigingen. Dus dit moet veroorzaakt worden door de modificaties die uitgevoerd worden.
Verder zie ik dat het script is gebouwd voor een oude controller versie en er ziijn geen updates voor de nieuwere versies. De JSON wijzigingen mogen niet botsen met de wijzigingen van de controller. Dus eigenlijk zou je eerst de USG moeten provisionen zonder json file en kijken of alle wijzigingen nog correct zijn.
Daarnaast is bij de CloudKey het onderliggende OS compleet over de kop gegaan dus dat kan ook de oorzaak zijn


Zijn deze modificaties eigenlijk nog wel nodig? Er zijn genoeg mensen die hun UDM / UDM Pro ook gebruiken met KPN FTTH zonder deze modificaties. Dus de controller instellingen zouden voldoende moeten zijn.

 

[Sandertjuhh]

In de GitHub repo wordt inderdaad een oudere controller versie vermeld, is dit de versie waarmee de ontwikkelaar het getest heeft. Echter zijn er op tweakers voldoende mensen die op de laatste controller versie geen problemen ervaren. Daarnaast heb ik met controller in Docker dezelfde versie draaien, waarbij ik dit probleem niet ervaar. De 'Network Application' software lijkt dus niet het probleem, tenzij er een verschil zit tussen de versie op de Cloud Key en de versie in Docker (terwijl de build hetzelfde is).

Uiteraard blijft dan het OS van de Cloud Key over als mogelijke boosdoener, zijn er logs om hier verdere analyse naar te doen?

Wat bedoel je precies met: "Dus eigenlijk zou je eerst de USG moeten provisionen zonder json file en kijken of alle wijzigingen nog correct zijn."

Als ik de USG provision zonder de config.gateway.json en de scripts werkt met IPTV niet. Internet kan ik wel configureren door de user/pass in te stellen voor de WAN PPPoE, maar ik wil ook graag IPTV. De EA build van de controller zou hier betere ondersteuning voor moeten bieden, maar ik lees op het UniFi forum ook nog de nodige uitdagingen m.b.t. IPTV dus ik wil graag nog even wachten.

Ik heb overigens geen UDM, maar een USG. Ik ga er vanuit dat er wel een redelijk verschil zit tussen de firmware opties tussen beide?

 

[Hofstede]

Maar je zou toch in elk geval het even zonder deze modificatie kunnen proberen? Ik begrijp dat je IPTV wilt maar als het zonder modificatie wel goed werkt weet je waar je moet zoeken. Aangezien het elk kwartier gebeurd is dat toch binnen een uur getest.

Edit: Wat me nog te binnen schiet. Welke rechten heeft de config.gateway.json file op de CloudKey?

Op de CloudKey moeten owner en group permissions op unifi:unifi staan anders wordt de file niet goed verwerkt.

 

[Sandertjuhh]

Ik heb de config.gateway.json even als de scripts volledig verwijderd en internet verbinding handmatig geconfigureerd.

Om inzicht te krijgen in of er nog steeds commits gedaan worden heb ik een eenvoudig scriptje in de /etc/commit/post-hooks.d/ folder geplaatst met excute rechten die simpelweg alleen iets logt.

Ook zonder config.gateway.json zie ik om het kwartier dat er een commit wordt gedaan. Daarmee denk ik dat de we configuratie van coolhva kunnen uitsluiten als boosdoener. Immers gebruik ik deze nu niet meer, waarmee het naar mijn idee echt een issue is met de Cloud Key. Maar ik kan niet achterhalen waarom de Cloud Key Network Application zich anders gedraagt dan een losse controller in docker die dezelfde Network versie heeft.

 

[Hofstede]

Ik zou de CloudKey ook een fabrieksreset geven, om zeker te weten dat hij "schoon" is.

En: Het zou zomaar kunnen dat juist het plaatsen van dat scriptje het uitvoeren van de commit triggert....

Enig zoekwerk op het internet geeft trouwens aan dat er meer mensen zijn bij wie de USG in combinatie met dit script in een provisioning loop raakt, echter een oorzaak is nooit gevonden.

 

[Sandertjuhh]

Zojuist de Cloud Key een factory reset geven en handmatig de zaken weer geconfigureerd. Dit keer geen scriptje geplaatst dat logt, maar in de portal blijven kijken. Ook nu zie ik (ongeveer) iedere 15 min dat de USG naar "Getting Ready" springt en na een tijd weer online is. Ik verwacht dat het nog steeds iedere 15 min gebeurd, maar ik heb nu natuurlijk geen exacte timestamps.

Dat het plaatsen van het script een commit triggert, kan ik mij voorstellen. Maar dan zou ik verwachten dat het eenmalig gebeurt en niet iedere 15 minuten, of zie ik dat verkeerd?

Daarnaast heb ik inderdaad gelezen dat sommige mensen een provisioning loop ervaren bij het gebruik van het script. Echter is de provisioning loop die mensen ervaren zijn naar mijn idee continu, waardoor het provisionen niet afgerond wordt. Dit is mi.i. iets anders dan dat de Cloud Key precies om de 15 min een commit pusht. Ook gebruik ik die scripts nu niet meer. Deze heb ik allemaal verwijderd en eerder (maar nu niet meer) een eigen custom log-scriptje toegevoegd.

 

[Hofstede]

De volgende stap zou zijn om de USG op de CloudKey te “vergeten” en een factory reset te geven. Vervolgens opnieuw adopteren. Er lijkt iets fout te gaan in de koppeling tussen controller en USG.

 

[Sandertjuhh]

Sorry dat ik even een tijdje niet gereageerd heb, door omstandigheden kon ik niet eerder verder met dit issue.

Ik heb besloten om alles helemaal vanaf scratch op te gaan bouwen. Ik heb alle relevante devices gereset;
- Factory reset van de CK, updates geïnstalleerd en daarna alleen een static IP ingesteld.
- Via command line een 'set-default' uitgevoerd op de USG.

Ik heb een minimale netwerk setup gemaakt:
- USG op de FTTH op WAN
- Switch op de LAN van de USG
- CK op de Switch
- Computer op de switch met static IP.
- Alle andere devices los gekoppeld

Vervolgens heb ik de USG geadopt in de CK, PPPoE2 instellingen ingesteld internet getest. Door middel van een ping naar Google DNS heb ik geconstateerd dat de verbinding meer dan een uur stabiel heeft gewerkt. Ook heb ik geen uitval of zichtbare provisioning in de CK gezien. Instellingen weer ongedaan gemaakt (terug gezet op AUTO).

Hierna ben ik de config van coolhva gaan toepassen. config.gateway.json geplaatst, scripts geplaatst en force provision uitgevoerd. Hierna heb ik de USG een reboot gegeven omdat IPTV nog niet goed werkte. Na de reboot werkte zowel internet als IPTV.

Wederom heb ik een ping laten lopen naar Google DNS en nog steeds geen uitval na 1,5 uur gezien. Vooralsnog lijkt internet en IPTV nu dus stabiel te werken zonder uitval. Ook de scripts van coolhva loggen niet meer dat er een commit gedaan wordt.

Tot slot heb ik alle andere netwerk devices weer aangesloten en ben ik WiFi en alle andere zaken (port forwarding, gasten netwerk etc) opnieuw gaan instellen.

So far, so good. Ondanks dat ik alle devices afzonder heb gereset leek dit toch niet voldoende. Alles tegelijk resetten en helemaal vanaf 0 beginnen leek de oplossing.

Bedankt voor het mee denken en alle tips!