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

[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 <murdoch.edu.au at roddines.com>
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 <alopez at ac.upc.edu>
Cc: users at 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, &uc->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 <alopez at ac.upc.edu> 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
> <https://github.com/OpenOverlayRouter/oor/wiki/Mailing-lists>? 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 you published papers on the RTR.  I
> have the slides and whitepaper from the LispMob site.
>
> Regards, Rod,
>
>
>
>
>
> --
> Rod Dines
> Honours in Internetworking and Network Security Research
> Perth, Western Australia
> +61-449891222
> www.roddines.com
>
>
>
> --
>
>


-- 
Rod Dines
Honours in Internetworking and Network Security Research
Perth, Western Australia
+61-449891222
www.roddines.com



-- 
Rod Dines
Honours in Internetworking and Network Security Research
Perth, Western Australia
+61-449891222
www.roddines.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20161010/4f3401d5/attachment-0001.html>