Unifi USG ipv6 bei PPPOE Verbindung zu T-Online (Update 12.01.2019)

Probleme

  1. Wird das VLAN 7 für die WAN Verbindung in der USG verwendet funktioniert nach einem Neustart kein ipv6 mehr
  2. Die CPU Auslastung der USG geht nach einiger Zeit auf 50-100%.
  3. Hat man keinen Business Anschluss, also auch keinen festen ipv6 Präfix, so verlieren die Clients die Verbindung wenn die PPPOE Verbindung vom Router neu aufgebaut wird.

Ursachen / Lösungen

Vorab zwei Informationen: 

Für alle, die kein VI und copy and paste mögen, gibt es am Ende des Artikels ein Paket zum Download, dass die entsprechenden Dateien enthält!

Die hier gezeigten Interface Bezeichungen gelten für eine USG3, bei Verwendung von VLAN 7 in der USG.
Wird ein anders Gateway oder kein VLAN 7 verwendet ändern sich die Interface Bezeichner eth0 bzw. pppoe2. Dies muss bei allen Modifikationen beachtet und eventuell angepasst werden!

Das erste Problem wird durch einen Fehler im Unifi Controller verursacht. Dieser erzeugt ein zweites DHCP-PD Tag auf dem Wan-Interface eth0 zusätzlich zu dem Tag auf dem PPPOE2 Interface.
Dieser Fehler ist erstmals im „UniFi Network Controller 5.10.5 Unstable“ behoben.
Wird diese Version noch nicht eingesetzt, kann der Fehler umgangen werden wenn:
a) sich ein vorgeschaltes Modem (hier ein Vigor 130) um das VLAN 7 kümmert
oder
b) der Fehlerhafte Eintrag durch Scripting entfernt wird. (hier hatte ich das beschrieben)
Dieser Workaround ist eine Bastelei mit einigen Nebenwirkungen, so dass ich darauf heute verzichten würde.

Zweite Problem:
per „top“ lässt sich schnell herausfinden, dass „dhcpv6-pd-respo“ Prozess für die hohe CPU Auslastung verantwortlich ist.
Dieses verhalten kann sich durch das Tag „PREFIX-ONLY“ vermeiden lassen.


Wir erzeugen/erweitern eine config.gateway.json auf dem Controller um das Prefix-Only Tag an das PPPOE Interface zu schreiben.
Informationen zur Erstellung / Platzierung gibt es hier.
Die config.gateway.json ist im Backup des Controllers enthalten, so dass diese grundsätzlich updatefest sein sollte

{
    "interfaces":{
        "ethernet":{
            "eth0":{
                "vif":{
                    "7":{
                        "pppoe":{
                            "2":{
                                "dhcpv6-pd":{
                                    "prefix-only":"''"
                                }
                            }
                        }
                    }
                }
            }
        }
    }
}

Drittes Problem:
Dies ist dem dynamischen Prefix geschuldet. Einerseits scheint die USG die alte IPV6 Adresse nicht von seinen internen LAN Interfaces zu entfernen, andererseits werden die alten IPV6 Adressen an den Clients nicht verworfen, so dass die Clients diese erst „aufbrauchen“.
Da diese Pakete vom Router nicht mehr weitergeleitet werden stirbt die IPV6 Verbindung der Clients bis diese neu gestartet werden (Windows) oder die WLAN Verbindung einmal getrennt wurde (Android).

Der Ansatz hier basiert auf den Erkenntnissen in diesem Beitrag im Edge-Router Forum.

Hierzu sind einige Modifikationen auf dem USG notwendig:

Wir erzeugen einer remove_invalid_ipv6.sh
innerhalb des Ordners /config/scripts/ppp/ipv6-down.d

#!/bin/sh
#deletes the old ipv6 connection prefix after disconnect 
#restarts radvd daemon to "announce" a discard of the old prefix to the clients

echo "/config/scripts/ppp/ipv6-down.d/remove_invalid_ipv6.sh:" >> /tmp/ipv6.log

/etc/init.d/radvd stop

/sbin/ifconfig | grep 'eth1' | awk '{print $1}' | while read -r interface ; do 

  
    /sbin/ifconfig $interface | grep -ivE ' fe80' | grep -ivE ' fd' | grep -ivE ' 2001' | grep -ivE ' fd' | grep 'inet6' | awk '{print $3}' | while read -r ipv6addr ; do
        echo "removing $ipv6addr from $interface" 
        /sbin/ip -6 addr del $ipv6addr dev $interface  >> /tmp/ipv6.log

    done 
done

/etc/init.d/radvd start

Die Datei machen wir noch ausführbar
chmod +x /config/scripts/ppp/ipv6-down.d/remove_invalid_ipv6.sh

*Alle Dateien im /config Ordner sind updatefest, die Änderung überlebt also auch ein Firmwareupdate des USG

Wir müssen die Datei /opt/vyatta/sbin/vyatta_gen_radvd.pl editieren.
Hier suchen wir die folgende Passage (ab Zeile 243):

    # Write parameters out to config file
    print $FD_WR "    prefix $prefix {\n";
    foreach my $key (keys %prefix_param_hash) {
        print $FD_WR "        $key $prefix_param_hash{$key};\n";
    }
    print $FD_WR "    };\n";

und ergänzen Sie um die zwei abgebildeten Zeilen

    # Write parameters out to config file
    print $FD_WR "    prefix $prefix {\n";
    foreach my $key (keys %prefix_param_hash) {
        print $FD_WR "        $key $prefix_param_hash{$key};\n";
    }
    print $FD_WR "        DeprecatePrefix on;\n";
    print $FD_WR "        DecrementLifetimes on;\n";
    print $FD_WR "    };\n";

Diese Modifikation wäre nicht updatefest!
Ich habe dies gelöst, indem ich die abgeänderte vyatta_gen_radvd.pl
in das zu erstellende Verzeichnis /config/_install kopiert habe und sie von dort beim Reboot zurück kopieren lasse.
Im Falle eines Firmwareupdates muss der USG schlimmstenfalls einmalig weiteres mal neugestartet werden bis die Anpassung wieder greift.

mkdir /config/_install
sudo cp /opt/vyatta/sbin/vyatta_gen_radvd.pl /config/_install/vyatta_gen_radvd.pl  

Anschließend habe ich die Datei
/config/scripts/post-config.d/install_anpassungen.sh
mit folgendem Inhalt erstellt:

#!/bin/vbash
sudo cp /config/_install/vyatta_gen_radvd.pl  /opt/vyatta/sbin/vyatta_gen_radvd.pl
sudo chmod +x /opt/vyatta/sbin/vyatta_gen_radvd.pl

Und diese ausführbar gemacht
chmod +x /config/scripts/post-config.d/install_anpassungen.sh

Es gibt alle Modifikationen von oben auch als fertiges Archiv zum Download.

Die Dateien könnt ihr z.B. per Winscp auf euren USG und euren Controller verteilen. Anschließend muss nur noch:

  • die kopierten Skripte auf der USG per SSH startfähig gemacht werden
chmod +x /config/scripts/post-config.d/install_anpassungen.sh 
chmod +x /config/scripts/ppp/ipv6-down.d/remove_invalid_ipv6.sh  
  • Der USG einmal manuell provisioniert werden
  • Der USG einmal (eventuell zwei mal) neu gestartet werden

Author: Stefan