Folgende Netzwerkfehler treten unter Solaris 10 auf.
Unter hoher Belastung erzeugt der e1000g-Treiber u. U. beschädigte LSO-Pakete, die den Ethernet-Chip blockieren und zurücksetzen.
Problemumgehung: Deaktivieren Sie LSO, indem Sie in der Datei e1000g.conf die folgende Zeile hinzufügen:
lso_enable=0,0,0,0,0,0,0,0; |
Stellen Sie sicher, dass '0's sich in der gleichen Zeile wie die e1000g-Schnittstellennummern befinden.
Die DMAs des Intel 82571-Chips übertragen möglicherweise falsche Daten, aber gültigen CRC auf dem Netzwerk und blockieren die Antwort. Da das Gerät keine Antwort erhält, wird es blockiert und zurückgesetzt.
Problemumgehung: Deaktivieren Sie LSO, indem Sie in der Datei e1000g.conf die folgende Zeile hinzufügen:
lso_enable=0,0,0,0,0,0,0,0; |
Stellen Sie sicher, dass '0's sich in der gleichen Zeile wie die e1000g-Schnittstellennummern befinden.
Verstärkte Einschränkungen bei der Interzone-Kommunikation für Systeme mit der Konfiguration Solaris Trusted Extensions können eventuell nicht kompatible Drittanbieteranwendungen behindern und Fehler verursachen.
Problemumgehung: Wählen Sie eine der folgenden Lösungen:
Problemumgehung 1: Verändern Sie vorübergehend die Sicherheitseinstellungen. Kommentieren Sie die folgenden Zeilen in der Datei /lib/svc/method/svc-labeld:
/usr/sbin/ndd -set /dev/ip \ ip_restrict_interzone_loopback 1 |
Geben Sie folgenden Befehl ein:
/usr/sbin/ndd -set /dev/ip ip_restrict_interzone_loopback 0 |
Diese Änderung gibt Ihnen zwar die Möglichkeit, eventuelle Konfigurations- oder Programmierungsprobleme der Anwendung zu behandeln, wird jedoch nicht als dauerhafte Lösung empfohlen.
Problemumgehung 2: Ändern Sie die Anwendung oder die Konfiguration entsprechend den Programmierungs- und Konfigurationsanweisungen für ein Solaris-Betriebssystem, das mit Trusted Extensions konfiguriert wurde. Weitere Informationen erhalten Sie in Kapitel 5, Interprocess Communications in Solaris Trusted Extensions Developer’s Guide.
Wenn die Korrektur der Anwendung oder Konfiguration nicht möglich ist, wenden Sie sich bitte an einen Servicevertreter von Sun.
Nach dem Neustart des XSCF-Service-Prozessors auf OPL-Systemen gehen die IPsec-Verbindungen verloren. Daraufhin wird für den XSCF-Service-Prozessor die folgende Fehlermeldung angezeigt:
XSCF> showdevices -d 0 Can't get device information from DomainID 0. |
Die folgende Meldung wird in der Datei /var/adm/messages auf der Domain angezeigt:
Apr 7 11:19:20 domain-0 sckmd: [ID 205163 daemon.error] PF_KEY error: type=ADD, errno=17: File exists, diagnostic code=0: No diagnostic |
Dieses Problem tritt auf, weil die vorhandenen Security Associations (SAs) auf der Domain nicht ordnungsgemäß gelöscht wurden, und deshalb die neuen SAs nicht hinzugefügt werden können.
Problemumgehung 1: Führen Sie den Neustart des XSCF-Service-Prozessors zweimal durch. Beim ersten Neustart wird eine Hälfte der SAs gelöscht, beim zweiten die andere Hälfte. Beim zweiten Mal ist das Hinzufügen erfolgreich, und die IPsec-Kommunikation wird wiederhergestellt.
Problemumgehung 2: Löschen Sie die IPsec-SAs zweimal auf jeder Domain, bevor Sie den Dienstprozessor neu starten.
Wenn Sie IPsec auf dem System für nichts anderes verwenden, wird ipseckey flush alle SAs anzeigen. Wenn Sie IPsec auch für andere Zwecke verwenden, müssen Sie folgende Schritte ausführen, um alle SAs anzuzeigen:
IP-Adressen ermitteln:
# /usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp Domain Address: 192.168.224.2 SP Address: 192.168.224.1 |
Löschen Sie die SPIs zweimal mithilfe der Dienstprogramme ipseckey und prtdscp:
# ipseckey delete ah spi 0xff00 dst `/usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp -s` # ipseckey delete ah spi 0xff00 dst `/usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp -s` # ipseckey delete ah spi 0xff dst `/usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp -d` # ipseckey delete ah spi 0xff dst `/usr/platform/SUNW,SPARC-Enterprise/sbin/prtdscp -d` |
Beim Neustart des Dienstprozessors werden die Schlüssel korrekt hinzugefügt.
Das Broadcom NetXtreme II 5709-Chipset (BCM5709) wird in Solaris 10 10/09 nicht unterstützt.
Problemumgehung: Laden Sie den bnx-Treiber von der Website http://www.broadcom.com/support/ethernet_nic/downloaddrivers.php herunter.
Nach dem Installieren des heruntergeladenen Treibers kann es sein, dass bei vorhandenen Chipsets Leistungseinbußen auftreten.
Bei Verwendung von RDMA (Remote Direct Memory Access) kann es zu Verbindungsfehlern zwischen einem NFS-Server und -Client kommen. Aufgrund dieser Fehler stehen nicht ausreichend Pufferpoolressourcen zur Verfügung und es kommt zu einem Systemabsturz. Daraufhin wird die folgende Fehlermeldung angezeigt:
rpcib: WARNING: rib_rbuf_alloc: No free buffers! |
Abhilfemaßnahme: Wählen Sie eine der folgenden Lösungen:
Aktivieren Sie TCP auf dem NFS-Server. Ändern Sie die Datei /etc/default/nfs so, dass der Eintrag (NFSD_PROTOCOL=tcp) lautet.
Hängen Sie das NFS-Dateisystem vom Client aus mit der Einhängeoption proto=tcp ein.
Weitere Informationen finden Sie auf den Manpages mount_nfs(1M) und nfs(4).
Wenn ein iSCSI-Zielgerät oder -Array als Teil seiner Antwort auf send target mehrere IP-Adressen zurückliefert, berücksichtigt das aufrufende Programm nur die letzte Adresse in der Liste und nicht die erste Adresse, wie es vorher üblich war. Wenn also die letzte IP-Adresse falsch oder ungültig ist, schlägt die Verbindung zum betreffenden Zielgerät fehl.
Problemumgehung: Die verschiedenen Gruppen-Tags für Zielportale (TPGT) müssen für jeden einzelnen Eintrag in seiner Antwort auf send target zurückgeliefert werden. Das aufrufende Programm versucht, eine Verbindung zu allen IP-Adressen herzustellen, sodass die verbindungsaufnahme erfolgreich abgeschlossen werden kann.
Die System Domain of Interpretation (DOI) ist nicht konfigurierbar. Wenn mit SMC eine neue Trusted Network Template erstellt wird, setzt SMC die DOI auf 0 und Solaris Trusted Extensions funktioniert deswegen nicht ordnungsgemäß. Es werden verschiedene Fehlermeldungen angezeigt. Es werden verschiedene Fehlermeldungen angezeigt.
Problemumgehung: Setzen Sie die DOI mit SMC auf 1.
In dieser Solaris-Version ist die IP-Weiterleitung standardmäßig deaktiviert. Diese Einstellung gilt sowohl für IPv4 als auch für IPv6, unabhängig von anderen Systemkonfigurationen. Systeme mit mehreren IP-Schnittstellen, die vorher standardmäßig IP-Pakete weitergeleitet haben, verfügen nicht mehr über diese automatische Funktion. Um die IP-Weiterleitung in mehrfach vernetzten Systemen (multihomed) zu aktivieren, müssen Administratoren manuell zusätzliche Konfigurationsschritte durchführen.
Problemumgehung: Der Befehl routeadm aktiviert die IP-Weiterleitung. Die Konfigurationsänderungen, die das Ergebnis der Verwendung von routeadm sind, bleiben auch nach dem Systemneustart bestehen.
Um IPv4-Weiterleitung zu aktivieren, geben Sie routeadm -e ipv4-forwarding ein.
Um IPv6-Weiterleitung zu aktivieren, geben Sie routeadm -e ipv6-forwarding ein.
Um die aktivierte IP-Weiterleitungskonfiguration auf das aktuell ausgeführte System anzuwenden, geben Sie routeadm -u ein.
Weitere Informationen zur IP-Weiterleitung finden Sie in der Manpage routeadm(1M).
Eine Zone kann so konfiguriert sein, dass ihre IP-Adresse Teil einer IP-Netzwerk-Multipathing-Gruppe (IPMP) wird. Der Konfigurationsprozess ist unter So erweitern Sie die Funktionen des IP Network Multipathing auf nicht-globale Shared IP-Zonen in Systemverwaltungshandbuch: Solaris Container – Ressourcenverwaltung und Solaris Zones dokumentiert .
Wenn alle Netzwerkschnittstellen in der IPMP-Gruppe fehlschlagen, bootet eine Zone nicht, wenn sie über eine IP verfügt, die Teil dieser IPMP-Gruppe ist.
Das folgende Beispiel illustriert das Ergebnis, wenn Sie versuchen, die Zone zu booten.
# zoneadm -z my-zone boot zoneadm: zone 'my-zone': bge0:1: could not set default interface for multicast: Invalid argument zoneadm: zone 'my-zone': call to zoneadmd failed |
Problemumgehung: Reparieren Sie mindestens eine Netzwerkschnittstelle in der Gruppe.