Subject: Re: (usr-tc) TC user's conference?

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Oct 1999 20:08:11 +0000

Thus spake Jeff Mcadams
>Yeah...I've talked with George about this extensively...and while the
>interface is pretty good.  TCM as a whole has some significant
>limitations...things I can think of off the top of my head...

>- You can only really manipulate one chassis at once...with some good
>scripting ability you could manipulate multiple chassis at once (which
>is what I've been doing with my perl scripts recently...iterate through
>all our chassis and perform action xyz)...there's just really no good
>way to do this with TCM, so when you get beyond...oh...10 or so chassis,
>it starts getting really tedious to administer things in TCM...that
>number varies with the patience of the one doing the administration.  :)

Duh...forgot to type in the other one...  :/

- Copying configs from one card to one or more others is terribly
inefficient...setting *all* of the config settings, when you're dealing
with a large number of settings can take a *long* time.  Would be good
to have the ability to only set the settings that are different...same
eventual effect (the cards end up with identical configs) but
considerably more effecient...this is one of the main reasons that I
moved away from using TCM as my primary tool for configuring chassis
(that and I happened to have access to one that did these things
better...unfortunately, its not mine to give away, or I would do so).
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-
 To unsubscribe to usr-tc, send an email to "[email-masked]"
 with "unsubscribe usr-tc" in the body of the message.
 For information on digests or retrieving files and old messages send
 "help" to the same address.  Do not use quotes in your message.

---

From: Jeff Mcadams <[email-masked]>
Date: Tue, 12 Oct 1999 20:08:20 +0000

Thus spake Scott Trautman
>Yep, similiar experiences. Unfortunate. Understand that they can't be all
>things to all people, but seems like there'd be a few strategic things
>they could do without a whole huge effort. Also understood is the things
>you'd like to see maybe only a handful think is as important. My thing
>(currently) is I'd like to see the ptrace style output. Then I go look at
>my Cisco routers, they have even less than that where it's even more
>important. Shrug.

I don't know...there's some *really* good trouble-shooting tools in
Ciscos...you just have to go about it in a different way.  Now, there is
certainly an issue of which works better, and that's very valid...but
you do have tools in Ciscos...they just don't work the same way.  :/

>>A few examples....I'm sure y'all can think of many more.....

>>- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise
>>ratio's, etc.)

>Good...unfortunately, there's not much in the way of tools in the TC's
>to do trouble resolution on these things.  More control over the
>CSU/DSU's would be *very* useful here.

>Well, useful to the extent that problems they're seeing <through> the
>TC equipment is really telco issues, and being able to better tell the
>difference would be really helpful.

Exactly...I would *really* like to have a decent suite of BER tests
available on the CSU/DSU's...I'd like to be able to do payload
loopbacks (in order to be able to test the actual CSU/DSU better)...

Maybe this is a bit bizarre...but it would be nifty to have a way to
"simulate" a telco switch on the DSPs or something like that.  Something
where we could plug a DSP into another DSP (cross-over t1 cable) and
actually bring up the D channel, and maybe even "place calls" over it.
With a good set of BER tests, and this ability, you could almost
eliminate the need for T1 test sets.  ;)  Anyway...these things are
definitely farther off type of things...but would be cool.  :)  I
certainly want to see engineering resources pulled away from maturing
the modem code on the DSPs to do things like this.  :)

>>- Getting more mileage out of TCM

>Hrmm...unfortunately, I've pretty much given up on TCM...you can only
>get so much mileage out of a VW bug.  :/  I'm beginning to write some
>Perl5 (with SNMP module) scripts to interact with the TC's...  I'm not
>quite to the point of putting TCM type functionality together...I'm
>starting with scripts to fulfull specific functions...I may, eventually,
>get to that point.

>George helped me along off of the same thought. I get quite a bit of
>use from TCM, and it beats the snot out of any other dialup control
>interface I've seen. Cisco, for example, I'm not sure they have ANY
>such graphical interface. 

>>- Advanced SNMP

>Isn't that a contradiction in terms?  ;)

>Well, no, kind of like TCM, I think one could do a lot more if one
>understood better "how it all fits together". Some of recent trails on
>SNMP manipulation that I've not delved into could be quite useful. For
>example, have a feeling I could probably find my "no answer" modems via
>SNMP a lot easier than any sort of RADIUS accounting grooming or the
>usual expect-like scripting. I just don't know how at this point.
>Session on, say, okay, (and we use this tool...great) RRD for modems in
>use monitoring, but other types of trap monitoring perhaps.

Yeah...I understand your point...and it is a good one.  Wrapping your
brain around the functioning of SNMP does take some work...but once it
clicks...it then becomes more a matter of how good your are at scripting
(which I'm just getting into) to be able to make use of it.  One good
thing that I think could come out of this would be methods of working
around the limitations of the SNMP implementations (ie, fairly small max
PDU size that is such a limit on the NMC :/ ).

>>- Dialup user issues (monitoring, filtering, setup, etc.)
>>- Getting to the bottom of modem compatibility issues

>I see these two kinda being two different sides of the same coin...most
>specifically, I would benefit from a seriously in depth seminar about
>modem technology...unfortunately, I'm not sure how generally useful this
>would be as I'm thinking about actually getting down into the encoding
>of the data into the analog waveform and stuff.  :)

>Sure. I'm personally not all that interested in the encoding level of
>things, but would be in understanding more fully WHY Rockwell chipset
>modems are such a problem. (I mean other than "they suck")

Well...true...and I'm probably interested in getting way deeper than
necessary...but that's kinda the way I am...I was one of those kids that
always asked "Why?"...not because I wanted to annoy someone, but because
I really and truly was interested into how things worked, why things are
the way they are, etc.  :)  I'd be interested in learning about noise
levels, transmit and receive levels, how the actual modulation and
encoding works so I can understand why those values are important, and
how they're dealt with...all that.  I'm doing some studying on my own,
but its *really* hard to find information on this type of stuff (esp.
since some of the specs aren't freely available...blech)
-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

-

---

From: Scott Trautman <[email-masked]>
Date: Tue, 12 Oct 1999 20:08:23 +0000

-----Original Message-----
From: Jeff Mcadams [mailto:[email-masked]]
Sent: Monday, October 11, 1999 10:08 AM
To: [email-masked]
Subject: (usr-tc) TC user's conference?

>I concur on the training; I know in our area there are plans to have a
>session in the near future. Even those that think they "know it all",
>will learn some new tricks. I've been fortunate to get to know George
>Ebert at 3Com, and he's been a fantastic resource for those types of
>things. It'll be nice, though, to retain more than say 30% from those
>valuable informal sessions; as well as send a couple of our Admins to
>the training.

Indeed...those informal training sessions are good...and they're a good
way for 3Com folks to get feedback from customers (there were about 8 of
us at the one in Louisville...there was some good give and take there).
I just wish they could get 3Com folks to come that aren't in the sales
side of things...while the sales folks are good (Tom Goodman and George
Ebert are indeed wonderful resources), it seems that, within 3Com,
feedback doesn't really seem to be taken seriously from the sales folks.
:/  Unfortunately, this seems to be the case in many companies...not
just 3Com.

>I had suggested perhaps a TC users conference would be cool; something
>like an ISPCON but specifically for TC units. 1-2 days with conferences
>on many of the subjects we talk about here. There's a lot more "under
>the hood" than many of us ever get to, and I know we could, if we knew
>about them, use a lot more features than we currently do.

Neat idea...I'd certainly go for it (if I could get my company to pay
for the travel ;)

Well, useful to the extent that problems they're seeing <through> the TC
equipment
is really telco issues, and being able to better tell the difference would
be
really helpful.

George helped me along off of the same thought. I get quite a bit of use
from TCM, and it beats
the snot out of any other dialup control interface I've seen. Cisco, for
example, I'm not sure
they have ANY such graphical interface. 

Well, no, kind of like TCM, I think one could do a lot more if one
understood better "how it all
fits together". Some of recent trails on SNMP manipulation that I've not
delved into could be quite
useful. For example, have a feeling I could probably find my "no answer"
modems via SNMP a lot easier
than any sort of RADIUS accounting grooming or the usual expect-like
scripting. I just don't know
how at this point. Session on, say, okay, (and we use this tool...great) RRD
for modems in use monitoring,
but other types of trap monitoring perhaps.

Sure. I'm personally not all that interested in the encoding level of
things,
but would be in understanding more fully WHY Rockwell chipset modems are
such a 
problem. (I mean other than "they suck")

>- HiperARC setup
>- TC "future" - VoIP, ?

Indeed...this would be nice...especially to give feedback to 3Com
through it.  Where do you/I/we want this platform to go?  I sent a nice
long letter to the list the other day and got very little feedback...one
person agreeing with me (in private, asked for his message not to be
publically posted), and one person sort of disagreeing with me in
public.  :)

>I'd pay $1-2k for such a day-2day conference.....Just thoughts....

Unfortunately, that'd probably be out of our price range...but I would
be interested in such a conference in idea at least.  :)

Shrug.

SMT

-

-