Inhalt
Einleitung
Erste Schritte
Die Bash
Das Dateisystem
Nutzerkommandos
Installation
Shells
Unix-Werkzeuge
System-Administration
X Window System
Der Kernel
Netzwerk Grundlagen
Geschichte
Protokolle
Netzwerkstruktur
Allgemeine Dienste
Konfigurationsdateien
Konfigurationstools
Diagnose
Internet Service Dämon
Remote Procedure Call
Request For Comments
Netzwerk Clients
Netzwerk Server
Netzwerk Sicherheit
Anhang
Register
Netzwerk-Diagnose |
| Übersicht |
|
Das eine oder andere hier aufgeführte Kommando finden Sie auch an anderen Stellen des Buches. Der hiesige Schwerpunkt liegt auf Netzwerkdiagnose, d.h. auf der Verwendung der Kommandos zur Analyse von Netzwerkproblemen. Deshalb finden sie zu Kommandos, die auch für andere Zwecke eingesetzt werden können, im folgenden Abschnitt einzig die zur Inspektion der Netzwerkfunktionalität relevanten Optionen.
Die Fehlersuche gestaltet sich zumeist schwierig. Sie erfordert eine gewisse Methodik, um sich aus der Masse der Möglichkeiten zur wahrscheinlichsten Ursache vorzuarbeiten. Die Reihenfolge der Beschreibung der Ihnen als Administrator zur Seite stehenden Werkzeuge spiegelt die von uns bevorzugte Herangehensweise ab. Wir hangeln uns vom Allgemeinen ins Detail, beginnend bei einfacher Funktionsprüfung bis hin zu Maßnahmen der Optimierung.
| Das Kommando ping/ping6 |
|
Vorwort
Funktional besteht kein Unterschied zwischen ping (IPv4) und ping6 (IPv6), sodass wir in nachfolgender Beschreibung auf eine Unterscheidung verzichten. Verwenden Sie ping in traditionellen IPv4-Netzwerken und ping6 in Netzwerken, die unter IPv6 laufen.
Sollten Sie dennoch einmal einem der Kommandos die »falsche« IP-Adresse unterschieben, so wird dieses den Dienst mit »unknown host« quittieren:
user@sonne> ping ::1
|
Das Kommando ping greift auf Systemressourcen zu, die i.d.R. nur für root zugänglich sind. Um dem »normalen« Benutzer dennoch seine Anwendung zu ermöglichen, ist zumeist das setuid-root Flag gesetzt.
Allgemeines
ping dient vorrangig zum Testen, Messen und Administrieren von Netzwerken. Es erhöht die Netzwerklast, womit sein Einsatz in automatischen Skripten in Produktionsumgebungen zu vermeiden ist.
»Ping« wurde nach dem Klang von Sonar-Ortungssystemen benannt, wo niederfrequenter Schall in die Tiefen des Ozeans ausgesandt wird, um anhand von Reflexionen den Standort von Objekten zu kalkulieren. Im übertragenen Sinne arbeitet »Ping« analog zu einem Sonar, da es eine Anforderung ins Netzwerk entlässt und anhand der Art und Weise der Reaktion (»Reflexion«) verschiedene Rückschlüsse zu ziehen vermag. Welche das sein können, werden Sie nachfolgend kennen lernen.
Intern arbeitet ping über das ICMP-Protokoll, indem es ein ICMP ECHO_REQUEST (Typ 8) an den entfernten Rechner im Netzwerk sendet, um (hoffentlich) ein ECHO_RESPONSE (Typ 0) als Antwort zu erhalten.
Wichtigste Erkenntnis aus einem ECHO_RESPONSE ist sicherlich, dass die Gegenseite arbeitet und erreichbar ist. Aussagen zur Qualität der Erreichbarbeit lassen sich ebenso ableiten.
Die Anwendung des Kommandos
Zumindest der Zielrechner ist beim Aufruf des Kommandos als Parameter anzugeben. Ohne weitere Optionen werden ständig ECHO_REQUEST's ausgesendet, d.h. der Zielrechner wird ohne Unterlass »angepingt«. Dies können Sie nur durch Eingabe von [Ctrl][C] unterbrechen. ping schreibt abschließend eine kurze Zusammenfassung auf die Standardausgabe:
user@sonne> ping localhost
|
[Ctrl][C] bewirkt das Senden des Signals SIGINT an den Prozess, das im Falle von ping zum Beenden des Programms führt. ping reagiert ebenso auf ein Signal SIGQUIT, womit die Statistik erscheint, ohne das Programm zu beenden. SIGQUIT wird durch keinen Tastencode erzeugt.
Die Statistik
Das Ausgabeformat der Statistik ist zum Großteil selbsterklärend. Eine erste Zeile enthält die Anzahl ausgesendeter und empfangener Pakete sowie den Verlustfaktor (in Prozent). Ein letzter Wert gibt die Gesamtzeit des Programmlaufs an.
Die zweite Zeile umfasst vier Zeitwerte. Erster beschreibt die kürzeste Zeitspanne, nach der eine Antwort auf ein ausgesendetes Paket eintraf. Der zweite Wert enthält die längste gemessener Dauer. Dritter Wert ist die durchschnittliche Zeitdauer und Wert Nummer 4 beschreibt die gemittelte Abweichung vom durchschnittlichen Wert.
Die Optionen
Allgemeine Optionen
Etliche Optionen von ping lassen sich nach funktionalen Aspekten gruppieren. Aber eben nicht alle. Die nach unserem Schema nicht »qualifizierbaren« Optionen fassen wir deshalb als »allgemeine« Optionen zusammen. Diese Einteilung ist rein willkürlich!
Die weiter oben beschriebene Anwendung des Kommandos eignet sich nicht zur Verwendung in Skripten, da es zum Beenden eine Interaktion mit dem Benutzer erfordert. Zwei Optionen steuern deshalb das Programmende:
| -c Anzahl | ||
| Begrenzt die Anzahl zu sendender »Pings«. Nach Erreichen dieser endet das Programm selbstätig. | ||
| -w Sekunden | ||
| Nach Verstreichen der angegebenen Sekunden endet das Programm selbstätig unabhängig von der Anzahl gesendeter bzw. erhaltenener Pakete. | ||
In Verbindung mit beiden Optionen steht Ihnen zur Auswertung der Rückgabewert des Kommandos ping zur Verfügung. Hierbei bedeutet:
| 0 | ||
| Der Zielrechner ist erreichbar; es wurde mindestens ein ECHO_RESPONSE empfangen. | ||
| 1 | ||
| Es wurde entweder gar kein ECHO_RESPONSE empfangen oder, bei gleichzeitiger Verwendung der Optionen »-w« und »-c«, die spezifizierte Anzahl wurde nicht erreicht (weniger »Pongs« als »Pings«). | ||
| 2 | ||
| Nicht näher spezifizierter Fehler. | ||
Zwei Beispiele zur Auswertung des Rückgabewertes:
user@sonne> ping -c 1 localhost
|
user@sonne> for host in server1 server1;
|
Eher formalen Charakter besitzen folgende Optionen:
| -a | ||
| Für jedes eintreffende ECHO_REPLY wird ein Piepton ausgegeben. Die Erreichbarkeit eines Rechners wird damit akkustisch signalisiert. | ||
| -n | ||
| Rechner werden stets mit ihrer IP-Adresse angegeben (und nicht mit ihrem Namen). | ||
| -q | ||
| Sämtliche Ausgaben mit Ausnahme der ersten Zeile und der Statistik werden unterdrückt. | ||
Optionen zur Steuerung des Zeitverhalten
In der Voreinstellung versendet ping seine Anforderungen im Sekundentakt. Die Optionen zur Manipulation des Zeitverhaltens erfordern teils Rootrechte, da sie zu extremer Erhöhung der Netzwerklast missbraucht werden könnten.
| -i Sekunden | ||
| Die Option legt die Zeitspanne in Sekunden zwischen dem Aussenden zweier aufeinander folgender ICMP_REQUEST's fest. Nur Root darf einen Wert < 0.2 (Sekunden) wählen. | ||
| -f | ||
| (flood ping). Dieses »flutende« Ping entspricht der Option »-i 0«, d.h. die ICMP_REQUEST werden ohne Verzögerung abgesetzt. Das Setzen der Option bleibt einzig Root vorbehalten. Jedes gesendete ICMP_REQUEST-Paket wird in der Ausgabe durch einen Punkt symbolisiert, der bei eintreffendem ICMP_RESPONSE durch einen Backspace »\b« gelöscht wird. Die Anzahl Punkte entspricht somit der Anzahl ausstehender Antworten. | ||
| -l Anzahl | ||
| Die Wirkungsweise der Option ist wie »-f« nur dass sie die Anzahl zu sendender ICMP_REQUEST's beschränkt. Nur Root darf mehr als 3 Pakete gleichzeitig abschicken. | ||
| -t TimeToLive | ||
|
Der so genannte TTL-Wert (Time To Live) entspricht der Anzahl von Routern, die
ein Paket maximal passieren kann. Jeder Router auf dem Weg des Pakets verringert dessen
TTL-Wert stets um eins. Geht der Wert in einem Router auf Null, so wird dieser das Paket
verwerfen und eine Fehlermeldung an den Absender senden. Die Bezeichnung Time to live
stammt noch aus den Anfängen von TCP/IP, zu denen tatsächlich die Lebensdauer
eines Pakets durch einen Zeitwert begrenzt wurde. Die Voreinstellung für TTL ist 255. |
||
# Falls 3 Router auf dem Weg liegen...
user@sonne> ping -c 1 rechner.irgendwo.foo
|
Der TTL-Wert in der Endstatistik (obiges Beispiel) wird von dem Rechner gesetzt, der »angepingt« wurde. Die Interpretation des Wertes gestaltet sich schwierig, da es keine feste Regeln gibt, nach denen ein Rechner das Feld belegt. Manche Implementierungen schreiben dort einen Wert, der 255 minus der Anzahl der durchlaufenen Router beträgt. Wiederum andere Rechner verändern den Wert auf 255 oder auf einen Wert, der durch ein übergeordnetes Protokoll des TCP/IP-Protollstacks vorgegeben wird (bspw. arbeitet Telnet mit einen TTL-Wert von 60 oder 30).
Theoretisch ist es also möglich, dass ein Rechner per ping erreichbar ist, der Kontakt via Telnet aber scheitert (wegen des zu geringen TTL-Wertes von Telnet). Praktisch wird ein solcher Fall kaum auftreten, da eine Vermittlung über mehr als 30 Router ein sicheres Indiz für eine Fehlkonfiguration ist (eine Schleife).
Optionen zur Beeinflussung der Testdaten
Im Abschnitt Netzwerkprotokolle finden Sie eine Beschreibung des Aufbaus eines ICMP-Protokollkopfes. Uns interessiert im Folgenden das in der dortigen Skizze als »Optionale Daten« bezeichnete Feld. Dessen Gröszlig;e findet sich in der Ausgabe des ping-Kommandos wieder:
user@sonne> ping -c 1 localhost | head -1
|
Per Voreinstellung verpackt ping 56 Bytes Daten in ein Paket. Dieser Wert trägt auch zur zweiten, in Klammern stehenden Angabe bei. Diese 84 Bytes im Beispiel errechnen sich aus den 20 Bytes des IP-Protokollkopfes, aus 8 Bytes, die Laufzeitinformationen des Pakets enthalten und eben den 56 Datenbytes.
Die Paketgröße ist konfigurierbar:
| -s Paketgröße | ||
| Setzt die Größe des Datenpakets auf den angegebenen Wert (in Bytes). | ||
Die Option eignet sich insbesondere zur Diagnose von Netzwerkproblemen, die auf Probleme mit der Paketgröße hindeuten.
user@sonne> ping -c 1 -s 0 localhost | head -1
|
In letztem Beispiel provozierten wir einen Überlauf, indem wir ein für IP zu großes Datenpaket verwendeten (das Maximum ist fest im Programm implementiert, da hilft auch keine Änderung an der MTU).
Selbst das Muster der Testdaten kann per Option eingestellt werden:
| -p Muster | ||
| Muster ist ein 16 Bytes großer Wert, der als Hexadezimalzahl anzugeben ist. »-p FF« führt zu Testdaten, die aus einer Folge von 1-Bits bestehen. | ||
user@sonne> ping -p xx localhost
|
Optionen zum Routing
Ein ausbleibendes ECHO_REQUEST muss nicht den Ausfall des Zielrechners bedeuten. Ebensogut könnte einer der Vermittlerstellen (Router, Gateway,...) streiken. Die Aufzeichnung der Wegstrecke, die ein Paket passierte, kann unter Umständen weiter helfen:
| -R | ||
| Aufzeichnen der Hin- und Rückroute, die ein ICMP-Paket durchläuft. | ||
user@sonne> ping -c 2 -R lkap1073
|
Die Erreichbarkeit aller Rechner eines Netzwerks kann mit einem Broadcast erreicht werden:
| -b | ||
| »Broadcast-Ping« an alle Rechner eines angegebenen Netzwerks. | ||
Da alle Rechner einunddasselbe Paket erhalten, entstehen Duplikate bei der Antwort, die ping durch ein nachgestellten DUP! in der Ausgabe kennzeichnet:
user@sonne> ping -b -c 2 187.0.34.0
|
| Das Kommando traceroute/tracepath |
|
Traceroute oder Ping?
»Ping« in Verbindung mit der Option »-R« erfüllt scheinbar dieselben Aufgaben wie »traceroute«. Jedoch existieren entscheidende Einschränkungen.
Zunächst vermag »Ping« nur maximal 9 Stationen (»Hops«), die ein Paket durchläuft, aufzuzeichen. Für mehr ist einfach kein Platz in einem ICMP-Request-Paket. Sie können das Verhalten leicht nachvollziehen, wenn Sie nur einen Zielrechner wählen, der »weit genug« entfernt ist:
user@sonne> ping -R -c 1 www.heise.de
|
Erst »traceroute« zeigt die fehlenden Zwischenstationen auf:
user@sonne> /usr/sbin/traceroute www.heise.de
|
Ist der Zielrechner nicht erreichbar, bleibt Ihnen »ping« eine Antwort schuldig. Mit »traceroute« hingegen können Sie mit einiger Sicherheit den Streckenabschnitt identifizieren, der das Problem verursacht.
Und schließlich ermöglicht erst »traceroute« eine Analyse der Laufzeiten der Pakete und die Identifikation eventueller Leistungsengpässe im Netz.
Die Arbeitsweise von Traceroute
Abbildung 1: Die Arbeitsweise von Traceroute
Zwei Techniken kommen zum Einsatz. Zum einen ist dies die Variation des Time-to-live-Feldes der UDP-Testpakete. Erinnern Sie sich an die Aufgabe dieses TTL-Feldes, das verhindern soll, dass fehl geleitete Pakete ewig im Netz kursieren. Jeder Rechner, den ein Paket passiert, inkrementiert hierzu den Wert des Feldes. Sinkt der Wert auf Null, wird der aktuelle Rechner, insofern er nicht das Ziel markiert, das Paket verwerfen und eine Fehlermitteilung an den Absender initiieren (ICMP-Meldung »Time excceded«). »Traceroute« erzwingt eine solche Fehlernachricht von jeder Zwischenstation, die das Paket durchläuft.
Auf dem Zielrechner kontaktiert »Traceroute« den Port 33434. In der Regel wartet niemals ein Programm auf diesem Port, sodass der Rechner den Verbindungswunsch als Fehler interpretiert und seinerseits mir der ICMP-Mitteilung »Unreachable Port« antwortet. Hieran erkennt »Traceroute« das Erreichen des Ziels.
Aus Effizienzgründen sendet »Traceroute« zu einer Zeit gleich mehrere UDP-Pakete aus (im Beispiel aus Abbildung 1 sind es 6). Des Weiteren wird in der Voreinstellung jedes Paket genau drei Mal versandt, um zum Einen eine gewisse Resistenz gegenüber Fehlern zu wahren (bspw. darf ein Router bei &Uuuml;berlastung Pakete verwerfen, ohne entsprechende Fehlerpakete auszusenden) und zum Anderen mehrere Zeitmessungen vorzunehmen (um »Ausreißer« zu markieren). Fehlversuche kennzeichnet »Traceroute« mit einem Stern (*). Es ist durchaus mölgich, dass »Traceroute« einen Weg zum Ziel findet, obwohl ein Zwischenrechner scheinbar nicht erreichbar ist (nur Sterne in der Ausgabe). Ursachen sind zumeist Fehler in »Traceroute«-Implementierungen mancher Unix-Systeme, die dazu führen, dass die »Time exceeded« Fehlermitteilung den Absender nicht erreichen.
Anmerkung: Manche Netzwerkrouter können so konfiguriert werden, dass sie »Traceroute«-Pakete ignorieren, d.h. sie weiter leiten, ohne das TTL-Feld anzutasten. Deshalb muss die aufgezeichnete Route nicht vollständig sein (eine Option -R, um auch solche Router aufzuzeichnen, existiert zwar, ist jedoch in der aktuellen Version nicht implementiert).
Die Optionen
Optionen zur Steuerung des Sendeverhaltens
| -q <Anzahl> | ||
| In der Voreinstellung versendet »Traceroute« je drei UDP-Pakete je Time-to-live-Wert. Mit der Option -q kann jeder anderer Wert vorgegeben werden. | ||
user@sonne> /usr/sbin/traceroute -q 4 www.heise.de | head -4
|
Anmerkung: In einigen (älteren) Programmversionen stürzt »Traceroute« bei hohen Werten mit einen Segmentation fault (Speicherschutzverletzung) ab oder es verweigert das Setzen des TTL-Wertes. Eine Aktualisierung auf die neueste Version behebt die Ursachen.
| -w <Anzahl> | ||
| »Traceroute« sendet in der Voreinstellung sechs Pakete quasi parallel mit jeweils verändertem Time-to-live-Wert aus (im ersten Schritt mit TTL=1..6, im zweiten Schritt mit TTL=7..12 usw.). Trifft die letzte Antwort ein, wird die nächste Welle von Paketen ins Rennen geworfen. Mit der Option -w kann eine Zeitspanne fest gelegt werden, die zwischen dem Aussenden zweier Sondierungspakete zu warten ist (Angabe in Sekunden). | ||
| -N <Anzahl> | ||
| Die Voreinstellung von sechs gleichzeitig zu sendenden Paketen kann hiermit verändert werden. Beachten Sie, dass sehr hohe Werte zwar die Routenfinding durchaus beschleunigen können, gleichzeitig jedoch den Netzwerkverkehr extrem erhöhen. Spätestens wenn Fehlermeldungen der Art »ICMP rate throttling« vermehrt austreten, sollten Sie ein solches Vorgehen vermeiden, um nicht Auml;rger mit Ihren Netzwerkadministratoren heraufzubeschwören. | ||
| -f <Start-TTL> | ||
| Wenn Sie die Route zu einem weit entfernten Ziel verfolgen und genau wissen, dass die ersten Stationen zuverlässig arbeiten, dann können Sie deren Test auslassen, indem Sie mit einem höheren Startwert für das »Time-to-live«-Feld beginnen. | ||
| -F | ||
| Im IP-Protokollkopf wird das Don't Fragment-Bit gesetzt. Router dürfen ein solches Datenpaket nicht weiter splitten, auch wenn es für das folgende Teilnetz zu groß sein sollte. Sie sind gezwungen, dieses zu verwerfen und eine Fehlermeldung an den Absender zu verschicken. | ||
| -m <max_hops> | ||
| Der maximale Wert für TTL, mit dem Pakete ausgesendet werden, liegt bei 30. Die Option -m gestattet das Setzen dieser Grenze. Schon der Wert von 30 erscheint recht hoch; es ist unwahrscheinlich, dass zwischen zwei Rechnern mehr Zwischenstationen liegen, es sei denn, irgendwo im Routing liegt eine Fehlkonfiguration vor. | ||
user@sonne> /usr/sbin/traceroute -n -m 3 www.heise.de
|
Optionen bezüglich der gewählten Route
| -I <Interface> | ||
| Verfügt ein Rechner über mehrere Netzwerk-Schnittstellen (mehrere Netzwerkkarten, Modem, ISDN-Karte...), so muss die zu verwendende Schnittstelle angegeben werden, insofern es sich nicht um die erste Schnittstelle handelt (Vergleichen Sie die Reihenfolge der Ausgabe von ifconfig). | ||
| -S <Quell-IP> | ||
| Für einen Rechner mit mehreren IP-Adressen, kann mit der Option -S die als Absender zu verwendende Adresse angegeben werden. | ||
| -g <Gateway> | ||
| Fügt dem ausgehenden Paket die »IP source routing Option« hinzu, womit eine Route durch das angebene Gateway zu wählen ist. Etliche Route ignorieren jedoch aus Sichereitsgründen diese Option. | ||
| -t <Type of Service> | ||
|
Zahlreiche Implementierungen des IP-Protokoll-Stacks ignorieren diese Option, die das Routing derart
beeinflussen soll, dass Routen mit bestimmten Eigenschaften bevorzugt gewählt werden. Mögliche Werte
sind 0 (Voreinstellung), 1 (Route mit den geringsten Kosten), 2 (Route mit höchster
Zuverlässigkeit), 4 (Route mit höchstem Durchsatz), 8 (schnellste Route) und 16 (Route mit höchster
Sicherheit. Der praktische Nutzen dieser Information steigt und fällt mit den den Routern zur Verfügung stehenden Informationen. Das Setzen der Option ist nur Root möglich. |
||
Weitere Optionen
| -n | ||
| Verhindert die Namensauflösung von IP-Adressen, d.h. die Zwischenstationen werden stets mit ihrer IP-Adresse angegeben. | ||
user@sonne> /usr/sbin/traceroute -n www.heise.de
|
| -4 | ||
| Erzwingt die Verwendung von IP-Adressen nach Version 4 (ipv4). | ||
| -6 | ||
| Erzwingt die Verwendung von IP-Adressen nach Version 6 (ipv6). | ||
| Paketlänge | ||
| Der zwischen 1 und 65536 liegende Wert (Voreinstellung 40 Bytes) kann hinter der Angabe des Zielrechners auf der Kommandozeile folgen. In Verbindung mit der Option -F besteht so eine Möglichkeit, die Maximale Transfereinheit (MTU) zu ermitteln. | ||
Anmerkung: Die Optionen -4 bzw. -6 erübrigen sich, wenn der Zielrechner als IP-Adresse angegeben wird. In dem Fall entscheidet »Traceroute« anhand des Adressformats, nach welchem Mechanismus vorzugehen ist.
tracepath
Für Fälle, in denen es einzig um den Test des Routenverlaufs geht, ist »Traceroute« mit der Fülle seiner Optionen quasi überqualifiziert, zumal etliche Optionen die Rechte des Administrators bedingen. Oft genügt tracepath, das keine Optionen kennt und vom »jedem« Benutzer verwendet werden darf. Neben der Angabe der Zieladresse kann optional der zu verwendende Port vorgegeben werden. Ohne diesen wählt »Tracepath« zufällig einen Port aus einem definierten Pool (i.d.R.) ungültiger Portnummern aus.
user@sonne> /usr/sbin/tracepath www.heise.de
|
| Das Kommando arp |
|
Der ARP-Cache des Kernels
Während im Internet Pakete anhand ihrer IP-Adresse vermittelt werden, erfolgt in lokalen Netzen die Adressierung mittels Hardwareadressen. So besitzt jede Ethernetnetzwerkkarte eine (weltweit) eindeutige 48 Bit lange Adresse. Das Ermitteln der Hardwareadresse des Rechners zu einer gegebenen IP-Adresse erfolgt durch das Address Resolution Protocol.
Einmal ermittelte Zuordnungen speichert der Linuxkernel in einem internen Zwischenspeicher (»arp-Cache«), um wiederholte Anfragen ohne teure Rechercheoperationen bedienen zu können. In der üblichen Konfiguration stehen 256 Einträge im Cache zur Verfügung. Lange Zeit nicht verwendete Adressen werden nach einer maximalen Verweildauer oder bei Bedarf (voller Cache) entfernt.
Mit dem Kommando arp steht dem Administrator ein Werkzeug zur manuellen Inspektion und Manipulation des Arp-Caches zur Verfügung.
Die Optionen
Optionen zum Betrachten des Arp-Caches
Für den Fall, dass ein Rechner via Netzwerk nicht erreichbar ist, kann ein Blick in den Arp-Cache helfen, um Probleme auf Hardwareebene auszuschließen. Vorhandene Einträge (die nicht manuell eingefügt wurden) sind sichere Anzeichen für eine funktionierende Anbindung.
user@sonne> arp
|
Eine an die arp-Implementierung auf BSD-Systemen angelehnte Form der Ausgabe vermag arp ebenso zu erzeugen.
| -a | ||
| Anzeige gemäß des Formats der BSD-Implementierung. | ||
user@sonne> arp -a
|
Auch zur Ausgabe erweiterter Informationen und zur Anzeige numerischer Adressen anstatt Rechnernamen stehen Optionen zur Verfügung.
| -n | ||
| Adressen werden in numerischer Form wiedergegeben. | ||
| -v | ||
| Ausführlichere Ausgaben. | ||
user@sonne> arp -vn
|
| -H Typ | ||
| Beschränkung auf Einträge des angegebenen Schnittstellentyps. Voreinstellung ist ether (Ethernet). Weitere mögliche Werte sind arcnet (ARCnet), ax25 (AMPR AX.25), dlci (Frame Relay DLCI), fddi (Fiber Distributed Data Interface), hippi (HIPPI), irda (IrLAP), netrom (AMPR NET/ROM), pronet (PROnet), strip (Metricom Starmode IP), tr (16/4 Mbps Token Ring) und x25 (generic X.25). | ||
| -i <Schnittstelle> | ||
| Die Anzeige beschränkt sich auf Einträge der angegebenen Netzwerkschnittstelle (nur bei Rechnern mit mehreren Schnittstellenkarten sinnvoll). | ||
| Das Kommando netstat |
|
| Das Kommando route |
|
| Das Kommando ifconfig |
|
| Das Kommando bing |
|
| Das Kommando nmap |
|
Korrekturen, Hinweise?