-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi again

Apparently some configuration file for my site were missing on one of
the MR's. A nice Cisco technician made it right and now it works :)

Case closed

Thanks

Best Regards
Dennis Glindhart

On 20-10-2014 13:14, Dennis Glindhart wrote:
> Dear All
> 
> Just so you are informed in case you don't read my response on the 
> mailing list.
> 
> I tried yesterday, as a last resort, to remove the intouch-pxtr-2
> (and intouch-pxtr-1 based on gut feeling :p) from my PITR-list in
> my configuration and it works currently with those PITR's removed.
> 
> Let me know if I should put them back in again if you need it to
> debug the problem while it is happening.
> 
> Best Regards Dennis Glindhart
> 
> On 20-10-2014 12:10, Albert López wrote:
>> Dear All,
> 
>> Dennis, a user of LISPmob, has detected a loop in the PiTR of the
>>  intouch-pxtr2. I forward his mail with all the details.
> 
>> Could you have a look at it?
> 
>> Many thanks
> 
>> Albert L.
> 
> 
>> 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

iQIcBAEBCAAGBQJURVbuAAoJECKVpokMNO7TOzAP+gIk3KQIeSSUbJQY1TrUtjdO
DOnCIf3i2sgL2wAKtZO6y2MajQ6YeWbNqAaU7jbLF8fDva082tS5BnGiNPw3kufW
WDi1QgKytDmjOHTf39FlpwxmiURuo0AueNwbAF7Ng9acF2KY83YxdhhwAtnV/IKh
AqGiPgb+HCW8xpabwnkNVRT/kVSaHZlAqSBxryAVbThi66+kGuL9CXrkC9+vwyE2
bRAjpLri6K/6iDPlbJiZSuk8VBeBiagq5tZn2EKSupXHyHUWh4EUMCRP4oM4lCOO
XW+7/Gr0ksCkuMOAwDtSbQFdZgeK0tq8JKVI8Apqv+zJRXnLyvrN5MahcaW+6wEF
rtfFaMdajcONCBwZ1LmAQO7rInm42AvQDpCgv6CNZAEsAIv9y9fircslTK5qLMFP
Ek6NK5M9rkp81idRN94KY2vcJm/3P2k3SmEnklhFP+QDelzWOQyDZ7XNQBX5YKbC
uDX0tGj8B/BVZ13IAAdRbOnMJlv9eapaD6mGc/CUa3t18paG+YWO8TA9MZSBpTAO
HKV5xyOu7ydIYdobDhOhBX5Bp4VL8qJ/L/kTWJB9eNjR4pwf3XOtFNfAmjkr0S3U
csaPBYLSvQM2cOiwUo00VCuBhNtxdFUxnq/ANPFkEpJ8iBjpfrM1eZE4ddbPCERj
gAlcDZ7IDWDrSEY/Ckk/
=xZal
-----END PGP SIGNATURE-----

Reply via email to