config_overview.tex

xorp源码hg

%
% $XORP: xorp/docs/user_manual/config_overview.tex,v 1.22 2006/06/30 00:43:04 pavlin Exp $
%

\chapter{Configuration Overview}
\section{Introduction}

A XORP router must be configured to perform the desired operations.
The configuration information can be provided in one of the two ways:

\begin{itemize}
\item
  Use a configuration file when the \rtrmgr is started.
  By default, the \rtrmgr will load the configuration from file
  ``config.boot'' in the XORP installation directory.
  This file can be specified by the ``-b~~$<$filename$>$'' command line
  option:
\begin{verbatim}
    xorp_rtrmgr -b my_config.boot
\end{verbatim}

    See ``rtrmgr/config.boot.sample'' for an example of a
    configuration file (note that this file MUST be modified
    before using it).

\item
  Use the \xorpsh command line interface after the \rtrmgr is started.
  It should be noted that command line completion in the \xorpsh
  does greatly simplify configuration.
\end{itemize}

\noindent
A mixture of both methods is permissible. For example,
a configuration file can also be loaded from within the \xorpsh.

At very minimum, a router's interfaces must be configured (see
Section~\ref{sec:network_interfaces}). Typically, the FEA needs to be
configured (\eg to enable unicast forwarding); the FEA configuration is
described in Section~\ref{sec:fea}. All protocol configuration is
described in Section~\ref{sec:protocols}.

\section{Network Interfaces}
\label{sec:network_interfaces}

A XORP router will only use interfaces that it has been explicitly
configured to use. Even for protocols such as BGP that are agnostic to
interfaces, if the next-hop router for a routing entry is not through
a configured interface the route will not be installed. For protocols
that are explicitly aware of interfaces only configured interfaces
will be used.

Every physical network device in the system is considered to be an
``interface''. Every interface can contain a number of virtual
interfaces (``vif''s). In the majority of cases the interface name and
vif name will be identical and will map to the name given to the
interface by the operating system. A virtual interface is configured
with the address or addresses that should be used. At each level in
the configuration hierarchy ({\tt interface}, {\tt vif} and
{\tt address}) it is necessary to enable this part of the
configuration.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
interfaces \{\\
\>restore-original-config-on-shutdown: false\\
\>interface dc0 \{\\
\>\>description: "data interface"\\
\>\>disable: false\\
\>\>/* default-system-config */\\
\>\>vif dc0 \{\\
\>\>\>disable: false\\
\>\>\>address 10.10.10.10 \{\\
\>\>\>\>prefix-length: 24\\
\>\>\>\>broadcast: 10.10.10.255\\
\>\>\>\>disable: false\\
\>\>\>\}\\
\>\>\>/*\\
\>\>\>address 10:10:10:10:10:10:10:10 \{\\
\>\>\>\>prefix-length: 64\\
\>\>\>\>disable: false\\
\>\>\>\}\\
\>\>\>*/\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}
\vspace{0.1in}

We recommend that you select the interfaces that you want to use on
your system and configure them as above. If you are configuring an
interface that is currently being used by the the system make sure
that there is no mismatch in the {\tt address}, {\tt prefix-length} and
{\tt broadcast} arguments.
If the \linebreak
{\tt default-system-config} statement is used, it
instructs the FEA that the interface should be configured by using
the existing interface information from the underlying system.
In that case, the {\tt vif} and {\tt address} sections must not be
configured.

\section{Forwarding Engine Abstraction}
\label{sec:fea}

It is a requirement to explicitly enable forwarding for each
protocol family.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
fea \{\\
\>unicast-forwarding4 \{\\
\>\>disable: false\\
\>\}\\
/*\\
\>unicast-forwarding6 \{\\
\>\>disable: false\\
\>\}\\
*/\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}
\vspace{0.1in}

If IPv4 forwarding is required you will require the configuration
above. If the system supports IPv6 and IPv6 forwarding is required,
then the {\tt unicast-forwarding6} statement must be used to enable
it~\footnote{Note that prior to XORP Release-1.1, the
{\tt enable-unicast-forwarding4} and {\tt enable-unicast-forwarding6}
flags were used instead to enable or disable the IPv4 and IPv6 forwarding.}.

\newpage
\section{Protocols}
\label{sec:protocols}

A unicast router typically will be configured with one or more
of the following protocols:
StaticRoutes (Section~\ref{sec:protocols:static_routes}),
RIP (Section~\ref{sec:protocols:rip})
or BGP (Section~\ref{sec:protocols:bgp}).

A multicast router must have the MFEA configured
(Section~\ref{sec:protocols:mfea}). Typically, a multicast router should
have IGMP/MLD configured (Section~\ref{sec:protocols:mld6igmp}).
Currently, PIM-SM is the only multicast routing protocol implemented
(Section~\ref{sec:protocols:pim}). If some multicast-specific static
routes need to be installed in the MRIB (for computing the reverse-path
forwarding information), those can be specified in the StaticRoutes
configuration (Section~\ref{sec:protocols:static_routes}).
If there are no
unicast routing protocols configured, the FIB2MRIB module may
need to be configured as well (Section~\ref{sec:protocols:fib2mrib}).

\subsection{Static Routes}
\label{sec:protocols:static_routes}

This is the simplest routing protocol in XORP. It allows the
installation of unicast or multicast static routes (either IPv4 or
IPv6).  Note that in case of multicast the routes are installed only
in the user-level Multicast Routing Information Base and are used for
multicast-specific reverse-path forwarding information by multicast routing
protocols such as PIM-SM.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
protocols \{\\
\>static \{\\
\>\>route 10.20.0.0/16 \{\\
\>\>\>nexthop: 10.10.10.20\\
\>\>\>metric: 1\\
\>\>\}\\
\>\>mrib-route 10.20.0.0/16 \{\\
\>\>\>nexthop: 10.10.10.30\\
\>\>\>metric: 1\\
\>\>\}\\
\>\>/*\\
\>\>route 20:20:20:20::/64 \{\\
\>\>\>nexthop: 10:10:10:10:10:10:10:20\\
\>\>\>metric: 1\\
\>\>\}\\
\>\>mrib-route 20:20:20:20::/64 \{\\
\>\>\>nexthop: 10:10:10:10:10:10:10:30\\
\>\>\>metric: 1\\
\>\>\}\\
\>\>*/\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}
\vspace{0.1in}

\newpage
\subsection{Routing Information Protocol}
\label{sec:protocols:rip}

In order to run RIP it is sufficient to specify the set of interfaces,
vifs and addresses ({\tt interface}, {\tt vif} and {\tt address}) on
which RIP is enabled~\footnote{Note that prior to XORP Release-1.1,
the {\tt enable} flag was used instead of {\tt disable} to enable
or disable each part of the configuration.}.

If you wish to announce routes then it is necessary to
the routes that are to be announced. For example, {\tt connected} and 
{\tt static}~\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.}.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
policy \{\\
\>/* Describe connected routes for redistribution */\\
\>policy-statement connected \{\\
\>\>term export \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "connected"\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
policy \{\\
\>/* Describe static routes for redistribution */\\
\>policy-statement static \{\\
\>\>term export \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "static"\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
protocols \{\\
\>rip \{\\
/* Redistribute routes for connected interfaces */\\
/*\\
\>\>export: "connected"\\
*/\\
/* Redistribute static routes */\\
/*\\
\>\>export: "static"\\
*/\\
/* Redistribute connected and static routes */\\
/*\\
\>\>export: "connected,static"\\
*/\\
/* Run on specified network interface addresses */\\
\>\>interface dc0 \{\\
\>\>\>vif dc0 \{\\
\>\>\>\>address 10.10.10.10 \{\\
\>\>\>\>\>disable: false\\
\>\>\>\>\}\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}

\newpage
\subsection{Open Shortest Path First}
\label{sec:protocols:ospf}

In order to run OSPF Version 2 the {\tt router-id} must be specified, it
is a unique IPv4 address within the Autonomous System. The smallest IP
address of an interface belonging to the router is a good choice.

OSPF splits networks into areas so an {\tt area} must be configured.

Configure one or more of the routers configured interface/vif/address
in this area.

{\bf The {\stt 4} in {\stt ospf4} refers to the IPv4 address family.}

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
protocols \{\\
\>ospf4 \{\\
\>\>router-id: 10.10.10.10\\
\\
\>\>area 0.0.0.0 \{\\
\>\>\>interface dc0 \{\\
\>\>\>\>vif dc0 \{\\
\>\>\>\>\>address 10.10.10.10 \{\\
\>\>\>\>\>\}\\
\>\>\>\>\}\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
\end{tabbing}
\end{alltt}
\end{minipage}
}

\newpage
\subsection{Border Gateway Protocol}
\label{sec:protocols:bgp}

In order to run BGP the {\tt bgp-id} (BGP Identifier) and {\tt local-as}
(Autonomous System number) must be specified.

The {\tt peer} statement specifies a peering. The argument to the peer
statement is the IP address of the peer. The {\tt local-ip} is the IP
address that TCP should use. The {\tt as} is the Autonomous System Number
of the peer.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
protocols \{\\
\>bgp \{\\
\>\>bgp-id: 10.10.10.10\\
\>\>local-as: 65002\\
\\
\>\>peer 10.30.30.30 \{\\
\>\>\>local-ip: 10.10.10.10\\
\>\>\>as: 65000\\
\>\>\>next-hop: 10.10.10.20\\
\>\>\>/*\\
\>\>\>local-port: 179\\
\>\>\>peer-port: 179\\
\>\>\>*/\\
\>\>\>/* holdtime: 120 */\\
\>\>\>/* disable: false */\\
\\
\>\>\>/* IPv4 unicast is enabled by default */\\
\>\>\>/* ipv4-unicast: true */\\
\\
\>\>\>/* Optionally enable other AFI/SAFI combinations */\\
\>\>\>/* ipv4-multicast: true */\\
\>\>\>/* ipv6-unicast: true */\\
\>\>\>/* ipv6-multicast: true */\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}
\vspace{0.1in}

\newpage
\subsection{Multicast Forwarding Engine Abstraction}
\label{sec:protocols:mfea}

The MFEA must be configured if the XORP router is to be used for multicast
routing. The MFEA for IPv4 and IPv6 are configured separately.

In the configuration we must explicitly configure the entity itself, and
each {\tt vif}. The {\tt traceoptions} section is used to explicitly enable
log information that can be used for debugging purpose~\footnote{Note that
prior to XORP Release-1.1, the {\tt enable} flag was used instead of
{\tt disable} to enable or disable each part of the configuration.}.

\vspace{0.1in}
\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
plumbing \{\\
\>mfea4 \{\\
\>\>disable: false\\
\>\>interface dc0 \{\\
\>\>\>vif dc0 \{\\
\>\>\>\>disable: false\\
\>\>\>\}\\
\>\>\}\\
\>\>interface register\_vif \{\\
\>\>\>vif register\_vif \{\\
\>\>\>\>/* Note: this vif should be always enabled */\\
\>\>\>\>disable: true\\
\>\>\>\}\\
\>\>\}\\
\>\>traceoptions \{\\
\>\>\>flag all \{\\
\>\>\>\>disable: true\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}\\
\\
plumbing \{\\
\>mfea6 \{\\
\>\>disable: true\\
\>\>interface dc0 \{\\
\>\>\>vif dc0 \{\\
\>\>\>\>disable: true\\
\>\>\>\}\\
\>\>\}\\
\>\>interface register\_vif \{\\
\>\>\>vif register\_vif \{\\
\>\>\>\>/* Note: this vif should be always enabled */\\
\>\>\>\>disable: true\\
\>\>\>\}\\
\>\>\}\\
\>\>traceoptions \{\\
\>\>\>flag all \{\\
\>\>\>\>disable: true\\
\>\>\>\}\\
\>\>\}\\
\>\}\\
\}
\end{tabbing}
\end{alltt}
\end{minipage}
}
\vspace{0.1in}