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 > >
