Skip to content

Investigate ghost cluster peer and IPv6 swarm addresses #4

@vm-wylbur

Description

@vm-wylbur

Context

IPFS monitoring deployed (2026-02-08) shows two anomalies that need investigation.

1. Ghost cluster peer ID

12D3KooWEa7paYzEqPf8Mr1h69XR4twJMZQW6Fz7MGT828aPTk5m appears in cluster monitor metrics (pinqueue, ping) but doesn't match any known ccs_peer_id in ansible inventory.

  • ipfs1's recorded ID is 12D3KooWFdQri2MC... (different)
  • ipfs1 is currently offline
  • Ghost peer shows valid: True in ping and pinqueue: 0

Possible causes:

  • ipfs1 was re-provisioned and got a new cluster identity
  • A test peer that was never cleaned up from CRDT state

Action: When ipfs1 comes back online, check its actual cluster peer ID (ipfs-cluster-ctl id). If it matches the ghost, update inventory/host_vars/ipfs1.yml. If not, remove the stale peer from cluster state.

2. IPv6 Tailscale addresses in swarm peers

meerkat and pihost show some peers connected via Tailscale IPv6 (fd7a:115c:a1e0::9, fd7a:115c:a1e0::c) instead of IPv4. The bandwidth collector's name map only covers IPv4 Tailscale IPs, so these show as raw addresses in metrics.

Action: Either add IPv6 Tailscale addresses to the ansible peer name mapping, or investigate why some connections prefer IPv6 over IPv4 and whether kubo can be configured to prefer IPv4 for cluster-internal traffic.

Related

  • Monitoring role: roles/ipfs-monitoring/ in hrdag-ansible
  • Peer name map: roles/ipfs-monitoring/defaults/main.yml (ipfs_extra_peer_names)

By PB & Claude

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions