orm@doc-tcpip.org

Erstellt: April 1999 - Letzte Modifikation: September 2007

[ Main | Local ]


Netstat unter AIX

In Beispielen

Das netstat-Kommando

Alles hier gesagte bezieht sich auf die Implementation von netstat, die mit AIX kommt. Netstat ist je nach System stark unterschiedlich, was die Schalter und Ausgaben betrifft. Allerdings sind die Unterschiede eher optischer Natur, also wenn man begriffen hat, wie es funktioniert und was eine bestimmte Rückgabe bedeutet, dann ist es kein Problem, sich auch mit einem andern Netstat zurechtzufinden. Gibt es eine bestimmte Funktion auf einem bestimmten OS nicht, so muß man woanders suchen (z.B. Routing-Information über das route-Kommando zeigen etc.). Netstat läßt sich auch über das Netz, remote, durchführen. Das ist aber in fast allen Fällen per default abgeschaltet, einige Implementationen bringen diese Fähigkeit garnicht mehr mit.

Eine weitere Besonderheit von AIX ist, das es noch Übertragungsprotokoll spezifische netstat-Varianten gibt (tokstat, entstat, fddistat). Diese sollte man bei genaueren Analysen vorziehen, weil sie besser auszuwerten sind.

Was kann (AIX) Netstat?

Mit dem netstat-Kommando erhält man Informationen über die Interfaces der Maschine, die aktuellen Routen sowie deren Typ, die offenen Ports und aktiven Sockets sowie ausführliche Statistiken, bezogen auf das Protokoll, auf die Schicht oder das Interface. Mit dem -Z-Flag ist es möglich, einzelne Teile der Statistik zurückzusetzen und so genaue Werte zu finden - entgegen verbreiteter Meinung muß man dazu nicht booten. Man kann also viel Spaß mit dem netstat haben.

Einige Standardanwendungen

Ich will die Interfaces dieser Maschine sehen
Ich will die Routen dieser Maschine sehen
Ich will sehen, wie das Routing funktioniert
Ich will sehen, welche Gewichte für das Multipath-Routing eingestellt sind
Ich will sehen, was für Informationen für eine Route gespeichert sind
Ich will sehen, welchen Statistiken aufgelaufen sind - Kollissionen, Paketverluste und der ganze Krempel
Ich will sehen, wie es um die Netzwerk-Puffer (mbuf, thewall..) bestellt ist
Ich will sehen, wo ich Pakete verliere
Ich will Werte für jedes Protokoll (TCP, UDP, IP..)
Ich will offene Ports und aktive Sockets sehen
Es gibt undokumentierte Flags?

Ich will die Interfaces dieser Maschine sehen:

netstat -ni macht das. Mit -n gibt es keine Hostauflösung, bei einem gestörten Netz sollte das Standard sein... Hier die Ausgabe des Kommandos:


root@nimmaster_en#netstat -ni
Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
lo0   16896 link#1                          138232     0   138248     0     0
lo0   16896 127         127.0.0.1           138232     0   138248     0     0
lo0   16896 ::1                             138232     0   138248     0     0
tr0   1492  link#2      8.0.5a.d.64.1d    36669249     0   528923    21     0
tr0   1492  9.39        9.39.3.19         36669249     0   528923    21     0
tr0   1492  fe80::a00:5aff:fe0d:641d      36669249     0   528923    21     0
en1   1500  link#3      8.0.5a.92.e6.ec          7     0        8     0     0
en1   1500  192.168.140 192.168.140.1            7     0        8     0     0
en1   1500  fe80::a00:5aff:fe92:e6ec             7     0        8     0     0
sit0  1480  link#4      9.27.3.13                0     0        0     0     0
sit0  1480  ::9.39.3.19                          0     0        0     0     0

In der ersten Spalte findet sich das Interface, die zweite die MTU (Maximal Transmission Unit) des Interfaces. Diese kann natürlich durch PMTU Discovery verkleinert werden. In der dritten Spalte findet sich das Netz, auf das dieses Interface zeigt. Dabei wird die konfigurierte Netzmaske des Interfaces zur Berechnung der Netzadresse genutzt. Es können mehrere Einträge in dieser Spalte stehen, wenn IP-Aliase konfiguriert sind. Die vierte Spalte gibt dann die Adresse des Interfaces. Die restlichen Spalten sind wie folgt:
Ipkts - Zahl der hereingekommenen Pakete
Ierrs - Zahl der Fehler dabei
Opkts - Zahl der rausgegangenen Pakete
Oerrs - Zahl der Fehler dabei
Coll - Der Collision Count - wird unter AIX nicht unterstützt.

Für jedes Interface gibt es hier 3 Einträge (weil IPv6 konfiguriert ist - sonst nur 2). Es kommt zuerst das Link, also die Hardware, die im Netz hängt, mit der MAC (Media Access Control) Adresse. Dann die IP (Internet Protocol) Adresse, also die logische Ebene, komplett mit der entsprechenden Netz-Adresse. Sind Aliase definiert, dann werden diese unter dem entsprechenden Link, der Hardware, gelistet. Die dritte Zeile ist die Local-Link Adresse, wenn IPv6 konfiguriert ist. Diese fängt mit fe80 an und ist die logische (IP) Adresse dieses Interfaces auf diesem lokalen Netz (IPv6 vergibt pro Interface mehrer Adressen mit unterschiedlicher Reichweite (scope)). Als letztes kommt ein sit-Tunnel, hier gibt es keine IPv4 Adresse, es ist eine IPv6 Sache.

Man kann sich diese Information auch auf ein Interface bezogen anzeigen lassen: netstat -I en0.

[ Inhaltsverzeichnis ]

Ich will die Route dieser Maschine sehen:

netstat -r hilft hier. Da der netstat so Namensauflösung macht, kann es ein wenig dauern. Mit den Schaltern -rn ist das aus und es geht schnell. Hier die Ausgabe:


root@nimmaster_en#netstat -rn
Routing tables
Destination      Gateway           Flags   Refs     Use  If   PMTU  Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default          9.39.0.191        UGc       0        0  tr0     -   -
9.39/20          9.39.3.19         U        71   500547  tr0     -   -
9.39.128.2       9.39.8.1          UGHMW     1     1062  tr0     -   -
9.228.8.10       9.39.8.1          UGHMW     0       26  tr0  1492     1
9.228.40.7       9.39.0.1          UGHMW     2    46011  tr0     -   -
10.30.0.17       9.39.0.191        UGHW      1     3736  tr0     -   -
127/8            127.0.0.1         U         2     3208  lo0     -   -
192.168.140/24   192.168.140.1     U         0       33  en1     -   -

Route Tree for Protocol Family 24 (Internet v6):
::/96            0.0.0.0           UC        0        0 sit0  1480   -  =>
default          link#2            UCS       0        0  tr0  1492   -
::1              ::1               UH        0        0  lo0 16896   -
fe80::/64        link#2            UCX       0        0  tr0  1492   -
ff01::/16        ::1               US        0        0  lo0     -   -
ff02::/16        fe80::a00:5aff:fe0d:641d US        0        7  tr0  1492   -
ff11::/16        ::1               US        0        0  lo0     -   -
ff12::/16        fe80::a00:5aff:fe0d:641d US        0        0  tr0  1492   -

Diese Maschine hat konfigurierte IPv6 Interfaces. Daher der untere Teil (Protocol Family 24, das ist IPv6). Der obere Teil ist der IPv4 Teil.
Die erste Spalte zeigt das Ziel, also wo die Route hinweist - entweder ein Netz oder ein Host. Die zweite Spalte zeigt das Gateway, wobei ein Interface auch ein "Gateway" sein kann - wenn das Ziel im selben, lokalen, Netz liegt. Hier ein Beispiel aus dem richtigen Leben:
Kantine Vorderer_Ausgang U
Mallorca Frankfurt_Flughafen UG
Gehe ich zum vorderen Ausgang raus, dann sehe ich die Kantine sofort. Will ich nach Mallorca, muß ich auch zum vorderen Ausgang raus (was aber keinen interessiert, weil mir die Route sagt, das ich irgendwie zum Flughafen muß - das ist mein Gateway, und es liegt auf meinem lokalen Netz. Da es eine direkte Autobahnverbindung gibt, ist der Flughafen im selben Subnet.
Die dritte Spalte zeigt die Flags dieser Route:
U - Die Route Ist Up, also aktiv.
H - Geht zu einem Host, und nicht zu einem Netz.
G - Geht zu einem Gateway, das dann weiterroutet (z.B. ein Router).
D - Diese Route ist dynamisch angelegt worden durch einen redirect (Ein Steuermechanismus auf IP-Ebene oder ein Deamon). (ICMP oder Routing Protokoll)
M - Eine bestehende Route ist verändert worden (modified). (ICMP oder Routing Protokoll)
L - Der Eintrag für das Link (Adapter etc) ist in der Route enthalten, d.h. diese Route geht über das spezifizierte Link.
c - Benutzt man diese Route, so wird eine neue, geklonte Route angelegt.

Das hat mit Path MTU Discovery zu tun, für jede Verbindung über das Netz wird eine eigene Route mit "feingetunten" Parametern angelegt.

W - Das ist so eine geklonte Route. Die "Mutter-Route" ist die vorhergehende Route mit dem c.... (W= "was cloned").
R - Dieser Host oder dieses Netz ist nicht zu erreichen (R= reject).
S - Diese Route ist von Hand angelegt worden.
b - Diese Route zeigt auf eine Broadcast Adresse.

Mit AIX 5.x hat sich einiges geändert. Es wird jetzt pro Interface eine Route auf das Interface angelegt (Flag U), eine Route über das lo0 auf das Interface (Flag UGHS), sowie zwei Broadcast Routen ins lokale Netz (Flag UHSb). Das dient alles zu Beschleunigung des Netzverkehrs, da ja nun immer wiederkehrende Adressen nicht immer wieder berechnet werden müssen. Die Route aufs Lokale Interface sorgt dafür, das lokaler, Maschinen-interner Verkher auch wircklich nur über lo0 abgearbeitet wird - mit der sehr großen MTU von lo0. Aussehen tut das alles auf einem AIX 5.2 System jetzt so:

10.225.183.2     127.0.0.1         UGHS      1       83  lo0     -   -      -
10.225.183.0     10.225.183.2      UHSb      0        0  en1     -   -      -   =>
10.225.183/25    10.225.183.2      U         4        0  en1     -   -      -
10.225.183.127   10.225.183.2      UHSb      0        4  en1     -   -      -
Zusätzlich gibt es jetzt noch beliebig viele Netzrouten, die dann die Flags UGc tragen und von denen weitere Routen geklont werden - Flag W. Das verschwindet mit AIX 5.3, dort sieht man die geklonten Routen in der Routing Table nicht mehr - es gibt jetzt einen eigenen Befehl: pmtu display.

Die vierte Spalte zeigt an, wie oft auf diese Route verwiesen wird. Hierbei zählen nur die aktiven Verbindungen, also die, die im Moment über diese Route gehen.

Die fünfte Spalte zeigt die Menge der Pakete, die über diese Route gegangen sind.

Die sechste Spalte zeigt das Interface, über das diese Route läuft.

Die siebte Spalte zeigt die Maximale MTU für dieser Route.

Die achte Spalte zeigt an, wann die Route ihre Gültigkeit verliert. (In Minuten)

Die neunte Spalte zeigt die Gruppenzugehörigkeit an.

Es kann sein, das nicht alle Felder gesetzt sind - das hängt davon ab, ob PMTU Discovery an oder aus ist.

Das Beispiel oben ist eigenartig, weil es ganz viele modifizierte Routen gibt. Offensichtlich hat jemand das Default-Gateway (9.39.0.191) geändert, und nichts gesagt.
Dasselbe sieht man im folgenden Output. Die Maschine versucht es immer über 9.39.0.191, dann gibt es einen Redirect, weil 9.39.0.191 offensichtlich nach 9.39.8.1 routen möchte, und das ist im selben Netz.
Dumm.


root@cristina#netstat -rn
Routing tables
Destination      Gateway           Flags   Refs     Use  If   PMTU  Exp  Groups

Route Tree for Protocol Family 2 (Internet):
default          9.39.0.191        UG        2    54629  tr0     -   -
9.3.216.134      9.39.8.1          UGHD      0      202  tr0     -   -
9.19.129.12      9.39.8.1          UGHD      0        0  tr0     -   -
9.37.172.5       9.39.8.1          UGHD      0       16  tr0     -   -
9.39/20          9.39.0.74         U       227  1980994  tr0     -   -
9.39.64.151      9.39.8.1          UGHD      0     1456  tr0     -   -
9.228.8.10       9.39.8.1          UGHD      4     3887  tr0     -   -
127/8            127.0.0.1         U         4      698  lo0     -   -
192.168.140/24   192.168.140.3     U         1      112  en0     -   -

Route Tree for Protocol Family 24 (Internet v6):
::1              ::1               UH        0        0  lo0 16896   -
[ Inhaltsverzeichnis ]

Ich will sehen, wie das Routing funktioniert:

netstat -rs ist da der richtige Kandidat. Es zeigt mir, wie oft ein Redirect zugeschlagen hat, wie oft eine Route dynamisch zugefügt wird, wie oft eine Route modifiziert wurde, wie oft sie nicht zum Ziel führte. Hier die Ausgaben auf den Oben erwähnten Maschinen: (Leider ziemlich krank)


root@nimmaster_en#netstat -rs
routing:
3 bad routing redirect
0 dynamically created route
203 new gateway due to redirects
2 destination found unreachable
0 use of a wildcard route

root@cristina#netstat -rs
routing:
4294953556 bad routing redirect
163 dynamically created route
1 new gateway due to redirects
76 destination found unreachable
0 use of a wildcard route

Einträge im Feld bad routing redirect bedeuten, daß diese Maschine einen Redirekt empfangen hat (entweder per ICMP oder per Routing Deamon), den es nicht in seine Routing Table eintragen kann - weil es z.B. eine duplizierte Route ist, oder das angegebene Gateway nicht auf dem lokalen Netz liegt. Vielleicht ist es auch eine Interface-Route; es gibt viele Gründe.

Einträge im Feld dynamically created route bedeuten, daß diese Anzahl an Routen per Redirekt erzeugt worden sind. Das sind die Routen mit dem Flag D.

Der Rest der Einträge erklärt sich eigentlich selbst...

[ Inhaltsverzeichnis ]

Die allgemeinen Statistiken

netstat -v zeigt unter AIX diese Information. Man erhält allgemeine Informationen über den Adapter, die Uptime, den Paketfluss in beide Richtungen und die vorhandenen Queues. Weiterhin werden alle Zähler ausgegeben, die über das Schicksal von Paketen Auskunft geben können.

Diese Zähler hängen stark von der Adapter-Hardware und der Treiber-Software ab. Zähler, die nicht bedient werden, stehen auf dem Wert 0 - was die Unterscheidung ein bischen schwierig macht.

 
-------------------------------------------------------------
ETHERNET STATISTICS (ent0) :
Device Type: IBM PCI Ethernet Adapter (22100020)
Hardware Address: 08:00:5a:f8:b5:b6
Elapsed Time: 42 days 1 hours 44 minutes 44 seconds

Transmit Statistics:                          Receive Statistics:
--------------------                          -------------------
Packets: 20686                                Packets: 1243
Bytes: 1803908                                Bytes: 144606
Interrupts: 0                                 Interrupts: 1243
Transmit Errors: 0                            Receive Errors: 0
Packets Dropped: 0                            Packets Dropped: 0
Bad Packets: 0
Max Packets on S/W Transmit Queue: 1
S/W Transmit Queue Overflow: 0
Current S/W+H/W Transmit Queue Length: 0

Die Anzahl der Pakete, die Gesendet und Empfangen wurden. Angegeben wird die Anzahl der Pakete und die gesamte Menge der damit übertragenen Daten. Ein Interrupt wird gezählt, wenn die Karte ein Paket empfangen hat und dann den Treiber anweisen muss (per Interrupt) Resourcen für die Abarbeitung zur Verfügung zu stellen. Im Fall der Interrupts beim Übertragen zeigt die Karte dem Treiber an, dass sie nicht senden konnte. Transmit oder Receive Errors entstehen, wenn das Paket während der Übertragung verloren geht (wegen Hardware oder Netzwerkfehlern, späte Kollisionen etc.). Der Treiber zählt genau jedes von ihm verworfene Paket (Packets Dropped). Das tut er bezogen auf die Richtung, also Pakete, die Empfangen (Receive) werden, gibt er nicht an den Demuxer weiter. Im Fall der gesendeten Pakete gibt er sie - aus welchem Grund auch immer - nicht an den Adapter weiter. Gründe können DMA-Probleme, CRC Fehler, Überlast etc. sein. In jedem Fall hat der Treiber das Paket schon in der Hand gehabt, es ist also kein Receive- oder Transmit-Error. Das sind Fehler der Adapters. Es gibt Pakete, die sich nach dem Empfang als schadhaft herausstellen (Bad Packets). Die letzten Zähler zeigen die Software-Transmit Queue an. Es wird die aktuelle Anzahl der zu sendenden Pakete in der Warteschlange von Hard- und Software gezählt, sowie alle bisherigen Überläufe und der Spitzenwert.

 
Broadcast Packets: 18753                      Broadcast Packets: 47
Multicast Packets: 2                          Multicast: 4

Die Anzahl der Broad- und Multicast Pakete wird aufgeschlüsselt. Überzogenen Werte sind Zeichen für Loops oder Miskonfigurationen.

 
No Carrier Sense: 0                           CRC Errors: 0
DMA Underrun: 0                               DMA Overrun: 0
Lost CTS Errors: 0                            Alignment Errors: 0
Max Collision Errors: 0                       No Resource Errors: 0
Late Collision Errors: 0                      Receive Collision Errors: 0

Der erste Zähler (No Carrier) zeigt Probleme auf dem Link an. Der Zähler wird erhöht, wenn im Half-Duplex Mode der Link nicht gefunden werden kann. CRC Fehler entstehen, wenn die Checksumme des Paketes nicht nachvollzogen werden kann. DMA Überläufe entstehen, wenn der Adapter ein empfangenes Paket in den Systemspeicher schreiben möchte, dies aber nicht beenden kann. Das ist kein Mangel an Speicher, sondern der Bus ist hier die überlastete Resource. Im anderen Fall erwartet der Adapter mehr Daten aus dem Speicher als er empfangen hat (es kommen keine Daten mehr, aber es war keine Endmarke zu sehen). Das sind DMA Unterläufe. Fehler können auch entstehen, wenn die Frames nicht richtig ausgerichtet sind (Alignment Error). Mangelt es zum Empfangen an Resourcen, so wird der entsprechende Zähler hochgezählt. Kollisionen gehören zum normalen Leben auf dem Ethernet, und die Anzahl der maximalen Kollisionen muss im Verhältnis zu den übertragenen Paketen sehr hoch sein (Werte sind sehr persönlich, vielleicht zwischen 5 bis 20%), um Besorgnis zu erregen. Richtig schlimm sind die späten Kollisionen (Late Collision Errors). Hier wird eine Kollision entdeckt, nachdem eine Station schon länger als die Slottime gesendet hat, der Kanal ihr also schon gehört. Passiert z.B., wenn eine Station Full-Duplex auf einem Half-Duplex Link sendet. Ähnliches gilt für Kollisionen während des Empfangs. Das weist auf zu lange Kabelstrecken hin (Laufzeit des Signals ist zu gross).

 
Deferred: 0                                   Packet Too Short Errors: 0
SQE Test: 0                                   Packet Too Long Errors: 0
Timeout Errors: 0                             Packets Discarded by Adapter: 0
Single Collision Count: 0                     Receiver Start Count: 0
Multiple Collision Count: 0
Current HW Transmit Queue Length: 0

Pakete werden zurückgewiesen, wenn das Netz nicht verfügbar ist; der Zähler Deferred wird erhöht. Ist ein Paket zu kurz, dann wird davon ausgegangen, dass es ein verirrtes Signal auf dem Link ist. Pakete können auch zu lang sein, beides Zeichen für Konfigurationsfehler. Die weiteren Parameter sind selbsterklärend

 
General Statistics:
-------------------
No mbuf Errors: 0
Adapter Reset Count: 1
Driver Flags: Up Broadcast Running
Simplex AlternateAddress 64BitSupport

IBM PCI Ethernet Adapter Specific Statistics:
------------------------------------------------
Chip Version: 16
Packets with Transmit collisions:
1 collisions: 0           6 collisions: 0          11 collisions: 0
2 collisions: 0           7 collisions: 0          12 collisions: 0
3 collisions: 0           8 collisions: 0          13 collisions: 0
4 collisions: 0           9 collisions: 0          14 collisions: 0
5 collisions: 0          10 collisions: 0          15 collisions: 0
-------------------------------------------------------------

Hier ist die Angabe zu den mbuf-Fehlern wichtig. Ein aufgelaufener Zähler indiziert ein Problem mit dem Speicher. Die Flags und die Geschwindigkeit sind die aktuellen Werte. Der Kollisionszähler wird oft nicht unterstützt. Er bezieht sich auf die Anzahl der Kollisionen, die ein einzelnes Paket erfahren hat. Ist ein Paket auf insgesamt 16 Kollisionen gekommen, so wird es der Anwendung mit einer Fehlermeldung zurückgegeben. Man sollte daran denken, das zwischen den einzelnen Kollisionen progessiv ansteigende Timeout-Wert liegen (exponentieller Backoff).

[ Inhaltsverzeichnis ]

Die Netzwerk-Puffer - Memory Management

$ netstat -m

Kernel malloc statistics:

******* CPU 0 *******
By size           inuse     calls failed   delayed    free   hiwat   freed
32                  190       417      0         0      66   15400       0
64                  191   1119062      0         5     193   15400       0
128                 371    391992      0         9      77    7700       0
256                 243    772952      0        14     141   15400       0
512                6438  65433206      0       998    2050   19250       0
1024                210    463750      0        59     110    7700       0
2048               6288   1432969      0      4149    2046   11550       0
4096                 76     28881      0        25      20    3850       0
8192                  2      4850      0        20       5    1925       0
16384              1464      5240      0       282     510     962       0
32768                 0      4325      0        19       8     481       0
65536                 1        16      0         5       0     481       0
131072                4         4      0         0     231     463       0


******* CPU 1 *******
By size           inuse     calls failed   delayed    free   hiwat   freed
32                    0         2      0         0     128   15400       0
64                   24     17967      0         1     104   15400       0
128                   3      4978      0         0      61    7700       0
256                   0      4179      0         0      32   15400       0
512                  26   5325445      0        10     334   19250       0
1024                 19      5916      0        16      57    7700       0
2048                 14     26204      0        63     120   11550       0
4096                  0       916      0         3      26    3850       0
8192                  0       297      0        13      18    1925       0
16384                 0       355      0        18      24     962       0
32768                 0       443      0         9       7     481       0
65536                 0         2      0         1       0     481       0
131072                0         0      0         0       8      16       0

Streams mblk statistic failures:
0 high priority mblk failures
1 medium priority mblk failures
0 low priority mblk failures
$ netstat -M
Cluster pool Statistics
  Cluster Size   Pool Size   Calls   Failed   Inuse   Max Outcount
          2048        2048 35659258        0    1242           2048
          2048        2048 25915760        0    1025           2048
        131072           0       0        0       0              0
         65536           0       2        1       0              1
         32768           0   73982      428       0              5
         16384           0   37677      404       0             13
          8192           0   20573      279       0              9
          4096           0    3375      450       0             18
          2048           2  127785     4021       0            129
          1024           3   29395     2110       0             26
           512           1   10197     1390       0              3
        131072           2      13        2       0              2
         65536           0      30        9       0              3
         32768           0 3079937     3710       0             10
         16384           0 1608059     3213       0             24
          8192           0  860161     1963       0             15
          4096           2  160007    21934       0             32
          2048           3 1511416    17090       0            129
          1024           3  407912     5566       0             49
           512           2  197549     5041       0              8

[ Inhaltsverzeichnis ]

Ich will Werte für jedes Protokoll (TCP, UDP, IP..)

An diese Information komme ich mit netstat -s. Da die Ausgabe durchaus umfangreich ist, sollte man das Protokoll von Interesse spezifizieren, also z.B. netstat -sp tcp . Das netstat-Kommando gibt Statistiken zu folgenden Protokollen aus: ip, icmp, igmp, tcp, udp, ipv6, icmpv6 . Der folgende Schalter unterdrückt alle Einträge, deren Wert Null ist, wo also nichts aufgelaufen ist: netstat -ss.
Hier Beispiele für ip, icmp und tcp:

 
ip:
10037486 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
1081 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
424 packets reassembled ok
7462217 packets for this host
14587 packets for unknown/unsupported protocol
0 packets forwarded
552068 packets not forwardable
0 redirects sent
828929 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
0 output packets discarded due to no route
2 output datagrams fragmented
4 fragments created
0 datagrams that can't be fragmented
2007954 IP Multicast packets dropped due to no receiver
0 successful path MTU discovery cycles
0 path MTU rediscovery cycles attempted
0 path MTU discovery no-response estimates
0 path MTU discovery response timeouts
0 path MTU discovery decreases detected
0 path MTU discovery packets sent
0 path MTU discovery memory allocation failures
0 ipintrq overflows
0 with illegal source
 
 
icmp:
130 calls to icmp_error
0 errors not generated because old message was icmp
Output histogram:
echo reply: 12377
destination unreachable: 37
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
echo reply: 9
destination unreachable: 158
routing redirect: 50
echo: 12412
#9: 13542
time exceeded: 6
address mask request: 2
12377 message responses generated
 
 
tcp:
317320 packets sent
255716 data packets (238564737 bytes)
656 data packets (320333 bytes) retransmitted
41852 ack-only packets (19940 delayed)
0 URG only packets
0 window probe packets
1542 window update packets
17554 control packets
230429 packets received
170612 acks (for 238582469 bytes)
7914 duplicate acks
0 acks for unsent data
108750 packets (20635066 bytes) received in-sequence
624 completely duplicate packets (4026 bytes)
30 packets with some dup. data (59 bytes duped)
6095 out-of-order packets (5740 bytes)
0 packets (0 bytes) of data after window
0 window probes
321 window update packets
3 packets received after close
0 packets with bad hardware assisted checksum
0 discarded for bad checksums
0 discarded for bad header offset fields
0 connection request
6064 connection requests
4879 connection accepts
10822 connections established (including accepts)
13621 connections closed (including 28 drops)
131 embryonic connections dropped
131446 segments updated rtt (of 131961 attempts)
0 resends due to path MTU discovery
0 path MTU discovery terminations due to retransmits
1236 retransmit timeouts
19 connections dropped by rexmit timeout
0 persist timeouts
7184 keepalive timeouts
504 keepalive probes sent
120 connections dropped by keepalive
0 connections in timewait reused
0 delayed ACKs for SYN
0 delayed ACKs for FIN
0 send_and_disconnects
 

[ Inhaltsverzeichnis ]

Ich will sehen, wo ich Pakete verliere

netstat -D ist gut dafür. Das zeigt das ganze Subssystem, vom Adapter bis zur Applikation (NFS bzw. RPCs (Remote Procedure Calls)). Hier das Beispiel:


root@nimmaster_en#netstat -D

Source                         Ipkts                Opkts     Idrops     Odrops
-------------------------------------------------------------------------------
ent_dev0                           0                    0          0          0
tok_dev0                    39715837               531277          4          0
ent_dev1                       23651                11842          0          0
---------------------------------------------------------------
Devices Total               39739488               543119          4          0
-------------------------------------------------------------------------------
ent_dd0                            0                    0          0          0
tok_dd0                     39715833               531277          0          0
ent_dd1                        23651                11842          0          0
---------------------------------------------------------------
Drivers Total               39739484               543119          0          0
-------------------------------------------------------------------------------
ent_dmx0                           0                  N/A          0        N/A
tok_dmx0                    36782580                  N/A    2933255        N/A
ent_dmx1                       23651                  N/A          0        N/A
---------------------------------------------------------------
Demuxer Total               36806231                  N/A    2933255        N/A
-------------------------------------------------------------------------------
IP                           4220573              3121755     211342     202973
TCP                           144616               105360          0          0
UDP                          2976491               552993      16694          0
---------------------------------------------------------------
Protocols Total              7341680              3780108     228036     202973
-------------------------------------------------------------------------------
lo_if0                        138709               138726         17          0
tr_if0                      36782582               531299          0         45
en_if1                         23651                11842          0          0
sit_if0                            0                    0          0          0
---------------------------------------------------------------
Net IF Total                36944942               681867         17         45
-------------------------------------------------------------------------------
NFS/RPC Client                   319                  N/A          0        N/A
NFS/RPC Server                     0                  N/A          0        N/A
NFS Client                       319                  N/A          0        N/A
NFS Server                         0                  N/A          0        N/A
---------------------------------------------------------------
NFS/RPC Total                    N/A                  319          0          0
-------------------------------------------------------------------------------
(Note:  N/A -> Not Applicable)

Zuerst kommt der Adapter als solcher (hier 3, weil nimmaster einen Token Ring und 2 Ethernet Adapter hat). Wir reden hier vom Device, und wieviele Pakete rein und raus sind sowie die Fehler. Hier werden Fehler gezählt, wenn der Adapter aus irgendwelchen Gründen mit dem Paket nicht fertig wird. Wir reden hier von reiner HW Ebene, die Logik des Adapters ermittelt die Werte und reicht sie an das System weiter. Ein Beispiel:

tok_dev0                    39715837               531277          4

. Das kam rein. Das ging raus. Nicht reingelassen.

Dann kommt die Statistik für den Device Treiber - Das wäre die untere Ebene des Interfaces. Wir sind also jetzt auf dem System. Das Interface ist in zwei Teile geteilt: den Treiber und den Demuxer (De-Multiplexer). Auch hier ein Beispiel:

tok_dd0                     39715833               531277          0

. Alle reingekommenen Pakete, minus den gedroppten (4) - also verworfenen Paketen.

Danach laufen die Pakete durch den Demuxer, also den De-Multiplexer. Das ist, wo der Strom der Pakete, die vom Netz kommen, nach ihrem Protokoll (ICMP, UDP, TCP etc.) zugeordnet werden. Für die rausgehenden Pakete gibt es keine Statistik, das Multiplexen ist zwanglos, die Pakete gehen einfach auf den Draht (klingt logisch). Das Beispiel dazu:

tok_dmx0                    36782580                  N/A    2933255

. Das sind die Pakete, die vom Demuxer weitergereicht werden. Die anderen (2933255) waren zB. nicht für diesen Host, oder es sind Pakete für andere Protokolle, z.B. IPX.
Der Demuxer schmeisst alles weg, was er nicht zuordnen kann. Das indiziert in der Regel keinen Fehler.

Jetzt kommen die Protokolle mit ihrer Statistik. Das sind also alle Pakete, die vom Adapter (der HW!), vom Treiber und vom Demuxer als in Ordnung angesehen wurden. Hier spiegeln sich also Probleme mit TCP-Headern wieder, Services, die es nicht gibt etc.

Und am Schluss die Interfaces mit der zugehörigen Statistik. Diese Information ist ein bisschen redundant, weil sie ja schon in Treiber und Demuxer enthalten ist - aber es muß ja nicht immer so sein, das das Interface so aufgespalten wird. Ein anders, neues Netzwerkdevice muß es nicht so machen (ATM oder Tunnel-Interfaces).

Ganz am Ende RPC/NFS. Meine Maschine ist ein NFS-Client. NFS schreibt keine ausführlichen Statistiken - es gibt z.B. gar keine Statistik über rausgehende Pakete (deshalb N/A (Not Available). Genauso wird nicht zwischen NFS und RPCs unterschieden. Die Anzahl ist gleich, deshalb ist auch eine Summe unsinnig.

[ Inhaltsverzeichnis ]

Ich will sehen, was für Informationen für eine Route gespeichert sind

route get Ziel hilft mir da. Hier ein Beispiel, mehr Information bei der Diskussion des route-Kommandos.


root@cristina#route get 9.39.3.19
route to: nimmaster
destination: nimmaster
interface: tr0
interf addr: cristina.ncs.mainz.ibm.com
flags: 
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
0         0         0       438       438         0      1492        -2
Man sieht die Flags, Namen von Gateway und Destination etc. Die letzte Zeile sind Informationen zur MTU, zur Gültigkeit, zur gemessenen Round Trip Time etc.

[ Inhaltsverzeichnis ]

Ich will sehen, welche Gewichte für das Multipath-Routing eingestellt sind

Dazu dient ab AIX 5.x das Flag -C. Damit werden zusätzliche spalten angezeigt, in denen die gesetzten Gewichte (Wt), die Policy (hier überall Standard) und die Kosten der Route (Cost) angegeben werden:

$ netstat -Cn
Routing tables
Destination      Gateway           Flags     Wt  Policy  If   Cost Config_Cost

Route Tree for Protocol Family 2 (Internet):
default          10.225.101.251    UG         1    -    en0       1    1
10.224.164.128/26 10.225.242.254    UG         1    -    en1       1    1
10.225.101.0     10.225.101.139    UHSb       1   WRR  en0       0    0 =>
10.225.101.0     10.225.101.34     UHSb       1   -"-   en2       0    0 =>
10.225.101/24    10.225.101.139    U          1   WRR  en0       0    0 =>
10.225.101/24    10.225.101.34     U          1   -"-   en2       0    0
10.225.101.34    127.0.0.1         UGHS       1    -    lo0       0    0
10.225.101.139   127.0.0.1         UGHS       1    -    lo0       0    0
10.225.101.255   10.225.101.139    UHSb       1   RR   en0       0    0 =>
10.225.101.255   10.225.101.34     UHSb       1   -"-   en2       0    0

Route Tree for Protocol Family 24 (Internet v6):
::1              ::1               UH         1    -    lo0       0    0
Dabei wird die Policy mit folgenden Abkürzungen bezeichnet: Eingestellt wird Mutlipath-Routing mit dem no-Parameter mpr_policy, Werte für die Routen werden mittels des Route-Kommandos gesetzt.

[ Inhaltsverzeichnis ]

Ich will offene Ports und aktive Sockets sehen

netstat -aAn zeigt mir alle offenen Sockets. Mit dem Schalter -A ist netstat noch so nett, die Adresse des PCB (Protocol Control Block) anzugeben. Man kann dann mit LSOF den entsprechenden Prozess suchen (das geht leider nicht immer). Hier ein Beispiel, das ich stark gekuerzt habe:

 
Active Internet connections (including servers)
PCB/ADDR Proto Recv-Q Send-Q  Local Address  Foreign Address    (state)
700f76dc tcp4       0      0  9.39.0.74.39374    9.39.0.74.39373    ESTABLISHED
700f8adc tcp4       0      0  *.39373            *.*                LISTEN
700c66dc tcp4       0      0  *.2049             *.*                LISTEN
700ad2dc tcp4       0      0  127.0.0.1.32771    127.0.0.1.199      ESTABLISHED
700a22dc tcp        0      0  *.23               *.*                LISTEN
700a26dc tcp        0      0  *.21               *.*                LISTEN
700a2adc tcp4       0      0  *.111              *.*                LISTEN
700a2edc tcp4       0      0  *.25               *.*                LISTEN
700f3a00 udp4       0      0  *.*                *.*
700c9900 udp4       0      0  *.2049             *.*
700ac500 udp4       0      0  *.135              *.*
700acb00 udp4       0      0  9.39.0.74.123      *.*
700ac800 udp4       0      0  192.168.140.3.123  *.*
700ac700 udp4       0      0  127.0.0.1.123      *.*
700a7100 udp4       0      0  *.123              *.*
700aae00 udp4       0      0  *.111              *.*

Active UNIX domain sockets
SADR/PCB  Type   Recv-Q Send-Q Inode    Conn     Refs     Nextref  Addr
700a6200 dgram       0      0 132c48e0        0        0        0 /dev/SRC
700a3d40
700a6000 dgram       0      0 1318b240        0 700a33c0        0 /dev/log
700a3d00
700c3e00 stream      0      0 130d5200        0        0        0
/opt/dcelocal/var/security/adm/dceunixd/dceunixd.skt0
700a3540
 
Die Ausgabe gibt mir folgende Information:

[ Inhaltsverzeichnis ]

Undokumentierte Flags in AIX 4.3.2 und 4.3.3

Es gibt in AIX 4.3.2 und 4.3.3 einige, manchmal nützlich Flags, die noch nicht richtig dokumentiert sind. Ob diese in früheren oder späteren Releases enthalten bzw. richtig dokumentiert sind, habe ich nicht geprüft (ist ja auch ziemlich Banane). Hier diese Flags:

Die Flags -a und -d waren sehr praktisch...

[ Inhaltsverzeichnis ]

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )