policy.tex

xorp源码hg

{\tt network6} & {\tt :} & ipv6net & Matches the prefix of an IPv6 route. \\
\hline
{\tt network4-list} & {\tt :} & txt & Matches if the named IPv4 set
contains the route.\\
{\tt network6-list} & {\tt :} & txt & Matches if the named IPv6 set
contains the route.\\
\hline
{\tt prefix-length4} & {\tt :} & u32range & Matches if the IPv4 route has a
prefix length within the specified range. \\
{\tt prefix-length6} & {\tt :} & u32range & Matches if the IPv6 route has a
prefix length within the specified range. \\
\hline
\end{tabular}
\caption{\label{policy_common_match_from}Common match conditions in the {\tt from}
block for all protocols}
\end{table}

Note that the {\tt network4} and {\tt prefix-length4} statements
are independent and cannot be used together to match, say, all routes
within a specific prefix. For example, using both statements
{\tt network4 = 10.0.0.0/8} and {\tt prefix-length4 >= 8} is incorrect
if the intend is to match all routes within prefix 10.0.0.0/8.
Instead, the {\tt network4 <= 10.0.0.0/4} statement alone should be used
for that purpose.
The same applies for the {\tt network6} and {\tt prefix-length6}
statements as well.

The following comparison operators or keywords can be used to match network
prefixes:

\begin{itemize}
  \item {\tt ==} or {\tt exact} to match the given network prefix.

  \item {\tt <} or {\tt longer} to match all network prefixes that are
  covered by the given network prefix (that prefix excluded).

  \item {\tt <=} or {\tt orlonger} to match all network prefixes that
  are covered by the given network prefix (that prefix included).

  \item {\tt >} or {\tt shorter} to match all network prefixes that cover
  the given network prefix (that prefix excluded).

  \item {\tt >=} or {\tt orshorter} to match all network prefixes that
  cover the given network prefix (that prefix included).

  \item {\tt !=} or {\tt not} to match all network prefixes except the
  given one.

\end{itemize}


The match conditions for the {\tt to} block are identical in syntax and
semantics as the {\tt from} block except for one case.  It is illegal to specify
the protocol in the {\tt to} block.  The reason for this is that when a policy
is bound to a protocol via the {\tt export} or {\tt import} statement, that
protocol automatically becomes the one referenced in the {\tt to} block.  When a
BGP export policy is created, the {\tt to} must be BGP by definition as {\em it}
is doing the advertisement.

\subsection{Actions}
Common actions to all protocols are summarized in
table~\ref{policy_common_action}.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{9cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline\hline
{\tt accept} & none & none & Propagate this route downstream and stop executing
all policies associated to this route.\\
{\tt reject} & none & none & Do not propagate this route downstream and stop executing
all policies associated to this route.\\
\hline
{\tt trace} & {\tt :} & u32 & Enable tracing at a specific verbosity level.
Currently 1 means a single line of logging and 3 is the most verbose level. \\
\hline
\end{tabular}
\caption{\label{policy_common_action}Common actions for all protocols}
\end{table}

\section{BGP}
BGP supports policy and route redistribution.  It can be used both as a source
for redistribution (BGP-to-something) and as a target (something-to-BGP).  The
following sections summarize which aspects of BGP routes may be matched and what
actions may be taken. These are also specified in the {\tt bgp.tp} template file.

The BGP policy engine currently has an interesting feature / bug.  An export
filter is placed on the RIB branch too.  Thus, if an export policy rejects all
routes, the RIB will never receive these routes and no routes will go into the
forwarding plane.  To avoid this, match {\tt neighbor: 0.0.0.0} in the {\tt to}
block and {\tt accept}.  The next term could match all and reject.  This
``feature'' is actually useful if you want a BGP peering but do not wish to
change the routing table.

\subsection{Match Conditions}
Table~\ref{policy_bgp_match} summarizes the match conditions specific to BGP.
\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline\hline
{\tt nexthop4} & {\tt :} & ipv4range & Matches if the IPv4 next-hop of the route
lies within the specified range.\\
{\tt nexhtop6} & {\tt :} & ipv6range & Matches if the IPv6 next-hop of the route
lies within the specified range. \\
\hline
{\tt as-path} & {\tt :} & txt & Matches an AS-Path with a regular expression. \\
{\tt as-path-list} & {\tt :} & as-path-list & If the set contains a regular
expression which matches an AS-Path, then the term matches. \\
\hline
{\tt community} & {\tt :} & txt & Matches against the specified community. \\
{\tt community-list} & {\tt :} & community-list & If the set contains a
community which matches, then the term matches. \\
\hline
{\tt neighbor} & {\tt :} & ipv4range & In a {\tt from} block it matches whether
the route was learnt from a BGP peer in the specified range.  In a {\tt to}
block it matches whether the route is about to be advertised to a BGP peer in
the specified range. \\
\hline
{\tt origin} & {\tt :} & u32 & Matches the origin attribute of the route. 0
stands for IGP, 1 for EGP and 2 for INCOMPLETE.  \\
\hline
{\tt med} & {\tt :} & u32range & Matches the MED of the route. \\
\hline
{\tt localpref} & {\tt :} & u32range & Matches the local preference of the route. \\
\hline
{\tt was-aggregated} & {\tt :} & bool & True if this route contributed to
origination of an aggregate route. \\
\hline
\end{tabular}
\caption{\label{policy_bgp_match}BGP specific match conditions.}
\end{table}

\subsection{Actions}
Table~\ref{policy_bgp_action} summarizes the actions specific to BGP.
\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline\hline
{\tt nexthop4} & {\tt :} & ipv4 & Replaces the IPv4 nexthop. \\
{\tt nexhtop6} & {\tt :} & ipv6 & Replaces the IPv6 nexthop. \\
\hline
{\tt as-path-prepend} & {\tt :} & txt & Prepends the specified AS-Path to the
one on the route. \\
{\tt as-path-expand} & {\tt :} & u32 & Prepends the last AS in the path the
specified number of times. \\
\hline
{\tt community} & {\tt :} & txt &  Sets the community attribute.\\
{\tt community-add} & {\tt :} & txt & Adds the specified community. \\
\hline
{\tt community-del} & {\tt :} & txt & Deletes the specified community. \\
\hline
{\tt origin} & {\tt :} & u32 & Sets the origin. \\
\hline
{\tt med} & {\tt :} & u32 & Sets the MED. \\
\hline
{\tt med-remove} & {\tt :} & bool & Remove MED if present. \\
\hline
{\tt localpref} & {\tt :} & u32 & Sets the localpref. \\
\hline
{\tt aggregate-prefix-len} & {\tt :} & u32 & Originate an aggregate route with
this prefix length. \\
\hline
{\tt aggregate-brief-mode} & {\tt :} & bool & If true omit AS SET generation
in aggregate route. \\
\hline
\end{tabular}
\caption{\label{policy_bgp_action}BGP specific actions.}
\end{table}

\section{Static Routes}
Static routes support policy and may be used as a source for route
redistribution.
Table~\ref{policy_static_match} summarizes the match conditions specific to
static routes.
These are also specified in the {\tt static\_routes.tp} template file.
Note that the static routes can match only the {\tt from}
block, because then can only be exported.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline
\hline
{\tt nexthop4} & {\tt :} & ipv4range & Matches if the IPv4 next-hop of
the route lies within the specified range.\\

\hline
{\tt nexthop6} & {\tt :} & ipv6range & Matches if the IPv6 next-hop of
the route lies within the specified range.\\

\hline
{\tt metric} & {\tt :} & u32 & Matches the metric of a route.\\
\hline

\end{tabular}
\caption{\label{policy_static_match}Static routes specific match conditions.}
\end{table}


\section{RIP and RIPng}

RIP and RIPng support policy and route redistribution.  Each of
them can be used both as a source for redistribution
(RIP/RIPng-to-something) and as a target (something-to-RIP/RIPng). The
following sections summarize which aspects of 
RIP and RIPng routes may be matched and what actions may be taken. These
are also specified in the {\tt rip.tp} and {\tt ripng.tp} template files.

\subsection{Match Conditions}

Table~\ref{policy_rip_match} summarizes the match conditions specific to
RIP and RIPng.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline
\hline
{\tt nexthop4} & {\tt :} & ipv4range & Matches if the IPv4 next-hop of
the route lies within the specified range (RIP only).\\

\hline
{\tt nexthop4} & {\tt :} & ipv6range & Matches if the IPv6 next-hop of
the route lies within the specified range (RIPng only).\\

\hline
{\tt metric} & {\tt :} & u32 & Matches the metric of a route.\\

\hline
{\tt tag} & {\tt :} & u32range & Matches the route tag field in a route. \\
\hline

\end{tabular}
\caption{\label{policy_rip_match}RIP and RIPng specific match conditions.}
\end{table}

\subsection{Actions}

Table~\ref{policy_rip_action} summarizes the actions specific to RIP and
RIPng.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline
\hline
{\tt nexthop4} & {\tt :} & ipv4 & Replaces the IPv4 nexthop (RIP only).\\

\hline
{\tt nexthop6} & {\tt :} & ipv6 & Replaces the IPv6 nexthop (RIPng only).\\

\hline
{\tt metric} & {\tt :} & u32 & Sets the metric. \\

\hline
{\tt tag} & {\tt :} & u32 & Sets the route tag field. \\
\hline

\end{tabular}
\caption{\label{policy_rip_action}RIP and RIPng specific actions.}
\end{table}

\section{OSPF}
OSPF supports policy and route redistribution.  It can be used both as
a source for redistribution (OSPF-to-something) and as a target
(something-to-OSPF). The following sections summarize which aspects of
OSPF routes may be matched and what actions may be taken. These are
also specified in the {\tt ospfv2.tp} template file.

\subsection{Match Conditions}
Table~\ref{policy_ospf_match} summarizes the match conditions specific to
OSPF.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline\hline
{\tt nexthop4} & {\tt :} & ipv4range & Matches if the IPv4 next-hop of the route
lies within the specified range.\\

\hline
{\tt metric} & {\tt :} & u32 & Matches metric \\
\hline

\hline
{\tt ebit} & {\tt :} & bool & Matches ebit true for type2 false for type1 \\
\hline

\hline
{\tt tag} & {\tt :} & u32range & Matches tag field in AS-external-LSA \\
\hline

\end{tabular}
\caption{\label{policy_ospf_match}OSPF specific match conditions.}
\end{table}

\subsection{Actions}
Table~\ref{policy_ospf_action} summarizes the actions specific to OSPF.

\begin{table}[h]
\centering
\begin{tabular}{|l|c|c|p{7cm}|}
\hline
Variable & Operator & Argument type & Semantics \\
\hline\hline
{\tt nexthop4} & {\tt :} & ipv4 & Set the forwarding field in an
AS-external-LSA \\

\hline
{\tt metric} & {\tt :} & u32 & Set the metric \\
\hline

\hline
{\tt ebit} & {\tt :} & bool & Set ebit true for type2 false for type1 \\
\hline

\hline
{\tt tag} & {\tt :} & u32 & Set tag field in AS-external-LSA \\
\hline

\end{tabular}
\caption{\label{policy_ospf_action}OSPF specific actions.}
\end{table}

\section{Examples}
Some common policies are presented in this section for a better understanding of
the syntax.  Here is a simple one:

\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
policy \{\\
\>policy-statement medout \{\\
\>\>term a \{\\
\>\>\>then \{\\
\>\>\>\>med: 42\\
\>\>\>\}\\
\>\>\} \\
\>\} \\
\}\\
\\
protocols \{\\
\>bgp \{\\
\>\>export: "medout"\\
\>\}\\
\}\\
\end{tabbing} 
\end{alltt}
\end{minipage}
}

This will cause all routes leaving BGP to have a MED of 42.  The whole decision
process is unaffected as routes come in with their original MED.  

If this were used as an import policy, then routes flowing into the decision
process would have a modified MED.  As a consequence, it is also possible that
the advertised routes will have a MED of 42, even though it is used as an import
policy.

\newpage
Here is a more complicated example:

\noindent\framebox[\textwidth][l]{\scriptsize
\begin{minipage}{6in}
\begin{alltt}
\begin{tabbing}
xx\=xx\=xx\=xx\=xx\=\kill
policy \{\\
\>policy-statement static-to-bgp \{\\
\>\>term friend \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "static"\\
\>\>\>\}\\
\>\>\>to \{\\
\>\>\>\>neighbor: 10.0.0.1\\
\>\>\>\}\\
\>\>\>then \{\\
\>\>\>\>med: 1\\
\>\>\>\>accept\\
\>\>\>\}\\
\>\>\} \\
\>\>term metric \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "static"\\
\>\>\>\>metric: 7\\
\>\>\>\}\\
\>\>\>to \{\\
\>\>\>\>neighbor: 10.0.0.2\\
\>\>\>\}\\
\>\>\>then \{\\
\>\>\>\>trace: 1\\
\>\>\>\>med: 7\\
\>\>\>\>accept\\
\>\>\>\}\\
\>\>\} \\
\>\>term drop \{\\
\>\>\>from \{\\
\>\>\>\>protocol: "static"\\
\>\>\>\}\\
\>\>\>then \{\\
\>\>\>\>reject\\
\>\>\>\}\\
\>\>\} \\
\>\} \\
\} \\
\\
protocols \{\\
\>bgp \{\\
\>\>export: "static-to-bgp" \\
\>\}\\
\}
\end{tabbing} 
\end{alltt}
\end{minipage}
}

In this example, all static routes are redistributed to BGP.  The BGP peer
10.0.0.1 will receive all of them with a MED of 1.  

For some reason, static routes with a metric of 7 are important and they are
advertised to the BGP peer 10.0.0.2 with a MED of 7 and are also logged.  Note
that 10.0.0.1 will receive these static routes with a MED of 1, even if they had
a metric of 7.

Finally, all static routes which are now in BGP are dropped on the export path.
All other BGP peers will not receive any of the static routes.