Hi Rod,

Your diagram is correct. You have more information of how nat works here <https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal-11>. 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* <murdoch.edu...@roddines.com <mailto:murdoch.edu...@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 <alo...@ac.upc.edu <mailto:alo...@ac.upc.edu>>
Cc: us...@lispmob.org <mailto: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, &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 <alo...@ac.upc.edu <mailto:alo...@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 <tel:%2B61-449891222>
    www.roddines.com <http://www.roddines.com>


--



--
Rod Dines
Honours in Internetworking and Network Security Research
Perth, Western Australia
+61-449891222 <tel:%2B61-449891222>
www.roddines.com <http://www.roddines.com>



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


_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users

Reply via email to