ODBC Connectivity problem from home only

Connectivity
Enthusiast

ODBC Connectivity problem from home only

https://community.teradata.com/t5/Teradata-Applications/SQL-Assistant-ODBC-Unable-to-connect-from-Ho...

I made the above post some time ago, but the solution provided by Fred did not work.

I am getting this error when attempting to connect:

TDATA.DLL 10060 WSAE

Timed Out - No response received by the server

Note: the ISP is Verizon; Teradata 5.10.06 - 32 bit under 64 bit Windows 10

Any other suggestions ?

 

 

 

Tags (1)
8 REPLIES
Teradata Employee

Re: ODBC Connectivity problem from home only

Have tried to increase the "Login Timeout". It defaults to 20 seconds. 

Enthusiast

Re: ODBC Connectivity problem from home only

Yep....moved it up to 60 seconds....still no go.

Teradata Employee

Re: ODBC Connectivity problem from home only

Note the server name in your ODBC configuration, e.g. abc or abc.mycorp.com.

From a Windows command prompt, at work, do "nslookup abc" or "nslookup abc.mycorp.com"

Also try "nslookup abcCOP1" or "nslookup abcCOP1.mycorp.com"

Note the responses / IP address(es) returned.

 

If nslookup works with the name alone but not with the COP1 suffix (which I suspect will be the case), then for home you need to set Data Source DNS Entries to 0 to disable COP discovery. And you should still be able to connect at work with this setting.

 

Enthusiast

Re: ODBC Connectivity problem from home only

Thanks Fred, I will give that a shot......and will even try substituting the named reference with the IP address.

BTW: what does COP stand for anyway ?

Teradata Employee

Re: ODBC Connectivity problem from home only

COP stands for COmmunications Processor.

In the original Teradata DBC/1012 architecture it was a separate specialized physical unit.

Re: ODBC Connectivity problem from home only

1st:  Answer to the COP question:  "COP" stands for Communications Process and has been around in Teradata, since the 1990's (the last century lol).  It is the means, by which connections to a TD system are made.  If more than that a single node exists on a given system, then each node is identified in a numerical fashion: COP1, COP2, COP3 +++ COPn.  See the other post about the history of COP on the DBC/1012.  Usually, connections to TD are made to COP1.  But the point is that if one of the COP's (nodes) does not respond to a request for a connection, then TD will iteravely search down the COP#'s for another COP# that is responsive, until it finds one, at which point the connection occurs.

 

Please note that we lost a node several years ago, which was manifested by that node not accepting connections, which showed up under our SolarWinds tool.

 

Now to why I am responding:  remote connectivity issues.  We are experiencing lack of connectivity to Teradata systems, when remoting in via our enterprise VPN.  Note:  This lack of connectivity is occurring only when users have AT&T as their ISL.  Users that have Verizon, Comcast, or Charter (and others) are not experiencing thiis connectivity issue.

 

Our successful solutions, to date, have been two: 

1) Issue a Verizon "Hot Spot" puck, which is connected to the Clients node, when in remote mode, and which provides successful wireless ISL support.

2) Submit the IPA (Internet Protocol Address), e.g. "30.1.999.888" (faux) to the user, who hard wires it into their connection string.

 

The primary TD app, which experiences this connection issue, has been SQL Asst.  We have engaged our Security Team, but they cannot find any basis for this issue.  However, they are about to do more research, due the needed escalation, in the next point below.

 

Up to this point, there were not a sigificant number of users with AT&T remotely, so the "puck" or the IPA was satisfactory.  However, now a larger number of users will be using AT&T (myself included!) and the issue has now scaled up to the point, where a long term solution is now required.

 

P.s., I think I notice that in some cases, Verizon seems to be subject to this issue.

  • Does anyone have a general comment, or more specifcally, a proposed or actuall solution?

    Fred wrote:

    COP stands for COmmunications Processor.

    In the original Teradata DBC/1012 architecture it was a separate specialized physical unit.



New Member

Re: ODBC Connectivity problem from home only

@itboater: I have been having the same issues while connecting to Teradata SQL assistant from my home AT&T connection. Could you be kind enough to lay out the next steps of what I have to do to fix this? Thank you!

Highlighted
Teradata Employee

Re: ODBC Connectivity problem from home only

First check how connections work from the office:

See what name is being used in the ODBC DSN or the .NET connection parameters.

If it's a simple name like xyz, see if you can resolve xyzCOP1; if it's a FQDN like xyz.somedomain.com then try xyzCOP1.somedomain.com (e.g. using nslookup or ping)

If that works, make a note of the IP address, and also try COP2, COP3, etc. until you determine the highest number that resolves successfully. Make a note of that highest COP number.

If COP1 fails, resolve the name with no COP suffix and make a note of the IP address.

 

From home:

Again, check to see if you can resolve the COP1 name. (Normally it will be the same IP address you found in the office, though occasionally a company will translate VPN addresses.)

If you could resolve COP1 in the office but not from home, you'll need to contact your network support to get assistance in figuring out what is wrong.

If you could not resolve COP1 in the office but it does resolve from home, see if the name without COP suffix resolves and is different from the COP1 address  from home. If so, try setting DataSourceDNSEntries to 0 for the connection.

If you can resolve COP1 in both places, and COPn was the highest one that resolved in the office, see if COP(n+1) resolves from home. [In other words if COP4 worked in the office and COP5 didn't, then try COP5 from home.] If so, try setting  DataSourceDNSEntries to n.

 

Often this problem is the result of an ISPs DNS servers violating expected behavior (namel, returning a failure for an undefined name).

You can also try using the IP address (from work) instead of the name, just to determine if the problem is with the connection itself or something else to do with resolving the name.