NSX Federation is supposed to be one network told twice, once from the Global Manager and once from the Local Manager, so both sites agree. Aria Automation does not experience it that way. It experiences two fabric networks for one segment, both eligible for a network profile, and a catalog request that might land on either.
The Challenge
The duplicate is not a mis-click. Global and Local Managers publish the same segment into the fabric inventory, and Aria records both. A network profile that was correct before federation now contains two entries with the same name and different identities. IPAM makes it worse, not better. BlueCat has a range and a gateway. NSX has a CIDR and a gateway. Those are not guaranteed to be the same row.
Cleaning this by hand does not scale past a handful of segments, and the wrong deletion removes the entry the profile should have kept.
Which One Stays
The cleanup tool’s keeper rule is fixed, and it is worth knowing before anyone runs it:
- The network that has the proper segment tag and sits in the preferred cloud account.
- The one that has the segment tag, in any cloud account.
- The one in the preferred cloud account, even without the tag.
- The first network found, if nothing else distinguishes them.
Analyze lists the duplicate groups. Plan says which entry would be kept. Execute removes the others from the profiles. Deleting the fabric networks themselves is a separate flag, not the default. A single segment can be passed in if you want to see one name before you see all of them.
IPAM Does Not Get a Vote for Free
A second tool compares BlueCat blocks to the segments on each NSX manager, global or local, and writes a CSV. Each row is matched, present only in BlueCat, present only in NSX, or a gateway mismatch. It can also emit the segment-to-network-id map a later automation wants. It does not “fix” the mismatch. A gateway that differs is a finding, not a value the script is allowed to overwrite.
That split is deliberate. Federation duplicates in Aria are a profile problem with a keeper rule. IPAM drift is a data problem with a report. Running the report and then letting a mapper invent the gateway is how a cleanup becomes an outage.
The BlueCat provider is what allocates an address once the profile is trustworthy. It cannot tell that the profile contains the same segment twice. That check has to happen first.
The Results
Analyze listed the duplicate groups. Plan named the keeper. Execute removed the others from the profiles. The fabric networks themselves stayed, because deleting them is a separate flag. The IPAM comparison wrote a CSV. A gateway that differed was a finding. It was not overwritten.
Lessons Learned
The duplicate is a product boundary. Global Manager and Local Manager both publish the same segment, and Aria records both. Cleaning that by hand does not scale, and the wrong deletion removes the entry the profile should have kept. The keeper rule has to be fixed before anyone runs execute. IPAM drift is a different problem and does not get a write.
Getting Started
Run it beside this, from a checkout of the network toolkit, with that repo’s config pointed at your Aria host. Analyze writes nothing. --delete-networks is not the default.
python3 scripts/cleanup_profiles.py --analyze
python3 scripts/cleanup_profiles.py --analyze --segment app-segment-01
python3 scripts/cleanup_profiles.py --plan
python3 scripts/cleanup_profiles.py --executeClone aria-network-automation. The keeper rule is scripts/cleanup_profiles.py. Run analyze. Read which entry would be kept. Execute only after that read. Pass one segment name if you want to see one group before you see all of them. The BlueCat-versus-NSX report is a CSV, not a fix. The BlueCat provider allocates an address only after the profile is trustworthy.
Conclusion
Federation is supposed to be one network told twice. Aria experiences two fabric networks. Decide which one stays, remove the other from the profile, and do not let a mapper invent the gateway.
References
The duplicate is a consequence of a product boundary, not a naming mistake. Upgrading NSX Global Manager Nodes in a Federated Environment says SDDC Manager does not manage Global Manager lifecycle when federation spans two VCF instances. Global Manager and Local Manager both remain sources of the same segment, and both can land in the fabric inventory that a network profile selects from. Which NSX build belongs with VCF 9.1.1 is the NSX row of the VCF 9.1.1 Bill of Materials. The keeper rule and the IPAM comparison are the field tool. They are not a VCF API.
The keeper rule is scripts/cleanup_profiles.py in the network toolkit. Analyze, then plan, then execute. Deleting the fabric networks themselves is a separate flag, not the default.
Repository: github.com/noahfarshad/aria-network-automation
Related Stories:
- Infrastructure-as-Code for Aria Automation — the post that walks this toolkit
- Moving NSX DFW Between Global Managers — the other manual federation job
- Production-Ready BlueCat IPAM Integration — the allocator that runs after the profile is trustworthy