[comp.protocols.tcp-ip] gateways ignores ICMP redirect

goud@sicsun.epfl.ch (Mireille Goud) (05/15/91)

   Our NSC router (DX4130) does not update its routing table when it
receives an ICMP redirect message (host redirect or network redirect).
The ICMP redirect comes from the routers default gateway (on the same
subnet) and gives the address of a better gateway on the same subnet.

   I dont find anything in the RFCs about what a gateway should do when
it receives an icmp redirect, but a gateway must be intelligent and
optimize the traffic on the network...
   NSC says the ICMP redirect messages are only for hosts.

   Can somebody help me? Thank you.


 Mireille Goud
 EPFL - SIC
 1015 Lausanne              goud@sic.epfl.ch

art@opal.acc.com (Art Berggreen) (05/15/91)

In article <1991May15.095703@sicsun.epfl.ch> goud@sicsun.epfl.ch (Mireille Goud) writes:
>
>
>   Our NSC router (DX4130) does not update its routing table when it
>receives an ICMP redirect message (host redirect or network redirect).
>The ICMP redirect comes from the routers default gateway (on the same
>subnet) and gives the address of a better gateway on the same subnet.
>
>   I dont find anything in the RFCs about what a gateway should do when
>it receives an icmp redirect, but a gateway must be intelligent and
>optimize the traffic on the network...
>   NSC says the ICMP redirect messages are only for hosts.
>
>   Can somebody help me? Thank you.
>
>
> Mireille Goud
> EPFL - SIC
> 1015 Lausanne              goud@sic.epfl.ch

This is pretty normal behavior for current routers.

RFC1009 (and its someday successor) indicate that routers running routing
protocols should NOT respond to Redirects.  The routing protocols should
always provide better information than a Redirect.

Are your gateways communicating via a routing protocol? If not, why not?

Art

tsuchiya@THUMPER.BELLCORE.COM (Paul Tsuchiya) (05/15/91)

Briefly put, it is quite dangerous for routers to use icmp redirects.
For a routing algorithm to work correctly (that is, no long-term
looping), then the information received at each router must be
consistent with that received  by other routers.

The use of icmp redirects by routers can easily lead to looping,
if it is not a coordinated part of the routing algorithm (I don't know
any routing algorithms that explicitly use redirects).

One question is--why is the router getting the redirects in the
first place?

PT

goud@sicsun.epfl.ch (Mireille Goud) (05/16/91)

Thanks to the people who answered my question.

I want to summarize here the answers and why I have the problem.

The problem :

   We have 2 parallel backbones in the school (One ethernet backbone
and one fddi backbone). The departments are all connected to the
backbones with a cisco router. Some departments are connected to the
two backbones (with only one router which has one fddi interface and
at least two ethernet interfaces) and the other departements are
connected only on the ethernet backbone (in the futur all the
departments will be connected on the two backbones). 
(Why 2 backbones ? because we had the ethernet backbone already and
it was not too expensive to keep that backbone as a spare backbone).

   For the departments connected to the 2 backbones we want the
traffic uses the fddi backbone if it is running and the traffic uses
the ethernet backbone only if the fddi backbone is down.

   We couldn't obtain this result with the rip protocol so we use the
igrp protocol.

   The cray is connected to the 2 backbones with 2 different NSC
routers. These routers do not understand igrp protocol. Our idea was
to give a default gateway to the NSC routers and they would have
learned the better routes by ICMP redirect from the default gateway.



The answers :
   
  ICMP redirects are sent only by routers and processed only by hosts.
  In RFC 1009 4.5.5 they say that dumb routers should pay attention
to redirects. 


Conclusion :
   Maybe, it is difficult to consider NSC routers as dumb routers.
   So I have to give all the static routes to the NSC routers. That
is the progress...


Thanks


Mireille Goud
Sic - EPFL              goud@sic.epfl.ch