Cisco FirePOWER fun. Discovery of quirks. Why does my dynamic routing fail each time I deploy?

This isn't to ask for help. This is something I discovered. I've recently become the go-to FirePOWER guy at my MSP job since I'm the only one that has had experience with it and has read all the stories about FirePOWER and how to fix them. I don't think FirePOWER is complete trash, but its pretty close. It's what you get when you try to layer several technologies on top of each other instead of creating a distinct and discrete service.

Anyways, I have recently had a client that had a really strange thing going on with their FirePOWER stack. It was a combo of east/west, north/south routing with a FirePOWER stack for each silo. Large DC hosting provider with several tenants. They have over 100 VLANs on the FirePOWER for several legit reasons. It's very well configured. FirePOWER just wants us to hate it.

They have had an issue where they couldn't deploy anything, ANYTHING, outside of maintenance windows since when they did, it would cause their dynamic routing (OSPF in this case) to drop and re-converge. Troubleshooting took a long time cause of that with windows occurring at times that I'd rather be sleeping. Tshoot files flying everywhere. It was always the same regardless of the little tricks I'd try. Flex configs did nothing, transcripts would fail to load (still don't know why, thanks FirePOWER) and I was getting no where.

Well, here's the thing. FirePOWER doesn't try to sanitize configs before trying to deploy. Sure it'll tell you if something just won't work, but somethings will get through. One of the things is IP configurations. You can have an IP that looks like;

ip address 10.00.0.1 255.255.255.0 

And it will take it. That extra zero? It takes it. That's a problem. What happens then is when you deploy the config, the FMC will compare configs to the FTD and see this on the FTD;

ip address 10.0.0.1 255.255.255.0 

That's not what the FMC sees as what the config should be. So it overrides it with the 10.00.0.1 address, but the FTD will only display 10.0.0.1 in its config. So each and every deploy you will see the FMC applying the 10.00.0.1 address to that interface. What happens when you change IPs on a dynamically routed interface? It resets the dynamic routing. Traffic fails, OSPF re-converges, things fix itself after a little while. You get rid of that extra 0 and it will no longer do that. Took far too long to discover that. We almost went to a full static route solution out of pure frustration.

tl;dr:FMC will allow IP octets to have multiple zeros. FTDs don't display multiple zeros in config. FMC thinks FTDs are wrong, sends IP address information to FTD as new config, will cause dynamic routing to fail. Remove all extra zeros from FMC IP address configs to fix issue.