Example.com is moving into a new office building.
This is their first brick-and-mortar location.
They have a new server.
A VyOS router named spine01 is online and connected to the management network, as well as an intermediate device named leaf01, which is also running VyOS.
They decided to use static routes for now: static routes are simple and reliable, and in this stage of their development, example.com is young enough and small enough that Jasper has not decided to make scalability a priority.
During this phase, the Production Services Network of example.com consists of cs01 and server03 in the cloud, plus now two network devices at the new office: spine01 and leaf01.
There is also a server at the office: server01.
Counting the cloud and the office, there are now three network devices that will be active at layer 3 and two servers.
Jasper is asking for the following:
Make these changes on spine01:
Label interface eth0 with the description management.
Label interface eth5 with the description outside.
Label interface eth1 with the description internal.
Configure layer 3 on interfaces eth1 and eth5 according to the table.
Do not change anything with respect to layer 3 on the management interface.
Make sure OSPF is not enabled.
The default gateway should point to the next hop address associated with the outside interface.
Add a static route for the server subnet that points to the next hop associated with the internal interface.
Make these changes on leaf01:
Label interface eth0 with the description management.
Label interface eth5 with the description uplink.
Label interface eth1 with the description server01.
Configure layer 3 on the uplink and server01 interfaces.
Do not change anything with respect to layer 3 on the management interface.
Make sure OSPF is not enabled.
The default gateway should point to the next hop address associated with the uplink interface.
Make these changes on cs01:
Label interface GigabitEthernet1 with the description management.
Label interface GigabitEthernet2 with the description outside.
Configure layer 3 on interface GigabitEthernet2 according to the table.
The default route should point to the next hop address associated with the outside interface.
You will access spine01 and leaf01 by way of their eth0 interfaces, and access cs01 by way of its GigabitEthernet1 interface.
These interfaces are already configured with respect to layer 3 and up.
Table 5.3. Expansion Phase Interface Descriptions
| Devices | Interfaces | Descriptions |
|---|---|---|
| cs01 | GigabitEthernet1 | management |
| cs01 | GigabitEthernet2 | outside |
| cs01 | GigabitEthernet4 | inside |
| spine01 | eth0 | management |
| spine01 | eth1 | inside |
| spine01 | eth5 | outside |
| leaf01 | eth0 | management |
| leaf01 | eth1 | server01 |
| leaf01 | eth5 | uplink |
Table 5.4. Expansion Phase Layer 3 Addressing (management interface not shown)
| Devices | Interfaces | Descriptions |
|---|---|---|
| cs01 | Loopback1 | 172.16.0.1/32 |
| cs01 | GigabitEthernet2 | 172.16.2.2/30 |
| cs01 | GigabitEthernet4 | 172.16.10.1/30 |
| spine01 | lo | 10.0.0.1/32 |
| spine01 | eth1 | 10.10.5.1/30 |
| spine01 | eth5 | 172.16.2.1/30 |
| leaf01 | lo | 10.0.0.11/32 |
| leaf01 | eth1 | 10.10.10.1/30 |
| leaf01 | eth5 | 10.10.5.2/30 |
In this exercise, you will provision the example.com Production Services network that corresponds to the expansion 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 expansion-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/expansion-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 expansion.yml as shown below.
This could be developed as three separate playbooks and then combined, possibly by using include or import.
Alternatively, roles could be used.
This provides an example of a simple, straightforward method of explicitly encoding actions as tasks.
It works, and it is relatively easy to look at this playbook and understand what is being done.
There are, however, more efficient ways to accomplish what this playbook does.
The playbook used to provision the example.com network for the Consolidation phase accomplishes a similar set of objectives with one play.
Write a play containing tasks that configure cs01.
- name: configure cs01 for expansion
hosts: cs01
vars_files:
- vars/expansion-data.yml
tasks:
- name: label the management interface
ios_interface:
name: GigabitEthernet1
description: management
- name: label the outside interface
ios_interface:
name: GigabitEthernet2
description: outside
- name: configure layer3 interfaces
ios_l3_interface:
aggregate: "{{ layer3_data[inventory_hostname] }}"
- name: set default gateway
ios_static_route:
prefix: 0.0.0.0
mask: 0.0.0.0
next_hop: 172.16.2.1
- name: bring the outside interface up
ios_interface:
name: GigabitEthernet2
enabled: yes
Write a play containing tasks that configure spine01.
- name: configure spine01 for expansion
hosts: spine01
vars_files:
- vars/expansion-data.yml
tasks:
- name: make sure ospf is not enabled
vyos_config:
lines:
- delete protocols ospf
- name: label the management interface (eth0)
vyos_interface:
name: eth0
description: management
- name: label the outside interface (eth5)
vyos_interface:
name: eth5
description: outside
- name: label the inside interface (eth1)
vyos_interface:
name: eth1
description: inside
- name: configure layer 3
vyos_l3_interface:
aggregate: "{{ layer3_data[inventory_hostname] }}"
- name: set default gateway
vyos_static_route:
prefix: 0.0.0.0
mask: 0
next_hop: 172.16.2.2
- name: add static route for server subnet
vyos_static_route:
prefix: 10.10.10.0
mask: 30
next_hop: 10.10.5.2
Write a play containing tasks that configure leaf01.
- name: >
a play that configures leaf01
this is the expansion model
hosts: leaf01
vars_files:
- vars/expansion-data.yml
tasks:
- name: label the management interface (eth0)
vyos_interface:
name: eth0
description: management
- name: label the uplink interface (eth5)
vyos_interface:
name: eth5
description: uplink
- name: label the server interface (eth1)
vyos_interface:
name: eth1
description: server01
- name: configure layer3 interfaces
vyos_l3_interface:
aggregate: "{{ layer3_data[inventory_hostname] }}"
- name: set default gateway
vyos_static_route:
prefix: 0.0.0.0
mask: 0
next_hop: 10.10.5.1Perform the plays in the playbook to enact the desired changes.
[student@workstation proj]$ansible-playbook expansion.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.
The expansion scenario networking devices are spine01, leaf01, and cs01.
The following ad hoc command verifies the addresses and interface descriptions on spine01 and leaf01:
[student@workstation proj]$ansible -m vyos_command \>-a "commands='sh int'" spine01,leaf01
The following ad hoc command checks layer 3 addresses on cs01.
[student@workstation proj]$ansible -m ios_command \>-a "commands='sh ip int br'" cs01
This concludes the guided exercise.