In the consolidation phase of example.com, the non-cloud Production Services network devices and server have been temporarily relocated to a data center.
A third server is being added: server02.
Redundant network devices are to be provisioned in the data center named spine02 and leaf02.
For now, there is only one connection to the internet (interface eth1 on spine01).
We know that the eth1 interface on spine01 is actually a link to the GigabitEthernet2 interface of cs01, but for the sake of the story, we imagine this Ethernet interface on spine01 (eth1, that is) is connected the Network Termination Equipment (NTE) that marks the demarcation point (Demarc) between example.com as the customer and the Internet Service Provider (ISP) providing internet access to the data center.
The Production Services Network of example.com, during this phase, consists of five network devices at two different locations, plus three servers:
In the cloud
Network devices
cs01
Servers
server03
At the office
Network devices
spine01
spine02
leaf01
leaf02
Servers
server01
server02
Jasper asks you to compose a playbook that will:
Apply interface descriptions to interfaces as documented in the table.
Configure layer 3 on interfaces as documented in the table.
Enable OSPF and configure it to advertise network routes appropriately.
Verify that the servers are reachable from the network.
You will be accessing the network devices by way of management interfaces. Those interfaces are already configured with respect to layer 3 and up, and should not be changed.
Table 6.1. Consolidation Phase Interface Descriptions
| Devices | Interfaces | Descriptions |
|---|---|---|
| cs01 | GigabitEthernet1 | management |
| GigabitEthernet2 | outside | |
| GigabitEthernet4 | inside | |
| spine01 | eth0 | management |
| eth1 | leaf01 | |
| eth2 | leaf02 | |
| eth5 | outside | |
| spine02 | eth0 | management |
| eth1 | leaf01 | |
| eth2 | leaf02 | |
| leaf01 | eth0 | management |
| eth1 | server01 | |
| eth5 | spine01 | |
| eth6 | spine02 | |
| leaf02 | eth0 | management |
| eth2 | server02 | |
| eth5 | spine01 | |
| eth6 | spine02 |
Table 6.2. Consolidation Phase Layer 3 Addressing (management interface not shown)
| Devices | Interfaces | Descriptions |
|---|---|---|
| cs01 | Loopback1 | 172.16.0.1/32 |
| GigabitEthernet2 | 172.16.2.2/30 | |
| GigabitEthernet4 | 172.16.10.1/30 | |
| spine01 | lo | 10.0.0.1/32 |
| eth1 | 10.10.5.1/30 | |
| eth2 | 10.10.6.1/30 | |
| eth5 | 172.16.2.1/30 | |
| leaf01 | lo | 10.0.0.11/32 |
| eth1 | 10.10.10.1/30 | |
| eth5 | 10.10.5.2/30 | |
| eth6 | 10.10.7.2/30 | |
| spine02 | lo | 10.0.0.2/32 |
| eth1 | 10.10.7.1/30 | |
| eth2 | 10.10.8.1/30 | |
| leaf02 | lo | 10.0.0.12/32 |
| eth2 | 192.168.10.1/30 | |
| eth5 | 10.10.6.2/30 | |
| eth6 | 10.10.8.2/30 |
In this exercise, you will provision the example.com Production Services network that corresponds to the consolidation phase.
Outcomes
You should be able to:
Create a vars file defining the variables that will be used.
Compose a playbook with a play that satisfies the business requirements as stated by Jasper.
Perform the play in the playbook to enact the desired changes.
Verify that the outcome is as intended.
Open a terminal window on the workstation VM and change to the ~/proj/ directory.
Create a vars file defining the variables that will be used.
Download the consolidation-data.yml file into the vars/ directory.
This file maps layer 3 address data to interfaces and also provides interface descriptions.
[student@workstation proj]$cd vars[student@workstation vars]$wget \>http://materials.example.com/full/vars/consolidation-data.yml[student@workstation vars]$cd ..[student@workstation proj]$
Compose a playbook with a play that satisfies the business requirements as stated by Jasper.
Create a playbook named consolidation.yml as shown here.
Notice how much simpler this playbook is than the one that was used for the expansion phase.
That is intentional.
The difference between the two playbooks illustrates how effective with_dict can be.
---
- name: consolidate the layer 3 network
hosts: network
vars_files:
- vars/consolidation-data.yml
tasks:
- name: configure interface descriptions
vyos_interface:
name: "{{ item.key }}"
description: "{{ item.value.description }}"
with_dict: "{{ interface_data[inventory_hostname] }}"
when: ansible_network_os == 'vyos'
- name: configure layer 3
vyos_l3_interface:
aggregate: "{{ layer3_data[inventory_hostname] }}"
when: ansible_network_os == 'vyos'
- name: configure interface descriptions
ios_interface:
name: "{{ item.key }}"
description: "{{ item.value.description }}"
with_dict: "{{ interface_data[inventory_hostname] }}"
when: ansible_network_os == 'ios'
- name: configure layer 3
ios_l3_interface:
aggregate: "{{ layer3_data[inventory_hostname] }}"
when: ansible_network_os == 'ios'Perform the play in the playbook to enact the desired changes.
[student@workstation proj]$ansible-playbook consolidation.yml
Execute ad hoc commands and verify that layer 3 addresses and interface descriptions are mapped to interfaces as described in the tables found at the start of this exercise. Here the syntax of the command is shown for use with the VyOS devices:
[student@workstation proj]$ansible -m vyos_command -a "commands='sh int'" vyos
The following ad hoc command can be used to verify that layer 3 addresses are listed correctly for the IOS networking device cs01.
The following command should be entered as a single line.
[student@workstation proj]$ansible -m ios_command -a "commands='sh ip int br'" cs01
This concludes the guided exercise.