Re: [LISPmob-users] lispmob xtr router on linux

[Albert López]

Hi Artur,

Which platform are you using? We have detected an issue when using 
LISPmob in openWRT with multihoming. It seems that the system is not 
able to detect interface changes when the change is produced in the port 
configured as a WAN port in the LAN switch of the router (using VLANs).  
Changes of the real wan port are correctly detected. We are trying to 
find a solution to this issue.
When the node is configured in a linux box (mobile node or XTR), it 
should work and detect interface changes: interface UP/DOWN and change 
of address.

 * Priority_v4: LISPmob uses the IPv4 address assigned to the interface
   indicated in the database mapping as a locator. Priority_v4 assigns
   the priority of this locator.
 * Priority_v6: LISPmob uses the first global IPv6 address assigned to
   the interface indicated in the database mapping as a locator.
   Priority_v6 assigns the priority of this locator

If priority_vX is equal to -1, then the IPvX address is not used as a 
locator.

LISPmob doesn't maintain state of the connections. If no change is 
produced, a flow (5 tuple traffic identifier) will always use the same 
output and destination locators. When a change is produced in a locator, 
the vector of locators used to balance the traffic is recalculated and 
new locators can be assigned to this flow, this could happen even if the 
previous locators used by the flow has not been affected by any change.

You could find more details of priority and weight in the page 33 of the 
lisp RFC6830. <http://tools.ietf.org/html/rfc6830>

A peculiarity of the implementation of LISPmob is that we overload the 
use of priority and weight parameters. A part from the use that is 
specified in the RFC for this parameters, we also use them to specify 
how we send the outgoing traffic of our node through its interfaces.

Please, let us know if you are using an openWRT router or a linux box. 
If you are using a linux box, we will need extra information as the 
operatin system and  your logs in debug 3

Regards

Albert




On 05/28/2013 05:56 PM, Artur Skonecki wrote:
The issue is not longer present and the xtr is working fine now.
Probably some kind glitch with my setup :)

I was testing how does lispd behave after turning off one of the
multihomed interfaces.
It seems that so far lispd is not capable of dealing with such events
during runtime.
What is the communication with different lisp sites after runtime RLOC changes?

What is the purpose of priority_v4, priority_v6 options?

Regards,
Artur

On 24 May 2013 09:40, Albert López<alo...@ac.upc.edu>  wrote:
Hello Artur,

You should be able to see them, at least we are able to see them when using
wireshark.
Could you provide some more information? Are you using linux or openWRT
router? Which Operating System?
Apart from not being able to see the pakets with tcpdump, other things work
well?

Regards

Albert

On 05/23/2013 05:01 PM, Artur Skonecki wrote:
Thanks, your explanations have clarified a lot!

xTR is working as expected, however, I've observed
unexpected pattern while watching interfaces on xTR with tcpdump.
Outgoing icmp packets are visible only on eth0.
Incoming icmp packets are visible only on lispTun0.
Is this an expected behavior?


My setup looks like this:

Internet --- eth0 XTR eth1 (153.16.49.225/28) --- NODE (153.16.49.226/28)

I am including tcpdump logs:

---------- pinging 8.8.8.8 from NODE
root@NODE:~# ping -c1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=38 time=109 ms

--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 109.785/109.785/109.785/0.000 ms

root@XTR:/etc# sudo tcpdump -nvvXSs 0 -i lispTun0 icmp
tcpdump: listening on lispTun0, link-type RAW (Raw IP), capture size 65535
bytes
14:25:44.027523 IP (tos 0x0, ttl 39, id 0, offset 0, flags [none],
proto ICMP (1), length 84)
      8.8.8.8 > 153.16.49.226: ICMP echo reply, id 20619, seq 1, length 64
          0x0000:  4500 0054 0000 0000 2701 b8a7 0808 0808
E..T....'.......
          0x0010:  9910 31e2 0000 f707 508b 0001 eb27 9e51
..1.....P....'.Q
          0x0020:  3def 0600 0809 0a0b 0c0d 0e0f 1011 1213
=...............
          0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
.............!"#
          0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
$%&'()*+,-./0123
          0x0050:  3435 3637 0000 0000 0000 0000 0000 0000
4567............
          0x0060:  0000 0000 0000 0000

root@XTR:~# sudo tcpdump -nvvXSs 0 -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
14:25:43.917970 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto
ICMP (1), length 84)
      153.16.49.226 > 8.8.8.8: ICMP echo request, id 20619, seq 1, length
64
          0x0000:  4500 0054 0000 4000 3f01 60a7 9910 31e2
E..T..@.?.`...1.
          0x0010:  0808 0808 0800 ef07 508b 0001 eb27 9e51
........P....'.Q
          0x0020:  3def 0600 0809 0a0b 0c0d 0e0f 1011 1213
=...............
          0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
.............!"#
          0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
$%&'()*+,-./0123
          0x0050:  3435 3637

---------- pinging NODE from EXTERNAL-HOST

EXTERNAL-HOST% ping -c1 153.16.49.226
PING 153.16.49.226 (153.16.49.226): 56 data bytes
64 bytes from 153.16.49.226: icmp_seq=0 ttl=57 time=180.585 ms

--- 153.16.49.226 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 180.585/180.585/180.585/0.000 ms


root@XTR:/etc# sudo tcpdump -nvvXSs 0 -i lispTun0 icmp
tcpdump: listening on lispTun0, link-type RAW (Raw IP), capture size 65535
bytes
14:10:09.411026 IP (tos 0x0, ttl 39, id 4417, offset 0, flags [none],
proto ICMP (1), length 84)
      194.29.146.3 > 153.16.49.226: ICMP echo request, id 17243, seq 0,
length 64
          0x0000:  4500 0054 1141 0000 2701 6355 c21d 9203
E..T.A..'.cU....
          0x0010:  9910 31e2 0800 f6c5 435b 0000 519e 2349
..1.....C[..Q.#I
          0x0020:  0000 5df4 0809 0a0b 0c0d 0e0f 1011 1213
..].............
          0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
.............!"#
          0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
$%&'()*+,-./0123
          0x0050:  3435 3637 0000 0000 0000 0000 0000 0000
4567............
          0x0060:  0000 0000 0000 0000

root@XTR:~# sudo tcpdump -nvvXSs 0 -i eth0 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
65535 bytes
14:10:09.411233 IP (tos 0x0, ttl 63, id 26807, offset 0, flags [none],
proto ICMP (1), length 84)
      153.16.49.226 > 194.29.146.3: ICMP echo reply, id 17243, seq 0,
length 64
          0x0000:  4500 0054 68b7 0000 3f01 f3de 9910 31e2
E..Th...?.....1.
          0x0010:  c21d 9203 0000 fec5 435b 0000 519e 2349
........C[..Q.#I
          0x0020:  0000 5df4 0809 0a0b 0c0d 0e0f 1011 1213
..].............
          0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223
.............!"#
          0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233
$%&'()*+,-./0123
          0x0050:  3435 3637


Regards,
Artur


--
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182