CRS-42216: No interfaces are configured on the local node for interface definition ethN

Vinicius, 2 meses ago 0 8 min read 24

Olá pessoal,

Espero que estejam bem!

Eu estava trabalhando para um cliente onde eles estavam atualizando seus servidores de RHEL 7 para RHEL 8. Como parte do projeto, os servidores de banco de dados estão sendo atualizados.

Nesse cliente, eles usam uma convenção de nomenclatura para interfaces de rede (ethN), que não é mais usada por padrão no Linux.

Então, como parte das tarefas de upgrade, eles estavam renomeando as interfaces de rede para a convenção de nomenclatura padrão: enpN. Após isso, eles realizaram o processo de upgrade e, durante as tarefas pós-upgrade, eles estavam renomeando as interfaces de rede para o nome original: ethN.

OK. Com isso dito, eles estavam atualizando o SO para um cluster de 3 nós de forma rolling.

Então, após cada servidor ser atualizado, eles entregavam os servidores para a equipe de DB, que basicamente fazia o seguinte:

Checar se os discos ASM estavam presentes;
Relink dos binários do RDBMS Home;
Execução do script $GRID_HOME/crs/install/rootcrs.sh -updateosfiles;
Start do cluster.

OK, então, no segundo nó, durante o último passo (start do cluster), nos pegamos o seguinte erro (saída truncada para melhor exibição):

[root@dbnode02 install]# crsctl start crs -wait
CRS-4123: Starting Oracle High Availability Services-managed resources
CRS-2672: Attempting to start 'ora.evmd' on 'dbnode02'
CRS-2672: Attempting to start 'ora.mdnsd' on 'dbnode02'
CRS-2676: Start of 'ora.evmd' on 'dbnode02' succeeded
CRS-2676: Start of 'ora.mdnsd' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'dbnode02'
CRS-2676: Start of 'ora.gpnpd' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.gipcd' on 'dbnode02'
CRS-2676: Start of 'ora.gipcd' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.crf' on 'dbnode02'
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'dbnode02'
CRS-2676: Start of 'ora.cssdmonitor' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'dbnode02'
CRS-2672: Attempting to start 'ora.diskmon' on 'dbnode02'
CRS-2676: Start of 'ora.diskmon' on 'dbnode02' succeeded
CRS-2676: Start of 'ora.crf' on 'dbnode02' succeeded
CRS-2676: Start of 'ora.cssd' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'dbnode02'
CRS-2672: Attempting to start 'ora.ctssd' on 'dbnode02'
CRS-2676: Start of 'ora.ctssd' on 'dbnode02' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'dbnode02'
CRS-2676: Start of 'ora.asm' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.storage' on 'dbnode02'
CRS-2676: Start of 'ora.storage' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'dbnode02'
CRS-2676: Start of 'ora.crsd' on 'dbnode02' succeeded
CRS-2672: Attempting to start 'ora.asmnet1.asmnetwork' on 'dbnode02'
CRS-5017: The resource action "ora.asmnet1.asmnetwork start" encountered the following error:
CRS-5006: Unable to automatically select a network interface which has subnet mask  and subnet number 192.168.118.0
. For details refer to "(:CLSN00107:)" in "/oracle/app/grid/diag/crs/dbnode02/crs/trace/crsd_orarootagent_root.trc".

Só para informar, o cluster foi iniciado e a instância do DB e os servidores de DB estavam disponíveis.

Interessante esse erro hein?

CRS-5006: Unable to automatically select a network interface which has subnet mask and subnet number 192.168.118.0

Após isso chequei o alert.log do cluster e havia uma mensagem de erro floodando/inundando o log:

2024-06-23 08:32:57.998 [GIPCD(74101)]CRS-42216: No interfaces are configured on the local node for interface definition eth1(:.*)?:192.168.118.0: available interface definitions are [eth0(:.*)?:10.250.118.0][eth1(:.*)?:192.168.118.18][eth2(:.*)?:192.168.119.0][eth2:1(:.*)?:169.254.0.0][eth2:2(:.*)?:169.254.16.0][eth3(:.*)?:10.250.113.0][eth4(:.*)?:10.250.113.0][eth5(:.*)?:10.250.111.0][eth3(:.*)?:[fe80:0:0:0:0:0:0:0]][eth5(:.*)?:[fe80:0:0:0:0:0:0:0]][eth1(:.*)?:[fe80:0:0:0:0:0:0:0]][eth2(:.*)?:[fe80:0:0:0:0:0:0:0]][eth0(:.*)?:[fe80:0:0:0:0:0:0:0]][eth4(:.*)?:[fe80:0:0:0:0:0:0:0]].

OK, nesse cliente, temos duas interfaces de rede para o cluster interconnect, vamos verificar novamente:

[root@dbnode02 ~]# oifcfg getif
eth0  10.250.118.0  global  public
eth1  192.168.118.0  global  cluster_interconnect,asm
eth2  192.168.119.0  global  cluster_interconnect,asm

Confirmado, eth1 é a interface de rede com a qual estamos tendo problemas. Se verificarmos a saída exibida acima, podemos ver que:

eth1 está configurada como interconnect, com subnet 192.168.118.0

O fato de ter duas interfaces de rede configuradas como cluster interconnect explica por que o cluster conseguiu ser iniciado. Se esse ambiente não tivesse duas interfaces de rede para funcionar como cluster interconnect, o cluster não seria inicializado nesse nó.

Vamos prosseguir com o troubleshooting.

OK, agora vamos verificar a camada do SO:

[root@dbnode02 ~]# ifconfig eth1

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.118.18  netmask 255.255.255.255  broadcast 192.168.118.18
        inet6 fe80::250:56ff:fe82:93de  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:82:93:de  txqueuelen 1000  (Ethernet)
        RX packets 1125140563  bytes 835592309784 (778.2 GiB)
        RX errors 0  dropped 24  overruns 0  frame 0
        TX packets 1214647607  bytes 849189780308 (790.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Hummm, você notou isso?

netmask 255.255.255.255
broadcast 192.168.118.18

O IP de broadcast está apontando para o IP de interconnect em si: 192.168.118.18

Isso significa que a máscara de rede é 255.255.255.255 (como exibido na saída do ifconfig) em vez de 255.255.255.0.

Vamos verificar a comunicação entre os nós do cluster nesta rede privada.

Do primeiro nó para o segundo nó:

[root@dbnode01 ~]# ping 192.168.118.18
PING 192.168.118.18 (192.168.118.18) 56(84) bytes of data.
^C
--- 192.168.118.18 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2069ms

Todas as tentativas falharam.

Agora, do terceiro nó para o segundo nó:

[root@dbnode03 ~]# ping 192.168.118.18
PING 192.168.118.18 (192.168.118.18) 56(84) bytes of data.
^C
--- 192.168.118.18 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2069ms

Novamente, todas as tentativas falharam.

Agora, vamos verificar do segundo nó para o primeiro nó:

[root@dbnode02 ~]# ping 192.168.118.17
PING 192.168.118.17 (192.168.118.17) 56(84) bytes of data.
^C
--- 192.168.118.17 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2069ms

Novamente, todas as tentativas falharam.

Vamos verificar agora do segundo nó para o terceiro nó:

[root@dbnode02 ~]# ping 192.168.118.19
PING 192.168.118.19 (192.168.118.19) 56(84) bytes of data.
^C
--- 192.168.118.19 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2069ms

Novamente, todas as tentativas falharam.

Vamos agora verificar a comunicação entre o primeiro nó e o terceiro nó, que supostamente deveria estar funcionando:

[root@dbnode01 ~]# ping 192.168.118.19
PING 192.168.118.19 (192.168.118.19) 56(84) bytes of data.
64 bytes from 192.168.118.19: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.19: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.19: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Perfeito! Sem problemas! Se tentarmos do terceiro nó para o primeiro nó, também funcionará:

[root@dbnode03 ~]# ping 192.168.118.17
PING 192.168.118.19 (192.168.118.17) 56(84) bytes of data.
64 bytes from 192.168.118.17: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.17: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.17: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.17 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Maravilha!

Vamos tentar entender por que a máscara de rede está errada.

OK, vamos verificar o script de configuração da interface de rede no SO:

[root@dbnode02 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static 
IPADDR=192.168.118.18
PREFIZ=24
DEFROUTE=yes
NAME=eth1
DEVICE=eth1
ONBOOT=yes
MTU=9000

OK, você percebeu algo estranho/errado aqui?

PREFIZ=24

Veja, há um typo (erro de digitação) no arquivo de configuração: PREFIZ.

Esse parâmetro não existe, deveria ser PREFIX.

Uma vez que o parâmetro está errado, o Linux assumiu que o IP usará 255.255.255.255 como máscara de rede e essa interface de rede não será capaz de se comunicar com outros nós do cluster.

OK, eu então corrigi o parâmetro:

PREFIX=24

Depois disso, baixamos e subimos a interface de rede no SO:

ifdown eth1
ifup eth1

Vamos fazer agora um double check na interface de rede:

[root@dbnode02 ~]# ifconfig eth1

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 192.168.118.18  netmask 255.255.255.0  broadcast 192.168.118.255
        inet6 fe80::250:56ff:fe82:93de  prefixlen 64  scopeid 0x20<link>
        ether 00:50:56:82:93:de  txqueuelen 1000  (Ethernet)
        RX packets 1125140563  bytes 835592309784 (778.2 GiB)
        RX errors 0  dropped 24  overruns 0  frame 0
        TX packets 1214647607  bytes 849189780308 (790.8 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Após corrigirmos, a mensagem de erro que estava floodando o log parou de ser exibida.

Vamos verificar a comunicação entre os nós do cluster.

Do primeiro nó para o segundo nó:

[root@dbnode01 ~]# ping 192.168.118.18
PING 192.168.118.18 (192.168.118.18) 56(84) bytes of data.
64 bytes from 192.168.118.18: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.18: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.18: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.18 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Maravilha!

Vamos tentar agora do terceiro nó para o segundo nó:

[root@dbnode03 ~]# ping 192.168.118.18
PING 192.168.118.18 (192.168.118.18) 56(84) bytes of data.
64 bytes from 192.168.118.18: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.18: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.18: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.18 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Maravilha novamente!

Vamos tentar agora do segundo nó para o primeiro nó:

[root@dbnode02 ~]# ping 192.168.118.17
PING 192.168.118.17 (192.168.118.17) 56(84) bytes of data.
64 bytes from 192.168.118.17: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.17: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.17: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.17 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Até agora, tudo perfeito!

E agora do segundo nó para o terceiro nó:

[root@dbnode02 ~]# ping 192.168.118.19
PING 192.168.118.19 (192.168.118.19) 56(84) bytes of data.
64 bytes from 192.168.118.19: icmp_seq=1 ttl=64 time=0.294 ms
64 bytes from 192.168.118.19: icmp_seq=2 ttl=64 time=0.169 ms
64 bytes from 192.168.118.19: icmp_seq=3 ttl=64 time=0.214 ms
^C
--- 192.168.118.19 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2083ms
rtt min/avg/max/mdev = 0.169/0.225/0.294/0.054 ms

Maravilha!

A comunicação agora está funcionando bem entre os nós do cluster nesta rede privada.

Espero que tenha sido útil!

Um abraço!

Vinicius

Tags #cluster interconnect #CRS-42216 #CRS-42216: No interfaces are configured on the local node for interface definition eth #CRS-5006 #CRS-5017 #interconnect #private interconnect #private network

Administração, Clusterware

CRS-42216: No interfaces are configured on the local node for interface definition ethN

Administração, Database

Gerenciamento Eficaz do $ORACLE_HOME/.patch_storage: Estratégias de Limpeza e Arquivamento

Deixe um comentário Cancelar resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Blog Post

Sobre

Blog reconhecido pela:

Disclaimer

Busca

Archive

Blogroll Internacional

Blogroll Nacional

Links

Visitantes

Blog Post

CRS-42216: No interfaces are configured on the local node for interface definition ethN

Related posts

Shell Script para copiar backup do OCR para filesystem

Oracle Clusterware – Rotinas Administrativas – Parte 3 – srvctl

ACFS-9459: ADVM/ACFS is not supported on this OS version: ‘4.18.0-477.27.1.el8_8.x86_64’ depois de realizar upgrade para RHEL/OEL 8.8

CLSRSC-180: An error occurred while executing the command ‘/bin/rpm -qf /sbin/init’ durante o postpatch

Oracle Clusterware – Arquitetura – Parte 2 – Principais Arquivos: Voting Disk e OCR

Duplicate Database travando em “remote file db read”

Deixe um comentário Cancelar resposta

Sobre

Blog reconhecido pela:

Disclaimer

Busca

Archive

Blogroll Internacional

Blogroll Nacional

Links

Visitantes