Welcome to zeroslash.io
There's nothing to show here but you can use the link below to go to the main website.
Network Automation
Network Engineering
How To Become A Network Engineer
In this post, I'm going to take you through how to start your career as a Network Engineer. I understand that there are many aspiring Network Engineers that are just lost or confused about how to start or which path to take so that they can enter the Networking industry. Since you are reading this, I'm going to assume you are one of them. Don't worry as this is exactly why I wrote this blog. This post is the result of the common questions I get talking to many aspiring Network Engineers, as well as things I learned from my own experience.
Below are the 5 main points that we will cover:
All about certifications
How to train
How to study and practice
Job hunting
Working as a Network Engineer
How I started
I started my journey into Networking back in 2007 and like most newcomers into the field, I started with studying Cisco and eventually got my CCNA (Cisco Certified Network Associate) certification. Please realize that this was more than a decade ago, so my options back then will be different from your options today. A lot of things have changed and the good news is nowadays there are more ways to start a career in Network Engineering, and a whole lot more study resources as well.
At that time back then when I was studying, I only had 1 book, a network simulator with limited support of network device functions, and a dial-up connection if I had to do some online research (yes a 56 kbit/s connection). Fortunately, today things have improved a lot and there are more resources for learning and research.
Alright, I won't keep you waiting because I know you want to go straight to the good stuff.
All about certifications
Let's talk about certifications. The reason why I'm starting with this one is that I want to show you what's out there. When you are just starting out, you may not even know what exists.
In this section, we will break down the different options that you have. Take note that this is not a comprehensive list of possible paths for you, but at least these are the options which I know that are out there.
So why certifications?
It cannot be denied that the majority of the entry-level Network Engineer job openings today are still looking for certified candidates. The networking industry is a "vendor-driven" industry dominated by large networking vendors. When we say vendor here it means a manufacturer of networking equipment such as Cisco, Juniper, Huawei and etc.
To understand this "vendor-driven" industry, compare this to programmers or the Software Engineering world. Certification is NOT a thing for programmers.
With certifications, companies do get some benefit in narrowing down their hiring process to just "certified" job candidates. At least, for the most part, because the system isn’t perfect.
On the other hand, there are organizations out there who don’t really care about certifications and have their own capability to figure out candidates that fit their requirements as well as train them for the actual job without the help of any certification body.
Overall, it’s a matter of industry and company requirements. So there’s 2 main paths for you, one that requires certification, and one that does not.
The companies which do not require certifications are harder to find since they are fewer. Fortunately, we now have more people and more information on the Internet, you can just post a question (such as in FB groups or forums) and someone will probably have a recommendation. Thanks to information being more easily accessible.
Now let's go to this question - "If I will go via the certification path, what are the different certifications out there?"
The different vendor certifications
Cisco (CCNA)
This is the most popular entry-level networking certification and the one which you will find in most job requirements. Cisco is the top networking vendor and their products are the most deployed networking equipment especially in the enterprise environments (medium to large business).
However, unlike 10 years ago, Cisco has a lot more competitors nowadays. So there are other networking vendors which are taking some piece of the networking market.
CompTIA (Network+)
CompTIA is a vendor-neutral certification body which has a variety of I.T. certifications (vendor-neutral means they are not specific to any company or vendor). One of the major ones being Network+ which is their networking certification.
Juniper (JNCIA)
Juniper is a major competitor and also have their own certifications similar to Cisco’s certification program. They primarily compete in the Service Provider space (ISP/Telco) but also have a respectable position in the enterprise space primarily with their firewall/security products.
They are quite strong on automation so if you’ve heard about the buzz around Network Automation, Juniper has a lot of advantages when it comes to that area.
To give you an idea about what's going on in this field - Network Automation, which includes learning Programming, is the current trend in the Networking industry.
Huawei (HCIA)
Huawei is another major competitor and just like Juniper, they also have their own certification similar to Cisco’s certification program. They primarily compete in the Service Provider space as well but have also been trying to penetrate the enterprise space.
Alcatel-Lucent now Nokia (NRS 1)
Alcatel-Lucent which is now owned by Nokia also has a certification program. However, their certification is targeted for the Service Provider space since that’s the market they mostly compete in, quite similar to Juniper. But unlike Juniper, they have less presence in the enterprise.
Due to less popularity, this certification may not end up on top of your list. However, it does give you more options. I have read their books and it's actually good material.
Even if you consider this just as a "good to have" certification, it may still give you a unique advantage since there’s not a lot of Network Engineers who have this.
When you apply for a Service Provider who uses Nokia/Alcatel-Lucent, then you’re probably going to be highly considered.
Certification renewal
Certifications are renewed every few years. For example, in Cisco certifications, the CCNA certification, as well as the CCNP certifications (the next level of certification after CCNA) have an expiry of every 3 years.
Higher-level certification
Most of the vendor certification programs have different levels of certifications. For example, in the Juniper certifications page, you’ll see that they have multiple levels of certifications, starting from an Associate Level (entry-level) to an Expert Level certification. You can think of this as beginner, intermediate, and advanced level certifications.
For now, you don't need to think about anything else other than the entry-level certifications. However, I'd like to give you a glimpse of what you're getting into.
Entry-level certifications are just the beginning. The typical approach is to climb up the ladder and take higher-level certifications as this also renews your existing certification.
You'll be doing this every few years for you to maintain your certification. You've got to be dedicated to it because it means you'll be constantly studying (with timelines since there's an expiry date).
Should you certify or not?
This is a question only you can answer. Most people will try to get certified. The biggest reason you will certify as a beginner is so that you can get into the industry. Since you don’t have any experience, all you can really show when starting your career is a certificate, proving that you have gone through the necessary studies.
However, if you can land a Network Engineer role in a company that doesn’t require certifications then i think you can get away without it. Yes, this is possible and some Network Engineers started this way. Although you probably need to stay there for a while, because your primary target in the first few years is to gain experience.
Once you get in, you need to accumulate experience, so later on in case you move jobs and someone else is looking to hire you, their primary decision point is your experience. You’re not a beginner anymore, you have the experience. If ever you get the chance to get in without a certificate, make the most out of it - learn and gain experience.
It's worth noting that studying certification material is still very helpful regardless if you take the exam or not. I personally have studied certification books without taking the actual exam. I just read the book, and I just wanted to learn.
Honestly, that's really the whole point of it. The paper doesn't matter if you can't prove that you've learned from what you studied. It's one thing to certify, passing an interview is a different story. Once, you're in the room with your interviewer, it's all just you.
How to train
Now let’s talk about your options for training. Here you can decide which path you want to take in terms of studying and training either for a certification exam or just to learn in general.
Live face-to-face training
I'm going to use Cisco here since it's the most popular and most available. There’s a lot of training centers nowadays, the majority of them are within Metro Manila. I just want to point out that most of the training centers available only offer a “boot camp” training. What this means is that it’s usually 5 days and is fast-paced.
WARNING: Cisco boot camps are not meant for total beginners or if you’re starting from "zero-knowledge". A boot camp is intended for those who already have some prior learning and are close to taking the certification exam. The point of a boot camp is to validate your existing understanding of what you have learned so far and fill in those areas which you feel you’re not confident yet. The bottom line is to prepare you for your Cisco certification exam.
It’s worth noting that there are slow-paced trainings as well. It's typically comprised of 4 modules (usually they call it Cisco 1 to 4) and is taken over a span of a couple of weeks or months depending on the schedule. If you’re starting from "zero-knowledge" this is probably better for you.
NOTE: due to our current situation with the pandemic, some may be hesitant with live face-to-face training. But I still included it as it is an option that existed even before all this started and may still be a good option after we all get through this crisis.
Self-study (self-paced)
If you have a limited budget or going to face-to-face training is not possible for you or you simply don't have plans to certify, then this is the option for you.
I know a lot have done this with success so it’s still a good option especially if you want to take your time with your studies. You can either read books or watch video tutorials.
As far as price is concerned, self-study won’t cost you as much. However, expect to put a little more effort in trying to find answers to your questions.
I highly recommend joining a community of other people who are also learning networking such as online groups. I will tell you from experience that learning with the help and support of a community will make your learning journey faster.
How to study and practice
Virtual lab
Having a virtual lab (virtual network simulator/emulator) is crucial because you want to be able to practice anytime.
I wouldn’t advice building a physical networking lab as a first option, but if you prefer that and you have the budget, yes it's possible. There are many refurbished equipment you can buy online.
In reality, you can survive without ever building a physical networking lab. Here are a few reasons why.
It’s not required for entry-level certifications (if you will certify).
Virtual network simulators/emulators nowadays are much more mature and reliable than before. Unless you are training for an expert level networking certification, you probably won’t need it.
You’ll be able to handle physical equipment anyway once you’re on the job.
Note that if you plan to work for a role that requires a lot of physical work such as cabling, racking and stacking (see what a rack looks like here), then getting experience with physical equipment will most likely be better for you. Such kind of work is not uncommon when you’re just starting out and don’t have any experience.
I also acknowledge the fact that it can boost your confidence if you've handled physical network equipment before applying for a Network Engineering role.
If you're already in the I.T. field, you probably are already doing some related work so I don't think you're going to be completely clueless about physical equipment and cabling, etc. I'll leave it up to you to gauge if you really need to experience it.
I know some aspiring Network Engineers enroll in boot camps just to experience the physical hardware. If you're purpose is to experience physical hardware, then perhaps it's a better idea to just buy physical hardware. Because you can't take the equipment in the boot camp back home. That way you can practice on real equipment anytime.
Virtual lab software
Here are your options for virtual network simulators/emulators.
Cisco Packet Tracer
GNS3
There's another one called EVE-NG however I wouldn't recommend it for complete beginners.
If you're going for just the CCNA certification, Cisco Packet Tracer will suffice. For a more future proof setup, GNS3 is a better option than Cisco Packet Tracer since it supports other networking vendor devices, not just Cisco. As you gain experience, you'll eventually encounter other networking vendors so multi-vendor support for your virtual lab is a good thing.
It's worth mentioning that for Cisco Packet Tracer, it can only simulate the network devices. This means that it is not real. But it's the easiest to setup and use.
For GNS3 (as well as EVE-NG), it provides emulation for the actual network device software. This means that it is close to the real thing.
When the network device software is loaded into an emulator such as GNS3, the network device software "thinks" it is running on real hardware. But in fact, GNS3 is just making it "appear" as if there is a real network device hardware. This is the main difference between a simulator and an emulator.
NOTE: You will have to provide the networking vendor software on your own (ex. Cisco IOS). This is usually the inconvenient part when using emulators because some of these network device software requires you to spend some money to acquire them legally. It's worth noting however that some networking vendors are already providing their software for free (lab purposes only). An example of this is Juniper.
Books and video tutorials
When it comes to self-studying I find that videos are usually a good place to start with. I like reading, but the video tutorials tend to give you a better "overview" approach.
If I want to dive deeper into a topic then that’s the time I will read the books. Books are usually the "detailed" version and work well if you’re ready to get into the specifics of a topic. I would recommend going for the official certification/study guide of the certification exam you're studying for.
If paired with some online search and asking some help from online communities, self-studying isn’t that hard at all. But here’s the truth, whether you choose to get more help with face-to-face training, or if you self-study, you’ll be self-studying anyway, all throughout your career. Learning in I.T. never stops so you need to learn how to learn by yourself.
Job hunting
Entry-level requirements
The typical requirements would be similar to what you can find in the Network+ or the CCNA exam. Obviously, each company will have their own qualifications. However, I’d like to point out a few important topics that you should really nail at the time of the interview.
The OSI or TCP/IP model - This is the base for everything so your TCP/IP knowledge should be solid.
IP addressing and subnetting - I know it's the math part which a lot of people don't like but this is something you will breathe every day as a Network Engineer so you have to get used to it.
Basics of Routing - You’ve got to at least cover the very basics of routing such as how a router selects the best route, how to advertise networks and some basic ways to control or manipulate routing.
Basics of Switching - You’ve got to at least cover the very basics of switching such as how a switch learns MAC addresses, how it handles broadcasts and unicasts. You need to understand the basics of Ethernet and VLANs.
I cannot stress enough how important these basic topics are. Imagine failing an interview because of a basic question. You may not be able to get all the questions right but at least get the basics right. To me this is the most important thing for a Network Engineer candidate apart from character and the other non-technical considerations.
The different industries
Here are some examples of typical industries or types of companies that you might get into. This gives you an idea on where to go in the industry. It's a big world by the way, but I'm going to list the ones which are common.
SI (System Integrator)
These are the ones which sell vendor equipment/products to companies as well as help companies deploy and implement these equipment/products. So primarily working in an SI will involve roles such as implementation and pre-sales.
Service Provider (ISP/Telco)
As the name suggests, this involves working in some Internet provider, Telecoms provider as well as other types of network communications provider. There are various roles for Network Engineers in a Service Provider. This can be any of the following.
NOC / Operations
Implementation / Service Delivery
Design / Architecture and Engineering (typical for more senior roles)
NOTE: Service Providers are large networks. So it's normal to have dedicated teams for specific types of work.
Enterprise
This makes up the largest portion simply because there are a lot more other businesses compared to System Integrators and Service Providers.
These businesses are usually the customers of the System Integrators and Service Providers so you’ll be in the "customer" environment.
You’ll usually work with Service Providers for your Internet and WAN (Wide Area Network) connections. You might also work with System Integrators if you buy networking equipment from them.
Vendor
Yes, it’s also possible to end up working with the vendor itself. This is not one of the common places that Network Engineers start out but it’s good to know that it’s a possibility somewhere down the road.
Below are some of the typical roles when working for a vendor.
pre-sales / sales
consulting / expert services
It's worth noting that in these roles it's normal to have some design and architecture related work. Most of the time you are working on getting a solution deployed on a customer network.
Personally, I’ve worked for Service Providers for the majority of my professional career. I’ve also worked with one of the major vendors but even when I was working for a vendor, I was still working with Service Provider customers for the most part (vendors of course also sell equipment and provide networking expertise to Service Providers).
Deciding where to work
Now that you know the common industries that you might get into, you can decide where to work. It's not going to be easy figuring out where you would fit. But at least you have an idea of your options and you can check which one appeals more to you.
I can't tell you which industry to go or where you should work. You'll discover or perhaps stumble upon that on your own.
In my case, I dreamed about getting into the Service Provider industry. But I didn't know I was going to work for an ISP on my first job as a Network Engineer until my first day at work!
But let me give you a piece of honest advice. I understand everybody has their own priorities in life. However, based on my personal experience, I highly recommend working in a place where you will get the most exposure.
A good learning environment where you can really sharpen your skills is beneficial in this early stage of your career. Even if the salary isn't that high, but if it trains you well, ideally not just on the technical side but in other areas as well, it's a lot more worth it long term.
It will be easier for you to succeed later on because your skills and experience are much more attractive. Never underestimate the value of experience.
What to do when experience is required
A lot of companies looking for Network Engineers requires someone who already has experience. I get this a lot from young and aspiring Network Engineers.
"It's hard to get experience if you need experience to get a job" - I see these kind of comments all the time. It may sound funny but this is actually a real frustration for someone who's trying to break into Network Engineering.
We also can't blame some companies for only accepting candidates who already has experience. They have priorities, and that may include time and money.
They may not have the resources to train someone. It could also mean they really need help and needs someone who can take care of the network for them. Apart from that, even a small configuration mistake may have big consequences in a network. There's a risk factor for them.
So what can you do as an aspiring Network Engineer? Well you can focus on the companies or job positions where you have a better chance.
There are still companies out there who hire candidates with no experience but with good potential. Of course, you will start with simple things first, and then work your way towards more complicated tasks. If you come across one, especially if it will give you good exposure to networks, grab the opportunity!
There are also many options for a stepping stone. If there's a Network Engineer opening and you don't meet the requirements, check if they have other open positions for a more junior role. Something you can apply for just to get in. You can work your way through promotion later.
Working as a Network Engineer
What to expect for junior positions
Networking is such a big world, and just like you could never really know everything, you definitely cannot handle everything, especially at the beginning. So don’t be surprised if you’re only tasked to do a few (and easier) things at the beginning. It’s just natural that you’ll only be given more responsibility as you learn and understand more about the network.
What to do when you get in
I’m just going to say it again. Make the most out of it - learn and gain experience. That’s your focus, because that’s your investment to yourself. Sharpen your skills because you’ll benefit from it later. You may think it doesn’t sound much but let me give you something to think about.
Imagine that you already have an experience of 5 years being a Network Engineer and you have a great opportunity in front of you. You’re sitting in an interview and you have to sell yourself. What would you want to say? Think about that for a moment.
How the beginning looks like
Back when I was just starting out as a Network Engineer, I realized that everything I knew was just the tip of the iceberg, similar to most things we learn in life. Expect to start learning all over again once you're in practice.
I learned that there is a big difference between knowing something, and using it in the real world. There's a whole lot of stuff you won't learn from the books, and that's easy to understand. It’s called reality.
The books are meant to give you the basics. You are given the manual, but how you implement it for your network environment is a different story. I know this sounds like it's just common sense. But it's better for me to mention it than not.
It is only by experience that we begin to really learn how to harness our newly acquired knowledge. They don't really turn into skills until we actually make use of them in practice.
As we go through the journey of building and breaking networks (yes, I made mistakes, and you will too), we begin to connect the dots and understand the weight of our actions. We realize that there’s more to this than just typing commands on a network device. There’s a need for a sense of ownership, a sense of responsibility.
Continuing your journey
Forming a habit of learning either by taking courses, reading books, or even just researching online, along with enough curiosity to try out the things you learn and apply it, is a good formula for making it in this industry.
But improving only your technical skills isn't enough. Being able to communicate and work with your peers, customers, and people external to your organization is a very important factor.
We can continue to refine our skills by:
Constantly updating our knowledge
Putting our knowledge into practice
Sharing / collaborating
Learning from others
By focusing on improvement, it becomes easier to be in a position of success. You'll be surprised one day how far you have gone.
"Knowledge is a treasure, but practice is the key to it." - Lao Tzu
Review
To wrap it up here's a summary of what we just covered.
First, we talked about certifications. We discussed this for you to understand the different paths you can take. We talked about why we have certifications and the typical certifications exams, as well as not so common ones. We also touched on certification renewal and higher-level certifications. We ended the section by discussing whether you should certify or not.
Second, we talked about training. We discussed your options on how to go about your learning journey to become a Network Engineer. We discussed both face-to-face training and self-study options.
Third, we discussed what to do (or have) for your studies and practice. We primarily discussed virtual labs but also touched on considerations for having a physical networking lab. We ended the section discussing books and video tutorials which are important if you're going to self-study but is even more important all throughout your career.
Fourth, we talked about job hunting. We discussed the important topics you should nail when applying for entry-level positions. We also broke down the different industries that you can get into as a Network Engineer. We described the nature of these industries, as well as what potential roles you might find in these different industries. We ended the section with some guidance on deciding where to work.
Finally, we talked about how it is working as a Network Engineer. I gave you an idea of what to expect and what to do once you get in. We also covered how the beginning of your career may look like, as well as some advice as you continue your journey.
Was this post helpful? Please consider sharing this to friends who might need this information. It helps me a lot!

by: Jess Primero
@iamzeroslash
Related content
Applying For Network Engineer Positions
In this post, I’m going to give you some tips and strategies that I’ve learned from my career in Network Engineering when it comes to job applications. I get a lot of job application-related questions talking to many aspiring Network Engineers and I’m sure there’s a lot more out there who needs this kind of information and advice. I’m not promising I have an answer to all your questions, but I’ll try to provide as much insight and direction in the following points that I will talk about.
Below are the 4 main points that we will cover.
What to look for in job openings
Resume tips
The hiring process (nobody tells you this)
How to prepare for your technical interview
An aspiring Network Engineer’s story
Before we dive into the topics, let me get into a story of a young and aspiring Network Engineer named Martin.
When Martin first got into networking he took immediate steps to get a job wherein he can practice his new knowledge. He wanted to work for an ISP back then, but it turns out that for local ISPs they had some requirements which he didn't have. He couldn’t apply for those jobs.
Searching through job ad after job ad, he tried to get an interview with any company which posted "Network" in their open positions. He knew he had to get some experience first and move forward from there.
He stumbled upon a call center with a network-related job opening. He then went to their office to submit an application and was hoping to get an interview. He was told to just wait for a call. Martin was really looking forward to getting an interview, but it didn't happen.
But just as he was about to go back down the elevator, he saw this office right across the one where he just submitted his application.
It was another call center, and in their poster right at the entrance mentioned "IP Network Engineer" in one of the open positions. His face lit up again, like a kid that got handed back the candy that was taken from him. He submitted a copy of his resume and was told to come back a week after. With a specific day, an exact day! Which means he got an interview schedule. He was the happiest young man and went home with all smiles.
Martin went through the scheduled job interview which was followed by another 2 interviews.
After the series of interviews, he waited but did not receive any call. He actually waited for 3 months or so before receiving a feedback. It was the last quarter of the year, and those 3 months felt like eternity for him. Because he was hoping, and expecting. He did apply for some other job openings but wasn't really getting any luck despite all his efforts.
But eventually, Martin did land the "IP Network Engineer" role.
It was the month of January, there was no better way to start the year. He had a fresh start with a new job he dreamed about. It actually turned out to be an Australian ISP. The call center office which he applied for, turned out to be the offshore office of the ISP. It included other departments and teams such as the Network Engineers.
The responsibility of the job he got turned out to be for the ISP in Australia. So all of a sudden the young Network Engineering freshie will start his journey to help build and maintain one of the largest ISPs down under.
I hope that little story inspired you. Yes, many of us go through the same stages as what Martin has gone through. However, each one of us has different situations in life and we will be presented with very different opportunities. With that said, this post was made to help you better navigate the world of Network Engineering.
Now let's move on to the good stuff.
What to look for in job openings
When looking for Network Engineer positions, ideally we want to optimize for experience. This means that we would want to go for getting the best experience that we can get. You probably have noticed it, a lot of Network Engineer positions require some previous experience. So getting good exposure to networks is crucial.
Here are my recommendations on what to look at when you’re checking a job ad.
Base your judgment on the job description, not the job title:
When looking at a job opening, you need to go through the job description and base your judgment from there instead of just referring to the job title.
A job title is just a title and doesn’t give you an accurate picture of the role’s tasks and responsibilities.
You can have a fancy title but don’t really have good exposure to networks. You can have a simple job title but have solid network experience. You get the point.
Note that some companies will have job titles as “Network Engineer” but the actual job doesn’t necessarily require a lot of Network Engineering skills such as mixing it with other responsibilities that are not necessarily related to the network. So always review the job description or job responsibilities.
Honestly, sometimes even the job description isn’t 100% accurate. This is something you’ll just have to find out in the actual job interview.
So how does one determine a good job description?
Well we go back to our aim which is to gain good exposure to networks.
There are 2 aspects to consider:
how focused are the responsibilities are on networking
how in-depth the required skills are
This leads us to the next point.
The more focused and the more in-depth, the better:
You might ask - does that mean I need to avoid jobs with non network-related responsibilities?
Well I think it boils down to this. When you are going through a job description, if you feel that they're trying to cram a mix of I.T. functions into one role despite the title being "Network Engineer", that most likely means you'll be switching across various other tasks.
So you can start and weigh things from there.
If you're not sure or if something isn't clear, you can always ask. However, these things will almost not be disclosed until you're in the interview room.
The biggest reason why you would want to go for more focused and more in-depth network related jobs is because of "Relevant Experience".
In other words, how well does your experience or overall profile matches the position you're applying for.
As you move forward in your career in Network Engineering, your profile will be judged based on how much experience you have working in a particular area of networking.
Generally speaking, a more "focused" profile will be preferred over experience that's a bit scattered. You'll understand this more in a later discussion.
You might ask again - does that mean I should not consider getting experience on other skills so I can diversify?
The answer is not yet. Specializing gives you a better chance to get off the ground FAST.
At the beginning of your career, focused and deeper knowledge is better than diverse but shallow knowledge. That is if you want to go faster.
However, diversifying your skillset is necessary later on as you gain experience.
Take note that it's not just about diversifying. A good combination of complementing skills is one of the key aspects to providing uniqueness to your profile.
NOTE: Focused and diverse are quite loose terms here. To be completely honest, within Network Engineering, even the baseline skills are already quite diverse. Understanding the basics requires going through a wide range of topics.
Consider the nature of business of the company:
The level of experience you will get across different companies will not be equal. There are a few things that can prevent you from getting good exposure to networks.
Below are some of the common reasons:
If the company does not consider the network infrastructure a critical part of the business (regardless if it is or not)
If the network is simply not a core driver for the business
The network requirements are super simple
I know this is an unfair example, but just to make you better understand - a Network Engineer for a mall will not get as good exposure or experience compared to a Network Engineer at Google.
Google’s networking team is a driving force for their business. There’s no doubt that a mall business doesn’t have the same networking requirements as Google. Again, this is just for the sake of example, but I hope that makes sense.
It’s also worth noting that these points I’ve mentioned do have an impact on your potential salary. But again, it depends on how a company sees its network infrastructure, and most importantly, its Network team, as a part of its business.
Now I’d like to point out that I’m not telling you to only apply for companies with massive budgets and invests heavily on network infrastructure, or has complex networking requirements. Majority of the companies out there are not like that. There are scenarios where it makes sense to go for those.
My point here is for you to maximize your time.
As I said, we would want to aim for getting as much good exposure to networks as possible. This is particularly important in the first couple of years of your career.
Quality experience can significantly accelerate your career as well as your value.
Imagine spending 2 or 3 years in a place where you feel stagnant.
Yes, you can keep improving outside of work. But remember that you will spend at least 40 hours of your week at work. So you would want to maximize the use of your time and focus on getting good experience rather than just many years of experience.
Remember that quality is more important than quantity.
Resume tips
Be more like an artist:
What I’ve learned in my experience is that the thing that got companies calling me is that I’ve set up my profile to highlight my best projects and experiences.
It’s not simply telling where I’ve worked, how many years I’ve worked in a company, or what networking protocols I know.
Before that, I want the person looking at my profile to see in summary what I can bring to the table. Because at the end of the day that’s what they are after. This is the same style used by artists and other creative professionals with their work portfolio.
Most importantly, they have to see something unique about you.
In my case, I’ve specialized in Network Automation. This worked well at a time that Networking skills and Programming skills combined aren’t really common.
However, as you may have heard, Network Automation, as well as a lot of these Software Defined Networking (SDN) related technology are now more widely known so more and more Network Engineers are getting into it.
Build yourself like a game character:
When I was starting out, I wasn’t really consciously trying to design my career.
All I really wanted was to learn and learn more. It was just the hunger for knowledge.
However, as I gained experience, I started to really think about what kind of projects or experience I wanted to get into. So you begin to think and be selective about these two considerations:
Where you would want to work
What kind of experience you’ll get in that place
The purpose of these considerations is for you to be able to shape your skillset. So you want your resume to kind of reflect this shape such as you are built in a particular way.
If you played games such Diablo or say Dota, it’s like collecting items and building your character attributes to fight in a particular style.
If you want to be a tank player then you will have to really pack a lot of armor and still do a great deal of damage, especially in close-range combat.
When you’re a strong player in these games, guess what? People want you on their team.
You're not necessarily strong at everything, but instead you're strong in certain areas and in certain roles. That’s a key to attracting opportunities.
For example, in my case we can say that when someone looks at my skills and experience, it is clear that I'm well suited for an "Automation" role.
The hiring process
Now let’s get to the juicy part. In the following section, I will pull the curtains back and let you know about how the hiring process for Network Engineers is done. So everything that I will talk about from this point will be from the perspective of the company which could potentially hire you.
I’ve done a lot of interviews for Network Engineers over the years and have been involved in the hiring process enough that I believe I have a few things to share.
Please note that these are not necessarily standard practice. Every company has its own approach. Nonetheless this will still help you in your approach in a job application or interview.
The job opening:
The hiring process typically starts with the recruitment team receiving a job opening requirement from the hiring manager. The hiring manager is usually the person who requires additional resources on their team or department.
The job opening requirement will include what the open position is along with the job description and qualifications. As you would expect, these details are pretty much the same details that will end up in the job ad.
Apart from the job requirement, the hiring manager also needs to define certain details that the recruitment team needs to look at in order to filter out the resumes.
This could be like certain keywords, years of experience, number of companies that an applicant has been with, etc.
The point is for the recruitment team to identify what’s a YES and what’s a NO.
This is the part where the high-level overview of your resume matters as well as the keywords you've included. An example of keywords could be certifications, protocols that you know and have experience with, etc.
Filtering of resumes:
When applications start coming in, the applications will be reviewed. Typically, the resumes will be reviewed by someone who can gauge if the applicant is indeed a potential candidate for the open position.
This process will select the applicants who will be invited for an interview. This is the part where the details of your resume matter.
Now there could be an initial phone call to speak with the candidate over the phone and see if it’s worth inviting the candidate for a full interview.
Of course, the company doesn't want to waste time. But this goes both ways since you as the candidate also don’t want to attend an interview that isn't going anywhere. It's important to have respect for the time of both parties.
An important part of this process is to understand how relevant the experience of the applicant is to what is required for the position. This is not an easy task but it is necessary.
The one reviewing the resumes may like the skills you have or the different kinds of protocols you know in your resume. But there's one big question that still needs to be answered.
That is if how well are you going to match the expectations of the job.
Because anybody can put whatever network protocol or network technology in their resume, but your history of experience and environments you've worked with tells it better. Remember this one and it will change how you view your career.
The technical interview:
Now I’m not going to include every detail of how an interview goes about but instead, I'll highlight the key points in an interview.
Phase 1 - The baseline test
Remember the first couple of minutes are important. The reason for this is that a technical interviewer will only try to find out one thing in the first part of the interview and that is whether he/she needs to spend more time on you.
This is a filtering technique. Because an interviewer will not want to wait 30 minutes before figuring out that you don’t meet their base requirements.
Phase 2 - The whiteboard session
Most likely your technical interview will involve a part where you draw and explain a particular network setup on the whiteboard or something similar.
The purpose is to go into the specifics. This is the meat of the interview and you’ll most likely spend the most time here. The key here is to be confident about what you’re explaining, like you’re an instructor teaching how the network behaves.
This is also the part you can’t fake. The technical interviewer will be able to figure out how well you understand the subject.
Be ready to receive questions involving breaking the network topology you have on the whiteboard. This is one approach a technical interviewer may use to gauge your level of understanding of how a particular network setup will operate.
It’s one thing to understand how to set up and configure a network, it’s another thing if you know how it will react if something fails. This is where your knowledge of how protocols work and behave will come into play.
Phase 3 - Shifting gears
If you are doing well so far, it’s not uncommon for a technical interviewer to step up the questions and see where you start to reach your limits.
This is not about asking you a question about something you don’t know (although those kinds of interviews exist). It is more about figuring out how deep is your knowledge on a subject which you seem to be knowledgeable about.
For example, if you seem to know enough about a particular routing protocol, the next question to that would be like how deep is your understanding of that routing protocol?
This can be taken in different angles but your understanding plus your experience of the subject will come into play in this part. It all comes down to how easy or how hard it was for you to come up with an answer.
How a candidate is considered for the position:
First, we need to make sure that you do well up until Phase 2 as mentioned above. There’s definitely no question about that. The following are some other considerations.
Having one area of strength is enough
To be honest, this is quite a personal take which I’ve used in my experience in interviews. This may not reflect the views of others. But I have a good reason for this.
Everything else can be learned on the job. If you can learn in one area of networking quite well, then it’s likely that you’ll be capable of doing the same in a different area given enough time.
For example, I find that most candidates coming from an enterprise background typically have their strengths in switching and LAN technologies. This is easy to understand because it’s quite normal that most of the action is happening within the LAN in enterprise type of environments.
If you're really good on the LAN side, but not as confident on the WAN side, that's ok. It just means you can be easily deployed in LAN responsibilities and that's already a good start.
Complementing skills
This is where the hiring team looks at what you bring to the table. There is no perfect team so if there’s a part of the team that’s a bit weak or a part which requires more attention, and you have the skills to fill in those gaps, then you’re more likely to be considered.
Chemistry with the existing team
Not all Network Engineering teams do this but I’ve been part of one that does so I’m throwing it here as I think it helps.
Obviously, this only applies to already established teams. Thinking about how well a candidate will work with an already existing team can be a factor to the team’s success.
I understand these things can get complicated because we are talking about human personality and each of one of us is different. We have different attitudes and not everybody can work well with just about anyone.
Yes, we do have to be professional regardless of the people we work with, but I admire teams who take an extra step to do this because I know for a fact that it certainly plays an important part in the working environment.
How to prepare for your technical interview
Now that we have covered the interview process, how do you prepare for it?
The requirements when applying for a Network Engineer position would of course vary. This is highly dependent on the type of company that you're applying for or the industry that they operate in.
Here are the most common types of companies that you might get into:
SI (System Integrator)
Service Provider (ISP/Telco)
Enterprise
Networking Vendor
These types of companies are different environments therefore their preferences in terms of skills will have some differences. Fortunately, Networking is Networking, so there are certain fundamentals that doesn't change wherever you go.
Here are core skills that you should have regardless of where you apply:
TCP/IP Networking - a solid understanding of how the OSI model or TCP/IP model is implemented in Networks
Routing - this goes hand in hand with Layer 3 or Network layer fundamentals
Switching - this goes hand in hand with Layer 2 or Data Link layer fundamentals
Here's a piece of advice - DO NOT underestimate these topics. They may be "basics" and probably don't look that exciting on a resume, but I will tell you it's easy to get lost in a technical interview if you overlook these "basics". You're less likely to get lost (or confused), as long you have a good understanding of these core / fundamental topics.
Since having solid fundamentals will be a big factor in your success, let's go through some points on how it will impact your interviews and your career.
How fundamentals helps you land the job:
Remember Phase 1 - The baseline test of the technical interview process? Well, having a good grasp of the "basics" will help you through that phase.
Here's an example. Let's say you're quite comfortable with OSPF routing and perhaps it's you're favorite topic. You know you can answer OSPF questions with confidence.
But what if you were asked to explain how ARP works. Then let's say you understand how it happens from the client side, but maybe you're not 100% clear on the full process when an ARP passes through a switch.
This is not a good situation to be in. A "basic" question such as this one can cost you an interview. Even if you were well prepared for OSPF questions, all of that doesn't matter if you can't get through these "baseline" tests. This is why fundamentals are very important.
Fundamentals in practice:
Here's the reality. Fundamentals are not just important for the sake of the interview process. They are actually crucial on the real job!
Imagine a Network troubleshooting scenario that stretches for 2 hours when you could have fixed it in less than 15 minutes if you just studied the "basics" well. If it was a Network outage, this becomes even worse.
When you are working as Network Engineer, these "basics" are always running through the back of your mind. The more you use them, the more they become second nature to you - and that's what you want.
Ask any experienced Network Engineer about IP address subnetting or supernetting and you will notice how it's just natural to them. Network Engineers "breathe" IP addresses everyday, they almost don't even think about it. It's built into muscle memory.
Why is this even important? The point here is that these core / fundamental topics are just a portion of the job. We use them to achieve something bigger - and that is to connect computers and people to each other.
When you're trying to build a Network, all these fundamental topics are pieces that we put together to come up with the final outcome - just like how we mix ingredients for a recipe. Every piece has a purpose. A single piece cannot do much on its own. But if we use the right pieces together, we can build a Network.
Since the Network is such an important part of businesses and our day to day lives, Network Engineers essentially help keep the world running.
Ok, that was a lot! But we have covered a good amount of topics that are not only important for your job applications but also for the long term strategy of your career.
Review
To wrap it up here's a summary of what we just covered.
First, we talked about what to look for in Network Engineer job openings. We discussed why you should base your judgment on the job description, not the job title. We discussed about preferring responsibilities that are more focused on the network and more in-depth. We talked about considering the nature of business of the company. We ended the section by talking about maximizing your time and going for quality experience.
Second, we talked about resume tips. We discussed why you should approach it more like an artist such as treating it as a portfolio. We then discussed why you should think like you're building a game character.
Third, we had a detailed section about the hiring process. We discussed how it starts with the job opening and how the resumes are filtered and selected. We answered why relevant experience matters. We discussed the key points in the technical interview so that hopefully you can better prepare for it. We ended the section with some key considerations for hiring a Network Engineer candidate.
Finally, we went through the important topics to help you better prepare for your technical interview.
I hope that the things that i discussed here will be able to help you in your journey in Network Engineering.
I wish you nothing but the best. Go ahead and achieve your dreams!
Was this post helpful? Please consider sharing this to friends who might need this information. It helps me a lot!

by: Jess Primero
@iamzeroslash
Related content

by: Jess Primero
@iamzeroslash
9 Key Reasons To Learn Programming For Network Engineers
Isa ka bang Network Engineer at gusto mong makasabay sa demand ng mga company ngayon for Automation? Alamin kung bakit worth it na mag-invest sa pagaaral ng Python programming.
Client-Server Applications Explained - With Python Example (Tagalog)
Sa topic na ito paguusapan natin ang Client-Server applications dahil sila ang pinaka-common na type ng application that exists on the Internet. Gumagana ang Client-Server communication kung saan merong isang application (server) that listens on a particular port and on a particular IP address sa isang computer, habang meron naman isa pang application (client) na halos pareho lang ginagawa nya, yung nga lang it doesn't listen but instead sya yung mag-initiate ng connection dun sa server. Susubukan nya i-contact yung server through its listening port.
Typically mangyayari to sa pamamagitan ng some form of request papunta dun sa listening application (server) pagkatapos sasagot sya pabalik with its answer dun sa requesting application (client).

Sockets
Para magkaron tayo ng mas malinaw na idea kung papano gumagana ang ganitong communication, kelangan natin maintindihan kung papano mag-create ng network connections and mga applications. Titingnan natin papano to nangyayari sa perspective ng application.
Ang mga applications ay gumagamit ng tinatawag nating sockets para makapag-padala ng messages (data) across the network. Imagine merong pipe between the two applications para makapagpasahan sila ng messages sa isa't-isa.
Kapag gusto natin pumunta sa Google website, we type www.google.com sa address bar ng ating browser. Pagkatapos nito the browser will perform our request. Sa perspective ng browser, ang sasabihin nya is gusto ko makausap ang IP address na to (Google's IP address) sa port number na to (for example 80 or 443).

In the background, may mabubuksan na socket na ang target destination is yung server sa kabila which in this case ay server ni Google. Dahil dito may mabubuong TCP connection sa pagitan ng client at server application. Kung successful ang TCP connection then gagamitin ng browser ang HTTP protocol para makapagpadala ng HTTP request. Kung maging ok ang lahat then sasagot si Google pabalik with the web page na nirequest ng browser at yung browser na ang bahala mag-translate nung HTML, CSS, JavaScript etc. sa makikita mo sa screen.
Susubukan natin himayin ang proseso na to ng mas may detalye, pero bago yun pagusapan muna natin yung 2 paraan na pwedeng mag-open ng socket and mga applications.
Active Open - Kapag ang isang application ay gustong makipag-usap sa isang pang application over the network, it will request to open a socket at kelangan nya i-provide yung details na to.
destination IP address and destination portsource IP address and source port
Sa scenario na to, it is expected na yung pag-open ng socket will require both yung destination and source details. Yung ating requesting application ay gustong makipag-communicate with another application so kelangan nya i-provide yung IP address at port kung saan listening yung kabilang application. Yung ganitong klase ng pag-open ng socket is ginagawa ng isang client or yung initiator ng connection. Sya yung actively nagta-try mag-open ng socket.
Passive Open - Kapag ang isang application ay gustong mag-listen for incoming requests. Wala pa syang kausap na application pero magsisimula sya bumuo ng connections habang pumapasok yung mga request. It will request to open a socket at kelangan nya i-provide yung details na to.
source IP address and source port
Sa scenario na to, obvious naman na yung application na gusto mag-open ng socket ay hindi makakapag-provide ng kahit anong destination IP or port details dahil wala pa syang kausap na application. Gusto lang nya mag-open ng socket at maghintay ng incoming requests. Yung ganitong klase ng pag-open ng socket is ginagawa ng isang server or yung listener. Once open na yung socket, ready na sya to tumanggap ng connections anytime.
Between sa 2 klase ng pag-open ng socket na to, yung server ang kelangan mauna. Listening na dapat yung server bago makapag-open ng connection yung client. Sa example natin, yung server ni Google is kelangan naka-open na ng socket na passive open.

Once nakakuha na ng passive open na type ng socket yung server, ready na sya para tumanggap ng connections.
Yung client ay pwede na mag-initiate ng connection dun sa server. An active open type of socket is requested at susubukan nitong bumuo ng connection between the client and the server.

Kapag nabuo na yung connection then pwede na magpadala ng data yung client and server application sa isa't-isa.

Tandaan lang natin na both yung IP address at port number information ay required together as a pair (IP:port) sa pag-request para makapag-open ng socket.
A Simple Client and Server Application in Python
Meron si Python built-in na socket module na pwede natin gamitin for socket programming. Mag-create tayo ng client and server application. Very basic lang naman at ang purpose lang is to open sockets para makapag-send ng data between the client and server application. Bale yung server application natin will just accept messages and send each message pabalik sa client na nag-send. Pwede natin itong tawaging "Echo" application since para syang echo na ibabato lang nya pabalik yung same na sinabi mo.
Ito yung ating code para sa server - pangalanan nating server.py.
Explain natin yung iba't ibang parts ng server code na to.
1. Una is yung pag-import ng Python module na socket
. Itong module na to lets us request sockets sa ating OS. Hindi na natin kelangan alalahanin kung papano ito lahat mangyayari since lahat ay ipapasa sa TCP/IP software na kasama sa ating OS. Pero kelangan parin natin i-specify yung type ng connection na kelangan natin along with related information.
2. Meron tayong listen_port
variable na may value na 80. Ito yung gagamitin na port ng ating server kung saan sya mag-listen for incoming connections.
3. Nag-create tayo ng socket at in-assign natin sa server
variable. Ito yung 2 arguments na pinasa natin sa pag-create ng socket.
socket.AF_INET - Ito yung mag-specify na kelangan natin mag-communicate using IP, which is IP version 4 (IPv4) to be specific. Meron din IPv6 pero hindi yun kasama sa example natin na to.socket.SOCK_STREAM - Ito yung mag-specify na kelangan natin mag-communicate using TCP. Meron din option for UDP at pwede yun gamitin using socket.SOCK_DGRAM
pero for this example ang gagamitin lang natin is TCP.
4. Tapos ginamit natin yung bind()
method para ma-bind yung ating socket gamit yung IP address and port na gusto natin. Dito sa example natin hindi tayo nag-specify ng particular IP address kaya meron lang tayong empty string then after that yung listen_port
variable. Since hindi tayo nag-specify ng particular IP address ang ibig sabihin lang nito is yung ating server application will listen to incoming connections on any of the IP addresses on the computer kung saan sya tatakbo.
5. Ginamit natin yung listen()
method para magsimula na mag-listen for incoming connections.
6. Tapos ginamit natin yung accept()
method para i-accept yung connections when they arrive. Nilagay natin sya sa loob ng isang while loop. Sa while loop na to gumamit tayo ng while True
para continuous lang sya na tumatakbo. We save yung return value ng accept()
method sa variables conn
(para sa connection object) and addr
(para sa address object).
7. Sa loob ng if condition (if conn:
) meron tayo uling while loop which is gumagamit din ng while True
. Ang purpose is to keep receiving data as long as meron.
8. Ginamit natin ang recv()
method para kunin yung data na marereceive natin through the connection. Nag-specify din tayo na pwede lang tayo mag-receive ng 1024 bytes of data at a time. Kung ano man yung mareceive natin, we save it sa data
variable.
9. Kung umabot sa point na wala ng data to receive we break
from the loop.
10. But as long as merong data that is received, ibabalik natin sya sa kung sino mang nag-send satin gamit ang sendall()
method.
11. Finally, we close yung current connection at uulit lang tayo through the loop waiting for new connections to come in.
Please note na para magamit natin yung port 80 sa example na to, kelangan natin ng root user privileges. This is true para sa lahat ng port number below 1024. Pwedeng gumamit ng higher port numbers para hindi na kelangan ng root user privileges.
Ito naman yung ating code para sa client - pangalanan nating client.py.
Explain natin yung iba't ibang parts ng client code na to.
1. Una is yung pag-import ng Python modules. Alam na natin yung socket
module so hindi ko na uulitin dito. Yung sys
module is Python's system module. Itong module na to lets our application interact with our OS habang tumatakbo sya. Sa scenario natin, kelangan natin to para makuha yung argument na ipapasa natin sa ating client.py program. Kapag ni-run natin yung client.py {argument} then makukuha natin kung ano man yung asa {argument} gamit ang sys
module.
2. Makukuha natin yung arguments sa ating program sa pamamagitan ng argv
list. Nag-specify tayo na gusto natin makuha yung laman ng argv[1]
. Yung unang item sa list (argv[0]
) is yung mismong program which in this case is client.py. Kasunod nya at index 1 is yung unang argument pagkatapos ng client.py, kaya natin gusto makuha yung laman ng argv[1]
. Kung sakaling meron pang susunod na mga arguments, mapupunta na sila sa argv[2]
, argv[3]
and so on.
3. Dito sa side ng client we specify yung IP address ng destination kung saan natin gusto mag-connect. Meron tayong dest_host
variable with the IP address nung ating server. As the client, tayo yung mag-initiate ng connection so kelangan natin explicitly i-specify yung information na to para makapag-open ng socket.
4. Maliban sa destination IP address, kelangan din natin yung destination port. Meron tayong dest_port
variable assigned with the value of 80. Ito yung port number kung saan naka-listen yung ating server application.
5. Nag open tayo ng socket para sa ating client gamit ang socket.socket()
. Ito yung eksaktong ginamit din natin with our server pero yung mga sumunod na steps is mas simple. So pag-usapan nalang natin yung mga naiba sa mga susunod na points.
6. Imbis na bind()
and listen()
gaya ng ginawa natin sa ating server, gumamit lang tayo ng connect()
method para sa ating client. Binigay natin yung host and port information nung ating server.
7. Ginamit natin yung sendall()
method para ipadala yung ating message. Yung message natin is nagumpisa muna as a string galing sa ating argument then in-assign natin sa ating message
variable. Bago natin sya ipadala over the network we convert it muna into bytes. Yung conversion na to requires a certain encoding and in this case gumamit lang tayo ng utf-8
encoding.
8. Finally, we receive any message na ibabalik satin ng server and save it sa data
variable then print it.
Kung napansin mo, hindi na tayo nag-specify ng source IP address and source port. Normal lang to kasi by default bahala na ang OS natin sa part na to.
Ito yung mga example ng test run ng code na to.
$ python client.py hello
Server: b'hello'
$ python client.py 'how are you?'
Server: b'how are you?'
Sa example na to makikita natin na binabalik lang ng server yung exact same message na pinadala natin. Kung familiar ka sa command or tool na ping, same concept ito (ping uses ICMP echo messages).
Also, kung mapapansin mo sa 2nd test yung message is asa loob ng quotes. Meron kasi tayong multiple words sa message natin. Kung hindi natin to gagawin, ang mapupunta lang sa argv[1]
is yung part ng message na 'how' so putol sya. By placing yung ating message inside quotes masisigurado natin na lahat ng words will be treated as one argument at makukuha natin yung buong message sa argv[1]
.
Yun na lang muna para sa topic na to and I hope may bago kang natutunan.

by: Jess Primero
@iamzeroslash

by: Jess Primero
@iamzeroslash

Hirap ka pa rin ba sa programming? Tulungan kita you can take my Python tutorial.
How To Install Virtualbox and Vagrant For Your Virtual Lab
Submitted: 09/28/2018
I personally use Virtualbox + Vagrant for my virtual lab. In this post, I’m going to share how to install these two applications. But first, let’s describe what Virtualbox and Vagrant is.
Virtualbox
Virtualbox is a virtualization software. You install it on top of your OS/Operating System (Virtualbox can be installed on Windows/Mac/Linux). From there, you can install other Operating Systems on a virtual machine created through Virtualbox. You will essentially be running an OS on top of your existing OS.
This is how virtualization works, but to be specific, this is how virtualization using a Type 2 Hypervisor works (a Type 2 Hypervisor like Virtualbox runs on top of an existing OS while Type 1 runs directly on top of hardware). Your existing OS will be the host OS and the one running on top of it will be the guest OS. You can create as many virtual machines and install as many guest OS as you want as long as your computer resources can handle it.
Vagrant
Vagrant is a tool that you can use to build and manage virtual machine environments. It can help you provision virtual machines in Virtualbox without ever touching Virtualbox (Virtualbox needs to be running of course).
Vagrant supports other virtualization software such as VMware and Hyper-V. These are all called providers in Vagrant terms.
Vagrant gives you a single workflow to deal with when you set up your virtual environment. You use a single configuration file to define all your virtual machines. You can bring them up, restart or delete them all from Vagrant.
You can also use provisioning tools to automate the installation of any required software or initial configuration for the guest OS after they are brought up. This helps you achieve a consistent and repeatable environment that you can deploy anywhere. For example, using a Vagrant configuration file you can spin up your virtual environment again and again, even if you move it to a different computer.
That’s it for our Virtualbox and Vagrant primer. Let’s now proceed to how we can install them.
Step 1. First, let’s download Virtualbox as it will be our prerequisite before we can use Vagrant. Go to the Virtualbox downloads page here. Choose the download option based on the Operating System you are using right now. At the time of this writing, the current Virtualbox version is 5.2.18.

Step 2. After your download is finished then install Virtualbox. It’s usually a typical wizard-based install (except with Linux) so it should be straightforward and easy. Just keep on clicking next until it’s finished. Try to launch Virtualbox after the installation to test if it has been properly installed.
Step 3. Then let’s download Vagrant. Go to the Vagrant downloads page here. Again, choose the download option based on the Operating System you are using right now. At the time of this writing, the current Vagrant version is 2.1.5.

Step 4. After your download is finished then install Vagrant. It’s also usually a typical wizard-based install (except with Linux) so it should be straightforward and easy.
Now that everything is installed, let’s try to launch our first virtual machine through Vagrant.
Step 5. Create a folder where we will place our Vagrant configuration file. Basically, this is where our little virtual environment project will live. Name it whatever you want, it could be anything, it’s just a simple folder. In my case, I’ll be naming it virtual-lab.
NOTE: I'm on a Mac OS X using the terminal so I'm using the commands such as mkdir
(applicable to Linux/Unix type Operating Systems). If you are on Windows or using the GUI then create a folder in the same way you normally do. The important thing is we have a folder that will contain our Vagrant configuration file.
$ mkdir virtual-lab
Step 6. On the command line change your directory into your newly created folder using
cd <path-to-your-folder>
so we can initialize a Vagrant file.
$ cd virtual-lab
NOTE: You may have to provide path-to-your-folder
as a full path (ex. /Documents/myfolder
) depending on your current directory in the command line.
Once you're in the folder you created, you can now initialize the Vagrant file. In this example we're going to use an Ubuntu virtual machine.
$ vagrant init ubuntu/xenial64
The vagrant init
command creates a Vagrant file in your current folder (the name of the file created is Vagrantfile). This Vagrant file contains your Vagrant configuration. Vagrant files contain information about your virtual machine/s and you declare other specific details and provisioning steps that you would want for your virtual machines. For now, our Vagrant file is simple and we will keep it as it is.
The ubuntu/xenial64
in the command tells vagrant to create the Vagrant file with the ubuntu/xenial64
Vagrant box. Think of it as a premade virtual machine which we could just easily download to our computer. It’s ready to use and all we need to do is launch it from Vagrant.
NOTE: The ubuntu/xenial64 vagrant box is the official vagrant box release for Ubuntu Linux 16.04 LTS (named Xenial Xerus).
You can view the contents of the newly created Vagrant file and you should see a bunch of stuff (mostly comments at this point) but the most important parts would be the lines the same as below.
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/xenial64”
end
Step 7. Run
vagrant up
to launch the virtual environment. Since this is the first time you’ll be using the ubuntu/xenial64 vagrant box it will first download it from vagrantcloud and once done it will immediately bring up the box.
$ vagrant up
NOTE: This step may take some time depending on your Internet connection.
Step 8. Once the box is up you can now login to it using
vagrant ssh
.
$ vagrant ssh
You should now be logged in and your prompt will look similar to this.
vagrant@ubuntu-xenial:~$
Use the exit
command to exit out of Ubuntu Linux.
vagrant@ubuntu-xenial:~$ exit
Managing virtual machines using Vagrant
You can check the status of the virtual machine using vagrant status
.
$ vagrant status
Current machine states:
default running (virtualbox)
You can reload the virtual machine using vagrant reload
.
$ vagrant reload
You can shut down the virtual machine using vagrant halt.
$ vagrant halt
Finally you can delete the virtual machine using vagrant destroy
.
$ vagrant destroy
That’s it! You have successfully installed and tested Virtualbox + Vagrant. From this point you should be able to play around and test out other Vagrant boxes. I've included another example in the next section so you can try more of Vagrant.
Keep practicing
To get more used to using vagrant, here's another example for Centos 7 Linux. Create another folder and perform the same steps as we did above.
$ vagrant init centos/7
$ vagrant up
Technically you can just create a file named Vagrantfile as long as it is inside your intended folder and edit it to have the contents as below.
Vagrant.configure("2") do |config|
config.vm.box = "centos/7"
end
The config.vm.box
line defines which vagrant box you'll be using. As you can see it's using the same vagrant box name "centos/7" as we did in the vagrant init
command.
Go ahead and try out any of the other Vagrant commands to manage your virtual machine.
vagrant status
vagrant reload
vagrant halt
vagrant destroy
Now that you've seen how Vagrant makes setting up and managing your virtual lab easy, I highly recommend continuing to explore. To look for other Vagrant box options available, you can check it out here.
You can also check out this resource for building a Python + Juniper Network Automation lab using Vagrant.

by: Jess Primero
@iamzeroslash
How Python is Solving The Real Problem of Network Engineers
Submitted: 06/12/2020

In Network Automation, although there are already some good abstractions in place (thanks to the work done by Python Network Automation libraries), it is still important to understand the underlying interactions with the network devices. Let's discuss why this is important.
Different types of Network OS
First of all, it is quite normal to be dealing with different types of Network OS.
Cisco alone has a bunch of them.
IOS
NX-OS
IOS-XE
IOS-XR
Other vendors normally just have one main Network OS.
Junos (Juniper)
EOS (Arista)
SR OS (Nokia - formerly Alcatel-Lucent)
VRP (Huawei)
That's just to name a few.
With our traditional experience of configuring them through the CLI, we know that dealing with different types of Network OS also means dealing with different types of behaviors. Each have their own style of configuration, plus their own supported configuration features.
As an example, some Network OS has a candidate configuration datastore, others do not. Some have atomic changes, some do not. Also, there can be considerations with their respective behaviors with config replace, or merge. All these things can come into play with how you build your Automation System.
NOTE: A candidate configuration datastore is what is used with certain Network OS that supports transactions for configuration changes. If you've encountered one where you have to perform a commit for your changes to take effect, then it's most likely using a candidate configuration datastore (ex. Juniper Junos).
Consider the situation wherein you are managing Cisco (IOS-XR), Juniper and Arista devices. They may have similarities, but they are also very different from each other.
Different types of interaction
On top of that, each may also offer different types of interactions. A CLI is standard, but not all vendors have an API which you can use to remotely interact with the network device. Among those which have an API, the options may also vary.
So even though we are making use of Network Automation libraries, we still need to understand what type of interaction is being used. As an example, NETCONF is totally different from HTTP-based APIs. And within HTTP-based APIs, there are RESTful and non-RESTful.
Each vendor API will have their own set of supported operations. If that's not enough, it's also possible that there's a discrepancy between what you can do in the CLI vs what you can do using the API. This means that not everything you can do in the CLI can be done using the API, and vice versa.
The important thing is to take some time to understand the types of interactions that you'll support (ex. different types of APIs), and the specific configuration management features of your supported Network OS (ex. commit, rollback). These things impact what can and cannot be done for each type of Network OS.
It is not an easy task. With that said, we still have a long way to go as the industry develops more standards. Let's now discuss the considerations as we move forward with Network Automation.
Things to watch out for
When solving a problem, be careful not to create another problem.
Being multi-vendor is becoming relatively easier with the rise of automation due to better abstractions. However, what we gain with faster and more efficient operations of the network can move the problem somewhere else - Software Development.
Remember, we still have various types of Network OS. Too many supported vendors can have a significant impact on the number of considerations during development.
To give you an idea on certain nuances you might encounter, you may intend to deploy a standard setup across different vendors. But the supposedely standard configuration X may be configured a little bit different on vendor A from vendor B. Data inputs can be different, business logic can be different, the list goes on.
I've just described a basic example, but there are more of these type of things that happens throughout development. It's an example of the saying "The devil is in the detail". When you look at the requirements it may look simple, but working through the implementation reveals that it will take more time and effort than you expected. Seemingly little things like this can greatly increase the amount of resources that needs to be invested in a project.
In my experience, 3 vendors is quite manageable. I can probably accept a 4th one but I'll start to think carefully about the maintainability of the code. Anything more than that can really increase the complexity.
I do acknowledge that as Network Automation software matures, as well as advancements in configuration management, we might reach a point wherein it doesn't really matter which networking vendor we use (i.e. just plug and play).
Standardizing of vendor-neutral configuration is in active development. But until then, we'll just have to work with the best of what we have right now. So far, Python has been a big game changer. Thanks to its beginner-friendly syntax, it's more approachable for Network Engineers. This has helped Python gain a lot of traction in the Network Engineering community.
How we are moving forward
Today, Python has been the language of choice for most of the Network Automation related libraries. Because of this, Python is increasingly becoming an important tool in a Network Engineer's arsenal. Yes, not everyone likes programming, but Python is quite a good middle ground - "I can code, but I'm not a developer". So it's still worth a try, especially if it will help you get work done faster (and get work done while you sleep).
Nonetheless, Python has proven to get the job done. There's always a lot of Hype in the world of Networking. New buzz words are invented all the time. But you know what happened all these years? It turns out all we really needed was a way to keep up with all the work in Network Management.
Because the old way doesn't work anymore. We need more automation. This is exactly what happened with managing Servers when virtualization and cloud exploded. Before we only know that we have System Administrators. Today we have DevOps and SRE.
Managing networks is going through the same phase and we're seeing the same SysAdmin practices being adopted into our world. Python has already been heavily used by SysAdmins for a long time and now it's taking over in Networking by being a powerful tool for Network Engineers.

by: Jess Primero
@iamzeroslash