[OOR-Users] Fwd: A LISP Map Server that supports Info-Request and Info-Reply messages?

2016-10-11 Thread Rod Dines 
Sorry errors in the fifth and sixth line in my scenario:

xTR-MN --> NAT --> Info-Request (type 7)--> MSMR Map Server
xTR-MN --> NAT --> Info-Reply (with RTRs)  <-- MSMR Map Server
xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
RTR -->
Map_Reg (RTR RLOC)   --> MSMR (Map Server on LISP-BETA)
RTR <--
ECM (Data_Map_Notify(RTR RLOC)) <-- MSMR (Map Server on LISP-BETA)
xTR-MN <-- NAT <-- Map_Notify   <-- RTR
xTR-MN --> NAT --> ECM Data--> RTR --> DATA OUT (to
LISP direct or legacy via PETR)
xTR-MN --> NAT <-- ECM Data<-- RTR <-- DATA IN (from
LISP direct or legacy via PITR)

-- Forwarded message --
From: Rod Dines 
Date: 10 October 2016 at 17:45
Subject: Re: A LISP Map Server that supports Info-Request and Info-Reply
messages?
To: Albert López 
Cc: us...@lispmob.org


Hi Albert:

Thanks for the fast response and I will join the new mail list.

I understand that you only have support for NAT in xTR but I am under the
impression that an xTR (MN)  behind a NAT sends an Info-Request to a
Map-Server to initiate a Info-Reply by the Map Server to establish the NAT
info and a list of RTR's.  Is this not correct?

My scenario:

xTR-MN --> NAT --> Info-Request (type 7)--> MSMR Map Server
xTR-MN --> NAT --> Info-Reply (with RTRs)  <-- MSMR Map Server
xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
RTR -->
Map_Reg (RTR RLOC)   --> MSMR (Map Server on LISP-BETA)
RTR <--
Map_Notify(RTR RLOC) <-- MSMR (Map Server on LISP-BETA)
xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
xTR-MN --> NAT --> ECM Data--> RTR --> DATA OUT (to
LISP direct or legacy via PETR)
xTR-MN --> NAT <-- ECM Data<-- RTR <-- DATA IN (from
LISP direct or legacy via PITR)

The source for the OOR map server receive-message handler as follows does
not support this.

static int
ms_recv_msg(oor_ctrl_dev_t *dev, lbuf_t *msg, uconn_t *uc)
{
int ret = BAD;
lisp_msg_type_e type;
lisp_ms_t *ms;

ms = lisp_ms_cast(dev);
type = lisp_msg_type(msg);

if (type == LISP_ENCAP_CONTROL_TYPE) {
if (lisp_msg_ecm_decap(msg, >rp) != GOOD)
return (BAD);
type = lisp_msg_type(msg);
}

 switch(type) {
 case LISP_MAP_REQUEST:
 ret = ms_recv_map_request(ms, msg, uc);
 break;
 case LISP_MAP_REGISTER:
 ret = ms_recv_map_register(ms, msg, uc);
 break;
 case LISP_MAP_REPLY:
 case LISP_MAP_NOTIFY:
 case LISP_INFO_NAT:
 OOR_LOG(LDBG_3, "Map-Server: Received control message with type
%d."
 " Discarding!", type);
 break;
 default:



On 10 October 2016 at 17:19, Albert López  wrote:

> Hi Rod,
>
> We only have support for NAT in xTRs. The support of nat traversal in Map
> Servers and RTRs is not yet implemented. Some Cisco boxes  have support for
> NAT but is not official and have some limitations (only one xTR behind the
> same NAT). The RTR implementation of OOR is only supporting ELPs (Explicit
> Locator Path). If you are interested in this functionality and can give you
> some examples.
> On the other hand, would you mind to use the new mailing list
> ? We are
> trying to do a rebrand of the project.
>
> Thanks
>
> Albert
>
>
>
>
>
> On 10/10/16 10:36, Rod Dines wrote:
>
>
> Hi Albert/Others:
>
> While I have had some success (crashes after an approx an hour) I can't
> seem to get Lisp-MN behind a NAT sorted out at all.  I assumed the OOR-MSMR
> could handle the Info-Request and Info-Reply but it returns a discarding
> error and inspecting source appears to not have any implementation
>
> switch(type) {
>  case LISP_MAP_REQUEST:
>  ret = ms_recv_map_request(ms, msg, uc);
>  break;
>  case LISP_MAP_REGISTER:
>  ret = ms_recv_map_register(ms, msg, uc);
>  break;
>  case LISP_MAP_REPLY:
>  case LISP_MAP_NOTIFY:
>  case LISP_INFO_NAT:
>  OOR_LOG(LDBG_3, "Map-Server: Received control message with type
> %d."
>  " Discarding!", type);
>  break;
>
>
> I also find that implementing a RTR configuration is far from clear.  Do
> you have any example configurations or tutorials?  Or am I just looking to
> do something not yet sorted out?
>
> If a NATed MN is possible can you please explain how am I suppose to get a
> MSMR that will help me determine the NAT configuration and work with a RTR
> list?  Does Cisco do it in their IOS version?  Is there an older or forked
> version of oor or lispmob source I should be using?
>
> Do you have any further info besides

Re: [OOR-Users] Fwd: A LISP Map Server that supports Info-Request and Info-Reply messages?

2016-10-10 Thread Albert López 

Hi Rod,

Your diagram is correct. You have more information of how nat works here 
. I 
think that Cisco boxes implements version 2 of this draft. Our xTR 
implementation is a mix of 2 and 10.
Regarding our Map Server implementation, as we don't support NAT 
traversal, the code discards these messages. The MS/MR sg-nus-pxtr has 
NAT support if you want to have a try.


Best regards

Albert


On 10/10/16 11:50, Rod Dines wrote:

Sorry errors in the fifth and sixth line in my scenario:

xTR-MN --> NAT --> Info-Request (type 7)--> MSMR Map Server
xTR-MN --> NAT --> Info-Reply (with RTRs)  <-- MSMR Map Server
xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
  RTR --> Map_Reg (RTR RLOC)   --> 
MSMR (Map Server on LISP-BETA)
  RTR <-- ECM (Data_Map_Notify(RTR 
RLOC)) <-- MSMR (Map Server on LISP-BETA)

xTR-MN <-- NAT <-- Map_Notify   <-- RTR
xTR-MN --> NAT --> ECM Data--> RTR --> DATA OUT 
(to LISP direct or legacy via PETR)
xTR-MN --> NAT <-- ECM Data<-- RTR <-- DATA IN 
(from LISP direct or legacy via PITR)


-- Forwarded message --
From: *Rod Dines* >

Date: 10 October 2016 at 17:45
Subject: Re: A LISP Map Server that supports Info-Request and 
Info-Reply messages?

To: Albert López >
Cc: us...@lispmob.org 


Hi Albert:

Thanks for the fast response and I will join the new mail list.

I understand that you only have support for NAT in xTR but I am under 
the impression that an xTR (MN)  behind a NAT sends an Info-Request to 
a Map-Server to initiate a Info-Reply by the Map Server to establish 
the NAT info and a list of RTR's.  Is this not correct?


My scenario:

xTR-MN --> NAT --> Info-Request (type 7)  --> MSMR Map Server
xTR-MN --> NAT --> Info-Reply (with RTRs)  <-- MSMR Map Server
xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
  RTR --> Map_Reg (RTR RLOC)   --> MSMR (Map Server on 
LISP-BETA)
  RTR <-- Map_Notify(RTR RLOC) <-- MSMR (Map Server on 
LISP-BETA)

xTR-MN --> NAT --> ECM Data-Map_Reg --> RTR
xTR-MN --> NAT --> ECM Data  --> RTR --> DATA OUT (to LISP direct or 
legacy via PETR)
xTR-MN --> NAT <-- ECM Data  <-- RTR <-- DATA IN (from LISP direct or 
legacy via PITR)


The source for the OOR map server receive-message handler as follows 
does not support this.


static int
ms_recv_msg(oor_ctrl_dev_t *dev, lbuf_t *msg, uconn_t *uc)
{
int ret = BAD;
lisp_msg_type_e type;
lisp_ms_t *ms;

ms = lisp_ms_cast(dev);
type = lisp_msg_type(msg);

if (type == LISP_ENCAP_CONTROL_TYPE) {
if (lisp_msg_ecm_decap(msg, >rp) != GOOD)
return (BAD);
type = lisp_msg_type(msg);
}

 switch(type) {
 case LISP_MAP_REQUEST:
 ret = ms_recv_map_request(ms, msg, uc);
 break;
 case LISP_MAP_REGISTER:
 ret = ms_recv_map_register(ms, msg, uc);
 break;
 case LISP_MAP_REPLY:
 case LISP_MAP_NOTIFY:
 case LISP_INFO_NAT:
 OOR_LOG(LDBG_3, "Map-Server: Received control message with 
type %d."

 " Discarding!", type);
 break;
 default:



On 10 October 2016 at 17:19, Albert López > wrote:


Hi Rod,

We only have support for NAT in xTRs. The support of nat traversal
in Map Servers and RTRs is not yet implemented. Some Cisco boxes 
have support for NAT but is not official and have some limitations

(only one xTR behind the same NAT). The RTR implementation of OOR
is only supporting ELPs (Explicit Locator Path). If you are
interested in this functionality and can give you some examples.
On the other hand, would you mind to use the new mailing list
? We
are trying to do a rebrand of the project.

Thanks

Albert





On 10/10/16 10:36, Rod Dines wrote:


Hi Albert/Others:

While I have had some success (crashes after an approx an hour) I
can't seem to get Lisp-MN behind a NAT sorted out at all.  I
assumed the OOR-MSMR could handle the Info-Request and Info-Reply
but it returns a discarding error and inspecting source appears
to not have any implementation

switch(type) {
 case LISP_MAP_REQUEST:
 ret = ms_recv_map_request(ms, msg, uc);
 break;
 case LISP_MAP_REGISTER:
 ret = ms_recv_map_register(ms, msg, uc);
 break;
 case LISP_MAP_REPLY:
 case LISP_MAP_NOTIFY:
   case LISP_INFO_NAT:
   OOR_LOG(LDBG_3, "Map-Server: Received control message with
type %d."
   " Discarding!", type);
 break;


I also find that implementing a