brian_chee
Contributing Editor

Once upon a time there was an arp entry

analysis
Feb 12, 20082 mins

So a short story for you… …once upon a time I was hosting a research server behind my firewall and had done one-to-one NAT to hide and protect it…however, the researchers decided they wanted their own firewall and moved down the hall, but were still using the same “public address” for their server…things were kinda ok, weird slowdowns and such came and went but we couldn&#8217

So a short story for you…

…once upon a time I was hosting a research server behind my firewall and had done one-to-one NAT to hide and protect it…however, the researchers decided they wanted their own firewall and moved down the hall, but were still using the same “public address” for their server…things were kinda ok, weird slowdowns and such came and went but we couldn’t put our fingers on it…well today I swapped in my super duper faster firewall that went from a 100mb/sec uplink to a gigabit uplink and from a VIA processor to an Intel Xeon with multiple Caveum encryption processors….about a 100 fold increase in throughput possible…well now the researcher’s itty bitty NetGear FVS-318 (max 1mb/sec WAN) was never able to provide an arp response fast enough to the upstream switch, and all requests to that server kept going to my firewall, which kept saying that the server wasn’t there….sigh…when I finally killed the address objects for the server, everything sped up and I’m sitting here with egg on face….

The moral of the story is that you should never put off doing cleanups, not even if folks are screaming at you…this little cleanup chore actually has costed me quite a bit of time tracking down a red herring slowdown…that was just a cleanup job left undone…

sigh…

/brian chee