Central Manager Aggregation Fails After an IP Address Migration
Guardium has a central manager in Dallas, an aggregator in Frankfurt, and 12 collectors. Collectors aggregate to Frankfurt every 30 minutes; the CM aggregates from Frankfurt daily at 02:00. The CM shows Managed Unit Status Connected for the aggregator, and Frankfurt local reports contain yesterday's data. The CM dashboard has no new audit data for three days. The only recent change was a CM IP migration from 10.10.1.10 to 10.10.1.20. The CM's /etc/hosts still contains an old entry mapping the aggregator's short name to 10.10.1.10. The CM aggregation job log shows connection timed out to the aggregator hostname, but a manual ping from the CM to the aggregator's real IP 10.20.5.15 succeeds. The aggregation schedule is enabled and CM disk is 65% full. Explain the most likely failure and the checks that separate name resolution from aggregation configuration.
1. What is the most likely cause, and why does the managed-unit status still show Connected?
Read the worked answer
The likely failure is name resolution on the CM. The aggregation job connects to the aggregator by hostname; the stale /etc/hosts entry resolves that name to 10.10.1.10, the CM's old address, so the connection times out even though ping to the real aggregator IP 10.20.5.15 works. The green managed-unit status reflects the last management heartbeat or cached status, not a successful aggregation run. Separate the layers: getent hosts/nslookup for the aggregator name, /etc/hosts, aggregation job log, schedule, port 8443 reachability, and CM disk. If name resolution is wrong, fix it before touching the aggregation profile.
2. How would you correct the problem and validate that CM aggregation is current?
Read the worked answer
Correct the stale /etc/hosts entry or DNS record so the aggregator hostname resolves to 10.20.5.15, then clear the resolver cache if applicable. Run a manual aggregation or wait for the next scheduled run. Validate: aggregation job completes, CM report row counts for a fixed recent window match the aggregator's local counts, and no gaps appear. Check CM disk stays below threshold and the aggregator-to-CM path is healthy. Document the change and monitor the next two cycles.
3. If data is still missing after name resolution is fixed, what would you check next?
Read the worked answer
Check the aggregation profile filters, time zone, and data source used for the aggregator; confirm collectors are still sending to the aggregator and that the aggregator has no gaps. Check certificates and port 8443, CM disk, and whether the aggregation task is disabled or queued. Compare a known session on collector, aggregator, and CM to localize the break. Do not assume the CM is at fault just because the dashboard is empty.