SIP Gateway Sending SNMP Trap Communication Link Down for all ISDN B Channels on a PRI

travisr · ‎12-07-2011

We recently switched from MGCP to SIP Gateways. On all of the SIP gateways, we have ISDN PRIs plugged into them from the PSTN. We now started taking calls on these PRIs. For every call that ends and the Bchannel goes back to an idle/down state, the gateway is sending an SNMP Trap Communication Link Down for the B channels of the PRI. This is causing our Network Monitoring System to flag the device in critical alarm for every single call that ends.

Seeing alarms like this below in our Network Monitoring System:

Communication Link Down for Serial_IF_Port port, named SRST_Router_Se0/3/0:0, has detected a Communication Link Down.

Also ISDN Flapping Dialup Links

Fri 02 Dec, 2011 - 07:42:15 - A flapping dialup link has been detected via demandNbrCallDetails trap reception on Rtr_Cisco device named SRST_Router.

D-channel_ifIndex.sequence = 138.20 (Neighbor Table index)

Interface = 142
Neighbor name =
Called address = 1XXXXXXXXXX <- Removed

Call origin = originate

In some cases, the following notification variables may have a null value if a connection has been made:

Duration =
Clearing reason =
Clearing code =

(event [0x00210b95])

We normally turn on all snmp traps including the following.

snmp-server enable traps

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server enable traps isdn call-information

snmp-server enable traps isdn layer2

snmp-server enable traps isdn chan-not-avail

snmp-server enable traps isdn ietf

We have all of our MGCP gateways configured the same way for SNMP but I'm wondering if it is now sending the traps because the D channel information is now being process locally instead of backhauling it to Call Manager.

Is there a way to shut this behavior off in the router via the command line without shutting the linkdown off on all interfaces? Is there a way to do it only on the B channels? Has anyone else experienced this issue with SIP gateways?

travisr · ‎12-20-2011

reposting as still no resolution.

Any help is appreciated. Thanks!

ronaldobf · ‎07-17-2012

Hi Travis.

Did you solve this issue?

I have the same situation here.

I am currently using the following:

snmp-server enable traps snmp linkdown linkup coldstart warmstart

snmp-server enable traps isdn layer2

snmp-server enable traps isdn chan-not-avail

snmp-server enable traps isdn ietf

snmp-server enable traps voice poor-qov

The solution I could think is to filter it under the monitoring tool or to remove the global linkdown / linkup snmp parameter and apply it on interface level on the interfaces you want to generate the up/down traps.

Anyway, I guess this solution is not the best one since we have to log in on each equipment and configure each single interface.
thinking on changes in the environment, all the time a change is done (interface), you will have also to apply the snmp parameter.

I am still looking for a solution.

Anyone?

thanks in advance

ronaldobf · ‎07-17-2012

If I could find any relevant information on the trap sent indicating that it is a trap for a B channel interface I could generate a global filter under the monitoring tool.

Does anyone know if is there is any data within the trap that I could work with to create the filter?

The trap is shown below:

RecvTime = 07/17/2012 14:01:58:696

PDU-Type = TRAP VarNum = 4

Id = 2 Name = linkDown

Desc = An interface has changed from the up to the down state.

ifIndex.15(INTEGER)(1.3.6.1.2.1.2.2.1.1.15) = 15

ifDescr.15(OCTET_STRING)(1.3.6.1.2.1.2.2.1.2.15) = Serial0/1/0:3

ifType.15(INTEGER)(1.3.6.1.2.1.2.2.1.3.15) = propPointToPointSerial(22)

locIfReason.15(OCTET_STRING)(1.3.6.1.4.1.9.2.2.1.1.20.15) = down

I have already navigated under the Cisco SNMP Object Navigator for the OIDs shown above, but I found nothing indicating that the trap is related to a B channel.

Thanks in advance

ronaldobf · ‎07-18-2012

For now, the only thing I could do is to keep the global configuration on it and just add the "no snmp trap link-status" under the signaling interface.

In this case, it suppressed all the B channels traps.

This is not the best way, but works.

I am still looking for a solution which I could create a filter under the monitoring tool globally.

Ken Douglas · ‎09-13-2012

We're having the same issue. SIP attached voice gateways with PRIs to the local PSTN. Every call generates a link up or link down trap. I need to know if the layer 3 construct (the D-Channel) is up or down but I don't really care about the B-Channels.

The link up / link down messages are flooding our SNMP management tool, making the trap alert component useless.

Of course I tried to access the individual B-Channels:

WTC304CVG05#config t

Enter configuration commands, one per line. End with CNTL/Z.

WTC304CVG05(config)#int s0/0/0:1

% Cannot access B-channel interfaces

WTC304CVG05(config)#

Would love it if Cisco provided us access to the B-Channels for management purposes.

I think our solution will be:

1. Turn off SNMP link status traps on the PRI

WTC304CVG05#config t

Enter configuration commands, one per line. End with CNTL/Z.

WTC304CVG05(config)#int s0/0/0:23

WTC304CVG05(config-if)#no snmp trap link-status

2. Enable more frequent polling of this interface using our SNMP management system and alerting on a change in the MIB just for the D-Channel (if the MIB allows for that granular of monitoring).

This is NOT an ideal solution. Even if I set polling for every 5 minutes, I know my users will be calling before I see the alert. Something that is frowned upon here.