Tag Archives: networking

The Continuing Evolution of Forward Networks – Networking Field Day 34

Posted on by
Check out those backdrops!

Digital Twin

I was very fortunate to be a delegate at Networking Field Day 13, all the way back in 2016. This was a milestone event for Forward, as this was their official move out of “stealth” as a Silicon Valley startup. Their initial presentation was impressive, and the Forward Networks platform offered something I had not seen before, an accurate digital copy of your network, which you could query to understand paths and flows, and test proposed changes to prevent misconfiguration.

Fast forward to Networking Field Day 34, and Forward Networks are presenting again, now to highlight the maturity of their product, and how they are now integrating AI and LLM to allow for an even better experience with natural language queries, and enhanced visibility into your network digital twin.

At it’s core, the Forward Networks platform remains a full digital twin of your environment, allowing you to search, query, verify, and predict how traffic is behaving, and will behave in your environment. They are vendor-agnostic, meaning you can easily have a mix of Cisco, Juniper, HPE-Aruba, Arista, etc. and still leverage the power of the platform. A simple local agent crawls your network with SSH credentials (or via API if you have devices that don’t support SSH) and builds the snapshot of your network, which you can then import into the tool, and begin working with.

Having evolved quite a lot since 2016, Forward Networks now included integrations with the 3 major cloud providers, and security tie-ins to platforms like Rapid7 and Tenable to identify CVEs that may impact your network devices. Now they have taken the next step, with integration of Generative AI with AI Assist as part of the Network Query Engine (NQE).

AI Assist now allows the use of AI LLM to generate queries against the network model. These queries can be saved for use later in your own repository of queries, or you can also use a number of pre-packaged queries out of the box. The reverse is also true, and you can use Summary Assist to analyze a query and provide a plain language summary of what it is doing.

Proving the Negatives

If you’ve been in networking for any length of time, you know the feeling of having to “defend” the network because it’s the first thing that gets blamed when something isn’t working. We’re constantly having to prove a negative, which is sometimes hard to do. It can involve a lot of jumping around your network in the CLI, pinging and checking routes, doing packet captures, etc. and there’s no easy way to translate a lot of these methods into a simple to understand view of your network, and where the traffic is or is not going.

The Forward Networks platform provides a simple, easy to understand analysis and view of traffic flow across your network in a 100% mathematically accurate carbon copy. Queries can be copied and shared, so now you can send a link to your Dev team and show them that, despite their initial assessment with no troubleshooting or factual information, it is *not* the network.

Contining Forward

The team at Forward Networks continue to evolve and strengthen their platform, and the integration of AI LLM with AI Assist and Network Query Engine is a perfect fit. In an era where everyone is trying to shoehorn AI into their product, whether or not it makes sense to, this is an excellent example of what is still a very immature technology, put to good use.

If you want to learn more, and check out a customer testimonial around automation and cost savings from one of Forward Networks’ biggest customers, you can watch the recordings from the presentations here.

Forward Thinkers, Forward Networks.

Posted on by

Maintenance windows. Let’s be honest, they suck. If you ask any network admin they will likely tell you the midnight maintenance windows are their least favorite part of the job. They are a necessity due to the very nature of what we do, which is build, operate and maintain large, complex networks, because any changes that are made can have far-reaching, and often unpredictable impact. Impact to production systems that we must avoid whenever possible. So, we schedule downtime and amp up our caffeine intake for an evening of changes and testing whatever we may have broken.

No matter how meticulous you are in your planning, no matter how well you know the subtle intricacies of your environment, something, somewhere is going to go wrong. Even if you are one of the lucky few to have a lab environment in which to test changes, it’s often not even close to the scale of your actual network.

But, what if you had a completely accurate, full-scale model of your network, and could test those changes without having to risk your production network? A break/fix playground that would allow you to vet any changes you needed to make, which would in turn, allow you the peace of mind of shorter, smoother maintenance windows, or perhaps (GASP!) no maintenance windows at all?

Go ahead, break it.

That’s what Forward Networks’ co-founders David Erickson and Brandon Heller want you to do within their Forward Platform, as they bring about a new product category they call Network Assurance:

“Reducing the complexity of networks while eliminating the human error, misconfiguration, and policy violations that lead to outages.”

At Network Field Day 13, only a few days after Forward Networks came out of stealth, we had the privilege of hearing, for the first time, exactly who and what Forward Networks was, and how their product would “accelerate an industry-wide transition toward networks with greater flexibility, agility, and automation, driven by a new generation of network control software.”

David Erickson, CEO and co-founder, spoke to how they have recognized that modern networks are complex, made up of hundreds if not thousands of devices, are often heterogeneous, and can contain millions of lines of configuration, rules, and policy. The tools we have to manage these networks are outdated (ping, traceroute, SNMP, etc.) and the time spent as a network admin going through the configuration of these devices looking for problems is overwhelming at times. As a result, a significant portion of outages in today’s networks are caused by simple human error, which has far-reaching impact to business, and brand.

This is not a simulation or emulated model of your network, but a full-scale replica, in software, that you can use to review, verify and test against, without risk to production systems. The algorithm they use claims to trace through every port in your network to determine where every possible packet could go within the network as it is presently configured. The “all packet”.

Applications

The three applications that were demonstrated for us were Search, Verify, and Predict.

Search – think “Google” for your network. Search devices and behavior within and interactive topology.

Verify – See if your network is doing what you think it should be doing. All policy is applied with some intent, is your intent being met?

Predict – When you identify the need for a change, how can you be sure the change you make will work? How do you know that change won’t break something else? Test your proposed changes against the copy of your network and see exactly what the impacts will be.

Forward Search

Brandon Heller offered an in-depth demo of these tools, beginning with Search. Looking at a visual overview of the demo network, he was able to query in very simple terms for specific traffic. In this case traffic from the Internet, to his web servers. In a split second, Search zoomed in on a subset of the network topology, showing exactly where this traffic would flow. Diving further into the results, each device would then show the rules or configuration that allowed this traffic across the device in an intuitive step-through menu that traced the specified path through the entire network, and highlighted the relevant configuration or code.

This was all done in a few seconds, on a heterogeneous topology of Juniper, Arista, and Cisco devices.

Normally, tracing the path through the network would require a network admin, with knowledge of each of those vendors, to manually test with tools like ping and traceroute, and also comb through each configuration device-by-device along the path he or she thought was the correct one, in order to verify the traffic was flowing properly.

The response time on the queries was snappy,  and Brandon explained this was due to the fact that, like a search engine, everything about the network was indexed ahead of time, making queries almost instantaneous.

Forward Verify

It’s one thing to understand how your network should behave, and another to be able to test and confirm this behavior. Forward Verify has two ways of doing this. The first is a library of predefined checks that identify common configuration errors. Things like duplex consistency, etc. that are fairly common, yet easy to miss configuration errors.

The second is with network-specific policy checks. Here once again, a simple to understand intuitive query verified that bidirectional traffic to and from the Internet could get to the web servers over via http and ssh.

When there is a failure, a link is provided which allows you to drill down into the pertinent devices and their configuration and see where your policy check is failing.

Forward Predict

When a problem is identified or a change to the network configuration is necessary, Forward Predict is the final tool in the suite, and in my opinion, the most important one, as it allows you to test a change against your modeled network to see what impact it will have. This is huge, as typically changes are planned, implemented and then tested in a production environment in a change or maintenance window.

Forward Predict, while it may not eliminate the need for proper planning and implementation, allows you to build and test configuration changes in what is essentially a fully duplicated sandbox model of your exact environment. This is going to make those change windows a lot less painful as you already know what the outcome will be, rather than troubleshooting problems that weren’t anticipated when the changes were planned.

Moving “Forward”

A common sentiment among NFD delegates during this presentation was that Forward Networks’ product did some amazing things, however we wondered if there was an opportunity here to move this product one step further and have it actually implement or make the changes to the network, after the changes have been vetted by Forward Predict.

Forward Adjust, perhaps?

Understandably, this is going to involve a lot of testing, especially in light of the fact that Forward is completely vendor-neutral and touts the ability to work with complex, mixed environments. Making changes in those types of environments adds a lot of responsibility to this platform, and with that comes risk. Risk that most engineers might be a little skeptical to entrust to a single platform.

Time will tell, and I look forward to hearing more about Forward Networks’ development over the upcoming months, and see where the Network Assurance platform takes us.

Check out the entire presentation over at Tech Field Day, including a fantastic demonstration from Behram Mistree on how Forward Verify can help mitigate and diagnose outages in complex, highly resilient networks.

 

 

Netool – Pocket Sized Network Tester and Analyzer

Posted on by

As network engineers/analysts/administrators, we’re always looking to add to our list of tools. Whether these are pieces of software, tidbits of script, or physical tools, anything that helps us in the performance of our day to day work is something we tend to hang on to and use again and again. More often than not these tools are manifested out of a need to make a specific task more efficient, or less mundane, especially if you don’t have a junior analyst around to give all that work to.

One such task is identifying or tracing a switch port. In a perfect world, all of the network drops in a building would have accurate labels that never fade or fall off, that correspond precisely to the switch and port that they connect to, and cables that never get arbitrarily moved between ports, and of course accurate port descriptions on the switches themselves. In this world, there’s no need for any kind of tool to trace a cable or drop, is there?

Sadly that perfect world rarely exists. Even in new construction the natural entropy of networks ensures that wall jack labels, punch panels, and switch ports all become muddled, and more often than not one or more of those pieces is incorrect. This leads to a need to verify and ensure the information you have is accurate, and the need for another tool.

Now, cable tracing isn’t new, and tools for tracing cables have been around for a very long time. Often these come in the form of a probe and tone set, where one device is connected to the cable and it sends a tone along the wires, which can then be traced with a probe that listens for this tone. One simply waves the magic wand around all of your cables and wait for the one that provides tone, that must be the right cable! Well, not so fast, as crosstalk sometimes causes that tone to carry to several other cables in a bundle, and that tone you hear might not be the “real” one. That aside, it’s a tedious, manual practice, and can waste a lot of time if you have to repeat the task with several ports.

Companies like Fluke Networks have, over the years, developed some very nice tools for cable testing and verification. Many of these can be fairly expensive however, and perhaps outside the budget of an independant network consultant or other IT professional.

netool-logo

Enter Netool. This Indiegogo campaign touts the “World’s smallest network analyzer, testing and mapping tool”. When I came across this product on my Twitter feed I was very interested in learning more. This tiny tool will connect to and analyze a data port or cable, and provide switch and network information to your smartphone. It can provide information gleaned from protocols such as CDP (Cisco Discovery Protocol) and LLDP (Link Layer Discovery Protocol) which can provide switch port, VLAN, switch host name and IP information. It will test for DHCP services and display a leased IP as well as default gateway.

Check our their campaign video:

According to the list of campaign perks, one of these will cost $160 USD + shipping, or a special early bird price of $130 USD + shipping. There is also currently a Beta Tester perk that will get one of these in your hands before anyone else for only $99 USD + shipping.

Compare this to a Fluke Networks Linksprinter 100 at $215.99 USD (as listed on CDW) this seems like a great deal. As far as I can tell the only features the Netool lacks in comparison to the entry-level Linksprinter would be PoE detection, and perhaps some support for additional protocols such as EDP (Extreme Discovery Protocol) or BDP (Brocade Discovery Protocol). All of these that perhaps could come via a software update in the future.

I would encourage any of you in the market for a lightweight, hand-held, network testing and port mapping tool to check out the Netool web site, and consider a contribution to their Indiegogo campaign if this device is something you could see being part of your toolkit.

Hyperscale Networking for the Masses

Posted on by

In my career I’ve typically been responsible for plumbing together networks for branch, campus, and (very) small enterprise networks that had datacenters that were defined by single-digit rack numbers. So, when I’m reading or watching news about datacenter networking I often have a difficult time putting this into perspective, especially when the topic is focused on warehouse and football field sized datacenters. This might explain why I have not spent a lot of time working with or learning about Software Defined Networking, because it seems to me that SDN is a solution to a problem of scale, and scale isn’t something I’ve had to deal with.

As networks grow, management of configuration and policy eventually becomes ungainly and increasingly difficult to keep consistent. Having to log into 100, 200, even 1000 devices to make a change is cumbersome, and so we as networkers seek to automate this process in some way. There have been applications and tools developed over the years that leverage existing management protocols like SNMP and others to provide a single-pane view to managing changes to your network, but once again these don’t scale to the size and scope that we’re talking about with SDN.

Taken to the extreme, SDN and Open Networking have allowed companies like Facebook and Google to actually define and design their own data center infrastructure, using merchant silicon. The argument here being that Moore’s Law is coming to an end. Commodity hardware is catching up to or has caught up to custom built silicon and the premium that many were willing to pay for these custom ASICs is no longer required in order to stay on the cutting edge of data networking.

Amin Vahdat, Fellow and Technical Lead for Networking at Google spoke about this at the Open Networking Summit earlier this year, and contributed to a paper on Google’s Datacenter Network for Sigcomm ’15. In both presentations, Amin outlines how Google has, over the course of the last 7-8 years, achieved 1.3 Pbps of bisection bandwidth in their current datacenters with their home-grown Jupiter platform. I would encourage you to check out both the video and the paper to learn more.

ONS 2015 Keynote – Amin Vahdat
Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network

This application of SDN is dramatic. Few organizations have the ability, or need, to develop their own SDN solution for their own use. So how can this same scale-out model be applied to these other, smaller datacenters?

Recently I was invited to attend Networking Field Day 10 in San Jose, and we had an opportunity to visit Big Switch Networks. Rob Sherwood, CTO for Big Switch, spoke about some of the same principals around SDN, citing the Facebook and Google examples, and explained that there was “a tacit assertion that the incumbent vendors, the products that they build do not work for companies at this scale.”

Their solution? Big Cloud Fabric, designed to offer hyperscale-style networking to any enterprise. It is designed around the same three principals seen in Google’s infrastructure:

1) Merchant Silicon
2) Centralized Control
3) Clos Topology

Operating on 1U white-box/bare-metal switches running Switch Light OS, the leaf-spine topology is managed through the Big Cloud Fabric Controller. Several deployment options exist including integration with Openstack and VMware, and based on the current Broadcom chip being used, can scale out to up to 16 racks of compute resources per controller pair. Even if you only have half a dozen racks today, BCF provides scalability, and economy.

You can watch Rob’s presentation on BCF here:

One of the other things Big Switch Networks has done is launch Big Switch Labs, which provides an opportunity to test drive their products and for those of us who don’t work in large(ish) datacenters, a venue for getting your hands on a true SDN product in a lab environment. It’s a great way to gain insight into some of the problems SDN is aimed at solving and provides a fantastic demonstration of some of the capabilities and scalability that the Big Switch Fabric can offer.

BSLabs

If you’re just getting your feet wet with SDN, and/or Open Networking and want a brain-melting crash course on how it operates and scales in some of the world’s largest, most powerful datacenters, give Big Switch Labs a test drive. Big Cloud Fabric provides datacenter management and control modeled around the same principals as other massive hyperscale fabrics, but designed to be “within reach” for today’s enterprise customers and their own datacenter workloads.

Looking for the next opportunity!

Posted on by

As some of you already know, I’ve recently become a free agent and have begun the search for my next great job. I’ve learned a lot about the “brave new world” of job hunting over the last couple of weeks, and to be honest it’s been a bit scary.

I’ve only had two employers over the past 18 years, and in both cases I was laid off due to staff reductions. I jokingly told my wife that someday I’d like to experience what it is like to actually quit a job, rather than having a job quit me. After leaving my role as a Sr. Business Manager with Convergys (a large contact center organization) in June of 2007, it had been 10 years since I had applied for and interviewed for a job, and I found the idea of re-writing my resume and hitting the pavement to find a new career rather daunting. In October that same year I was contacted by someone I had worked with previously who was now working in the HR department of a public school division. She explained their IT department needed some temporary help for about 3 months, and although my role when we worked together had been in Operations, she knew I had technical skills, and wanted to know if I was interested. I accepted, thinking the work would pay some bills in the short-term while I continued to tweak my resume and find full-time employment. Instead, I re-kindled my passion for hands-on technical work, and ended up accepting a permanent position in January 2008, and worked there until April of this year.

That was my first taste of social networking and finding a job.

8 years later it seems leveraging the power of social media and professional networks is the absolute best way to find that new role. The general consensus seems to be that sending your resume out electronically to a bunch of automated HR systems, or submitting your CV and cover letter through a web form is not going to get you that position you wanted. It is frightening to read articles on the subject of modern recruiting explaining how automated software scans and scores your resume and rejects it before a real human being ever reads it. How prevalent that actually is I don’t know, but I do know that when I send a resume via email, I often envision it being packed away in a warehouse and forgotten like the Ark of The Covenant in Raiders of the Lost Ark.

Decisions…decisions

I have a few decisions to make. The first and foremost seems to be deciding what I want to do next. In 1997 I began doing technical support in a call center and fast-forward 10 years later I had relocated twice, and been promoted through various roles within that same organization with experience in training, client services, project management, and operations management. I had managed multi-million dollar budgets, with staff and operations spanning multiple cities in Canada and the US. I had developed my business skills, and although each of the projects I had worked on over the years were technical in nature, I had not really been hands-on with technology in some time. I knew I wanted to get back to that.

As a Systems Analyst with my most recent employer, a K-12 public school division, I had been able to spend the last 7+ years “doing IT” again. I’ve focused on networking and virtualization, and even knocked out a few certifications. The technology is what I am truly passionate about and being in a position to learn something new every day was fantastic. While it wasn’t a large infrastructure, I’ve had exposure and developed skills and experience with Cisco, HP, Dell, Microsoft, VMware, NetApp, Fortinet, and a number of other technologies. It was truly a great experience to work in a small IT shop and have access into a little bit of everything.

Somewhat parallel to this I decided to combine my business knowledge and my IT skills and started my own business 2 years ago offering managed IT services to small businesses that can’t afford their own dedicated IT staff. I’m able to partner with them and understand both the key issues that drive their business, while assisting them meet any technology needs they have. The possibility of growing the business is there, but with a family, and my wife presently on maternity leave, there is something to be said for the comfort and security of full-time employment. Mainly the steady income and benefits.

I could perhaps work for a vendor, doing pre-sales or post-sales support, and really get to know one particular technology. I could work for a reseller, which might provide exposure to a larger variety of products. Or, I could join another IT team, but if I did it would have to be a significantly larger organization. I want to experience work in a real data center, no more 2 rack switch closets with a portable AC unit that serve as one.

My “dream job” would probably be working somewhere with responsibility for a decent-sized VMware cluster, maybe on Cisco UCS or another converged/hyper-converged platform, and management of the underlying L2/L3 network infrastructure.

Wherever I go, I want to be able to make a real contribution and continue to develop myself as an IT professional. I want to ask dumb questions and learn from others and I want to be part of a great team.

Ongoing Learning

In my previous role there was some opportunity for on-the-job learning, but very little time or budget was set aside for real professional development. The reality is, in a public education environment, budgets seem to dwindle year after year and there is constant juggling between departments as to where the dollars are needed the most. Funding someone to take a $3000 course at Global Knowledge was out of the question.

That being said, I believe ongoing learning is critical, and found ways on my own to learn, play with, study and prepare for certifications. I’ve developed a fairly decent home lab, without raising too many red flags with my wife in terms of our household budget, and have been able to prepare for and pass a number of certifications over the last several years.

I’m in the process of wrapping up my CCNP R&S with one exam left (ROUTE), and completed the VCP5-DCV in December. I’ll likely focus on learning more about VMware’s NSX product and perhaps look at writing the VCP6-NV exam along with upgrading my VCP5-DCV to the VCP6 version.

Long term, I plan to dedicate myself to the challenge of the CCIE.

Success stories

I’ve read and been inspired by a couple of other folks in the industry who have used social media as a platform or jumping-off point to find their new career, and although I certainly don’t have the same sphere of influence these people have, I’m going to try to do the same. Hat tip to Keith Townsend for sharing his story over at VirtualizedGeek.com and also to Sean Thulin whose journey is told on his blog at Thulin’ Around and congratulations to both of them on their new roles.

Now, do I expect my dream job to simply fall into my lap? Of course not. I’ll be engaged in some of the more traditional methods of searching online and reaching out directly to a handful of contacts who may know of some unlisted positions. First of all however, I’ll need to tweak my resume to fool those pesky HR screening tools!

So, if you or someone you know are aware of an opportunity for a skilled, loyal (2 jobs in 18 years!) networking and virtualization professional, or simply would like to learn a little bit more about me, feel free to reach me here, or on Twitter or LinkedIn. I’d love to hear from you!

Otherwise feel free to share, retweet, or carrier pigeon this article and help me cast the net as far and wide as possible.

Two Out of Three Ain’t Bad?

Posted on by

The last several months have been quite a blur. My wife and I were expecting the arrival of our second child in April so way back in October 2014 I decided to spend the last few months of relative freedom catching up on some studying, in the hopes that I could knock out a few exams before some deadlines passed.

I had two goals, the first was to complete my CCNP certification as Cisco had announced the end of the current track effective January 30th, 2014. I had started and stopped studying for ROUTE so many times I was beginning to wonder if I was ever going to actually finish it. I had already passed SWITCH, and I, like many others, was saving TSHOOT for last.

The second goal was to attempt the VCP5-DCV exam. I had taken the VMware vSphere: Install, Configure, Manage course early in 2014 and had a voucher for 85% off the exam, but it had to be used by the end of 2014. I didn’t think I was prepared for it, but why waste an 85% discount? I decided to at least get a peek at the exam and gauge where I needed to focus in order to pass when I took a “real” shot at it.

 My Nemesis – ROUTE

I’ve never failed a Cisco exam more than once. Each time I’ve failed an exam I’ve taken a little time to regroup, and then focus right back on the areas I was deficient in, scheduled a re-take and passed. With ROUTE, this was not the case. I had failed it previously twice, both as my free exam at Cisco Live. Maybe it was the environment, staying in a hotel, lack of sleep, or the fact that it was “free” and something in my subconscious didn’t take it seriously, but for whatever reason I had not been able to massage a passing score out of this particular exam.

Now, my exposure to a lot of the L3 subjects has been limited, in that my day job had very little routing other than some static routes between sites and our ISP, so I had my work cut out for me starting all over again and learning OSPF, EIGRP, and BGP from scratch.

I dedicated myself beginning in October to studying for this exam. I was going to pass it if it killed me. I had Wendell Odom’s CCNP ROUTE 642-902 Official Certification Guide, I had video training from Pluralsight, INE, and CBT Nuggets, I had the Boson practice exams, I had physical lab gear, I had virtual lab gear. This was it, I was going to pass.

Not So Fast…

December came a lot quicker than I had anticipated. You see I was fighting with two deadlines, the expiration of my VCP exam voucher at the end of December, and the end of the current CCNP track of exams. I had hoped to pass ROUTE by mid-December and then take a run at the VCP exam, knowing it was just a trial run, and then finish off TSHOOT sometime in January.

By mid-December I felt I wasn’t ready for ROUTE yet, and my studying was getting more and more difficult as I read and re-read certain chapters and concepts that I just didn’t seem to grasp very well. It was time to take a break.

So, I scheduled the VCP5-DCV exam for December 29th and spent a couple of weeks re-reading Mastering VMware vSphere 5.5 by Scott Lowe and Nick Marshall, playing around in my VMware home lab, and testing myself with the MeasureUp practice exams.

By the time the 29th rolled around I actually felt pretty good. I mean, I didn’t expect to pass, but I thought maybe if the exam gods were in the spirit of the holidays, I might have a shot…

And I passed!

Back to ROUTE

Passing the VCP gave me a boost and so I re-focused on the ROUTE exam with a scheduled exam on January 16th. When exam day rolled around I felt I had a good shot at passing. The usual light nervousness hit me as I sat down at the PC and began to read through the usual Cisco exam agreement, but I focused and started the exam.

Well, I failed. and not by much. I was devastated. I had felt so prepared, but some of the simulations just caught me off guard for some reason. Back in my car I scrambled to recall areas that I needed to re-focus on and take notes, but I was seriously considering walking away from this exam for a while.

With the encouragement of a number of friends and peers on social media, I decided to at least take a run at TSHOOT before the end of January. This would at least mean I had 2 of the 3 exams under my belt and I could re-focus on the new ROUTE exam in February.

TSHOOT

I scheduled TSHOOT for January 24th, and just in case, re-scheduled ROUTE for January 29th. Knowing I could cancel up to 48 hours in advance, if I didn’t pass TSHOOT I wasn’t going to take another run at ROUTE.

I didn’t study much for TSHOOT to be honest. I’ve heard from many people it’s the type of exam you can either do, or you can’t. If you understand the L2/L3 technologies behind the topology (freely published and available from Cisco) then it all comes down to whether or not you can troubleshoot in an orderly, systematic way that eliminates possible problems, and identifies the root cause of the issue.

I did run through some of the tickets in the Boson TSHOOT practice exams, more or less to get comfortable with the format. I also did a bit of review on the “dry” subjects that would likely be part of the multiple choice questions that focused on methodologies like ITIL, etc.

When I sat the exam on the 24th I didn’t think I could feel any more relaxed. They way the exam is formatted you pretty much know if you got the ticket right or not, so by the end of the exam I was expecting to see a perfect score.

It wasn’t perfect, but it was about as close to perfect as you can get. I think I may have gotten one of the five multiple choice questions wrong, but seeing a score that high was confirmation at least that I did in fact have the skills necessary to continue with this career path. I had been pretty discouraged after failing ROUTE yet again, but this gave me the boost I needed to take another run at it.

 Re-ROUTE

I didn’t see much of my family between the 24th and 29th, I was so focused on reviewing the areas I needed to improve to pass ROUTE. I felt really good going into the exam center on the 29th.

So good in fact that I think I got over-confident. I had some repeat questions and simulations from my previous attempt and when faced with those I had the attitude “Oh yeah, I know this” and didn’t spend enough time really making sure I was answering the question correctly. I got through the exam way too quickly but 100% expected to see a passing score.

Nope.

And it was really close, too.

Looking on the Bright Side

I passed two out of three exams in a 4 month period, ending up 2/3 of the way to completing my CCNP and adding the VCP5-DCV to my list of accomplishments. I think I’m okay with that.

I’ve already purchased the new Official Certification Guide for the new 300-101 ROUTE exam, along with some practice exams, and although there are some new topics on the exam I don’t think it will be all that different from the old exam.

Two goals for this year will be to complete the CCNP and then I would like to focus on VMware’s NSX product and perhaps write the VCP-NV exam. I’ll also have to think about upgrading my VCP certification to version 6 sometime.

Certifications aren’t easy, as anyone who has ever taken one will tell you. You have to be able to take a failure and learn from it, and not get too discouraged. I know I’ll pass ROUTE, I’m stubborn that way.

Wearing Many Hats

Posted on by
Jack Of All Trades

If you’ve read my bio you’ll know I am part of a 4 person IT department for a small rural public school division in northern Alberta.  Technically there are 5 of us, but does Management count?  No, I didn’t think so.

This brings some interesting challenges, one of which is perfecting the lost art of the IT Generalist.  The person who can do a little bit of everything.  The guy or gal who, even if they’ve never seen that particular problem before, has a fundamental base skill set that will let them logically and efficiently troubleshoot and bring the issue to resolution.

I like to think that’s me.  Although my primary passion has always been networking, I don’t always get to pick and choose my assignments.  I have a primary responsibility to ensure that all of the technology in our schools are working, first and foremost.  That means general help desk type work fixing the mundane….printers, wireless mice with dead batteries, staff and student logins, turning it off and on again, etc.  On top of that each of us within the department has a niche area that we specialize in.

The Network Guy

Let me introduce the team.  We have “Server Guy” who handles a wide gamete of tasks such as managing our Exchange environment, our VMware cluster, our SAN…  We have “Linux Guy” who really has several things he takes care of but they all run on Linux so I don’t know what those are.  He’s also kind of “Security Guy” because he handles things like our content filter and likes to port scan everything to try to find “attack vectors”, when he isn’t lamenting our lack of password complexity rules, or stringing together video cards to brute-force passwords using rainbow tables.  Right now we also have “New Guy” who we haven’t quite assigned any niche responsibilities to as we haven’t fully evaluated his skill set yet.  For now he’s a good minion and we make him climb ladders and run cable.

Of course there is also “Network Guy”.  That’s me.  In this environment that means LAN, WAN, voice and wireless, all of it.  I (try) to do it all. I work closely with “Server Guy” when we’re adding a new VMware host to our cluster ensuring we have switchports and VLANs ready for his needs, connecting the iSCSI SAN where it needs to go, etc. I work with “Linux Guy” when there are firewall changes that need to be made.  It’s often said that you can be great at one thing or good  mediocre at several things.  It begs the question “Can you know everything?”.  I certainly don’t, nor do I expect I ever will.  It absolutely makes it difficult to focus on a particular area of expertise though.

Don’t Make Me Pick

I love it all.  Well, for the most part.  Sometimes there are those really nit-picky problems with a certain networking technology that drives you nuts and if it wasn’t for that one thing you’d spend 100% of your time working on that discipline, right?  As technophiles/nerds/geeks we all have a certain amount of attention deficit, it’s a trait that is almost required to be able to keep up with the ever-changing landscape of the technology world.  This is a blessing and a curse.  After I’ve spent a week working on a nasty voice issue with Callmanager or Unity you can bet I’m feeling like a voice god and oh yeah I’m going to start on my CCIE-Voice right away!  Next week after spending several dozen hours with a spectrum analyzer and site survey tools trying to figure out why this one classroom has a large wi-fi black hole, I might be ready to challenge the CWNE, because clearly, 802.11 is what I was meant to do.  When you are forced to handle a variety of subjects like this it can be a daunting task to narrow the field when it comes to sitting down at your study desk or home lab and really deciding what you want to do.

Don’t get me wrong, I love the exposure and variety that comes with this territory.  Ultimately I have to be disciplined enough to focus on specializing in one area, without losing tough with the rest.  From my perspective, at least from my networking perspective, Routing and Switching is the base from which all the other technologies flow.  Being great at that fundamental level, I believe allows you to thrive in any subset of networking.  For me, that’s why I have renewed focus in working towards my CCIE R&S.

4 x CCIE

You’ve seen them, the folks sporting two or three, or even four CCIE certifications.  Will that ever be me?  No.  At least I don’t think so, not while I’m still married.  I have one goal and that is to get my CCIE R&S before I turn 40. I’m not going to tell you how long that is but I’ve got a long way to go since all I have right now is the CCNA and CCNA-Voice. I am about ready to write the 642-813 SWITCH exam towards the CCNP and will then move onto ROUTE and TSHOOT.

Fueled

For several reasons that I won’t get into with this post, I’m very motivated right now.  I have a plan, and I am slowly working towards it.  This blog is one piece in that puzzle and I hope to use it as a tool and resource to study and push towards my goal.  It’s a great community of people in this industry and I plan to leverage all of the resources at my disposal towards the task at hand.  Feedback, comments, advice are always welcome, and thanks for reading!

Origins

Posted on by

That’s it, I’ve done it.  I’ve added another time sink to a rather busy schedule.  *sigh*

I have two very simple objectives for this endeavor:

First – As a repository for the day-to-day tedium that I face as a jack-of-all-trades networker.  Let’s face it, I’m not getting any younger and sometimes I forget things.  It’ll be nice to have somewhere I can come and rediscover issues that might resurface on occasion. It should be entertaining when I Google something and my own blog post comes up and I don’t recognize it.

Second – I want my CCIE, dammit.  I’ve long been of the opinion that it was out of reach.  I didn’t feel I had the time or the energy to put into it (or the finances) and I’ve been content slowly studying here and there towards whatever certification seemed to be the most interesting at the time. Because I’m not really able to focus on one discipline (more on that in another post) I have a bit of ADD when it comes to networking and technology.  I’ll spend a week on a particular problem and decide that is where I want to focus my professional development.  For various reasons (also to be highlighted in another post, I have to stretch the limited content!) I’ve decided to stick with the fundamentals for now, and focus all effort on the CCIE R&S track.  This blog will serve as a study tool as I progress and take notes and blog about whatever it is I may have learned that day.  I’ve seen it done and heard it recommended as a great way to ensure learning retention, so I’ll try it out.

Most of what I post here will be for me, but perhaps I’ll work may way into the blogosphere a little at a time and gain some exposure for my random ramblings and incoherent jabber.

The good news is nobody can make fun of how I say ‘roof’ or ‘about’ in a blog, eh.

Why doesn’t anyone bug Greg Ferro over at http://packetpushers.net for saying ‘rooter’?