from:"José Miguel Guzmán"

[OOR-Users] Segmentation Fault

2017-02-14 Thread José Miguel Guzmán

Hi

I think I understand the configuration of OOR much better now, but I
realized that OOR is crashing (about every 30m)

Las lines in log
[2017/2/14 22:31:45] DEBUG: Map-Register -> flags:PirM record-count: 1
nonce d627d5dc7cefafd7, EID: (IID 13000/32, EID 192.168.1.0/24), MS:
192.168.200.100
[2017/2/14 22:31:45] DEBUG: Sent control message IP: 192.168.123.90 ->
192.168.200.100 UDP: 4342 -> 4342
[2017/2/14 22:31:45] DEBUG: Sent Map-Register for mapping (IID 13000/32,
EID 192.168.1.0/24) to 192.168.200.100
[2017/2/14 22:31:45] DEBUG: Received Map-Notify-> flags:ir, record-count:
1, nonce D627D5DC7CEFAFD7, IP: 192.168.200.100 -> 192.168.123.90, UDP: 4342
-> 4342
[2017/2/14 22:31:45] DEBUG:   Mapping-record -> ttl: 10 loc-count: 1
action: no-action auth: 1 map-version: 0 eid: (IID 13000/32, EID
192.168.1.0/24)
[2017/2/14 22:31:45] DEBUG: Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-re, p/w: 1/100 255/0r

and then
Segmentation fault

The only non-debug message in the logs are:
 Re-Register and send SMRs for mappings with updated RLOCs 
[2017/2/14 22:24:2] ERR: LMAPI: Error while ZMQ receiving: Resource
temporarily unavailable
[2017/2/14 22:24:2] ERR: oor_api_loop: Error while trying to retrieve API
packet

What kind of information would be useful to collect, to be able to
troubleshoot?

I am running in openwrt over armv7l
Linux turris 4.4.39-80079e1c1e5f9ca7ad734044462a761a-4 #1 SMP Wed Jan 25
14:26:49 CET 2017 armv7l n

Config is


*# cat /etc/config/oor |egrep -v "^#|^ *$"*
package 'oor'
config 'daemon'
option  'debug' '1'
option  'log_file'  '/tmp/oor.log'
option  'map_request_retries'   '2'
option  'operating_mode''xTR'
config 'rloc-probing'
option  'rloc_probe_interval'   '5'
option  'rloc_probe_retries''2'
option  'rloc_probe_retries_interval'   '2'
config 'map-resolver'
list  'address'   '192.168.200.100'
config 'nat-traversal'
option  'nat_traversal_support' 'off'
config 'map-server'
option   'address'  '192.168.200.100'
option   'key_type' '1'
option   'key'  'yunque'
option   'proxy_reply'  'on'
config 'database-mapping'
option   'eid_prefix'   '192.168.1.0/24'
option   'iid'  '13000'
option   'rloc_set' 'yunque'
config 'proxy-itr'
config 'rloc-set'
option   'name' 'yunque'
list 'rloc_name''wan'
config 'rloc-iface'
option   'name' 'wan'
option   'interface''eth1'
option   'ip_version'   '4'
option   'priority' '1' # Priority of IPv4 locator
of the interface eth0 for this EID
option   'weight'   '100'   # Weight of IPv4 locator of
the interface eth0 for this EID


Thanks a lot
JM
-- 

*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

Re: [OOR-Users] Segmentation Fault

2017-02-14 Thread José Miguel Guzmán

I see that it is crashing every 12 minutes

2017-02-15T01:19:44-03:00 notice oor[]: Starting Open Overlay Router
2017-02-15T01:31:45-03:00 notice oor[]: Open Overlay Router Stopped

2017-02-15T02:42:56-03:00 notice oor[]: Starting Open Overlay Router
2017-02-15T02:54:57-03:00 notice oor[]: Open Overlay Router Stopped

and same identical last line
[2017/2/14 23:54:57] DEBUG: Received Map-Notify-> flags:ir, record-count:
1, nonce 4035E665FF3C305, IP: 192.168.200.100 -> 192.168.123.90, UDP: 4342
-> 4342
[2017/2/14 23:54:57] DEBUG:   Mapping-record -> ttl: 10 loc-count: 1
action: no-action auth: 1 map-version: 0 eid: (IID 13000/32, EID
192.168.1.0/24) <http://192.168.1.0/24)%5B2017/2/14>
[2017/2/14 23:54:57] DEBUG: Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record ->
flags: L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-re, p/w: 1/100 255/0

El mar., 14 feb. 2017 a las 23:47, José Miguel Guzmán (<
jmguz...@whitestack.com>) escribió:

Hi

I think I understand the configuration of OOR much better now, but I
realized that OOR is crashing (about every 30m)

Las lines in log
[2017/2/14 22:31:45] DEBUG: Map-Register -> flags:PirM record-count: 1
nonce d627d5dc7cefafd7, EID: (IID 13000/32, EID 192.168.1.0/24), MS:
192.168.200.100
[2017/2/14 22:31:45] DEBUG: Sent control message IP: 192.168.123.90 ->
192.168.200.100 UDP: 4342 -> 4342
[2017/2/14 22:31:45] DEBUG: Sent Map-Register for mapping (IID 13000/32,
EID 192.168.1.0/24) to 192.168.200.100
[2017/2/14 22:31:45] DEBUG: Received Map-Notify-> flags:ir, record-count:
1, nonce D627D5DC7CEFAFD7, IP: 192.168.200.100 -> 192.168.123.90, UDP: 4342
-> 4342
[2017/2/14 22:31:45] DEBUG:   Mapping-record -> ttl: 10 loc-count: 1
action: no-action auth: 1 map-version: 0 eid: (IID 13000/32, EID
192.168.1.0/24)
[2017/2/14 22:31:45] DEBUG: Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-record -> flags:
L=1,p=0,Locator-record -> flags: L=1,p=0,Locator-re, p/w: 1/100 255/0r

and then
Segmentation fault

The only non-debug message in the logs are:
 Re-Register and send SMRs for mappings with updated RLOCs 
[2017/2/14 22:24:2] ERR: LMAPI: Error while ZMQ receiving: Resource
temporarily unavailable
[2017/2/14 22:24:2] ERR: oor_api_loop: Error while trying to retrieve API
packet

What kind of information would be useful to collect, to be able to
troubleshoot?

I am running in openwrt over armv7l
Linux turris 4.4.39-80079e1c1e5f9ca7ad734044462a761a-4 #1 SMP Wed Jan 25
14:26:49 CET 2017 armv7l n

Config is


*# cat /etc/config/oor |egrep -v "^#|^ *$"*
package 'oor'
config 'daemon'
option  'debug' '1'
option  'log_file'  '/tmp/oor.log'
option  'map_request_retries'   '2'
option  'operating_mode''xTR'
config 'rloc-probing'
option  'rloc_probe_interval'   '5'
option  'rloc_probe_retries''2'
option  'rloc_probe_retries_interval'   '2'
config 'map-resolver'
list  'address'   '192.168.200.100'
config 'nat-traversal'
option  'nat_traversal_support' 'off'
config 'map-server'
option   'address'  '192.168.200.100'
option   'key_type' '1'
option   'key'  'yunque'
option   'proxy_reply'  'on'
config 'database-mapping'
option   'eid_prefix'   '192.168.1.0/24'
option   'iid'  '13000'
option   'rloc_set' 'yunque'
config 'proxy-itr'
config 'rloc-set'
option   'name' 'yunque'
list 'rloc_name''wan'
config 'rloc-iface'
option   'name' 'wan'
option   'interface''eth1'

Re: [OOR-Users] Segmentation Fault

2017-02-14 Thread José Miguel Guzmán


Hi

It parsed the config file, that is in /etc/config/oor, I could see in 
the log lines like


[2017/2/15 2:54:7] WARNING: Rights: Effective [4294967295] Permitted  
[4294967295]

[2017/2/15 2:54:7] INFO: Building address to interface hash table
[2017/2/15 2:54:7] INFO: Control created!
[2017/2/15 2:54:7] DEBUG: Creating map cache and local mapping database
[2017/2/15 2:54:7] DEBUG: Finished Constructing xTR
[2017/2/15 2:54:7] INFO: Device working in mode xTR registering with control
[2017/2/15 2:54:7] DEBUG: bind_socket: Binded socket 5 to source address 
192.168.123.90 and port 0 with afi 2
[2017/2/15 2:54:7] DEBUG: add_rule: Add rule -> Send packets with source 
address 192.168.123.90 and destination address _NULL_ to the table 3 
with priority 3.

[2017/2/15 2:54:7] DEBUG: RLOC Probing Interval: 30
[2017/2/15 2:54:7] DEBUG: Added 192.168.200.100 to map-resolver list
[2017/2/15 2:54:7] DEBUG: Added 192.168.200.100 to map-server list
[2017/2/15 2:54:7] DEBUG: Balancing locator vector for (IID 13000/32, 
EID 192.168.1.0/24):
[2017/2/15 2:54:7] DEBUG:   IPv4 locators vector (1 locators): 
192.168.123.90

[2017/2/15 2:54:7] DEBUG:   IPv6 locators vector (0 locators):
[2017/2/15 2:54:7] DEBUG:   IPv4 & IPv6 locators vector (0 locators):
[2017/2/15 2:54:7] DEBUG: Added EID prefix (IID 13000/32, EID 
192.168.1.0/24) in the database.

[2017/2/15 2:54:7] DEBUG: Balancing locator vector for 0.0.0.0/32:
[2017/2/15 2:54:7] DEBUG:   IPv4 locators vector (0 locators):
[2017/2/15 2:54:7] DEBUG:   IPv6 locators vector (0 locators):
[2017/2/15 2:54:7] DEBUG:   IPv4 & IPv6 locators vector (0 locators):
[2017/2/15 2:54:8] DEBUG: TUN/TAP mtu set to 1440
[2017/2/15 2:54:8] DEBUG: TUN interface UP.
[2017/2/15 2:54:8] DEBUG: add_route: added route to the system: src 
addr: -, dst prefix:-, gw: -, table: 100
[2017/2/15 2:54:8] DEBUG: add_route: added route to the system: src 
addr: -, dst prefix:-, gw: -, table: 100
[2017/2/15 2:54:8] DEBUG: bind_socket: Binded socket 8 to source address 
_NULL_ and port 4341 with afi 2
[2017/2/15 2:54:8] DEBUG: bind_socket: Binded socket 10 to source 
address _NULL_ and port 4341 with afi 10


Actually, oor ran for about 10 mins, before dying

I am using it as a xTR, and there is no interface config item (although 
it is required for the MS and RTR modes)


Thanks for your help (and your comment about gdb.. It is a very exciting 
utility)







El 15/02/2017 a las 3:36 AM, Florin Coras escribió:

I’d say you’re doing pretty well for a first time gdb user ;-)

I’m guessing: p interface_list returns 0, so it looks like OOR has no 
interfaces configured. I’m guessing it started without parsing the 
config file. Try something like:


sudo gdb --args $binary -f $config_file

Cheers,
Florin

On Feb 14, 2017, at 10:16 PM, José Miguel Guzmán 
<jmguz...@whitestack.com <mailto:jmguz...@whitestack.com>> wrote:


Great, I didn´t know about how to hable SIG35 (first time using gdb

I saw several logs like these
[2017/2/15 3:13:3] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:4] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:5] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:6] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:7] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:8] WARNING: write signal 35: Bad file descriptor
[2017/2/15 3:13:9] WARNING: write signal 35: Bad file descriptor


And finally:

[2017/2/15 3:13:30] DEBUG: Sending Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,Map-Reply-> 
flags:P=1,E=0,S=0,Map-Reply-> flags:P=1,E=0,S=0,ecord-count: 1, 
nonce: 9473ea437bfbf19e


*Program received signal SIGSEGV, Segmentation fault.*
0x0003e8a4 in get_interface_with_address 
(address=address@

Re: [OOR-Users] Segmentation Fault

2017-02-14 Thread José Miguel Guzmán

I have been trying to run it under gdb, but I am not sure if I am doing it
correctly

When running in gdb, it fails immediately (not the same when running w/o
gdb)

With gdb:
*# rm /var/run/oor.pid; gdb --directory /root/oor-1.1.1/oor /usr/sbin/oor*

[2017/2/15 2:58:55] WARNING: No Proxy-ETR defined. Packets to non-LISP
destinations will be forwarded natively (no LISP encapsulation). This may
prevent mobility in some scenarios.

Program received signal SIG35, Real-time event 35.
0xb6fd41a4 in __clone () from /lib/ld-musl-armhf.so.1
(gdb) bt full
#0  0xb6fd41a4 in __clone () from /lib/ld-musl-armhf.so.1
No symbol table info available.
#1  0xb6fd4ec8 in ?? () from /lib/ld-musl-armhf.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I am not sure if this is what you need.

El mié., 15 feb. 2017 a las 2:37, Lori Jakab (<lorand.ja...@gmail.com>)
escribió:

> On Wed, Feb 15, 2017 at 4:47 AM, José Miguel Guzmán <
> jmguz...@whitestack.com> wrote:
>
> Hi
>
> I think I understand the configuration of OOR much better now, but I
> realized that OOR is crashing (about every 30m)
>
>
> [...]
>
>
>
> What kind of information would be useful to collect, to be able to
> troubleshoot?
>
>
> Is it possible to start OOR under gdb on OpenWrt? In that case, when the
> segmentation fault occurs you can get a backtrace, which would show the
> call graph causing the crash.
>
> -Lori
>
-- 

*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

[OOR-Users] lispTun0 going nowhere...

2017-02-10 Thread José Miguel Guzmán

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: ICMP echo request, id
12847, seq 222, length 64
07:54:51.104745 ip: 172.31.64.250 > 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: ICMP echo request, id
12847, seq 224, length 64
07:54:53.104761 ip: 172.31.64.250 > 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: ICMP echo request, id
12847, seq 226, length 64
07:54:55.104748 ip: 172.31.64.250 > 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 <+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

[OOR-Users] LMAPI: Error while ZMQ receiving: Resource temporarily unavailable

2017-05-18 Thread José Miguel Guzmán

Hi

I am getting this error in OpenWRT

[2017/5/18 13:59:13] ERR: LMAPI: Error while ZMQ receiving: Resource
temporarily unavailable
[2017/5/18 13:59:13] ERR: oor_api_loop: Error while trying to retrieve API
packet
[2017/5/18 14:5:45] ERR: LMAPI: Error while ZMQ receiving: Resource
temporarily unavailable
[2017/5/18 14:5:45] ERR: oor_api_loop: Error while trying to retrieve API
packet
[2017/5/18 14:12:22] ERR: LMAPI: Error while ZMQ receiving: Resource
temporarily unavailable
[2017/5/18 14:12:22] ERR: oor_api_loop: Error while trying to retrieve API
packet

This produces traffic drop (ie, packets are not forwarded from the tunnel
to the external interface, when this happens)

I am using

root@cpe3:~# uname -a
Linux cpe3 4.4.59-627f0117679bc72ef5e58881035f567a-4 #1 SMP Mon Apr 24
14:05:28 CEST 2017 armv7l n
root@cpe3:~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='Chaos Calmer'
DISTRIB_REVISION='r47055'
DISTRIB_CODENAME='omnia'
DISTRIB_TARGET='mvebu/generic'
DISTRIB_DESCRIPTION='OpenWrt omnia 15.05'
DISTRIB_TAINTS='busybox'
root@cpe3:~#

Any clue about where should I take a look?

JM

-- 

*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

Re: [OOR-Users] Prefix expiration dropping traffic

2017-06-09 Thread José Miguel Guzmán

Thanks Albert

I forgot to mention I changed that timer some time ago, to deal with the
fact that when one xTR changed its RLOC, it took up to 10m to get the other
xTRs to notice it. But did not realize this side effect.
I reverted to 10m, and I see the same behavior (though with larger interval)

[2017/6/9 16:27:28] DEBUG: Got expiration for EID 192.168.101.0/24
[2017/6/9 16:27:29] DEBUG: No map cache for EID 192.168.101.1. Sending
Map-Request!
[2017/6/9 16:27:29] DEBUG: The map cache entry of EID 192.168.101.0/24 will
expire in 10 minutes.

[2017/6/9 16:37:28] DEBUG: Got expiration for EID 192.168.101.0/24
[2017/6/9 16:37:30] DEBUG: No map cache for EID 192.168.101.1. Sending
Map-Request!
[2017/6/9 16:37:30] DEBUG: The map cache entry of EID 192.168.101.0/24 will
expire in 10 minutes.

[2017/6/9 16:47:29] DEBUG: Got expiration for EID 192.168.101.0/24
[2017/6/9 16:47:31] DEBUG: No map cache for EID 192.168.101.1. Sending
Map-Request!
[2017/6/9 16:47:31] DEBUG: The map cache entry of EID 192.168.101.0/24 will
expire in 10 minutes.

JM

El vie., 9 jun. 2017 a las 3:33, Albert López (<alo...@ac.upc.edu>)
escribió:

> Dear José,
>
> The expiration time is defined by TTL. This is a hard coded parameter that
> is defined by DEFAULT_DATA_CACHE_TTL (defs.h) and is used in
> mapping_record_init_hdr(lisp_message_fields.c) . We usually set this value
> to 10 (10 minutes). I don't know why you have 1, may be I sent to you a
> testing version. In a future we would like to add this parameter in the
> configuration file but we don't have it yet.
>
> Best regards
>
> Albert
>
>
> El 09/06/17 a les 00:08, José Miguel Guzmán ha escrit:
>
> Hi All
>
> We realized that every minute, we are dropping traffic packets due to
> expiration of the destination prefix, and time required to update the entry
> form server (couple of seconds)
>
> *[2017/6/8 18:53:48] DEBUG: Got expiration for EID 192.168.102.0/24
> <http://192.168.102.0/24>*
>
> *[2017/6/8 18:53:49] DEBUG: No map cache for EID 192.168.102.168. Sending
> Map-Request! *
> [2017/6/8 18:53:49] DEBUG-2: lisp_addr_get_ip_pref_addr: Not applicable to
> ip addressess
> [2017/6/8 18:53:49] DEBUG: Balancing locator vector for 192.168.102.168/32
> :
> [2017/6/8 18:53:49] DEBUG:   IPv4 locators vector (0 locators):
> [2017/6/8 18:53:49] DEBUG:   IPv6 locators vector (0 locators):
> [2017/6/8 18:53:49] DEBUG:   IPv4 & IPv6 locators vector (0 locators):
> [2017/6/8 18:53:49] DEBUG: locators for req: 172.16.60.8
> [2017/6/8 18:53:49] DEBUG: Map-Request-> flags:a=0,m=0,p=0,s=0,P=0,S=0,
> irc: 0 (+1), record-count: 1, nonce: 78627d755, itr-rlocs:172.16.60.8,
> src-eid: 192.168.101.1, req-eid: 192.168.102.168/32
> [2017/6/8 18:53:49] DEBUG-2: lisp_addr_get_ip_addr: Not applicable to
> prefixes
> [2017/6/8 18:53:49] DEBUG: ECM -> flags:s, inner IP: 192.168.101.1 ->
> 192.168.102.168/32, inner UDP: 4342 -> 4342
> [2017/6/8 18:53:49] DEBUG: Sent control message IP: 172.16.60.8 ->
> 172.16.60.194 UDP: 4342 -> 4342
> *[2017/6/8 18:53:49] DEBUG: Received Map-Reply-> flags:P=0,E=0,S=0,
> record-count: 1, nonce: 78627d75597fe77d, IP: 192.168.123.75 ->
> 172.16.60.8, UDP: 4342 -> 4342*
> [2017/6/8 18:53:49] DEBUG:   Mapping-record -> ttl: 1 loc-count: 1 action:
> no-action auth: 0 map-version: 0 eid: 192.168.102.0/24
> [2017/6/8 18:53:49] DEBUG: Locator-record -> flags: L=1,p=0,R=1, p/w:
> 1/100 255/0, addr: 172.16.60.9
> [2017/6/8 18:53:49] DEBUG-2: mapping_get_locators_with_afi: List for OOR
> AFI 1 and afi 2 not yet created
> [2017/6/8 18:53:49] DEBUG-2: mapping_add_locator: Added locator
> 172.16.60.9 to the mapping with EID 192.168.102.0/24.
> [2017/6/8 18:53:49] DEBUG-2: mapping_get_locators_with_afi: List for OOR
> AFI 3 and afi 10 not yet created
> [2017/6/8 18:53:49] DEBUG: Balancing locator vector for 192.168.102.0/24:
> [2017/6/8 18:53:49] DEBUG:   IPv4 locators vector (1 locators):
> 172.16.60.9
> [2017/6/8 18:53:49] DEBUG:   IPv6 locators vector (0 locators):
> [2017/6/8 18:53:49] DEBUG:   IPv4 & IPv6 locators vector (0 locators):
> *[2017/6/8 18:53:49] DEBUG: The map cache entry of EID 192.168.102.0/24
> <http://192.168.102.0/24> will expire in 1 minutes.*
> [2017/6/8 18:53:49] DEBUG-2: Programming probing of EID's 192.168.102.0/24
> locator 172.16.60.9 (30 seconds)
>
> I am not sure if I am doing something wrong.. (probably :))
>
> Is there any way to handle this transparently? For instance, have xTR
> refreshing prefixes 5secs before expiration, so, traffic is not interrupted?
> Are these expiration timers, configurable? I only see that rloc-probing
> timers are tunable.
>
> Thanks!
> JM
>
>
>
>
> --
>
>
> *José Miguel Guzmán *Senior Network Consultant
> Latin Ameri

[OOR-Users] Segmentation Fault

Re: [OOR-Users] Segmentation Fault

Re: [OOR-Users] Segmentation Fault

Re: [OOR-Users] Segmentation Fault

[OOR-Users] lispTun0 going nowhere...

[OOR-Users] LMAPI: Error while ZMQ receiving: Resource temporarily unavailable

Re: [OOR-Users] Prefix expiration dropping traffic

7 matches

Site Navigation

Mail list logo

Footer information