Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Author Topic: Peering issue with tserv10.par1.ipv6.he.net and PANAP ?  (Read 2218 times)

xroche

  • Newbie
  • *
  • Posts: 1
Peering issue with tserv10.par1.ipv6.he.net and PANAP ?
« on: January 23, 2011, 10:09:06 AM »

I am the happy user of a he.net ipv6 tunnel, and I am using the Paris POP.

I noticed however that from a machine based on a datacenter (88.191.124.95), the Paris POP (216.66.84.42) looks a bit far:

Code: [Select]
# ping 216.66.84.42
PING 216.66.84.42 (216.66.84.42) 56(84) bytes of data.
64 bytes from 216.66.84.42: icmp_seq=1 ttl=58 time=26.8 ms
64 bytes from 216.66.84.42: icmp_seq=2 ttl=58 time=27.5 ms

(The ping time should be something like 1ms or 2ms)

The strange thing is that the PANAP should be used for the route, but it is not, and the traffic goes through Amsterdam (!):

Code: [Select]
~# traceroute 216.66.84.42
traceroute to 216.66.84.42 (216.66.84.42), 30 hops max, 40 byte packets
 1  88.191.124.1 (88.191.124.1)  3.549 ms  3.563 ms  3.613 ms
 2  88.191.2.70 (88.191.2.70)  14.310 ms * *
 3  th2-crs16-1-be1503-p.intf.routers.proxad.net (212.27.58.45)  0.869 ms  0.883 ms  0.869 ms
 4  strasbourg-crs16-1-be2000.intf.routers.proxad.net (212.27.50.10)  7.635 ms  7.643 ms  7.629 ms
 5  francfort-6k-1-po100.intf.routers.proxad.net (212.27.56.30)  10.481 ms  10.483 ms  10.555 ms
 6  * amsterdam-6k-1-po100.intf.routers.proxad.net (212.27.56.38)  18.923 ms *
 7  20gigabitethernet1-3.core1.ams1.he.net (195.69.145.150)  17.400 ms  16.992 ms  17.235 ms
 8  10gigabitethernet1-1.core1.fra1.he.net (72.52.92.93)  17.885 ms  27.372 ms  27.671 ms
 9  10gigabitethernet1-2.core1.par1.he.net (72.52.92.89)  32.695 ms  30.330 ms  30.161 ms
10  tserv10.par1.ipv6.he.net (216.66.84.42)  25.181 ms  24.951 ms  24.904 ms

The traffic should be routed through panap ; for example:

Code: [Select]
# traceroute 62.35.254.152
traceroute to 62.35.254.152 (62.35.254.152), 30 hops max, 40 byte packets
 1  88.191.124.1 (88.191.124.1)  17.328 ms  17.384 ms  17.431 ms
 2  88.191.2.70 (88.191.2.70)  0.300 ms * *
 3  bzn-crs16-1-be1500-p.intf.routers.proxad.net (212.27.50.161)  1.200 ms  1.196 ms  1.181 ms
 4  th2-6k-3-po21.intf.routers.proxad.net (212.27.56.2)  12.922 ms * *
 5  TenGE3-3.core02-t2.club-internet.fr (194.117.192.9)  1.888 ms  1.979 ms  2.033 ms
 6  interxion-france.panap.fr (62.35.254.152)  1.245 ms  1.140 ms  1.181 ms

And strangely, the 62.35.254.111 (Hurricane Electric IP endpoint on PANAP) route looks good:

Code: [Select]
# traceroute 62.35.254.111
traceroute to 62.35.254.111 (62.35.254.111), 30 hops max, 40 byte packets
 1  88.191.124.1 (88.191.124.1)  0.462 ms  0.526 ms  0.570 ms
 2  88.191.2.70 (88.191.2.70)  0.253 ms * *
 3  bzn-crs16-1-be1500-p.intf.routers.proxad.net (212.27.50.161)  1.268 ms  1.261 ms  1.252 ms
 4  th2-6k-3-po21.intf.routers.proxad.net (212.27.56.2)  0.718 ms * *
 5  TenGE3-3.core02-t2.club-internet.fr (194.117.192.9)  0.942 ms * *
..filtered trace

There might be a routing glitch somewhere ?

I am available for any additional testing.

BTW, thanks to he.net IPv6 tunnel broker admins for their excellent service!
Logged

mtindle

  • Administrator
  • Newbie
  • *****
  • Posts: 25
Re: Peering issue with tserv10.par1.ipv6.he.net and PANAP ?
« Reply #1 on: January 26, 2011, 08:24:43 PM »

AS12322 Proxad who's sourcing that IP

    *>i 88.160.0.0/11      195.66.224.191  1      100    0      12322 i

doesn't appear to be present on PaNAP

    http://www.peeringdb.com/view.php?asn=12322

They are, however on FreeIX, but we are not (yet?, I'll look into it.)

Our closest exit to AS12322 currently is actually in London where we are both present on LINX, but it appears they prefer AMSIX in Amsterdam for the return path from Paris.   If Proxad connects to PaNAP or FranceIX (which is where most of the PaNAP folks are moving and where HE is also present) I'll certainly work on getting a session turned up with them there.

Your last traceroute is to our PaNAP IP, but it's not an IP block we announce (and we shouldn't be announcing it; most IX netblocks can have interesting routing and announcements.)  So unfortunately, that traceroute is not going to be very informative of the actual path back to HE.
Logged