Files
proxmox/reports/status/IP_CONFLICT_ANALYSIS.md
defiQUG cb47cce074 Complete markdown files cleanup and organization
- Organized 252 files across project
- Root directory: 187 → 2 files (98.9% reduction)
- Moved configuration guides to docs/04-configuration/
- Moved troubleshooting guides to docs/09-troubleshooting/
- Moved quick start guides to docs/01-getting-started/
- Moved reports to reports/ directory
- Archived temporary files
- Generated comprehensive reports and documentation
- Created maintenance scripts and guides

All files organized according to established standards.
2026-01-06 01:46:25 -08:00

3.4 KiB

IP Conflict Analysis: 192.168.11.14

Date: 2026-01-05
Status: 🔍 DEEP INVESTIGATION REQUIRED


Current Situation

Confirmed Facts

  1. r630-04 Physical Server:

    • Powered OFF (confirmed)
    • Runs Debian/Proxmox (confirmed)
    • Should use IP 192.168.11.14 (assigned)
  2. Device Using 192.168.11.14:

    • MAC: bc:24:11:ee:a6:ec (Proxmox-generated)
    • OS: Ubuntu (not Debian/Proxmox)
    • Responds to ping and SSH
    • NOT found in any cluster containers
    • NOT found in any cluster VMs

Mystery

How can a device respond if r630-04 is powered off?

Possible explanations:

  1. Container on Different Host: Container exists but not visible in cluster
  2. Network Device: Switch/router interface using this IP
  3. MAC Spoofing: Another device spoofing the MAC
  4. Cached ARP: Old ARP entry (unlikely - device responds actively)
  5. Container on r630-04: Container was on r630-04, but server is off (contradicts active response)

Investigation Results

  • Checked all LXC containers on ml110, r630-01, r630-02
  • Checked all QEMU VMs on ml110, r630-01, r630-02
  • No container found with IP 192.168.11.14
  • No container found with MAC bc:24:11:ee:a6:ec

Network Interface Check

  • Checking network interfaces on all hosts
  • Checking for orphaned containers

Next Investigation Steps

1. Check Router/Switch ARP Tables

Action: Access ER605 router (192.168.11.1) and check ARP table

# Via Omada controller or direct router access
# Look for device with IP 192.168.11.14
# Get device information from router

2. Check Omada Controller

Action: Access Omada controller (VMID 103, 192.168.11.20 or 192.168.11.8)

# Check device list for 192.168.11.14
# Get device type, MAC, and connection info

3. Network Scan

Action: Perform network scan to identify all devices

# Scan 192.168.11.0/24 network
# Identify all active devices
# Match MAC addresses

4. Check for Hidden Containers

Action: Check for containers in unusual states

# Check /etc/pve/lxc/ on all hosts
# Look for config files with this IP
# Check for containers not in cluster view

Resolution Strategy

If Container Found

  1. Identify container (VMID, host, name)
  2. Stop container
  3. Change IP to available address (e.g., 192.168.11.28)
  4. Restart container
  5. Verify 192.168.11.14 is free

If Container Not Found

  1. Block IP at router level (temporary)
  2. Power on r630-04
  3. Configure r630-04 with 192.168.11.14
  4. Monitor for conflicts
  5. If conflict persists, investigate network device

If Network Device

  1. Identify device type
  2. Reconfigure device with different IP
  3. Update network documentation
  4. Reserve 192.168.11.14 for r630-04

Recommendations

Immediate Actions

  1. Access Omada Controller to check device list
  2. Check router ARP table for device information
  3. Perform network scan to identify all devices
  4. Check for containers in unusual locations/states

Before Powering On r630-04

  1. Resolve IP conflict completely
  2. Verify 192.168.11.14 is free
  3. Document resolution
  4. Prepare r630-04 configuration

Last Updated: 2026-01-05
Status: 🔍 INVESTIGATION CONTINUING
Priority: 🔴 HIGH - Must resolve before powering on r630-04