| orm@doc-tcpip.org | Erstellt: April 1999 - Letzte Modifikation: September 2007 |
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.
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.
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.
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").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 -
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...
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).
$ 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
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
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 2933255Der Demuxer schmeisst alles weg, was er nicht zuordnen kann. Das indiziert in der Regel keinen Fehler.
. 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.
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.
route get Ziel hilft mir da. Hier ein Beispiel, mehr Information bei der Diskussion des route-Kommandos.