The Wierd Tracert Results thread got me thinking about a long-time problem I have on my network that no one has been able to resolve. Two servers, identical hardware, identical operating system (NetWare), pretty similar amounts of data on both. Both are simple print/file servers, nothing strange running on them. I was called in because the local SysAdmin noticed that one box took about 45 minutes to do the nightly back up, one takes almost 6 hours. No one is accessing these boxes at night, and there shouldn't be any open files. They both back up to the same device using ArcServe 6.6

So, my guy couldn't find anything wrong with the servers or the back up system. I got my start in IT as a wire dog, and now am the Cisco guy, and he was (is) pretty sure it's an infrastructure problem. So I went down to the site with my handy-dandy Fluke meter and did a network health check. Everything looks totally normal. Both connect to an old Cabletron fiber MUX, and are on the exact same network segment. In fact, their addresses are x.x.x.19 and .20.

The only bit of strangeness I could find was this. When I pinged .19 from a host on the segment, my TTL didn't decrement a bit, that is, it remained 255 as it should have. When I ping .20 from the same host, on the same segment, the TTL decrements to 128. It is .20 that takes forever to back up.

I tested and changed the patch cords out, and moved which port on the mux the servers attach to, nothing changes the results. There is only a dumb L2 switch and the mux between the servers and the host I pinged from, so it's not a misconfigured VLAN, or anything of that nature. I've run this past a couple of people, but no one seems to know what would cause this. I have no idea if the TTL wierdness has anything to do with the back up issues, but we really can't find anything else wrong.

Ideas?