

DATABASE MANAGEMENT

Listener and Virtual IP

25.04.2017 
by Oracle Team

By Franck Pachot
.
When you configure a standby database, you want the application to transparently
connect to the primary database, wherever it is. That’s the role of Transparent
Application Failover, but this requires configuration on the client side. If you can’t
configure TAF, you can use a virtual IP address. But then the question is how to
configure the listener.ora to handle connections to this VIP.

Don’t worry, if you configured everything as recommended, with the hostname

declared in /etc/hosts, and listener.ora referencing this host name, then you can
simply ignore the VIP for your configuration. The reason is that when the host
specified in the listener.ora resolves to the same IP address as the hostname of the
server, then Oracle listener binds the port on all interfaces, and this includes the
VIP.

However, if you mentioned an IP address in the listener.ora, or if you mentioned a

host that resolves to a different IP than the hostname, then it listens only tho this
interface.
Why not just listen to the VIP? There are two reasons for that. First, you will need to
listen to the host IP anyway for the dynamic registration of instances. You don’t
want the standby database to contact the listener on the primary server. The
second reason is that you cannot start the listener if the IP is not up. Then, if you
want to explicitly listen to the VIP you will need two listeners, some security rules
to allow only local registration and to manage the start of the listener, monitoring,
etc.

The simplest configuration is to have one listener configured on the server

hostname, then it listens on all interfaces and clients can connect with the VIP (for
the application) or with the server IP (for Data Guard broker, backups, monitoring,
administration).

The behaviour is described in How The Listener Binds On TCP Protocol Addresses
(Doc ID 421305.1) 

Examples
I have two network interfaces on my system, the loopback (lo) and Ethernet
(enp0s3). This interface has the IP 192.168.78.104 and I have added a virtual IP
192.168.66.102 with:

ip a add 192.168.66.102/24 dev enp0s3

Here is the list of interfaces:

[oracle@VM104 tmp]$ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 08:00:cc:00:4e:68 brd ff:ff:ff:ff:ff:ff
inet 192.168.78.104/24 brd 192.168.78.255 scope global enp0s3
inet 192.168.66.102/24 scope global enp0s3
inet6 fe80::a00:ccff:fe00:4e68/64 scope link
valid_lft forever preferred_lft forever

Here is the content of my /etc/hosts where I have two names that resolve to my
server IP address 192.168.78.104
 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.78.104 VM104 myhost

One of these names is my server hostname:

[oracle@VM104 tmp]$ hostname

VM104

I’ll try different configuration of my listener.ora

(HOST=127.0.0.1)
I mentioned the IP address of the loopback interface

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))

The listener listens to this address only:

[oracle@VM104 tmp]$ ss -elpunt | grep -E "^Net|tnslsnr"

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 127.0.0.1:6666 *:* users

With this configuration, I’m able to connect only through the mentioned address,
127.0.0.1

ON=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.78.104)(PORT=6666)

ON=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.66.102)(PORT=6666)

ON=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=6666)))

(HOST=localhost)
I mentioned the loopback interface by a host name
 Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))

This is actually the same as above: the host mentioned has been resolved at listener
startup.

(HOST=1192.168.78.104)
I mentioned the IP address of the host interface

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.78.104)(PORT=6666)))

The listener listens to this address only:

[oracle@VM104 tmp]$ ss -elpunt | grep -E "^Net|tnslsnr"

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 192.168.78.104:6666 *:* users

With this configuration, I’m able to connect only through the mentioned address,
not the virtual IP, not other interfaces:

Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC

OK (0 msec)
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC
TNS-12541: TNS:no listener
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC
TNS-12541: TNS:no listener

(HOST=localhost)
I mentioned the loopback interface by a host name

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))
This is actually the same as above: the host mentioned has been resolved at listener
startup.

(HOST=VM104)
I mentioned the host name which resolves to the IP address of the host interface –
this is the default when creating with DBCA, and the recommended configuration.

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))

The listener socket do not mention the IP address:

[oracle@VM104 tmp]$ ss -elpunt | grep -E "^Net|tnslsnr"

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 :::6666 :::* users

We see something different here as there’s no mention of a local address in :::6666

With this configuration, I’m able to connect through any IP address, including the
virtual IP

Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC

OK (0 msec)
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC
OK (10 msec)
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TC
OK (10 msec)

(HOST=myhost)
I mentioned another host name which resolves to the IP address of the host
interface (see the /etc/hosts above). It is not the hostname returned by
$(hostname) but it resolve to same IP.

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))
The listener has resolved the address through /etc/hosts and then, because the IP
matches the resolution of $(hostname), has used the $(hostname). We are then in
the same situation as above where we can connect through any interface:

[oracle@VM104 tmp]$ ss -elpunt | grep -E "^Net|tnslsnr"

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 :::6666 :::* users

(HOST=0.0.0.0)
Finally, when you want to listen on all interfaces, why not configure the host to
0.0.0.0

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))

We are again in the same situation here and the listener has replaced it with the
hostname. This may be convenient when you want to use the same listener.ora for
different hosts. However, as it finally show the hostname, better to avoid confusion
and have it in the listener.ora

(HOST=VM104)(IP=FIRST)
This is the way to bypass the ‘listen on all interfaces’ rule, even when you resolve to
the hostname.

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.78.104)(PORT=6666)))

Because of (IP=FIRST) the listener listens to the first IP address returned by

gethostbyname()

Conclusion
It is easy to know if the listener listens on one specific IP address, or on all
interfaces. You get the hostname and the listener endpoints
 hostname
lsnrctl status

If the ‘HOST=’ matches the hostname, then it listens to all interfaces. If the ‘HOST=’
mentions an IP address, then it listens on this IP only. If it mentions a name which is
not the hostname, then maybe someone has changed the hostname after the
listener was started?

The other way is to look at the socket information with:

netstat -elpunt
ss -elpunt

If you think that it is a security problem to listen to all interfaces, then you should
understand that the listener is not a firewall. It is just a convenient way to route
connections by service name to the right instance. But remember that you can even
connect to the database without the listener (read
https://amitzil.wordpress.com/2015/10/19/bypassing-the-listener/ ), just
connecting to the dispatcher:

Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SID=CDB1))(ADDRESS=(PROTOCOL=TCP)(HO

OK (0 msec)

And this one listens to all interfaces:

[oracle@VM104 tmp]$ ss -elpunt | grep -E "(^Net|ora_d)"

Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 :::30229 :::* users
tcp LISTEN 0 128 :::32316 :::* users

Security is done by firewall rules. Listener is there only to help, so keep it simple.

by
Oracle Team
 BE SHARING

Related blog articles

DATABASE ADMINISTRATION & MONITORING


Configure Data Guard between 2 DB
Systems with Oracle 21c
29.04.2022 by Mouhamadou Diaw

DATABASE ADMINISTRATION & MONITORING


Configure DB System Oracle 21c in a ODA
19.14
29.04.2022 by Mouhamadou Diaw

DATABASE ADMINISTRATION & MONITORING


How to create an Oracle GoldenGate
EXTRACT in Multitenant
23.04.2022 by Lazhar Felahi

DATABASE ADMINISTRATION & MONITORING


Near Zero Downtime Migration and failback
with GoldenGate
23.04.2022 by Lazhar Felahi
ABOUT
dbi services est une entreprise spécialisée dans le consulting et les services IT. Nous sommes des
experts des infrastructures et plateformes de données innovantes et efficientes. Nous proposons à nos
clients des solutions adaptées et sur mesure grâce à nos consultant.e.s dont les compétences et
connaissances évoluent constamment grâce à la formation continue.

Delémont  Nyon 

Basel  Bern 

Zürich 

1958
Trees planted

2022 © dbi services

WE ARE CLOSE TO YOU

Delémont 
Nyon 
Basel 
Bern 
Zürich 