08-10-2015 06:57 AM - edited 03-12-2019 05:44 AM
I am looking to setup redundant ASA5525-X firewalls with FireSight IPS for my customer.
I will be setting it up in advance in my lab area (along with other components of the project) and I want to make sure I won't have issues moving the VDC to the production environment once I go to install it. In particular, I don't want to get it working in my lab and find that the licensing has been invalidated because I put the VDC on a different VMware host/cluster.
What I intend to do is set it all up and activate licensing on my test VMware host and export the VDC to an OVF for deployment in the production environment. Then I expect to plug everything in onsite and deploy the OVF as a fully functioning guest.
Can someone confirm that this is a valid procedure. I figure it should be, but I don't want to be surprised when I am in front of my customer.
thanks...
Solved! Go to Solution.
08-10-2015 08:23 AM
I've been told be a Cisco SE that you can do that. I haven't tried it and have my doubts that it is always the case.
My reasoning is that the license key of a FMC is derived from the server's MAC address. There are certain ways to move a VM that don't convey the original MAC address.
I haven't been able to test it but I'd think if the VM's MAC address changes, the associated licenses would not be valid.
An alternative is to just export the policies you build in the lab and install them along with newly-issued licenses on the newly-built VM in the customer's environment.
08-10-2015 08:23 AM
I've been told be a Cisco SE that you can do that. I haven't tried it and have my doubts that it is always the case.
My reasoning is that the license key of a FMC is derived from the server's MAC address. There are certain ways to move a VM that don't convey the original MAC address.
I haven't been able to test it but I'd think if the VM's MAC address changes, the associated licenses would not be valid.
An alternative is to just export the policies you build in the lab and install them along with newly-issued licenses on the newly-built VM in the customer's environment.
08-10-2015 09:38 AM
Hi Marvin,
That was where I thought there may be an issue. It is easy enough to set the MAC address of a VM to whatever you want though, so assuming I am careful about retaining the MAC, is it a workable setup? Or are there other settings that contribute to the license file (Processor SN, etc).
thanks...
08-10-2015 09:52 AM
Good question. the license key is 14 bytes. The last 12 bytes are the MAC address of the FMC eth0 interface. (Or in the case of an ASA 5506/08/16 with on-board ASDM-based FireSIGHT Management, the MAC address of the FirePOWER module itself.) See screenshot below.
The first two bytes - I'm not sure where those come from and whether changing them will invalidate a license residing on the FMC.
We'll probably have to open a TAC case to get a definitive answer on that unless you know a Sourcefire development engineer. :)
08-10-2015 01:20 PM
So, just as an FYI..
I did some testing in my environment here. I was able to configure a VDC in my demo cluster and get is all working (with no licensing installed). I made note of the License Key, which was the MAC address preceded by the numbers 66: as in your screenshot.
I exported it to an OVF and imported it into a standalone management host we have in our production environment. It booted up fine, but showed the License Key as different - reflecting the new MAC address of the deployed server. I powered it off and changed the MAC address in VMware, then powered it back up again and the License Key was correct again.
Like I said, this is just an FYI. Thanks again for your help.
08-10-2015 01:32 PM
Excellent info. Thanks for the update. Paraphrasing Ben Franklin, I always say "An ounce of data is worth a pound of conjecture." :)
So the 66: prefix seems to be common for Virtual Defense Center / FireSIGHT Management Center (for the four I just went back and checked plus yours = sample size 5 anyhow). I had a customer with a DC appliance and it also used "66". So it doesn't appear to be tied to any host-specific attributes like processor SN.
My ASA 5506 with ASDM-based FMC uses "72" as the prefix.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide