Google Git
Sign in
googlers / maze / iproute2 / e8740e42ece716b1dcce89a573fba413846af468 / . / doc / ip-cref.tex
blob: d8fed66e23af19246bfb970a589894853338ad97 [file] [log] [blame]
\documentstyle[12pt,twoside]{article}
\def\TITLE{IP Command Reference}
\input preamble
\begin{center}
\Large\bf IP Command Reference.
\end{center}
\begin{center}
{ \large Alexey~N.~Kuznetsov } \\
\em Institute for Nuclear Research, Moscow \\
\verb|kuznet@ms2.inr.ac.ru| \\
\rm April 14, 1999
\end{center}
\vspace{5mm}
\tableofcontents
\newpage
\section{About this document}
This document presents a comprehensive description of the \verb|ip| utility
from the \verb|iproute2| package. It is not a tutorial or user's guide.
It is a {\em dictionary\/}, not explaining terms,
but translating them into other terms, which may also be unknown to the reader.
However, the document is self-contained and the reader, provided they have a
basic networking background, will find enough information
and examples to understand and configure Linux-2.2 IP and IPv6
networking.
This document is split into sections explaining \verb|ip| commands
and options, decrypting \verb|ip| output and containing a few examples.
More voluminous examples and some topics, which require more elaborate
discussion, are in the appendix.
The paragraphs beginning with NB contain side notes, warnings about
bugs and design drawbacks. They may be skipped at the first reading.
\section{{\tt ip} --- command syntax}
The generic form of an \verb|ip| command is:
\begin{verbatim}
ip [ OPTIONS ] OBJECT [ COMMAND [ ARGUMENTS ]]
\end{verbatim}
where \verb|OPTIONS| is a set of optional modifiers affecting the
general behaviour of the \verb|ip| utility or changing its output. All options
begin with the character \verb|'-'| and may be used in either long or abbreviated
forms. Currently, the following options are available:
\begin{itemize}
\item \verb|-V|, \verb|-Version|
--- print the version of the \verb|ip| utility and exit.
\item \verb|-s|, \verb|-stats|, \verb|-statistics|
--- output more information. If the option
appears twice or more, the amount of information increases.
As a rule, the information is statistics or some time values.
\item \verb|-f|, \verb|-family| followed by a protocol family
identifier: \verb|inet|, \verb|inet6| or \verb|link|.
--- enforce the protocol family to use. If the option is not present,
the protocol family is guessed from other arguments. If the rest of the command
line does not give enough information to guess the family, \verb|ip| falls back to the default
one, usually \verb|inet| or \verb|any|. \verb|link| is a special family
identifier meaning that no networking protocol is involved.
\item \verb|-4|
--- shortcut for \verb|-family inet|.
\item \verb|-6|
--- shortcut for \verb|-family inet6|.
\item \verb|-0|
--- shortcut for \verb|-family link|.
\item \verb|-o|, \verb|-oneline|
--- output each record on a single line, replacing line feeds
with the \verb|'\'| character. This is convenient when you want to
count records with \verb|wc| or to \verb|grep| the output. The trivial
script \verb|rtpr| converts the output back into readable form.
\item \verb|-r|, \verb|-resolve|
--- use the system's name resolver to print DNS names instead of
host addresses.
\begin{NB}
Do not use this option when reporting bugs or asking for advice.
\end{NB}
\begin{NB}
\verb|ip| never uses DNS to resolve names to addresses.
\end{NB}
\end{itemize}
\verb|OBJECT| is the object to manage or to get information about.
The object types currently understood by \verb|ip| are:
\begin{itemize}
\item \verb|link| --- network device
\item \verb|address| --- protocol (IP or IPv6) address on a device
\item \verb|neighbour| --- ARP or NDISC cache entry
\item \verb|route| --- routing table entry
\item \verb|rule| --- rule in routing policy database
\item \verb|maddress| --- multicast address
\item \verb|mroute| --- multicast routing cache entry
\item \verb|tunnel| --- tunnel over IP
\end{itemize}
Again, the names of all objects may be written in full or
abbreviated form, f.e.\ \verb|address| is abbreviated as \verb|addr|
or just \verb|a|.
\verb|COMMAND| specifies the action to perform on the object.
The set of possible actions depends on the object type.
As a rule, it is possible to \verb|add|, \verb|delete| and
\verb|show| (or \verb|list|) objects, but some objects
do not allow all of these operations or have some additional commands.
The \verb|help| command is available for all objects. It prints
out a list of available commands and argument syntax conventions.
If no command is given, some default command is assumed.
Usually it is \verb|list| or, if the objects of this class
cannot be listed, \verb|help|.
\verb|ARGUMENTS| is a list of arguments to the command.
The arguments depend on the command and object. There are two types of arguments:
{\em flags\/}, consisting of a single keyword, and {\em parameters\/},
consisting of a keyword followed by a value. For convenience,
each command has some {\em default parameter\/}
which may be omitted. F.e.\ parameter \verb|dev| is the default
for the {\tt ip link} command, so {\tt ip link ls eth0} is equivalent
to {\tt ip link ls dev eth0}.
In the command descriptions below such parameters
are distinguished with the marker: ``(default)''.
Almost all keywords may be abbreviated with several first (or even single)
letters. The shortcuts are convenient when \verb|ip| is used interactively,
but they are not recommended in scripts or when reporting bugs
or asking for advice. ``Officially'' allowed abbreviations are listed
in the document body.
\section{{\tt ip} --- error messages}
\verb|ip| may fail for one of the following reasons:
\begin{itemize}
\item
A syntax error on the command line: an unknown keyword, incorrectly formatted
IP address {\em et al\/}. In this case \verb|ip| prints an error message
and exits. As a rule, the error message will contain information
about the reason for the failure. Sometimes it also prints a help page.
\item
The arguments did not pass verification for self-consistency.
\item
\verb|ip| failed to compile a kernel request from the arguments
because the user didn't give enough information.
\item
The kernel returned an error to some syscall. In this case \verb|ip|
prints the error message, as it is output with \verb|perror(3)|,
prefixed with a comment and a syscall identifier.
\item
The kernel returned an error to some RTNETLINK request.
In this case \verb|ip| prints the error message, as it is output
with \verb|perror(3)| prefixed with ``RTNETLINK answers:''.
\end{itemize}
All the operations are atomic, i.e.\
if the \verb|ip| utility fails, it does not change anything
in the system. One harmful exception is \verb|ip link| command
(Sec.\ref{IP-LINK}, p.\pageref{IP-LINK}),
which may change only some of the device parameters given
on command line.
It is difficult to list all the error messages (especially
syntax errors). However, as a rule, their meaning is clear
from the context of the command.
The most common mistakes are:
\begin{enumerate}
\item Netlink is not configured in the kernel. The message is:
\begin{verbatim}
Cannot open netlink socket: Invalid value
\end{verbatim}
\item RTNETLINK is not configured in the kernel. In this case
one of the following messages may be printed, depending on the command:
\begin{verbatim}
Cannot talk to rtnetlink: Connection refused
Cannot send dump request: Connection refused
\end{verbatim}
\item The \verb|CONFIG_IP_MULTIPLE_TABLES| option was not selected
when configuring the kernel. In this case any attempt to use the
\verb|ip| \verb|rule| command will fail, f.e.
\begin{verbatim}
kuznet@kaiser $ ip rule list
RTNETLINK error: Invalid argument
dump terminated
\end{verbatim}
\end{enumerate}
\section{{\tt ip link} --- network device configuration}
\label{IP-LINK}
\paragraph{Object:} A \verb|link| is a network device and the corresponding
commands display and change the state of devices.
\paragraph{Commands:} \verb|set| and \verb|show| (or \verb|list|).
\subsection{{\tt ip link set} --- change device attributes}
\paragraph{Abbreviations:} \verb|set|, \verb|s|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|dev NAME| (default)
--- \verb|NAME| specifies the network device on which to operate.
\item \verb|up| and \verb|down|
--- change the state of the device to \verb|UP| or \verb|DOWN|.
\item \verb|arp on| or \verb|arp off|
--- change the \verb|NOARP| flag on the device.
\begin{NB}
This operation is {\em not allowed\/} if the device is in state \verb|UP|.
Though neither the \verb|ip| utility nor the kernel check for this condition.
You can get unpredictable results changing this flag while the
device is running.
\end{NB}
\item \verb|multicast on| or \verb|multicast off|
--- change the \verb|MULTICAST| flag on the device.
\item \verb|dynamic on| or \verb|dynamic off|
--- change the \verb|DYNAMIC| flag on the device.
\item \verb|name NAME|
--- change the name of the device. This operation is not
recommended if the device is running or has some addresses
already configured.
\item \verb|txqueuelen NUMBER| or \verb|txqlen NUMBER|
--- change the transmit queue length of the device.
\item \verb|mtu NUMBER|
--- change the MTU of the device.
\item \verb|address LLADDRESS|
--- change the station address of the interface.
\item \verb|broadcast LLADDRESS|, \verb|brd LLADDRESS| or \verb|peer LLADDRESS|
--- change the link layer broadcast address or the peer address when
the interface is \verb|POINTOPOINT|.
\vskip 1mm
\begin{NB}
For most devices (f.e.\ for Ethernet) changing the link layer
broadcast address will break networking.
Do not use it, if you do not understand what this operation really does.
\end{NB}
\item \verb|netns PID|
--- move the device to the network namespace associated with the process PID.
\end{itemize}
\vskip 1mm
\begin{NB}
The \verb|PROMISC| and \verb|ALLMULTI| flags are considered
obsolete and should not be changed administratively, though
the {\tt ip} utility will allow that.
\end{NB}
\paragraph{Warning:} If multiple parameter changes are requested,
\verb|ip| aborts immediately after any of the changes have failed.
This is the only case when \verb|ip| can move the system to
an unpredictable state. The solution is to avoid changing
several parameters with one {\tt ip link set} call.
\paragraph{Examples:}
\begin{itemize}
\item \verb|ip link set dummy address 00:00:00:00:00:01|
--- change the station address of the interface \verb|dummy|.
\item \verb|ip link set dummy up|
--- start the interface \verb|dummy|.
\end{itemize}
\subsection{{\tt ip link show} --- display device attributes}
\label{IP-LINK-SHOW}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|lst|, \verb|sh|, \verb|ls|,
\verb|l|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|dev NAME| (default)
--- \verb|NAME| specifies the network device to show.
If this argument is omitted all devices are listed.
\item \verb|up|
--- only display running interfaces.
\end{itemize}
\paragraph{Output format:}
\begin{verbatim}
kuznet@alisa:~ $ ip link ls eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc cbq qlen 100
link/ether 00:a0:cc:66:18:78 brd ff:ff:ff:ff:ff:ff
kuznet@alisa:~ $ ip link ls sit0
5: sit0@NONE: <NOARP,UP> mtu 1480 qdisc noqueue
link/sit 0.0.0.0 brd 0.0.0.0
kuznet@alisa:~ $ ip link ls dummy
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
kuznet@alisa:~ $
\end{verbatim}
The number before each colon is an {\em interface index\/} or {\em ifindex\/}.
This number uniquely identifies the interface. This is followed by the {\em interface name\/}
(\verb|eth0|, \verb|sit0| etc.). The interface name is also
unique at every given moment. However, the interface may disappear from the
list (f.e.\ when the corresponding driver module is unloaded) and another
one with the same name may be created later. Besides that,
the administrator may change the name of any device with
\verb|ip| \verb|link| \verb|set| \verb|name|
to make it more intelligible.
The interface name may have another name or \verb|NONE| appended
after the \verb|@| sign. This means that this device is bound to some other
device,
i.e.\ packets send through it are encapsulated and sent via the ``master''
device. If the name is \verb|NONE|, the master is unknown.
Then we see the interface {\em mtu\/} (``maximal transfer unit''). This determines
the maximal size of data which can be sent as a single packet over this interface.
{\em qdisc\/} (``queuing discipline'') shows the queuing algorithm used
on the interface. Particularly, \verb|noqueue| means that this interface
does not queue anything and \verb|noop| means that the interface is in blackhole
mode i.e.\ all packets sent to it are immediately discarded.
{\em qlen\/} is the default transmit queue length of the device measured
in packets.
The interface flags are summarized in the angle brackets.
\begin{itemize}
\item \verb|UP| --- the device is turned on. It is ready to accept
packets for transmission and it may inject into the kernel packets received
from other nodes on the network.
\item \verb|LOOPBACK| --- the interface does not communicate with other
hosts. All packets sent through it will be returned
and nothing but bounced packets can be received.
\item \verb|BROADCAST| --- the device has the facility to send packets
to all hosts sharing the same link. A typical example is an Ethernet link.
\item \verb|POINTOPOINT| --- the link has only two ends with one node
attached to each end. All packets sent to this link will reach the peer
and all packets received by us came from this single peer.
If neither \verb|LOOPBACK| nor \verb|BROADCAST| nor \verb|POINTOPOINT|
are set, the interface is assumed to be NMBA (Non-Broadcast Multi-Access).
This is the most generic type of device and the most complicated one, because
the host attached to a NBMA link has no means to send to anyone
without additionally configured information.
\item \verb|MULTICAST| --- is an advisory flag indicating that the interface
is aware of multicasting i.e.\ sending packets to some subset of neighbouring
nodes. Broadcasting is a particular case of multicasting, where the multicast
group consists of all nodes on the link. It is important to emphasize
that software {\em must not\/} interpret the absence of this flag as the inability
to use multicasting on this interface. Any \verb|POINTOPOINT| and
\verb|BROADCAST| link is multicasting by definition, because we have
direct access to all the neighbours and, hence, to any part of them.
Certainly, the use of high bandwidth multicast transfers is not recommended
on broadcast-only links because of high expense, but it is not strictly
prohibited.
\item \verb|PROMISC| --- the device listens to and feeds to the kernel all
traffic on the link even if it is not destined for us, not broadcasted
and not destined for a multicast group of which we are member. Usually
this mode exists only on broadcast links and is used by bridges and for network
monitoring.
\item \verb|ALLMULTI| --- the device receives all multicast packets
wandering on the link. This mode is used by multicast routers.
\item \verb|NOARP| --- this flag is different from the other ones. It has
no invariant value and its interpretation depends on the network protocols
involved. As a rule, it indicates that the device needs no address
resolution and that the software or hardware knows how to deliver packets
without any help from the protocol stacks.
\item \verb|DYNAMIC| --- is an advisory flag indicating that the interface is
dynamically created and destroyed.
\item \verb|SLAVE| --- this interface is bonded to some other interfaces
to share link capacities.
\end{itemize}
\vskip 1mm
\begin{NB}
There are other flags but they are either obsolete (\verb|NOTRAILERS|)
or not implemented (\verb|DEBUG|) or specific to some devices
(\verb|MASTER|, \verb|AUTOMEDIA| and \verb|PORTSEL|). We do not discuss
them here.
\end{NB}
The second line contains information on the link layer addresses
associated with the device. The first word (\verb|ether|, \verb|sit|)
defines the interface hardware type. This type determines the format and semantics
of the addresses and is logically part of the address.
The default format of the station address and the broadcast address
(or the peer address for pointopoint links) is a
sequence of hexadecimal bytes separated by colons, but some link
types may have their natural address format, f.e.\ addresses
of tunnels over IP are printed as dotted-quad IP addresses.
\vskip 1mm
\begin{NB}
NBMA links have no well-defined broadcast or peer address,
however this field may contain useful information, f.e.\
about the address of broadcast relay or about the address of the ARP server.
\end{NB}
\begin{NB}
Multicast addresses are not shown by this command, see
\verb|ip maddr ls| in~Sec.\ref{IP-MADDR} (p.\pageref{IP-MADDR} of this
document).
\end{NB}
\paragraph{Statistics:} With the \verb|-statistics| option, \verb|ip| also
prints interface statistics:
\begin{verbatim}
kuznet@alisa:~ $ ip -s link ls eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc cbq qlen 100
link/ether 00:a0:cc:66:18:78 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2449949362 2786187 0 0 0 0
TX: bytes packets errors dropped carrier collsns
178558497 1783945 332 0 332 35172
kuznet@alisa:~ $
\end{verbatim}
\verb|RX:| and \verb|TX:| lines summarize receiver and transmitter
statistics. They contain:
\begin{itemize}
\item \verb|bytes| --- the total number of bytes received or transmitted
on the interface. This number wraps when the maximal length of the data type
natural for the architecture is exceeded, so continuous monitoring requires
a user level daemon snapping it periodically.
\item \verb|packets| --- the total number of packets received or transmitted
on the interface.
\item \verb|errors| --- the total number of receiver or transmitter errors.
\item \verb|dropped| --- the total number of packets dropped due to lack
of resources.
\item \verb|overrun| --- the total number of receiver overruns resulting
in dropped packets. As a rule, if the interface is overrun, it means
serious problems in the kernel or that your machine is too slow
for this interface.
\item \verb|mcast| --- the total number of received multicast packets. This option
is only supported by a few devices.
\item \verb|carrier| --- total number of link media failures f.e.\ because
of lost carrier.
\item \verb|collsns| --- the total number of collision events
on Ethernet-like media. This number may have a different sense on other
link types.
\item \verb|compressed| --- the total number of compressed packets. This is
available only for links using VJ header compression.
\end{itemize}
If the \verb|-s| option is entered twice or more,
\verb|ip| prints more detailed statistics on receiver
and transmitter errors.
\begin{verbatim}
kuznet@alisa:~ $ ip -s -s link ls eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc cbq qlen 100
link/ether 00:a0:cc:66:18:78 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
2449949362 2786187 0 0 0 0
RX errors: length crc frame fifo missed
0 0 0 0 0
TX: bytes packets errors dropped carrier collsns
178558497 1783945 332 0 332 35172
TX errors: aborted fifo window heartbeat
0 0 0 332
kuznet@alisa:~ $
\end{verbatim}
These error names are pure Ethernetisms. Other devices
may have non zero values in these fields but they may be
interpreted differently.
\section{{\tt ip address} --- protocol address management}
\paragraph{Abbreviations:} \verb|address|, \verb|addr|, \verb|a|.
\paragraph{Object:} The \verb|address| is a protocol (IP or IPv6) address attached
to a network device. Each device must have at least one address
to use the corresponding protocol. It is possible to have several
different addresses attached to one device. These addresses are not
discriminated, so that the term {\em alias\/} is not quite appropriate
for them and we do not use it in this document.
The \verb|ip addr| command displays addresses and their properties,
adds new addresses and deletes old ones.
\paragraph{Commands:} \verb|add|, \verb|delete|, \verb|flush| and \verb|show|
(or \verb|list|).
\subsection{{\tt ip address add} --- add a new protocol address}
\label{IP-ADDR-ADD}
\paragraph{Abbreviations:} \verb|add|, \verb|a|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|dev NAME|
\noindent--- the name of the device to add the address to.
\item \verb|local ADDRESS| (default)
--- the address of the interface. The format of the address depends
on the protocol. It is a dotted quad for IP and a sequence of hexadecimal halfwords
separated by colons for IPv6. The \verb|ADDRESS| may be followed by
a slash and a decimal number which encodes the network prefix length.
\item \verb|peer ADDRESS|
--- the address of the remote endpoint for pointopoint interfaces.
Again, the \verb|ADDRESS| may be followed by a slash and a decimal number,
encoding the network prefix length. If a peer address is specified,
the local address {\em cannot\/} have a prefix length. The network prefix is associated
with the peer rather than with the local address.
\item \verb|broadcast ADDRESS|
--- the broadcast address on the interface.
It is possible to use the special symbols \verb|'+'| and \verb|'-'|
instead of the broadcast address. In this case, the broadcast address
is derived by setting/resetting the host bits of the interface prefix.
\vskip 1mm
\begin{NB}
Unlike \verb|ifconfig|, the \verb|ip| utility {\em does not\/} set any broadcast
address unless explicitly requested.
\end{NB}
\item \verb|label NAME|
--- Each address may be tagged with a label string.
In order to preserve compatibility with Linux-2.0 net aliases,
this string must coincide with the name of the device or must be prefixed
with the device name followed by colon.
\item \verb|scope SCOPE_VALUE|
--- the scope of the area where this address is valid.
The available scopes are listed in file \verb|/etc/iproute2/rt_scopes|.
Predefined scope values are:
\begin{itemize}
\item \verb|global| --- the address is globally valid.
\item \verb|site| --- (IPv6 only) the address is site local,
i.e.\ it is valid inside this site.
\item \verb|link| --- the address is link local, i.e.\
it is valid only on this device.
\item \verb|host| --- the address is valid only inside this host.
\end{itemize}
Appendix~\ref{ADDR-SEL} (p.\pageref{ADDR-SEL} of this document)
contains more details on address scopes.
\end{itemize}
\paragraph{Examples:}
\begin{itemize}
\item \verb|ip addr add 127.0.0.1/8 dev lo brd + scope host|
--- add the usual loopback address to the loopback device.
\item \verb|ip addr add 10.0.0.1/24 brd + dev eth0 label eth0:Alias|
--- add the address 10.0.0.1 with prefix length 24 (i.e.\ netmask
\verb|255.255.255.0|), standard broadcast and label \verb|eth0:Alias|
to the interface \verb|eth0|.
\end{itemize}
\subsection{{\tt ip address delete} --- delete a protocol address}
\paragraph{Abbreviations:} \verb|delete|, \verb|del|, \verb|d|.
\paragraph{Arguments:} coincide with the arguments of \verb|ip addr add|.
The device name is a required argument. The rest are optional.
If no arguments are given, the first address is deleted.
\paragraph{Examples:}
\begin{itemize}
\item \verb|ip addr del 127.0.0.1/8 dev lo|
--- deletes the loopback address from the loopback device.
It would be best not to repeat this experiment.
\item Disable IP on the interface \verb|eth0|:
\begin{verbatim}
while ip -f inet addr del dev eth0; do
: nothing
done
\end{verbatim}
Another method to disable IP on an interface using {\tt ip addr flush}
may be found in sec.\ref{IP-ADDR-FLUSH}, p.\pageref{IP-ADDR-FLUSH}.
\end{itemize}
\subsection{{\tt ip address show} --- display protocol addresses}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|lst|, \verb|sh|, \verb|ls|,
\verb|l|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|dev NAME| (default)
--- the name of the device.
\item \verb|scope SCOPE_VAL|
--- only list addresses with this scope.
\item \verb|to PREFIX|
--- only list addresses matching this prefix.
\item \verb|label PATTERN|
--- only list addresses with labels matching the \verb|PATTERN|.
\verb|PATTERN| is a usual shell style pattern.
\item \verb|dynamic| and \verb|permanent|
--- (IPv6 only) only list addresses installed due to stateless
address configuration or only list permanent (not dynamic) addresses.
\item \verb|tentative|
--- (IPv6 only) only list addresses which did not pass duplicate
address detection.
\item \verb|deprecated|
--- (IPv6 only) only list deprecated addresses.
\item \verb|primary| and \verb|secondary|
--- only list primary (or secondary) addresses.
\end{itemize}
\paragraph{Output format:}
\begin{verbatim}
kuznet@alisa:~ $ ip addr ls eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc cbq qlen 100
link/ether 00:a0:cc:66:18:78 brd ff:ff:ff:ff:ff:ff
inet 193.233.7.90/24 brd 193.233.7.255 scope global eth0
inet6 3ffe:2400:0:1:2a0:ccff:fe66:1878/64 scope global dynamic
valid_lft forever preferred_lft 604746sec
inet6 fe80::2a0:ccff:fe66:1878/10 scope link
kuznet@alisa:~ $
\end{verbatim}
The first two lines coincide with the output of \verb|ip link ls|.
It is natural to interpret link layer addresses
as addresses of the protocol family \verb|AF_PACKET|.
Then the list of IP and IPv6 addresses follows, accompanied by
additional address attributes: scope value (see Sec.\ref{IP-ADDR-ADD},
p.\pageref{IP-ADDR-ADD} above), flags and the address label.
Address flags are set by the kernel and cannot be changed
administratively. Currently, the following flags are defined:
\begin{enumerate}
\item \verb|secondary|
--- the address is not used when selecting the default source address
of outgoing packets (Cf.\ Appendix~\ref{ADDR-SEL}, p.\pageref{ADDR-SEL}.).
An IP address becomes secondary if another address with the same
prefix bits already exists. The first address is primary.
It is the leader of the group of all secondary addresses. When the leader
is deleted, all secondaries are purged too.
There is a tweak in \verb|/proc/sys/net/ipv4/conf/<dev>/promote_secondaries|
which activate secondaries promotion when a primary is deleted.
To permanently enable this feature on all devices add
\verb|net.ipv4.conf.all.promote_secondaries=1| to \verb|/etc/sysctl.conf|.
This tweak is available in linux 2.6.15 and later.
\item \verb|dynamic|
--- the address was created due to stateless autoconfiguration~\cite{RFC-ADDRCONF}.
In this case the output also contains information on times, when
the address is still valid. After \verb|preferred_lft| expires the address is
moved to the deprecated state. After \verb|valid_lft| expires the address
is finally invalidated.
\item \verb|deprecated|
--- the address is deprecated, i.e.\ it is still valid, but cannot
be used by newly created connections.
\item \verb|tentative|
--- the address is not used because duplicate address detection~\cite{RFC-ADDRCONF}
is still not complete or failed.
\end{enumerate}
\subsection{{\tt ip address flush} --- flush protocol addresses}
\label{IP-ADDR-FLUSH}
\paragraph{Abbreviations:} \verb|flush|, \verb|f|.
\paragraph{Description:}This command flushes the protocol addresses
selected by some criteria.
\paragraph{Arguments:} This command has the same arguments as \verb|show|.
The difference is that it does not run when no arguments are given.
\paragraph{Warning:} This command (and other \verb|flush| commands
described below) is pretty dangerous. If you make a mistake, it will
not forgive it, but will cruelly purge all the addresses.
\paragraph{Statistics:} With the \verb|-statistics| option, the command
becomes verbose. It prints out the number of deleted addresses and the number
of rounds made to flush the address list. If this option is given
twice, \verb|ip addr flush| also dumps all the deleted addresses
in the format described in the previous subsection.
\paragraph{Example:} Delete all the addresses from the private network
10.0.0.0/8:
\begin{verbatim}
netadm@amber:~ # ip -s -s a f to 10/8
2: dummy inet 10.7.7.7/16 brd 10.7.255.255 scope global dummy
3: eth0 inet 10.10.7.7/16 brd 10.10.255.255 scope global eth0
4: eth1 inet 10.8.7.7/16 brd 10.8.255.255 scope global eth1
*** Round 1, deleting 3 addresses ***
*** Flush is complete after 1 round ***
netadm@amber:~ #
\end{verbatim}
Another instructive example is disabling IP on all the Ethernets:
\begin{verbatim}
netadm@amber:~ # ip -4 addr flush label "eth*"
\end{verbatim}
And the last example shows how to flush all the IPv6 addresses
acquired by the host from stateless address autoconfiguration
after you enabled forwarding or disabled autoconfiguration.
\begin{verbatim}
netadm@amber:~ # ip -6 addr flush dynamic
\end{verbatim}
\section{{\tt ip neighbour} --- neighbour/arp tables management}
\paragraph{Abbreviations:} \verb|neighbour|, \verb|neighbor|, \verb|neigh|,
\verb|n|.
\paragraph{Object:} \verb|neighbour| objects establish bindings between protocol
addresses and link layer addresses for hosts sharing the same link.
Neighbour entries are organized into tables. The IPv4 neighbour table
is known by another name --- the ARP table.
The corresponding commands display neighbour bindings
and their properties, add new neighbour entries and delete old ones.
\paragraph{Commands:} \verb|add|, \verb|change|, \verb|replace|,
\verb|delete|, \verb|flush| and \verb|show| (or \verb|list|).
\paragraph{See also:} Appendix~\ref{PROXY-NEIGH}, p.\pageref{PROXY-NEIGH}
describes how to manage proxy ARP/NDISC with the \verb|ip| utility.
\subsection{{\tt ip neighbour add} --- add a new neighbour entry\\
{\tt ip neighbour change} --- change an existing entry\\
{\tt ip neighbour replace} --- add a new entry or change an existing one}
\paragraph{Abbreviations:} \verb|add|, \verb|a|; \verb|change|, \verb|chg|;
\verb|replace|, \verb|repl|.
\paragraph{Description:} These commands create new neighbour records
or update existing ones.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to ADDRESS| (default)
--- the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
\item \verb|dev NAME|
--- the interface to which this neighbour is attached.
\item \verb|lladdr LLADDRESS|
--- the link layer address of the neighbour. \verb|LLADDRESS| can also be
\verb|null|.
\item \verb|nud NUD_STATE|
--- the state of the neighbour entry. \verb|nud| is an abbreviation for ``Neighbour
Unreachability Detection''. The state can take one of the following values:
\begin{enumerate}
\item \verb|permanent| --- the neighbour entry is valid forever and can be only be removed
administratively.
\item \verb|noarp| --- the neighbour entry is valid. No attempts to validate
this entry will be made but it can be removed when its lifetime expires.
\item \verb|reachable| --- the neighbour entry is valid until the reachability
timeout expires.
\item \verb|stale| --- the neighbour entry is valid but suspicious.
This option to \verb|ip neigh| does not change the neighbour state if
it was valid and the address is not changed by this command.
\end{enumerate}
\end{itemize}
\paragraph{Examples:}
\begin{itemize}
\item \verb|ip neigh add 10.0.0.3 lladdr 0:0:0:0:0:1 dev eth0 nud perm|
--- add a permanent ARP entry for the neighbour 10.0.0.3 on the device \verb|eth0|.
\item \verb|ip neigh chg 10.0.0.3 dev eth0 nud reachable|
--- change its state to \verb|reachable|.
\end{itemize}
\subsection{{\tt ip neighbour delete} --- delete a neighbour entry}
\paragraph{Abbreviations:} \verb|delete|, \verb|del|, \verb|d|.
\paragraph{Description:} This command invalidates a neighbour entry.
\paragraph{Arguments:} The arguments are the same as with \verb|ip neigh add|,
except that \verb|lladdr| and \verb|nud| are ignored.
\paragraph{Example:}
\begin{itemize}
\item \verb|ip neigh del 10.0.0.3 dev eth0|
--- invalidate an ARP entry for the neighbour 10.0.0.3 on the device \verb|eth0|.
\end{itemize}
\begin{NB}
The deleted neighbour entry will not disappear from the tables
immediately. If it is in use it cannot be deleted until the last
client releases it. Otherwise it will be destroyed during
the next garbage collection.
\end{NB}
\paragraph{Warning:} Attempts to delete or manually change
a \verb|noarp| entry created by the kernel may result in unpredictable behaviour.
Particularly, the kernel may try to resolve this address even
on a \verb|NOARP| interface or if the address is multicast or broadcast.
\subsection{{\tt ip neighbour show} --- list neighbour entries}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|.
\paragraph{Description:}This commands displays neighbour tables.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to ADDRESS| (default)
--- the prefix selecting the neighbours to list.
\item \verb|dev NAME|
--- only list the neighbours attached to this device.
\item \verb|unused|
--- only list neighbours which are not currently in use.
\item \verb|nud NUD_STATE|
--- only list neighbour entries in this state. \verb|NUD_STATE| takes
values listed below or the special value \verb|all| which means all states.
This option may occur more than once. If this option is absent, \verb|ip|
lists all entries except for \verb|none| and \verb|noarp|.
\end{itemize}
\paragraph{Output format:}
\begin{verbatim}
kuznet@alisa:~ $ ip neigh ls
:: dev lo lladdr 00:00:00:00:00:00 nud noarp
fe80::200:cff:fe76:3f85 dev eth0 lladdr 00:00:0c:76:3f:85 router \
nud stale
0.0.0.0 dev lo lladdr 00:00:00:00:00:00 nud noarp
193.233.7.254 dev eth0 lladdr 00:00:0c:76:3f:85 nud reachable
193.233.7.85 dev eth0 lladdr 00:e0:1e:63:39:00 nud stale
kuznet@alisa:~ $
\end{verbatim}
The first word of each line is the protocol address of the neighbour.
Then the device name follows. The rest of the line describes the contents of
the neighbour entry identified by the pair (device, address).
\verb|lladdr| is the link layer address of the neighbour.
\verb|nud| is the state of the ``neighbour unreachability detection'' machine
for this entry. The detailed description of the neighbour
state machine can be found in~\cite{RFC-NDISC}. Here is the full list
of the states with short descriptions:
\begin{enumerate}
\item\verb|none| --- the state of the neighbour is void.
\item\verb|incomplete| --- the neighbour is in the process of resolution.
\item\verb|reachable| --- the neighbour is valid and apparently reachable.
\item\verb|stale| --- the neighbour is valid, but is probably already
unreachable, so the kernel will try to check it at the first transmission.
\item\verb|delay| --- a packet has been sent to the stale neighbour and the kernel is waiting
for confirmation.
\item\verb|probe| --- the delay timer expired but no confirmation was received.
The kernel has started to probe the neighbour with ARP/NDISC messages.
\item\verb|failed| --- resolution has failed.
\item\verb|noarp| --- the neighbour is valid. No attempts to check the entry
will be made.
\item\verb|permanent| --- it is a \verb|noarp| entry, but only the administrator
may remove the entry from the neighbour table.
\end{enumerate}
The link layer address is valid in all states except for \verb|none|,
\verb|failed| and \verb|incomplete|.
IPv6 neighbours can be marked with the additional flag \verb|router|
which means that the neighbour introduced itself as an IPv6 router~\cite{RFC-NDISC}.
\paragraph{Statistics:} The \verb|-statistics| option displays some usage
statistics, f.e.\
\begin{verbatim}
kuznet@alisa:~ $ ip -s n ls 193.233.7.254
193.233.7.254 dev eth0 lladdr 00:00:0c:76:3f:85 ref 5 used 12/13/20 \
nud reachable
kuznet@alisa:~ $
\end{verbatim}
Here \verb|ref| is the number of users of this entry
and \verb|used| is a triplet of time intervals in seconds
separated by slashes. In this case they show that:
\begin{enumerate}
\item the entry was used 12 seconds ago.
\item the entry was confirmed 13 seconds ago.
\item the entry was updated 20 seconds ago.
\end{enumerate}
\subsection{{\tt ip neighbour flush} --- flush neighbour entries}
\paragraph{Abbreviations:} \verb|flush|, \verb|f|.
\paragraph{Description:}This command flushes neighbour tables, selecting
entries to flush by some criteria.
\paragraph{Arguments:} This command has the same arguments as \verb|show|.
The differences are that it does not run when no arguments are given,
and that the default neighbour states to be flushed do not include
\verb|permanent| and \verb|noarp|.
\paragraph{Statistics:} With the \verb|-statistics| option, the command
becomes verbose. It prints out the number of deleted neighbours and the number
of rounds made to flush the neighbour table. If the option is given
twice, \verb|ip neigh flush| also dumps all the deleted neighbours
in the format described in the previous subsection.
\paragraph{Example:}
\begin{verbatim}
netadm@alisa:~ # ip -s -s n f 193.233.7.254
193.233.7.254 dev eth0 lladdr 00:00:0c:76:3f:85 ref 5 used 12/13/20 \
nud reachable
*** Round 1, deleting 1 entries ***
*** Flush is complete after 1 round ***
netadm@alisa:~ #
\end{verbatim}
\section{{\tt ip route} --- routing table management}
\label{IP-ROUTE}
\paragraph{Abbreviations:} \verb|route|, \verb|ro|, \verb|r|.
\paragraph{Object:} \verb|route| entries in the kernel routing tables keep
information about paths to other networked nodes.
Each route entry has a {\em key\/} consisting of a {\em prefix\/}
(i.e.\ a pair containing a network address and the length of its mask) and,
optionally, the TOS value. An IP packet matches the route if the highest
bits of its destination address are equal to the route prefix at least
up to the prefix length and if the TOS of the route is zero or equal to
the TOS of the packet.
If several routes match the packet, the following pruning rules
are used to select the best one (see~\cite{RFC1812}):
\begin{enumerate}
\item The longest matching prefix is selected. All shorter ones
are dropped.
\item If the TOS of some route with the longest prefix is equal to the TOS
of the packet, the routes with different TOS are dropped.
If no exact TOS match was found and routes with TOS=0 exist,
the rest of routes are pruned.
Otherwise, the route lookup fails.
\item If several routes remain after the previous steps, then
the routes with the best preference values are selected.
\item If we still have several routes, then the {\em first\/} of them
is selected.
\begin{NB}
Note the ambiguity of the last step. Unfortunately, Linux
historically allows such a bizarre situation. The sense of the
word ``first'' depends on the order of route additions and it is practically
impossible to maintain a bundle of such routes in this order.
\end{NB}
For simplicity we will limit ourselves to the case where such a situation
is impossible and routes are uniquely identified by the triplet
\{prefix, tos, preference\}. Actually, it is impossible to create
non-unique routes with \verb|ip| commands described in this section.
One useful exception to this rule is the default route on non-forwarding
hosts. It is ``officially'' allowed to have several fallback routes
when several routers are present on directly connected networks.
In this case, Linux-2.2 makes ``dead gateway detection''~\cite{RFC1122}
controlled by neighbour unreachability detection and by advice
from transport protocols to select a working router, so the order
of the routes is not essential. However, in this case,
fiddling with default routes manually is not recommended. Use the Router Discovery
protocol (see Appendix~\ref{EXAMPLE-SETUP}, p.\pageref{EXAMPLE-SETUP})
instead. Actually, Linux-2.2 IPv6 does not give user level applications
any access to default routes.
\end{enumerate}
Certainly, the steps above are not performed exactly
in this sequence. Instead, the routing table in the kernel is kept
in some data structure to achieve the final result
with minimal cost. However, not depending on a particular
routing algorithm implemented in the kernel, we can summarize
the statements above as: a route is identified by the triplet
\{prefix, tos, preference\}. This {\em key\/} lets us locate
the route in the routing table.
\paragraph{Route attributes:} Each route key refers to a routing
information record containing
the data required to deliver IP packets (f.e.\ output device and
next hop router) and some optional attributes (f.e. the path MTU or
the preferred source address when communicating with this destination).
These attributes are described in the following subsection.
\paragraph{Route types:} \label{IP-ROUTE-TYPES}
It is important that the set
of required and optional attributes depend on the route {\em type\/}.
The most important route type
is \verb|unicast|. It describes real paths to other hosts.
As a rule, common routing tables contain only such routes. However,
there are other types of routes with different semantics. The
full list of types understood by Linux-2.2 is:
\begin{itemize}
\item \verb|unicast| --- the route entry describes real paths to the
destinations covered by the route prefix.
\item \verb|unreachable| --- these destinations are unreachable. Packets
are discarded and the ICMP message {\em host unreachable\/} is generated.
The local senders get an \verb|EHOSTUNREACH| error.
\item \verb|blackhole| --- these destinations are unreachable. Packets
are discarded silently. The local senders get an \verb|EINVAL| error.
\item \verb|prohibit| --- these destinations are unreachable. Packets
are discarded and the ICMP message {\em communication administratively
prohibited\/} is generated. The local senders get an \verb|EACCES| error.
\item \verb|local| --- the destinations are assigned to this
host. The packets are looped back and delivered locally.
\item \verb|broadcast| --- the destinations are broadcast addresses.
The packets are sent as link broadcasts.
\item \verb|throw| --- a special control route used together with policy
rules (see sec.\ref{IP-RULE}, p.\pageref{IP-RULE}). If such a route is selected, lookup
in this table is terminated pretending that no route was found.
Without policy routing it is equivalent to the absence of the route in the routing
table. The packets are dropped and the ICMP message {\em net unreachable\/}
is generated. The local senders get an \verb|ENETUNREACH| error.
\item \verb|nat| --- a special NAT route. Destinations covered by the prefix
are considered to be dummy (or external) addresses which require translation
to real (or internal) ones before forwarding. The addresses to translate to
are selected with the attribute \verb|via|. More about NAT is
in Appendix~\ref{ROUTE-NAT}, p.\pageref{ROUTE-NAT}.
\item \verb|anycast| --- ({\em not implemented\/}) the destinations are
{\em anycast\/} addresses assigned to this host. They are mainly equivalent
to \verb|local| with one difference: such addresses are invalid when used
as the source address of any packet.
\item \verb|multicast| --- a special type used for multicast routing.
It is not present in normal routing tables.
\end{itemize}
\paragraph{Route tables:} Linux-2.2 can pack routes into several routing
tables identified by a number in the range from 1 to 255 or by
name from the file \verb|/etc/iproute2/rt_tables|. By default all normal
routes are inserted into the \verb|main| table (ID 254) and the kernel only uses
this table when calculating routes.
Actually, one other table always exists, which is invisible but
even more important. It is the \verb|local| table (ID 255). This table
consists of routes for local and broadcast addresses. The kernel maintains
this table automatically and the administrator usually need not modify it
or even look at it.
The multiple routing tables enter the game when {\em policy routing\/}
is used. See sec.\ref{IP-RULE}, p.\pageref{IP-RULE}.
In this case, the table identifier effectively becomes
one more parameter, which should be added to the triplet
\{prefix, tos, preference\} to uniquely identify the route.
\subsection{{\tt ip route add} --- add a new route\\
{\tt ip route change} --- change a route\\
{\tt ip route replace} --- change a route or add a new one}
\label{IP-ROUTE-ADD}
\paragraph{Abbreviations:} \verb|add|, \verb|a|; \verb|change|, \verb|chg|;
\verb|replace|, \verb|repl|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to PREFIX| or \verb|to TYPE PREFIX| (default)
--- the destination prefix of the route. If \verb|TYPE| is omitted,
\verb|ip| assumes type \verb|unicast|. Other values of \verb|TYPE|
are listed above. \verb|PREFIX| is an IP or IPv6 address optionally followed
by a slash and the prefix length. If the length of the prefix is missing,
\verb|ip| assumes a full-length host route. There is also a special
\verb|PREFIX| --- \verb|default| --- which is equivalent to IP \verb|0/0| or
to IPv6 \verb|::/0|.
\item \verb|tos TOS| or \verb|dsfield TOS|
--- the Type Of Service (TOS) key. This key has no associated mask and
the longest match is understood as: First, compare the TOS
of the route and of the packet. If they are not equal, then the packet
may still match a route with a zero TOS. \verb|TOS| is either an 8 bit hexadecimal
number or an identifier from {\tt /etc/iproute2/rt\_dsfield}.
\item \verb|metric NUMBER| or \verb|preference NUMBER|
--- the preference value of the route. \verb|NUMBER| is an arbitrary 32bit number.
\item \verb|table TABLEID|
--- the table to add this route to.
\verb|TABLEID| may be a number or a string from the file
\verb|/etc/iproute2/rt_tables|. If this parameter is omitted,
\verb|ip| assumes the \verb|main| table, with the exception of
\verb|local|, \verb|broadcast| and \verb|nat| routes, which are
put into the \verb|local| table by default.
\item \verb|dev NAME|
--- the output device name.
\item \verb|via ADDRESS|
--- the address of the nexthop router. Actually, the sense of this field depends
on the route type. For normal \verb|unicast| routes it is either the true nexthop
router or, if it is a direct route installed in BSD compatibility mode,
it can be a local address of the interface.
For NAT routes it is the first address of the block of translated IP destinations.
\item \verb|src ADDRESS|
--- the source address to prefer when sending to the destinations
covered by the route prefix.
\item \verb|realm REALMID|
--- the realm to which this route is assigned.
\verb|REALMID| may be a number or a string from the file
\verb|/etc/iproute2/rt_realms|. Sec.\ref{RT-REALMS} (p.\pageref{RT-REALMS})
contains more information on realms.
\item \verb|mtu MTU| or \verb|mtu lock MTU|
--- the MTU along the path to the destination. If the modifier \verb|lock| is
not used, the MTU may be updated by the kernel due to Path MTU Discovery.
If the modifier \verb|lock| is used, no path MTU discovery will be tried,
all packets will be sent without the DF bit in IPv4 case
or fragmented to MTU for IPv6.
\item \verb|window NUMBER|
--- the maximal window for TCP to advertise to these destinations,
measured in bytes. It limits maximal data bursts that our TCP
peers are allowed to send to us.
\item \verb|rtt NUMBER|
--- the initial RTT (``Round Trip Time'') estimate.
\item \verb|rttvar NUMBER|
--- \threeonly the initial RTT variance estimate.
\item \verb|ssthresh NUMBER|
--- \threeonly an estimate for the initial slow start threshold.
\item \verb|cwnd NUMBER|
--- \threeonly the clamp for congestion window. It is ignored if the \verb|lock|
flag is not used.
\item \verb|advmss NUMBER|
--- \threeonly the MSS (``Maximal Segment Size'') to advertise to these
destinations when establishing TCP connections. If it is not given,
Linux uses a default value calculated from the first hop device MTU.
\begin{NB}
If the path to these destination is asymmetric, this guess may be wrong.
\end{NB}
\item \verb|reordering NUMBER|
--- \threeonly Maximal reordering on the path to this destination.
If it is not given, Linux uses the value selected with \verb|sysctl|
variable \verb|net/ipv4/tcp_reordering|.
\item \verb|hoplimit NUMBER|
--- [2.5.74+ only] Maximum number of hops on the path to this destination.
The default is the value selected with the \verb|sysctl| variable
\verb|net/ipv4/ip_default_ttl|.
\item \verb|initcwnd NUMBER|
--- [2.5.70+ only] Initial congestion window size for connections to
this destination. Actual window size is this value multiplied by the
MSS (``Maximal Segment Size'') for same connection. The default is
zero, meaning to use the values specified in~\cite{RFC2414}.
+\item \verb|initrwnd NUMBER|
+--- [2.6.33+ only] Initial receive window size for connections to
+ this destination. The actual window size is this value multiplied
+ by the MSS (''Maximal Segment Size'') of the connection. The default
+ value is zero, meaning to use Slow Start value.
\item \verb|nexthop NEXTHOP|
--- the nexthop of a multipath route. \verb|NEXTHOP| is a complex value
with its own syntax similar to the top level argument lists:
\begin{itemize}
\item \verb|via ADDRESS| is the nexthop router.
\item \verb|dev NAME| is the output device.
\item \verb|weight NUMBER| is a weight for this element of a multipath
route reflecting its relative bandwidth or quality.
\end{itemize}
\item \verb|scope SCOPE_VAL|
--- the scope of the destinations covered by the route prefix.
\verb|SCOPE_VAL| may be a number or a string from the file
\verb|/etc/iproute2/rt_scopes|.
If this parameter is omitted,
\verb|ip| assumes scope \verb|global| for all gatewayed \verb|unicast|
routes, scope \verb|link| for direct \verb|unicast| and \verb|broadcast| routes
and scope \verb|host| for \verb|local| routes.
\item \verb|protocol RTPROTO|
--- the routing protocol identifier of this route.
\verb|RTPROTO| may be a number or a string from the file
\verb|/etc/iproute2/rt_protos|. If the routing protocol ID is
not given, \verb|ip| assumes protocol \verb|boot| (i.e.\
it assumes the route was added by someone who doesn't
understand what they are doing). Several protocol values have a fixed interpretation.
Namely:
\begin{itemize}
\item \verb|redirect| --- the route was installed due to an ICMP redirect.
\item \verb|kernel| --- the route was installed by the kernel during
autoconfiguration.
\item \verb|boot| --- the route was installed during the bootup sequence.
If a routing daemon starts, it will purge all of them.
\item \verb|static| --- the route was installed by the administrator
to override dynamic routing. Routing daemon will respect them
and, probably, even advertise them to its peers.
\item \verb|ra| --- the route was installed by Router Discovery protocol.
\end{itemize}
The rest of the values are not reserved and the administrator is free
to assign (or not to assign) protocol tags. At least, routing
daemons should take care of setting some unique protocol values,
f.e.\ as they are assigned in \verb|rtnetlink.h| or in \verb|rt_protos|
database.
\item \verb|onlink|
--- pretend that the nexthop is directly attached to this link,
even if it does not match any interface prefix. One application of this
option may be found in~\cite{IP-TUNNELS}.
\end{itemize}
\begin{NB}
Actually there are more commands: \verb|prepend| does the same
thing as classic \verb|route add|, i.e.\ adds a route, even if another
route to the same destination exists. Its opposite case is \verb|append|,
which adds the route to the end of the list. Avoid these
features.
\end{NB}
\begin{NB}
More sad news, IPv6 only understands the \verb|append| command correctly.
All the others are translated into \verb|append| commands. Certainly,
this will change in the future.
\end{NB}
\paragraph{Examples:}
\begin{itemize}
\item add a plain route to network 10.0.0/24 via gateway 193.233.7.65
\begin{verbatim}
ip route add 10.0.0/24 via 193.233.7.65
\end{verbatim}
\item change it to a direct route via the \verb|dummy| device
\begin{verbatim}
ip ro chg 10.0.0/24 dev dummy
\end{verbatim}
\item add a default multipath route splitting the load between \verb|ppp0|
and \verb|ppp1|
\begin{verbatim}
ip route add default scope global nexthop dev ppp0 \
nexthop dev ppp1
\end{verbatim}
Note the scope value. It is not necessary but it informs the kernel
that this route is gatewayed rather than direct. Actually, if you
know the addresses of remote endpoints it would be better to use the
\verb|via| parameter.
\item announce that the address 192.203.80.144 is not a real one, but
should be translated to 193.233.7.83 before forwarding
\begin{verbatim}
ip route add nat 192.203.80.144 via 193.233.7.83
\end{verbatim}
Backward translation is setup with policy rules described
in the following section (sec.\ref{IP-RULE}, p.\pageref{IP-RULE}).
\end{itemize}
\subsection{{\tt ip route delete} --- delete a route}
\paragraph{Abbreviations:} \verb|delete|, \verb|del|, \verb|d|.
\paragraph{Arguments:} \verb|ip route del| has the same arguments as
\verb|ip route add|, but their semantics are a bit different.
Key values (\verb|to|, \verb|tos|, \verb|preference| and \verb|table|)
select the route to delete. If optional attributes are present, \verb|ip|
verifies that they coincide with the attributes of the route to delete.
If no route with the given key and attributes was found, \verb|ip route del|
fails.
\begin{NB}
Linux-2.0 had the option to delete a route selected only by prefix address,
ignoring its length (i.e.\ netmask). This option no longer exists
because it was ambiguous. However, look at {\tt ip route flush}
(sec.\ref{IP-ROUTE-FLUSH}, p.\pageref{IP-ROUTE-FLUSH}) which
provides similar and even richer functionality.
\end{NB}
\paragraph{Example:}
\begin{itemize}
\item delete the multipath route created by the command in previous subsection
\begin{verbatim}
ip route del default scope global nexthop dev ppp0 \
nexthop dev ppp1
\end{verbatim}
\end{itemize}
\subsection{{\tt ip route show} --- list routes}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|, \verb|l|.
\paragraph{Description:} the command displays the contents of the routing tables
or the route(s) selected by some criteria.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to SELECTOR| (default)
--- only select routes from the given range of destinations. \verb|SELECTOR|
consists of an optional modifier (\verb|root|, \verb|match| or \verb|exact|)
and a prefix. \verb|root PREFIX| selects routes with prefixes not shorter
than \verb|PREFIX|. F.e.\ \verb|root 0/0| selects the entire routing table.
\verb|match PREFIX| selects routes with prefixes not longer than
\verb|PREFIX|. F.e.\ \verb|match 10.0/16| selects \verb|10.0/16|,
\verb|10/8| and \verb|0/0|, but it does not select \verb|10.1/16| and
\verb|10.0.0/24|. And \verb|exact PREFIX| (or just \verb|PREFIX|)
selects routes with this exact prefix. If neither of these options
are present, \verb|ip| assumes \verb|root 0/0| i.e.\ it lists the entire table.
\item \verb|tos TOS| or \verb|dsfield TOS|
--- only select routes with the given TOS.
\item \verb|table TABLEID|
--- show the routes from this table(s). The default setting is to show
\verb|table| \verb|main|. \verb|TABLEID| may either be the ID of a real table
or one of the special values:
\begin{itemize}
\item \verb|all| --- list all of the tables.
\item \verb|cache| --- dump the routing cache.
\end{itemize}
\begin{NB}
IPv6 has a single table. However, splitting it into \verb|main|, \verb|local|
and \verb|cache| is emulated by the \verb|ip| utility.
\end{NB}
\item \verb|cloned| or \verb|cached|
--- list cloned routes i.e.\ routes which were dynamically forked from
other routes because some route attribute (f.e.\ MTU) was updated.
Actually, it is equivalent to \verb|table cache|.
\item \verb|from SELECTOR|
--- the same syntax as for \verb|to|, but it binds the source address range
rather than destinations. Note that the \verb|from| option only works with
cloned routes.
\item \verb|protocol RTPROTO|
--- only list routes of this protocol.
\item \verb|scope SCOPE_VAL|
--- only list routes with this scope.
\item \verb|type TYPE|
--- only list routes of this type.
\item \verb|dev NAME|
--- only list routes going via this device.
\item \verb|via PREFIX|
--- only list routes going via the nexthop routers selected by \verb|PREFIX|.
\item \verb|src PREFIX|
--- only list routes with preferred source addresses selected
by \verb|PREFIX|.
\item \verb|realm REALMID| or \verb|realms FROMREALM/TOREALM|
--- only list routes with these realms.
\end{itemize}
\paragraph{Examples:} Let us count routes of protocol \verb|gated/bgp|
on a router:
\begin{verbatim}
kuznet@amber:~ $ ip ro ls proto gated/bgp | wc
1413 9891 79010
kuznet@amber:~ $
\end{verbatim}
To count the size of the routing cache, we have to use the \verb|-o| option
because cached attributes can take more than one line of output:
\begin{verbatim}
kuznet@amber:~ $ ip -o ro ls cloned | wc
159 2543 18707
kuznet@amber:~ $
\end{verbatim}
\paragraph{Output format:} The output of this command consists
of per route records separated by line feeds.
However, some records may consist
of more than one line: particularly, this is the case when the route
is cloned or you requested additional statistics. If the
\verb|-o| option was given, then line feeds separating lines inside
records are replaced with the backslash sign.
The output has the same syntax as arguments given to {\tt ip route add},
so that it can be understood easily. F.e.\
\begin{verbatim}
kuznet@amber:~ $ ip ro ls 193.233.7/24
193.233.7.0/24 dev eth0 proto gated/conn scope link \
src 193.233.7.65 realms inr.ac
kuznet@amber:~ $
\end{verbatim}
If you list cloned entries, the output contains other attributes which
are evaluated during route calculation and updated during route
lifetime. An example of the output is:
\begin{verbatim}
kuznet@amber:~ $ ip ro ls 193.233.7.82 tab cache
193.233.7.82 from 193.233.7.82 dev eth0 src 193.233.7.65 \
realms inr.ac/inr.ac
cache <src-direct,redirect> mtu 1500 rtt 300 iif eth0
193.233.7.82 dev eth0 src 193.233.7.65 realms inr.ac
cache mtu 1500 rtt 300
kuznet@amber:~ $
\end{verbatim}
\begin{NB}
\label{NB-strange-route}
The route looks a bit strange, doesn't it? Did you notice that
it is a path from 193.233.7.82 back to 193.233.82? Well, you will
see in the section on \verb|ip route get| (p.\pageref{NB-nature-of-strangeness})
how it appeared.
\end{NB}
The second line, starting with the word \verb|cache|, shows
additional attributes which normal routes do not possess.
Cached flags are summarized in angle brackets:
\begin{itemize}
\item \verb|local| --- packets are delivered locally.
It stands for loopback unicast routes, for broadcast routes
and for multicast routes, if this host is a member of the corresponding
group.
\item \verb|reject| --- the path is bad. Any attempt to use it results
in an error. See attribute \verb|error| below (p.\pageref{IP-ROUTE-GET-error}).
\item \verb|mc| --- the destination is multicast.
\item \verb|brd| --- the destination is broadcast.
\item \verb|src-direct| --- the source is on a directly connected
interface.
\item \verb|redirected| --- the route was created by an ICMP Redirect.
\item \verb|redirect| --- packets going via this route will
trigger an ICMP redirect.
\item \verb|fastroute| --- the route is eligible to be used for fastroute.
\item \verb|equalize| --- make packet by packet randomization
along this path.
\item \verb|dst-nat| --- the destination address requires translation.
\item \verb|src-nat| --- the source address requires translation.
\item \verb|masq| --- the source address requires masquerading.
This feature disappeared in linux-2.4.
\item \verb|notify| --- ({\em not implemented}) change/deletion
of this route will trigger RTNETLINK notification.
\end{itemize}
Then some optional attributes follow:
\begin{itemize}
\item \verb|error| --- on \verb|reject| routes it is error code
returned to local senders when they try to use this route.
These error codes are translated into ICMP error codes, sent to remote
senders, according to the rules described above in the subsection
devoted to route types (p.\pageref{IP-ROUTE-TYPES}).
\label{IP-ROUTE-GET-error}
\item \verb|expires| --- this entry will expire after this timeout.
\item \verb|iif| --- the packets for this path are expected to arrive
on this interface.
\end{itemize}
\paragraph{Statistics:} With the \verb|-statistics| option, more
information about this route is shown:
\begin{itemize}
\item \verb|users| --- the number of users of this entry.
\item \verb|age| --- shows when this route was last used.
\item \verb|used| --- the number of lookups of this route since its creation.
\end{itemize}
\subsection{{\tt ip route save} -- save routing tables}
\label{IP-ROUTE-SAVE}
\paragraph{Description:} this command saves the contents of the routing
tables or the route(s) selected by some criteria to standard output.
\paragraph{Arguments:} \verb|ip route save| has the same arguments as
\verb|ip route show|.
\paragraph{Example:} This saves all the routes to the {\tt saved\_routes}
file:
\begin{verbatim}
dan@caffeine:~ # ip route save > saved_routes
\end{verbatim}
\paragraph{Output format:} The format of the data stream provided by
\verb|ip route save| is that of \verb|rtnetlink|. See
\verb|rtnetlink(7)| for more information.
\subsection{{\tt ip route restore} -- restore routing tables}
\label{IP-ROUTE-RESTORE}
\paragraph{Description:} this command restores the contents of the routing
tables according to a data stream as provided by \verb|ip route save| via
standard input. Note that any routes already in the table are left unchanged.
Any routes in the input stream that already exist in the tables are ignored.
\paragraph{Arguments:} This command takes no arguments.
\paragraph{Example:} This restores all routes that were saved to the
{\tt saved\_routes} file:
\begin{verbatim}
dan@caffeine:~ # ip route restore < saved_routes
\end{verbatim}
\subsection{{\tt ip route flush} --- flush routing tables}
\label{IP-ROUTE-FLUSH}
\paragraph{Abbreviations:} \verb|flush|, \verb|f|.
\paragraph{Description:} this command flushes routes selected
by some criteria.
\paragraph{Arguments:} the arguments have the same syntax and semantics
as the arguments of \verb|ip route show|, but routing tables are not
listed but purged. The only difference is the default action: \verb|show|
dumps all the IP main routing table but \verb|flush| prints the helper page.
The reason for this difference does not require any explanation, does it?
\paragraph{Statistics:} With the \verb|-statistics| option, the command
becomes verbose. It prints out the number of deleted routes and the number
of rounds made to flush the routing table. If the option is given
twice, \verb|ip route flush| also dumps all the deleted routes
in the format described in the previous subsection.
\paragraph{Examples:} The first example flushes all the
gatewayed routes from the main table (f.e.\ after a routing daemon crash).
\begin{verbatim}
netadm@amber:~ # ip -4 ro flush scope global type unicast
\end{verbatim}
This option deserves to be put into a scriptlet \verb|routef|.
\begin{NB}
This option was described in the \verb|route(8)| man page borrowed
from BSD, but was never implemented in Linux.
\end{NB}
The second example flushes all IPv6 cloned routes:
\begin{verbatim}
netadm@amber:~ # ip -6 -s -s ro flush cache
3ffe:2400::220:afff:fef4:c5d1 via 3ffe:2400::220:afff:fef4:c5d1 \
dev eth0 metric 0
cache used 2 age 12sec mtu 1500 rtt 300
3ffe:2400::280:adff:feb7:8034 via 3ffe:2400::280:adff:feb7:8034 \
dev eth0 metric 0
cache used 2 age 15sec mtu 1500 rtt 300
3ffe:2400::280:c8ff:fe59:5bcc via 3ffe:2400::280:c8ff:fe59:5bcc \
dev eth0 metric 0
cache users 1 used 1 age 23sec mtu 1500 rtt 300
3ffe:2400:0:1:2a0:ccff:fe66:1878 via 3ffe:2400:0:1:2a0:ccff:fe66:1878 \
dev eth1 metric 0
cache used 2 age 20sec mtu 1500 rtt 300
3ffe:2400:0:1:a00:20ff:fe71:fb30 via 3ffe:2400:0:1:a00:20ff:fe71:fb30 \
dev eth1 metric 0
cache used 2 age 33sec mtu 1500 rtt 300
ff02::1 via ff02::1 dev eth1 metric 0
cache users 1 used 1 age 45sec mtu 1500 rtt 300
*** Round 1, deleting 6 entries ***
*** Flush is complete after 1 round ***
netadm@amber:~ # ip -6 -s -s ro flush cache
Nothing to flush.
netadm@amber:~ #
\end{verbatim}
The third example flushes BGP routing tables after a \verb|gated|
death.
\begin{verbatim}
netadm@amber:~ # ip ro ls proto gated/bgp | wc
1408 9856 78730
netadm@amber:~ # ip -s ro f proto gated/bgp
*** Round 1, deleting 1408 entries ***
*** Flush is complete after 1 round ***
netadm@amber:~ # ip ro f proto gated/bgp
Nothing to flush.
netadm@amber:~ # ip ro ls proto gated/bgp
netadm@amber:~ #
\end{verbatim}
\subsection{{\tt ip route get} --- get a single route}
\label{IP-ROUTE-GET}
\paragraph{Abbreviations:} \verb|get|, \verb|g|.
\paragraph{Description:} this command gets a single route to a destination
and prints its contents exactly as the kernel sees it.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to ADDRESS| (default)
--- the destination address.
\item \verb|from ADDRESS|
--- the source address.
\item \verb|tos TOS| or \verb|dsfield TOS|
--- the Type Of Service.
\item \verb|iif NAME|
--- the device from which this packet is expected to arrive.
\item \verb|oif NAME|
--- force the output device on which this packet will be routed.
\item \verb|connected|
--- if no source address (option \verb|from|) was given, relookup
the route with the source set to the preferred address received from the first lookup.
If policy routing is used, it may be a different route.
\end{itemize}
Note that this operation is not equivalent to \verb|ip route show|.
\verb|show| shows existing routes. \verb|get| resolves them and
creates new clones if necessary. Essentially, \verb|get|
is equivalent to sending a packet along this path.
If the \verb|iif| argument is not given, the kernel creates a route
to output packets towards the requested destination.
This is equivalent to pinging the destination
with a subsequent {\tt ip route ls cache}, however, no packets are
actually sent. With the \verb|iif| argument, the kernel pretends
that a packet arrived from this interface and searches for
a path to forward the packet.
\paragraph{Output format:} This command outputs routes in the same
format as \verb|ip route ls|.
\paragraph{Examples:}
\begin{itemize}
\item Find a route to output packets to 193.233.7.82:
\begin{verbatim}
kuznet@amber:~ $ ip route get 193.233.7.82
193.233.7.82 dev eth0 src 193.233.7.65 realms inr.ac
cache mtu 1500 rtt 300
kuznet@amber:~ $
\end{verbatim}
\item Find a route to forward packets arriving on \verb|eth0|
from 193.233.7.82 and destined for 193.233.7.82:
\begin{verbatim}
kuznet@amber:~ $ ip r g 193.233.7.82 from 193.233.7.82 iif eth0
193.233.7.82 from 193.233.7.82 dev eth0 src 193.233.7.65 \
realms inr.ac/inr.ac
cache <src-direct,redirect> mtu 1500 rtt 300 iif eth0
kuznet@amber:~ $
\end{verbatim}
\begin{NB}
\label{NB-nature-of-strangeness}
This is the command that created the funny route from 193.233.7.82
looped back to 193.233.7.82 (cf.\ NB on~p.\pageref{NB-strange-route}).
Note the \verb|redirect| flag on it.
\end{NB}
\item Find a multicast route for packets arriving on \verb|eth0|
from host 193.233.7.82 and destined for multicast group 224.2.127.254
(it is assumed that a multicast routing daemon is running.
In this case, it is \verb|pimd|)
\begin{verbatim}
kuznet@amber:~ $ ip r g 224.2.127.254 from 193.233.7.82 iif eth0
multicast 224.2.127.254 from 193.233.7.82 dev lo \
src 193.233.7.65 realms inr.ac/cosmos
cache <mc> iif eth0 Oifs: eth1 pimreg
kuznet@amber:~ $
\end{verbatim}
This route differs from the ones seen before. It contains a ``normal'' part
and a ``multicast'' part. The normal part is used to deliver (or not to
deliver) the packet to local IP listeners. In this case the router
is not a member
of this group, so that route has no \verb|local| flag and only
forwards packets. The output device for such entries is always loopback.
The multicast part consists of an additional \verb|Oifs:| list showing
the output interfaces.
\end{itemize}
It is time for a more complicated example. Let us add an invalid
gatewayed route for a destination which is really directly connected:
\begin{verbatim}
netadm@alisa:~ # ip route add 193.233.7.98 via 193.233.7.254
netadm@alisa:~ # ip route get 193.233.7.98
193.233.7.98 via 193.233.7.254 dev eth0 src 193.233.7.90
cache mtu 1500 rtt 3072
netadm@alisa:~ #
\end{verbatim}
and probe it with ping:
\begin{verbatim}
netadm@alisa:~ # ping -n 193.233.7.98
PING 193.233.7.98 (193.233.7.98) from 193.233.7.90 : 56 data bytes
From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
64 bytes from 193.233.7.98: icmp_seq=0 ttl=255 time=3.5 ms
From 193.233.7.254: Redirect Host(New nexthop: 193.233.7.98)
64 bytes from 193.233.7.98: icmp_seq=1 ttl=255 time=2.2 ms
64 bytes from 193.233.7.98: icmp_seq=2 ttl=255 time=0.4 ms
64 bytes from 193.233.7.98: icmp_seq=3 ttl=255 time=0.4 ms
64 bytes from 193.233.7.98: icmp_seq=4 ttl=255 time=0.4 ms
^C
--- 193.233.7.98 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.4/1.3/3.5 ms
netadm@alisa:~ #
\end{verbatim}
What happened? Router 193.233.7.254 understood that we have a much
better path to the destination and sent us an ICMP redirect message.
We may retry \verb|ip route get| to see what we have in the routing
tables now:
\begin{verbatim}
netadm@alisa:~ # ip route get 193.233.7.98
193.233.7.98 dev eth0 src 193.233.7.90
cache <redirected> mtu 1500 rtt 3072
netadm@alisa:~ #
\end{verbatim}
\section{{\tt ip rule} --- routing policy database management}
\label{IP-RULE}
\paragraph{Abbreviations:} \verb|rule|, \verb|ru|.
\paragraph{Object:} \verb|rule|s in the routing policy database control
the route selection algorithm.
Classic routing algorithms used in the Internet make routing decisions
based only on the destination address of packets (and in theory,
but not in practice, on the TOS field). The seminal review of classic
routing algorithms and their modifications can be found in~\cite{RFC1812}.
In some circumstances we want to route packets differently depending not only
on destination addresses, but also on other packet fields: source address,
IP protocol, transport protocol ports or even packet payload.
This task is called ``policy routing''.
\begin{NB}
``policy routing'' $\neq$ ``routing policy''.
\noindent ``policy routing'' $=$ ``cunning routing''.
\noindent ``routing policy'' $=$ ``routing tactics'' or ``routing plan''.
\end{NB}
To solve this task, the conventional destination based routing table, ordered
according to the longest match rule, is replaced with a ``routing policy
database'' (or RPDB), which selects routes
by executing some set of rules. The rules may have lots of keys of different
natures and therefore they have no natural ordering, but one imposed
by the administrator. Linux-2.2 RPDB is a linear list of rules
ordered by numeric priority value.
RPDB explicitly allows matching a few packet fields:
\begin{itemize}
\item packet source address.
\item packet destination address.
\item TOS.
\item incoming interface (which is packet metadata, rather than a packet field).
\end{itemize}
Matching IP protocols and transport ports is also possible,
indirectly, via \verb|ipchains|, by exploiting their ability
to mark some classes of packets with \verb|fwmark|. Therefore,
\verb|fwmark| is also included in the set of keys checked by rules.
Each policy routing rule consists of a {\em selector\/} and an {\em action\/}
predicate. The RPDB is scanned in the order of increasing priority. The selector
of each rule is applied to \{source address, destination address, incoming
interface, tos, fwmark\} and, if the selector matches the packet,
the action is performed. The action predicate may return with success.
In this case, it will either give a route or failure indication
and the RPDB lookup is terminated. Otherwise, the RPDB program
continues on the next rule.
What is the action, semantically? The natural action is to select the
nexthop and the output device. This is what
Cisco IOS~\cite{IOS} does. Let us call it ``match \& set''.
The Linux-2.2 approach is more flexible. The action includes
lookups in destination-based routing tables and selecting
a route from these tables according to the classic longest match algorithm.
The ``match \& set'' approach is the simplest case of the Linux one. It is realized
when a second level routing table contains a single default route.
Recall that Linux-2.2 supports multiple tables
managed with the \verb|ip route| command, described in the previous section.
At startup time the kernel configures the default RPDB consisting of three
rules:
\begin{enumerate}
\item Priority: 0, Selector: match anything, Action: lookup routing
table \verb|local| (ID 255).
The \verb|local| table is a special routing table containing
high priority control routes for local and broadcast addresses.
Rule 0 is special. It cannot be deleted or overridden.
\item Priority: 32766, Selector: match anything, Action: lookup routing
table \verb|main| (ID 254).
The \verb|main| table is the normal routing table containing all non-policy
routes. This rule may be deleted and/or overridden with other
ones by the administrator.
\item Priority: 32767, Selector: match anything, Action: lookup routing
table \verb|default| (ID 253).
The \verb|default| table is empty. It is reserved for some
post-processing if no previous default rules selected the packet.
This rule may also be deleted.
\end{enumerate}
Do not confuse routing tables with rules: rules point to routing tables,
several rules may refer to one routing table and some routing tables
may have no rules pointing to them. If the administrator deletes all the rules
referring to a table, the table is not used, but it still exists
and will disappear only after all the routes contained in it are deleted.
\paragraph{Rule attributes:} Each RPDB entry has additional
attributes. F.e.\ each rule has a pointer to some routing
table. NAT and masquerading rules have an attribute to select new IP
address to translate/masquerade. Besides that, rules have some
optional attributes, which routes have, namely \verb|realms|.
These values do not override those contained in the routing tables. They
are only used if the route did not select any attributes.
\paragraph{Rule types:} The RPDB may contain rules of the following
types:
\begin{itemize}
\item \verb|unicast| --- the rule prescribes to return the route found
in the routing table referenced by the rule.
\item \verb|blackhole| --- the rule prescribes to silently drop the packet.
\item \verb|unreachable| --- the rule prescribes to generate a ``Network
is unreachable'' error.
\item \verb|prohibit| --- the rule prescribes to generate
``Communication is administratively prohibited'' error.
\item \verb|nat| --- the rule prescribes to translate the source address
of the IP packet into some other value. More about NAT is
in Appendix~\ref{ROUTE-NAT}, p.\pageref{ROUTE-NAT}.
\end{itemize}
\paragraph{Commands:} \verb|add|, \verb|delete| and \verb|show|
(or \verb|list|).
\subsection{{\tt ip rule add} --- insert a new rule\\
{\tt ip rule delete} --- delete a rule}
\label{IP-RULE-ADD}
\paragraph{Abbreviations:} \verb|add|, \verb|a|; \verb|delete|, \verb|del|,
\verb|d|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|type TYPE| (default)
--- the type of this rule. The list of valid types was given in the previous
subsection.
\item \verb|from PREFIX|
--- select the source prefix to match.
\item \verb|to PREFIX|
--- select the destination prefix to match.
\item \verb|iif NAME|
--- select the incoming device to match. If the interface is loopback,
the rule only matches packets originating from this host. This means that you
may create separate routing tables for forwarded and local packets and,
hence, completely segregate them.
\item \verb|tos TOS| or \verb|dsfield TOS|
--- select the TOS value to match.
\item \verb|fwmark MARK|
--- select the \verb|fwmark| value to match.
\item \verb|priority PREFERENCE|
--- the priority of this rule. Each rule should have an explicitly
set {\em unique\/} priority value.
\begin{NB}
Really, for historical reasons \verb|ip rule add| does not require a
priority value and allows them to be non-unique.
If the user does not supplied a priority, it is selected by the kernel.
If the user creates a rule with a priority value that
already exists, the kernel does not reject the request. It adds
the new rule before all old rules of the same priority.
It is mistake in design, no more. And it will be fixed one day,
so do not rely on this feature. Use explicit priorities.
\end{NB}
\item \verb|table TABLEID|
--- the routing table identifier to lookup if the rule selector matches.
\item \verb|realms FROM/TO|
--- Realms to select if the rule matched and the routing table lookup
succeeded. Realm \verb|TO| is only used if the route did not select
any realm.
\item \verb|nat ADDRESS|
--- The base of the IP address block to translate (for source addresses).
The \verb|ADDRESS| may be either the start of the block of NAT addresses
(selected by NAT routes) or in linux-2.2 a local host address (or even zero).
In the last case the router does not translate the packets,
but masquerades them to this address; this feature disappered in 2.4.
More about NAT is in Appendix~\ref{ROUTE-NAT},
p.\pageref{ROUTE-NAT}.
\end{itemize}
\paragraph{Warning:} Changes to the RPDB made with these commands
do not become active immediately. It is assumed that after
a script finishes a batch of updates, it flushes the routing cache
with \verb|ip route flush cache|.
\paragraph{Examples:}
\begin{itemize}
\item Route packets with source addresses from 192.203.80/24
according to routing table \verb|inr.ruhep|:
\begin{verbatim}
ip ru add from 192.203.80.0/24 table inr.ruhep prio 220
\end{verbatim}
\item Translate packet source address 193.233.7.83 into 192.203.80.144
and route it according to table \#1 (actually, it is \verb|inr.ruhep|):
\begin{verbatim}
ip ru add from 193.233.7.83 nat 192.203.80.144 table 1 prio 320
\end{verbatim}
\item Delete the unused default rule:
\begin{verbatim}
ip ru del prio 32767
\end{verbatim}
\end{itemize}
\subsection{{\tt ip rule show} --- list rules}
\label{IP-RULE-SHOW}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|, \verb|l|.
\paragraph{Arguments:} Good news, this is one command that has no arguments.
\paragraph{Output format:}
\begin{verbatim}
kuznet@amber:~ $ ip ru ls
0: from all lookup local
200: from 192.203.80.0/24 to 193.233.7.0/24 lookup main
210: from 192.203.80.0/24 to 192.203.80.0/24 lookup main
220: from 192.203.80.0/24 lookup inr.ruhep realms inr.ruhep/radio-msu
300: from 193.233.7.83 to 193.233.7.0/24 lookup main
310: from 193.233.7.83 to 192.203.80.0/24 lookup main
320: from 193.233.7.83 lookup inr.ruhep map-to 192.203.80.144
32766: from all lookup main
kuznet@amber:~ $
\end{verbatim}
In the first column is the rule priority value followed
by a colon. Then the selectors follow. Each key is prefixed
with the same keyword that was used to create the rule.
The keyword \verb|lookup| is followed by a routing table identifier,
as it is recorded in the file \verb|/etc/iproute2/rt_tables|.
If the rule does NAT (f.e.\ rule \#320), it is shown by the keyword
\verb|map-to| followed by the start of the block of addresses to map.
The sense of this example is pretty simple. The prefixes
192.203.80.0/24 and 193.233.7.0/24 form the internal network, but
they are routed differently when the packets leave it.
Besides that, the host 193.233.7.83 is translated into
another prefix to look like 192.203.80.144 when talking
to the outer world.
\section{{\tt ip maddress} --- multicast addresses management}
\label{IP-MADDR}
\paragraph{Object:} \verb|maddress| objects are multicast addresses.
\paragraph{Commands:} \verb|add|, \verb|delete|, \verb|show| (or \verb|list|).
\subsection{{\tt ip maddress show} --- list multicast addresses}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|, \verb|l|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|dev NAME| (default)
--- the device name.
\end{itemize}
\paragraph{Output format:}
\begin{verbatim}
kuznet@alisa:~ $ ip maddr ls dummy
2: dummy
link 33:33:00:00:00:01
link 01:00:5e:00:00:01
inet 224.0.0.1 users 2
inet6 ff02::1
kuznet@alisa:~ $
\end{verbatim}
The first line of the output shows the interface index and its name.
Then the multicast address list follows. Each line starts with the
protocol identifier. The word \verb|link| denotes a link layer
multicast addresses.
If a multicast address has more than one user, the number
of users is shown after the \verb|users| keyword.
One additional feature not present in the example above
is the \verb|static| flag, which indicates that the address was joined
with \verb|ip maddr add|. See the following subsection.
\subsection{{\tt ip maddress add} --- add a multicast address\\
{\tt ip maddress delete} --- delete a multicast address}
\paragraph{Abbreviations:} \verb|add|, \verb|a|; \verb|delete|, \verb|del|, \verb|d|.
\paragraph{Description:} these commands attach/detach
a static link layer multicast address to listen on the interface.
Note that it is impossible to join protocol multicast groups
statically. This command only manages link layer addresses.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|address LLADDRESS| (default)
--- the link layer multicast address.
\item \verb|dev NAME|
--- the device to join/leave this multicast address.
\end{itemize}
\paragraph{Example:} Let us continue with the example from the previous subsection.
\begin{verbatim}
netadm@alisa:~ # ip maddr add 33:33:00:00:00:01 dev dummy
netadm@alisa:~ # ip -0 maddr ls dummy
2: dummy
link 33:33:00:00:00:01 users 2 static
link 01:00:5e:00:00:01
netadm@alisa:~ # ip maddr del 33:33:00:00:00:01 dev dummy
\end{verbatim}
\begin{NB}
Neither \verb|ip| nor the kernel check for multicast address validity.
Particularly, this means that you can try to load a unicast address
instead of a multicast address. Most drivers will ignore such addresses,
but several (f.e.\ Tulip) will intern it to their on-board filter.
The effects may be strange. Namely, the addresses become additional
local link addresses and, if you loaded the address of another host
to the router, wait for duplicated packets on the wire.
It is not a bug, but rather a hole in the API and intra-kernel interfaces.
This feature is really more useful for traffic monitoring, but using it
with Linux-2.2 you {\em have to\/} be sure that the host is not
a router and, especially, that it is not a transparent proxy or masquerading
agent.
\end{NB}
\section{{\tt ip mroute} --- multicast routing cache management}
\label{IP-MROUTE}
\paragraph{Abbreviations:} \verb|mroute|, \verb|mr|.
\paragraph{Object:} \verb|mroute| objects are multicast routing cache
entries created by a user level mrouting daemon
(f.e.\ \verb|pimd| or \verb|mrouted|).
Due to the limitations of the current interface to the multicast routing
engine, it is impossible to change \verb|mroute| objects administratively,
so we may only display them. This limitation will be removed
in the future.
\paragraph{Commands:} \verb|show| (or \verb|list|).
\subsection{{\tt ip mroute show} --- list mroute cache entries}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|, \verb|l|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|to PREFIX| (default)
--- the prefix selecting the destination multicast addresses to list.
\item \verb|iif NAME|
--- the interface on which multicast packets are received.
\item \verb|from PREFIX|
--- the prefix selecting the IP source addresses of the multicast route.
\end{itemize}
\paragraph{Output format:}
\begin{verbatim}
kuznet@amber:~ $ ip mroute ls
(193.232.127.6, 224.0.1.39) Iif: unresolved
(193.232.244.34, 224.0.1.40) Iif: unresolved
(193.233.7.65, 224.66.66.66) Iif: eth0 Oifs: pimreg
kuznet@amber:~ $
\end{verbatim}
Each line shows one (S,G) entry in the multicast routing cache,
where S is the source address and G is the multicast group. \verb|Iif| is
the interface on which multicast packets are expected to arrive.
If the word \verb|unresolved| is there instead of the interface name,
it means that the routing daemon still hasn't resolved this entry.
The keyword \verb|oifs| is followed by a list of output interfaces, separated
by spaces. If a multicast routing entry is created with non-trivial
TTL scope, administrative distances are appended to the device names
in the \verb|oifs| list.
\paragraph{Statistics:} The \verb|-statistics| option also prints the
number of packets and bytes forwarded along this route and
the number of packets that arrived on the wrong interface, if this number is not zero.
\begin{verbatim}
kuznet@amber:~ $ ip -s mr ls 224.66/16
(193.233.7.65, 224.66.66.66) Iif: eth0 Oifs: pimreg
9383 packets, 300256 bytes
kuznet@amber:~ $
\end{verbatim}
\section{{\tt ip tunnel} --- tunnel configuration}
\label{IP-TUNNEL}
\paragraph{Abbreviations:} \verb|tunnel|, \verb|tunl|.
\paragraph{Object:} \verb|tunnel| objects are tunnels, encapsulating
packets in IPv4 packets and then sending them over the IP infrastructure.
\paragraph{Commands:} \verb|add|, \verb|delete|, \verb|change|, \verb|show|
(or \verb|list|).
\paragraph{See also:} A more informal discussion of tunneling
over IP and the \verb|ip tunnel| command can be found in~\cite{IP-TUNNELS}.
\subsection{{\tt ip tunnel add} --- add a new tunnel\\
{\tt ip tunnel change} --- change an existing tunnel\\
{\tt ip tunnel delete} --- destroy a tunnel}
\paragraph{Abbreviations:} \verb|add|, \verb|a|; \verb|change|, \verb|chg|;
\verb|delete|, \verb|del|, \verb|d|.
\paragraph{Arguments:}
\begin{itemize}
\item \verb|name NAME| (default)
--- select the tunnel device name.
\item \verb|mode MODE|
--- set the tunnel mode. Three modes are currently available:
\verb|ipip|, \verb|sit| and \verb|gre|.
\item \verb|remote ADDRESS|
--- set the remote endpoint of the tunnel.
\item \verb|local ADDRESS|
--- set the fixed local address for tunneled packets.
It must be an address on another interface of this host.
\item \verb|ttl N|
--- set a fixed TTL \verb|N| on tunneled packets.
\verb|N| is a number in the range 1--255. 0 is a special value
meaning that packets inherit the TTL value.
The default value is: \verb|inherit|.
\item \verb|tos T| or \verb|dsfield T|
--- set a fixed TOS \verb|T| on tunneled packets.
The default value is: \verb|inherit|.
\item \verb|dev NAME|
--- bind the tunnel to the device \verb|NAME| so that
tunneled packets will only be routed via this device and will
not be able to escape to another device when the route to endpoint changes.
\item \verb|nopmtudisc|
--- disable Path MTU Discovery on this tunnel.
It is enabled by default. Note that a fixed ttl is incompatible
with this option: tunnelling with a fixed ttl always makes pmtu discovery.
\item \verb|key K|, \verb|ikey K|, \verb|okey K|
--- (only GRE tunnels) use keyed GRE with key \verb|K|. \verb|K| is
either a number or an IP address-like dotted quad.
The \verb|key| parameter sets the key to use in both directions.
The \verb|ikey| and \verb|okey| parameters set different keys for input and output.
\item \verb|csum|, \verb|icsum|, \verb|ocsum|
--- (only GRE tunnels) generate/require checksums for tunneled packets.
The \verb|ocsum| flag calculates checksums for outgoing packets.
The \verb|icsum| flag requires that all input packets have the correct
checksum. The \verb|csum| flag is equivalent to the combination
``\verb|icsum| \verb|ocsum|''.
\item \verb|seq|, \verb|iseq|, \verb|oseq|
--- (only GRE tunnels) serialize packets.
The \verb|oseq| flag enables sequencing of outgoing packets.
The \verb|iseq| flag requires that all input packets are serialized.
The \verb|seq| flag is equivalent to the combination ``\verb|iseq| \verb|oseq|''.
\begin{NB}
I think this option does not
work. At least, I did not test it, did not debug it and
do not even understand how it is supposed to work or for what
purpose Cisco planned to use it. Do not use it.
\end{NB}
\end{itemize}
\paragraph{Example:} Create a pointopoint IPv6 tunnel with maximal TTL of 32.
\begin{verbatim}
netadm@amber:~ # ip tunl add Cisco mode sit remote 192.31.7.104 \
local 192.203.80.142 ttl 32
\end{verbatim}
\subsection{{\tt ip tunnel show} --- list tunnels}
\paragraph{Abbreviations:} \verb|show|, \verb|list|, \verb|sh|, \verb|ls|, \verb|l|.
\paragraph{Arguments:} None.
\paragraph{Output format:}
\begin{verbatim}
kuznet@amber:~ $ ip tunl ls Cisco
Cisco: ipv6/ip remote 192.31.7.104 local 192.203.80.142 ttl 32
kuznet@amber:~ $
\end{verbatim}
The line starts with the tunnel device name followed by a colon.
Then the tunnel mode follows. The parameters of the tunnel are listed
with the same keywords that were used when creating the tunnel.
\paragraph{Statistics:}
\begin{verbatim}
kuznet@amber:~ $ ip -s tunl ls Cisco
Cisco: ipv6/ip remote 192.31.7.104 local 192.203.80.142 ttl 32
RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
12566 1707516 0 0 0 0
TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
13445 1879677 0 0 0 0
kuznet@amber:~ $
\end{verbatim}
Essentially, these numbers are the same as the numbers
printed with {\tt ip -s link show}
(sec.\ref{IP-LINK-SHOW}, p.\pageref{IP-LINK-SHOW}) but the tags are different
to reflect that they are tunnel specific.
\begin{itemize}
\item \verb|CsumErrs| --- the total number of packets dropped
because of checksum failures for a GRE tunnel with checksumming enabled.
\item \verb|OutOfSeq| --- the total number of packets dropped
because they arrived out of sequence for a GRE tunnel with
serialization enabled.
\item \verb|Mcasts| --- the total number of multicast packets
received on a broadcast GRE tunnel.
\item \verb|DeadLoop| --- the total number of packets which were not
transmitted because the tunnel is looped back to itself.
\item \verb|NoRoute| --- the total number of packets which were not
transmitted because there is no IP route to the remote endpoint.
\item \verb|NoBufs| --- the total number of packets which were not
transmitted because the kernel failed to allocate a buffer.
\end{itemize}
\section{{\tt ip monitor} and {\tt rtmon} --- state monitoring}
\label{IP-MONITOR}
The \verb|ip| utility can monitor the state of devices, addresses
and routes continuously. This option has a slightly different format.
Namely,
the \verb|monitor| command is the first in the command line and then
the object list follows:
\begin{verbatim}
ip monitor [ file FILE ] [ all | OBJECT-LIST ]
\end{verbatim}
\verb|OBJECT-LIST| is the list of object types that we want to monitor.
It may contain \verb|link|, \verb|address| and \verb|route|.
If no \verb|file| argument is given, \verb|ip| opens RTNETLINK,
listens on it and dumps state changes in the format described
in previous sections.
If a file name is given, it does not listen on RTNETLINK,
but opens the file containing RTNETLINK messages saved in binary format
and dumps them. Such a history file can be generated with the
\verb|rtmon| utility. This utility has a command line syntax similar to
\verb|ip monitor|.
Ideally, \verb|rtmon| should be started before
the first network configuration command is issued. F.e.\ if
you insert:
\begin{verbatim}
rtmon file /var/log/rtmon.log
\end{verbatim}
in a startup script, you will be able to view the full history
later.
Certainly, it is possible to start \verb|rtmon| at any time.
It prepends the history with the state snapshot dumped at the moment
of starting.
\section{Route realms and policy propagation, {\tt rtacct}}
\label{RT-REALMS}
On routers using OSPF ASE or, especially, the BGP protocol, routing
tables may be huge. If we want to classify or to account for the packets
per route, we will have to keep lots of information. Even worse, if we
want to distinguish the packets not only by their destination, but
also by their source, the task gets quadratic complexity and its solution
is physically impossible.
One approach to propagating the policy from routing protocols
to the forwarding engine has been proposed in~\cite{IOS-BGP-PP}.
Essentially, Cisco Policy Propagation via BGP is based on the fact
that dedicated routers all have the RIB (Routing Information Base)
close to the forwarding engine, so policy routing rules can
check all the route attributes, including ASPATH information
and community strings.
The Linux architecture, splitting the RIB (maintained by a user level
daemon) and the kernel based FIB (Forwarding Information Base),
does not allow such a simple approach.
It is to our fortune because there is another solution
which allows even more flexible policy and richer semantics.
Namely, routes can be clustered together in user space, based on their
attributes. F.e.\ a BGP router knows route ASPATH, its community;
an OSPF router knows the route tag or its area. The administrator, when adding
routes manually, also knows their nature. Providing that the number of such
aggregates (we call them {\em realms\/}) is low, the task of full
classification both by source and destination becomes quite manageable.
So each route may be assigned to a realm. It is assumed that
this identification is made by a routing daemon, but static routes
can also be handled manually with \verb|ip route| (see sec.\ref{IP-ROUTE},
p.\pageref{IP-ROUTE}).
\begin{NB}
There is a patch to \verb|gated|, allowing classification of routes
to realms with all the set of policy rules implemented in \verb|gated|:
by prefix, by ASPATH, by origin, by tag etc.
\end{NB}
To facilitate the construction (f.e.\ in case the routing
daemon is not aware of realms), missing realms may be completed
with routing policy rules, see sec.~\ref{IP-RULE}, p.\pageref{IP-RULE}.
For each packet the kernel calculates a tuple of realms: source realm
and destination realm, using the following algorithm:
\begin{enumerate}
\item If the route has a realm, the destination realm of the packet is set to it.
\item If the rule has a source realm, the source realm of the packet is set to it.
If the destination realm was not inherited from the route and the rule has a destination realm,
it is also set.
\item If at least one of the realms is still unknown, the kernel finds
the reversed route to the source of the packet.
\item If the source realm is still unknown, get it from the reversed route.
\item If one of the realms is still unknown, swap the realms of reversed
routes and apply step 2 again.
\end{enumerate}
After this procedure is completed we know what realm the packet
arrived from and the realm where it is going to propagate to.
If some of the realms are unknown, they are initialized to zero
(or realm \verb|unknown|).
The main application of realms is the TC \verb|route| classifier~\cite{TC-CREF},
where they are used to help assign packets to traffic classes,
to account, police and schedule them according to this
classification.
A much simpler but still very useful application is incoming packet
accounting by realms. The kernel gathers a packet statistics summary
which can be viewed with the \verb|rtacct| utility.
\begin{verbatim}
kuznet@amber:~ $ rtacct russia
Realm BytesTo PktsTo BytesFrom PktsFrom
russia 20576778 169176 47080168 153805
kuznet@amber:~ $
\end{verbatim}
This shows that this router received 153805 packets from
the realm \verb|russia| and forwarded 169176 packets to \verb|russia|.
The realm \verb|russia| consists of routes with ASPATHs not leaving
Russia.
Note that locally originating packets are not accounted here,
\verb|rtacct| shows incoming packets only. Using the \verb|route|
classifier (see~\cite{TC-CREF}) you can get even more detailed
accounting information about outgoing packets, optionally
summarizing traffic not only by source or destination, but
by any pair of source and destination realms.
\begin{thebibliography}{99}
\addcontentsline{toc}{section}{References}
\bibitem{RFC-NDISC} T.~Narten, E.~Nordmark, W.~Simpson.
``Neighbor Discovery for IP Version 6 (IPv6)'', RFC-2461.
\bibitem{RFC-ADDRCONF} S.~Thomson, T.~Narten.
``IPv6 Stateless Address Autoconfiguration'', RFC-2462.
\bibitem{RFC1812} F.~Baker.
``Requirements for IP Version 4 Routers'', RFC-1812.
\bibitem{RFC1122} R.~T.~Braden.
``Requirements for Internet hosts --- communication layers'', RFC-1122.
\bibitem{IOS} ``Cisco IOS Release 12.0 Network Protocols
Command Reference, Part 1'' and
``Cisco IOS Release 12.0 Quality of Service Solutions
Configuration Guide: Configuring Policy-Based Routing'',\\
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120.
\bibitem{IP-TUNNELS} A.~N.~Kuznetsov.
``Tunnels over IP in Linux-2.2'', \\
In: {\tt ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz}.
\bibitem{TC-CREF} A.~N.~Kuznetsov. ``TC Command Reference'',\\
In: {\tt ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz}.
\bibitem{IOS-BGP-PP} ``Cisco IOS Release 12.0 Quality of Service Solutions
Configuration Guide: Configuring QoS Policy Propagation via
Border Gateway Protocol'',\\
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120.
\bibitem{RFC-DHCP} R.~Droms.
``Dynamic Host Configuration Protocol.'', RFC-2131
\bibitem{RFC2414} M.~Allman, S.~Floyd, C.~Partridge.
``Increasing TCP's Initial Window'', RFC-2414.
\end{thebibliography}
\appendix
\addcontentsline{toc}{section}{Appendix}
\section{Source address selection}
\label{ADDR-SEL}
When a host creates an IP packet, it must select some source
address. Correct source address selection is a critical procedure,
because it gives the receiver the information needed to deliver a
reply. If the source is selected incorrectly, in the best case,
the backward path may appear different to the forward one which
is harmful for performance. In the worst case, when the addresses
are administratively scoped, the reply may be lost entirely.
Linux-2.2 selects source addresses using the following algorithm:
\begin{itemize}
\item
The application may select a source address explicitly with \verb|bind(2)|
syscall or supplying it to \verb|sendmsg(2)| via the ancillary data object
\verb|IP_PKTINFO|. In this case the kernel only checks the validity
of the address and never tries to ``improve'' an incorrect user choice,
generating an error instead.
\begin{NB}
Never say ``Never''. The sysctl option \verb|ip_dynaddr| breaks
this axiom. It has been made deliberately with the purpose
of automatically reselecting the address on hosts with dynamic dial-out interfaces.
However, this hack {\em must not\/} be used on multihomed hosts
and especially on routers: it would break them.
\end{NB}
\item Otherwise, IP routing tables can contain an explicit source
address hint for this destination. The hint is set with the \verb|src| parameter
to the \verb|ip route| command, sec.\ref{IP-ROUTE}, p.\pageref{IP-ROUTE}.
\item Otherwise, the kernel searches through the list of addresses
attached to the interface through which the packets will be routed.
The search strategies are different for IP and IPv6. Namely:
\begin{itemize}
\item IPv6 searches for the first valid, not deprecated address
with the same scope as the destination.
\item IP searches for the first valid address with a scope wider
than the scope of the destination but it prefers addresses
which fall to the same subnet as the nexthop of the route
to the destination. Unlike IPv6, the scopes of IPv4 destinations
are not encoded in their addresses but are supplied
in routing tables instead (the \verb|scope| parameter to the \verb|ip route| command,
sec.\ref{IP-ROUTE}, p.\pageref{IP-ROUTE}).
\end{itemize}
\item Otherwise, if the scope of the destination is \verb|link| or \verb|host|,
the algorithm fails and returns a zero source address.
\item Otherwise, all interfaces are scanned to search for an address
with an appropriate scope. The loopback device \verb|lo| is always the first
in the search list, so that if an address with global scope (not 127.0.0.1!)
is configured on loopback, it is always preferred.
\end{itemize}
\section{Proxy ARP/NDISC}
\label{PROXY-NEIGH}
Routers may answer ARP/NDISC solicitations on behalf of other hosts.
In Linux-2.2 proxy ARP on an interface may be enabled
by setting the kernel \verb|sysctl| variable
\verb|/proc/sys/net/ipv4/conf/<dev>/proxy_arp| to 1. After this, the router
starts to answer ARP requests on the interface \verb|<dev>|, provided
the route to the requested destination does {\em not\/} go back via the same
device.
The variable \verb|/proc/sys/net/ipv4/conf/all/proxy_arp| enables proxy
ARP on all the IP devices.
However, this approach fails in the case of IPv6 because the router
must join the solicited node multicast address to listen for the corresponding
NDISC queries. It means that proxy NDISC is possible only on a per destination
basis.
Logically, proxy ARP/NDISC is not a kernel task. It can easily be implemented
in user space. However, similar functionality was present in BSD kernels
and in Linux-2.0, so we have to preserve it at least to the extent that
is standardized in BSD.
\begin{NB}
Linux-2.0 ARP had a feature called {\em subnet\/} proxy ARP.
It is replaced with the sysctl flag in Linux-2.2.
\end{NB}
The \verb|ip| utility provides a way to manage proxy ARP/NDISC
with the \verb|ip neigh| command, namely:
\begin{verbatim}
ip neigh add proxy ADDRESS [ dev NAME ]
\end{verbatim}
adds a new proxy ARP/NDISC record and
\begin{verbatim}
ip neigh del proxy ADDRESS [ dev NAME ]
\end{verbatim}
deletes it.
If the name of the device is not given, the router will answer solicitations
for address \verb|ADDRESS| on all devices, otherwise it will only serve
the device \verb|NAME|. Even if the proxy entry is created with
\verb|ip neigh|, the router {\em will not\/} answer a query if the route
to the destination goes back via the interface from which the solicitation
was received.
It is important to emphasize that proxy entries have {\em no\/}
parameters other than these (IP/IPv6 address and optional device).
Particularly, the entry does not store any link layer address.
It always advertises the station address of the interface
on which it sends advertisements (i.e. it's own station address).
\section{Route NAT status}
\label{ROUTE-NAT}
NAT (or ``Network Address Translation'') remaps some parts
of the IP address space into other ones. Linux-2.2 route NAT is supposed
to be used to facilitate policy routing by rewriting addresses
to other routing domains or to help while renumbering sites
to another prefix.
\paragraph{What it is not:}
It is necessary to emphasize that {\em it is not supposed\/}
to be used to compress address space or to split load.
This is not missing functionality but a design principle.
Route NAT is {\em stateless\/}. It does not hold any state
about translated sessions. This means that it handles any number
of sessions flawlessly. But it also means that it is {\em static\/}.
It cannot detect the moment when the last TCP client stops
using an address. For the same reason, it will not help to split
load between several servers.
\begin{NB}
It is a pretty commonly held belief that it is useful to split load between
several servers with NAT. This is a mistake. All you get from this
is the requirement that the router keep the state of all the TCP connections
going via it. Well, if the router is so powerful, run apache on it. 8)
\end{NB}
The second feature: it does not touch packet payload,
does not try to ``improve'' broken protocols by looking
through its data and mangling it. It mangles IP addresses,
only IP addresses and nothing but IP addresses.
This also, is not missing any functionality.
To resume: if you need to compress address space or keep
active FTP clients happy, your choice is not route NAT but masquerading,
port forwarding, NAPT etc.
\begin{NB}
By the way, you may also want to look at
http://www.suse.com/\~mha/HyperNews/get/linux-ip-nat.html
\end{NB}
\paragraph{How it works.}
Some part of the address space is reserved for dummy addresses
which will look for all the world like some host addresses
inside your network. No other hosts may use these addresses,
however other routers may also be configured to translate them.
\begin{NB}
A great advantage of route NAT is that it may be used not
only in stub networks but in environments with arbitrarily complicated
structure. It does not firewall, it {\em forwards.}
\end{NB}
These addresses are selected by the \verb|ip route| command
(sec.\ref{IP-ROUTE-ADD}, p.\pageref{IP-ROUTE-ADD}). F.e.\
\begin{verbatim}
ip route add nat 192.203.80.144 via 193.233.7.83
\end{verbatim}
states that the single address 192.203.80.144 is a dummy NAT address.
For all the world it looks like a host address inside our network.
For neighbouring hosts and routers it looks like the local address
of the translating router. The router answers ARP for it, advertises
this address as routed via it, {\em et al\/}. When the router
receives a packet destined for 192.203.80.144, it replaces
this address with 193.233.7.83 which is the address of some real
host and forwards the packet. If you need to remap
blocks of addresses, you may use a command like:
\begin{verbatim}
ip route add nat 192.203.80.192/26 via 193.233.7.64
\end{verbatim}
This command will map a block of 63 addresses 192.203.80.192-255 to
193.233.7.64-127.
When an internal host (193.233.7.83 in the example above)
sends something to the outer world and these packets are forwarded
by our router, it should translate the source address 193.233.7.83
into 192.203.80.144. This task is solved by setting a special
policy rule (sec.\ref{IP-RULE-ADD}, p.\pageref{IP-RULE-ADD}):
\begin{verbatim}
ip rule add prio 320 from 193.233.7.83 nat 192.203.80.144
\end{verbatim}
This rule says that the source address 193.233.7.83
should be translated into 192.203.80.144 before forwarding.
It is important that the address after the \verb|nat| keyword
is some NAT address, declared by {\tt ip route add nat}.
If it is just a random address the router will not map to it.
\begin{NB}
The exception is when the address is a local address of this
router (or 0.0.0.0) and masquerading is configured in the linux-2.2
kernel. In this case the router will masquerade the packets as this address.
If 0.0.0.0 is selected, the result is equivalent to one
obtained with firewalling rules. Otherwise, you have the way
to order Linux to masquerade to this fixed address.
NAT mechanism used in linux-2.4 is more flexible than
masquerading, so that this feature has lost meaning and disabled.
\end{NB}
If the network has non-trivial internal structure, it is
useful and even necessary to add rules disabling translation
when a packet does not leave this network. Let us return to the
example from sec.\ref{IP-RULE-SHOW} (p.\pageref{IP-RULE-SHOW}).
\begin{verbatim}
300: from 193.233.7.83 to 193.233.7.0/24 lookup main
310: from 193.233.7.83 to 192.203.80.0/24 lookup main
320: from 193.233.7.83 lookup inr.ruhep map-to 192.203.80.144
\end{verbatim}
This block of rules causes normal forwarding when
packets from 193.233.7.83 do not leave networks 193.233.7/24
and 192.203.80/24. Also, if the \verb|inr.ruhep| table does not
contain a route to the destination (which means that the routing
domain owning addresses from 192.203.80/24 is dead), no translation
will occur. Otherwise, the packets are translated.
\paragraph{How to only translate selected ports:}
If you only want to translate selected ports (f.e.\ http)
and leave the rest intact, you may use \verb|ipchains|
to \verb|fwmark| a class of packets.
Suppose you did and all the packets from 193.233.7.83
destined for port 80 are marked with marker 0x1234 in input fwchain.
In this case you may replace rule \#320 with:
\begin{verbatim}
320: from 193.233.7.83 fwmark 1234 lookup main map-to 192.203.80.144
\end{verbatim}
and translation will only be enabled for outgoing http requests.
\section{Example: minimal host setup}
\label{EXAMPLE-SETUP}
The following script gives an example of a fault safe
setup of IP (and IPv6, if it is compiled into the kernel)
in the common case of a node attached to a single broadcast
network. A more advanced script, which may be used both on multihomed
hosts and on routers, is described in the following
section.
The utilities used in the script may be found in the
directory ftp://ftp.inr.ac.ru/ip-routing/:
\begin{enumerate}
\item \verb|ip| --- package \verb|iproute2|.
\item \verb|arping| --- package \verb|iputils|.
\item \verb|rdisc| --- package \verb|iputils|.
\end{enumerate}
\begin{NB}
It also refers to a DHCP client, \verb|dhcpcd|. I should refrain from
recommending a good DHCP client to use. All that I can
say is that ISC \verb|dhcp-2.0b1pl6| patched with the patch that
can be found in the \verb|dhcp.bootp.rarp| subdirectory of
the same ftp site {\em does\/} work,
at least on Ethernet and Token Ring.
\end{NB}
\begin{verbatim}
#! /bin/bash
\end{verbatim}
\begin{flushleft}
\# {\bf Usage: \verb|ifone ADDRESS[/PREFIX-LENGTH] [DEVICE]|}\\
\# {\bf Parameters:}\\
\# \$1 --- Static IP address, optionally followed by prefix length.\\
\# \$2 --- Device name. If it is missing, \verb|eth0| is asssumed.\\
\# F.e. \verb|ifone 193.233.7.90|
\end{flushleft}
\begin{verbatim}
dev=$2
: ${dev:=eth0}
ipaddr=
\end{verbatim}
\# Parse IP address, splitting prefix length.
\begin{verbatim}
if [ "$1" != "" ]; then
ipaddr=${1%/*}
if [ "$1" != "$ipaddr" ]; then
pfxlen=${1#*/}
fi
: ${pfxlen:=24}
fi
pfx="${ipaddr}/${pfxlen}"
\end{verbatim}
\begin{flushleft}
\# {\bf Step 0} --- enable loopback.\\
\#\\
\# This step is necessary on any networked box before attempt\\
\# to configure any other device.\\
\end{flushleft}
\begin{verbatim}
ip link set up dev lo
ip addr add 127.0.0.1/8 dev lo brd + scope host
\end{verbatim}
\begin{flushleft}
\# IPv6 autoconfigure themself on loopback.\\
\#\\
\# If user gave loopback as device, we add the address as alias and exit.
\end{flushleft}
\begin{verbatim}
if [ "$dev" = "lo" ]; then
if [ "$ipaddr" != "" -a "$ipaddr" != "127.0.0.1" ]; then
ip address add $ipaddr dev $dev
exit $?
fi
exit 0
fi
\end{verbatim}
\noindent\# {\bf Step 1} --- enable device \verb|$dev|
\begin{verbatim}
if ! ip link set up dev $dev ; then
echo "Cannot enable interface $dev. Aborting." 1>&2
exit 1
fi
\end{verbatim}
\begin{flushleft}
\# The interface is \verb|UP|. IPv6 started stateless autoconfiguration itself,\\
\# and its configuration finishes here. However,\\
\# IP still needs some static preconfigured address.
\end{flushleft}
\begin{verbatim}
if [ "$ipaddr" = "" ]; then
echo "No address for $dev is configured, trying DHCP..." 1>&2
dhcpcd
exit $?
fi
\end{verbatim}
\begin{flushleft}
\# {\bf Step 2} --- IP Duplicate Address Detection~\cite{RFC-DHCP}.\\
\# Send two probes and wait for result for 3 seconds.\\
\# If the interface opens slower f.e.\ due to long media detection,\\
\# you want to increase the timeout.\\
\end{flushleft}
\begin{verbatim}
if ! arping -q -c 2 -w 3 -D -I $dev $ipaddr ; then
echo "Address $ipaddr is busy, trying DHCP..." 1>&2
dhcpcd
exit $?
fi
\end{verbatim}
\begin{flushleft}
\# OK, the address is unique, we may add it on the interface.\\
\#\\
\# {\bf Step 3} --- Configure the address on the interface.
\end{flushleft}
\begin{verbatim}
if ! ip address add $pfx brd + dev $dev; then
echo "Failed to add $pfx on $dev, trying DHCP..." 1>&2
dhcpcd
exit $?
fi
\end{verbatim}
\noindent\# {\bf Step 4} --- Announce our presence on the link.
\begin{verbatim}
arping -A -c 1 -I $dev $ipaddr
noarp=$?
( sleep 2;
arping -U -c 1 -I $dev $ipaddr ) >& /dev/null </dev/null &
\end{verbatim}
\begin{flushleft}
\# {\bf Step 5} (optional) --- Add some control routes.\\
\#\\
\# 1. Prohibit link local multicast addresses.\\
\# 2. Prohibit link local (alias, limited) broadcast.\\
\# 3. Add default multicast route.
\end{flushleft}
\begin{verbatim}
ip route add unreachable 224.0.0.0/24
ip route add unreachable 255.255.255.255
if [ `ip link ls $dev | grep -c MULTICAST` -ge 1 ]; then
ip route add 224.0.0.0/4 dev $dev scope global
fi
\end{verbatim}
\begin{flushleft}
\# {\bf Step 6} --- Add fallback default route with huge metric.\\
\# If a proxy ARP server is present on the interface, we will be\\
\# able to talk to all the Internet without further configuration.\\
\# It is not so cheap though and we still hope that this route\\
\# will be overridden by more correct one by rdisc.\\
\# Do not make this step if the device is not ARPable,\\
\# because dead nexthop detection does not work on them.
\end{flushleft}
\begin{verbatim}
if [ "$noarp" = "0" ]; then
ip ro add default dev $dev metric 30000 scope global
fi
\end{verbatim}
\begin{flushleft}
\# {\bf Step 7} --- Restart router discovery and exit.
\end{flushleft}
\begin{verbatim}
killall -HUP rdisc || rdisc -fs
exit 0
\end{verbatim}
\section{Example: {\protect\tt ifcfg} --- interface address management}
\label{EXAMPLE-IFCFG}
This is a simplistic script replacing one option of \verb|ifconfig|,
namely, IP address management. It not only adds
addresses, but also carries out Duplicate Address Detection~\cite{RFC-DHCP},
sends unsolicited ARP to update the caches of other hosts sharing
the interface, adds some control routes and restarts Router Discovery
when it is necessary.
I strongly recommend using it {\em instead\/} of \verb|ifconfig| both
on hosts and on routers.
\begin{verbatim}
#! /bin/bash
\end{verbatim}
\begin{flushleft}
\# {\bf Usage: \verb?ifcfg DEVICE[:ALIAS] [add|del] ADDRESS[/LENGTH] [PEER]?}\\
\# {\bf Parameters:}\\
\# ---Device name. It may have alias suffix, separated by colon.\\
\# ---Command: add, delete or stop.\\
\# ---IP address, optionally followed by prefix length.\\
\# ---Optional peer address for pointopoint interfaces.\\
\# F.e. \verb|ifcfg eth0 193.233.7.90/24|
\noindent\# This function determines, whether it is router or host.\\
\# It returns 0, if the host is apparently not router.
\end{flushleft}
\begin{verbatim}
CheckForwarding () {
local sbase fwd
sbase=/proc/sys/net/ipv4/conf
fwd=0
if [ -d $sbase ]; then
for dir in $sbase/*/forwarding; do
fwd=$[$fwd + `cat $dir`]
done
else
fwd=2
fi
return $fwd
}
\end{verbatim}
\begin{flushleft}
\# This function restarts Router Discovery.\\
\end{flushleft}
\begin{verbatim}
RestartRDISC () {
killall -HUP rdisc || rdisc -fs
}
\end{verbatim}
\begin{flushleft}
\# Calculate ABC "natural" mask length\\
\# Arg: \$1 = dotquad address
\end{flushleft}
\begin{verbatim}
ABCMaskLen () {
local class;
class=${1%%.*}
if [ $class -eq 0 -o $class -ge 224 ]; then return 0
elif [ $class -ge 192 ]; then return 24
elif [ $class -ge 128 ]; then return 16
else return 8 ; fi
}
\end{verbatim}
\begin{flushleft}
\# {\bf MAIN()}\\
\#\\
\# Strip alias suffix separated by colon.
\end{flushleft}
\begin{verbatim}
label="label $1"
ldev=$1
dev=${1%:*}
if [ "$dev" = "" -o "$1" = "help" ]; then
echo "Usage: ifcfg DEV [[add|del [ADDR[/LEN]] [PEER] | stop]" 1>&2
echo " add - add new address" 1>&2
echo " del - delete address" 1>&2
echo " stop - completely disable IP" 1>&2
exit 1
fi
shift
CheckForwarding
fwd=$?
\end{verbatim}
\begin{flushleft}
\# Parse command. If it is ``stop'', flush and exit.
\end{flushleft}
\begin{verbatim}
deleting=0
case "$1" in
add) shift ;;
stop)
if [ "$ldev" != "$dev" ]; then
echo "Cannot stop alias $ldev" 1>&2
exit 1;
fi
ip -4 addr flush dev $dev $label || exit 1
if [ $fwd -eq 0 ]; then RestartRDISC; fi
exit 0 ;;
del*)
deleting=1; shift ;;
*)
esac
\end{verbatim}
\begin{flushleft}
\# Parse prefix, split prefix length, separated by slash.
\end{flushleft}
\begin{verbatim}
ipaddr=
pfxlen=
if [ "$1" != "" ]; then
ipaddr=${1%/*}
if [ "$1" != "$ipaddr" ]; then
pfxlen=${1#*/}
fi
if [ "$ipaddr" = "" ]; then
echo "$1 is bad IP address." 1>&2
exit 1
fi
fi
shift
\end{verbatim}
\begin{flushleft}
\# If peer address is present, prefix length is 32.\\
\# Otherwise, if prefix length was not given, guess it.
\end{flushleft}
\begin{verbatim}
peer=$1
if [ "$peer" != "" ]; then
if [ "$pfxlen" != "" -a "$pfxlen" != "32" ]; then
echo "Peer address with non-trivial netmask." 1>&2
exit 1
fi
pfx="$ipaddr peer $peer"
else
if [ "$pfxlen" = "" ]; then
ABCMaskLen $ipaddr
pfxlen=$?
fi
pfx="$ipaddr/$pfxlen"
fi
if [ "$ldev" = "$dev" -a "$ipaddr" != "" ]; then
label=
fi
\end{verbatim}
\begin{flushleft}
\# If deletion was requested, delete the address and restart RDISC
\end{flushleft}
\begin{verbatim}
if [ $deleting -ne 0 ]; then
ip addr del $pfx dev $dev $label || exit 1
if [ $fwd -eq 0 ]; then RestartRDISC; fi
exit 0
fi
\end{verbatim}
\begin{flushleft}
\# Start interface initialization.\\
\#\\
\# {\bf Step 0} --- enable device \verb|$dev|
\end{flushleft}
\begin{verbatim}
if ! ip link set up dev $dev ; then
echo "Error: cannot enable interface $dev." 1>&2
exit 1
fi
if [ "$ipaddr" = "" ]; then exit 0; fi
\end{verbatim}
\begin{flushleft}
\# {\bf Step 1} --- IP Duplicate Address Detection~\cite{RFC-DHCP}.\\
\# Send two probes and wait for result for 3 seconds.\\
\# If the interface opens slower f.e.\ due to long media detection,\\
\# you want to increase the timeout.\\
\end{flushleft}
\begin{verbatim}
if ! arping -q -c 2 -w 3 -D -I $dev $ipaddr ; then
echo "Error: some host already uses address $ipaddr on $dev." 1>&2
exit 1
fi
\end{verbatim}
\begin{flushleft}
\# OK, the address is unique. We may add it to the interface.\\
\#\\
\# {\bf Step 2} --- Configure the address on the interface.
\end{flushleft}
\begin{verbatim}
if ! ip address add $pfx brd + dev $dev $label; then
echo "Error: failed to add $pfx on $dev." 1>&2
exit 1
fi
\end{verbatim}
\noindent\# {\bf Step 3} --- Announce our presence on the link
\begin{verbatim}
arping -q -A -c 1 -I $dev $ipaddr
noarp=$?
( sleep 2 ;
arping -q -U -c 1 -I $dev $ipaddr ) >& /dev/null </dev/null &
\end{verbatim}
\begin{flushleft}
\# {\bf Step 4} (optional) --- Add some control routes.\\
\#\\
\# 1. Prohibit link local multicast addresses.\\
\# 2. Prohibit link local (alias, limited) broadcast.\\
\# 3. Add default multicast route.
\end{flushleft}
\begin{verbatim}
ip route add unreachable 224.0.0.0/24 >& /dev/null
ip route add unreachable 255.255.255.255 >& /dev/null
if [ `ip link ls $dev | grep -c MULTICAST` -ge 1 ]; then
ip route add 224.0.0.0/4 dev $dev scope global >& /dev/null
fi
\end{verbatim}
\begin{flushleft}
\# {\bf Step 5} --- Add fallback default route with huge metric.\\
\# If a proxy ARP server is present on the interface, we will be\\
\# able to talk to all the Internet without further configuration.\\
\# Do not make this step on router or if the device is not ARPable.\\
\# because dead nexthop detection does not work on them.
\end{flushleft}
\begin{verbatim}
if [ $fwd -eq 0 ]; then
if [ $noarp -eq 0 ]; then
ip ro append default dev $dev metric 30000 scope global
elif [ "$peer" != "" ]; then
if ping -q -c 2 -w 4 $peer ; then
ip ro append default via $peer dev $dev metric 30001
fi
fi
RestartRDISC
fi
exit 0
\end{verbatim}
\begin{flushleft}
\# End of {\bf MAIN()}
\end{flushleft}
\end{document}