Monitoring/alerting on a BUSY/out of service T1 in CM?

[avayaaacc]

I have BUSY'd out a T1 in CM and confirmed that CM did not generate a major/critical alarm. Should an alarm be triggered in CM when a T1 on our gateway is busy'd out?

Alternatively, has anyone setup SNMP to alert when a T1 outage occurs?

Ultimately we would like to add this data to our monitoring system, which offers a single pane of glass.

 

[kyle555]

No, CM is very self centered. A T1 down has no impact on its ability to process calls. So, warning.
That you can't get any calls in really isn't CMs problem. Funny, eh?

In 6.3.1 and 7, the SNMP stack was totally revamped and now standard net-snmp, so it's a lot easier to read.

Now, you program your single pane of glass to look for oid# whatever and if the maintenance object a warning on is ISDN-TRK, nms red alert or whatever.

If you lookup the SNMP refresh whitepaper by Mary Magnusson I believe, you can change alarm levels per object just to your nms (not sal), so it could be a major trap while remaining a warning alarm in CM. It looks like a dog's breakfast to do though. I never got around to trying though.

 

[avayaaacc]

Thanks for the update kyle555

We are running 6.3 SP3 for CM. I downloaded the mib file (g3-something) fro the CM web interface, but I am having a hard time finding an OID that would provide the information I need (such as a busy'd T1). Do you have this same version, or are you monitoring such an oid?

thanks again

 

[kyle555]

So, there's 6.3.0 and 6.3.1. I think ending .124.0 or something is .0 and on the G3 mib and the more recent version is net-snmp. You don't wanna chase it down in the g3 mib.

In that whitepaper,

https://downloads.avaya.com/css/P8/documents/101013339

theres a g3busytrk value in the old mib that's deprecated in the new one.

I'd think that it's very possible you don't get to poll the busy/release state of something but rather get a trap of it's in/out of service state. To say, you get a warning alarm that a T1 is down via a trap regardless of why it might be down.

 

[avayaaacc]

it does look like we are on 6.3.0 then, as I can see "g3busytrk" in the G3-AVAYA-MIB Version 6.3 file.

in the file though, I do not see any OIDs listed, am I misinterpreting?

g3busytrk OBJECT IDENTIFIER ::= { g3-mib 19 }


The file is 1.5mb, but I don't see any complete OIDs listed.

 

[avayaaacc]

also, is it possible to busy out an individual DS1 instead of an entire trunk? I noticed that busying out the trunk does not light up the DS1 or gateway for an error, and was wondering if busying a DS1 might instead.

 

[joe2938]

if you mean just to busy out only 1 member then it would be busy trunk 1/4 this would be for trunk group 1 member 4

 

[avayaaacc]

that's perfect, thanks joe2938! Do you happen to have experience with SNMP monitoring or monitoring these trunks in general?

 

[joe2938]

not the SNMP but to monitor a trunk group in real time, the command is monitor traffic trunk group, this will monitor all trunk groups

 

[kyle555]

Yeah, don't bother with the g3 mib. It's a pain to program and you'll be doing the new way at 7 anyhow. Upgrade to 6.3.1. It's not much work and nothing changes but the SNMP and the syntax is less arcane and mysterious.

 

[avayaaacc]

Thanks all. Some testing happened last night, where one gateway had the trunks busy'd out, and the other gateway was powered off. Funny enough, the gateway that was powered off only generated a "Minor Alarm" in CM.

 

[mojoputter]

If you need to have trunk alarms show up as Major alarms, Avaya can make changes in your system to have trunk outages cause a Major alarm.
We had a very large health insurance customer a few years ago make a big deal about that and Avaya got into their system so that they showed up as Major alarms and then in turn would show up in our alarm(AlarmTraq) monitoring system. But, Avaya will charge a pretty penny to do that.

Trying is the first step towards failure. --Homer Simpson

 

[kyle555]

I don't know if Avaya does that anymore in terms of cranking up your trunk alarms to Major to get to them. The point of the severity of the alarm is always "how does this impact CM's ability to process calls?", not "how does this impact how many calls get in to CM to process".

This whitepaper has instructions how, on the new snmp stack, to change the severity of alarms as they pass from CM to the SNMP stack to your NMS. ISDN-TRK can be a warning in CM, a warning to SAL, and a major to your NMS. Get on 6.3.1/7 to use it!

https://downloads.avaya.com/css/P8/documents/101013339