2

I have a Linux system with two ethernet interfaces, eth0 & eth1, which are used on the same subnet. At times, I see that even when one of the interfaces is disconnected (cable unplugged), Linux continues to use its IP address.

For example, if eth0 is disconnected while eth1 is plugged in, you can see that the "ip ro get" command reports eth0 as being the default interface.

~ $ ip ro get 192.168.1.1

192.168.1.1 dev eth0  src 192.168.1.5

As a consequence, tools such as scp & ping end up using a disconnected interface & fail.

My question is, why does Linux continue to use disconnected interfaces? Shouldn't it automatically detect & stop using them?

  • 2
    No, it shouldn't. – Ipor Sircer Oct 12 '18 at 17:39
  • Wanting IP addresses to change when an interface disconnects is an unusual thing to want. It would be quite surprising if it happened automatically. The system is still operational and the IP address is still assigned to the system. Why should it change IP addresses it's using? – David Schwartz Oct 12 '18 at 21:41
  • If the route is used or not depends on the neighbor discovery state for the gateway which in turn depends on the interface state. But I think ip Rö get only searches in the FIB table with no regards to the lower layers. It does not emulate the path of a outgoing packet. Besides that dynamic routing usually require a routing protocol agent which does respond to network device events. – eckes Oct 12 '18 at 23:33
  • @IporSircer Why not? If the cable is disconnected, what's the point in still using that interface as the default? – Sunny Yates Oct 13 '18 at 6:15
  • 1
    @SunnyYates You seem to be confusing interfaces with IP address. You asked, "I see that even when one of the interfaces is disconnected (cable unplugged), Linux continues to use its IP address". The answer is that the loss of an interface is not a reason to change IP addresses. IP addresses belong to the system, not the interface. – David Schwartz Oct 14 '18 at 18:49
1

ARP flux!

you should set the sysctl parameters arp_ignore and arp_announce to yours needs.

First test this commands and then if these work you can add thas lines to /etc/sysctl.conf file.

First execute this command:

# sysctl -a | grep net.ipv4.conf.*.arp

and the output should be something like this:

net.ipv4.conf.all.arp_accept = 0
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.all.arp_notify = 0
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.proxy_arp_pvlan = 0
net.ipv4.conf.default.arp_accept = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.default.arp_notify = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.proxy_arp_pvlan = 0
net.ipv4.conf.eth0.arp_accept = 0
net.ipv4.conf.eth0.arp_announce = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.arp_ignore = 0
net.ipv4.conf.eth0.arp_notify = 0
net.ipv4.conf.eth0.proxy_arp = 0
net.ipv4.conf.eth0.proxy_arp_pvlan = 0
net.ipv4.conf.eth1.arp_accept = 0
net.ipv4.conf.eth1.arp_announce = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.arp_ignore = 0
net.ipv4.conf.eth1.arp_notify = 0
net.ipv4.conf.eth1.proxy_arp = 0
net.ipv4.conf.eth1.proxy_arp_pvlan = 0
net.ipv4.conf.lo.arp_accept = 0
net.ipv4.conf.lo.arp_announce = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.lo.arp_notify = 0
net.ipv4.conf.lo.proxy_arp = 0
net.ipv4.conf.lo.proxy_arp_pvlan = 0

then you execute these commands:

# sysctl -w net.ipv4.conf.all.arp_ignore=1
# sysctl -w net.ipv4.conf.all.arp_announce=2

still execute this command to check for the changes

# sysctl -a | grep net.ipv4.conf.*.arp

and you should see something like this with changes:

net.ipv4.conf.all.arp_accept = 0
net.ipv4.conf.all.arp_announce = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_notify = 0
net.ipv4.conf.all.proxy_arp = 0
net.ipv4.conf.all.proxy_arp_pvlan = 0
net.ipv4.conf.default.arp_accept = 0
net.ipv4.conf.default.arp_announce = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.arp_ignore = 0
net.ipv4.conf.default.arp_notify = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.proxy_arp_pvlan = 0
net.ipv4.conf.eth0.arp_accept = 0
net.ipv4.conf.eth0.arp_announce = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.arp_ignore = 0
net.ipv4.conf.eth0.arp_notify = 0
net.ipv4.conf.eth0.proxy_arp = 0
net.ipv4.conf.eth0.proxy_arp_pvlan = 0
net.ipv4.conf.eth1.arp_accept = 0
net.ipv4.conf.eth1.arp_announce = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.arp_ignore = 0
net.ipv4.conf.eth1.arp_notify = 0
net.ipv4.conf.eth1.proxy_arp = 0
net.ipv4.conf.eth1.proxy_arp_pvlan = 0
net.ipv4.conf.lo.arp_accept = 0
net.ipv4.conf.lo.arp_announce = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.arp_ignore = 0
net.ipv4.conf.lo.arp_notify = 0
net.ipv4.conf.lo.proxy_arp = 0
net.ipv4.conf.lo.proxy_arp_pvlan = 0

Or you can change the values accord to your needs:

arp_announce

arp_announce - INTEGER
    Define different restriction levels for announcing the local
    source IP address from IP packets in ARP requests sent on
    interface:
    0 - (default) Use any local address, configured on any interface
    1 - Try to avoid local addresses that are not in the target's
    subnet for this interface. This mode is useful when target
    hosts reachable via this interface require the source IP
    address in ARP requests to be part of their logical network
    configured on the receiving interface. When we generate the
    request we will check all our subnets that include the
    target IP and will preserve the source address if it is from
    such subnet. If there is no such subnet we select source
    address according to the rules for level 2.
    2 - Always use the best local address for this target.
    In this mode we ignore the source address in the IP packet
    and try to select local address that we prefer for talks with
    the target host. Such local address is selected by looking
    for primary IP addresses on all our subnets on the outgoing
    interface that include the target IP address. If no suitable
    local address is found we select the first local address
    we have on the outgoing interface or on all other interfaces,
    with the hope we will receive reply for our request and
    even sometimes no matter the source IP address we announce.

    The max value from conf/{all,interface}/arp_announce is used.

    Increasing the restriction level gives more chance for
    receiving answer from the resolved target while decreasing
    the level announces more valid sender's information.

arp_ignore

arp_ignore - INTEGER
    Define different modes for sending replies in response to
    received ARP requests that resolve local target IP addresses:
    0 - (default): reply for any local target IP address, configured
    on any interface
    1 - reply only if the target IP address is local address
    configured on the incoming interface
    2 - reply only if the target IP address is local address
    configured on the incoming interface and both with the
    sender's IP address are part from same subnet on this interface
    3 - do not reply for local addresses configured with scope host,
    only resolutions for global and link addresses are replied
    4-7 - reserved
    8 - do not reply for all local addresses

    The max value from conf/{all,interface}/arp_ignore is used
    when ARP request is received on the {interface}

When you are satisfied you should add these two lines in /etc/sysctl.conf

# cp /etc/sysctl.conf /etc/sysctl.confBKP

# echo "net.ipv4.conf.all.arp_ignore=1" >> /etc/sysctl.conf

# echo s"net.ipv4.conf.all.arp_announce=2" >> /etc/sysctl.conf

these links for reference:

ARP flux

Using ARP

Hope this help.

  • I'm already setting both arp_ignore & arp_announce to the values you mentioned. Neither have any effect on this problem. The ARP flux issue relates to when one interface decides to respond to the traffic meant for the other one just cause it can. I have that issue sorted out already. The key thing here is that the communication is being initiated from the system's side and an interface with no cable plugged in is being treated as the default when clearly, Linux could pick the other one. – Sunny Yates Oct 13 '18 at 6:26

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.