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:
-----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-----
--
Albert López
CCABA System Administrator
Universitat Politècnica de Catalunya
Telf: 93 4017182
