Best TAC Services from Equipment Vendors

Mon Mar 11 14:41:17 UTC 2024

You are missing the point, we opened the case 3 months ago

michael brooks

On Mon, Mar 11, 2024 at 8:24 AM <sronan at ronan-online.com> wrote:

> To be honest, if your DR environment has been offline for 3 months and you
> are just now opening a case, I would not consider that critical.
>
> Shane
>
> On Mar 11, 2024, at 10:08 AM, 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> 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.
>
>

-- 
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/40b33bed/attachment.html>