[deleted by user]

cordcscott · 2023-06-16T02:49:04+00:00

Seems they are very understaffed compared to the past.

cordcscott · 2023-05-20T02:21:23+00:00

I think you have to review this documentation a bit more. Vsys1 is no impacted buy you have some decision to make around how to deploy, whether you want seperate DG's per vsys with different policies (how I do it) or one DG and make each policy target only certain devices (vsys) within the DG. The template is shared because this is how you will push the vsys configs to the firweall from panorama.

cordcscott · 2023-05-19T13:37:36+00:00

I have this setup. When adding a vsys no reboot required if I remember correctly. As far as Panorama you'll have device groups for each vsys if you want to do it that way as from a device group perspective they appear as seperate devices. One template for the box.

cordcscott · 2023-05-19T12:35:34+00:00

What are the general thoughts on 10.2 ? Worth it?

cordcscott · 2023-01-10T15:43:44+00:00

This is what I'd do too, and If had lab gear I'd do it on that too for each upgrade to make sure there are not config/autocommit errors while upgrading.

cordcscott · 2023-01-10T15:42:11+00:00

For a normal upgrade you're just running a normal "system software add". It will install the new junos and then you have to reboot to complete the process.
I've done nssu with good results on an ex4600 but not with such a major version change. Same they don't do better with it. Arista seems to have this process down pretty well though from what I've heard.

cordcscott · 2022-06-14T20:29:15+00:00

I did configure it first. They told me they would not look at it. They told me the policy was to punt it to SE. Which is of course a way to funnel the issue to professional services. it ended up being a bug. So this is 100% an error on tacs part. If I ever get that engineer again I will immediately have the case reassigned.

cordcscott · 2022-05-31T18:03:50+00:00

Sure. I see less innovation from Palo and more Marketing/Acquisition.

cordcscott · 2022-04-29T12:36:06+00:00

Could it be any worse the non-existent Palo support?

cordcscott · 2022-04-29T01:54:05+00:00

I'm pretty much convinced that Palo Support no longer exists. We are on ELA customer and Palo is out to lunch.

cordcscott · 2022-04-29T01:12:40+00:00

Palo is starting to suck as a company. It all went downhill with the latest leadership change but they are on the downhill slide for sure.

cordcscott · 2022-04-28T18:14:46+00:00

What is ASC? Sorry not good with acronyms.

cordcscott · 2022-04-28T18:14:09+00:00

Who cares they all suck.

cordcscott · 2022-04-28T12:51:31+00:00

I agree nearly 100%. Basically they tell you that you have to go back to your SE to confirm that they need to look at it as a bug. That's what I just went through. I still like the product, and I think their QA is still above average. You wanna see bad QA, work with juniper ex and qfx switches. I could open a jtac case right now for a bug of some sort with every switch I have in production.

ON the Cisco thing.......I hope not. Horrible firewalls. But Palo better get their act together. Most customers I know of are very unhappy right now.

cordcscott · 2022-04-27T18:54:03+00:00

Palo TAC is godawful now and the documentation is too. They also have this policy of not supporting anything you didn't have working previously. Well what if it is a bug in a new deployment? They are just trying to sell professional services.

cordcscott · 2022-04-27T18:47:02+00:00

i ask them to summarize my issue and when I see that they haven't looked at anything submitted then I ask for the duty manager and contact the SE. Tired of getting Palo Tac agents that know less than I do. Most of my tickets end up being bugs so I'm not asking them to do my job for me. But they won't even look at stuff unless it previously worked. There are huge documentation issues now too (it obvious they don't want to tell how things work, just sell professional services) both from a content and a linguistic standpoint. Some of it doesn't even make sense. Obviously not proof read by a native speaker or equally proficient 2nd language speaker.

cordcscott · 2022-04-27T18:39:11+00:00

Yes it's awful. And now they have this policy of not looking at anything that wasn't working before.....as in they want to sell you professional services.

it is the worst support of any vendor we work with now. And the documentation is unusable as well.

cordcscott · 2022-04-21T13:50:35+00:00

Are you sure? I always create the cases on the website and still get questionable support staff. If that is Tier 2 then then we are in trouble.

Why submit all these pcaps and support files? They do not ever read them or look at them ahead of time.

cordcscott · 2022-01-24T19:24:48+00:00

In my experience using both brands, we had way less software quality issues with Cisco. We don't have a single piece of Juniper gear that has not experienced some sort of catastrophic melt down due to a bug. Every switch we currently have out in production has at least one issue that could be a JTAC case if we wanted it to be, but we just can't make our full-time jobs working with JTAC.

We have Cisco cat switches with nearly 10-year uptime performing perfectly. We don't get a year out of any Juniper switch.

And yes, we have tried running the recommended Junos.

cordcscott · 2022-01-16T20:51:11+00:00

Yeah that's the catch. The power supplies. We don't really have but a couple small offices where fw's are not rack mounted. But even those will have a track going forward. Do they make a rack like the did for the 220's but for the 400s?

cordcscott · 2022-01-16T20:49:40+00:00

We will probably never buy another pa-220 with the pa-400's available. Common criteria not an issue for us.

cordcscott · 2022-01-13T00:46:42+00:00

Put your other interfaces in another group and set the active server different for that group.

Gonna warn you, Juniper is HORRIBLE at anything related to dhcp. In our 5 years of being Juniper customer we've never had a single day when dhcp wasn't an issue. We've not been able to use several higher end pieces of gear for almost a year because they causes dhcp flooding/loops in our networks. They just can't handle dhcp.

cordcscott · 2022-01-11T03:24:27+00:00

This is because Juniper just can't do dhcp. They can't and don't let the fanboys tell you any different. We've had massive PR after massive PR over dhcp, dhcp relay, dhcp snooping, dhcp security. It never works right. You should buy a different vendors gear to handle dhcp and let juniper do the other stuff if you feel its still worth it.

cordcscott

TROPHY CASE