Prisma SD-WAN Reviews

Prisma SD-WAN is cost-effective and easy to manage. We have replaced all our MPLS connections with dial-up internet links. This will reduce our costs in place of ISP and is easy to manage. We can route the traffic based on the application. Sometimes, we used to route the package based on the user because some users want to use the internet. We are effectively using the solution for path manipulation for the users. We also have multiple tunnels whenever there is an issue or drop with one of the ISP tunnels.

We have a single dashboard to view all kinds of analytics. If we make Prisma SD-WAN as analytics, we can only see what kind of traffic is going and how much bandwidth it is utilizing. We can also see if there is high utilization from any particular link or application. Otherwise, we can configure Prisma SD-WAN as a control mode to use it as a routing protocol and for analytics. It gives you more insights about what kind of traffic is going, how much the consumption was, how we can reduce that consumption, and how we can apply that quality of service. If one of the sites is accessing more teams, our bandwidth will be utilized as a platinum application so that most of the bandwidth will be utilized for the team. Unlike traditional networks, it is very flexible, and based on the kind of application we are using, our bandwidth will be utilized.

It is flexible to use the internet connection via local breakouts without going to data centers. We don't need to install firewalls within the site to inspect the traffic. It will forward the traffic directly to the cloud so that the inspection will happen there for any unknown or unwanted traffic. This will also reduce the cost because we are not managing side-by-side firewalls. Your traffic will not go to data centers to inspect the outgoing traffic.

Prisma SD-WAN's technical support should be improved. When we have some issues, the technical support should be available on time, and the engineer should join to help us. It can increase the bandwidth capacity for some of the small branches. A warning message comes to us to notify us that something is going wrong, but we cannot understand that information.

Prisma SD-WAN can be automated so that our network will be faster and our work will be reduced.

My team has been using Prisma SD-WAN for the last two years, but I joined this project for the last six months.

Prisma SD-WAN is a stable solution.

I rate Prisma SD-WAN a seven or eight out of ten for scalability.

Prisma SD-WAN's support is good, but the engagement of the engineers gets delayed, or the right person might not join the call. The information should be made available on time. So we require very knowledgeable people in technical support to improve the customer environment and the network performance, as well as the operation team's knowledge.

Neutral

Prisma SD-WAN’s initial setup is very straightforward.

Prisma SD-WAN's deployment is completely based on the process. For example, one box running with a little older version was migrated from one of the sites to our site. So, it is running with a very older version, and our devices are running with a very higher version. Sometimes, the internet connectivity will not come up, and we have to connect to that Prisma cloud to get the diverse version to upgrade it.

Sometimes, the upgrade might take some time due to the heavy load on the cloud or a congested ISP. Generally, if you go for a simple configuration, it won't take much time. You simply configure basic ISP settings, and it will get the internet connection. It might not take more than 45 minutes.

You need console access. It's based on the ISP. If you have a dynamic ISP, you connect that ISP to one of the WAN links, and it'll get the IP address. So if you get the IP address, it automatically shows it online in the system in your domain. If that ISP is not dynamic and we have to manually configure the IT address, we have to take the console access. We need help from site IDs. It is not a drawback of the project, but it is something dependent on the ISP.

We used to open tickets because it was a completely new environment for every engineer and because it was hosted for the last two years. Whenever we had such challenges in the network at the architect level, we used to open a ticket. So we request the engineer to join and discuss our plans for what we want to achieve. They will help us with most things. Sometimes we might see some failure of changes as well, but most of the time, we succeed when we involve this Prisma SD-WAN tactic.

Prisma SD-WAN has layer seven capability to check how the traffic is going, but unfortunately, I do not have in-depth knowledge of that process. We have a workflow at the layer seven level. They have all kinds of analytics at layers three, four, five, and seven.

Prisma SD-WAN can automate many things, but we also need to have that kind of testing environment. We never use it in our environment because of our daily activities.

Network automation is the biggest thing in current evaluation in the network world. We have thousands of switches and network devices where we need to configure multiple configurations. So if you have automation in place, it will reduce the timeline, and we won't miss anything. If we do it manually, some people might properly follow the process, and others might not. So if the automation comes in place, only one person can push all the configurations to the respective devices so that we follow the standards.

We never tried using automation for network troubleshooting, but we tried much automation while provisioning some networks, like new installations. Troubleshooting will come with the packet capture directly. We do some packet captures, but as of now, we didn't automate those. We are looking for automation for provisioning things when new sites come into the picture. We want to automate without doing manual configurations.

The alarms make sure that we are checking everything on time and give us some flexibility to ensure that the device will not go down. So, the alarms might not reduce in the future, but they will give us a trigger point so that we check immediately what is missing. Those are mandatory alarms for CPU alerts. Every time there is a high utilization on the box, it will show some trigger. We'll understand why the CPU utilization was happening. They will show some information on the network regarding why the CPU is being utilized. We can ensure not to repeat that kind of scenario in the future. Sometimes, if the bandwidth utilization from the users is high, we cannot control those alerts. But when such kind of traffic utilization is high, we can increase the bandwidth so that we can reduce those alerts. If you take those steps effectively, then it will definitely reduce your alerts.

Prisma SD-WAN incorporates policy control for event correlation and analysis, which affects our admins' control over events generated on our network.

We have many path policies and QOS policies. It will show which is the better path that needs to be selected while the traffic was going. It also shows the next backup path, if one of the paths fails. We have to configure manually with the path policies, what kind of application requires minimum amounts of bandwidth. Those path policies need to be applied to the iron box. Whenever a user sends traffic via the iron box, it will select those path policies to make an effective decision.

Prisma SD-WAN's policy control for event correlation and analysis helps admins pinpoint issues. Whenever we log in and check, users complain about issues related to packet loss, and we have to load share the network manually. These automated path policies affect configurations. Sometimes, if the internet link keeps on disconnecting, we can see something on the analytics screen that packet drops are high.

Unlike traditional networks, you don't have any kind of analytics. The customer might not take third-party analytics because of the cost. So we don't know the visibility of checking those WAN links, and we simply rely on the ISPs to understand how the WAN link is working. They tell that there is no issue with the WAN links and everything is fine.

There might be some milli-seconds of packet loss which cannot be shown on the ping reserves. So this analytics gives a lot of information to the administrator to understand the issue. We can ask those people to understand this issue, and they can resolve those things by seeing those analytics. Prisma SD-WAN is the web solution that helps the administrator to understand the issue and resolve it.

Prisma SD-WAN enables branch services such as networking and security to be delivered from the cloud. They also have virtual solutions that they can provide, but we never use those virtual solutions.

Prisma SD-WAN is a very good product. It gives lots of benefits to the enterprise network by deactivating the costliest MPRS networks. Even non-technical people can understand the packet flow and easily see what is happening by seeing the analytics of the link.

Overall, I rate Prisma SD-WAN an eight out of ten.

Prisma SD-WAN is intuitive. We have a better idea of the different tools we can use and jump between the menus quickly. 

The tool needs to work on price and complexity. 

I have been working with the product for about two weeks. 

I rate the product a seven out of ten. 

Initially, we deployed it in a hybrid fashion and were utilizing the Internet, but we had MPLS being defined on our WAN routers as well. While the MPLS link wasn't terminated on Prisma SD-WAN, it was helping us route traffic through it. This made the WAN routers kind of redundant since the solution creates its VPN tunnels from Internet links and we have data center devices where it establishes its tunnels. Therefore, if any MPLS goes down in any of our branch offices, it helps us route the traffic through them. 

We have a site where we deployed its VPN tunnels through MPLS, not just the Internet. However, we still have some BFD issues there. Right now, we are transitioning our sites to all Internet circuit sites. We are deploying our Prisma SD-WANs there. So, it is just doing VPN tunnels through the Internet with no MPLS on all new upcoming sites.

We are transitioning into AWS.

When we deployed CloudGenix, we had Internet and MPLS links. We had to manually transition our VPN tunnels and shift the routing from MPLS towards the Internet in case our MPLS went down. During that transition, there were human errors. Sometimes, there was downtime, where the MPLS went down, and people were on a short coffee break when services went down. Then, people had to scramble, come in, and put in commands, typing in everything to just fail over the traffic from MPLS to the VPN tunnels. However, Prisma SD-WAN has taken that out of our minds, because it does that itself. It is pretty smooth. As soon as it analyzes that the MPLS has gone down, it starts to advertise branch routes to others through Internet VPN links. So, it has saved us a lot of time, effort, and cost from this aspect.

We haven't experienced anything ever go down. It sends traffic out, regardless of the fact that we aren't maintaining any SLAs on the Prisma SD-WAN front, because it is doing routing only. There is a traffic flow log where we can clearly see if it wasn't able to reach an AWS-deployed application over the Internet, then it sends the traffic over to MPLS. That transition is very smooth. It's not like we need to go into the aspect of saying that Prisma SD-WAN took time to fail over the traffic because it couldn't understand the cloud-based services. Therefore, we never had a need to define any SLA for its transitioning and work.

It decreases alarms in terms of network link failure. Many times earlier, we could miss some traffic that was being sent over MPLS. For example, if we had 15 applications routed over MPLS and that MPLS failed, we had to manually route all those back towards the Internet. Many times, we missed some applications and that resulted in new tickets trickling in. We then had to identify if the traffic was taking a default routing earlier. In that case, it was working over MPLS, but since MPLS is down, we have to now put in another route and advertise it over BGP so it is reachable over VPN. With Prisma SD-WAN in play, we don't need that because it analyzes applications, like Layer 7 applications, and transitions them based on our policies. We do not need to worry that we may have forgotten something or that Prisma SD-WAN may forget to fail over some stuff if MPLS goes down.

Its valuable features are its use of VPN tunnels. You don't really have to tinker with anything.

If the MPLS goes down, there is a really smooth transition for a branch site to take traffic over the Internet. It will advertise the routes of that site in a jiffy. 

Its VPN tunnel creation is smooth. I have never faced any issues where it wasn't able to establish its VPN tunnels or had trouble doing negotiations. That is pretty awesome. 

Prisma SD-WAN provides deep application visibility, along with Layer 7 intelligence. We can manipulate traffic on Layer 7. It understands the algorithm, packets, and which application it is, according to the traffic going through it. For example, we usually have traffic going out for Zoom. We wanted to understand whether Zoom had some new public IPs every now and then. In its early years, Prisma SD-WAN didn't have the correct signatures to understand that it was a Zoom application, but they have continued to improve it. They published that Prisma SD-WAN can now understand Zoom, as per its Layer 7 signatures. Now, we can pin its traffic over the Internet only. It analyzes the deep packets going out on an application basis. We can manipulate it as well on the affinity. So, we can state, "I do not want the video traffic to be going over MPLS if my Internet goes down. Just shut it off."

Previously, they were sending traffic from their data center primarily over VPN lines. This was the default routing behavior for them. We had routing policies in our branch offices, which basically did the routing on outgoing traffic regardless of where the traffic was received. If we had a policy that stated, "Do not send it back over the VPN. Send it over any other link." The data center understood that, because it has persistent routing enabled. It would send it over that link, then start sending it back over the link with the routing policy in effect. Recently, regardless of our routing policy, the data center devices keep sending traffic on the VM and our return traffic is sent according to our policy. This can now have some effect on stateful devices, which are in between, because they see traffic going in from another link and coming out from another link. They sometimes change their routing design and manipulations with their firmware, which shouldn't be happening. 

We are incorporating their zone-based firewalls. Prisma SD-WAN has limited documentation on how it manipulates traffic, e.g., how it is interacting with TCP and UDP. We recently had some traffic that was black holing. We literally had to do packet captures to see that the new zone-based firewall, which runs on top of Prisma SD-WAN, was causing issues.

It is growing in its routing policy. Its transitioning is pretty smooth, but its maintenance is what takes time and understanding. From the maintenance aspect, if there are any issues caused by Prisma SD-WAN, you really need to dig down and troubleshoot. Many times, it is not evident from its traffic logs whether you can assert that Prisma SD-WAN is doing something wrong. You need to understand the interactions between Prisma SD-WAN and other networking gears. When you need to troubleshoot something, then you really need to dig down. Two or three people have needed to do packet captures so many times on different devices. So, if you are on a shift and four people are working, and there is a major routing issue, then you need at least two people to work on the routing issue and the other two people to cover the day-to-day normal operations.

We don't want our MPLS link to get saturated if the Internet goes down. This minimizes other application bandwidth utilization. So, it analyzes Layer 7 applications as well, e.g., we saw that with Zoom. We can also limit some web-based public IPs based on regions. We can apply a policy that states, "If it understands that this application is Zoom and the outgoing traffic is going towards these public IPs, put a strict affinity on them and just pin them on an Internet link. If the Internet goes down, then just drop those packets."

We are deploying the new zone-based firewall of Prisma SD-WAN into our network. The original CGX appliance and the new firewall do not always go hand to hand, because the former one is a stateless device and their new firewall is stateful.

If an event occurred and Prisma SD-WAN finds that event, it defines that in its dashboard. However, there is a gripe that it is not very good at defining traps and sending alerts over to third-party monitoring software. For example, if you have SolarWinds or LM in your environment, and you have people who are watching over those monitoring appliances' GUIs. Sometimes those alerts are missed because they are present over in the Prisma SD-WAN dashboard, but Prisma SD-WAN does not have that flexible communication with monitoring appliances. Therefore, we have experienced stuff where some traffic was pinned over MPLS and there were no secondary paths defined for them. 

The MPLS went down and failed over everything to the Internet. Since we had it set for certain kinds of traffic to be pinned over on MPLS only, or the dedicated circuit, it didn't actually put out an alert. If you check its traffic logs, it states there that the L3 path reachability for this traffic has been lost and is being dropped. The policy control is a bit lacking with the event correlation because we do not get active alerts on our monitoring applications. We need to go into Prisma SD-WAN traffic flow logs to see if certain flows have been dropped.

We have been using this solution for the past four years. 

It is far more stable now than it was in its initial years. We used to face TCP proxies getting hung and their internal processes getting stuck. Our routes were not advertised in the first year of our Prisma SD-WAN being deployed. Those issues have been smoothed out and we no longer face them. Each passing year, we see less issues with Prisma SD-WAN. As of now, we seldom have any Prisma SD-WAN issues. So, its stability is growing. However, when you throw into the picture the new Prisma SD-WAN appliance, which is a zone-based firewall, then we have some complications like we had when we first deployed Prisma SD-WAN.

The downtime has been zero, if we have MPLS and Internet at our site. It has transitioned everything smoothly over the Internet. If something previously took an hour, then the solution reduced that amount of time to just 10 minutes because it fails over everything to the Internet.

We might start upgrading all our Prisma SD-WAN devices in the next two or three months.

Prisma SD-WAN is good when it comes to supporting large, complex network architectures. We have global offices and data centers, where it has been working awesomely at catering the traffic. We receive the support from Prisma SD-WAN on time as well. So, the solution can be utilized in any type of scenario: big firms, data centers, small firms, etc.

It is pretty scalable. The device spans across four data centers. It is now deployed in our AWS data center as well in a virtual image. It is deployed at 27 different locations in a HA manner.

When they were just CloudGenix, we had awesome support. The people were candid in answering questions. Many times, we had the co-founders of CGX joining us on our call to understand what the issue was and helping us out. When it moved over to Palo Alto, the usual tech scenario came into the picture: 80% of the time, you get a person who is pretty knowledgeable about the stuff, but 20% of the time you may get a person who does not know that CGX has been adding to the tech. So, the tech is knowledgeable 80% of the time, but 20% of the time, we find ourselves giving directions to the tech rather than getting directions from them.

Under Palo Alto, I would rate their technical support as 8 (out of 10). Before Palo Alto, I would rate them close to 9.5 (out of 10).

GRE tunneling was always present, but they added some other signatures for Office 365, etc. They are doing that on the back-end, then they publish those in subsequent firmware versions. It is like their Prisma SD-WAN stack team is analyzing the traffic going out. They check all the tickets being sent to them for traffic that is not acting properly or the solution is unable to identify. I do not believe the device itself has machine learning where it checks signatures. For example, if we define some traffic between public and private IPs to be real-time traffic or RTP, then it understands that and keeps those signatures as RTP traffic. There is no machine learning defined on the box itself. It is the back-end team who defines the signatures, then rolls them out.

Positive

We were previously using a legacy system. We had Cisco routers in place. We were defining routes, advertising it out via BGP, defining our own VPN tunnels to different sites and data centers, and then shooting stuff out via the legacy way of doing routing.

We started to utilize this solution due to the fact that every big organization was moving to SD-WAN. It had some promising aspects of quick failovers, smooth transition, etc. The downtimes could be reduced, and it literally did that. Those were our main triggers for bringing in SD-WAN capabilities, and this solution was the best that we could find. Our higher management identified this SD-WAN appliance for deployment all over our firm to curb downtimes.

CloudGenix was still a nascent technology, and not yet acquired by Palo Alto, when we were deploying it in our branch offices. They had ION 3000s and ION 7000s then for data centers.

When we were setting up the solution, it was a complex process because there were a lot of moving parts in its transitioning. 

You need to have certain network policies in place so Prisma SD-WAN can work flawlessly, which can depend on different businesses. We have a custom hybrid network in place, so our deployment is usually complex. 

We had to take care of a lot of things before Prisma SD-WAN could be deployed. In the initial years, the deployment of Prisma SD-WAN was a process where we deployed stuff on certain sites and kept it under monitoring for over a week. Our reason was that all the other sites didn't have Prisma SD-WAN, like they have now. So, there was legacy routing that was interacting with SD-WAN. At that point, it was a little tedious to understand which routes were missing, and which were not. If a site whose MPLS went down and it was live with Prisma SD-WAN, then could it even talk with a site which did not have Prisma SD-WAN and worked on legacy routing mechanisms?

For the initial deployment, you need some type of network communication presence so Prisma SD-WAN can communicate to its cloud. From a WAN management perspective, many times when you create third-party tunnels between branch devices, you need to be certain that you are defining NAT IPs for Prisma SD-WAN. Therefore, on a WAN management base, I would say that one has to isolate the traffic and put certain network policies in place so Prisma SD-WAN can work better before it is deployed.

We understood all the routing stuff happening for a site 15 to 20 days prior to Prisma SD-WAN being deployed there. The deployment activity, if everything went fine, took around four to six hours for Prisma SD-WAN to become live. We then put it in a monitoring bucket for a week to discern whether everything was moving fine.

There were instances where some of our traffic, like the BFD path or some underlying BGP sessions, was affected when we put Prisma SD-WAN in front of them. In those scenarios, the Prisma SD-WAN deployment took upwards of 12 hours for the deployment. 

Prisma SD-WAN stack engineers have underlying kernel administration rights, so our guys cannot log in and see stuff. We had to call Prisma SD-WAN to help us to discern what was wrong. 

The underlying architecture has been smoothed out. There are quite fewer instances where we have to call them to understand the underlying kernel interactions. However, once in a year, we get a situation where we need to call their tech engineers. Then, they type in their usernames and passwords to log into the underlying kernel shell and check stuff out, because we do not have the rights.

The solution has saved us about 50% of our costs.

Moving from a legacy Layer 3 WAN to Prisma SD-WAN has resulted in a reduction in outages.

This solution stood out because it cost considerably less than the other SD-WAN solutions out there from Cisco.

It is a nascent technology when you compare it with the big guys, like Cisco. I am stating this because we have been helping Prisma SD-WAN to mature its technology for the past four years. We had issues where BFD packets were black holed by Prisma SD-WAN. So, we had to remove BFD from our Cisco Catalyst Switches. Though it is fairly mature now and able to route traffic in a pretty smooth manner, there are still some issues, e.g., in every new firmware, sometimes they change their route manipulation base. Now, there is traffic going in and out of a branch office, i.e., traffic from LAN to WAN and WAN to LAN. 

The general cost of Cisco routers is high, and we are deploying Prisma SD-WAN everywhere. This solution costs less than Cisco Routers, saving us time and effort. It is about a 50% cost savings.

I still want to understand why, in subsequent firmware versions, Prisma SD-WAN thinks of changing the route mechanism. Those route mechanisms adversely affect our policy creation. Even though Prisma SD-WAN is a capable device of symmetry, we define and design our network based on those routing mechanisms. However, if they keep on changing with subsequent major releases, then we need to go through all the network designs each time that change occurs.

I would rate it as 7 out of 10. We have many other options coming out from Palo Alto. The interactions between those and other network gears has a lack of documentation. 

The solution is used for multi-cloud and remote access for workers. On top of that is the CASB use case. We are going for zero-trust. If you want to implement zero-trust, this approach is very successful.

The mix between the normal gateway of my firewall and the other branches or the head office firewall is great. The gateway is available on the cloud which allows you to gain access from anywhere and still connect to your home gateway. 

Also, if I want to access a resource on the cloud, it can be accessed from the nearest EU tower data center right from London, not from here where I am.

Its connectivity and security are great.

The initial setup is easy.

I'm happy with it as it is. Maybe they could introduce some new features that make things easier. That said, for me, I didn't find it lacking in any major way. It gives me all that I really need. 

I'd like to see them move more towards CASB.

The solution does do a lot of frequent updating. 

I've used the solution for about two years now. Since they started, I've been using it.

The solution is both stable and reliable. There are no bugs or glitches. It doesn't crash or freeze. 

We mostly deal with medium and large-sized organizations, specifically in retail and multi-national branches. It works well and can scale to meet the needs of businesses of that size. 

It should scale well. We don't have a large implementation - which I would consider as 100 branches or more. Until now, we've been able to handle 35 to 36 branches without issue.  It should scale. I haven't had issues yet in this regard.

Palo Alto support is good. We are an old Palo Alto partner. We're not a customer, however, instead, we have our own setup with Palo Alto. It's not a limitation. They're good. Technical support has been amazing for us. 

I have used both Prisma SD-WAN and Juniper Contrail SD-WAN.

We found the initial setup to be very simple and straightforward. it wasn't overly complex or difficult. 

That said, it depends on how many sites it allows and what the complications related to that might be. If your setup is not ready, and you need to work on it, normalize it, and baseline it, it could take longer. That's it.

For us, for 20 sites, it took us two days to complete with just one resource.

In terms of maintenance, we receive the updates automatically. This is scheduled for the weekends. It's non-disruptive. The updates are frequent. They happen frequently and mostly on the firewall, or the ION itself.

The solution is expensive. Its competitor, Zscaler, is far less expensive. It's half the price. I haven't however, tried it to compare them. 

It's sort of like iPhone versus Android. They are both phones, yes, however, I don't care about the money, I care about the product. I'll choose an iPhone even if it is more expensive due to the fact that I love the experience I get from Apple. The same is true with Prisma. It's not cheap, however, I really appreciate the service they offer. 

There are different ways they can deliver their services, and these have different costs associated. There's Prisma Access, Prisma SaaS, and Prisma Cloud.

We are a Palo Alto partner. 

We are a system integrator and not a customer. We're selling to customers right now.

We are using the solution with a SASE subscription, Prisma Access.

I've used both on-premises and cloud deployments. 

I'd recommend the solution to the users and companies. It comes with all the security and the good direct point to the cloud application as well.

I would rate the solution at a ten out of ten. It's a really great product.