[nSLUG] Router won't do 100mbps locally
nslug at fop.ns.ca
Fri Feb 5 08:56:41 AST 2010
On Thu, 4 Feb 2010, Daniel Morrison wrote:
> On 4 February 2010 12:55, Dop Ganger <nslug at fop.ns.ca> wrote:
>> On Thu, 4 Feb 2010, Daniel Morrison wrote:
>> In the enterprise world I'm working in a lot of stuff is broken (shock!),
>> and things tend to be implemented as safely as possible. Disabling
>> autonegotiation at both ends is standard practice for the enterprise
>> software as a result, and when the bundle costs the best part of half a
>> million dollars, things are installed according to the vendors'
> The argument that "the companies we buy from make broken hardware, but
> we're better than that" (i.e. can track port assignments accurately
> and efficiently) doesn't work for me.
Not quite. It's more like "we're buying best of breed hardware but we have
to figure out interop issues".
> If IBM and Cisco can't get it right, then I'm mighty impressed that your
> company can implement "change management" that works better.
IBM and Cisco aren't too bad talking to each other (I have an IBM blade
chassis with an on-board Cisco switch that rips along). Let me take a
wander through memory lane for a couple of examples:
* US Robotics vs Rockwell on V.42
The first V.34 implementations from USR and Rockwell didn't complete the
V.42 negotiations due to a disagreement reading the ITU specs (to be fair,
the line in particular was ambiguous and could legitimately be read either
way). This was fixed after a couple of flash revisions on the Courier
(both rack and standalone), but I think the Sportster V.34 was released
long enough after the upgrades that residential users never saw it.
* Cisco and the ECN bit
Remember Cisco getting it wrong with the ECN bit? Enterprises can have
long memories, ECN will probably never be as useful as it could have been.
Port assignments are tracked at my enterprise. There's some app they have
that does it all for them, I would presume SNMP based.
> Conversely, if you can be so efficient, then I'm sure the big guys can
> fix autonegotiation -- and in fact I believe it is this latter which is
> the case. Autonegotiation mostly "just works" nowadays.
Mmm, yes, but... Would you like the connection for the life support of
your favourite relative to mostly "just work" should they come in for
> Another part of what you've said is: "hardware companies make broken
> hardware, but software companies' installation instructions are
> gospel", which I also find hard to swallow, especially when the
> software instructions refer to hardware! A lot of "enterprise level"
> documentation is simply wrong.
Yes, indeed it is, which is one of the reasons a lot of project
implementations take so long - it's necessary to go back repeatedly to
clarify poorly written (or simply wrong) documentation. If the
documentation is not followed, however, if there is a problem the vendor
will deny support until it is on the grounds that the configuration they
gave us is a known working config.
The upside of doing things quite so (and I will readily admit)
inefficiently is that once things are up and running they keep running
fairly indefinitely. There are many stories out there on the net about
servers getting drywalled in for years at a time; the longest I could find
was 7 years. This pales next to the cement works out past Truro that
bought a VAX from a FOAF's outfit in the late 70's that has been running
since then up to at least 3 or 4 years ago.
> I've had this debate before, and I doubt we'll settle it here... in
> any case, people are free to do as they will, and neither approach is
Oh, for sure. I was reflecting more on how enterprise level isn't quite
the hallowed ground some people think it is more than anything else. If
anything, sometimes it's little more than an extended beta test for
hardware and protocols before they get rolled out to consumers.
> Dop recommends disabling auto-negotiation for
> enterprise-level data centres, which is fine. I recommend leaving
> autonegotiation enabled for all ordinary situations (from home to
> office to data centre) and I think that is fine also.
I certainly wouldn't argue with that summation.
More information about the nSLUG