no. that's the part that has me confused.<div><br></div><div>maybe a bug with the sh controller command?</div><div><br></div><div>I have no errors until I get to last 24 hours. nothing in the first 96 intervals.</div>
<div><br></div><div>I'll look for a bug with 12.4.24t1.</div><div><br></div><div>Scott</div><div><br></div><div><br><br><div class="gmail_quote">On Mon, Feb 15, 2010 at 8:45 AM, Peter Slow <span dir="ltr"><<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">im pretty sure that's telling you that your telco is being stupid. are<br>
there any unavailable seconds on the controller for the interval in<br>
which the timeframe "Feb 15 16:38:32.747 until Feb 15 16:39:02.747"<br>
lies?<br>
<font color="#888888"><br>
-Peter<br>
</font><div><div></div><div class="h5"><br>
On Mon, Feb 15, 2010 at 11:41 AM, Scott Voll <<a href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>> wrote:<br>
> so what does this tell me?<br>
> Feb 15 16:37:40.619: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:37:40.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:41.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:42.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:43.619: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: S4_SABME: Sending UA<br>
> Feb 15 16:37:49.699: %ISDN-6-LAYER2UP: Layer 2 for Interface Se0/3/0:23, TEI<br>
> 0 changed to up<br>
> Feb 15 16:37:49.699: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:37:50.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:50.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:37:51.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:51.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:37:52.683: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:52.687: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:37:59.707: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:37:59.711: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:00.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:00.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:01.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:01.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:02.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:02.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:09.719: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:09.719: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:10.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:10.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:11.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:11.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:12.703: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:12.707: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:19.727: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:19.731: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:20.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:20.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:21.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:21.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:22.723: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:22.727: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:29.751: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:29.751: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:30.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:30.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:31.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:31.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:38:32.743: ISDN Se0/3/0:23 Q921: User RX <- SABMEp sapi=0 tei=0<br>
> Feb 15 16:38:32.747: ISDN Se0/3/0:23 Q921: User TX -> UAf sapi=0 tei=0<br>
> Feb 15 16:39:02.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0 nr=0<br>
> Feb 15 16:39:03.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0 nr=0<br>
> Feb 15 16:39:04.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0 nr=0<br>
> Feb 15 16:39:05.747: ISDN Se0/3/0:23 Q921: User TX -> RRp sapi=0 tei=0 nr=0<br>
> Feb 15 16:39:06.747: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:06.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:07.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:08.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:09.747: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:10.747: %ISDN-6-LAYER2DOWN: Layer 2 for Interface Se0/3/0:23,<br>
> TEI 0 changed to down<br>
> Feb 15 16:39:10.755: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:10.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:11.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:12.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:13.755: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:20.759: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:20.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:21.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:22.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:23.759: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:30.779: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:30.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:31.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:32.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:33.779: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:40.799: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:40.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:41.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:42.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:43.799: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:50.819: ISDN Se0/3/0:23 Q921: L2_EstablishDataLink: sending<br>
> SABME<br>
> Feb 15 16:39:50.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:51.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0u<br>
> Feb 15 16:39:52.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0<br>
> Feb 15 16:39:53.819: ISDN Se0/3/0:23 Q921: User TX -> SABMEp sapi=0 tei=0n<br>
> all<br>
> Scott<br>
> On Mon, Feb 15, 2010 at 8:38 AM, Peter Slow <<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>> wrote:<br>
>><br>
>> ideally, we want all of those debugs starting abotu two minutes prior<br>
>> to the failure. also... debug isdn q921 probably wouldnt hurt either.<br>
>><br>
>> -Peter<br>
>><br>
>> On Mon, Feb 15, 2010 at 11:36 AM, Peter Slow <<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>> wrote:<br>
>> > there are definitely going to be things going on with MGCP when this<br>
>> > is happening.... We need to see what's going on what that in relation<br>
>> > to the point at which the 921/931 states change. Is it possible for us<br>
>> > to get the debugs leading up to and including one of the events?<br>
>> ><br>
>> > -Pete<br>
>> ><br>
>> > On Mon, Feb 15, 2010 at 11:33 AM, Scott Voll <<a href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>><br>
>> > wrote:<br>
>> >> mgcp packets are following back and forth.<br>
>> >> isdn: Feb 15 16:31:19.360: %ISDN-6-LAYER2DOWN: Layer 2 for Interface<br>
>> >> Se0/3/0:23, TEI 0 changed to down<br>
>> >> Feb 15 16:31:48.852: %ISDN-6-LAYER2UP: Layer 2 for Interface<br>
>> >> Se0/3/0:23, TEI<br>
>> >> 0 changed to up<br>
>> >> not seeing any ccm manager events. should I?<br>
>> >> Scott<br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Mon, Feb 15, 2010 at 8:25 AM, Peter Slow <<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> Errrr.... Also I sort of jumped the gun....<br>
>> >>><br>
>> >>> > I have shut not shut the interface but I continue to get RTMT<br>
>> >>> > reports<br>
>> >>> > that the D channel is down(every 1 - 3 minutes). Router has been up<br>
>> >>> > for<br>
>> >>> > multiple days.(had a power outage last week). but d channel went<br>
>> >>> > down<br>
>> >>> > yesterday afternoon.<br>
>> >>><br>
>> >>> ...This can mean a TON of things... You're goign to see this alert if<br>
>> >>> your GW ungesisters from your CCM. That could easily be due to a<br>
>> >>> network issue. Its entirely possible that your interface is bouncing<br>
>> >>> at one layer or another when it unregisters or re-registers with your<br>
>> >>> CCM, that could explain your controller errors. We need to see what's<br>
>> >>> happening first. Is the GW losing registration with the CCM for a<br>
>> >>> network or software-related reason, or is the actual T1 interface<br>
>> >>> bouncing, or is there a different issues thats just causing a problem<br>
>> >>> with the q.931 signaling.<br>
>> >>><br>
>> >>> we need:<br>
>> >>> debug mgcp packet<br>
>> >>> debug isdn q931<br>
>> >>> debug ccm-manager backhaul events<br>
>> >>> debug ccm-manager config-download all<br>
>> >>><br>
>> >>> ...and anythign that appears in syslog, such as interface protocol<br>
>> >>> state changes (int x is up down etc)<br>
>> >>><br>
>> >>> ...begging before and ending after the occurrence of one of the<br>
>> >>> D-Channel OOS events.<br>
>> >>><br>
>> >>> -Peter<br>
>> >>><br>
>> >>> On Mon, Feb 15, 2010 at 11:17 AM, Peter Slow <<a href="mailto:peter.slow@gmail.com">peter.slow@gmail.com</a>><br>
>> >>> wrote:<br>
>> >>> > I recommend doing one of two things:<br>
>> >>> ><br>
>> >>> > if you have hardware to accommodate a second PRI, wire it up to this<br>
>> >>> > one and set them up back to back, and we'll see if the issue<br>
>> >>> > continues, and if you keep getting errors or not.<br>
>> >>> ><br>
>> >>> > If you can't go with option 1, you need to slap a loopback into that<br>
>> >>> > bad boy and set it up as an HDLC encapsulated data T1 and we can<br>
>> >>> > send<br>
>> >>> > packets of various sizes over it to see if you get any errors that<br>
>> >>> > way.<br>
>> >>> ><br>
>> >>> > Pick one, and we'll go through the specifics =)<br>
>> >>> ><br>
>> >>> > -Peter<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On Mon, Feb 15, 2010 at 11:10 AM, Scott Voll <<a href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >> show isdn stat shows multiple frames established which makes me<br>
>> >>> >> still<br>
>> >>> >> think<br>
>> >>> >> it's a Telco issue. any other ideas?<br>
>> >>> >> Scott<br>
>> >>> >> ps. I have no mgcp -- mgcp.<br>
>> >>> >><br>
>> >>> >> On Mon, Feb 15, 2010 at 7:53 AM, Scott Voll <<a href="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >>><br>
>> >>> >>> I have a ticket in with the local telco, but I have a D channel on<br>
>> >>> >>> my<br>
>> >>> >>> PRI<br>
>> >>> >>> that is bouncing about every 1-3 minutes.<br>
>> >>> >>> How do I check to make sure it's not a hardware issue on my side?<br>
>> >>> >>> it's a 2851 with vwic-2mft-t1=<br>
>> >>> >>> I see on the controller in the last 24 hours it has 1610 path code<br>
>> >>> >>> violations, 9 line code violoations, 2 serverly err secs, and 6<br>
>> >>> >>> unavail<br>
>> >>> >>> secs. but nothing in the current interval.<br>
>> >>> >>> I have shut not shut the interface but I continue to get RTMT<br>
>> >>> >>> reports<br>
>> >>> >>> that<br>
>> >>> >>> the D channel is down(every 1 - 3 minutes). Router has been up<br>
>> >>> >>> for<br>
>> >>> >>> multiple<br>
>> >>> >>> days.(had a power outage last week). but d channel went down<br>
>> >>> >>> yesterday<br>
>> >>> >>> afternoon.<br>
>> >>> >>> What else should I be looking at.<br>
>> >>> >>> Thanks<br>
>> >>> >>> Scott<br>
>> >>> >>> ps. CM 6.1.3 and MGCP.<br>
>> >>> >><br>
>> >>> >> _______________________________________________<br>
>> >>> >> cisco-voip mailing list<br>
>> >>> >> <a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
>> >>> >> <a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
>> >>> >><br>
>> >>> >><br>
>> >>> ><br>
>> >><br>
>> >><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>