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(a)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(a)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.
