Cisco CCIE Security 350-701 – PUPPET – Config MGMT Tool

1. PUPPET – Config MGMT Tool

Okay, fine. So now in this section, we’ll try to understand about some basic overview of the Puppet config management tool. And also we’ll try to see some of the terminology concepts inside the Puppet. So let’s see overview of the Puppet. So Puppet is a confirmation management and automation tool and we can say it is one of the commonly used tool for automation of your servers or automation of your, your networking devices. So again, basically, with the help of this tool, we can do the same things what we discussed, like we can do the initial deployment of your devices, we can make some changes to your configurations, we call it as a configuration management.

And also we can install or remove specific devices from the network. And also it will allow you to manage multiple devices at the same time. Now again, when you talk about Puppet, puppet Cisco supports the use of the Puppet software in variety of devices. Like if you go with some of the Cisco catalyst switches or Nexus switches or even if you’re using some Cisco UCS server platforms, they do have a support for this Puppet software. And of course, the Puppet is going to work with many other different vendors as well. And it is a commonly used tool especially for server and network automation options. So like server virtualization where you can add or remove the virtual machines or even it can include also it can also be used for network automation as well.

Again, one more thing we need to know. Puppet uses the pool model. Now in the previous topics we have discussed the pull model, the pull model, the devices or the nodes do have an agent software installed in their own devices and they’re going to initiate the connection to the server or initiate the request. There is a timer and based on that timer they will be sending out the request. And this particular or the server where the Puppet server is actually installed, it’s going to provide the configuration files and those configuration files will be pushed later on after the request to the end devices. So all the agent based normally the agent based software requires this mechanism. But of course the Puppet uses the pullmodel.

2. PUPPET-Master Agent Database

The next thing we’ll try to understand some of the concepts or the terminologies used inside the Puppet. Now probably most of the concepts we have already discussed just the naming wise there will be slight different names we refer here. The first one is your puppet master. Now Puppet Master is actually a device from where you do all the management. Or we can say the software. If you remember the Master concept, the master within the agent concepts the same thing here we call it as a Puppet Master puppet Agent. Okay? So once we decide to use the Puppet, the first thing what we are going to do is we are going to install the Puppet software probably on any one of the servers we’ll install. Maybe Linux or Linux host or it can be a Linux host as well. And that particular server is referred as a Puppet Master. Okay? Now again, this software, as I said, this software can be an open source. There are a couple of variations. If you visit the Puppet website you’ll find some details.

Now there is an option of free open source version or you can also use some kind of paid version is also available. So you can visit the website as I said for more details. Now, what is the job of this Puppet Master? The same thing. The Master is going to push the configuration or the config files to the nodes or to the agents to the end devices. Now again we have something called Puppet Agent. Nothing but the node. Now these are the actual end devices. Maybe routers or switches or maybe some firewalls or even it can be your server if there is some kind of server virtualization probably these devices do have an agent software installed.

So typically the agent software is installed on them and these agents are being managed by the server. Again, the server is responsible for sending out the configurations and of course the end devices we call them as Puppet Agents. As I said, the Puppet agents are nothing. But they do have some kind of agent software installed that need to be installed on their end. And these are actually managed by the Master. Again and also we have something called Puppet Database. The database is nothing but like storage. You store the tasks, the actual tasks which are supposed to be executed.

We can say like changes or the automation tasks, whatever you want to execute on these end devices. So that has to be stored in some place. And we call that particular thing called as Popped Database. Okay, so now these changes, or we can say these are like the changes or whatever the automation tasks and again these changes, whatever you want to make either you can store them locally on the same server or even you can have a separate box where you can actually do all the storage of your Automationrelated task.

3. PUPPET – Manifest

Next thing we’ll try to understand here there is something called Puppet Manifest. The Puppet manifest are nothing but the configuration files. If you remember in the previous concepts we have discussed about the configuration files and these configuration files are nothing but whatever the configurations you want to apply to this end nodes probably we are going to group those set of commands within help of some kind of scripting languages. And these configuration files will be pushed onto the nodes so that the configurations can be applied on the nodes from the master device. So this particular master is going to have those configuration files or define those configuration files and then being pushed or pull method, whatever the method software is using here. Basically Popped uses the pull model so it sends out the configuration files to the end devices.

Now this configurations can be anything depending upon what is the actual node. And let’s say if I have these end nodes or Cisco devices we can compare the configurations like maybe any kind of drafting configurations or maybe some ACL or Iprocing or Nat or whatever adding the VLANs it can be anything. Probably each and every option. Probably we call them as resources here. So it’s a collection of all these configurations in the confirmation files and technically we call them as manifest. Puppet manifest is a technical term used to define the configuration files. So it’s the same thing equivalent to configuration files concept what we have covered in the basic concepts previously. And again this Puppet manifest or the configuration files inside the Puppet software will be written in Ruby programming language. That is a kind of programming language used by the Puppet.

Okay, so Ruby it uses and mostly all these confliction files will have an extension of PP. That’s an extension. That’s how you can identify in the Puppet software the confession files and they use the same Puppet coding style. It’s a kind of Puppet dedicated coding style inside the Ruby. That’s what we call as domain specific language. Because even though different vendors uses the same Ruby language but they have their own software defined specific defined format language that’s what domain specific language we call it as. Now if you try to see some of the examples here, like this is one configuration for example used inside the Puppet.

Now this is relevant to NTP configurations network time protocol where you can have a common synchronized time. And here you can see there is a server with an IP address of 1234. That’s an IP address of the server. And I want these devices probably they should contact the server and synchronize the time. So there is a concept called NTP if you have seen in the other networking concepts. And then there is a timer specific timer periodical timer set and from which interface that particular what will be the source interface from where the NTP request has to be sent between the nodes and the server. So this is the sample configuration file inside the Cisco iOS.

And if you take one more example here, there is one more example which is again another configuration file which is going to display the message or banner message like we configure banner messages on the Cisco devices. That is something relevant to this. Likewise, if you take another example with Puppet software. Now, this is a specific OSPF configuration where we are creating an OSPF protocol in the first step here and then in the second step with specific to VRF, we are going to assign the cost, probably the cost values. We are going to assign 34 cost values. And again here you can see this example. Again you will see the interface status should be up. So that’s interface status and I want that particular interface to be in the area 200 and the cost should be 200. So it is a little bit readable format and this is how the coding style will go.

4. PUPPET-Module-Forge

The next thing we’ll try to understand one more concept. In the puppet. There is something called puppet model. Now, Puppet Model is a collection of files and the directories, probably those are referred as Puppet Model. The collection of files and directory means your confirmation files. So if you remember in the previous topic we have seen there is something called config files where you are going going to define a set of commands which are being pushed to the nodes. And again we have something called class definitions which are again defined inside the configuration files or inside the manifest. Now, what exactly models? Now, if you take a simple example like normally this is your Puppet Master and this Puppet Master is going to manage or configure multiple nodes means it is going to control multiple nodes or agents, let’s say, because they do have an agent software.

You can say nodes or agents and these agents can be different vendors. Like it can be a Cisco specific vendors or you may also have some devices which are non Cisco. As well as even the Puppet is also used for managing your virtual machines inside the server. Now, the server has to be installed now this server has to be installed with some kind of information about what is the provider or we can say what is the vendor. And in that vendor, let’s say here we are saying Cisco specific in that vendor, what is a type? Again, in that you have many security devices and you have routing switching devices, routing device, switching device. Or you can say it can be a firewall, what type of device it is or we can say what type of vendor it is. And again, if you take an example of it’s, a router. Again, what is the operating system?

Because within the Cisco you have Cisco operating system normal iOS and you have iOS XE and you have XR you have Nxos used in Nexus. This is in ASR routers and in other routers you’ll find this iOS. So the command line and the configuration hierarchy will be different for each and every and every platform. So basically each set of configurations. Let’s say here I’m using a router and the vendor is Cisco and that is your router. And then the router is an iOS running iOS XE operating system. This is whatever the configuration files relevant to this can be defined as a specific model. This is going to give a skill that the Puppet can understand and talk to the nodes, whether it is what type of device it is, whether it is a router or switch or what vendor it is and what is the operating system it is running. So these are like collectively referred as something called module.

Again, the Puppet have many modules available for different vendors and the different types of devices. Like I said, one example here, the Cisco model which is specific to Cisco operating system in that again, you may have some kind of subcategories and then just like SQL, have its own separate model for configuring the SQL devices. These are some of the examples here. And these modules can be reused and shared between the multiple users. Probably we can say that way. And there will be some kind of predefined if you go to the puppet website, on the puppet website you will find a specific community. If I just go here, you can see these are the URLs I already opened here. Now here you will find some predefined puppets. Like normally there are some users who create their own files or the manager or the config files or the modules will be uploaded here.

If I just search with specific Cisco here, I can find this is like a Cisco puppet which is for configuring the Nxoise devices. And if I click on open it here, I have that in the next tab here and you can find some information over there. So this specific model description, if you click on this, you’ll find the description of the module. This is specifically to allow the network engineers to manage the Nxos that is running on Cisco Nexus platforms by using a puppet. And of course you see the configurations, what are the specific commands or use or scripts used. And these are kind of sample examples.

Probably you see here the people are going to upload their own manifest or the code shade here. This is one example and the second one again, there’s one more example on Cisco iOS. I think this is specific to managing your Cisco Catalyst switches or Cisco Catalyst devices running with iOS and iOS XE. And you can see the description here. This is going to allow you to configure those devices, like how the configuration goes. And I think it is more specific to creating SSH and telenet sessions to do this device. So probably what we can do is we can use this kind of models, we can edit them in our network and we can modify according to our requirements.

5. PUPPET-Agent- Agentless

Okay, the next thing we’ll try to understand the difference between the Puppet agent as well as agent list. Because in the previous sections we have seen the Puppet requires an agent software or the agent code has to be installed on the nodes. So all the nodes must be supporting the agent software. And based on this agent software, it is going to communicate with the master. And this is like the compulsory requirement when you are going with agent based Puppet in general. So as you can see here, Puppet typically uses this agent based architecture to support or to talk to the devices.

So all the devices need to have the agent software installed in that. And with the help of this agent software, as I said, it is going to communicate with the server and it gets the required configurations from the server here. But now the question is, what if there are some of the devices which do not support the agent software?

Like, let’s say I do have some of the Cisco devices and these Cisco devices, there is no agent support on this or maybe any other vendor. But now the question is, without any agent you are not able to communicate with a master because typically you need to have an agent’s software must be the Puppet in order to communicate between the agent as well as the master. Now, in this kind of scenarios, we need some kind of middlemen like the external agent. We can use something called external agent software or proxy kind of thing, where this external agent is going to help us in communicating between the nodes. Now with the help of this external agent, we are ensuring that we can communicate between the non agent as well as with the server.

Okay? So that’s what the Puppet is going to solve. So Puppet is going to support some kind of external agent option. So what you can do is you can have an external agent and you can still use some kind of SSH even there is something called Windows Remote Management. These features which are natively supported on these devices.

And this section agent is going to initiate those sessions which are natively supported here. And then this actual agent will again talk back to the server. Now this is kind of alternative option because when you go with a Puppet based automation tools, you need to decide whether you want to go with the agent based or agent list. It totally depends upon your network design or the network support. So if you have plenty of devices which they don’t support the native agent module or native agent code.

6. PUPPET-PULL Model Steps

In this topic probably will see the steps inside the Puppet pull model. First, let me quickly review the basic differences between the pull model and the push model. Now we have seen that in the previous topics. In the pull model what happens is the device will have an agent and this agent is going to request the Puppet master and the server server or the master is going to send out the configuration information. So which is something used in the case of Puppet. So Puppet uses pull model where the agent is going to send out a request for the configurations.

Of course a pull push model is something like used in some other software like ansible where the server is going to push the configurations initially. So the Puppet is going to use the pull model to make it configuration appear on the device. And this process goes in four steps. So I’ll just quickly give an overview of these four steps. Now the first step is it is going to build the configuration files. Now the engineer, probably the engineer is going to server and is going to create something called configuration files. Configuration files. Technically we call it as a manifest here.

So that has to be created. And if you already have some kind of confirmation files where you need to make some changes, probably you can go and create or you can just go and edit those confirmation files on the server or the Puppet master. So that is like the first step. And the second step is the agent. Now that agent have agent software installed, the end nodes. Now the engineer has to configure and enable the agent on this particular device. Option means this agent must be enabled or whatever the configurations or specific configurations you need to do. Probably you have to do it over there. So this is like first step and this is like second step. Just like, you know, you need to enable the agent. Agent has to be enabled in order to initiate the request.

Because in the pull model as I said, the agent is going to initiate the request and that agent has to be configured or enabled with that option on each and every device. Now the third step is the agent is going to pull the manifest files. So in the third step the agent is going to send out a request to the master because in the pull model the agent is going to initiate the request. So agent is going to contact the server and then it’s going to ask for the details of the configuration files.

So server is going to update the confirmation files. So probably the next thing is the server is going to send out a reply saying that okay, these are the confirmation files you need to apply and this is how the confirmation should look and this is what you need to apply. And finally this is how it should look. Probably after that, there will be something like the the last step. Now, agent is going to pull the conflicts additional configurations, if required, from the server.

So if the agent need to be updated, more updates because the configuration files is not exactly, let’s say whatever the configurations need to be present. And to make that possible, it needs some more detailed information or some more options. So probably it is going to do some additional pools or additional requests to the server to get all the configurations in detail and update the device configuration. So this is how at the back end it works. So it uses pool model. And this pool model goes in four different steps. Beta.

• Category: Uncategorized