cancel
Showing results for 
Search instead for 
Did you mean: 

What might be defeating DoBroadcast=NONE?

justin_willey
Participant
8,535

The situation is that we want client machines to connect to a database sever by server (and engine) name - not IP address. This is so that we can update a DNS server to point to a different machine when required (eg a warm-standby server) without having to change thousands of ODBC DSNs.

To this end we use DoBroadcast=NONE in the connection strings eg:

UID=MyUser;PWD=**;DBN=IQX;ENG=IQX;CON=IQXUser51;LOG=C:\\iqx.log;LINKS='TCPIP{host=iqx.group.com;DoBroadcast=NONE}'

On some machines this works exactly as expected. In this (slightly artificial) test the wrong server is running at 10.200.129.10:2638 and the correct server is 10.200.129.11:2638 but is not running - we did it that way to be sure of what was happening. Pinging the server name (iqx.group.com) correctly resolves to 10.200.129.11. So we would expect the client to ignore the server at 10 and then fail to connect to the one at 11 - which is exactly what happens:

Mon Jan 12 2015 14:40:40
14:40:40 Attempting to connect using:
UID=MyUser;PWD=**;DBN=IQX;ENG=IQX;CON=IQXUser51;LOG=C:\\iqx.log;LINKS='TCPIP{host=iqx.group.com;DoBroadcast=NONE}'
14:40:40 Attempting to connect to a running server...
14:40:40 Trying to start TCPIP link ...

14:40:40 TCP using Winsock version 2.2 14:40:40 My IP address is 10.200.128.204 14:40:40 My IP address is ::1 14:40:40 My IP address is 127.0.0.1 14:40:40 TCPIP link started successfully

14:40:40 Attempting TCPIP connection (address 10.200.129.10:2638 found in sasrv.ini cache)

14:40:40 DoBroadcast=NONE specified, ignoring cached address 14:40:40 DoBroadcast=NONE specified, skipping LDAP check 14:40:40 Looking for server with name iqx 14:40:40 Trying to find server at address iqx.group.com 14:40:41 TCP/IP link, function connect(), error code 10061 14:40:41 Failed to connect over TCPIP

14:40:41 Removing failed address from sasrv.ini cache

14:40:41 Not attempting to autostart server 14:40:41 Cannot connect to server

However on another machine with the same OS (Windows 7 Pro SP1, where again iqx.group.com correctly resolves to 10.200.129.11) we get this:

Tue Jan 13 2015 17:07:06
17:07:06 Attempting to connect using:
UID=MyUser;PWD=********;DBN=IQX;ENG=IQX;CON=IQXUser55;ASTOP=YES;INT=NO;DBG=YES;LOG=C:\\odbc_iqx.log;DMRF=NO;LINKS='TCPIP{host=iqx.group.com;DoBroadcast=NONE}';COMP=NO
17:07:06 Attempting to connect to a running server...
17:07:06 Trying to start TCPIP link ...

17:07:06 TCP using Winsock version 2.2
17:07:06 My IP address is 10.200.128.202
17:07:06 My IP address is ::1
17:07:06 My IP address is 127.0.0.1
17:07:06     TCPIP link started successfully

17:07:06 Attempting TCPIP connection (address 10.200.129.10:2638 found in sasrv.ini cache)

17:07:06 DoBroadcast=NONE specified, ignoring cached address
17:07:06 DoBroadcast=NONE specified, skipping LDAP check
17:07:06 Looking for server with name iqx
17:07:06 Trying to find server at address iqx.group.com
17:07:06 Found server, verifying server name
17:07:06 Found database server at address 10.200.129.10:2638
17:07:06 Found database server iqx on TCPIP link
17:07:06 Connected using client address 10.200.128.202:55607
17:07:06 Connected to server over TCPIP at address 10.200.129.10:2638

17:07:06 Connected to SQL Anywhere Server version 11.0.1.2960
17:07:06 Application information:
17:07:06 IP=10.200.128.202;HOST=MG001669;OS='Windows Vista Build 7601 Service Pack 1';PID=0xb24;THREAD=0x12e8;EXE=C:\\PROGRA~1\\iqx\\Program\\pears.exe;VERSION=10.0.1.4310;API=ODBC;TIMEZONEADJUSTMENT=0
17:07:06 Connected to the server, attempting to connect to a running database...
17:07:06 [15208] Connected to database successfully
17:07:07 [15208] The number of prefetch rows has been reduced to 0 due to the prefetch buffer
17:07:07 [15208] limit. Increasing the PrefetchBuffer connection parameter may improve performance.

In this case - although the client is recognising the DoBroadcast setting it is still managing to end up connecting to the wrong server. This may not be a SQL Anywhere problem at all - but how does the client go about finding the server by name once it's been told to ignore sasrv.ini - it is using the DNS or some other method?

NB - I'm not quite sure where the DBG setting is coming from. The connection string is being configured in the ODBC Admin application.

All suggestions gratefully received!

Accepted Solutions (0)

Answers (2)

Answers (2)

ian_mchardy
Product and Topic Expert
Product and Topic Expert

From a quick look a the LOGFILE, I don't think UDP is being used. If it was you would see a bunch of "Using broadcast address" lines. From the LOGFILE output, it looks to me like the address iqx.group.com was resolved to 10.200.129.10.

This may be an issue with a network host names not being updated immediately (AFAIK, it is normal for there to be some delay before machines see the new value). On the machine in question, try:

ping -a iqx.group.com


If it resolves to a different address than the current address of iqx.group.com, this is not a SQL Anywhere issue.

FYI, the DBG=YES is historical (but normal), and version 10.x is out of support.

justin_willey
Participant
0 Kudos

Thanks Ian. From what you and Jeff are saying I think it must be something to do with dns caching. I'll try a specific flushdns and see if it makes a difference.

justin_willey
Participant
0 Kudos

Hi - tried that:

ping -a iqx.group.com

returns the correct current address of iqx.group.com BUT the client still connects to the old one.

tried

ipconfig /flushdns 
and got a success message, but again the client still connects to the old address

Mmmmm....

ian_mchardy
Product and Topic Expert
Product and Topic Expert

Note that in SQL Anywhere version 12 the host connection parameter & protocol option was changed so that if provided, you will only connect to a server at that address. Before version 12, the host protocol option was a hint.

However, I just checked our SQLA 10.0.1 documentation, and specifying DoBroadcast=None should ignore the server address cache. Other than the server address cache, and the host address, I don't know how the client is finding the server address, because as I said before, I don't think UDP broadcasts are being used. Try also adding the undocumented IgnoreCache=Yes connection parameter (note this is not a protocol option so it is not part of the links parameter).

If that still doesn't work, please confirm there is nothing in the local etc\\hosts file (on my Windows 7 machine, it is in c:\\windows\\system32\\drivers\\etc).

FYI I had a look at the version 10 client code, and it looks to me like they system getaddrinfo call that is used to resolve the hostname to an address returned the address we tried to connect to. Perhaps the process was running before the address changed and the system cached the old host address for the process?

justin_willey
Participant
0 Kudos

Thanks Ian for following this up - I'll check out those suggestions and let you know what I find. Also we'll knock up a utility to show us what getaddrinfo is returning.

jeff_albion
Product and Topic Expert
Product and Topic Expert

This may not be a SQL Anywhere problem at all - but how does the client go about finding the server by name once it's been told to ignore sasrv.ini - it is using the DNS or some other method?

Server broadcasts are performed over UDP - so looking for server 'iqx', the server at 10.200.129.10 recognizes the UDP broadcast from 10.200.128.202 and responds appropriately. The UDP broadcast will only succeed across your local subnet (UDP broadcast packets are filtered across subnets).

If you don't want a database server responding to UDP server name requests, you can use the "-sb 0" switch on the database server start line. Note that there will still be a UDP broadcast when the database server starts up (checking for similarly named servers) and if you want to disable that check also, you can use: "-x tcpip(DOBROAD=no)" on the server start line.

justin_willey
Participant
0 Kudos

Hi Jeff - thanks for looking at this.

I thought that the DoBroadcast=NONE would prevent the client doing UDP broadcasts to find the server as well as making sure the sasrv.ini file was ignored - am I misunderstanding how it works?

jeff_albion
Product and Topic Expert
Product and Topic Expert

I believe your understanding is correct, but other than UDP packets coming from 10.200.128.10 to direct the client over there, I don't think we can explain how you would find yourself talking to the other server.

Have you flushed your DNS cache?

 ipconfig /flushdns


If you add "port" does that change anything? If you do a Wireshark trace, can you see UDP packets coming back from 10.200.128.10?


The situation is that we want client machines to connect to a database sever by server (and engine) name - not IP address. This is so that we can update a DNS server to point to a different machine when required (eg a warm-standby server) without having to change thousands of ODBC DSNs.

Have you considered opening a permanent secondary DNS entry and just have clients always point to both servers in the HOST entry? The clients will automatically fail over and you could save yourself trying to update the one DNS entry (and wait for DNS invalidations) all the time:

e.g.

 iqx1.group.com - 10.200.128.10
 iqx2.group.com - 10.200.128.11


UID=MyUser;PWD=********;DBN=IQX;ENG=IQX;CON=IQXUser51;LOG=C:\\iqx.log;LINKS='TCPIP{host=iqx1.group.com,iqx2.group.com;DoBroadcast=NONE}

justin_willey
Participant
0 Kudos

Thanks Jeff - I'll try the flushdns and see if that's the issue - but odd that ping gets the right IP address.

We've not (so far) gone down the secondary DNS route - we are terrified of ending up with half our clients on one server and half on the other! In a situation where you can go and pull the network cable out of the live one it wouldn't be a problem, but when everything is remotely hosted you can never be sure of what is going on with a server you can't see - you think its crashed and won't come back - but maybe half your clients can see it (and connect to it) just fine!