[hipl-users] Re: long delay in mobility handling procedure

  • From: Robert Moskowitz <rgm@xxxxxxxxxxxxxxx>
  • To: hipl-users@xxxxxxxxxxxxx
  • Date: Fri, 6 Mar 2009 09:19:13 -0500

Szabolcs Nováczki wrote:
What we do is instead of waiting for the old address (and the old default route!!!) to disappear we delete them manually (i.e. with the script). 

Can you share the script?


We configured radvd like:
      MinRtrAdvInterval 1;
      MaxRtrAdvInterval 3;
We also used other min-max combinations.
What do you mean by 'other min-max combinations'? Other values for these parameters or other parameters?
When I was getting RADVD set up back in August, I could not find any advise or help with it.
2009/3/6 Robert Moskowitz <rgm@xxxxxxxxxxxxxxx <mailto:rgm@xxxxxxxxxxxxxxx>> 

    Szabolcs Nováczki wrote:

        All is IPv6. There are three different  /64 networks. One for
        the cn and two for the mobile. The cn is attached on wire. The
        mobile is attched to one of the latter two sites through
         wireless acces points and uses IPv6 stateless
        autoconfiguration when receiving router advertisements to
        configure its IP address. We use a script which periodically
        changes (iwconfig new_ap) from one ap to the other and back.
        The mobile reconfigures its ip address which triggers the hip
        update mechanism.


    I am also running IPv6 and using RADVD for the addresses.  I am
    using separate vlans and right now just unplug a mobile from one
    vlan port and plug it into another.  I hope at some point to have
    a wireless setup, but vlaning and wireless typically means
    separate SSIDs or multiple APs, this is why I am using the wired
    approach for now.

    When I do switch ports, the old IPv6 address hangs in there for a
    little while, then goes away.  By this time it seems the RVS
    update has gone out.  I can do some more testing and report what I
    see.

    BTW, here is one of my entries in radvd.conf:

    interface eth1.16
    {
          AdvSendAdvert on;
          MinRtrAdvInterval 3;
          MaxRtrAdvInterval 10;
          prefix 2607:f4b8:3:3::/64
          {
                  AdvOnLink off;
                  AdvAutonomous on;
                  AdvRouterAddr on;
                  AdvPreferredLifetime 20;
                  AdvValidLifetime 30;
          };
          route ::/0
          {
          };
    };




        2009/3/6 Robert Moskowitz <rgm@xxxxxxxxxxxxxxx
        <mailto:rgm@xxxxxxxxxxxxxxx> <mailto:rgm@xxxxxxxxxxxxxxx
        <mailto:rgm@xxxxxxxxxxxxxxx>>>


           Szabolcs Nováczki wrote:

               Hi hipl users!

               We are doing some tests with infraHIP recently. With basic
               mobility tests we run into the following behaviour:

               There is a significant delay in infraHIP (on the mobile
        side)
               before sending out the first update package.


           How do you create the mobility?  What protocol provides the
        new IP
           address?  Is this IPv4 or IPv6?



               I attached a commented trace of the hipd output
               (hipd_trace_medium) where I highlighted the suspected part.

               My request is that if some of you has time to analyze
        this or
               someone knows the reason for this behaviour please
        share with
               us! What happenes there? Is this delay ok? We are also
               interested of  mechanisms triggering the update
        procedure in
               hipd, and how this trigger is processed.

               Thx!

               Br,
               Szabolcs Novaczki

               Ps.: hipd is running on 2.6.27-11 generic kernel installed
               from ubuntu interpid package

Other related posts:

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