Unless otherwise specified, I think it is easy to go into a routing scenario or situation assuming that the traffic flows are unicast. What do I mean by this? Unicast traffic flows are what I will call the “typical” end user type communications in a network. One device needs to talk to another device. The source IP is the address of the originating host and destination IP is the address of the “far end” device (for example, server). Let’s give an example of a unicast traffic flow. A person opens up a web browser and types http://www.bogusexamplewebsite.com (I don’t know if this is real or not, this is just an example) into the address bar. As we flow down the stack (or OSI model) from Layer 7 (Application Layer), in order for the packets to be delivered, a destination IP address needs to be known. In this case, DNS will be leveraged to translate the website name into an IP address. Once that process is complete, we now have our unicast conversation, one source IP address to one destination IP address. This is a basic unicast conversation on a network. This seems fairly straightforward, this must be the way that all conversations should happen on a network, right? Well, not always.

Let’s bring another example in. Let’s say that an organization has a need to deliver real-time, streaming video to employees for “daily check-in” meetings. A server gets set up for this, and every day at 9:00 AM, live video is streamed to the organization, and employees can use an application on their devices to “tune in” to this stream if they wish. This could get out of hand in a hurry if we had to leverage unicast for this method of streaming video delivery. If unicast was used, there would be a separate session for every client from the server that requested the stream. This does not scale well as it could heavily consume computing resources on the server and bandwidth on the network. See the example diagram below that gives a visual for how this stream would look if unicast was leveraged for packet delivery.

In the image above, there are four total workstations in the network that request the video stream. With unicast, the video server receives four different requests and sends the same stream four different times. This method can be resource intensive and may not scale well in large environments. Thankfully, another option exists. When leveraging multicast, we can have a streaming traffic flow that looks more like this image below.

While unicast gives us a “one-to-one” packet delivery mechanism, multicast is leveraged to support “one-to-many” use cases. The case of the “daily check-in” meetings is definitely a scenario in which a one-to-many delivery mechanism makes sense. Well, this sounds great, let’s just “turn it on” and walk away, right!? As with most things, there is more to it than that. First off, what are the requirements to support multicast?

• The end user applications must be programmed to request data from a multicast group address.
• The server application must be programmed to send data to a multicast group.
• The network must configured to support multicast routing.

In the requirements listed above, I made reference to a multicast group address. A multicast sender (server) sends data to a multicast group address instead of individual client unicast IP addresses. Multicast receivers (end user applications) “subscribe” to a multicast group and request to receive data that is sent to that multicast group address from the multicast sender. The routers in between facilitate the multicast registration and packet delivery. Multicast addresses live in the Class D IP space of 224.0.0.0/4, which gives a range of addresses from 224.0.0.0 to 239.255.255.255. Within the Class D space, different ranges are specified for different purposes of multicast.

Conclusion

Multicast provides us the ability for more efficient packet delivery for certain use cases. These use cases include applications that provide a “one-to-many” functionality. An example use case is a server delivering streaming video to clients. When applications support multicast, and someone opens the app to request a stream, in modern multicast deployments, the application “subscribes” to a multicast group, which registers the device to it’s local router saying “Hey, please send me traffic destined to multicast IP address X.X.X.X”. The local router then registers itself to upstream routers requesting subscription to receive multicast packets to that specified multicast group. Then, as the stream is sent to that multicast group address, it is forwarded down the multicast distribution tree (MDT) to routers that have registered. Those routers keep track of the downstream interfaces from which the multicast requests were generated, and continue forwarding the packets to their destination. There is more to come, as there is a lot to unpack with multicast! Please join me in future posts.

The title of this post really says it all. I want to become a more automation/programmability minded person and to kick off this journey, I decided to start by getting a familiar with Python. As time permits I am going through Al Sweigart’s “Automate the Boring Stuff with Python” book and Udemy course, and plan to document here what I learn along way. I have started learning the very basic programming concepts and am starting to get familiar with the Python shell and basic syntax. Traditionally, I’ve definitely been a “slow and steady wins the race” kind of guy. I like to take my time and try not to get overwhelmed. Luckily for me, Al’s book and course seems to cater to that. You’re going to have to bear with me during these posts, I’m really starting from square one here. I’m hoping that seeing my documented struggles and hopeful eventual successes might help others along the way. In the rest of this post, I want to go over my explanation/take on the basic terminology that I have learned. And yes, even though this isn’t geared toward exam study, I am making Anki flashcards. Going through these cards is really helping me soak up and retain the new concepts that I’m learning. Here are some concepts that I’m learning in question/answer form.

• What is Python? Python is a combination of a programming language along with an interpreter that reads and takes action on the code written in the Python language.
• What are expressions? Expressions take multiple values and evaluate them down to a single value. A basic example is 2 + 1 = 3. This expression leverages a “+” operator to evaluate the two values of “2” and “1” down to a single value of “3”.
• What is a data type? We can think of a data type as a category or classification of a value. A specific value can only belong to one data type. Three common data types in Python are:
  • integers – Whole numbers.
  • floating point numbers – Numbers with decimal points such as 17.2, 9.7, 256.3.
  • strings – Data type that leverages alphanumeric characters.
• What is a variable? A variable is memory allocation in a program used to store a value. The variable can then be called to use later in the program. Al explained variables in a way that I really like. A variable can be thought of as a labeled box that is used to store something. In a program that “something” can be set statically or dynamically. For example, a variable could be set as a result of someone typing some input into the program in a certain spot.
• What is an assignment statement? This is how value gets assigned (or stored) to a variable. An example is age = 23. In this assignment statement, a variable is created named age and is assigned an integer value of 23. In the assignment statement the = sign acts as the assignment operator. Variables contain one value at a time. So, after we set age to 23, if we then type age = 42 the value of 23 has now been overwritten by the value of 42 in the age variable.
• What is # used for? The # symbol is used in Python to write comments in your code. Essentially, anything typed on a line after the # is ignored by the Python interpreter when the code is run. Here are a couple of use cases for “commenting out” Python code.
  • For documentation purposes to explain what your code is trying to accomplish.
  • For debugging purposes to “disable” certain lines of code to see if they are causing issues.
• What is a function? A function is an “external” set of code that your program can call upon to run within your code. Functions are already built/established programs for you to use within your code. Built-in Python functions include print() and input().
• What is an argument? In the point directly above, I explained at a high level what a function is along with its purpose. Well, an argument is a value that is passed to a function. Let’s take a look at a simple example with the print() function.

>>> print('Hi, I am Tim and I am a complete Python/coding beginner. Please Help!')
Hi, I am Tim and I am a complete Python/coding beginner. Please Help!

In the example above, I am passing the string value of ‘Hi, I am Tim and I am a complete Python/coding beginner. Please Help!’ That string value is an argument within the print() function. In other words, it is the value being passed to the function.

Summary

As you can tell, I’m learning the basics of the basics here. Also, I’m going through this on a “as time permits” basis, which probably isn’t the best approach, but building and reviewing the digital flashcards is helping retain the knowledge, at least around the terminology, which is good. If you are learning Python as you’re reading this, then I hope this helps.

It’s time. Time that I make a conscious effort to start learning concepts and leveraging tools to dive into network automation. I have heard a lot of advice for a while now that a great way to become a better network engineer is to automate repetitive tasks so that you can spend time providing value elsewhere. The concept of providing value is important to me. Whenever I struggle with thoughts around not knowing where to start, I figuratively step back and tell myself to just find where you can use your skills (and build new skills) to provide value. I also want to position myself to continue to remain relevant, and learning automation seems like a great way to go.

As you can probably gather from the title, I’ve been down this road before. I’ve dabbled for a bit and dropped it, but now is time to break the cycle. I am currently working toward achieving the CCNP Enterprise certification and do not plan on taking time away from that goal to study automation. As much as I would love to dive into Cisco DevNet and eventually work toward the DevNet Associate Certification, I do not plan to start that yet. While I work toward CCNP Enterprise, I would like to start my automation journey and find some quick wins. I feel (it might be ‘right’ and it might be ‘wrong’) that I can do that by getting familiar with Python. I have decided to start with going through Al Sweigart’s “Automate the Boring Stuff with Python” book and Udemy course. I am really excited to dig in. I plan to build upon this series and really hope that I can look back on this first post sometime in the future and be proud of my progress. I also encourage you to learn along with me. Or better yet, TEACH ME EVERYTHING YOU KNOW!

In the last installment of this series, I keyed in on the STP feature of PortFast. In this post, I wanted to highlight two more STP features, or “add-ons”, that I think are very important for controlling and securing the Layer 2 domains. Those two features are BPDU guard and root guard. Both features are leveraged to react to Spanning Tree BPDUs in similar ways, but in different scenarios, and for different reasons.

First, BPDU guard is leveraged on access ports configured with PortFast. BPDU guard prevents switches from being plugged into access ports and potentially causing Layer 2 loops. Remember, PortFast allows interfaces to immediately transition to the forwarding state, which is dangerous if switches are being plugged in. When BPDU guard is enabled on PortFast interfaces, if a BPDU is received on the port, the port will be placed into an err-disabled state (effectively shut down). BPDU guard can be configured either globally on all PortFast enabled interfaces, or explicitly on specific interfaces with the following commands.

• Global
  • configure terminal
  • spanning-tree portfast bpduguard default
• Interface Specific
  • configure terminal
  • interface interface-id
  • spanning-tree bpduguard enable

Next, root guard is a mechanism to prevent switches that should not become the root bridge, from becoming the root bridge. STP root guard is configured on designated ports that connect to downstream switches that should never become the root bridge. If a superior BPDU is received on a port configured with root guard, rather than the designated port transitioning to become a root port, the port is placed into an err-disabled state to protect the current root bridge and to prevent a topology change from occurring. Well designed Layer 2 topologies should have defined primary and secondary root bridges, and leverage root guard if necessary to protect against unnecessary topology changes due to misconfigured or rogue switches. Root guard can be enabled on STP designated ports with the following commands.

• configure terminal
• interface interface-id
• spanning-tree guard root

I have enjoyed gaining a deeper knowledge of STP, including the additional features. I see BPDU guard and root guard as protection mechanisms that help promote a stable topology and assist in the prevention of unnecessary or unwanted topology changes.

• Podcast: ZigBits Network Design Podcast
• Episode: 70 – Demystifying the Role of the Network Engineer with Ethan Banks

For a while now on the podcast, Zig has been doing a series of “Demystifying the Role of the Network Engineer” episodes with various guests. In this episode, Zig sits down with Ethan Banks to get his take on the role of the network engineer. This was a fun one for me because I’ve been a Packet Pushers fan for a little while now and really enjoy Ethan’s perspective. I took some notes while listening to this episode, so I am going to list out some paraphrased key topics that were said during the episode, and give my thoughts/interpretations inline.

• A network engineer is a builder.
  • In an organization, the network engineer is the individual (or individuals) that actually build and implement the network infrastructure.
  • Depending on size and structure, the engineer will take and interpret a design from a network architect, develop a design of their own, or work with a contractor for the design process.
• When seeking help or mentorship, do your homework first.
  • Unless there is an outage/emergency, you aren’t really doing yourself any favors by seeking help from others without trying to do some research of your own. This will help you learn and build confidence in your own abilities.
  • Mentors and more experienced individuals will probably be more willing to help someone that has proven that they are serious about learning something.
• Build trust, don’t just try to be the smartest person in the room.
  • If you are lucky enough to be a member of a team, do what you can to make the team stronger, rather than just make yourself look good.
  • You are one person, we are stronger together.
  • Working with different team members brings different perspectives. You never know when someone else might catch or see something that you did not.
• Repetition and practice is not always easy to accomplish, so proper documentation is vital.
  • There may be certain technologies or skill sets that we do not get to tap into on a daily basis. Having good documentation or at least knowing where to obtain good documentation is important.
• Do not lose sight of the business, speak the language.
  • I think that it’s an easy trap to fall in (I’m guilty, myself), of thinking that “Well, I’m in IT, I just do ‘IT things’ and do not need to understand the core business purpose and principles”. We are more than just IT workers. We are contributors for a business toward business goals. It can be difficult to provide value to a business if you do not understand the whats/whys/hows of the company.
• Communicate effectively.
  • I am a firm believer in communicating clearly and often to customers, team members, and management. Not only so that people do not have to wonder about the status of certain things, but I feel that it is a way of showing that you care about what you do and the task at hand. If I can provide information or an update before someone has to ask, then I feel that I am communicating at least decently.
• Have the ability and drive to learn.
  • Network engineers and other IT contributors work in ever-changing environments. We need to have the ability, desire, and drive to continuously learn, adapt, and grow.
• Ethan still loves networking.

I love hearing people’s stories, experiences, and advice. Listening to these two incredibly experienced and intelligent individuals provided just that. This was a great discussion with a lot of solid advice for network engineers and I definitely recommend giving it a listen.

I have been going through Spanning-Tree Protocol study for the last week or so and wanted to highlight a key part of the portfast feature that had not really hit me (and stuck) until now. I’ve known that a big reason and benefit of the portfast feature is to move interfaces (typically access ports) to the forwarding state immediately. However, another big reason and benefit that I’ll say I didn’t realize or remember, but is just as important in my opinion, is the suppression of topology change notification (TCN) BPDUs for interfaces with the portfast enabled.

By default, switches will create and send a TCN BPDU toward the root bridge when they detect a topology change (for example and interface going to a down state). Upon receipt of the TCN BPDU, the root bridge will create a configuration BPDU with the topology change flag set, and flood it to all other switches in the topology. When the non-root bridges receive a configuration BPDU with the topology change flag set, they need to change the MAC address age time to the STP forward delay time and flush out all MAC addresses older than that time period. This is done to prevent frames from being forwarded out interfaces to MAC addresses that may no longer exist out that port anymore. By default, this process could happen very often due to end devices potentially connecting and disconnecting frequently. That could cause a lot of churn and inefficiency in the Layer 2 topology. If portfast is enabled on all access ports connecting to individual end hosts, this TCN behavior is suppressed and only leveraged on non-portfast interfaces (switch to switch connections). To me, this seems very important.

STP portfast can be enabled on individual interfaces or globally on all access ports.

• Interface configuration
  • interface interface-id
    • switchport mode access
    • spanning-tree portfast
• Global configuration
  • spanning-tree portfast default

I’m not particularly proud of this, but I actually began this ENCOR journey at the end of 2019/beginning of 2020. I spent a lot of time studying throughout 2020, and I won’t call that time wasted by any means, but where I feel I failed is I did not have a proper plan for absorbing and reviewing content. I would go through multiple content sources for each topic, but did not have a review process to go back and keep the knowledge “fresh”. One thing I was proud of in 2020 was that I spent a decent about of time with lab practice of different concepts. All of this being said, something had to change, and I needed a “real” plan. One tool that I have been really excited about (thanks to @artofneteng for the advice) is the digital flashcard concept with Anki. I have incorporated flashcards into most of the steps in my plan. Here is the current plan I’m working through for each topic or grouping of topics.

1. OCG chapter (creating flashcards along the way).
2. OCG chapter key topic review.
3. OCG key terms (create flashcards).
4. OCG command reference (create flashcards).
5. Cisco On-demand learning (creating flashcards along the way).
6. CBT Nuggets (creating flashcards along the way).
7. Labs as necessary.
8. Flashcard review.

As far as flashcard content, from the sources I’m leveraging, I create cards for quiz questions, key topics, key terms, and anything else that I deem necessary. One thing that I have found myself doing, is starting each study session by going through flashcards. A benefit I see to this is that I don’t go over just the current topic’s flashcards. I feel that is the review concept that I was missing last year. I feel really good about this plan and am very excited to continue this path. Due to the recent @artofneteng podcast episode titled “Goal Hacks“, I am also now considering adding in practice exams sooner than later. On your path to your goals, I think you need to find what steps work best for you, but I do recommend making a plan and sticking to the core concepts of that plan.

I have been around OSPF for some time now, but I had not until recently (while studying for ENCOR), done a deep dive into understanding how to read and understand the link state database (LSDB). The LSDB essentially contains route reachability information for all known OSPF routes in a network and is built from six different link state advertisement (LSA) types, which are listed and described (with my notes) here.

• Type 1 – Router LSA
  • Each router in an area generates a single Type 1 LSA that describes all OSPF enabled links.
  • The foundation LSA of OSPF.
  • Type 1 LSAs do not get advertised outside of the area of origin.
• Type 2 – Network LSA
  • Type 2 LSAs describe the network and attached routers of multi-access links.
  • Like Type 1 LSAs, Type 2 LSAs are not advertised outside of the area or origin.
• Type 3 – Summary LSA
  • Generated at area border routers (ABRs).
  • Describe networks that originate from another area.
  • Type 1/2 LSAs are recreated at ABRs as Type 3 LSAs to be advertised to other areas.
• Type 4 – Summary ASBR LSA
  • Generated at area border routers (ABRs).
  • Describe how to reach an autonomous system boundary router (ASBR).
  • Used in conjunction with Type 5 LSAs.
    • Because Type 5 LSAs describe networks that are advertised by ASBRs, routers need to know how to reach the ASBR. The Type 4 LSA is advertised by the ABR to the local area so the local routers know that to reach an ASBR, they need to route to the ABR.
• Type 5 – AS external LSA
  • Describe external routes that are redistributed into OSPF.
  • Generated at autonomous system boundary routers (ASBRs).
  • The only LSA type that is advertised “in tact” throughout multiple areas.
• Type 7 – NSSA LSA
  • Describe routes that are redistributed by an autonomous system boundary router within a Not-So-Stubby Area.

The LSDB can be a very powerful tool for discovery. Because all routers within an area maintain and identical LSDB, you can draw out a topology map of that entire area by just logging into an looking at the LSDB of a single router. When doing this, you would just need to focus on the type 1 (router) and type 2 (network) LSAs.

• Suggested commands
  • show ip ospf database
  • show ip ospf database router
  • show ip ospf database network

• Podcast: The Art of Network Engineering (AONE)
• Episodes: 22 and 23 – The OG of IT

In this exciting two-parter, the crew sits down with none other than Keith Barker. Yes, that Keith Barker, Mr. CBT Nuggets himself! My “introduction” to Keith was a while back when I was searching the internet for a better understanding of the building blocks of IPSec VPNs. Then, I found it. A three minute video on YouTube from this guy named Keith Barker titled “Remembering the 5 Things to Negotiate in IKE Phase 1“. I learned more about IKE Phase 1 in those three minutes than I had know about it to date. Now, I have the opportunity to leverage CBT Nuggets with Keith and crew to work through the ENCOR curriculum.

So, I’ve known Keith the trainer for a little while now, but had not gotten a good idea of who he is outside of teaching us all how to network. That definitely changed with these two AONE episodes. It was so cool to really hear his backstory. From working on printers in his early days, to network infrastructure at Paramount Pictures (to name a couple), Keith has had quite the career even outside of being a professional IT trainer. My favorite parts of this series were hearing more about Keith as a person and his journey. The amount of time, effort, and training he has put in to become a excellent trainer and teacher is incredible. He shared details of his personal life and revealed, hey, he’s just as human as the rest of us (an incredibly kind, dedicated, and motivated human, but human nonetheless). Things that stick with me (I’m paraphrasing for the most part) from the end of Episode 23:

• Be kind.
• Do more than what you’re paid for.
• Have a good attitude.

These were two great episodes with a true legend of network infrastructure that I encourage you to check out.

Key Off-Topic Takeaway: Dan’s tone shall now be referred to as “Barry White voice”.

As with any Cisco exam (along with other vendors), the sheer amount of content that needs to be understood to pass the exam can be staggering. Let’s say you are learning topics from a book which is broken up into chapters. You read and understand the first chapter, but all you do is read it. Over the next month, you cover five more chapters the same way as the first. Great, but now, how much do you really remember and are able to comprehend from way back in chapter one? This is an issue that I have run into with my ENCOR studies.

I have been studying for the ENCOR exam longer than I care to admit. There are chapters/topics that I hit months ago that I’m sure I am completely rusty with now. I’ve been covering this content, leveraging multiple sources, but let’s face it, I’ve done an incredibly poor job when it comes to note-taking. A little while back I started mind maps at the end of chapters, but I started it late and feel that while helpful, it isn’t enough for me. I’m not sure where I went wrong. I did mind maps (and potentially flash cards) when preparing for the CCNA, but I really dropped the ball with ENCOR. That is all starting to change. I had gotten some advice from the AONE podcast to try out digital flashcards, specifically the Anki platform. I just started this within the last few days and it has already proven beneficial. For me, repetition is key when it comes to learning and this platforms allows for just that. It has also given me a new energy for studying which is huge. I have the application installed on a computer along with my phone and I can sync the flashcards created between both platforms. When it’s been a while since I studied a topic, I have the flashcards that I can review. So far, my flashcards mainly consist of questions from both CBT Nuggets and the OCG, and key topics and terms from the OCG. I wish I would have done this from the beginning, but at least I’ doing it now, and that’s good enough for me. Happy studying, everyone!