-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Albert
Thanks for the response. Sounds great. I tried yesterday, as a last resort, to remove the intouch-pxtr-2 (and intouch-pxtr-1 based on gut feeling :p) and it works currently with those PITR's removed. Let me know if I should put them back in again if the Cisco LISP team need it so the problem can be debugged while it is happening. As for the IPv4 PiTR's in the configuration, they are commented out. I just included them for you to see that they were actually disabled. I should probably have written explicitly that they were disabled/commented out - the #'s are easy to overlook I guess :) Best regards Dennis Glindhart On 20-10-2014 12:05, Albert López wrote: > Hi Dennis, > > Thanks for your detailed email, it is very helpful. For the > information you have provided, it seems that it may be a > misconfiguration in the intouch-pxtr-2. I will forward your mail to > LISP Beta support in order to see if they could fix it. Regarding > the last point, if you only have IPv6 RLOCs, it doesn't have sense > to have the IPv4 PiTR in the configuration file. Usually PiTR > should have both, IPv4 and IPv6 RLOCs. In your case, the > notifications send by LISPmob to PiTR are sent to the IPv6 RLOCs of > the PiTR. > > Regards > > Albert > > > > On 18/10/14 15:22, Dennis Glindhart wrote: Hey > > After getting access to the LISP test network I'm doing some tests > and have come across a rather strange behavior I can't figure out > how to deal with. > > I have my LISPmob daemon running on a server with the EID loopback > address: 153.16.54.81 (part of LISP-subnet 153.16.54.80/28) > > - From a different/independent network, I then try to ping the > address > > [dennis@dennis ~]$ ping 153.16.54.81 PING 153.16.54.81 > (153.16.54.81) 56(84) bytes of data. - From 217.8.98.35 icmp_seq=1 > Time to live exceeded - From 217.8.98.35 icmp_seq=2 Time to live > exceeded > > Hmm.. Let's try a traceroute to see whats happening > > [dennis@dennis ~]$ traceroute 153.16.54.81 traceroute to > 153.16.54.81 (153.16.54.81), 30 hops max, 60 byte packets 1 > 192.168.1.1 (192.168.1.1) 1.253 ms 2.249 ms 2.539 ms 2 * * * 3 > ten4-3-130.frede-core-b-pe-02.profibernet.dk (87.104.248.138) 4.455 > ms 4.544 ms 4.821 ms 4 * * * 5 130.185.140.113 > (130.185.140.113) 7.361 ms 6.979 ms 7.651 ms 6 93.176.94.17 > (93.176.94.17) 17.599 ms 13.245 ms 13.508 ms 7 > ams-ix.intouch.net (80.249.208.93) 17.256 ms 17.570 ms 18.012 > ms 8 217.8.98.35 (217.8.98.35) 18.867 ms 19.076 ms 19.070 ms 9 > 217.8.98.34 (217.8.98.34) 18.815 ms 18.811 ms 16.525 ms 10 > 217.8.98.35 (217.8.98.35) 17.239 ms 18.065 ms 18.322 ms 11 > 217.8.98.34 (217.8.98.34) 17.029 ms 17.986 ms 18.280 ms 12 > 217.8.98.35 (217.8.98.35) 18.767 ms 18.587 ms 18.580 ms 13 > 217.8.98.34 (217.8.98.34) 16.155 ms 16.224 ms 16.794 ms 14 > 217.8.98.35 (217.8.98.35) 17.277 ms 18.307 ms 18.022 ms 15 > 217.8.98.34 (217.8.98.34) 17.367 ms 17.198 ms 17.192 ms 16 > 217.8.98.35 (217.8.98.35) 17.546 ms 38.616 ms 37.549 ms 17 > 217.8.98.34 (217.8.98.34) 17.018 ms 16.709 ms 17.319 ms 18 > 217.8.98.35 (217.8.98.35) 29.930 ms 29.637 ms 29.602 ms 19 > 217.8.98.34 (217.8.98.34) 17.952 ms 18.390 ms 17.772 ms 20 > 217.8.98.35 (217.8.98.35) 18.227 ms 17.284 ms 17.583 ms 21 > 217.8.98.34 (217.8.98.34) 17.189 ms 16.806 ms 17.091 ms 22 > 217.8.98.35 (217.8.98.35) 18.126 ms 18.520 ms 19.228 ms 23 > 217.8.98.34 (217.8.98.34) 17.547 ms 17.341 ms 17.030 ms 24 > 217.8.98.35 (217.8.98.35) 17.861 ms 17.804 ms 17.445 ms 25 > 217.8.98.34 (217.8.98.34) 18.353 ms 17.936 ms 18.274 ms 26 > 217.8.98.35 (217.8.98.35) 18.160 ms 17.980 ms 20.194 ms 27 > 217.8.98.34 (217.8.98.34) 17.007 ms 17.482 ms 17.504 ms 28 > 217.8.98.35 (217.8.98.35) 17.205 ms 17.319 ms 17.507 ms 29 > 217.8.98.34 (217.8.98.34) 17.211 ms 17.409 ms 17.390 ms 30 > 217.8.98.35 (217.8.98.35) 39.866 ms 37.914 ms 37.534 ms > > It seems to loop at intouch-pxtr-2 (217.8.98.35) > > I've then tried a traceroute to another random participant in > LISP-test network (aflorio-it-xtr), and it seems to work fine > through the same PITR > > traceroute to 153.16.54.161 (153.16.54.161), 30 hops max, 60 byte > packets 1 192.168.1.1 (192.168.1.1) 3.749 ms 3.731 ms 3.730 ms > 2 * * * 3 ten4-3-130.frede-core-b-pe-02.profibernet.dk > (87.104.248.138) 7.430 ms 7.527 ms 7.629 ms 4 * * * 5 > 130.185.140.113 (130.185.140.113) 11.397 ms 11.746 ms 11.731 ms > 6 93.176.94.17 (93.176.94.17) 21.065 ms 13.108 ms 13.689 ms 7 > ams-ix.intouch.net (80.249.208.93) 16.829 ms 17.681 ms 17.697 > ms 8 217.8.98.35 (217.8.98.35) 18.720 ms 19.017 ms 19.023 ms 9 > * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 > aflorio-it-xtr.lisp4.net (153.16.54.161) 99.810 ms * * > > All previous pings and traceroutes has been run from Denmark, > which should be close to the intouch-pxtr-2 PITR which is located > in Amsterdam, Netherlands as far as I can see. > > I then figured I would try to see what happened going through > another PITR, so I then tried some Online traceroute/ping util to > test that would hit another PITR > (http://www.subnetonline.com/pages/network-tools/online-traceroute.php) > > traceroute to 153.16.54.81 (153.16.54.81), 30 hops max, 40 byte > packets 1 gw-v130.xl-is.net (141.138.203.1) 7.122 ms 7.138 ms > 7.350 ms 2 rt-eu01-v2.xl-is.net (79.170.92.19) 2.392 ms 2.439 ms > 2.543 ms 3 hurricane-electric.nikhef.nl-ix.net (193.239.116.14) > 1.399 ms 1.392 ms 1.364 ms 4 10ge9-7.core1.par2.he.net > (184.105.213.102) 20.423 ms 20.414 ms 20.436 ms 5 > 10ge15-1.core1.ash1.he.net (184.105.213.93) 90.688 ms 88.264 ms > 90.617 ms 6 10ge1-2.core1.atl1.he.net (184.105.213.110) 100.548 > ms 100.623 ms 100.718 ms 7 isc.gige-g2-1.core1.atl1.he.net > (216.66.0.50) 154.358 ms 153.600 ms 153.680 ms 8 > iana.r1.atl1.isc.org (199.6.12.1) 170.258 ms 154.135 ms 154.030 > ms 9 int-0-0-0-7.r1.pao1.isc.org (149.20.65.37) 154.327 ms > 154.248 ms 154.183 ms 10 int-0-0-1-0.r1.sql1.isc.org > (149.20.65.10) 157.563 ms 157.546 ms 157.520 ms 11 > isc-pxtr.rloc.lisp4.net (149.20.48.60) 154.107 ms 154.284 ms > 154.556 ms 12 glindhart-xtr.lisp4.net (153.16.54.81) 174.397 ms > 174.035 ms 174.173 ms > > Then it works. So it seems that it works when going through some > PITR but not with others (intouch-pxtr-2) > > I only have a Public IPv6 address available on the server running > the LISPmob daemon, so I disabled the IPv4-itrs in /etc/lispd.conf > > # LISP beta-network IPv4 PITRs #proxy-itrs = { # > 69.31.31.98, # eqx-ash-pxtr # 149.20.48.60, > # isc-pxtr # 198.6.255.37, # asp-pxtr # > 173.36.193.25, # sjc-pxtr # 129.250.1.63, > # ntt-amer-pxtr # 217.8.98.33, # intouch-pxtr-1 # > 217.8.98.35, # intouch-pxtr-2 # 193.162.145.46, > # tdc-pxtr # 158.38.1.92, # uninett-pxtr # > 203.181.249.172, # apan-pxtr # 202.51.247.10 > # sg-nus-pxtr #} > > # LISP beta-network IPv6 PITRs proxy-itrs = { 2001:590::451f:1f62, > # eqx-ash-pxtr 2001:4f8:3:d::60, # isc-pxtr > 2001:418:4:1:deaf:bebe::10d, # asp-pxtr 2001:418:0:1000::613, > # ntt-amer-pxtr 2001:200:e000:17::17, # intouch-pxtr-1 > 2001:67C:21B4:108::b, # intouch-pxtr-2 > 2001:6c8:41:100:0:2:1:c, # tdc-pxtr 2001:700:0:52E::4, > # uninett-pxtr 2001:67C:21B4:107::b # apan-pxtr } > > LISP-Subnet mappings: > > database-mapping { eid-prefix = 2610:D0:21B3::/48 interface > = ens32 priority_v4 = 1 # Priority of IPv4 locator > of <interface_name> for this EID weight_v4 = 100 # > Weight of IPv4 locator of <interface_name> for this EID priority_v6 > = 1 # Priority of IPv6 locator of <interface_name> for > this EID weight_v6 = 100 # Weight of IPv6 locator > of <interface_name> for this EID } > > database-mapping { eid-prefix = 153.16.54.80/28 interface > = ens32 priority_v4 = 1 # Priority of IPv4 locator > of <interface_name> for this EID weight_v4 = 100 # > Weight of IPv4 locator of <interface_name> for this EID priority_v6 > = 1 # Priority of IPv6 locator of <interface_name> for > this EID weight_v6 = 100 # Weight of IPv6 locator > of <interface_name> for this EID } > > # ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue > state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd > 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever > preferred_lft forever inet6 ::1/128 scope host valid_lft forever > preferred_lft forever 3: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> > mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 > link/ether 00:0c:29:4b:0d:7f brd ff:ff:ff:ff:ff:ff inet6 > 2a02:188:12e:4::3/64 scope global valid_lft forever preferred_lft > forever inet6 fe80::20c:29ff:fe4b:d7f/64 scope link valid_lft > forever preferred_lft forever 4: ens34: > <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state > UP group default qlen 1000 link/ether 00:0c:29:4b:0d:89 brd > ff:ff:ff:ff:ff:ff inet 153.16.54.81/28 brd 153.16.54.95 scope > global ens34 valid_lft forever preferred_lft forever inet6 > 2610:d0:21b3:0:153:16:54:81/48 scope global valid_lft forever > preferred_lft forever inet6 fe80::20c:29ff:fe4b:d89/64 scope link > valid_lft forever preferred_lft forever 7: lispTun0: > <POINTOPOINT,UP,LOWER_UP> mtu 1440 qdisc pfifo_fast state UNKNOWN > group default qlen 500 link/none inet 127.0.0.127/32 scope global > lispTun0 valid_lft forever preferred_lft forever inet6 ::127/128 > scope global valid_lft forever preferred_lft forever > > > Is it possible that the missing IPv4 PITR hosts are what is > causing the problem? Then why would it work on one PITR, but not on > another? > > I guess it should be possible to get IPv4 connectivity, only > having IPv6 available - At least, LISP should be able to provide > as transition to IPv6, so the other way around should be the same? > > Looking forward to hear any suggestions. If more configuration > details are needed, just ask :) > > Thanks > > Best regards Dennis Glindhart > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJURO2+AAoJECKVpokMNO7TpyoP/0K4hISRaFJIDEpQ58AUJdjU BXYKDG0hh9vXuFywgSzkurcUYCaU2PSMh8H846Wa994+BbqV7LlQClVoUEP0HvpY ZgndXj5kEGNns5qsBFwUPniIyEC5LdJ1ECQq19mDucDnzeT26LMl6f6tHSmKYwiA LBaJGmMmi2oCKE+5d9lxOpq4/ttMSahLP/gRx6Z+kRPeptN3DSYJWOn2ATgduvIz xE+S1zzXANHxUH2fCpPe8IdRlWUcJzLompOJWcX1EVfWV5XEU5Nav+RSdq6fUfIM Y/wInGQCIpxTRYytqsyhPDJiyuQ0y/JM+dh7N/eGsZq2+TPayLX2T5ihdaC7DuwA XWnfOPzrv99KUdPBBiMoLokZ9UatJlPi2elzXTvwOcNZWMXwFDC2s0rUXuWtiPO4 eLmXMrFWcFt319Fd4yUREJ2Kk50cwfwud+fTaZ42dgxfBYTt6CthRbgrerif/DL7 BUkhNzsI2ErYX5ikubBRKppCMqlZ8QV9krh7V8KbI+WyLT+GD0l+8zomB/bo+5T6 zYJQrnRdd+Pg6pFS813h9zANmx9svHEeKCdJ2qEIwKzagxcqmiOoifywR6latKr3 KpjolvYaoezDhtNd4ZJfZPn3SEoaGmIsXzsXx07aPVbhAoqc8jxKoNTOBjH3q9W1 hzums1HBq+FhJZWcPPPT =7bKJ -----END PGP SIGNATURE-----
