Adding Netbox
This commit is contained in:
@@ -0,0 +1,24 @@
|
||||
# Configure VPN routing as initiator
|
||||
The `cloud_vpn/configure_routing_initiator` function will configure the routing where
|
||||
a VPN as initiator has been configured previously on Cisco IOS devices.
|
||||
It is performed by calling the `cloud_vpn/configure_routing_initiator` task from the role.
|
||||
The task will process variables needed for routing configuration and apply it to the device.
|
||||
|
||||
Below is an example to configure routing on a CSR device configured as initiator,
|
||||
where the responder is AWS VPN.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
tasks:
|
||||
- name: Configure initiator routing
|
||||
include_role:
|
||||
name: ansible-network.cisco_ios
|
||||
tasks_from: cloud_vpn/configure_routing_initiator
|
||||
vars:
|
||||
cloud_vpn_responder_provider: aws_vpn
|
||||
cloud_vpn_responder_cidr: 192.168.0.0/24
|
||||
```
|
||||
|
||||
## Notes
|
||||
None
|
||||
@@ -0,0 +1,33 @@
|
||||
# Configure VPN as initiator
|
||||
The `cloud_vpn/configure_vpn_initiator` function will configure IPSEC VPN as initiator
|
||||
on Cisco IOS devices.
|
||||
It is performed by calling the `cloud_vpn/configure_vpn_initiator` task from the role.
|
||||
The task will process variables needed for VPN configuration and apply it to the device.
|
||||
|
||||
Below is an example to configure an IPSEC VPN as initiator on CSR device, where
|
||||
the responder is AWS VPN:
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
tasks:
|
||||
- name: Configure IPSEC VPN as initiator
|
||||
include_role:
|
||||
name: ansible-network.cisco_ios
|
||||
tasks_from: cloud_vpn/configure_vpn_initiator
|
||||
vars:
|
||||
cloud_vpn_name: myvpn
|
||||
cloud_vpn_psk: mypsksecret
|
||||
cloud_vpn_initiator_provider: csr
|
||||
cloud_vpn_initiator_outside_interface: GigabitEthernet1
|
||||
cloud_vpn_initiator_tunnel_ip: 169.254.56.25
|
||||
cloud_vpn_initiator_tunnel_failover_ip: 169.254.56.29
|
||||
cloud_vpn_responder_provider: aws_vpn
|
||||
cloud_vpn_responder_public_ip: 18.191.132.220
|
||||
cloud_vpn_responder_failover_ip: 18.191.132.221
|
||||
cloud_vpn_responder_tunnel_ip: 169.254.56.26
|
||||
cloud_vpn_responder_tunnel_failover_ip: 169.254.56.30
|
||||
```
|
||||
|
||||
## Notes
|
||||
None
|
||||
78
roles/ansible-network.cisco_ios/docs/config_manager/get.md
Normal file
78
roles/ansible-network.cisco_ios/docs/config_manager/get.md
Normal file
@@ -0,0 +1,78 @@
|
||||
# Get configuration from device
|
||||
The `config_manager/get` function will return the either the current active or current
|
||||
saved configuration from an Cisco IOS devices. This function is only
|
||||
supported over `network_cli` connections.
|
||||
|
||||
The `config_manager/get` function will also parse the device active configuration into
|
||||
a set of host facts during its execution. All of the parsed facts are stored
|
||||
in the ``cisco_ios.config`` top level facts key.
|
||||
|
||||
## How to get the device configuration
|
||||
Retrieving the configuration from the device involves just calling the
|
||||
`config_manager/get` function from the role. By default, the `config_manager/get` role will
|
||||
return the device active (running) configuraiton. The text configuration will
|
||||
be returned as a fact for the host. The configuration text is stored in the
|
||||
`configuration` fact.
|
||||
|
||||
Below is an example of calling the `config_manager/get` function from the playbook.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible-network.cisco_ios
|
||||
function: config_manager/get
|
||||
```
|
||||
|
||||
The above playbook will return the current running config from each host listed
|
||||
in the `cisco_ios` group in inventory.
|
||||
|
||||
### Get the current startup config
|
||||
By default the `config_manager/get` function will return the device running
|
||||
configuration. If you want to retrieve the device startup configuration, set
|
||||
the value of `source` to `startup`.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible-network.cisco_ios
|
||||
function: config_manager/get
|
||||
source: startup
|
||||
```
|
||||
|
||||
### Implement using tasks
|
||||
The `config_manager/get` function can also be implemented in the `tasks` during the
|
||||
playbook run using either the `include_role` or `import_role` modules as shown
|
||||
below.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
tasks:
|
||||
- name: collect facts from cisco ios devices
|
||||
include_role:
|
||||
name: ansible-network.cisco_ios
|
||||
tasks_from: config_manager/get
|
||||
```
|
||||
|
||||
## How to add additional parsers
|
||||
|
||||
The configuration facts are returned by this function are parsed using the
|
||||
parsers in the `parser_templates/config` folder. To add a new parser, simply
|
||||
create a PR and add the new parser to the folder. Once merged, the
|
||||
`config_manager/get` function will automatically use the new parser.
|
||||
|
||||
## Arguments
|
||||
|
||||
### source
|
||||
|
||||
Defines the configuration source to return from the device. This argument
|
||||
accepts one of `running` or `startup`. When the value is set to `running`
|
||||
(default), the current active configuration is returned. When the value is set
|
||||
to `sartup`, the device saved configuration is returned.
|
||||
|
||||
The default value is `running`
|
||||
|
||||
## Notes
|
||||
None
|
||||
86
roles/ansible-network.cisco_ios/docs/config_manager/load.md
Normal file
86
roles/ansible-network.cisco_ios/docs/config_manager/load.md
Normal file
@@ -0,0 +1,86 @@
|
||||
# Load configuration onto device
|
||||
The `config_manager/load` function will take a Cisco IOS configuration file and load it
|
||||
onto the device. This function supports either merging the configuration with
|
||||
the current active configuration or replacing the current active configuration
|
||||
with the provided configuration file.
|
||||
|
||||
The `config_manager/load` function will return the full configuration diff in the
|
||||
`ios_diff` fact.
|
||||
|
||||
NOTE: When performing a configuration replace function be sure to specify the
|
||||
entire configuration to be loaded otherwise you could end up not being able to
|
||||
reconnect to your IOS device after the configuration has been loaded.
|
||||
|
||||
## How to load and merge a configuration
|
||||
Loading and merging a configuration file is the default operation for the
|
||||
`config_manager/load` function. It will take the contents of a Cisco IOS configuration
|
||||
file and merge it with the current device active configurations.
|
||||
|
||||
Below is an example of calling the `config_manager/load` function from the playbook.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible_network.cisco_ios
|
||||
function: config_manager/load
|
||||
config_manager_text: "{{ lookup('file', 'ios.cfg') }}"
|
||||
```
|
||||
|
||||
The above playbook will load the specified configuration file onto each device
|
||||
in the `cisco_ios` host group.
|
||||
|
||||
## How to replace the current active configuration
|
||||
The `config_manager/load` function also supports replacing the current active
|
||||
configuration with the configuration file located on the Ansible controller.
|
||||
In order to replace the device's active configuration, set the value of the
|
||||
`config_manager_replace` setting to `True`.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible_network.cisco_ios
|
||||
function: config_manager/load
|
||||
config_manager_text: "{{ lookup('file', 'ios.cfg') }}"
|
||||
config_manager_replace: true
|
||||
```
|
||||
|
||||
|
||||
## Arguments
|
||||
|
||||
### config_manager_text
|
||||
|
||||
This value accepts the text form of the configuration to be loaded on to the remote device.
|
||||
The configuration file should be the native set of commands used to configure the remote device.
|
||||
|
||||
The default value is `null`
|
||||
|
||||
### config_manager_replace
|
||||
|
||||
Specifies whether or not the source configuration should replace the current
|
||||
active configuration on the target IOS device. When this value is set to
|
||||
False, the source configuration is merged with the active configuration. When
|
||||
this value is set to True, the source configuration will replace the current
|
||||
active configuration
|
||||
|
||||
The default value is `False`
|
||||
|
||||
### ios_config_remove_temp_files
|
||||
|
||||
Configures the function to remove or not remove the temp files created when
|
||||
preparing to load the configuration file. There are two locations for temp
|
||||
files, one on the Ansible controller and one on the device. This argument
|
||||
accepts a boolean value.
|
||||
|
||||
The default value is `True`
|
||||
|
||||
### ios_config_rollback_enabled
|
||||
|
||||
Configures whether or not automatic rollback is enabled during the execution of
|
||||
the function. When enabled, if an error is enountered, then the configuration
|
||||
is automatically returned to the original running-config. If disabled, then
|
||||
the rollback operation is not performed automatically.
|
||||
|
||||
The default value is `True`
|
||||
|
||||
166
roles/ansible-network.cisco_ios/docs/get_facts.md
Normal file
166
roles/ansible-network.cisco_ios/docs/get_facts.md
Normal file
@@ -0,0 +1,166 @@
|
||||
# Get facts from device
|
||||
|
||||
The `get_facts` function can be used to collect facts from an Cisco IOS
|
||||
devices. This function is only supported over `network_cli` connection
|
||||
type and requires the `ansible_network_os` value set to `ios`.
|
||||
|
||||
## How to get facts from the device
|
||||
|
||||
To collect facts from the device, simply include this function in the playbook
|
||||
using either the `roles` directive or the `tasks` directive. If no other
|
||||
options are provided, then all of the available facts will be collected for the
|
||||
device.
|
||||
|
||||
Below is an example of how to use the `roles` directive to collect all facts
|
||||
from the IOS device.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible-network.cisco_ios
|
||||
function: get_facts
|
||||
```
|
||||
|
||||
The above playbook will return the facts for the host under the `cisco_ios`
|
||||
top level key.
|
||||
|
||||
### Filter the subset of facts returned
|
||||
|
||||
By default all available facts will be returned by the `get_facts` function.
|
||||
If you only want to return a subset of the facts, you can specify the `subset`
|
||||
variable as a list of keys to return.
|
||||
|
||||
For instance, the below will return only `interfaces` and `system` facts.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
roles:
|
||||
- name ansible-network.cisco_ios
|
||||
function: get_facts
|
||||
subset:
|
||||
- system
|
||||
```
|
||||
|
||||
### Implement using tasks
|
||||
|
||||
The `get_facts` function can also be implemented using the `tasks` directive
|
||||
instead of the `roles` directive. By using the `tasks` directive, you can
|
||||
control when the fact collection is run.
|
||||
|
||||
Below is an example of how to use the `get_facts` function with `tasks`.
|
||||
|
||||
```
|
||||
- hosts: cisco_ios
|
||||
|
||||
tasks:
|
||||
- name: collect facts from cisco ios devices
|
||||
import_role:
|
||||
name: ansible-network.cisco_ios
|
||||
tasks_from: get_facts
|
||||
vars:
|
||||
subset:
|
||||
- system
|
||||
- interfaces
|
||||
```
|
||||
|
||||
## Adding new parsers
|
||||
|
||||
Over time new parsers can be added (or updated) to the role to add additional
|
||||
or enhanced functionality. To add or update parsers perform the following
|
||||
steps:
|
||||
|
||||
* Add (or update) command parser located ino `parse_templates/cli`
|
||||
|
||||
* Update the `vars/get_facts_command_map.yaml` file to map the CLI command
|
||||
to the parser
|
||||
|
||||
The `get_facts_command_map.yaml` file provides a mapping between CLI command
|
||||
and parser used to transform the output into Ansible facts.
|
||||
|
||||
### Understanding the mapping file
|
||||
|
||||
The command map file provides the mapping between show command and parser file.
|
||||
The format of the file is a list of objects. Each object supports a set of
|
||||
keys that can be configured to provide granular control over how each command
|
||||
is implemented.
|
||||
|
||||
Command map entries support the following keys:
|
||||
|
||||
#### command
|
||||
|
||||
The `command` key is required and specifies the actual CLI command to execute
|
||||
on the target device. The output from the command is then passed to the parser
|
||||
for further processing.
|
||||
|
||||
#### parser
|
||||
|
||||
The `parser` key provides the name of the parser used to accept the output from
|
||||
the command. The parser value shoule be the command parser filename either
|
||||
relative to `parser_templates/cli` or absolute path. This value is required.
|
||||
|
||||
#### engine
|
||||
|
||||
This key accepts one of two values, either `command_parser` or `textfsm_parser`.
|
||||
This value instructs the the parsing function as to which parsing engine to
|
||||
use to parse the output from the CLI command.
|
||||
|
||||
This key is not required and, if not provided, the engine will assumed to be
|
||||
`command_parser`
|
||||
|
||||
#### groups
|
||||
|
||||
Commands can be contained in one (or more) groups to make it easy for playbook
|
||||
designers to filter specific facts to retreive from the network device. The
|
||||
`groups` key must be a list and contain the groups the this command should be
|
||||
associated with.
|
||||
|
||||
#### pre_hook
|
||||
|
||||
The `pre_hook` key provides the path to the set of tasks to include prior
|
||||
to running the command on the CLI. This is useful if there is a need to check
|
||||
if a command is available or supported on a particular version.
|
||||
|
||||
#### post_hook
|
||||
|
||||
The `post_hook` key provides the path to the set of tasks to include after the
|
||||
command has been run on the target device and its results have been parsed by
|
||||
the parser.
|
||||
|
||||
## Arguments
|
||||
|
||||
### ios_get_facts_subset
|
||||
|
||||
Defines the subset of facts to collection when the `get_facts` function is
|
||||
called. This value must be a list value and contain only the sub keys for the
|
||||
facts you wish to return.
|
||||
|
||||
The default value is `default`
|
||||
|
||||
#### Aliases
|
||||
|
||||
* subset
|
||||
|
||||
#### Current supported values for subset are
|
||||
|
||||
* default
|
||||
* all
|
||||
* interfaces
|
||||
* bgp
|
||||
* lldp
|
||||
|
||||
### ios_get_facts_command_map
|
||||
|
||||
Defines the command / parser mapping file to use when the call to `get_facts`
|
||||
is made by the playbook. Normally this value does not need to be modified but
|
||||
can be used to pass a custom command map to the function.
|
||||
|
||||
The default value is `vars/get_facts_command_map.yaml`
|
||||
|
||||
|
||||
## Notes
|
||||
|
||||
None
|
||||
|
||||
|
||||
Reference in New Issue
Block a user