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! Alberto On 5 June 2013 17:06, Artur Skonecki <[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]> 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]> <[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) --- 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 >> >> >
