Several feature requests & enhancements for Expedition

[rolinger]

My current client is migrating hundreds of FWs to a handful of 7000s in their datacenters.  Expedition has been a lifesaver to help automate this but with the sheer volume of FWs and Rules/Objs we must analyze there are a few items we found Expedition needs or needs improving on.

1.  We need the ability to search for 'null' or malformed components of security rules.  We import a few thousand rules into Expedition about 5% of the "services' in the rules are invalid formats and the rule lists the service as "null".  When this happens we open the rule but can't edit the rule.  Interestingly, when we do open the rule, the service is listed as "any"...even though in the main list it does say 'null'.  To edit it we have to clone the rule and then we can edit the service to a valid "any" or we have to find the original source pre-import rule to find what the correct service was.  I attached a screenshot of what the list of rules looks like - to get this list we had export the entire rule list to Excel, filter for 'blanks/any/null' and then with the filtered results create a custom filter in Expeditin to search just for those ruleIDs with an extensive "OR" filter.

But with thousands of rules, 5% adds up to a lot of rules with a malformed service that now says "null".  We need a way to filter for that and hopefully if they are found we can simply do a mass search/replace with "any" (or other).  I imagine a malformed value can cause 'null' on other fields other than 'service' so the filter and search/repleace would need to applicable to other rule fields as well.

2. I brought this up in another thread but will place here again.  Rule consolidation by more than 10 cases at a time.  With thousands of rules...and each "Case 1 (5 rules), Case 2 (11 rules)...Case 311 (19 rules) we need an option that essentially consolidates all cases into single rules - this example would out put 311 individual rules.  Doing them 10 or 1 at a time is one of our biggest road blocks in trying to automate/streamline these mass migrations.

3.  The filter for search&replace defaults to 200 items per page.  When you "select all" its ONLY selecting the 1st page of results.  In our migrations we have 40 to 50 pages of in the search/replace filter section.  Sometimes when we try to change the view to 8,000 per page (40x200) the filter errors out as its too many objects - when the error happens Expedition loses its mind and we often have to back out of the project and come back in.  If we didn't save or do a snapshot prior to beginning the search/replace step - that error is somehow embedded into the project file and corrupts the project.  The first few times it bit us, we had to start the projects over and then began doing incremental snapshots so we had a progress state to go back to in case the error corrupted the project again.

4. We experienced filtering issues related to "invalid address objects" meaning the IP range was not a valid IP range.  We went through projects and then merged expedition outputted files into Panorama and would get errors with rules or objects that referenced invalid IPs like "10.88.280.10" - obviously 280 is not a valid octet.  But they were slipping through somehow.  I am not certain if the it was the rule that was referencing a direct (invalid) IP or if it was an object was just being missed.  I will keep a closer eye on this one in our next migration two weeks from now.

5.  Feature: macros - it would be very nice to be able to record a set of commands as a macro.  Our migrations are like 10 steps.  Each step is about 15 specific things that we need to do - it would awesome if we could record 10 different, 15 step macros and for future migrations just run the macros in order.  Combined with #2, this would dramatically reduce our clean/scrub process and eliminate a lot of the reptitiveness required.

[rolinger]

Also, regarding issue #1, if you search for a blank/empty value in services it will return all ones that are valid rules with "any" as the service.  There just seems be no filter variation that will weed out the nulls.