Despite my triumph earlier in the day in discovering a duplex mismatch that was overlooked, I also spent far to much time thinking about another problem in which I forgot my basic IP handshaking and routing fundamentals.

We’re migrating to a new ISP, so in a flash of brilliance I figured I’d setup another interface on the PIX to test the new connection. The connection appeared to be up, since I could see the flood of Windows zombies attempting to connect already. But I was unable to actually pass any data over the link.

After poking around the logs I determined that the firewall was not blocking anything, nor was iptables on the web server. I plugged in a hub between the web server any the firewall, and ran ethereal on my notebook to see what was happening. What I saw was the handshaking failing on the link. SYN packets would come in from my external host, and the server would send the SYN-ACK back. The external host would then reset the link with an RST.

I thought about it for a bit before realizing my downfall: the web server is NAT’d behind the firewall. The external host was sending to one address, but the firewall was sending the reply on a different address. The external host thinks “spoof” and resets the connection.

We have been receiving complaints of slow printing services on and off for the last couple of months at the centre, but had been unable to nail down any problems. Endless combing through documentation and reviews of the settings turned up nothing. Today I happened to recognized the problem while doing some other network configuration work.

It turns out the server that handles the print queues had its interface locked at 100Mbs full-duplex. The switch was set to auto-negotiate, resulting in it setting the connection at half-duplex. This is a recipe for exactly the kinds of problems we were experiencing - poor performance under load. Once the server was configured to auto-negotiate the link (since it will be moving to a new switch soon), printing performance drastically improved. Printing a PDF with graphics that took several minutes at times now prints in seconds.

This quote excerpt from Critical Networks Advanced Ethernet pages explains netter than I could how the duplex mismatch occurs:

So how does a duplex mis-match occur? The process below describes just one common scenario where one device is auto-negotiating but the other device is hard coded for full duplex:

1. The hard coded device is configured for 100baseTX full duplex (100FD) operation. It does not listen for FLPs sent by the other device, it simply waits for the correct idle signal before making the link active
2. The auto-negotiating device will notice the absence of FLPs and will see the 100baseTX idle signal using parallel detection. It will make the link active as 100baseTX half duplex (100HD).
3. Now link is active on both devices and data will be transmitted, but there will be performance problems
4. The hard coded 100FD device can send data at any time regardless of whether the 100HD device is transmitting. This causes the 100HD to detect both excess and late collisions and to abort the current frame in mid-transmission. This in turn causes the 100FD device to see many runts, alignment, CRC and FCS errors.