We've recently seen the release of HiPer Arc releases 4.2.32 and 4.1.22. So now seems to be an appropriate time to take a look at the "State of the Hub" (with apologies to the President of the U.S. and Larry Wall for the name). I'm trying to bring about some structure to these messages that I post to give people a bit more assistance in finding the content that they need/are interested in out of my greater ramblings. I'll start off with some specific issues and questions that I have (essentially like the rest of my messages), and then go into some rather more broad thoughts. First, with release of 4.1.22, 3Com seems to have added some support, or at least control over directed broadcasting. Specifically disable/enable ip directed_bcast_forwarding. The release notes describe it as "When enabled, it allows directed broadcast forwarding from the user." My question is...how does this work? It seems to imply that it magically figures out what's going to be a directed broadcast that the user is sending out and drops it on the floor. I hope this isn't the case, but that it only drops directed broadcasts for directly connected networks. This, of course, because there is no way for the Arc to know if something is going to be a directed broadcast on a remote network. :) Second, SAA (Source Address Assurance) now pays attention to the netmask assigned on a connection to check to make sure that the source address coming in from that connection is indeed supposed to be able to be sourced from there. Previously, this only worked for /32's, but the description in the Release Notes indicates that it now considers the netmask for that. Does it consider a seperate route? I can understand if it wouldn't...that's considerably less trivial, but it would be good functionality to add to this feature. Even further...would be to allow it if the address is reachable (As best the Arc can tell) from that connection...which means that it may not even be in the routing table. You'd have to consult with the OSPF table (well...not in 4.1.x, but in later code), as well as any other routing protocol tables and static routes that aren't preferred. Anyway...just a question that I'm sure will come up before long that will be good to get clarified. :) OK...now on to greater, broader, longer-standing issues. :) 3Com's release numbering (at least on the total control stuff) is still nuts. I'm not sure what would be a good solution...but some releases counting up, and some releases counting down is just completely confusing to customers. Even long-time customers can have difficulty figuring out what the status of a particular release is, and which releases are newer than others. New customers are usually totally baffled, and understandbly so. This really needs to be changed...its been a call that those of us on the list have been making for many years, with no result. The best response (and given the people that are responding, this is understandable) that we get is yet another explanation of the current release numbering system, which isn't what is needed. I applaud Mike Wronski's and Krish's and Chuck Stace's, and the rest of the crew's patience in explaining this time and time again to new folks, and clarifying the status of releases when they're asked about. Really though, 3Com as a whole, would be much better served by letting these people do the job they were hired to do, not looking up (I know, most of you know them well enough that you don't have to look them up) what the status of a specific version of code is. Security releases are still taking *WAY* too long to be made widely available. There have been several security issues that have been made public in the last year or so, ER's have been made available that address these issues. Due to the nature of ER's though, these are not widely available, or publicized, or clearly understood (see the release number issue above ;). HiPerBomb was announced (I believe by Ed Taylor?) in mid-August. I had announced an SNMP security hole before that...both of which affected 4.1.59-6. Though ER's were available, it has taken 5 months for an SR to be made available (in the 4.1.x tree) that includes these fixes. This is an order of magnitude or two off from the amount of time this should be. Security fixes for problems of the magnitude represented by HiPerBomb and the SNMP issues that had been brought should have code widely available that addresses these on the order of a week or so from the time that they are made known to 3Com. I still get reports of people running into problems with NETServers, and 3Com continues to be unresponsive in dealing with thier handling of the practical end of support for this product. At this point, support contracts for the NETServer products should have all expired (unless 3Com continued to sell support for NETServers after they lost access to the source code which would be even worse!), so complaints have less of a basis at this point, but given the poor way that 3Com originally handled the NETServer to HiPer Arc transition, some complaints still are valid. Hopefully, 3Com has at least learned from the NETServer fiasco and won't repeat the same mistake twice, but that's little consolation for people that are still making do with buggy NETServer code as a result of 3Com's abrupt transition from the NETServer platform to the HiPer Arc platform. 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.