Network Perils

It’s been a week of networking pain. For the past few weeks Comcast has been using a low DHCP lease time. 30 minutes to be exact. This is typical of when they are doing network upgrades/repairs and is what a normal network administrator does. It’s similar to lowering the TTL for DNS.

Renewing the DHCP lease is normally a pretty transparent process, but this time around it’s been causing network connections to drop. While this process is relatively quick, it still resulted in a brief network outage that would kill connections. Occasionally it created a spike when things came back online, which made it feel even longer due to the resulting lag.

No configurations have changed in a long time other than a firmware upgrade a few months ago. Strange I thought. Why is it insisting on on loosing the IP and rediscovering, rather than just renewing? I let it go for a few days hoping Comcast’s low DHCP lease time would be temporary. After 2 weeks I decided to dig deeper.

After a few emails with Motorola’s tech support (Motorola bought Netopia in 2007) they came to the conclusion that the renew-lease ACK packet wasn’t reaching the router. They suspected the firewall wasn’t allowing it to pass, as a result it was dropping the IP, and requesting it again from the DHCP server. They suggested opening up UDP/67 and UDP/68 on the firewall. This seems to resolve the problem. I’m still seeing the lease drop at about 1:00 AM for the past 2 nights, but that’s really a low priority issue and may indeed be on Comcast’s end. It’s possible the router was renewing the hard way every 24-72 hours for a few months, but I know Comcast’s DHCP lease time has been lowered before and the router didn’t exhibit this behavior. Perhaps the firmware upgrade changed the firewalls behavior? I don’t recall that in the docs. Regardless, it’s fixed.

Now today, the UPS for the router, modem and file server’s battery died. Yet another pain. I was able to swap the battery with a similar model UPS from another computer for now. I can deal with that other computer later.

Now maybe I can take my networking hat off for a little while.

WMM Slowdown

I turned on Wireless Multimedia (WMM) support the other day on my wireless network, figuring QoS for a wireless network would pretty much be a slam dunk. For those who don’t know, the four access categories it uses are:

  • voice
  • video
  • best effort
  • background

I was surprised to find, at least with the Netopia box that this actually resulted in a significant slowdown in http traffic, even when there was no other services being used. To put some numbers out there, we’re talking 10000 kbps with it enabled vs. 17400 kbps when disabled (these aren’t scientific, they are just bandwidth tests). I think the performance hit negated any real benefit, at least in this case. The box doesn’t handle much VoIP, so it really doesn’t do much. Video is more about raw bandwidth these days than latency thanks to CDN’s becoming more common and reducing the bulk of the latency issue. Also interesting is that the CPU hit seems pretty minimal. Daily average increased from 2% to about 4%, it’s double but really nothing serious. With it enabled it never spiked past 50%, and that was only one time.

So after a few days testing, WWM is turned off. Seems QoS at least in this case doesn’t pay. I can’t complain, wireless performance (20Mbps+) and signal strength are fantastic (when the microwave isn’t on) for an 802.11g network. Despite that, there’s always the desire to find ways to make it even better. Next step would be 802.11n, but I have a thing against uncertified gear. Once it’s standardized, I’d strongly consider it, especially if I can find a device that supports Linux firmware.

Experiment complete.