FMC 7.3.1.1 API NetworkObject payload > 2097152 Bytes

[paulkbeyer]

Afternoon all,
I've a need to populate an FMC 7.3.1.1 with the tags from Azure Service Tags https://www.microsoft.com/en-us/download/details.aspx?id=56519
I'm trying to create a network object group which contains the IP addresses of all the entries for a particular service tag.
All is well creating the payload from the source file/URL, except the payload for a POST request for a single tag to https://{{fmc}}/api/fmc_config/v1/domain/{{domain_uuid}}/object/networkgroups is 3.4MiB.
I can see everywhere that one _can't_ send a payload with more than 2MiB, but I can't see any offers of how to work round that problem if the network object simply is bigger than 2MiB and you don't want to type it into the GUI.

Any offers of ways to create and then append, work around or just do something differently?

Many Thanks!

[paulkbeyer]

The question looks like it's hindered by a further limit on literals supported in a Network Group object.
"Network group object 'AzureActiveDirectory_Public_20231009' contains too many literals. Network group object supports upto 1000 literals only. Please remove extra literals."
I was intentionally avoiding Cisco Secure Dynamic Attribute Connector which to my understanding can/could provide the requirement I'm looking for but at a cost of operating more infrastructure.
Despite(!) both limits I'm hitting, does anyone have any experience of working to achieve a similar outcome?

I'm able to populate ASA9.x code with Network object groups which contain the same number of address entries. I'm sad I'm being pushed back against by the newer products.

[paulkbeyer]

After using the Cisco Firewall Migration Tool (FMT) to move config from an ASA to the FMC, the tool has worked around the object-group size on the ASA by creating numerous object-groups which contain no more than 100 literals in each.
So, I'm aware that this is a reasonable outcome if the literals weren't to change over time, but with a group that's changing weekly, it's really disappointing.
The way that this is going to have to be managed is to have a parent/root object-group called the thing you're working on `AzureActiveDirectory_Public` for example, and then sub groups created with n number of literals (no more than 1000 in each as stated above) and then for me, I'll embed the weekly update reference in the group name so `AzureActiveDirectory_Public_split_20231106_0001`, `AzureActiveDirectory_Public_split_20231106_0002` and so on. Then as each week update occurs, that allows the logic to parse all the split groups to nuke the previous weeks object-groups and inject the current weeks object-groups.
Really dirty IMO. I yearn for the days of no 1000 literal limits and dependent external logic to manage something so ubiquitous.
Unless someone wants to shine a light on this and offer better outcomes, I'll consider this thread closed.