May 7, 2016

Git For Network Engineers

Devops is a buzz word that means a lot of things today. In my pursuit to find out what all the excitement is about, I came across something called "version control". There are multiple version control systems out there, but the one I've been using the most personally is git.

Version Control Explained

Version control is a system to track changes to a file or multiple files at a time. Git tracks changes to a file in the form of something called a "commit". Once the file has been "committed" it will start being tracked by the git version control system. With the file being tracked by git you can start establishing a history of all your changes. Think of every commit like a "snapshot" in time, when the file was changed. Git will track the line additions or subtractions to your file and also store a log of messages along with that snapshot. Programmers use version control to track the history of their code. Version control is a very powerful tool for programmers in particular because it allows them to identify the point in time when a bug was introduced into their code or allow them to work on their program without impacting the "master" code. However! Version control isn't just for programmers. Anyone can benefit if they have a need of tracking changes, establishing a history of a living documentation, and tracking a particular procedure or process.

Git. Not Just For Programmers.

If you've been in network engineering for a long time you may be what is considered a "wealth of knowledge" or a "benevolent configuration overlord" at your company. Someone who other engineers seek out to understand the history of a particular environment. How nice would it be if you could track your entire thought process of establishing and maintaining that environment. It would empower yourself and your peers to figure out why things are in the production network configuration or why a particular technology was introduced, and the way in which is was introduced. On the flip side, how nice would it be if you're a new hire at a company or a junior engineer and you want to learn about your environment and history behind it all. A well maintained version control system can enable your team to accomplish these things. The senior engineers  can share their historical knowledge. The new engineers can learn the history and "the why". The junior engineers can feel engaged and not in the dark when it comes to configuration and "configlets".

"How is this any different from establishing a good knowledge base?"

I asked myself this same question when I heard about version control systems. I wondered, "What could be beneficial about this, if I keep well maintained pdfs or word documents?". After learning about git and git collaboration tools ( such as GitHub ), I discovered sharing and tracking knowledge with git is an entirely different way of thinking. I was basically asking the wrong question. Git isn't designed to replace your local file share where you may keep topology diagrams, software images, or other miscellaneous objects. It is designed for source controlling your code. Code can mean different things to different professions. To an author, "code" could be a book. Keeping track of the history and changes of their body of work. To a mathematician, "code" could be a series of formulas or an algorithm they're developing. To a network engineer "code" could be a device's configuration or a snippet of configuration.

Git In Action

For this example, let's pretend we need to keep track of a quality of service configuration for a particular network element. We'll start with the initial configuration and initialize a git repository. First create a repository.

ong$ mkdir Git_Repo
ong$ cd Git_Repo
ong$ git init
Initialized empty Git repository in /Users/ong/Git_Repo/.git/
ong$ git status
On branch master

Initial commit

nothing to commit (create/copy files and use "git add" to track)
ong$ 

We created an empty directory and initialized the directory as a git repository with the command "git init". After we initialized the repo we checked the status of any files inside that directory using "git status". We can see that there is nothing to commit, basically nothing is being tracked yet. So let's create our initial configuration and start tracking it! We're going to create a file called branch_qos.txt and save it into our git repository.

#branch_qos.txt

class-map match-all VOIP
match ip dscp ef

policy-map WAN_SHAPER
class VOIP
priority percent 20
class class-default

Let's check the status of our git repo:

ong$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    branch_qos.txt

nothing added to commit but untracked files present (use "git add" to track)
ong$ 

We can see that our git repo noticed branch_qos.txt as a new, untracked file. Currently, git is not tracking this file yet. To do so we will need to use the "git add file" command.

ong$ git add branch_qos.txt
ong$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   branch_qos.txt

ong$ 

Now git is tracking branch_qos.txt. Let's commit the file to the "master branch" using the command "git commit -m 'commmit message'".

ong$ git commit -m "Initial commit of branch QoS config"
[master (root-commit) 6a4d25e] Initial commit of branch QoS config
 1 file changed, 7 insertions(+)
 create mode 100644 branch_qos.txt
ong$ git status
On branch master
nothing to commit, working directory clean

Now our QoS configuration has been committed to our master branch and both the file, branch_qos.txt, and our repo are synced up. Let's say some time has passed and your voice group has informed you they want to change the VOIP codec being used and they need more bandwidth in their priority queue. So we modify the QoS configuration as follows:

#branch_qos.txt

policy-map WAN_SHAPER
class VOIP
priority percent 30

We save the file and check the status of our git repo.

ong$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   branch_qos.txt

no changes added to commit (use "git add" and/or "git commit -a")

Git noticed our configuration has changed. Let's commit the change and add a log message explaining why we changed the size of the priority queue.

ong$ git add branch_qos.txt
ong$ git commit -m "Modified priority queue to account for new VOIP codec"
[master 9cf98c9] Modified priority queue to account for new VOIP codec
 1 file changed, 1 insertion(+), 1 deletion(-)
ong$ git status
On branch master
nothing to commit, working directory clean
ong$ 

Now we can start viewing the history we've established using the git log command with the -p flag.

ong$ git log -p
commit 9cf98c9733a168aa47bd69f9eb6cb9b52567ebc8
Author: onenetworkguy 
Date:   Tue May 17 22:00:15 2016 -0500

    Modified priority queue to account for new VOIP codec

diff --git a/branch_qos.txt b/branch_qos.txt
index 04acb4d..8885400 100644
--- a/branch_qos.txt
+++ b/branch_qos.txt
@@ -3,5 +3,5 @@ match ip dscp ef
 
 policy-map WAN_SHAPER
 class VOIP
-priority percent 20
+priority percent 30
 class class-default

commit 6a4d25e3f0d2f77fd8f016e382730fc6d86d971b
Author: onenetworkguy 
Date:   Tue May 17 21:51:50 2016 -0500

    Initial commit of branch QoS config

diff --git a/branch_qos.txt b/branch_qos.txt
new file mode 100644
index 0000000..04acb4d
--- /dev/null
+++ b/branch_qos.txt
@@ -0,0 +1,7 @@
+class-map match-all VOIP
+match ip dscp ef
+
+policy-map WAN_SHAPER
+class VOIP
+priority percent 20
+class class-default
ong$ 

We can see the initial commit when our priority queue was configured for 20 percent and we also see our latest commit where the "priority percent 20" line was deleted and "priority percent 30" was added. We also see our commit message explaining the reason for the change.

Git Expanded

Hopefully, with this simple example, the benefits of version control are becoming a little more clear. When working with configuration with hundreds to thousands of lines of syntax having a good version control system in place will aide in remembering why something was removed or put in place. In our example we were using git locally on our machine. However, this isn't ideal for team collaboration. There are multiple git tools available for teams collaborate on the same code, you may have heard of an extremely popular tool in GitHub.