SRST problems

[a.dementyev]

Hi All!

We are using ISR 2951 in SRST mode.

When router switched to SRST mode due to WAN failover all is working OK. But then due to power interruption router has been restarted we couldn't make incoming and outgoing  voice call. . Layer 2 status ia TEI_ASSIGNED.

Solution for Layer 2 status  TEI_ASSIGNED -  the next (very strange):

isdn bind-l3 ccm - not shown in port config (SRST-mode)

but then we manualy entered this command in serial 1/X:15 isdn bind-l3 ccm, shut and no shut its, and after than manualy deleted this command from serial port, port moves in  Established state.

Can anybody help me?

[Steven Holl · Accepted solution]

Can you ensure that you have the following commands:

ccm-manager config

ccm-manager config server

'sh ccm' doesn't show any config download errors, does it?

When you click the 'reset gateway' button for this endpoint in CM, and you watch the router console, do you see the PRI get torn down, and rebuilt properly?

[a.dementyev]

1. Yes

2. Yes

3. No errors.

4. I can't reset gateway (WAN link failure in ISP broadband)

The problem is when router in SRST-mode reloaded and WAN link still in failure state isdn bind-l3 ccm not deleted from int s1/x:15 interface, as I know when router come in SRST-mode the shown above command must be deleted from config. I've tested this situation in my lab environment - this is working fine. But in production router which in SRST state now all in opposite. The isdn bind-l3 ccm not shown in config but ISDN PRI trunk in l2 in TEI_ASSIGNED STATE. And when I manually entered isdn bind-l3 restart interface and remove command from interface - interface come in ESTABLISHED state. But no b-channeks available, so as misconfigured before. So as WAN link still unavailable I don't know how to recover PRI interface state. In my lab environment I've timely restarted my SRST router. Command was successfully  deleted. May be this procedure (delete) depend from router reloads?

Thank's

Alex

[Steven Holl]

Looks like a bug, then.  That command should be going back in there.

I'd enable the following debugs and wait until you can reproduce the issue:

  debug ccm-manager back ev
  debug ccm-manager back pack
  debug ccm-manager config all
  debug ccm-manager event
  debug ip tcp trans
  debug mgcp pack
  debug tftp events

These debugs are fairly verbose.  Ensure you debug as follows:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg

While the issue is in the bad state, get:

sh isdn st

sh ccm

Once you get these debugs, open a TAC case with the debugs and we can get this looked at.

-Steve