lkml.org 
[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectwhy is it taking so long to change interfaces?
    I'm trying to figure out why swapping from one NIC to another is taking
    so long (on the order of a few seconds), and I was hoping one of you
    could help me out.

    I'm running a bit of an odd setup, so bear with me for a minute while I
    explain. Machine A has two NICs each set to a different IP address but
    on the same subnet (192.168.1.0). (Note: I've also tried it with them
    on different subnets to start with, and it makes no difference.) They
    each go to the same switch. Also on that switch is machine B with one
    NIC, set to 192.168.0.10. Initially, eth0:0 on machine A is aliased to
    192.168.0.20. (I know this is an odd setup with two subnets on the same
    wires, but there is a reason for it and it seems to work. Also, I do
    realize the issues with routing for dual nics on the same subnet, so
    don't concentrate on that, please.) Both machines are running linux
    2.2.17.

    Anyways, I then run ping from 0.10 to 0.20. This works just fine. I
    then execute the following commands in a script on machine A:

    ifconfig eth0:0 down (removes the alias, but leaves eth0 running fine)
    ifconfig eth1:0 192.168.0.20 (set up a new alias on the other NIC)
    send_arp eth1 [apropriate arguments to send out a gratuitous arp]
    route

    This returns immediately, tcpdump shows the arp being sent out
    immediately, route shows the new route to 192.168.0.0 going through
    eth1, and tcpdump shows the ping requests come in on eth1, but the first
    few ping replies still go out on eth0 and it takes a few seconds before
    the ping replies go out on eth1. This baffles me--the route to the
    192.168.0.0 network is through eth1 now, so why would they go out on
    eth0?

    Going back to eth0 its the same thing--packets come in on the new alias,
    but still go out the old interface for a few seconds.

    Does anyone have any idea why it is taking so long for the packets to
    get sent out the new route? I've got the cards set to 1.0 by default but
    in this scenario there is no traffic on 1.0, and the active NIC is
    aliased to 0.0 to ensure that the 0.0 packets only go out on that card.

    Here is what my routing tables look like initially, then after a change
    to eth1, then after the change back to eth0:


    # route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
    127.0.0.0 * 255.0.0.0 U 0 0 0 lo
    # ./change
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.0.0 * 255.255.255.0 U 0 0 0 eth1
    127.0.0.0 * 255.0.0.0 U 0 0 0 lo
    # ./change2
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
    192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
    127.0.0.0 * 255.0.0.0 U 0 0 0 lo
    #

    So, in all cases there is only a single interface that should be used to
    access the .0.0 subnet from machine A. But what I'm seeing is that for
    a few seconds after the change or change2 command, the incoming packets
    come in the new interface (as they should) but outgoing packets go out
    the old interface.

    Anyways, if anyone could suggest where in the routing code this delay is
    coming from and maybe how to avoid it, I would greatly appreciate it.

    Chris
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:41    [W:0.026 / U:31.608 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site