It has been almost exactly six months since my last post. What have I been up to? As you can imagine, a lot can happen within six months of time. For most of the year, I have been involved in some paid writing engagements (in fact, I’ve written about 40,000 words this year!). I’ll admit, this has taken quite a lot of my time and made me less interested in creating content for this site.
Facebook announced their homegrown Open/R routing protocol a few years ago and eventually used the open-source software model to make it available to the general public. As a distributed network application, Open/R shares many fundamentals with traditional Dijkstra-based link-state routing protocols like IS-IS and OSPF. Upon announcement, there was much skepticism across the industry as to the need for yet another routing protocol. This article does not attempt to examine the positives or negatives of running a new routing protocol.
NAT can be a very confusing topic. In the real world, NAT is most frequently performed on firewalls and load balancers, but the Cisco Routing & Switching curriculum has you configure NAT on routers. It is easy to get confused by the addressing terminology and everyone explains it a little differently. NAT44 (translating one IPv4 address to another) is a part of the CCIE RSv5 lab exam and my lack of preparedness for this topic was part of my downfall for my first lab attempt in 2018.
VeloCloud has an API available to perform different actions including pushing configurations and reading back status information. Unfortunately, a lot of the API access functions are limited to end customers. However, any information you can obtain through the usual VeloCloud Orchestrator web interface, you can retrieve programmatically. I will explain how to do this using Python 3. I have a very specific issue with my VeloCloud deployment in that when using cable circuits from Comcast, the modem hands out a 10.
In this post I detail my experiences as a network engineer deploying SD-WAN from the point of view of an enterprise customer of a Managed Services Provider (MSP). My company is dispersed across approximately 400 sites with multiple datacenters. I am fortunate enough to be in a position where my technical expertise and operational experience play a large role in helping shape the direction of network connectivity across the entire company.
Recently, I was lucky enough to attend Networking Field Day 19 where I saw many different presentations. One of the presentations I witnessed made me think about some of the operational aspects of managing a large-scale network, and I found the ideas presented by Apstra to be very interesting. Apstra’s AOS is built around the concept of Intent-Based Networking (IBN). While this has become somewhat of a marketing term in the industry, the concept itself is founded in the idea that you express the desired networking outcome, and not how it shall be done.
I found the CCNA Industrial certification to be interesting because like the Cisco Network Design certifications (CCDA/CCDP/CCDE), this single certification has quite an overlap of other certifications and technologies. Basic network design, security, wireless, and troubleshooting are added to the industrial networking protocols covered (CIP over EtherNet/IP and PROFINET). I found the exam to be fairly easy, but once again that is due to my accumulated knowledge and experience, where many of the questions and answers just seemed like common sense.
This post covers how to join together devices requiring multicast connectivity across networks that do not support multicast. This situation is common when the Internet is used for transport, and even in private networks such as MPLS L3VPN if the carrier does not support multicast (or you decided not to pay extra for that service). I will be using Cisco devices and GRE tunnels, though the concepts are generic and apply to multi-vendor networks.
In this lab, I cover automating the setup for a simple 3-customer VPLS L2VPN. I detail the basic configuration components, as well as automating the deployment to alleviate repetitive configuration commands. Like many technologies, it is best to start simple to build a foundation of knowledge before moving on to a more advanced depth. This lab is meant to be an introduction to multipoint L2VPN using MPLS, and more advanced options are not covered in this post.
Or the CCNP Jr., as I’ve come to call it. Studying for this exam provides a nice overview of various service provider technologies and general architecture, as well as a glimpse into Cisco’s service provider portfolio, including the IOS-XR operating system. This certification consists of two separate exams (SPNGN1 and SPNGN2), with no prerequisites. Several of Cisco’s CCNA-level tracks require the ICND1/CCENT certification first, but the CCNA Service Provider certification does not.
This posts walks through how to create an isolated network which has access to the IPv6 Internet via 6RD using Ubiquiti EdgeMax equipment and a router running DD-WRT. 6RD (Rapid Deployment) is a method to reach the IPv6 Internet by tunneling over an IPv4 network, similar to 6to4. While 6to4 is primarily used to connect different “IPv6 islands” together, 6RD was designed to allow a service provider connected to the IPv6 Internet in its core network to provide IPv6 services in the access layer based on its own registered IPv6 public address space without deploying native dual- stack (simultaneous IPv4 and IPv6 connectivity).
Wait, wasn’t I just studying for the CCIE? After my lab attempt, I decided it was important to branch out a little bit and develop a more T-shaped skillset. I came from a generalist background (read jack-of-all-trades), then specialized in expert-level routing & switching which serves as a great foundation for other networking and infrastructure-related skills. Passing the CCNA Wireless is one of a few moves I’ve decided to make to ensure my realm of knowledge is not too narrow.
I am breaking out of the Cisco wheelhouse a little bit by using MikroTik RouterOS to build on my previous work of automating a base-level lab configuration. Working with another network operating system that uses a completely different syntax allows you to learn the various protocols in a more meaningful way (in my opinion). When you configure a single vendor’s equipment, it is easy to get in the habit of pushing out configurations without taking the time to understand the meaning behind the commands.
DR plans encompass everything from no plan whatsoever (failing to plan is planning to fail), to active/active workloads distributed among several geo- redundant datacenters. This spectrum, just like nearly everything else in business, goes from zero to enormous cost and complexity. In the interest of keeping things simple, I designed a relatively inexpensive and uncomplicated enterprise DR plan that can be adapted and scaled with organizational requirements. The initial design starts with two datacenters (or campuses, or a couple boxes in a rented colo cage, whatever your situation may be).
This is the unabridged version. The abridged version is available on LinkedIn. From the Written… I passed the CCIE Routing & Switching v5.1 written exam in August 2017. It was a huge moment for me, and felt like a great validation of the effort I had put in to reach that point. Around the same time, my work had some Cisco Learning Credits that were about to expire, and they let me use them to purchase the full self- paced Cisco Expert Level Training (CELT, formerly 360) package, which included 25 workbook labs and 15 graded labs.
I am replacing an old Cisco 3945 router with a new ASR-1001X. The 3945, which has three gigabit Ethernet interfaces, has one connection to two service providers, and a single tagged link back to the network core carrying the traffic of a few different IP subnets. The ASR-1001X has six gigabit Ethernet interfaces, so when replacing the 3945 I wanted to introduce some redundancy into the network by utilizing two physical links back to the core, with each link going to a separate physical switch.
The automation described in my last post had a couple of glaring flaws. I quickly discovered the inflexibility of using a CSV file for the data source as I started to add more variables to each device. The second flaw was that for approximately 30 devices, it took about 20 minutes to generate and push the device configurations, because each device was processed serially. I solved the first issue by using a YAML file for the data source.
Following up on my last post, I have set out to start automating certain aspects of my labs. I spent a few days going over the material from Kirk Byers‘ highly-recommend Python for Network Engineers course. I studied on the previous version of his course a couple of years ago (covering Python2), but this new version, which covers Python3, is even better. I came up with a generic topology that was purposely over-engineered so that I can enable and disable links on-demand to create different logical topologies without having to interact with the physical lab topology.
I have been wanting to get a little deeper into some various technologies surrounding MPLS and BGP-based VPNs (beyond basic L3VPN, such L2VPN, QoS, multicast, EVPN, etc.), so I assembled a virtual lab with approximately 30 routers which represent a service provider core and several “customer” sites, along with two sources of fake Internet connectivity (or more accurately, a simulated Default-Free Zone (DFZ)). After I earn a deeper understanding of topics within a single service provider core, I will expand this to inter- provider topics.
I created a mindmap of topics that are covered on the current Cisco CCIE RSv5 lab exam to help myself study, and I thought my work might be useful to the general network community as well. I included CCNP R&S in the title, because there’s a lot of overlapping information that I think most people pursuing the CCNP might find useful as well. I have covered a lot of topics by way of configuration examples that I remember struggling with a little bit when I was studying for the CCNP (wow, it’s been five years already!
Today I have decided to finally release the flashcard deck that I created for myself in order to pass the written portion of the CCIE Routing & Switching v5.1 exam. This deck represents many months and hundreds (if not thousands) of hours of study effort. After passing the exam, I had considered putting together some kind of study package, but I recently started thinking about how version six of the CCIE R&S is going to be here before too long, and it serves no purpose for me to sit on this accumulated knowledge and not share it.
This is a big step for me, and has been a long time coming. I know I haven’t “won” anything yet (I’m not going to be one of those people who put “CCIE written” on my resumé), but at the same time, passing this exam is a major milestone for me. The topic scope for the CCIE written exam is quite vast. There are 100 questions on the exam, which means the single exam cannot cover all of the topics.
Last year, I was not yet ready to take the CCIE R&S written exam, but my CCNP was about to expire. I decided to renew by taking the SWITCH exam, which had been revised since my original CCNP certification. I continued to study for the CCIE, but I focused my attention on topics that were on the SWITCH exam. As I was doing this, I was still in the middle of transitioning my learning process to using Anki, and therefore I was still taking traditional notes.
For most knowledge-intensive fields of work, including network engineering, you must learn how to manage vast amounts of information if you wish to progress into more advanced levels. The first two articles in this series discuss creating and reviewing flash cards, which through spaced repetitions lead to dramatically increased knowledge retention. But what about static knowledge at-rest? Knowledge Management: Just twenty years ago, resting knowledge would typically consist of multiple shelves of books, and several binders full of notes.
This part covers what I have learned about reviewing the flash cards. Flash Card Review: The premise of Anki] (and related types of software) is spaced repetitions. To get the most out of the software, you need to make yourself get in the habit of reviewing your cards every single day. When you stop reviewing, you very quickly start to lose retention. However, by maintaining the habit of reviewing cards every day, you will spend less time each day reviewing because the retained cards will be spaced further apart.
This is part one of a three-part series. I still study for the CCIE R&S. I study for it in some form (and often multiple forms) every single day. My attitude, thought processes, and learning process has changed quite significantly in the last year and a half. My experience is growing, and timelines are starting to become more concrete. I’ve written about this before, but this past year really has been life-changing with regard to my study habits, “learning how to learn”, and discovering what works best for me to take in, manage, and retain information.
Oxidized is an open-source project started by Saku Ytti and Samer Abdel-Hafez as an alternative to the very popular RANCID software. A little over a year ago, I created a RANCID server to backup the configuration of my network devices. It has been a good, stable piece of software that has been doing the job very well across hundreds of devices. When I set up the RANCID server, I had heard of Oxidized, but the project wasn’t yet as far along as it is now.
I have been involved with both wired and wireless networking for many years. My original wireless setups were from the early 2000s, shortly after 802.11b became popular. I remember at one point I had a PCMCIA card with a pigtail and external antenna attached to it. As my career started taking a focus more toward networking, I became intimately familiar with just about every aspect of wired networking. Having worked with wireless for so long, I knew a decent amount about how the technology works, but not nearly to the level of familiarity I have with Ethernet.
Having fundamental knowledge of what affects TCP, UDP, and IP itself helps you to better troubleshoot the network when things go wrong. I feel like most of the lower-level network-oriented certifications barely touch on these topics, if at all. However, the current Cisco CCNP and CCIE Routing & Switching exams do expect you to know this. This post is geared toward Cisco’s implementation and defaults regarding the various topics. However, whether you are studying for a certification or not, this is all good information to have.
Quality of Service is an added-value network infrastructure service that is still very important within the scope of private networks. Some might argue that QoS is not as important as it once was as we start to see more SD-WAN deployments that utilize the general Internet for transport, because the Internet has no inherent QoS. Additionally, many private networks do not utilize QoS whatsoever, and their operators essentially just “hope for the best” as all the different types of traffic traverse the various links.
Sometimes in life, the best experience comes from being in the right place at the right time. I studied enterprise networking for years while being employed in the SMB space. My short time with the Flagler County school system was my first enterprise-level job, but my role at my present company as network engineer has really been the start of my journey of “real” enterprise-level experience. In such a comparatively short period of time of being employed here, I have gained immense experience that I know will serve me well for the rest of my career.
This post was also featured on PacketPushers.net Until now, I was never one to use flashcards. I could not see their value, and I was too lazy to actually write things down on a paper flashcard (and my handwriting is horrible). I recently discovered a program called Anki. On the surface, it is just a flash card program, but underneath, it can be as simple or as complex as you desire.
The original Mac Pro is a 64-bit workstation-class computer that was designed with the unfortunate limitation of a 32-bit EFI. The two models this post discusses are the original 2006 Mac Pro 1,1 and the 2007 Mac Pro 2,1 revision. Both systems are architecturally similar, but the 2006 model features two dual-core CPUs, while the 2007 model has two quad-core CPUs, both based on the server versions of Intel Core 2 chips.
It’s true, I did start this blog in October 2012. In June 2018, I made the decision to prune all of my entries before December 2015. I spent a couple of hours reading over the majority of these entries and realized they are no longer relevant to my life and current career trajectory. When I started this blog, I was just entering into the vast world of network engineering. I was not yet working in an environment that could take advantage of the new skills I was developing.