[hipl-users] Re: Fwd: Re: Fwd: hip update flood

  • From: Miika Komu <miika.komu@xxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Mon, 07 Dec 2009 19:21:18 +0200

Till Janos wrote:

Hi,
please have a look at hipd/maintenance.c:hip_handle_update_heartbeat_trigger(). Particularly this part: 

        ha->update_trigger_on_heartbeat_counter++;
_HIP_DEBUG("Trigger count %d/%d\n", ha->update_trigger_on_heartbeat_counter, 
                  HIP_ADDRESS_CHANGE_HB_COUNT_TRIGGER * hip_icmp_interval);

        if (ha->update_trigger_on_heartbeat_counter <
            HIP_ADDRESS_CHANGE_HB_COUNT_TRIGGER * hip_icmp_interval)
                goto out_err;

        /* Time to try a handover because heart beats have been failing.
           Let's also reset to counter to avoid UPDATE looping in case e.g.
           there is just no connectivity at all. */
        ha->update_trigger_on_heartbeat_counter = 0;
Does the per HIP association update_trigger_on_heartbeat_counter get confused somehow?
Notice the counters gets reset always in hip_icmp_statistics() which is called from hip_icmp_recvmsg().
Can I ask what does "hipconf get ha all" tell you about the ICMP statistics? Do your hosts block somehow ICMPv6 traffic? 


Hi Miika!
If I run simple the hipd daemon on both side host A and host B it works correctly, the address_change_time_counter doesn't reach 0 to trigger the updates. The flooding begins when I start pinging host B from A. The HIP association establishes during the course of the Base Exchange mechanism (A is the Initiator, B the Responder), and from that point the updates are coming frequently. 1. Could you try it? 


I 've checked mobility with handover.
My host A receives the UDP packets from host B using DITG traffic generator. A short time after 4 sec I initiate handover manually, I receive my new address correctly. Even I delete the previous address and route entry right after invoking handover, it seems that the triggering of the update mechanism takes too long sometimes, and causes an extra handover latency (see an axample below). 2. Is this built in handover delaying mechanism necessary? How could I reduce the latency? 


Here is my tshark log:
...
*4.103628 2001:738:2001:20a0:216:76ff:fe06:c0b1 -> 2001:738:2001:2084:230:5ff:fe61:1eb5 ESP ESP (SPI=0xd128d584) /(B -> A)/* 4.103628 2001:12:4e97:be5b:8711:1ab9:68fd:ce95 -> 2001:16:c51e:bd25:5363:b:4de1:2cda UDP Source port: 39181 Destination port: bctp 
7.465298 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
8.403834 :: -> ff02::1:ff61:1eb5 ICMPv6 Neighbor solicitation
10.023130 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
11.555857 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xbe58ab70 
12.570006 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
13.549919 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xbe58ab70 
15.393276 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
15.550055 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xbe58ab70 
17.764293 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
20.038019 fe80::213:20ff:fe20:7c4a -> ff02::1 ICMPv6 Router advertisement
20.072095 2001:738:2001:2087:230:5ff:fe61:1eb5 -> 2001:738:2001:20a0:216:76ff:fe06:c0b1 HIP HIP UPDATE (HIP Update Packet)/ (A -> B Locator )/ 20.209789 fe80::213:20ff:fe20:7c4a -> ff02::1:ff61:1eb5 ICMPv6 Neighbor solicitation 20.209834 2001:738:2001:2087:230:5ff:fe61:1eb5 -> fe80::213:20ff:fe20:7c4a ICMPv6 Neighbor advertisement 20.212753 2001:738:2001:20a0:216:76ff:fe06:c0b1 -> 2001:738:2001:2087:230:5ff:fe61:1eb5 HIP HIP UPDATE (HIP Update Packet) / (B -> A echo_request )/ 20.326227 2001:738:2001:2087:230:5ff:fe61:1eb5 -> 2001:738:2001:20a0:216:76ff:fe06:c0b1 HIP HIP UPDATE (HIP Update Packet) / (A -> B echo_response )/ *20.326784 2001:738:2001:2087:230:5ff:fe61:1eb5 -> 2001:738:2001:20a0:216:76ff:fe06:c0b1 ESP ESP (SPI=0x633d1fd3) /(new address A -> B)/* 20.501106 2001:738:2001:20a0:216:76ff:fe06:c0b1 -> 2001:738:2001:2087:230:5ff:fe61:1eb5 ESP ESP (SPI=0xd128d584) 20.501106 2001:12:4e97:be5b:8711:1ab9:68fd:ce95 -> 2001:16:c51e:bd25:5363:b:4de1:2cda UDP Source port: 39181 Destination port: bctp 
...

handover switching script:

echo "HO: ap2 -> ap1 "
iwconfig wlan0 essid asus-fmip-ap1 &
echo  "previous address and route deleting"
ip -6 addr del dev wlan0 2001:738:2001:2084:230:5ff:fe61:1eb5/64 &
ip -6 route del default via fe80::213:20ff:fe20:7c4d dev wlan0 &


Thanks for your help,
Janos 

2009/12/4 Miika Komu <miika.komu@xxxxxxx <mailto:miika.komu@xxxxxxx>>



    Hi,

    I tried but I can't repeat your problem. Your logs say first:

    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 5)
    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 4)
    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 3)
    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 2)
    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 1)
    debug(maintenance.c:753@periodic_maintenance): Delay mobility
    triggering (count 0)

    and this not displayed later at all:

    debug(maintenance.c:748@periodic_maintenance): Triggering UPDATE

    I believe this is probably the source of the problem.

    The new algo for "delayed handovers" is quit short and simple. It's
    in hipd/maintenance.c:

       744         if (hip_wait_addr_changes_to_stabilize &&
       745             address_change_time_counter != -1) {
       746                 if (address_change_time_counter == 0) {
       747                         address_change_time_counter = -1;
       748                         HIP_DEBUG("Triggering UPDATE\n");
       749                         err = hip_send_update_locator();
       750                         if (err)
       751                                 HIP_ERROR("Error sending
    UPDATE\n");
       752                 } else {
       753                         HIP_DEBUG("Delay mobility triggering
    (count %d)\n   753 n", address_change_time_counter - 1);
       754                         address_change_time_counter--;
       755                 }
       756         }

    Value -1 is the initial for address_change_time_counter and it means
    that there no need trigger handover. Value zero means that a
    handover needs to be triggered immediately. A positive value N means
    that the handover should be triggered in N seconds.

    Can you find a flaw in that algorithm? You can also use gdb to test
    this as follows:

    # gdb hipd
    watch address_change_time_counter
    run

    (then type "continue" to continue after hitting a breakpoint)

    I am sorry the bounce this problem back to you but I really tried to
    repeat the problem but couldn't.

Other related posts:

  1. Home
  2. hipl-users
  3. Archive
  4. 12-2009