1. Topics
  2. [lispflowmapping-dev] LISP.

[lispflowmapping-dev] LISP.

Lori Jakab <lojakab@...>
 

Hi Navid,

On 5/5/14, 9:45 PM, Luis Gomez wrote:
CC-ing lisp developers for this question.

BR/Luis

On May 5, 2014, at 11:42 AM, Ghazisaidi, Navid <navid.ghazisaidi@...> wrote:

I think it is better to change the subject of this email, as I did here.
-Navid



On 5/5/14, 11:39 AM, "Ghazisaidi, Navid"
<navid.ghazisaidi@...> wrote:

Another question: I noticed there is no any database running in controller
level to keep and restore information. I created a LISP between 2 LISPmobs
(worked well!). Then I killed the controller, packets were transmitted and
received between the ends as long as the path was in the cache. Then I
restarted the controller. The controller came up completely, the packets
didn¹t get delivered. So I was forced to destroy the LISP in each end
You mean the LISPmob instances? Why did you need to stop them? Just adding the keys in the controller should re-enable registration for them, which they do every minute.

and
reregister the keys in the controller to reestablish the LISP between
ends.
As a workaround, you could increase the TTL of the mapping registration in LISPmob from the current 10 minutes to whatever suits your testbed, by editing lispd/lispd.h and changing the #define for DEFAULT_MAP_REGISTER_TIMEOUT. This will probably be configurable in the future.

Shouldn¹t controller at least keep the keys somewhere that in case
the controller crashed or rebooted it can continue its work? I think it
should be considered as a high-priority requirement for LISP.
Thanks for pointing out this issue, we will consider this feature request for our roadmap.

Best regards,
-Lori

Is there any
plan to add DB to the controller at all?



Thanks,
Navid
_______________________________________________
lispflowmapping-dev mailing list
lispflowmapping-dev@...
https://lists.opendaylight.org/mailman/listinfo/lispflowmapping-dev
Gal Mainzer <GMainzer@...>
 

Hi Navid,
I'd like to point out that at this point, LISP is using ODL ClusterService to store the data. I know that in the past there was a big talk about data persistency (I'm not sure what is the up-to-date status) - the idea of cluster service is relaying on the fact that you will have enough ODL nodes that will allow you to use high enough replication factor to recover for ODL failure (or even simultaneous failures).

Hope this helps,
Gal

-----Original Message-----
From: lispflowmapping-dev-bounces@... [mailto:lispflowmapping-dev-bounces@...] On Behalf Of Lori Jakab
Sent: Tuesday, May 06, 2014 4:07 PM
To: Ghazisaidi, Navid; lispflowmapping-dev@...
Cc: Brent Salisbury; demos-and-pocs@...
Subject: Re: [lispflowmapping-dev] LISP.

Hi Navid,

On 5/5/14, 9:45 PM, Luis Gomez wrote:
CC-ing lisp developers for this question.

BR/Luis

On May 5, 2014, at 11:42 AM, Ghazisaidi, Navid <navid.ghazisaidi@...> wrote:

I think it is better to change the subject of this email, as I did here.
-Navid



On 5/5/14, 11:39 AM, "Ghazisaidi, Navid"
<navid.ghazisaidi@...> wrote:

Another question: I noticed there is no any database running in
controller level to keep and restore information. I created a LISP
between 2 LISPmobs (worked well!). Then I killed the controller,
packets were transmitted and received between the ends as long as
the path was in the cache. Then I restarted the controller. The
controller came up completely, the packets didn¹t get delivered. So
I was forced to destroy the LISP in each end
You mean the LISPmob instances? Why did you need to stop them? Just adding the keys in the controller should re-enable registration for them, which they do every minute.

and
reregister the keys in the controller to reestablish the LISP
between ends.
As a workaround, you could increase the TTL of the mapping registration in LISPmob from the current 10 minutes to whatever suits your testbed, by editing lispd/lispd.h and changing the #define for DEFAULT_MAP_REGISTER_TIMEOUT. This will probably be configurable in the future.

Shouldn¹t controller at least keep the keys somewhere that in case
the controller crashed or rebooted it can continue its work? I think
it should be considered as a high-priority requirement for LISP.
Thanks for pointing out this issue, we will consider this feature request for our roadmap.

Best regards,
-Lori

Is there any
plan to add DB to the controller at all?



Thanks,
Navid
_______________________________________________
lispflowmapping-dev mailing list
lispflowmapping-dev@...
https://lists.opendaylight.org/mailman/listinfo/lispflowmapping-dev
_______________________________________________
lispflowmapping-dev mailing list
lispflowmapping-dev@...
https://lists.opendaylight.org/mailman/listinfo/lispflowmapping-dev
1 - 2 of 2