RE: (usr-tc) TC user's conference?
-----Original Message----- From: Jeff Mcadams [mailto:jeffm@iglou.com] Sent: Monday, October 11, 1999 10:08 AM To: usr-tc@lists.xmission.com Subject: (usr-tc) TC user's conference? Thus spake Scott Trautman
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. 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 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 ;)
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.
- 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.
- 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")
- 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 -- 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. - 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.
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.
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: 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.
participants (2)
-
Jeff Mcadams -
Scott Trautman