-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 iQIcBAEBAgAGBQJUQmmoAAoJECKVpokMNO7TbQQP/jGJjvRZDjpQ2MTWGemQcnqh zCwTzQio17L7eyOAHg86V4cZr3+TZ9SKUr+8VDCv8QucwDCSQ8s9yvc/xnzyV50i 03kflKhhiuxxlp3hWtarWh0uIU+lRLZ94r1RyVW20kDYhj4+7741gEd+G6CNdBYV +XYtemB6skHyrTN1l9OEN7Zr5iMpShXDhhGvpYpPfRK4qAmohdDPvgKeM2c4Yzgp 0Mt70XqQGaBaOsQTH6sgBTG3ph4u6dDyjoA8D9NutKmp6pOsr15IiYD+QNZJ0Dz6 Oa3feBmP+gAPMr2efXMJgcsER2kc286+ATm5FPI5kISM9CIEhbYiatuqA4C+YoHx t4lCfNKvFAhG4324hzeKJLARXLeBbPVKLEmWZ55kBUdtGOc2dJJ7uTK6B/gjJpGQ VfbPeJTGl4vQcWdOTAjKTZz/YMa34eZfIHWZ4Z56Wxo/+rH3++SI+klFmGWXMG/5 mvWu7A50d8QnxHtCZWcSiv6bfCnk7auzKDyH7PYrc8QahYYmC5mePf8FxV/EtJ4u IEZYn92svVuP4p8EDHc7Xe9a5N6QyI7Owd7Ejf24tB23umV9ITsGEEy548Dz+jhQ U664A/1wC1VEV6gIDhCZ/91A429JYgJOaCTHIUH5HSZIirv/gfOntT63K7gLrbij 1eAdHG1QMLU/AnL+OcRI =V4yI -----END PGP SIGNATURE-----
