XENMASTER
Da es sich bei der Kontrolldomäne (Dom0) eines XenServers um ein Linux Betriebssystem handelt, stehen uns hier auch diverse native Kommandos zur Diagnose zur Verfügung. In diesem Artikel möchte ich auf die Möglichkeiten die uns das Linux der Dom0 bietet einmal etwas genauer eingehen.
Alle auftretenden Netzwerkprobleme basieren in der Regel auf einer von zwei möglichen Formen.
Ich gehe mal davon aus, dass die physischen Probleme bereits ausgeschlossen sind. Also Themen wie Kabelfehler und/oder -längen, fehlerhafte oder einfach ausgeschaltete Server, Router, Switches beachtet wurden. In diesem Artikel beschränke ich mich nur mit den logischen Problemen die wir an der Konsole lösen können. Um hier gleich tiefer einzusteigen, beschreibe ich erstmal das Konzept wie der XenServer bzw. die Kontrolldomäne mit Netzwerken umgeht.
Ein sehr gutes Whitepaper wurde von Citrix mit der Nummer CTX117915 veröffentlicht und beschreibt die grundlegenden Konzepte. Hier nur noch mal ein stark vereinfachtes Modell.
Das Konzept ist dabei sehr einfach. Für jedes physische Interface bildet die Dom0 ein virtuelles Netzwerk über einen virtuellen Switch. An diesen virtuellen Switch werden die virtuellen Netzwerk-Interfaces (VIF) der virtuellen Maschinen an das physische Interface gebunden. Jedes virtuelle Netzwerk-Interface kann dabei immer nur an einen virtuellen Switch gebunden werden (wie im richtigen Leben). Jedoch können mehrere VIF's erzeugt werden, die dann jeweils auch an verschiedene virtuelle Switche gebunden werden können.
Über das XenCenter kann man dieses Konzept sehr schön sehen.
In diesem Beispiel sehen wir zwei physikalische Interfaces die mittels Bonding (Teaming) miteinander verbunden sind. Für den XenServer stellt sich dieser Bond dann als einziges physisches Netzwerk-Interface dar (zu sehen an den identischen MAC Adressen). Schauen wir uns im XenCenter dann den Reiter Network an, sehen wir das zuvor beschriebene Konzept.
Der XenServer kennt in diesem Beispiel zwei Netzwerke (also zwei virtuelle Switche), einen mit der Bezeichnung Internal sowie einen weiteren mit der Bezeichnung Bond 0+1. Bei dem Netzwerk mit der Bezeichnung „Internal“ handelt es sich um ein Netzwerk, dass nur zur Kommunikation zwischen den virtuellen Maschinen benutzt wird und nicht an ein physisches externes Interface gebunden ist. Im oberen Bild zu sehen, dass weder eine NIC noch eine externe MAC Adresse zugeordnet ist. Für die Kommunikation mit der externen Welt ist nur das Netzwerk „Bond 0+1“ zuständig. Hier finden wir auch die MAC Adresse unserer physischen NICs wieder.
Allerdings lässt sich im XenCenter nicht viel an Fehlersuche betreiben. Auch die xsconsole hat eher informativen Charakter.
So zeigt uns die xsconsole im Unterschied zum XenCenter die echten MAC Adressen der einzelnen NIC's an. Das XenCenter zeigt nur die MAC Adresse der ersten NIC bzw. die des Bonds für alle NICs an.
Wenn wir aber Netzwerkprobleme finden oder im Idealfall sogar lösen wollen, kommen wir am CLI nicht vorbei. Und hier kommen wir dann auch gleich zu einem der simpelsten aber sehr interessanten Kommandos auf der Konsole.
[root@xenserver ~]# ifconfig
Das Kommando ifconfig listet uns alle aktiven Netzwerkschnittstellen auf. Will man auch die Schnittstellen sehen, die keinen Link haben oder aus anderen Gründen abgeschaltet wurden hilft uns der Parameter -a
[root@xenserver ~]# ifconfig -a
Die Ausgabe von ifconfig zeigt uns eine sehr ausführliche Übersicht unserer Netzwerk-Interfaces. Und anders als beim XenCenter sehen wir auch hier bereits die virtuellen Switche.
[root@xenserver ~]# ifconfig
bond0 Link encap:Ethernet HWaddr 1C:C1:DE:E8:17:D8
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:388373169 errors:0 dropped:0 overruns:0 frame:0
TX packets:10953551 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:585488711 (558.3 MiB) TX bytes:35808780 (34.1 MiB)
eth0 Link encap:Ethernet HWaddr 1C:C1:DE:E8:17:D8
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:199018927 errors:0 dropped:0 overruns:0 frame:0
TX packets:9243457 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1332701647 (1.2 GiB) TX bytes:3590146831 (3.3 GiB)
Interrupt:22 Memory:fa000000-fa012800
eth1 Link encap:Ethernet HWaddr 1C:C1:DE:E8:17:D8
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:189354242 errors:0 dropped:0 overruns:0 frame:0
TX packets:1710094 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3547754360 (3.3 GiB) TX bytes:740629245 (706.3 MiB)
Interrupt:23 Memory:f8000000-f8012800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:5414541 errors:0 dropped:0 overruns:0 frame:0
TX packets:5414541 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2550531318 (2.3 GiB) TX bytes:2550531318 (2.3 GiB)
xapi1 Link encap:Ethernet HWaddr 1C:C1:DE:E8:17:D8
inet addr:10.217.20.173 Bcast:10.217.20.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:197417303 errors:0 dropped:0 overruns:0 frame:0
TX packets:7331528 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3939962866 (3.6 GiB) TX bytes:3929227446 (3.6 GiB)
[root@xenserver ~]#
Die Ausgabe zeigt uns das virtuelle Bonding Interface (bond0) bestehend aus den NICs eth0 sowie eth1 und das Loopback Interface (lo). Am Ende der Ausgabe sehen wir noch den externen virtuellen Switch, mit der Bezeichnung xapi1. Was die Ausgabe uns an Informationen liefert, zeigt das nachfolgende Bild.
Wer noch genau wissen möchte welches Interface zu einem virtuellen Switch (im XenServer bridge) gehört, kann das folgenden Kommando nutzen:
[root@xenserver ~]# brctl show
Die Ausgabe von brctl zeigt uns die entsprechenden Interfaces an.
bridge name bridge id STP enabled interfaces xapi1 8000.1cc1dee817d8 no bond0
Für einen ersten Überblick eignet sich das alles ganz gut. Wenn man aber etwas genauere Informationen benötigt eignet sich das folgende Kommando etwas besser.
[root@xenserver ~]# ethtool <interface>
ethtool ist ein nützliches Werkzeug mit vielen Optionen. Ich beschränke mich hier mal auf die beiden gebräuchlichsten.
[root@xenserver ~]# ethtool eth0
Gibt uns einige Basisinformationen über das gewählte Interface aus. Zu den interessantesten gehören hier natürlich Speed und Duplex Informationen.
[root@xenserver ~]# ethtool eth0
Settings for eth0:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: FIBRE
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Link detected: yes
Ein interessanter Schalter ist -S der uns die Statistik des gewählten Interfaces anzeigt. Da uns zur Fehlersuche nur Fehler und Kollisionen interessieren, Filtern wir die Augabe gleich mit egrep.
[root@xenserver ~]# ethtool -S eth0 | egrep '(_errors|_collisions)'
Die Ausgabe beschränkt sich hierbei dann nur auf die Fehler-Statistik.
[root@xenserver ~]# ethtool -S eth0 | egrep '(_errors|_collisions)'
tx_mac_errors: 0
tx_carrier_errors: 0
rx_crc_errors: 0
rx_align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
tx_excess_collisions: 0
tx_late_collisions: 0
tx_total_collisions: 0
Das ethtool funktioniert nur bei physischen Interfaces. Ein Versuch auf bond0 oder xapi1 liefert kein Ergebnis.
Für eine Statistik kann ebenso das folgende Kommando benutzt werden:
[root@xenserver ~]# netstat -i
netstat hat den Vorteil, dass es uns die Statistiken aller Interfaces (auch bond0 und xapi1) in einer schönen Übersicht liefert.
[root@xenserver ~]# netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bond0 1500 0 306077 0 0 0 10905 0 0 0 BMmRU eth0 1500 0 156652 0 0 0 10905 0 0 0 BMsRU eth1 1500 0 149425 0 0 0 0 0 0 0 BMsRU lo 16436 0 13451 0 0 0 13451 0 0 0 LRU xapi1 1500 0 156296 0 0 0 9307 0 0 0 BMRU
Wer jetzt noch Wissen möchte, wie die einzelnen Interfaces konfiguriert sind kann einen Blick in das Verzeichnis /etc/sysconfig/network-scripts/ werfen. Hier sind die Konfigurationsdateien der einzelnen Interfaces zu finden. Ändern sollte man hier allerdings nur dann etwas, wenn man genau weiß was man da macht. Denn viele dieser Konfigurationsdateien werden automatisch erzeugt. Dies wird deutlich wenn man sich eine der Dateien mit dem Befehl cat anschaut.
[root@xenserver ~]# cat ifcfg-xenbr0 # DON NOT EDIT: This file (ifcfg-xenbr0) was autogenerated by interface-reconfigure ...
Hier sagt einem gleich die erste Zeile ⇒ Finger weg!
Aber auch das Xen-eigene Interface zur API zeigt uns einige nützliche Informationen zu den NIC's an. Ein wichtiges Kommando ist hier pif-list. Die Ausgabe ist sehr spartanisch, wenn man jedoch ein params=all dran hängt wird die Ausgabe schon interessanter.
Leider werden bei dieser Ausgabe nicht alle Schlüssel mit Werten gefüllt. Hier macht es mehr Sinn das Kommando pif-param-list uuid=<uuid vom interface> zu benutzen. Dann sind auch die Werte io_read_kbs und io_write_kbs mit aktuellen Werten versehen.
[root@xenserver ~]# xe pif-param-list uuid=`xe pif-list device=eth0 --minimal`
uuid ( RO) : e54e581b-57f2-d308-1c37-5b45013b1da3
device ( RO): eth0
MAC ( RO): 1c:c1:de:ed:dd:f0
physical ( RO): true
currently-attached ( RO): true
MTU ( RO): 1500
VLAN ( RO): -1
bond-master-of ( RO):
bond-slave-of ( RO): <not in database>
management ( RO): true
network-uuid ( RO): cdd2dd2d-ffcb-ccec-4f46-c0c748ed4940
network-name-label ( RO): Pool-wide network associated with eth0
host-uuid ( RO): eb48197f-6f40-4ea7-9ed1-d8da58028ffb
host-name-label ( RO): xenserver
IP-configuration-mode ( RO): Static
IP ( RO): 10.217.20.171
netmask ( RO): 255.255.255.0
gateway ( RO): 10.217.20.250
DNS ( RO): 10.9.12.21
io_read_kbs ( RO): 2.593
io_write_kbs ( RO): 0.280
carrier ( RO): true
vendor-id ( RO): 14e4
vendor-name ( RO): Broadcom Corporation
device-id ( RO): 1650
device-name ( RO): NetXtreme II BCM57711E 10-Gigabit PCIe
speed ( RO): 1000 Mbit/s
duplex ( RO): full
disallow-unplug ( RW): false
pci-bus-path ( RO): 0000:02:00.0
other-config (MRW):
Wer sich über den Syntax des Kommandos etwas wundert, wird wahrscheinlich ein Windows Benutzer sein. Ich bin lediglich zu faul mir vorher die uuid der Netzwerkkarte mit pif-list zu holen und sie dann per copy & paste einzufügen. Deshalb nutze ich die kleinen Tricks der Shell und mache alles in einem Kommando. Wer viel innerhalb der Shell arbeiten muss/möchte, sollte sich diese Tricks mal in einem Linux Kurs aneignen. In diesem Artikel gehe ich darauf jetzt nicht näher ein.
Wer jetzt die IP Konfiguration eines Interfaces ändern will, kennt bereits die Konfigurationsdateien mit der Bezeichnung ifcfg-… und weiß auch, dass hier nichts geändert werden sollte. Für Änderungen, wie auch schon die Warnung in der ersten Zeile der Konfigurationsdateien beschreibt, ist ein interface-reconfigure zuständig. Und wie der Zufall es will haben wir auch ein xe pif-reconfigure-ip Kommando. Gibt man dieses Kommando in der Shell ein und drückt zweimal die TAB Taste, sieht man gleich welche Parameter erwartet werden.
[root@xenserver ~]# xe pif-reconfigure-ip DNS= gateway= IP= mode= netmask= uuid=
Wie bereits eingehend beschrieben, betreffen die Kommandos pif-… die physischen Interfaces. Zusätzlich bietet uns die API auch noch entsprechende Kommandos für die virtuellen Interfaces (vif-…), die virtuellen Switches/Bridges (network-…) sowie für die Bonds (bond-…). Bei jedem dieser Kommandos listet die doppelte TAB Taste alle möglichen Kommandos auf. Ein …-list params=all ist bei allen Kommandos erstmal ein guter Anfang.
Für die weitere Diagnose von Netzwerkproblemen helfen uns die auf allen Betriebssystemen vorhandenen Kommandos ping, traceroute, nslookup und telnet (bei Linux Systemen helfen auch noch wget oder curl zur Diagnose auf TCP Ebene) weiter. Auf die Anwendung dieser simplen Tools gehe ich jetzt nicht weiter ein, da sie wirklich jedem bekannt sein sollten.
Wenn man jetzt auf die Packet-Ebene herunter möchte, bietet sich das Tool tcpdump an. tcpdump ist, wie der Name schon sagt, ein Packet-Sniffer. Wer allerdings in diesem Artikel eine Erklärung erwartet wie eine Paket Analyse durchgeführt wird, ist auf dem Holzweg (für die englischen Kollegen “you are on the wood way“). Allein die Beschreibung der Parameter von tcpdump füllt Bücher und die Analyse von Dumps ist nicht „mal schnell“ erklärt. Einige kleine Hinweise möchte ich aber dennoch erwähnen.
Ruft man tcpdump ohne Parameter auf, werden sämtliche Pakete aller NIC's auf dem Bildschirm ausgegeben. Sieht cool aus, hilft uns aber kein Stück weiter. Wir wollen hier unter anderem ein wenig filtern und auch den Dump in eine Datei zur späteren Analyse sichern. Also hier die wichtigsten Paramter:
| Parameter | Beispiel | Wirkung |
|---|---|---|
| -c | tcpdump -c 10 | Hört mit dem Dump nach -c count Paketen auf. |
| -i | tcpdump -i eth1 | Gibt das Interface an. Ohne -i werden alle Interfaces benutzt. Bei -i ohne Parameter wird das niedrigste Interface (z.B. eth0) benutzt. |
| -w | tcpdump -w file.dump | Erzeugt einen speziellen Dump File, der mit grafischen Tools wie z.B. Wireshark ausgewertet werden kann. |
| -C | tcpdump -C 1024 | Schreibt in das mit -w definierte File bis zur angegebenen Größe und fängt danach einen neuen nummerierten File an. |
| -t | tcpdump -t | Unterdrückt den Timestamp am Anfang jeder Zeile. |
Hier noch ein kleines Beispiel:
tcpdump -i eth1 -w /tmp/packets.dump -t host 192.168.1.102 and tcp port 80
Dieses Kommando schreibt alle Pakete von Interface eth1 die auf TCP-Port 80 an den Host 192.168.1.102 gehen in die Datei /tmp/packets.dump und unterdrückt den Timestamp. Simpel oder?
Spaß beiseite, Netzwerkanalyse auf Paket-Ebene ist schon eine anspruchsvolle Aufgabe und benötigt mehr Informationen als ich in diesem Artikel liefern kann. Wer sich damit beschäftigen möchte, findet im Web reichlich Informationen zu diesem Thema.