- 论坛徽章:
- 0
|
Table of Contents
1.0: About Routing
1.1: Routing Definitions
1.2: How Routing Starts Up
1.3: IP addresses, Netmasks and Subnets
2.0: Debugging Routing
2.1: ifconfig
2.2: netstat
2.3: ping
2.4: traceroute
3.0: Common How Tos
3.1: How to Set a defaultrouter
3.2: How to Add Static Routes
3.3: How to Use in.rdisc
3.4: How to Use in.routed
3.5: How to Force a Machine to Be a Router
3.6: How to Force a SunOS Machine Not to Be a Router
3.7: How to Force a Solaris Machine Not to Be a Router
3.8: How to Set a Netmask under SunOS
3.9: How to Set a Netmask under Solaris
3.10: How to Subnet by Bit
3.11: How to Protect a Gateway Machine
3.12: How to Proxy ARP
3.13: How to Delete ARP Entries
1.0 About Routing
This PSD documents a wide variety of information concerning routing as
implemented in the SunOS and Solaris operating systems. It is intended
as both an introduction to routing, and as a guide to the most common
problems. Routing can be a very complex subject, and this PSD can
really only skim the surface of it. If you are setting up a complex
routing environment, you will probably also want to refer to the more
complete references listed in Section 7.0.
For this discussion of routing, an understanding is needed of various
aspects of ROUTING, as well as NETMASKS. These are both covered below.
Solaris in.routed supports RIPv1 ( rip version 1).
RIPv2 is available in gated, gated is not SUPPORTED
1.1: Routing Definitions
The ROUTING TABLE is a table maintained in the kernel that determines
how packets are routed to other systems. A number of programs may add
or delete routes from the routing tables, including route, ifconfig,
in.routed and in.rdisc. The routing table consists of three types of
routes:
HOST ROUTES are checked first and define a route to just one host.
NETWORK ROUTES are checked second and define a route to all the hosts
on one network.
DEFAULT ROUTES are used as a catch-all, when no host or network routes
are found to a destination. They usually send to a more knowledgeable
routing machine, which has a better chance of being able to find a
host or network route to the destination. (see Section 3.1 for how to
add a default static route as explained in Sections 3.3 and 3.4,
default routes may also be used with in.routed and in.rdisc.)
For a packet to get from your machine to its destination, it usually
goes through a number of routers. Each of these routers decides what
to do with the packet based on the set of rules listed above.
Systems are configured to handle routing in one of two ways:
With STATIC ROUTING, the tables in the kernel are defined when the
system boots and do not change. The ROUTE command can also be used to
manually add and remove static routes. (see Section 3.1 for how to add
an automatic default route at boot time see Section 3.2 for how to
use route to add static routes.)
With DYNAMIC ROUTING, the tables in the kernel are updated by a
ROUTING DAEMON as the network changes. SunOS and Solaris machines both
provide IN.ROUTED to exchange routing information between hosts.
in.routed depends upon RIP PACKETS to exchange this info. Solaris also
provides IN.RDISC, which just manipulates default routes. in.rdisc
depends upon ROUTER DISCOVERY PACKETS to gather this information. (see
Sections 3.3 and 3.4 for how to run in.routed, and in.rdisc,
respectively.)
In addition, IFCONFIG will always add routes when interfaces are
brought up. These routes will be to directly connected networks for
most interfaces, though they will be to directly connected hosts for
point-to-point interfaces.
With regard to routing, machines are divided into two classes, routers
and hosts:
A machine with more than one interface is, by default, defined to be a
ROUTER. If in.rdisc or in.routed are running, they will advertise
routing information. In addition, the machine will automatically
forward IP packets. (see Section 3.6 and 3.7 for how to force a
multiple-interface machine not to be a router.)
A machine with only one interface is a HOST. If in.rdisc or in.routed
are running, the host will listen for routing information. Hosts do
not advertise routing information.
1.1.1: A Note on ARP
This document also contains some information on ARP, the ADDRESS
RESOLUTION PROTOCOL. ARP is the protocol which converts the IP address
to an address appropriate to the hardware type (ie, ethernet addresses
on an ether network). After normal routing protocols have done their
work, ARP springs in to action. It's what actually gets packets from
one machine to another.
Usually, you should not have to worry about ARP at all. Except in
special setups, it should work totally transparently.
1.2: How Routing Starts Up
Solaris and SunOS each have a specific order which they use to start
up routing:
If an /etc/defaultrouter file exists (see Section 3.1), only static
routing will be used, and a static default route will be created to
the machine listed in the defaultrouter file.
If there is no /etc/defaultrouter file, and the machine is a router,
both in.routed and in.rdisc will be started, and they will advertise
routing information. SunOS machines will only start up in.routed, as
in.rdisc is not available under SunOS.
If there is no /etc/defaultrouter file, and the machine is a host,
in.rdisc is initially started. If any machines on the same network
advertise via Routing Discovery, in.rdisc will be used as the dynamic
routing program if there are no machines advertising via Routing
Discovery, in.rdisc will quickly quit. SunOS skips this step.
Finally, if there is no /etc/defaultrouter file, and either the
machine is running SunOS, or in.rdisc has failed, then in.routed is
started. It will listen for other in.routed programs advertising via
RIP packets. This is the default manner in which most out-of-the-box
Suns will operate.
1.3: IP addresses, Netmasks and Subnets
All IP ADDRESSES are divided into two portions: the NETWORK ADDRESS,
and the HOST ADDRESS. The network portion of the IP address defines
the level at which routing is done this means that all machines with
the same network address are on the same network. For example, if we
had the IP address a.b.c.d, we might learn that the network portion of
that address was a.b, and the host portion of that address was c.d. In
that case, all machines with the IP address a.b.*.* would be on the
same network. We would typically see a route to the network a.b.0.0.
By default, Internet IP addresses are divided into 3 Classes. Each of
these ranges has a different portion of the IP address reserved as the
network and host addresses.
Class IP Range Network Host
----- -------- ------- ----
Class A 1.*.*.* to 127.*.*.* a b.c.d
Class B 128.*.*.* to 191.*.*.* a.b c.d
Class C 192.*.*.* to 223.*.*.* a.b.c d
Multicast:
Class D 224.0.0.0 to 239.255.255.255.
Reserved:
Class E 240.0.0.0 to 247.255.255.255
Given the standard classes, a few typical network routes would be:
16.0.0.0
150.101.0.0
207.48.123.0
NETMASKS are a shorthand way to define what portion of an IP address
is reserved for the network address. The netmask is a set of 1 and 0
bits bits set to 1 define the network portion of an IP address, while
bits set to 0 define the host portion of an IP address. We can look at
the example of a Class B network address. In the address a.b.c.d, the
network portion is a.b and the host portion is c.d. This is equivalent
to the netmask 255.255.0.0:
255.255.0.0 = 11111111.11111111.00000000.00000000
This means that the three classes of networks have the following three
default netmasks:
Class IP Range Netmask Nodes/Network
----- -------- ------- -------------
Class A 1.*.*.* to 127.*.*.* 255.0.0.0 16,777,215
Class B 128.*.*.* to 191.*.*.* 255.255.0.0 65,535
Class C 192.*.*.* to 223.*.*.* 255.255.255.0 255
Thus, packets sent to 100.1.2.3 are routed at the level 100.0.0.0 (and
all 16 million machines in the 100.*.*.* range should form one
distinct network), while packets sent to 200.1.2.3 are routed at the
level 200.1.2.0 (and all 255 machines in the 200.1.2.* range should
form one distinct network).
Often, the default netmasks are not sufficient. You can further divide
a network by defining a custom netmask. This is termed SUBNETTING. A
custom netmask changes the definition of the network size, and also
changes the level at which routing is done. For example, many people
on Class A or B networks implement a netmask of 255.255.255.0, so that
all routing is done to networks of 255 or less machines. Sections 3.8
and 3.9 explain how to set a custom netmask for SunOS and Solaris.
A few examples of custom netmasks:
IP Address Netmask Network Address
---------- ------- ---------------
16.1.2.3 255.255.0.0 16.1.0.0
32.7.3.7 255.255.255.0 32.7.3.0
150.101.16.28 255.255.255.0 150.101.16.0
This netmasking is really done down at the bit level. These means that
you can divide a network even further. An example of this is given
down in Section 3.10.
[Example Note: references to the network 150.101.*.* in this document should
be understood to be wholely fictious, and are only used for reasons of
example.]
Ip Addressing assignment notes:
InterNic Pre-Reserved Private Network - see RFC 1918
proposes network numbers that are reserved forprivate use.
( networks not on the internet or behind a Firewall using NAT)
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
It is unwise to create a private network with the same addressing as one
assigned on the global internet.
What Addresses NOT to use ?
IP address is all zeros
IP address of all ones
A valid network number
A valid subnet number
loopback
127.x.x.x
addresses reserved by the Network Information Center.
( 0.x.x.x, 128.0.x.x, 191.255.x.x, 129.0.0.x, 223.255.255.x )
Multicast
224.x.x.x (greater than 223.*.*.*)
What is the meaning of N in x.x.x.x/N?
N is the number of significant bits in a prefix. This is a compact notation.
In the old days, you'd write 129.146.86.51, netmask 255.255.255.0.
Nowadays, you can just say 129.146.86.51/24, because 24 bits of the address
indicate the subnet. We no longer have class in IP addresses (as of Solaris
2.6),
so this syntax fits better. Also this will be the PRIMARY way of saying
things in IPv6.
2.0 Debugging Routing
Routing can be somewhat tricky because problems could exist anywhere
between you and your destination machine. The following commands are
helpful, because they can be used to isolate which machine is the one
with incorrect information.
The following understanding of routing is necessary to be able to
fully debug your routing tables:
For communication from host A to host B to work, there must be a route
from A to B and there must be a route from B to A.
If there is an intermediate machine, machine C, then there should be a
route from A to B through C, and C must have a route to B. The reverse
is true as well. There must be a route from B to A through C and also
a route from C to A.
Also, C must be configured to pass packets from one interface to
another to allow routing. This is done via the ip_forwarding variable
described in sections 3.6 and 3.7.
When debugging routing, you must also know whether you are working
with a host or a router, as they have very different characteristics.
2.1: ifconfig
It is always best to start investigating routing problems by making
sure that your interfaces are set up correctly. By running ifconfig,
you can see your current interface setup:
# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST>; mtu 8232
inet 127.0.0.1 netmask ff000000
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST>; mtu 1500
inet 150.101.16.28 netmask ffffff00 broadcast 150.101.16.255
ether 8:0:20:10:78:d
When an interface is brought up, it automatically creates a route.
This route will be to the local network for multipoint interfaces
(ether, FDDI, TR, etc), or to a host for point-to-point interfaces
(PPP).
If your main interface (le0 in the above example) is not UP and
RUNNING, clearly no routing will be occurring through it. If the
interface is UP, you will also want to examine the inet and netmask
entries of your main interface, and make sure they are set correctly.
If the inet is set wrong, check your /etc/hostname.interfacename file
(ie, hostname.le0) and your /etc/hosts file. If the netmask is set
wrong, check your /etc/netmasks file (see Section 3.8 and Section 3.9
for correct netmask setup).
2.2: netstat
You can examine your current routing tables by running the command
netstat, as follows:
%%%% netstat -rn
Routing Table:
Destination Gateway Flags Ref Use Interface
-------------------- -------------------- ----- ----- ------ ---------
127.0.0.1 127.0.0.1 UH 0 581 lo0
150.101.16.0 150.101.16.28 U 3 935 le0
224.0.0.0 150.101.16.28 U 3 0 le0
default 150.101.16.3 UG 0 802
default 150.101.16.12 UG 0 854
By examining this table, and correlating it with your problems, you
can sometimes figure out what is going on. For example, if some of my
non-local packets were randomly getting lost, I might suspect that one
of my two default routes was dropping packets.
Some problems are even more obvious. For example, if the "default"
entries were not present in the Routing Table above, I would probably
find that I could route nowhere but 127.0.0.1, 150.101.16.0 and
224.0.0.0. (In actuality, 224.0.0.0 is a special multicast route,
while 127.0.0.1 is a special localhost route they can both be ignored
for basic discussions of routing, which would mean that I could really
route only to the network 150.101.16.0.)
2.3: ping
If your problem is not obvious from examining 'ifconfig -a' and
'netstat -rn', the ping command can be very useful in diagnosing it
further. Try running 'ping -s machine-with-no-route'. There are two
possibilities.
If you get some type of 'network unreachable' or 'host unreachable'
error, this typically means that there is no route on your machine to
the machine you are trying to ping. You will probably need to define a
static route for that machine's network, or possibly a default route.
Following are a few examples.
Under SunOS, you'll just get the basic '... unreachable' errors:
%%%% ping -s lab-manta
PING lab-manta: 56 data bytes
sendto: Network is unreachable
ping: wrote 150.101.89.28 64 chars, ret=-1
At this point, you should return to looking at your 'netstat -r'
table. You should find that there is no entry for the network you are
trying to ping.
Under Solaris, you will get some additional information. In the
following example, I am again pinging lab-manta from psi:
%%%% ping -s lab-manta
PING lab-manta: 56 data bytes
ICMP Host Unreachable from gateway psi (150.101.16.2 for icmp from psi
(150.101.16.2 to lab-manta (150.101.89.2
The above message confirms very clearly that it is the gateway 'psi'
that did not have the route, when I tried to ping from 'psi' to
'lab-manta'. Again, I would have to examine psi's routing tables at
this point.
In addition, Solaris can sometimes report back errors that remote
machines are having:
%%%% ping -s lab-manta
PING lab-manta: 56 data bytes
ICMP Host Unreachable from gateway softmtv716 (150.101.16.3) for icmp from
psi (150.101.16.2 to lab-manta (150.101.89.2
In this case, it is the gateway 'softmtv716', which is one of my
default routers, which does not have a path to the remote machines. If
I investigate the routing tables on that machine, I will probably find
that there is no route to the 150.101.89.0 subnet.
The other possibility is that ping just reports packets being dropped:
%%%% ping -s lab-manta
PING lab-manta: 56 data bytes
^C
----lab-manta PING Statistics----
7 packets transmitted, 0 packets received, 100%%%% packet loss
First, you should verify that the remote machine is up. If it is, you
likely have a routing problem.
Usually, this means that routes do exist in routing tables, but
something along the path just drops the packets. This usually occurs
because a router is set up wrong, or because a machine is listed as a
gateway, but is not configured to forward IP packets.
The only way to diagnose this is to examine a map of your network,
find all the IP addresses in between you and the machine that is not
responding, and then ping them one at a time. For example, I might
discover that to get to lab-manta, a packet first goes out of the
ethernet interface of psi, then into router-le0, then out of
router-le1, then into lab-manta. In this case, I would ping first psi,
then router-le0, then router-le1 then lab-manta. If router-le0
responded, but router-le1 did not, I would suspect that router was not
passing packets correctly.
(If you note such a problem, before examining the router, you should
check the netmask on your local machine, via the ifconfig -a command.
An incorrectly set netmask can cause the symptoms described above.)
If you discover that a remote router or non-Sun machine is not passing
packets, SunService is unable to provide further assistance in this
routing matter. Sections 8.0 and 9.0 explain your alternatives.
If you discover that a Sun machine is not passing packets, you should
make sure that the procedures explained in Sections 3.6 and 3.7 have
not been implemented on the remote machine, to prevent it from
routing.
Packets might also be dropped if there are not paths back to your
machine. In the above example, packets might go from psi, to router,
to lab-manta fine, and then run into problems on the return trip. If
nothing else has proved fruitful, you could then examine lab-manta,
and make sure it had a path to psi, through router, and then examine
router, and make sure that it also had a path to psi.
2.3.1: ping -sRv
ping is able to record routes for you. However, this is only of
limited utility because (1) you will not get any results if packets
are not being returned (2) there is a limit of 9 IP addresses -and-
(3) this method depends upon source routing, which may be turned off
on some machines, for security reasons.
Still, if you find that routes are being done incorrectly, you might
find it of some use. Here is an example of usage:
%%%% ping -sRv lab-classic
PING lab-classic: 56 data bytes
64 bytes from lab-classic (150.101.89.54): icmp_seq=0. time=7. ms
IP options: <record route>; softmtv703-bb (150.101.15.60), four-oh
(150.101.89
.4), lab-classic (150.101.89.54), install-7 (150.101.89.25), four-oh-mrn
(150.10
1.15.11), softmtv716 (150.101.16.3), psi (150.101.16.2, (End of record)
^C
----lab-classic PING Statistics----
1 packets transmitted, 1 packets received, 0%%%% packet loss
round-trip (ms) min/avg/max = 7/7/7
This was done on this network:
16.28---(16.0)---16.3/15.60---(15.0)---15.11/89.4---(89.0)---89.54
psi softmtv four-oh lab-classic
Two things are of note here. First, the route we get returned is a
round trip, to the machine and back. Second, whenever a packet hits a
machine, ping -sRv records only the OUTGOING interface, not the
incoming interface. That is, the first time a packet goes through
softmtv, we see the address 15.60, not 16.3.
It's also interesting to see that the route was not symmetric. The
packet bounced off install-7 on the way back, which is a machine that
it did not touch on the way in. Examining that type of things can
point you towards possible errors in your routing.
If ping -sRv gives you massively incomplete info, or no info, you
should ignore it, as you're probably hitting one of the limitations
described at the start of this section.
2.4: traceroute
If you can't solve your routing problems by looking at the routing
tables and interfaces, a useful program for helping solve the problem
is traceroute.
Solaris 2.7 software bundles the popular traceroute utility.
Unfortunately, this program is not shipped with SunOS or Solaris prior to 2.7,
and as a result is not supported by SunService. However, you can easily find
a copy on the internet.
The ftp site ftp.dfn.de contains traceroute under the /pub/tools
directory. If you consult 'archie' or other searching programs, it is
likely that you will be able to find a more local copy.
Traceroute works by sending out a set of 3 UDP packets. These packets
are initially given a Time-To-Live of 1 hop, which is then increased
to 2 hops, then to 3, etc.... until the packets reach the remote
machine. This has the effect of stepping through the routers leading
towards a destination machine, one at a time. However, it also causes
you to only see a unidirectional route, from your client to the
destination machines. It's quite possible for routes to be different
going from and to a machine, and traceroute will not standardly show
this. For example, if packets followed the following path:
-->; C -->;
A B
<-- D <--
A traceroute from A to B would show: A, C, B, while a traceroute from
B to A would show: B, D, A. Only by doing both traceroutes could you
be sure of understanding the full route to and from a machine.
Once you have a copy of traceroute, you can run it to request the path
to a machine as follows:
# traceroute lab-classic
traceroute to lab-classic (150.101.89.54), 30 hops max, 40 byte packets
1 rainbow-16 (150.101.16.12) 6 ms * 3 ms
2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms
3 lab-classic (150.101.89.54) 10 ms 3 ms 3 ms
Unlike ping, traceroute lists the INCOMING port of each machine.
We can get a round trip path by running traceroute with the following
options:
# traceroute -g remote-machine local-machine
For example, if I were logged in to psi, and wanted to know the round
trip path to lab-classic, I would type:
# traceroute -g lab-classic psi
traceroute to psi (150.101.16.2, 30 hops max, 40 byte packets
1 softmtv716 (150.101.16.3) 13 ms * 2 ms
2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms
3 lab-classic (150.101.89.54) 4 ms 4 ms 3 ms
4 install-7 (150.101.89.25) 3 ms * 3 ms
5 four-oh-mrn (150.101.15.11) 3 ms * 3 ms
6 softmtv716 (150.101.16.3) 3 ms * 6 ms
7 psi (150.101.16.2 10 ms 9 ms 3 ms
Again, we see that when the packets are headed to lab-classic, we just
get the INCOMING port listed. Oddly enough, traceroute reports the
same port on the way back. This is to avoid confusion.
However, this round trip method again uses source routing, which could
be a problem if some intervening machines disable source routing. If a
round trip invocation of traceroute seems to give bizarre results, you
should try running a traceroute in each direction, to be sure that you
are seeing the correct results.
Traceroute is more useful than ping -sRv because it will show us
partial paths, even if our destination machine is unreachable. In
addition, it will show more than 30 hops, while ping -sRv is limited
to 9.
For example, if I knew that packets were not getting to lab-manta, I
could run traceroute:
# traceroute lab-manta
traceroute to lab-manta (150.101.89.2, 30 hops max, 40 byte packets
1 rainbow-16 (150.101.16.12) 6 ms * 3 ms
2 four-oh-mrn (150.101.15.11) 3 ms * 3 ms
3 * * *
4 * * *
...
This would tell me that either four-oh is not passing packets, or the
router beyond four-oh is not answering at all. I could then examine
those machines for problems.
2.5: Running in.routed verbose and trace mode for debugging and logging
Examples:
in.routed -s -t
in.routed -q -v /var/adm/rip.log
See SunOS 5.6 in.routed(1M) man page
-v Allows a logfile (whose name must be supplied)
to be created showing the changes made to the routing tables with a
timestamp.
-t All packets sent or received are printed on standard output.
2.6 : Solaris 2.6 route debugging info
For further info see the 2.6 route man page and answerbook.
-------------------------
Route verbose mode example:
# route -v add 10.0.0.0 192.168.21.57 -net -netmask 255.255.255.0
so_dst: inet 10.0.0.0; so_gate: inet 192.168.21.57; so_mask: inet
255.255.255.0; RTM_ADD: Add Route: len 124, pid: 0, seq 1, errno 0, flags:<UP,
GATEWAY,STATIC>;
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>;
10.0.0.0 brickwall 255.255.255.0
add net 10.0.0.0: gateway 129.151.21.57
-------------------------
Route monitor
# route monitor
got message of size 124
RTM_ADD: Add Route: len 124, pid: 20871, seq 1, errno 0, flags:<UP,GATEWAY,DONE,
STATIC>;
locks: inits:
sockaddrs: <DST,GATEWAY,NETMASK>;
10.0.0.0 elvis 255.255.255.0
-------------------------
Route get
# route get elvis
route to: elvis
destination: 192.168.21.0
mask: 255.255.255.0
interface: le0
flags: <UP,DONE>;
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 0
3.0 Common How Tos
3.1: How to Set a defaultrouter
If you want to define a default router, so that you can send all of
your non-local packets through one standard machine, simply create the
file /etc/defaultrouter. It should have as its sole contents, the hostname
or ipnumber of your router:
%%%% cat /etc/defaultrouter
router-1
or:
150.101.16.1
Note that any machine listed as a defaultrouter _must_ be on the same
subnet as your machine and the name listed in /etc/hosts.
On Solaris 2.4, and later, you can actually list multiple routers in
the /etc/defaultrouter file, one default router per line:
%%%% cat /etc/defaultrouter
router-1
router-2
router-3
You also need to make sure that every name which appears in
/etc/defaultrouter has an entry in your /etc/hosts file:
%%%% cat /etc/hosts
...
150.101.16.1 router-1
150.101.16.2 router-2
150.101.16.3 router-3
After you have created /etc/defaultrouter, and made sure that any
names listed in that file are also listed in /etc/hosts, you can
reboot your machine. When it comes back up, it will automatically be
routing through the defaultrouter that you have defined.
If you have a simple network, or if you are just trying to get routing
to work after your Sun machine is first installed, you probably want
to set up a defaultrouter, as is described here. Section 4.1 gives
some further advice on what type of routing to use.
How does multiple default routes work?
see SunSolve Infodoc
INFODOC ID: 17516
SYNOPSIS: How does multiple default routes work ( 2 static defaultrouter
entries) ?
Multiple default routes (wildcards) is a special case, they will be used in a
round-robin fashion. Network connections will alternate between the
defaultrouters
unless one is down, in which case it may take a few seconds to pick up the next
defaultroute.
IREs( internal routing entries) are selected in a alternating fashion and
that once selected, they are cached and the IRE entry is used for subsequent
packets until it is flushed at ip_ire_flush_interval time (default 20 minutes)
Multiple IRE entries are created by packets using the different default
routes, which can be observed with " netstat -ra ".
What happens if one of the default routers goes off-line?
The TCP module on the gateway will attempt to resend the packet to that failed
router based upon
tcp_ip_notify_cinterval = 10 seconds (timeout value when TCP is performing an
active open after which, TCP notifies IP to find a new route
OR
tcp_ip_notify_interval = 2 min (timeout value for an ESTABLISHED connection
after
which TCP notifies IP to find a new route.
What happens if the default router looses the route?
If the default router is up, and the route that it would use to forward the
packet is not available and the router knows this, then the router should
send back to your gateway an ICMP redirect, which should specify the IP
address of one of your other default routers.
3.2: How to Add Static Routes
At any time, you can add static routes to your machine via the route
command. The standard syntax for adding a network route is:
route add net "remote-network-ip gateway-ip" 'hop-metric-count'
On Solaris 2.6:
route add -net "remote-network-ip gateway-ip" -netmask
route add -host "host-ip local-intrf-ip" -interface
remote-network-ip is the network you are adding a route to, gateway-ip
is the ip address of the gateway that leads to that remote-network.
hop-count is an integer which identifies the number of gateways that
you must go through to get to the remote-network. A network that is
directly connected to your machine would have a hop count of 0 (ie,
the 150.101.16.0 net in the example below). A remote-network that is
directly connected to a gateway-machine that is, in turn, on the same
network as your machine would have a hop count of 1 (ie, the
150.101.17.0 net in the example below). Static routes are rarely added
for remote-networks with a hop count greater than 1.
One thing to note is that the metric is really not used except to differentiate
between a "gateway" route (metric >; 0) and an interface route (metric == 0)."
Routes created with the route(1m) command play no part in the RIPv1 protocol
.."
For example, on the following network:
YOUR-MACHINE---(150.101.16.0 NET)---ROUTER-1---(150.101.17.0 NET)
You could execute the following command from your machine, in order to
create a static route to the 150.101.17.0 net:
route add net 150.101.17.0 150.101.16.1 1
(150.101.16.1 is the IP address of router-1)
Solaris 2.6 example:
route add -net 150.101.17.0 150.101.16.1 -netmask 255.255.255.0
The route command can also be used to add routes to remote machines.
This is typically only done when using some type of point-to-point
interface. The syntax is:
route add host remote-machine-ip gateway-ip hop-count
ie:
route add host 150.101.17.100 150.101.16.1 1
Static routes are usually only used in conjunction with a
/etc/defaultrouter. You might do so if you had a couple of networks
which you did not want to go through your defaultrouter. In that case,
you will probably want to make the routes permanent, by adding the
route commands to the /etc/init.d/inetinit file.
You can not use the above method to add static routes if you are
running in.routed, as in.routed will automatically remove them after
90 seconds. If you are using in.routed, but want to include a few
static routes, you can do this with the /etc/gateways file, explained
in Section 3.4 below.
3.3: How to Use in.rdisc
The in.rdisc daemon is only available on Solaris machine it depends
on multicasting, which is not present on older SunOS machines.
If you do not have an /etc/defaultrouter file on a Solaris machine,
any routing host will automatically bring up in.rdisc at boot time. As
long as there is at least one router on the same network which
advertises Router Discovery messages, in.rdisc will continue running.
If nothing responds to the initial Router Discovery queries, in.rdisc
on a routing host will automatically quit, and the rc files will fall
through to in.routed.
Solaris routers will also automatically bring up in.rdisc at boot
time, if there is no /etc/defaultrouter file. They will not ever exit,
but rather will advertise via Router Discovery messages.
If you want in.rdisc to run, you should never have to do anything,
other than delete the /etc/defaultrouter file, if it exists, and make
sure that at least one Router Discovery compliant router exists on the
same subnet as your machine.
If you want to disable in.rdisc, you should simply rename it:
%%%% mv /usr/sbin/in.rdisc /usr/sbin/rdisc.save
In general, in.rdisc should only be run on routing hosts if your local
network is relatively complex.
3.4: How to Use in.routed
On a SunOS machine, in.routed will automatically be started if there
is no /etc/defaultrouter file and in.rdisc failed to find any Router Discovery
compliant routers on the local network.
in.routed will automatically start on routers if there is no /etc/defaultrouter
file, even if in.rdisc is running.
in.routed supports RIPv1 only.
You should not need to do anything, other than possibly deleting an
/etc/defaultrouter file, in order to get in.routed to run.
You can force in.routed to bring up standard network routes by putting
entries for them into the file /etc/gateways. The standard format for
that file is:
net <remote-network-ip>; gateway <gateway-ip>; metric <hop-count>; passive
or:
net <remote-network-ip>; gateway <gateway-ip>; metric <hop-count>; active
remote-network-ip, gateway-ip and hop-count are all described in
Section 3.2. The keyword 'passive' should be used if you want the
entry to be permanent.Passive gateways are maintained in the routing
tables forever.Information regarding their existence is not included in any
routing information transmitted. Active gateways are treated equally to network
interfaces. The keyword 'active' should be used if you want
in.routed to occasionally query the gateway host, and delete the route
if it becomes inactive. Routing information is distributed to the gateway
and if no routing information is received for a period of time,the associated
route is deleted.
An example of a gateway file follows:
%%%% cat /etc/gateways
net 150.101.17.0 gateway 150.101.16.1 metric 1 passive
net 0.0.0.0 gateway 150.101.16.2 metric 1 passive
The first line of this example is identical to the 'route add' command
given in Section 3.2. It creates a route for the network 150.101.17.0
through the gateway machine 150.101.16.1.
In the gateways file, the number 0.0.0.0 is a special number which
means 'default route'. Thus, the second line creates a default route
through the gateway machine 150.101.16.2.
The gateways file may also be used to add routes to specific hosts,
with the following syntax:
host <remote-machine-ip>; gateway <gateway-ip>; metric <hop-count>; passive
Or:
host <remote-machine-ip>; gateway <gateway-ip>; metric <hop-count>; active
Finally, the following directives may also be put in a gateways file:
norip <interface>;
noripin <interface>;
noripout <interface>;
These prevent RIP (in.routed) packets from either going in or out of
the specified interface (norip prevents packets from going either in
or out). For example:
%%%% cat /etc/gateways
norip le1
The above would prevent RIP packets from going in or out of the le1
interface. This could be exceptionally helpful if you did not want
your RIP info to be broadcast out of your le1 interface for security
reasons.
In general, routed should only be used on routing hosts if your local
network is relatively complex. In addition, there must be machines on
the local network which will correctly send out RIP packets if there
are not, routed will fail to work correctly on a routing host.
If you wish to disable in.routed, the best way to do this is by
creating a defaultrouter file, as is described in Section 3.1.
3.5: How To Force a Machine to Be a Router
If your machine has at least two interfaces in addition to lo0, or if
your machine has at least one point-to-point interface, it will
automatically be set up as a router.
Solaris 2.x:
The IP layer will normally act as a router (forwarding datagrams that are not
addressed to it, among other things) when the machine has two or more
interfaces that are up. This behavior can be overridden by using ndd(1M)
to to set the /dev/ip variable, ip_forwarding. The value 0 means do not
forward; the value 1 means forward. The initialization scripts
(see /etc/init.d/inetinit) set this value at boot time based on the number
of "up" interfaces, but will not turn on IP forwarding at all if the
file /etc/notrouter exists. When the IP module is loaded, ip_forwarding is 0
and remains so if:
only one non-DHCP-managed interface is up (the most common case)
the file /etc/notrouter exists and DHCP does not say that IP forwarding is
on
the file /etc/defaultrouter exists and DHCP does not say IP forwarding is
on
Otherwise, ip_forwarding will be set to 1 .
SunOS 4.x
On a SunOS machine, you will want to adjust the /etc/rc.local file,
to change the following line:
in.routed echo 'running routing daemon.'
To read:
in.routed -s echo 'running routing daemon.'
In order to insure that routed is in the "supplier" mode and routing
information is being advertised.
This is done for you automatically on Solaris machines if there
are 2 up interfaces on bootup.
ip_forwarding must be enabled to allow the system to forward packets
between interfaces.
to check
on SunOS 4.x
# echo "ip_forwarding/X" | adb -w /vmunix /dev/kmem
on Solaris 2.x
# ndd /dev/ip ip_forwarding
0 = don't forward, 1 = forwarding enabled
3.6: How to Force a SunOS Machine Not to Be a Router
If you do not want your multiple-interface SunOS machine to route
packets, you will need to rebuild the kernel. In the file
/sys/netinet/in_proto.c, change the following line:
#define IPFORWARDING 0
to read:
#define IPFORWARDING -1
Afterwards, config the kernel, remake it, and then install it.
It may be useful to note, that on SunOS machines, IPFORWARDING can
have three values:
-1 Never forward IP packets
0 Don't forward, but change IPFORWARDING to 1 if there are two
or more interfaces
1 Always forward IP packets
3.7: How to Force a Solaris Machine Not to Be a Router
If you do not want your multiple-interface machine, running Solaris
2.4 or lower, to route packets, you just need to make a small change
to the file /etc/init.d/inetinit. Find the following two lines:
numifs=`ifconfig -au grep inet wc -l`
numptptifs=`ifconfig -au grep inet egrep -e '-->;' wc -l`
And immediately after them, insert the following:
numifs=2
numptptifs=0
After the machine next reboots, it will not act as a router.
If you are using Solaris 2.5 or greater, it's even easier to make your
machine not route packets. Simply create an /etc/notrouter file:
%% touch /etc/notrouter
Afterwards, reboot the machine.
It may be useful to note, that on Solaris machines, ip_forwarding can
have three values:
0 Never Forward
1 Always Forward
2 Only forward when two or more interfaces are up
The above steps result in the ndd /dev/ip ip_forwarding variable being
changed from "1" to "0", which prevents routing.
3.8: How to Set a Netmask under SunOS
In order to include a permanent netmask on your SunOS machine, you
must make an entry in the /etc/netmasks file, in the following format:
network-address-without-zeroes netmask
For example:
%%%% cat /etc/netmasks
150.101 255.255.255.0
The above would subnet the class B network, 150.101.0.0, into 254
subnets, from 150.101.1.0 to 150.101.254.0.
It is important to note that the entry in the left hand column must be
the original base network number (ie # for a Class A, #.# for a Class
B and #.#.# for a Class C), not the subnet.
3.9: How to Set a Netmask under Solaris
In order to include a permanent netmask on your Solaris machine, you
must make an entry in the /etc/netmasks file, in the following format:
network-address netmask
For example:
%%%% cat /etc/netmasks
150.101.0.0 255.255.255.0
The above would subnet the class B network, 150.101.0.0, into 254
subnets, from 150.101.1.0 to 150.101.254.0.
In 2.5.1 and below, only one entry for the entire class network is allowed
to support standard subnetting as specified in RFC-950
It is important to note that the entry in the left hand column must be
the original base network number (ie #.0.0.0 for a Class A, #.#.0.0
for a Class B and #.#.#.0 for a Class C), not the subnet.
The 2.6 kernel has changed to support VLSM. It is now possible to combine
the RFC-950 and RFC-1519 form of subnet masks in the netmasks file.
The network address should be the "SUBNETTED" address NOT the standard
network number based on the hosts ip address. (see man page for netmasks)
Here are a few examples:
A host address 192.188.206.65 with a netmask of 255.255.255.224
/etc/netmasks
192.188.206.64 255.255.255.224
A host address 172.31.16.193 with a netmask of 255.255.255.192
/etc/netmasks
172.31.16.192 255.255.255.192
See section 3.10 to get a better understanding of how to subnet by bit.
3.10: How to Subnet by Bit
As was noted in Section 1.3, subnetting is actually done at the bit
level. That is, all the bits that form the IP address are masked by
the bits that form the Netmask, in order to generate the Network
Address. Here's some examples of what a netmask looks like down at
the bit level:
255.255.255.0 = 11111111.11111111.11111111.00000000
255.255.255.192 = 11111111.11111111.11111111.11000000
And here are a few examples of using the '192' netmask:
IP Address Netmask Network Address
---------- ------- ---------------
150.101.16.90 255.255.255.192 150.101.16.64
150.101.16.150 255.255.255.192 150.101.16.128
Expanding out the first example should make this a bit more clear:
150.101.16.90 = 10010110.01100101.00010000.01011010
255.255.255.192 = 11111111.11111111.11111111.11000000
Network Address = 10010110.01100101.00010000.01000000 = 150.101.16.64
The resulting network number is 150.101.16.64 and the host address
is 26.
The only caveat is that RFC 917 states that it is illegal to have a
subnet address that is all 0s or all 1s. This means that when you
split your class C, you will lose the bottom set of IP addresses, and
also the top set of IP addresses.
Putting this all together, we can take a look at two examples. These
examples both assume a Class C network (that is a network between
192.*.*.* and 223.*.*.*), which you wish to subnet.
IP ADDRESS = any Class C
NETMASK = 255.255.255.128 = 11111111.11111111.11111111.10000000
Subnet 1 = '0' Illegal because subnet is all 0s
Subnet 2 = '1' Illegal because subnet is all 1s
Clearly, using the 255.255.255.128 mask to subnet a Class C is useless.
IP ADDRESS = any Class C
NETMASK = 255.255.255.192 = 11111111.11111111.11111111.11000000
Subnet 1 = '00' Illegal because subnet is all 0s
addresses x.x.x.0 to x.x.x.63 are wasted
Subnet 2 = '01' network x.x.x.64, broadcast x.x.x.127
machines range from x.x.x.65 to x.x.x.126
Subnet 3 = '10' network x.x.x.128, broadcast x.x.x.191
machines range from x.x.x.129 to x.x.x.190
Subnet 4 = '11' Illegal because subnet is all 1s
addresses x.x.x.192 to x.x.x.255 are wasted
Thus, if you had a Class C that you wanted to divide into two subnets,
you would use the 192 netmask described above, and end up with two
ranges of 63 machines each.
Now, the above all assumes that you own a Class C network, that is a
network with an network address between 192.*.*.* and 223.*.*.*.
Another common situation is the case where you are on a Class B
network (ie 150.101.0.0), but you actually control a network
equivalent in size to a Class C (ie 150.101.16.0), and you want to
subnet further. Things work about the same as above, but you do not
have to waste the top and bottom IP ranges. This is because the entire
subnet, which is nine or more bits long, is not set to all 0s or all 1s
in those cases only the last two digits are. So, if we were subnetting
150.101.16.0 further, using the 192 subnet, our table would look like
this:
IP ADDRESS = 150.101.16.0
(though any class B, further subnetted will work the same)
NETMASK = 255.255.255.192 = 11111111.11111111.11111111.11000000
Subnet 1 = '00010000.00' network 150.101.16.0, broadcast 150.101.16.63
machines range from 150.101.16.1 to 150.101.16.62
Subnet 2 = '00010000.01' network 150.101.16.64, broadcast 150.101.16.127
machines range from 150.101.16.65 to 150.101.16.126
Subnet 3 = '00010000.10' network 150.101.16.128, broadcast 150.101.16.191
machines range from 150.101.16.129 to 150.101.16.190
Subnet 4 = '00010000.11' network 150.101.16.192, broadcast 150.101.16.255
machines range from 150.101.16.193 to 150.101.16.254
Subnetting by the bit can be a pretty complex process and SunService
can not provide further assistance on initial configuration of this
type. However, if you're trying to subnet at this small of a level,
and don't totally understand how to do so, consult Section 8.0 and 9.0
for where you can get further assistance from within Sun.
3.11: How to Protect a Gateway Machine
Routing:
---------------
You may find that you wish to keep a gateway machine from sending
routing information via certain interfaces. This is usually done on a
machine that acts as a firewall of some type. Assuming that you have a
multiple interface machine that is advertising routing information
(via in.routed and in.rdisc), you should do two things.
First, totally turn off in.rdisc:
%%%% mv /usr/sbin/in.rdisc /usr/sbin/rdisc.save
Second, add norip lines to the /etc/gateways file for all interfaces
that you do not want routing information to be sent through. For
example, if le1 led to an external net, you would probably add the
following entry:
%%%% cat /etc/gateways
norip le1
This type of setup should only be done on a firewall machine where you
are trying to decrease your net connectivity.
IP forwarding:
---------------
For Security and network isolation. You can set ip_forwarding off and
ip_strict_dst_multihoming on, if you are trying to prevent access to
the other interfaces.
"ndd /dev/ip ip_forwarding" Determines if the workstation will route packets.
ex: ndd -set /dev/ip ip_forwarding 0
"ndd /dev/ip ip_strict_dst_multihoming" Determines whether to use Strict
Destination Multihoming. If this variable is set to True, and ip_forwarding
is turned off, then the machine will not except packets destined for a
different interface. RFC112
ex: ndd -set /dev/ip ip_strict_dst_multihoming 0
also see:
"ip_forward_directed_broadcasts" Determines whether to forward
broadcasts directed to a specific net or subnet, if directly connected
"ip_forward_src_routed" Determines whether to forward packets that are
source routed,(packets which have a specific machine listed as part of route)
3.12: How to Proxy Arp
Proxy ARPing involves one machine answering ARP requests for another
machine. This is most frequently done when a point-to-point interface
(ie PPP) is being used. For example, imagine the following setup:
ppp-machine psi
150.101.16.200---PPP LINK--ttya--150.101.16.28--le0--150.101.16.0 NETWORK
8:0:20:1:2:70 8:0:20:1:2:3
^^^ether NA
default route=psi
In this example systems on le0 network would have problems, because systems
on the le0 network and ppp link are not directly connected on the 150.101.16.0
network, 150.101.16.X will arp for 150.101.16.200 and not get a response.
Using psi to proxy arp on behalf of the ppp-machine will allow the packets
to be forwarded properly.
The following command, run on psi, would allow that machine to proxy
arp for ppp-machine:
# arp -s ppp-machine 8:0:20:1:2:3 pub
^^^ ^^^^^^^^^^^^
ppp client hostname psi servers ethernet mac address
Note that psi supplies its own ethernet address, not ppp-machine's.
This is because ARP should cause packets to go to psi, which is the
only machine which actually can pass on packets to ppp-machine.
(This command should also be put in the rc files if you wish it to be
permanent.)
Example:
Create an executable file called /etc/rc2.d/S99proxyarp. This should
have an arp entry for each of the clients , listing your server's
ethernet address:
#!/bin/sh
#
# S99proxyarp script to force ip forwarding
# and add published arp entries for point to point clients.
ndd -set /dev/ip ip_forwarding 1
arp -s ppp-pc1 8:0:20:1:2:3 pub
arp -s ppp-pc2 8:0:20:1:2:3 pub
make it executable:
# chmod +x /etc/rc2.d/S99proxyarp
3.13: How to Remove ARP Entries in Solaris?
You may determine that you need to remove arp entries. This could be
done if a machine has changed ether addresses, and you must have
access to it at once, or if a proxy arp has changed. You can delete a
single ARP entry with the following command:
# arp -d machine-name
a simple way to clear a machine's entire ARP cache without rebooting, deleting
entries manually or waiting for timeouts.
# ifconfig le0 <IP>;
The above command ( = ifconfig down; ifconfig up) will delete all entries
including static entries and published virtual interface entries.
See srdb 11416 for arp time-out info.
srdb 11416 what are the ARP values set by ndd?
|
|
免费注册
发表于 2002-06-18 12:14
发表于 2002-06-18 18:16
