User poll: answering poor TAC cases

[Kaspars_Zibarts]

I know I have written before on similar topics (RE: case update quality) but I have to bring it up again:

last night a raised a case (maybe too short, but I already had spent 4hrs investigating it and it was 2AM..):

Title: SNMPv3 not working after R80.40 upgrade

Description: 

We have problems monitoring our VSX after upgrade to R80.40 T78 (from R80.30 T215)
When trying to snmpwalk, you get error snmpwalk: Unknown user name
We have narrowed it down to the fact that SNMP engineID is not the same for user and agent in /var/lib/net-snmp/snmpd.conf:

usmUser 1 3 0x80001f8880154d8c7e9204925f "bla" "bla" NULL .1.3.6.1.6.3.10.1.1.3 0xea .1.3.6.1.6.3.10.1.2.4 0x91

oldEngineID 0x80001f8880ca6c8f31cc04925f

SNMP agent has been restarted and user deleted and recreated without success.

I received following questions from TAC:

1. Hotfix installed: Please run “#cpinfo –y all” and provide us the output.
2. Has this configuration ever worked correctly?
3. If it has previously worked correctly, what changes were made on or about the time that problem was first experienced?
4. How long has this problem been occurring?

Was I correct to respond with a message that all questions had been answered already in initial submission? 

I want comments from both - CP TAC and customers:) I'm ready to take my words back if I was incorrect, just felt odd set of questions when all was "laid down" in front of you. Well, I thought so. .🤔

[G_W_Albrecht]

This is possible and does occur with first support level - 1. - 4. are the questions you can always ask, so they do 😎. And that they neither read nor understand the case summary sometimes is also true, takes time to get to a higher support level...

[fwmeister]

Annoys me every time. Strictly speaking you were only partially correct. No cpinfo -yall but the info is implied by R80.40 T78 , assuming no errors, of course    Smells like SLA gaming. However, they have procedures and they seem to have little room for maneuver. No cpinfo, no next level.  Just got to live with it, I suppose. 

They could also improve the beyond junk to ask those questions (just a few tick boxes and a field for the cpinfo -yall .) 

[SharonElmashaly]

Kaspars, all,

Thank you for sharing this!

Please share with me the SR numbers so I can look into it and learn what needs to be improved.

My direct email is elmashaly@checkpoint.com.

Regards,

Sharon Elmashaly

VP, Customer Support

[Bob_Zimmerman]

1. Check Point does seem to have multiple releases with different "take" numbers which don't correspond to the jumbo numbers. I sure can't be bothered to keep track of all those, so maybe the first TAC rep saw "R80.40" and didn't interpret the take as a jumbo. Maybe "R80.40 with jumbo 78" would be a better way to style the version?
2. Your first message certainly implies the configuration worked before, but doesn't necessarily outright say it. Somebody who upgraded from R80.30 to R80.40 then tried using SNMP for the first time might write a similar message.
3. Again, you imply it worked before the upgrade, then the upgrade was performed, then it stopped working, but it's useful to confirm absolutely.
4. Not sure about this one.

When I was in the TAC, I had a lot of customers who included extraneous information, and who didn't include any sort of timeline or what they are observing. One guy opened a ticket and all he would tell me is "It doesn't work." It was like pulling teeth to find out what "It" was (a VPN-1 Edge), and I never did find out what "doesn't work" specifically meant. Is it on fire? Do any lights turn on? Is it just not letting him log in to the web UI? Is it not handing out DHCP addresses? Is a firewall rule not working as expected? No idea.

While your message indicates technical ability (and most people in the TAC probably wouldn't have the context of your forum presence), I can't exactly fault the TAC for wanting to get a definitive timeline. They could definitely have asked the questions in a way which showed they had read what you wrote. For example, they could have written a summary of the situation, asked you to confirm it was correct, and suggested the next troubleshooting step with the assumption it was. Not sure how much time the frontline team has per ticket they have to handle, though.

[HristoGrigorov]

I had the best experience with IL TAC. Guys there are always top-notch master ninjas. Never wasted my time asking this and that. And I am talking about T3 engineers not R&D. Once, one of them told me there is no way to engage R&D without cpinfo collected. I am surprised actually that you were not called on the phone. They usually do that initially when SR is assigned to them. Go figure...

[Michal_Gans]

We have similar experiences too often in this days (like after 14 days of communication with SR owner he just recapitulate all information from initial submission). I think that TAC engineer technical skills variate a lot (even on same level of support). Also there is a big difference between TACs.

That remines me, is there any possibility how to target new SR to specific TAC?

[Kaspars_Zibarts]

Apparently you need to log the case right time of the day and right day of the week 😎 can't remember actually which one it was though..

[genisis__]

In our case all our cases are routed to India TAC and we have no choice in this matter, and it takes days for them to come back to you.

Feels like they get the basic information, then log an internal ticket with Israel who then come back to them with the own OLA timescales.

I for one would like order to be restored and my tickets to once again flow to Israel or US TACs.

[Vladimir]

It really is a very situation-specific issue. Sometimes the customer fails to do the prepwork and supply sufficient information at the time the SR is opened. I normally do that rightaway with full-blown cpinfo upload to SR just to get it out of the way or to reference in the future communication.

But even with this done and the relevant (from my point of view) information supplied, most of the time it takes two to three escalations to get to the engineer versed in the specific subject. If not resolved during particular escalation session and if you are left with the changes pending due to the clients maintenance windows, tough luck. You are likely going to work with different engineer when you are ready to proceed with the next steps.

My personal preference of TACs is Ottawa, IL, Dallas in terms of ease of communication, attitudes and capabilities. IL is rearly getting involved (for US cases), unless it is R&D issue, but if you'll get to it and if your house is not burning down, you will likely have a resolution in the next JHFA.

[the_rock]

Too many cases to list...

[genisis__]

In my experience TAC from Israel and Dallas have been pretty good and passionate about helping, however some of the things you have mentioned, sadly I would have to agree. 

TAC used to be the main selling point for me.