% % $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 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.