I have discovered a problem with the implementation of ICMP redirect in the
BSD code:
Due to interaction between this code and the router discovery protocol,
stations may receive and keep a wrong default route, and the routers will
not correct this wrong route.
This leads to excessive traffic on Ethernet cables.
I wish to have opinions on this problem. Which is wrong, automatic
configuration of router discovery (and of any method of distributing defult
routes which can be sub optimal), or the BSD routing code ?
The problem was discovered with Solaris 2 staions, as they use the router
discovery by default, but the Solaris system is not the cause of the problem.
Description:
1/ Configuration
Ethernet R1 +---+
---------------------------------------| R | --> + connexion to station D
| | +---+ using the default route
+---+ +---+ + connexion to station C
| A | | B | using an explicit net route
+---+ +---+
|
------------
Ethernet R2
- A is a Sun station (1 Ethernet card), system Solaris 2.3 or 2.4,
automatic configuration (no explicit routing information configured)
- B is a Sun server (2 Ethernet cards), system Solaris 2.3 or 2.4,
automatic configuration (no explicit routing information configured)
- R is a router (not a Sun) running RIP but not running the Router Discovery
protocol. R is connected to cable R1, and connect the site to outside.
It gives access to machine C (using an explicit net route), and to
machine D, using the defaut route.
2/ The problem
All the packets from A to D are routed through B. Therefore each packet
appears twice on the ethernet cable R1.
Using snoop and netstat -r on A one can see:
- A has received a default route to B.
- Packets sent from A to D are sent by A to B on Ethernet, and then are
sent by B to R on Ethernet.
- No ICMP redirect is sent by B to A to correct the routing information.
On the opposite, packets from A to C behave correctly:
- the first packet from A to C is forwarded to B, then to R
- On this first packet, B sends a ICMP redirect to A (redirect C through R).
- the following packets from A to C are directly forwarded to R.
So in this configuration, a station acquires a wrong default route, and routers
fail to generate ICMP redirects to correct it.
3/ Discussion
The fact that A acquires a wrong default route comes from the default
configuration of both A and B (use of in.rdisc):
- At boot time, B starts the in.rdisc -r daemon. (and also in.routed -s, so
B receives all routes of R, including a default route)
- At boot time, A starts the in.rdisc -s daemon. As B's in.rdisc daemon is
active, A will use in.rdisc information and will not start in.routed.
- But as R is not using the router discovery protocol,
A will not discover the router R, and so will install a poor default
route.
One should note that :
- If B sends ICMP redirects, the problem is solved : the ICMP redirect will
correct the wrong route. But B does not send ICMP redirects for messages
forwarded by the default route.
- B knows all the correct routes received from R through RIP. It also
receives the correct default routel to Internet.
- Even if R is a router using rdisc protocol, there is still a problem:
with standard configuration, the rdisc messages sent by R and B will
have the same preference, and so there is a chance that A chooses B as
default routeur.
The decision not to send ICMP redirects for default routes is explicit in
all the BSD codes. For example here is the comment and test in the
bsd.networking code (file ip_input.c):
/*
* If forwarding packet using same interface that it came in on,
* perhaps should send a redirect to sender to shortcut a hop.
* Only send redirect if source is sending directly to us,
* and if packet was not source routed (or has any options).
* Also, don't send redirect if forwarding using a default route
* or a route modfied by a redirect.
*/
#define satosin(sa) ((struct sockaddr_in *)(sa))
if (ipforward_rt.ro_rt && ipforward_rt.ro_rt->rt_ifp == ifp &&
(ipforward_rt.ro_rt->rt_flags & (RTF_DYNAMIC|RTF_MODIFIED)) == 0 &&
>>>>>> satosin(&ipforward_rt.ro_rt->rt_dst)->sin_addr.s_addr != 0 &&
ipsendredirects && ip->ip_hl == (sizeof(struct ip) >> 2)) {
struct in_ifaddr *ia;
My opinion is that ``don't send redirect if forwarding using a default route''
is a wrong decision and should be suppressed.
This contradicts the RFCs on ``gateway requirements'', which do not suggest
that a default route is something special. It also contradicts the philosophy
of Router discovery ICMP. In order to use efficiently
the net when using default routes on hosts, routers must be able to correct
all routes. Default routes for a router are normal, they are a mean to
lower the route information exchanged and stored. In a hierarchic routing
domain, the default route is simply ``let the upper domain do the
correct thing''.
The problem can also appear in a site which use static default routes on
hosts, when the topology changes. Suppose stations are manually configured
with a default route pointing on a router B (the default router of the site).
Some time after a new default router R is installed.
With the current code for ICMP redirect all stations must be modified in
order to correct the default route.
Here are some parts of relevant RFCs:
RFC1009 (Gateway requirements)
A gateway will generate an ICMP Redirect if and only if the
destination IP address is reachable from the gateway (as
determined by the routing algorithm) and the next-hop gateway is
on the same (sub-)network as the source host. Redirects must not
be sent in response to an IP network or subnet broadcast address
or in response to a Class D or Class E IP address.
RFC1716 (Gateway requirements)
Routers MUST be able to generate
the Redirect for Host message (Code 1) and SHOULD be able to
generate the Redirect for Type of Service and Host message
(Code 3) specified in [INTERNET:8].
Routers MUST NOT generate a Redirect Message unless all of the
following conditions are met:
o The packet is being forwarded out the same physical
interface that it was received from,
o The IP source address in the packet is on the same Logical
IP (sub)network as the next-hop IP address, and
o The packet does not contain an IP source route option.
The source address used in the ICMP Redirect MUST belong to the
same logical (sub)net as the destination address.
A router using a routing protocol (other than static routes)
MUST NOT consider paths learned from ICMP Redirects when
forwarding a packet.
RFC 1256 (ICMP outer discovery message)
The router discovery messages do not constitute a routing protocol:
they enable hosts to discover the existence of neighboring routers,
but not which router is best to reach a particular destination. If a
host chooses a poor first-hop router for a particular destination, it
should receive an ICMP Redirect from that router, identifying a
better one.
It has been suggested that, when the preference level of an address
has not been explicitly configured, a router could set it according
to the metric of the router's "default route" (if it has one), rather
than defaulting it to zero as suggested above. ......
....... Such a strategy might reduce the amount of ICMP Redirect
traffic on some links by making it more likely that a host's first
choice router for reaching an arbitrary destination is also the best
choice. On the other hand, Redirect traffic is rarely a significant
load on a link, and there are some cases where such a strategy would
result in more Redirect traffic, not less (for example, on links from
--
Jean-Luc RICHIER (Jean-Luc.Richier(a)Imag.Fr richier(a)imag.fr)
LGI, IMAG-CAMPUS, BP 53, F-38041 GRENOBLE Cedex 9
Tel : (33) 76 82 72 32 Fax : (33) 76 44 66 75
