cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6049
Views
0
Helpful
24
Replies

Cisco ASA 5512 - restore configuration from backup

Techme
Level 1
Level 1

Hello.

 

I am quite unexperienced with ASA.

 

Does the system require a reboot after restoring the configuration from a backup?

 

Thank you for any information provided.

 

Kind Regards,

   

24 Replies 24

Hello Francesco,

 

The ARP collision problem is solved.

 

I turned off the secondary device and all the errors are gone.

 

I am not sure what happened but the failover device took over the active primary firewall and was causing trouble.

 

Tonight I will turn the failover device back online and in theory should pick all the configuration from the primary firewall.

 

Thank for the help provided so far.

 

I will update you.

 

Kind Regards

 

 

Cool to know that the issue was there. Let me know if you need any help

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hello Francesco,

 

Here is an update when turned back on the failver firewall:

 

The ARP collision occured again and I noticed that I was disconnected from the firewall.

 

When I logged in again every appeared normal ( I used the same IP address of the active firewall to login .26 the passive firewall is .27) but the device uptime started from 0 this makes me thing that I was actually connected on the failover.

 

When I turned the failover off again and logged in again the uptime was showing over 600 days which I believe is the primary active firewall.

 

For some reason when I turn the failover on its like that is taking over but both devices are trying to process the traffic ( not aware of each other?).

 

Looking at the failover status page on ASDM:

 

Failover On
Failover unit Primary
Failover LAN Interface: LAN_Fail GigabitEthernet0/5 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 114 maximum
Version: Ours 8.6(1)2, Mate 8.6(1)2
Last Failover at: 12:11:51 GMT/BDT Oct 1 2018
This host: Primary - Active
Active time: 54613131 (sec)
slot 0: ASA5512 hw/sw rev (1.0/8.6(1)2) status (Up Sys)
Interface Outside (xxx.xxx.xxx.26): Normal (Waiting)
Interface Inside (xxx.xxx.xxx.65): Normal (Waiting)
Interface Inside2 (xxx.xxx.xxx.129): Normal (Waiting)
Interface Inside3 (xxx.xxx.xxx.241): No Link (Waiting)
slot 1: IPS5512 hw/sw rev (N/A/) status (Unresponsive/Up)
Other host: Secondary - Failed
Active time: 3970 (sec)
slot 0: ASA5512 hw/sw rev (3.0/8.6(1)2) status (Unknown/Unknown)
Interface Outside (xxx.xxx.xxx.27): Unknown (Monitored)
Interface Inside (xxx.xxx.xxx.76): Unknown (Monitored)
Interface Inside2 (xxx.xxx.xxx.182): Unknown (Monitored)
Interface Inside3 (xxx.xxx.xxx.254): Unknown (Waiting)
slot 1: IPS5512 hw/sw rev (N/A/) status (Unknown/Unknown)

Stateful Failover Logical Update Statistics
Link : Unconfigured.

 

At first impression I think I will need to update the device by clicking the "Make active" or "Make stanby" depending on which device I am connected when I log back in ASDM.

 

Most likely when I turn the failover back on and access ASDM with the ip address xx.xxx.xx.26 I will be connected on the failover, I am not sure but I think to solve the issue I just need to instruct the system to be in standby?

 

Kind Regards and thank you for your time

I don't know the status of your secondary box compared to the primary.
Does inside3 interface is also down on secondary? You can run the command sh run all monitor-interface on both boxes.
If inside3 is monitored on both but down on primary box, that's why it keeps falling over secondary box.
To test, you can do no monitor-interface inside3 and connect back the secondary box, it should make secondary box as active.

If the inside3 isn't monitored (I wouldn't believe so based on output) and primary box is up to date with the correct config, I would suggest to keep disconnected the secondary, flush the config, update the software and configure the failover only. Then connect it back and it should be back on.

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

Hello Francesco,

 

I wanted to let you know that I solved the problem.

 

As you suggested I reconfigured the Failover on the secondary firewall and the issue is solved.

 

Thank you so much for all the help and information provided.

 

Kind Regards

Super! Thanks for the follow up

Thanks
Francesco
PS: Please don't forget to rate and select as validated answer if this answered your question

johnd2310
Level 8
Level 8

Hi,

 

How did you restore the configuration?

 

Thanks

John

**Please rate posts you find helpful**

Hello John

 

I restored the configuration via asdm but I did not reboot the device yet.

Kind regards 

 

 

Trying to understand what is the reason of restoring from backup, is something broken ?

If nothing broken, why not compare the current config with backup config - do only changes required and save it.

 

If this is not the case i am more interested to know your requirements ?

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Hello,

 

Thank you for the response.

 

I realised of the mistake after I performed the restore from backup (via ASDM and I did not reboot the device).

 

I was a little bit in hurry to have the systems back online.

 

Since I performed the restore from backup i noticed that the failover firewall become unresponsive and I noticed the following errors in the syslog:

 

No matching connection for ICMP error message: icmp src Inside2:xx.xxx.xxx.xxx dst Outside:xxx.xxx.xx.xxx (type 3, code 10) on Inside2 interface.  Original IP payload: tcp src xx.xxx.xxx.xxx/993 dst xx.xxx.xxx.xxx/58062.

 

Received ARP request collision from 10.1.1.1/c08c.608b.b278 on interface LAN_Fail with existing ARP entry 10.1.1.1/a0e0.afa2.854e

4 Oct 07 2018 10:53:41 405001 Received ARP request collision from xx.xxx.xxx.65/c08c.608b.b276 on interface Inside with existing ARP entry xx.xxx.xxx.65/a0e0.afa2.854c

 

I am not sure if refreshing the ARP cache and/or turning off the failover may solve the above problem.

 

Any suggestion would be highly appreaciated and thank you so much for the response.

 

Kind Regards,

   

 

Review Cisco Networking for a $25 gift card