You sir, not wrong.
> On Mar 11, 2024, at 10:04, michael brooks - ESC <michael.bro...@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 <j...@joelesler.net
> <mailto:j...@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 <pascalma...@gmail.com
>>> <mailto:pascalma...@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, <sro...@ronan-online.com
>>> <mailto:sro...@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 <pascalma...@gmail.com
>>>> > <mailto:pascalma...@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.
