Database Reference
In-Depth Information
Table 30-1.
Valid Node Checking Parameters
Name
Purpose
Values
Default
tcp.validnode_checking
Turns valid node
checking on or off
yes, no
no
tcp.invited_nodes
List of nodes that may
connect to the TNS
Listener
Comma separated list of host
names and/or IP addresses
on a single line
empty list
tcp.excluded_nodes
List of nodes that are
denied a connection to
the TNS Listener
Comma separated list of host
names and/or IP addresses
on a single line
empty list
It appears that the code path for valid node checking is always executed. As long as the
feature is not in use, the lists for invited and excluded hosts are empty, thus allowing any client
to connect. This assumption is based on the observation that the TNS Listener writes lines such
as in the following excerpt on each connect by a client to its trace file, irrespective of the setting
of
tcp.validnode_checking
:
[12-JUL-2007 20:03:12:268] nttcnp: Validnode Table IN use; err 0x0
[12-JUL-2007 20:03:12:268] nttvlser: valid node check on incoming node 10.6.6.64
Only when the TNS Listener trace level is at least at level
ADMIN
and
tcp.validnode_
checking=no
is set, does the trace file contain evidence that valid node checking is switched off:
[12-JUL-2007 19:52:28:329] ntvllt: tcp.validnode_checking not turned on
Let's take a look at some examples. The prompts
dbserver$
and
client$
indicate where
each command was run. The
listener.ora
and
sqlnet.ora
on the server are shown here:
dbserver$ head -200 listener.ora sqlnet.ora
==> listener.ora <==
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =dbserver.oradbpro.com)(PORT = 1521))
)
)
)
trace_level_listener=admin
==> sqlnet.ora <==
NAMES.DIRECTORY_PATH= (TNSNAMES)
Valid node checking is currently switched off. This is evident from the configuration file
sqlnet.ora
reproduced in the preceding code example. Following is the
tnsnames.ora
on
the client:
