Need help with possible dual listener configuration and listener traffic

Question

Hello:
We seperate our network traffic to the database servers using VLAN's. We have application traffic on 192.168.1.x and replication/admin traffic on 10.112.28.x. We are looking to configure 2 listeners for the database, one to listen and respond on 192.168.1.x and one to listen and respond on 10.112.28.x. Right now, we have one listener that is configured for both networks, however, for servers that are connected to both networks, the client sends on 192.168.1 but receives a TNS redirect to 10.112.28. For clients only on the 192.168.1, the TNS redirect to 10.112.28 times out because the client cannot resolve the address. I can make available a Visio diagram of our current configuration. We also utilize server-side load balancing.
Here is our dilemma, confirmed by analyzing packet traffic to and from the database on a Fluke:
1) For servers in our environment that reside on BOTH network segments (multihomed), application "traffic" generated on 192.168.1.x arrives at the listener. Through server-side load balancing, a TNS redirect string is returned to the client, which, based on the following listener configuration, redirects the connection to the 10.112.28.x segment:
LISTENER_RMLNDB01 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.112.28.8)(PORT = 1521)(IP = FIRST))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.8)(PORT = 1529)(IP = FIRST))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
2) For servers that reside on only one network (ex. 192.168.1.x), when the redirect is returned to that server, it experiences a timeout and connection failure because it cannot physically reach 10.112.28.x
Is there any way, through tnsnames, splitting listener.ora, VLAN's, the database itself, anything, for us to have requests for 192.168.1 be returned on 192.168.1 and not redirected. Would client side load balancing be a better option? Any way to manipulate the service registrations?
Thanks for all future responses!
Paul

Answer 1

Hello:
We seperate our network traffic to the database servers using VLAN's. We have application traffic on 192.168.1.x and replication/admin traffic on 10.112.28.x. We are looking to configure 2 listeners for the database, one to listen and respond on 192.168.1.x and one to listen and respond on 10.112.28.x. Right now, we have one listener that is configured for both networks, however, for servers that are connected to both networks, the client sends on 192.168.1 but receives a TNS redirect to 10.112.28. For clients only on the 192.168.1, the TNS redirect to 10.112.28 times out because the client cannot resolve the address. I can make available a Visio diagram of our current configuration. We also utilize server-side load balancing.
Here is our dilemma, confirmed by analyzing packet traffic to and from the database on a Fluke:
1) For servers in our environment that reside on BOTH network segments (multihomed), application "traffic" generated on 192.168.1.x arrives at the listener. Through server-side load balancing, a TNS redirect string is returned to the client, which, based on the following listener configuration, redirects the connection to the 10.112.28.x segment:
LISTENER_RMLNDB01 =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 10.112.28.8)(PORT = 1521)(IP = FIRST))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.8)(PORT = 1529)(IP = FIRST))
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
2) For servers that reside on only one network (ex. 192.168.1.x), when the redirect is returned to that server, it experiences a timeout and connection failure because it cannot physically reach 10.112.28.x
Is there any way, through tnsnames, splitting listener.ora, VLAN's, the database itself, anything, for us to have requests for 192.168.1 be returned on 192.168.1 and not redirected. Would client side load balancing be a better option? Any way to manipulate the service registrations?
Thanks for all future responses!
Paul