Is there a way to bring up a virtual interface without it first sending an arping to check if that IP address is already in use elsewhere?
I'm working with a proprietary product that recommends copying the ifup script and commenting out the arping check section. But then that custom version of the ifup script needs to be stored somewhere, and it's not the nicest thing to maintain.
Is there a better way of bringing up the interface without the arping check?
答案1
You should be able to do this within the confines of Red Hat's network scripts. However, you can't due to a bug in those scripts.
This is how I would have gone about it:
First, suppress ARP completely while the interface is being brought up. Then re-enable it after the interface is up. (You must re-enable ARP or the machine will not be able to communicate at all.)
To suppress ARP during interface initialization, add to /etc/sysconfig/network-scripts/ifcfg-eth0. This actually disables ARP at the kernel level, which should make any attempts to use arping fail.
ARP=no
To re-enable ARP after the interface is up, create a file /sbin/ifup-local with the necessary commands:
#!/bin/bash
ip link set dev $1 arp on
However, this fails, precisely because it causes arping to fail. Since the /etc/sysconfig/network-scripts/ifup-eth script doesn't actually check the return code from arping carefully enough, if you actually set ARP=no then the initialization fails with an incorrect error message claiming the IP address is already in use.
This leaves you with your original option, that recommended by the vendor: Hack the script, and (optionally) report the bug to Red Hat.
答案2
I know this is old but I was looking this up today
You can add ARPCHECK=no to any interface definition file to skip the check.
Only tested in CentOS 6.7
答案3
You don't have to use the ifup scripts at all. You could just use ifconfig?
The problem is that you're likely to have one requirement after another of things that you want to happen when you raise or lower the interface, and then you'll be reinventing the ifup system.
I'm not currently working with redhat systems, so I'm not well placed to poke around the scripts you're talking about. I'd have thought tough that it wouldn't be too bad to maintain some variations in the ifup scripts, and it's the right place to describe what the behaviour you want is. For the sort of environment you're talking about you should be running configuration management software anyway. (puppet, chef, or similar). So making sure your changes don't get lost in upgrades shouldn't be too hard.
答案4
firewall rule to block ARP?
Seriously though, why would you not want ARP to operate normally?
Most of the reasons I can think of for wanting to use an address that someone else already has are less than honest.