rip.tex

xorp源码hg

%
% $XORP: xorp/docs/user_manual/rip.tex,v 1.20 2006/07/19 00:43:38 pavlin Exp $
%

\chapter{RIP and RIPng}
\label{rip}
\section{Terminology and Concepts}

The Routing Information Protocol (RIP) is the simplest unicast routing
protocol in widespread use today.  RIP is very simple, both in
configuration and protocol design, so it is widely used in simple
topologies.  However, RIP does not scale well to larger networks,
where OSPF or IS-IS might be more appropriate.

There have been two versions of the RIP protocol.  RIP version 1 dates
back to the early days of the Internet.  It is now historic, primarily
because it does not support classless addressing which is necessary in
today's Internet.  XORP does not support RIPv1.  

RIP version 2 introduces a subnet mask, which allows classless
addressing.  XORP completely supports RIPv2, as specified in RFC 2453.

RIPng introduces IPv6 support.  It is very similar to RIPv2, but for
IPv6 instead of IPv4.

RIP is a distance vector protocol, which means that when a router
receives a route from a neighbor, that route comes with a distance
metric indicating the cost associated with reaching the destination
via that neighbor.  The router adds its metric for the link on which
the route was received to the metric in the received route, and then
compares the route against its current best path to that destination.
If the metric is lower, or if there is no current route to the
destination, then the new route wins, and is installed in the router's
routing table.  If the route is simply an update of the previous best
route, then the stored metric is updated, and the route's deletion
timer is restarted.  Otherwise the route is ignored.  Periodically,
the router's routing table is sent to each of it's neighbors.
Additionally, if a route changes, then the new route is sent to each
neighbor.

On reason why RIP is not good for large networks is that in complex
topologies it is rather slow to conclude that a route is no longer
usable.  This is because routers in a loop will learn a route from
each other all the way around the loop, and so when a destination
becomes unreachable, the routing change will have to propagate around
the loop multiple times, increasing the metric each time until the
metric reaches infinity, when the route is finally removed.  RIP uses
a low value of 15 as infinity to reduce the time it takes to remove
old information.

A simple case of such a loop is two routers talking to each other.
After a destination becomes unreachable, two routers may each believe
the other has the best route.  {\it Split horizon} is a scheme for
avoiding problems caused by including routes in updates sent to the
router from which they were learned.  The {\it simple split horizon}
scheme omits routes learned from one neighbor in updates sent to that
neighbor.  {\it Split horizon with poisoned reverse} includes such
routes in updates, but sets their metrics to infinity.  In general, it
is advisable to use split-horizon with poisoned reverse when using
RIP, as this significantly speeds convergence in many scenarios.

\subsection{Standards Supported}

XORP RIP complies with the following standards:
\begin{description}
\item{\bf RFC 2453}: RIP version 2.
\item{\bf RFC 2082}: RIP-2 MD5 Authentication.
\item{\bf RFC 2080}: RIPng for IPv6.
\end{description} 

\newpage
\section{Configuring RIP}

To run RIP it is sufficient to specify the set of interfaces, vifs and
addresses ({\stt interface}, {\stt vif} and {\stt address}) on which
RIP is enabled.  Each {\stt address} to be used by RIP must be
explicitly configured, and typically a metric will also be configured.

In addition, to originate routes via RIP, it is necessary to use the
{\stt export} command to export routes from the router's routing table
via RIP~\footnote{Starting with XORP Release-1.2 policy is used to
export routes into RIP with the {\tt export} statement.  Prior to XORP
Release-1.2 the {\tt export} statement was used with a different syntax.}.
The {\stt export} commands arguments are policy statements;
see Chapter \ref{policy} for additional detais.

\subsection{Configuration Syntax}

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=xx\=xx\=\kill
protocols \{\\
\>rip \{\\
\>\>targetname {\it text}\\
\>\>export {\it text}\\
\>\>interface {\it text} \{\\
\>\>\>vif {\it text} \{\\
\>\>\>\>address {\it IPv4} \{\\
\>\>\>\>\>metric: {\it uint}\\
\>\>\>\>\>horizon: {\it text}\\
\>\>\>\>\>disable: {\it bool}\\
\>\>\>\>\>passive: {\it bool}\\
\>\>\>\>\>accept-non-rip-requests: {\it bool}\\
\>\>\>\>\>accept-default-route: {\it bool}\\
\>\>\>\>\>route-timeout: {\it uint}\\
\>\>\>\>\>deletion-delay: {\it uint}\\
\>\>\>\>\>triggered-delay: {\it uint}\\
\>\>\>\>\>triggered-jitter: {\it uint(0..100)}\\
\>\>\>\>\>update-interval: {\it uint}\\
\>\>\>\>\>update-jitter: {\it uint(0..100)}\\
\>\>\>\>\>request-interval: {\it uint}\\
\>\>\>\>\>interpacket-delay: {\it uint}\\
\>\>\>\>\>authentication \{\\
\>\>\>\>\>\>simple-password: {\it text}\\
\>\>\>\>\>\>md5 {\it uint(0..255)} \{\\
\>\>\>\>\>\>\>password: {\it text}\\
\>\>\>\>\>\>\>start-time: {\it text(``YYYY-MM-DD.HH:MM'')}\\
\>\>\>\>\>\>\>end-time: {\it text(``YYYY-MM-DD.HH:MM'')}\\
\>\>\>\>\>\>\}\\
\>\>\>\>\>\}\\
\>\>\>\>\}\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}

\begin{description}
\item{\tt protocols}: this delimits the configuration for all routing
  protocols in the XORP router configuration.  It is mandatory that
  RIP configuration is under the {\stt protocols} node in the
  configuration.
\item{\tt rip}: this delimits the RIP configuration part of the XORP
  router configuration.
\item{\tt targetname}: this is the name for this instance of RIP.  It
  defaults to ``{\stt rip}'', and it is not recommended that this
  default is overridden under normal usage scenarios.
\item{\tt export}: this directive specifies an export policy statement
(see Chapter \ref{policy}).
\item{\tt interface}: this specifies a network interface that should
  be used by RIP for routing.  See Chapter \ref{interfaces} for
  details of interfaces.  The interface must be configured
  in the {\stt interfaces} part of the router configuration.

  Each interface can have multiple vifs configured:
\item{\tt vif}: this specifies a vif that should be used by RIP for routing.
  See Chapter \ref{interfaces} for details of vifs.
\item{\tt address}: this specifies an IPv4 address that should be used
  by RIP for routing.  RIP will peer with other routers on this {\stt
  interface/vif} using this {\stt address}.  The address must be a
  valid configured address for this vif.

  The parameters that can be specified for each address are:
\begin{description}
\item{\tt metric}: this specifies the metric or cost associated with
  routes received on this vif/address.  The metric is added to the
  cost in routes received before deciding between best routes to the
  same destination subnet.  {\stt metric} should be an integer between
  1 and 15.  Note that 15 is regarded as infinity as far as RIP is
  concerned.  The sum of all the metrics across the entire RIP domain
  should be less than 15.
\item{\tt horizon}: this specifies how RIP deals with eliminating
  routes quickly after a path has failed.  Possible values are ``{\stt
  split-horizon-poison-reverse}'', ``{\stt split-horizon}'', and ``{\stt
  none}''.  The default is {\stt split-horizon-poison-reverse} and under
  normal circumstances should be left unchanged.
\item{\tt disable}: this takes the value {\stt true} or {\stt false},
  and determines whether RIP will exchange routes via this
  vif/address~\footnote{Note
  that prior to XORP Release-1.1, the {\tt enable} flag was used instead of
  {\tt disable}.}.
  Setting this to {\stt true} allows routes received
  via an address to be temporarily removed without deleting the
  configuration.  The default is {\stt false}.
\item{\tt passive}: this takes the value {\stt true} or {\stt false},
  and determines whether RIP runs in passive mode on this address.  In
  passive mode, RIP will accept routes received on this address, but
  will not advertise any routes to neighbors via this address.  The
  default is {\stt false}.
\item{\tt accept-non-rip-requests}: this takes the value {\stt true}
  or {\stt false}.  Normal RIPv2 requests for routing updates are
  multicast to all neighbors and sourced from the RIP port.  However
  for monitoring purposes RIP also allows requests to be unicast, and
  then they can be sourced from non-RIP ports.  When this option is
  {\stt true}, RIP will accept RIP requests from any UDP port.  The
  default is {\stt true}.
\item{\tt accept-default-route}: this takes the value {\stt true} or
  {\stt false}, and indicates whether RIP should accept a default
  route if it receives one from a RIP neighbor.  The default is {\stt
  false}.
\item{\tt route-timeout}: If no periodic or triggered update of a
  route from this neighbor has been received for this time interval,
  the route is considered to have expired~\footnote{Note that prior
  to XORP Release-1.3, the {\tt route-expiry-secs} statement was used
  instead of {\tt route-timeout}.}.  The default is 180 seconds,
  and should not normally need to be changed.
\item{\tt deletion-delay}: After a route has expired (the
  route has an infinite metric), a router must keep a copy of it for a
  certain time so it can have a reasonably confidence that it has told
  its neighbors that the route has expired~\footnote{Note that prior