OSPF Point-to-Point

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:

   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:

     ip ospf network point-to-point
     

   • Port-channel 1 on the distribution switch that connects to specific port-channel on the core:

     ip ospf network point-to-point
     

3. Capture new state:

   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.

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