08-07-2013 04:01 AM - edited 03-11-2019 07:22 PM
Hi there,
We have procured ASA 5585 S20X , that will replace our existing ASA & the FWSM . We have some 21 contexts to be migrated from FWSM to the new ASA box . Does the Cisco migration procedure provided in documentation "fwsm2asasm" suffice our needs or is this only for the ASA Service Modules ?
Thanks
Prabs
08-07-2013 06:06 AM
That tool is only for migration to the ASA SM which uses VLAN interfaces like the FWSM does.
An ASA 5585 with 21 contexts is going to have to use some combination of physical Ethernet ports and logical subinterfaces (and possibly Etherchannels) and will require a non-trivial amount of engineering effort to migrate the contexts manually.
08-07-2013 06:20 AM
Thanks Marvin ; the differences in configuration post migration to ASA5585 , i,e, all differences highlighted in documentation "fwsm2asasm" will also apply to non Service Modules ?
Finally , do we have any references/best practice to migrate from FWSM to ASA (non Service Module)
Thanks
Prabs
08-07-2013 06:26 AM
You may get some utility from the tool (NAT migration if you're doing NAT your FWSM) but I'd be very careful just dropping it in as-is with tweaks to account for interfaces vs. VLANs. Consider, for example how the ASA access-lists are applied to interface names.
Personally I'm not aware of any best practices / guides. Our take (as a Cisco partner) would be to approach it is an engineering task and apply some old fashioned manual configuration skills by an experienced security expert to the job.
I'd perhaps run the tool and just use that as an offline starting point for the migration effort.
08-07-2013 06:37 AM
Thanks Mavin, appreciate your swift response . Taken note of your points ; will plan this accordingly.
Thanks
Prabs
08-07-2013 06:42 AM
You're welcome.
Please rate responses according to their value in answering your question and mark your question as answered if it is.
08-07-2013 06:58 AM
Hi,
I have migrated one around 100 Security Context FWSM to an ASA5585-X SSP-20.
I would first suggest you start by planning the setup of the new ASA in the network. As you know the FWSM is directly connected to another device as a separate module while the ASA is its own device. Therefore you have to check what the current bandwith usage through the FWSM is and plan the connection to the network accordingly so that the ASA doesnt come a bottleneck in the network.
Though I imagine this has already been done before aquiring the ASA. The FWSM to my understanding has fairly higher throughput than most ASA models other than the ASA5585-X higher end models and 5580 models. The FWSM also benefits from being directly attached to your core device.
As Marvin already mentioned, you are probably going to use Trunk interfaces or Trunk with Port-Channel configuration. Natuarally the fact if you have the 10G I/O license might also factor into some choises made.
Naturally when you begin the project of replacing the FWSM with the ASA you should first go through all the Security Contexts and possibly rest of the network to really understand what is required from the new ASA. After this you should be able to easily produce the correct configurations for the new ASA. Usually this is something that has already been done as you might have maintained the FWSM environment for a long time and know it in and out already.
You could then probably separate each Security Contexts configurations to their own files and migrate the configurations manually one by one. You could also go through the required steps to eventually direct the traffic to the ASA instead of the FWSM.
You will probably be able to install the ASA to the network and create all the Security Contexts to the ASA with full configurations before you really migrate any Security Context from the original FWSM. The actual migration process might be as simple as shutting down /enabling interfaces/ports, changing routes and moving IP addresses between interfaces. Naturally this requires that you have a good understanding how everything works.
I essentially did the migration in following steps
The above served me well atleast. I think I ran into 2-3 minor problems where the actual problem was related to a typo. Once it was forgetting to enable default route propagation adverticement in the network as the core device had changed. One was having a typo in NAT configuration.
I would also suggest that you also use the Cisco Support Community (just like at the moment) and ask if you run into some problems with migrating some configurations like the NAT configurations. There is usually always someone that can help with those.
Hope this was of any help.
- Jouni
08-07-2013 09:35 AM
Thanks for the detailed input Jouni , definitely would be helpful for my planning ..
Thanks
Prabs
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