Opinion Post: “Intelligent” Direction

When deciding on direction, tools, and ultimately purchases related to IT in an organization, it is very easy to get caught up in trends and buzzwords. Every product and service can quickly become the “next best thing” and you don’t want to be left in the dust, right?

I do believe that in order to make intelligent decisions regarding the direction of your company, you need to be informed on new technologies and services. Whether you are researching on your own or getting this information from a partner, it’s definitely a good thing to do. Having knowledge of these technologies and services will help you if you need them at some point to serve a business need.

The two important words at the end of that last sentence are “business need”. As an IT professional, your ultimate goal are to serve the needs of the business. If you are someone in the organization responsible for making IT related decisions, it’s my opinion that you really need to understand what your business is doing and where it is going to provide proper value. Remote access throughout the pandemic is an example of this. How do people need to connect and what do that need to do? Maybe a “one size fits all” approach meets the need, and maybe is does not. Understanding the tech is obviously important in IT, but understanding the business is just as important.

Virtual Conferences – A Social Aspect

Last week, I was able to attend a fair amount of the virtual Cisco Live US 2020 event. I wanted to share my thoughts around the social aspect of virtual versus physical conferences.

Up until now, I have only attended one Cisco Live US event and that was in Las Vegas in 2017. I remember getting registered late and not preparing the best for the event. It was overwhelming to say the least, but I had a great experience. I attended multiple sessions and met with a few people, but largely kept to myself. I’ve learned since then that I did it wrong. A big benefit of these conferences is to meet and network with like-minded people. The social aspect of these events is huge. I was really looking forward to giving it another go this year.

I think that currently, virtual conferences make social interaction more difficult because there is less chance for organic conversation. I say “more difficult”, but definitely not impossible. We have been using videoconferencing technologies for some time now (and is used to supplement these virtual conferences). I definitely think that virtual conferences are here to stay and that’s a very good thing. They promote inclusion by making it easier for people to join in without travel. I do think that we need to be careful that we don’t let the interaction, organic conversation, and general people networking go by the wayside. We need to continue to leverage technology to stay connected, when we cannot meet face to face. In my opinion, humans are the heart technology.

Learning Log – VRF

I am currently working toward achieving the CCNP Enterprise certification. I thought it might be fun and interesting (relatively speaking) to create blog posts around some of the topics I am covering throughout my preparation. I recently spent some time going over virtual routing and forwarding (VRF). Up until now, I haven’t had a lot of direct exposure to VRF. I had somewhat of an idea of the purpose, but it was mostly magic and unicorns as far as I was concerned. As I dug into the technology, I quickly realized that it’s a really simple concept with fairly simple configuration (the high level basics, of course). We virtualize everything these days, why not routing tables? Maintaining route separation with being able to use overlapping networks in separate VRFs can be very useful. My advice to anyone else learning about VRF (along with practically every other networking technology) is to find a way to lab it up, play, and test. This isn’t new advice by any means, but I find it really helpful. Being able to apply learned concepts in practical examples is really powerful. Plus, having “ah-ha” moments while going through practical application can do wonders for your confidence.

Happy learning, and remember to help each other out there.

Conversation Starter: Route Where You Can, Switch Where You Must?

Disclaimer: There is a fair amount of my opinion in this post. I welcome feedback, especially on anything that doesn’t seem right.

When discussing and thinking about campus networking, I go back and forth on where the L2/L3 boundary should be placed. In a traditional three tier architecture of core, distribution, and access, how far toward the access layer should we take routing? Of course, that answer is probably the all popular “it depends” reply.

My thought is that with multi-layer switches being common for some time now, and that modern switches (depending on what you’re dealing with) can function at Layer 2 and Layer 3, taking routing all the way to the access makes sense. My reasoning behind this is simplicity and bandwidth. Spanning Tree Protocol does its job well, but if I don’t even have to think about STP, generally I’m happy. On the bandwidth side, leveraging Layer 3 means we can reap the benefits of Layer 3 Equal Cost Multipath (ECMP).

That all being said, any design should be approached by understanding the business requirements. Is there a business need to have VLANs span multiple switches? If so, and if there is no overlay technology in play, then Layer 2 from distribution to access is necessary, which is still a valid design. Also, to maintain redundancy and utilize more physical links, Mutlichassis Etherchannel (MEC) supported designs can be deployed.

In conclusion, I think it is great to have standards to strive to implement, however you always need to be mindful of business requirements. I do think that overlay technologies will continue to become more prevalent and allow for standard underlay designs of Layer 3 to the edge (access layer) while the overlay handles any Layer 2 extension requirements.

Opinion Post: Don’t Forget your Eyesight

When so much effort and pressure are put on designing and implementing strong technology solutions, in my opinion, it’s easy to neglect having visibility into those solutions once they are implemented. While competent design and implementation are important, having access to insight and analytics into the system once the design is in production is just as important. Having a competent design to reduce issues is ideal, but what do you do when the system is not working properly or someone is accusing the system of not functioning properly? Visibility and analytics are important for many reasons, but to me, a big one is troubleshooting. I want to be able to help people resolve issues in the quickest way possible and if I have that deep visibility at the ready, there is a better chance that I can do just that. A more selfish way to put it is “mean time to innocence”. How do I quickly prove or disprove that an issue is my fault so that I can move onto the next task or project? Having visibility, analytics, insight, evidence, etc is key. Whether the system you are designing and implementing has built-in visibility, there is a product out there that can provide that visibility, or you can develop a home-grown solution, leveraging that insight is important. Once the design/solution has been implemented, someone has to support it, and having proper tools can help greatly.

Factinion: Multiple Spanning Tree

[Factinion Definition: A combination of facts (or at least statements that I believe to be facts) along with my opinions (with which you may agree or disagree).

Background: I am currently on the new CCNP track. One topic that is covered in my studies is Multiple Spanning Tree Protocol. MSTP is something that I’ve seen in the CLI, but never delved into until now. In this post, I’ll go over my understanding of the protocol as well as deliver my opinion. This post can be seen as “high level” and not getting in depth into the protocol in question. I encourage you to comment with your thoughts and to let me know where I got it wrong.

The Need for MSTP: Rapid Per VLAN Spanning Tree (PVST+) gives us the ability to maintain a separate Spanning Tree instance for each VLAN in our environment. In a traditional Layer 2 topology where we have multiple access layer switches that are dual connected to diverse distribution layer switches, leveraging PVST+ allows us to “load balance” VLANs to either distribution layer switch #1 or #2 by alternating forwarding and blocking ports on the different access layer switches. One thought is to have all odd numbered VLANs actively forward to distribution layer switch #1 and all even numbered VLANs actively forward to distribution switch #2. While this practice is valid, it may not scale well. A separate Spanning Tree is maintained for each VLAN and separate BPDUs need to be generated and processed for each VLAN. That could become resource intensive for switches as “many” VLANs are added to the topology. Enter MSTP as a scalability option.

My Understanding of MSTP: MSTP builds off of the PVST+ protocol. We can still achieve the load balancing goal explained above, while minimizing the number of Spanning Tree instances. For example, let’s say we have 20 VLANs in our topology. With PVST+, we would have 20 instances of Spanning Tree running. If we wanted to load balance VLANs across the two distribution switches, we could leverage MSTP and cut the number of instances down to 2. MSTP allows us to group multiple VLANs into a single instance. Building off of our load balancing example, we could have odd numbered VLANs in instance #1 (with distribution switch #1 as the root bridge) and even numbered VLANs in instance #2 (with distribution switch #2 as the root bridge). Any VLANs not specified to a given instance would automatically be joined to the Internal Spanning Tree instance (instance 0).

My Opinion: While I see the place and benefit for MSTP, it also adds a level of complexity that needs to be considered. Certain parameters need to match across switches in the topology, and because of this I can see where it could become difficult to manage and troubleshoot. On another note, outside of the individual Spanning Tree modes, I can see STP altogether becoming less relevant. With Software Defined everything, overlays are bridging the Layer 2 gap over end to end Layer 3 networks. Large native Layer 2 domains can become very complex and difficult to troubleshoot. While STP does its job well, if Layer 3 can be taken as far to the edge as possible, minimizing STP domains and calculations, that makes sense to me to do so. However, if Layer 2 from the distribution layer to the access layer is necessary, there are Cisco technologies such as Virtual Switching System (VSS) and StackWise Virtual in the Catalyst line, and virtual PortChannel (vPC) in the Nexus line to make that more efficient. With these technologies, the physically diverse distribution switches can be paired together to appear as a single logical switch to the access layer.