[support] DAD Delay too high?

support at adhari.de support at adhari.de
Thu Sep 3 18:20:56 JST 2009


  Normal 0   21   false false false  DE X-NONE X-NONE       
      MicrosoftInternetExplorer4                            
                                                            
                                                            
    <!--  /* Font Definitions */  @font-face
	{font-family:"Cambria Math"; 	panose-1:2 4 5 3 5 4 6 3 2 4;
	mso-font-charset:1; 	mso-generic-font-family:roman;
	mso-font-format:other; 	mso-font-pitch:variable;
	mso-font-signature:0 0 0 0 0 0;} @font-face
	{font-family:Calibri; 	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0; 	mso-generic-font-family:swiss;
	mso-font-pitch:variable; 	mso-font-signature:-1610611985
1073750139 0 0 159 0;}  /* Style Definitions */ 
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no; 	mso-style-qformat:yes;
	mso-style-parent:""; 	margin:0cm; 	margin-bottom:.0001pt;
	mso-pagination:widow-orphan; 	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-fareast-font-family:Calibri;
	mso-fareast-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";} .MsoChpDefault
	{mso-style-type:export-only; 	mso-default-props:yes;
	font-size:10.0pt; 	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;} @page Section1 	{size:612.0pt
792.0pt; 	margin:70.85pt 70.85pt 2.0cm 70.85pt;
	mso-header-margin:36.0pt; 	mso-footer-margin:36.0pt;
	mso-paper-source:0;} div.Section1 	{page:Section1;} --> 

 /* Style Definitions */
 table.MsoNormalTable
	{mso-style-name:"Normale Tabelle";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";
	mso-ascii-font-family:Calibri;
	mso-ascii-theme-font:minor-latin;
	mso-fareast-font-family:SimSun;
	mso-fareast-theme-font:minor-fareast;
	mso-hansi-font-family:Calibri;
	mso-hansi-theme-font:minor-latin;
	mso-bidi-font-family:"Times New Roman";
	mso-bidi-theme-font:minor-bidi;}


Hello everybody,



I am performing MIPv6 handover measurements using UMIP-4.0
on a debian system with a 2.6.29 kerne, and i am recording
some unusually high values of handover latency (upto 8
&ndash; 10 seconds) and am wondering if any one has an
idea.



I am performing a manual handover from HA to foreign
network in a WLAN network (using Linksys APs), and I am
capturing traffic using wireshark and I notice that after
Router Discovery, the MN will understandably perform DAD
test on the new CoA by sending Neighbor Solicitation
messages (NS) I notice that the MN sends out two NS, one
having the Link Local Address and the other the tentative
CoA. They are send at times 5.255676 and 5.423619 sec
respectively. 



Now as per my understanding, the DAD test will take 1 sec
and if it passes, the MN will assign the CoA and send a BU
to the HA immediately. However I observe that the BU is sent
almost 3 seconds later (i.e., at time 8.182842 sec. This can
be seen in the wireshark log below:



3.962357 fe80::201:2ff:fe1a:d2be -> ff02::1 ICMPv6 Router
advertisement

 3.967629 :: -> ff02::16 ICMPv6 Multicast Listener Report
Message v2

 4.000767 2001:a:b::1 -> 2001:a:c:1::1000 ICMPv6 Echo
request

 4.001619 2001:a:c:1::1000 -> 2001:a:b::1 ICMPv6 Echo
reply

 4.053322 :: -> ff02::2 ICMPv6 Router solicitation

 4.059649 :: -> ff02::16 ICMPv6 Multicast Listener Report
Message v2

 4.339647 :: -> ff02::1:ff1d:b521 ICMPv6 Neighbor
solicitation

 4.900831 :: -> ff02::2 ICMPv6 Router solicitation

 5.108217 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 5.109545 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 5.115649 :: -> ff02::16 ICMPv6 Multicast Listener Report
Message v2

 5.200038 :: -> ff02::2 ICMPv6 Router solicitation

 5.255676 :: -> ff02::1:ff1d:b521 ICMPv6 Neighbor
solicitation

 5.423619 :: -> ff02::1:ff1d:b521 ICMPv6 Neighbor
solicitation

 6.009816 2001:a:b::1 -> 2001:a:c:1::1000 ICMPv6 Echo
request

 6.691858 2001:a:b::1 -> ff02::fb MDNS Standard query ANY
1.2.5.b.d.1.e.ff.f.f.6.6.1.2.0.1.0.0.0.e.0.0.0.a.0.0.0.1.0.0.2.ip6.arpa,
"QM" question ANY MobileNode-2.local, "QM" question

 6.692349 2001:a:b::1 -> ff02::fb MDNS Standard query
response HINFO, cache flush I686 LINUX AAAA, cache flush
2001:a:b::1

 6.942266 2001:a:b::1 -> ff02::fb MDNS Standard query ANY
1.2.5.b.d.1.e.ff.f.f.6.6.1.2.0.1.0.0.0.e.0.0.0.a.0.0.0.1.0.0.2.ip6.arpa,
"QM" question ANY MobileNode-2.local, "QM" question

 7.017749 2001:a:b::1 -> 2001:a:c:1::1000 ICMPv6 Echo
request

 7.193428 2001:a:b::1 -> ff02::fb MDNS Standard query ANY
1.2.5.b.d.1.e.ff.f.f.6.6.1.2.0.1.0.0.0.e.0.0.0.a.0.0.0.1.0.0.2.ip6.arpa,
"QM" question ANY MobileNode-2.local, "QM" question

 7.193880 2001:a:b::1 -> ff02::fb MDNS Standard query
response HINFO, cache flush I686 LINUX AAAA, cache flush
2001:a:b::1

 7.393745 2001:a:b::1 -> ff02::fb MDNS Standard query
response PTR, cache flush MobileNode-2.local AAAA, cache
flush 2001:a:e:1:216:6fff:fe1d:b521

 8.025806 2001:a:b::1 -> 2001:a:c:1::1000 ICMPv6 Echo
request

 8.180210 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 8.181595 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 8.182842 2001:a:b::1 -> 2001:a:b::1000 MIPv6 Binding
Update

 8.182988 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 .

 .

 .

 9.408966 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.410098 fe80::208:a1ff:fe24:8384 -> ff02::1:ff1d:b521
ICMPv6 Neighbor solicitation

 9.410148 2001:a:e:1:216:6fff:fe1d:b521 ->
fe80::208:a1ff:fe24:8384 ICMPv6 Neighbor advertisement

 9.411510 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.412989 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.414346 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.415793 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.417281 fe80::208:a1ff:fe24:8384 -> ff02::1 ICMPv6 Router
advertisement

 9.419958 2001:a:b::1000 -> 2001:a:b::1 MIPv6 Binding
Acknowledgement





Can any one explain as to why the MN spends so much time
after the DAD test before sending out a BU message? Is this
normal as I expect the BU to be sent almost 1 sec after the
NS is sent out?

Where can I check the value of the DADRetransTimer
parameter? Is there a possibility to manually set the
DADRetransTimer parameter?



Looking forward to an answer, suggestion, advice,



Hakim







-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 12362 bytes
Desc: not available
Url : http://ml.nautilus6.org/pipermail/support/attachments/20090903/5bfb7a56/attachment.bin 


More information about the Support mailing list