OraFAQ Forum: RAC & Failsafe » SCAN Listener redirecting to wrong Local listener port

Home » Server Options » RAC & Failsafe » SCAN Listener redirecting to wrong Local listener port

Show: Today's Messages :: Polls :: Message Navigator
E-mail to friend

SCAN Listener redirecting to wrong Local listener port [message #685856]

Thu, 07 April 2022 09:34

piripicchio
Messages: 20
Registered: April 2018
Location: Rome

Junior Member

Hi everyone,
this is the scenario: in a 4 node 12.1 RAC database, we have local listeners listening on standard port 1521 (non encrypted). In addition to those, now we also need an encrypted connection, so in order test the desired configuration, in a replica environment I added a new listener on port 1522, which of course reads its own sqlnet.ora. Direct connection to both ports work as expected, so I moved on and added the endpoint to the scan_listener. Again, connection through scan to both ports work as expected: encrypted on 1522, non-encrypted to the old one. So far so good...until today, when another DBA told me there's no correlation between scan_listener port and local listener port and I was just lucky. So to verify it I shut down the local listener on port 1522 and tried to connect using scan on same port and....he was right: I expected to fail the connection but instead I was still able to connect, apparently through the listener on port 1521..
Am I missing something?

[Updated on: Thu, 07 April 2022 09:50]

Report message to a moderator

Re: SCAN Listener redirecting to wrong Local listener port [message #685857 is a reply to message #685856]

Thu, 07 April 2022 10:10

John Watson
Messages: 8974
Registered: January 2010
Location: Global Village

Senior Member

What did you actually do? Starting from the position of not using tcps, it should have been something like this to add the listening ports to the node listeners and the scan listeners:

Code: [Select all] [Show/ hide]

srvctl modify listener -p TCP:1521/TCPS:1522
srvctl modify scan_listener -p TCP:1521/TCPS:1522

then you have to create your wallet, and edit listener.ora in the GI homes and sqlnet.ora in the DB homes to have wallet_location point to it. There shouldn't be any reason to create additional listeners.

Remember that the only thing a scan listener does is redirect the client to a node listener. There is no requirement for them to use the same port numbers, GI knows what they are. Then it is the node listeners that establish the sessions. As you shutdown the tcps node listener, then I would think that the scan listener redirected you to the tcp listener and you ended up with a session that was not tcps.

Does that sound possible?

Report message to a moderator

Re: SCAN Listener redirecting to wrong Local listener port [message #685859 is a reply to message #685857]

Fri, 08 April 2022 02:17

piripicchio
Messages: 20
Registered: April 2018
Location: Rome

Junior Member

Hi John,
thank you for your answer. As you said, there's no need for an additional listener: this request comes from a misconception, I talked to the client and he agreed to leave everything as is on the server and simply enable encryption on the applications that needs it via parameter (sqlnet.encryption_client = required).
Regarding the scan listener port redirection, there was another misconception but this time was mine Smile

[Updated on: Fri, 08 April 2022 02:18]

Report message to a moderator

Re: SCAN Listener redirecting to wrong Local listener port [message #685867 is a reply to message #685859]

Fri, 08 April 2022 03:00

John Watson
Messages: 8974
Registered: January 2010
Location: Global Village

Senior Member

Sussed. When I'm asked to enable tcps, I always try to persuade the client to use the native encryption instead, as you are doing (except that I do it the server side, with sqlnet.encryption_server = required). It is so much simpler. I don't see any point to using SSL between the apps tier and the database tier. I suppose if it were some ancient application that uses a two tier client-server model with each user having their own schema logon, it might make some sense. But only "might".

Report message to a moderator

Previous Topic:	ORA-29701: unable to connect to Cluster Synchronization Service
Next Topic:	How to prevent connections to a specific node in RAC?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 17 05:26:10 CDT 2025