I have a cluster that is not running properly. While doing something it added an extra Ip address which is not supposed to be there. Since this is generated by the cluster (not in network-script) and I'm not familiar with Centos 7 pacemaker + corosync stack, I don't know what command to run. Please advice.

The one I'm trying to get rid is the first inet number with /16 subnet.

Thanks in advance.

2: em1: mtu 1500 qdisc mq state 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
  • You say "While doing something ..." without giving us any idea what you've done, you've obscured all the IP addresses to the same value. Sorry, but there's no way we can know what's going on here. We're going to need to know what you did, and what it is that differentiates those IPs, and why that one is "not supposed to be there". – Patrick Mar 15 '18 at 0:15
  • I know the question is very vague, I'm sorry because I really don't know what I did. I think this machine shutdown and it wouldn't boot because of kernel panic. I was told to use older version of kernel then it finally rebooted. I think at that point it added this extra ip address on the top. the middle one is the public ip address of this machine to ssh. the last one with /32 is haproxy ip address. Besides the kernel downgrade, I started apache, started php fpms, and haproxy. I was in panic at that time so I don't remember exactly when exactly this ip address appeared. – user2983011 Mar 15 '18 at 4:06

The IP was most likely added by the IPaddr2 resource agent which is commonly used by pacemaker to provision and migrate virtual IP addresses (https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/IPaddr2).

Removing it should be as simple as: ip addr del xxx.xxx.xxx.xxx/16 dev em1

| improve this answer | |

I see the topmost masked IP address has a /16 netmask. The link-local 169.254.?.? addresses typically have that mask. They are used by avahi-daemon for zero-configuration networking: the auto-detection of printers and other shareable services in other devices in the same network segment. Oracle Clusterware / Grid technology also uses the link-local addresses.

Otherwise, I think it would be fairly unlikely to see a /16 mask anywhere in modern IPv4 networks.

avahi-daemon is enabled by default on modern RedHat/CentOS systems and many other Linux distributions.

If avahi-daemon is not useful in a server, it is fairly common to disable it, in particular in servers that need to be highly available, in order to reduce system complexity and potential attack surface. It is possible that the system administrator had previously stopped avahi-daemon. but not prevented it from starting at boot, so it probably was restarted when the system was rebooted.

Compare the outputs of systemctl status avahi-daemon on all cluster nodes. If only the problem system indicates avahi-daemon is running, you can stop it with systemctl stop avahi-daemon and prevent it from starting at boot time with systemctl disable avahi-daemon. This command is a "soft" disable: if some other systemd service is marked as requiring avahi-daemon and that service is configured to start at boot, avahi-daemon would still be started automatically. It's kind of similar to placing a Windows service into "Manual" start-up mode.

The command for a "hard" disable (= "don't start this service for any reason, no matter what, even if it causes something else to not work") would be systemctl mask <service-name>. This is the equivalent of setting a Windows service to a "Disabled" state. To allow the service to start again, you'd need systemctl unmask <service-name>.

If you choose to fully disable avahi-daemon, and you're using classic RedHat-style /etc/sysconfig/network-scripts/ifcfg-* files for network configuration (instead of using NetworkManager), you may also want to add the line


to each ifcfg-* file.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.