AS overview
Test target: 2a02:6b8::1 · ns1.yandex.net · address space: unknown · prefixes announced: 18
prefix(es): 2a02:6b8::/32, 2a02:6b8:4::/48, 2a02:6b8:a::/48, 2a0e:fd87::/32, 2a0e:fd80::/32, 2a02:6b8:e::/48, 2a02:6b8:5::/48, 2a02:6b8:215::/48 (+10 more)
Targets & per-vantage-point probe results (10 target(s) across 3 vantage point(s))
Source codes (hover any badge for full description): CUR=curated · NS/SOA/MX=DNS records · SPF=SPF TXT · DRV=holder-derived (www, ns1, mail, gw, …) · ATL=RIPE Atlas · PDB=PeeringDB · WHOIS=RIPE whois · RDAP=RIPE RDAP · HIT=IPv6 Hitlist · RTR=in-prefix path hop (router) · PRB=static prefix probe · SYN=synthetic prefix::1 fallback
| Target IP / hostname | Source | NL host (go6lab) | ITA host (Karsolink) | SLO host (6connect) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ping | 1500B | :80 | :443 | reached | ping | 1500B | :80 | :443 | reached | ping | 1500B | :80 | :443 | reached | ||
2a02:6b8:0:1::1ns2.yandex.net | NS | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8:0:1::213dns2.yandex.net | whois | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8:0:809:95:108:159:23lg.yandex.net | whois | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8::1ns1.yandex.net | NS | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8::125imap.yandex.ru | whois | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8::183ftp.yandex.ru | whois | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - |
2a02:6b8::1bdns.yandex.ru | whois | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - |
2a02:6b8::213dns1.yandex.net | whois | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8::311mx.yandex.ru | MX | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - | ✓ | ✓ | ? | ? | - |
2a02:6b8::78autodiscover.yandex.ru | whois | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - | ✓ | ✓ | open | open | - |
RPKI & ASPA
18 of 18 prefix(es) covered by a valid ROA.
| Prefix | RPKI state | Reason | Covering VRP(s) |
|---|---|---|---|
2a02:6b8:8::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:5::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:b::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS207304 /48 maxLen 48 (ripe); AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:21::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:6::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:e::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a0e:fd80::/32 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS208398 /32 maxLen 32 (ripe) |
2a02:6b8::/32 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:22::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:d::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8::/29 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:a::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:23::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:4::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:215::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS207304 /48 maxLen 48 (ripe); AS212066 /48 maxLen 48 (ripe); AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a02:6b8:c::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
2a0e:fd87::/32 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS208398 /32 maxLen 32 (ripe); AS49714 /32 maxLen 48 (ripe) |
2a02:6b8:20::/48 | ✓ valid | matched VRP (correct origin, length within maxLength) | AS13238 /29 maxLen 48 (ripe); AS208398 /29 maxLen 48 (ripe) |
ASPA: this AS has published an ASPA record listing 4 upstream provider(s) that are authorized to propagate routes from it: AS174, AS1299, AS3491, AS6762. Routes from this AS that arrive via any other upstream are considered ASPA-invalid by validators that enforce ASPA.
Random-IP probe (yarrp) into the AS' prefixes
We probed 30 arbitrary IPv6 address(es) inside AS208398's announced prefix(es). No router inside the prefix responded. The deepest visible hop was 2a03:5f80:4::225:147 at hop 11 - that router does not answer ICMPv6 Echo. This is not in AS208398's announced prefix; operationally it's the AS-edge / peering interface (often on a SOX peering address or an upstream's /127 link). The traceroute boundary is the AS edge: ICMPv6 Time-Exceeded responses from anything inside this AS are filtered.
ICMPv6 Type 2 (Packet Too Big) acceptance - active test
Vantage points disagree about Type 2 acceptance - transit ASes on one path may be filtering Type 2 even though the destination's stack accepts it on another path:
- NL host (go6lab): Type 2 NOT honored. Forged PTB had no effect (filtered en route or stack ignored it). (ICMPv6 Echo + forged PTB)
- ITA host (Karsolink): inconclusive: no Echo Reply to 1300-byte probe. (ICMPv6 Echo + forged PTB)
- SLO host (6connect): Type 2 NOT honored. Forged PTB had no effect (filtered en route or stack ignored it). (ICMPv6 Echo + forged PTB)
Why they disagree - reachability mismatch: One vantage couldn't drive a flow at all to this destination (no Echo Reply or no responding TCP port), so the active test had no behavioural change to observe. The other vantage's verdict is the only meaningful one here.
Failure detail — what to grep in your logs
| vantage | our source | your target | method | result | tested (UTC) |
|---|---|---|---|---|---|
| go6lab | 2a00:8642:42::75 | 2a02:6b8::1 | icmp6-echo | not_honored | 2026-05-30T11:29:44Z |
| karsolink | 2a12:d8c0:105a:9001::a154 | 2a02:6b8::1 | icmp6-echo | no_echo | 2026-05-30T11:30:35Z |
| odin | 2607:fae0:a000::42 | 2a02:6b8::1 | icmp6-echo | not_honored | 2026-05-30T11:29:41Z |
Attempt log (go6lab):
icmp6-echo→ not_honored (size_before=1460, size_after=1460)dns-tcp→ inconclusive (size_before=133, size_after=None): max DNS-over-TCP segment 133B; not big enough to test PMTU shrinktls→ no_tcp: TLS connect failedhttp→ no_tcp: tcp/80 not open
Attempt log (karsolink):
icmp6-echo→ no_echo: no Echo Reply to 1300-byte probedns-tcp→ inconclusive (size_before=87, size_after=None): max DNS-over-TCP segment 87B; not big enough to test PMTU shrinktls→ no_tcp: TLS connect failedhttp→ no_tcp: tcp/80 not open
Attempt log (odin):
icmp6-echo→ not_honored (size_before=1460, size_after=1460)dns-tcp→ inconclusive (size_before=31, size_after=None): max DNS-over-TCP segment 31B; not big enough to test PMTU shrinktls→ no_tcp: TLS connect failedhttp→ no_tcp: tcp/80 not open
To match the corresponding ICMPv6 packet on your side (host firewall, AS edge, or transit tap), look for our PTBs around the timestamps above:
sudo tcpdump -i any -n -e 'icmp6 and ip6[40] = 2 and (src host 2607:fae0:a000::42 or src host 2a00:8642:42::75 or src host 2a12:d8c0:105a:9001::a154)'
If you see our PTBs arriving but the destination's TCP/Echo flow does not shrink, the drop is in the destination kernel (cause 3 below). If you don't see them at all, drop is upstream of you (cause 2). If you only see them from one of our two source IPs, the drop is path-asymmetric — one transit on the asymmetric route is filtering, the other is not.
What does "Type 2 not honored" actually mean? — click to expand
What this test does
Using the icmp6-echo method, we send a 1500-byte ICMPv6 Echo Request, then a forged ICMPv6 Type 2 (Packet Too Big) declaring path MTU=1280, and observe whether the next Echo Reply arrives split into IPv6 fragments. RFC 4890 requires hosts and intermediate networks not to filter ICMPv6 Type 2; the destination's TCP/UDP stack must act on a received PTB by lowering its Path MTU cache for that destination, which makes subsequent segments smaller.
What we measured
The TCP segment size your server emitted before our forged Type 2 was 1460 B; after, it was 1460 B. No change. RFC 4890 ("Type 2 messages MUST NOT be filtered") expects subsequent segments to shrink to fit a Path MTU of 1280 B.
Three plausible causes
- Your host firewall is dropping ICMPv6 Type 2 inbound. Many default firewall rule sets only allow Echo Request/Reply and Neighbor Discovery, silently dropping all other ICMPv6 types - including Packet Too Big.
- An upstream / transit network is dropping ICMPv6 Type 2 before it reaches you. Some transit ASes filter ICMPv6 messages other than Echo at the edge. The forged PTB never arrives, so your stack never has a chance to act on it.
- Your kernel is ignoring the PTB. Linux / BSD stacks normally accept ICMPv6 PTB and update the route cache, but a few sysctls (or a hardened kernel) can be configured to ignore PMTU updates - typically as part of an over-aggressive anti-spoofing or uRPF policy.
How to check & fix (Linux examples)
1. Confirm Type 2 is not blocked at the host firewall:
sudo ip6tables -L INPUT -nv | grep -iE 'icmpv6|packet-too-big' sudo nft list ruleset 2>/dev/null | grep -A1 'icmpv6'
If you see rules dropping ICMPv6 unconditionally, change them to permit at least icmpv6 type packet-too-big (and destination-unreachable, time-exceeded, parameter-problem per RFC 4890).
2. Confirm the kernel accepts incoming PTB:
sudo sysctl net.ipv6.conf.all.accept_redirects net.ipv4.ip_no_pmtu_disc net.ipv6.route.mtu_expires
The defaults (accept_redirects=1, ip_no_pmtu_disc=0) are the right values for honoring PTB.
3. Live trace: while we have an open TCP flow with a small MSS (we run our test from 2607:fae0:a000::42 on odin, 2a00:8642:42::75 on go6lab and 2a12:d8c0:105a:9001::a154 on karsolink), watch for our forged Type 2 arriving on your interface:
sudo tcpdump -i any -n -e 'icmp6 and ip6[40] = 2 and (src host 2607:fae0:a000::42 or src host 2a00:8642:42::75 or src host 2a12:d8c0:105a:9001::a154)'
If you see our PTBs arriving but TCP segments still stay big, the drop is in your kernel or NIC offload (cause 3). If you don't see them at all, the drop is upstream of you (cause 2) - ask your upstream(s) to permit ICMPv6 Type 2.
4. If your test target above (2026-05-30T11:29:44Z) is a host that you don't own (e.g. a third-party DNS / TLS server you happen to operate prefixes for), the verdict reflects that specific host's behaviour - try the test against a server you do own and we'll happily re-run.
RFC 4890 references: §4.3.1 (Packet Too Big - MUST NOT be dropped), and RFC 8201 for the broader PMTUD requirement.
Where the path divergence is
Per-vantage probe + verdict (headline):
- go6lab: probe
icmp6-echo→ verdictnot_honored - karsolink: probe
icmp6-echo→ verdictno_echo - odin: probe
icmp6-echo→ verdictnot_honored
Full per-method matrix (all four methods run at each vantage):
| vantage | icmp6-echo | dns-tcp | tls | http |
|---|---|---|---|---|
| go6lab | not_honored | inconclusive | no_tcp | no_tcp |
| karsolink | no_echo | inconclusive | no_tcp | no_tcp |
| odin | not_honored | inconclusive | no_tcp | no_tcp |
✓ All vantages agree on method(s): icmp6-echo — the headline-method spread above is dispatcher noise, not a real Type 2 disagreement.
These vantage-level disagreements are rooted somewhere in the forward paths. Joining each per-vantage traceroute against the IP→AS lookup from our global yarrp mesh, the first hop where the paths land in different ASes is the most likely site of the offending filter / unreachable AS / Type 2 drop.
Suspect transit ASes (ranked by how often they appear at the divergence point on the path of the worse-classifying vantage): AS50673, AS56635.
- From go6lab (open/Type-2=not_honored) the path enters AS50673 at hop 3; from odin (open/Type-2=not_honored) the same hop is in AS56635. Last common AS: no shared transit. The disagreement is most likely rooted in one of those two transit ASes.
Diagnosis is path-level, not packet-level: it tells you which transit AS is the prime suspect, not exactly which firewall rule is to blame. Use the tracepath6 output below (when available) for per-hop PMTU evidence on the same path.
✨ Diagnostic interpretation
Per-hop PTB acceptance walk
From the local vantage, we walk the forward path hop-by-hop, sending each hop a 1500-byte ICMPv6 Echo, then a forged PTB (MTU=1280) sourced from us, then another 1500-byte Echo. If the second reply arrives fragmented or smaller, that hop honoured the PTB. If unchanged, it didn't. The first ✗ in an otherwise-✓ path is the most likely filter location. Cross-country aggregation: see the global PTB filter atlas for transit ASes ranked by filter rate across all measurements.
| # | hop IP | AS | Holder | PTB acceptance |
|---|---|---|---|---|
| 1 | 2607:fae0:a000::2 | AS8038 | 6CONNECT - 6connect, Inc., US | - skipped (CoPP) |
| 2 | * | - | - (no IP) | |
| 3 | 2a03:a100:0:201:1::1 | AS56635 | XENYA - XENYA inzeniring, proizvodnja in | ✓ honored |
| 4 | 2001:470:1:5be::1 | AS6939 | HURRICANE - Hurricane Electric LLC, US | ? no_response |
| 5 | 2001:470:0:578::1 | AS6939 | HURRICANE - Hurricane Electric LLC, US | ? no_response |
| 6 | 2001:470:0:7ef::1 | AS6939 | HURRICANE - Hurricane Electric LLC, US | ? no_response |
| 7 | 2001:470:e:5a::2 | AS6939 | HURRICANE - Hurricane Electric LLC, US | ? no_response |
| 8 | 2001:470:e:38::1 | AS6939 | HURRICANE - Hurricane Electric LLC, US | ? no_response |
| 9 | * | - | - (no IP) | |
| 10 | 2a03:5f80:4:2::236:2 | - | NA | ? no_response |
| 11 | 2a03:5f80:4::225:147 | - | NA | ? no_response |
| 12 | * | - | - (no IP) | |
| 13 | * | - | - (no IP) | |
| 14 | * | - | - (no IP) | |
| 15 | * | - | - (no IP) | |
| 16 | * | - | - (no IP) | |
| 17 | * | - | - (no IP) | |
| 18 | * | - | - (no IP) | |
| 19 | * | - | - (no IP) | |
| 20 | * | - | - (no IP) | |
| 21 | * | - | - (no IP) | |
| 22 | * | - | - (no IP) | |
| 23 | * | - | - (no IP) | |
| 24 | * | - | - (no IP) |
Tests host-mode PTB acceptance (PTBs aimed at the hop itself). A router that honours PTBs to itself can still be filtering PTBs transiting through it; this is one indicator, not proof of full PTB transparency. Hops in CoPP-rate-limit ranges are skipped to avoid false signals.
From NL host (go6lab) openRFC 4890 ✗
filter likely at: (none) · min PMTU on path: 1500
Path (traceroute + mtr + PTR)
| # | IP / PTR | RTT | mtr loss | AS | AS holder |
|---|---|---|---|---|---|
| 1 | 2a00:8642:42::3 | 1.1ms | 0% | AS203993 | STEFFANN-DC-AS - S.J.M. Steffann, NL |
| 2 | * | - | 0%* | - | |
| 3 | 2a00:1ca8:1::194 | 2.4ms | 0% | AS50673 | Serverius-as - Serverius Holding B.V., NL |
| 4 | 2a03:3f40::10:41 | 2.3ms | 0% | AS50673 | Serverius-as - Serverius Holding B.V., NL |
| 5 | 2001:978:2:40::3:1 | 4.3ms | - | AS174 | COGENT-174 - Cogent Communications, LLC, US |
| 6 | be3457.ccr41.ams03.atlas.cogentco.com 2001:550:0:1000::8275:109 | 4.4ms | - | AS174 | COGENT-174 - Cogent Communications, LLC, US |
| 7 | be2175.rcr21.b021535-1.ams03.atlas.cogentco.com 2001:550:0:1000::9a36:3d2a | 5.2ms | 80% | AS174 | COGENT-174 - Cogent Communications, LLC, US |
| 8 | 2001:978:2:2c::6c:2 | 5.4ms | 0% | AS174 | COGENT-174 - Cogent Communications, LLC, US |
| 9 | * | - | 0% | - | |
| 10 | * | - | 0% | - | |
| 11 | * | - | - | - | |
| 12 | * | - | - | - | |
| 13 | * | - | - | - | |
| 14 | * | - | - | - | |
| 15 | * | - | - | - | |
| 16 | * | - | - | - | |
| 17 | * | - | - | - | |
| 18 | * | - | - | - | |
| 19 | * | - | - | - | |
| 20 | * | - | - | - | |
| 21 | * | - | - | - | |
| 22 | * | - | - | - | |
| 23 | * | - | - | - | |
| 24 | * | - | - | - |
Rate-limited ICMPv6: hop 7 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).
tracepath -6
1?: [LOCALHOST] 0.051ms pmtu 1500
1: 2a00:8642:42::3 1.982ms
1: 2a00:8642:42::3 1.361ms
2: gw.friends.steffann.nl 2.332ms
3: 2a00:1ca8:1::194 2.706ms
4: 2a03:3f40::10:41 2.611ms
5: no reply
6: no reply
7: be2020.rcr21.b021535-1.ams03.atlas.cogentco.com 5.668ms
8: 2001:978:2:2c::6c:2 5.646ms
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500 From ITA host (Karsolink) open
filter likely at: (none) · min PMTU on path: 1500
Path (traceroute + mtr + PTR)
| # | IP / PTR | RTT | mtr loss | AS | AS holder |
|---|---|---|---|---|---|
| 1 | * | - | 0%* | - | |
| 2 | * | - | 0%* | - | |
| 3 | * | - | - | - | |
| 4 | 2a03:b020:1:51::a | 10.0ms | 0% | AS41327 | FIBERTELECOM-AS - Fiber Telecom S.p.A., IT |
| 5 | 2a03:b020::244 | 19.1ms | 0% | AS41327 | FIBERTELECOM-AS - Fiber Telecom S.p.A., IT |
| 6 | styri.yndx.net 2001:7f8:20:101::208:116 | 57.0ms | 0% | - | NA |
| 7 | * | - | - | - | |
| 8 | * | - | 0% | - | |
| 9 | * | - | 0% | - | |
| 10 | * | - | - | - | |
| 11 | * | - | - | - | |
| 12 | * | - | - | - | |
| 13 | * | - | - | - | |
| 14 | * | - | - | - | |
| 15 | * | - | - | - | |
| 16 | * | - | - | - | |
| 17 | * | - | - | - | |
| 18 | * | - | - | - | |
| 19 | * | - | - | - | |
| 20 | * | - | - | - | |
| 21 | * | - | - | - | |
| 22 | * | - | - | - | |
| 23 | * | - | - | - | |
| 24 | * | - | - | - |
tracepath -6
1?: [LOCALHOST] 0.085ms pmtu 1500
1: karsolink-01.net.karsolink.com 0.649ms
2: 2a12:d8c0:109f:121::a1 0.656ms
3: 2a12:d8c0:101f:6::1 10.095ms
4: 2a03:b020:1:51::a 10.808ms
5: 2a03:b020::244 19.621ms
6: styri.yndx.net 56.295ms
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500 From SLO host (6connect) openRFC 4890 ✗
filter likely at: (none) · min PMTU on path: 1500
Path (traceroute + mtr + PTR)
| # | IP / PTR | RTT | mtr loss | AS | AS holder |
|---|---|---|---|---|---|
| 1 | fw1-lju.6connect.com 2607:fae0:a000::2 | 0.5ms | 0%* | AS8038 | 6CONNECT - 6connect, Inc., US |
| 2 | * | - | - | - | |
| 3 | 2a03:a100:0:201:1::1 | 0.7ms | 30% | AS56635 | XENYA - XENYA inzeniring, proizvodnja in trgovina, d.o.o. Ljubljana, SI |
| 4 | e0-1.core1.lju1.he.net 2001:470:1:5be::1 | 1.9ms | 0% | AS6939 | HURRICANE - Hurricane Electric LLC, US |
| 5 | 100ge0-0-0-5.core1.vie1.he.net 2001:470:0:578::1 | 7.5ms | 10% | AS6939 | HURRICANE - Hurricane Electric LLC, US |
| 6 | 100ge0-0-0-19.core2.fra2.he.net 2001:470:0:7ef::1 | 18.8ms | 0% | AS6939 | HURRICANE - Hurricane Electric LLC, US |
| 7 | be3.core4.fra1.he.net 2001:470:e:5a::2 | 19.3ms | 0% | AS6939 | HURRICANE - Hurricane Electric LLC, US |
| 8 | be2.core3.ams1.he.net 2001:470:e:38::1 | 24.6ms | 10% | AS6939 | HURRICANE - Hurricane Electric LLC, US |
| 9 | * | - | - | - | |
| 10 | test-20032023-1.ix.dataix.eu 2a03:5f80:4:2::236:2 | 39.1ms | 0% | - | NA |
| 11 | 2a03:5f80:4::225:147 | 58.7ms | 0% | - | NA |
| 12 | * | - | - | - | |
| 13 | * | - | 0% | - | |
| 14 | * | - | 0% | - | |
| 15 | * | - | - | - | |
| 16 | * | - | - | - | |
| 17 | * | - | - | - | |
| 18 | * | - | - | - | |
| 19 | * | - | - | - | |
| 20 | * | - | - | - | |
| 21 | * | - | - | - | |
| 22 | * | - | - | - | |
| 23 | * | - | - | - | |
| 24 | * | - | - | - |
Rate-limited ICMPv6: hop 3, hop 5, hop 8 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).
tracepath -6
1?: [LOCALHOST] 0.032ms pmtu 1500
1: fw1-lju.6connect.com 0.441ms
1: fw1-lju.6connect.com 0.409ms
2: ccr-to-fw-ccr1-gw-lju.6connect.com 0.808ms
3: 2a03:a100:0:201:1::1 0.636ms
4: e0-1.core1.lju1.he.net 2.080ms
5: 100ge0-0-0-5.core1.vie1.he.net 8.537ms
6: 100ge0-0-0-19.core2.fra2.he.net 19.344ms asymm 7
7: be3.core4.fra1.he.net 19.022ms asymm 8
8: be2.core3.ams1.he.net 24.643ms asymm 9
9: no reply
10: ix.dataix.eu 41.226ms
11: 2a03:5f80:4::225:147 58.638ms asymm 14
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500