2

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?

Josh Smeaton
  • 1,340
  • 2
  • 19
  • 31

4 Answers4

3

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

squareborg
  • 592
  • 3
  • 14
2

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.

Michael Hampton
  • 244,070
  • 43
  • 506
  • 972
1

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.

mc0e
  • 5,866
  • 18
  • 31
  • We are using puppet and managing these files with puppet already. It's not too bad currently - but I was hoping for something a little better. A single command line switch is easier to manage and understand than a hacked together ifup script. Thanks for the input though. – Josh Smeaton Jun 07 '13 at 01:49
0

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.

mc0e
  • 5,866
  • 18
  • 31
  • The applications are for routing/streaming RTP traffic in a call center. The control server, during a primary/backup failover, sends an up message to the new primary and a down message to the old primary. If these arrive out-of-order, the switchover fails, and thousands of calls drop because they no longer have a RTP server to connect to. – Josh Smeaton Jun 05 '13 at 12:12
  • What I was hoping for was something like: `ifup eth0:1 --force` – Josh Smeaton Jun 05 '13 at 12:14