When planning for an SD-WAN, I like to start with these ten questions to determine my high-level design and initial implementation strategy. This is just scratching the surface, but it helps me get moving with an actual design and migration strategy.Continue reading “Top 10 Questions to Ask When Planning a New SD-WAN”
I have the luxury and privilege to work on some very interesting projects. Sometimes it’s advanced routing, sometimes it’s working with brand-new technology, and sometimes it’s a very interesting and unique use case.
However, it never ceases to amaze me that some the most important skills and technical knowledge I’ve gained over the years is understanding how to calculate a power budget for an IDF, the difference between an L620P and 620P cord, the difference between various types of fiber, and remembering to ask my customer about the direction of airflow in their data center.
When designing real-world networks, it really is the overall picture we have to keep in mind. Speeds and feeds, bits and bytes, and all the syntax in the world isn’t enough to properly design a real-work network that you can actually power on and plug into.
Over the past five or six years we’ve heard plenty of discussion around the slow and steady demise of monolith single-vendor networking and a shift to multi-vendor environments. Due to the rise of disaggregation, whitebox networking, and to an extent even vendor agnostic network automation, we should all be running multivendor networks by now.
Imposter syndrome is the topic du jour for blogs and podcasts, so I’m almost reluctant to write about it. However, I want to share something I realized about myself that breaks from the conversation at large about this popular subject.
I believe continual professional development is absolutely necessary for workers in the IT industry, and for a network engineer like myself, blogs and podcasts have helped with my own professional development as much as formal training courses.
Below is a list of the technology-related podcasts that have been my go-to when driving the many miles I travel per month. Most are networking-related, but some cover information on security, cloud, virtualization, etc.
There are more out there, but these are the handful I always seem to gravitate to. I’d love to get your recommendations for podcasts I should be listening to, so please let me know in the comments.
I got very interested in intent based networking a few years ago when the term was relatively unknown. However, in the last year or so the term has been adopted by a variety of networking vendors and applied to technologies that I believe have very little to do with intent based networking.
The term has become part of the current marketing narrative leaving a bitter taste in the mouths of many engineers and technical individuals. However, I believe it’s very important to consider that intent based networking is not simply the use of a new buzzword by networking vendors. IBN stands on its own as a new networking paradigm, despite it being hijacked by marketing teams.
As much as I love to call out a vendor on marketing nonsense, Ramesh Prabagaran, Director of Product Management at Cisco, made some compelling marketing statements about SD-WAN at Networking Field Day 19. In particular he said:
Recently I was in the midst of setting up a simple two node Cisco ISE 220.127.116.118 cluster and got to the stage when I registered the secondary node through the GUI of the primary. At that point, things wouldn’t work.
I’ve been an active part of the networking community on social media for only a few years. Before that I was a passive consumer of tweets, blogs, and videos. A previous manager inspired me to be more active, and very quickly after engaging directly with bloggers, podcasters, and engineers, the value of being an active participant became very clear to me.
I spent about a year completely focused on network security, and one thing I learned was that spending all my time focused on securing the perimeter to the neglect of intra-LAN traffic was a recipe for disaster.
Most of the traffic in our data centers is east-west, with only a small fraction actually being northbound out to the rest of the world. The cost of massive firewall appliance clusters operating at line-rate is astronomical, and it doesn’t make sense to punt traffic all over the place if there’s a better way.
Servers, especially Linux servers, have been managed programmatically for years. Today, it goes almost without saying that a decent IT department is running Chef, Ansible, or some other tool to manage their servers as pools of resources.
What strikes me as odd is that this didn’t catch on in the network side of the house. Of course, there are always exceptions. A look at networking forums from years ago will showcase a few ambitious engineers arguing over using Expect or Perl scripts to manage their switches, but this was the exception in the networking industry, not the norm.
At Networking Field Day 17, several vendors that have long embraced network programmability turned their gaze from the data center to enterprise networking, and it seems as if networking may be finally ready to catch up to what we’ve been doing with servers for decades.
When I was a new high school English teacher I sat through a class on grammar my department chair taught to her 7th graders explaining a preposition is a word that describes anywhere a mouse can go. I’ve never forgotten that.
A few years later I changed careers to IT and found some very helpful mnemonic devices and acronyms that helped me remember various aspects of networking.
Here are a few that I used over the years:
Intent-based networking is a hot new topic in the networking industry right now, but what really is intent-based networking? Watch my video to find out more.
There are a small variety of methods to implement failover of your WAN perimeter between two ISPs. In this post we’ll look at one way to accomplish this goal with a few technical requirements.
Keep in mind that there are several ways to accomplish this same goal depending on the hardware available, the flexibility of the ISPs, and the skill level or preference of the engineer.
This topology utilizes two edge routers and two ISPs instead of the single edge router design I wrote about recently (you can read that here). For this post we’re using Cisco routers, but the concepts apply universally. Our requirements are that we maintain connectivity from our inside host to the internet in the event one of the company routers fails or one of the ISPs fails. Failover and fail-back must be automatic with no manual intervention.
Check out the first Network Collective video podcast, Top 10 Ways to Break Your Network, in which experienced network engineers share their most memorable blunders and the lessons learned from them.
Here’s the website: http://thenetworkcollective.com/
The header image was used with permission from Michael Nelson who was one of the Twitter participants during the first show. Check out his site here.
No Networking Field Day would be complete without a presentation from an SD-WAN vendor. The technology is now established and maturing into a ubiquitous WAN solution across small and large enterprises alike, so at the upcoming Networking Field Day 15, I’ll be focused on how TELoIP, one of the presenters at the event, differentiates itself from its competitors.
Sometimes political, financial, or logistical hurdles determine how we solve networking problems. In these tricky situations we may not be able to solve the problem the way we’d prefer, but we still need to solve the problem.
In this post I’m going to look at how we can solve a WAN failover scenario when we have a default route learned from both of our service providers and a reachability problem via our primary ISP.
I’ve been thinking a little bit about the Amazon S3 incident. Not really the incident, actually, but the responses to it. More than once I read something along the lines of “I’m sure that guy got fired” with regard to the engineer who entered the fatal command.
Sure, that’s kind of funny for a quick tweet or in the greater context of a blog post on change control, but for me, I’m not sitting at my desk shaking my head right now. Instead, I’m reminded about the times I did the exact same thing (on a much smaller scale) and will probably do it again.