T.R | Title | User | Personal Name | Date | Lines |
---|
3632.1 | Only start-up frames are traced for HDLC on DECNIS | MARVIN::RIGBY | No such thing as an alpha beta | Tue May 13 1997 05:46 | 15 |
| Once the linecard is operating the L2 protocol the management processor can no
longer trace the HDLC headers as the linecard is responsisble for creating them.
When the HDLC state is not "LINECARD L2" then the management processor generates
the entire frame and, thus, can trace it in a way that the HDLC decoder can
display.
While the linecard is forwarding it is not possible to see the
linecard-to-linecard forwarded packets at all, the events you are seeing are the
management processor generated traffic (probably routing control traffic) which
could be seen in detail by tracing the routing circuit tracepoint.
You should not have been able to see data packets being traced by the management
processor last week, it should have only been HDLC control packets (XIDs, SABMe
etc.) If you could reproduce this situation I would be interested to see traces
and, preferably, a DECNIS dump - it would have to be a bug.
|
3632.2 | command line for reproduce the info | DAIVC::ROSDIYANTO | | Tue May 13 1997 22:40 | 11 |
| Thank you for your reply.
BTW, in our situation this decnis is used for connection from head office to
4 branc office that was currently running well.
I will ask my customer to reproduce the decnis dump.
Could you please give me the command line to reproduce all of information that
you need (NCLs and traces command) ?
Thank a lot for your cooperation.
Rgrds,
ros
|
3632.3 | trace data file and dump shoudl suffice | MARVIN::RIGBY | No such thing as an alpha beta | Wed May 14 1997 10:58 | 9 |
| A trace file taken using CTF (trace start decnis"user pass"::"hdlc link NAME")
and the dump should suffice if the trace shows data being traced in the RUNNING
state. Make sure they don't just submit a dump with the LINECARD L2 behaviour -
this is expected.
I'd suggest just supplying a pointer to the dump to me by mail until we can show
that there is a problem worth raising an IMPT case for.
John
|
3632.4 | no longer this as an issue | DAIVC::ROSDIYANTO | | Thu May 15 1997 08:23 | 16 |
| Hello John,
Regarding with the decnis trace problem, I ask my customer to reproduce
dump file.
But they said that the current situation the decnis was running well, and
they don't really have a problem. About the trace that they saw last week,
they agree these were HDLC control packets when a link was trying to
initialize, ie when the HDLC protocol was not in normar on-running state.
And therefore they no longer regard this as an issue.
Thank you for your time and cooperation.
Best regards,
rosdiyanto
|
3632.5 | mail attachment from customer | DAIVC::ROSDIYANTO | | Thu May 15 1997 08:36 | 52 |
|
I N T E R O F F I C E M E M O R A N D U M
Date: 16-May-1997 02:26am WIB
From: Chaitanya Mistry
[email protected]@PMDF@INTERNET
Dept:
Tel No:
TO: '[email protected]' ( rosdiyanto@dai )
CC: Zuherman ( /o=SATELINDO/ou=EXCHANGE/cn=Recipients/[email protected]@PMDF@INTERNET )
CC: Iman Santosa ( /o=SATELINDO/ou=EXCHANGE/cn=Recipients/[email protected]@PMDF@INTERNET )
Subject: [I:] DECNIS and HDLC Tracing
Hello Rosdiyanto,
Thank you for following up our questions concerning the possibility of tracing HDLC data packets
and the information/responses from Engineering. Having carefully going through John's replies
it seems that in actual fact we don't really have a problem.
He states that when tracing HDLC during normal operation, it is not possible to
get a trace of the data packets. What we saw last week were HDLC control packets when a
link was trying to initialize, ie when the HDLC protocol was not in the normal on-running state.
To confirm the above, we are seeing the same "LINECARD L2" type traces on our other
working routing circuits to Palembang, Ujung Pandang, Elektrindo etc.
I believe therefore we no longer regard this as an issue.
Thank you for your time and cooperation.
Best regards,
Chris.
RFC-822-headers:
Received: from mail11.digital.com by dasmts.imc.das.dec.com
(PMDF V5.1-8 #16470) with ESMTP id <[email protected]>
for [email protected]; Thu, 15 May 1997 01:38:50 EDT
Received: from gtw1 by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV)
id BAA00907; Thu, 15 May 1997 01:35:53 -0400 (EDT)
Received: from thomas.satelindo.co.id by gtw1 (SMI-8.6/SMI-SVR4)
id WAA05323; Wed, 14 May 1997 22:25:53 -0700
Received: by thomas.satelindo.co.id with Microsoft Mail id
<[email protected]>; Thu, 15 May 1997 12:26:13 -0700
Encoding: 23 TEXT
|