O IP provavelmente foi adicionado pelo agente de recursos IPaddr2, que é normalmente usado pelo marca-passo para provisionar e migrar endereços IP virtuais ( link ).
A remoção deve ser tão simples como:
ip addr del xxx.xxx.xxx.xxx/16 dev em1
Eu tenho um cluster que não está funcionando corretamente. Ao fazer algo, acrescentou um endereço IP extra que não deveria estar lá. Como isso é gerado pelo cluster (não no script de rede) e não estou familiarizado com o Centos 7 pacemaker + corosync stack, não sei qual comando executar. Por favor, conselhos.
O que eu estou tentando me livrar é o primeiro número inet com sub-rede / 16.
Obrigado antecipadamente.
2: em1: mtu 1500 qdisc mq estado UP qlen 1000
link/ether 14:18:77:66:ef:e0 brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.xxx/16 brd xxx.xxx.xxx.xxx scope global em1
valid_lft forever preferred_lft forever
inet xxx.xxx.xxx.xxx/27 brd xxx.xxx.xxx.xxx scope global dynamic em1
valid_lft 25353sec preferred_lft 25353sec
inet xxx.xxx.xxx.xxx/32 brd xxx.xxx.xxx.xxx scope global em1
valid_lft forever preferred_lft forever
inet6 fe80::1618:77ff:fe66:efe0/64 scope link
valid_lft forever preferred_lft forever
O IP provavelmente foi adicionado pelo agente de recursos IPaddr2, que é normalmente usado pelo marca-passo para provisionar e migrar endereços IP virtuais ( link ).
A remoção deve ser tão simples como:
ip addr del xxx.xxx.xxx.xxx/16 dev em1
Eu vejo que o endereço IP mais alto mascarado tem uma máscara de rede / 16. O link-local 169.254. endereços normalmente têm essa máscara. Eles são usados por avahi-daemon para redes de configuração zero: a detecção automática de impressoras e outros serviços compartilháveis em outros dispositivos no mesmo segmento de rede. A tecnologia Oracle Clusterware / Grid também usa os endereços locais de link.
Caso contrário, acho que seria bastante improvável ver uma máscara / 16 em qualquer lugar nas redes IPv4 modernas.
avahi-daemon é habilitado por padrão nos sistemas modernos RedHat / CentOS e em muitas outras distribuições Linux.
Se avahi-daemon não for útil em um servidor, é bastante comum desativá-lo, especialmente em servidores que precisam estar altamente disponíveis, para reduzir a complexidade do sistema e a potencial superfície de ataque. É possível que o administrador do sistema tenha parado anteriormente o avahi-daemon . mas não impediu que ele iniciasse na inicialização, então ele provavelmente foi reiniciado quando o sistema foi reinicializado.
Compare as saídas de systemctl status avahi-daemon em todos os nós do cluster. Se apenas o sistema com problema indicar que avahi-daemon está em execução, você poderá pará-lo com systemctl stop avahi-daemon e impedir que ele inicie no momento da inicialização com systemctl disable avahi-daemon . Esse comando é uma desativação "soft": se algum outro serviço systemd estiver marcado como exigindo avahi-daemon e esse serviço estiver configurado para iniciar na inicialização, avahi-daemon ainda será iniciado automaticamente. É semelhante a colocar um serviço do Windows no modo de inicialização "Manual".
O comando para uma desativação "hard" (= "não iniciar este serviço por qualquer motivo, não importa o quê, mesmo que isso faça com que algo não funcione") seria systemctl mask <service-name> . Isso equivale a configurar um serviço do Windows para um estado "Desativado". Para permitir que o serviço fosse iniciado novamente, você precisaria de systemctl unmask <service-name> .
Se você optar por desabilitar totalmente o avahi-daemon e estiver usando arquivos clássicos% Red_at /etc/sysconfig/network-scripts/ifcfg-* para a configuração da rede (em vez de usar o NetworkManager), talvez também queira adicionar a linha
NOZEROCONF="yes"
para cada arquivo ifcfg-* .