|
|
This chapter focuses on a series of connectivity problems associated with routing and bridging in IBM-based networks, possible causes of those symptoms, and general suggestions for identifying, isolating, and resolving those causes.
This chapter consists of the following sections:
The symptom modules consist of the following sections:
With multiprotocol internetworks, the chances of misconfiguration resulting in connectivity loss are substantially greater than with single-protocol networking environments. Along with the added efficiency and flexibility of multiprotocol internetworks comes an added level of management complexity.
The following connectivity-related scenario features both Novell and Sun networking systems sharing access to resources over Token Ring and serial media. This scenario illustrates problems facing internetworks characterized by concurrent bridging and routing.
Consider a corporate network composed of Token Ring segments partitioned with source-route bridges (SRBs) as illustrated in Figure 8-1. Here, the personal computers (PCs) on Ring 4 are unable to connect to Novell servers on Rings 2 and 3, while a PC on Ring 3 cannot communicate with the Sun file server on Ring 4.
Figure 8-1 illustrates a map of the environment discussed in this case.
The following summarizes the relevant elements of this internetworking environment:
Given the situation, the following possible problems are the most likely candidates for interconnection failure:
The next step is to eliminate each potential cause as the problem source and then test the network to determine whether it is operational. The following discussion works through the process of problem isolation.
Given the difficulties being experienced, router configuration problems are definite possibilities. In particular, if routed protocols are not making their way through an SRB environment, look for missing multiring interface configuration commands. The following steps outline actions to diagnose and remedy potential configuration problems in this kind of environment.
Step 1 Use the write terminal command on the two routers connected to the T1 serial line to look for a multiring interface configuration command for each routed protocol, or use the all keyword option (applied to the Token Ring interfaces). Note that the multiring command is only required when there are other SRB bridges on the LAN. Excessive use of multiring can lead to other problems.
Step 2 Assuming that the multiring command is not included or that it does not cover a particular protocol that is being routed and subsequently bridged as in this scenario, make any required changes. Figure 8-2 illustrates a specification of the multiring command that generates RIFs for IP frames, but not for Novell IPX frames. Refer to the Router Products Configuration Guide and Router Products Command Reference publications for more information about using the multiring command.
The specification of IP network addresses is often the source of connectivity problems. An incorrect IP address can create a discontinuous network space, which results in a complete stoppage of all IP traffic at the point of discontinuity.
In this scenario, assume that Token Rings 1, 2, 3, and 4 are all configured for major net 131.108.0.0. The interfaces attached to the serial line linking the two sites are assigned IP addresses 192.1.100.1 (Router-Far) and 192.1.100.2 (Router-Corp). The discontinuity in this example results from the separation of segments in the same subnet (the four Token Rings) by a segment that belongs to a different major network (the serial network).
Step 1 Use the write terminal EXEC command to determine the address specifications associated with the Token Rings and serial lines to which the routers are attached.
Step 2 There are two solutions for this situation:
The end systems (PCs) attached to the various rings are another likely problem source in this scenario. The following steps outline actions to diagnose and remedy potential problems associated with the end systems in this kind of environment.
Step 1 Check the end systems for SRB drivers. Missing drivers might make end systems unable to participate in protocol exchanges.
Step 2 Reconfigure the end systems or replace them with systems that have the ability to handle SRB.
Step 3 In addition to missing SRB drivers, end systems may be unable to participate in protocol exchanges because of software problems. To isolate this problem in a TCP/IP environment, ping the end systems.
Step 4 If there is no response, the hardware address might be present. If so, the device was previously seen; if not, it was either never seen, or the entry timed out. Use the show rif and show arp EXEC commands to determine the hardware address of the end systems in the ARP and RIF tables. Figure 8-3 and Figure 8-4 illustrate the output of the show rif and show arp commands.
Step 5 If the end system does not appear in the table, use the clear rif-cache and clear arp-cache commands. Be aware, however, that clearing caches causes network activity spikes while the caches are repopulated. If this high activity contributes to station problems, this might produce random results, which may be confusing to a user doing a "sample of one on a random result"--in other words, the station response gets lost and the user assumes it is still unavailable. Set the RIF timeout to a small value and ping the end system at intervals greater than the RIF timeout to see if the end system can respond.
Step 6 If the end system does not respond, use a network analyzer to look for the response of the end system to the Exchange ID (XID)-to-NULL SAP packet (DSAP value of 00) from the router.
The default timeout for Address Resolution Protocol (ARP) table entries is much larger than the Routing Information Field (RIF) entries (such as 4 hours for ARP and 15 minutes for RIF). The first time that a station is pinged, there are no ARP or RIF table entries for its hardware address, so both entries are updated with the ARP response from the end system. After the default timeout for RIF, the RIF entry is cleared, whereas the ARP entry remains. When this situation arises, if the end system is pinged again, the router generates an XID packet and sends it to the destination hardware address of the end system with a NULL SAP value (DSAP value of 00) to find the RIF.
Step 7 If you do see the router XID-to-NULL SAP packet, but the end system is unable to respond, there is probably a problem with the end system (host) SRB software, and you must upgrade the software on the end system.
(In one case, there was a bug in the IBM RS6000 where an RS6000 would not reply to an XID sent with a NULL SAP value.)
Connectivity problems can be further complicated when the ARP cache contains so many entries that IP cache invalidations occur due to a constant stream of devices aging out. Any route change will result in a request to update the cache. If there are three or more simultaneous route-update requests for the cache, the Cisco device will invalidate the entire cache because doing so is faster than processing each one. The result is that each route that is invalidated (all of them in the case of three or more) will cause the next packet to be process switched and the route cache to be repopulated with up-to-date information.
The following steps outline actions to diagnose and remedy potential problems associated with the end systems in this kind of environment.
Step 1 Depending on the mix of network traffic, there will be a processor-load "spike" of random height and duration. The IP cache damping features may be used to reduce this effect in a LARGE routing table environment. In most corporate networks, the real cause of route flaps should be determined and overcome. In service provider environments with very large routing tables, it may be impossible to control the flapping route information received from outside sources; as a result, you might need to use the damping features (these are documented in the 10.2 manual). If you notice these symptoms, enable the IP cache damping features to extend the time at which devices time out (aging). To do so, enter the following command:
Step 2 Try using the debug ip-icmp, debug arp and debug broadcast commands.
Executing the debug ip-icmp command, in particular, can provide a quick indication on the health of your network. If you see time-to-live exceeded (TTL) messages, this is a sign that there are permanent or temporary routing loops in this network. If you see the router sending "redirects", end-stations might be responding improperly if the redirects are being constantly emitted toward one or more stations. Some users might constantly ping the routers as confirmation and reassurance that devices can be reached; unfortunately, this bogs down the routers with unnecessary overhead. In this case, you might want to ask users to limit their use of ping commands.
Execute the debug arp command to help you identify situations in which misconfigured end-stations are constantly running processes that attempt to reach non-existent (or powered-off) devices. These constantly running processes create a burden on the router, which must convert connection attempts into ARPs that are never answered. This also burdens all end-stations on the destination LAN with broadcast traffic, which must be evaluated and discarded
Execute the debug broadcast command after you check the relative broadcast "rate" on all interfaces of a router. After you enable debug broadcast, you can easily identify non-productive network traffic that is consuming bandwidth and router resources.
Step 3 Try using egrep on terminal output to quickly search for counts, errors, drops, and so forth.
Topics covered in this scenario addressed a number of common SRB and routing problems encountered in IBM internetworks. Procedures discussed included the following:
Figure 8-5 and Figure 8-6 provide relevant configuration listings for Router-Corp and Router-Far. These configurations illustrate changes required to ensure proper RIF updating and a contiguous network addressing scheme.
Cisco provides IBM connectivity options that range from support for source-route bridging (SRB) and source-route transparent (SRT) bridging to translational bridging and SDLC Transport over TCP/IP. Thus, network managers can tailor router configurations to the specific needs of existing networks and reconfigure routers to respond to network changes.
The scenario that follows illustrates some common pitfalls encountered in implementing internetworking solutions in complex IBM networks. This scenario focuses on potential problems associated with translational bridging, SRT bridging, serial tunneling (STUN), Synchronous Data Link Control (SDLC) Transport, and SDLC-to-Logical Link Control type 2 translation (SDLLC).
The large-scale corporate network illustrated in Figure 8-7 is composed of multiple Ethernet and Token Ring segments partitioned with SRBs, SRT bridges, a transparent bridge, and a translational bridge.
Connectivity problems on this network are as follows:
Figure 8-7 illustrates a map of the environment discussed in this scenario. The following summarizes the relevant elements of this internetworking environment:
Before attempting to define a specific problem, it is important to identify the most likely causes and to then systematically eliminate each one. Given the situation, the following problems are the best candidates for interconnection failures:
The next step is to eliminate each potential cause as the problem source and then test the network to determine whether it is operational. The following discussion works through the process of problem isolation.
In the first symptom, PC-2 is unable to access either of the target DEC LAT servers (LAT-1 and LAT-2). With an SRB in the path to both, PC-2 itself becomes a suspect. In particular, its ability to support SRB is in question. The following steps suggest ways to determine whether the system is source-route capable:
Step 1 Place a network analyzer on Ring 3 (the same ring to which end system PC-2 is connected).
Step 2 Look for any frames sent by the end system (PC-2) with the high-order bit of the source address set to 1. Figure 8-8 illustrates output from the network analyzer, with the high-order bit of the source address set to 1.
Step 3 If you cannot find a frame with the high-order bit of the source address set to 1, the end system does not support RIF and is not able to participate in source routing.
Step 4 If the end system supports source routing, replace SRB-1 with an SRT bridge to get its traffic through to LAT-1 and LAT-2. This network change is addressed later as part of a comprehensive solution; see Figure 8-10 for a revised map and a description of the network changes involved.
In symptom number 2, PC-1 (which is SRB-capable) on Ring 3 can talk to DEC LAT server LAT-1, but cannot talk to DEC LAT server LAT-2. As with the preceding problem, the key here rests with technology differences between the internetworking devices in the path to the servers and the end system trying to make a connection.
The likely stopping point for traffic in this case is Router-5, which is configured as an SRT bridge. Because Router-5 is attached to both a Token Ring and an Ethernet segment (and is configured for SRT bridging), it discards packets that include RIF data. Determine whether the end system (PC-1) is source-route capable. The steps to remedy this problem are analogous to the prior procedure, with some slight differences:
Step 1 Place a network analyzer on Ring 3 (the same ring to which end system PC-1 is connected).
Step 2 Look for frames sent by the end system (PC-1) with the RIF present. Figure 8-9 illustrates output from the network analyzer with RIF present.
Step 3 If you find a frame with the high-order bit of the source address set to 1 (see Figure 8-8), PC-1 is source-route capable. The RIF illustrated in Figure 8-9 specifies that the frame came from Ring 001 (hexadecimal) over bridge 1 (hexadecimal), through Ring 00A (hexadecimal) over bridge 1 (hexadecimal) to Ring 002 (hexadecimal). Note that Bridge 0 is valid though not often seen.
Step 4 In this case, an end system with a RIF is a problem. When Router-5 sees the RIF in packets sent from PC-1, it will drop those packets rather than put them on the Ethernet interface.
Step 5 To get traffic from PC-1 through to LAT-2, you can enable translational bridging on Router-5 or replace SRB-1 with an SRT bridge. This network change is part of a comprehensive solution described in the section "Problem Solution Summary," later in this chapter.
Older Token Ring implementations, such as the IBM 8209, expect the vendor code (OUI) field of the SNAP header to be 000000. Cisco routers modify this field to be 0000F8 to specify that the frame was translated from Ethernet Version 2 to Token Ring. Cisco's modification of this field can cause end systems that expect the SNAP header to be 000000 to drop packets. The ethernet-transit-oui interface configuration command forces the router to make the vendor code field 000000.
To determine whether you need to add the ethernet-transit-oui interface configuration command to the configuration of a router, follow these steps:
Step 1 On the router acting as a translational bridge (Router-1), use the write terminal EXEC command and look for the ethernet-transit-oui interface configuration command.
Step 2 If the ethernet-transit-oui interface configuration command is not present and if frames are getting through the translational bridge, but some workstations are dropping packets, specify the ethernet-transit-oui interface configuration command on Router-1. This command forces the router to make the vendor code field 000000.
For more information, refer to the Router Products Configuration Guide and Router Products Command Reference publications.
If routed protocols are not making it through an environment consisting of SRBs, look for missing multiring Token Ring interface configuration commands.
Symptom number 3 is a 3174 cluster controller (Cluster-2) that cannot communicate with FEP-2. In this scenario, SDLC Transport (tunneling) is implemented via IP encapsulation. This configuration suggests that Router-4 or Router-5 is missing the multiring interface configuration command, which is required as a result of routing between Router-4 and Router-5.
The following steps outline actions for determining whether you should add the multiring interface configuration command to the configuration of a router:
Step 1 Use the ping EXEC command to determine whether Router-5 can communicate with Router-4.
Step 2 Use the write terminal EXEC command (on Router-4 and Router-5) to look for a multiring interface configuration command that includes the ip keyword option, or the all keyword option, for the Token Ring interfaces.
Step 3 Assuming that the multiring command is not included or does not cover a particular protocol that is being routed (and subsequently bridged over the SRB as in this scenario), you can add the multiring ip command to Router-4 (Token Ring interface T0) and Router-5 (Token Ring interface T0), as illustrated in Figure 8-7.
Step 4 Another option is to reconfigure to eliminate this problem. See Figure 8-10 for a revised map and a description of the network changes involved. Removing SRB-1 and SRT-1 remedies the problem without requiring the addition of the multiring ip command.
The last symptom in the scenario is the 3174 cluster controller (Cluster-1) that cannot communicate with the AS/400 host that is directly attached to Ring 2. The following procedure isolates and suggests ways to resolve this problem:
Step 1 Place a network analyzer on Ring 1 (the same ring to which Router-3 is connected), or use the debug sdllc EXEC command on Router-3.
Step 2 Determine whether Router-3 is generating explorer packets for the AS/400.
Step 3 If Router-3 is not generating explorer packets for the AS/400, check its configuration for inclusion of the sdllc partner interface command and sdllc xid interface configuration command.
Step 4 If not present, add the sdllc partner and sdllc xid commands. These commands force the router to generate explorer packets.
Several of the solutions in this scenario pointed to a redesign of the original network as illustrated in Figure 8-7. Figure 8-10 presents a suggested reconfiguration of the internetwork. The modification includes the replacement of SRB-1 and SRT-1 by an AGS+ Cisco router and the implementation of SRT bridging on all Main-Net Token Ring links.
This scenario addressed a number of common problems encountered in complex IBM internetworks. The solutions included the following:
Figure 8-11 through Figure 8-14 provide the complete, final configuration listings for the key routers discussed in this scenario.
The symptom modules that follow pertain to IBM internetworking problems. There are modules for the following topics:
Symptom: When installing a new router in a Token Ring environment, you find that the router will not connect to the ring. Table 8-1 outlines possible causes and suggested actions when a router fails to connect to a Token Ring.
Symptom: SRBs are bridging traffic as they should, but routed protocols are not getting through a router. If this symptom occurs, you must route certain protocols (for example, Novell IPX) through an internetwork that is dominated by SRB links. Table 8-2 outlines a possible cause and suggested actions when routing does not function in an SRB environment.
| Possible Cause | Suggested Actions |
|---|---|
| Misconfigured router; routing a protocol and attempting to communicate with host on another ring across an SRB bridge | Step 1 Check the configuration for inclusion or absence of a multiring protocol-name interface configuration command.
Step 2 Add a multiring protocol-name interface configuration command to the router configuration if it is missing. Step 3 For IP networks, make sure that the end system is pointing to the Token Ring address of the router as the default gateway. If a UNIX host is running routed, check its default routes. Step 4 Determine whether a host can respond using the ping command. If it does not respond, use the show arp EXEC command to determine whether an entry for the host exists in the ARP table. If an entry exists, use the show rif EXEC command to match the RIF with the hardware address of the host. Step 5 Try the steps outlined in the next symptom module, "Routing in SRB Network Fails Unexpectedly." Step 6 Contact your router technical support representative if you still cannot get traffic intended to be routed to transit the router. |
Symptom: Routing is working in an environment dominated by SRB links, then halts without any known administrative changes in the network. Table 8-3 outlines a possible cause and suggested actions when routing in an SRB network fails unexpectedly.
Symptom: A router configured to operate as an SRB that connects two or more Token Rings is not forwarding SRB traffic. Table 8-4 outlines possible causes and suggested actions when no communication is occurring over an SRB.
| Possible Causes | Suggested Actions |
|---|---|
| Misconfigured router; ring number mismatch | Step 1 Get the ring number (specified in hexadecimal) from IBM SRBs.
Step 2 Use the write terminal privileged EXEC command to look for the source-bridge local-ring bridge-number remote-ring interface configuration command that assigns ring numbers (displayed in decimal) to the rings that are connected to the router's interfaces. (Although you can enter the ring number in hexadecimal or decimal, it always appears in the configuration as a decimal number. Also note that parallel bridges situated between the same two rings must have different bridge numbers.) Step 3 Convert IBM SRB ring numbers to decimal and verify that the ring numbers for all internetworking nodes agree. Step 4 If the ring numbers do not agree, reconfigure the router's interface so that its ring number matches the IBM SRB. Step 5 If you still cannot communicate over the SRB, contact your technical support representative. |
| End system does not support RIF | Step 1 Place a network analyzer on the same ring to which the end system is connected.
Step 2 Look for any frames sent from the end system with the first bit of the source MAC address set to 1. Refer to the section entitled "Translational Bridging, SRT Bridging, STUN, SDLC, and SDLLC Connectivity Scenario" earlier in this chapter for illustrations and additional context-related information. Step 3 If no such frames are found, the end system does not support RIF and is not able to participate in source routing. Step 4 If the protocol is routable, you can configure the router to act as an SRT bridge and route the protocol. 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 system configured to send spanning explorers, but router not configured to forward them
(A spanning explorer is equivalent to a single-route broadcast.) | Step 1 Place a network analyzer on the same ring to which the end system is connected.
Step 2 Look for any frames sent from the end system with the first bit of the source address set to 1. Step 3 If such frames are found, determine whether the frames are spanning all-ring frames (that is, the first two bits are set to 1). Step 4 If you find spanning all-ring frames, determine whether the router is configured to forward spanning explorers (using the source-bridge spanning interface configuration command). Step 5 If necessary, add the source-bridge spanning interface configuration command to any router that is required to pass spanning explorers. Step 6 Use the show source-bridge EXEC command to determine whether the explorer count is incrementing. Step 7 If sessions still cannot be successfully established over the SRB, contact your technical support representative for more assistance. |
Symptom: Users are unable to communicate over a remote SRB. 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 a Fiber Distributed Data Interface [FDDI] backbone, point-to-point serial lines, or a packet-switched network). Table 8-5 outlines possible causes and suggested actions when communication over a remote SRB is blocked.
| Possible Causes | Suggested Actions |
|---|---|
| Misconfigured source-bridge remote-peer global configuration commands on the router | Step 1 Use the write terminal privileged EXEC command to verify that the source-bridge remote-peer command is pointing to the correct IP address on each router.
Step 2 Modify configuration as required. Step 3 Use the show source-bridge EXEC command to check for the existence of remote peers. |
| End system does not support RIF | Step 1 See Table 8-4 for suggested actions. |
| Hop count exceeded | Step 1 Use the show protocol route command to check the hop count values on the routers and other bridges in the path.
Step 2 Alternatively, you can enable the debug source event privileged EXEC command to see whether packets are being dropped because the hop count has been exceeded. |
| No route to the remote peer (TCP/IP encapsulation) | Step 1 Check the result of the show ip route EXEC 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 cannot get through. If it does reply, IP routing is operational. |
| Serial link problem | Step 1 Use the show interfaces EXEC command to verify that the interface and line protocol are up. Refer to Chapter 3, "Troubleshooting Serial Line Problems," if the status line indicates any other condition.
Step 2 Verify that the selected encapsulation type matches the requirements of the network to which the serial interface is attached. |
| Peer problems | Step 1 Use the show source-bridge EXEC command to determine whether the peer is "open" between routers. If the peer is not open, routers cannot communicate.
Step 2 Use the show source-bridge command to determine whether the remote router can see the ring. If devices are not present on both rings, peers may not open, or peers may not appear in the show source-bridge display. Step 3 If devices are present on both rings and peers are open, but communication is still blocked over the remote SRB connection, contact your router technical support representative for more assistance. |
Symptom: Sessions time out over a router configured for remote SRB. Table 8-6 outlines a possible cause and suggested actions when intermittent communication failures occur over a router configured as a remote SRB (encapsulated SRB over any non-Token Ring media).
| 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 that appear on the local ring after the transmission timeout period.
Step 2 Perform a ping test to the remote router and note the round trip delay. Compare this value with the timeout value. If the round trip delay is close to or exceeds the timeout value, increase the timeout parameter. If the measured delay is close to or exceeds the timeout value, modify the timeout configuration at the source station. Step 3 Use the show interfaces EXEC command to check for dropped packets on all interfaces in the path. Step 4 If you are using TCP encapsulation, use the show tcp EXEC command to check the retransmission count for the peer in question. Step 5 Use a network analyzer to capture traffic for six or seven stations that have connectivity problems. Step 6 Adjust protocol parameters as described in the Router Products Configuration Guide and Router Products Command Reference publications. In particular, the various LLC2 timer values may need tuning. Step 7 On low-end routers, verify that the allocated buffers are adequate. Use the show buffers command, and look for misses in small, middle, or big buffers. Tune the number of buffers if there are many misses. For details, see the section "Adjusting Buffers to Ease Overutilized Serial Links" in the "Troubleshooting Serial Line Problems" chapter. |
Symptom: Users on NetBIOS clients complain that they cannot establish connections to NetBIOS servers over routers acting as remote SRBs. Table 8-7 outlines possible causes and suggested actions when NetBIOS clients cannot connect to NetBIOS servers over a remote SRB.
Symptom: Routers allow for the translation of transparent bridging and source-route bridging between Ethernet and Token Ring, respectively. Under certain circumstances, this translation may not work, which results in an apparent failure of translational bridging.
Table 8-8 outlines possible causes and suggested actions when users cannot communicate over Cisco routers configured for translational bridging.
Symptom: Packets cannot traverse a router configured to support SRT bridging. Table 8-9 outlines possible causes and suggested actions when traffic cannot get through a router configured for SRT bridging.
Symptom: User connections to hosts time out over a router configured to support SDLC Transport. Table 8-10 outlines a possible cause and suggested actions when connectivity to hosts is intermittent over a router configured for SDLC.
Symptom: When installing a router, you find that the router is not able to communicate with an IBM SDLC device over an EIA/TIA-232 (formerly RS-232) cable.
Table 8-11 outlines a possible cause and suggested actions when a router is apparently not communicating with IBM SDLC devices over EIA/TIA-232.
Symptom: SDLC sessions between two nodes are not coming up when they are attempted over a router that is running STUN. An underlying symptom is that the handshaking required to complete SDLC sessions is not occurring. Table 8-12 outlines possible causes and suggested actions when SDLC sessions fail over a router running STUN.
| Possible Causes | Suggested Actions |
|---|---|
| Broken physical connectivity of SDLC secondary stations and the STUN peer | Step 1 Use the show stun EXEC command to check the STUN state.
Step 2 If the output of the show stun EXEC command indicates that the STUN is "closed," check physical connectivity as described in the "Router Is Not Communicating with IBM SDLC Devices over EIA/TIA-232" symptom module earlier in this chapter. |
| Misconfigured stun route address interface configuration command | Step 1 Use the show stun EXEC command to check the STUN state.
Step 2 If the output of the show stun EXEC command indicates that the STUN is "open," use the debug stun-packet privileged EXEC command 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 router. Step 3 If SNRMs are indicated in the debug stun-packet command output, but UAs are not indicated as returning, use the write terminal privileged EXEC command on the router to which the primary link station is attached. Step 4 Look for the SDLC address specified in the stun route address interface configuration command. Entries for this command should point to relevant secondary link stations. (Routers do not support the stun route all functionality for SDLC; routers only support the basic STUN transport protocol.) |
| Misconfigured stun peer-name global configuration command | Step 1 At the router to which the secondary link station is attached, enable the debug stun-packet privileged EXEC command and look for SNRMs for that peer.
Step 2 If no SNRMs appear in the output, check the stun peer-name commands on the router to which the primary link station is attached. Make sure that this command specifies the IP address of the router correctly. |
| Physical connectivity problem from the secondary link station to the router; misconfigured stun route address interface configuration command on router to which the secondary link station is attached; or, broken IBM equipment | Step 1 At the router to which the secondary link station is attached, enable the debug stun-packet privileged EXEC command and look for SNRMs for that peer.
Step 2 If you do see SNRMs, use the show interfaces serial EXEC command to see if output drops are accumulating. Accumulating output drops suggest that the router is not communicating with the secondary link station. Step 3 For 3174s, if output drops are not accumulating, check the front panel display for values cycling between 505 and 532. This cycling of values indicates that SNRMs are getting to the 3174, but the receiver ready signal is not initializing. Step 4 Check the output of the debug stun-packet privileged EXEC command to see if relevant UAs are being detected. If so, physical connectivity and broken IBM equipment can be eliminated as possible causes. If the debug stun-packet privileged EXEC command output at the router to which the primary link station is attached displays relevant UAs, the problem is isolated to a physical connectivity problem from that router to the primary link station. Step 5 Check physical connectivity as described in the "Router Is Not Communicating with IBM SDLC Devices over EIA/TIA-232" symptom module earlier in this chapter. |
Symptom: Users cannot make session connections to hosts on the other side of a router configured to support SDLLC.Table 8-13 outlines possible causes and suggested actions when users are unable to make host connections over a router configured for SDLLC.
| Possible Causes | Suggested Actions |
|---|---|
| Missing sdllc partner command | Step 1 Configure the sdllc partner interface configuration command so that it points the router to the hardware address of the FEP on Token Ring. This command forces the transmission of explorer packets. |
| Missing sdllc xid command | Step 1 Include the sdllc xid interface configuration command. This command defines XID information (IDBLK and IDNUM) that must match host definitions when any 37X5 or 317X device is being used as a gateway.
Step 2 Check with the system administrators of the hosts to ensure that the XID information is properly defined. If the 317X device is a channel-attached gateway, XID must be 0000000 for IDBLK and IDNUM. |
| Microcode incompatibility | Step 1 Use the show controller mci EXEC command to obtain the SCI microcode version of the serial card.
Step 2 Upgrade to the latest microcode version. |
| Incorrect RTS signal in full-duplex implementation | Step 1 Insert a breakout box between the router and the IBM device and monitor the LEDs for correct signaling. EIA/TIA-232 signaling requirements are briefly described in the discussion following this table, "IBM EIA/TIA-232 Signaling Requirements Summary."
Step 2 Check RTS for a continuously active signal from the router. 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. For more information concerning physical layer mismatches, see the "Router Is Not Communicating with IBM SDLC Devices over EIA/TIA-232" symptom module earlier in this chapter. Step 4 Configure the 3174 for permanent RTS by replying with a "1" to question number 340. |
| Incorrect V.35 applique jumper setting | Step 1 When using the V.35 dual-mode applique as a DCE, remove the SCT/SCTE jumper, which selects SCT and specifies that the timing signal come from the server. |
When connecting a router to an IBM device with a serial connection, you must verify that the signaling configurations are compatible. Figure 8-15 illustrates a typical serial connection between a router (Router-1) and an IBM device. Assume that the connection is full duplex. A breakout box is inserted to examine signal states on the cable.
Table 8-14 outlines the key signaling requirements for the full-duplex link between Router-1 and the 3745 FEP. Figure 8-15 illustrates the direction of signals with respect to the router as listed in
Table 8-14. This environment assumes that the router is configured for DCE, while the IBM FEP is configured for DTE.
| Lead/Signal | State | Reference to Router |
|---|---|---|
| 4/RTS | High | Incoming |
| 5/CTS | High | Outgoing |
| 6/DSR | High | Outgoing |
| 8/CD | High | Outgoing |
| 20/DTR | High | Incoming |
When configuring a router for SDLLC operation in IBM internetworking environments, try the following actions for preventing operational problems:
The sdllc traddr command requires the specification of 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 hexadecimal digits of the virtual ring address must be 00 because the last byte of the address represents the SDLC address of the station on the serial link.
Assign virtual ring addresses carefully. 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 internetwork will have an LAA that falls in the same range. If this occurs, problems can arise because routers only examine the first 10 digits of the LAA address of a packet (not the last two, which are considered wildcards). 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 incorrectly forwarded to the SDLLC process and sessions never being established.
Symptom: A specific router cannot be linked from the LAN Network Manager (LNM) in an SRB environment. Table 8-15 outlines possible causes and suggested actions when a router cannot be linked using LNM.
Troubleshooting STUN and SDLLC internetworks can involve a fairly complicated series of diagnostic steps. Even the simplest interconnection requires careful evaluation of each possible problem. This section outlines the basic diagnostic steps for representative STUN and SDLLC internetworking arrangements.
Consider the basic configuration illustrated in Figure 8-16. In this arrangement, an IBM mainframe is channel-attached to an FEP. The FEP is serial-attached to a router (Router-A), which is point-to-point connected over a serial connection to Router-B. Router-B is attached to a cluster controller. Assume that SDLC connections cannot be completed over the routed internetwork illustrated in Figure 8-16.
The following diagnostic tables (Table 8-16 through Table 8-19) outline a process for diagnosing blocked connectivity in this internetwork; the process starts at the FEP and moves to the cluster controller at the other end of the SDLC connection. The diagnostic steps outlined for this example are split into four parts:
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Failed serial connection from FEP to router | Step 1 Use the show interfaces EXEC command at Router-A; look for any indication of a possible problem. For more information about troubleshooting serial connections, refer to the "Troubleshooting Serial Line Problems" chapter. |
| Incorrect IBM cable | Step 2 Ensure that the correct cable is attached to the FEP. The V.35 cable and the EIA/TIA-232 IBM cable are similar in appearance. The chief difference is that the V.35 cable has three switches while the EIA/TIA-232 cable has only two.
Step 3 Use the show interfaces command to determine whether the interface and line protocol are up, and that the reset counter is not changed. If everything appears normal, proceed to Table 8-17. |
| Incorrect RTS signal in full-duplex implementation | Step 4 Insert a breakout box between the router and the IBM device and monitor the LEDs for correct signaling.
Step 5 Check RTS for a continuous active signal from the router. Step 6 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. For more information concerning physical layer mismatches, see the "Router Is Not Communicating with IBM SDLC Devices over EIA/TIA-232" symptom module earlier in this chapter. Step 7 When using the V.35 dual-mode applique as a DCE, remove the SCT/SCTE jumper, which selects SCT and specifies that the timing signal come from the server. |
| Microcode incompatibility | Step 8 Use the show controller mci EXEC command to obtain the SCI microcode version of the serial card.
Step 9 Upgrade to the latest microcode version. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Misconfigured FEP | Step 1 Check RTS and Clear to Send (CTS) signals; RTS should be active.
Step 2 Check CD and ground; make sure that CD is strapped to ground. Step 3 Enable the debug stun-packet privileged EXEC command on Router-A. Step 4 Deactivate and then activate the SDLC lines at the host. Use the following VTAM commands: VARY NET,INACT,LINE=xx (where xx is the number of the line being toggled) Step 5 If SNRMs do not appear in the debug stun-packet output, check the line from the FEP to the serial interface on the router; the NCPGEN on the FEP, and the line number used with the VARY VTAM command as specified at the FEP. Step 6 If SNRMs appear in the debug stun-packet output, go to Table 8-18; otherwise, go to Table 8-19. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Misconfigured stun peer-name global configuration command and stun route address interface configuration command | Step 1 Enable the debug stun-packet privileged EXEC command at Router-B.
Step 2 If SNRMs appear in the debug stun-packet output at Router-B, misconfigured stun peer-name and stun route address commands might be blocking connectivity. Proceed to Table 8-19. (The show stun EXEC command can also provide a clue. It should indicate that the serial link between the routers is in "open" mode.) |
| Physical serial connection failed | Step 3 Use the show interfaces EXEC command at Router-A and Router-B to determine whether they are operational. Make sure that the output indicates that both the interface and the line protocol are up.
Step 4 If either the interface or the line protocol is not up, you may have a hardware problem. Check all your physical connections and refer to Chapter 2, "Troubleshooting Router Startup Problems," for hardware diagnostic information. |
| Mismatched SDLC (PU) address | Step 5 If this serial connection uses direct HDLC encapsulation, verify that the SDLC address is correctly matched with the appropriate interface number. If not, modify as necessary. |
| IP connection is incorrectly defined | Step 6 If this serial connection uses TCP/IP encapsulation, verify that the IP addresses of the stun route address interface configuration commands at both ends are matched with the IP addresses of the complementary stun peer-name global configuration commands. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Failed connection at cluster controller | Step 1 Use the show interfaces EXEC command at Router-B to look for a possible problem. For more information about troubleshooting serial connections, refer to the "Troubleshooting Serial Line Problems" chapter. |
| Incorrect IBM cable | Step 2 Ensure that the correct cable is attached to the FEP.
Step 3 Use the show interfaces command to determine the status of the interface. If the output indicates that the interface and line protocol are up, and you still cannot establish connectivity, contact your router technical support representative. |
| Incorrect RTS signal in full-duplex implementation | Step 4 Insert a breakout box between the router and the IBM device, and monitor the LEDs for correct signaling. |
| Incorrect V.35 applique jumper setting | Step 5 Check RTS for a continuously active signal from the router.
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. For more information concerning physical layer mismatches, see the "Router Is Not Communicating with IBM SDLC Devices over EIA/TIA-232" symptom module earlier in this chapter. Step 6 Configure the 3174 for permanent RTS by replying with a "1" to question number 340. Step 7 When using the V.35 dual-mode applique as a DCE, remove the SCT/SCTE jumper, which selects SCT and specifies that the timing signal come from the server. |
| Cluster controller configuration problem | Step 8 Determine whether the cluster controller is operational.
Step 9 If the cluster controller is not up, or if UAs are not returning from the controller, check the configuration of the controller and make sure that it is properly set; look for PU address, NRZI, and NRZ specification errors. |
| Microcode incompatibility | Step 10 Use the show controller mci EXEC command to obtain the SCI microcode version of the serial card. |
Figure 8-17 illustrates an example SDLLC environment. An IBM mainframe is channel-attached to an FEP. The FEP and Router-A are both attached to a Token Ring. Router-A is point-to-point connected to Router-B, and Router-B is SDLC-attached to a cluster controller. For SDLLC troubleshooting, start with the SDLLC router--in this case Router-B. Assume that SDLLC connections cannot be completed over the routed internetwork illustrated in Figure 8-17.
The following diagnostic tables (Table 8-20 through Table 8-24) outline a process of diagnosing blocked connectivity starting from Router-B. The diagnostic steps outlined for this example are split into four parts:
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| SDLLC configuration problems (general) | Step 1 If the routers are running Cisco IOS Release 10.0, go to Table 8-21. |
| Incorrectly specified TIC address in the sdllc partner interface configuration command | Step 2 Verify that the sdllc partner interface configuration command correctly specifies the TIC address in the configuration of the router. Make sure that the TIC address is the same as the LOCADDR defined on the FEP.
Step 3 Enable the debug sdllc privileged EXEC command on Router-B. Step 4 To cause Router-B to display debug output on the console, turn the cluster controller off and on or apply the shutdown and no shutdown interface configuration commands to the SDLC serial interface that is connected to the cluster controller. If debug output does not appear, go to Step 7. Step 5 If a network analyzer is available, insert it into the FEP ring. (As a last resort, if a network analyzer is not available, use the debug token ring privileged EXEC command. However, use this command with extreme caution. This command generates a large number of messages. Unless you can capture this output using a UNIX script or some similar facility, it will scroll too quickly to be useful. In addition, this command uses substantial CPU bandwidth; just enabling it can disrupt traffic significantly.) Step 6 Check the output of the analyzer (or the output of the debug token ring privileged EXEC command) for a response from the FEP to a test message sent from Router-B. Step 7 If you do not get a response from the FEP, use a network analyzer to determine whether test frames are being placed on the ring. |
| Failed serial connection between routers | Step 8 Check all physical connections between the routers (cables, connectors, interface cards, and appliques). Use the show source-bridge and show interfaces serial EXEC commands to identify any other serial connection problems.
Step 9 Use the show source-bridge EXEC command to determine whether all peers are "open" and whether the relevant remote SRB peers appear in the listings for local SRB ports. Step 10 Use the show interfaces EXEC command to determine whether the interface and line protocol are up and whether the reset counter is unchanged; if so, go to Table 8-23. Step 11 If test frames appear in the output of the debug token ring privileged EXEC command, go to Table 8-22; otherwise, go to Table 8-23. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Missing sdllc partner interface configuration command | Step 1 Verify that the configuration of the router includes the sdllc partner interface configuration command, which points the router to the hardware address of the FEP on Token Ring. This command is required to initialize the SDLLC process. |
| Incorrectly specified TIC address in the sdllc partner interface configuration command | Step 2 Verify that the TIC address is specified correctly in the configuration of the router. Make sure that this address is the same as the LOCADDR defined on the FEP.
Step 3 Enable the debug sdllc privileged EXEC command on Router-B. Step 4 To cause Router-B to display debug output on the console, turn the cluster controller off and on or apply the shutdown and no shutdown interface configuration commands to the SDLC serial interface that is connected to the cluster controller. If debug output does not appear, go to Step 7. Step 5 Send a test message from Router-B. Check the output of the debug sdllc privileged EXEC command for a response from the FEP. Step 6 If you do not get a response from the FEP, use a network analyzer to determine whether a test frame was placed on the ring. |
| Failed serial connection between routers | Step 7 Check all physical connections between the routers (cables, connectors, interface cards, and appliques). Use the show source-bridge and show interfaces serial EXEC commands to identify any other serial connection problems.
Step 8 Use the show source-bridge command to determine whether all peers are "open" and whether the relevant remote SRB peers appear in the listings for local SRB ports. Step 9 Use the show interfaces EXEC command to determine whether the interface and line protocol are up and whether the reset counter is unchanged; if so, go to Table 8-23. Step 10 If test frames appear in the output of the debug token ring privileged EXEC command, go to Table 8-22; otherwise, go to Table 8-23. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Failed FEP Token Ring adapter | Step 1 Check the network analyzer output (or debug token ring privileged EXEC command output) for a response to the null XID packet sent by the router.
Step 2 If you do not see a response, check the Token Ring adapter of the FEP. If you see a response, go to Table 8-24. |
| Possible Problem | Suggested Diagnostic Actions |
|---|---|
| Missing sdllc xid interface configuration command | Step 1 Check the network analyzer output (or debug token ring output) for an XID response for XID type 2.
Step 2 If not already configured, include the sdllc xid interface configuration command. This command defines XID information (IDBLK and IDNUM) that must match host definitions when any 37X5 or 317X device is used as a gateway. (If the 317X device is a channel-attached gateway, use the value 00000000 for IDNUM and IDBLK.) Step 3 If you do not see an XID response for XID type 2, check the IDNUM and IDBLK found in the trace. Step 4 Check with the system administrators of the hosts to ensure that XID information is properly defined. Step 5 Check the network analyzer output (or debug token ring privileged EXEC command output) for a SABME message from the FEP and a UA from Router-B. Step 6 Enable the debug sdlc command on Router-B. You should see SNRMs from Router-B arriving at the cluster controller. (If you do not see any UA responses to the SNRM messages in the debug sdlc command output, go to Table 8-24 or contact your technical support representative.) |
|
|
