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’ve been doing quite a few wireless networking projects lately, and often that also means Cisco ISE, Prime, location services, and that sort of thing. I really enjoy it, but it’s a funny story how my heart changed from loathing wireless projects to looking forward to them.
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.
Locating a wireless client in real time and viewing its location history in Cisco Prime Infrastructure is a little bit different with CMX than with MSE. In this post we’ll walk through the few steps to locate a wireless client among all your maps and then view its location history.
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:
Oh no. Pings stopped.
A cold breeze raised the hair on the back of my neck while I stood motionless in front of rack 5 in aisle 7. I much preferred standing in the hot aisle, but this is where the KVM console was. The screen flickered as I adjusted the angle of the monitor. This thing was ancient, but at least I had something to work with.
Last night I tweeted the question:
It was Sunday night, so I didn’t get an overwhelming number of responses, but I did get more than a few.
Does a pre-sales engineer need to have strong implementation experience to be good at their job?
Not long ago, I needed to put a script together for a simple task, so I wrote something very brief in Python. When I say “wrote”, what I mean is I copied and pasted parts of scripts others had written and created some new monstrosity to get the job done.
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.
Whitebox switches make use of generic and generally inexpensive hardware along with a network operating system that can be purchased and installed separately. Often the hardware and software come from different vendors, and there are several reasons this practice is becoming more common especially in the data center. What I’m interested in lately is how this is relevant to the non-webscale enterprise.
SD-WAN as a Service is coming to the marketplace as something to be be consumed, not owned. IT decision makers just want an ethernet handoff, and a managed WAN is already a common professional service, so for the typical IT manager, the case for SD-WAN as a Service is ease of use and cost savings. Very little else.
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.
If you haven’t heard, the networking community is awesome. I’ve made some great friends, developed strong new relationships, and I’ve had the incredible luxury to bounce ideas off some seriously talented people. However, whether it’s through various Slack groups, Google hangouts, or private email chains, it’s all been relatively private. Not much makes its way onto Twitter, and not as much as I’d like makes it into blog posts.
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.