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 U.S. Government 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.
(cont. due to message size limitations)
--
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.
