TAC Tales #19: Butt-in-Chair
This one falls into the category of, “I probably shouldn’t post this, especially now that I’m at Cisco again,” but what the heck. I’ve often mentioned, in this series, the different practices of...
Read MoreCategory: TAC Tales
TAC Tales #18: All at once
The case came into the routing protocols queue, even though it was simply a line card crash. The RP queue in HTTS was the dumping ground for anything that did not fit into one of the few other specialized queues we had. A...
Read MoreTAC Tales #17: Escalations
When you open a TAC case, how exactly does the customer support engineer (CSE) figure out how to solve the case? After all, CSEs are not super-human. Just like any engineer, in TAC you have a range of brilliant to...
Read MoreTAC Tales #16: To microburst or not to microburst
I’ve mentioned before that EIGRP SIA was my nightmare case at TAC, but there was one other type of case that I hated–QoS problems. Routing protocol problems tend to be binary. Either the route is there or it...
Read MoreTAC Tales #15: Loopy
I’ve mentioned in previous TAC Tales that I started on a TAC team dedicated to enterprise, which made sense given my background. Shortly after I came to Cisco the enterprise team was broken up and its staff distributed...
Read MoreTAC Tales #14: Stuck in Active
Everyone who’s worked in TAC can tell you their nightmare case–the type of case that, when they see it in the queue, makes them want to run away, take an unexpected lunch break, and hope some other engineer grabs...
Read MoreTAC Tales #13: All Zeros
A common approach for TAC engineers and customers working on a tough case is to just “throw hardware at it.” Sometimes this can be laziness: why troubleshoot a complex problem when you can send an RMA, swap out a...
Read MoreTAC Tales #12: SACK of trouble
When I first started at Cisco TAC, I was assigned to a team that handled only enterprise customers. One of the first things my boss said to me when I started there was “At Cisco, if you don’t like your boss or your...
Read MoreTAC Tales #11: Full up
No customer is happy if they have to reboot one of their Internet-facing routers periodically, and this was one of our biggest customers. (At HTTS, they were all big customers.) This customer had a GSR connecting to the...
Read MoreTAC Tales #10: Out to Lunch
When you work at TAC, you are required to be “on-shift” for 4 hours each day. This doesn’t mean that you work four hours a day, just that you are actively taking cases only four hours per day. The other four...
Read MoreTAC Tales #9: Left Hanging
When I was still a new engineer, a fellow customer support engineer (CSE) asked a favor of me. I’ll call him Andy. “I’m going on PTO, could you cover a case for me? I’ve filed a bug and while I’m...
Read MoreTAC Tales #8: The problem with data
My job as a customer support engineer (CSE) at TAC was the most quantified I’ve ever had. Every aspect of our job performance was tracked and measured. We live in the era of big data, and while numbers can be helpful,...
Read More
Recent Comments