How To: TAC Support

After all my years in network operations having to navigate vendor Technical Account Centers, it was tough to figure out the best way for everyone to be efficient. Not just identifying who has access to open, close, or review a ticket but even administrative tasks like accessing license keys, device management, and other support functions.

If there’s an outage impacting your customers, what are you supposed to do as a network engineer? Just sit on hold for 1 minute? 10 minutes? An hour? How do you prepare for planned system maintenance, and what’s the best way to work with TAC?

Here is my advice broken up into several, operations, categories. These guidelines are critical to your ability to partner with TAC to address your issues. TAC should not be used as free consulting services; they are break-fix. Partner with your account team to identify options for consultative services. As a sales engineer, I often help my customers with design solutions and am always happy to do it.

Let’s get down to brass tacks.

TAC: Technical Issues

When you have to call in for an emergency or to figure out some service-impacting problem on your network, this is what I recommend to all of my customers. If you find something on the network that makes you think, “well that’s not right,” or “this is causing a user problem,” or “I can’t figure out what’s happening and I could use some eyes.”, it’s time to open a ticket. It’s an anomaly that you can’t solve yourself in normal network operations, and you need some help digging deeper.

TAC contracts have an SLA for interaction and escalation for all parties. If you aren’t living up to your end of the requirements, and TAC doesn’t receive responses, the case be closed. For example, certain levels of support tickets require customer engagement; a severity 1 may require customer availability to help run the problem to the ground, regardless of the time.

As a ticket-opening workflow, I’d recommend the following:

• Open your ticket through the support web portal, if possible. This will reduce your hold time on the phone. Consider this as a “fast pass” to the front of the line. There may be other customers with more urgent issues and TAC will triage as they do support.
• As you open an online ticket, make sure you provide an accurate subject line title. “Network is hard down”, does not help. This is especially true when you review TAC tickets over the last year for reporting purposes. “Switch stack failure – flooding all interfaces” in the subject line is much better when you search.
• Is the description field accurate? Describe all troubleshooting steps and symptoms. Remember the OSI Model? Describe your work in that method. We still need to know everything from how a host is physically connected to the applications being impacted.
• Upload logs, core dumps, accurate diagrams, and other documents that are germane to the traffic flow. The TAC engineer is going to have to understand your environment on the fly. Detailed information is extremely helpful, especially if the ticket is escalated.
• Add your account team as watchers to the ticket. Never, as a customer, suffer in silence! The account team is there to help support you, advocate for you, and bring in additional resources as necessary. They are not your first defense, but they are resources who want to help.

These are guidelines to help reduce the impact of a network outage. Outages happen and no vendor can do 100% uptime. The issue is how to address “things” when the “things” go wrong.

Planned Network Deployment

A planned network change is much different than an emergency outage. In this scenario, you’ve already considered the project results. You’ve already addressed your workflow that included a discussion with the Change Review Board (CRB) and all the teams are ready to go.

If you are planning a managed outage:

• Contact your account manager and sales engineer. Let them know, if they don’t already, what is being changed.
• Open a ticket with TAC approximately 2 weeks prior to the scheduled change. The TAC manager may be able to proactively schedule resource availability so the engineer can join conference bridge during the change.
• If you think something in the change request may impact your network, let the AM and SE know ahead of time. Your SE may be able to verify some of your changes or any particular bugs prior to your deployment.

The important thing is to let your team know what’s happening, ahead of time. If you don’t inform the team, any hiccup may suddenly become an emergency. If the system is informed, we can shorten the resolution time.

TAC: Administrative Issues

What happens when you need help, but it isn’t related to some router or switch that cratered? Maybe you have new hires that require TAC accounts. Maybe you have employees that hit the lottery and have retired and should be removed. Account clean-up, inventory, license assignments? How should you clean up access?

In the Juniper world, all you need to do is open an administrative ticket, and I’ll assume it’s similar for other vendors. These are for issues that let you do an audit, add/remove/change user permissions, install base reporting, and a litany of other options. The idea is that your network is still fine, you just need to see what’s going on with your account.

Closing

Most of this probably seems logical. Being on the OEM side of the house, it would surprise you how illogical this is. I think the thrust of this is to “do unto others as you would have them do to you.” If you’re at your desk and someone says, “Everything’s broken. Fix it.” you’d be rightfully irritated. You need data to fix a problem.

In this case, if you provide TAC with a date, time, and data related to the issue it makes resolution easier for everyone. Some issues may be much more complex. Start with the basics and be prepared to work with the account and technical teams.