Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Coming this summer: Cisco Support Community and Cisco Communities are merging. Learn more

FirePOWER Blogs



After deploying a new Virtual Firesight Management Center (FMC), the console may display the message "WRITE SAME Failed. Manually Zeroing" after installation.



 Does this message indicate a failure during installation? Should it be cause for concern?



 This message does not indicate an error and can safely be ignored. The reason that this is displayed is because the VMware storage driver does not support the "WRITE SAME" command. WRITE SAME is a SCSI command that is used to zero out blocks on disk. Since this command is not supported, this message will be displayed and the system will then proceed with a fallback command to accomplish the same task of zeroing out blocks.


I hope this research helps others with the same question. Enjoy...

I wasn’t sure, so I researched the subject communications channel between FirePOWER Management Center and its managed devices. My question was the security of the communications channel – especially in the scenario of a remote or cloud-based FMC with on-premises sensors.

I found the following documentation:

Firepower Management Centers and their managed devices communicate using a two-way, SSL-encrypted communication channel, which by default uses port 8305/tcp.

So I wanted to grab some traffic to confirm it.

Here’s how I got a capture (run from the FMC):

sudo tcpdump -i eth0 host -s 1514 -w tcp8305_2.pcap

eth0 is the management interface, the host is a managed device, we want the full 1514 byte Ethernet frame and will write the output to a pcap file so that Wireshark automatically recognizes it later.

Then use SCP on my computer to copy the file. (FMC does not have an ftp client or server in its Linux distro.)

Before opening it in Wireshark, I changed the settings under “Edit, Preferences, Protocols, http” to recognize port 8305 as SSL/TLS. Once we do that, Wireshark will recognize TLS 1.2 headers and confirm via the protocol decode that the traffic is using a secure channel. Note the decoded TLS version and encrypted application data in the following snippet:


Good fun!