| orm@doc-tcpip.org | Erstellt: April 1999 - Letzte Modifikation: Juli 2010 |
Die Netz- und TCP-Parameter basieren auf AIX 4.3.2 (ML04). Alle weiteren Parameter, die danach dazu gekommen sind, finden sich also nicht an derselben Stelle wie in der Ausgabe von no -a sondern am Ende der Liste, so wie sie mit neuen Maintenance Leveln und Releases hinzukommen. Die Standard- bzw. Default-Werte habe ich nur in Ausnahmefällen angegeben. Diese Werte ändern sich von Version zu Version und man sollte sie am Besten auf dem System direkt nachsehen.
Mit AIX V5.2 hatten die Entwickler ein Einsehen - die Parameter sind jetzt alphabetisch geordnet (teilweise mit funktionalen Modifikationen). Ausserdem wurde endlich eine einheitliche Schnittstelle für alle Tuning-Parameter geschaffen - dazu mehr auf einer eigenen Seite.
Auch ich hatte ein Einsehen, daher gibt es jetzt zusätzlich eine Tabelle in Alphabetischer Ordnung, nach denen nach AIX Version geordneten Tabellen.
Mit AIX 6 sind ein paar Parameter als restricted geführt, die erscheinen dann nicht mehr im normalen Listing, man muß zusätzliche Flags mitgeben. Ändert man diese Parameter, so wird das geloggt und man muß mehrfache Sicherheitsabfragen beantworten.
| sack | use_isno | tcp_newreno | tcp_nagle_limit |
| rfc2414 | tcp_init_window | tcp_ecn | tcp_limited_transmit | dgd_packets_lost | dgd_retry_time |
| dgd_ping_time | passive_dgd | sodebug | tcp_bad_port_limit | udp_bad_port_limit | icmp6_errmsg_rate |
| tcp_maxburst |
| tcp_nodelayack | tcp_finwait2 |
| nbc_ofile_hashsz | tcp_inpcb_hashtab_siz | tcp_keepcnt | udp_inpcb_hashtab_siz |
| mpr_policy | ndd_event_name | ndd_event_tracing | net_buf_size | net_buf_type | pmtu_expire |
| use_sndbufpool |
| ip_ifdelete_notify | ip_nfrag | sodebug_env | tcp_icmpsecure | tcp_tcpsecure |
| tcp_low_rto | tcp_nagleoverride | tcprexmtthresh | timer_wheel_tick |
| net_malloc_frag_mask | netm_page_promote | tcptr_enable | tn_filter |
Schaltet zwischen ausführlichen und verkürztem netstat Output hin- und her. Die ausführliche Ausgabe beinhaltet Buffer-Statistiken pro CPU und kostet einiges an Performance. Daher ist Default, das extendednetstats in der /etc/rc.net auf 0, also aus, gesetzt wird. für Testzwecke kann man das ändern, muß aber dann rebooten - sonst sind die Werte ungültig. Ist seit AIX V6 ein Restricted tunable.
Setzt die Grenze des Bereiches im Hauptspeicher, den die
Networkservices für sich beanspruchen dürfen. Steht normalen Prozessen
normalerweise zur Verfügung, diese werden aber ausgepaged,
sobald die Networkservices den Platz beanspruchen. Das ist alles
dynamisch, und das System vergibt die Hälfte des Hauptspeichers für
diesen Zweck - bis zu einem Maximum von 1 GB (Das hängt von der
Architektur ab. Auf non-CHRP Architekturen ist 256 MB das
Maximum). Es gibt keinen guten Grund mehr, warum man den
Default-Wert noch verändern sollte.
Und es ist mittlerweile gekommen, wie es kommen mußte: ab
AIX 5.1
gibt es nichts mehr einzustellen
- thewall ist die Hälfte vom
Hauptspeicher und damit basta (obwohl der Parameter noch existiert).
Dieser Schwellenwert bezieht sich auf thewall. Es ist ein Teil in Prozent. Ist dieser Anteil belegt, so werden keine neuen Verbindungen von außen akzeptiert, und interne Socket-Aufrufe scheitern mit dem "no mbufs" Fehler (ENOMBUFS). Dient dazu, die Funktion der laufenden Verbindungen zu sichern. Root kann noch neue Verbindungen öffnen. Der Default-Wert liegt bei 85% von thewall.
Gibt eine Obergrenze für die Menge an Puffer, die
ein Socket (eine Verbindung) benutzen darf. Einige
Applikationen (z.B. iptrace) brauchen mindestens 1 MB. Normalerweise
berechnet man den richtigen Wert aus den Send- und Receive-Spaces, denn
im Falle eines Hängers auf dem Netzwerk laufen diese Buffer voll (da TCP
ja weitersenden darf). Also muß
dieser Wert richtig angepasst werden - er muß größer sein als der
theoretisch größtmögliche Socket. Also eine der folgenden
Kombinationen:
tcp_sendspace + tcp_recvspace
udp_sendspace + udp_recvspace
Die Applikation mit der größten Summe von setsockopt(SO_RECVBUF)
und setsockopt(SO_SNDBUF)
Die größe der Sockets bezieht sich direkt auf thewall: teilt man
thewall durch den Wert von sb_max, so erhält man einen
guten Wert für die Anzahl der möglichen Verbindungen, die im
schlechtesten Fall funktionieren würden. Es wird dabei außer Acht
gelassen, das Puffer auch noch durch andere Dinge verbraucht werden
(Routing, Terminals etc.) - aber es ist eine gute Näherung.
Die Länge des Listen Backlogs. Die Routine, die einen
Socket überwacht, also auf einem Port auf Verbindungen wartet,
ist die listen() Subroutine. Der betroffen Port/Socket
ist dann im State LISTEN (aus TCP-Sicht). Das Backlog kommt
dann zustande, wenn viele Verbindungen auf einem Port/Socket
auflaufen, und die Routine nicht nachkommt. Diese Verbindungen
werden dann im Backlog in eine Warteschlange gestellt.
Mit somaxconn kann man dieses Backlog beschränken.
Es gilt der Wert von somaxconn oder von
SOMAXCONN (aus /usr/include/sys/socket.h),
welcher von beiden kleiner ist.
Da laut listen()-man-page die Subroutine eine Maximale
Queue Länge von 10 kennt, ist das bei AIX offensichtlich
deutlich erweitert worden.
Will eine ferne Maschine mit uns eine TCP-Session öffnen, so
geschieht das mit dem Senden eines SYN-Paketes. Das wird in eine
Warteschlange gestellt, und eine Antwort wird von uns gesendet - ein
SYN/ACK Paket. Wir erwarten dann für eine gewisse Zeit ein ACK auf
dieser Verbindung, um das Paket aus der Queue zu löschen und die
Verbindung in den Status ESTABLISHED zu setzen.
Das kann man nun in einer Denial of Service Attacke ausnutzen
(sogenanntes SYN-Flooding). Dabei wird der Rechner mit
SYN-Paketen zugemüllt, seine Warteschlange füllt sich und neue,
vielleicht berechtigte Anfragen, werden fallengelassen. Mit diesem
Parameter kann man die Zahl der gequeueten SYN-Pakete spezifizieren, die
bei voller Queue nach dem Zufallsprinzip gelöscht werden. Aktive
Webserver profitieren von diesem Parameter unter Umständen.
Setzt man diesen Parameter, so wird im Kernel ein Puffer angelegt, in dem Informationen zum Speichermanagement des Netzwerkes (mbufs etc.) abgelegt werden (wenn Speicher allokiert oder frei gemacht wird - Trace-Hook HKWD_NET_MALLOC). Dann funktioniert im crash bzw. kdb-Kommando (der Kernel Debugger) das netm Subkommando. Ist seit AIX V6 ein Restricted tunable.
rto_limit ist die Anzahl der Schritte zwischen den eingestellten Werten für rto_high und rto_low. In dem Augenblick, wo man rto_limit Retransmissions gesendet hat, ist der Timeout gleich rto_high - er steigt nicht mehr.
Der Parameter rto_length gibt die gesamte Anzahl an Retransmissions an, die gesendet werden. Daher muß rto_limit immer kleiner als rto_length sein. Sonst setzt der Algorithmus rto_limit auf den größten möglichen Wert, also rto_length. Hier der Zusammenhang im Bild:
. low high . | | | | | | | | | | | | | | . == . Limit <-----------------------Length------------------------->All diese Werte sind keine Zeiteinheiten, sondern Vielfache der gemittelten Rundlaufzeiten, die das TCP errechnet hat, die "smoothed round trip time".
Telnet bricht erst dann ab, wenn die darunterliegende TCP-Verbindung abbricht. Das hängt von der Anzahl der gewählten Retransmissions ab, was der no-Parameter "rto_length" wiederspiegelt.
Ein Beispiel Meine TCP Verbindung hat lange gut funktioniert, und ich
habe eine RTT von Z Sekunden. Jetzt sind alle rto-Werte auf
Standardwerte gesetzt, also gilt:
rto_low = 1
rto_high = 64
rto_limit = 7
rto_length = 13
Bei einer berechneten RTT von Z wird also bei einem fehlenden
ACK auf ein gesendetes Paket nach Z Sekunden dieses Segment
neu gesendet. Jetzt ist der Bereich zwischen Low und High in
7 Teile geteilt, was einen Intervall von 9 ergibt. Kommt
auf das neu gesendete Paket auch kein ACK innerhalb von 9*Z
Sekunden, so wird nochmal gesendet. Jetzt wird 18*Z Sekunden
gewartet. Das wiederholt sich solange, bis man den High-Wert
erreicht. Der Timeout ist jetzt 64*Z Sekunden und 8 Pakete
sind ohne Antowrt gesendet worden. Jetzt werden mit diesem
Timeout (64*Z Sek.) bis maximal 13 Pakete verschickt.
Dann wird die Verbindung als verloren betrachtet und
der Socket geschloßen.
Kommt eine Antwort, also ein ACK, so wird mit dem hohen Timeout solange weitergesendet, bis wieder ein sicherer Messwert für die RTT zur Verfügung steht - es muß in jedem Fall verhindert werden, daß RTT über wiedergesendete Pakete berechnet werden. Nach der ersten guten Messung wird diese RTT genommen und die Zähler zurückgesetzt.
Konfiguriert die Größe (in KB) der inet interrupt stack table. Ist nur dann nötig, wenn ein Debug-Kernel oder eine Debug-Netinet Kernel-Extension eingesetzt wird. Es ist ein Reboot nötig. Ist seit AIX V6 ein Restricted tunable.
Spezifiziert die Anzahl der möglichen ARP Einträge in der
Kernel-Tabelle. Die Tabelle besteht aus einer Anzahl Buckets (Eimer)
einer bestimmten Größe. Die gesamte Anzahl der möglichen Einträge ist
das Produkt Anzahl der Buckets mal deren Größe, also arptab_nb *
arptab_bsiz. Man muß daran denken, das 3 Einträge pro Bucket für
statische Einträge reserviert sind. Ist die Kapazität erschöpft, so
werden die ältesten Einträge vor dem Ablauf der in arpt_killc
spezifizierten Zeit gelöscht und durch neue ersetzt. Es ist gute
Administrations-Praxis, die ungefähre Anzahl der Hosts zu ermitteln, mit
denen eine Maschine kommuniziert (mit dem Kommando arp -a |
wc -l) und wenn diese Zahl sich den maximal Möglichen
Einträgen nähert, das Fassungsvermögen der ARP-Table zu vergrößern.
Dieser Parameter ist ein loadtime attribute es ist also ein
Eintrag in die /etc/rc.net und ein Reboot nötig
(Kernel-Tabelle!).
Die Anzahl der Pakete, die während des Wartens auf eine ARP-Antwort gequeued werden. Ist normalerweise 1, wird auf höhere Werte gesetzt bei aktiven Servern oder bei eingeschaltener Path MTU Discovery (5).
Die Zeit, die ein nicht benutzter ARP-Eintrag in der ARP-Table gehalten wird. Danach wird der Eintrag gelöscht. Einträge werden früher gelöscht, wenn die Tabelle zu klein und der Verkehr groß ist. Auf Servern mit sehr aktiven, kurzen Verbindungen zu anderen Maschinen (z.B. DNS-Server) kann diese Zeit verkleinert werden. Oder auf Netzwerken, wo die Zuordnung von IP und MAC sich schneller ändert (wenig wahrscheinlich).
Spezifiziert die Anzahl der Network Interface Daten-Strukturen pro Interface Typ. Standard ist 8, ab V5.2 256. Auf Deutsch heißt das: "Network Interface" ist das Interface zum Device Treiber (tok oder ent), und "Interface" ist das Protokol Interface (tr oder en). Pro Protokol kann ich also maximal 8 Adapter unterstützen, im Fall von Token Ring tr0 bis tr7. Habe ich mehr Adapter eines Protokol-Typs, muß ich diesen Wert hochsetzen und booten. Ab 4.3.2 erkennt das System, wenn mehr Adapter da sind und legt entsprechend viele Datenstrukturen an - der Parameter ist also obsolet.
ndpqsizesend_file_duration
Die Größe des Network Buffer Caches in KB. Der Network Buffer Cache liegt innerhalb von Thewall und wird im Default-Fall aus Thewall errechnet. Wenn der Network Buffer Cache vollläuft, werden die ältesten Einträge gelöscht bzw. überschrieben.
Man kann für jeden Cache Eintrag eine maximale Größe definieren (in KB). Größere Einträge werden in sogenannten privaten Segmenten gespeichert. Sind solche Segmente nicht definiert, wird der Eintrag nicht gecached.
Das ist die minimale Größe für jeden Cache Eintrag. Kleinere Einträge werden nicht gecached.
pseg Specifies the maximum number of private segments that can be created for the Network Buffer Cache. The default value is 0. When this option is set at non-0, a data object between the size specified in nbc_max_cache and the segment size (256MB) is cached in a private segment. A data object bigger than the segment size is not cached at all. When the maximum number of private segments exist, cache data in private segments may be flushed for new cache data so that the number of private segments do not exceed the limit. When nbc_pseg is set to 0, all cache in private segments are flushed. This attribute only applies to AIX 4.3.3 or later. nbc_pseg_limit Specifies the maximum amount of cached data size allowed in private segments in the Network Buffer Cache. This value is expressed in KBytes. The default value is half of the total real memory size on the running system. Since data cached in private segments are pinned by the Network Buffer Cache, nbc_pseg_limit controls the amount of pinned memory used for the Network Buffer Cache in addition to the network buffers in global segments. When the amount of cached data reaches this limit, cache data in private segments may be flushed for new cache data so that the total pinned memory size doesn't exceed the limit. When nbc_pseg_limit is set to 0, all cache strmsgsz strctlsz nstrpush strthresh psetimers psebufcalls strturncnt pseintrstack lowthresh medthresh
Sind die tunbaren Parameter des STREAMS-Subsystems.
Streams sind der bevorzugte
Weg, zwischen Kernel- und User-Space zu kommunizieren.
Das trifft z.B. zu, wenn mehrere Prozesse oder Threads
Information austauschen wollen. Die Information
wird per "message queueing" transportiert - daher
beziehen sich die meisten Parameter auf diese "messages".
Die Parameter werden in der Regel nur diejenigen
Interessieren, die sich sehr nah an diesen
Dingen bewegen - in der "normalen" Administration ist
hier wahrscheinlich kein Eingriff nötig.
Zwei der Parameter (nstrpush, pseintrstack) sind
load-time attribute, werden also nur beim Start
des STREAMS Subsystemes angezogen. Der Rest
ist sofort aktiv.
Ein System-Call kann STREAMS Daten übergeben, die dann in eine Message gepackt werden. Dieser Parameter gibt die maximale Größe in Byte pro System-Call an.
Dasselbe für den Control-Teil der Message.
Gibt eine obere Grenze für die Menge an Platz, den STREAMS benutzten darf. Wird die Schwelle überschritten, so wird ein Fehlercode zurückgegeben (ENOSR). Der Wert ist eine Angabe in Prozent, bezogen auf thewall. Das ist mit einer der Gründe, warum sich bei erreichen von thewall nur noch root einloggen kann - er ist priviligiert.
Anzahl der Timer, die von den STREAMS Modulen angestoßen werden können.
Anzahl der Buffer, die STREAMS beim Starten vorhält.
Ist seit AIX V6 ein Restricted tunable.
Damit läßt sich der "streams memory cache" an- und abschalten. Das trifft nur für Systeme mit einem Prozessor zu - und auf diesen sollte man diesen Cache immer benutzten (1 ist an und 0 ist aus..).
Setzt die maximale Lebensdauer eines RIP Paketes in Sekunden. Standard sind 255 Sekunden, was man entsprechend anpassen kann.
Setzt die Lebensdauer eines IP-Fragmentes. Standard sind 60 Halbsekunden, also 30 Sekunden. Können in dieser Zeit nicht alle Fragmente empfangen werden, so wird das ganze Segment verworfen und muß neu gesendet werden.
Legt fest, ob der Kernel ICMP Redirects schicken soll oder nicht. Bei Wert 1 macht der Kernel den Sender mit einem Redirekt darauf aufmerksam, das er für ein bestimmtes Ziel nicht der beste Router ist: Hat man die Rechner A, B und C im selben Netz und trägt dann auf A eine Route über B nach C ein (was völlig Blödsinnig ist, denn A kann ja direkt mit C kommunizieren) so wird B auf das erste Paket von A nach C mit einem Redirekt reagieren und sagen, das A besser direkt mit C redet. Die Route auf A wird dann modifiziert (Flags M oder D). Bei Point to Point Strecken sorgt das manchmal für Probleme.
Schaltet IP-Forwarding an. Dann ist der Kernel willig, ein Paket mit seiner MAC-Adresse, aber einer anderen IP, anhand seiner Routing Tabelle weiterzuleiten. Die Maschine funktioniert dann als Router/Gateway. Das sollte auf normalen Workstations auf 0 stehen - wenn Maschinen, die es nicht sollen trotzdem Routen, dann vertuscht das leicht schwere Fehler im Netz.
Entscheidet, ob die Maschine auf empfangene Redirekts reagieren soll oder nicht. Wie oben schon ausgeführt, sind ICMP Redirects ein wichtiger Bestandteil der Fehlerkorrektur in Netzen und sollten nur im Spezialfall ausgeschaltet werden.
Entscheided, ob diese Maschine es zuläßt, das Pakete mit der sourceroute-Option gesendet werden können. Dabei bestimmt der Sender, welchen Weg das Paket zu gehen hat. Es gibt strict und loose Sourcerouting (Im ersten Fall muß hin- und Rückweg gleich sein, im zweiten Fall kann der Rückweg ein anderer sein. Stellt man 0 ein, so bekommt eine Applikation, die einen Socket mit Sourcerouting öffnen möchte, einen Fehler (der von setsockopt generiert wird). Hacker können mit Sourcerouting Sicherheitsbarrieren umgehen.
Soll die Maschine gesourceroutete Pakete annehmen? Das sollte man nicht tun, weil die Pakete mit böser Absicht kommen können. Daher ein Default von 0.
Soll diese Maschine gesourceroutete Pakete forwarden oder nicht? Standard ist 1, also ja. Das Sicherheits-Problem haben ja andere.
Setzt den Default-Wert für den hop-count bei IPv6 Paketen. Wird von Setzungen beim Öffnen des Socket überspielt. Ist ein dyniamscher Parameter.
Spezifiziert die Lebensdauer für ein UDP Paket. Standard sind 30 Sekunden (Hops).
Send- und Receive-Space von TCP. Eingestellter Wert: 16384 Byte.
Dazu etwas ausführlicher:
TCP sorgt für einen kontinuierlichen Datenstrom. Dieser wird in einzelnen
Paketen auf das Netz gegeben, wobei die Pakete gezählt werden und ein Austausch
besteht, ob ein Paket angekommen ist oder nicht. Daher muß der Sender jedes
Paket solange speichern, bis er von der anderen Seite hört, das es empfangen
wurde. Da es Unsinn wäre, jeweils nur ein Paket zu schicken, eine Antwort
zu erwarten, und dann das nächste Paket zu schicken, einigen sich beide Seiten,
wieviel Pakete/Daten auf dem Netz, also unkontrolliert, vorliegen dürfen.
Im Prinzip sind diese "Fenster" eine Art Puffer. Im Fall des Receive-Space
ist es eine Art Kredit, dem man der anderen Seite gibt: Soviel darf diese
senden, ohne ein ACK abwarten zu müssen - weil wir sicher sind, das wir
so viele Daten Zwischenspeichern und Handlen können. Der Sendspace ist somit
der persönliche Kreditrahmen des Senders, auch wenn der Empfänger mehr anbietet.
Dabei ist zu beachten, das sich der Kredit an der vorhandenen Geldmenge
orientieren muß. Jede Verbindung hat ein gewissen Fassungsvermögen, das sich
aus dem Produkt von Bandweite und Verzögerung ergibt. Zu große Fenster führen
dazu, daß im Fall eines Hängers auf dem Netzwerk TCP erstmal fröhlich
weitersendet
- es hat ja einen großzügigen Kredit. Diese Pakete hauen dann die Queues zu
und gehen verloren, sorgen so für Retransmissions usw.
Es ist oft so, das eine Anpassung der Fenster eine Verbesserung der Performance
zur Folge hat.
Die Angabe erfolgt in Byte, und sollte pro Interface erfolgen. Applikationen
können per Socketaufruf eigene Werte setzen.
Standard ist 512 Byte.
Das ist die Default Maximum Segment Size für eine Verbindung zu einem
nicht lokalen Netz, also ein Netz mit einer anderen IP. Subnetze kann man
mit "subnetsarelocal" als lokale Netze definieren. Dann ist alles Lokal, was
dieselbe Subnetz-Maske hat.
Das ist häufig ein Problem mit FTP, also großen Datenübertragungen am Stück.
Es wird dann, unabhängig von den MTUs der beteiligten Netze, dieser Wert
angezogen - und das ist meist zu klein. Man muß also genau schauen, welche
MTU wirklich die kleinste ist, und diese dann hier angeben.
Bitte beachten, das es sich hier um die Maximum Segment Size handelt, also
um die reine Nutzlast! IP Header müssen von der effektiv vorhandenen MTU
abgezogen werden.
Besser ist natürlich PMTU Discovery (tcp_pmtu_discover).
Normalerweise unterscheidet IP zwischen lokalem Netz und remotem Netz aufgrund der Netzwerkaddresse. Ist die Netzwerkadresse des Zieles gleich der eigenen, dann ist es lokal, und sonst remote. Lebt man auf einem weiter eingeteilten Netz, ist das wenig sinnvoll, da schon der Rechner auf dem anderen Tisch in einem anderen Subnet sein kann. Setzt man diesen Parameter auf 1, dann dndert IP sein Kriterium und betrachtet alle Adressen mit derselben Netzmaske als lokale Adressen.
Standard ist 1, also an.
Damit werden die TCP Performance Enhancements angeschaltet.
Diese Techniken sind im RFC 1323 im einzelnen beschrieben.
Es sind:
Window Scale Option - Mehr als 16 Bit für die Größe des Fensters.
Fast Retransmit - Es wird nicht mehr 500 msec gewartet, sondern nach 3 ACK für diesselbe Sequenznummer sofort neu gesendet.
Fast Recovery - Es wird nicht ein ganzer "Slow Start" durchgeführt.
Timestamp Mechanismus - Die Pakete bringen einen Zeitstempel mit. Das ermöglicht eine bessere Abschätzung der RTT (Round Trip Time).
Der Intervall der Keepalive Pakete in Halbsekunden. Standard ist 150, also 75 Sekunden.
Standard ist 14400 Halbsekunden (2 Stunden).
Folgendes Verhalten tritt nur dann ein, wenn im Socket dieser
Verbindung die Option SO_KEEPALIVE gesetzt wurde!
Das ist die Zeit, die eine Verbindung ohne Datenverkehr offenbleibt. Die Angabe
ist in Sekunden, Default sind also 2 Stunden. Nach dieser Zeit wird ein Paket
mit der letzten gesendeten Sequenznummer nochmal gesendet, worauf die andere
Seite mit einem Acknowledge antwortet - wenn die Verbindung noch steht.
Steht die Verbindung nicht mehr, so sendet TCP 8 solche Pakete, und zwar
im Abstand von tcp_keepintvl. Kommt keine Antwort, wird die Verbindung
abgebrochen. Die Zahl 8 ist ab AIX 5.2 durch den Parameter
tcp_keepcnt konfigurierbar geworden.
Viele Leute möchten gerne bestehende Verbindungen, auf denen nichts läuft,
abbrechen. Das kann man mit tcp_keepidle und tcp_keepintvl machen.
Wobei tcp_keepidle bestimmt, ab wann TCP die Verbindung als unbenutzt ansieht
und tcp_keepintvl festlegt, wie lange rumgemacht wird, bevor die Verbindung
geschlossen wird.
Grosser Pferdefuß bei der Sache ist: Wenn auf der anderen Seite der Partner
richtig antwortet, dann kommen auf die Keepalives antwortet. Eine normale
TCP Verbindung steht bis zum Wärmetod des Weltalls.
Es funktioniert also nur, wenn das Kabel kaputt, der Partner gebootet hat
oder die Applikation gestorben ist und vorher seine TCP Verbindungen geschlossen
hat.
tcp_keepinit hat damit nichts zu tun - daran zu drehen
macht nur Sinn, wenn
man viele Anfragen nach neuen Verbindungen hat, also viele SYNs sieht.
(Das ist oft ein Hackerangriff - SYN Flooding)
Setzt die Anzahl der Keepalive Proben, die der TCP-Keepalive Algorithmus sendet.
Standard ist 150.
Das ist der Wert, der eine im Aufbau befindliche TCP Verbindung terminiert.
Also eine Verbindung, die sich noch im 3-Wege Handshake befindet. Solche
Verbindungen blockieren einen Platz in einer Wait-Queue, und es ist eine
gute Idee, nach einer gewissen Zeit davon auszugehen, das der Verbindungspartner
ein Problem hat - man läßt die Verbindung dann fallen, und schmeisst den Vorgang
von der Queue. Angabe auch in Halbsekunden.
Die Anzahl der tcp_debug Strukturen. Das sind normalerweise 100.
Das ist die voreingestellte Lebenddauer für TCP Pakete. Default ist 60, also ein Paket lebt 60 Ticks, wobei eine Minute etwa 100 Ticks hat.
Damit wird Path MTU Discovery angeschaltet. Das kann man unter AIX für UDP und TCP getrennt tun. Applikationen, die UDP benutzen, m|_en entsprechend programmiert sein, um diese Information zu nutzen (sie ermitteln die MTU meist selbst). Ab 4.3.3 ist das Standardmässig an. Dabei wird mit einem ICMP Paket einer definierten Größe (die man mit dem Kommando mmtu ansehen (-s) und ändern kann (-a, -d)) losgeschickt. Dieses Paket hat ein Bit gesetzt, was es den Routern verbietet, es zu Fragmentieren, also in kleine Stücke zu schneiden. Es gibt dann eine Fehlermeldung, und der sendende Rechner schickt das nächstkleinere Paket. So wird automatisch die optimale Paketgröße gefunden. Diese Information wird für jede Verbindung individuell gespeichert (die vielen neuen Routen mit dem W Flag). Geht mein Verkehr regelmd_ig |ber Netze mit unterschiedlichen MTUs, dann habe ich einen gro_en Vorteil von diesem Feature. Bin ich aber sicher, das 95% meines Verkehrs Ethernet mit einer MTU von 1500 Byte ist, dann lohnt es sich eher nicht. Leute mit dumm eingestellten Firewalls haben mit den ICMP Pakete ein Problem. Die Route wird auch regelmäßig geprüft, einmal ob sie noch steht und zum anderen, um zu sehen, ob sich die MTU vielleicht geändert hat. Das kann Leuten mit ISDN oder sonstigen, nicht dauernden Verbindungen viel Geld kosten...
Routen auf einem Internet sind dynamisch und können sich leicht ändern. Mit dieser Option stelle ich ein, wie oft die gefundene und in der Routing Table eingetragene Path MTU auf eine Verkleinerung geprüft werden soll. Standard sind 10 Minuten. Eine Verkleinerung der Path MTU ist kritisch, da es keine Möglichkeit gibt, das zu entdecken - die Pakete werden dann von irgendeinem armen Router fragmentiert.
Mit AIX 5.3 ist dieser no-Parameter obsolet. Pakete werden immer mit dem Flag IP_DONTFRAG versendet, dürfen also nicht fragmentiert werden, und eine Verkleinerung der MTU auf dem Pfad fällt sofort auf.
Routen auf einem Internet sind dynamisch und können sich leicht ändern. Mit dieser Option stelle ich ein, wie oft die gefundene und in der Routing Table eingetragene Path MTU auf eine vergrößerung geprüft werden soll. Standard sind 30 Minuten. Eine Vergrößerung ist zwar nicht so kritisch wie der Fall der Verkleinerung, aber es geht natürlich Durchsatz verloren.
Mit diesem Parameter wird festgelegt, ob dynamische Routen, also von ICMP oder Routing Deamons hinzugefügte Routen, nach einiger Zeit ihre Gültigkeit verlieren sollen und gelöscht werden sollen. Der Timer läuft an, wenn die Route nicht mehr benutzt wird. Statische Routen sind davon nicht betroffen. Das ist nützlich, wenn man Path MTU Discovery einsetzt, weil damit pro Verbindung eine Route erzeugt wird und die Routing Table stark anwachsen kann. Angabe in Minuten, Default ist 1.
Setzt man diesen Parameter auf 1, so wird jede Route bei einer Änderung der Routing Table geprüft. Dadurch soll sichergestellt werden, das Applikationen, die eine Verbindung lange aufhalten, Änderungen auf dem Netz auch mitschneiden. Je größer die Routing Table, desto länger dauert der Prozeß. Bei angeschalteter Path MTU Discovery verbietet sich dieses Feature von selbst.
Die Länge der IP Input-Queue. Soviele Pakete können von IP zwischengelagert werden. Wird in Paketen gezählt und 100 Pakete können per Default in diese Warteschlange gegeben werden. Ändert man den Wert, so muß man einen Reboot fahren (Kernel Datenstruktur).
Timewait ist der Zustand, in dem die TCP State Machine nach dem schliessen
einer Verbindung verweilt. Die Angabe erfolgt in 15 Sekunden Einheiten,
Standard ist 1.
Das sieht im Detail so aus:
Maschine A Maschine B . ------- FIN --------------> FIN_WAIT_1 CLOSE_WAITA sagt B, das es von seiner Seite nichts mehr zu sagen gibt. A geht dann in den Zustand FIN_WAIT_1 über. B empfängt das und schickt ein ACK auf dieses FIN. B geht dann in den Zustand CLOSE_WAIT.
. <------ ACK -------------- FIN_WAIT2A empfängt das ACK und geht darauf in den Zustand FIN_WAIT_2. A wartet hier, den B hat jetzt noch das Recht, Daten zu senden. Wenn B damit fertig ist, dann sendet er ein FIN und geht nach LAST_ACK.
. <------ FIN -------------- . LAST_ACKA empfängt das FIN von B - die Verbindung ist jetzt abgebaut. A schickt ein ACK, damit B das auch klar hat und geht über in TIME_WAIT. B empfängt das ACK auf sein FIN und macht den Socket zu.
. ------- ACK --------------> TIME_WAIT closed ... ... closedWarum macht aber A den Socket nicht auch einfach zu? Das geschieht aus Sicherheitsgründen. Es könnten noch Pakete auf dem Netz herumlaufen, die falsch geroutet wurden und im Zuge von Retransmission eigentlich obsolet sind. Diese kommen aber auf demselben Socket an und könnten Verwirrung stiften. Deshalb hält A den Socket in TIME_WAIT, und zwar nach alter Tradition für eine Zeit von 2 * MSL (Maximum Segment Lifetime). Das ist aber in der Regel viel zu lang, und deshalb kann man das einstellen..
Spezifiziert die maximale Anzahl an Unicast NDP
Paketen, die geschickt werden. Standard ist 3,
es geht bis MAXINT (Header File in /usr/include).
Der Parameter ist dynamisch.
Neighbour Discovery Protocol, NDP
Spezifiziert die maximale Anzahl an Multicast NDP
Paketen, die geschickt werden. Standard ist 3,
es geht bis MAXINT (Header File in /usr/include).
Der Parameter ist dynamisch.
Neighbour Discovery Protocol, NDP
Spezifiziert, wie oft die IPv6-Routing Table nach abgelaufenen Routen geprüft werden soll. Angabe des Intervales in Sekunden.
llsleep_timeoutHat der Rechner mehrere Interfaces (er ist dann multihomed) dann kann man hier die Zeit einstelle, die IPv6 wartet, nachdem es eine Neighbour Discovery angestoßen hat. Ist die Zeit abgelaufen, wird es erneut versucht.
Hier kann man die dynamischen, flüchtigen Ports einstellen. Es bringt TCP oder UDP dazu, eine Verbindung von einem Port in diesem Bereich zu öffnen, und verhindert so, das man erst den unteren Bereich durchlaufen muß, wo schon viele Applikationen/Dienste feste Ports belegt haben. Traditionell ist das der Bereich von Port 32768 bis Port 65535.
Mit diesem Parameter lassen sich die ACKs bestimmter Pakete
verzögern, damit man diese ACKs dann dem nächsten Paket mitgeben kann
("piggyback"). Das verhindert das Senden einer vielzahl kleiner Pakete
und entlastet speziell die Verbindungen zu Web-Server (HTTP).
Es gibt 4 mögliche Werte: 0 ist normale Operation, 1 verzögert das ACK
auf ein SYN des Servers, 2 verzögert das ACK auf ein FIN des Servers und
3 verzögert ACKs auf sowohl FIN wie SYN des Servers. Das ganze läßt sich
auf bestimmte Ports beschränken - mit dem Parameter delayackports
Definiert eine Liste von bis zu 10 Ports, für deren Paketfluß der Parameter delayack gelten soll. Die Angabe erfolgt in geschweifen Klammern: no -o delayackports={80,8080,1023}.
Die Angabe erfolgt in Millisekunden in einem Bereich von 50 - 200 ms. Setzt den TCP-Fasttimeout Timer.
Das schaltet das SACK (Selective Acknowledgement) Feature an. Das ist RFC2018. Damit wird bei Verlust eines Paketes nicht gleich das ganze Daten-Fenster (Window => TCP Receive Space) erneut übertagen, sondern aus dem Window gezielt die Segmente/Pakete wiederholt, die Fehlen. Das ist sehr wichtig bei großen Windows und schnellen Netzen, da hierbei der Verlust mehrerer Pakete in einem TCP-Window sofort enorme Mengen an mehrfach übertragenen Daten erzeugt. Damit diese Feature funktioniert, müssen es beide Seiten können. Es wird wdhrend des TCP-Handshakes ausgehandelt, ob dieses Feature benutzt werden soll. 0 schaltet diese Verhandlung aus, 1 schaltet sie ein.
Damit schaltet man die Interface Spezifischen Optionen ein. Man kann dann pro Interface via chdev oder ifconfig folgende Parameter einstellen:
rfc1323 - Die Performance Enhancements nach RFC 1323
tcp_nodelay - Kein verzögertes Versenden von ACKs
tcp_sendspace - Send- und Receivespace der TCP Verbindung
tcp_recvspace - siehe Oben
tcp_mssdflt - Die Default Maximum Segment Size
Damit schaltet man die New Reno Erweiterungen zum Fast Retransmission Feature von Reno ein. RFC 2582. 1 ist an, 0 ist aus.
für Pakete grv_er oder gleich zum eingestelleten Wert in Byte wird der Nagle-Algorithmus ausgeschaltet. Der Nagle Algorithmus verhindert, das kleine Pakete das Netz überschwemmen. (Eine Nutzlast von 1 Byte gibt ein Paket von mindestens 41 Byte: 20 Byte IP-Header, 20 Byte TCP-Header). Der Nagle Algorithmus tut das folgende: Solange die TCP Verbindung noch nicht geACKnowledgte Segmente hat, werden kleine Pakete nicht geschickt. Sie werden gesammelt und dann dem nächsten ACK mitgegeben. Normalerweise entscheidet der Algorithmus anhand der MSS, ob ein Paket klein oder normal ist. Diese Information findet sich im TCP Control Block der Verbindung. Das funktioniert bei Ethernet sehr gut, bei Switchen, ATM oder Gigabit Jumboframes ist das aber schwierig. Daher kann man den Wert hier entsprechend setzen. Setzt man tcp_nagle_limit auf 1, dann hat das den gleichen Effekt, wie wenn man für jedes Interface tcp_nodelay auf 1 setzt. Dann gibt es keine Verzögerung mehr. Standardmässig nutzt TCP den Nagle Algorithmus.
Schaltet die Möglichkeit, das TCP-Window, mit dem eine Verbindung startet, zu vergrößern. 0 ist aus, 1 ist an. Der Wert ist der in tcp_init_window angegebene. Das ist RFC 2414 ;-).
Ist rfc2414 gesetzt, dann wird diese Einstellung ausgewertet: 0 bedeutet, das das Initial Window, also das Congestion Window, der neuen Verbindung nach RFC 2414 berechnet wird. Steht hier ein Wert, so wird dieser als das Congestion Window genommen. (Es wird hier in Segmenten gezählt, also Anzahl der Pakete).
Schaltet die Nutzung des Explicit Congestion Notification Features. Beide Seiten müssen sich im Handshake über die Benutzung einigen. Das ist RFC 2481. Das Feature funktioniert nur, wenn die Gegenstelle und die Router auf dem Weg es auch unterstützen. Da im TCP-Header zwei neue Flags auftauchen, schiessen schlecht konfigurierte Firewalls diese Pakete ohne Fehlermeldung ab.
TCP loss recovery nach RFC 3042.
Einer der no-Parameter für die aktive Dead Gateway Detection (DGD). Wird via route-Kommando pro Route festgelegt; das Keywort ist -active_dgd. Dadurch wird das Gateway dieser Route alle dgd_ping_time Sekunden angepingt (Default ist 5 Sekunden); bleibt die Antwort aus, so wird es dgd_packets_lost Mal weiter versucht. Danach wird die Metrik der Route hochgesetzt, bis wieder Kontakt entstanden ist. Solange sendet IP über eine andere Route. Die aktive Variante erzeugt einiges an Verkehr auf dem Netz.
Setzt man passive_dgd auf 1, so schaltet man die passive Dead Gateway Detection (DGD) an. Kann nach einem Gateway nicht mehr gearped werden, (dgd_packets_lost Versuche, das zu tun - Default ist 3) dann wird die Metrik der Route hochgesetzt. Nach einer Zeit von dgd_retry_time Sekunden (Default ist 5) wird die Metrik wieder "normal" gesetzt, das Gateway bekommt eine neue Change. Das geht dann so weiter. Dasselbe passiert, wenn eine TCP-Verbindung diese Anzahl an Paketen verliert. Es gibt noch aktives DGD, das aber über das route-Kommando pro Route festgelegt; das Keywort ist -active_dgd. Die passive Variante funktioniert nicht bei UDP (kein Feedback).
Setzt man diesen Parameter auf 1, so wird jeder neue Socket mit dem Debug-Flag SO_DEBUG gestartet. Man kann dann auf dem Socket erweitert Tracen.
Dieser Parameter dient auch zum Abwehren von Denial of Service
Angriffen. Eine Attacke besteht darin, Unmengen an SYN Pakete auf einen
Port ohne Service, also ohne einen Dienst, der auf diesem Port horcht,
loszulassen. Für jedes dieser SYN-Pakete muß TCP dann ein RST als
Antwort schicken, und der Stack geht in die Knie. Bei UDP muß ein IMCP
Error generiert und gesendet werden.
Der mit diesen Parametern eingestellt Wert ist eine Obergrenze für die
Anzahl von Paketen, die innerhalb einer Halbsekunde (also eines Ticks,
ungefähr eine Halbsekunde) auf einem Port als normal angesehen werden.
Sind es SYN Pakete auf einem nicht bedienten Port, wird jeweils ein RST
(bzw. ICMP) zurückgegeben. Wird die Anzahl überschritten, dann läßt
TCP (bzw. UDP) das Paket
ohne Rückgabe eines RST (bzw. ICMP) fallen. Das gilt immer nur für das 500
Millisekunden Zeitfenster. Ein erneuter SYN nach einem
Tick erhält dann wieder ein RST (bzw. ICMP). Default ist 0, also keine
Restriktion.
Mit diesem Parameter schränkt man die Anzahl der IPv6 ICMP Error-Messages ein, die per Sekunde geschickt werden können. Um DoS Attacken und ähnliches zu verhindern.
Nutzt man bestimmte TCP Mechanismen (wie SACK und newreno) so kann es sehr plötzlich zu einem Schwall an Paketen kommen, die dann eventuel eine schwachbrüstiges Gateway überfordern - das Gateway (Router) würde weitere Pakete in einem solchen Fall einfach "droppen". Um das zu Verhindern, kann man hier eine bestimmte Anzahl an Paketen vorgeben. Gute Werte sind 4 oder 8. Der Default ist 0, es gibt also kein Limit.
Spezifiziert, ob TCP Sockets den Nagle Algorithmus nutzen
sollen, wenn sie Daten senden. Der Parameter ist dynamisch,
und eine ISNO-Option. Default ist 0, der Nagle Algorithmus
wird also genutzt.
(1 ==> Socket sendet sofort, 0 ==> Socket wartet bis zu 200ms
und sendet dann; ansonsten wird das Paket huckepack auf einem
anderen Paket mitgesendet.)
Zeit, die ein TCP Socket im State FIN_WAIT2 gehalten wird. In Halbsekunden. Default ist 1200, also 600 Sekunden, etwa 10 Minuten. Der Parameter ist dynamisch, der Bereich ist von 0 bis USHORTMAX. Eigentlich ist der Timer für FINWAIT2 ein dynamischer TCP Timer, der aus dem Keepalive Timer und den guten TCP Proben errechnet wird. Diese Methode reichte für aktive Server wohl nicht mehr aus.
Damit läßt sich die Anzahl der Einträge in der Hash-Tabelle des Network Buffer Caches bestimmen. Dieser Cache hält pro offenem im Filesystem einen Eintrag. Der Wert kann nur bei leerem Cache geändert werden, da die Tabelle und der Index neu angelegt werden müßen.
Damit läßt sich die Anzahl der Einträge in der Hash-Tabelle der TCP-Verbindungen für die INPCB (Internet Protocol Control Block) Datenstrukturen verändern. Diese Blöcke waren traditionell in verlinkten Listen abgelegt, jetzt wird ein Index erstellt und die Einträge des Indexes verlinkt. Eine große Hash-Tabelle sorgt für kurze Listen, die Suche nach einem bestimmten Block geht also schneller (und verbraucht mehr Arbeitsspeicher). Nur nach einem Reboot wirksam - da die ganze Datenstruktur neu aufgebaut werden muß.
Analog der Funktion von tcp_inpcb_hashtab_siz.
Eine Performance Verbesserung bei der Datenübertragung über das Loopback Device. Ändert die Art, wie bestimmte Tabellen angelegt und verarbeitet werden. Die 1 schaltet an, ist eine 0 gesetzt, so bleibt alles wie gewohnt.
Setzt die Global Routing Policy, die beim Multipath Routing angewandt wird. Der Parameter ist dynamisch, es sind 5 Werte (Policies) möglich:
Dies ist eine Debug-Option. Erlaubt es, eine Liste von Interfaces zum Tracen der relevanten ns_alloc und ns_free Events einzugeben. Wird also zum Tracen eines Device Treibers benutzt. Die Liste wird in geschweiften Klammern eingeschlossen, Trennzeichen ist der Doppelpunkt und maximal 127 Zeichen sind erlaubt.
Dies ist eine Debug-Option. Setzt die Größe von ns_alloc und ns_free, Trace-Buffern, die vom kdb ausgelesen werden können. Der Parameter ist dynamisch.
Ist der Wert größer 0, so werden alle ns_alloc und ns_free Events in einem Puffer des Kernels mitgeschrieben. Wird benutzt wenn man mit dem ndd ein Netzwerk-Stack Problem debuggen möchte. Wird in der Regel auf 1024 oder größer gesetzt.
Dies ist eine Debug-Option. Spezifiziert eine Liste in geschweiften Klammern mit maximal 127 Zeichen, in der die Puffergrößen durch Doppelpunkte getrennt aufgeführt werden. Alle net_malloc bzw. free events der Cluster dieser Größe werden protokolliert (wenn net_malloc_police gesetzt ist). Per default werden alle Größen protokolliert. Der Parameter ist dynamisch.
Dies ist eine Debug-Option und ist normalerweise für alle Typen aktiviert ({all}). Gibt an, welcher Typ von net_malloc bzw. free event durch die Option net_malloc_police geloggt wird. In geschweiften Klammern kann eine durch Doppelpunkte getrennte Liste von Typ-Bezeichnern angegeben werden (maximal 127 Zeichen). Der Parameter ist dynamisch.
Setzt das Alter in Minuten, mit dem bei Nichtbenutzung Path MTU Einträge gelöscht werden. Default ist 10 Minuten, Maximalwert ist MAXSHORT. Ein Wert von 0 zeigt an, daß die PMTU Routing Einträge nicht gelöscht werden. Der Parameter ist dynamisch.
Dieser Wert ist per Default auf 1, also aktiviert. Das bedeutet: AIX hält einen Vorrat an mbuf Clustern jeder genutzten Größe. Ohne diese Option muß für die Allokation eines mbuf Clusters zuerst der Puffer dür den Cluster angelegt werden, und dann der mbuf Puffer darauf zeigen. Der Parameter erfordert einen Reboot; der Cluster Cache kann mit dem netstat -M Kommando angezeigt werden.
Ist diese Option gesetzt, so werden alle TCP Verbindungen, die über ein bestimmtes Interface gehen, mit einem Fehler (ENETDOWN) informiert wenn das Interface gelöscht wird.
Setzt die höchste Zahl an Fragmenten, die für ein IP Paket in der Reassembly-Queue gehalten werden.
Ist dieser Parameter gesetzt, so wird für jeden neuen Socket geprüft, ob die SODEBUG Variable gesetzt ist. Dann wird das SO_DEBUG Flag gesetzt.
Schützt gegen ICMP Denial of Service Angriffe. Ist der Parameter gesetzt, so reagiert der TCP Stack nicht auf ICMP Source-Quench Messages. Das ICMP Paket bringt als Payload einen Teil des TCP Headers der Verbindung, auf die es sich bezieht. Dieser Teil des TCP Headers wird geprüft, ob die Sequenz-Nummer tatsächlich zu einer bestehenden Verbindung gehört.
Schützt gegen diverse Angriffe auf TCP Verbindungen:
tcp_tcpsecure Value Issue addressed ========================================================================== 0 None 1 Blind reset attack using the RST bit 2 Blind reset attack using the SYN bit 3 Both issues addressed by tcp_tcpsecure value 1 and 2 4 Blind data injection attack 5 Both issues addressed by tcp_tcpsecure value 1 and 4 6 Both issues addressed by tcp_tcpsecure value 2 and 4 7 Issues addressed by tcp_tcpsecure values 1, 2 and 4Was passiert jetzt?
Dieser Parameter explizit einen unteren Wert für den Round Trip Timeout. Das entspricht der Zeit, die auf ein ACK gewartet wird, bevor ein Segment nochmal gesendet wird. Man kann diesen Parameter in einem Bereich von 0 - 3000 millisekunden einstellen, Default sind 3 Sekunden. Der Parameter sollte immer auf 10-fache Vielfache des Intervalles der Uhr des TCP-Stacks eingestellt sein (Parameter "timer_wheel_tick, diesen Wert muß man setzen, bevor man tcp_low_rto setzen kann). Der Parameter ist dynamisch.
Dazu gibt es noch keine Dokumentation, aber man kann messerscharf schließen, daß sich mit diesem Parameter der Nagle-Algorithmus abschalten läßt.
Setzt die Anzahl der wiederholten ACK Pakete, die TCP dazubringen, in den "fast retransmit" zu gehen (setzt also einen Schwellenwert). Es wird in so einem Fall vermutet, daß Pakete verloren gegangen sind. Man wartet dann nicht das Ablaufen der Timer ab, sondern sendet sofort erneut. Default ist 3, also 3 wiederholte ACK führen zum Retransmit. Einstellbar von 1 bis zum Werte von MAXSHORT, den man in /usr/include/values.h findet. Sinnvolles Tuning für diesen Parameter wäre, wenn viele ACKs empfangen werden, obwohl das Netz nicht ausgelastet ist (so richtig hat sich mir das noch nicht erschlossen). Der Parameter ist dynamisch.
Dieser Parameter setzt explizit die "slot time" des Netzwerk-Stacks; also die zeitliche Länge eines Intervalls, eines "ticks". Die Einheit sind 10 millisekunden. Einstellbar sind Werte von 0 - 100 (jeweils mal 10 millisekunden). Man muß booten, da der Timer im Stack sitzt.
tbd. Default: {0} Range: 0 - 128 Type: Dynamic Unit: string
Erlaubt die Verteilung des in net_malloc_frag_mask gesetzten Wertes.
Zu diesem Parameter gehört das tcptr-Kommando. Damit kann man den TCP Verkehr bezogen auf eine bestimmte Verbindung (Ports und Verbindungspartner) formen bzw. regulieren (TCP Traffic Regulation). In der Regel wird man pro Port ein oberes Limit für die Zahl der parallelen Verbindungen setzen, um so einen Angriff zu verhindern. Der Parameter muß auf einen Wert größer 0 gesetzt werden, damit das Kommando aktiv wird.
Der Parameter gilt nur in einer Trusted AIX Umgebung. Dort schaltet er die Prüfung der MAC Adresse auf der IP Ebene ab.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL