AS205007 - ESERVER-RS Maxim Azarov trading as eServerRFC 4890 ✓RPKI ✓ 3/3ASPA -

← back to summary

All countriesHomeState of IPv6TopologySOXAboutipv6.si ↗ Sparky

AS overview

Test target: 2a04:b540:3000:2::3 · (SPF ip6: literal) · address space: unknown · prefixes announced: 3

prefix(es): 2a10:9686::/32, 2a04:b540:3000::/36, 2a09:31c0:babe::/48

Targets & per-vantage-point probe results (2 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 / hostnameSourceNL host (go6lab)ITA host (Karsolink)SLO host (6connect)
ping1500B:80:443reachedping1500B:80:443reachedping1500B:80:443reached
2a04:b540:3000:2::2
eserver.rs
drvopenopenopenopenopenopen
2a04:b540:3000:2::3SPFopenopenopenopenopenopen

RPKI & ASPA

3 of 3 prefix(es) covered by a valid ROA.

PrefixRPKI stateReasonCovering VRP(s)
2a04:b540:3000::/36✓ validmatched VRP (correct origin, length within maxLength)AS205007 /36 maxLen 36 (ripe)
2a10:9686::/32✓ validmatched VRP (correct origin, length within maxLength)AS205007 /32 maxLen 32 (ripe)
2a09:31c0:babe::/48✓ validmatched VRP (correct origin, length within maxLength)AS205007 /48 maxLen 48 (ripe)

Random-IP probe (yarrp) into the AS' prefixes

We probed 30 arbitrary IPv6 address(es) inside AS205007's announced prefix(es). No router inside the prefix responded. The deepest visible hop was 2a02:e40::100:e at hop 12 - that router answers ICMPv6 Echo. This is not in AS205007'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:

Why they disagree - different probe methods: These vantages picked different probe methods, so their verdicts are not directly comparable. The active test tries methods in order (icmp6-echodns-tcptlshttp) and stops at the first that produces a definitive verdict; if the chosen method differs, the underlying evidence differs too. Most often this is because the path PMTU on one vantage is below 1500 B, so the natural Echo Reply is already fragmented and the icmp6-echo method falls through to a TCP-based one. This is largely a measurement artifact, not a destination-behaviour difference.

Failure detail — what to grep in your logs
vantageour sourceyour targetmethodresulttested (UTC)
go6lab2a00:8642:42::752a04:b540:3000:2::3icmp6-echohonored2026-05-30T11:30:02Z
karsolink2a12:d8c0:105a:9001::a1542a04:b540:3000:2::3tlsnot_honored2026-05-30T11:31:32Z
odin2607:fae0:a000::422a04:b540:3000:2::3icmp6-echohonored2026-05-30T11:29:59Z

Attempt log (go6lab):

  1. icmp6-echohonored (size_before=1460, size_after=None)
  2. dns-tcpinconclusive (size_before=156, size_after=None): max DNS-over-TCP segment 156B; not big enough to test PMTU shrink
  3. tlsnot_honored (size_before=1454, size_after=1454)
  4. httpinconclusive (size_before=295, size_after=None): natural max segment 295B already <= 1220B; nothing to shrink

Attempt log (karsolink):

  1. icmp6-echono_echo: no Echo Reply to 1300-byte probe
  2. dns-tcpinconclusive (size_before=156, size_after=None): max DNS-over-TCP segment 156B; not big enough to test PMTU shrink
  3. tlsnot_honored (size_before=1454, size_after=1428)
  4. httpinconclusive (size_before=295, size_after=None): natural max segment 295B already <= 1220B; nothing to shrink

Attempt log (odin):

  1. icmp6-echohonored (size_before=1460, size_after=None)
  2. dns-tcpinconclusive (size_before=133, size_after=None): max DNS-over-TCP segment 133B; not big enough to test PMTU shrink
  3. tlsnot_honored (size_before=1454, size_after=1454)
  4. httpinconclusive (size_before=295, size_after=None): natural max segment 295B already <= 1220B; nothing to shrink

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 tls method, we open a TLS handshake to your TCP server, observe its TCP segment size, forge an ICMPv6 PTB declaring path MTU=1280, and observe whether subsequent segments shrink. 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

Three plausible causes

  1. 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.
  2. 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.
  3. 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:31:32Z) 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.

tracepath6 per-hop PMTU drilldown

For each target where Type 2 verdicts disagreed across vantages, tracepath -6 ran from every vantage to capture per-hop PMTU evolution along that vantage's actual forward path. A pmtu change entry on a hop means that hop's router generated a PTB and we observed the shrink; absence of any change combined with a not_honored verdict suggests a router somewhere downstream is silently dropping >MTU packets (an RFC 4890 violation) rather than sending a PTB.

Target 2a04:b540:3000:2::3

go6lab — verdict honored

verdict = honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22a00:8642:1000:f000::1
32a00:1ca8:1::194
42a03:3f40::10:33
52001:7f8:1::a500:8400:1
62a00:e90::212:200:5:7
72a00:e90::212:200:6:8
82a00:e90::212:200:6:60
92a00:e90:0:c::7
102a02:e40::23
112a02:e40::100:e
122a04:b540:3000:2::3
karsolink — verdict not_honored

verdict = not_honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22a12:d8c0:109f:121::a1
32a12:d8c0:101f:6::1
42a03:b020:1:51::a
52a03:b020::222
62a03:5f80:4:2::237:40
72a00:e90:0:b::19
82a02:e40::24
92a02:e40::100:e
102a04:b540:3000:2::3
odin — verdict honored

verdict = honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22607:fae0:a000:2::2
32a03:a100:0:201:1::1
42001:470:1:5be::1
52001:470:0:578::1
62001:7f8:30:0:2:1:0:8400
72a00:e90::212:200:5:7
82a00:e90::212:200:6:8
92a00:e90::212:200:6:60
102a00:e90:0:c::7
112a02:e40::23
122a02:e40::100:e
132a04:b540:3000:2::3

Target 2a04:b540:3000:2::2

go6lab — verdict honored

verdict = honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22a00:8642:1000:f000::1
32a00:1ca8:1::194
42a03:3f40::10:33
52001:7f8:1::a500:8400:1
62a00:e90::212:200:5:7
72a00:e90::212:200:6:8
82a00:e90::212:200:6:60
92a00:e90:0:c::7
102a02:e40::23
112a02:e40::100:e
122a04:b540:3000:2::2
karsolink — verdict not_honored

verdict = not_honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22a12:d8c0:109f:121::a1
32a12:d8c0:101f:6::1
42a03:b020:1:51::a
52a03:b020::222
62a03:5f80:4:2::237:40
72a00:e90:0:b::19
82a02:e40::24
92a02:e40::100:e
102a04:b540:3000:2::2
odin — verdict honored

verdict = honored; final pmtu = 1500

#hop IPpmtu change
1<span class='muted'>no reply</span>
22607:fae0:a000:2::2
32a03:a100:0:201:1::1
42001:470:1:5be::1
52001:470:0:578::1
62001:7f8:30:0:2:1:0:8400
72a00:e90::212:200:5:7
82a00:e90::212:200:6:8
92a00:e90::212:200:6:60
102a00:e90:0:c::7
112a02:e40::23
122a02:e40::100:e
132a04:b540:3000:2::2

From NL host (go6lab)   openRFC 4890 ✓

filter likely at: (none) · min PMTU on path: 1500

4/4
Echo small (56B) 31.4ms
4/4
Echo 1500B (DF) 30.8ms
yes
Type 1 dest-unreach
443,80
TCP responds on

Path (traceroute + mtr + PTR)

#IP / PTRRTTmtr lossASAS holder
12a00:8642:42::31.1ms0%AS203993STEFFANN-DC-AS - S.J.M. Steffann, NL
2*---
32a00:1ca8:1::1942.5ms0%AS50673Serverius-as - Serverius Holding B.V., NL
42a03:3f40::10:335.3ms0%AS50673Serverius-as - Serverius Holding B.V., NL
52001:7f8:1::a500:8400:122.6ms0%-NA
62a00:e90::212:200:5:732.0ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
72a00:e90::212:200:6:831.5ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
82a00:e90::212:200:6:6031.7ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
92a00:e90:0:c::731.2ms40%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
102a02:e40::2331.1ms20%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
112a02:e40::100:e30.9ms0%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
12service-1.rs.eserver.net
2a04:b540:3000:2::3
31.3ms0%AS205007ESERVER-RS - Maxim Azarov trading as eServer, RS

Rate-limited ICMPv6: hop 9, hop 10 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).

tracepath -6

 1?: [LOCALHOST]                        0.039ms pmtu 1500
 1:  2a00:8642:42::3                                       1.281ms 
 1:  2a00:8642:42::3                                       1.376ms 
 2:  gw.friends.steffann.nl                                2.721ms 
 3:  2a00:1ca8:1::194                                      3.215ms 
 4:  2a03:3f40::10:33                                     14.530ms 
 5:  2001:7f8:1::a500:8400:1                              23.243ms 
 6:  2a00:e90::212:200:5:7                                32.783ms asymm 11 
 7:  2a00:e90::212:200:6:8                                32.141ms asymm 10 
 8:  2a00:e90::212:200:6:60                               32.629ms 
 9:  no reply
10:  2a02:e40::23                                         32.072ms asymm  7 
11:  2a02:e40::100:e                                      32.419ms asymm  8 
12:  service-1.rs.eserver.net                             31.709ms !A
     Resume: pmtu 1500 

From ITA host (Karsolink)   openRFC 4890 ✗

filter likely at: (none) · min PMTU on path: 1500

4/4
Echo small (56B) 50.7ms
4/4
Echo 1500B (DF) 50.5ms
yes
Type 1 dest-unreach
443,80
TCP responds on

Path (traceroute + mtr + PTR)

#IP / PTRRTTmtr lossASAS holder
1*-0%*-
2*---
3*---
42a03:b020:1:51::a10.4ms0%AS41327FIBERTELECOM-AS - Fiber Telecom S.p.A., IT
52a03:b020::22225.9ms0%AS41327FIBERTELECOM-AS - Fiber Telecom S.p.A., IT
62a03:5f80:4:2::237:4051.1ms0%-NA
72a00:e90:0:b::1950.4ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
82a02:e40::2450.5ms10%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
92a02:e40::100:e50.8ms0%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
10service-1.rs.eserver.net
2a04:b540:3000:2::3
50.8ms0%AS205007ESERVER-RS - Maxim Azarov trading as eServer, RS

Rate-limited ICMPv6: hop 8 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).

tracepath -6

 1?: [LOCALHOST]                        0.027ms pmtu 1500
 1:  no reply
 2:  2a12:d8c0:109f:121::a1                                0.681ms 
 3:  2a12:d8c0:101f:6::1                                  10.273ms 
 4:  2a03:b020:1:51::a                                    10.652ms 
 5:  2a03:b020::222                                       26.448ms 
 6:  2a03:5f80:4:2::237:40                                50.252ms 
 7:  2a00:e90:0:b::19                                     50.913ms 
 8:  2a02:e40::24                                         51.069ms 
 9:  2a02:e40::100:e                                      50.979ms 
10:  service-1.rs.eserver.net                             50.915ms !A
     Resume: pmtu 1500 

From SLO host (6connect)   openRFC 4890 ✓

filter likely at: (none) · min PMTU on path: 1500

4/4
Echo small (56B) 31.1ms
3/4
Echo 1500B (DF) 31.9ms
yes
Type 1 dest-unreach
443,80
TCP responds on

Path (traceroute + mtr + PTR)

#IP / PTRRTTmtr lossASAS holder
1fw1-lju.6connect.com
2607:fae0:a000::2
0.2ms0%*AS80386CONNECT - 6connect, Inc., US
2*---
32a03:a100:0:201:1::10.7ms90%AS56635XENYA - XENYA inzeniring, proizvodnja in trgovina, d.o.o. Ljubljana, SI
4*-70%-
5100ge0-0-0-5.core1.vie1.he.net
2001:470:0:578::1
7.3ms30%AS6939HURRICANE - Hurricane Electric LLC, US
62001:7f8:30:0:2:1:0:840034.2ms0%-NA
72a00:e90::212:200:5:741.0ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
82a00:e90::212:200:6:840.9ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
92a00:e90::212:200:6:6041.3ms0%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
102a00:e90:0:c::741.6ms50%AS8400TELEKOM-AS - TELEKOM SRBIJA a.d., RS
112a02:e40::2331.3ms30%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
122a02:e40::100:e31.8ms0%AS6700BEOTEL-AS - TELEKOM SRBIJA a.d., RS
13service-1.rs.eserver.net
2a04:b540:3000:2::3
31.1ms0%AS205007ESERVER-RS - Maxim Azarov trading as eServer, RS

Rate-limited ICMPv6: hop 3, hop 4, hop 5, hop 10, hop 11 (loss between 5% and 95% across mtr cycles - the router replies but only sometimes).

tracepath -6

 1?: [LOCALHOST]                        0.024ms pmtu 1500
 1:  fw1-lju.6connect.com                                  0.472ms 
 1:  fw1-lju.6connect.com                                  0.440ms 
 2:  ccr-to-fw-ccr1-gw-lju.6connect.com                    0.992ms 
 3:  2a03:a100:0:201:1::1                                  0.661ms 
 4:  e0-1.core1.lju1.he.net                                2.139ms 
 5:  100ge0-0-0-5.core1.vie1.he.net                        8.856ms 
 6:  2001:7f8:30:0:2:1:0:8400                              6.438ms 
 7:  2a00:e90::212:200:5:7                                40.869ms asymm 20 
 8:  2a00:e90::212:200:6:8                                41.082ms asymm 19 
 9:  2a00:e90::212:200:6:60                               41.167ms asymm 18 
10:  2a00:e90:0:c::7                                      41.720ms asymm 19 
11:  2a02:e40::23                                         32.318ms asymm 13 
12:  2a02:e40::100:e                                      31.436ms asymm 13 
13:  service-1.rs.eserver.net                             31.474ms !A
     Resume: pmtu 1500