Gain insights into automating network reconnaissance, orchestrating repetitive changes, and transforming network configuration management. Discover CI/CD pipeline migration for full network automation.

ansibleFinal1.tar.gz

gitjob

CIPhosts

CIPhosts-copy

gather_info

gather_important_facts

facts_to_md

facts_to_csv_html

tools

frr01

frr02

first_gather_important_facts

​​Network automation begins with automating network reconnaissance. This is accomplished by gathering important information from network devices while building a library of dynamic on-demand utilities and generating living documentation. Starting small, the course exhibits the simplicity and elegance of network automation.

Next, you will learn how to automate larger changes that require a high number of repetitive steps. These changes will be executed serially in a specific orchestrated order, making them perfect for an automated solution. After gaining comfort with the new tools, you can fully transform network configuration management to an automated, intent-based, self-documenting system.

The final step is learning how to migrate to a continuous integration/continuous delivery (CI/CD) pipeline, thereby fully automating the network.

Automate Your Network

# OSPF point-to-point 
This next example includes a change that is disruptive to the network, while downtime is unavoidable.
Should the operator make an error on either end or perform the change in the wrong order, they can leave the network offline until somebody visits the remote device with a console cable and restores
connectivity. This is avoided with automation.

The example involves interface configurations for OSPF. There are two building distribution switches
connected to the core through layer 3 port-channels. Each side of the link is logically a single interface, so
this should be connected as an OSPF point-to-point connection. This is not the default configuration for
layer 3 port-channels, and must be configured explicitly on the interface. The default is a broadcast type
for OSPF. While broadcast will still work and connectivity will be established, there are some worthwhile
advantages to following best practices. 

If running OSPF on point-to-point connections, configure the
OSPF point-to-point type under those layer 3 interfaces. The OSPF hello interval, as well as the dead detection interval, is much higher using P2P. Adjacency time is only 2 seconds (fast) versus over 40
seconds (very slow) with P2P versus broadcast. There is one less Link State Advertisement (LSA) per 30
seconds, with P2P (2) versus broadcast (3) making this an extremely important setting, especially as the
network scales.

After building the network, we will discover the “bug” or “flaw” where the default I used, and the network uses OSPF type broadcast instead of type P2P on all building uplinks. 

It may be quick and safe enough to perform changes manually over two sites— but that misses the
point of network automation. Even with only two sites to change,there is still a requirement of the manual configuration
of three devices, the core and all distribution layer devices. The correct order of operation, along with the
commands on the correct interfaces, must be followed during the implementation. At scale, the risk is
compounded per site. This change is fully documented and included in the master branch history of
reference for what the state of the network was pre- and post-change. 

The approach is as follows:

1. Capture current state:
    ```bash
    show ip ospf neighbors
    ```

2. Change OSPF type to P2P on all links between the core and distribution layers:
    - The port-channel on the core that connects to a specific distribution switch:
         ```bash
         ip ospf network point-to-point
         ```
    - Port-channel 1 on the distribution switch that connects to specific port-channel on the core:
         ```bash
         ip ospf network point-to-point
         ```
3. Capture new state:
    ```bash    
    show ip ospf neighbors
    ```

The OSPF neighbors' playbook is already written and can be reused. This can be considered as part of this
playbook, to gather OSPF neighbors before and after the change to compare and validate.

Follow the NDLC, which by now should be second nature. Make a new working branch. Refresh the local repository and change to the working branch. Update `hosts` to have a new group of devices for this playbook. This group can be removed from `hosts` after the play has been completed. 

```text
[OSPFP2P:children]
CORE
LAB-DISTRIBUTION 
```
Create a new YAML file in the tactical playbook folder called `point_to_point.yml`. The playbook
needs to configure `Port-channel1` of the distribution switches and the matching core port-channel interface to be OSPF type point-to-point. The networks will take two
seconds each to converge. 

Write a new playbook to capture pre and post-OSPF neighbor's state. This is slightly different from the
existing playbook `ios_command_show_ospf_neighbors.yml` that executes the show `ip ospf neighbor` command and dumps the output to a file.

Now prompt for a filename “PRE-CHANGE” for the output for the `show ip ospf neighbor` command. Execute the changes, and then prompt for another filename “POST-CHANGE”. Recapture the `show ip ospf neighbor` command. 

We can use YAML files similar to the ones provided below:


Let's take a look at some examples involving changes to OSPF configurations.

Introduction

What Is Network Automation?

Why Automate the Network?

How to Automate the Network

Where to Start with Network Automation

Repository Structure

Network Reconnaissance

Tactical Playbooks

Data Models and Dynamic Templates

Dynamic Intent-Based Documentation

Configuration Management

Continuous Integration/Continuous Delivery

Conclusion

OSPF Point-to-Point

OSPF point-to-point