Verbesserungen
- Deutlich verbessertes Channel Bandwidth Autotuning. Sie bekommen nun viel bessere Ergebnisse für alle Arten von Verbindungen, speziell aber Sat-Verbindungen. Hybrid Autotuning bekommt nun viel bessere Ergebnisse bei seinen anfänglichen Tests auf VPN-Tunnels, die idle sind. Überlastung auf dem Channel wird nun Max Bandwidth To WAN wesentlich weniger drastisch senken, d.h. Sie werden bessere Leistung auf WAN-Links sehen, die viel Packet Loss zeigen.
- VLANs on Node werden nun auf folgende Art unterstützt:
- In den LAN-Setting gibt es nun eine „Allow route-back“-Option. Wenn diese aktiviert wird, kann Traffic, der von einem VLAN kommt, zum selben oder einem unterschiedlichen VLAN zurückgeroutet werden – in anderen Worten, VLAN-Segmente können miteinander sprechen. Wenn die Funktion deaktiviert ist, wird Traffic vom LAN mit Ziel im LAN stattdessen gedroppt, sodass die VLANs in diesem Fall komplett separiert sind und nur mit dem VPN-Tunnel sprechen können.
- Auf dem Node gibt es die Option „Allow all VLANs to talk to tunnel“. Wenn diese aktiviert ist, können alle VLANs mit dem Tunnel sprechen; wenn sie deaktiviert ist, kann das nur VLAN0.
- In den WAN/VPN Routing-Einstellung auf dem Hub kann ebenso eine „allow route-back“-Option aktiviert werden. Wenn diese inaktiv ist, wird der Traffic, der vom Tunnel reinkommt und in denselben Tunnel gehen würde, gedroppt.
Mithilfe dieser Funktionen können Sie nun sowohl einen Router (Node) implementieren, der ein lokales VLAN hat, welches nicht mit dem VPN, dafür aber mit dem restlichen LAN sprechen kann, wie auch ein Setup erstellen, bei dem mehrere VLANs voneinander getrennt, aber in der Lage sein sollen, mit dem VPN zu sprechen (z.B. ein Firmennetzwerk und gleichzeitig ein öffentliches Besucher-WLAN).
Bitte beachten Sie, dass VLAN-Tags NICHT durch den Tunnel transportiert werden. Aus Sicht des Hubs kommt noch immer aller Traffic aus einem einzigen Tunnel mit einer einzigen Tunnel Segmentation ID. Wenn Sie die gerouteten Netzwerke separat behandeln müssen, müssen Sie ein VLAN auf dem Hub anlegen und den gesamten Traffic aus dem Tunnel zu einem Next-Hop in diesem VLAN routen, wo Sie dann den Traffic nach seinen Quell-IPs in mehrere verschiedene VLANs auftrennen.
- Auf allen Routern und Hubs findet sich nun ein integrierter HTTP Test-Traffic-Generator, der unter [ AdminDesk ] [ Logging & Maintenance ] Allow HTTP test downloads aktiviert werden kann.
Wenn er aktiviert ist, können HTTP Test-Downloads von diesem Router gemacht werden ohne irgendeine Form der Authentifizierung. Dies sollte nur aktiviert werden, solange Sie selbst testen, und für Produktivsysteme deaktiviert werden.
Wenn diese Funktion aktiviert ist, kann ein zufälliger Datenstrom von diesem Router runtergeladen werden unter folgender URL:
http://[your router IP]/exec?module=download&speed=Speed&size=Size
Speed wird angegeben in Bit/s, 1K bedeutet 1Kbit/s, 1M bedeutet 1 MBit/s, 1G bedeutet 1 Gbit/s. Der Speed-Parameter ist optional. Wenn dieser Parameter nicht gegeben ist, wird die maximal mögliche Link-Geschwindigkeit genutzt. Der maximale erlaubte Wert ist 1G.
Size ist die Größe der herunterzuladenden Datei in Bytes, 1K bedeutet 1 Kbyte, 1M bedeutet 1 MByte, 1G bedeutet 1 GByte. Der Größen-Parameter ist optional, wenn er nicht gegeben ist, werden 16 GByte angenommen, also der maximale erlaubte Wert.
- Viprinet-Router beinhalten nun eine Sicherheitsfunktion, die vor den meisten bekannten Arten der DNS Amplification-Attacke Schutz bietet – eine einzelne IP darf jetzt nur 2 BELIEBIGE Anfragen innerhalb von 60 Sekunden stellen. Wir empfehlen weiterhin, in Ihrer Kern-Firewall ausgefeiltere Methoden zum Schutz vor DNS-Amp-Attacken zu installieren.
- Das Download-Test-Tool in den LAN- und Modul-Settings wurde erweitert und um einiges verbessert. Es kann nun Test-Dateien von einem weltweiten von Viprinet zur Verfügung gestellten Content Delivery Network runterladen, welches automatisch den Edge-Server wählt, der Ihrer Position am nächsten ist, oder – sofern der Hub diese Firmware nutzt – vom Hub Traffic-Generator runtergeladen wird. Hiermit haben Sie ein Tool, mithilfe dessen Sie einfach Ihre Verbindung und Durchsatzprobleme mit WAN-Interfaces testen, und überprüfen können, wo der Flaschenhals bzgl. Ihrer Bandbreite ist. Benutzen Sie es!
- In den Channel Feineinstellungen kann nun eine Minimum-Link-Stabilität definiert werden, die ein Channel haben soll; dabei wird eine Warnung ins Logsystem verschickt, wenn die Link-Stabilität diesen Wert unterschreitet. Für stationäre Installationen sollte ein aktiver Link mehr als 90% Stabilität aufweisen, bei sich bewegenden Fahrzeugen hängt das von der typischen Netzabdeckung ab. Mithilfe dieser Einstellung können Sie leichter automatische Benachrichtigungen einstellen, wenn Verbindungsprobleme auftreten (z.B. wenn eine SIM-Karte ihr Traffic-Limit erreicht).
- Die Monitoring AP, die vom Viprinet Monitoring Tool verwendet wird, verursachte eine hohe CPU Load auf dem überwachten Router. Diese Load wurde gesenkt.
- Früher verwendete das Konfigurationssystem (sowohl Web-Interface als auch CLI) eine globale Sperre, die den Routing-Kern für mehrere Sekunden komplett lahmlegte – z.B. konnte der Router, während LAN-Settings zugewiesen wurden, keine Pakete routen. Diese globale Sperre wurde nun entfernt, und das Arbeiten im Web-Interface sollte nicht länger solche drastischen Effekte auf die Routing-Leistung von Viprinet-Routern haben.
Fehlerbehebungen
- Eine große Zahl an SNMP-Fehler wurde behoben. Am wichtigsten ist, dass Hotspare Hubs, die einen Hub übernehmen/ersetzen, nun korrekterweise normale volle Viprinet SNMP auf den übernommenen IPs berichten und Hotspare SNMP-Antworten auf der Hotspare IP ausgeben.
- SNMP ändert nicht länger OIDs auf anderen Tunnels, wenn ein Tunnel gelöscht wurde.
- SNMP VPNRouterCPULoad, VPNRouterCPUTemperature, VPNRouterSystemTemperature sind nun implementiert.
- Aufgrund einer Race Condition konnte Node Stacking manchmal in Failover-Situationen abstürzen. Auch der „Failed to open slot for stacking“-Fehler wurde behoben, sowie der interne Fehler 23239482394811Aa.
- Konfiguriertes Stacking zu deaktivieren konnte die falsche Fehlermeldung „[Stacking] This router does not have the stacking featured licensed. Can not start stacking!“ hervorrufen.
- Es konnte manchmal passieren, dass ein Node-Stacking Slave den internen DHCP-Server nicht beendete. Dadurch konnten zwei DHCPs auf dem LAN laufen, wodurch es zu Problemen kommen konnte.
- Der Firmware Online-Updater erforderte immer das DOPPELTE Klicken auf „check for updates now“, um ein aktuelles Ergebnis zu bekommen. Nun funktioniert schon der erste Klick.
- ADSL-Module hatten manchmal Probleme damit, die Modul-Info zu lesen zu lassen. Wir haben den Timeout für das Warten auf die Antwort vom Modem-Diagnostik-Bericht erhöht. Bitte benachrichtigen Sie den Viprinet-Support, wenn Sie beim Auslesen der Modul-Info eines ADSL-Moduls immer noch Fehlermeldungen bekommen.
- Alles im Bezug auf „Ethernet speed and auto-negotiation settings“ wurde überarbeitet. Es gab an allen Ecken und Enden Fehler: Das Ausschalten der Auto-Negotiation bei manchen Produkten und Ethernet-Modulen funktionierte nicht; das Ausschalten der Auto-Negotiation wurde beim nächsten Router-Reboot ignoriert; und zahlreiche andere. Alle wurden behoben, und wir haben sichergestellt, dass das manuelle Setzen von Ethernet Parametern nun bei allen Produkten und Modulen funktioniert, auch nach Reboots.
- Die „Reconnect“-Funktion von Fast/Gigabit Ethernet Modulen verursacht keinen PHY Reset / Neustart der Ethernet Auto-Negotiation mehr. Wenn Sie das möchten, müssen Sie das Modul jetzt resetten.
- VLANs und eine MTU von 1500 zu nutzen funktioniert bei Fast Ethernet Modulen nicht (mit Gigabit Ethernet Modulen hingegen schon). Nun funktioniert es bei beiden Modulen.
- Es konnte passieren, dass der Routing-Kern aufgrund von Rundungsfehlern in der Praxis oft mehr durchschnittliche Bandbreite auf einen Channel schickte als der „Maximum Allowed Bandwidth to WAN“-Wert erlaubte. Bei manchen Verbindungstypen konnte das dazu führen, dass der Link überlastet wurde und die Latenz trotz perfekter Autotuning-Resultate stieg. Diese Rundungsfehler wurden behoben.
- Seit der letzten Stable Firmware-Version werden Änderungen bei LAN-Einstellungen inkl. LAN Aliases übernommen noch bevor der Knopf „Apply Settings“ gedrückt wird. Das konnte für einen unsauberen Zustand sorgen, wenn man gerade dabei war, einen LAN Alias anzulegen.
- Wenn „Allow remote service connections“ eingeschaltet war und dann ausgeschaltet wurde, konnte es passieren, dass Remote Service-Verbindungen weiterhin möglich waren, bis der Router rebootet wurde. Das Ausschalten dieser Funktion hat nun direkt den erwarteten Effekt.
- Das Download Test-Tool konnte oft abstürzen „due to high CPU load“, selbst wenn die CPU Load gar nicht hoch war.