Dear  Jean-Jacques

Sorry for the delay, this month we are partially off.
After some investigation we have detected an strange behaviour that we must investigate in more detail. When we establish a communication with a non LISP site through a proxy xTR, the piTR initiate a mechanism to know that our RLOC is reachable. This procedure is called RLOC probing and is based in sending request messages and waiting for the reply. When the LISPmob node doesn't reply these messages because is not running, the pitr will change the status of our RLOC in its map-cache to down. (The entry to the map cache of the pitr is added due to a initial communication in the past). When you start again LISPmob, the node send a SMR to all piTR specified in the configuration fail to indicate them that a change of status or address has been produced in the LISPmob node and they should request again the mapping information for our entry. This process seems to work, but the piTR doesn't change the status of the entry from down to up until the next RLOC probing iteration. As the interval between iterations could be bigger for each iteration without reply ( depend on developers decision and it seems it is the case), the interval to obtain a reply to wget increase. From our point of view the status of rloc should change after the reply of the SMR and not wait to next RLOC prob. We will investigate what could happen and try to find a solution.
Thanks for your feed back

Regards

Albert


On 08/10/2013 12:02 PM, Jean-Jacques Sarton wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Albert,

I have started and stopped lisp some times but what I wrote
is also OK for other sites. for example I tried:
wget -6 http://www.yahoo.com
this what OK.
with
wget -4 http://www.yahoo.com
wget tried 3 times and the result 11 minutes.

Yahoo.com has 2 IPv4 adresses and for the third try,
the first IP has ho in time out the try with the second
address what OK.

I had also similar problems with other sites as google.com
With german sites the first try may require a little delay
(1 - 4 sec) but there are no timeouts.

With lispmon.net the IPv6 communication what now OK, the
IPv4 query resulted in a wait time of more than 1 minute.
Consecutive queries work as expected and the "files" are
delivered in max 1 sec.

The lisp-lisp communication don't work always.
wget www.lisp4.net work,  wget www.lisp6.net does not.

If the test node is not a mn node the queries are processed
as expected.


Regards,

Jean-Jacques

Am 10.08.2013 09:12, schrieb Albert López:
Dear Jean-Jacques

Could you provide me with some more details? You experimented this
behaviour since the first time you started LISPmob or after
stopping LISPmob and starting it again after some seconds? Were you
doing handover (change of IP)? Regarding lispmon.net, from 7th to
8th of august, the website was off due to a maintenance procedure.
Now it should be reachable again. Any way, as LISP beta network is
an experimental network maintained by many volunteer institutions,
some times, it is possible that you can not reach some locations.

Regards

Albert




On 08/08/2013 01:59 PM, Jean-Jacques Sarton wrote: I have set up a
mobile node and have performed some tests: if I try to download
some http files (as www.google.com) the time in order to get the
file may be very long, up to several minutes. The results are not
very reproducable. After I have got an answer a following query
return after a shor time. This affect as well IPv4 as IPv6
addresses. Some time the response occur within a short time for
IPv4 or IPv6 but the queried node may not answer for the other IP
type.

I have also tried to query lispmon.net. I have never get an
answer.

wget -6 http://lispmon.net return with no route to hosts

wget -4 http://lispmon.net terminate due to timeout.

May anythings be wrong for my configuration ?

Jean-Jacques



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iEYEARECAAYFAlIGD8YACgkQM9JbiR3CwQvCWwCfY1sWdPrfWg0ucE3P7K4CxQuZ
tmcAnA/mI5g5B6wIVEgh5jdqcugx1keM
=g5BM
-----END PGP SIGNATURE-----

Reply via email to