[Top] [Table Of Contents] [Prev] [Next] [Index]

Solving Networking Problems        3


Use   Table 3-1       to identify diagnose common networking problems. For more in-depth discussion on troubleshooting routing protocols such as OSPF and BGP, see the PortMaster Routing Guide.  
Table 3-1 Common Networking Problems

Problem

Possible Cause

Solution

Unspecified problem on a local PortMaster seems to be network related.

See the following sections for preliminary diagnostics:

Unspecified problem on a remote PortMaster seems to be network related.

Faulty hardware or software.

No connectivity exists between the PortMaster and other nodes.

All hardware connections are correct, but the PortMaster still cannot communicate with other nodes.

The idle timer is not timing out connections.

RIP packets maintaining the link.

Verify IP traffic on the port with ptrace (page 3-14).

The Domain Name System (DNS) not functioning as expected.

Primary DNS server malfunction.

Use ptrace to verify which DNS is being accessed (page 3-15).

Packets are not reaching their destination.

A ping echo request reaches its destination, but the echo reply does not return.

The network can no longer access the Internet.

Routing has stopped.

Use the traceroute command to isolate the routing problem (page 3-19).

The traceroute command reaches its target but ping does not, or vice versa.

Note ¯ You can access the command line from a console terminal regardless of network condition.

Using Console Messages to Troubleshoot

To troubleshoot a PortMaster by checking console messages, you must connect to its console port in one of the following ways:

If you use this method, attach a terminal or workstation in terminal emulation mode for 9600 baud, 8 data bits, 1 stop bit, no parity, and software flow control (XON/XOFF) off. For more information, refer to the hardware installation guide that came with your PortMaster.
  1. Set DIP switch 1 on the back of the PortMaster to the up position.
DIP switch 1 is the leftmost switch. Refer to your hardware installation guide for detailed information about the PortMaster DIP switches.
  1. Turn the PortMaster off and on.

  2. Observe the diagnostic output.

Refer to the troubleshooting chapter of your hardware installation guide for more information on diagnostic boot messages.

Using Administrative Telnet Sessions

You can establish an administrative Telnet session to a remote PortMaster. The PortMaster supports up to four simultaneous administrative Telnet connections.

Establishing a Telnet Session

To establish an administrative Telnet session, telnet to your PortMaster and log in as !root with your administrative password. If you are using RADIUS, you can use an administrative user account. Refer to the RADIUS Administrator's Guide for more information.

If you have problems establishing a Telnet session, see "Troubleshooting the Session" on page 3-5.

Displaying Console Messages

Use the set console command to set the port used for an administrative Telnet session as the console port. This configuration allows you to display messages that are sent to the port on the console terminal or workstation. To release the Telnet port from console use, enter the reset console command. Lucent Remote Access recommends that you reset the console at the end of every Telnet session.

To display Telnet messages to the console, enter the following command:

Command> set console
Setting CONSOLE to admin session

When you are finished, enter the following command:

Command> reset console
Console RESET

Troubleshooting the Session

If you are having trouble establishing an administrative Telnet session, follow these steps on the PortMaster:

  1. Verify the TCP port used for Telnet access with the show global command.
See the PortMaster Command Line Reference for an explanation of command output.
 

Command> show global

System Name:

pm2e

Default Host:

192.168.1.70

Alternate Hosts:

 

IP Gateway:

192.168.96.2

Gateway Metric:

1

Default Routing:

Quiet (Off)

OSPF Priority:

0

OSPF Router ID:

192.168.96.6

Name Service:

DNS

Name Server:

192.168.1.70

Domain:

livingston.com

Telnet Access Port:

23

Loghost:

0.0.0.0

Maximum PMconsole:

10

Assigned Address:

192.168.93.200 (Pool Size 3)

RADIUS Server:

192.168.64.26

Alternate Server:

0.0.0.0

Accounting Server:

192.168.64.26

Alt. Acct. Server:

0.0.0.0

PPP Authentication:

PAP: on CHAP: off

Disabled Modules:

BGP

  1. Check for Telnet sessions by using the show netconns commandand looking for administrative connections to that port.
Use the following explanation of the output:
Command> show netconns

Hnd

Recv-Q

Send-Q

Local Address

Foreign Address

(state)

47

0

0

192.187.195.1.23

0.0.0.0.0

LISTEN

46

0

0

192.187.195.1.1041

192.187.195.2.53

UDP

37

0

2

192.187.195.1.23

128.165.32.27.32872

ESTABLISHED

11

0

0

192.187.195.1.1011

192.187.195.2.1642

ESTABLISHED

7

0

0

192.187.195.1.67

0.0.0.0.0

UDP

5

0

0

192.187.195.1.1643

0.0.0.0.0

LISTEN

4

0

0

192.187.195.1.161

0.0.0.0.0

UDP

1

24

0

192.187.195.1.520

192.187.195.0.520

UDP

The preceding show netconns output is from a PortMaster with an IP address of 192.187.195.1. The output shows an established state on the third line (shown in bold for this example).
The Local Address column shows the PortMaster address as 192.187.195.1.23-the .23 indicates the listening socket. Telnet listens on socket 23 by default. This output indicates that an active Telnet session exists between the PortMaster and a remote host.
For a list of services and their associated port numbers, see Table 3-2.
Services and Associated Port Numbers

Port Number

Service

23

telnet

53

Domain Name System (DNS)

67

BOOTP

161

SNMP

512

syslog

520

RIP

1642

pmd

1643

pmconsole, pmcommand, pminstall, PMVision, and other management applications

1645

RADIUS

1646

RADIUS accounting

1647

ChoiceNet

1649

Multichassis PPP

The remote host address (128.165.32.27.32872) is shown in the Foreign Address column. The number 32872 is a random number greater than 1023, which is used by most TCP client applications. The 128.165.32.27 is the IP address of the remote host calling the PortMaster.
The first column labeled Hnd is the network handle. A network handle is a number assigned to an active socket that can be used to close that socket manually, rather than by a request from the client. You can reset the Telnet session between the remote host and the PortMaster by entering the reset n37 command (37 is the network handle for the Telnet session).
  1. Reset any unused connections with the reset nHandle command.

    Command> reset n37

    Note ¯ Although you can have up to four concurrent Telnet sessions, you can have only one pmcommand, pmconsole, pminstall, or pmreadconf program running at one time with a given PortMaster unless you use the set maximum pmconsole Number command to increase the default to a number between 1 and 10.

Determining the ComOS Version

You often need to know the version of ComOS that is running on the PortMaster. For example, if the PortMaster is running an older version of ComOS, upgrading to the most current version might solve the problem. The version command also reports the system uptime since the last reboot.

Note ¯ You must know the ComOS version when contacting Lucent Remote Access Technical Support.

To determine the version of ComOS on your PortMaster, log in as !root and enter the following command:

Command> version
Livingston Enterprises PortMaster version 3.7
System uptime is 21 days 15 hours 24 minutes

Depending on the version of ComOS you are running, you might see this type of output instead:
Command> version
Livingston PortMaster PM-3 ComOS 3.8b2/9710211203
System uptime is 1 hours 20 minutes

The ComOS in the second example was built using version 3.8 as its base; the b2 indicates a beta release. A c would indicate a maintenance patch release. The date and time stamp after the version number indicates exactly when the version was released. In this example, the ComOS was released in 1997 (97) on October 21 (1021), at 12:03 p.m. (1203).

Verifying Network Connections

Use the ping command to verify connectivity between your PortMaster and devices on your network. The ping command sends an Internet Control Message Protocol (ICMP) echo request to the host specified and listens for the corresponding echo reply from the specified host. If a reply is received, connectivity between the PortMaster and the device is at least minimally sound.

If no reply is received, connectivity is failing somewhere on your network between the machine issuing the ping request and the specified device.

To ping a device on your network, use the following command:

Command> ping Ipaddress

To stop the ping process, enter the command with no IP address or hostname.

If you do not receive a response to the ping command, do the following:

If you see ARP requests as shown in this example, the Ethernet hardware is working, but you probably have a configuration or routing problem.

Using ifconfig

If you have verified that everything is connected properly, check the configuration of your PortMaster interfaces using the ifconfig command.

Verifying the PortMaster's Configuration

The ifconfig command allows you to view the active configuration of each network interface.

In the following example, ifconfig is used to verify the Ethernet parameters.

In ifconfig command output, netmasks are shown in hexadecimal format. Table 3-3 on page 3-11 shows equivalent dotted decimal and classless interdomain routing (CIDR) formats for netmasks.

Command> ifconfig
ether0: flags=16<IP_UP,IPX_DOWN,BROADCAST>
inet 192.168.1.2 netmask ffff0000 broadcast 192.168.0.0 mtu 1500

This example ifconfig command output displays the following information about the Ethernet interface:

To convert the netmask into dotted decimal format, refer to Table 3-3 on page 3-11. The hexadecimal ffff0000 is equivalent to 255.255.0.0 in dotted decimal format.
32-Bit Netmask Formats

Binary

Hex

CIDR

Dotted Decimal

00000000 00000000 00000000 00000000

0x00000000

/0

0.0.0.0

10000000 00000000 00000000 00000000

0x80000000

/1

128.0.0.0

11000000 00000000 00000000 00000000

0xC0000000

/2

192.0.0.0

11100000 00000000 00000000 00000000

0xE0000000

/3

224.0.0.0

11110000 00000000 00000000 00000000

0xF0000000

/4

240.0.0.0

11111000 00000000 00000000 00000000

0xF8000000

/5

248.0.0.0

11111100 00000000 00000000 00000000

0xFC000000

/6

252.0.0.0

11111110 00000000 00000000 00000000

0xFE000000

/7

254.0.0.0

11111111 00000000 00000000 00000000

0xFF000000

/8

255.0.0.0

11111111 10000000 00000000 00000000

0xFF800000

/9

255.128.0.0

11111111 11000000 00000000 00000000

0xFFC00000

/10

255.192.0.0

11111111 11100000 00000000 00000000

0xFFE00000

/11

255.224.0.0

11111111 11110000 00000000 00000000

0xFFF00000

/12

255.240.0.0

11111111 11111000 00000000 00000000

0xFFF80000

/13

255.248.0.0

11111111 11111100 00000000 00000000

0xFFFC0000

/14

255.252.0.0

11111111 11111110 00000000 00000000

0xFFFE0000

/15

255.254.0.0

11111111 11111111 00000000 00000000

0xFFFF0000

/16

255.255.0.0

11111111 11111111 10000000 00000000

0xFFFF8000

/17

255.255.128.0

11111111 11111111 11000000 00000000

0xFFFFC000

/18

255.255.192.0

11111111 11111111 11100000 00000000

0xFFFFE000

/19

255.255.224.0

11111111 11111111 11110000 00000000

0xFFFFF000

/20

255.255.240.0

11111111 11111111 11111000 00000000

0xFFFFF800

/21

255.255.248.0

11111111 11111111 11111100 00000000

0xFFFFFC00

/22

255.255.252.0

11111111 11111111 11111110 00000000

0xFFFFFE00

/23

255.255.254.0

11111111 11111111 11111111 00000000

0xFFFFFF00

/24

255.255.255.0

11111111 11111111 11111111 10000000

0xFFFFFF80

/25

255.255.255.128

11111111 11111111 11111111 11000000

0xFFFFFFC0

/26

255.255.255.192

11111111 11111111 11111111 11100000

0xFFFFFFE0

/27

255.255.255.224

11111111 11111111 11111111 11110000

0xFFFFFFF0

/28

255.255.255.240

11111111 11111111 11111111 11111000

0xFFFFFFF8

/29

255.255.255.248

11111111 11111111 11111111 11111100

0xFFFFFFFC

/30

255.255.255.252

11111111 11111111 11111111 11111110

0xFFFFFFFE

/31

255.255.255.254

11111111 11111111 11111111 11111111

0xFFFFFFFF

/32

255.255.255.255

Temporarily Changing the Configuration

You can use ifconfig to modify the active Ethernet interface, but the change is only temporary until the next reboot. Therefore, Lucent Remote Access recommends that you use the set commands followed by save all and reboot.

In the following example, the ifconfig command is used to change the address of the Ether0 port and the netmask. This approach is useful when you want to quickly (and temporarily) try out a different setting on an interface.

Command> ifconfig ether0 address 192.168.100.1 netmask 255.255.255.0
ether0: flags=16<IP_UP,IPX_DOWN,BROADCAST>
inet 192.168.100.1 netmask ffffff00 broadcast 192.168.100.0 mtu 1500

To change the configuration of the PortMaster on a more permanent basis use the following commands:

Command> set ether0 192.168.100.1
Command> set ether0 netmask 255.255.255.0
Command> save all
Command> reboot

Displaying Network Statistics

You can determine if your problems are caused by an overloaded network by using the show netstat command. See "Diagnosing an Overloaded Ethernet Network" on page 1-12 for more information.

Tracing Packets

The ptrace command allows you to see packet information as it passes through the PortMaster. It is often used in conjunction with ping to isolate a routing problem.

The ptrace command uses the name of a filter as its argument. The filter narrows the output to only those packets of interest. All packets passing through the PortMaster are evaluated against the selected filter, except for User Datagram Protocol (UDP) and ICMP packets that are generated by the PortMaster itself.

Packets that are permitted by the filter appear on the console with the following packet information:

Filtering Telnet Traffic for ptrace

The following is an example of a filter named all that denies all Telnet packets while allowing all other IP traffic for evaluation:

Command> add filter all
New filter successfully added

Command> set filter all 1 deny tcp src eq 23
Filter all updated

Command> set filter all 2 deny tcp dst eq 23
Filter all updated

Command> set filter all 3 permit
Filter all updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace all
Packet Tracing Enabled

TCP

from

128.165.96.6.1011

to

128.165.64.23.1642

seq 7F,

ack 0x0,

win 4096,

 

SYN

TCP

from

128.165.64.23.1642

to

128.165.96.6.1011

seq 0,

ack 0x80,

win 0,

RST

ACK

UDP

from

128.165.96.229.1649

to

128.165.96.0.1649

 

 

 

 

 

UDP

from

128.165.96.16.520

to

128.165.96.0.520

 

 

 

 

 

UDP

from

128.165.96.135.520

to

128.165.96.0.520

 

 

 

 

 

UDP

from

128.165.96.2.520

to

128.165.96.0.520

 

 

 

 

 

UDP

from

128.165.96.2.520

to

128.165.96.0.520

 

 

 

 

 

TCP

from

128.165.96.6.1011

to

128.165.93.2.1642

seq 7F,

ack 0x0,

win 4096,

SYN

 

TCP

from

128.165.1.93.1642

to

128.165.96.6.1011

seq 0,

ack 0x80,

win 0,

RST

ACK

UDP

from

128.165.96.76.520

to

128.165.96.0.520

 

 

 

 

 

Command> ptrace

Tracing IP Packets

The following example uses a filter named i that shows all packets arriving at or passing through the PortMaster. Using this filter with the ptrace command helps to determine why the idle timer is not timing out a connection. RIP packets (UDP/520) are considered idle traffic and do not maintain a link that is configured to drop due to lack of traffic.

Command> add filter i
New Filter successfully added

Command> set filter i 1 permit
Filter i updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace i
Packet Tracing Enabled

Note ¯ Do not use this filter if you are telneted into a PortMaster. See "Filtering Telnet Traffic for ptrace" on page 3-13 for more information.

Tracing DNS Packets

This packet filter shows all Domain Name System (DNS) packets arriving at or passing through the PortMaster. This tool is useful in debugging DNS problems because it shows a user's or host's DNS queries destined for the DNS server and the IP address of the DNS server being accessed. A secondary DNS server that is being accessed too often might indicate that the primary DNS server is having problems.

The PortMaster uses DNS to translate IP addresses into hostnames and for administrative programs like telnet, rlogin, ping, and traceroute. DNS runs on UDP port 53 for DNS queries and responses. DNS zone transfers run on TCP port 53.

Command> add filter dns
New Filter successfully added

Command> set filter dns 1 permit udp src eq 53
Filter dns updated

Command> set filter dns 2 permit udp dst eq 53
Filter dns updated

Command> set filter dns 3 permit tcp src eq 53
Filter dns updated

Command> set filter dns 4 permit tcp dst eq 53
Filter dns updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace dns
Packet Tracing Enabled

UDP from 192.168.1.2.53 to 192.168.1.3.1025
UDP from 192.168.1.2.53 to 192.168.1.3.1025
UDP from 192.168.1.2.53 to 192.168.1.154.1238
UDP from 10.41.69.222.1330 to 192.168.1.2.53
UDP from 192.168.1.2.53 to 10.41.69.222.1330
UDP from 192.168.1.137.1097 to 192.168.1.2.53
UDP from 192.168.1.2.53 to 204.192.168.1.137.1097
UDP from 192.168.1.137.1102 to 192.168.1.2.53
UDP from 192.168.1.2.53 to 192.168.1.137.110

Command> ptrace

Tracing IPX Packets

This packet filter shows all IPX packets passing through the PortMaster. It does not show IPX packets originating from the PortMaster.

Command> add filter seeipx
New Filter successfully added

Command> set ipxfilter seeipx 1 permit
Filter seeipx updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace seeipx
Packet Tracing Enabled

IPX from 00000008:0000C06F195C:0455 to 00000008: FFFFFFFFFFFF:0455
IPX from 00000008:0000C06F195C:0553 to 00000008: FFFFFFFFFFFF:0553
IPX from 00000008:0000C06F195C:0455 to 00000008: FFFFFFFFFFFF:0455
IPX from 00000008:0000C06F195C:0553 to 00000008: FFFFFFFFFFFF:0553

Command> ptrace

IPX packets are represented in the following format. All Fs in a "to" address represent a broadcast to the entire network.

[8-digit network number]:[12-digit node address]:[4-digit socket number]

Tracing TCP Packets

This packet filter shows all TCP packets arriving at or passing through the PortMaster. TCP packets are used by applications such as HTTP (World Wide Web), FTP, Telnet and many others.

  1. Create a filter called ctcp:

    Command> add filter ctcp
    New Filter successfully added

    Command> set filter ctcp 1 permit tcp
    Filter ctcp updated

  2. If you want to see only packets from TCP negotiations, add the estab keyword:

    Command> set filter ctcp 1 deny tcp estab
    Filter ctcp updated

    Command> set filter ctcp 2 permit tcp
    Filter ctcp updated

  3. Set the console and issue the ptrace command:

    Command> set console
    Setting CONSOLE to admin session

    Command> ptrace ctcp
    Packet Tracing Enabled

    If you are telneting into the PortMaster, see "Filtering Telnet Traffic for ptrace" on page 3-13

Tracing UDP Packets

This packet filter shows all UDP packets arriving at or passing through the PortMaster. UDP packets are used by applications such as DNS, RADIUS, finger, whois, and traceroute.

Command> add filter cudp
New Filter successfully added

Command> set filter cudp 1 permit udp
Filter cudp updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace cudp
Packet Tracing Enabled

UDP from 128.165.96.16.520 to 128.165.96.0.520
UDP from 128.165.96.229.1649 to 128.165.96.0.1649
UDP from 128.165.96.135.520 to 128.165.96.0.520
UDP from 128.165.96.2.520 to 128.165.96.0.520
UDP from 128.165.96.2.520 to 128.165.96.0.520
UDP from 128.165.96.76.520 to 128.165.96.0.520
UDP from 128.165.96.16.520 to 128.165.96.0.520
UDP from 128.165.96.229.1649 to 128.165.96.0.1649

Command> ptrace

Tracing Ping Packets

This packet filter shows all pings arriving at or passing through the PortMaster. This tool is useful in debugging routing problems because a ping echo request often arrives at the destination host but the echo reply cannot return. Using this packet trace filter at different points along the path can help diagnose the problem.

Command> add filter p
New Filter successfully added

Command> set filter p 1 permit icmp
Filter p updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace p
Packet Tracing Enabled

Command> ptrace

The following example shows ptrace output of pings arriving at the PortMaster. (The PortMaster in this example has an IP address of 10.0.0.3.)

icmp from 192.168.148.1 to 10.0.0.3 type Echo Request
icmp from 192.168.148.1 to 10.0.0.3 type Echo Request
icmp from 192.168.148.1 to 10.0.0.3 type Echo Request

The following example shows ptrace output of pings passing through the PortMaster:

icmp from 192.168.148.1 to 10.0.0.15 type Echo Request
icmp from 10.0.0.15 to 192.168.148.1 type Echo Reply

Tracing RIP Packets

This packet filter shows all RIP packets arriving at the PortMaster.

RIP uses UDP port 520 to transmit routing information between hosts. UDP is one of the protocols the PortMaster uses to learn dynamic routing information and is useful in debugging routing problems. A host broadcasting RIP broadcasts its routing table at least once every 30 seconds.

For example, the following filter shows RIP packets being advertised by other routers or workstations:

Command> add filter rip
New Filter successfully added

Command> set filter rip 1 permit udp src eq 520
Filter rip updated

Command> set console
Setting CONSOLE to admin session

Command> ptrace rip
Packet Tracing Enabled

UDP from 192.168.1.5.520 to 192.168.1.255.520
UDP from 192.168.1.6.520 to 192.168.1.0.520
UDP from 192.168.1.6.520 to 192.168.1.0.520
UDP from 192.168.1.6.520 to 192.168.1.0.520
UDP from 192.168.1.13.520 to 255.255.255.255.520
UDP from 192.168.1.1.520 to 255.255.255.255.520
UDP from 192.168.1.8.520 to 192.168.1.0.520
UDP from 192.168.1.6.520 to 192.168.1.0.520
UDP from 192.168.1.13.520 to 255.255.255.255.520

Command> ptrace

Troubleshooting Routing

The following sections explain how to locate an incorrect static route and how to use the traceroute command to diagnose routing problems. For more detailed information on how to troubleshoot particular routing protocols such as BGP, OSPF or RIP, see the PortMaster Routing Guide.

Locating an Incorrect Static Route

If packets are not reaching their destination, an incorrect static route might be the cause. Examine the IP routing table with the show routes command. (In the following example, the optional keyword local limits the output to those routes that match the string local.)

Command> show routes local

 

 

 

 

Destination

Mask

Gateway

Source

Flag

Met

Interface

------------

-----

--------------

-------

-----

----

----------

0.0.0.0

0

192.168.96.2

local

NS

1

ether0

192.168.96.0

24

192.168.96.225

local

NL

1

ether0

10.2.5.0

24

192.168.96.2

local

NS

1

ether0

Specifying an IP address and netmask displays routes only to that destination:

 

Command> show routes 192.168.1.0/24

 

 

 

 

Destination

Mask

Gateway

Source

Flag

Met

Interface

-----------

-----

--------------

-------

-----

----

----------

192.168.1.0

24

192.168.2.31

rip

ND

2

ether0

The show routes command output helps to verify that no static route exists for your local IP Ethernet network. A static route appears with the flag NS; a normal entry for the Ethernet network displays the NL flag and ether0 as the interface. A static route overrides the default route and interferes with normal Ethernet routing.

To remove the route, use the following command. Replace the IP address with your IP network address-the destination shown in the routing table:

Command> delete route 192.168.7.0

If you are using the OSPF or BGP routing protocol, refer to the PortMaster Routing Guide for more troubleshooting information.

Note ¯ If some types of packets reach their destination but others do not, a routing problem is not the cause. For example, if small packets reach their destination, but big packets do not, this behavior indicates a problem in Layer 1 or 2 of the Open Systems Interconnection (OSI) model.

Tracing a Route

Traceroute is a useful tool for debugging routing problems. You can use it to identify the routers used to reach a remote host. While ping checks only end-to-end connectivity, traceroute tries to characterize each hop in the path to a destination. The traceroute command sends UDP packets to the specified host and listens for ICMP messages returning. When you enter the hostname or IP address of the destination host with the traceroute command, a list of router addresses is displayed in the order they are encountered.

If a routing problem exists, packets often get to their destination but do not return. If you can determine via ptrace (see page 3-12) that packets are arriving at their destination, you can use traceroute from that destination back to the first router and see where the routes go off course.

To trace the route to a remote host, use the following command:

Command> traceroute Ipaddress

To stop traceroute, enter the command with no IP address:

Command> traceroute

If routing has stopped and a network can no longer connect to the Internet, do the following:

  1. Use the traceroute command from the isolated LAN to the router to display the last IP address seen.

  2. Use the traceroute command from the router to the isolated LAN and note the last IP address.

    The routing problem is usually located between the LAN and that address.
    Command> traceroute 172.16.1.2
    traceroute to (172.16.1.2), 30 hops max
    1 192.168.96.2
    2 192.168.1.3
    3 172.16.1.2

    The traceroute command sends UDP packets until it gets an ICMP packet back from the specified IP address or host.

  3. If the destination is unreachable, terminate traceroute manually by entering the command without an IP address.

    The traceroute command shows IP addresses only (not hostnames) and does not show the times associated with each hop.

    For more information on the traceroute command, see the PortMaster Command Line Reference.

Finding a Particular Route

If traceroute reaches its target and ping does not-or vice versa-check routing with the show routes to-dest command to determine if the two addresses are being routed differently. This is a common routing problem over Frame Relay connections.

The show routes to-dest command displays detailed information about which route in the routing table the PortMaster uses to send a packet to a particular destination. Contrast this command with the show routes command, which lists the PortMaster's entire routing table. Using show routes to-dest allows you to find a particular route without having to search the whole routing table manually.

The following is sample output from the show routes command:

Command> show routes

Destination Mask Gateway Source Flag Met Interface
----------------- ---- -------------------- ------- ---- --- --------
0.0.0.0 0 128.198.110.2 local NS 1 ether0
128.165.110.64 27 128.165.110.4 rip ND 2 ether0
128.165.0.0 27 128.165.110.9 rip ND 3 ether0
128.165.110.0 27 128.165.110.3 local ND 1 ether0
192.168.32.0 24 128.165.110.9 rip ND 2 ether0
10.0.0.0 8 128.165.110.9 rip ND 3 ether0

To find the particular route in the routing table that will forward an IP packet with a destination address of 128.165.110.68, use the show routes to-dest command as follows:

Command> show routes to-dest 128.165.110.68
Destination Mask Gateway Source Flag Met Interface
----------------- ---- -------------------- ------- ---- --- ---------
128.165.110.64 27 128.165.110.4 rip ND 2 ether0

The route 128.165.110.64 is a network route with a 27-bit subnet mask. The route will deliver IP packets to any of the IP addresses between 128.165.110.65 and 128.165.110.94 (128.165.110.64 is the network address and 128.165.110.95 is the broadcast address). The PortMaster displays this route because 128.165.110.68 is a member of this subnet.

If the destination you specify is not in the routing table and a default route exists, the PortMaster uses the default route to forward the packet:

Command> show routes to-dest 192.168.10.2

Destination Mask Gateway Source Flag Met Interface
----------------- ---- -------------------- ------- ---- --- --------
0.0.0.0 0 128.165.110.2 local NS 1 ether0

If the destination you specify is not in the routing table and no default route exists, the command output is the following:

Command> show routes to-dest 1.1.1.1

Destination Mask Gateway Source Flag Met Interface
----------------- ---- -------------------- ------- ---- --- ---------

Command>



[Top] [Table Of Contents] [Prev] [Next] [Index]

spider@livingston.com
Copyright © 1998, Lucent Technologies. All rights reserved.