I really believe it has yet to be overstated, but is there any chance Cisco can concede that the way you configure FTD devices has not been a total success?
Here's my beefs:
- It's SLOW, regardless which method you use FMC/FDM.
- It's built only for organizations that are too large to trust their engineers with change-management.
- No CLI (real) support. New CLI support is like a fragmented spinning disk drive, and appears to still be under development.
- Too many relied upon and used black-listed commands or features ripped out vs. ASA.
- TAC support for FTD/FDM is overwhelmed.
- FTD is unreliable. I can't trust it as much as ASA for stability, flexibility, or reliability.
- Cisco is still struggling to keep up with the industry (too little, too late)
It goes without saying that engineers like me who have been using Cisco firewalls since 1999, when the PIX-520 was the greatest thing, when conduits were a thing, and you could clear the ACL list with a single command, are used to the CLI. Even later, the PDM and subsequently, ASDM were a god-send to people like me who prefer GUIs. FMC, on the other hand, is a hard and definitely not convenient to single engineer organizations. I gave up on it. Can't trust it. It fails, can be corrupted easily, and it's REALLY SLOW! More, it requires VPN's or WANs to manage remote FTD devices. Well, VPN and device management is still pretty broken.
Cisco FTD is a step in the right direction, but as one blogger on the Internet stated, "it's still in diapers". I wholeheartedly agree. even if the FirePower technology (it's really just a repackaged Snort), and the VPN technology (it's really Charon, or StrongSwan now) is fleshed out in gobs of open-source code, and it's super awesome to see a root-able access to CiscoLinux, the truth is, the basics of firewall management are still underwhelming, so say the very least.
CDO has promise, but in three months and multiple attempts, Cisco doesn't seem to know how to allow a customer to pilot it. more, Cisco is devoid of decent screenshots online---a very key selling point. I digress.
What I request
Where you can submit even black-listed commands through lina_cli (Cisco TAC has to do this to fix what FDM can't--trust me, I can prove it; it's broken, even in 6.5.0-115 code), it would be very welcome to allow the customer to choose to use or not use FDM/FMC/CDO, and return the CLI ability to those who are better suited for the job. Or, return all the missing features that ASDM supported, such as, separate DNS servers per DHCP scope, or management-interface, which was unblacklisted in 6.5.0-115 FTD code under a bug?
NOTE Sure lina_cli can be used to write commands directly to the configuration of FTD. That said, it should only be used to clean up a problem that FDM creates and cannot correct on its own, not to add anything new. For example, you can actually add additional configuration to the FTD through lina_cli, but as soon as you deploy something through FDM, you're previous lina_cli addition is wiped out. It was worth a shot, and in fact, would have been a nice thing to have for advanced users. I suppose, if you stuck with making changes to only lina_cli, this might be ok, but it's certainly not as easy to work with as ASA CLI was.
Cisco, please bring back what actually worked and if not, please openly document what went away from ASA code. You could save your customers a significant amount of frustration and embarrassment. As of right now, you're shutting out customers who rely on great, truly-vetted open-source automation tools that will (you watch) become the de-facto standards in the industry. Just ask me. It's a bit ironic to embrace open-source code in FTD, but lock it down to only supportable by Cisco products.
Finally, I realize this is not an appealing post for Cisco, but admitting it's ok to post feedback in a place where it might be received and acknowledged should certainly be something of interest to Cisco. I do encourage Cisco not to remove this post, as it's best to stay posted here among friends. Thanks!
RFC 1925
