In this scenario, example.com is in a break-up phase.
You are now part of a team headed by Jasper that has been spun off into a different company, named Ideal Networking Incorporated, that manages networks for many different businesses.
What used to be the Production Services Network of example.com is now three different networks, owned by three different companies.
The three companies that used to be example.com are Ideal Services Incorporated (ISI), Ideal Products Incorporated (IPI), and Ideal Technologies Incorporated (ITI).
They still work closely together with each other.
Ideal Networking Incorporated manages all three networks.
The Production Services Network of example.com, during this phase, will consist of three different networks associated with three different Autonomous Systems (AS):
ITI - AS17216
Network devices
cs01 (cloud)
Servers
server03
ISI - AS10101
Network devices
spine01
leaf01
Servers
server01
IPI - AS19216
Network devices
spine02
leaf02
Servers
server02
In this guided exercise, you will change the layer 3 addresses and interface descriptions according to values found in the Break Up Phase Layer 3 Addressing and Break Up Phase Interface Descriptions tables.
During a brief interim period, routing information among the networks of the three new companies will be shared by way of the OSPF routing protocol as a single zone: a single routing domain.
In the next guided exercise, though, you will separate the three networks into distinct autonomous systems that share routing information explicitly by way of EBGP; three different routing domains that explicitly share routes in accordance with peering agreements.
These are the immediate business requirements:
Apply interface descriptions to interfaces as documented in the table.
Configure layer 3 on interfaces as documented in the table.
Configure dynamic routing with OSPF using a single zone.
The decision to use a single zone instead of multiple OSPF zones was made because management knows that the network is to be divided, in the next guided exercise, into three different autonomous systems that do not use OSPF to advertise routes between each other. After that change is complete, there will be three small networks, each consisting of a single zone.
The process of separating the old, consolidated example.com network into three independent networks involves a significant amount of change, including many deletions.
Nothing is being removed on the IOS device, but many changes need to happen on the VyOS devices.
Given the extraordinary nature of this change, management has given approval for the VyOS devices to be reinitialized with respect to the non-management interfaces. This makes your job easier, because (1) you already have a playbook that can do this, and (2) you can build a new playbook that provisions the three networks without the additional complexity associated with surgical removal of legacy resources.
Management also has given approval to perform the change in two phases. The outcome of the first phase is expected to be end-to-end reachability with routes by way of dynamic routing using OSPF. During the first phase, it is acceptable for routes to be advertised by way of OSF across the boundaries of the three networks.
The second part of the Break Up scenario is described in the next guided exercise.
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.3. Break Up Phase Interface Descriptions
| Devices | Interfaces | Descriptions |
|---|---|---|
cs01
|
GigabitEthernet1
|
management
|
GigabitEthernet2
|
outside-as10101
| |
GigabitEthernet3
|
outside-as19216
| |
GigabitEthernet4
|
inside
| |
spine01
|
eth0
|
management
|
eth1
|
leaf01
| |
eth5
|
outside-as17216
| |
spine02
|
eth0
|
management
|
eth2
|
leaf02
| |
eth5
|
outside-as17216
| |
leaf01
|
eth0
|
management
|
eth1
|
server01
| |
eth5
|
uplink
| |
leaf02
|
eth0
|
management
|
eth2
|
server02
| |
eth6
|
uplink
|
Table 6.4. Break Up Phase Layer 3 Addressing (management interfaces not shown)
| Devices | Interfaces | Descriptions |
|---|---|---|
cs01
|
Loopback1
|
172.16.0.1/32
|
GigabitEthernet2
|
172.16.2.2/30
| |
GigabitEthernet3
|
172.16.5.2/30
| |
GigabitEthernet4
|
172.16.10.1/30
| |
spine01
|
lo
|
10.0.0.1/32
|
eth1
|
10.10.5.1/30
| |
eth5
|
172.16.2.1/30
| |
spine02
|
lo
|
192.168.0.1/32
|
eth2
|
192.168.5.1/30
| |
eth5
|
172.16.5.1/30
| |
leaf01
|
lo
|
10.0.0.11/32
|
eth1
|
10.10.10.1/30
| |
eth5
|
172.16.5.1/30
| |
leaf02
|
lo
|
192.168.0.2/32
|
eth2
|
192.168.10.1/30
| |
eth6
|
192.168.5.2/30
|
In this exercise, you will provision the example.com Production Services network that corresponds to the break up phase.
Outcomes
You should be able to:
Reinitialize non-management resources on the VyOS devices.
Create a variables file that defines the variables that are needed.
Perform a play that implements layer 3 address and interface description changes.
Perform a play that implements OSPF configuration changes.
Verify that the outcome is as desired.
Open a terminal window on the workstation VM and change to the ~/proj/ directory.
Reinitialize non-management resources on the VyOS devices.
If you did not create a playbook named vyos-reinitialize-l3.yml in a previous guided exercise, download it from http://materials.example.com/playbooks/.
[student@workstation proj]$ansible-playbook vyos-reinitialize-l3.yml
Create a variables file that defines the variables that are needed.
Download the breakup-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/breakup-data.yml[student@workstation vars]$cd ..[student@workstation proj]$
Perform a play that implements layer 3 address and interface description changes.
Write a play that implements layer 3 address and interface description changes.
Create a file named breakup.yml with the following content:
---
- name: break up the layer 3 network
hosts: network
vars_files:
- vars/breakup-data.yml
tasks:
- name: remove the legacy layer3 data
vyos_l3_interface:
aggregate: "{{ remove_layer3_data[inventory_hostname] }}"
state: absent
when: ansible_network_os == 'vyos'
- 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 found in the breakup.yml playbook.
This provisions the networks at layer 3.
[student@workstation proj]$ansible-playbook breakup.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.
[student@workstation proj]$ansible -m ios_command \>-a "commands='sh ip int br'" cs01
Perform a play that implements OSPF configuration changes.
Copy the existing ospf-consolidation.yml file and modify it to create a new ospf-breakup.yml playbook.
[student@workstation proj]$cp ospf-consolidation.yml ospf-breakup.yml
The only change is to use the breakupdata.yml variables file.
After editing, the ospf-breakup.yml file should contain the following:
---
- name: play that configures OSPF according to data and templates
hosts: network
vars:
vyos_ospf_template: j2/vyos-ospf.j2
ios_ospf_template: j2/ios-ospf.j2
vars_files:
- vars/breakup-data.yml
tasks:
- name: configure ospf on vyos
vyos_config:
src: "{{ vyos_ospf_template }}"
save: True
when: ansible_network_os == 'vyos'
- name: configure ospf on ios
ios_config:
src: "{{ ios_ospf_template }}"
save_when: changed
when: ansible_network_os == 'ios'
Perform the play in the ospf-breakup.yml playbook.
[student@workstation proj]$ansible-playbook ospf-breakup.yml
Execute ad hoc commands to confirm that the desired routes are present.
[student@workstation proj]$ansible -m vyos_command \>-a "commands='sh ip ro'" vyos[student@workstation proj]$ansible -m ios_command -a "commands='sh ip ro'" ios
Verify that the outcome is as desired.
Perform the end-to-end reachability test using the e2e.yml playbook.
[student@workstation proj]$ansible-playbook e2e.yml
This concludes the guided exercise.