This page provides you with troubleshooting tips, problems, and solutions related to IP Switch Processor installation.
Troubleshooting Tips: Each using a terminal emulation program, two laptops or terminals should be able to talk back to back in the same way the terminal would communicate with the IP Switch Processor. If this is not possible, the problem is with the terminal or cable and not the IP Switch Processor.
Problem: You do not have a console connection to the IP Switch Processor.
Solution: See Step 2-Make a Console or Modem Connection in the IP Switch Processor Installation Guide for instructions to create console connection.
Problem: Console connection is using wrong port.
Solution: Verify that you are connected to the port labeled console.
Problem: Not connected with a null-modem cable.
Solution: Verify that you are using a null-modem cable. See Appendix B, Cables in the IP Switch Processor Installation Guide for pinouts.
Problem: Wrong terminal settings.
Solution: Verify terminal settings: 8 data, 1 stop, no parity, 9600 bps.
Problem: Terminal set for flow control.
Solution: The IP Switch Processor does not use flow control. The terminal should be set for no flow control.
Problem: Defective unit or file system.
Solution: Boot from floppy disk and perform full install. See the Ipsilon World Wide Web site Support page for instructions for performing the Full Installation procedure from floppy disk.
Problem: Entered wrong password.
Solution: Obtain valid password or default password.
Problem: Database is corrupt.
Solution: Default database according to the instructions shown below, or contact Ipsilon Customer Service.
This procedure requires local access to the unit.
1. Connect a VT-100 terminal or PC running a VT-100 emulation program
to the console port.
2. Boot in single-user mode. To do so: cycle power and enter s
when you see a line that says boot. There is a ten second
window before multi-user mode is initiated.
3. After several lines you will see the following message:
Enter pathname of shell or RETURN for sh
4. Press Enter.
5. Use the following command to enter new passwords:
/etc/overpw
6. After entering your new passwords, type reboot.
This procedure defaults the entire database and brings up the New System Startup procedure. (The New System Startup procedure is described in Chapter 3, Configuring the System in the IP Switch Processor Installation Guide.)
1. Log in to the IP Switch Processor as admin.
2. Type the following command to default the database:
/etc/unconfig
3. Reboot.
Problem: IP Switch Processor is defective, or file system on IP Switch Processor is defective.
Solution: Contact Ipsilon Customer Service.
The Full Installation procedure can be used to install a system from scratch.
This will completely replace the contents of the drive and may be needed
to restore or reload a unit. This procedure will erase any configuration
database on the unit. See the Ipsilon
World Wide Web site Support page for Full Installation procedure instructions.
Problem: Using the wrong Ethernet cable.
Solution: Use a crossover Ethernet cable if directly connecting to the PC. Use a straight-through cable if connecting to a hub. See Appendix B, Cables in the IP Switch Processor Installation Guide for cabling information.
Problem: Port is not configured UP.
Solution: Use the ifconfig command from the console port to verify that the port is UP, and RUNNING.
Problem: Host port configuration is incorrect.
Solution: Check host Ethernet port settings. Verify that IP address and netmask settings are correct for the IP Switch Processor configuration.
Problem: Wrong link speed.
Solution: Verify that the port on the host and the port on the IP Switch Processor are set for the same speed (10/100 Mbps). A solid on data LED is a good indication that there is a speed mismatch..
Problem: Local IP Switch Processor ports do not display.
Solution: Your card may be defective. Contact Ipsilon Customer Service to replace the card.
Problem: Remote device ports do not display.
Solution: GSMP link may not be up. Verify that the first available port on the IP Switch ATM1600 is connected to the ATM port on the IP Switch Processor and that all fault lights are cleared.
Problem: FAS1200 port does not display.
Solution: If the ATM1600 ATM port displays, but the FAS1200 port does not, the IFMP-C link may not be up. Verify that the ATM link to the FAS1200 module is up and no fault lights are on.
Problem: No link light.
Solution: You may have used the wrong cable. Use a crossover cable between IP Switch Processor and host, and a straight-through cable between IP Switch Processor and hub.
Problem: Solid data LED.
Solution: You may have the wrong speed set. Verify that the speeds match on each end (10 or 100 MB).
Problem: Port not enabled.
Solution: Verify from the Interface page in Voyager that the interface is configured as active.
Problem: High number of collisions on hub.
Solution: Disconnect connections one at a time until the problem is localized to one machine and then troubleshoot further.
Problem: Wrong cable used.
Solution: Verify that the proper crossover cable is used. See Appendix B, Cables in the IP Switch Processor Installation Guide for more information.
Problem: MMF to SMF interface.
Solution: Verify that you are not trying to connect MMF to SMF. SMF cards (indicated by red faceplate on IP Switch ATM1600) will only work with SMF interfaces.
Problem: No IFMP sync exists on the link between two IP Switch ATM1600s or link between an IP Switch ATM1600 and an IP Switch Processor.
Solution: Verify that each end of the link is configured Up and has a IP address in the same network..
This section covers connectivity issues isolated within a router or network.
Troubleshooting tips: Localize the problem by issuing pings to various network interfaces. Use tcpdump to help isolate the problem. tcpdump can be used to verify that a packet is leaving or entering a port. (See Viewing Packets with tcpdump in the IP Switch Processor Installation Guide for further information)
Problem: Interfaces not up.
Solution: Ensure that all interfaces are up and active, as described in the Interfaces section.
Problem: No route to network.
Solution: Check the routing table to see if a route exists to the network where the interface is located. If not route exists see troubleshooting routing below.
Problem: Attached device does not have proper default route or routing information.
Solution:
1) If a local PC is unable to ping through an attached IP Switch Processor, the PC may contain either an invalid default route or invalid routing information.
2) If you're using default routes from a PC, ensure that the local Ipsilon interface is the default route for that PC.
Problem: arp table has old information.
Solution: If the arp table has an old or invalid entry for the device associated with the IP address you are attempting to ping, delete the invalid entry with the arp -d <ip address> command.
Troubleshooting Tips: Use tcpdump to view routing information. Use the command tcpdump -i <interface> proto ospf to display routing updates for that interface. (See Viewing Packets with tcpdump in the IP Switch Processor Installation Guide for more information on using the tcpdump command.)
You can flush the routing table if invalid routes exist. Execute the command route -n flush from a console session. (View the man page for the route command for more information.)
Problem: OSPF is not configured.
Solution: Verify that OSPF is properly configured for all interfaces
that are involved in OSPF routing. For more information, view the Configuring
OSPF task (press )
from the Routing Configuration--OSPF page in Voyager.
Problem: OSPF hello and dead timers are not the same on each interface for a given link.
Solution: Verify that the settings at the end of each link are identical.
Problem: Attached devices do not support OSPF.
Solution: Ensure that the attached unit supports OSPF. If the attached device does not support OSPF, configure it with exchange routes or a default route with a protocol it does support.
Troubleshooting Tips: Use tcpdump to view packets. Use the command tcpdump -i <interface> proto rip to display packets for that interface. (See Viewing Packets with tcpdump in the IP Switch Processor Installation Guide for more information on using the tcpdump command.)
You can flush the routing table if invalid routes exist. Execute the command route -n flush from a console session. (View the man page for the route command for more information.)
Problem: Inconsistent subnet mask.
Solution: RIP version 1 must use a consistent subnet mask; change to RIP version 2 or OSPF if you want to use inconsistent subnet masks.
Problem: Number of networks exceeds RIP limit.
Solution: RIP can span up to 16 networks. Verify that your network topology does not exceed this limit.
Troubleshooting Tip: Always enter a metric value if you're exporting routes from OSPF to RIP.
Problem: Exchanging routes not configured correctly.
Solution: Exchanging routes involves several configuration steps. Follow the tasks in the Voyager Guide (online documentation) to ensure that all steps are followed.
Problem: Routing protocol not functioning properly.
Solution: See Common Problems with OSPF and Common Problems with RIP, above, to ensure that each routing protocol is functioning properly.
Troubleshooting Tips: Use tcpdump to view packets. Use the command tcpdump -i <interface> proto igmp to display packets for that interface. (See Viewing Packets with tcpdump in the IP Switch Processor Installation Guide for more information on using the tcpdump command.)
Use the command mtrace to view multicast routing path. (View the man page for the mtrace command for more information.)
Problem: No IP connectivity.
Solution: Verify that you have IP connectivity; ping various hosts on each network.
Problem: DVMRP is not enabled on the interfaces.
Solution: Verify that DVMRP is enabled on the interfaces in use.
Problem: Exceeding TTL on clients.
Solution: Verify that the client is set up for the proper TTL variable. Many clients are set to receive local traffic only one hop away.
Problem: Remote and local devices are not configured for the same VC and VP value.
Solution: Set remote and local devices to the same VC and VP values. (Consult your 1483 device documentation.)
Problem: Remote and local devices are not in the supported range of the NIC.
Solution: Determine the VC range of a NIC using the dctl command located in /usr/ips directory.
The following example shows an ATM NIC with 59 VC and an IDT card with 4095 (the max RX label defines the VC range for the card).
Ipsilon Nic: Adaptec0
Nic Id = 4
Device Name = atm-s1p1c0
Type = ATM
Media = MMF
Physical = STS_3C
Min Tx Label = 1
Max Tx Label = 1023
Min Rx Label = 1
Max Rx Label = 59
Ipsilon Nic: IDT NICStAR0
Nic Id = 2
Device Name = atm-s3p1c0
Type = ATM
Media = MMF
Physical = STS_3C
Min Tx Label = 1
Max Tx Label = 65535
Min Rx Label = 1
Max Rx Label = 4095
Problem: Encapsulation is not set to LLC/SNAP.
Solution: Set encapsulation to LLC/SNAP. (Consult your 1483 device documentation.)
Problem: The MTU size is not 1.5k.
Solution: MTU size must be 1.5k. Ipsilon does not currently support larger MTU sizes. Verify the 1483 device MTU size.
Problem: Failed to get image from FTP server.
Solution: Manually FTP the file to the IP Switch Processor and then choose install from local file option from the Setup program.
Problem: Tried to upgrade using full install file.
Solution: The full install file is only for installing a system from scratch with a boot floppy. Restart upgrade process and use the upgrade install file.
Problem: Corrupted upgrade file.
Solution: Ensure that the file is not corrupted. Ipsilon can provide MD5 verification number.
Problem: There is already another session of Setup in progress error message.
Solution: Delete the /tmp/.setup.lock file to remove the lock on Setup.
Problem: The /Ipsilon/config/.IPSO.MANIFEST file is corrupt and causes Setup to fail.
Solution: Back up the database and perform a full install. See System Configuration in the Voyager online documentation for instructions to back up the database to floppy disk, host machine, or FTP server. The Ipsilon World Wide Web site Support page contains Full Installation procedure instructions.
tcpdump is a program provided with the Ipsilon software used to view traffic on a network, much like the tcpdump or snoop programs of a UNIX workstation. Some features and commands used with tcpdump are outlined in this section; for more information, see the man page for tcpdump.
Press control-c to stop tcpdump. Substitute either physical or logical
interface names for <interface>.
The following example shows a local port on IPS0:
The following example shows IP Switch ATM1600 port from controller:
The following example command will return OSPF traffic:
The following example command will return IGRP traffic:
The following example command will return telnet traffic:
The following example command will also return telnet traffic:
The following example shows all bootp/dhcp traffic:
The following example shows no WWW traffic for that interface:
The following example specifies 320 bytes of the packet:
A trace file may be generated by using tcpdump with the w flag, which stores the packet in a local file for later viewing with tcpdump. This feature is useful when you want to mail a copy of tcpdump results to Ipsilon Customer Service.
The w flag copies the first 68 bytes of every packet, unless the capture size is increased. For users running without data encryption, passwords are also stored in the file.
The file will grow very quickly if the network being snooped is busy. We
recommend creating this file on the /usr partition, as this is
the 810 Mb area. Remember to delete this file once you are done.
The following example does not display packets:
Press ControlC to end the capture and print the number of packets captured.
The following example shows all RIP traffic for that interface:
Port 520 is also the port used by routed on UNIX workstations.
The following example shows all OSPF traffic on the ATM link, including LSAs and full information on routes:
The following example shows all IGRP traffic connected to that interface:
The following example shows all telnet traffic connected to that interface:
Updated May 30, 1997
This document can be found at http://<switchname>/voy.guide/troubleshoot.fm.html
Send comments to Ipsilon Technical Publications docs@ipsilon.com