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.
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. :)
- 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: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" 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.