Best TAC Services from Equipment Vendors

Mon Mar 11 14:04:52 UTC 2024

>It may be a pain in the butt to get Cisco equipment, but their TAC is
sublime.  If something is critical enough, and you push hard enough, Cisco
will move heaven and earth to solve your issue.

But is this not the problem itself?

Strap in for an "I remember when" ...
Once upon a time, I could call (specifically) Cisco TAC, knowing, without
any doubt, that my quality problem resolution was inbound, no questions
asked. That came to a crashing halt about 15 years ago when a TAC engineer
wanted to bounce our Voice VLAN SVI in the middle of an *airport* production
day. I about turned over my desk trying to wrest the remote control session
back from him before he hit enter on the shut. Since then, I have had to go
through a not insignificant evaluation period of TAC engineers before I let
them take control of a remote session, and it is now simply pure instinct
to log SSH sessions.

Fast forward and my user base is now ~45k people, not massive by any
stretch, but certainly not a small org, and we tend to buy Premium/Platinum
support on all of our critical applications. I truly do have to "push hard"
and long to get the attention of our support teams to get a seemingly
simple problem supported and solved. Our support is still in the dumper.
Take, for instance, a recent case with our replication/DR vendor. Our DR
environment has been offline for ~3 months, does that not scream
"critical?" And yet, we are still having engineers jump on a call to
collect .... the same data that the last engineer jumped on a call to
collect. One of our engineers, as has been not-so-subtly alluded to,
resorted to a screamfest to get the attention of TAC, and not surprisingly
that dressing-down got upper levels involved.

For good measure, major networking vendor possibly mentioned earlier spent
9 *months*, at the developer level, troubleshooting a multicast issue which
ultimately turned out to be PIM not configured on all interfaces in the
path. Yes, I felt like an idiot for not already checking that, but should
not have the first engineer on the phone asked this?

Admittedly, we are going through a rough patch in terms of support, but it
is not out of line with the past decade's experiences.

michael brooks

On Thu, Mar 7, 2024 at 12:47 PM Joel Esler <joel at joelesler.net> wrote:

> It may be a pain in the butt to get Cisco equipment, but their TAC is
> sublime.  If something is critical enough, and you push hard enough, Cisco
> will move heaven and earth to solve your issue.
> —
> Sent from my iPhone
>
> On Mar 6, 2024, at 13:42, Pascal Masha <pascalmasha at gmail.com> wrote:
>
> 
> For us this has been the experience to a point where 100s of nodes( from
> vendor x) had to be swapped out because no one had the patience anymore…
>
> On Wed, 6 Mar 2024 at 21:29, <sronan at ronan-online.com> wrote:
>
>> Interesting, this has never been my experience even with Cisco or
>> Juniper, have always been able to escalate quickly to engineering. I wonder
>> if it was related to the size of my accounts.
>>
>> Shane
>>
>> > On Mar 6, 2024, at 1:27 PM, Pascal Masha <pascalmasha at gmail.com> wrote:
>> >
>> > Thought about it but so far I believe companies from China provide
>> better and fast TAC responses to their customers than the likes of Cisco
>> and perhaps that’s why some companies(where there are no
>> restrictions)prefer them for critical services.
>> >
>> > For a short period in TAC call you can have over 10 R&D engineers and
>> solutions provided in a matter of hours even if it involves software
>> changes.. while these other companies even before you get in a call with a
>> TAC engineer it’s hours and when they join you hear something like “my
>> shift ended 15 minutes ago, hold let me look for another engineer”. WHY?
>> Thoughts
>>
>

-- 
This is a staff email account managed by Adams 12 Five Star Schools.  This 
email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the sender.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240311/79fae82c/attachment.html>