Re: {Spam?} RE: local area connection!
A Windows XP Informix server got a second NIC on a different IP range; local connections stayed fast (1-2s) but clients from the other subnet took ~25 seconds to connect. Clive Eisen (backed by RedGrittyBrick and Fernando Nunes) argued this delay is classic forward/reverse DNS resolution timeout, since a true routing problem would make connections fail outright rather than succeed late; Ian Gumby pushed for missing static routes/NIC misconfiguration. Suggested tests: nslookup from client and server, adding the client to the hosts file, checking sqlhosts (especially *hostname), or a Wireshark trace. The thread degenerated into bickering and the original poster never reported back, so no confirmed resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Ian Michael Gumby wrote: > > > > Date: Wed, 27 May 2009 13:45:53 +0100 > > From: clive@serendipita.com > > CC: informix-list@iiug.org > > Subject: Re: local area connection! > > > > Dray wrote: > > > OS is Win Xp Pro > > > "Dray" <dray@dray.com> wrote in message > news:gvj9a8$8nb$1@ss408.t-com.hr... > > >> We added another lan card on the computer(informix server), but > now we > > >> have slower connection on database! Each card has it own ip range! > On a > > >> local server connection on the database is ok(1,2 seconds),but > when some > > >> host tray to connect to database(from another ip range then local) > he need > > >> app. 25 seconds! > > >> How to solve this? > > > > You have not set up forward and/or reverse dns for the new nic > > > > You may not have to set up a DNS entry. > Suppose the nic is for an internal network. > > I would suspect that when the card was configured possibly the routing > information wasn't set up. And I would suspect that you are blowing again Gumby. The OP didn't say it never connected - he said it takes 25 seconds
On May 27, 8:24 am, Clive Eisen <cl...@serendipita.com> wrote: > Ian Michael Gumby wrote: > > > > Date: Wed, 27 May 2009 13:45:53 +0100 > > > From: cl...@serendipita.com > > > CC: informix-l...@iiug.org > > > Subject: Re: local area connection! > > > > Dray wrote: > > > > OS is Win Xp Pro > > > > "Dray" <d...@dray.com> wrote in message > >news:gvj9a8$8nb$1@ss408.t-com.hr... > > > >> We added another lan card on the computer(informix server), but > > now we > > > >> have slower connection on database! Each card has it own ip range! > > On a > > > >> local server connection on the database is ok(1,2 seconds),but > > when some > > > >> host tray to connect to database(from another ip range then local) > > he need > > > >> app. 25 seconds! > > > >> How to solve this? > > > > You have not set up forward and/or reverse dns for the new nic > > > You may not have to set up a DNS entry. > > Suppose the nic is for an internal network. > > > I would suspect that when the card was configured possibly the routing > > information wasn't set up. > > And I would suspect that you are blowing again Gumby. > > The OP didn't say it never connected - he said it takes 25 seconds Uhm are you so sure? I'm not expurt on Microsoft's OS, but you know you don't need to have DNS set up in order to handle TCP/IP. In a Unix environment, you could just rely on /etc/hosts and routing tables for everything. Based on what little the OP said, the issue is that when the connected the second NIC card, things went to hell. 25 seconds response time? Sounds like something is timing out before switching to the second Nic card. But hey! What do I know? I just run Informix on *real* operating systems like *nix. :-P -G
Ian Michael Gumby wrote: > > But hey! What do I know? I just run Informix on *real* operating > systems like *nix. :-P Indeed. So why do you feel the need to butt in to things, of which, you admit to knowing nothing? -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: > Ian Michael Gumby wrote: > > > But hey! What do I know? I just run Informix on *real* operating > > systems like *nix. :-P > > Indeed. So why do you feel the need to butt in to things, of which, you > admit to knowing nothing? > > -- > Cheers, > Obnoxio The Clown > That has never stopped you. ;-)
Ian Michael Gumby wrote: > On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> > wrote: >> Ian Michael Gumby wrote: >> >>> But hey! What do I know? I just run Informix on *real* operating >>> systems like *nix. :-P >> Indeed. So why do you feel the need to butt in to things, of which, you >> admit to knowing nothing? >> >> -- >> Cheers, >> Obnoxio The Clown >> > > That has never stopped you. ;-) I never admit it. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
On May 27, 3:09 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: > Ian Michael Gumby wrote: > > On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> > > wrote: > >> Ian Michael Gumby wrote: > > >>> But hey! What do I know? I just run Informix on *real* operating > >>> systems like *nix. :-P > >> Indeed. So why do you feel the need to butt in to things, of which, you > >> admit to knowing nothing? > > >> -- > >> Cheers, > >> Obnoxio The Clown > > > That has never stopped you. ;-) > > I never admit it. > LOL! Yeah you're a cheeky bastard. But getting back on target, the issue doesn't sound like one of just putting in a DNS entry for the second nic card. Of course I don't know how badly Microsoft has munged things up, but the problem the OP sounds like he's having is that his connection isn't routing properly so it tries the first nic that it sees and then times out goes to the next nic card ... Without knowing what the OP's network configuration looks like, he'll need to at least set up some static routes as to where he expects his traffic to go. Also he may want to set up a second tcp/ip entry for his secondary network. It doesn't make sense that users on the second (new) nic card would want to connect via tcp/ip on the first nic card, now does it? You know the old expression, the more you know, the more you realize what you don't know. So what do I know? (I know nuthing, nut ting! ) [Old Hogan's Heros episodes are still being played on cable....] ;-) -G
Ian Michael Gumby wrote: > On May 27, 3:09 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: >> Ian Michael Gumby wrote: >>> On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> >>> wrote: >>>> Ian Michael Gumby wrote: >>>>> But hey! What do I know? I just run Informix on *real* operating >>>>> systems like *nix. :-P >>>> Indeed. So why do you feel the need to butt in to things, of which, you >>>> admit to knowing nothing? >>>> -- >>>> Cheers, >>>> Obnoxio The Clown >>> That has never stopped you. ;-) >> I never admit it. >> > LOL! > Yeah you're a cheeky bastard. > > But getting back on target, the issue doesn't sound like one of just > putting in a DNS entry for the second nic card. > > Of course I don't know how badly Microsoft has munged things up, but > the problem the OP sounds like he's having is that his connection > isn't routing properly so it tries the first nic that it sees and then > times out goes to the next nic card ... > And how oh great one do you think thats gonna happen - they nics will have different IP addresses. So the client tries to connect to a.b.c.d - fails (actually it doesnt - it's just waiting for reverse dns which times out as I said earlier) and then magically guesses the ip address of the other nic and connects to that - right! As I said before Gumby - you really do blow when it comes to how networks work.
On May 28, 3:21 am, Clive Eisen <cl...@serendipita.com> wrote: > > As I said before Gumby - you really do blow when it comes to how > networks work. Really? Riddle me this then sparky, what happens when you have the same host name resolving to two different ip addresses?
Ian Michael Gumby wrote: > On May 28, 3:21 am, Clive Eisen <cl...@serendipita.com> wrote: > >> As I said before Gumby - you really do blow when it comes to how >> networks work. > > Really? > Riddle me this then sparky, what happens when you have the same host > name resolving to two different ip addresses? Actually it depends what the client does with the DNS lookup - which will be returned in random order, so in your scenario sometimes his connect should be instant - which is not what he said. It MAY fail over to the next entry, but it MAY not - client dependant. And if it did that would imply that there is an entry for both nics in the DNS and as I said ( now twice ) there isn't - or at least there isn't a reverse entry.
On May 28, 3:21 am, Clive Eisen <cl...@serendipita.com> wrote: > Ian Michael Gumby wrote: > > On May 27, 3:09 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: > >> Ian Michael Gumby wrote: > >>> On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> > >>> wrote: > >>>> Ian Michael Gumby wrote: > >>>>> But hey! What do I know? I just run Informix on *real* operating > >>>>> systems like *nix. :-P > >>>> Indeed. So why do you feel the need to butt in to things, of which, you > >>>> admit to knowing nothing? > >>>> -- > >>>> Cheers, > >>>> Obnoxio The Clown > >>> That has never stopped you. ;-) > >> I never admit it. > > > LOL! > > Yeah you're a cheeky bastard. > > > But getting back on target, the issue doesn't sound like one of just > > putting in a DNS entry for the second nic card. > > > Of course I don't know how badly Microsoft has munged things up, but > > the problem the OP sounds like he's having is that his connection > > isn't routing properly so it tries the first nic that it sees and then > > times out goes to the next nic card ... > > And how oh great one do you think thats gonna happen - they nics will > have different IP addresses. > > So the client tries to connect to a.b.c.d - fails (actually it doesnt - > it's just waiting for reverse dns which times out as I said earlier) and > then magically guesses the ip address of the other nic and connects to > that - right! > > As I said before Gumby - you really do blow when it comes to how > networks work. Clive, Sorry to double post, but I have to ask... when did DNS tell a server which route to take? If that isn't a big enough clue for you, then I suggest that you consider the following... OP adds second Nic card, all hell breaks loose. Is this an issue with a change on the server side or on the client side? Its rhetorical... Also, consider that the clients use DNS, and the server will know the IP address of the client, why would the server not know how to resolve the client's IP address? So really a DNS issue isn't the first place to guess. But not knowing the route to the client, now that's a problem. Isn't it? Where do you set up your routing information? In DNS? I don't think so. Now since the OP didn't really provide a lot of information, we really should be asking more questions. But since we all like to jump the gun in an effort to help, the first place to look is on the server itself. Here's a really simple test. Have the OP disable the second Nic. Do the problems continue or do they go away? Note: Disabling the Nic is a lot easier than actually taking the card out. The OP may want to disable both Nics, enable the main Nic and possibly bounce the Informix engine. He could also reboot if he wants to be damn sure that everything is cleared out and that only the first Nic card is active. But that's really overkill. If the problem suddenly goes away, then poof! Your DNS idea isn't really supported. But hey! What do I know?
Ian Michael Gumby wrote: > > But hey! What do I know? Well, given that Clive does this shit for a living and you're too busy telling everyone else what they are doing wrong to earn a living, I'm going to go with Clive on this one. -- Cheers, Obnoxio The Clown http://obotheclown.blogspot.com -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.
Ian Michael Gumby wrote: > On May 28, 3:21 am, Clive Eisen <cl...@serendipita.com> wrote: >> Ian Michael Gumby wrote: >>> On May 27, 3:09 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: >>>> Ian Michael Gumby wrote: >>>>> On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> >>>>> wrote: >>>>>> Ian Michael Gumby wrote: >>>>>>> But hey! What do I know? I just run Informix on *real* operating >>>>>>> systems like *nix. :-P >>>>>> Indeed. So why do you feel the need to butt in to things, of which, you >>>>>> admit to knowing nothing? >>>>>> -- >>>>>> Cheers, >>>>>> Obnoxio The Clown >>>>> That has never stopped you. ;-) >>>> I never admit it. >>> LOL! >>> Yeah you're a cheeky bastard. >>> But getting back on target, the issue doesn't sound like one of just >>> putting in a DNS entry for the second nic card. >>> Of course I don't know how badly Microsoft has munged things up, but >>> the problem the OP sounds like he's having is that his connection >>> isn't routing properly so it tries the first nic that it sees and then >>> times out goes to the next nic card ... >> And how oh great one do you think thats gonna happen - they nics will >> have different IP addresses. >> >> So the client tries to connect to a.b.c.d - fails (actually it doesnt - >> it's just waiting for reverse dns which times out as I said earlier) and >> then magically guesses the ip address of the other nic and connects to >> that - right! >> >> As I said before Gumby - you really do blow when it comes to how >> networks work. > > Clive, > Sorry to double post, but I have to ask... when did DNS tell a server > which route to take? > > If that isn't a big enough clue for you, then I suggest that you > consider the following... > > OP adds second Nic card, all hell breaks loose. Is this an issue with > a change on the server side or on the client side? > Its rhetorical... > > Also, consider that the clients use DNS, and the server will know the > IP address of the client, why would the server not know how to resolve > the client's IP address? So really a DNS issue isn't the first place > to guess. > > But not knowing the route to the client, now that's a problem. Isn't > it? > Where do you set up your routing information? In DNS? > I don't think so. > > Now since the OP didn't really provide a lot of information, we really > should be asking more questions. But since we all like to jump the gun > in an effort to help, the first place to look is on the server itself. > > Here's a really simple test. > Have the OP disable the second Nic. Do the problems continue or do > they go away? Note: Disabling the Nic is a lot easier than actually > taking the card out. The OP may want to disable both Nics, enable the > main Nic and possibly bounce the Informix engine. He could also reboot > if he wants to be damn sure that everything is cleared out and that > only the first Nic card is active. But that's really overkill. > > If the problem suddenly goes away, then poof! Your DNS idea isn't > really supported. > > But hey! What do I know? It seems absolutely nothing. I give up Gumby - I'm not here to teach you how networks work. And you DO have a lot to learn.
Ian Michael Gumby wrote: > On May 28, 3:21 am, Clive Eisen <cl...@serendipita.com> wrote: >> Ian Michael Gumby wrote: >>> On May 27, 3:09 pm, Obnoxio The Clown <obno...@serendipita.com> wrote: >>>> Ian Michael Gumby wrote: >>>>> On May 27, 12:01 pm, Obnoxio The Clown <obno...@serendipita.com> >>>>> wrote: >>>>>> Ian Michael Gumby wrote: >>>>>>> But hey! What do I know? I just run Informix on *real* operating >>>>>>> systems like *nix. :-P >>>>>> Indeed. So why do you feel the need to butt in to things, of which, you >>>>>> admit to knowing nothing? >>>>>> -- >>>>>> Cheers, >>>>>> Obnoxio The Clown >>>>> That has never stopped you. ;-) >>>> I never admit it. >>> LOL! >>> Yeah you're a cheeky bastard. >>> But getting back on target, the issue doesn't sound like one of just >>> putting in a DNS entry for the second nic card. >>> Of course I don't know how badly Microsoft has munged things up, but >>> the problem the OP sounds like he's having is that his connection >>> isn't routing properly so it tries the first nic that it sees and then >>> times out goes to the next nic card ... >> And how oh great one do you think thats gonna happen - they nics will >> have different IP addresses. >> >> So the client tries to connect to a.b.c.d - fails (actually it doesnt - >> it's just waiting for reverse dns which times out as I said earlier) and >> then magically guesses the ip address of the other nic and connects to >> that - right! >> >> As I said before Gumby - you really do blow when it comes to how >> networks work. > > Clive, > Sorry to double post, but I have to ask... when did DNS tell a server > which route to take? > > If that isn't a big enough clue for you, then I suggest that you > consider the following... > > OP adds second Nic card, all hell breaks loose. Is this an issue with > a change on the server side or on the client side? > Its rhetorical... > > Also, consider that the clients use DNS, and the server will know the > IP address of the client, why would the server not know how to resolve > the client's IP address? So really a DNS issue isn't the first place > to guess. > > But not knowing the route to the client, now that's a problem. Isn't > it? That is not the OP's problem. When the server doesn't know a route to the client, it doesn't magically find out 25s later and complete the three-way TCP handshake. If there's a routing problem, the connection won't succeed. > Where do you set up your routing information? In DNS? > I don't think so. > > Now since the OP didn't really provide a lot of information, we really > should be asking more questions. But since we all like to jump the gun > in an effort to help, the first place to look is on the server itself. The OP mentioned a 25s *delay* before the connection *succeeds*. In my experience[1] that order of delay is very characteristic of DNS resolution timeouts. I've seen that *many* times when the server is trying to log the FQDN of the client. > Here's a really simple test. > Have the OP disable the second Nic. Do the problems continue or do > they go away? Note: Disabling the Nic is a lot easier than actually > taking the card out. The OP may want to disable both Nics, enable the > main Nic and possibly bounce the Informix engine. He could also reboot > if he wants to be damn sure that everything is cleared out and that > only the first Nic card is active. But that's really overkill. The whole procedure seems overkill to me, a few minutes with a network sniffer (e.g. Wireshark) might be more informative and less disruptive. > > If the problem suddenly goes away, then poof! Your DNS idea isn't > really supported. > > But hey! What do I know? I think that question was answered already. [1] I first registered a domain back in the days when it was run by nic.ddn.mil. My NIC-handle was my initials with no numbers. For five years I managed top-level DNS for a Fortune-500 company with hundreds of offices in dozens of countries worldwide and with several class-A address ranges (and lots of Bs and Cs). I was reasonably familiar with DNS and with the characteristics of problems associated with DNS misconfiguration. I think what Clive writes makes most sense. -- RGB
> Date: Thu, 28 May 2009 14:58:51 +0100 > From: RedGrittyBrick@spamweary.invalid > > That is not the OP's problem. When the server doesn't know a route to > the client, it doesn't magically find out 25s later and complete the > three-way TCP handshake. If there's a routing problem, the connection > won't succeed. > > No! Really? So what happens when there are two Nic cards in a pc and you haven't properly defined your routing information? Random choice? Try one network, timeout, try the second network and succeed and then cache the route ? (Not you per se, but the OS.) I'm not a Windows guy so I don't know how they handle multiple nics. Hmmm. That would be too easy. The key here is that we can easily test for a DNS problem. 1) On a client, open a shell window and do a nslookup. Type in the server name and see what you get. Now you may have to do a q=any to make sure you get all of the information. 2) On the server, do the same thing. If you were on Unix, you could do a traceroute from the server to the client but I don't know if Windows has a traceroute equivlent, but again you can do this either by entering the client's name or its IP address. You can also do this from the client, assuming that you have an equivelent application like 'traceroute' on the client. Oh and lets go one step further. If it were a DNS problem, then it would mean that the OP's network admin setup multiple A records with the same hostname. That would be an easy thing to check. On the reverse side, the OP would have to grep his two different zone files for the same hostname. Assuming of course that the OP's network administrators are configuring different zones for their subnets. Of course the issue isn't with the reverse lookup but the name to address resolution which would be the A (address) record. Now since you want to jump the gun and say that its a DNS problem, there's a big assumption on your part. You're assuming that they are running DNS. Sure its a valid assumption, but you can run a network and not run your own DNS servers. Or if you have no intention on connecting to an outside network, you *can* run a network that has no DNS server at all. (Hmmm. I wonder what's the purpose of /etc/hosts ?) Oh you can use wireshark, but then you'll have to sift through all of your network traffic for a given port which means on the server, you'd have to run an instance of wireshark on each Nic entry at the same time, then compare results. A trace route would actually simulate the problem and you'd get an instant result. Is it starting to sink in yet? Jumping to the conclusion that its a 'DNS' related problem is making a large assumption. Starting with the server, which from the OP's post was the only thing to change in his network is probably the best place to start looking at the problem. A misconfigured Nic card could easily cause the same symptoms and its the first place to look. -G ms138 ;-) _________________________________________________________________ Hotmail® has ever-growing storage! Don’t worry about storage limits. http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009
Ian Michael Gumby wrote: > > > > Date: Thu, 28 May 2009 14:58:51 +0100 > > From: RedGrittyBrick@spamweary.invalid > > > > > That is not the OP's problem. When the server doesn't know a route to > > the client, it doesn't magically find out 25s later and complete the > > three-way TCP handshake. If there's a routing problem, the connection > > won't succeed. > > > > > No! Really? > > So what happens when there are two Nic cards in a pc and you haven't > properly defined your routing information? Random choice? Try one > network, timeout, try the second network and succeed and then cache the > route ? (Not you per se, but the OS.) I'm not a Windows guy so I don't > know how they handle multiple nics. > > Hmmm. That would be too easy. > > The key here is that we can easily test for a DNS problem. > 1) On a client, open a shell window and do a nslookup. > Type in the server name and see what you get. > > Now you may have to do a q=any to make sure you get all of the information. > > 2) On the server, do the same thing. > > If you were on Unix, you could do a traceroute from the server to the > client but I don't know if Windows has a traceroute equivlent, but again > you can do this either by entering the client's name or its IP address. > > You can also do this from the client, assuming that you have an > equivelent application like 'traceroute' on the client. > > Oh and lets go one step further. > If it were a DNS problem, then it would mean that the OP's network admin > setup multiple A records with the same hostname. That would be an easy > thing to check. On the reverse side, the OP would have to grep his two > different zone files for the same hostname. Assuming of course that the > OP's network administrators are configuring different zones for their > subnets. Of course the issue isn't with the reverse lookup but the name > to address resolution which would be the A (address) record. > > Now since you want to jump the gun and say that its a DNS problem, > there's a big assumption on your part. You're assuming that they are > running DNS. Sure its a valid assumption, but you can run a network and > not run your own DNS servers. Or if you have no intention on connecting > to an outside network, you *can* run a network that has no DNS server at > all. (Hmmm. I wonder what's the purpose of /etc/hosts ?) > > Oh you can use wireshark, but then you'll have to sift through all of > your network traffic for a given port which means on the server, you'd > have to run an instance of wireshark on each Nic entry at the same time, > then compare results. A trace route would actually simulate the problem > and you'd get an instant result. > > Is it starting to sink in yet? Jumping to the conclusion that its a > 'DNS' related problem is making a large assumption. Starting with the > server, which from the OP's post was the only thing to change in his > network is probably the best place to start looking at the problem. A > misconfigured Nic card could easily cause the same symptoms and its the > first place to look. > > > -G > ms138 ;-) > > > > > > ------------------------------------------------------------------------ > Hotmail' has ever-growing storage! Don't worry about storage limits. > Check it out. > <http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage1_052009>; An easy way to test this would be to add the client IP to the hosts file (after making sure it's looking at the hosts file, which I don't recall how it's done in windows... but I think per default it will) If this solves the problem it's a DNS issue. As others have said this is a typical scenario. Other interesting points to check would be sqlhosts of both server and client (server is a must, specially if it uses *hostname) For brain massaging, and in a "real" OS, a truss/strace of the MSC (or ADM VP, I never know) would be interesting... real men use truss/strace for solving trivial issues ;) Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...