ICMP-Redirects

Aus Knowledgebase
Version vom 21. November 2010, 01:57 Uhr von PoC (Diskussion | Beiträge) (→‎Fallstrick: Zitat besser herausgearbeitet)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

ICMP-Redirects werden oft auf den Routerinterfaces ausgeschaltet. Manchmal sind sie trotzdem nützlich.

Grundlagen

ICMP Redirects dienen dazu, Clients einen direkteren Weg zu einem Ziel (Server) zu zeigen.

Redirect-example.jpg

Im folgenden Beispiel greift der Client Cl auf den Server Svr zu, um eine Datei herunterzuladen, zum Beispiel per FTP. Die Anfrage gelangt also über Router R2 auf den Server Svr. Der wiederum schickt die Antwortpakete mit der Datei zu R1, welcher anhand seiner Routingtabelle die Pakete aber an R2 weiterleitet. R2 weiß, daß die Pakete für das Interface auf seiner rechten Seite bestimmt sind und leitet sie dann an den Client Cl weiter.

Warum ist das so? Nun, der Server hat nur sein Defaultgateway konfiguriert, er kennt ausschließlich diesen Weg, zu Maschinen außerhalb seines eigenen Netzwerksegmentes. Der ganze Traffic zum Client geht also über diesen Router. Angenommen, R1 ist 'n kleiner 830er oder 1700er Router, die intern nur 10MBit Routen können, während R2 ein dicker 3600er ist, der auch 100MBit routen kann. Der Benutzer an Cl wundert sich, warum er bei Downloads vom Server nur 10MBit kriegt, während der Netzwerkadministrator sich wundert, warum er auf R1 Traffic sieht, der auf dem gleichen Wege wie er reinkommt, auch wieder rausgeht.

ICMP Redirects

Router R1 erkennt nun, daß der Server Svr zu doof ist, den Traffic direkt zu R2 zu senden, obwohl er das eigentlich könnte, weil Svr als auch die beiden Router im selben Netzwerksegment stehen. Daher generiert R1 ein ICMP-Redirect-Paket mit dem Ziel R2 und dem Inhalt Cl und sendet das an Svr. Das bedeutet für Svr: Hey, schick Deinen Traffic für Cl an R2. Der Server merkt sich diesen Redirect und schickt ab sofort den Traffic direkt zu R2. R1 wird entlastet und Cl erhält die Daten mit der vollen Geschwindigkeit.

Sobald Svr den Redirect nach einer Weile wieder vergißt, kriegt er von R1 wieder einen zugeschickt.

Per Default sind diese ICMP-Redirects eingeschaltet.

dslrouter#show ip int vlan1
Vlan1 is up, line protocol is up
 Internet address is 192.168.59.1/26
 Broadcast address is 255.255.255.255
 Address determined by non-volatile memory
 MTU is 1500 bytes
 Helper address is not set
 Directed broadcast forwarding is enabled
 Multicast reserved groups joined: 224.0.0.1 224.0.0.2 224.0.0.10
 Outgoing access list is not set
 Inbound  access list is not set
 Proxy ARP is enabled
 Local Proxy ARP is disabled
 Security level is default
 Split horizon is enabled
 ICMP redirects are always sent
 ICMP unreachables are always sent
 ICMP mask replies are never sent
 IP fast switching is enabled
 IP fast switching on the same interface is disabled
 IP Flow switching is enabled
 IP CEF switching is enabled
 IP CEF Flow Fast switching turbo vector
 IP multicast fast switching is enabled
 IP multicast distributed fast switching is disabled
 IP route-cache flags are Fast, Flow cache, CEF, Full Flow
 Router Discovery is enabled
 IP output packet accounting is disabled
 IP access violation accounting is disabled
 TCP/IP header compression is disabled
 RTP/IP header compression is disabled
 Policy routing is disabled
 Network address translation is enabled, interface in domain inside
 BGP Policy Mapping is disabled
 WCCP Redirect outbound is disabled
 WCCP Redirect inbound is disabled
 WCCP Redirect exclude is disabled

Fallstrick

Um auch für den beschriebenen Fall die Last auf R1 klein zu halten, wenn ICMP-Redirects nicht akzeptiert werden, hat der Autor empfohlen, in der Interfacekonfiguration ein

ip route-cache same-interface

aufzunehmen. Nun hat sich gezeigt, daß diese Konfiguration dafür sorgt, daß ICMP-Redirects nicht mehr generiert werden. Der Route-Cache sorgt zwar dafür, daß auf R1 die Last klein bleibt, weil die Pakete nicht über die CPU gehen, aber dafür bleibt die Netzlast hoch, weil keine ICMP-Redirects generiert werden.

Zitat aus der Cisco-Dokumentation:

Enabling Fast Switching on the Same IP Interface: You can enable IP fast switching when the input and output interfaces are the same interface. This normally is not recommended, though it is useful when you have partially meshed media such as Frame Relay. You could use this feature on other interfaces, although it is not recommended because it would interfere with redirection.

Andere Systeme

Linux generiert auch ICMP Redirects. Kann man z. B. mit sysctl abschalten/anschalten:

 # /sbin/sysctl -w net.ipv4.conf.all.accept_redirects = 0
 # /sbin/sysctl -w net.ipv4.conf.all.send_redirects = 0

Ob PIX/ASA auch solche Redirects generiert, ist nicht bekannt.

Schlußfolgerung

Wenn wir eine Konstellation wie im obigen Beispiel haben, dann lassen wir auf Multipoint-Interfaces wie Ethernet, FDDI, oder Token Ring den ip route-cache same-interface weg.