1699 lines
33 KiB
HTML
1699 lines
33 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Interface Configuration for IP</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|
REL="HOME"
|
|
TITLE="Linux Network Administrators Guide"
|
|
HREF="index.html"><LINK
|
|
REL="UP"
|
|
TITLE="Configuring TCP/IP Networking"
|
|
HREF="x-087-2-iface.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Writing hosts and networks Files"
|
|
HREF="x-087-2-iface.simple-resolv.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="All About ifconfig"
|
|
HREF="x-087-2-iface.ifconfig.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Linux Network Administrators Guide</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-iface.simple-resolv.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
>Chapter 5. Configuring TCP/IP Networking</TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x-087-2-iface.ifconfig.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE"
|
|
>5.7. Interface Configuration for IP</A
|
|
></H1
|
|
><P
|
|
>After setting up your hardware as explained in <A
|
|
HREF="x-087-2-serial.html"
|
|
>Chapter 4</A
|
|
>, you have to make these devices known to the
|
|
kernel networking software. A couple of commands are used to configure
|
|
the network interfaces and initialize the routing table. These tasks
|
|
are usually performed from the network initialization script each time
|
|
you boot the system. The basic tools for this process are called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> (where “if ” stands for
|
|
interface) and <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
>.</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> is used to make an interface accessible to
|
|
the kernel networking layer. This involves the assignment of an IP
|
|
address and other parameters, and activation of the interface, also
|
|
known as “bringing up” the interface. Being active here
|
|
means that the kernel will send and receive IP datagrams through the
|
|
interface. The simplest way to invoke it is with:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>ifconfig <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>interface</I
|
|
></TT
|
|
> <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ip-address</I
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This command assigns <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>ip-address</I
|
|
></TT
|
|
> to
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>interface</I
|
|
></TT
|
|
> and activates it. All other
|
|
parameters are set to default values. For instance, the default
|
|
network mask is derived from the network class of the IP address, such
|
|
as <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>255.255.0.0</SPAN
|
|
> for a class B
|
|
address. <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> is described in detail in the
|
|
section <A
|
|
HREF="x-087-2-iface.ifconfig.html"
|
|
>Section 5.8</A
|
|
>.”</P
|
|
><P
|
|
><B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> allows you to add or remove routes from the kernel
|
|
routing table. It can be invoked as:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>route [add|del] [-net|-host] <TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>target</I
|
|
></TT
|
|
> [<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>if</I
|
|
></TT
|
|
>]</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The <TT
|
|
CLASS="OPTION"
|
|
>add</TT
|
|
> and <TT
|
|
CLASS="OPTION"
|
|
>del</TT
|
|
> arguments determine
|
|
whether to add or delete the route to
|
|
<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>target</I
|
|
></TT
|
|
>. The <TT
|
|
CLASS="OPTION"
|
|
>-net</TT
|
|
> and
|
|
<TT
|
|
CLASS="OPTION"
|
|
>-host</TT
|
|
> arguments tell the route command whether the
|
|
target is a network or a host (a host is assumed if you don't
|
|
specify). The <TT
|
|
CLASS="OPTION"
|
|
>if</TT
|
|
> argument is again optional, and
|
|
allows you to specify to which network interface the route should be
|
|
directed—the Linux kernel makes a sensible guess if you don't
|
|
supply this information. This topic will be explained in more detail
|
|
in succeeding sections.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.LOOPBACK"
|
|
>5.7.1. The Loopback Interface</A
|
|
></H2
|
|
><P
|
|
>The very first interface to be activated is the loopback interface:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig lo 127.0.0.1</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
> Occasionally, you will see the dummy hostname
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>localhost</SPAN
|
|
> being used instead of the
|
|
IP address. <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> will look up the name in the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>hosts</TT
|
|
> file, where an entry should declare
|
|
it as the hostname for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.1</SPAN
|
|
>:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># Sample /etc/hosts entry for localhost
|
|
localhost 127.0.0.1</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
> To view the configuration of an interface, you invoke
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
>, giving it only the interface name as argument:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>$ <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig lo</B
|
|
></TT
|
|
>
|
|
lo Link encap:Local Loopback
|
|
inet addr:127.0.0.1 Mask:255.0.0.0
|
|
UP LOOPBACK RUNNING MTU:3924 Metric:1
|
|
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
|
|
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
|
|
Collisions:0 </PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>As you can see, the loopback interface has been assigned a netmask
|
|
of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>255.0.0.0</SPAN
|
|
>, since
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.1</SPAN
|
|
> is a class A address.</P
|
|
><P
|
|
>Now you can almost start playing with your mini-network. What is still
|
|
missing is an entry in the routing table that tells IP that it may use
|
|
this interface as a route to destination <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.1</SPAN
|
|
>. This is accomplished by using:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># route add 127.0.0.1</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Again, you can use <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>localhost</SPAN
|
|
> instead
|
|
of the IP address, provided you've entered it into your
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/hosts</TT
|
|
>.</P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
Next, you should check that everything works fine, for example by using
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
>. <B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
> is the networking equivalent
|
|
of a sonar device.<A
|
|
NAME="X-087-2-FNTC05"
|
|
HREF="#FTN.X-087-2-FNTC05"
|
|
>[1]</A
|
|
> The command is used to verify that a given address is
|
|
actually reachable, and to measure the delay that occurs when sending
|
|
a datagram to it and back again. The time required for this process is
|
|
often referred to as the “round-trip time”:</P
|
|
><P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ping localhost</B
|
|
></TT
|
|
>
|
|
PING localhost (127.0.0.1): 56 data bytes
|
|
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms
|
|
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms
|
|
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms
|
|
^C
|
|
--- localhost ping statistics ---
|
|
3 packets transmitted, 3 packets received, 0% packet loss
|
|
round-trip min/avg/max = 0.4/0.4/0.4 ms
|
|
#</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>When you invoke <B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
> as shown here, it will
|
|
continue emitting packets forever, unless interrupted by the user. The
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>^C</TT
|
|
> marks the place where we pressed Ctrl-C.</P
|
|
><P
|
|
>The previous example shows that packets for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.1</SPAN
|
|
> are properly delivered and a
|
|
reply is returned to <B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
> almost instantaneously.
|
|
This shows that you have successfully set up your first network
|
|
interface.</P
|
|
><P
|
|
>
|
|
If the output you get from <B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
> does not resemble
|
|
that shown in the previous example, you are in trouble. Check any
|
|
errors if they indicate that some file hasn't been installed
|
|
properly. Check that the <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> and
|
|
<B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> binaries you use are compatible with the
|
|
kernel release you run, and above all, that the kernel has been
|
|
compiled with networking enabled (you see this from the presence of
|
|
the <TT
|
|
CLASS="FILENAME"
|
|
>/proc/net</TT
|
|
> directory). If you get an error
|
|
message saying “Network unreachable,” you probably got the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> command wrong. Make sure you use the same
|
|
address you gave to <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
>.</P
|
|
><P
|
|
> The steps previously described are enough to use networking
|
|
applications on a standalone host. After adding the lines mentioned
|
|
earlier to your network initialization script and making sure it will
|
|
be executed at boot time, you may reboot your machine and try out
|
|
various applications. For instance, <B
|
|
CLASS="COMMAND"
|
|
>telnet
|
|
localhost</B
|
|
> should establish a <B
|
|
CLASS="COMMAND"
|
|
>telnet</B
|
|
>
|
|
connection to your host, giving you a <TT
|
|
CLASS="LITERAL"
|
|
>login:</TT
|
|
>
|
|
prompt.</P
|
|
><P
|
|
>However, the loopback interface is useful not only as an example in
|
|
networking books, or as a test bed during development, but is actually
|
|
used by some applications during normal operation.<A
|
|
NAME="X-087-2-FNTC06"
|
|
HREF="#FTN.X-087-2-FNTC06"
|
|
>[2]</A
|
|
>
|
|
Therefore, you always have to configure it, regardless of whether your machine
|
|
is attached to a network or not.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.ETHERNET"
|
|
>5.7.2. Ethernet Interfaces</A
|
|
></H2
|
|
><P
|
|
>Configuring an Ethernet interface is pretty much the same as the
|
|
loopback interface; it just requires a few more parameters when you are
|
|
using subnetting. </P
|
|
><P
|
|
>At the Virtual Brewery, we have subnetted the IP network, which was
|
|
originally a class B network, into class C subnetworks. To make the
|
|
interface recognize this, the <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> incantation
|
|
would look like this:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig eth0 vstout netmask 255.255.255.0</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>This command assigns the <TT
|
|
CLASS="FILENAME"
|
|
>eth0</TT
|
|
> interface the IP
|
|
address of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vstout</SPAN
|
|
>
|
|
(<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.2</SPAN
|
|
>). If we omitted
|
|
the netmask, <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> would deduce the netmask from
|
|
the IP network class, which would result in an incorrect netmask of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>255.255.0.0</SPAN
|
|
>. Now a quick
|
|
check shows:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig eth0</B
|
|
></TT
|
|
>
|
|
eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42
|
|
inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0
|
|
UP BROADCAST RUNNING MTU 1500 Metric 1
|
|
RX packets 0 errors 0 dropped 0 overrun 0
|
|
TX packets 0 errors 0 dropped 0 overrun 0</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>You can see that <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> automatically sets the broadcast
|
|
address (the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>Bcast</SPAN
|
|
> field) to the
|
|
usual value, which is the host's network number with all the host bits set.
|
|
Also, the maximum transmission unit (the maximum size of IP datagrams the
|
|
kernel will generate for this interface) has been set to the maximum size of
|
|
Ethernet packets: 1,500 bytes. The defaults are usually what you will use, but
|
|
all these values can be overidden if required, with special options that will
|
|
be described under <A
|
|
HREF="x-087-2-iface.ifconfig.html"
|
|
>Section 5.8</A
|
|
>”.</P
|
|
><P
|
|
>
|
|
Just as for the loopback interface, you now have to install a routing
|
|
entry that informs the kernel about the network that can be reached
|
|
through <TT
|
|
CLASS="FILENAME"
|
|
>eth0</TT
|
|
>. For the Virtual Brewery, you might invoke
|
|
<B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> as:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add -net 172.16.1.0</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>At first this looks a little like magic, because it's not really
|
|
clear how <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> detects which interface to route through.
|
|
However, the trick is rather simple: the kernel checks all interfaces
|
|
that have been configured so far and compares the destination address
|
|
(<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.0</SPAN
|
|
> in this case) to the
|
|
network part of the interface address (that is, the bitwise AND of the
|
|
interface address and the netmask). The only interface that matches is
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>eth0</TT
|
|
>.</P
|
|
><P
|
|
>Now, what's that <TT
|
|
CLASS="OPTION"
|
|
>–net</TT
|
|
> option for? This is used
|
|
because <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> can handle both routes to networks
|
|
and routes to single hosts (as you saw before with <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>localhost</SPAN
|
|
>). When given an address in
|
|
dotted quad notation, <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> attempts to guess
|
|
whether it is a network or a hostname by looking at the host part
|
|
bits. If the address's host part is zero, <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
>
|
|
assumes it denotes a network; otherwise, <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
>
|
|
takes it as a host address. Therefore, <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> would
|
|
think that <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.0</SPAN
|
|
> is a
|
|
host address rather than a network number, because it cannot know that
|
|
we use subnetting. We have to tell <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> explicitly
|
|
that it denotes a network, so we give it the
|
|
<TT
|
|
CLASS="OPTION"
|
|
>–net</TT
|
|
> flag.</P
|
|
><P
|
|
>Of course, the <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> command is a little tedious to
|
|
type, and it's prone to spelling mistakes. A more convenient approach
|
|
is to use the network names we defined in
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/networks</TT
|
|
>. This approach makes the command
|
|
much more readable; even the <TT
|
|
CLASS="OPTION"
|
|
>–net</TT
|
|
> flag can be
|
|
omitted because <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> knows that <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.0</SPAN
|
|
> denotes a network:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add brew-net</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>
|
|
|
|
Now that you've finished the basic configuration steps, we want to
|
|
make sure that your Ethernet interface is indeed running
|
|
happily. Choose a host from your Ethernet, for instance <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>, and type:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ping vlager</B
|
|
></TT
|
|
>
|
|
PING vlager: 64 byte packets
|
|
64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms
|
|
64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms
|
|
64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms
|
|
64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms
|
|
^C
|
|
----vstout.vbrew.com PING Statistics----
|
|
4 packets transmitted, 4 packets received, 0
|
|
round-trip (ms) min/avg/max = 3/8/12</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
> If you don't see similar output, something is broken. If you encounter
|
|
unusual packet loss rates, this hints at a hardware problem, like bad
|
|
or missing terminators. If you don't receive any replies at all, you
|
|
should check the interface configuration with
|
|
<B
|
|
CLASS="COMMAND"
|
|
>netstat</B
|
|
> described later in <A
|
|
HREF="x-087-2-iface.netstat.html"
|
|
>Section 5.9</A
|
|
>”. The packet statistics displayed by
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> should tell you whether any packets have
|
|
been sent out on the interface at all. If you have access to the
|
|
remote host too, you should go over to that machine and check the
|
|
interface statistics. This way you can determine exactly where the
|
|
packets got dropped. In addition, you should display the routing
|
|
information with <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> to see if both hosts have
|
|
the correct routing entry. <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> prints out the
|
|
complete kernel routing table when invoked without any arguments
|
|
(<TT
|
|
CLASS="OPTION"
|
|
>–n</TT
|
|
> just makes it print addresses as dotted
|
|
quad instead of using the hostname):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route -n</B
|
|
></TT
|
|
>
|
|
Kernel routing table
|
|
Destination Gateway Genmask Flags Metric Ref Use Iface
|
|
127.0.0.1 * 255.255.255.255 UH 1 0 112 lo
|
|
172.16.1.0 * 255.255.255.0 U 1 0 10 eth0</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The detailed meaning of these fields is explained later in <A
|
|
HREF="x-087-2-iface.netstat.html"
|
|
>Section 5.9</A
|
|
>." The <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>Flags</SPAN
|
|
> column contains a list of flags set
|
|
for each interface. <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>U</SPAN
|
|
> is
|
|
always set for active interfaces, and <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>H</SPAN
|
|
> says the destination address denotes a
|
|
host. If the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>H</SPAN
|
|
> flag is set for
|
|
a route that you meant to be a network route, you have to reissue the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> command with the <TT
|
|
CLASS="OPTION"
|
|
>–net</TT
|
|
>
|
|
option. To check whether a route you have entered is used at all,
|
|
check to see if the <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>Use</SPAN
|
|
> field
|
|
in the second to last column increases between two invocations of
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ping</B
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.GATEWAY"
|
|
>5.7.3. Routing Through a Gateway</A
|
|
></H2
|
|
><P
|
|
>In the previous section, we covered only the case of setting up a host
|
|
on a single Ethernet. Quite frequently, however, one encounters
|
|
networks connected to one another by gateways. These gateways may
|
|
simply link two or more Ethernets, but may also provide a link to the
|
|
outside world, such as the Internet. In order to use a gateway, you
|
|
have to provide additional routing information to the networking
|
|
layer.</P
|
|
><P
|
|
>The Ethernets of the Virtual Brewery and the Virtual Winery are linked
|
|
through such a gateway, namely the host <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>. Assuming that <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> has already been configured, we
|
|
just have to add another entry to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vstout</SPAN
|
|
>'s routing table that tells the
|
|
kernel it can reach all hosts on the Winery's network through
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>. The appropriate
|
|
incantation of <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> is shown below; the
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>gw</SPAN
|
|
> keyword tells it that the
|
|
next argument denotes a gateway:</P
|
|
><P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add wine-net gw vlager</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Of course, any host on the Winery network you wish to talk to must have
|
|
a routing entry for the Brewery's network. Otherwise you would only be able
|
|
to send data to the Winery network from the Brewery network, but the hosts on
|
|
the Winery would be unable to reply.</P
|
|
><P
|
|
>This example describes only a gateway that switches packets between
|
|
two isolated Ethernets. Now assume that <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> also has a connection to the
|
|
Internet (say, through an additional SLIP link). Then we would want
|
|
datagrams to <I
|
|
CLASS="EMPHASIS"
|
|
>any</I
|
|
> destination network other than
|
|
the Brewery to be handed to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>. This action can be accomplished
|
|
by making it the default gateway for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vstout</SPAN
|
|
>:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add default gw vlager</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>
|
|
The network name <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>default</SPAN
|
|
> is a shorthand
|
|
for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>0.0.0.0</SPAN
|
|
>, which denotes the default
|
|
route. The default route matches every destination and will be used if there
|
|
is no more specific route that matches. You do not have to add this name to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/etc/networks</TT
|
|
> because it is built into
|
|
<B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
>.</P
|
|
><P
|
|
>If you see high packet loss rates when pinging a host behind one or more
|
|
gateways, this may hint at a very congested network. Packet loss is not so
|
|
much due to technical deficiencies as to temporary excess loads on
|
|
forwarding hosts, which makes them delay or even drop incoming datagrams.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.GATEWAY-CONF"
|
|
>5.7.4. Configuring a Gateway</A
|
|
></H2
|
|
><P
|
|
>Configuring a machine to switch packets between two Ethernets is
|
|
pretty straightforward. Assume we're back at <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>, which is equipped with two
|
|
Ethernet cards, each connected to one of the two networks. All you
|
|
have to do is configure both interfaces separately, giving them their
|
|
respective IP addresses and matching routes, and that's it.</P
|
|
><P
|
|
>It is quite useful to add information on the two interfaces to the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>hosts</TT
|
|
> file as shown in the following example, so
|
|
we have handy names for them, too:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
>172.16.1.1 vlager.vbrew.com vlager vlager-if1
|
|
172.16.2.1 vlager-if2</PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The sequence of commands to set up the two interfaces is then:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig eth0 vlager-if1</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add brew-net</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig eth1 vlager-if2</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add wine-net</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>If this sequence doesn't work, make sure your kernel has been compiled
|
|
with support for IP forwarding enabled. One good way to do this is to
|
|
ensure that the first number on the second line of
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/proc/net/snmp</TT
|
|
> is set to <TT
|
|
CLASS="LITERAL"
|
|
>1</TT
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.PLIP"
|
|
>5.7.5. The PLIP Interface</A
|
|
></H2
|
|
><P
|
|
>A PLIP link used to connect two machines is a little different from an
|
|
Ethernet. PLIP links are an example of what are called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>point-to-point</I
|
|
> links, meaning that there is a single
|
|
host at each end of the link. Networks like Ethernet are called
|
|
<I
|
|
CLASS="EMPHASIS"
|
|
>broadcast</I
|
|
> networks. Configuration of point-to-point links
|
|
is different because unlike broadcast networks, point-to-point links don't
|
|
support a network of their own.</P
|
|
><P
|
|
>PLIP provides very cheap and portable links between computers. As
|
|
an example, we'll consider the laptop computer of an employee at the Virtual
|
|
Brewery that is connected to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>
|
|
via PLIP. The laptop itself is called
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
> and has only one parallel port.
|
|
At boot time, this port will be registered as <TT
|
|
CLASS="FILENAME"
|
|
>plip1</TT
|
|
>. To
|
|
activate the link, you have to configure the <TT
|
|
CLASS="FILENAME"
|
|
>plip1</TT
|
|
>
|
|
interface using the following commands:<A
|
|
NAME="X-087-2-FNTC07"
|
|
HREF="#FTN.X-087-2-FNTC07"
|
|
>[3]</A
|
|
>
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig plip1 vlite pointopoint vlager</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add default gw vlager</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>The first command configures the interface, telling the kernel that this
|
|
is a point-to-point link, with the remote side having the address of
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>. The second installs the default
|
|
route, using <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> as gateway. On
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>, a similar
|
|
<B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> command is necessary to activate the link
|
|
(a <B
|
|
CLASS="COMMAND"
|
|
>route</B
|
|
> invocation is not needed):
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig plip1 vlager pointopoint vlite</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>Note that the <TT
|
|
CLASS="FILENAME"
|
|
>plip1</TT
|
|
> interface on <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> does not need a separate IP
|
|
address, but may also be given the address <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.1</SPAN
|
|
>. Point-to-point networks don't
|
|
support a network directly, so the interfaces don't require an address
|
|
on any supported network. The kernel uses the interface information in
|
|
the routing table to avoid any possible confusion.<A
|
|
NAME="X-087-2-FNTC08"
|
|
HREF="#FTN.X-087-2-FNTC08"
|
|
>[4]</A
|
|
></P
|
|
><P
|
|
> Now we have configured routing from the laptop to the Brewery's
|
|
network; what's still missing is a way to route from any of the
|
|
Brewery's hosts to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
>. One
|
|
particularly cumbersome way is to add a specific route to every host's routing
|
|
table that names <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> as a gateway
|
|
to <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
>:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add vlite gw vlager</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
><P
|
|
>
|
|
|
|
|
|
|
|
|
|
Dynamic routing offers a much better option for temporary routes. You
|
|
could use <B
|
|
CLASS="COMMAND"
|
|
>gated</B
|
|
>, a routing daemon, which you would
|
|
have to install on each host in the network in order to distribute
|
|
routing information dynamically. The easiest option, however, is to
|
|
use <I
|
|
CLASS="EMPHASIS"
|
|
>proxy ARP</I
|
|
> (Address Resolution Protocol).
|
|
With proxy ARP, <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
> will
|
|
respond to any ARP query for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
> by sending its own Ethernet
|
|
address. All packets for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
> will wind up at <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlager</SPAN
|
|
>, which then forwards them to the
|
|
laptop. We will come back to proxy ARP in the section <A
|
|
HREF="x-087-2-iface.verify.arp.html"
|
|
>Section 5.10</A
|
|
>.”</P
|
|
><P
|
|
> Current <TT
|
|
CLASS="FILENAME"
|
|
>net-tools</TT
|
|
> releases contain a tool called
|
|
<B
|
|
CLASS="COMMAND"
|
|
>plipconfig</B
|
|
>, which allows you to set certain PLIP
|
|
timing parameters. The IRQ to be used for the printer port can be set using
|
|
the <B
|
|
CLASS="COMMAND"
|
|
>ifconfig</B
|
|
> command.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.SLIP"
|
|
>5.7.6. The SLIP and PPP Interfaces</A
|
|
></H2
|
|
><P
|
|
>Although SLIP and PPP links are only simple point-to-point links like
|
|
PLIP connections, there is much more to be said about them. Usually,
|
|
establishing a SLIP connection involves dialing up a remote site
|
|
through your modem and setting the serial line to SLIP mode. PPP is
|
|
used in a similar fashion. We discuss SLIP and PPP in detail in
|
|
<A
|
|
HREF="x-087-2-slip.html"
|
|
>Chapter 7</A
|
|
> and <A
|
|
HREF="x-087-2-ppp.html"
|
|
>Chapter 8</A
|
|
>.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.DUMMY"
|
|
>5.7.7. The Dummy Interface</A
|
|
></H2
|
|
><P
|
|
>The dummy interface is a little exotic, but rather useful
|
|
nevertheless. Its main benefit is with standalone hosts and machines
|
|
whose only IP network connection is a dialup link. In fact, the
|
|
latter are standalone hosts most of the time, too.</P
|
|
><P
|
|
>The dilemma with standalone hosts is that they only have a single
|
|
network device active, the loopback device, which is usually assigned
|
|
the address <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>127.0.0.1</SPAN
|
|
>. On
|
|
some occasions, however, you must send data to the
|
|
“official” IP address of the local host. For instance,
|
|
consider the laptop <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
>,
|
|
which was disconnected from a network for the duration of this
|
|
example. An application on <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
> may now want to send data to
|
|
another application on the same host. Looking up <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
> in <TT
|
|
CLASS="FILENAME"
|
|
>/etc/hosts</TT
|
|
>
|
|
yields an IP address of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.65</SPAN
|
|
>, so the application tries to
|
|
send to this address. As the loopback interface is currently the only
|
|
active interface on the machine, the kernel has no idea that
|
|
<SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.65</SPAN
|
|
> actually refers
|
|
to itself ! Consequently, the kernel discards the datagram and returns
|
|
an error to the application.</P
|
|
><P
|
|
>This is where the dummy device steps in. It solves the dilemma by
|
|
simply serving as the alter ego of the loopback interface. In the
|
|
case of <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>vlite</SPAN
|
|
>, you simply
|
|
give it the address <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.65</SPAN
|
|
> and add a host route pointing
|
|
to it. Every datagram for <SPAN
|
|
CLASS="SYSTEMITEM"
|
|
>172.16.1.65</SPAN
|
|
> is then delivered
|
|
locally. The proper invocation is:<A
|
|
NAME="X-087-2-FNTC09"
|
|
HREF="#FTN.X-087-2-FNTC09"
|
|
>[5]</A
|
|
>
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig dummy vlite</B
|
|
></TT
|
|
>
|
|
# <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>route add vlite</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="X-087-2-IFACE.INTERFACE.ALIAS"
|
|
>5.7.8. IP Alias</A
|
|
></H2
|
|
><P
|
|
>New kernels support a feature that can completely replace the dummy
|
|
interface and serve other useful functions. <I
|
|
CLASS="EMPHASIS"
|
|
>IP
|
|
Alias</I
|
|
> allows you to configure multiple IP addresses onto a
|
|
physical device. In the simplest case, you could replicate the function
|
|
of the dummy interface by configuring the host address as an alias
|
|
onto the loopback interface and completely avoid using the dummy
|
|
interface. In more complex uses, you could configure your host to look
|
|
like many different hosts, each with its own IP address. This
|
|
configuration is sometimes called “Virtual Hosting,”
|
|
although technically it is also used for a variety of other
|
|
techniques.<A
|
|
NAME="X-087-2-FNTC10"
|
|
HREF="#FTN.X-087-2-FNTC10"
|
|
>[6]</A
|
|
></P
|
|
><P
|
|
>To configure an alias for an interface, you must first ensure that
|
|
your kernel has been compiled with support for IP Alias (check that
|
|
you have a <TT
|
|
CLASS="FILENAME"
|
|
>/proc/net/ip_alias</TT
|
|
> file; if not, you
|
|
will have to recompile your kernel). Configuration of an IP alias is
|
|
virtually identical to configuring a real network device; you use a
|
|
special name to indicate it's an alias that you want. For example:
|
|
|
|
<TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><PRE
|
|
CLASS="SCREEN"
|
|
># <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>ifconfig lo:0 172.16.1.1</B
|
|
></TT
|
|
></PRE
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
>
|
|
|
|
This command would produce an alias for the loopback interface with
|
|
the address <TT
|
|
CLASS="LITERAL"
|
|
>172.16.1.1</TT
|
|
>. IP aliases are referred to
|
|
by appending :<TT
|
|
CLASS="REPLACEABLE"
|
|
><I
|
|
>n</I
|
|
></TT
|
|
> to the actual
|
|
network device, in which “n” is an integer. In our example,
|
|
the network device we are creating the alias on is
|
|
<TT
|
|
CLASS="LITERAL"
|
|
>lo</TT
|
|
>, and we are creating an alias numbered zero for
|
|
it. This way, a single physical device may support a number of
|
|
aliases.</P
|
|
><P
|
|
>Each alias may be treated as though it is a separate device, and as
|
|
far as the kernel IP software is concerned, it will be; however, it
|
|
will be sharing its hardware with another interface.</P
|
|
></DIV
|
|
></DIV
|
|
><H3
|
|
CLASS="FOOTNOTES"
|
|
>Notes</H3
|
|
><TABLE
|
|
BORDER="0"
|
|
CLASS="FOOTNOTES"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC05"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC05"
|
|
>[1]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>Anyone remember Pink Floyd's “Echoes”?</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC06"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC06"
|
|
>[2]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
> For example, all applications based on RPC
|
|
use the loopback interface to register themselves with the
|
|
<B
|
|
CLASS="COMMAND"
|
|
>portmapper</B
|
|
> daemon at startup. These applications
|
|
include NIS and NFS.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC07"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC07"
|
|
>[3]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>Note that <TT
|
|
CLASS="USERINPUT"
|
|
><B
|
|
>pointopoint</B
|
|
></TT
|
|
> is not a typo. It's really spelled like
|
|
this.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC08"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC08"
|
|
>[4]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
> As a matter of caution, you should
|
|
configure a PLIP or SLIP link only after you have completely set up
|
|
the routing table entries for your Ethernets. With some older kernels,
|
|
your network route might otherwise end up pointing at the
|
|
point-to-point link.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC09"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC09"
|
|
>[5]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
>The dummy device is called <TT
|
|
CLASS="FILENAME"
|
|
>dummy0</TT
|
|
> if you have
|
|
loaded it as a module rather than choosing it as an inbuilt kernel
|
|
option. This is because you are able to load multiple modules and have
|
|
more than one dummy device.</P
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="5%"
|
|
><A
|
|
NAME="FTN.X-087-2-FNTC10"
|
|
HREF="x-087-2-iface.interface.html#X-087-2-FNTC10"
|
|
>[6]</A
|
|
></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
WIDTH="95%"
|
|
><P
|
|
> More correctly, using
|
|
IP aliasing is known as network layer virtual hosting. It is more
|
|
common in the WWW and STMP worlds to use application layer virtual
|
|
hosting, in which the same IP address is used for each virtual host,
|
|
but a different hostname is passed with each application layer
|
|
request. Services like FTP are not capable of operating in this way,
|
|
and they demand network layer virtual hosting.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-iface.simple-resolv.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-iface.ifconfig.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Writing hosts and networks Files</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x-087-2-iface.html"
|
|
>Up</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>All About ifconfig</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |