Red Hat Ansible for Network Automation

After completing this section, you should be able to:

The hands-on activities in this course are written to tell the story of an organization with an evolving network, example.com.

The guided exercises and lab activities in the first part of the course are written as if the original network administrator for the organization has prepared training for you to learn how to use Ansible to manage the company's network. Later exercises are intended to represent how you could use Ansible to perform increasingly complex network administration tasks and to migrate that network to more sophisticated configurations.

The remainder of this section provides a detailed overview of the classroom environment that you will use to perform these hands-on activities, and of the story told in those activities.

Like most businesses, example.com has had good years, and less good ones.

Jasper expects that in the future, example.com might want to change the way the Production Services Network is provisioned at layer 3.

The separation of the network infrastructure into production services and management is an example of in-band/out-of-band design. Production network traffic happens in the bandwidth of the Production Services Network, and management traffic happens out of the bandwidth associated with it.

In one of his first actions at example.com, Jasper created a management network. You should assume the management network exists, and does not change.

At example.com, Marsha is in charge of servers.

At the present time, assume that servers can only be reached by way of the in-band network. In order for servers to be reachable, the Production Services Network (the lab network) must be working.

All student systems in the Management Network have a standard user account, student, which has the password student. The root password on all student systems is redhat.

The URL of the student's Git repository on the Management Network is http://git.lab.example.com:3000/student.

Here is the schematic representation of the relationship between the Production Services and Management Networks at example.com.

Figure 1.4: The Management Network topology

The topology of the Production Services Network connections are not shown in the previous diagram.

Jasper has been tasked by founders Joe and Denise to design, implement, and manage a production network that will grow with example.com.

He is familiar with the conventional three-tier network architecture: access layer, aggregation/distribution layer, and core. Lately, he has been reading accounts of the new leaf and spine architecture, and he is interested in exploring that at example.com.

During their consolidation phase, example.com will have an opportunity to implement a data center with four network devices. The data center part of the Consolidation scenario is an example of true spine and leaf architecture, in the sense that every low-tier device (leaf layer) is connected to each of the top-tier devices (spine layer) in a full-mesh topology.

Other internetwork scenarios for example.com model changes that reflect shifting business needs. The leaf and spine naming convention is retained for devices, but other than the Consolidation scenario, roles and interconnections do not necessarily provide a good example of spine and leaf architecture. The Break Up scenario, for instance, resembles a hub and spoke topology.

In real life, outside the example.com narrative, a particular set of layer 2 interconnections exist. This underlying apparatus makes it possible to implement various forms of the example.com Production Services Network at layer 3:

Figure 1.5: Production Services Network interconnections at layer 2

Interfaces labeled “oob mgmt” in the previous diagram are connected to the management network.

As example.com goes through different stages or phases of development, the Production Services Network is redesigned to keep pace with changing business requirements.

Start-up

The Start-up phase network of example.com.

This single-router network models a simple external, internal separation between public and private networks. During this phase both router and server were hosted in the cloud. The diagram illustrates that physical location is immaterial; the same diagram could apply to a residence.

Notice that the interface Gi1 on cs01 is playing the role of an in-band internet connection, even through in the classroom environment it is actually connection to the management network at layer 2. During the start-up phase, Jasper was accessing the example.com organization's sole router for management purposes by way of the internet. (For the sake of illustration, what is actually the real-life management network is considered to be playing the role of the example.com organization's internet.)

Figure 1.6: Start-up phase

Expansion

The Expansion phase network of example.com.

This models a scenario in which example.com has moved into an office. The spine01 router is at the office. The network device leaf01 is positioned where one expects a switch. It could be playing the role of a layer 3 switch, but with just the single server it fails to model fan-in/fan-out or port density.

The cs01 router is representing a device that is still hosted with a cloud service provider.

Pretend that the eth5 interface on spine01 and the Gi2 interface on cs01 are connections to the networks of ISPs, even though in the actual lab environment they are directly connected to each other.

Figure 1.7: Expansion phase

Consolidation

The Consolidation phase network of example.com.

In this scenario there are two locations: a data center and the original router and server hosted in the cloud.

The data center portion of this scenario is an example of true spine and leaf architecture, in the sense that every lower-tier device (leaf layer) is connected to each of the top-tier devices (spine layer) in a full-mesh topology.

Figure 1.8: Consolidation phase

Break-up

The Break-up phase network of example.com.

This models the transition away from a single organization, into three separate organizations. A fourth organization is providing managed services.

The three organizations have separate governance and separate networks. Each is considered an autonomous system, even though one service provider manages the networks for all three organizations.

Even though they are now three separate organizations with their own independent networks, they have entered into an agreement to share routing information, which is communicated across AS boundaries by eBGP peers.

For this scenario, pretend that the eth5 interface of spine02 and the Gi3 interface of cs01 are now connected through the networks of ISPs, even though in the actual lab environment they are directly connected to each other. (This is just like the relationship between eth5 on spine01 and Gi2 on cs01 in the scenario and in the actual lab environment.)

Figure 1.9: Break-up phase

Adjustment

The Adjustment phase network of example.com.

This model eliminates an inherent brittleness in the original Break-up scenario.

With the original Break-up phase internetwork, all traffic between AS10101 and AS19216 was routed through cs01. Not only did this add an extra hop, but cs01 is potentially a single point of failure. Provisioning a direct link between AS10101 and AS19216 improves stability and performance.

Figure 1.10: Adjustment phase

Jasper is ultimately responsible for managing networks at example.com.

At example.com, the power tools are Red Hat Ansible Engine and Red Hat Ansible Tower.

Jasper devised a series of lessons illustrating features and functionality of Red Hat Ansible Engine and Red Hat Ansible Tower.

That series of lessons is organized in four parts, or chapters:

Those who master these four challenges graduate to a fresh set of challenges that focus on networks and networking. Participants will help example.com shape and reshape its Production Services Network in response to changing business requirements.