cc/td/doc/product/wanbu
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Cisco 3801 Series Product Release Notes

Cisco 3801 Series Product Release Notes

January 9, 1998
Cisco IOS Release 11.2(11)P
Cisco IOS Release 11.2(10)P
Cisco IOS Release 11.2(9)P
Cisco IOS Release 11.2(8)P
Cisco IOS Release 11.2(7)P

These release notes provide you with late-breaking information about the Cisco 3801 series product, and contain the following sections:

Note These release notes are intended to be read along with the publication Release Notes for Cisco IOS Release 11.2(10)P, 11.2(9)P, 11.2(8)P, or 11.2(7)P.

Cisco IOS Software Images Supported

Your Cisco 3801 system is delivered with the most up-to-date Cisco IOS software available. The following model numbers of Cisco IOS software images will be available with a CCO membership for you to upgrade your system as necessary:

Note The "X" in the part number reflects the latest version of the Cisco IOS software image. For Cisco IOS Release 11.2(8)11.2(8)P, the "X" is replaced with a "7."

Software Notes and Caveats

This section lists general software problems and describes caveats that affect customers. Suggested workarounds are included if they exist.

General Software Issues

Important Software Caveats

This section describes caveats or unexpected behaviors you may encounter while configuring Cisco IOS software.

Report all problems you experience to the Cisco Technical Assistance Center (TAC) by calling 1-800 553-2447. Indicate the software version you are using and its image name and describe the symptoms in detail, the steps you have taken to reproduce the problem and any workaround you have discovered.

Caveats are reported and logged into a central database throughout the life cycle of the product. The most notable caveats are listed here in order of their DDTS reference number. Cite this number to your TAC representative when you report the problem so the database can be searched for a history and solution.

You can access the caveat database online to search the database for workarounds and bugs without making a phone call. You must purchasing a service contract with Cisco Connection Online membership. Ask your support representative for details.

Important Software Caveats for Release 11.2(11)P

Issuing the command "show connection-table" displays voice soft PVCs (connections from voice port to voice port) but the status of the connection does not include PNNI status.The status may be "OK," meaning the syntax is fine and the original port is fine, yet the connection to the remote voice port may not be established. The user can enter "show call-controller call" to see the PNNI status and the ATM endpoint address of the original voice interface.
See related caveat CSCdi88101.
When the serial interface is configured with encapsulation SDLC, it is not tracking the correct control lead coming from the DTE. Currently the interface goes up/up if the DTE raises RTS, the interface needs to track DTR and go up/up when DTR is raised.
Currently when the encapsulation on the serial interface is sdlc the RTS lead must be held high for the interface to stay line up protocol up. The other work around is to use the configuration to ignore the control signals altogether.
When a serial port is configured to encapsulation ftc-trunk, the interface does not go down when DTR is dropped. This can be seen by running 2 units back-to-back and then by pulling the cable or doing a shut at the other end.
Although the interface stays up, the ftc-trunk protocol is robust enough to reset the connections and restart communications when it detects that it is no longer in contact with the other end.
Issuing the command "show connection-table connection-number" displays cell and frame drop counters for cells and frames dropped in the switch. Counters display for data connections and for voice PVCs. These counters need to be added for voice port soft PVCs.
See related caveat CSCdi85966.
The software only reads some of the switches, and cannot validate that all switches are set correctly. It displays the selected settings based on just a few of the switches. It is important, therefore, to check that all switches are fully switched into the correct position. It is a good idea, with rocker switches, to put them into the desired position and then push them once more just to be sure they carefully depressed.
The hardware only provides 2 switches for software to read:sw1-1 (75/120 ohm) and sw1-2 (T1 or E1). Thus the software cannot detect any invalid combinations of any other switches. As a result, it is important to redoubly verify the settings of the switches, and insure that they are firmly positioned at the desired setting.
An FXS to FXS call must be configured for voice ports using the same coder. Different coder selections on each end of the circuit will not operate correctly.
When using DTMF dialing with echo canceller and non-linear processing enabled, there is minor echo in initial digit input, falling off to very little echo after first 1 or 2 digits input. Also, there is very minor echo in the audio when input and output gains are set to 0. This echo in audio can be eliminated by setting input gain to -6dB and output gain to -9dB.
The 3801 cannot be configured with a 'statsmaster' parameter to tell it which of the potentially many StrataView+ stations that have access to it is the one which it is allowed to accept and respond to statsfile updates. The user must be sure not to send conflicting statsfile info.
When the PNNI controller attempts to re-route a call, it does not examine the actual available bandwidth on the ftc trunk session-trunk to determine if there is sufficient room to add the call. This can cause a call to be tried and then rejected due to lack of bandwidth and it will not be tried out another path that has sufficient bandwidth. The workaround is to provision sufficient bandwidth.
When a voice port is configured for coder csacelp, DTMF tones can be corrupted to the point that they appear to be multiples of the digit entered. Digits 1, 4 and 5 exhibit this problem, other digits are OK.
This problem is observed as measured by a digit grabber test device but the digits are recognized and accepted by both the A.T.&T. PBX and the Rolm 9200 PBX.
Indication is that there may be some installations which would be sensitive to the corruption of these tones due to variations in PBX capabilities.
If a problem is experienced with passing DTMF tones through the 3801 network, then LD-CELP or some other coder should be selected.
When configured for fax-relay operation over CSACELP at a rate of 9600bps, the fax will fall back to 7200bps when the line is clean and should support the full 9600bps rate.
When a connection on an ftc-trunk is torn down, the statistics associated with the connection-id are not cleared. These statistics are displayed using the command show connection
The "Ground Start" operation does not function for PVC connections. This operation is intended to be supported using a translated signalling type only for FXS-to-FXO connectivity. Even this configuration does not work. Only SVC circuits are operational for Ground Start operation.
Many configuration options for voice calls activate only after you create a circuit using the "connect" command for PVCs, the "svc" command for SVCs, or after you reboot the Cisco 3801 system. The following voice port options are affected:

  • Call processing tones

  • Dial type

  • Echo cancellation

  • E&M configuration

  • Generate noise

  • Timing

  • Voice Activity Detect

For PVCs, the following options also become active only after the next circuit is created. For SVCs they take effect after the next outgoing call is placed:

  • Dial peer

  • Coder

  • Fax Relay

When configured for SPVC operation, if an FTC trunk is repeatedly created and then deleted, eventually the system may encounter a "software forced reload".
The workaround is that after many times creating and deleting an FTC trunk, manually reload the software before proceeding in production operation.
A "software forced reload" may occur after configuring an FTC trunk. The process to recreate the problem is:
1. Configure an FTC trunk. Do not configure "snmp-server enable traps svplus."
2. Configure 100 Frame Relay PVCs.
3. Repeatedly shut down and bring back up the FTC trunk (30 times is enough).
4. Delete PVCs and unconfigure the FTC trunk.
5. Configure FTC and issue the command "snmp-server enable traps svplus."
You will see the following messages: "%Software-forced reload" and "Preparing to dump core... Check heaps."
There is no workaround except to manually reload the software after performing the repeated shutdown and no shutdown sequence or to entirely avoid doing that.
When two routes are available for trunk traffic and one fails, the other cannot be made the backup to the first. This occurs when one route is over an FTC trunk and the other is over a serial port. The workaround is not to use routed backup for FTC operation.
When an SVC connection of an FXS to FXS call is disconnected by the remote FXS station hanging up and the local FXS is left off hook, the off hook circuit should time out and return dial-tone. The circuit is now returning a loud tone.
This becomes an issue when one of the FXS circuits is acting as a loop start Trunk to a PBX. When the call is automatically routed in the PBX to a Voice-Mail such as an Octel, the mail box records the tone as voice (a very long mono tone message).
The 'dlsw remote-peer' command will not accept 'switch0' as the destination for the command. There is no workaround.
An FXO ground-start configured C3801 does not detect incoming seizure when only tip-ground is applied by the PBX. Seizure is only detected if ring-voltage is applied.
A show controller e1 indicates that the line is 'unbalanced' whereas it is actually 'balanced'. This is a display inaccuracy only.
When performing a 'net boot' of the software, it is possible to get into a state in which a 'net boot' will not succeed thereafter.
If the net boot procedure encounters 'out of order' packets and finally times out, then the following attempts to repeat the net boot never seem to work. Power cycle and the reset button clear the condition until the next time. This is an intermittent failure in the sense that the 'out of order' packet condition is not easily reproducible.
Note that the true effect of this bug can be a very long boot up time (on the order of 10-20 minutes). If a netboot attempt fails because of this 'out-of-order' problem, IOS will eventually attempt the next boot configuration line if it exists.
A workaround is to configure multiple 'boot system from the net' lines so that more attempts to do the net boot will be made. They should succeed unless the network is in a dreadful state. Ultimately the algorithm reverts to attempting a boot from the first image in flash.
So, to ensure multiple attempts at net booting, configure multiple 'boot system from the net' lines. Note that each boot system line must refer to a different image name (which can be links to the same image).
When you change the coder type and then you do a reload, the display within the sh voice port command is incorrect for the coder type. It still shows the previous one upon the first call.
The interrupt counters AIS16 and API, shown in the "show controllers t1 | e1" display don't get cleared by "clear controller t1 | e1".
On an FTC trunk, DLCIs assigned for use are not deleted until the system is re-booted. New DLCI assignments operate correctly and no error effects occur in this case. DLCIs will remain in the system but cause no problem.
When you do "show interface s0/x" where s0/x is ftc trunk, it always shows non-empty input queue statistics which is misleading. Normally it shows:
Output queue 0/40, 0 drops; input queue 6/75, 0 drops
If a session trunk is added, input queue count increased by about 6.
The E1 "show controller e1" command gives erroneous information pertaining to the line impedance. It shows: Applique type is Channelized E1 - unbalanced when the line impedance is 120 ohms and Applique type is Channelized E1 - balanced when the line impedance is 75 ohms. This is backwards, 75 ohm is unbalanced and 120 ohms is balanced. Later on in the display the actual line impedance is given and this is correct.
The portion of the "show controller t1|e1" display which shows the interrupt counters contains non-applicable information.
The same display is used for both T1 and E1. Most of the fields are applicable to both. Some are applicable to only T1 and others only to E1. The display is not automatically adjusted to display only T1 fields when in T1 mode and E1 fields only when in E1 mode.
The 'M' lead on pin 2 is still active on an FXS circuit. If pins 1 & 2 are connected and become shorted, dial tone will be returned on tip and ring (pins 4 & 5). Correct wiring will not allow this to occur.
PVC operation using Ground Start procedure does not operate correctly. The workaround is to use SVC operation.
The voice port selection DIP switches may be set in an invalid combination which can cause associated resistors to overheat and fail. In both SW1 and SW2, switches 3 and 6 should not be set to ON at the same time.

Important Software Caveats for Release 11.2(10)P

Issuing the command "show connection-table" displays voice soft PVCs (connections from voice port to voice port) but the status of the connection does not include PNNI status.The status may be "OK," meaning the syntax is fine and the original port is fine, yet the connection to the remote voice port may not be established. The user can enter "show call-controller call" to see the PNNI status and the ATM endpoint address of the original voice interface.
See related caveat CSCdi88101.
When the serial interface is configured with encapsulation SDLC, it is not tracking the correct control lead coming from the DTE. Currently the interface goes up/up if the DTE raises RTS, the interface needs to track DTR and go up/up when DTR is raised.
Currently when the encapsulation on the serial interface is sdlc the RTS lead must be held high for the interface to stay line up protocol up. The other work around is to use the configuration to ignore the control signals altogether.
When a serial port is configured to encapsulation ftc-trunk, the interface does not go down when DTR is dropped. This can be seen by running 2 units back-to-back and then by pulling the cable or doing a shut at the other end.
Although the interface stays up, the ftc-trunk protocol is robust enough to reset the connections and restart communications when it detects that it is no longer in contact with the other end.
Issuing the command "show connection-table connection-number" displays cell and frame drop counters for cells and frames dropped in the switch. Counters display for data connections and for voice PVCs. These counters need to be added for voice port soft PVCs.
See related caveat CSCdi85966.
The software only reads some of the switches, and cannot validate that all switches are set correctly. It displays the selected settings based on just a few of the switches. It is important, therefore, to check that all switches are fully switched into the correct position. It is a good idea, with rocker switches, to put them into the desired position and then push them once more just to be sure they carefully depressed.
The hardware only provides 2 switches for software to read:sw1-1 (75/120 ohm) and sw1-2 (T1 or E1). Thus the software cannot detect any invalid combinations of any other switches. As a result, it is important to redoubly verify the settings of the switches, and insure that they are firmly positioned at the desired setting.
An FXS to FXS call must be configured for voice ports using the same coder. Different coder selections on each end of the circuit will not operate correctly.
When using DTMF dialing with echo canceller and non-linear processing enabled, there is minor echo in initial digit input, falling off to very little echo after first 1 or 2 digits input. Also, there is very minor echo in the audio when input and output gains are set to 0. This echo in audio can be eliminated by setting input gain to -6dB and output gain to -9dB.
.The amount of free memory will slowly diminish over time. It takes at least 5 weeks for memory to deplete in a very active network.
The memory leak is in the code that builds the dial parser. As a result, each time the dial plan is altered about 100 bytes are lost. In a very active network, where nodes are added and deleted, or when the dial plan configuration is changed often, this loss will occur more often. Commands such as group or destination will cause the problem.
The workaround is to reload the box manually once every 5 weeks, or less often if the network is not as active.
The 3801 cannot be configured with a 'statsmaster' parameter to tell it which of the potentially many StrataView+ stations that have access to it is the one which it is allowed to accept and respond to statsfile updates. The user must be sure not to send conflicting statsfile info.
When the PNNI controller attempts to re-route a call, it does not examine the actual available bandwidth on the ftc trunk session-trunk to determine if there is sufficient room to add the call. This can cause a call to be tried and then rejected due to lack of bandwidth and it will not be tried out another path that has sufficient bandwidth. The workaround is to provision sufficient bandwidth.
When a voice port is configured for coder csacelp, DTMF tones can be corrupted to the point that they appear to be multiples of the digit entered. Digits 1, 4 and 5 exhibit this problem, other digits are OK.
This problem is observed as measured by a digit grabber test device but the digits are recognized and accepted by both the A.T.&T. PBX and the Rolm 9200 PBX.
Indication is that there may be some installations which would be sensitive to the corruption of these tones due to variations in PBX capabilities.
If a problem is experienced with passing DTMF tones through the 3801 network, then LD-CELP or some other coder should be selected.
When configured for fax-relay operation over CSACELP at a rate of 9600bps, the fax will fall back to 7200bps when the line is clean and should support the full 9600bps rate.
When a connection on an ftc-trunk is torn down, the statistics associated with the connection-id are not cleared. These statistics are displayed using the command show connection
The "Ground Start" operation does not function for PVC connections. This operation is intended to be supported using a translated signalling type only for FXS-to-FXO connectivity. Even this configuration does not work. Only SVC circuits are operational for Ground Start operation.
Many configuration options for voice calls activate only after you create a circuit using the "connect" command for PVCs, the "svc" command for SVCs, or after you reboot the Cisco 3801 system. The following voice port options are affected:

  • Call processing tones

  • Dial type

  • Echo cancellation

  • E&M configuration

  • Generate noise

  • Timing

  • Voice Activity Detect

For PVCs, the following options also become active only after the next circuit is created. For SVCs they take effect after the next outgoing call is placed:

  • Dial peer

  • Coder

  • Fax Relay

Addition of a connection on the c3801 using an odd connection id silently utilized by a voice pvc connection is allowed. After the connection is added telephony on that c3801 no longer functions.
A c3801 'reload' is necessary to get the 2 way voice functionality on the voice pvc connection working again. Merely removing the violating connection does not bring back voice functionality.
When configured for SPVC operation, if an FTC trunk is repeatedly created and then deleted, eventually the system may encounter a "software forced reload".
The workaround is that after many times creating and deleting an FTC trunk, manually reload the software before proceeding in production operation.
A "software forced reload" may occur after configuring an FTC trunk. The process to recreate the problem is:
1. Configure an FTC trunk. Do not configure "snmp-server enable traps svplus."
2. Configure 100 Frame Relay PVCs.
3. Repeatedly shut down and bring back up the FTC trunk (30 times is enough).
4. Delete PVCs and unconfigure the FTC trunk.
5. Configure FTC and issue the command "snmp-server enable traps svplus."
You will see the following messages: "%Software-forced reload" and "Preparing to dump core... Check heaps."
There is no workaround except to manually reload the software after performing the repeated shutdown and no shutdown sequence or to entirely avoid doing that.
If a 3801 is added to a network to replace another one, it will distribute its PNNI call database using its own MAC address. Other nodes will adjust their database to reflect the new node added to the network. However, they will still have the same call destination patterns recorded in their database from the previous node's operation only under it's MAC address.
A call to that destination pattern then will be sent to the old node's MAC address and will fail to match. This will continue until the PNNI entry for the old node is removed from the database by automatic 'aging out' process. This can take up to 40 minutes. After that, a call to the destination will succeed.
There is no workaround, although it is possible in a small network to manually reset the nodes, causing them to re-build their databases.
When two routes are available for trunk traffic and one fails, the other cannot be made the backup to the first. This occurs when one route is over an FTC trunk and the other is over a serial port. The workaround is not to use routed backup for FTC operation.
When an SVC connection of an FXS to FXS call is disconnected by the remote FXS station hanging up and the local FXS is left off hook, the off hook circuit should time out and return dial-tone. The circuit is now returning a loud tone.
This becomes an issue when one of the FXS circuits is acting as a loop start Trunk to a PBX. When the call is automatically routed in the PBX to a Voice-Mail such as an Octel, the mail box records the tone as voice (a very long mono tone message).
The 'dlsw remote-peer' command will not accept 'switch0' as the destination for the command. There is no workaround.
An FXO ground-start configured C3801 does not detect incoming seizure when only tip-ground is applied by the PBX. Seizure is only detected if ring-voltage is applied.
A session trunk configured with a connection id of 250 and above is not displayed in the C3801's running configuration. The 'show running' command was done immediately following the 'ftc-trunk session-trunk connection-id 'was completed on the FTC trunk port.
When you try to add the same (undisplayed) session trunk conn id's you get the following error message:
*Mar 1 16:24:44: %FTC_TRUNK-3-CID_IN_USE: Serial0/3 connection-id 250 is busy, try other cidftc
However, when you do a 'show interface s0/3 ftc' the connection-id's are displayed in this status output.
Note Connection-id 252 is not displayed in both the 'show running' and 'show interface s0/3 ftc' command output.
A show controller e1 indicates that the line is 'unbalanced' whereas it is actually 'balanced'. This is a display inaccuracy only.
When performing a 'net boot' of the software, it is possible to get into a state in which a 'net boot' will not succeed thereafter.
If the net boot procedure encounters 'out of order' packets and finally times out, then the following attempts to repeat the net boot never seem to work. Power cycle and the reset button clear the condition until the next time. This is an intermittent failure in the sense that the 'out of order' packet condition is not easily reproducible.
Note that the true effect of this bug can be a very long boot up time (on the order of 10-20 minutes). If a netboot attempt fails because of this 'out-of-order' problem, IOS will eventually attempt the next boot configuration line if it exists.
A workaround is to configure multiple 'boot system from the net' lines so that more attempts to do the net boot will be made. They should succeed unless the network is in a dreadful state. Ultimately the algorithm reverts to attempting a boot from the first image in flash.
So, to ensure multiple attempts at net booting, configure multiple 'boot system from the net' lines. Note that each boot system line must refer to a different image name (which can be links to the same image).
When you change the coder type and then you do a reload, the display within the sh voice port command is incorrect for the coder type. It still shows the previous one upon the first call.
The interrupt counters AIS16 and API, shown in the "show controllers t1 | e1" display don't get cleared by "clear controller t1 | e1".
On an FTC trunk, DLCIs assigned for use are not deleted until the system is re-booted. New DLCI assignments operate correctly and no error effects occur in this case. DLCIs will remain in the system but cause no problem.
When you do "show interface s0/x" where s0/x is ftc trunk, it always shows non-empty input queue statistics which is misleading. Normally it shows:
Output queue 0/40, 0 drops; input queue 6/75, 0 drops
If a session trunk is added, input queue count increased by about 6.
The E1 "show controller e1" command gives erroneous information pertaining to the line impedance. It shows: Applique type is Channelized E1 - unbalanced when the line impedance is 120 ohms and Applique type is Channelized E1 - balanced when the line impedance is 75 ohms. This is backwards, 75 ohm is unbalanced and 120 ohms is balanced. Later on in the display the actual line impedance is given and this is correct.
The portion of the "show controller t1|e1" display which shows the interrupt counters contains non-applicable information.
The same display is used for both T1 and E1. Most of the fields are applicable to both. Some are applicable to only T1 and others only to E1. The display is not automatically adjusted to display only T1 fields when in T1 mode and E1 fields only when in E1 mode.
The 'M' lead on pin 2 is still active on an FXS circuit. If pins 1 & 2 are connected and become shorted, dial tone will be returned on tip and ring (pins 4 & 5). Correct wiring will not allow this to occur.
PVC operation using Ground Start procedure does not operate correctly. The workaround is to use SVC operation.
The voice port selection DIP switches may be set in an invalid combination which can cause associated resistors to overheat and fail. In both SW1 and SW2, switches 3 and 6 should not be set to ON at the same time.

Important Software Caveats for Release 11.2(9)P

Issuing the command "show connection-table" displays voice soft PVCs (connections from voice port to voice port) but the status of the connection does not include PNNI status.The status may be "OK," meaning the syntax is fine and the original port is fine, yet the connection to the remote voice port may not be established. The user can enter "show call-controller call" to see the PNNI status and the ATM endpoint address of the original voice interface.
See related caveat CSCdi88101.
When the serial interface is configured with encapsulation SDLC, it is not tracking the correct control lead coming from the DTE. Currently the interface goes up/up if the DTE raises RTS, the interface needs to track DTR and go up/up when DTR is raised.
Currently when the encapsulation on the serial interface is sdlc the RTS lead must be held high for the interface to stay line up protocol up. The other work around is to use the configuration to ignore the control signals altogether.
When a serial port is configured to encapsulation ftc-trunk, the interface does not go down when DTR is dropped. This can be seen by running 2 units back-to-back and then by pulling the cable or doing a shut at the other end.
Although the interface stays up, the ftc-trunk protocol is robust enough to reset the connections and restart communications when it detects that it is no longer in contact with the other end.
Issuing the command "show connection-table connection-number" displays cell and frame drop counters for cells and frames dropped in the switch. Counters display for data connections and for voice PVCs. These counters need to be added for voice port soft PVCs.
See related caveat CSCdi85966.
The LMI on the FTC trunk is not started correctly when the unit starts up using the stored configuration, or when the interface is given the "encaps ftc-trunk" command. It is necessary to issue a "shutdown" and then a "no shutdown" in order to get the LMI to start working.
This problem started in 11.2(8.1)P due to some changes in the frame relay LMI initialization code. It is in all subsequent releases until it is fixed in 11.2(9.4)P and 11.2(10)P.
The software only reads some of the switches, and cannot validate that all switches are set correctly. It displays the selected settings based on just a few of the switches. It is important, therefore, to check that all switches are fully switched into the correct position. It is a good idea, with rocker switches, to put them into the desired position and then push them once more just to be sure they carefully depressed.
The hardware only provides 2 switches for software to read:sw1-1 (75/120 ohm) and sw1-2 (T1 or E1). Thus the software cannot detect any invalid combinations of any other switches. As a result, it is important to redoubly verify the settings of the switches, and insure that they are firmly positioned at the desired setting.
An FXS to FXS call must be configured for voice ports using the same coder. Different coder selections on each end of the circuit will not operate correctly.
When using DTMF dialing with echo canceller and non-linear processing enabled, there is minor echo in initial digit input, falling off to very little echo after first 1 or 2 digits input. Also, there is very minor echo in the audio when input and output gains are set to 0. This echo in audio can be eliminated by setting input gain to -6dB and output gain to -9dB.
.The amount of free memory will slowly diminish over time. It takes at least 5 weeks for memory to deplete in a very active network.
The memory leak is in the code that builds the dial parser. As a result, each time the dial plan is altered about 100 bytes are lost. In a very active network, where nodes are added and deleted, or when the dial plan configuration is changed often, this loss will occur more often. Commands such as group or destination will cause the problem.
The workaround is to reload the box manually once every 5 weeks, or less often if the network is not as active.
The 3801 cannot be configured with a 'statsmaster' parameter to tell it which of the potentially many StrataView+ stations that have access to it is the one which it is allowed to accept and respond to statsfile updates. The user must be sure not to send conflicting statsfile info.
When the PNNI controller attempts to re-route a call, it does not examine the actual available bandwidth on the ftc trunk session-trunk to determine if there is sufficient room to add the call. This can cause a call to be tried and then rejected due to lack of bandwidth and it will not be tried out another path that has sufficient bandwidth. The workaround is to provision sufficient bandwidth.
When a voice port is configured for coder csacelp, DTMF tones can be corrupted to the point that they appear to be multiples of the digit entered. Digits 1, 4 and 5 exhibit this problem, other digits are OK.
This problem is observed as measured by a digit grabber test device but the digits are recognized and accepted by both the A.T.&T. PBX and the Rolm 9200 PBX.
Indication is that there may be some installations which would be sensitive to the corruption of these tones due to variations in PBX capabilities.
If a problem is experienced with passing DTMF tones through the 3801 network, then LD-CELP or some other coder should be selected.
When an SVC call refers to a dial-peer that does not reference a voice port, the call will be placed with the default coder rather than the coder specified in the dial-peer. The dial-peer must specify a voice-port.
When configured for fax-relay operation over CSACELP at a rate of 9600bps, the fax will fall back to 7200bps when the line is clean and should support the full 9600bps rate.
When a connection on an ftc-trunk is torn down, the statistics associated with the connection-id are not cleared. These statistics are displayed using the command show connection
The "Ground Start" operation does not function for PVC connections. This operation is intended to be supported using a translated signalling type only for FXS-to-FXO connectivity. Even this configuration does not work. Only SVC circuits are operational for Ground Start operation.
For a PVC connection, the status displayed in a 'show voice port' for the on-hook or off-hook condition is not updated correctly but always shows off-hook.
Many configuration options for voice calls activate only after you create a circuit using the "connect" command for PVCs, the "svc" command for SVCs, or after you reboot the Cisco 3801 system. The following voice port options are affected:

  • Call processing tones

  • Dial type

  • Echo cancellation

  • E&M configuration

  • Generate noise

  • Timing

  • Voice Activity Detect

For PVCs, the following options also become active only after the next circuit is created. For SVCs they take effect after the next outgoing call is placed:

  • Dial peer

  • Coder

  • Fax Relay

Addition of a connection on the c3801 using an odd connection id silently utilized by a voice pvc connection is allowed. After the connection is added telephony on that c3801 no longer functions.
A c3801 'reload' is necessary to get the 2 way voice functionality on the voice pvc connection working again. Merely removing the violating connection does not bring back voice functionality.
When configured for SPVC operation, if an FTC trunk is repeatedly created and then deleted, eventually the system may encounter a "software forced reload".
The workaround is that after many times creating and deleting an FTC trunk, manually reload the software before proceeding in production operation.
After configuring an FTC trunk and an SPVC connection, then deleting these configurations, the next time the FTC trunk is configured, the system may encounter a message "Sparc process not responding, reloading". The failure may occur after one such sequence or after a number of similar sequences of commands. This will only occur if the operator has not saved the configuration yet.
The workaround is to update the configuration changes immediately by entering a 'write mem'. The problem will not occur after that.
A "software forced reload" may occur after configuring an FTC trunk. The process to recreate the problem is:
1. Configure an FTC trunk. Do not configure "snmp-server enable traps svplus."
2. Configure 100 Frame Relay PVCs.
3. Repeatedly shut down and bring back up the FTC trunk (30 times is enough).
4. Delete PVCs and unconfigure the FTC trunk.
5. Configure FTC and issue the command "snmp-server enable traps svplus."
You will see the following messages: "%Software-forced reload" and "Preparing to dump core... Check heaps."
There is no workaround except to manually reload the software after performing the repeated shutdown and no shutdown sequence or to entirely avoid doing that.
If a 3801 is added to a network to replace another one, it will distribute its PNNI call database using its own MAC address. Other nodes will adjust their database to reflect the new node added to the network. However, they will still have the same call destination patterns recorded in their database from the previous node's operation only under it's MAC address.
A call to that destination pattern then will be sent to the old node's MAC address and will fail to match. This will continue until the PNNI entry for the old node is removed from the database by automatic 'aging out' process. This can take up to 40 minutes. After that, a call to the destination will succeed.
There is no workaround, although it is possible in a small network to manually reset the nodes, causing them to re-build their databases.
When two routes are available for trunk traffic and one fails, the other cannot be made the backup to the first. This occurs when one route is over an FTC trunk and the other is over a serial port. The workaround is not to use routed backup for FTC operation.
When an SVC connection of an FXS to FXS call is disconnected by the remote FXS station hanging up and the local FXS is left off hook, the off hook circuit should time out and return dial-tone. The circuit is now returning a loud tone.
This becomes an issue when one of the FXS circuits is acting as a loop start Trunk to a PBX. When the call is automatically routed in the PBX to a Voice-Mail such as an , the mail box records the tone as voice (a very long mono tone message).
The 'dlsw remote-peer' command will not accept 'switch0' as the destination for the command. There is no workaround.
An FXO ground-start configured C3801 does not detect incoming seizure when only tip-ground is applied by the PBX. Seizure is only detected if ring-voltage is applied.
A session trunk configured with a connection id of 250 and above is not displayed in the C3801's running configuration. The 'show running' command was done immediately following the 'ftc-trunk session-trunk connection-id 'was completed on the FTC trunk port.
When you try to add the same (undisplayed) session trunk conn id's you get the following error message:
*Mar 1 16:24:44: %FTC_TRUNK-3-CID_IN_USE: Serial0/3 connection-id 250 is busy, try other cid
However, when you do a 'show interface s0/3 ftc' the connection-id's are displayed in this status output.
Note Connection-id 252 is not displayed in both the 'show running' and 'show interface s0/3 ftc' command output.
By default, the bandwidth parameter is set to 1544 for a serial port, the value observed in a sh int s0/x. However it seems that this is not the case. When you try to make a svc voice call with adpcm32k it does not work except if you set the Parameter Bandw to a random value whatever it is (even lower than 32). If you do not, the calling site gets a dsp crash.
When a new sparc image is loaded into a running system (IE by a crash or reload) There may still be parts of the previous code image in the sparc instruction cache. This can cause a system crash or erratic behavior.
This will occur when a new different image is loaded into flash and then a reload is done (if the new image contains different Sparc code, 11.2(7)P, 11.2(8)P and 11.2(9)P all have different sparc code, so upgrading between them may run into this problem.
The workaround is to load the new image into flash and then power down the unit before attempting to reload with the new software. This will be fixed in 11.2(10)P, so an upgrade to 11.2(10)P will not require this step.
This may also occur if the boot helper image used during netboot is not the standard c3801 boot helper image. Only the standard c3801 boot helper image should be used as the boot helper during netboot.
A show controller e1 indicates that the line is 'unbalanced' whereas it is actually 'balanced'. This is a display inaccuracy only.
When performing a 'net boot' of the software, it is possible to get into a state in which a 'net boot' will not succeed thereafter.
If the net boot procedure encounters 'out of order' packets and finally times out, then the following attempts to repeat the net boot never seem to work. Power cycle and the reset button clear the condition until the next time. This is an intermittent failure in the sense that the 'out of order' packet condition is not easily reproducible.
Note that the true effect of this bug can be a very long boot up time (on the order of 10-20 minutes). If a netboot attempt fails because of this 'out-of-order' problem, IOS will eventually attempt the next boot configuration line if it exists.
A workaround is to configure multiple 'boot system from the net' lines so that more attempts to do the net boot will be made. They should succeed unless the network is in a dreadful state. Ultimately the algorithm reverts to attempting a boot from the first image in flash.
So, to ensure multiple attempts at net booting, configure multiple 'boot system from the net' lines. Note that each boot system line must refer to a different image name (which can be links to the same image).
When a 'show voice port ' command is entered, the display is not controlled correctly by the '-more-' process, causing some lines to scroll off the screen.
The workaround is to use an Xterm display and manually scroll back or to use the CTRL-Q and CTRL-S function keys to control the display.
When you change the coder type and then you do a reload, the display within the sh voice port command is incorrect for the coder type. It still shows the previous one upon the first call.
The interrupt counters AIS16 and API, shown in the "show controllers t1 | e1" display don't get cleared by "clear controller t1 | e1".
On an FTC trunk, DLCIs assigned for use are not deleted until the system is re-booted. New DLCI assignments operate correctly and no error effects occur in this case. DLCIs will remain in the system but cause no problem.
When you do "show interface s0/x" where s0/x is ftc trunk, it always shows non-empty input queue statistics which is misleading. Normally it shows:
Output queue 0/40, 0 drops; input queue 6/75, 0 drops
If a session trunk is added, input queue count increased by about 6.
The E1 "show controller e1" command gives erroneous information pertaining to the line impedance. It shows: Applique type is Channelized E1 - unbalanced when the line impedance is 120 ohms and Applique type is Channelized E1 - balanced when the line impedance is 75 ohms. This is backwards, 75 ohm is unbalanced and 120 ohms is balanced. Later on in the display the actual line impedance is given and this is correct.
The portion of the "show controller t1|e1" display which shows the interrupt counters contains non-applicable information.
The same display is used for both T1 and E1. Most of the fields are applicable to both. Some are applicable to only T1 and others only to E1. The display is not automatically adjusted to display only T1 fields when in T1 mode and E1 fields only when in E1 mode.
The 'M' lead on pin 2 is still active on an FXS circuit. If pins 1 & 2 are connected and become shorted, dial tone will be returned on tip and ring (pins 4 & 5). Correct wiring will not allow this to occur.
PVC operation using Ground Start procedure does not operate correctly. The workaround is to use SVC operation.
The voice port selection DIP switches may be set in an invalid combination which can cause associated resistors to overheat and fail. In both SW1 and SW2, switches 3 and 6 should not be set to ON at the same time.

Important Software Caveats for Release 11.2(8)P

When configuring a dial-peer group to use a destination pattern, it must be configured completely for each port configured and may not use a previously configured group without including the destination pattern again. An error message will appear indicating the pattern is already in-use. The workaround is to configure the destination pattern for all ports even if the same group is used.
Issuing the command "show connection-table" displays voice soft PVCs (connections from voice port to voice port) but the status of the connection does not include PNNI status.The status may be "OK," meaning the syntax is fine and the original port is fine, yet the connection to the remote voice port may not be established. The user can enter "show call-controller call" to see the PNNI status and the ATM endpoint address of the original voice interface.
See related caveat CSCdi88101.
When the serial interface is configured with encapsulation SDLC, it is not tracking the correct control lead coming from the DTE. Currently the interface goes up/up if the DTE raises RTS, the interface needs to track DTR and go up/up when DTR is raised.
Currently when the encapsulation on the serial interface is sdlc the RTS lead must be held high for the interface to stay line up protocol up. The other work around is to use the configuration to ignore the control signals altogether.
When a serial port is configured to encapsulation ftc-trunk, the interface does not go down when DTR is dropped. This can be seen by running 2 units back-to-back and then by pulling the cable or doing a shut at the other end.
Although the interface stays up, the ftc-trunk protocol is robust enough to reset the connections and restart communications when it detects that it is no longer in contact with the other end.
Issuing the command "show connection-table connection-number" displays cell and frame drop counters for cells and frames dropped in the switch. Counters display for data connections and for voice PVCs. These counters need to be added for voice port soft PVCs.
See related caveat CSCdi85966.
The software only reads some of the switches, and cannot validate that all switches are set correctly. It displays the selected settings based on just a few of the switches. It is important, therefore, to check that all switches are fully switched into the correct position. It is a good idea, with rocker switches, to put them into the desired position and then push them once more just to be sure they carefully depressed.
The hardware only provides 2 switches for software to read:sw1-1 (75/120 ohm) and sw1-2 (T1 or E1). Thus the software cannot detect any invalid combinations of any other switches. As a result, it is important to redoubly verify the settings of the switches, and insure that they are firmly positioned at the desired setting.
An FXS to FXS call must be configured for voice ports using the same coder. Different coder selections on each end of the circuit will not operate correctly.
When using DTMF dialing with echo canceller and non-linear processing enabled, there is minor echo in initial digit input, falling off to very little echo after first 1 or 2 digits input. Also, there is very minor echo in the audio when input and output gains are set to 0. This echo in audio can be eliminated by setting input gain to -6dB and output gain to -9dB.
.The amount of free memory will slowly diminish over time. It takes at least 5 weeks for memory to deplete in a very active network.
The memory leak is in the code that builds the dial parser. As a result, each time the dial plan is altered about 100 bytes are lost. In a very active network, where nodes are added and deleted, or when the dial plan configuration is changed often, this loss will occur more often. Commands such as group or destination will cause the problem.
The workaround is to reload the box manually once every 5 weeks, or less often if the network is not as active.
The 3801 cannot be configured with a 'statsmaster' parameter to tell it which of the potentially many StrataView+ stations that have access to it is the one which it is allowed to accept and respond to statsfile updates. The user must be sure not to send conflicting statsfile info.
When the PNNI controller attempts to re-route a call, it does not examine the actual available bandwidth on the ftc trunk session-trunk to determine if there is sufficient room to add the call. This can cause a call to be tried and then rejected due to lack of bandwidth and it will not be tried out another path that has sufficient bandwidth. The workaround is to provision sufficient bandwidth.
When a voice port is configured for coder csacelp, DTMF tones can be corrupted to the point that they appear to be multiples of the digit entered. Digits 1, 4 and 5 exhibit this problem, other digits are OK.
This problem is observed as measured by a digit grabber test device but the digits are recognized and accepted by both the A.T.&T. PBX and the Rolm 9200 PBX.
Indication is that there may be some installations which would be sensitive to the corruption of these tones due to variations in PBX capabilities.
If a problem is experienced with passing DTMF tones through the 3801 network, then LD-CELP or some other coder should be selected.
When an SVC call refers to a dial-peer that does not reference a voice port, the call will be placed with the default coder rather than the coder specified in the dial-peer. The dial-peer must specify a voice-port.
When configured for fax-relay operation over CSACELP at a rate of 9600bps, the fax will fall back to 7200bps when the line is clean and should support the full 9600bps rate.
When a connection on an ftc-trunk is torn down, the statistics associated with the connection-id are not cleared. These statistics are displayed using the command show connection
The "Ground Start" operation does not function for PVC connections. This operation is intended to be supported using a translated signalling type only for FXS-to-FXO connectivity. Even this configuration does not work. Only SVC circuits are operational for Ground Start operation.
For a PVC connection, the status displayed in a 'show voice port' for the on-hook or off-hook condition is not updated correctly but always shows off-hook.
When configured for SVC operation and a continuous sequence of call setup followed by call teardown is generated at a very high rate, approximately 800 calls per hour, after approximately 30 hours of operation, one of two failures may occur. The likelihood of occurrence is dependent on the rate of calls and the duration of continuous calls at that rate, but it is possible that the failures will never occur.
The failures are:

  • 1) an error message referencing an "xp_balloc" failure is output and then a software forced reload occurs;

  • 2) the voice port stops transferring audio data but the call remains up.

There are no workarounds to these failures except to operate the system under more normal conditions of low call rate. The only likely situation under which these failures would be seen is in a test lab environment.
Many configuration options for voice calls activate only after you create a circuit using the "connect" command for PVCs, the "svc" command for SVCs, or after you reboot the Cisco 3801 system. The following voice port options are affected:

  • Call processing tones

  • Dial type

  • Echo cancellation

  • E&M configuration

  • Generate noise

  • Timing

  • Voice Activity Detect

For PVCs, the following options also become active only after the next circuit is created. For SVCs they take effect after the next outgoing call is placed:

  • Dial peer

  • Coder

  • Fax Relay

Addition of a connection on the c3801 using an odd connection id silently utilized by a voice pvc connection is allowed. After the connection is added telephony on that c3801 no longer functions.
A c3801 'reload' is necessary to get the 2 way voice functionality on the voice pvc connection working again. Merely removing the violating connection does not bring back voice functionality.
When configured for SPVC operation, if an FTC trunk is repeatedly created and then deleted, eventually the system may encounter a "software forced reload".
The workaround is that after many times creating and deleting an FTC trunk, manually reload the software before proceeding in production operation.
It is possible to encounter a "software forced reload" or other erratic behavior during operation after re-configuring a system from PVC operation to SVC operation. The change will take effect properly and operate for a period, sometimes for a long period, on the order of hours or days, other times for a short period more like a few minutes to an hour.
The workaround for this failure is that after making this type of change to configuration of voice operation, manually reload the system.
After configuring an FTC trunk and an SPVC connection, then deleting these configurations, the next time the FTC trunk is configured, the system may encounter a message "Sparc process not responding, reloading". The failure may occur after one such sequence or after a number of similar sequences of commands. This will only occur if the operator has not saved the configuration yet.
The workaround is to update the configuration changes immediately by entering a 'write mem'. The problem will not occur after that.
A "software forced reload" may occur after configuring an FTC trunk. The process to recreate the problem is:
1. Configure an FTC trunk. Do not configure "snmp-server enable traps svplus."
2. Configure 100 Frame Relay PVCs.
3. Repeatedly shut down and bring back up the FTC trunk (30 times is enough).
4. Delete PVCs and unconfigure the FTC trunk.
5. Configure FTC and issue the command "snmp-server enable traps svplus."
You will see the following messages: "%Software-forced reload" and "Preparing to dump core... Check heaps."
There is no workaround except to manually reload the software after performing the repeated shutdown and no shutdown sequence or to entirely avoid doing that.
If a 3801 is added to a network to replace another one, it will distribute its PNNI call database using its own MAC address. Other nodes will adjust their database to reflect the new node added to the network. However, they will still have the same call destination patterns recorded in their database from the previous node's operation only under it's MAC address.
A call to that destination pattern then will be sent to the old node's MAC address and will fail to match. This will continue until the PNNI entry for the old node is removed from the database by automatic 'aging out' process. This can take up to 40 minutes. After that, a call to the destination will succeed.
There is no workaround, although it is possible in a small network to manually reset the nodes, causing them to re-build their databases.
When two routes are available for trunk traffic and one fails, the other cannot be made the backup to the first. This occurs when one route is over an FTC trunk and the other is over a serial port. The workaround is not to use routed backup for FTC operation.
For T1 the transmit pulse shape is defined by ITU-T.G.703. Because of attenuation introduced by varying cable lengths the c3801 may not always provide the correct waveform. Although the waveform is not in spec, as measured by test equipment, it does not seem to cause any problems in actual customer use.
When an SVC connection of an FXS to FXS call is disconnected by the remote FXS station hanging up and the local FXS is left off hook, the off hook circuit should time out and return dial-tone. The circuit is now returning a loud tone.
This becomes an issue when one of the FXS circuits is acting as a loop start Trunk to a PBX. When the call is automatically routed in the PBX to a Voice-Mail such as an Octel, the mail box records the tone as voice (a very long mono tone message).
The 'dlsw remote-peer' command will not accept 'switch0' as the destination for the command. There is no workaround.
An FXO ground-start configured C3801 does not detect incoming seizure when only tip-ground is applied by the PBX. Seizure is only detected if ring-voltage is applied.
A session trunk configured with a connection id of 250 and above is not displayed in the C3801's running configuration. The 'show running' command was done immediately following the 'ftc-trunk session-trunk connection-id 'was completed on the FTC trunk port.
When you try to add the same (undisplayed) session trunk conn id's you get the following error message:
*Mar 1 16:24:44: %FTC_TRUNK-3-CID_IN_USE: Serial0/3 connection-id 250 is busy, try other cid
However, when you do a 'show interface s0/3 ftc' the connection-id's are displayed in this status output.
Note Connection-id 252 is not displayed in both the 'show running' and 'show interface s0/3 ftc' command output.
By default, the bandwidth parameter is set to 1544 for a serial port, the value observed in a sh int s0/x. However it seems that this is not the case. When you try to make a svc voice call with adpcm32k it does not work except if you set the Parameter Bandw to a random value whatever it is (even lower than 32). If you do not, the calling site gets a dsp crash.
When a new sparc image is loaded into a running system (IE by a crash or reload) There may still be parts of the previous code image in the sparc instruction cache. This can cause a system crash or erratic behavior.
This will occur when a new different image is loaded into flash and then a reload is done (if the new image contains different Sparc code, 11.2(7)P, 11.2(8)P and 11.2(9)P all have different sparc code, so upgrading between them may run into this problem.
The workaround is to load the new image into flash and then power down the unit before attempting to reload with the new software. This will be fixed in 11.2(10)P, so an upgrade to 11.2(10)P will not require this step.
This may also occur if the boot helper image used during netboot is not the standard c3801 boot helper image. Only the standard c3801 boot helper image should be used as the boot helper during netboot.
Systems Crash when sending large frame relay frames on new data path. After Configuring the Frame Relay port and setting up a connection, frame relay frames over 2000 bytes may cause a crash.
The problem stems from changing the MTU size on a data port while the port is in "shutdown" state. It is important to set a port to "no shutdown" before changing MTU size. An alternate approach is to make the configuration changes for a data port, then do a" write memory" and a reload.
A show controller e1 indicates that the line is 'unbalanced' whereas it is actually 'balanced'. This is a display inaccuracy only.
When performing a 'net boot' of the software, it is possible to get into a state in which a 'net boot' will not succeed thereafter.
If the net boot procedure encounters 'out of order' packets and finally times out, then the following attempts to repeat the net boot never seem to work. Power cycle and the reset button clear the condition until the next time. This is an intermittent failure in the sense that the 'out of order' packet condition is not easily reproducible.
Note that the true effect of this bug can be a very long boot up time (on the order of 10-20 minutes). If a netboot attempt fails because of this 'out-of-order' problem, IOS will eventually attempt the next boot configuration line if it exists.
A workaround is to configure multiple 'boot system from the net' lines so that more attempts to do the net boot will be made. They should succeed unless the network is in a dreadful state. Ultimately the algorithm reverts to attempting a boot from the first image in flash.
So, to ensure multiple attempts at net booting, configure multiple 'boot system from the net' lines. Note that each boot system line must refer to a different image name (which can be links to the same image).
When a 'show voice port ' command is entered, the display is not controlled correctly by the '-more-' process, causing some lines to scroll off the screen.
The workaround is to use an Xterm display and manually scroll back or to use the CTRL-Q and CTRL-S function keys to control the display.
When you change the coder type and then you do a reload, the display within the sh voice port command is incorrect for the coder type. It still shows the previous one upon the first call.
The interrupt counters AIS16 and API, shown in the "show controllers t1 | e1" display don't get cleared by "clear controller t1 | e1".
On an FTC trunk, DLCIs assigned for use are not deleted until the system is re-booted. New DLCI assignments operate correctly and no error effects occur in this case. DLCIs will remain in the system but cause no problem.
When you do "show interface s0/x" where s0/x is ftc trunk, it always shows non-empty input queue statistics which is misleading. Normally it shows:
Output queue 0/40, 0 drops; input queue 6/75, 0 drops
If a session trunk is added, input queue count increased by about 6.
The E1 "show controller e1" command gives erroneous information pertaining to the line impedance. It shows: Applique type is Channelized E1 - unbalanced when the line impedance is 120 ohms and Applique type is Channelized E1 - balanced when the line impedance is 75 ohms. This is backwards, 75 ohm is unbalanced and 120 ohms is balanced. Later on in the display the actual line impedance is given and this is correct.
The portion of the "show controller t1|e1" display which shows the interrupt counters contains non-applicable information.
The same display is used for both T1 and E1. Most of the fields are applicable to both. Some are applicable to only T1 and others only to E1. The display is not automatically adjusted to display only T1 fields when in T1 mode and E1 fields only when in E1 mode.
The 'M' lead on pin 2 is still active on an FXS circuit. If pins 1 & 2 are connected and become shorted, dial tone will be returned on tip and ring (pins 4 & 5). Correct wiring will not allow this to occur.
PVC operation using Ground Start procedure does not operate correctly. The workaround is to use SVC operation.
The voice port selection DIP switches may be set in an invalid combination which can cause associated resistors to overheat and fail. In both SW1 and SW2, switches 3 and 6 should not be set to ON at the same time.

Important Software Caveats for Release 11.2(7)P

When configuring a dial-peer group to use a destination pattern, it must be configured completely for each port configured and may not use a previously configured group without including the destination pattern again. An error message will appear indicating the pattern is already in-use. The workaround is to configure the destination pattern for all ports even if the same group is used.
Issuing the command "show connection-table" displays voice soft PVCs (connections from voice port to voice port) but the status of the connection does not include PNNI status.The status may be "OK," meaning the syntax is fine and the original port is fine, yet the connection to the remote voice port may not be established. The user can enter "show call-controller call" to see the PNNI status and the ATM endpoint address of the original voice interface.
See related caveat CSCdi88101.
When the serial interface is configured with encapsulation SDLC, it is not tracking the correct control lead coming from the DTE. Currently the interface goes up/up if the DTE raises RTS, the interface needs to track DTR and go up/up when DTR is raised.
Currently when the encapsulation on the serial interface is sdlc the RTS lead must be held high for the interface to stay line up protocol up. The other work around is to use the configuration to ignore the control signals altogether.
When a serial port is configured to encapsulation ftc-trunk, the interface does not go down when DTR is dropped. This can be seen by running 2 units back-to-back and then by pulling the cable or doing a shut at the other end.
Although the interface stays up, the ftc-trunk protocol is robust enough to reset the connections and restart communications when it detects that it is no longer in contact with the other end.
Issuing the command "show connection-table connection-number" displays cell and frame drop counters for cells and frames dropped in the switch. Counters display for data connections and for voice PVCs. These counters need to be added for voice port soft PVCs.
See related caveat CSCdi85966.
The software only reads some of the switches, and cannot validate that all switches are set correctly. It displays the selected settings based on just a few of the switches. It is important, therefore, to check that all switches are fully switched into the correct position. It is a good idea, with rocker switches, to put them into the desired position and then push them once more just to be sure they carefully depressed.
The hardware only provides 2 switches for software to read:sw1-1 (75/120 ohm) and sw1-2 (T1 or E1). Thus the software cannot detect any invalid combinations of any other switches. As a result, it is important to redoubly verify the settings of the switches, and insure that they are firmly positioned at the desired setting.
An FXS to FXS call must be configured for voice ports using the same coder. Different coder selections on each end of the circuit will not operate correctly.
When using DTMF dialing with echo canceller and non-linear processing enabled, there is minor echo in initial digit input, falling off to very little echo after first 1 or 2 digits input. Also, there is very minor echo in the audio when input and output gains are set to 0. This echo in audio can be eliminated by setting input gain to -6dB and output gain to -9dB.
.The amount of free memory will slowly diminish over time. It takes at least 5 weeks for memory to deplete in a very active network.
The memory leak is in the code that builds the dial parser. As a result, each time the dial plan is altered about 100 bytes are lost. In a very active network, where nodes are added and deleted, or when the dial plan configuration is changed often, this loss will occur more often. Commands such as group or destination will cause the problem.
The workaround is to reload the box manually once every 5 weeks, or less often if the network is not as active.
The 3801 cannot be configured with a 'statsmaster' parameter to tell it which of the potentially many StrataView+ stations that have access to it is the one which it is allowed to accept and respond to statsfile updates. The user must be sure not to send conflicting statsfile info.
When the PNNI controller attempts to re-route a call, it does not examine the actual available bandwidth on the ftc trunk session-trunk to determine if there is sufficient room to add the call. This can cause a call to be tried and then rejected due to lack of bandwidth and it will not be tried out another path that has sufficient bandwidth. The workaround is to provision sufficient bandwidth.
When a voice port is configured for coder csacelp, DTMF tones can be corrupted to the point that they appear to be multiples of the digit entered. Digits 1, 4 and 5 exhibit this problem, other digits are OK.
This problem is observed as measured by a digit grabber test device but the digits are recognized and accepted by both the A.T.&T. PBX and the Rolm 9200 PBX.
Indication is that there may be some installations which would be sensitive to the corruption of these tones due to variations in PBX capabilities.
If a problem is experienced with passing DTMF tones through the 3801 network, then LD-CELP or some other coder should be selected.
When an SVC call refers to a dial-peer that does not reference a voice port, the call will be placed with the default coder rather than the coder specified in the dial-peer. The dial-peer must specify a voice-port.
When configured for fax-relay operation over CSACELP at a rate of 9600bps, the fax will fall back to 7200bps when the line is clean and should support the full 9600bps rate.
When a connection on an ftc-trunk is torn down, the statistics associated with the connection-id are not cleared. These statistics are displayed using the command show connection
The "Ground Start" operation does not function for PVC connections. This operation is intended to be supported using a translated signalling type only for FXS-to-FXO connectivity. Even this configuration does not work. Only SVC circuits are operational for Ground Start operation.
For a PVC connection, the status displayed in a 'show voice port' for the on-hook or off-hook condition is not updated correctly but always shows off-hook.
When configured for SVC operation and a continuous sequence of call setup followed by call teardown is generated at a very high rate, approximately 800 calls per hour, after approximately 30 hours of operation, one of two failures may occur. The likelihood of occurrence is dependent on the rate of calls and the duration of continuous calls at that rate, but it is possible that the failures will never occur.
The failures are:

  • 1) an error message referencing an "xp_balloc" failure is output and then a software forced reload occurs;

  • 2) the voice port stops transferring audio data but the call remains up.

There are no workarounds to these failures except to operate the system under more normal conditions of low call rate. The only likely situation under which these failures would be seen is in a test lab environment.
Many configuration options for voice calls activate only after you create a circuit using the "connect" command for PVCs, the "svc" command for SVCs, or after you reboot the Cisco 3801 system. The following voice port options are affected:

  • Call processing tones

  • Dial type

  • Echo cancellation

  • E&M configuration

  • Generate noise

  • Timing

  • Voice Activity Detect

For PVCs, the following options also become active only after the next circuit is created. For SVCs they take effect after the next outgoing call is placed:

  • Dial peer

  • Coder

  • Fax Relay

Addition of a connection on the c3801 using an odd connection id silently utilized by a voice pvc connection is allowed. After the connection is added telephony on that c3801 no longer functions.
A c3801 'reload' is necessary to get the 2 way voice functionality on the voice pvc connection working again. Merely removing the violating connection does not bring back voice functionality.
When configured for SPVC operation, if an FTC trunk is repeatedly created and then deleted, eventually the system may encounter a "software forced reload".
The workaround is that after many times creating and deleting an FTC trunk, manually reload the software before proceeding in production operation.
It is possible to encounter a "software forced reload" or other erratic behavior during operation after re-configuring a system from PVC operation to SVC operation. The change will take effect properly and operate for a period, sometimes for a long period, on the order of hours or days, other times for a short period more like a few minutes to an hour.
The workaround for this failure is that after making this type of change to configuration of voice operation, manually reload the system.
After configuring an FTC trunk and an SPVC connection, then deleting these configurations, the next time the FTC trunk is configured, the system may encounter a message "Sparc process not responding, reloading". The failure may occur after one such sequence or after a number of similar sequences of commands. This will only occur if the operator has not saved the configuration yet.
The workaround is to update the configuration changes immediately by entering a 'write mem'. The problem will not occur after that.
When configuring Connectionless Service the Cisco 3801 system spontaneously reboots with a bus-error after entering the "clns route" command. There is no workaround, therefore this feature should be avoided.
A "software forced reload" may occur after configuring an FTC trunk. The process to recreate the problem is:
1. Configure an FTC trunk. Do not configure "snmp-server enable traps svplus."
2. Configure 100 Frame Relay PVCs.
3. Repeatedly shut down and bring back up the FTC trunk (30 times is enough).
4. Delete PVCs and unconfigure the FTC trunk.
5. Configure FTC and issue the command "snmp-server enable traps svplus."
You will see the following messages: "%Software-forced reload" and "Preparing to dump core... Check heaps."
There is no workaround except to manually reload the software after performing the repeated shutdown and no shutdown sequence or to entirely avoid doing that.
When a PVC is configured using a "Connect" statement but there is no "group" statement in any "dial-peer" configuration, then the system encounters a bus-error at the next reboot and must be cleared by defaulting the configuration.
The workaround is to always create a dial-peer with a group setting even for PVC operation.
If a 3801 is added to a network to replace another one, it will distribute its PNNI call database using its own MAC address. Other nodes will adjust their database to reflect the new node added to the network. However, they will still have the same call destination patterns recorded in their database from the previous node's operation only under it's MAC address.
A call to that destination pattern then will be sent to the old node's MAC address and will fail to match. This will continue until the PNNI entry for the old node is removed from the database by automatic 'aging out' process. This can take up to 40 minutes. After that, a call to the destination will succeed.
There is no workaround, although it is possible in a small network to manually reset the nodes, causing them to re-build their databases.
When two routes are available for trunk traffic and one fails, the other cannot be made the backup to the first. This occurs when one route is over an FTC trunk and the other is over a serial port. The workaround is not to use routed backup for FTC operation.
For T1 the transmit pulse shape is defined by ITU-T.G.703. Because of attenuation introduced by varying cable lengths the c3801 may not always provide the correct waveform. Alsthough the waveform is not in spec, as measured by test equipment, it does not seem to cause any problems in actual customer use.
When an SVC connection of an FXS to FXS call is disconnected by the remote FXS station hanging up and the local FXS is left off hook, the off hook circuit should time out and return dial-tone. The circuit is now returning a loud tone.
This becomes an issue when one of the FXS circuits is acting as a loop start Trunk to a PBX. When the call is automatically routed in the PBX to a Voice-Mail such as an Octel, the mail box records the tone as voice (a very long mono tone message).
The 'dlsw remote-peer' command will not accept 'switch0' as the destination for the command. There is no workaround.
An FXO ground-start configured C3801 does not detect incoming seizure when only tip-ground is applied by the PBX. Seizure is only detected if ring-voltage is applied.
A session trunk configured with a connection id of 250 and above is not displayed in the C3801's running configuration. The 'show running' command was done immediately following the 'ftc-trunk session-trunk connection-id 'was completed on the FTC trunk port.
When you try to add the same (undisplayed) session trunk conn id's you get the following error message:
*Mar 1 16:24:44: %FTC_TRUNK-3-CID_IN_USE: Serial0/3 connection-id 250 is busy, try other cidftc
However, when you do a 'show interface s0/3 ftc' the connection-id's are displayed in this status output.
Note Connection-id 252 is not displayed in both the 'show running' and 'show interface s0/3 ftc' command output.
By default, the bandwidth parameter is set to 1544 for a serial port, the value observed in a sh int s0/x. However it seems that this is not the case. When you try to make a svc voice call with adpcm32k it does not work except if you set the Parameter Bandw to a random value whatever it is (even lower than 32). If you do not, the calling site gets a dsp crash.
When a new sparc image is loaded into a running system (IE by a crash or reload) There may still be parts of the previous code image in the sparc instruction cache. This can cause a system crash or erratic behavior.
This will occur when a new different image is loaded into flash and then a reload is done (if the new image contains different Sparc code, 11.2(7)P, 11.2(8)P and 11.2(9)P all have different sparc code, so upgrading between them may run into this problem.
The workaround is to load the new image into flash and then power down the unit before attempting to reload with the new software. This will be fixed in 11.2(10)P, so an upgrade to 11.2(10)P will not require this step.
This may also occur if the boot helper image used during netboot is not the standard c3801 boot helper image. Only the standard c3801 boot helper image should be used as the boot helper during netboot.
Systems Crash when sending large frame relay frames on new data path. After Configuring the Frame Relay port and setting up a connection, frame relay frames over 2000 bytes may cause a crash.
The problem stems from changing the MTU size on a data port while the port is in "shutdown" state. It is important to set a port to "no shutdown" before changing MTU size. An alternate approach is to make the configuration changes for a data port, then do a" write memory" and a reload.
A show controller e1 indicates that the line is 'unbalanced' whereas it is actually 'balanced'. This is a display inaccuracy only.
When performing a 'net boot' of the software, it is possible to get into a state in which a 'net boot' will not succeed thereafter.
If the net boot procedure encounters 'out of order' packets and finally times out, then the following attempts to repeat the net boot never seem to work. Power cycle and the reset button clear the condition until the next time. This is an intermittent failure in the sense that the 'out of order' packet condition is not easily reproducible.
Note that the true effect of this bug can be a very long boot up time (on the order of 10-20 minutes). If a netboot attempt fails because of this 'out-of-order' problem, IOS will eventually attempt the next boot configuration line if it exists.
A workaround is to configure multiple 'boot system from the net' lines so that more attempts to do the net boot will be made. They should succeed unless the network is in a dreadful state. Ultimately the algorithm reverts to attempting a boot from the first image in flash.
So, to ensure multiple attempts at net booting, configure multiple 'boot system from the net' lines. Note that each boot system line must refer to a different image name (which can be links to the same image).
When a 'show voice port ' command is entered, the display is not controlled correctly by the '-more-' process, causing some lines to scroll off the screen.
The workaround is to use an Xterm display and manually scroll back or to use the CTRL-Q and CTRL-S function keys to control the display.
When you change the coder type and then you do a reload, the display within the sh voice port command is incorrect for the coder type. It still shows the previous one upon the first call.
The T1/E1 controller's "Loopback local" command implements a payload loopback.
The Cisco web based documentation calls for the T1/E1 controller's "loopback local" to implement a line loopback.
In addition, in the C3801, the line loopback can be implemented with a jitter attenuator while the payload loopback cannot.
The existing loopback works from a user's perspective, i.e. it passes a bert test and only fails jitter tolerance measurements.
The interrupt counters AIS16 and API, shown in the "show controllers t1 | e1" display don't get cleared by "clear controller t1 | e1".
On an FTC trunk, DLCIs assigned for use are not deleted until the system is re-booted. New DLCI assignments operate correctly and no error effects occur in this case. DLCIs will remain in the system but cause no problem.
When you do "show interface s0/x" where s0/x is ftc trunk, it always shows non-empty input queue statistics which is misleading. Normally it shows:
Output queue 0/40, 0 drops; input queue 6/75, 0 drops
If a session trunk is added, input queue count increased by about 6.
The E1 "show controller e1" command gives erroneous information pertaining to the line impedance. It shows: Applique type is Channelized E1 - unbalanced when the line impedance is 120 ohms and Applique type is Channelized E1 - balanced when the line impedance is 75 ohms. This is backwards, 75 ohm is unbalanced and 120 ohms is balanced. Later on in the display the actual line impedance is given and this is correct.
The portion of the "show controller t1|e1" display which shows the interrupt counters contains non-applicable information.
The same display is used for both T1 and E1. Most of the fields are applicable to both. Some are applicable to only T1 and others only to E1. The display is not automatically adjusted to display only T1 fields when in T1 mode and E1 fields only when in E1 mode.
The 'M' lead on pin 2 is still active on an FXS circuit. If pins 1 & 2 are connected and become shorted, dial tone will be returned on tip and ring (pins 4 & 5). Correct wiring will not allow this to occur.
PVC operation using Ground Start procedure does not operate correctly. The workaround is to use SVC operation.
The voice port selection DIP switches may be set in an invalid combination which can cause associated resistors to overheat and fail. In both SW1 and SW2, switches 3 and 6 should not be set to ON at the same time.

Hardware Notes and Caveats

This section describes hardware notes and limitations that will be fixed in later releases.

3801 T1/E1 DB-15 Connector Pinout for T1 and E1 modes

Pin 1: Tx Tip/+

C3801 DB-15 Signal
P1-1 Tx Tip
P1-2 Tx Ground (Usually not connected for T1)
P1-3 Rx Tip
P1-4 Rx Ground (not usually connected for T1)
P1-9 Tx Ring
P1-11 Rx Ring

Technical Specifications: Operating Temperature

During the Early Field Trial phase, the performance documented in product documentation and marketing literature is valid at operating temperatures of 40 degrees Celsius or less.

Important Hardware Caveats

Setting Voice DIP switches SW1 or SW2 incorrectly causes significant warming of the Cisco 3801-COMBO-01 card. Follow the tables in documentation carefully.
If SW1 and SW2 DIP switches on the Cisco 3801-COMBO-01 card are set in an invalid combination, the card may be damaged. The components have actually been observed to fall off the board. (CSCdj11019)
If the media-type on a serial interface is changed while the interface is in shutdown state, it may not actually change. The change takes place the next time the interface is placed in the no shutdown state. If the operator changes media-type while the interface is administratively down and re-cables it to the appropriate customer equipment with the changed media-type, signals output on the interface may not be correct for the attached customer equipment.
Hint: You can program the media-type parameter to a new value. This causes the interface to reset. When the interface comes back up the voltage levels reflect the new media-type. Resetting an interface doesn't do anything if the interface is administratively down. In the multi-card release of the Cisco 3801, the Cisco 5-in-1 serial interface style package will be introduced. The 5-in-1 interface automatically detects cable changes and adapts to them. (CSCdi86796)
Functional throughput is a factor of the amount of frames moving within the unit. Interfaces may be configured for up to 2-Mbps clock rates. However, frame sizes and addressing may cause congestion within the unit resulting in a throughput less than 2 Mbps.
Redundant power supplies are not supported in the first release of the Cisco 3801 series product.
Although as many as three Cisco 3801 Combo cards can be installed into a three-slot chassis, there is no backplane connection between the modules. Any connection between the modules must be accomplished externally through the serial ports, including connections with optional modules such as the Cisco 3801 ERM card.
When determining the LED state on the daughter card, pay attention to the relative position of the LEDs rather than the labels. There has been some confusion regarding the labeling and it could be misleading.
In countries other than tthe US and Canada, the 2 wire FXO ports and the 2/4 wires E&M ports of this product shall not connect directly to the PSTN analog lines.

Documentation

You can access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com. The following list of documentation is provided as a quick reference:

Books Chapter Topics
Cisco 3800 Series Hardware Installation Guide Overview of Cisco 3800 products
Installing Cisco 3800 hardware
Installing Cisco 3800 cards
Connection pinouts and configuration
Cisco 3800 applications
Technical specifications
Error messages
Cisco 3800 Series Software Configuration Guide and Command Reference System configuration and setup
Using the Cisco 3800
Voice port commands
FTC trunk commands
ATM PNNI commands
Switch commands
Serial interface commands
Example configurations
Cisco 3800 Expansion Router Module Installation and Configuration Guide Overview, installation, configuration and maintenance of the Cisco 3800 ERM product
11.2 Cisco IOS General Command Reference Summary Alphabetical listing of global Cisco IOS commands
Cisco StrataCom IGX Reference
Cisco StrataCom IPX Reference 		Defining a Cisco 3800 node's IP address and subnet mask remotely using Cisco IGX or Cisco IPX commands
BPX Service Node Reference

BPX Service Node Installation

 Defining a Cisco 3800 node's IP address and subnet mask remotely using BPX commands
Release Notes for Cisco IOS Release 11.2 and Cisco IOS configuration guides and command reference publications Using Cisco IOS software

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.



hometocprevnextglossaryfeedbacksearchhelp
Copyright 1989-1997 © Cisco Systems Inc.