(usr-tc) State of the Hub (part 2)(take 2)
(cont. from previous message due to message size limitations) I have received no reports, either positive or negative about the current state of 3Com support contract rules. A perusal of relevant 3Com web sites seems to indicate that some progress has been made on this issue. If you go to 3Com's web site, to the support section, and click on 3Com Care service offerings, under Maintenance Services, you'll see a section entitled "Unbundled Services." There are sub-sections for InfoPak telephone support (which is at the time of this writing a broken link), software updates (all of the latest software upgrades for a year for one low price...this has promise), Advanced Hardware Replacement (one contract covers multiple pieces of equipment...new equip. can be added at a pro-rated cost...this has potential *if* you can pick and choose which hardware is covered and are not required to cover all your hardware with the same coverage), and Multi-Year Warranty (also a broken link at the time of writing). I have a call in to my great sales-rep Tom Goodman to get more in depth information about the requirements of these service offerings (and prices), and will post what information I get when I get it. This covers the major outstanding issues that I'm aware of. Some further discussion points that have been brought up in the past are discussed below. Customer involvement in software development. I've not seen much progress here, it seems that most software development on the TC equipment is still done with very little connection to customer requests (very cathedral style, with apologies to ESR). There has been recent calls for more participation on the beta list for TCS 4.0, I wholeheartedly encourage this...unfortunately, I haven't had the opportunity to work with the beta software as I would like. The beta list (and I'm under the beta NDA, so I need to be a little careful here ;) seems primarily to be a list for customer feedback to 3Com folks about the problems we're having. It would be nice, (and this isn't just restricted to the beta list) to have the possibility to be part of the discussion about how things get implemented. Had more customer input been solicited, perhaps we wouldn't have ended up with ip pool aggregation reserving a network and broadcast address unnecessarily, and similar types of issues...none are critical, but all would make the TC equipment that much nicer to use. Another access server type of feature request to be re-iterated (this has been a long term request)...the ability to define, by an administrator, what traffic will reset the idle timer on a port. The ability to set this via RADIUS would be an added bonus. Beaurocracy (and I'm still not sure if I'm spelling this right). There seems to have been made a *little* progress in this area, however, this requires a disclaimer. I, personally, apparently, have achieved some...ah...notoriety within 3Com...particularly in the Rolling Meadows facilities. As such, I must consider the possibility that I've been getting contact with people within 3Com that its not common to have direct customer contact with. :) Even this, however, is an improvement. Perhaps this gives me the opportunity to be a sort of liason between 3Com and 3Com's customers. I fear that I'm sounding cocky ("I have better contacts than you do"), and assure you that this isn't my intention. I'd rather people have direct contact...I have plenty of things on my plate to do that the time taken up being such a liason could be used elsewhere, but if I do have better contacts, and can be useful as a sort of liason, I'm certainly willing to do so for the betterment of 3Com-customer relations. :) Direction. Specifically with the HiPer Arc card (which is where I'm particularly knowledgeable within the TC product group), it seems that 3Com is beginning to see the possibilities that the HiPer Arc (at least) provides beyond just being a dial-up access server. Again, I have to be careful here because of the restrictions of the beta NDA...but the direction of the development seems to be towards making the HiPer Arc a full-fledged router. Some things that need to be worked on still: - 3500 route limit needs to be removed, or at least upped - more routing protocols...OSPF is a great start...more needed (BGP?) - OSPF needs to be able to be an ABR - more control over routing protocols...summarization, redistribution - route selection still somewhat buggy (Mike Andrews is the expert on these problems ;) And some things that I think are important, but not necessarily to the point of being *needed*: - bridging - QoS...this is apparently a company wide push for 3Com...so I suspect its going to be done in a big way - wider array of interface types And, just for kicks, a gee-whiz cool feature that the TC lends itself to: - packet bus interface...the ability to treat the internal packet of the chassis as an interface in the Arc...some cool things can be done when this is combined with bridging support above Even as an access server, the Arc needs to be developed to adapt to changing times. As modem and ISDN access becomes less and less prevelent with the proliferation of broadband, the Arc needs to adapt. There seems to be some work on this front (again, TCS 4.0 beta), the bridging support mentioned above is needed for this as many DSL providers transport DSP and other broadband access methods to ISP via a bridging over frame-relay or bridging over ATM. The Arc already has support for frame and ATM, but can't (from what I've seen) do bridging over top of it. I encourage people to submit their own feature requests, etc. to the list and/or me. I've been keeping some notes recently for inclusion into this and future "State of the Hub" messages. :) Like I said...I'm willing to take up the role of liason between 3Com and customers if that's necessary/desireable, let me know. I also encourage feedback to me and to this forum regarding this message and others of mine. My philosophy is that I own my words. I'll take responsibility for what I say, I encourage forwarding of my messages on to people who would benefit from my messages, all I ask is that you keep attribution and contact info in tact so that I can continue to take responsibility for my words. :) -- 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.
<musing> If 3Com is listening, as I've mentioned to TG in the past, like to see 3Com come out with a DS3 <-> CT1/PRI interface internal to the hub. Even if it'd take up an entire chassis to do it, it'd be really cool to be able to plug in twin coax on the back of a chassis and be done with it, turning things up as needed but working on the DS3 level instead of having a mess of wires running around everywhere from the DS3 interface to the mux, to the dsx panel to the DSP's, etc. I don't know if the packet or TDM bus is designed to handle that much data, however. I would hope that it is. Heck, I wouldn't mind having a DS3 card which would interface to the DSP's across the TDM bus as long as we could get dual PRI or dual T1 DSP's in place. Wouldn't that be cool? :) It would mean making those LED's a bit smaller so we could see if span 1 is working vs span 2 on the dual DSP. Let's see... 28 / 2 = 14. If the DS3 card took up one one slot, that'd be 15 slots with the DSP's. Hmmm :) One for the serving gateway card, and one for the NMC... :) Sounds like just the right size to me... Am I the only one who thought of this? :) The only real disadvantage to doing this is putting so many eggs in one basket with the chassis being required to be up. If we were going to do this, we'd definitely have spare DS3 equipment on hand and thanks to a very nice arrangement with our telco, they've installed an FLM150 in our offices where we have DS3 and that's their responsiblity. As far as dual DSP's, we'd probably keep a couple on hand along with spare power supplies and a chassis. If we were going to put that much $ into a box, though, I'd definitely want to be able to peel off some of those DS1's into external RJ45's to be used by other CSU/DSU's so we could put DAP customers, etc. on it. </musing> Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice - 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 Kevin Benton
I don't know if the packet or TDM bus is designed to handle that much data, however.
Unfortunately, I believe the answer to that is, no, it isn't designed to handle that much data. The TDM bus on the chassis has (if I remember correctly) 512 timeslots...a fairly significant number short of the 672 needed to handle DS3 ingress. :/ Now, in theory, you could change the clocking in the chassis and crank the number of timeslots higher, and assuming that 3Com has overengineered the TDM bus like they did the rest of the chassis, this might even be feasible. I'm certainly not a guru when it comes to this area, so I don't know for sure, but I wouldn't rule it out. The downside of this is that you probably would not be able to have any of the current cards that use the TDM bus in a chassis with cards that would use the faster TDM bus as they pull their clocking off the bus itself and the current crop of cards (unless they're also rather overengineered) couldn't handle the higher speed clocking. Minor drawback, and one that I, for one, would certainly be willing to live with. There are probably other obstacles to this that I'm not aware of, but the theory seems pretty simple. :) The thought that I had was that you had a master/slave ds3 card setup...master in one chassis took the ds3 in, split off half the channels and sent them across the packet bus to the DSP cards, then the other half of the channels were daisy chained to another chassis where it connects to another ds3 ingress card and the rest of the channels were handled. Shoot, if this were done right, you could then daisy-chain that over to a third chassis as a full hot-spare chassis...if one of the first two chassis failed, the calls would get passed through to the third. I discussed all of this with Tom Goodman when I was up for Networks3, so there's at least one person in 3Com who I've talked to about these ideas. :)
Let's see... 28 / 2 = 14. If the DS3 card took up one one slot, that'd be 15 slots with the DSP's. Hmmm :) One for the serving gateway card, and one for the NMC... :) Sounds like just the right size to me... Am I the only one who thought of this? :)
Ai...not sure I like the idea of a full ds3 worth of calls terminating on a gateway card with no hot spare available. :/
The only real disadvantage to doing this is putting so many eggs in one basket with the chassis being required to be up.
Particularly the gateway card (HiPer Arc, or whatever a beast that could handle 600 calls would be called).
If we were going to put that much $ into a box, though, I'd definitely want to be able to peel off some of those DS1's into external RJ45's to be used by other CSU/DSU's so we could put DAP customers, etc. on it.
I've thought that the DSP's should be more general purpuse anyway. Take the DSP NAC, and rather than making it a T1/PRI/modem board, use that mondo processing power there (and with 3 PPC's, its got plenty) give it a T3 NIC and let it do packet T3. Then you could also use those PPC's as a distributed route-cache/forwarding engine, or a compression or encryption engine. Certainly it would at least do the framing work that it currently does with PPP. Its quite possible that you could even relegate the HiPer Arc to being a control engine type of thing, where the routing protocols and such are processed by the Arc, a forwarding table is built which is then pushed out to the DSP cards which do the actual forwarding. This isn't exactly unheard of in other vendor products as it is. :) Most vendors are going to a processing engine, and one or more forwarding engines...certainly a DSP/Arc equipped chassis has more than enough processing power available to handle a huge amount of throughput/pps. Careful coding should let you have transparent failover of the Arcs that way too. You could at least do this for plain packet forwarding...you'd lose telnet sessions to the Arc, probably BGP sessions (assuming BGP is available then), but with a draft I saw the other day...kind of like a soft restart of BGP...you could prevent that from stopping packet forwarding even. There are so many possibilities here...I don't think any one person can conceive of them all...that's one of the reasons that I've been trying to get people to post some blue-sky thinking here...give 3Com some ideas of what could be possible. :) -- 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 -
Kevin Benton