Hi,
I kind of accidently managed to find solution. Writing below script solved
the issue. My earlier assumption was that ansible would connect to the
device even before it would execute the 1st TASK but based on my teasting
below script, iam thinking it probably connects when executing the first
task in below script.
---
- name: PLAYBOOK FOR ROUTER PRE-UPGRADE TASKS
hosts: ACTIVEFIREWALL
gather_facts: false
connection: network_cli
vars:
ansible_network_os: asa
tasks:
- name: RELOAD DEVICE
ios_command:
commands:
- command: 'reload'
prompt: '[confirm]'
answer: 'y'
vars:
ansible_command_timeout: 180
- name: PLAYBOOK FOR ROUTER PRE-UPGRADE TASKS
hosts: STANDBYFIREWALL
gather_facts: false
connection: network_cli
vars:
ansible_network_os: asa
tasks:
- name: WAIT FOR ROUTER TO REBOOT
wait_for:
host: "{{ ansible_host }}"
port: 22
delay: 10
timeout: 300
delegate_to: localhost
ignore_errors: yes
On a separate note, none of the ansible courses geared for network
engineers that i took covered Jinja2 in detail. I felt even what was
covered seemed to skim the surface and so iam not sure how to use jinja2
except for the most basic task (never felt like this about any other
ansible concept after having spent consioderable time learning it). Are you
aware of any good book/udemy couse for Jinja2 template?
Thanks,
Vikram
On Monday, 9 August, 2021 at 12:37:59 am UTC+5:30 [email protected]
wrote:
> Create a task in your play with a shell module to do arp to all your
> hosts. Just filter the destination Mac and save it via jinja.
> It would be great if you can establish any connection before you do the
> arp, else you won't get the output.
>
> On Mon, 9 Aug, 2021, 12:28 am Vikram S, <[email protected]> wrote:
>
>> Hi,
>>
>> Thanks for your suggestion but i just now checked asa_facts doesn't
>> gather mac address. The modules for ASA are not as feature rich nor
>> extensive as that for network routers and switches (ios).
>>
>> So iam wondering if i should consider this workaround: as mentioned
>> above, end the 1st play playbook after reload. Then write 2nd playbook
>> referencing standby firewall in 'hosts' column and keep below TASK as first
>> task. So the script aill automatically take access to standby firewall (the
>> active firewall that reloaded and became standby now) and check if IOS is
>> upgraded, etc. But only issue is that i don't know when the standby
>> firewall may come up, so 2nd play may fail to connect and playbook may end.
>> So can i use ignore_errors keyword for 2nd playbook as a whole instead of
>> specific tasks (as i have used below)?
>>
>>
>> - name: 2ND PLAY FOR ASA UPGRADE
>> hosts: STANDBYFIREWALL
>> gather_facts: false
>> connection: network_cli
>>
>> vars:
>> ansible_network_os: asa
>>
>> tasks:
>> - name: WAIT FOR
>> wait_for:
>> host: "{{ ansible_host }}"
>> port: 22
>> delay: 300
>> timeout: 4800
>> delegate_to: localhost
>> ignore_errors: yes
>>
>> - name: sleep for 10 more minutes and continue with play
>> wait_for:
>> timeout: 600
>> delegate_to: localhost
>>
>> - name: WAIT FOR
>> wait_for:
>> host: "{{ ansible_host }}"
>> port: 22
>> delay: 300
>> timeout: 4800
>> delegate_to: localhost
>>
>> Thanks,
>> Vikram
>>
>> On Sunday, 8 August, 2021 at 11:17:12 pm UTC+5:30 [email protected]
>> wrote:
>>
>>> Just a thought.
>>> Try to gather the MAC address from the fact, register it and save it as
>>> a local file?
>>>
>>> Write a play with two tasks,
>>> One for ping test.
>>> Second for ios validation.
>>> Schedule this job for every 5 min and it should gather the fact and
>>> match the mac saved in the local file.
>>> Another task is, the job should run the ios version fetch command and
>>> save it in the local file.
>>>
>>> Remember. Your inventory should be updated with the hoatname of fw, or
>>> static ip.
>>> You can use jinja template for preparing the report.
>>>
>>> On Sun, 8 Aug, 2021, 10:17 pm Vikram S, <[email protected]> wrote:
>>>
>>>> I am trying to write a script for IOS upgrade of active-standby ASA
>>>> firewall (failover pair).
>>>>
>>>> 2 firewalls are configured as Active-standby firewall for failover
>>>> purpose. Which means if the active firewall goes down, standby firewall
>>>> automatically becomes the active and standby also takes over the IP of
>>>> active firewall and this is what creates hurdle in writing script for ASA.
>>>>
>>>> Below is the script i have written for Routers and is successfully
>>>> working but facing a challenge in writing similar script for ASA firewall.
>>>> I have given the portion where script waits for router to come back UP
>>>> after reboot and then checks if image is successfully upgraded. But when i
>>>> upgrade and reboot active firewall, standby firewall would immediately
>>>> become active and script would detect the wrong device to be UP and would
>>>> be checking the ios image of wrong device.
>>>>
>>>> I thought of writing multiple plays within same playbook wherein the
>>>> 1st play would end after reboot and 2nd play would check the standby
>>>> device
>>>> (the active would have become standby after reboot since the earlier
>>>> standby took over as active) but issue is firewall may take anywhere
>>>> between 10-50 mins to reboot and come back UP. So my 2nd play would fail
>>>> immediately unless i use wait_for module for certain minutes before
>>>> continuing with 2nd play. Downside to this approach is many a times,
>>>> firewall would come back earlier than the time set in wait_for module and
>>>> precious time wasted.
>>>>
>>>>
>>>> - name: WRITE TO MEMORY
>>>>
>>>> ios_config:
>>>>
>>>> save_when: always
>>>>
>>>> vars:
>>>>
>>>> ansible_command_timeout: 180
>>>>
>>>>
>>>> - name: RELOAD DEVICE
>>>>
>>>> ios_command:
>>>>
>>>> commands:
>>>>
>>>> - command: 'reload'
>>>>
>>>> prompt: '[confirm]'
>>>>
>>>> answer: 'y'
>>>>
>>>> vars:
>>>>
>>>> ansible_command_timeout: 180
>>>>
>>>>
>>>> - name: WAIT FOR ROUTER TO REBOOT
>>>>
>>>> wait_for:
>>>>
>>>> host: "{{ ansible_host }}"
>>>>
>>>> port: 22
>>>>
>>>> delay: 300
>>>>
>>>> timeout: 4800
>>>>
>>>> delegate_to: localhost
>>>>
>>>>
>>>> - name: GATHER NEW DEVICE FACTS
>>>>
>>>> ios_facts:
>>>>
>>>>
>>>> - assert:
>>>>
>>>> that:
>>>>
>>>> - ansible_net_version is version('16.12.04', '==')
>>>>
>>>> fail_msg: "IMAGE WAS NOT UPGRADED. PLAYBOOK IS ENDING"
>>>>
>>>> success_msg: "IMAGE HAS BEEN SUCCESSFULLY UPGRADED"
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Vikram
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Ansible Project" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/ansible-project/d1068dc0-0d8a-4b6d-85c4-963f722677c8n%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/ansible-project/d1068dc0-0d8a-4b6d-85c4-963f722677c8n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ansible Project" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/ansible-project/dcf47a0a-54ef-4328-b6ba-d7c4270b2b3cn%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/ansible-project/dcf47a0a-54ef-4328-b6ba-d7c4270b2b3cn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/4c3d884e-c70f-4b53-8f60-b309d0281666n%40googlegroups.com.
