U
TILITIES
6-6
6.8 F
AULTFINDING
TCP/IP N
ETWORKS
To confirm that basic operation is correct, make a manual call and attempt
to connect to a remote host. If this fails, then there is a general network
problem, as at this stage the two networks are transparently joined together.
The faultfinding process in a TCP/IP network is made easier by the fact that
most TCP/IP terminal devices (hosts) contain a ‘ping’ facility. This utility
sends an ‘echo request’ packet to the named device, which should then
respond with an ‘echo reply’. By using this facility, it is possible to find
faults in a network connection in logical stages.
The first step is to ‘ping’ the local bridge by typically typing PING [target
IP address]. If the connection is working, then a positive response should
be received. It is often possible to ping a device continuously by adding a
modifier to the PING command (e.g. -t). Consult your TCP/IP supplier’s
documentation for the command syntax. If this test fails, then there is a
problem with the local network connection to the bridge.
The next step would be to check that other devices on the local network can
be pinged, to make sure that the terminal device is functioning correctly. To
check if the bridge has received any packets from the terminal device, the
ARP list can be viewed by typing STAT TCP ARP. This list is the
mapping of IP addresses to physical Ethernet MAC addresses that the
bridge has learned on the local network. The local terminal first sends an
ARP request to the bridge to find out the MAC address of the bridge, so that
frames can be sent to it. If the bridge has either received an ARP request, or
received a response to an ARP request from the terminal device, the IP and
MAC addresses will be in this table.
The next step after confirming that the local bridge can be contacted is to
ping the remote bridge. If this test fails, check that the two bridge units can
communicate by using the REM command from the local bridge to the
remote unit: see the R
EFERENCE
chapter of this manual for further details.
Problems in this area are often caused by: the link not being set up due to
ISDN call establishment problems; incorrect autocall configuration (to view
the autocalls, type CO ISDN AUTO); network numbers different at both
ends of the link with no default router; the network connection is excluded
by type or address filtering, etc.
Содержание Marlin
Страница 1: ...ISSUE 3 0 MAN ML BRIDGE REF MARLIN BRIDGE REFERENCE MANUAL Issue 3 0 ...
Страница 3: ...ISSUE 3 0 MAN ML BRIDGE REF 1996 Scorpion Logic Ltd A Bay Networks company ...
Страница 13: ...CONTENTS Issue 3 0 ...
Страница 21: ...OVERVIEW 1 8 ...
Страница 24: ...TUTORIAL 2 3 physically close then a local bridge can be used otherwise a remote bridge is used ...
Страница 30: ...TUTORIAL 2 9 Figure 2 4 Multiple Remote Bridges ...
Страница 38: ...TUTORIAL 2 17 In any case STA resolves the paths to allow the network to operate satisfactorily ...
Страница 46: ...TUTORIAL 2 25 ...
Страница 74: ...NETWORKING EXAMPLES 3 28 ...
Страница 105: ...REFERENCE 5 12 TIME SINCE REBOOT This is the time in hours mins secs since the Marlin Bridge was last rebooted ...