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?""

More information?

[physicsnick]

I'm curious to find more information on this. TFA just says "Cisco has provided a fix". What nature of fix was this? Was it actually a flaw in the routers, or did someone just configure them wrong?

Given the widespread use of Cisco routers compared to the isolated nature of the problem, it sounds a bit like Duke is just trying to save face.

Correlation is not cause and effect

[PIPBoy3000]

This is unfortunately a common issue with people. When two events happen at about the same time, people assume they're somehow connected. The autism and vaccine link, for example, is one of those things where they get their shots and soon afterwards, they notice their child is acting strangely. Then there's the old "this coincidence must be a sign of the divine" theory.

We run into this all the time when doing server administration. 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. Since he was going over a slow VPN connection, it made a fairly significant difference. Once switched on, they worked about the same as real servers.

Re:Correlation is not cause and effect

[kevorkian]

We run into this all the time when doing server administration. 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. Since he was going over a slow VPN connection, it made a fairly significant difference. Once switched on, they worked about the same as real servers.

Yea , but it was still 'something' related to the change that was made.

The dev may not know all about what was done. All he knows is that "before the change it was fast" and "after the changes it was slow". His only information about the change is that it was new VM servers.

Because of the fact that his knowledge of the change was limited. His observations are no less valid. to him it IS the vm servers that are slower.

You mention server administration , so I assume that you do something tech like as work. When you walk in the door on Monday and there is a problem, do you start trouble shooting the whole system ? or do you first ask "what has changed" and start looking at it from that point ? 9 times out of 10 if something has changed , thats the cause of the problem.

The good thing about this story is about how apple and cisco were able to come together to find the problem. In my experience , cisco is one of the few company's that will admit when its there stuff thats broken. At least once you get through the first levels of support. And duke most likely has a ccie on staff , or a provider contract with cisco to gain access to real support.

Cisco gear just isn't that good.

[CRC'99]

I think that after spending a number of years working in Cisco only networks, I'm constantly amazed at the generally poor compatibility and functionality of Cisco equipment.

This ranges from critical recovery steps being removed from the 7200 series G2 NPE (NEVER make one of these crash to ROMMON on boot. The fix is to RMA the NPE) for Xmodem recovery of bootloaders - something a basic 827 router has to their latest 7961 VoIP SIP phones that are apparently RFC compliant for SIP communications - but aren't.

There are MANY things that make Cisco equipment worse and worse as the years go by. Part of it I believe is the outsourcing of the people who write the software for these things now. Chances are that they weren't even around with Xmodem was in use - and I bet a lot of the coders have NEVER admin'ed a network of Cisco gear. This is the only thing I can think behind removing essential recovery procedures for $35,000AU routers.

There's a whole new direction that Cisco is heading, and with the stupid things missing from their new gear, I'm starting to wonder if it's a direction that will have huge impacts for the worse in the network admin side of life.

Re:So what was it

[freeweed]

Take anything Gartner says and apply the old adage: a stopped clock is correct twice a day. That seems to just about cover their accuracy in most technical matters.

Re:More information?

[Anonymous Coward]

They did this for my university too. And then made us sign an NDA so we wouldn't talk about their hardware sucking. Not me, though, so I don't care...I was just the guy that couldn't do my job until the techies figured out a solution.

http://hardware.slashdot.org/comments.pl?sid=25112 9&cid=19886053 [slashdot.org]

Our other routers and access points work perfectly. For instance, I have a dozen PCs with Intel network cards that when set to autonegotiate, they get pretty much crippled speeds (feels like dialup)...I have to set the speed to something completely different than our network engineers tell me is right to get any decent speed. The throughput is around a third of the others (100bT) on the Cisco routers. On the old HP routers, it worked perfectly. They work perfectly when put back on other networks. I don't really care to try to fix it at this point as these make up a small amount of my machines and unless I'm pushing images, I really don't care about the speed. So it was never just an Apple problem. Cisco makes substandard products these days and don't seem to mind living off their name and reputation of the past.

Re:Cisco gear just isn't that good.

[CRC'99]

...(NEVER make one of these crash to ROMMON on boot. The fix is to RMA the NPE)...

I understand the ROMMON, RMA, and NPE acronyms, but what's NEVER stand for?

The NEVER stands for what I mean when I don't want to sit through 8+ weeks of rubbish from Cisco to get the thing RMA'ed (lucky it was in our testing phase and not live equipment). The TAC closed the case off and refused the warranty and it's been put on the account managers plate to fix. You can think of it as _never_ or never - which ever you like. I still refuse to use the flash tag though ;)

Re:idiots.. But it is true...

[Fallen Kell]

I and my group have experienced this at work all the time almost whenever a new person is hired into the network team. Cisco gear do NOT play nice with Sun Microsystems, be it their desktop workstations or their servers. The Cisco gear refuses to properly auto-negotiate with the equipemnt causing issues such as duplex/simplex mis-matches (i.e. the workstation thinks it is connected at 100 Full duplex, while the switch thinks it is connected at 10 Half duplex). Needless to say this causes all kinds of collisions, IErrors, OErrors, etc., on the system and the network. All the Sun gear must have their associate network partner's port forced to 100 Full, and we do the same for the system as well. How do I know the problem is with the Cisco gear? Because the workstation/server works fine if you use a HP, Xylan, Baynetworks, or other switch. The net network engineers immediately believe it is the Sun equipment because they have been brainwashed into believing that Cisco can't make a mistake or a poor product. It usually takes us to demonstrate using 2 or more other switches that the problem only happens on the Cisco. Cisco still denies that there is a problem as well.

Oh and if you don't believe me, do a google "Cisco problems with Sun"...

Re:More information?

[ZWithaPGGB]

But it isn't Duke, and only Duke, or even iPhones, and only iPhones, that have been having problems with Cisco APs. It's anything other than Windows clients. Cisco has just done a good job of hushing it up by requiring that people sign NDAs to get the fix.

Something is still unexplained though

[lena_10326]

In the original article:

18,000 requests per second from iPhones knocking out dozens of access points at Duke Universit

I don't understand why no one thinks it's a problem that the iPhone didn't back off. It still generated thousands of requests (or responses) to the broken router. It should have detected that and backed off. But then, I'm not very familiar with how ARP works.