It’s funny, in my exerperience, OSPF is the most widely used interior gateway protocol because it “just works” and it’s an IETF standard which means it interops between different vendors and platforms. However, if you really start to look at how OSPF works, you realize it’s actually a highly complex protocol. So on the one hand you get a protocol that likely works across your whole environment, regardless of vendor/platform, but on the other you’re implementing a lot of complexity in your control plane which may not be intuitive to troubleshoot.
This post isn’t a judgement about OSPF or link-state protocols in general. Instead it will detail five functional aspects of OSPF in order to reveal–at least in part–how this protocol works, and indirectly, some of the complexity lying under the hood.
Cacti is a “complete network graphing solution” according to their website. It has also been a thorn in my side for a long time.
See what I did there? Thorn… because it’s a cactus… never mind.
When Cacti is in a steady state–when I could get it to a steady state–it was good. Not great, because there was a lot of effort to get it into what I consider “steady state”, but good. The rest of the time… thorny.
This past June when I was in North Carolina at Cisco’s CPOC lab, I learned that there was a chance–albeit a slim one, but a chance nonetheless–that a position would be opening up on the CPOC team in the fall. By that point I had been to CPOC three times and knew many of the engineers who worked there. I spoke to them to get their feedback, met with the newly-hired manager of the team, and just generally did all the things I thought I should be doing to take advantage of my time being face to face with these folks.
Then I flew home, subscribed to the “new jobs at Cisco mailing list” and waited.
And then, one day, it was posted: CPOC Technical Projects Systems Engineer. I immediately sent a message to my wife who responded as only she knows how:
Five short interviews later I was offered the job!
This brings me to change #1: As of this month (January), I am no longer a Systems Engineer with Cisco Systems Canada. I am now a Systems Engineer on the CPOC team reporting to a manager in the US.
Beyond the basic level of excitement I have about joining this team, I’m even more excited because I’m being hired for a role that isn’t quite the typical CPOC engineer role. My role is part of an initiative to help field sales teams (which up until today, would’ve included myself) sell various Cisco enterprise networking solutions, the first of which is Cisco Intelligent WAN. My role in this initiative is to provide technical expertise in helping field SEs conduct proof of value (POV) exercises with their customers through a combination of remote support and direct hands-on engagement at customer locations (as the situation warrants).
This is a new initiative at Cisco and involves a lot of people at different levels and in different parts of the company. I’m really excited to get back to a more technical, hands-on role, to feed my field experience back into this initiative to make it successful and valuable to the field teams, and to be involved in an initiative this big from the ground floor.
Now, you may have noticed that I said above that I am reporting to a manager in the US. Well, that’s because the CPOC lab is in RTP, North Carolina and that’s where the team is based.
That brings me to change #2: My wife and I (and the cats, can’t forget the cats 😼) will be moving from Calgary to the Raleigh/Durham area in the coming weeks.
Something else we did when I was at CPOC in June was to make sure my wife came down over the weekend so she could (finally!) see the area and understand why I loved going down there so much. It took her no time at all to get it. Now that we’re looking at moving, she understands the area a bit and has a feeling for what we’ll be stepping into.
She grew up and has lived her whole life in Calgary and I grew up not far from Calgary and have been here for about 15 years. We’re very excited for this change! We’re excited for a different climate, we’re excited to explore, and we’re excited to be close(r) to the ocean.
So there we go! Not a long list, but a very impactful one, for sure. Thank you to everyone for your support, small and large, over the past few and upcoming weeks! Bring on the BBQ!
Update Feb 22 2017
It’s been a few weeks since I posted that I had taken a new job and that we were moving to North Carolina. A lot has happened since then, enough that I thought it warranted this unplanned update.
First, I’ve been doing the new job since early January and it’s been a lot of fun. Normally a Cisco CPOC engagement means the customer comes to Cisco and does their testing in our lab, but I was hired to take the show on the road and conduct demonstrations on-site with customers. It’s been a lot of fun playing a part in getting this new type of CPOC delivery up and going.
Second, there has been a rather major, unexpected wrinkle in the relocation. While reviewing my tax situation with a professional tax advisor, I came to learn about a Canadian tax known as the departure tax. This tax kicks in once you become a non-resident in the eyes of the Canada Revenue Agency (CRA). CRA has a set of criteria for determining who is a resident, none of which we would meet. As a non-resident, we would be hit with the departure tax.
The departure tax is basically CRA’s way of ensuring they get what they feel they’re entitled to in terms of taxes on capital gains and other investments. The reasoning seems to be that if you leave Canada, you’re untouchable from CRA’s perspective and they won’t be able to collect tax from you. The departure tax is very odd though because you don’t actually have to sell anything or realize any actual capital gains for the tax to kick in. What happens is something called a “deemed sale” where–for all intents and purposes–everyone pretends that you executed a sale and you are summarily taxed on the imaginary capital gains. Beyond just capital gains, there are other investment assets that are also taxed.
What hurts about this is that it all comes in one shot. And in our situation, having never heard about this before now, we had not done any financial planning in order to mitigate the tax hit. Our exposure to this is rather high and being that it comes all in one shot, would be very difficult to absorb.
Because of this tax situation, the move is now on hold until further notice. Thankfully, my role on the CPOC team allows me to work from anywhere and my manager has been absolutely amazing in her understanding and patience.
So for now, my wife and I are digging our toques and mittens out of storage, mentally preparing to have to continue dealing with winter, and making plans for the future to cut our exposure to this little known, high impact part of the Canadian tax code.
I haven’t ever written a “year in review” type of post before. Sure, I do a post to summarize how the blog has done over the year but I’ve never done a personal look back. Last night–New Years Eve–I was thinking about everything that I was involved in during 2016 and I realized “I should write this down! I was involved in or a participant of some amazing things last year!”
Happy New Year! I just realized the other day that this blog turned 5 years old in 2016. It’s been a lot of fun and has paid me back for my time in terms of building my brand and being a means to explore and learn new topics. I have plans to put more focus on my writing in 2017 and reduce the friction between starting with a blank page and hitting that “Publish” button.
I recently decided it would be fun to upgrade the hardware on my main OpenBSD machine at home (because, you know, geek). These Intel NUC machines are pretty interesting. They are pretty powerful, support a decent amount of RAM, certain models support internal storage, and they are very low power and low noise. Perfect for a machine that is a shell/email/development box.
So… I’m a little embarrased to admit this but I only very recently found out that there are significant differences in how Virtual Port Channels (vPC) behave on the Nexus 5k vs the Nexus 7k when it comes to forming routing adjacencies over the vPC.
I’ve read the vPC Best Practice whitepaper and have often referred
others to it and also referred back to it myself from time to time. What I failed to realize is that I should’ve been taking the title of this paper more literally: it is 100% specific to the Nexus 7k. The behaviors the paper describes, particularly around the data plane loop prevention protections for packets crossing the vPC peer-link, are specific to the n7k and are not necessarily repeated on the n5k.
There’s a lot of information on the intertoobs about getting ssh-agent “working” in OS X and even more articles about when and how the stock behavior of ssh-agent changed (mostly with respect to how ssh-agent interacted with the Keychain).
This article doesn’t cover or care about any of that.
This article is concerned with:
Enabling ssh-agent in such a way that I can “ssh-add” in one terminal window and that same agent (and the loaded keys) is available in all of my other terminal windows.
Enabling use of ssh-agent from MacPorts and/or Homebrew and not the older ssh-agent that OS X ships with in /usr/bin.
To avoid having to put my keys in the Keychain (just a matter of preference).