I doubt this has anything to do with DNS. DNS is used to convert a hostname into an IP address. If there was an error at that stage the error would be something like "Host not found". Also there would be no retries and the FDCONNECT timeout wouldn't come into play. In addition, it is most likely going to be the same DNS for different subnets in a corporation or at the very least they'll be configured with the same timeouts.
To have a routing problem you have to be at the stage of sending packets. Once you have an IP address you need to figure out which interface to send it on. So if it wasn't on the same subnet and there were no default gateway configured you could end up with a no route to host. But that wouldn't be affected by whether the host were up or not. So it must be able to figure out which interface to use. So now you need to figure out to which Ethernet MAC address the packet should be addressed. This process uses the ARP protocol (Address Resolution Protocol). For the same subnet it tries to map the hosts IP address to a MAC address. For different subnets, it tries to map the IP address of the default gateway. So I stand by my original problem analysis. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arno Lehmann Sent: Friday, October 27, 2006 2:44 AM To: bacula-users@lists.sourceforge.net Subject: Re: [Bacula-users] Different timeouts in different subnets Hi, just some minor correction (or assumption...): On 10/27/2006 5:54 AM, Robert Nelson wrote: ... > The reason for the differences is probably caching on the switch. I suspect > that in the same subnet case the arp is failing (so the IP address can't be > converted to an Ethernet address), in the other case the switch is > responding to the arp and a higher level (and longer timeout) is coming into > play, probably the TCP connect timer. I rather suspect that in one case the DNS was already cleared of the host name (message No Route to Host) while in the other case the DNS still had a record for the host and thus the tcp stack had to actually try the connect, and thus rely on the underlying IP timeouts (error message Timeout). Arno -- IT-Service Lehmann [EMAIL PROTECTED] Arno Lehmann http://www.its-lehmann.de ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
