Author: peter

According to this post, a huge chunk of us white-collar types are playing games at work. I find this number rather high, and somewhat hard to believe. One in four? The way I figure it, this means the entire IT industry (and I mean everyone) is playing games in the server room at lunchtime. I just don’t buy this number, unless you count Solitaire, in which case the number is pathetically low.
Either that, or we really gotta play more games at Paradigm. We used to do this on our lunch break, almost every day, but things tapered off over time. In the late 90’s, we played lots of RTS games like Age of Empires and Starcraft. A few years ago, it was GuildWars and World of Warcraft. Now that I employ a former guildie of mine, perhaps we should do this again. I’m sure our clients would love to hear the sounds of dying Fel Orcs and Shadow Council Warlocks when we answer the phone on our lunch break.

So, it turns out that the root cause of all of our problems that we were troubleshooting with the new content filtering software that was deployed. Somehow, it was instructed (or just decided) to install itself onto our two domain controllers, among others. This resulted in our DCs sending all traffic out to our content filter, which is a hosted service on the Internet, for perusal, before sending it back to the client. No wonder we had so many delays and disconnects.
This really was a comedy of errors, which included a faulty NIC in one of the servers, as well as a poorly-configured switch cascading setup. Throw the content filtering debacle into it, and we had a real mess.

1. Backed up /etc/X11/xorg.conf to xorg.conf.bak
2. Copied the section entitled
   Section “Device”
   Identifier “nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x]”
   Driver “nv”
   BusID “PCI:1:0:0”
   EndSection
   
   and pasted in then modified so that I had a second section as follows:Section “Device”
   Identifier “nVidia Corporation NV18 [GeForce4 MX 5200 AGP 8x]”
   Driver “nv”
   BusID “PCI:2:0:0”
   EndSection
   Note, the Identifier doesn’t need to actually be the name of the card, as it’s just used for your reference. I don’t even know for certain that I have an MX 5200, and I know it’s not AGP, but I was in a hurry, so I left it as is. The important part is the BusID section. Since I knew my working, default monitor was in PCI slot 1, and the second card I had was in the next slot, and that both cards were using the DVI ports, I simply changed BusID “PCI:1:0:0” to read BusID “PCI:2:0:0” in the second “Device” section.
3. Copied the “Monitor” section so that I started with
   Section “Monitor”
   Identifier “UltraSharp 1800 1”
   Option “DPMS”
   HorizSync 28-51
   VertRefresh 43-60
   EndSection
   
   and then had, in addition,Section “Monitor”
   Identifier “UltraSharp 1800 2”
   Option “DPMS”
   HorizSync 28-51
   VertRefresh 43-60
   EndSection
4. Copied the “Screen” section so I started with
   Section “Screen”
   Identifier “Default Screen”
   Device “nVidia Corporation NV18 [GeForce4 MX 440 AGP 8x]”
   Monitor “UltraSharp 1800 1”
   DefaultDepth 24
   SubSection “Display”
   Depth 1
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 4
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 8
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 15
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 16
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 24
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   EndSectionthen had, in addition,
   Section “Screen”
   Identifier “Default Screen”
   Device “nVidia Corporation NV18 [GeForce4 MX 5200 AGP 8x]”
   Monitor “UltraSharp 1800 2”
   DefaultDepth 24
   SubSection “Display”
   Depth 1
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 4
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 8
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 15
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 16
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   SubSection “Display”
   Depth 24
   Modes “1024×768” “800×600” “640×480”
   EndSubSection
   EndSection
5. Finally, I added the italicized line to my “ServerLayout” section
   Section “ServerLayout”
   Identifier “Default Layout”
   Screen “Default Screen”
   Screen “Second Screen” RightOf “Default Screen”
   InputDevice “Generic Keyboard”
   InputDevice “Configured Mouse”
   InputDevice “stylus” “SendCoreEvents”
   InputDevice “cursor” “SendCoreEvents”
   InputDevice “eraser” “SendCoreEvents”
   EndSectionto add my new, second screen to the right of the default screen.
6. I rebooted, and then BAM! It worked. Took about five minutes.

I am astounded as to the lengths that Spencer, the tech who is handling my case where we are working to address extremely slow network performance, will go. The service we are getting is incredible, and this is all included just because we purchased ProCurve equipment. Combine this with their lifetime warranty, and this is an “I will never purchase another manufacturer’s switch again” situation.
Seriously, I’ve never met a vendor who would provide such service and support for free. I still cannot believe it. No contracts to purchase, no nothing. Just because we have all HP equipment on the LAN, we’re getting phenomenal service. Other vendors would do well to follow ProCurve’s example.

I spent an entire day troubleshooting odd network problems at a local client last Friday. The symptoms were:

• Users could not
• get their email
• access files on the server
• log on successfully
• Internet access was sluggish, for some users, but fine for others.
• Software deployments from across the networks (content filtering software, Ghost images, GPO-deployed packages) would not deploy.
• Ping times from a workstation to a server (across 5 switches) ranged anywhere from <1ms to several thousand ms, or just plain timeouts.
• Ping times from a workstation to another workstation, connected on the same switch, were only marginally better, resulting in anything from 1ms to frequent timeouts and dropped packets.
• Ping times to the local switch, to which the servers were plugged in, ranged from 1ms to several hundred ms.

Several hours of troubleshooting resulted in the following highlights:

• After two hours of capturing packets, 30% of all network traffic was ARP. This is with only a handful of desktop machines powered on. Not good.
• Rebooting one switch made a huge difference, and all of a sudden network traffic was working again. However, things were still slow on occasion.

So tomorrow I will be making some VLANs to cut down on the broadcast traffic across these eight or so switches. Fun!