01-20-2021 12:04 PM
Hi,
I ran into a problem today when expanding a customer's environment. I'd previously set up an EDL pointing to a Minemeld-generated list of all Azure ip-ranges, no problem thus far. I've done this for other customers before without any issue but noticed now that when I used the recommended prototype azure.cloudIPsWithServiceTags it generated a list with some 24000 rows of ip ranges whereas the old one I've used only generated in the region of 3000. So as I expanded the security policies and NAT rules with more references to the EDL, I got this message when pushing the config from Panorama:
Details:
. Error: Failed to get vsys config, already allocated (131072 bytes)
. failed to handle CONFIG_UPDATE_START
. (Module: device)
. Commit failed
Which from as best I can gather is down to the config-size growing too large for the VM300's. Anyone here run into the same problem? Or how do you best get around this issue? Set filters to exclude all irrelevant ip-ranges? I should perhaps add that this would be a general rule for all Azure VMs regardless of region to be able to speak directly to Azures backbone services and differentiate it from general internet access so they can access things like Windows Update, activate windows licenses, update Linux VMs etc.
