[cisco-voip] Serial interface state change

[Rhodium]

When you shutdown the signalling channel, effectively all the bearer channels are also shutdown as nothing can traverse them due to there being no signalling channel.

Even if the provider reset the circuit, that would not bring up a shutdown interface. That could be tested on a H.323 or SIP gateway.

I am guessing that this is a MGCP gateway with ccm-manager config applied it where the router downloads the configuration file for itself off the CUCM. This would bring up the interface (D-channel) thus causing a restoration in service.




________________________________
 From: Mike King <me at mpking.com>
To: Fred Hunt <FHunt at erdman.com> 
Cc: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net> 
Sent: Monday, April 15, 2013 7:30 PM
Subject: Re: [cisco-voip] Serial interface state change
 


Hi Fred,

When you downed Se0/0/0:23, you downed 1 channel on the PRI. leaving the other 23 channels up.  The PRI was still up. You just downed the channel that has the D-Channel on it.  The reason it came backup is your Service providor received an alarm on they're side showing your PRI was down.  I'm assuming after a unspecified amount of time, they bounced the entire PRI to bring the channels back up. (That would the the AIS detected message, it's a test message)

Downing the controller is the correct way to do this/

Mike



On Wed, Apr 10, 2013 at 4:14 PM, Fred Hunt <FHunt at erdman.com> wrote:

I’m trying to figure out why a serial interface seemingly changed its state on its own.
>
>We have a PRI that we are planning to decommission.  I previously removed it from being routed to in CUCM and I shut down the serial0/0/0:23 interface, as shown in the log below:
>021241: Mar 16 20:32:48.963 CDT: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/0/0:23, TEI 0 changed to down
>021242: Mar 16 20:32:50.960 CDT: %LINK-5-CHANGED: Interface Serial0/0/0:23, changed state to administratively down
> 
>Then, somehow the serial interface changed its state back to up.  This occurred after what appeared to be a brief outage of the T1 service.  Here’s the relevant log detail:
>021244: Mar 18 10:25:16.673 CDT: %CONTROLLER-5-UPDOWN: Controller T1 0/0/0, changed state to down (AIS detected)
>021245: Mar 18 10:25:16.881 CDT: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller T1 0/0/0
>021246: Mar 18 10:25:18.673 CDT: %LINK-3-UPDOWN: Interface Serial0/0/0:23, changed state to down
>021247: Mar 18 10:25:20.673 CDT: %CONTROLLER-5-UPDOWN: Controller T1 0/0/0, changed state to up
>021248: Mar 18 10:25:22.189 CDT: %LINK-3-UPDOWN: Interface Serial0/0/0:23, changed state to up
>021249: Mar 18 10:25:23.133 CDT: %MARS_NETCLK-3-HOLDOVER: Exiting Holdover for Controller T1 0/0/0
>021250: Mar 18 10:25:24.917 CDT: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/0/0:23, TEI 0 changed to up
> 
>Today, I discovered that the interface was up and shut it down again.  Then I decided to shutdown the controller itself.  Here’s the log:
>021310: Apr 10 13:57:23.272 CDT: %LINK-5-CHANGED: Interface Serial0/0/0:23, changed state to administratively down
>021312: Apr 10 14:13:28.404 CDT: %CONTROLLER-5-UPDOWN: Controller T1 0/0/0, changed state to administratively down
>021313: Apr 10 14:13:28.424 CDT: %MARS_NETCLK-3-HOLDOVER: Entering Holdover for Controller T1 0/0/0
>021314: Apr 10 14:13:30.404 CDT: %LINK-3-UPDOWN: Interface Serial0/0/0:23, changed state to down
> 
>I observed that after shutting the controller down the state of serial0/0/0:23 changed from administratively down to down.  I’m guessing that this will stick now, but I’m not sure after the earlier behavior.  I don’t understand how the serial interface was able to previously change its layer 1 state on its own.  Don’t both administratively down and down mean down at the layer 1 level?  Does a router automatically reset the state of serial interfaces if their associated T1 controller changes from the down to up state?
> 
>Thanks,
>Fred
>_______________________________________________
>cisco-voip mailing list
>cisco-voip at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130415/ab80e492/attachment.html>