Time Warner Cable Ubee Modem: Auto-Negotiation Failure Results in Poor Internet Performance

5 October 2012 by 12 Comments

Last week, I visited a client to test their Internet speed. The company is paying for a 35Mb/s down and a 5Mb/s upload speed. However, when the company ran speed tests, the results revealed they were only getting 4Mb/s down and 3Mb/s up. To verify that the LAN side of the network wasn’t causing the problems, I connected my laptop directly to the Ubee DDW3600 series modem provided by Time Warner Cable, and ran a speed test. To my surprise, when I directly connected my laptop – BOOM: 35Mb/s down and 5Mb/s up. The modem was receiving the full bandwidth, but the connection between the LAN and WAN had a serious bottleneck.

The connection to the WAN was the “outside” interface on a Cisco ASA 5505. The interface was hard-coded to 100Mb/s, full-duplex.

“show int ethernet 0/0″ provided some very interesting output!

647803 CRC errors! Cyclic redundancy errors are almost ALWAYS due to speed/duplex mismatch. After waiting on hold with TWC for a while, tech support checked the modem, and what do you know…their Ubee modem auto-negotiated to 1000Mb/s instead of 100Mb/s! This drove me crazy after being sure to check that the firewall port was set to not auto-negotiate to prevent this exact problem! After TWC changed the port speed of their modem, the internet speed jumped to full 35Mb/s down and a 5Mb/s up.

The office I work at has an identical modem, and the office also has had slow internet speed. I checked the interface on the firewall at the office, and it had 6 million CRC errors! Another call into TWC. 20 minutes later, tech support had found the SAME problem on TWC’s modem. The tech I spoke with at TWC said that they see this all the time, and it is a known issue. The Ubee modem will see the other side as a 100Mb/s connection, but still set its local port speed to 1000!

I am posting this as a warning to always be sure to have the ISP define their port speed on the modem/router which connects to the outermost part of the network. It could save you a lot of hassle!

Filed Under: Blogs, Service Provider, Switching Tagged With: , ,
About Alex Clark

Alex Clark is a 21 year old college student from Ohio who was lucky enough to discover what he loves early on in life: Networking, Cisco, Linux and other nerdy activities. He works as a network engineer/analysts and is working towards his next certification whenever there is free time. He has earned his CCNP, CCNA: Security, CCNA: Wireless, CCDA and CCNA. He is actively working on the CCIE R& S and hopes to sit the lab before 2014. In the more immediate future, he is finishing his CCDP.

  • http://northlandboy.com/ Lindsay Hill

    I thought we’d moved on from hard-coding speed/duplex. See Greg’s post (http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/) for more. These days, you really, really don’t want to be hard-setting speed/duplex. I’ve done it many times in the past, but I freely admit to the error of my ways. There are the odd cases where it might be required, but never for Gigabit.

    If the ASA was hard-coded, and the modem was set to auto, then I would expect to see that issue you’ve got, where the modem falls back to 100/half, since it’s not seeing any attempt at autonegotiation, and so has to assume it’s plugged into a hub.

    I don’t quite follow what you’re saying about how the modem would see the other side as 100Mb, but set its local speed to 1000Mb – shouldn’t that result in link down, rather than duplex mismatch?

    What happens if you set the ASA to auto? I would have expected that auto on both ends would result in a working 100/full connection.

    • Alex__Clark

      Interesting. It has been beaten into me by professors/co-workers to always set speed/duplex rather than auto-negotiation. (The horrible “‘auto’ not do it” comes to mind) But from you have said, it seems this is no longer the case.

      What I mean by the modem seeing the other side as 100 mb/s I mean that both times the TWC tech logged into the modem, the modem showed that the device it was connected to WAS running 100mb. In other words, the modem did not think the other side was running 1000 mb/s, it saw it as 100 mb/s and still set its port to 1000. Both TWC techs verified this, and both gave an excuse about the firmware having a bug. (I must admit this is relying on the word or 2 techs, I did not see the Ubee config myself)

      And the link was full-duplex on either side, but speed mismatch. Therefore I am under the impression that the modem did not believe the ASA to be a hub.

      • http://northlandboy.com/ Lindsay Hill

        Full dup on both sides, but speed mismatch, and yet the link came up? Sounds very odd to me. I don’t think I’ve ever seen a link come up in that situation. I can’t see how it would work – clocking is wrong, Gigabit uses all four pairs….I suspect part of your problem is like you say – it’s coming from someone else, and you didn’t see the modem itself.

        Anyway, like in Greg’s post, the speed/duplex hard set thing is historical, but it takes us a long time to get past those sorts of things. Personally I think you are best to use auto everywhere, AND have your NMS alert you to high levels of errors in your network.

        If you’re getting professors telling you that you should hard-set your links, ask them if they believe that applies to Gigabit links. (search around on Greg’s site for more info about why they’re wrong if they think that).

        All up though, it’s amazing how much these little things can just hammer a network’s performance, and how much of a hero you can be by fixing it – with no extra cost or kit involved. It’s the sort of thing that I’ve seen far too often in production networks, where people didn’t know or care enough to track down the performance issues. As soon as the link was up, and the ping worked, they moved on. Shame.

        • http://twitter.com/cjinfantino CJ Infantino

          @northlandboy:disqus I agree with you – we _shouldn’t_ need to set speed/duplex anymore. But, I am finding that with carrier equipment, specifically ONTs, it is necessary to set speed/duplex. It is pretty unbelievable that we haven’t move past this, but I have seen issues with auto-neg more than once. Again, I have only seen this on carrier equipment.

          • http://northlandboy.com/ Lindsay Hill

            Yeah actually now that you mention it, I’ve seen this on media converters, since they have a hard switch, and don’t do any negotiation themselves.

      • Nigel Roberts

        It’s not possible for a link to be up with a speed mismatch due to the differences at layer 1 between FE and GE. It’s either duplex mis-match and CRC errors as you saw, or no link at all. In my experience disabling auto negotiation for GE causes more problems than it solves, such as what you’re seeing in this case.

    • Auto-Neg

      That is crap and what I consider hogwash! There is nothing wrong about hard-coding the speed and duplex of an interface, as long as you do the same to the other side!

      • http://northlandboy.com/ Lindsay Hill

        That is what @etherealmind would call “mythinformation”. Hard-coding gigabit links IS a problem. For proper performance, Gigabit links need to be able to negotiate. Read the link I gave previously. Gigabit Ethernet is not just 100Mb but faster. The standards have changed.
        You also point out one of the main problems with hard-coding settings – it means you have to do it on both sides, or otherwise performance is crap. Why not just leave it on auto on both sides and be done with it? Why create work for yourself, and risk poor performance? If you still have a policy of hard-coding settings everywhere then A) You’re making your life harder than it needs to be, and B) You need to re-evaluate whether those reasons that existed 10 years ago are still valid today.

  • http://twitter.com/networkdongle garry baker

    This was something I had to come to terms with when I came from Enterprise networks to service provider the gear would not work without playing with duplex speed settings….

    It is part of the Gigabit standard that you need auto and with10/100/1000 cards I assumed that in the SP I worked with but they had and still are doing hard coding all over the network…

  • Michael Gonnason

    Always auto/auto, unless there is a bug in the host NIC, then it is hardset in lieu of the server team fixing it.

    Desktops are always auto/auto and they work almost all the time. Why should it be any different with servers and other network gear?

  • drkat

    So Auto negotiation acts just like any other protocol – both sides need to be speaking it :) Gigabit negotiates auto negotiation much differently than 10/100 links, so auto/auto is ideal for 1000mbps.

    if TWC was 100/half and the ASA is 100/full we will not see late collisions on the ASA interface counters. You will see input errors/crc etc – the ASA side is full and doesnt care to record collisions as it doesnt know anything about them, it being in full duplex mode.

    The TWC side would have seen collisions / errors – the text book “theory” of auto negotiation and what you’re going to see does vary on model to model. I have seen duplex mismatch without any collision errors and only input.. I’ve seem just CRC errors, it depends on vendor equipment. In a perfect world between two cisco devices I’d expect to see what cisco says we’d see.

    I would have suspected shutting down the ASA interface, changing the duplex to auto and bringing it back up would have resolved the issue.

    Network Warrior 2nd edition provides a wonderful explanation of auto negotiation protocol.

  • Robert

    What do I tell Time Warner once I am on the phone with them? I’ve had 2 techs come out to my house and nothing has resolved the packet loss issue.