I have checked the forums, and haven't seen anything that helps me at all, so here we go.
Setup: Linux (2.6.24.5 Kernel)
1 Internal interface 10/100 card [eth0] (2001:470:d848::/48)
1 External interface 10/100 card [eth1] (2001:470:4:35::/64) => 2001:470:4:35:102/64)
1 HE Tunnel [sixbone] (2001:470:4:35::2/64)
My linux box, is a relay 4 to 6 switch, using HE's tunnel.
I have the tunnel setup and works perfect on the linux router. I can ping my endpoint, ipv6 world, and all my machines on the external ipv6 protocol (eth0).
On the internal eth1, I have radvd setup which is allowing the base6to4interface for the internal as it is a dhcpv4 network, since this allows the address to change with the ipv4 address given.
What I refer to as external (eth0) are machines with static IPv4 address that are outside of my internal (10.10.10.0/24) network.
There are no ip6table rules, and the forwarding if turned on.
I can ping from the base6to4interfaced machines through to the tunnel and I can see it traverse to the tunnel, however never see it come back. The external interface [eth0] give a destination unreachable error.
Results: (from a local machine) [eth1] {as shown below you can see the interface turn up and turn down, this is where I was modifing the radvd.conf file picking different prefix sets for the eth1 section.
Quote
ping6 2001:470:4:35::2
PING6(56=40+8+8 bytes) 2002:a0a:a02:35:211:24ff:fe42:ebb6 --> 2001:470:4:35::2
16 bytes from 2001:470:4:35::2, icmp_seq=23 hlim=64 time=0.644 ms
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
ping6: sendmsg: No route to host
ping6: wrote 2001:470:4:35::2 16 chars, ret=-1
16 bytes from 2001:470:4:35::2, icmp_seq=50 hlim=64 time=0.551 ms
^C
--- 2001:470:4:35::2 ping6 statistics ---
63 packets transmitted, 2 packets received, 96% packet loss
round-trip min/avg/max = 0.551/0.598/0.644 ms
Configurations :: (The Server)
/etc/radvd.conf
Quote
interface eth0 {
IgnoreIfMissing off;
AdvHomeAgentFlag off;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSendAdvert off;
prefix 2001:470:4:35::/64
{
AdvRouterAddr off;
AdvOnLink on;
AdvAutonomous off;
# Base6to4Interface eth0;
};
};
interface eth1 {
IgnoreIfMissing on;
AdvHomeAgentFlag on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSendAdvert on;
#prefix 2001:470:4:35:210:5aff:fee0:4902/64
prefix 2001:470:4:35::/64
#prefix 2001:470:d848::/64
#prefix 2001:470:4:35:210/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface eth1;
};
};
As you can see above I have been playing with the eth1 interface prefix, and none of the ones above seem to work, execept when I change them, I get 1 response returned. See ping above.
My ifconfig results
Quote
eth0 Link encap:Ethernet HWaddr 00:10:5a:a0:6b:23
inet addr:70.88.178.102 Bcast:70.88.178.111 Mask:255.255.255.240
inet6 addr: 2001:470:4:35::102/64 Scope:Global
inet6 addr: 2001:470:4:35:210:5aff:fea0:6b23/64 Scope:Global
inet6 addr: fe80::210:5aff:fea0:6b23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:289386 errors:0 dropped:0 overruns:0 frame:0
TX packets:374546 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:116230226 (110.8 MiB) TX bytes:219731557 (209.5 MiB)
Interrupt:10 Base address:0x4f00
eth1 Link encap:Ethernet HWaddr 00:10:5a:e0:49:02
inet addr:10.10.10.2 Bcast:10.10.10.255 Mask:255.255.255.0
inet6 addr: 2001:470:d848::1/48 Scope:Global
inet6 addr: fe80::210:5aff:fee0:4902/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:342376 errors:0 dropped:0 overruns:0 frame:0
TX packets:238873 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:218974805 (208.8 MiB) TX bytes:105811972 (100.9 MiB)
Interrupt:11 Base address:0x6f80
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:23793 errors:0 dropped:0 overruns:0 frame:0
TX packets:23793 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3332712 (3.1 MiB) TX bytes:3332712 (3.1 MiB)
sixbone Link encap:UNSPEC HWaddr 46-58-B2-66-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2001:470:4:35::2/64 Scope:Global
inet6 addr: fe80::4658:b266/128 Scope:Link
UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
RX packets:3323 errors:0 dropped:0 overruns:0 frame:0
TX packets:12265 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:822261 (802.9 KiB) TX bytes:1204472 (1.1 MiB)
My Routing Table
Quote
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: Un 0 1 7 lo
2001:470:4:35::/128 :: Un 0 2 0 lo
2001:470:4:35::/128 :: Un 0 2 0 lo
2001:470:4:35::2/128 :: Un 0 1 3900 lo
2001:470:4:35::102/128 :: Un 0 1 1321 lo
2001:470:4:35::/64 :: Un 256 0 5596 sixbone
2001:470:4:35::/64 :: U 256 0 0 eth0
2001:470:d848::1/128 :: Un 0 1 0 lo
2001:470:d848::/48 :: U 256 0 0 eth1
fe80::/128 :: Un 0 2 0 lo
fe80::/128 :: Un 0 2 0 lo
fe80::4658:b266/128 :: Un 0 1 0 lo
fe80::210:5aff:fea0:6b23/128 :: Un 0 1 20 lo
fe80::210:5aff:fee0:4902/128 :: Un 0 1 1537 lo
fe80::/64 :: Un 256 0 0 sixbone
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixbone
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
::/0 :: U 1024 0 0 sixbone
::/0 :: !n -1 5 17 lo
It would appear to me I have a routing issue. It is in retrospec that i say, I'm looking to route 2 interfaces to one tunnel, while still allowing the interfaces to see each other.
tunnel
|
+----------+------------+
| |
internal external
eth1 eth0
Looks like some confusion about what Base6to4Interface is used for: Base6to4Interface is only used for 2002::/48 addressing (aka 6to4), so you could have this:
prefix ::/64
{
Base6to4Interface eth0;
};
but only if you wanted to announce one of the /64's of your 2002:4658:b266::/48 range for an interface. Basically the option reads the IPv4 address on the interface specified and uses it as part of the IPv6 address. It doesn't look like you have sit0 configured so you don't have an active 6to4 configuration - so remove all Base6to4Interface entries from radvd's config file.
Your sixbone tunnel is referred to as a 6in4 tunnel, and he.net will assign two or three prefixes to it (/64 link, /64 allocation + optional /48 allocation)
The /64 link range should _only_ be assigned to the sixbone interface. The /64 allocation can then be assigned to _one_ other interface of your choosing. If you need to allocate to more interfaces than this you can split up your /48 and use that. Notice that you can't have the same range assigned to more than once interface at a time.
So it looks like:
link range: 2001:470:4:35::2/64
allocated /64: 2001:470:5:35::/64 (this you don't have configured anywhere yet)
allocated /48: 2001:470:d848::/48 (it looks like you assigned the entire /48 to eth1)
A minimal of what you want is something like:
sixbone: 2001:470:4:35::2/64
eth0: 2001:470:5:35::/64 (notice 4->5)
eth1: 2001:470:d848::/64 (notice /48->/64)
An alternative is not to use your allocated /64 and configure something like:
sixbone: 2001:470:4:35::2/64
eth0: 2001:470:d848:1234:/64
eth1: 2001:470:d848:5678:/64
because you've used two or your 65536 ranges from your /48 for eth0 and eth1, you can pick the '1234', and '5678' parts to be whatever four hexadecimal digits you want.
so an example radvd for those ideas would be:
interface eth0
{
prefix 2001:470:5:35::/64
{
};
}
interface eth1
{
prefix 2001:470:d848::/64
{
};
}
or interface eth0
{
prefix 2001:470:d848:1234:/64
{
};
}
interface eth1
{
prefix 2001:470:d848:5678:/64
{
};
}
Obviously you need to update your routing tables to match too.
Hope that helps,
Cheers
Thanks for the reply, but I have no idea where exactly you got the 5 from (2001:470:5:35::/64) This would be assigned to me from HE, and it wasn't. So if you know something I don't, as in HOW / WHY you changed the 4 to a 5, please enlighten me. Now, at one point in time, I did have a 5 address about a year or so ago, but not now.
OK, then the setup I have is correct and it is still only one way traffic. I was with HE before they where allocating /48, so I know the original was working.
This is what I would have used today, without a /48 assignment. (maybe i should move to that)
tunnel = 2001:470:4:35::2
eth0 = 2001:470:4:35::3
eth1 = 2001:479:4:35::4
My Current setup is this as of now.
tunnel 2001:470:4:35::2
eth1 2001:470:d848:5678::/64 IP assigned through base6to4interface.
My local machine IP. 2002:0a0a:0a02:5678:0211:24ff:fe42:ebb6
Currently I'm not working with the eth0 at all, I'm trying to get the traffic back.
Restults on the server from a pinging performed on a machine through eth1.
Quote
root@426-624:~$ tcpdump -vvisixbone
tcpdump: WARNING: sixbone: no IPv4 address assigned
tcpdump: listening on sixbone, link-type RAW (Raw IP), capture size 96 bytes
08:52:08.671670 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 0
08:52:08.699676 IP6 (hlim 64, next-header UDP (17) payload length: 109) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401 > ns-sec.ripe.net.domain: 64594% [1au][|domain]
08:52:08.863675 IP6 (hlim 57, next-header UDP (17) payload length: 182) ns-sec.ripe.net.domain > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401: 64594 NXDomain*- q:[|domain]
08:52:09.071700 IP6 (hlim 64, next-header UDP (17) payload length: 109) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401 > ns3.he.net.domain: 26260% [1au][|domain]
08:52:09.071700 IP6 (hlim 64, next-header UDP (17) payload length: 109) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401 > ns3.he.net.domain: 22043% [1au][|domain]
08:52:09.227687 IP6 (hlim 59, next-header UDP (17) payload length: 161) ns3.he.net.domain > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401: 26260*- q:[|domain]
08:52:09.231690 IP6 (hlim 59, next-header UDP (17) payload length: 122) ns3.he.net.domain > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401: 22043*- q:[|domain]
08:52:09.671697 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 1
08:52:10.671724 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 2
08:52:11.671751 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 3
08:52:12.671783 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 4
08:52:13.671805 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 5
08:52:13.863810 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) mosimossystems.tunnel.tserv12.mia1.ipv6.he.net > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net
08:52:13.863810 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > mosimossystems.tunnel.tserv12.mia1.ipv6.he.net: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net, Flags [router, solicited]
08:52:13.867968 IP6 (hlim 64, next-header UDP (17) payload length: 109) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401 > ns2.he.net.domain: 60284% [1au][|domain]
08:52:13.955903 IP6 (hlim 64, next-header UDP (17) payload length: 109) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401 > ns2.he.net.domain: 5671% [1au][|domain]
08:52:14.027815 IP6 (hlim 58, next-header UDP (17) payload length: 158) ns2.he.net.domain > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401: 60284*- q:[|domain]
08:52:14.111817 IP6 (hlim 58, next-header UDP (17) payload length: 122) ns2.he.net.domain > mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net.40401: 5671*- q:[|domain]
08:52:14.671832 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) mosimossystems-pt.tunnel.tserv12.mia1.ipv6.he.net > 2002:a0a:a02:5678:211:24ff:fe42:ebb6: [icmp6 sum ok] ICMP6, echo reply, length 16, seq 6
Results on the local machine.
dscott@praying-mantis:~$ ping6 2001:470:4:35::2
PING6(56=40+8+8 bytes)
2002:a0a:a02:5678:211:24ff:fe42:ebb6 --> 2001:470:4:35::2
^C
--- 2001:470:4:35::2 ping6 statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
dscott@praying-mantis:~$ date
Tue Oct 14 08:53:22 EDT 2008
dscott@praying-mantis:~$
My Current radvd.conf file
#
# This is set for our servers
#
#interface eth0 {
# IgnoreIfMissing off;
# AdvHomeAgentFlag off;
# MinRtrAdvInterval 3;
# MaxRtrAdvInterval 10;
# AdvSendAdvert off;
# prefix 2001:470:d848:1234::/64
# prefix 2001:470:5:35::/64
# {
# AdvRouterAddr on;
# AdvOnLink on;
# AdvAutonomous off;
# Base6to4Interface eth0;
# };
#};
#
# This is set for the local machines
#
interface eth1 {
IgnoreIfMissing on;
AdvHomeAgentFlag on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSendAdvert on;
prefix 2001:470:d848:5678::/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
Base6to4Interface eth1;
};
};
My Routing table now
Quote
root@426-624:~$ ip -6 route show
2001:470:4:35::/64 dev eth0 proto kernel metric 256 expires 2424346sec mtu 1500 advmss 1440 metric 10 4294967295
2001:470:4:35::/64 via :: dev sixbone metric 256 expires 21166404sec mtu 1480 advmss 1420 metric 10 4294967295
fe80::/64 dev eth0 metric 256 expires 21166394sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 dev eth1 metric 256 expires 21166394sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 via :: dev sixbone metric 256 expires 21166404sec mtu 1480 advmss 1420 metric 10 4294967295
ff00::/8 dev eth0 metric 256 expires 21166394sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev eth1 metric 256 expires 21166394sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev sixbone metric 256 expires 21166404sec mtu 1480 advmss 1420 metric 10 4294967295
default dev sixbone metric 1024 expires 21166404sec mtu 1480 advmss 1420 metric 10 4294967295
unreachable default dev lo proto none metric -1 error -101 metric 10 255
root@426-624:~$
the other way.
Quote
root@426-624:~$ route -6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: Un 0 1 68 lo
2001:470:4:35::/128 :: Un 0 2 0 lo
2001:470:4:35::/128 :: Un 0 2 0 lo
2001:470:4:35::2/128 :: Un 0 1 1825 lo
2001:470:4:35:210:5aff:fea0:6b23/128 :: Un 0 1 488 lo
2001:470:4:35::/64 :: UAe 256 0 0 eth0
2001:470:4:35::/64 :: Un 256 0 21 sixbone
fe80::/128 :: Un 0 2 0 lo
fe80::/128 :: Un 0 2 0 lo
fe80::4658:b266/128 :: Un 0 1 0 lo
fe80::210:5aff:fea0:6b23/128 :: Un 0 1 325 lo
fe80::210:5aff:fee0:4902/128 :: Un 0 1 434 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: Un 256 0 0 sixbone
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixbone
::/0 :: U 1024 0 0 sixbone
::/0 :: !n -1 1 1 lo
root@426-624:~$
Seems there are differences reported from the program route and ip.
Both, 2001:470:4:35::/64 and 2001:470:5:35::/64 route down your tunnel. One is for use on the tunnel interface (The Tunnel Details page calls it the "Server/Client IPv6 address"), the other is for local network usage (The Tunnel Details page calls it "Routed /64").
If you use Base6to4Interface in ravd.conf, then you're forcing it to change the prefix to 2002:aabb:ccdd: (derived from the public IPv4 address, aaa.bbb.ccc.ddd on the interface supplied). Based on your set up the only valid Base6to4Interface value MUST be eth0 (because that's your only public IPv4 interface). Since you don't want to announce a 2002:: prefix, you actually want to totally remove the Base6to4Interface entry entirely! If you don't remove Base6to4Interface, then the supplied prefix is ignored.
Dave, I think I understand what the person is saying.
Look at the help I got on my Post : http://www.tunnelbroker.net/forums/index.php?topic=224.0 (http://www.tunnelbroker.net/forums/index.php?topic=224.0)
Your symptoms are very similar to what I had.
Can you post your config page from HE ? I used my config to illustrate what I think you have to do.
1) Create the tunnel interface (you call it sixbone) and assign the v6 address labeled "Client IPv6 address to it". Obviously the other end of the tunnel is the Server IPv6 address. Looks like you did this.
2) On your eth1 internal interface assign the address range labeled Routed /48. This is your "inside range" Note it says /48 but when i did my set up we used /64.
3) on your eth0 outside interface assign the range labeled "Routed /64"
Notes: What I noticed from your ifconfig was that your tunnel and eth0 has the same range. I think this is wrong:
tunnel = 2001:470:4:35::2
eth0 = 2001:470:4:35::3
eth1 = 2001:479:4:35::4
Notice your tunnel and eth0 have the same prefix...To me this is like saying that eth0 is at 4.2.2.2 and your tunnel is at 4.2.2.3. Same subnet. Thats not going to work i don't think. Conceptually ALL your IPv6 traffic is going out your tunnel and coming in your tunnel. In my opinion in order for the traffic to route correctly each interface has to be a different subnet (even though the tunnel technically is on eth0, its virtual though think of it as physically separate)
just in case i was reading your post wrong you also did the same thing in an earlier ifconfig:
eth0 Link encap:Ethernet HWaddr 00:10:5a:a0:6b:23
inet6 addr: 2001:470:4:35::102/64 Scope:Global
inet6 addr: 2001:470:4:35:210:5aff:fea0:6b23/64 Scope:Global
inet6 addr: fe80::210:5aff:fea0:6b23/64 Scope:Link
sixbone Link encap:UNSPEC HWaddr 46-58-B2-66-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2001:470:4:35::2/64 Scope:Global
inet6 addr: fe80::4658:b266/128 Scope:Link
eth1 Link encap:Ethernet HWaddr 00:10:5a:e0:49:02
inet6 addr: 2001:470:d848::1/48 Scope:Global
inet6 addr: fe80::210:5aff:fee0:4902/64 Scope:Link
notice again your tunnel and eth0 have the same prefix.
Below is a edited pic of the front page of my HE tunnel config:
(http://www.ketema.net/heconfig2.png)
obviously your info is different. but i think if you assign the same ranges as specified you might start to work.
The way I understand it your router and ipv6 is smart. By assigning the different prefixes to the different interfaces the router broadcasts the fact that it is a gateway for that subnet. So all your internal hosts automatically configure up with the /48 prefix. all your outside computers that are plugged into the switch that only sees eth0 of your router box auto configure to the "Routed /64" prefix, and your tunnel is the final default gateway so to speak.
Here also is my routers interfaces to show an example:
r2811:322 #show ipv6 interface
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::217:59FF:FE71:5438
Description: [b]outside[/b]
Global unicast address(es):
2001:470:5:138::, subnet is [b]2001:470:5:138[/b]::/64 [ANY]
FastEthernet0/1 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::217:59FF:FE71:5439
Description: inside
Global unicast address(es):
2001:470:D847::1, subnet is 2001:470:D847::/64
Tunnel0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::472B:CF34
Description: HE IPv6 Tunnel Broker
Global unicast address(es):
2001:470:4:138::2, subnet is 2001:470:4:138::/64
Notice how the tunnel and eth0 (outside) are different prefix (by one number...4 instead of 5 after the 470).
With this set up I can ping from the out side:
1) my tunnel address: 2001:470:4:138::2
2) any host on the inside : 2001:470:d847::217:f2ff:fe05:1e70 (my macpro)
3) the outside ipv6 broadcast address 2001:470:5:138:: and any address that becomes auto configured from the outside interface of the router: 2001:470:5:138:205:9bff:feca:316c (i plugged in a pc directly to the last port on my cable modem where the outside interface of the router is and if fired right up)
So I think although you are using Linux and not routers, if you follow this setup it should work. If it does not you may want to contact broquea who helped me out, to ensure your tunnel is routing correctly.
In case my rambling made no sense....This post seems closer to what you are doing:
http://www.tunnelbroker.net/forums/index.php?topic=142.0 (http://www.tunnelbroker.net/forums/index.php?topic=142.0)
Ok, So what I had thought was my issue, routing only. So I started over.
My tunnel is up, 2001:470:4:35::/64; ::1 is HE end point; ::2 is my endpoint
eth0 is statically assigned 2001:470:5:35::102 (still not routing)
eth1 is statically assigned 2001:470:d848:210::102 (internal machine now working on I6)
local machine connected to eth1 gets this IP
2001:0470:d848:0210:0211:24ff:fe42:ebb6
The issue is as now, everything in the replies state that my eth0 should never be assigned a 2001:470:4:35::/64 IP, however, after rebooting, I performed an ifconfig eth0 and here are my results.
Quote
eth0 Link encap:Ethernet HWaddr 00:10:5a:a0:6b:23
inet addr:70.88.178.102 Bcast:70.88.178.111 Mask:255.255.255.240
inet6 addr: 2001:470:5:35::102/64 Scope:Global
inet6 addr: 2001:470:4:35:210:5aff:fea0:6b23/64 Scope:Global
inet6 addr: fe80::210:5aff:fea0:6b23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8020 errors:0 dropped:0 overruns:0 frame:0
TX packets:8982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3510852 (3.3 MiB) TX bytes:1270154 (1.2 MiB)
Interrupt:10 Base address:0x6f00
The bold interface I did not give this IP. this IP was auto generated.
Here is my radvd.conf file now.
Quote#
# This is set for our servers
#
interface eth0 {
# IgnoreIfMissing off;
# AdvHomeAgentFlag off;
# MinRtrAdvInterval 3;
# MaxRtrAdvInterval 10;
# AdvSendAdvert off;
prefix 2001:470:5:35::102/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous off;
# Base6to4Interface eth0;
};
};
#
# This is set for the local machines
#
interface eth1 {
IgnoreIfMissing on;
AdvHomeAgentFlag on;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
AdvSendAdvert on;
prefix 2001:470:d848:210::/64
{
AdvRouterAddr on;
AdvOnLink on;
AdvAutonomous on;
# Base6to4Interface eth1;
};
};
As you can see the base6to4interface option is turned off, on both eth0 and eth1. The machine connected to eth1 receives/generates this ip
2001:0470:d848:0210:0211:24ff:fe42:ebb6, which seems correct from the radvd.conf file. However, I'm lost as to WHY the
2001:470:4:35:210:5aff:fea0:6b23 is being generated for the machines connected to eth0.
Also on a machine connected to eth0 it too generated a
2001:470:4:35::/ address; After I assigned it an address of
2001:470:5:35::/ address.
By way of saying the prefix is ignored if you leave the base6to4interface option off, seems to be incorrect.
I am now attempting to delete the
2001:470:5:35::/ interface on the machine connected to eth0.
"prefix 2001:470:5:35::102/64" is invalid, so radvd should have refused to read it, you probably wanted "prefix 2001:470:5:35::/64".
Base6to4Interface is only for 6to4 addresses, which have to start with 2002:
All other addresses like 2001: are 6in4. (There's also 6over4, but that requires IPv4 multicast)
Quote"prefix 2001:470:5:35::102/64" is invalid, so radvd should have refused to read it, you probably wanted "prefix 2001:470:5:35::/64".
Changed, restarted. Yeah I missed that one, when I was changing the prefix.
prefix 2001:470:5:35::/64 {
QuoteBase6to4Interface is only for 6to4 addresses, which have to start with 2002:
All other addresses like 2001: are 6in4. (There's also 6over4, but that requires IPv4 multicast)
I understand more now what base6to4interface means.
Now my internals are working fine.
The eth0 (2001:470:5:35::/64) are not routing.
machine connected on the eth0 get the ip generated from 2001:470:4:35::/64 and I have statically assigned 2001:470:5:35::/64 addresses. With either interface removed, I get no response from ping6.
I have tcpdump -vvisixbone and have NO traffic traversing on this interface.
My understand is that these interfaces with routing should work like this.
- ext_eth0(2001:470:5:35::98) -> router_eth0 (2001:470:5:35::102) --(r_eth0_tunnel)--> world
- ext_eth1(2001:0470:d848:0210:0211:24ff:fe42:ebb6) -> router_eth1(2001:470:d848:210::2) --(r_eth0_tunnel)-->world
cat /proc/sys/net/ipv6/conf/all/forwarding
1
In #2 the rules and routing works fine, but in #1 it doesn't
so I'm a little confused, WHY it works for all generated IPs but not for statics.
Here's my routing.
Quote
root@426-624:~$ ip -f inet6 addr
1: lo: <LOOPBACK,UP,10000> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
inet6 2001:470:5:35::102/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::210:5aff:fea0:6b23/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qlen 1000
inet6 2001:470:d848:210::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::210:5aff:fee0:4902/64 scope link
valid_lft forever preferred_lft forever
5: sixbone@NONE: <POINTOPOINT,NOARP,UP,10000> mtu 1480
inet6 2001:470:4:35::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4658:b266/128 scope link
valid_lft forever preferred_lft forever
root@426-624:~$
Quoteroot@426-624:~$ route -6
Kernel IPv6 routing table
Destination Next Hop Flag Met Ref Use If
::1/128 :: Un 0 1 2 lo
2001:470:4:35::/128 :: Un 0 2 0 lo
2001:470:4:35::2/128 :: Un 0 1 206 lo
2001:470:4:35::/64 :: UAe 256 0 0 eth0
2001:470:4:35::/64 :: Un 256 0 7 sixbone
2001:470:5:35::/128 :: Un 0 2 0 lo
2001:470:5:35::102/128 :: Un 0 1 4946 lo
2001:470:5:35::/64 :: U 256 0 0 eth0
2001:470:d848:210::/128 :: Un 0 2 0 lo
2001:470:d848:210::2/128 :: Un 0 1 0 lo
2001:470:d848:210::/64 :: U 256 0 0 eth1
fe80::/128 :: Un 0 2 0 lo
fe80::/128 :: Un 0 2 0 lo
fe80::4658:b266/128 :: Un 0 1 0 lo
fe80::210:5aff:fea0:6b23/128 :: Un 0 1 71 lo
fe80::210:5aff:fee0:4902/128 :: Un 0 1 201 lo
fe80::/64 :: U 256 0 0 eth0
fe80::/64 :: U 256 0 0 eth1
fe80::/64 :: Un 256 0 0 sixbone
ff00::/8 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 sixbone
::/0 :: U 1024 0 0 sixbone
::/0 :: !n -1 1 1 lo
root@426-624:~$
Quoteroot@426-624:~$ ip -6 route show
2001:470:4:35::/64 dev eth0 proto kernel metric 256 expires 2587235sec mtu 1500 advmss 1440 metric 10 4294967295
2001:470:4:35::/64 via :: dev sixbone metric 256 expires 21329294sec mtu 1480 advmss 1420 metric 10 4294967295
2001:470:5:35::/64 dev eth0 metric 256 expires 21329294sec mtu 1500 advmss 1440 metric 10 4294967295
2001:470:d848:210::/64 dev eth1 metric 256 expires 21329294sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 dev eth0 metric 256 expires 21329284sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 dev eth1 metric 256 expires 21329284sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 via :: dev sixbone metric 256 expires 21329294sec mtu 1480 advmss 1420 metric 10 4294967295
ff00::/8 dev eth0 metric 256 expires 21329284sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev eth1 metric 256 expires 21329284sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev sixbone metric 256 expires 21329294sec mtu 1480 advmss 1420 metric 10 4294967295
default dev sixbone metric 1024 expires 21329294sec mtu 1480 advmss 1420 metric 10 4294967295
unreachable default dev lo proto none metric -1 error -101 metric 10 255
root@426-624:~$
Obviuosly I'm missing something, but i don't know what it is.
And a traceroute for good measures.
This machine is connected using #2 method from the list.
Quotedscott@praying-mantis:~$ traceroute6 www.kame.net
traceroute6 to www.kame.net (2001:200::8002:203:47ff:fea5:3085) from 2001:470:d848:210:211:24ff:fe42:ebb6, 30 hops max, 12 byte packets
1 2001:470:d848:210::2 2.527 ms 0.497 ms 0.338 ms
2 mosimossystems.tunnel.tserv12.mia1.ipv6.he.net 71.159 ms 57.227 ms 53.755 ms
3 gige-g2-3.core1.mia1.he.net 91.377 ms 83.193 ms 62.291 ms
4 10gigabitethernet5-4.core1.ash1.he.net 147.951 ms 82.864 ms 94.619 ms
5 10gigabitethernet1-4.core1.pao1.he.net 222.191 ms 169.027 ms 158.128 ms
6 3ffe:80a::b2 158.137 ms 175.952 ms 159.419 ms
7 hitachi1.otemachi.wide.ad.jp 302.993 ms 298.247 ms 320.554 ms
8 2001:200::1802:20c:dbff:fe1f:7200 298.983 ms 318.593 ms 301.464 ms
9 ve42.foundry4.nezu.wide.ad.jp 298.579 ms 303.126 ms 300.563 ms
10 ve45.nec2.yagami.wide.ad.jp 306.628 ms 306.271 ms 310.875 ms
11 lo0.alaxala1.k2.wide.ad.jp 301.517 ms 324.224 ms 301.983 ms
12 orange.kame.net 300.101 ms 301.773 ms 298.732 ms
dscott@praying-mantis:~$
another machine; this machine connected using #1 method in the list.
Quoteroot@femur:~$ traceroute6 www.kame.net
traceroute to www.kame.net (2001:200:0:8002:203:47ff:fea5:3085) from 2001:470:5:35::98, 30 hops max, 16 byte pack
ets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * *
It is most certainly a routing issue, not a connection issue.
Quoteroot@femur:~$ ping6 2001:470:5:35::102
PING 2001:470:5:35::102(2001:470:5:35::102) 56 data bytes
64 bytes from 2001:470:5:35::102: icmp_seq=1 ttl=64 time=0.293 ms
64 bytes from 2001:470:5:35::102: icmp_seq=2 ttl=64 time=0.245 ms
--- 2001:470:5:35::102 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.245/0.269/0.293/0.024 ms
root@femur:~$ traceroute6 2001:470:5:35::102
traceroute to 2001:470:5:35::102 (2001:470:5:35::102) from 2001:470:5:35::98, 30 hops max, 16 byte packets
1 2001:470:5:35::102 (2001:470:5:35::102) 0.413 ms 0.476 ms 0.836 ms
root@femur:~$
And the other way
Quoteroot@426-624:~$ ping6 2001:470:5:35::98
PING 2001:470:5:35::98(2001:470:5:35::98) 56 data bytes
64 bytes from 2001:470:5:35::98: icmp_seq=1 ttl=64 time=0.000 ms
64 bytes from 2001:470:5:35::98: icmp_seq=2 ttl=64 time=0.272 ms
--- 2001:470:5:35::98 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.000/0.136/0.272/0.136 ms
root@426-624:~$ traceroute6 2001:470:5:35::98
traceroute to 2001:470:5:35::98 (2001:470:5:35::98) from 2001:470:5:35::102, 30 hops max, 16 byte packets
1 2001:470:5:35::98 (2001:470:5:35::98) 0 ms 0 ms 0.313 ms
root@426-624:~$
It seems that all the routing performed on eth0 are just ignored, not drop, as i would/should have seen some traffic coming in.
Quote from: mosimossystems on October 15, 2008, 08:17:14 AMObviuosly I'm missing something, but i don't know what it is.
You still have 2001:470:4:35::/64 routed to sixbone and eth0. You must delete the route to 2001:470:4:35::/64 via eth0
Quote
You still have 2001:470:4:35::/64 routed to sixbone and eth0. You must delete the route to 2001:470:4:35::/64 via eth0
I remove that route, and the same results are occurring.
Quotedscott@426-624 [~] $ ip -6 route show
2001:470:4:35::/64 via :: dev sixbone metric 256 expires 21326011sec mtu 1480 advmss 1420 metric 10 4294967295
2001:470:5:35::/64 dev eth0 metric 256 expires 21326011sec mtu 1500 advmss 1440 metric 10 4294967295
2001:470:d848:210::/64 dev eth1 metric 256 expires 21326011sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 dev eth0 metric 256 expires 21326001sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 dev eth1 metric 256 expires 21326001sec mtu 1500 advmss 1440 metric 10 4294967295
fe80::/64 via :: dev sixbone metric 256 expires 21326011sec mtu 1480 advmss 1420 metric 10 4294967295
ff00::/8 dev eth0 metric 256 expires 21326001sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev eth1 metric 256 expires 21326001sec mtu 1500 advmss 1440 metric 10 4294967295
ff00::/8 dev sixbone metric 256 expires 21326011sec mtu 1480 advmss 1420 metric 10 4294967295
default dev sixbone metric 1024 expires 21326011sec mtu 1480 advmss 1420 metric 10 4294967295
unreachable default dev lo proto none metric -1 error -101 metric 10 255
426-624.mosimos-systems.com
AS well as no matter HOW many times I remove the interface 2001:470:4:35::/64 addresses, they still auto-generate.
Quote
root@femur:~$ ifconfig eth0 inet6 del 2001:470:4:35:204:5aff:fea7:1053/64
root@femur:~$ ping6 2001:470:4:35::2
PING 2001:470:4:35::2(2001:470:4:35::2) 56 data bytes
From 2001:470:5:35::98 icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:5:35::98 icmp_seq=2 Destination unreachable: Address unreachable
From 2001:470:5:35::98 icmp_seq=3 Destination unreachable: Address unreachable
From 2001:470:4:35:204:5aff:fea7:1053 icmp_seq=5 Destination unreachable: Address unreachable
From 2001:470:4:35:204:5aff:fea7:1053 icmp_seq=6 Destination unreachable: Address unreachable
From 2001:470:4:35:204:5aff:fea7:1053 icmp_seq=7 Destination unreachable: Address unreachable
--- 2001:470:4:35::2 ping statistics ---
9 packets transmitted, 0 received, +6 errors, 100% packet loss, time 8012ms
root@femur:~$
I have completed removed eth0 from my radvd.conf I supposed it is time to start utilizing ip6tables. :-\
Sounds to me like your tunnel is broadcasting its prefix. This is causing eth0 which where the tunnel physically resides, to assign itself an address in that prefix as well. What is the equivalent Linux command for ipv6 nd suppress-ra
which on a router tells it to "Suppress IPv6 Router Advertisements".
Also is there a way to test but having one of your machines that is connected to eth0 on your linux router NOT autoconfigure? If you statically set one with the 2001:470:5:35::/64 prefix see if it works
Quote from: moc on October 15, 2008, 09:56:12 AM
Sounds to me like your tunnel is broadcasting its prefix. This is causing eth0 which where the tunnel physically resides, to assign itself an address in that prefix as well. What is the equivalent Linux command for ipv6 nd suppress-ra
which on a router tells it to "Suppress IPv6 Router Advertisements".
Also is there a way to test but having one of your machines that is connected to eth0 on your linux router NOT autoconfigure? If you statically set one with the 2001:470:5:35::/64 prefix see if it works
So it seems the issue that I seem to be having, is I turned everything off, unset the IP's for all my interfaces, for the IPv6, except for the tunnel, the only thing that should be working on the IPv6 is my machine connected to the tunnel.
HOWEVER, my tunnel seems to be broadcasting that it has an IP of (2001:470:4:35::2/64 or something to that nature), therefore my other machines, that have IPv6 enable but do not have addressees at all. Automatically re-assign the prefix (2001:470:4:35) to the link local address.
Again, i turned off radvd, and unassigned all interfaces that previously had an Ipv6 address.
The question now, is how to I keep my tunnel IP from broadcasting?
Quote from: mosimossystems on October 18, 2008, 01:31:01 AMAgain, i turned off radvd, and unassigned all interfaces that previously had an Ipv6 address.
The question now, is how to I keep my tunnel IP from broadcasting?
To my knowledge on linux, if you shutdown radvd, then that stops all router advertisements. If you shutdown radvd, and you're still getting auto-configuration happening on the network, then check for another copy of radvd running, either on the router (maybe it never got stopped for some reason), or on another machine on the network - you should be able to tell where the router adverts are coming from based on the 'default' route that gets set on the other machines.
Just to clarify, you should only have one copy of radvd running on the entire network, and it should be on the router only.
Quote from: normanr on October 18, 2008, 02:35:20 AM
Quote from: mosimossystems on October 18, 2008, 01:31:01 AMAgain, i turned off radvd, and unassigned all interfaces that previously had an Ipv6 address.
The question now, is how to I keep my tunnel IP from broadcasting?
To my knowledge on linux, if you shutdown radvd, then that stops all router advertisements. If you shutdown radvd, and you're still getting auto-configuration happening on the network, then check for another copy of radvd running, either on the router (maybe it never got stopped for some reason), or on another machine on the network - you should be able to tell where the router adverts are coming from based on the 'default' route that gets set on the other machines.
Just to clarify, you should only have one copy of radvd running on the entire network, and it should be on the router only.
I did verify that radvd was not running. And the prefix was still prepended. After doing some seriuos searching, I found that the PIX i have here, was configured with the 2001:470:4:35::/64 prefix, and by default the cisco router will advertise that it is a route for that prefix, which will cause all device connected to the network that the cisco's interface is connected to, to auto assign prefix to link local.
So lesson learned..
In the end, I'm looking really dumb, for not checking the cisco first.
Thanks to all you how attempted to show me the way. Thanks noc, i should i looked at the cisco when you gave that hint about advertisement.
So if you have a cisco router, and are running into issue with you tunnel NOT working correctly, turn off or unassign IPv6 on the cisco first. Then check your network.
hey cool glad you found it. ipv6 nd suppress-ra
run that on the pix interface (i reserve the right for that to be wrong, pix and routers are similar but command can be different)...Any way that should allow you to keep the pix having a ipv6 address but not advertise.
Quote from: moc on October 18, 2008, 10:01:24 AM
hey cool glad you found it. ipv6 nd suppress-ra
run that on the pix interface (i reserve the right for that to be wrong, pix and routers are similar but command can be different)...Any way that should allow you to keep the pix having a ipv6 address but not advertise.
Yes the pix took that command. And routing still works... sometimes I amaze myself how overlooking i can be.. :-\
UPDATE
So my tunnel is working great, thanks everyone for the help they gave.
Now just to figure out what is causing radvd to stop responding, and dropping the connections altogether.
:) I know it is not the PIX, as I have disable ipv6 at this point.
So thanks again.