On Mon, Feb 13, 2017 at 10:54 AM, Albert López <alo...@ac.upc.edu> wrote:

> Hola José Miguel,
>
> I have not worked to much with Open Daylight but I think it will not
> work.  You need somehow a mechanism to open a hole in the NAT box and the
> current implementation of Lisp Flow Mapping will not help at this point.
>
> Best regards
>
> Albert
>
>
>
> On 10/02/17 15:36, José Miguel Guzmán wrote:
>
> Albert
>
> Thanks a lot for your clarification
>
> I was not aware of lisp-nat-traversal draft
> <https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal-11>
> Disabling nat traversal, fixed this problem, but introduced the problem
> that it does not work behind NAT :)
>
> Using OpenDaylight Lisp Flow Mapping:Main
> <https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Main> with
> OOR, is a viable solution for NAT?
>
>
Unfortunately ODL lfm Map-Server doesn't support NAT traversal.

-Lori


>
> Muchas Gracias
> JM
>
>
>
> El vie., 10 feb. 2017 a las 5:36, Albert López (<alo...@ac.upc.edu>)
> escribió:
>
>> Dear José Miguel,
>>
>> First of all, welcome to the OOR community :-).
>> The message type 7 is an info request message described in the 
>> lisp-nat-traversal
>> draft <https://tools.ietf.org/html/draft-ermagan-lisp-nat-traversal-11>
>> .
>> Unfortunately we only provide support of NAT Traversal in the xTR/MN
>> mode. Our implementation of MS and RTR are pretty basic and doesn't
>> support  this feature yet. When we want to use an xTR behind NAT, the xTR
>> registers  with a MSs deployed in a Cisco box which are compatible with our
>> implementation and using also  a Cisco RTR.
>> If you nodes are not behind NAT, then you can disable
>> nat_traversal_support. With this feature disabled, you can use our
>> implementation of MS.
>> By the way, thank you so much for your pull requests :-)
>>
>> Best regards
>>
>> Albert
>>
>>
>>
>> On 10/02/17 03:26, José Miguel Guzmán wrote:
>>
>> Hi
>>
>> I am trying to make OOR  v1.1.1 work is a simple scenario, but I see than
>> xTR is sending messages with an unsupported type 7, to the MS.
>> In Wireshark I confirmed the type is 7, although i don´t see this in
>> RFC6830 <https://tools.ietf.org/html/rfc6830>  this type as one of the
>> supported ones
>>
>> Locator/ID Separation Protocol
>>     0111 .... .... .... .... .... = Type: Info (7)
>>     .... 0... .... .... .... .... = R bit (Info-Reply): Not set
>>     .... .000 0000 0000 0000 0000 0000 0000 = Reserved bits: 0x00000000
>>
>> MS log says
>>
>> [2017/2/10 2:17:23] DEBUG: Received Info Request -> nonce
>> 93971bbd5dddb7b3, IP: 172.31.49.202 -> 172.31.55.142, UDP: 4342 -> 4342
>> [2017/2/10 2:17:23] DEBUG-3: Map-Server: Received control message with
>> type 7. Discarding!
>> [2017/2/10 2:17:23] DEBUG: Map-Server: Failed to process  control message
>>
>> Any idea about what I am doing wrong?
>> I would appreciate any guidance about this.
>>
>> Bellow a summary of both configurations:
>>
>> *OOR running as xTR*
>> operating-mode         = xTR
>> control-iface = eth0
>> encapsulation          = LISP
>> rloc-probing {
>>     rloc-probe-interval             = 30
>>     rloc-probe-retries              = 2
>>     rloc-probe-retries-interval     = 5
>> }
>> map-resolver        = {
>> 172.31.55.142
>> }
>> static-map-cache {
>>     eid-prefix          = 192.168.1.0/24
>>     iid                 = 13784
>>     rloc-address {
>>         address         = 172.31.85.142
>>         priority        = 0
>>         weight          = 0
>>     }
>> }
>> nat_traversal_support  = on
>> map-server {
>>         address        = 172.31.55.142
>>         key-type       = 1
>>         key            = yunque
>>         proxy-reply    = on
>> }
>> database-mapping {
>>     eid-prefix          = 172.31.64.0/24
>>     iid                 = 13785
>>     rloc-address {
>>         #address         = 34.194.45.229
>>         address         = 172.31.49.202
>>         priority        = 0
>>         weight          = 0
>>     }
>> }
>> proxy-itrs = {
>> ...
>> }
>>
>> *OOR running as xTR*
>> operating-mode         = MS
>> control-iface = eth0
>> lisp-site {
>>     eid-prefix            = 192.168.1.0/24
>>     key-type              = 1
>>     key                   = yunque
>>     iid                   = 13784
>>     accept-more-specifics = true
>> }
>> lisp-site {
>>     eid-prefix            = 172.31.64.0/24
>>     key-type              = 1
>>     key                   = yunque
>>     iid                   = 13785
>>     accept-more-specifics = true
>> }
>>
>>
>>
>>
>>
>> --
>>
>>
>> *José Miguel Guzmán *Senior Network Consultant
>> Latin America & Caribbean
>>
>>   +1 (650) 248-2490 <+16502482490>
>>   +56 (9) 9064-2780 <+56990642780>
>>
>>   jmguz...@whitestack.com
>>
>>   jmguzmanc
>>
>>
>> _______________________________________________
>> Users mailing 
>> listUsers@openoverlayrouter.orghttp://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> --
>
>
> *José Miguel Guzmán *Senior Network Consultant
> Latin America & Caribbean
>
>   +1 (650) 248-2490 <+16502482490>
>   +56 (9) 9064-2780 <+56990642780>
>
>   jmguz...@whitestack.com
>
>   jmguzmanc
>
>
>
> _______________________________________________
> Users mailing list
> Users@openoverlayrouter.org
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users

Reply via email to