Hi Artur,We have been doing some tests in our lab with multihoming and skype. In the scenario we tested, we have a pc with several interfaces connected with LISPmob to the beta network and a second PC without using lisp. We establish a Skype connecton between them and start to play with interfaces: unplug and plug the network wire and ifdown and ifup of the interfaces. The results of the experiment has been successful. In your case, you are using wire and wireless interface. We have not been able to configure the network using this configuration. Linux doesn't allow us to configure a default route for the wireless interface and wired interface at the same time. Without these defaults routes, LISPmob doesn't work. Could you provide us some information in how you have configured your interfaces?
Best regards Albert L. On 06/06/2013 01:34 PM, Alberto Rodriguez-Natal wrote:
Hi Artur,We are going to test LISPmob multihoming with skype in order to try to reproduce that behavior. We'll get back to you ASAP.Meanwhile we'll appreciate all the information you can provide us. If possible send us those log files. We need the logs from LISPmob boot up till you start seeing the problems, don't worry for the verbosity. We would also like to get the pcap capture of the traffic. Both at the external interfaces and on lispTun0.Thanks! AlbertoOn 5 June 2013 17:06, Artur Skonecki <[email protected] <mailto:[email protected]>> wrote:Hi Albert, Thanks for the answer. I am running Voyage Linux. When pinging a host in the background, lispd (router) detects ifdown on wifi or ethernet interfaces and pinging continues. However, when there is a Skype video call and ping is running in the background, connection is not recovered after ifdown on xTR. When Skype call timeouts pinging `might` restart but it depends on whether it was ifdown wlan0 or ifdown eth0. I don't have logs right now but I can capture them if necessary (although they are quite verbose...:)). Regards, Artur On 29 May 2013 09:53, Albert López <[email protected] <mailto:[email protected]>> wrote: 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<[email protected]> <mailto:[email protected]> 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 <http://153.16.49.225/28>) --- NODE (153.16.49.226/28 <http://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 from8.8.8.8 <http://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 <http://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 <http://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 from153.16.49.226 <http://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 <http://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 <http://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
