Podcast Review – ZigBits Episode 70

  • 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.

ENCOR Journey – STP Portfast

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

ENCOR Journey – The Plan

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 Review – AONE – The OG of IT

  • 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”.

ENCOR Journey – Flashcards

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!

ENCOR Journey Series

As I have progressed through my study toward the Cisco ENCOR exam, I have received some really solid advice. First, as far as materials, I have been leveraging the following:

Outside of the flashcard advice, I’ve also seen from others that writing about what you are learning can help solidify the topics within your brain, plus you have the potential of helping many other people. Call me selfish, but if I can do something that helps myself along with others, I’m going to at least check it out. For me, this concept comes from a couple of different sources. I had tried something like this earlier this year, but it never went past more than one post. Later in the year, I learned that a friend, Charles Uneze, uses the method of blogging to help himself even better grasp knowledge around things he’s learning. That seemed like an incredible idea to me, so I am going to give this another go. As far as helping others, at first, I’ll admit I was on the fence about whether or not me writing something could really benefit other people. Then I thought about how I had learned about blogging and leveraging digital flashcards to solidify knowledge. I learned these things because there are people out there sharing their journeys and reminding us all that we don’t have to go at “this” alone. I hope you all get as much benefit out of this series as I plan to get.

Podcast Review – ZigBits Episode 67

  • Podcast: ZigBits Network Design Podcast
  • Episode: 67 – Top 5 Network Design Principles with Daren Fulwell

This episode of the ZigBits Network Design Podcast around network design fundamentals was the inspiration for me to start this blog series around podcast reviews. Either with work or study, I’m always finding myself thinking about design. I think it’s very important to not just understand the “what’s and how’s”, but also the “why’s” when it comes to any technology or design. Like I continuously say, it all starts with business requirements. I have yet to go through any network design focused certification or in depth study, so I thought it would be great to have some high level pillars in mind when thinking about network design that can be transferrable to different situations and scenarios. This episode gives us exactly that. Zig and Daren break down network design into five principles. Here is the list, with my spin/interpretation/thoughts of each. Zig has these listed out, with full explanations in the show notes.

  • Availability
    • I love that this is the first principle listed and it makes complete sense. How much value can a network provide if it is only available and functioning a small portion of the time? It is highlighted in the podcast that availability is part of security minded CIA triangle of confidentiality, integrity, and availability.
  • Scalability
    • This tends to be a tough one for me. Is there a “magic” percentage number that we should select for every design in terms of growth? For example, when it comes to switches and routers, should I always account for 25% port count growth? Or 30%, or even 50%?! Let’s face it, planning for a fair amount of unknowns is difficult, but we need to do our best with the information given. My takeaway from this episode is that the keys are elasticity and the ability for the network to be flexible as business needs change.
  • Security
    • Security consideration really should not/cannot be left out in the design and implementation processes. Like mentioned earlier, it is directly related to availability.
  • Supportability
    • This is incredibly important, but I could see how it might sometimes be an afterthought. There could be a completely solid design on the table, but if it takes someone with 20 years of experience and 15 certifications to decipher it and troubleshoot when issues arise, is it really a solid design after all? Shifting gears a little bit, one thing that was brought up in the episode was automation and templates. If configuration standardization is a consideration in the design phase, automation can more easily be leveraged to support the design not only at implementation, but over time as well.
  • Simplicity
    • To me, this goes hand-in-hand with the supportability principle. Care should be taken when technologies and features are being considered for implementation. Maybe a cost/benefit analysis needs to be done whenever something being considered for deployment adds a certain level of complexity. At the end of the day, whatever is being implemented has to be supported by someone. I think I may have mixed thoughts a bit in these last two principles in relation to the episode, but I think these two are tightly coupled.

Final Thoughts

Again, this podcast episode was the inspiration for me to start this series of posts. I tend to have the desire to be “structured”, and I’m a creature of habit. To be able to look at network designs in the future with these five principles fresh in mind is incredibly helpful. Zig and Daren clearly know what they are talking about around this topic and have the CCDE certificates to prove it! This was a great listen and I strongly recommend it to any network engineer/admin/architect.

Podcast Review Series

I’m going to try something new here on the blog and see if it sticks. For a while now, I have been really getting into listening to technology related podcasts. Many episodes of different podcasts cover topics that really resonate with me. I thought it might be beneficial to write “reviews” of podcast episodes that are notable to me. Here is a list of podcasts that I listen to currently, that I could see covering in this series. I’ll try to remember to come back to this post if/when I add to the list.

I think this will be a lot of fun for me and hopefully beneficial for others as well.


In early August, I wrote about excitement around community involvement. To re-cap, throughout my career up until recently, my passion for network engineering was kept mainly to myself. Within the last couple of years I started listening to tech/networking related podcasts and started this blog site earlier this year. This summer, I found a podcast that was just starting out called the Art of Network Engineering. I was immediately hooked to the content being generated from the four engaging hosts and the incredible list of guests that they have invited to join them. Right away, this felt like a group with which I could carry on technical and non-technical conversations. Right after the first episode, I checked out the website, reached out to the crew and got hooked up with the “It’s All About the Journey” Discord channel. This is where the magic happened for me. Right after joining this community, I was getting mentored with career development advice by @aaronengineered and carrying on conversations with @noblinkyblinky. A.J. even invited me to write for the website and now I tell the stories of some amazing people from the community in the “Faces of the Journey” series. The individuals in this group are inclusive, encouraging, and push us all to be better. Seeing everyone work hard, accomplish difficult goals, and help each other, makes me strive to be better in everything that I do. This community of people has definitely been a game changer for me. If you are so inclined…..BE A PART OF IT!