The Routing and Remote Access service is one of the
more complex components in Windows Server 2003. Because RRAS can perform
so many functions, it has a large number of configurable settings. Even
a minor misconfiguration can prevent the server from routing traffic
properly. The TCP/IP implementation in Windows Server 2003 includes a
variety of tools that you can use to troubleshoot RRAS and its various
functions.
Isolating Router Problems
In most cases,
administrators discover router problems when communications fail between
computers on the network. However, once the troubleshooter suspects
that there might be a routing problem, the next step is to determine
which router is malfunctioning. Some of the TCP/IP tools in the Windows
operating system that can help you in this respect are discussed in the
following sections.
Using Ping.exe
PING is the
standard TCP/IP tool for testing connectivity; virtually every TCP/IP
client includes a PING implementation. In the Windows operating systems,
PING takes the form of a command line program called Ping.exe. By
typing ping followed by an IP address on the command line, you can test any TCP/IP system’s connectivity with any other system.
Note
PING
functions by transmitting a series of Echo Request messages containing a
sample of random data to the destination you specify, using the
Internet Control Message Protocol (ICMP). The system that receives the
Echo Request messages is required to generate an Echo Reply message for
each request that contains the same data sample and return the messages
to the sender. |
Compared to other tools,
PING has limited utility when you are trying to locate a malfunctioning
router. You might be able to ping a router’s IP address successfully
even when it is not routing traffic properly. However, as part of your
initial troubleshooting efforts, you can use PING to test a routed
network connection in the following manner:
Ping the computer’s loopback address (127.0.0.1) to confirm that the TCP/IP client is installed and functioning.
If
this test fails, there is a problem with the TCP/IP installation on the
computer, with the network interface adapter, or with the network
adapter driver. The problem is not caused by network cables or other
external hardware, because messages addressed to the loopback address
never leave the system.
Ping the computer’s own IP address to confirm that the routing table contains the appropriate entries.
A
properly configured routing table contains an entry with the computer’s
own IP address as the network destination and the loopback address as
the gateway the system should use to reach that destination. If this
test fails (after you have successfully pinged the loopback address),
this entry in the routing table is missing or incorrect. You should
check the routing table carefully at this point, because other important
entries might also be missing or incorrect.
Ping the IP address of another computer on the same LAN.
This
test confirms that the computer is not being prevented from accessing
the network by problems with TCP/IP configuration or network hardware.
If this test fails, you should check that the computer has a correct IP
address and subnet mask, and that the computer’s physical connection to
the network is intact.
Ping the DNS name of another computer on the same LAN.
If
this test fails, and you are able to successfully ping the IP address
of the same computer, there is a name resolution problem. Check the
computer’s DNS server address and that the DNS server is functioning
properly.
Ping the computer’s designated default gateway address.
Successfully
pinging the default gateway does not confirm that the gateway is
routing packets as it should, but it does verify that gateway system is
up and running, and that its TCP/IP client is properly configured. If
this test fails (after you have successfully completed all the previous
tests), you should examine the router functioning as the default gateway
for TCP/IP configuration or network hardware problems.
Ping several computers on another network that are accessible through the default gateway.
If
this test fails (and the previous test succeeded), then you know that
although the default gateway is up and running, it might not be routing
packets properly. A failure to ping a single computer on another network
could indicate that the destination system is not running, but if you
cannot ping several systems on another network, it is likely that there
is a routing problem.
Tip
For
best results, you should try to ping systems on a network to which the
default gateway is directly connected. This way, you know that if the
test fails, the default gateway is the problem. If the packets are
passing through two or more routers to get to their destinations, any
one of the routers could be at fault, and you must use another tool
(such as Tracert.exe or Pathping.exe) to determine which router is
malfunctioning. |
Using Tracert.exe
Tracert.exe is
the Windows operating system’s implementation of the UNIX traceroute
program. TRACERT enables you to view the path that packets take from a
computer to a specific destination. When you type tracert
and an IP address at the Windows command prompt, the program displays a
list of the hops to the destination, including the IP address and DNS
name (where available) of each router along the way, as follows:
Tracing route to www.adatum.co.uk [10.146.1.1]
over a maximum of 30 hops:
1 <10 ms 1 ms <10 ms 192.168.2.99
2 105 ms 92 ms 98 ms qrvl-67terminal01.epoch.net [172.24.67.3]
3 101 ms 110 ms 98 ms qrvl.epoch.net [172.24.67.1]
4 123 ms 109 ms 118 ms svcr03-7b.epoch.net [172.24.103.125]
5 123 ms 112 ms 114 ms clsm02-2.epoch.net [172.24.88.26]
6 136 ms 130 ms 133 ms sl-0-T3.sprintlink.net [10.228.116.5]
7 143 ms 126 ms 138 ms sl-3.sprintlink.net [192.168.5.117]
8 146 ms 129 ms 133 ms sl-12-0.sprintlink.net [192.168.5.1]
9 131 ms 128 ms 139 ms sl-13-0.sprintlink.net [192.168.18.38]
10 130 ms 134 ms 134 ms sl-8-0.sprintlink.net [192.168.7.94]
11 147 ms 149 ms 152 ms sl-0.sprintlink.net [192.168.173.10]
12 154 ms 146 ms 145 ms ny2-ge021.router.demon.net [172.21.173.121]
13 230 ms 225 ms 226 ms tele-ge023.router.demon.net [172.21.173.12]
14 233 ms 220 ms 226 ms tele-fxp1.router.demon.net [10.159.252.56]
15 223 ms 224 ms 224 ms tele-14.router.demon.net [10.159.254.245]
16 236 ms 221 ms 226 ms tele-165.router.demon.net [10.159.36.149]
17 220 ms 224 ms 210 ms www.adatum.co.uk [10.146.1.1]
Trace complete.
Tracert.exe is an
excellent tool for locating a malfunctioning router, because it is able
to inform you how far packets have gotten on the way to their
destination. When one of the routers on the path is not forwarding
packets properly, the TRACERT output stops at the last functioning
router. You know then that the next router on the path is the one
experiencing the problem.
|
Tracert.exe
works by sending ICMP Echo Request messages to the destination, much as
PING does, but with a special difference. For the first group of three
Echo Request messages, TRACERT assigns a value of 1 to the IP header’s
Time to Live (TTL) field. The TTL field is a safety measure designed to
prevent packets from circulating endlessly around an internetwork.
Normally, computers running Windows operating systems assign a value of
128 to the TTL field. When a router processes a packet, it reduces the
TTL value by 1; if the TTL value reaches 0, the router discards the
packet and returns an error message to the system that transmitted it.
Because the first
three TRACERT packets have a TTL value of 1, when they reach the first
router on their path, the router reduces their TTL values to 0 and
discards them, sending error messages back to the sender. Then, for each
successive group of three Echo Request messages, TRACERT increments the
initial TTL value by 1, causing each group of packets to travel one
more hop on the way to the destination before the router discards them.
The TRACERT program uses the error messages generated by the routers
(which contain the routers’ IP addresses) to create the output display.
|
Tip
It
is important to understand that routes through a large internetwork can
change frequently, for a variety of reasons, and packets can take
different paths to the same destination. Therefore, when you use
TRACERT, it is possible (although not probable) for the path through the
internetwork taken by successive sets of Echo Request messages to be
different. When you are using TRACERT to locate a malfunctioning router,
you should run the program at least twice, using the same destination,
to ensure that you are seeing an accurate path through the network. |
Using Pathping.exe
Pathping.exe is
another tool available from the Windows command prompt that is similar
to Tracert.exe in that it traces a path through the network to a
particular destination and displays the names and addresses of the
routers along the path. PATHPING is different, however, because it
reports packet loss rates at each of the routers on the path. TRACERT is
the preferred tool for locating a router failure that completely
interrupts communications, while PATHPING is more useful when you can
connect to a destination, but you are experiencing data loss or
transmission delays.
After
displaying the path to the destination, PATHPING sends 100 packets (by
default) to each of the routers on the path and computes the packet loss
rate in the form of a percentage. A typical PATHPING output display
appears as follows:
Computing statistics for 125 seconds. . .
Source to Here This Node/Link
Hop RTT Lost/Sent=Pct Lost/Sent = Pct Address
0 172.16.87.35
0/ 100 = 0% |
1 41ms 0/ 100 = 0% 0/ 100 = 0% 172.16.87.218
13/ 100 = 13% |
2 22ms 16/ 100 = 16% 3/ 100 = 3% 192.68.52.1
0/ 100 = 0% |
3 24ms 13/ 100 = 13% 0/ 100 = 0% 192.68.80.1
0/ 100 = 0% |
4 21ms 14/ 100 = 14% 1/ 100 = 1% 192.168.247.14
0/ 100 = 0% |
5 24ms 13/ 100 = 13% 0/ 100 = 0% 192.168.54.76
Trace complete.
Troubleshooting the Routing and Remote Access Configuration
The most common symptom
of trouble for an RRAS router is simply that the server is not routing
traffic. However, although the symptom might be simple, the cause might
not be. To begin troubleshooting, it is best to start with the most
obvious possible causes, such as the following:
Verify that the Routing and Remote Access service is running
Display the Services tool on the Administrative Tools menu to verify
that the status of the Routing and Remote Access service is Started. In
most cases, you should set the Startup Type selector to Automatic. If
the service had been running and has now stopped for no apparent reason,
check the Event Viewer console for error messages related to the
stoppage.
Verify that routing is enabled
In the Routing And Remote Access console, display the Properties dialog
box for your server and, in the General tab, make sure that the Router
check box and the appropriate routing option for your network (Local
Area Network (LAN) Routing Only or LAN And Demand-Dial Routing) are
selected. If your router is also functioning as a remote access server,
you should select that check box as well. If RRAS is not configured with
the correct options, you should check the other configuration
parameters or disable the Routing and Remote Access service completely
and reconfigure it from scratch.
Check the TCP/IP configuration settings Just
like any other TCP/IP computer, a router must have the proper TCP/IP
configuration settings in order to function properly. Make sure that
you’ve configured all the router’s interfaces with the correct IP
addresses, subnet masks, and other settings.
Check the IP addresses of the router interfaces
When you use the Routing And Remote Access Server Setup Wizard to
configure RRAS to function as a router, the wizard creates interfaces in
the router configuration using the computer’s current interface
settings. If you change the interface settings, such as the IP address
or subnet mask, you must change the corresponding setting in the RRAS
interface as well. In the Routing And Remote Services console, display
the Properties dialog boxes for the interfaces listed in the IP
Routing’s General subheading and check to see that their IP addresses
and subnet masks match the actual interface addresses, and that the
interfaces show Operational status.
Troubleshooting the Routing Table
If you have
configured RRAS correctly, and you are still experiencing routing
problems, another cause could be that the routing table does not contain
the information needed to route network traffic properly. The cause of
this problem depends largely on whether you use static routing or
dynamic routing. If you use static routing, someone might have deleted,
omitted, or mistyped important routing table entries. If you use dynamic
routing, your routing protocol might not be functioning properly.
Troubleshooting Static Routing
Because static routing
requires human beings to create all the specialized entries in a
routing table, the only possible source of problems in the routing table
(excluding hardware failures) is human error. If you have created your
static routes in the Routing And Remote Access console, you can view and
modify them there by selecting the IP Routing’s Static Routes
subheading in the console tree (see Figure 1). Note, however, that doing this displays only the static routes you have created in the Routing And Remote Access console.
Important
If
someone has created static routes using the Route.exe command line
utility, these routes do not appear in the Routing And Remote Access
console’s Static Routes display, nor do the default entries in the
routing table appear. The only way to modify or delete routing table
entries created with Route.exe is to use Route.exe. |
To
display the entire routing table for the computer using the Routing And
Remote Access console, click the Static Routes subheading and, on the
Action menu, click Show IP Routing Table, to produce a display like the
one in Figure 2. You cannot modify the routing table in this display, however, just view it.
The Route.exe command
line utility enables you to view, add, modify, or delete any entries in
the computer’s routing table, regardless of how you created them.
Tip
Although
it might take you a bit of time to get used to its command line syntax,
Route.exe is a much better tool for creating static routes than the
Routing And Remote Access console. For example, if you try to create a
routing table entry with a gateway address that does not exist on one of
the router’s connected networks, Route.exe refuses to create the entry
and displays an error message. The Static Route dialog box in the
Routing And Remote Access console allows you to create this incorrect
table entry without complaining. |
Troubleshooting Routing Protocols
If
you use dynamic routing, the lack of the proper entries in a router’s
routing table is the result of the routing protocol failing to put them
there. Assuming that no network communications problem is preventing the
routers from exchanging messages, it is likely that the routing
protocol on one or more of the routers is not configured properly. To
verify the functionality of the routing protocol, use the following
procedures:
1. | Verify that the routing protocol is installed on all the participating routers.
On an RRAS router, you must install the routing protocol
manually after you configure the Routing and Remote Access service.
Other operating systems and standalone routers might have their own
procedures for installing or enabling the routing protocol. Make sure
that all the routers on the network are configured to use the same
routing protocol, and that the protocol implementations are compatible.
|
2. | Verify that the routing protocol is configured to use the correct interfaces.
After you install RIP or OSPF on an RRAS router, you must
specify the interfaces over which you want the protocol to transmit its
messages. To do this, you click the routing protocol icon in the console
tree and, on the Action menu, click New Interface. In the New Interface
dialog box, you select the interface in the computer that provides
access to the network where the other routers are located. If other
routers are located on both networks to which the Routing and Remote
Access server is connected, you should perform this procedure twice, to
install both interfaces.
|
Once you have
ascertained that RRAS has the routing protocol installed and the
interfaces selected, you can begin checking elements specific to the
individual routing protocol, as described in the following sections.
Troubleshooting RIP
To determine whether RIP is functioning properly, you can select the RIP subheading in the console tree, as shown in Figure 3.
The
details pane shows the number of RIP packets transmitted and received
by the router. If RRAS is not sending or receiving RIP messages (or
both), you should check the RIP configuration settings, as described in
the following procedures:
1. | Verify that all the RIP routers are using the same message types.
The RIP implementation in Windows Server 2003 supports version 2
of the protocol, but you can configure RIP on each interface to
transmit its messages as either version 1 or version 2 broadcasts, or
version 2 multicasts. By default, RRAS uses RIP version 2, but you may
have to modify these settings so that the router functions with other
RIP implementations on your network. Be sure to check every RIP router
on your network to see which version of the protocol it uses, and then
modify your RRAS configuration accordingly.
Tip When
configuring the RIP version properties, remember that you must
configure ingoing traffic, outgoing traffic, and each interface
separately. |
|
2. | Check RIP security properties.
In the Security tab in each RIP interface’s Properties dialog
box, you can specify the address ranges of routes that you want RIP to
accept from other routers. By default, RRAS RIP accepts all incoming
routes, but if new entries are not appearing in the computer’s routing
table, check to make sure that no one has changed the security settings
inappropriately.
|
3. | Check the RIP timing interval settings.
By default, the RRAS RIP implementation transmits update
messages every 30 seconds, and RRAS removes RIP entries from the routing
table if they are not refreshed at least every 20 minutes (1200
seconds). If you decide to modify these defaults (as a bandwidth
conservation measure), make sure that the Periodic Announcement Interval
value is lower than the Time Before Route Is Removed setting.
Otherwise, RRAS will remove entries from the table before they have a
chance to be refreshed.
|
Tip
If
you change the RIP timing interval settings on one router, you should
change them on all the other RIP routers in the same way. |
Troubleshooting OSPF
As
with RIP, when you click the OSPF subheading in the Routing And Remote
Access console tree, the details pane shows the number of OSPF packets
the router has sent and received, so you can tell if the protocol is
functioning. If the router is not sending or receiving OSPF packets, the
first thing to check is whether OSPF is enabled on each of the
interfaces you installed. Display the Properties dialog box for each
interface and check to see that the Enable OSPF For This Address option
button is selected.
If OSPF is enabled
on the interfaces and your routers are still not communicating, it is
time to check whether each router is configured in accordance with your
OSPF deployment plan. Unlike RIP, which requires little or no
configuration, an OSPF deployment requires you to make decisions such as
how many areas you want to create, and which routers will handle the
communication between areas by functioning as area border routers. Make
sure that you have configured each OSPF router on the network to perform
its designated roles.
