[OOR-Users] Received control message with type 7. Discarding!

[Albert López]

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?
>
> Muchas Gracias
> JM
>
>
> El vie., 10 feb. 2017 a las 5:36, Albert López (<alopez at ac.upc.edu 
> <mailto:alopez at 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 <http://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 <http://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 <http://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 <http://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 <tel:+16502482490>
>>     +56 (9) 9064-2780 <tel:+56990642780>
>>
>>     		jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>>
>>     		jmguzmanc
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at openoverlayrouter.org <mailto:Users at openoverlayrouter.org>
>>     http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
>
>
> -- 
>
> 	*José Miguel Guzmán
> *Senior Network Consultant
> Latin America & Caribbean
>
> 		+1 (650) 248-2490 <tel:+16502482490>
> +56 (9) 9064-2780 <tel:+56990642780>
>
> 		jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>
> 		jmguzmanc
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170213/a8b95f8b/attachment-0001.html>