Slashdot Mirror
Duke Wireless Problem Caused by Cisco, not iPhone
jpallas writes "Following up to a previous Slashdot story, it now turns out that the widely reported problems with Duke University's wireless network were not caused by Apple's iPhone. The problem was actually with their Cisco network. Duke's Chief Information Officer praises the work of their technical staff. Does that include the assistant director for communications infrastructure who was quoted as saying, "I don't believe it's a Cisco problem in any way, shape, or form?""
Still others seem to imply that Duke's network was deficient in some way because the problem had not been encountered more broadly.
I would say that the network was deficient until the patch was applied. For him to say otherwise implies that there was no problem to begin with.
this is just another example of hair trigger IT morons with nothing but an MIS (Management Information Systems) degree and experience working on their mom's computer. I can hear it now, "but they are cisco certified!!!". Yeah- certification.. spend a few hours studying some high level networking material, take a test-- now your an *expert*. always blaming whatever is new touching their "pristine" networks.
I read in another article that some Gartner group guy speculated that it was a problem with the wireless network at Duke's security settings, that they were using LEAP (Lightweight Extensible Access Protocol). Since that was an unusually technical speculation by a Gartner-ite, I'm curious if anybody can confirm/deny that.
Many network IT folks just understand how to change settings on routers (what you learn to do in a "certification" course on a router) and understanding networking. Networking is more than just some router settings, and understanding the organic interdependent flowing nature of a network is critical to debugging problems. Just knowing something is causing a problem, and blaming the most recent change as the cause (as opposed to some underlying problem that this change simply brings to light). A senior IT official should, even if he doesn't know the exact problem, know that weird entworking problems are often way more complex than they seem, and should not jump to knee-jerk conclusions (especially based on some 1994 anti-mac bias about networking)
when he starts getting those Apple fanboy death threats.
You mean when hack journalists start reporting unsubstantiated rumors of death threats.
E pluribus unum
No, Wikipedia is peer moderated.
While not perfect, obvious mistakes or blatant lies are eventually picked up and corrected - this is why you shouldnt quote Wiki's, but use the references they cite.
To be fair, who hasn't had an issue where you were SURE it wasn't one thing, when it actually was. I would imagine most of you, like me, have seen issues where you still can't explain how you fixed it.
For example, one of our developers found that web pages were slower on our new virtual servers. The obvious thought is that virtualization=slow. It turns out that compression hadn't been turned on for those servers.
So how was he wrong? The virtual servers were slower.
Your sig(k) has been stolen. There is a puff of smoke!
The sick thing is that it was OBVIOUS it was a Cisco problem from the start. If you make the assumption that the iPhones are somehow defective, it's still a Cisco problem because any defective behavior from an iPhone would be indistinguishable from malicious behavior from a student. The fact that the iPhone was involved really was a non-issue all along.
It was terribly irresponsible of them to go off blaming Apple and, worse, absolving Cisco of responsibility.
Suppose Duke University (and only Duke university) suddenly has problems with all of their Windows boxes. Do you think it's a Windows problem? Given the widespread use of Windows compared to the isolated nature of the problem, it's far more likely that they themselves configured something incorrectly, otherwise all universities should be encountering similar problems.
This isn't to say that there aren't such problems; just as you said, both Cisco and Windows have widespread flaws that affect all universities. But for THIS particular problem, it's more likely to be just a misconfiguration, simply because of the fact that it's localized to Duke.
Seems to be all the rage at Duke. One would think they'd learn from their past mistakes.
"It is a miracle that curiosity survives formal education." -Albert Einstein
When you build a server (not a hobbiest linux box at home) would you rather buy all the parts (cpu, ram, disk, etc..) from ONE vendor, or would you rather buy each component from someone else? You'd call up IBM/hp/dell/sun and order a server, so when the ram breaks you call the same vendor as when the CPU breaks.
While cisco gear may not be the best in every catagory, the solution as a whole is pretty good and there's not a networking vendor that can provide an 'end to end' solution. Plus there's something to be said for being able to put firewall/content/PoE/WAN modules in a single chassis.
Integration and consolidation does save power.
I'm not saying that there aren't vendors with single produts that are better, but NOT all companies/customers are looking for 500 different vendors. You wouldn't build a server farm from 50 different linux servers b/c "IBM w/redhat is better at dns, HP w/Ubuntu is better at samba, Dell/slackware is better at sendmail..." you'd go outta your mind supporting such a hetergenous infrastructure.
Cisco/MSFT have plenty in common. All religions aside, when you hire someone it's much easier to find someone that is familiar (CCIE) with a broad range of cisco products than to find one that has (as you put it), "Juniper for routers. Extreme for Network Switches. Juniper/Netscreen, Fortinet, or even Checkpoint for firewalls." The same holds true if you were hiring someone with office skills. It's much easier to find someone that is well versed in MS-Office than it is to find someone that has the same skillset in lotusnotes, wordperfect, etc...
Building an IT infrastructure is more than just having the 'fastest, best out there'. It's building the best solution for YOUR environment. I work with plenty of clients that have Juniper in the core and cisco at the access/distribution layer.
There are benefits to having only one provider -- like consolidated support and supposed interoperability.
There are also costs, like lock-in -- not only are in a position to be taken advantage of by your single provider in terms of price, but you're actually likely to dimiss technically superior solutions if they don't come from your provider, and your solutions will be inflexible outside the bounds set by your provider.
Take Exchange email as an example. It's not a terrible way to do mail folders, and the integrated calendar is handy. But it means that only Outlook can read your mail, and Outlook only runs on Windows machine and Windows only runs on x86 hardware. Those may all be reasonable choices, but it's not reasonable to make them all simply because you want to run Exchange.
I know Exchange supports IMAP, but there are companies (like my current employer) that won't turn on the IMAP interface because it doesn't fit their one-provider toolchain. I develop on a company-provided linux system for a product that runs entirely in linux, but I have to launch a VM to check my email because of single-provider lock-in.