Print

[cholzhauer]

Still no ping

Code: [Select]

[carl@mars ~]$ ping6 2001:470:8:920:1:1:1:1
PING6(56=40+8+8 bytes) 2001:470:c27d:e000:20c:29ff:fe8a:1618 --> 2001:470:8:920:1:1:1:1
^C
--- 2001:470:8:920:1:1:1:1 ping6 statistics ---
11 packets transmitted, 0 packets received, 100.0% packet loss

And why use a /112? You have 65,536 /64's...I think you have one or two to spare.

[mcgurrin]

Still no ping

Code: [Select]

[carl@mars ~]$ ping6 2001:470:8:920:1:1:1:1
PING6(56=40+8+8 bytes) 2001:470:c27d:e000:20c:29ff:fe8a:1618 --> 2001:470:8:920:1:1:1:1
^C
--- 2001:470:8:920:1:1:1:1 ping6 statistics ---
11 packets transmitted, 0 packets received, 100.0% packet loss

And why use a /112? You have 65,536 /64's...I think you have one or two to spare.

Odd, I can ping it from my other tunnel but not you, any ideas as to why?  I chose that number because I figured that was all I needed for now, my plan is to add more as needed and as my DNS already points a /112 of the /64 I didn't want to have to redo it.  I could easily use the entire routed /64 and that would be fine if that is easier I just didn't know the performance impact of having that many IP addresses on the machine and didn't really need them so I figured I would leave them available until needed but yes I could easily use the entire /64 and I'm not really that opposed to it.

[cholzhauer]

I chose that number because I figured that was all I needed for now, my plan is to add more as needed and as my DNS already points a /112 of the /64 I didn't want to have to redo it.  I could easily use the entire routed /64 and that would be fine if that is easier I just didn't know the performance impact of having that many IP addresses on the machine and didn't really need them so I figured I would leave them available until needed but yes I could easily use the entire /64 and I'm not really that opposed to it.

A /64 is more "normal" as the IPv6 world uses that as the smallest routeable block.  I don't think performance will be an issue either.

Here's a traceroute to the address you listed

Code: [Select]


[carl@mars ~]$ traceroute6 2001:470:8:920:1:1:1:1
traceroute6 to 2001:470:8:920:1:1:1:1 (2001:470:8:920:1:1:1:1) from 2001:470:c27d:e000:20c:29ff:fe8a:1618, 64 hops max, 12 byte packets
 1  2001:470:c27d:d000:2e0:81ff:fe79:f4c4  1.465 ms  0.856 ms  0.715 ms
 2  servicespring-1.tunnel.tserv9.chi1.ipv6.he.net  48.412 ms  48.183 ms  47.484 ms
 3  gige-g3-4.core1.chi1.he.net  81.694 ms  45.169 ms  45.440 ms
 4  10gigabitethernet2-4.core1.nyc4.he.net  68.630 ms  74.351 ms  70.995 ms
 5  10gigabitethernet2-3.core1.ash1.he.net  73.660 ms  73.243 ms  92.107 ms
 6  gige-gbge0.tserv13.ash1.ipv6.he.net  108.317 ms  76.671 ms  78.062 ms
 7  * * *
 8  *^C

Do you have another address on that /64 that we can test?  I would like to rule out a routing issue at HE by testing another.

[mcgurrin]

I chose that number because I figured that was all I needed for now, my plan is to add more as needed and as my DNS already points a /112 of the /64 I didn't want to have to redo it.  I could easily use the entire routed /64 and that would be fine if that is easier I just didn't know the performance impact of having that many IP addresses on the machine and didn't really need them so I figured I would leave them available until needed but yes I could easily use the entire /64 and I'm not really that opposed to it.

A /64 is more "normal" as the IPv6 world uses that as the smallest routeable block.  I don't think performance will be an issue either.

Here's a traceroute to the address you listed

Code: [Select]


[carl@mars ~]$ traceroute6 2001:470:8:920:1:1:1:1
traceroute6 to 2001:470:8:920:1:1:1:1 (2001:470:8:920:1:1:1:1) from 2001:470:c27d:e000:20c:29ff:fe8a:1618, 64 hops max, 12 byte packets
 1  2001:470:c27d:d000:2e0:81ff:fe79:f4c4  1.465 ms  0.856 ms  0.715 ms
 2  servicespring-1.tunnel.tserv9.chi1.ipv6.he.net  48.412 ms  48.183 ms  47.484 ms
 3  gige-g3-4.core1.chi1.he.net  81.694 ms  45.169 ms  45.440 ms
 4  10gigabitethernet2-4.core1.nyc4.he.net  68.630 ms  74.351 ms  70.995 ms
 5  10gigabitethernet2-3.core1.ash1.he.net  73.660 ms  73.243 ms  92.107 ms
 6  gige-gbge0.tserv13.ash1.ipv6.he.net  108.317 ms  76.671 ms  78.062 ms
 7  * * *
 8  *^C

Do you have another address on that /64 that we can test?  I would like to rule out a routing issue at HE by testing another.

This is what I get:

Code: [Select]

debian:~# ping6 2001:470:8:920:1:1:1:2
PING 2001:470:8:920:1:1:1:2(2001:470:8:920:1:1:1:2) 56 data bytes
64 bytes from 2001:470:8:920:1:1:1:2: icmp_seq=1 ttl=62 time=472 ms
64 bytes from 2001:470:8:920:1:1:1:2: icmp_seq=2 ttl=62 time=445 ms
64 bytes from 2001:470:8:920:1:1:1:2: icmp_seq=3 ttl=62 time=469 ms
^C
--- 2001:470:8:920:1:1:1:2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2007ms
rtt min/avg/max/mdev = 445.090/462.175/472.413/12.159 ms
debian:~# traceroute 2001:470:8:920:1:1:1:1traceroute to 2001:470:8:920:1:1:1:1 (2001:470:8:920:1:1:1:1), 30 hops max, 40 byte packets
 1  mcgurrin-2.tunnel.tserv4.nyc4.ipv6.he.net (2001:470:1f06:cef::1)  289.626 ms  292.568 ms  295.184 ms
 2  gige-g3-8.core1.nyc4.he.net (2001:470:0:5d::1)  295.674 ms  295.745 ms  295.811 ms
 3  10gigabitethernet2-3.core1.ash1.he.net (2001:470:0:36::1)  301.438 ms  301.595 ms  301.140 ms
 4  gige-gbge0.tserv13.ash1.ipv6.he.net (2001:470:0:90::2)  302.013 ms  302.928 ms  295.066 ms
 5  1.vpslime.mcgurrin.net (2001:470:8:920:1:1:1:1)  320.683 ms  320.864 ms  321.055 ms
debian:~#
Try changing the last 1 to anything 2-8 as those are the others currently set up if you want a different address, I will be setting up more later today probably.  The whole block is from HE though so I don't know if that will help with a routing issue at all.  That test is from a different machine on a different HE tunnel where the connection to the internet from the machine is very slow so the long delays are from that, that is normal from there though I need to get it fixed but ipv4 pinging google.com would be similar times.

EDIT: make that 2-1c as I just added a bunch more.

[cholzhauer]

I can ping 2001:470:8:920:1:1:1:2 and 2001:470:8:920:1:1:1:5 with no problems now.

[mcgurrin]

I can ping 2001:470:8:920:1:1:1:2 and 2001:470:8:920:1:1:1:5 with no problems now.

So does that mean you can't ping the others?  I've done the exact same command for each only changing the IP, if you can only ping some that is odd.

[cholzhauer]

I can ping through ::11, which is where I stopped because I was tired of incrementing by one.

[mcgurrin]

I can ping through ::11, which is where I stopped because I was tired of incrementing by one.

Ok, it looks like it is working then, now the only question is do I have to add the IP addresses one by one or can I add a range at once to make things easier?  Thanks for all your help, having more machines being tested from has unearthed some things that have helped make this work and ideas and knowledge have been crucial.

[cholzhauer]

I'm not sure what you mean by "add a range at once"

You're looking for a quicker way to add addresses to each machine?

[mcgurrin]

I'm not sure what you mean by "add a range at once"

You're looking for a quicker way to add addresses to each machine?

There is only one machine behind the tunnel so and I want to have each domain/subdomain hosted on the machine have its own ipv6 address which will soon add up to over 100 addresses as I move more and more to the machine and I don't want to manually add an IP address per subdomain, I want to add lets say 2001:470:8:920:1:1:1:1 through 2001:470:8:920:1:1:1:ffff all as IP addresses for the machine in one command, basically I want to assign a bunch of IP addresses to the one machine without much effort.  It could also work to add every IP address in the /64 to the machine if that is easier.  All of the addresses are currently routed to the machine but it won't respond on those addresses unless I manually add them by doing a command like "ip -6 addr add 2001:470:8:920:1:1:1:1c/64 dev eth0" for each address, I want to add a bunch of addresses at once to the same effect except they won't all be listed in the ifconfig list which would also get unwieldy if it had 100+ addresses on one interface.

Thanks.

[cholzhauer]

Not that I'm aware of, but that doesn't mean there isn't a way.

I'll watch this thread too to see if anyone else has a suggestion/method