Bookmark this page

Guided Exercise: Provisioning the Break Up Network

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):

  1. ITI - AS17216

    1. Network devices

      1. cs01 (cloud)

    2. Servers

      1. server03

  2. ISI - AS10101

    1. Network devices

      1. spine01

      2. leaf01

    2. Servers

      1. server01

  3. IPI - AS19216

    1. Network devices

      1. spine02

      2. leaf02

    2. Servers

      1. 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:

  1. Apply interface descriptions to interfaces as documented in the table.

  2. Configure layer 3 on interfaces as documented in the table.

  3. 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.

Figure 6.4: The Consolidation Phase Production Services Network of example.com

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.

  1. 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
  2. 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]$
  3. Perform a play that implements layer 3 address and interface description changes.

    1. 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'
    2. Perform the play found in the breakup.yml playbook. This provisions the networks at layer 3.

      [student@workstation proj]$ ansible-playbook breakup.yml
    3. 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
  4. Perform a play that implements OSPF configuration changes.

    1. 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'
    2. Perform the play in the ospf-breakup.yml playbook.

      [student@workstation proj]$ ansible-playbook ospf-breakup.yml
    3. 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
  5. 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.

Revision: do457-2.5-4693601