rfc1058.txt

RFC 的详细文档！

2.2.1. Split horizon

   Note that some of the problem above is caused by the fact that A and
   C are engaged in a pattern of mutual deception.  Each claims to be
   able to get to D via the other.  This can be prevented by being a bit
   more careful about where information is sent.  In particular, it is
   never useful to claim reachability for a destination network to the
   neighbor(s) from which the route was learned.  "Split horizon" is a
   scheme for avoiding problems caused by including routes in updates
   sent to the gateway from which they were learned.  The "simple split
   horizon" scheme omits routes learned from one neighbor in updates
   sent to that neighbor.  "Split horizon with poisoned reverse"
   includes such routes in updates, but sets their metrics to infinity.

   If A thinks it can get to D via C, its messages to C should indicate
   that D is unreachable.  If the route through C is real, then C either
   has a direct connection to D, or a connection through some other
   gateway.  C's route can't possibly go back to A, since that forms a
   loop.  By telling C that D is unreachable, A simply guards against
   the possibility that C might get confused and believe that there is a
   route through A.  This is obvious for a point to point line.  But
   consider the possibility that A and C are connected by a broadcast
   network such as an Ethernet, and there are other gateways on that
   network.  If A has a route through C, it should indicate that D is
   unreachable when talking to any other gateway on that network.  The
   other gateways on the network can get to C themselves.  They would
   never need to get to C via A.  If A's best route is really through C,
   no other gateway on that network needs to know that A can reach D.
   This is fortunate, because it means that the same update message that
   is used for C can be used for all other gateways on the same network.
   Thus, update messages can be sent by broadcast.

   In general, split horizon with poisoned reverse is safer than simple
   split horizon.  If two gateways have routes pointing at each other,
   advertising reverse routes with a metric of 16 will break the loop
   immediately.  If the reverse routes are simply not advertised, the
   erroneous routes will have to be eliminated by waiting for a timeout.
   However, poisoned reverse does have a disadvantage: it increases the



Hedrick                                                        [Page 14]

RFC 1058              Routing Information Protocol             June 1988


   size of the routing messages.  Consider the case of a campus backbone
   connecting a number of different buildings.  In each building, there
   is a gateway connecting the backbone to a local network.  Consider
   what routing updates those gateways should broadcast on the backbone
   network.  All that the rest of the network really needs to know about
   each gateway is what local networks it is connected to.  Using simple
   split horizon, only those routes would appear in update messages sent
   by the gateway to the backbone network.  If split horizon with
   poisoned reverse is used, the gateway must mention all routes that it
   learns from the backbone, with metrics of 16.  If the system is
   large, this can result in a large update message, almost all of whose
   entries indicate unreachable networks.

   In a static sense, advertising reverse routes with a metric of 16
   provides no additional information.  If there are many gateways on
   one broadcast network, these extra entries can use significant
   bandwidth.  The reason they are there is to improve dynamic behavior.
   When topology changes, mentioning routes that should not go through
   the gateway as well as those that should can speed up convergence.
   However, in some situations, network managers may prefer to accept
   somewhat slower convergence in order to minimize routing overhead.
   Thus implementors may at their option implement simple split horizon
   rather than split horizon with poisoned reverse, or they may provide
   a configuration option that allows the network manager to choose
   which behavior to use.  It is also permissible to implement hybrid
   schemes that advertise some reverse routes with a metric of 16 and
   omit others.  An example of such a scheme would be to use a metric of
   16 for reverse routes for a certain period of time after routing
   changes involving them, and thereafter omitting them from updates.

2.2.2. Triggered updates

   Split horizon with poisoned reverse will prevent any routing loops
   that involve only two gateways.  However, it is still possible to end
   up with patterns in which three gateways are engaged in mutual
   deception.  For example, A may believe it has a route through B, B
   through C, and C through A.  Split horizon cannot stop such a loop.
   This loop will only be resolved when the metric reaches infinity and
   the network involved is then declared unreachable.  Triggered updates
   are an attempt to speed up this convergence.  To get triggered
   updates, we simply add a rule that whenever a gateway changes the
   metric for a route, it is required to send update messages almost
   immediately, even if it is not yet time for one of the regular update
   message.  (The timing details will differ from protocol to protocol.
   Some distance vector protocols, including RIP, specify a small time
   delay, in order to avoid having triggered updates generate excessive
   network traffic.)  Note how this combines with the rules for
   computing new metrics.  Suppose a gateway's route to destination N



Hedrick                                                        [Page 15]

RFC 1058              Routing Information Protocol             June 1988


   goes through gateway G.  If an update arrives from G itself, the
   receiving gateway is required to believe the new information, whether
   the new metric is higher or lower than the old one.  If the result is
   a change in metric, then the receiving gateway will send triggered
   updates to all the hosts and gateways directly connected to it.  They
   in turn may each send updates to their neighbors.  The result is a
   cascade of triggered updates.  It is easy to show which gateways and
   hosts are involved in the cascade.  Suppose a gateway G times out a
   route to destination N.  G will send triggered updates to all of its
   neighbors.  However, the only neighbors who will believe the new
   information are those whose routes for N go through G.  The other
   gateways and hosts will see this as information about a new route
   that is worse than the one they are already using, and ignore it.
   The neighbors whose routes go through G will update their metrics and
   send triggered updates to all of their neighbors.  Again, only those
   neighbors whose routes go through them will pay attention.  Thus, the
   triggered updates will propagate backwards along all paths leading to
   gateway G, updating the metrics to infinity.  This propagation will
   stop as soon as it reaches a portion of the network whose route to
   destination N takes some other path.

   If the system could be made to sit still while the cascade of
   triggered updates happens, it would be possible to prove that
   counting to infinity will never happen.  Bad routes would always be
   removed immediately, and so no routing loops could form.

   Unfortunately, things are not so nice.  While the triggered updates
   are being sent, regular updates may be happening at the same time.
   Gateways that haven't received the triggered update yet will still be
   sending out information based on the route that no longer exists.  It
   is possible that after the triggered update has gone through a
   gateway, it might receive a normal update from one of these gateways
   that hasn't yet gotten the word.  This could reestablish an orphaned
   remnant of the faulty route.  If triggered updates happen quickly
   enough, this is very unlikely.  However, counting to infinity is
   still possible.

3. Specifications for the protocol

   RIP is intended to allow hosts and gateways to exchange information
   for computing routes through an IP-based network.  RIP is a distance
   vector protocol.  Thus, it has the general features described in
   section 2.  RIP may be implemented by both hosts and gateways.  As in
   most IP documentation, the term "host" will be used here to cover
   either.  RIP is used to convey information about routes to
   "destinations", which may be individual hosts, networks, or a special
   destination used to convey a default route.




Hedrick                                                        [Page 16]

RFC 1058              Routing Information Protocol             June 1988


   Any host that uses RIP is assumed to have interfaces to one or more
   networks.  These are referred to as its "directly-connected
   networks".  The protocol relies on access to certain information
   about each of these networks.  The most important is its metric or
   "cost".  The metric of a network is an integer between 1 and 15
   inclusive.  It is set in some manner not specified in this protocol.
   Most existing implementations always use a metric of 1.  New
   implementations should allow the system administrator to set the cost
   of each network.  In addition to the cost, each network will have an
   IP network number and a subnet mask associated with it.  These are to
   be set by the system administrator in a manner not specified in this
   protocol.

   Note that the rules specified in section 3.2 assume that there is a
   single subnet mask applying to each IP network, and that only the
   subnet masks for directly-connected networks are known.  There may be
   systems that use different subnet masks for different subnets within
   a single network.  There may also be instances where it is desirable
   for a system to know the subnets masks of distant networks.  However,
   such situations will require modifications of the rules which govern
   the spread of subnet information.  Such modifications raise issues of
   interoperability, and thus must be viewed as modifying the protocol.

   Each host that implements RIP is assumed to have a routing table.
   This table has one entry for every destination that is reachable
   through the system described by RIP.  Each entry contains at least
   the following information:

      - The IP address of the destination.

      - A metric, which represents the total cost of getting a
        datagram from the host to that destination.  This metric is
        the sum of the costs associated with the networks that
        would be traversed in getting to the destination.

      - The IP address of the next gateway along the path to the
        destination.  If the destination is on one of the
        directly-connected networks, this item is not needed.

      - A flag to indicate that information about the route has
        changed recently.  This will be referred to as the "route
        change flag."

      - Various timers associated with the route.  See section 3.3
        for more details on them.

   The entries for the directly-connected networks are set up by the
   host, using information gathered by means not specified in this



Hedrick                                                        [Page 17]

RFC 1058              Routing Information Protocol             June 1988


   protocol.  The metric for a directly-connected network is set to the
   cost of that network.  In existing RIP implementations, 1 is always
   used for the cost.  In that case, the RIP metric reduces to a simple
   hop-count.  More complex metrics may be used when it is desirable to
   show preference for some networks over others, for example because of
   differences in bandwidth or reliability.

   Implementors may also choose to allow the system administrator to
   enter additional routes.  These would most likely be routes to hosts
   or networks outside the scope of the routing system.

   Entries for destinations other these initial ones are added and
   updated by the algorithms described in the following sections.

   In order for the protocol to provide complete information on routing,
   every gateway in the system must participate in it.  Hosts that are
   not gateways need not participate, but many implementations make
   provisions for them to listen to routing information in order to
   allow them to maintain their routing tables.

3.1. Message formats

   RIP is a UDP-based protocol.  Each host that uses RIP has a routing
   process that sends and receives datagrams on UDP port number 520.
   All communications directed at another host's RIP processor are sent
   to port 520.  All routing update messages are sent from port 520.
   Unsolicited routing update messages have both the source and
   destination port equal to 520.  Those sent in response to a request
   are sent to the port from which the request came.  Specific queries
   and debugging requests may be sent from ports other than 520, but
   they are directed to port 520 on the target machine.

   There are provisions in the protocol to allow "silent" RIP processes.
   A silent process is one that normally does not send out any messages.