Adding Netbox

This commit is contained in:
Patrick Toal
2019-05-06 00:34:45 -04:00
parent 832502de34
commit 6e2205a046
278 changed files with 12767 additions and 0 deletions

View File

@@ -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

View File

@@ -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

View 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

View 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`

View 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