[SOLVED] ipv6 stops working upon adding another address
ping6 google.com' works out of the box, then as soon as I run
sudo ip -6 addr add 2600:3c00::f/64 dev eth0', it stops working (100% packet loss). If I remove the address with `sudo ip -6 addr del 2600:3c00::f/64 dev eth0', it starts working again.
(after adding second ip)
ip -6 addr
1: lo: <loopback,up,lower_up>mtu 65536
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: eth0: <broadcast,multicast,up,lower_up>mtu 1500 qlen 1000
inet6 2600:3c00::f/64 scope global
valid_lft forever preferred_lft forever
inet6 2600:3c00::f03c:91ff:fe89:57a/64 scope global dynamic
valid_lft 2591987sec preferred_lft 604787sec
inet6 fe80::f03c:91ff:fe89:57a/64 scope link
valid_lft forever preferred_lft forever</broadcast,multicast,up,lower_up></loopback,up,lower_up>
Appears to be the same after adding IP
ip -6 route show
2600:3c00::/64 dev eth0 proto kernel metric 256 expires 2591976sec
fe80::/64 dev eth0 proto kernel metric 256
default via fe80::1 dev eth0 proto ra metric 1024 expires 66sec
sudo ip6tables-save
# Generated by ip6tables-save v1.4.21 on Sun Dec 14 19:21:08 2014
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [29:2816]
:POSTROUTING ACCEPT [29:2816]
COMMIT
# Completed on Sun Dec 14 19:21:08 2014
# Generated by ip6tables-save v1.4.21 on Sun Dec 14 19:21:08 2014
*security
:INPUT ACCEPT [143:13344]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [159:14432]
COMMIT
# Completed on Sun Dec 14 19:21:08 2014
# Generated by ip6tables-save v1.4.21 on Sun Dec 14 19:21:08 2014
*raw
:PREROUTING ACCEPT [145:13456]
:OUTPUT ACCEPT [159:14432]
COMMIT
# Completed on Sun Dec 14 19:21:08 2014
# Generated by ip6tables-save v1.4.21 on Sun Dec 14 19:21:08 2014
*mangle
:PREROUTING ACCEPT [145:13456]
:INPUT ACCEPT [143:13344]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [159:14432]
:POSTROUTING ACCEPT [159:14432]
COMMIT
# Completed on Sun Dec 14 19:21:08 2014
# Generated by ip6tables-save v1.4.21 on Sun Dec 14 19:21:08 2014
*filter
:INPUT ACCEPT [39:3776]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [159:14432]
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 137 -m hl --hl-eq 255 -j ACCEPT
COMMIT
# Completed on Sun Dec 14 19:21:08 2014
10 Replies
That seems highly unlikely; I'd recommend confirming what IPv6 ranges your Linode has in the Remote Access tab.
- Les
@akerl:
Does "2600:3c00::f/64" actually belong to you?
That seems highly unlikely; I'd recommend confirming what IPv6 ranges your Linode has in the Remote Access tab.
- Les
Hm. According to this calculator:http://www.tunnelsup.com/subnet-calculator I should have 2600:3C00:0000:0000:0000:0000:0000:0000 - 2600:3C00:0000:0000:FFFF:FFFF:FFFF:FFFF, which 2600:3c00::f/64 belongs to.
Unless I'm doing something horribly incorrect.
EDIT: according to the Linode Manager, I have 2600:3c00::f03c:91ff:fe89:057a / 64
-Chris
-Chris
@caker:
These may be useful:
https://www.linode.com/docs/networking/ … ress-pools">https://www.linode.com/docs/networking/native-ipv6-networking#ipv6-address-pools
https://www.linode.com/docs/networking/ … ipv6-pools">https://www.linode.com/docs/networking/native-ipv6-networking#ipv6-pools -Chris
mentions something along the lines of Public IP Pools showing in the remote access tab of the Linode manager, which certainly is not the case. It also says that the default pool size is /64, which I interpret as the last 16 hex digits of the IP being fully addressable to me. Since it appears to not be displaying my pool, I GUESS that it is 2600:3c00:0000:0000::/64. https://www.linode.com/docs/networking/ … networking">https://www.linode.com/docs/networking/native-ipv6-networking :?
@caker:
They show up after you open a ticket and request a pool from us
:) -Chris
Well, that should be shown more prominently in the ipv6 documentation (at the top):)
> Additional blocks of IPv6 addresses may be requested at no charge
@akerl:
It does say that; it's the first sentence of the section on additional IPv6 addresses:
> Additional blocks of IPv6 addresses may be requested at no charge
Aware. It's just a basic requirement of the guide to have an ipv6 block, which is apparently not default.
And putting a similar note at the top of the guide wouldn't hurt, either.