Network engineers deal with technical support frequently. That’s the nature of the networking business: the products often don’t work as advertised or break down under their own complexity. Throw in some ambiguous documentation that leaves you scratching your head, and you’ll finally resort to opening a case with the vendor to resolve the issue. In theory, the vendor’s crackerjack support team will come up with a resolution to your quandary. You might think of them as the oracle – the mighty ones on high who have the big answers to your difficult questions. In real life, this is not always the case. In fact, I think it’s better to go into a tech support exchange a bit defensively. To keep your guard up.
One consideration is that no matter what tech support tells you to do, ultimately, *you* carry the burden of responsibility for carrying out their instructions. Therefore, each bit of advice, recommendation to upgrade, and request to run a diagnostic tool comes with an asterisk next to it. That asterisk references a footnote that says, “Sure. Do what I say. But if it craters your data center, it’s not my fault.” And in fairness, how could it be? How could a tech support engineer know enough about your environment to be able to recommend any particular action with 100% confidence? You must take the responsibility of understanding exactly what the support engineer is asking you to do, and then making your own determination regarding potential impact. An attitude of, “I trust them. They’re tech support. They’re supposed to know. That’s why we pay for it,” is insufficient, in my opinion.
Why would trust in a support engineer be misplaced? Well, not all tech support engineers are equal in experience or ability. Therefore, you just don’t know what you’re going to get. Recent experiences of mine have demonstrated engineers with expansive and intimate product knowledge who were a joy to work with, as well as engineers whom I’ve had to
nudge shove to get going in the right direction. Assume nothing. You could be talking to a product genius. Or you could be talking to someone who just starting taking calls yesterday.
Let’s assume that after working with an engineer that you have no confidence in them, however they might have earned your mistrust. What can you do about it? The simplest thing you can do is ask for an escalation. Most service organizations I deal with have a policy that supports this. Certainly this policy could be abused by customers who reflexively ask for escalated service no matter what the issue, but in the few times I’ve requested escalation over the years, I’ve always gotten it. What does escalation accomplish? Ideally, your issue is moved up to the next tier of support: from first level to second level. When reaching escalated support, you should be dealing with an more seasoned engineer who has seen more issues, deeper knowledge of common customer problems, and potentially access to lab gear to replicate your issue or vet ideas.
Even if you’re dealing with the greatest support engineer your vendor has, there’s a burden on you to articulate the problem to them clearly. Your chances of talking to the right engineer and that engineer knowing how to deal with your problem improve greatly if you’ve given them the right information.
- Create the proper context. Did this problem happen after you did a software upgrade or unexpectedly? Does the problem show up consistently or sporadically? Is there one user with the issue or a thousand? Are there unique circumstances that might be relevant (such as an unusual user OS, the fact that you’re being DDoS’ed, one power supply in the device is fried, etc.)?
- Use detail to articulate the problem. Don’t say “high availability is broken”. Say, “We noticed that our HA is broken because the primary and secondary units are complaining about blah in the log entries, which I’ve attached. We also had both boxes go active, and had to shut one down to restore service. We verified heartbeat and all network connectivity, so we’re stumped. Please help.” And if you got into a specific problem even more deeply, don’t hold back. Add all the information you gathered. “Here’s a packet capture that shows the issue I’m describing. Take a look at the HTTP session starting at packet 58, and then compare to this other capture I took when things were working right.”
- Anticipate what else the vendor will need to start reviewing your issue. A simple network diagram with device IPs might be helpful. Logs relevant to the issue along with device configuration is probably useful. Cisco usually wants the output from a “show tech”. F5 usually wants a “qkview”.
The last point I’ll make is that you need to keep up with your open cases. A sad reality of modern tech support organizations is that often they’ll close tickets, even if unresolved, if they wait too long for you to respond to a question. If your case isn’t urgent and you’re busy (aren’t we all), you might skip updating a ticket for a day or so. I find that you need to stay in touch, or risk having to start the process all over again. Twice I’ve had cases closed on me because I didn’t touch a ticket that was waiting for my input in a 24 hour period. While I find this practice to be horrible customer service, that’s increasingly just the way it is. Therefore, if you open a case, be ready to put the time in to get it resolved quickly, even if it isn’t an urgent matter.