CS1000E T1 issue - loadware

[Tman45]

We just had the below errors occur on our CS1000E system and we were called by our vendor that they couldn't clear it remotely so I came in - apparantly for nothing - because it shows EST after they logged out :/

% DCH054 DCH: 34 EST REMOTE TIME: 3:18:40 18/09/2009

Any ideas? We are currently on CAM03 loadware on our MGCs and I know it is KNOWN BAD LOADWARE (only lasted a few months)

We would like to put the newest (CAM08) but we are currently dealing on our new Vendor contract.

In speaking with our other Vendor on our CS1000M system they said that they even get the DCH54 'EST REMOTE' messages on their CAM06 loadware - it would be nice to get these messages cleaned up as they are produced almost every night and our current vendor will call our on call person with this error.

Does anyone have the newer loadware to tell me if they get the annoying EST messages? Or do you see anything blantantly wrong with our 'critical to monitor' errors below?

The main ones I want to point out are the DCH 1014 and DCH 1019 - can anyone make sense of them using hex decoding?

% TIM000 02:00 18/9/2009 CPU 0
%
% DCH054 DCH: 31 EST REMOTE TIME: 2:01:41 18/09/2009
%
% DCH054 DCH: 41 EST REMOTE TIME: 2:01:43 18/09/2009
%
% AUD000
%
% AUD000
%
% DCH054 DCH: 34 EST REMOTE TIME: 2:49:02 18/09/2009
%
% DCH054 DCH: 44 EST REMOTE TIME: 2:49:02 18/09/2009
%
% DCH055 DCH: 34 RLS REMOTE TIME: 2:55:30 18/09/2009
%
% DCH055 DCH: 44 RLS REMOTE TIME: 2:55:30 18/09/2009
%
% TIM000 03:00 18/9/2009 CPU 0
%
% TTY #01 LOGGED IN VENDOR 03:02 18/9/2009
%
% TTY #01 LD 060 VENDOR 03:02:51 18/9/2009
%
% TTY #01 LD 022 VENDOR 03:02:59 18/9/2009
%
% TTY #01 LD 060 VENDOR 03:03:27 18/9/2009
%
% TTY #01 LD 096 VENDOR 03:03:37 18/9/2009
%
%
%
% TTY #01 LD 060 VENDOR 03:03:53 18/9/2009


% PRI000 100 5
%
% PRI000 100 5
%
% DTA023 100
%
% DCH055 DCH: 34 RLS NO RESPONSE TIME: 3:04:31 18/09/2009
%
% PRI000 101 5
%
% PRI000 101 5
%
% DTA023 101
%
% DCH1014 44 0F328615 00000006
%
% DCH055 DCH: 44 RLS NO RESPONSE TIME: 3:05:19 18/09/2009

% TTY #01 LOGGED OUT VENDOR 03:05 18/9/2009
% SESSION DURATION: 00:03

% AUD000
%
% DCH054 DCH: 34 EST CONFIRM TIME: 3:16:58 18/09/2009
%
% DCH1019 34 0F3295EB 00000008
%
% DCH055 DCH: 34 RLS CONFIRM TIME: 3:17:40 18/09/2009
%
% DCH054 DCH: 44 EST CONFIRM TIME: 3:17:40 18/09/2009
%
% DCH054 DCH: 44 EST CONFIRM TIME: 3:17:40 18/09/2009
%
% DCH054 DCH: 44 EST REMOTE TIME: 3:17:42 18/09/2009
%
% DCH054 DCH: 34 EST CONFIRM TIME: 3:17:52 18/09/2009
%
% DCH054 DCH: 44 EST REMOTE TIME: 3:18:34 18/09/2009
%
% DCH055 DCH: 34 RLS REMOTE TIME: 3:18:40 18/09/2009
%
% DCH055 DCH: 34 RLS SABME WDM TIME: 3:18:40 18/09/2009
%
% DCH054 DCH: 34 EST REMOTE TIME: 3:18:40 18/09/2009
%
% AUD000
%
% TIM000 04:00 18/9/2009 CPU 0

 

[johnpoole]

can you est new calls during this event?

are you taking any hits on your lcnt? you can see where they enl, you get the dta023, layer one up, then est, then drop, which is usually slow response from the far end.. ld 96 stat serv, enabling those may give you cleaner primary handshake..

as to why this is happening? is the far end stable.. possible power interuption with your smart jacks or csu rack?

look for any common point on those loops? not a single msdl card?

john poole
bellsouth business
columbia,sc

 

[Tman45]

Thanks for the info John ... yea it is quite strange and in this case we did have some LOSFA at the remote site which is Qwest and I think they do have some issues at times However, I would like to clear up these EST remote messages as we get them without a RLS occuring. Possibly others on this forum don't experience this, but as I said, I talked with others that have and said they just 'live' with it. Just sucks to get called during the night for a non-issue. AND I came in at 4a this morning to 'fix' this non-issue since the vendor could not remote clear I thought there would be a REAL issue. Next time I am VPN'ing in to double-check their work

WOW I see what you mean about the LD 96 stat serv - all of ours are disabled!!! What does that do if we enable it - can you elaborate please? I have seen invalid protocol, unknown character/paramter and DCH maint messages - is this something that would clean those up?

We also have no CSU/smart jacks as we are using a inverse mux Adtran - and no it does not appear to be a common loop or msdl