How to become a CISSP (Certified Information System Security Professional) – Part One

 

This blog is to give a brief overview of benefits of CISSP and the best way to achieve the certification. I have been in the Network Security industry for more than 10 years. I started my career as a network field engineer and moved on to an analyst role then NOC, engineering, senior network security specialist to finally network security design/architect. I also acquired network certifications such as CCIE-SP and security based ccertifications based on Palo Alto and Juniper security devices. All certs were very vendor specific. Working as a network security designer/architect, I feel like I know much about network security but there are many aspects in any organisation where customer need a security layer with some of the domains which I was quite unfamiliar with.

CISSP, vendor-neutral cert, gave me an excellent exposure and a very good overview of IT (as a whole department where network security is a small part of it) posture of any organisation. It also covered many domains which were new to me like “Software Development Security”. In short, CISSP provides a necessary overall grasp of IT security.

ISC2 certifications are very different to any other traditional certifications. I would suggest you have a read through ISC2 certification pre-req before attempting to sit in for CISSP. In a quick glance, ISC2 need certain years of experience which need to be proved once you pass the exam in order to get certified.

Regardless if you want to get the certification or not, I would say read the contents of CISSP and you will realise how beneficial it is.

CISSP is designed to cover the following eight domains;

  • Security and Risk Management.
  • Asset Security.
  • Security Architecture and Engineering.
  • Communications and Network Security.
  • Identity and Access Management.
  • Security Assessment and Testing.
  • Security Operations.
  • Software Development Security.

From the above domains, I always thought I would be fine on communication and Network Security but CISSP covered this domain very differently. Yes I know that domain is the principle of Network Security, but I learnt a lot because CISSP’s perspective about this domain is on a totally different level.

My next blog will focus on how to get CISSP certification in 8 weeks (subject to the right experience) based on my own experience. I will also share resources (books, online resource, etc.) that I found very useful.

How to see advertised and received routes via BGP neighbours

bgp-advertised-and-received-routes

When you pass the show ip route command on a cisco router, you are presented with the routing table of the router. This table comprises of the best routes the router has chosen as the primary routes.

 

sh ip route
Codes: L -- local, C -- connected, S -- static, R -- RIP, M -- mobile, B -- BGP
D -- EIGRP, EX -- EIGRP external, O -- OSPF, IA -- OSPF inter area
N1 -- OSPF NSSA external type 1, N2 -- OSPF NSSA external type 2
E1 -- OSPF external type 1, E2 -- OSPF external type 2
i -- IS-IS, su -- IS-IS summary, L1 -- IS-IS level-1, L2 -- IS-IS level-2
ia -- IS-IS inter area, * -- candidate default, U -- per-user static route
o -- ODR, P -- periodic downloaded static route, H -- NHRP, l -- LISP
+ -- replicated route, % -- next hop override
Gateway of last resort not set
 
1.0.0.0/8 is variably subnetted, 2583 subnets, 14 masks
B 1.0.0.0/24 [20/7031] via 10.0.0.1, 2w0d
B 1.0.4.0/22 [20/137121] via 10.0.0.1, 2w1d
B 1.0.4.0/24 [20/137121] via 10.0.0.1, 2w1d
B 1.0.5.0/24 [20/137121] via 10.0.0.1, 2w1d
B 1.0.6.0/24 [20/137121] via 10.0.0.1, 2w1d
B 1.0.7.0/24 [20/137121] via 10.0.0.1, 2w1d
B 1.0.16.0/24 [200/0] via 10.0.0.1, 2w1d
B 1.0.64.0/18 [200/0] via 10.0.0.1, 2w1d
--More--

However, If you want to see the routes received by BGP neighbours only along with key attributes such as AS Path and local preference etc, you can view the BGP routing table by using the show ip bgp command.

 

sh ip bgp
BGP table version is 9501588, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
 
Network Next Hop Metric LocPrf Weight Path
*> 1.0.0.0/24 10.0.0.1 7031 4000 0 213964 13335 13335 i
*> 1.0.4.0/24 10.0.0.1 137121 4000 0 213964 4826 38803 56203 i
*> 1.0.4.0/22 10.0.0.1 137121 4000 0 213964 4826 38803 56203 i
*> 1.0.5.0/24 10.0.0.1 137121 4000 0 213964 4826 38803 56203 i
*> 1.0.6.0/24 10.0.0.1 137121 4000 0 213964 4826 38803 56203 i
*> 1.0.7.0/24 10.0.0.1 137121 4000 0 213964 4826 38803 56203 i
*>i1.0.16.0/24 10.0.0.2 0 4000 0 3356 2914 2519 i
*>i1.0.64.0/18 10.0.0.2 0 4000 0 3356 2516 7670 18144 i
--More--

Further to that, the show ip bgp summary command lists all BGP neighbours on the router.

 

sh ip bgp summary
BGP router identifier 10.10.10.1
BGP table version is 9501373, main routing table version 9501373
698513 network entries using 97791820 bytes of memory
1242345 path entries using 69571320 bytes of memory
295132/106926 BGP path/bestpath attribute entries using 37776896 bytes of memory
166524 BGP AS-PATH entries using 6137930 bytes of memory
72 BGP community entries using 1728 bytes of memory
149 BGP route-map cache entries using 5364 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 211285058 total bytes of memory
BGP activity 900150/201636 prefixes, 3945360/2703015 paths, scan interval 60 secs
 
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.20.20.1 4 65177 7783 8563 9501373 0 0 5d09h 0
10.30.30.1 4 65122 22040 237883 9501373 0 0 2w1d 0
10.40.40.1 4 65133 2740502 1522137 9501206 0 0 2w1d 693452

To view which BGP neighbour is advertising which prefixes to you, you can use the show ip bgp neighbor <neighbour ip address> advertised-routes command:

 

sh ip bgp neighbors 10.20.20.1 advertised-routes
BGP table version is 9505142, local router ID is 10.10.10.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
 
Network Next Hop Metric LocPrf Weight Path
*> 10.1.1.0/24 10.20.20.2 0 400 i
Total number of prefixes 1

To view what prefixes you are receiving from a given BGP neighbour, you can use the show ip bgp neighbor <neighbour ip address> received-routes command:

 

sh ip bgp neighbors 10.20.20.1 received-routes
BGP table version is 9505142, local router ID is 10.10.10.2
Status codes: s suppressed, d damped, h history, * valid, > best, i -- internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external, f RT-Filter
Origin codes: i -- IGP, e -- EGP, ? -- incomplete
 
Network Next Hop Metric LocPrf Weight Path
*> 10.2.2.0/24 10.20.20.1 0 400 i
Total number of prefixes 1

It’s important to remember that the show ip bgp neighbor <neighbor-ip> <advertised/received>-routes command only shows you the attributes of the route BEFORE it was manipulated by a route map (if configured). This command can cause a lot of confusion sometimes if not used with this in mind.

The output of the command shows the routes AS they were received and AS they were advertised before a route map was applied to manipulate BGP attributes.

How to deploy an office network like a Pro!

deploy-office-network-in-one-day-automate

I have deployed many offices over the past decade. Some were complicated, others relatively straight forward. The common constraint in most of my deployments has always been time.

Usually new offices are always opened due to pressing business needs. This means, the higher management want to see staff moved/new recruits placed in the new office ASAP. Often I have found myself deploying offices on single links.

Every time, I wanted to deploy an office, I had to replicate existing process with minimal time to upgrade the tech involved. I always wanted to improve the network deployment but I always found myself running against time.

Office deployments are usually painful because after doing them the first time, you will find yourself not learning anything new in each successful deployment. You will, however, find yourself wasting a lot of time doing the same thing all over again. This lost time could be better utilized to other things such as improving the production network etc.

This all changed when I joined a company that gave me some breathing room and allowed me to improve the processes in place. This was a multi-billion dollar enterprise that was growing fast. I was already designing their new MPLS network so I realised an automated office network delivery mechanism would sync in really well.

How I managed to achieve this?

Follow my guide below to replicate the same for your next deployment and reduce the required time for all your subsequent deployments.

Config automation via Ansible:

The first thing I did was to automate configuration management with the use of Ansible. If you haven’t used Ansible before, you haven’t lived!

I used to write lengthy scripts in Perl and Python that would simply spit out configuration and change variables where intended. Writing those long print statements and spending countless hours, little did I know that I could achieve the same with Ansible in a matter of minutes!

As they say, it’s never too late, I jumped the Ansible bandwagon and automated all configuration deployment for successive deployments in future.

This meant, the usual components of an office deployment were all templated. These components included the following:

  1. Firewall configuration
  2. Core switch configuration
  3. Access switch configuration
  4. Production firewall rule sets configuration

Usually any office deployment involves the deployment of a branch firewall, core switch, multiple access switches and the configuration of rule sets over the corporate/production network firewalls in the data centre.

I configured Jinja templates which are simple YAML files for Ansible to manipulate for all devices listed above. This meant for each successive office, I simply had to update the variable files and the configuration for all the devices would churn out in a matter of seconds!

Ansible can actually go ahead and configure these devices for you as well but for new offices, the kit is still in boxes hence, you have to manually configure the devices via console. For existing firewalls in corporate/production network, you can easily task ansible to go and configure with the new rulesets/address addition in existing address objects.

If you want to follow me in automating your next office deployment via Ansible too, why not! than here’s a guide I have written for you: Ansible: Use playbook to deploy your next office

Securing the network using 802.1x:

In simple terms, 802.1x makes your ports secure by making the user authenticate against the active directory before allocating a vlan. This means if you are not an authorised user, you won’t get a vlan assigned on the port you are connected to. Moreover, security is further enhanced through the use of policy groups on the Network Policy Server (NPS). This means vlans can be associated with groups on active directory. To further elaborate this, consider the following scenario:

You have a dev/sysadmin or a network engineer on port gi1/0/35 on the switch with vlan 50 configured manually. This vlan has privileges to access almost all the resources on the network including key PCI or PII resources. It’s all fine if the right person is connected on that port. However, in case of a desk move, a marketing user can find himself connected on port gi1/0/35 with PCI level privileges. This is a considerable security risk as the first line of defence which is lack of reachability has just been broken. Anyone can connect on port gi1/0/35 and use hacked credentials of a privileged user and access PCI data. This might sound remote but it has happened before and corporations shouldn’t take risks like these that can damage their reputation and adversely affect business on a large scale.

802.1x has been around for a while now but a lot of business have shyed away from it predominantly because of negligence in their security model and the fact that it’s just not been high enough in their priority list. This, on top of laziness on part of the network team is usually to blame as 802.1x deployments are usually tedious and require a lot of troubleshooting to get it right. Therefore, instead of pushing this crucial port security method, a lot of times network engineers find it easier to pre-configure vlans on ports!

What most businesses don’t take into account is the overhead of network resources utilised upon port changes etc in the form of excessive tickets in the ticket queue. With 802.1x, you take all that hassle away and never have to worry about port moves performed by the desktop engineering teams.

I have to admit, whilst 802.1x was easy to understand (you can read the RFC here), it was one of the most painful deployments I have carried out to date.

The purpose of this post is NOT to scare you away but to encourage you to deploy 802.1x in your office network too.

I have gone through the hard work so you don’t have to. Most of the painful moments came whilst testing and trying to get the protocol to work properly in a lab environment.

I would highly recommend you go through the guides below and implement this in your office today.

MAB: Mac Authentication Bypass on 802.1x
NPS settings for Mac Authentication Bypass (MAB) using 802.1x
Microsoft Network Policy Server (NPS) configuration for 802.1x authentication using PEAP
802.1x (dot1x) configuration guide for cisco switches (Including IP Phones)

The guides are pretty self explanatory but in a nutshell, you have two kinds of devices in offices over a wired network. Ones that support EAP and others that don’t.

EAP is the protocol that is used to authenticate a device. A port configured using 802.1x simply discards all packets apart from EAP packets. It then authenticates the device by contacting the NPS and then dynamically allocates the correct vlan on the port. Devices that fall under this category are all your laptops that are osx, windows or linux based. Other devices might support 802.1x too and it’s best to check by following up with the vendor’s documentation.

Devices that don’t support 802.1x can use MAB, i.e. Mac Authentication Bypass. What MAB does is pickup the registered mac address on the port and try and authenticate with the NPS using that mac address instead of a userid/password with radius. Generally, best practice is to prioritize MAB on your port so that the switch tries to authenticate using MAB first before reverting to EAP. This way all devices with registered mac address on the NPS easily get a vlan assigned to them.

One important thing is you might have to turn 802.1x ON on end devices so that they can take part in the EAP process. Normally, as soon as you plugin and end device that is osx, windows or linux based, the NIC simply sends a broadcast dhcp request to the network and waits for a DHCP offer from the DHCP server. This would mean when the switch port is configured with 802.1x, it would listen for EAP packets only and discard ALL other traffic. This means, the end device has to take part in the 802.1x process. In my experiece, Linux and Osx detect 802.1x packets themselves and inform the user to end userid and password to authenticate with a prompt. If they don’t it’s a simple option in the network settings. Windows however, is a different ball game!

With Windows, you will have to change Wired AutoConfig to automatic and ensure the service is always in START state.

This can be achieved by searching for services from the start bar and selecting Wired AutoConfig in the window that opens up as shown below:

 

Once the wired AutoConfig tab opens up, simply start the service and set it to automatic to ensure it always runs upon boot.

 

This would now ensure the windows machine now takes part in 802.1x process. That said, most organizations are 90% windows and 10% other devices. Therefore, it would be better to make this change in your whole estate via the use of a GPO policy. If you are not incharge of managing the windows estate, than usually this falls under the windows team in your business who can help you with this.

There is a lot more to it than just a few paragraphs but if you refer to the guides and examples referred above, you should be able to test and deploy a working solution with ease.

Last but not least, Wifi deployment is pretty straight forward. You just have to create a similar policy to wired in the NPS and make your APs request 802.1x authentication for each SSID you want to perform 802.1x authentication on. This is pretty straight forward and in my experience is the easiest part of the whole cycle to implement but you have to follow the documentation provided by the vendor of your wireless Access Points to achieve that. The NPS policies on the other hand, stay the same as defined in the above guide.

The end result:

After implementing it all, I was simply blown away when it all came together on day one of the office going live. Almost all users reported seamless connectivity. All devices such as printers, cctv camera etc simply had a dynamic vlan assigned. I being the network engineer would get high privileges on each port I connected on! This was a much smoother deployment than any office I have deployed so far with Ansible being the icing on the cake.

Upon the next office deployment, I will simply churn out the configuration files within minutes and with all 802.1x NPS policies already configured and in place, I now have the ability to configure and deploy an office in ONE DAY!

Imagine the time this has freed up for me and the rest of the team to perform other tasks!

Happy Networking 🙂

DNS: Domain Name System

rp_dns-domain-name-system
Imagine trying to remember 216.58.212.78 or 157.240.20.35 at all times. Difficult? Well half of your life would lose meaning if you don’t remember these IPs. Why? It’s one of the IPs to reach Google and Facebook!

So why aren’t we memorizing IPs at all times?

Because we have a blessing called DNS to our rescue.

DNS stands for Domain Name System and the simple task of a DNS server is to make IP addresses translatable via names. This way, when you try and reach google.com, the DNS server your request reaches to translates it into an IP address which your browser than uses to reach google’s servers. Border Gateway Protocol is the routing protocol of the internet and at that level, from a connectivity point of view, IP reigns supreme as every device in the path is designed to understand IP addresses to route traffic.

DNS lookup is the first function performed by your browser as it knows without a resolved IP address, the request is getting nowhere.
So which DNS server are you using?

If you are at home, most likely your wifi router has forced all clients connected to it to point to itself for all DNS queries. Your wifi router doesn’t have local records of any domain names as such but it knows which DNS servers to point to resolve your name queries.

Over the internet, domain name servers have a mesh of interconnectivity. This way when one DNS server doesn’t know about the IP related to a requested domain name, it simply points to another server until either the request is resolved or fails.

You can manually configure your DNS server on your home computer to point to 8.8.8.8 and all your requests would point directly to google’s DNS  instead of your ISP’s DNS.

Similarly, you can also use a protection service which is DNS based whereby your home router would point to the DNS service and apart from resolving your name requests, the DNS service would also protect you from malicious websites as it would block your requests to access unsecure addresses. This way you can protect your devices from harmful content. Cisco Umbrella is an example of a similar DNS based premium service.

The reason some websites open faster than others is primarily because they have cached content placed strategically near you so that there are minimal hops between you and the content you intend to reach. DNS plays an important part in this process. The DNS service ensures you get the IP address of your nearest cached server. It achieves this by looking at your source IP address and since your IP address also reveals your geographical location, the resolved IP would be of a server located near you.

Global domains such as Google, Facebook, Twitter etc are all present in multiple locations over multiple data centers and constantly provide their content from these locations. They home in this feature of DNS and spread their content delivery network across to deliver content from the nearest possible location. All this, whilst replication takes place at the back between all data centres.

To understand the concept of Content Delivery Networks (CDN) with spread out data centers, refer to my video below.

IP SLA: Configuration on Cisco Routers

ip sla-cisco-static-route
In the absence of a dynamic routing protocol, sometimes you will find your routers fail to re-route traffic when a link becomes unavailable. This is a typical problem faced by most small networks that have a router connected to a tier 3 ISP which doesn’t run a dynamic routing protocol. It’s all good if you have ensured you have multiple links to multiple ISPs ensuring redundancy is in place. But if you don’t have IP SLA configured, at some point you will be left frustrated like I was when one of the ISPs on my routers had an internal network outage.

A static route stays up until the interface goes down. That is, if the interface that is part of the same subnet as the next hop goes down, the router thinks the next hop is unavailable and therefore, marks the route down. Traffic should then simply re-route using the secondary default static route you have in place.

However, if the interface stays up but the ISP starts discarding your traffic internally, than you will simply be blackholing your own traffic! This means a network outage is on the cards.
So how can we insert some intelligence on the router itself so that it can mark a route down in a situation like this?

Cisco’s IP SLA is great feature to tackle this problem.

To configure IP SLA refer to the following configuration snippet.

Static route config:

 

The above configuration is pretty standard. It configures two static routes pointing towards two different next-hop addresses with a difference in the distance for both to ensure the route via 150.122.31.1 is always preferred.

In order to ensure our router is actively performing some sort of tracking  we have inserted the configuration command track 1.

What this would do is refer the router to look for IP SLA config and perform tracking based on that.

Refer to the IP SLA config snippet below.

IP SLA Config:

 

All the above configuration would do is keep sending ICMP requests to the next hop 8.8.8.8 every 5 seconds as defined by the frequency command.

It would wait for 2000 milliseconds to receive a response from the pinged destination.

Upon configuration of the command track 1 ip sla 1 reachability, IP SLA tracking would begin which would then record any lapses  in ping responses from 8.8.8.8. Upon a lapse, the primary static route would go down making way for the secondary route to become active.

However, the router would keep sending ICMP probes and as soon as it would receive a response, the primary static route would be re-added into the routing table. Based on our configuration, this would demote the active route with next-hop 121.221.33.9 as it’s administrative distance is configured higher at 250.

So there it is! Your guide to ensuring your routers with static configuration always have a valid path to the internet.

Sublime Text: Colour code network configuration

sublime-network-configuration-syntax-colour-code

I started off configuration using good old notepad and to be honest, it did the job so I never knew any better. Than I started scripting and started using notepad++ which really blew me as to how customizable it was.

Whenever I would be programming, I would enjoy the colour distinction inside code snippets. When I would come back to my network configuration, it would really bother me when I wasn’t able to distinguish things as well as I would like to. Reading through hundreds of lines of configuration on a traditional unicolour output can be pretty exhausting.

This is until I found Sublime text. Like notepad++, sublime text was geared towards programming but it had one cool feature that made it my number one configuration editing tool.

The ability to colour code configuration files based on vendor.

For example, look at the following juniper configuration snippet:

On a notepad, the above configuration snippet would look as dull as any network device configuration can get.

However, look below how it looks when pasted in sublime text:

I bet you can’t help but appreciate the turn around. This tool can be a life saver as you can spot errors in your configuration you previously might have missed.

However, sublime doesn’t come packed with this cool feature by default. You have to download the correct plugin to achieve networking nirvana!

Allow me to show you how this is done.

Sublime plugins:

Simply go to Tools > Command Palette.

 

Search for install Package and choose Package Control: Install Package. This would give you access to packages not available in the local library.

 

 

Go to Tools > Command Palette again.

 

 

Search for Junos and install the junos syntax package.

 

 

Select junos from the syntax in the bottom right and off you go!

 

 

You can also look for Cisco’s package but in my experience it isn’t as great as the junos package. However, it does highlight the no keyword really well which can help you avoid deleting configuration by mistake.

Ansible: Use Playbook to deploy the next office

ansible-how-to-create-playbook-network-devices-office-deployment
After deploying many offices manually, I started dreading the thought of another office deployment. Normally, you don’t learn anything new when deploying an office as the process is usually the same. Configure access and core switches and then set about configuring the firewalls everywhere in your production network to allow access to new users. That is, until I found Ansible. I was thrilled about Ansible when I first learned about it and since then I have used it numerous times to deploy offices seamlessly and with minimal hassle.

Not just new office deployments but you can use Ansible in conjunction with jinja templates for management of existing architecture along with any other task that requires configuration management over a range of devices. The key here is, the task must be repetitive, otherwise, you are just wasting your time.

Allow me to share a simple guide for you to automate your next office deployment below:

 

Install Ansible:

Simply parse yum install ansible and you should be able to download and install ansible on a linux host.

Playbooks:

Ansible employs the use of playbooks configured in the form of YAML files that initiate tasks based on templates and variables to churn out configuration files.

The basic format is as follows:

  • Playbook
    • Roles
      • Tasks
      • Templates
      • Variables

In my example, I have chosen to call my playbook office.yml. This playbook file calls in three roles which are firewall, core switch and access switch respectively. Each role has a task that constitutes pinning the variables in the variable folder against the template to churn out a config file. Roles are executed sequentially so in my case, the office.yml playbook, when executed, produces firewall config, core switch config and configuration files for multiple access switches.

Example office playbook output:

 

Config files folder:

Setting up Ansible:

A typical office deployment requires the configuration of firewall, core switch and multiple access switches. To generate configuration files for any office deployment, all you have to do is change the variables in the variable file for each type of device, i.e. firewall, core switch and access switches and then re-run the playbook. You can obviously re-adjust this based on your network deployment.

Below, I have shown snippets from my own office deployment playbook. You can simply use my example to understand and create your own playbook.

Process:

A view of the ansible directory:

Configs is the name of the directory where the churned out configuration files rest and office template is the directory that holds the office playbook and all roles, tasks, templates and variables.

A view of the playbook called office.yml:

The three “- – – ” imply that his is a yaml file. The roles sub category defines the roles this playbook calls. Each role is just the name of the folder holding tasks, templates and variables for that type of network device.

You can have multiple roles called in a single playbook. In my example, you can see I have three roles defined:

As explained before, each of the above roles is a folder in it’s own right and contains the tasks, templates and variable folders as shown below:

Task folder:

A quick look at the task file produces the following output:

All this above task file does is locate template titled 3850.j2 in the template folder and run it against the variable file stored in the variable folder with variable list titled core_switches. The task file then produces the configuration file and deposits it in /home/rafay.rasool/ansible/configs/ folder.

Template folder:

A quick look at the template folder yields the following output:

The base config is what the task file will always prefer to use. This base configuration file contains all the configuration related to the core switch. However, the base.j2 file points to 3850.j2 where it gets its interface related information. The wisdom here is that for a different model of cisco switch we don’t need to duplicate configuration. We can simply create a new template identifying configuration which is different for that switch and proceed to dump that config in a jinja template file titled with the name of that switch’s model. This model name is then referred to in the task file. This results in reusability of the same base template for the core switch and reduces the amount of work required to manually create more templates with the same variables.

An example would be the use of cisco’s 3750 series switch as core switch for the next office deployment. All we would have to do is modify the task file with 3750 instead of 3850 and then make sure a jinja template is configured in the template folder titled 3750 that has all configuration in it that is different in 3750 series switches only. This way, ansible would use the base configuration which is similar in all cisco switches and refer to the directed model in the task file to fetch the correct config for the device in use.

A quick look at the base template produces the following output:

A quick look at the 3850 template yields the following output:

{% block interfaces %} points to a block of interfaces in another file. This file is the defined file in the task of the role which in the example is 3850.  {% extends “base.j2″%} in the 3850 file simply defines the extension of the base.j2 config file which is extended with the addition of all the config in the 3850.j2 template. Upon reaching the end of the 3850.j2 template file, ansible returns to base.j2 jinja template for execution of the remaining config in the template.

Variable folder:

The variable folder is where all the variables are listed that the task file picks and places inside the jinja template found inside the template folder. A quick look at the variable file produces the following output:

Each variable can be modified to a specified value and upon the next run of the playbook, this would impact the generation of the configuration.

Generating Configuration:

When tasked with an office deployment, all you need to do is modify the variable file in the firewall, core-switch and access-switch folder and then re-run the playbook. But before you can do that you have to define the variables first. These range from the IP schema to point to point addresses etc.

Therefore, lets say I want to churn out configuration for a new office with site code RMP-2. I would simply go ahead and open the variable file for the firewall and modify it as seen below:

Note: Remember to use CTRL+X and then press Y to save the config file when exiting if modifying the variable file using nano. For vi, its shift+zz

Similarly, a quick look at the vars file for core switch yields the following:

Moreover, a quick look at the vars file for access switch yields the following:

In case of access switches, each new line starting with a – denotes a new access switch. You simply need to change the sitecode details and update the management IP address in front of your management variable (in my example, it’s vlan20_ip) for each switch along with the gateway address. This is because the access switches are usually layer 2 switches with all layer 3 subnet addresses sitting on the core switch. If your deployment is different than modify as appropriate.

Once done, you are now ready to churn out office configuration using the office playbook inside the office-template folder.

Running the playbook:

To run the playbook all you need to do is go inside the office-template folder and pass the following command:

Once the playbook runs successfully without any errors, you can go back and view the generated configuration files which should be inside the ansible/configs folder:

Limitations:

Although Ansible reduces the time it takes to churn out configs, an IP Schema for your new office still needs to be defined and preferably uploaded onto an address management system such as Netbox before the variables inside ansible are modified.

It is easy to forget what IP address belongs to which vlan. A better naming convention in Netbox can help avoid this confusion.

Jinja template: Network device configuration

how-to-create-a-jinja-template-network-configuration

Creating a Jinja template is a very efficient way to deal with repetitive configuration of network devices. It is generally good practice to create templates for your network configuration anyway as most of the time network deployment requires change of IP addressing etc and the rest of the configuration file mimics that of a previous deployment.

One way to achieve this is with the use of Jinja templates. Originally designed to be used with Python, Jinja templates are very handy when used in conjunction with ansible. You can refer to my post on how to setup ansible here.

Refer to a snippet from a cisco jinja temple file:

In the above exhibit, you can see that wherever variables were meant to change, we created item values in a jinja template. All values inside {{}} get replaced with the reference value. This way, you can modify and create a new valid configuration file for a new deployment of any network device within minutes.

Just like the configuration snippet above, if the whole configuration file of a device is modified using a jinja template with the correct variables referenced everywhere, you can imagine how simple configuration generation would become.
You can either use jinja templates with Python or Ansible. Even though I perform extensive scripting to automate network tasks using Perl and Python, when it comes to bulk config generation, I am a big fan of Ansible. I prefer to define playbooks for all types of network use cases and then run them when needed.

With ansible, you can define all variables in a yaml file and create a playbook to call this yaml file. The playbook than replaces the referenced jinja template with all variable values found in the yaml file and generates an output file that mimics the configuration your wanted. It’s really that simple!

To refer to my guide of using Ansible in conjunction with jinja templates, refer to my post here.