rip.tex

xorp源码hg

  to XORP Release-1.3, the {\tt route-deletion-secs} statement was used
  instead of {\tt deletion-delay}.}.  This time interval
  determines how long the router maintains expired routes after their
  metric has reached infinity. The default is 120 seconds, and should
  not normally need to be changed.  
\item{\tt triggered-delay}: When a router receives a
  modified route from a neighbor, it does not have to wait until the
  next periodic update to tell the other neighbors, but instead sends
  a triggered update~\footnote{Note that prior
  to XORP Release-1.3, the {\tt triggered-update-min-secs} and
  {\tt triggered-update-max-secs} statements were used
  instead of {\tt triggered-delay} and {\tt triggered-jitter}.}.
  After a triggered update is sent, a timer is
  set for a random interval between
  {\stt (triggered-delay - triggered-delay * triggered-jitter / 100)} and
  {\stt (triggered-delay + triggered-delay * triggered-jitter / 100)}.
  If other changes occur that
  would trigger updates before the timer expires, a single update is
  triggered when the timer expires.  The default value of {\stt
  triggered-delay} is 3 second, and should not normally need
  to be changed.
\item{\tt triggered-jitter}: See {\stt
  triggered-delay} for details.  The default is 66 percents
  (\ie {\stt triggered-delay} would be in the interval [1..5] seconds),
  and should not normally need to be changed.
\item{\tt update-interval}: A RIP router will typically tell
  its neighbors its entire routing table every 30 seconds~\footnote{Note that
  prior to XORP Release-1.3, the {\tt table-announce-min-secs} and
  {\tt table-announce-max-secs} statements were used
  instead of {\tt update-interval} and {\tt update-jitter}.}.  To avoid
  self-synchronization of routing updates, the precise time interval
  between telling each neighbor about routing updates is randomly
  jittered, with the delay chosen uniformly at random between
  {\stt (update-interval - update-interval * update-jitter / 100)} and
  {\stt (update-interval + update-interval * update-jitter / 100)}.  The
  default for {\stt update-interval} is 30 seconds, and should
  not normally need to be changed.
\item{\tt update-jitter}: See {\stt update-interval}
  for details.  The default is 16 percents,
  (\ie {\stt update-jitter} would be in the interval [25..35] seconds),
  and should not normally need to be changed.
\item{\tt request-interval}: When a RIP router has no neighbors on a
  vif/address, it may periodically send a request for a route update
  in case a neighbor appears~\footnote{Note that prior to XORP
  Release-1.3, the {\tt table-request-secs} statement was used instead
  of {\tt request-interval}.}.  This timer determines how often such a
  request is re-sent. The default value is 30 seconds.
  If the timer's value is 0, then the periodic requests are not sent.
\item{\tt interpacket-delay}: This specifies the default delay
  between back-to-back RIP packets when an update is sent that
  requires multiple packets to be sent~\footnote{Note that prior to
  XORP Release-1.3, the {\tt interpacket-delay-msecs} statement was
  used instead of {\tt interpacket-delay}.}.  The default is 50
  milliseconds, and should not normally need to be changed.
\item{\tt authentication}: This directive specifies the authentication
mechanism used to authorise RIP updates sent and received via this
vif/address.  

The authentication is configured by using one of the following
mutually-exclusive statements:

\begin{description}
\item{\tt simple-password}: this specifies the password used for
  plaintext authentication on this vif/address.
\item{\tt md5}: this specifies an MD5 authentication key. The parameter
  is the key ID and must be in the interval [0, 255].
  The MD5 authentication is configured by using the following
  statements:
\begin{description}
  \item{\tt password}: this specifies the MD5 password for the specific
  key.
  \item{\tt start-time}: this specifies the start time when the key
  becomes active. The format is ``YYYY-MM-DD.HH:MM''. If it is empty,
  then the key should become active immediately.
  \item{\tt end-time}: this specifies the end time when the key becomes
  inactive. The format is ``YYYY-MM-DD.HH:MM''. If it is empty,
  then the key should never expire.
\end{description}

If there are multiple configured keys, the messages are transmitted
using each of the keys that are valid for message generation.

\end{description}

Note that prior to XORP Release-1.2, the authentication configuration
statement used a different format:
\begin{verbatim}
authentication {
    type: text
    password: text
}
\end{verbatim}

\end{description}
\end{description}

\section{Configuring RIPng}

The configuration for RIPng is basically the same as for RIP, with two
exceptions:
\begin{itemize}
\item The addresses are IPv6 addresses with RIPng whereas they are IPv4
  addresses with RIPv2.
\item The {\stt authentication} directive is not available in RIPng,
  because RFC 2081 does not specify authentication for RIPng.
\end{itemize}

\subsection{Example Configurations}

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
policy \{\\
\>policy-statement connected-to-rip \{\\
\>\>term export \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "connected"\\
\>\>\>\}\\
\>\>\>then \{\\
\>\>\>\>metric: 0\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
\\
policy \{\\
\>policy-statement static-to-rip \{\\
\>\>term export \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "static"\\
\>\>\>\}\\
\>\>\>then \{\\
\>\>\>\>metric: 1\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
\\
protocols \{\\
\>rip \{\\
\>\>/* Redistribute connected and static routes */\\
\>\>export: "connected-to-rip,static-to-rip"\\
\>\>/* Run on specified network interface addresses */\\
\>\>interface fxp0 \{\\
\>\>\>vif fxp0 \{\\
\>\>\>\>address 69.110.224.158 \{\\
\>\>\>\>\}\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}

In the above configuration, RIP is configured to export routes for
directly connected subnets and for routes that are statically
configured.  The RIP metric advertised is configured to be 0 for
connected subnets and 1 for static routes.

RIP is configured on only one interface/vif ({\stt dc0/dc0}), with
address 10.10.10.10.  This router will send and receive routes from
any RIP neighbors that it discovers on that vif/address.

\newpage
\section{Monitoring RIP}

RIP routes can be monitored using the operational mode command: \\
{\stt show route table ipv4 unicast rip}.  \\
For each subnet, the nexthop
router, the RIP metric, and the interface/vif to reach the nexthop
route are shown.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xxxxxxxxxxxxxxxx\=\kill
user@hostname> {\bf show route table ipv4 unicast rip}\\
172.16.0.0/24 \>[rip(120)/1]\\
               \>> to 172.16.0.1 via dc0/dc0\\
172.16.1.0/24 \>[rip(120)/1]\\
               \>> to 172.16.1.1 via dc1/dc1\\
172.16.2.0/24 \>[rip(120)/1]\\
               \>> to 172.16.2.1 via dc2/dc2\\
172.16.3.0/24 \>[rip(120)/1]\\
               \>> to 172.16.3.1 via dc3/dc3\\
192.150.187.0/25 \>[rip(120)/1]\\
               \>> to 192.150.187.112 via fxp0/fxp0
\end{tabbing}
\end{alltt}
\end{minipage}
}

The operational command for monitoring the IPv6 unicast routes
is {\stt show route table ipv6 unicast rip}.
The operational commands for monitoring the MRIB routes
are {\stt show route table ipv4 multicast rip}
and {\stt show route table ipv6 multicast rip}
for IPv4 and IPv6 respectively.