Latest Cisco Software problem: UVM with T1 Backcard is Stuck in Yellow Alarm When Using CCS

greenspun.com : LUSENET : Grassroots Information Coordination Center (GICC) : One Thread

Would someone with the necessary technical expertise please indicate the ramifications of this problem, how widespread its impact may be (what kinds of users it would impact, sorts of problems) and whether or not it could be a y2k problem:

Cisco Software problem: UVM with T1 Backcard is Stuck in Yellow Alarm When Using CCS

January 20, 2000

The UVM (Universal Voice Module) port will return a yellow alarm to the locally connected device, usually a Private Branch eXchange (PBX) or channel bank when the UVM port receives yellow alarm. Likewise, some PBXs detect yellow alarm and return yellow alarm. This combination results in a situation where neither the UVM port nor the PBX port can be cleared from the yellow alarm state without manual intervention by maintenance engineers.

If the PBX and IGX configurations are both set to Common Channel Signalling (CCS), this problem may appear when the channels on the PBX interface are manually put out of service, or when one of the channel Permanent Virtual Circuits (PVCs) terminating on the UVM fails.

This problem occurs only when the CCS feature is enabled via the cnflnsigparm command:

12 CVM & UVM Condition T1 Lines? [ YES]

This problem occurs only in 9.2.30 and earlier versions of 9.2. This problem does not occur in any 9.1 or earlier versions of software since the feature was not available in those releases. 9.3 software, currently unreleased and under development, has the fix for this problem.

This problem is caused by software. UVM card replacement will not resolve this problem.

Network users will not be able to establish calls through the affected T1 interfaces because the attached PBXs will busy out the channels on the T1 interfaces detecting yellow alarm.

Network maintenance staff will observe that the T1 line is stuck in yellow alarm. Yellow alarm is also known as Remote Alarm Indication (RAI) and is a standard T1 interface alarm.

Link to site:

http://www.cisco.com/warp/public/770/fn10591.shtml

-- Carl Jenkins (Somewherepress@aol.com), January 24, 2000

Answers

"Would someone with the necessary technical expertise please indicate the ramifications of this problem, how widespread its impact may be (what kinds of users it would impact, sorts of problems) and whether or not it could be a y2k problem: "

Happens all the time.

Telecommunications equipment usually has three alarm states: 1) Normal (no alarm) 2) Minor alarm (Yellow alarm) -- some services may be affected 3) Major alarm (Red Alarm) -- Services ARE affected.

"The UVM (Universal Voice Module) port will return a yellow alarm to the locally connected device, usually a Private Branch eXchange (PBX)"

... PBX, you know, the local business telephone system. So perhaps a company is using a Cisco UVM to route voice telephone calls through the Internet to save on long distance charges. In that case, the Cisco UVM is connected to the company's PBX ...

"or channel bank when the UVM port receives yellow alarm. Likewise, some PBXs detect yellow alarm and return yellow alarm."

... Oh good. So one piece of equipment sees a problem and sends out an alarm message. The equipment seeing that alarm message then returns a new alarm message to the equipment originating the alarm. Kind of like having the fire alarm lock all of the doors so the fire can't get out. Trouble is, neither can the people. This is called a deadlock condition when both pieces of equipment behave this way. A is in trouble so goes into alarm and sends an alarm to B. B goes into alarm and sends a message back to A which sends the message back to B ad nauseum. Push the reset button on one piece of equipment to clear the alarm and it goes right back into alarm because the equipment it is connected to is in alarm. This is abnormal behavior. Both pieces of equipment must be psychotic for this to happen. B must return an error when it sees an error (abnormal) and A must return an error when it receives an error (abnormal). So, just the Cisco UVM being psychotic is not sufficient to cause the deadlock...

"This combination results in a situation where neither the UVM port nor the PBX port can be cleared from the yellow alarm state without manual intervention by maintenance engineers."

This is a rare problem. It would not put a company out of business and hopefully the PBX yellow alarm would cause the PBX to not route calls throuth the UVM, but place the calls on regular telephone lines as long distance calls. It would cost money. It would be inconvenient. PBX, UVM, or network problems are common. That is why we build in alternate paths and redundant equipment. The call must go through.

-- Ray Strackbein (Ray@Strackbein.com), January 24, 2000.


Moderation questions? read the FAQ