Best TAC Services from Equipment Vendors

Tue Mar 12 00:19:29 UTC 2024

You sir, not wrong.

> On Mar 11, 2024, at 10:04, michael brooks - ESC <michael.brooks at adams12.org> 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.
> 
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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/5f8da2d5/attachment.html>