[OOR-Users] lispTun0 going nowhere...
Albert López
alopez at ac.upc.edu
Tue Feb 14 12:34:27 CET 2017
Hi José,
I try to reply inline
On 14/02/17 02:15, José Miguel Guzmán wrote:
> Albert
>
> Your mail came just before I was going to test sending packets to the
> Internet.
>
> Under the Proxy Tunnel Router model, there will be specific egress
> points, towards the public internet.
> The xTR complies with this, by installing only a default route in
> table 100, towards the tunnel interface
>
> # ip route list table 100
> *default dev lispTun0 metric 100*
OOR install a rule like "from <EID Prefix> lookup 100" where EID Prefix
are the local prefixes configured in the xTR. Only packets from an EID
host will be send to OOR using the default root of table 100 (we want
all packets from an EID host to be rooted by OOR). When a packet is
received into OOR through lispTun0 we check the destination EID at the
cache or the mapping system. If it is not a LISP EID we receive a
negative mapping with action native forward and then we send the packet
to the PeTR, or we forward native (non LISP encapsulated) if no PeTR is
defined.
>
> Wouldn't it be better to allow (if desired) distribute egress to the
> internet, by having each xTR making that decision?
> In that case, each xTR would make it as allowed in each site (eg, with
> source nat, load balancing, qos, shapping, etc)
I don't follow at this point. Could you explain in another way?
>
> I did a test, by adding specific routes towards the EIDs, via the tunnel.
> Everything else should follow lookup in the main table.
> *
> *
> *# ip route list table 100
> *
> 192.168.101.0/24 <http://192.168.101.0/24> dev lispTun0 proto static
> scope link metric 100
> 192.168.102.0/24 <http://192.168.102.0/24> dev lispTun0 proto static
> scope link metric 100
> 192.168.103.0/24 <http://192.168.103.0/24> dev lispTun0 proto static
> scope link metric 100
> 192.168.104.0/24 <http://192.168.104.0/24> dev lispTun0 proto static
> scope link metric 100
>
> It works great!
> So, I have access to my "private sites" and also full internet access
> from my devices.. with no need to use PxTRs.
This is a valid option for local scenario where you know all the EID
prefixes. Only LISP packets will go into OOR. Other packets will be send
using the main table. EIDs hosts will be able to send packets to the
Internet but how they will receive packets? Are the EIDs announced in
the global internet or do you use NAT?
>
> I imagine that the requirement for a default route via the tunnel, is
> to allow oor to resolve EIDs as it is required, based on the
> destination address in packets coming from the tunnel. So, without the
> default route, you cannot know which EIDs will need to be routed via
> the tunnel...
That's right.
>
> However, one option will be to leverage the static-map-cache config
> option.. where EIDs can be defined statically.
OOR use static-map-cache in a different way. You can introduce a static
mapping (EID to RLOCs) and in that way you don't need a Map Resolver to
obtain the location of the configured EID prefix.
What we need here is to extend the static-map-cache with action
"map-request" and use this to configure table 100 like your example.
>
> Do you see any value in a feature, that will allow to configure
> selective-tunnel-routing-only-for-statucally-mapped-eids, in order to
> provide something similar to "Split Tunneling"??
Yes, it is an interesting feature but unfortunately at this moments we
are working in other features.
Best regards
Albert
>
> I would appreciate your comments, as I am a newbie in this field. (and
> in many others)...
>
> JM
>
> El lun., 13 feb. 2017 a las 5:57, Albert López (<alopez at ac.upc.edu
> <mailto:alopez at ac.upc.edu>>) escribió:
>
> Hola José Miguel,
>
> I am glad you managed to make it work :-). I just wanted to
> remember you that with an IID different to 0, you can not interact
> with non lisp sites using PxTR. It is only used in private
> scenarios. You can considere iid some how as a vlan but at level 3.
>
> Best regards
>
>
> Albert
>
>
> On 11/02/17 07:47, José Miguel Guzmán wrote:
>> Hi Albert
>>
>> I found the problem
>>
>> It seems I misunderstood everything, when configured different
>> IIDs for each site :(
>> Now, with the same IIDs, it is working for VXLAN and LISP.
>>
>> Thanks, anyway
>> JM
>>
>>
>> El vie., 10 feb. 2017 a las 11:31, José Miguel Guzmán
>> (<jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>>)
>> escribió:
>>
>> Thanks Albert for your quick reply
>>
>>
>> So, basically I have 4 xTRs
>> LANs WANs
>> 172.31.64.250/24 <http://172.31.64.250/24> (eth1) <---> R1
>> <----> (eth0) 172.31.72.250/24 <http://172.31.72.250/24>
>> 172.31.65.250/24 <http://172.31.65.250/24> (eth1) <---> R2
>> <----> (eth0) 172.31.73.250/24 <http://172.31.73.250/24>
>> 172.31.66.250/24 <http://172.31.66.250/24> (eth1) <---> R3
>> <----> (eth0) 172.31.74.250/24 <http://172.31.74.250/24>
>> 172.31.67.250/24 <http://172.31.67.250/24> (eth1) <---> R4
>> <----> (eth0) 172.31.75.250/24 <http://172.31.75.250/24>
>>
>> This is info for R1
>>
>> *root at ip-172-31-72-250:~# cat /etc/oor.conf | egrep -v "^#|^$"*
>> debug = 1
>> map-request-retries = 2
>> log-file = /var/log/oor-R1.log
>> operating-mode = xTR
>> 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 = 172.31.65.0/24 <http://172.31.65.0/24>
>> iid = 13002
>> rloc-address {
>> address = 172.31.73.250
>> priority = 0
>> weight = 0
>> }
>> }
>> static-map-cache {
>> eid-prefix = 172.31.66.0/24 <http://172.31.66.0/24>
>> iid = 13003
>> rloc-address {
>> address = 172.31.74.250
>> priority = 0
>> weight = 0
>> }
>> }
>> static-map-cache {
>> eid-prefix = 172.31.67.0/24 <http://172.31.67.0/24>
>> iid = 13004
>> rloc-address {
>> address = 172.31.75.250
>> priority = 0
>> weight = 0
>> }
>> }
>> 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 = 13001
>> rloc-address {
>> address = 172.31.72.250
>> priority = 0
>> weight = 0
>> }
>> }
>>
>> *root at ip-172-31-72-250:~# ifconfig*
>> eth0 Link encap:Ethernet HWaddr 12:02:48:d3:aa:92
>> inet addr:172.31.72.250 Bcast:172.31.72.255
>> Mask:255.255.255.0
>> inet6 addr: fe80::1002:48ff:fed3:aa92/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:9001 Metric:1
>> RX packets:49374 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:36030 errors:0 dropped:0 overruns:0
>> carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:242451674 (242.4 MB) TX bytes:5473559
>> (5.4 MB)
>>
>> eth1 Link encap:Ethernet HWaddr 12:68:08:c1:52:94
>> inet addr:172.31.64.250 Bcast:172.31.64.255
>> Mask:255.255.255.0
>> inet6 addr: fe80::1068:8ff:fec1:5294/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:625 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:504 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:28818 (28.8 KB) TX bytes:21656 (21.6 KB)
>>
>> lispTun0 Link encap:UNSPEC HWaddr
>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>> UP POINTOPOINT RUNNING MTU:1440 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:350 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:500
>> RX bytes:0 (0.0 B) TX bytes:29400 (29.4 KB)
>>
>> lo Link encap:Local Loopback
>> inet addr:127.0.0.1 Mask:255.0.0.0
>> inet6 addr: ::1/128 Scope:Host
>> UP LOOPBACK RUNNING MTU:65536 Metric:1
>> RX packets:180 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1
>> RX bytes:13976 (13.9 KB) TX bytes:13976 (13.9 KB)
>>
>> *root at ip-172-31-72-250:~# ip rule*
>> 0:from all lookup local
>> 2:from 172.31.72.250 lookup 2
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 99:from all to 172.31.64.0/24 <http://172.31.64.0/24> lookup main
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 100:from 172.31.64.0/24 <http://172.31.64.0/24> lookup 100
>> 32766:from all lookup main
>> 32767:from all lookup default
>>
>> *root at ip-172-31-72-250:~# ip route*
>> default via 172.31.72.1 dev eth0
>> 172.31.64.0/24 <http://172.31.64.0/24> dev eth1 proto kernel
>> scope link src 172.31.64.250
>> 172.31.72.0/24 <http://172.31.72.0/24> dev eth0 proto kernel
>> scope link src 172.31.72.250
>>
>> *root at ip-172-31-72-250:~# ip route show table 2*
>> default via 172.31.72.1 dev eth0 proto static metric 100
>>
>> *root at ip-172-31-72-250:~# ip route list table 100*
>> default dev lispTun0 proto static metric 100
>>
>> In the logs I see that xTR registers successfully in MS
>>
>> [2017/2/10 14:16:16] DEBUG: *Map-Register* -> flags:PirM
>> record-count: 1 nonce f8184f415bbddbf8, EID: (IID 13001/32,
>> EID 172.31.64.0/24 <http://172.31.64.0/24>), MS: 172.31.55.142
>> [2017/2/10 14:16:16] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.55.142 UDP: 4342 -> 4342
>> [2017/2/10 14:16:16] DEBUG: Sent Map-Register for mapping
>> (IID 13001/32, EID 172.31.64.0/24 <http://172.31.64.0/24>) to
>> 172.31.55.142
>> [2017/2/10 14:16:16] DEBUG: Received *Map-Notify*-> flags:ir,
>> record-count: 1, nonce F8184F415BBDDBF8, IP: 172.31.55.142 ->
>> 172.31.72.250, UDP: 4342 -> 4342
>> [2017/2/10 14:16:16] DEBUG: Mapping-record -> ttl: 10
>> loc-count: 1 action: no-action auth: 1 map-version: 0 eid:
>> (IID 13001/32, EID 172.31.64.0/24 <http://172.31.64.0/24>)
>> [2017/2/10 14:16:16] DEBUG: Locator-record -> flags:
>> L=1,p=0,R=1, p/w: 0/0 255/0, addr: 172.31.72.250
>> [2017/2/10 14:16:16] DEBUG: Map-Notify message confirms
>> correct registration of (IID 13001/32, EID
>> 172.31.64.0/24).Programing
>> <http://172.31.64.0/24%29.Programing> next Map-Register in 60
>> seconds
>>
>> And it seems probes among routers are working
>>
>> [2017/2/10 14:16:45] DEBUG: Received *Map-Request*->
>> flags:a=0,m=0,p=1,s=0,P=0,S=0, irc: 0 (+1), record-count: 1,
>> nonce: de54a1785bdfdfde, IP: 172.31.73.250 -> 172.31.72.250,
>> UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: itr-rloc: 172.31.73.250
>> [2017/2/10 14:16:45] DEBUG: dst-eid: (IID 13001/32, EID
>> 172.31.64.0/24 <http://172.31.64.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Sending *Map-Reply->
>> *flags:P=1,E=0,S=0,, record-count: 1, nonce: de54a1785bdfdfde
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.73.250 UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Received *Map-Request*->
>> flags:a=0,m=0,p=1,s=0,P=0,S=0, irc: 0 (+1), record-count: 1,
>> nonce: 909c4ae17fbddfdc, IP: 172.31.74.250 -> 172.31.72.250,
>> UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: itr-rloc: 172.31.74.250
>> [2017/2/10 14:16:45] DEBUG: dst-eid: (IID 13001/32, EID
>> 172.31.64.0/24 <http://172.31.64.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Sending *Map-Reply->*
>> flags:P=1,E=0,S=0,, record-count: 1, nonce: 909c4ae17fbddfdc
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.74.250 UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.74.250 UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Map-Request Probe for locator
>> 172.31.74.250 and EID: (IID 13003/32, EID 172.31.66.0/24
>> <http://172.31.66.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.75.250 UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Map-Request Probe for locator
>> 172.31.75.250 and EID: (IID 13004/32, EID 172.31.67.0/24
>> <http://172.31.67.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.73.250 UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Map-Request Probe for locator
>> 172.31.73.250 and EID: (IID 13002/32, EID 172.31.65.0/24
>> <http://172.31.65.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Received Map-Reply->
>> flags:P=1,E=0,S=0,, record-count: 1, nonce: bb6a4e6c5bbdebff,
>> IP: 172.31.75.250 -> 172.31.72.250, UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Mapping-record -> ttl: 10
>> loc-count: 1 action: no-action auth: 1 map-version: 0 eid:
>> (IID 13004/32, EID 172.31.67.0/24 <http://172.31.67.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Locator-record -> flags:
>> L=1,p=1,R=1, p/w: 0/0 255/0, addr: 172.31.75.250
>> [2017/2/10 14:16:45] DEBUG: Successfully probed RLOC
>> 172.31.75.250 of cache entry with EID (IID 13004/32, EID
>> 172.31.67.0/24 <http://172.31.67.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Received Map-Reply->
>> flags:P=1,E=0,S=0,, record-count: 1, nonce: baca416c5bbfcbff,
>> IP: 172.31.74.250 -> 172.31.72.250, UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Mapping-record -> ttl: 10
>> loc-count: 1 action: no-action auth: 1 map-version: 0 eid:
>> (IID 13003/32, EID 172.31.66.0/24 <http://172.31.66.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Locator-record -> flags:
>> L=1,p=1,R=1, p/w: 0/0 255/0, addr: 172.31.74.250
>> [2017/2/10 14:16:45] DEBUG: Successfully probed RLOC
>> 172.31.74.250 of cache entry with EID (IID 13003/32, EID
>> 172.31.66.0/24 <http://172.31.66.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Received Map-Reply->
>> flags:P=1,E=0,S=0,, record-count: 1, nonce: e8b94e6c5bbdfbed,
>> IP: 172.31.73.250 -> 172.31.72.250, UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: Mapping-record -> ttl: 10
>> loc-count: 1 action: no-action auth: 1 map-version: 0 eid:
>> (IID 13002/32, EID 172.31.65.0/24 <http://172.31.65.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Locator-record -> flags:
>> L=1,p=1,R=1, p/w: 0/0 255/0, addr: 172.31.73.250
>> [2017/2/10 14:16:45] DEBUG: Successfully probed RLOC
>> 172.31.73.250 of cache entry with EID (IID 13002/32, EID
>> 172.31.65.0/24 <http://172.31.65.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Received *Map-Request*->
>> flags:a=0,m=0,p=1,s=0,P=0,S=0, irc: 0 (+1), record-count: 1,
>> nonce: 730b72c2599dcb7f, IP: 172.31.75.250 -> 172.31.72.250,
>> UDP: 4342 -> 4342
>> [2017/2/10 14:16:45] DEBUG: itr-rloc: 172.31.75.250
>> [2017/2/10 14:16:45] DEBUG: dst-eid: (IID 13001/32, EID
>> 172.31.64.0/24 <http://172.31.64.0/24>)
>> [2017/2/10 14:16:45] DEBUG: Sending *Map-Reply*->
>> flags:P=1,E=0,S=0,, record-count: 1, nonce: 730b72c2599dcb7f
>> [2017/2/10 14:16:45] DEBUG: Sent control message IP:
>> 172.31.72.250 -> 172.31.75.250 UDP: 4342 -> 4342
>>
>> Full log is attached
>>
>> Thanks a lot!!
>> JM
>>
>>
>> El vie., 10 feb. 2017 a las 5:44, Albert López
>> (<alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>>) escribió:
>>
>> Hi José Miguel,
>>
>> Could you send us your configuration files and log files?
>> Also it will be interesting to see ifconfig, ip route, ip
>> rule, ip route show table #.
>> By the way, do you have configured a gateway for your
>> rloc interface?
>>
>> Best regards
>>
>> Albert
>>
>>
>>
>>
>> On 10/02/17 09:20, José Miguel Guzmán wrote:
>>> Hi
>>>
>>> I am very close to make OOR work in Ubuntu... but
>>> probably I need some little help :)
>>>
>>> I have 4 xTR nodes R{1..4}, with LAN{1..4} as EIDs and
>>> interconnected among them with WAN{1..4} as RLOCs
>>>
>>> If I try to ping LAN4 from LAN1, I see packets being
>>> received by lispTun0, but they don´t go anywhere :(
>>> So, from R1, I am doing
>>> *ping -I 172.31.64.250 172.31.67.250
>>> *
>>>
>>> after what I see the packets in the tunnel:
>>> *tcpdump -ilispTun0 -n -nn*
>>> 07:54:50.104742 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 222, length 64
>>> 07:54:51.104745 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 223, length 64
>>> 07:54:52.104721 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 224, length 64
>>> 07:54:53.104761 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 225, length 64
>>> 07:54:54.104746 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 226, length 64
>>> 07:54:55.104748 ip: 172.31.64.250 > 172.31.67.250
>>> <http://172.31.67.250>: ICMP echo request, id 12847, seq
>>> 227, length 64
>>>
>>> This is how lispTun0 looks like
>>>
>>> lispTun0 Link encap:UNSPEC HWaddr
>>> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>> UP POINTOPOINT RUNNING MTU:1440 Metric:1
>>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>> TX packets:350 errors:0 dropped:0 overruns:0
>>> carrier:0
>>> collisions:0 txqueuelen:500
>>> RX bytes:0 (0.0 B) TX bytes:29400 (29.4 KB)
>>>
>>> I wonder how lispTun0 connects to the other routers?
>>> In some tunneling examples, I see the PtP information in
>>> ifconfig..
>>> inet addr:10.0.0.1 P-t-P:10.0.0.2
>>> Mask:255.255.255.252
>>>
>>> but here, I don´t see those parameters
>>> ip tunnel show doesnt return anything
>>>
>>> What am I missing?
>>>
>>> Thanks! I love the project!!
>>>
>>> JM
>>>
>>> --
>>>
>>> *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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170214/e00e0227/attachment-0001.html>
More information about the Users
mailing list