| |
This topic discusses the following common problems and their associated solutions:
Load CALLMGR.NLM and manually try to initiate a call. Press Ins , select WAN Call Destination, then select IP. Check the Status column for the call.
If the status is Out-Queued, this means that the Novell Internet Access Server 4.1 server cannot communicate with the interface. If you are using a modem, check the physical connections and board and driver settings. For leased lines, make sure the DSU/CSU is set up correctly and all connections are working. Check the console log to make sure that the drivers for the board are loaded properly.
If the status is Out-Connecting and then Out-Disconnect, this indicates that a physical connection was established to the ISP; however, PPP did not successfully negotiate, so the call was disconnected. Load PPPTRACE.NLM and select Real-Time Monitor. Initiate the call with CALLMGR and then toggle back to PPPRTRACE by pressing Ctrl+Esc .
Both send (Snd) and receive (Rec) data should appear as PPP traffic before the IP connection is negotiated. If you see only send data and no receive data, the other side is not responding to the PPP requests. You might need to set up a login script, or the ISP might not be set up for PPP. Typically, you will see both send and receive data in the form of Configuration Requests (CnfgReq), Configuration Acknowledgments (CnfgAck), and Configuration Rejection (CnfgRej). You might also see other protocol-specific packets. Eventually, when the link terminates, you will see a Terminate Request (TermReq) and then a Terminate Acknowledge (TermAck). By viewing the negotiation exchange in PPPTRACE, you might be able to see where the negotiation fails. When the link terminates, a message appears on the system console stating why the link was terminated. For a more detailed explanation of the error message, refer to Novell Internet Access Server 4.1 Messages . The message often points you directly to the solution of the problem. Common causes for negotiation failure include incorrect PAP or CHAP negotiation, or incorrect setup of IP addresses for the connection.
If the trace is blank (no data), load MONITOR and select LAN/WAN Information. Check the Data Send Ready (DSR) value.
If the DSR is set to 0, the modem might not raise DSR. Load PPPCON to verify that the DSR is set to Off (parameter path: Select PPP Interfaces > Serial Interface). Load NIASCFG to set the Simulate DSR option to Yes (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > Physical Options). Restart the server or issue the REINITIALIZE SYSTEM command.
Use the Real-time Monitor option to generate a trace. If several packets appear and then the link is disconnected, verify that there is only one source of clocking between the routing software and any CSU/DSUs. Also, ensure that the router interface speed settings on the routers match.
In addition, verify that Outgoing Authentication in WAN Call Destination specifies the same authorization protocol that is configured on the remote side. You might need to load NIASCFG and select Configure NIAS > Protocols and Routing > Network Interfaces > PPP card option to set the Inbound Authentication option on both routers to None.
Load PPPTRACE and select Real-time Monitor to verify that data is being sent and received, then complete the following steps:
Ensure that Time Synchronization and NDS Synchronization are configured for on-demand links.
If the on-demand link is also configured for routing IP, ensure that RIP is disabled on the WAN interfaces.
Continue with the following steps if the ManageWise® software is installed in your environment.
Close all ManageWise windows that are polling an agent when they are no longer needed. Also, ensure that the network segments are not being monitored unnecessarily.
Run the NetExplorerTM software during nonbusiness hours, or configure a NetExplorer server at each site and use IPX and IP scoping in NXPCON to limit the discovery to networks that are not across the on-demand link.
Limit the number of alarms sent across the on-demand link. For servers running the NetWare Management AgentTM software, the NWTRAP.CFG file can be configured to transmit only critical alarms.
Load CALLMGR.NLM and verify the link connection. If the link is up, enter DISPLAY SERVICES at the server console to view the available services. Load STATICOM.NLM to automatically create static routes and services.
Load NIASCFG and check the Physical Type option (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces). Change this setting to the correct physical type.
LCP is down: **Maximum reached for Configure-Request retries - remote rejected the call**.Cause 1--- Data Encoding option does not match on both ends of the link.
Change the Data Encoding option in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Physical Options) to be the same on both ends of the link. For example, a port with the Data Encoding option set to NRZI connects only to another port with the Data Encoding option set to NRZI.
Restart the server or issue the REINITIALIZE SYSTEM command.
CALLMGR shows Out-Connecting status until the connection attempt times out.
Cause 2--- Physical Type (V.35, RS-232, and others) was configured incorrectly.
Configure the correct type in the Physical Type option in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Physical Type).
Restart the server or issue the REINITIALIZE SYSTEM command.
NOTE: Make sure that both ends of the synchronous PPP connection have been configured to use external clocking. Otherwise, one end operates in synchronous mode and the other end operates in asynchronous mode. This causes the PPP link to fail to connect.
Could not make WAN connection to
call_name on interface
interface_name . Call is rejected by the remote WAN node, or the media failed.Cause 1--- Physical Type option is configured incorrectly.
Configure the correct type in NIASCFG for both ends of the connection (parameter path: Configure NIAS > Select Protocols and Routing > Network Interfaces > select an interface >Physical Type).
Restart the server or issue the REINITIALIZE SYSTEM command.
Cause 2--- Inbound Call Processing option is disabled on the receiving end.
At the called router, change the Inbound Call Processing option to Enabled in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Authentication Options).
Restart the server or issue the REINITIALIZE SYSTEM command.
On the called router, the following message appears: On the router originating the call, change the Outbound Authentication option to Either PAP or CHAP in NIASCFG under WAN Call Directory. On the router receiving the call, make entries in the Local System ID and Password fields of the calling router in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Authentication Options > Inbound Authentication). The Password and Local System ID fields are case-sensitive. Restart the server or issue the REINITIALIZE SYSTEM command.Could not make WAN connection to
call_name on interface
interface_name . Call is rejected by the remote WAN node, or the media failed.
**Peer rejected authentication negotiation.**
Check in PPPTRACE for the LCP data that was sent and the generated responses. If you are using a slow link, increase the Response Timeout in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Timeouts & Retries).
There is a call collision. Static routes or permanent WAN call destinations are configured on both routers, and both routers are attempting to set up the call at the same time. Using CALLMGR at the router making the call, delete the call by pressing Del or speed up the retry by pressing F3 . If you do not delete the call manually in CALLMGR by pressing Del , the retry mechanism eventually connects the calls.
Cause 1--- Interface on the receiving end is disabled. In NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces), press Tab on the desired interface to toggle the status to Enabled. Issue the REINITIALIZE SYSTEM command. Cause 2 ---Wrong phone number is being dialed. Cause 3--- Answering modem is not properly configured. Cause 1--- Outgoing phone line has no dial tone or is in the wrong plug. Follow the procedures in Verify the Proper Setup of Connecting Hardware. Cause 2--- In CALLMGR, the outgoing call shows a status of
If the problem continues, check the modem manual for a listing of DIP switch settings. Sometimes there is a switch setting to raise DSR.
Cause 3--- The modem answered, but it did not connect. Watch the LCP negotiation using PPPTRACE. If any error messages are displayed on either console, refer to Novell Internet Access Server 4.1 Messages for information about the appropriate solutions. If PPPTRACE only shows Send packets, check the interface speed, as described in Verify Your Interface Speed. If two routers are connected through a modem with servers on either side of the network and the routers have been set up for on-demand calls, you can set up a static route to the remote server on the local router to attempt to establish a connection. Use one of the following methods to set up a static route.
Out-Queued and the status does not change.
Could not make WAN connection to
call_name on interface
interface_name . Call is rejected by the remote WAN node, or the media failed.
On the called router, the following message appears:
**Illegal peer ID/Password in the Authenticate-Request packet.**
The entries in the Inbound Authentication Database and the WAN Call Directory do not match. On the calling end, verify that the Password and Local System ID (parameter path: Select Configure NIAS > Protocols and Routing > WAN Call Directory > entry for the affected call) are entered exactly the same as in the Inbound Authentication Database (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Authentication Options) of the called router. The Password and System ID fields are case-sensitive.
On the called router, the following message appears: The outbound authentication protocol and inbound authentication protocol do not match. On the calling end, verify that the Outbound Authentication option (parameter path: Select Configure NIAS > Protocols and Routing > WAN Call Directory > select an interface > entry for the affected call > Outbound Authentication Option) matches the Inbound Authentication option on the receiving interface (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > Authentication Options) of the called router. Could not make WAN connection to
call_name on interface
interface_name . Call is rejected by the remote WAN node, or the media failed.
**Peer rejected authentication negotiation.**
CALLMGR displays the following message:
A call could not be established. See the console messages for further information.
The console message states the following:
Will not make WAN Connection to
call_name . A connection to that remote WAN node
Remote System ID already exists.
The remote system ID is duplicated on two WAN calls. If you require two active calls between two machines running the routing software, specify a unique remote system ID for each call in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > WAN Call Directory > select an interface).
PPPTRACE shows that there is an LCP failure.
The PPP negotiated parameters are not configured properly. In NIASCFG, verify that the MRU Maximum Size and MRU Minimum Size for both routers are in a range in which an MRU can be negotiated (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Negotiation Options).
The following error message is displayed on the NetWare console of the Novell Internet Access Server 4.1 routing software receiving the call:
An incoming call for protocol
protocol on interface
interface_name was rejected. Check Protocol binding to interface.
The protocol specified in the incoming call is not bound to the port on which this call has been accepted. Bind the protocol to the port and issue the REINITIALIZE SYSTEM command. Enter the CONFIG command at the NetWare console and verify that the desired protocol is now bound to the port. To find out the protocol, use PPPTRACE to see the incoming NCP Configure-Request packets.
An on-demand link goes up and down too often.
The Idle Link Timeout value is too short. The console of the router making the call displays the following message:
Link termination due to inactivity.
Load NIASCFG to increase the Idle Connection Timeout value (parameter path: Select Configure NIAS > Protocols and Routing > WAN Call Directory > select an interface).
Cause 1 ---Window is not displaying the correct interface.
Press F2 to change interfaces until the desired interface is displayed.
Cause 2--- No data is being sent on the interface.
Send some data.
PPPTRACE cannot show all packets in Real Time-Monitor. Use F7 to save the packets, then use the Play Back window to display them.
The connection to a third-party PPP implementation is being dropped after it has been established for a few minutes.
Link quality monitoring is not supported in Novell Internet Access Server 4.1. Disable link quality monitoring in the third-party implementation of PPP. Alternatively, if a third-party implementation supports using Echoes as the link quality monitoring method, use Echoes.
Observe the lights on the NT1.
If the Terminal Error light is on, this indicates a local problem. Refer to Cause 1 and, if necessary, Cause 2.
If the Line Error light is on, this indicates a network problem. Refer to Cause 3.
Cause 1 ---There is a problem with the cable from the ISDN adapter to the NT1.
Determine whether the cable from the ISDN adapter to the NT1 is undamaged and is connected properly.
Cause 2 ---There is a problem with the ISDN driver.
Verify that the ISDN driver is loaded and is configured properly.
Cause 3 ---There is a problem with equipment on the network side of the connection.
Report the problem to your ISP.
Observe the lights on the NT1. If the Line Error light is on, this indicates a network problem. Refer to Cause 1. If the Terminal Error light is on, this indicates a local problem. Refer to Cause 2 and, if necessary, Cause 3. Cause 1 ---There is a problem with equipment on the network side of the connection. Report the problem to your ISP. Cause 2 ---There is a problem with the cable from the ISDN adapter to the NT1. Determine whether the cable from the ISDN adapter to the NT1 is undamaged and is connected properly. Cause 3 ---There is a problem with the ISDN driver. Verify that the ISDN driver is loaded and is configured properly.
An ISDN interface fails to connect. You can determine whether the AT command for dialing out failed by using PPPTRACE.
Cause 1--- The receiving end rejects the call after the CONNECT_IND message is received.
Cause 2--- The receiving end does not receive the CONNECT_IND message.
A call could not be initiated because the selected interface is not loaded or is not bound to the selected protocol.Cause 1--- WAN driver did not load.
Cause 2--- PPPTSM did not load.
Cause 3 ---LAN protocol was not bound to the outgoing interface.
Bind the desired protocol to the port (network interface) on the WAN board from which the call will be made.
Cause 4 ---Outgoing PPP port is disabled.
Cannot recognize driver
driver_name . Disabled boards for this driver. Delete board or install and reenable boards.
The driver file does not exist in SYS:SYSTEM. Verify that the WAN board driver (for example, NW2000.LAN) exists in SYS:SYSTEM and is not corrupt. Use the DOS COMP command to verify that the driver is valid.
AIO FAILURE: data bit rate not supported. Fatal error: Unable to initialize AIO Board.
The interface speed specified in NIASCFG for the WHSMAIO interface is too high. Decrease the Interface Speed option in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface) and issue the REINITIALIZE SYSTEM command.
MONITOR shows many CRC errors.
CRC errors indicate either noise on the phone line or a mismatched interface speed. Check the Interface Speed option in NIASCFG (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface) on both sides of the connection. Usually, this speed should match. If matching the interface speed does not improve the number of CRC errors, the phone lines or the modems might be at fault. Use modems of the same type, or at least from the same vendor. Use different phone lines if you can. Complete the steps in Verify Your Interface Speed.
NOTE: High values for the Receive CRC Errors and Receive Aborts statistics are normal if the Dialing Mode parameter is set to V.25bis.
The modem is not configured properly for DTR dialing mode. Make sure the modem is configured for DTR dialing by verifying the positions of the DIP switches. For some modems, the DTR dialing mode can be set on the front panel. Consult the modem operation manual. Use MONITOR to monitor the DTR signal and make sure it is changed from the OFF to ON state (0 to 1).
The modem is not preprogrammed with a phone number to be dialed, or it is programmed with the wrong phone number. Make sure that the phone number is stored correctly and is the correct number. Depending on the modem type, the preprogrammed phone number can be stored by using the front panel or by sending AT command strings. Refer to the modem operation manual. CPECFG can be used to send AT command strings to the attached modem.
Make sure that both ends of the cable are screwed in tightly.
The DSR and DCD signals are not in the correct state. Use PPPCON or MONITOR to look at the DSR and DCD signals. The DSR signal must be in state 1 and the DCD signal must be in state 0 before a call can be initiated. The ON (1) state for these two signals indicates that the connection is established. If the modem raises both DSR and DCD signals prior to the connection, disable this feature with the modem's DIP switches or use a different modem.
An IPCP failure has occurred.
The local IP address of the router is not configured properly. Use the Bindings option in NIASCFG to make sure that the ports (network interfaces) at each end of the link are configured with IP addresses that are in the same subnet (parameter path: Select Configure NIAS > Protocols and Routing > Bindings > select an interface). The subnet masks must be identical. This topic is complex; refer to Understanding in the TCP/IP documentation for a complete explanation of subnet masks.
The LAPB T1 Retransmission Timer option is too short. Use NIASCFG to review and adjust the LAPB T1 Retransmission Timer option to a larger value.
The connection link is not reliable. LAPB is finding transmission errors in the compressed data. Try different modems or different phone lines. Reducing the Interface Speed option might help also.
Cause 1--- One end of the connection has the PPP Data Compression option set to Disabled. Set PPP Data Compression in NIASCFG to Enabled for the correct port on both ends of the connection (parameter path: Select Configure NIAS > Protocols and Routing > Network Interfaces > select an interface > Negotiation Options). Cause 2--- The type of data compression used is not supported by another vendor's routing software. Novell Internet Access Server 4.1 supports the following types of data compression:
Verify that you are using the correct cables. Rev. D and Rev. E of the Synchronous/+ boards use different cables. After verifying your configuration, use a null modem to check all cables as described in Back-to-Back Testing in the Overview documentation.
When two or more IPX WAN connections exist between two routers, verify that the connections are not assigned the same remote system ID in the WAN Call Directory option of the originating router.
A permanent WAN call destination has the Retry Mode option set to Never Retry; however, when the link goes down, there is one attempt to reestablish the link.
This is normal operation. The Retry Mode option does not influence the operation of the network protocol stacks. Therefore, when a permanent link goes down, the network protocols make one attempt to reestablish the link.
Established links will forward most data, but the packets for certain protocols or between certain destinations are being blocked.
You have filters configured on the router. Use FILTCFG to delete the appropriate filters. In the case of backup calls, FILTCFG might not display the filters that are causing the problem. All filters for backup calls are automatically mapped from the primary call, but they are not displayed in FILTCFG. You can disable this automatic mapping by entering the FILTSRV NOBACKUP command. You must configure a remote system ID to enable filter support for backup calls. To delete a filter from a backup call, you must delete it from the primary call. You can configure additional services on a backup call by adding filters on the circuit (interface and remote system ID) that is configured in the backup call.
If the trace shows data being sent but not received, run a loopback test and hardware diagnostics to verify that the WAN card, cabling, and CSU/DSU devices are working.
If the loopback test between the CSU/DSU devices is successful, try configuring one of the CSUs as the clocking source. Not all telco lines provide clocking.
Load the PPP driver from NIASCFG. Configured WAN call destinations might not recognize the PPP driver loaded manually from the server console.
| |