Hello,
I have an additional IP (89.58.20.220/32) that Netcup's network does not deliver
to my server. I have done extensive packet-level debugging and would appreciate
help before escalating further.
SETUP
-----
- Root server "ns1.cloud-hosting-dns.com", Rocky Linux 10, kernel 6.12
- Primary IP: 152.53.110.156/22, gateway 152.53.108.1, MAC 0a:b2:2c:3a:33:1f
- Several additional IPs configured on eth0, all working:
89.58.20.168/32 (same subnet as the failing one), 159.195.141.13/24, .16-.21
- Failing IP: 89.58.20.220, shown in the SCP as:
"89.58.20.220/32 - Gateway / Routed to 152.53.110.156"
- Configured exactly as Netcup documents for a routed /32 additional IP:
89.58.20.220/32 on eth0, default gateway 152.53.108.1
(It was originally configured as /24; changing to /32 changed nothing.)
- DirectAdmin manages the IP (it is correctly listed in ip.list and added at boot)
SYMPTOMS
--------
1. Outbound: ping with source .220 to 1.1.1.1 = 100% packet loss.
tcpdump on eth0 during the test proves the echo requests DO leave eth0:
10:31:35.060487 IP 89.58.20.220 > 1.1.1.1: ICMP echo request
10:31:36.075762 IP 89.58.20.220 > 1.1.1.1: ICMP echo request
No reply ever returns. Same test with source 89.58.20.168: 0% loss, ~12 ms.
2. Inbound: external ping to .220 (from another host, 144.208.208.166) fails
with "Time to live exceeded". During a 180 s capture on eth0 filtered for
"host 89.58.20.220 or arp", 0 packets were captured. The traffic never
reaches the interface.
3. Control IP: 89.58.20.168, in the same /24, configured the same way through
the same tooling, passes all tests 100% (bidirectional, ~12 ms RTT).
RULED OUT (server side)
-----------------------
- Firewall (CSF/iptables): no rule references .220; generic port rules only;
egress packets are visible on the wire outside the firewall, inbound packets
never arrive at all.
- No local drops: eth0 counters clean (0 errors, 0 drops), rp_filter not
interfering (packets leave fine).
- Kernel treats .220 as local and answers for it; services can bind to it.
- SCP assignment verified: routed to this server's primary IP / correct MAC.
- rDNS was removed and re-created in the SCP as a provisioning test: no change.
- No reboot/reconfiguration of the server network was done at any point.
CONCLUSION
----------
With the SCP assignment correct, the config matching Netcup's documentation, an
identically configured IP in the same subnet working, packets leaving eth0 and
nothing ever arriving for .220, the fault must be in Netcup's upstream
routing/announcement for 89.58.20.220 (possibly a stale route or loop — the
"TTL exceeded" from the external tester suggests exactly that).
QUESTIONS
---------
1. Has anyone seen a Netcup additional IP that shows "routed to <primary>" in
the SCP but is not actually routed upstream? How did you get it fixed?
2. To Netcup staff reading this: can you check the live route/announce for
89.58.20.220 and run a delivery test toward it? I can keep a tcpdump open on
eth0 during any test window you propose — correlation is easy.
3. Support keeps asking me to boot into the rescue system. As far as I can tell
the rescue system cannot change anything here: it boots without my network
config, and the failing path is in Netcup's network, not on my server. Is
there anything a rescue boot would actually diagnose that the evidence above
does not?
Thanks in advance.