• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

Issues setting up use of routed /64 and /48

Started by mcgurrin, November 26, 2010, 10:00:27 AM

Previous topic - Next topic

mcgurrin

I'm running several several machines which I am trying to setup with the ipv6 tunnel service, the one I am having the most trouble with is running centos 64 bit and I can get it to ping out but I can't get it to respond on its routed /64 IP addresses from another IPv6 capable machine.  I have run through the steps given on the tunnel details page but I don't see any configuration when I look on the machine to tell it to use the routed /64 addresses, only the ppp tunnel address and some other that seem to be automatic from before I set up the tunnel that seem to be loopback and other similar addresses.  Can anyone help me?  If there are specific command outputs that would help let me know and I would be happy to post them, I have tried so many commands though I just don't want to post them all without knowing which are helpful.  Thanks.

cholzhauer

A copy of your routing tables and ifconfig would be helpful.

mcgurrin

Quote from: cholzhauer on November 26, 2010, 10:58:33 AM
A copy of your routing tables and ifconfig would be helpful.
I have included them below, its odd though because I see no IPv6 routing data even though I can use "ping6 ipv6.google.com" with success and get responses, is there some different command for ipv6 routing data?  Thanks.

[root@1 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3E:01:03:16 
          inet addr:173.234.9.77  Bcast:173.234.9.127  Mask:255.255.255.128
          inet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global
          inet6 addr: fe80::216:3eff:fe01:316/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:100280 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5740 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6862589 (6.5 MiB)  TX bytes:2510599 (2.3 MiB)

he-ipv6   Link encap:IPv6-in-IPv4 
          inet6 addr: 2001:470:7:920::2/64 Scope:Global
          inet6 addr: fe80::adea:94d/128 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:13 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1352 (1.3 KiB)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2004 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2004 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:354554 (346.2 KiB)  TX bytes:354554 (346.2 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.100.200.1  P-t-P:10.100.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00 
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:7665 (7.4 KiB)

[root@1 ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.100.200.2    *               255.255.255.255 UH    0      0        0 tun0
173.234.9.0     *               255.255.255.128 U     0      0        0 eth0
10.100.200.0    10.100.200.2    255.255.255.0   UG    0      0        0 tun0
192.168.122.0   *               255.255.255.0   U     0      0        0 virbr0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         173.234.9.1.rdn 0.0.0.0         UG    0      0        0 eth0
[root@1 ~]#

edderkop

to get the routing table for ipv6 use

ip -6 route

cholzhauer


mcgurrin

Quote from: edderkop on November 26, 2010, 10:53:11 PM
to get the routing table for ipv6 use

ip -6 route


Alright, here the output:

[root@1 ~]# ip -6 route
2001:470:7:920::/64 via :: dev he-ipv6  metric 256  expires 21251045sec mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:8:920::/64 via :: dev he-ipv6  metric 256  expires 21280880sec mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:1f07:bdd::/64 dev eth0  proto kernel  metric 256  expires 2592068sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev virbr0  metric 256  expires 21250517sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 via :: dev he-ipv6  metric 256  expires 21251045sec mtu 1480 advmss 1420 hoplimit 4294967295
fe80::/64 dev eth0  metric 256  expires 21277944sec mtu 1500 advmss 1440 hoplimit 4294967295
default dev he-ipv6  metric 1024  expires 21251045sec mtu 1480 advmss 1420 hoplimit 4294967295
default via fe80::dad3:85ff:fe5d:3415 dev eth0  proto kernel  metric 1024  expires 1706sec mtu 1500 advmss 1440 hoplimit 64

snarked

Quoteinet6 addr: 2001:470:7:920::2/64 Scope:Global
??? - especially when:
Quoteinet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global
seems to be your routed /64.

Are you certain you're using your tunnel's /64 correctly?

The encapsulated interface should have the tunnel ...::2 address on it, NOT one from the routed /48.

mcgurrin

Quote from: snarked on November 27, 2010, 04:49:00 PM
Quoteinet6 addr: 2001:470:7:920::2/64 Scope:Global
??? - especially when:
Quoteinet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global
seems to be your routed /64.

Are you certain you're using your tunnel's /64 correctly?

The encapsulated interface should have the tunnel ...::2 address on it, NOT one from the routed /48.

Actually I am quite confused about that address as my routed /64 is 2001:470:8:920::/64  I seem to have made progress though, It seems I needed to assign the IPv6 addresses as addresses on the link for them to be used but that seems like there must be something I am missing because that requires adding each individual address one by one for them to work but it seems to work on and off, sometimes I can ping them and others I can't though I think the times I can't might be due to an issue on one of the machines I tried pinging from as it sometimes fails when the other machine works however it can still ping ipv6.google.com at those times with ping6.  I am thoroughly confused as to why I can't ping it from my one box but my other can but there must be some way to assign more than one individual address at a time to the machine as that clutters up ifconfig readouts with one line each and is so time consuming that I doubt most places would take the time to do it on a large scale.  On a side note does anyone know a good place that lists and describes all of the different ipv6 reserved addresses?

The command I was using to add the addresses was ip -6 addr add 2001:470:8:920:1:1:1:1/64 dev he-ipv6 replacing the IP address in there each time with the next one to be added.  The tunnel interface is he-ipv6, not eth0 like the address you were wondering about came from.  I will have to look into what that address is, it is possible I am being supplied ipv6 by my host for that vps and did not know it, I am fairly sure they don't advertise it, I'll have to ask support as I never added anything with that address and I need a bunch of addresses for my stuff to work, I'm setting up all of the subdomains hosted there to have a unique ipv6 address and ssl on each with a valid ssl certificate so ipv6 capable users won't have to go through my single ipv4 based ssl site that includes all the others as subfolders as I only have one ipv4 address there and so it is a pain to do more than one ssl cert and it would not be fully compatible.  I'm looking at using as many as 100-200 addresses on that box eventually for different parts of my site as I subdivide by subdomains more than subdirectories.

Thanks,
Glenn McGurrin

lukec

Glen
You state:
QuoteActually I am quite confused about that address as my routed /64 is 2001:470:8:920::/64 

It looks like your Tunnel /64 is this 2001:0470:0007:0920::/64 (simplistically 4 "lots" of 8 = 64 leading zeros added)
Your Tunnel endpoint and HE's endpoint appear to be - and HEs end responds but your end doesn't.

lear:~> dig AAAA mcgurrin-1.tunnel.tserv13.ash1.ipv6.he.net. +short
2001:0470:0007:0920::1

lear:~> dig AAAA mcgurrin-1-pt.tunnel.tserv13.ash1.ipv6.he.net. +short
2001:0470:0007:0920::2

lear:~> ping6 2001:470:7:920::1
PING6(56=40+8+8 bytes) 2001:470:9313:0:224:81ff:fe07:99 --> 2001:470:7:920::1
16 bytes from 2001:470:7:920::1, icmp_seq=0 hlim=59 time=124.161 ms
16 bytes from 2001:470:7:920::1, icmp_seq=1 hlim=59 time=122.881 ms
^C
--- 2001:470:7:920::1 ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 122.881/123.521/124.161/0.640 ms

lear:~> ping6 2001:470:7:920::2
PING6(56=40+8+8 bytes) 2001:470:9313:0:224:81ff:fe07:99 --> 2001:470:7:920::2
^C
--- 2001:470:7:920::2 ping6 statistics ---
6 packets transmitted, 0 packets received, 100.0% packet loss


If your "routed" block were 2001:0470:1f07:0bdd::/64 then this would route to your tunnel endpoint and not as below to "crash430"

traceroute6 2001:470:1f07:bdd:216:3eff:fe01:316
traceroute6 to 2001:470:1f07:bdd:216:3eff:fe01:316 (2001:470:1f07:bdd:216:3eff:fe01:316) from 2001:470:9313:0:224:81ff:fe07:99, 64 hops max, 12 byte packets
1  lukec-gw  0.799 ms  0.697 ms  0.688 ms
2  lukec-1.tunnel.tserv5.lon1.ipv6.he.net  58.673 ms  54.610 ms  52.788 ms
3  gige-g4-6.core1.lon1.he.net  49.199 ms  49.202 ms  57.449 ms
4  10gigabitethernet2-3.core1.nyc4.he.net  117.536 ms  120.483 ms  125.609 ms
5  gige-gbge0.tserv4.nyc4.ipv6.he.net  120.022 ms  120.463 ms  120.684 ms
6  mzch-3-pt.tunnel.tserv4.nyc4.ipv6.he.net  139.931 ms  140.317 ms  140.963 ms
7  crash430-1-pt.tunnel.tserv4.nyc4.ipv6.he.net  3144.036 ms !A  3143.910 ms !A  3143.702 ms !A


So check both.

Your Tunnel interface should show something like
tun0 inet6 2001:0470:0007:0920::2  prefixlen 64

Your ethernet interface should show something like
eth0 inet6 <routed /64 address here> prefixlen 64 autoconf

(However probably without the "autoconf")

rgds
lukec

cholzhauer

If you could post a copy of your tunnel details, it might clear up a bunch of confusion.

mcgurrin

Quote from: cholzhauer on November 28, 2010, 06:31:46 AM
If you could post a copy of your tunnel details, it might clear up a bunch of confusion.

The tunnel details page is attached.  I used the linux-route2 commands so the name is actually he-ipv6 for the interface.  You are correct on the tunnel /64.  I don't think my endpoint is supposed to respond from the internet from my reading, try pinging 2001:470:8:920:1:1:1:1 which is within my routed /64 and I think it is responding to pings at my server but it seems to work sometimes and others not as I mentioned, I think that is due to some misconfiguration on one of the machines I tried pinging from's network though based on my tests.

QuoteIf your "routed" block were 2001:0470:1f07:0bdd::/64 then this would route to your tunnel endpoint and not as below to "crash430"
I don't think that that is my routed /64 based on the pages on this site.  I think that that block is from my host and it might just be the one address listed as I did nothing that would have set that address up and I see no reference to the entire /64 block on either of my tunnel details pages, one for this server one for another.  I think I figured out the labor intensive way to get it responding but what I need now is efficiency instead of assigning each address one by one and cluttering up my output, especially when I am not sure it will persist beyond a reboot and so I either have to write a script or do it all over again.

Thanks for all of the help so far, it has been really helpful in figuring this out both directly and indirectly.

cholzhauer

OK, so your routed /64 is 2001:470:8:920::/64  and the /48 is 2001:470:e2c4::/48  Your tunnel /64 is 2001:470:7:920::/64

We don't want to do anything with 2001:470:7:920::/64 other than use it for the tunnel end points

Since you have the /48, you might as well use it, so we'll ignore 2001:470:8:920::/64 as well (but you could use it)

I cannot ping the address you provided


[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 ---
20 packets transmitted, 0 packets received, 100.0% packet loss


As for automatically assigning addresses, your choices are Router Advertisements (RA) or DHCPv6.  As long as you're running DNS internally, RA is easier to set up and more universally supported.



mcgurrin

Quote from: cholzhauer on November 28, 2010, 09:05:12 AM
OK, so your routed /64 is 2001:470:8:920::/64  and the /48 is 2001:470:e2c4::/48  Your tunnel /64 is 2001:470:7:920::/64

We don't want to do anything with 2001:470:7:920::/64 other than use it for the tunnel end points

Since you have the /48, you might as well use it, so we'll ignore 2001:470:8:920::/64 as well (but you could use it)

I cannot ping the address you provided


[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 ---
20 packets transmitted, 0 packets received, 100.0% packet loss


As for automatically assigning addresses, your choices are Router Advertisements (RA) or DHCPv6.  As long as you're running DNS internally, RA is easier to set up and more universally supported.

I don't think you know the use case for this, the RA is something I could use help with as well but that is for a different tunnel, this tunnel is exclusively for one server, I just need it to know that a whole block of addresses are are local for it, probably just a /112 worth at a time out of my /64 as I have already started making AAAA records for those addresses and I don't want to have to redo them.  I have a few other projects in mind for my /48 so I am reserving that for now for other stuff.  Do you understand this use case better now?  I am basically making the one VPS I have ipv6 ready and set up.  The address I provided worked earlier but it does not seem to anymore.  Below I will include my current ifconfig output in the hopes it will help and will help you see what I am doing.  The issue I seem to be having is just telling the VPS to answer requests on those addresses, if you know anything about that use case I would really appreciate it, thanks for the help so far and I hope this makes it easier.  Your help has gone beyond the actual help because it has kept me working on this and doing further searches which have helped me better understand the issue and get parts of it solved, thanks.

[root@1 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:16:3E:01:03:16 
          inet addr:173.234.9.77  Bcast:173.234.9.127  Mask:255.255.255.128
          inet6 addr: 2001:470:1f07:bdd:216:3eff:fe01:316/64 Scope:Global
          inet6 addr: fe80::216:3eff:fe01:316/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1774980 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:257166781 (245.2 MiB)  TX bytes:48641947 (46.3 MiB)

he-ipv6   Link encap:IPv6-in-IPv4 
          inet6 addr: 2001:470:8:920:1:1:1:10/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:1/64 Scope:Global
          inet6 addr: 2001:470:8:920::/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:11/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:12/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:3/64 Scope:Global
          inet6 addr: 2001:470:7:920::2/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:13/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:2/64 Scope:Global
          inet6 addr: fe80::adea:94d/128 Scope:Link
          inet6 addr: 2001:470:8:920:1:1:1:14/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:5/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:15/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:4/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:16/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:7/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:17/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:6/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:18/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:9/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:19/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:8/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:1a/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:b/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:1b/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:a/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:d/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:c/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:f/64 Scope:Global
          inet6 addr: 2001:470:8:920:1:1:1:e/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:408 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:33538 (32.7 KiB)  TX bytes:0 (0.0 b)

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:97803 errors:0 dropped:0 overruns:0 frame:0
          TX packets:97803 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17449428 (16.6 MiB)  TX bytes:17449428 (16.6 MiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          inet addr:10.100.200.1  P-t-P:10.100.200.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

virbr0    Link encap:Ethernet  HWaddr 00:00:00:00:00:00 
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:7665 (7.4 KiB)

[root@1 ~]#

snarked

Still not proper, but maybe working?

The TUNNEL /64 is supposed to be the ONLY thing on the tunnel encapsulation interface.  "he-ipv6" should have ONLY "2001:470:7:920::2" as global on it (it may be a "/64", but only "/126" addresses will be used).  The other addresses, "2001:470:8:920::/64" and "2001:470:e2c4::/48" should be on OTHER interfaces (like eth0 or virbr0).

Eth0's "2001:470:1f07:bdd:216:3eff:fe01:316/64" is wrong - and seems as if it's a leftover from a prior tunnel you may have had via a different tunnel server location.

mcgurrin

Quote from: snarked on November 28, 2010, 11:45:59 AM
Still not proper, but maybe working?

The TUNNEL /64 is supposed to be the ONLY thing on the tunnel encapsulation interface.  "he-ipv6" should have ONLY "2001:470:7:920::2" as global on it (it may be a "/64", but only "/126" addresses will be used).  The other addresses, "2001:470:8:920::/64" and "2001:470:e2c4::/48" should be on OTHER interfaces (like eth0 or virbr0).

Eth0's "2001:470:1f07:bdd:216:3eff:fe01:316/64" is wrong - and seems as if it's a leftover from a prior tunnel you may have had via a different tunnel server location.

Oh, I didn't realize that for the other addresses, maybe that is why it is not working.  Actually this is the first tunnel I have done and that address works so I think it is actually an address from my host so unless it starts causing issues I will leave it though I didn't notice it until recently.  I have removed the addresses from the tunnel interface and I added the first back except on eth0 and that helped and made it work, can you try pinging 2001:470:8:920:1:1:1:1 to see if it works, that is the address I put back with that one change.  To think it might have been such a simple issue for the last half of this discussion.  Now the only remaining question as long as that continues to work is how would I add a group of addresses without specifying each one individually, say an /112?  Thanks, that is a huge help.