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

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Main Menu

Recent posts

#1
Questions & Answers / Re: Google simple CE machine t...
Last post by snarked - January 01, 2025, 11:58:17 AM
Check your IPv6 address instructions:  Make certain your "xxx" field is an odd number as that is used for the tunnel endpoints.  An even "xxx" is used for the routed /64 at your site (usually on Ethernet), and thus does not belong on the point-to-point interface.
#2
Questions & Answers / Re: Google simple CE machine t...
Last post by rattila - January 01, 2025, 04:35:53 AM
Addendum:

he-ipv6: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1480
        inet6 2001:470:1f1a:xxx::2  prefixlen 64  scopeid 0x0<global>
        sit  txqueuelen 1000  (IPv6-in-IPv4)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 191  dropped 0 overruns 0  carrier 191  collisions 0

Something wrong! There are TX error and carrier and no TX packets!
Where could be the problem? In my config (VM) or Google part (filtered protocol)?

I know there is native IPv6 support many GCEs except this very small (almost hobbyist) machines.

TIA,
Ruzsi
#3
Questions & Answers / Google simple CE machine tunne...
Last post by rattila - January 01, 2025, 04:20:39 AM
Hi,

I've got a very cheap originally free tier compute engine (VM).
I setup my tunnel and the remote end doesn't answer for ping:
root@ub2-1:/etc/netplan# ping 2001:470:1f1a:xxx::1
PING 2001:470:1f1a:xxx::1(2001:470:1f1a:xxx::1) 56 data bytes
From 2001:470:1f1a:xxx::2 icmp_seq=1 Destination unreachable: Address unreachable

I open up the firewall for the tunnel server IP address which the Budapest server.
I didn't get any packet from the server checking tcpdump ens4.

I read somewhere google doesn't allow tunnel protocol 41 (IPv6 encap).
Is that true?

TIA,
Ruzsi
#4
General Questions & Suggestions / HE Dynamic DNS Settings
Last post by Pivson - December 27, 2024, 02:10:19 PM
I understand the tunnel settings (tunnelbroker.net)
    My tunnel >> Advanced >> HE Dynamic DNS Settings >> Hostname

a) Does it work so that after updating my IPv4 address, the address of the DNS record in the domain is set at the same time?

b) Is there any way to set up more than one domain/subdomain here (with Hostname)?


Thanks for the answers.
#5
Then test

mtr <IP of tunnel endpoint>
It it maybe a problem in the connection between you and your ISP or your ISP between the HE tunnel server.
#6
Thanks, just tried that out and looks like I'm seeing packet loss right at my tunnel's endpoint and then continues from there until it hits Cloudflare's DNS server.


#7
IPv6 Basics & Questions & General Chatter / Re: selective failure pinging ...
Last post by PMch - December 17, 2024, 07:38:54 PM

Can it be a problem with the destination site (wand.daemon.contact in the example above)?

I have two tunnel endpoint IPv6 adresses (tunnel123456-pt.tunnel.etc.etc.he.net and tunnel123456.tunnel.etc.etc.he.net), and both of them show just the same 50% failures.

One of these is run entirely by HE, so it doesn't look like a flaw on my side. :(
#8
IPv6 Basics & Questions & General Chatter / selective failure pinging my t...
Last post by PMch - December 17, 2024, 11:15:11 AM
Hi,

a network failure suddenly appeared today at 01:40Z. No changes have happened.

Analysis showed that I can still reach some of my tunnels, and the behaviour is different for UDP, TCP and ICMP6 and for different targets. I found that it is also different for different sources.

For ping/ICMP6 it currently looks like this:
                                                tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    FAIL    FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        ok      FAIL    FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      ok      ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    ok      ok

tcpdump shows the packets depart from origin into the Internet (into DSL in this case), but no gif-encapsulated packet appears on the interface of the destination system.

I have no clue on why or where on the network they might disappear.

Pinging the two tunnel endpoints (ingress and egress) shows a different pattern again:
ingress                                         tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    ok      FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        FAIL    ok      FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      FAIL    ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    FAIL    FAIL
egress                                          tun-1   tun-2   tun-3
from 2003:e7:171d:6eff::1                       FAIL    ok      FAIL
from 2003:e7:171d:6ee1:41d:92ff:fe01:104        ok      ok      FAIL
from 2003:e7:171d:6ee0:41d:92ff:fe01:105        ok      ok      ok
from 2003:e7:17ff:f22:41d:92ff:fe01:301         FAIL    FAIL    ok


# ifconfig vtnet0
vtnet0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
        ether 06:1d:92:01:03:01
        inet 192.168.98.34 netmask 0xfffffffc broadcast 192.168.98.35
        inet6 fe80::2%vtnet0 prefixlen 64 scopeid 0x1
        inet6 2003:e7:1731:3cff::20 prefixlen 64
        inet6 2003:e7:1731:3cff::21 prefixlen 64
        inet6 2003:e7:1731:3cff::22 prefixlen 64
        inet6 2003:e7:1731:3cff::23 prefixlen 64
        inet6 2003:e7:1731:3cff::24 prefixlen 64
        inet6 2003:e7:1731:3cff::25 prefixlen 64
        inet6 2003:e7:1731:3cff::26 prefixlen 64
        inet6 2003:e7:1731:3cff::27 prefixlen 64
        inet6 2003:e7:1731:3cff::28 prefixlen 64
        inet6 2003:e7:1731:3cff::29 prefixlen 64
        media: Ethernet autoselect (10Gbase-T <full-duplex>)
        status: active
        nd6 options=1<PERFORMNUD>

# for i in 20 21 22 23 24 25 26 27 28 29; do ping -q -c 1 -S 2003:e7:1731:3cff::$i wand.daemon.contact >/dev/null 2>&1 && echo $i okay; done
21 okay
23 okay
24 okay
25 okay
26 okay
28 okay

The pattern reproduces. Over all quite precisely 50% failure rate.

However, trying google, or freebsd.org:

# for i in 20 21 22 23 24 25 26 27 28 29; do ping -q -c 1 -S 2003:e7:1731:3cff::$i freebsd.org >/dev/null 2>&1 && echo $i okay; done
20 okay
21 okay
22 okay
23 okay
24 okay
25 okay
26 okay
27 okay
28 okay
29 okay

So, it is not a problem with the IPv6 on this originating site (or with the router or whatever here).
#9
Please use mtr <Target-IP>
to check where the problem occurs.

I had a similar problem and the issue was the connecting between my ISP and en exchange point.
#10
Hi everyone, over the past month or so I've noticed quite a bit of packet loss to the Toronto peering point.  It's anywhere from 3%-15% at times and it becomes unusable.  Anyone know what's going on?