This chapter focuses on a series of common symptoms associated with routing and bridging in IBM-based networks, possible causes of those symptoms, and general suggestions for identifying, isolating, and resolving those causes. The emphasis here is on symptoms and problems associated with IBM network connectivity.
This chapter consists of the following sections:
- IBM connectivity symptom list
- Symptom/cause/action modules
The symptom/cause/action modules consist of the following sections:
- Symptom statement--A specific symptom associated with the technology/media/protocol in which this module appears
- Possible causes and suggested actions-- A table for each symptom containing possible causes for the symptom and suggested actions for resolving each cause.
Note This chapter focuses on IBM-related and Token Ring problems. General diagnostic tools and techniques used for isolating serial line problems are discussed in Chapter 7, "Troubleshooting WAN Connectivity."
When troubleshooting connectivity problems in IBM internets, there are a variety of tools and techniques that you can apply to isolate the causes of interruptions.
The following tools are universally applicable when gathering information to troubleshoot IBM internetworking links:
- Output of relevant show commands. Some of these include show rif, show arp, show source-bridge, show controller token, show interface token, show version, show tcp, show flash (useful only if the Flash Memory card is installed in your system), show lnm bridge, show lnm config, show lnm interface, and show netbios-cache.
- Output of relevant debug commands. Some useful debug commands include debug rif, debug source-bridge, debug source-event, debug lnm-events, debug lnm-llc, debug lnm-mac, and debug netbios-name-cache.
 | Caution Throughout this and other chapters, the use of debug commands is suggested for obtaining information about network traffic and router status. Use these commands with great care. In general, it is recommended that these commands only be used under the direction of your router technical support representative when troubleshooting specific problems. Enabling debugging can disrupt operation of the router when internets are experiencing high load conditions. Avoid using debug commands in production networks. When you finish using a debug command, remember to disable it with its specific undebug command or with the undebug all command. |
- Output of write terminal or show configuration screens to evaluate operational configuration.
- Output of network analyzer (attached to end-station token ring) trace. In the scenarios that appear in this manual, output is from a Network General Sniffer, but this suggests no endorsement of a particular product. This output is for illustrative purposes only.
The symptom modules that follow pertain to IBM internetworking problems. Unless otherwise indicated, each module is presented as a set of general problems. Where there are special considerations associated with a specific network type, notes are included.
IBM networking connectivity symptoms discussed in this section include the following:
- Routing does not function in SRB environment
- Routing in SRB network fails unexpectedly
- No communication over router configured as an SRB
- Blocked communication over router configured for remote SRB
- Intermittent communication failures over router configured for remote SRB
- Users cannot communicate over router when attempting translational bridging
- Traffic not transiting through router implementing SRT
- Users cannot establish connections over router running SDLLC
- Intermittent connectivity over router running SDLC
- Router is unable to connect to Token Ring
- Router is not communicating with IBM SDLC devices over RS-232
- SDLC sessions fail over router running STUN
- NetBIOS devices cannot communicate over remote SRB
- Router cannot be linked from LAN Network Manager
Symptom: In some cases, you may need to route certain protocols (for example, Novell IPX) through internetworks that are dominated by source route bridge (SRB) links. It is not unusual to find that the SRBs are bridging traffic as they should, but the routed protocol(s) is (are) not getting through a router.
Table 4-1 outlines possible problems that block routing of traffic through routers in SRB internetworks.
Causes and Actions for Blocked Routing in SRB Environments
| Possible Cause
| Suggested Actions
|
|---|
| Misconfigured router while routing a protocol and attempting to communicate with host on another ring across an SRB
| Step 1: Check configuration for inclusion or absence of multiring protocol-name command.
Step 2: Add this command to the router configuration if it is missing.
Step 3: Try the steps outlined in the next symptom, "Routing in SRB Network Fails Unexpectedly."
|
|
| Step 4: Contact your router technical support representative if you are still unable to get traffic intended to be routed to transit the router.
|
Note Refer to the scenario entitled "Concurrent Routing and Source Route Bridging Connectivity Problems" in Chapter 2, "Connectivity Problem Scenarios," for illustrations and additional context-related information.
Symptom: As with the preceding situation, you may need to route certain protocols (for example, Novell IPX) through internetworks that are dominated by source route bridge (SRB) links. In this symptom, routing is working, then halts without any known administrative changes in the network.
Table 4-2 outlines possible problems that could cause unexpected loss of communication over routers in SRB internetworks.
Causes and Actions for Routing Failures in SRB Networks
| Possible Cause
| Suggested Actions
|
|---|
| Software bug in the end station software
| Step 1: Enable debug token-ring on the router and examine the "Last Ring Status" line in the show interfaces display. If the status reads "Beaconing," there is a problem with the ring.
|
|
| Step 2: If the "Last Ring Status" line does not indicate a beaconing state, check the output of the show rif EXEC command.
|
|
| Step 3: Determine whether the end station entry is missing from the RIF table.
|
|
| Step 4: If the end station is not listed, use the clear rif and clear arp commands, then ping the end station. See if the host can respond.
|
|
| Step 5: If the end station does not respond, use a network analyzer to look for the XID packet to NULL SAP (LSAP value of 00) sent by the router to the end station. The XID packet to NULL SAP is generated when the router's RIF entry for a workstation ages out and the RIF table is being updated.
|
|
| Step 6: If you see the XID packet and the end station does not reply, there is probably a bug in the host software.
|
|
| Step 7: Upgrade your host software or contact your technical support representative for more assistance.
|
|
| Step 8: If you do not see the XID packet, or if the station replies, but you still cannot establish communication, contact your technical support representative.
|
Note Refer to the scenario entitled "Concurrent Routing and Source Route Bridging Connectivity Problems" in Chapter 2, "Connectivity Problem Scenarios," for illustrations and additional context-related information.
Symptom: Cisco routers can be configured to operate as source route bridges connecting two or more Token Rings. In this situation, the router is not forwarding SRB traffic.
Table 4-3 outlines possible causes and recommended actions when routers are not bridging SRB traffic but were configured to do so.
Causes and Actions for Blocked SRB Traffic
| Possible Cause
| Suggested Actions
|
|---|
| Misconfigured Cisco router; ring number mismatch
| Step 1: Get the ring number from IBM SRBs (specified in hexadecimal notation).
|
|
| Step 2: Check configuration with write terminal command. Look for ring number assigned to rings connected to router's interfaces. Ring numbers can be specified in either decimal or hexadecimal (with the 0xABCD notation).
|
|
| Step 3: Convert IBM SRB ring number to decimal and make sure ring numbers for all internetworking nodes agree.
|
|
| Step 4: If ring numbers do not agree, recalculate the router's ring number specification and make sure it matches the IBM SRB; reconfigure the router's interface specification.
|
|
| Step 5: If you still cannot communicate over the SRB, check subsequent symptom listings for possible causes. Contact your technical support representative if no actions restore communication.
|
| End station does not support RIF
| Step 1: Place a network analyzer on the same ring to which the end station is connected.
|
|
| Step 2: Look for any frames sent from the end station with the first bit of the source address set to 1. Refer to the scenario entitled "Translational Bridging, SRT, STUN, and SDLLC Connectivity Problems" in Chapter 2, "Connectivity Problem Scenarios," for illustrations and additional context-related information.
|
|
| Step 3: If no such frames are found, the end station does not support RIF and is not able to participate in source routing (example would be a UNIX or Novell workstation without source routing software).
|
|
| Step 4: Options: configure the router to act as an SRT; route the protocol if routable.
|
|
| Step 5: If your environment requires SRB, contact your workstation or server vendor for SRB drivers or for information about setting up SRB on your workstation or server.
|
| End station configured to send spanning explorers and router not configured to pass spanning explorers
| Step 1: Place a network analyzer on the same ring to which the end station is connected.
Step 2: Look for any frames sent from the end station with the first bit of the source address set to 1.
|
|
| Step 3: If such frames are found, check the first two bits of the routing control field and determine whether the frames are the spanning all ring frames (that is, first two bits are set to 1).
|
|
| Step 4: If these frames are spanning all ring frames, determine whether the router is configured to forward spanning explorers (use source-bridge spanning interface subommand).
|
|
| Step 5: If necessary, add the source-bridge spanning interface subcommand to any router that is required to pass spanning explorers.
|
|
| Step 6: If sessions still cannot be successfully established over the SRB, contact your technical support representative for more assistance.
|
Symptom: As a remote SRB, a router uses encapsulated Token Ring packets to allow interconnection of Token Ring networks over any non-Token Ring media type (such as an FDDI backbone, point-to-point serial lines, or a packet-switched network). In this situation, users/hosts are unable to communicate over the remote SRB.
Table 4-4 outlines possible causes of being unable to communicate over remote SRB configurations and suggests actions to remedy these connection stoppages.
Causes and Actions for Remote SRB Communication Problems
| Possible Cause
| Suggested Actions
|
|---|
| Misconfigured source-bridge remote-peer commands on the router
| Step 1: Check the router configuration using the write terminal EXEC command.
Step 2: Ensure that the source-bridge remote-peer command is pointing to the correct IP address on each router.
|
|
| Step 3: Modify configuration as required.
|
|
| Step 4: Check for existence of remote peers using the show source-bridge command.
|
| End station does not support RIF
| Step 1: Refer to "No Communication over SRB" earlier in this chapter.
|
| Hop count exceeded
| Step 1: Check the hop count values on the routers (using the show protocol route command) and other bridges in the path.
|
| No route to the remote peer (TCP/IP encapsulation)
| Step 1: Check the result of the show ip route command. If a route to the intended remote peer is not included in the list, create a route or check the state of devices and cabling in the path to the remote peer.
|
|
| Step 2: Verify IP connectivity; try to ping from the router to the remote peer IP address. If the remote peer does not reply, the SRB frames will not get through. If it does reply, IP routing is operational.
|
| Serial link problem
| Step 1: Make sure that the show interfaces command indicates that the serial port indicates the following: Serial n is up; line protocol is up. Refer to Chapter 7, "Troubleshooting WAN Connectivity," if the status line indicates any other condition.
|
|
| Step 2: Make sure the selected encapsulation type matches the requirements of the nework to which the serial interface is attached.
|
Symptom: Sessions time out over router configured for remote SRB.
Table 4-5 outlines possible causes of intermittent connection when trying to pass traffic over a router configured for remote source route bridging (encapsulated SRB over any non-Token Ring media).
Causes and Actions for Intermittent Connectivity over Remote SRB
| Possible Cause
| Suggested Actions
|
|---|
| Sessions are timing out
| Step 1: Place a network analyzer on the ring local to the source station and look for acknowledgments appearing on the local ring after the transmission timeout period.
|
|
| Step 2: Check for dropped packets in the show interfaces display output on all involved interfaces in the path.
|
|
| Step 3: Check configuration for keyword local-ack at the end of the source-bridge remote-peer global configuration command.
|
|
| Step 4: Add this additional keyword if missing.
|
|
| Step 5: Adjust protocol parameters as described in Chapter 24 of the Router Products Configuration and Reference publication. In particular, the various LLC2 timer values may need tuning.
|
Symptom: Cisco routers allow for the translation between Ethernet and Token Ring of transparent bridging and source route bridging, respectively. Under certain circumstances, this translation may not work, resulting in an apparent failure of translational bridging.
Note In certain situations, existing
translational bridges have been replaced with Cisco translational bridges. This can cause interoperability problems. Some translational bridge implementations map functional addresses between media (such as
LAT
functional address 0900.2B00.00FA on Ethernet) to a broadcast address on the Token Ring ring side (such as C000.FFFF.FFFF). Cisco does not support this functionality. Furthermore, note that you cannot use translational bridging with any protocol that embeds a station's
MAC address inside the information field of the MAC frames (examples include IP ARP and Novell IPX).
Table 4-6 outlines possible causes that may prevent communication through routers configured for translational bridging.
Causes and Actions for Traffic Stoppages over a Translational Bridge
| Possible Cause
| Suggested Actions
|
|---|
| Router does not support Ethernet-to-Token Ring address mapping
| Step 1: Check for the existence of the Ethernet station using the show bridge EXEC command.
Step 2: Use the show rif command to determine whether the target Token Ring station is visible on the internetwork.
Step 3: If Ethernet and Token Ring end stations are visible, statically configure any relevant server MAC addresses in the client configurations, so the clients can listen to the server advertisements directly.
|
|
| |
| Vendor code mismatch
| Step 1: Specify ethernet-transit-oui global configuration command. This command forces the Cisco router to make the vendor code field 000000. This is frequently required when there are IBM 8209s (IBM Token Ring-to-Ethernet translating bridges) in the same network. Refer to the Router Products Configuration and Reference publication for more information about this command.
|
|
| |
| Adding Cisco translational bridging destabilizes network, blocks all traffic
| Step 1: Check for pre-existing translational bridge(s) in parallel with the Cisco translational bridge; any that are left in place will result in loops.
|
|
| Step 2: Since implementing translational bridging defeats the spanning tree mechanism of both transparent bridging and SRB environments, you must eliminate all loops caused by insertion of the translational bridge.
|
| Trying to bridge protocols that embed MAC address in Information Field of MAC frame (such as IP ARP and IPX)
| Step 1: Route these protocols.
Step 2: If you still cannot communicate over the router, contact your technical support representative.
|
Symptom: Packets cannot traverse a router configured to support source-route transparent (SRT) bridging.
Note Source-route transparent bridging allows you to implement transparent bridging in Token Ring environments. It is not a means to translate between SRB on a Token Ring and transparent bridging on Ethernet (or other) media. This confusion is sometimes the cause of blocked traffic in multimedia environments.
Table 4-7 outlines possible causes and suggested actions to remedy blocked traffic flow in SRT implementations.
Causes and Actions for SRT Communication Problems
| Possible Cause
| Suggested Actions
|
|---|
| Trying to bridge frames containing RIF from Token Ring side to Ethernet side over SRT bridge
| Step 1: Use translational bridging instead of SRT to allow SRB-to-transparent bridging translation.
|
| Hardware does not support SRT
| Step 1: For each router interface required to support SRT, examine the output of the show interfaces token number command to determine whether the Token Ring interface is "Source Route Transparent capable."
|
|
| Step 2: Check all other bridges in network for SRT support.
|
|
| Step 3: Make sure that the software/microcode are compatible with SRT for all internetworking devices; upgrade as needed.
|
| Attempting to transfer large frame sizes (exceeding Ethernet MTU of 1500 bytes)
| Step 1: Configure hosts to generate frame sizes less than or equal to Ethernet MTU (1500 bytes).
|
| Trying to bridge protocols that embed MAC address in Information Field of MAC frame (such as IP ARP and IPX)
| Step 1: Route these protocols.
Step 2: If you still cannot communicate over the router, contact your technical support representative.
|
Symptom: Users cannot make session connections to hosts on the other side of a router configured to support SDLC-to-LLC Media Translation (SDLLC).
Table 4-8 outlines possible causes and suggested actions when users are unable to make host connections over an SDLLC implementation.
Causes and Actions for SDLLC Communication Problems
| Possible Cause
| Suggested Actions
|
|---|
| Missing partner command
| Step 1: Include partner interface subcommand (points router to the FEP's hardware address on Token Ring). This forces the transmission of explorer packets.
|
| Missing sdllc xid command
| Step 1: Include the sdllc xid interface subcommand. This command defines XID information (IDBLK and IDNUM) that must match host definitions when any 37X5 or 3172 device is being used as a gateway.
|
|
| Step 2: Check with host system administrators/programmers to ensure that XID information is properly defined.
|
| Microcode incompatibility
| Step 1: Perform show controller mci command to obtain microcode version of serial card. Look for the SCI microcode version.
|
|
| Step 2: Upgrade to the latest microcode version.
|
| Incorrect RTS signal
| Step 1: Insert a breakout box between the router and the IBM device. and monitor the LEDs for correct signaling. RS-232 signaling requirements are briefly described in the discussion following this table.
|
|
| Step 2: Check RTS for continuous active signal.
|
|
| Step 3: If the signal is not continuously active, set the signal high by strapping DTR from the IBM side to RTS on the router side. Open the RTS connection between the router and the IBM device. More information concerning physical layer mismatches is provided with a subsequent symptom module entitled "Router Is Not Communicating with IBM SDLC Devices over RS-232."
|
|
| Step 4: If the IBM device is a 3174, reply with a "1" to question number 340 in the 3174 configuration process (permanent request to send).
|
| Incorrect V.35 applique jumper setting
| Step 1: When using the V.35 dual-mode applique as a DCE, remove the SCT/SCTE jumper. This selects SCT (specifies timing signal from server).
|
When connecting a router to an IBM device with a serial connection, you must verify that the signaling configurations are compatible. Figure 4-1 illustrates a typical serial connection between a router (Router-1) and an IBM device. A breakout box is inserted to examine signal states on the cable.
Figure 4-1: Checking IBM Serial Link to Router with Breakout Box
Table 4-9 outlines the key signaling requirements for the RS-232 link between Router-1 and the 3745 FEP. Figure 4-1 illustrates the direction of signals with respect to the router as listed in Table 4-9. This environment assumes that the router is configured for DCE, while the IBM FEP is configured for DTE.
Key RS-232 Signaling Requirements for Router to IBM FEP Connection
| Lead/Signal
| State
| Reference to Router
|
|---|
| 4/RTS
| High
| Incoming
|
| 5/CTS
| High
| Outgoing
|
| 6/DSR
| High
| Outgoing
|
| 8/Carrier Detect
| High
| Outgoing
|
| 20/DTR
| High
| Incoming
|
When configuring a Cisco router for SDLLC operation in IBM internetworking environments, the following actions are suggested for preventing operational problems.
- When configuring SDLLC, the sdllc traddr command must point to the virtual ring, not to the physical ring. The virtual ring corresponds to the ring group number specified in the source-bridge ring-group command. This applies to single router configurations (where the Token Ring and the serial line are both tied to the same router) and multirouter configurations (where the routers are separated by WAN clouds). Also note that the specification of the virtual ring number is the last parameter to be included in the sdllc taddr command.
- SDLLC will not work between an IBM AS/400 and 5394. Do not try to use Cisco's SDLLC feature to provided this functionality. The AS/400 can only operate as a PU 2 device, while the 5394 can only operate as a PU 1 device. SDLLC only accommodates protocol and frame translation at the DLC level and does not participate in any SNA level exchange. To allow for this kind of translation, you must implement some kind of conversion device for translating PU 1 to PU 2.
Note Refer to the
Router Products Configuration and Reference publication for more information concerning these commands.
The sdllc traddr command requires that you specify a virtual Token Ring address for an SDLC-attached device (the device that you are spoofing to look like a Token Ring device). The last two hex digits of this virtual ring address must be 00 (hex). This is because the last byte of the address represents the SDLC address of the station on the serial link.
Use care in assigning virtual ring addresses. Any virtual ring address that falls into the range xxxx.xxxx.xx00 to xxxx.xxxx.xxFF belongs to the associated SDLLC serial interface. An IBM Locally Administered Address (LAA) is typically user-defined, and in practice these addresses tend to follow a logical ordering. As a result, there is a real chance that other IBM devices on an internet will have an LAA that falls in the same range. If this occurs, problems can arise because Cisco routers only examine the first 10 digits of the LAA address of a packet (not the last two, which are considered wild cards). If the router sees a match of the assigned SDLLC LAA address, it automatically forwards that packet to the SDLLC process. In certain cases, this can result in packets being lost (incorrectly forwarded to the SDLLC process) and sessions never being established.
Note Before assinging a virtual ring address for any SDLLC implementation, be sure to obtain the LAA naming convention used in the internet to avoid conflicting address assignments.
Symptom: User connections to hosts time out over a router configured to support SDLC Transport.
Table 4-10 outlines possible causes and suggested actions when connection service availability is erratic to hosts over an SDLC implementation.
Causes and Actions for Intermittent SDLC Connectivity
| Possible Cause
| Suggested Actions
|
|---|
| SDLC timing problems
| Step 1: Place a serial analyzer on the serial line attached to the source station and monitor packets.
|
|
| Step 2: If duplicates appear, check configuration for keyword local-ack at the end of the stun route address interface subcommand.
|
|
| Step 3: Add this additional keyword if missing on both router configurations for SDLC interfaces.
|
|
| Step 4: Adjust SDLC protocol parameter described in the Router Products Configuration and Reference publication. These parameters are used to customize SDLC transport over various network configurations. In particular, the various LLC2 timer values may need tuning.
|
Symptom: When installing a new router in a Token Ring environment, you find that the router will not connect to the ring.
Table 4-11 outlines possible causes and suggested actions when the router fails to connect to the Token Ring.
Causes and Actions for Router Not Connecting to Ring
| Possible Cause
| Suggested Actions
|
|---|
| Relay open in MAU
| Step 1: At system power-on, if "open lobe fault" message appears on console (or VTY) display connected to router, check the cable connection to MAU.
|
|
| Step 2: Issue the clear interface command to reset the Token Ring interface (used to clear the interface and reinsert into the ring).
|
|
| |
|
| Step 3: Issue a show interfaces token command to verify interface operation.
|
|
| Step 4: If the interface is operational, but "open lobe fault" message persists and router continues to be unable to connect to its ring, switch connection from router to a different MAU port.
|
|
| Step 5: If "open lobe fault" message continues to appear, disconnect all devices from the MAU and reset the MAU's relay with the tool provided by MAU vendor.
|
|
| Step 6: Reattach the router and determine whether it can connect to the ring. If resetting the relay does not remedy the problem, try replacing the MAU with one that is known to be operational.
|
|
| Step 7: If the router is still unable to connect to the ring, check internal cable connections of router Token Ring cards. Ensure that cables associated with the respective port numbers and applique numbers are correctly wired (make sure they are not swapped).
|
|
| Step 8: If router still cannot connect to the Token Ring, replace the cables connecting the router to the MAU with working cables.
|
|
| Step 9: Use the clear interface command to reset interface and reinsert the router into the ring. Using the show interfaces token command, look for "interface up" and "protocol up" in the status line.
|
| Bad ring speed specification
| Step 1: Use show interfaces token command to determine status of interface.
|
|
| Step 2: If status line indicates that the interface and line protocol are not up, check cable from router to the MAU. Make sure that the cable is good; replace if necessary.
|
|
| Step 3: If show interfaces token indicates interface up/line protocol up, use the ping command between routers to test connectivity.
|
|
| Step 4: If the remote router does not respond, check the ring specification on all nodes attached to the Token Ring backbone. Ring speed for all must be the same.
|
|
| Step 5: If necessary, modify ring speed specifications for clients, servers, and routers.
|
|
| Step 6: Use the ring speed command to modify ring speed configuration for IGS/TR. Change jumpers as needed for modular router platforms. Refer to your system's hardware installation and maintenance manual for more information about ring speed specification.
|
Symptom: When installing a router, you find that the router is not able to communicate with an IBM SDLC device over an RS-232 cable.
Note When debugging serial line physical layer problems, it is important to observe indicator lights on appliques, LEDs on modems/modem eliminators, and line drivers. These will help determine if the hardware is having any problems and can save time in debugging other problems.
Table 4-12 outlines possible causes and suggested actions when a router is apparently not communicating with SDLC devices over RS-232.
Causes and Actions for Blocked Communication with SDLC Device
| Possible Cause
| Suggested Actions
|
|---|
| Physical layer mismatch
| Step 1: Make sure that both the IBM device and the router implement the correct signal coding (NRZ or NRZI).
|
|
| Step 2: If the IBM device supports full-duplex NRZ, make sure it is set for full duplex NRZ (set RTS high). Set the signal high by strapping DTR from the IBM side to RTS on the Cisco side.
|
|
| Step 3: For AS/400 multidrop devices, make sure that the serial line connecting the router with the primary link station has carrier detect tied to ground.
|
|
| Step 4: Use the show interfaces command to determine whether the interface and protocol are up.
|
|
| Step 5: If the router is set up as a DTE device, check to make sure the clocking source configurations match for all devices. Make sure the modems/modem eliminators are properly configured.
|
|
| |
|
| |
|
| Step 6: If the clock settings match, try reducing the line speed to 9600 baud (whether the router is configured as DTE or DCE).
|
Symptom: SDLC sessions are not coming up when attempted over a router running STUN between two nodes. An underlying symptom here is that the SDLC sessions are not being completed--the necessary handshaking is not occurring.
Table 4-13 outlines possible causes and suggested actions when SDLC sessions are not coming up over a router implementing STUN.
Causes and Actions when SDLC Sessions Fail over STUN
| Possible Cause
| Suggested Actions
|
|---|
| Broken physical connectivity of SDLC secondary stations and the Cisco STUN peer
| Step 1: Check the STUN state with the show stun command from the router.
Step 2: If STUN state indicated using the show stun command is "closed," check physical connectivity as described in the previous symptom/problem discussion, "Router Is Not Communicating with IBM SDLC Devices over RS-232."
|
| Misconfigured stun route address command specification
| Step 1: If STUN state is "open," use the debug stun-packet command at the router(s) to look for Set Normal Response Mode (SNRM) and matching Unnumbered Acknowledgment (UA) packets. Ensure that the SNRMs and UAs (that have SDLC addresses corresponding to the relevant secondary stations) are getting to the correct STUN peer (router).
|
|
| Step 2: If SNRMs are detected with the debug stun-packet command output, but no UAs are returning, use the write terminal command on the router to which the primary link station is attached.
|
|
| |
| Misconfigured stun peer command
| Step 1: At the STUN peer (router) to which the secondary link station is attached, enable debug stun-packet and look for SNRMs for that peer.
|
|
| Step 2: If no SNRMs appear in the debug output, check the stun peer-name commands on the router to which the primary link station is attached. Make sure that the IP address specified in this command is correct for the router.
|
| Physical connectivity problem from the secondary link station to the router; misconfigured stun route address definition on router to which the secondary link station is attached; or broken IBM gear
| Step 1: If you do see SNRMs, use the show interface serial command to see if output drops are accumulating. This would suggest that the router is not communicating with the secondary link station.
Step 2: For 3174s, if no output drops are detected, check the front panel display for values cycling between 532 and 505. If the 3174 display is cycling between 532 and 505, then communication from the router to the secondary link station works. This cycling of values indicates that SNRMs are getting to the 3174, but the receiver ready signal is not initializing.
|
|
| Step 3: Check the output of the debug stun-packet display to see if relevant UAs are being detected. If so, the problems of physical connectivity and broken IBM gear can be eliminated.
|
|
| |
|
| Step 4: Check physical connectivity as described in the previous symptom/problem discussion, "Router Is Not Communicating with IBM SDLC Devices over RS-232."
|
Symptom: Users on NetBIOS clients complain that they cannot establish connections to NetBIOS servers over routers acting as remote SRBs.
Table 4-14 outlines possible causes and suggested actions when access is blocked to NetBIOS servers from clients over a remote SRB cloud.
Causes and Actions for Blocked NetBIOS Communication
| Possible Cause
| Suggested Actions
|
|---|
| Incorrect mapping of NetBIOS name cache server-to-client mapping
| Step 1: For each router on which NetBIOS name caching is enabled, use the show rif command to determine whether the RIF entry shows the correct path from the router to both the client and the server.
|
|
| Step 2: Use the show netbios command to see if the NetBIOS cache entry show the correct mapping from server name and client name to MAC address.
|
|
| Step 3: Use the write terminal command at each router and examine the mapping of addresses specified in the netbios name-cache command. Change these if they are not correct.
|
| Incorrect specification of remote peer parameters in source-bridge specification
| Step 1: For each router on which the name cache is enabled, use the show source-bridge command to obtain the version of the remote connection. The value specified should 2.
|
|
| Step 2: If the value is 1, connections will not get through and you must modify your configuration. Specify the version 2 parameter of the source-bridge remote-peer command.
|
Note Whenever name caching appears not to be running between a particular client and server, capture traces for packets that apparently are not flowing. In addition, get the output of
show rif,
show netbios, and
show source commands for the routers at each end of the RSRB cloud. This information will help in diagnosing a NetBIOS name caching problem by providing information about the state of the router.
Symptom: A specific router cannot be linked from LAN Network Manager (LNM) in an SRB environment.
Table 4-15 outlines possible causes and suggested actions when a router cannot be linked using LNM.
Causes and Actions for Problems Linking Router via LNM
| Possible Cause
| Suggested Actions
|
|---|
| Misconfigured LAN Network Manager MAC address specifications (universal)
| Step 1: Use the show lnm config command on the router to determine the Token Ring MAC addresses. They must match the addresses entered on the LNM.
|
|
| Step 2: If they do not match, enter these Token Ring MAC addresses on the LNM platform.
|
| MAC address mismatch when router is connected to a virtual ring (locally administered)
| Step 1: Use the show lnm config command on the router to determine the Token Ring MAC addresses.
Step 2: Make sure that the Token Ring address configured on the LNM matches the address administered on the router. Check the mac-address command for each Token Ring interface. This command gives each Token Ring interface a locally administered address (such as 4000.0001.2345).
|
