Prisma SD-WAN Reviews

Prisma SD-WAN is a software-defined wide area network that allows us to programmatically reconfigure how remote office locations connect to each other or to a centralized repository.

The most valuable component of the solution is the necessity of utilizing an SD-WAN to implement Prisma Access. The solution allows our network to be self-healing in the event of a loss of connectivity between different locations.

Prisma SD-WAN can be built on top of a couple of hardware platforms, including the Palo Alto Next-Generation Firewall or the CloudGenix infrastructure. On the CloudGenix side, the ability to drill down into the details of connectivity issues and built-in firewall capabilities is lacking. However, you don't have those limitations if you build it on top of the Next-Generation Firewall.

I rate the solution’s stability ten out of ten.

We've been able to add new sites without any significant increase in effort to implement it. Around 1,200 users are using the solution in a rental car company.

I rate the solution an eight out of ten for scalability.

The solution's initial setup and configuration were very problematic. However, once we got all the issues worked out, it has been working pretty much flawlessly.

Positive

We had significant issues getting the tool operational with the CloudGenix base for the SD-WAN, but once it became operational, we had no issues with it.

Four people from our side were utilized to deploy the solution, which included me, two network engineers, and one security analyst. We also had to rely heavily on the professional services of Palo Alto and a third party.

Prisma SD-WAN is a pretty expensive solution.

On a scale from one to ten, where one is cheap and ten is expensive, I rate the solution's pricing an eight out of ten.

Before choosing Prisma SD-WAN, we evaluated other tools like Cisco Umbrella, Zscaler, and BeyondCorp. At the time, Cisco Umbrella was incomplete. There were SaaS features that it had not yet implemented. BeyondCorp was still in production without a complete product yet released.

Zscaler was missing some of the core features and functions, and it had stability issues and some security breaches. Palo Alto was the last one standing, and it was far superior even in the definition of the capabilities of what was supposed to be included in the other tools.

Currently, we have just one person responsible for maintaining or making configuration changes for Prisma SD-WAN. Prisma SD-WAN has allowed us to reduce our telecommunications expenses by about 50%.

If you want your SD-WAN to be feature-rich, build it on top of the Next-Generation Firewall. If you just want to get it up and running, the CloudGenix solution is the better option.

Overall, I rate the solution an eight out of ten.

Prisma SD-WAN offers the same functionalities as Palo Alto CloudGenix, but my company uses it for different clients who operate retail chains. All the places where I have seen a big business setup, consisting of the head office, warehouse, sales office, and different kinds of offices for a particular area of business, require everything to be connected with their data centers, which is one of the main requirements of a business for which Prisma SD-WAN is required. Depending on the needs of my company's customers, we suggest Meraki, CloudGenix, or Juniper since the basic nature of all the aforementioned products is the same for a multi-point business setup.

The solution's most valuable features are that it is easy to onboard and its features are easier to understand. Prisma SD-WAN's features are similar to Cisco Viptela. Prisma SD-WAN is less costly than Cisco Viptela, but it did its job well. With Prisma SD-WAN, it took me a week to understand the concepts. In a month's time, I was able to deploy Prisma SD-WAN, so it was very easy and good. Users can cover up for the lack of support with the level of ease that the device provides you to interact with, so it gives confidence to its users. Whenever you go to the support, you are confident about what the issue is in the tool. Juniper, which functions on a Linux-based architecture, allows only a Linux expert to work on it, but a normal network technician cannot work so smoothly on it. The ease of troubleshooting and deployment are two main features that are better in Prisma SD-WAN compared to its competitors.

There are some small issues in Prisma SD-WAN's area related to bypass pair or couple ports related to redundancy. Sometimes, during the product's initial setup phase, bypass pair or couple ports don't come up normally, and it requires an hour and a half to troubleshoot to reset the box from Prisma SD-WAN to factory default. Prisma SD-WAN has some minor issues in its physical port, especially in bypass pair or couple ports. Bypass pair or couple ports are not abnormal ports. It is just that the aforementioned ports behave differently. If Prisma SD-WAN can fix bypass pair or couple ports and make them robust enough to work after the initial setup in the first attempt, then it can save a lot of time. The physical device's bypass pair or couple ports generally have issues.

I have been using Prisma SD-WAN for three years. My company has a partnership with the product.

It is a stable solution. Stability-wise, I rate the solution a nine out of ten.

The solution has some issues related to bugs, but in my company, we can fix them.

The product's scalability is good since my company has never found any issue with the traffic load or the memory utilization part. Scalability-wise, I rate the solution an eight or nine out of ten.

I have dealt with around 100 sites with small setups, so I can say that around 1,000 to 2,000 users use the solution.

Prisma SD-WAN has some support issues, but not much since it can be handled.

There are certain areas where the support team of the solution lacks.

I would say that the support team can easily find the root cause of the problems related to the product in a very short amount of time, but the support team's availability is not good. If we have a P1 ticket now, which needs to be given priority owing to its severity, the product's support team takes nearly two hours to join, which doesn't help us solve the problem even though they are good. In our company, every time we have some activity, we pre-plan it, and we ask the product's support team to join us irrespective of whether we have an issue or not so that in case we face an issue, we can get help. The support team might not be available to help our company even if there is some severe issue.

I rate the technical support a seven out of ten.

Neutral

The product's initial setup phase is straightforward.

The solution can be deployed in a day or two, considering it is done from my company's customer's branch office.

I have seen a return on investment in the sense that earlier, the customer used to work on the legacy network where it usually took time to set up the network, and once the network was set up, it worked fine, but, again, if you want to change something in the network, it takes time. After implementing Prisma SD-WAN in an environment like this, it can be described as offering more automation on the WAN side, so if you add a new service, you don't need to redesign the network. You just enable the service you want on the box from Prisma SD-WAN, or if you have some specific parameters, the box will take care of them under the service default list. In Prisma SD-WAN, voice is always prioritized, and data is less prioritized. Whatever services you have in your network, you can just add, and the device will take care of them, as it knows that a particular service may have four links, it knows from where it needs to send it, and if the service goes down, it knows by default where it has to send a link, so there is no manual intervention required. By considering the solution's base, we can say that it offers good scalability, as a user gets to see an increase in network readiness and uptime.

I recommend the solution to those who plan to use it. As per market standards, the product is doing good.

I rate the overall tool a nine out of ten.

We can integrate Prisma SD-WAN with Zscaler, a third-party application, as well as with Prisma Access from Palo Alto. These are the endpoints. That means we are controlling the internet traffic. These days, with so many people working from home due to Corona, we have to control the internet traffic. That is one of the main use cases for Prisma SD-WAN.

Another use case is because in Europe there are multiple languages. Some of our customers complain that when they are browsing the internet, they are not getting their local language, or they're not getting English. The reason is that we have established Zscaler connectivity. The low latency endpoint, because Zscaler is in the cloud, is communicating to the branch and, as a result, they're getting a different language. In such a case, we build a static tunnel to the static Zscaler and a static tunnel to the node. We can establish that connectivity in Prisma SD-WAN and it will connect smoothly, without any issues.

Prisma SD-WAN is an SD-WAN optimization product, where we don't require any kind of MPLS circuit. If such a circuit is there, it is no problem, but in general we are able to eliminate MPLS circuits and establish a site-to-site tunnel. That is one of Prisma's benefits. Some of our customers are still using MPLS circuits, but I am working with my customers to eliminate them. In place of that, we are allocating high-bandwidth internet to the site.

It also helps reduce costs. If you have one data center connected to another data center, or a branch connected to a DC, you have a P2P circuit. That is too costly and we can eliminate it. So it is very helpful, cost-wise, for our customers.

The solution is also very flexible when it comes to policies, so that you can redirect the traffic. Suppose the quality of one of your circuits is bad. It will automatically shift traffic to the second circuit, which has better quality. We don't need to make any alterations. In a legacy environment, we would have to do a lot of traffic-routing and change everything. But here, it is automatic. No human interaction is needed.

In addition, administration using Prisma SD-WAN is very flexible. Devices, policies— everything—is in a single portal. If you think about a legacy network, you would have to go to a data center, you have to go to a server or log in to the data center router, and do routing P2P. With this solution, that is not at all required. Everything is in the UI. With 10 days of training you can administer a customer. I was not a network guy, previously. I started my career as a system support engineer and I don't have a networking background. But it is very easy. With some training and knowledge of networks, it is easy to manage.

In terms of automation, we can connect this solution to our ticketing tool, which is ServiceNow. (We can also integrate Prisma SD-WAN with other third-party applications like Zscaler, AWS, and Azure, among others). Whenever there is an alert, it will send a message to ServiceNow and that solution will automatically create a ticket and send it to the concerned team. If we have 10 customers, we can monitor all the infra at the same time. Whenever an issue is resolved, one more message is sent automatically to ServiceNow saying, "Okay, this issue is resolved," and ServiceNow will automatically resolve the issue without human interaction. This kind of automation simplifies things because there is a single portal for administration.

Troubleshooting is very easy compared to other SD-WANs and legacy environments. We can filter by source and destination IP and check, if the traffic is failing, what is happening to it. We also have the advantage of being able to look at which application is involved, and that is not something we could not do on a legacy system. We can filter by application and see if the traffic behavior is normal or failing.

We can also see

• application health - if it is good, it shows as green, if not it will be red
• application response - whether the application is responding or not properly
• current, new and concurrent flows.

Everything is viewed in a single page. We don't need to go to a CLI. We can filter everything. Even the L1 team can monitor things and talk to the customer, rather than issues having to go to L3 or L4. That is the beauty of the solution. It is very easy. Previously, the L1 team could only create a ticket and didn't have access to the router to do troubleshooting. They would have to wait for L2 or L3. Now, we can give them basic, read-only access so that they can also view the network and see what the traffic is like, whether a device is up or down, its power status, et cetera. These kinds of things are no longer dependent on the L2 team. Tickets are mostly handled by the L1 team.

Another benefit is that it helps reduce network troubleshooting time, by a lot.

Previously, we were getting multiple alerts, even from one site going down. There are interface-down alerts, device-down alerts, internet-down alerts. All these are really a single alert that means "site down." That type of correlation was implemented about six months ago by the Prisma SD-WAN engineering team and it is working successfully. It makes things much easier when we are only getting a single alert. Otherwise what happens is that we have multiple tickets created in ServiceNow. A single site down could create 50 alerts, but now it's a single "site down" incident.

The product has a controller which is hosted on the AWS cloud, and we have three cloud data centers. From the main controller, we can administer the customer's devices, QoS, network, and traffic. We can monitor it and we can change and create policies as well as upgrade the software. We can totally control a customer's network from one site, the Prisma SD-WAN portal.

Prisma SD-WAN has a lot of advanced features, one of which is Zero Touch Provisioning. If you want to migrate to the cloud, or you want to migrate your office to a high-end router or an edge router, it is too difficult. It would require a lot of planning, a lot of implementation, and a lot of headaches and operational burdens. But with Prisma SD-WAN's Zero Touch Provisioning, we can collect the customer's infra and analyze it. According to that, we can prepare a diagram and implement high availability with two devices. That way, if one of the devices is down, the other will take an active role with the forwarded traffic.

And whenever we are required to make any changes, we can make them to multiple devices at the same time. Suppose we want to change the IP address, or create a static cloud. We can create a template and can use it for multiple uses.

If we want to upgrade software, in GitHub there is a lot of code uploaded by Prisma SD-WAN developers that we can download to schedule the upgrade onsite, and it will automatically upgrade the software and reboot the devices. If there is only a single device involved, traffic will definitely be cut off for some time, but if you have implemented high-availability, with two devices onsite, there is no traffic interruption during a software upgrade. It will be shifted to the second device while rebooting the first device.

Other features include event, security, network, and path policies. Regarding path policies, suppose you have two internet circuits and you want one circuit to be the primary and the second circuit to be the backup. Using an SD circuit would be too costly in a normal situation. But whenever the primary circuit is down, since the office should definitely not have an outage, we have to ship the traffic to the SD circuit. In that scenario, we can create a path policy, so that whenever the primary circuit is down, this traffic will forward automatically to the other circuit.

Also, suppose I have very critical business applications hosted on the cloud and I want to prioritize these applications. For example, if there are two people working with SAP while other people are just casually browsing the internet, using Facebook or Gmail. I want to give priority to the SAP customers. I can set this kind of priority with four levels of traffic or QoS, platinum, gold, silver, and bronze. I can put the SAP traffic in the platinum level and it will get more bandwidth and the application will perform fast. Its traffic is prioritized immediately, over the other levels. And if you have two internet circuits and you want to direct your SAP traffic to the fastest primary circuit and your Gmail and Facebook traffic to the secondary circuit, that is also possible with Prisma SD-WAN.

In Prisma SD-WAN there are three modes: Control, Analytics, and Disabled. If you disable the site the site is completely down and inactive. If you are in Analytics mode, that means the site is being monitored. But mostly, we are using that for DC sites to get the traffic metrics. In Control mode, the site is fully functional.

And WAN management is very flexible. We can create multiple WANs in a site and we can customize a WAN. We can move traffic around, depending on the customer's requirements and internet availability.

In some areas, compared to other SD-WANs, Prisma SD-WAN has fewer features. 

First of all, sometimes, if one device is down, the other device will not come up. When there are two devices and we have created HA, that means one device gets a priority of 100 and the other is given 90. The 100 priority is active and the 90 is the backup. In some cases, the primary device is down, but the secondary device is not becoming active. In that case, we have to reboot the devices, causing an outage.

I would also like to see improvement in the product training for customers. Palo Alto has not initiated very much training but they have to do so because this is a new product. If you have experience in a legacy environment, and you are moving to Prisma SD-WAN, you don't have a training framework. That is one of the disadvantages. Although they have a training portal, it is a read-only platform. They need training for engineers so that engineers can work very quickly and properly.

And with software upgrades, sometimes the device does not come up and we have to do a manual restart. It doesn't happen every time, maybe one or two times out of 100. It's minimal but it does happen.

I started working with Prisma SD-WAN in January, so I have been using it for about 10 months. I have multiple customers around the world. I support them in operations, QoS shaping, implementation, and many other requirements.

Prisma SD-WAN is stable.

Initially, the SD-WAN product was handled by cloud teams. In 2020, it was acquired by Palo Alto and then there were a lot of changes. Massive changes happened at the SD-WAN level.

Now, it's stable. If you go to the Prisma SD-WAN portal you can see any downtime. It is completely okay. I haven't seen any downtime for the traffic. There has been some downtime for the administration portal due to maintenance.

It is scalable. I have not faced any problems with the scalability.

In our company, there are approximately 100 people supporting many customers. In my scope I work with more than 10 customers. They're not very big customers. They are generally small enterprises with 20 or 30 sites, and some customers have only five or six sites. Some have branches in the UK, the US, India, Japan, or China.

Everything is done through a single support portal. Whether you are using Prisma SD-WAN or a Palo Alto firewall, you can create a ticket there. A Palo Alto engineer will call or email you with an update.

If you need help creating a policy, you can create a ticket and they will schedule a call via a Zoom meeting. You can then explain your requirements.

Most of the time they give good support.

Positive

It is straightforward to set up. It is very easy if you have a basic knowledge of networking. I didn't have much experience in networking and I'm not a super master of SD-WAN. But for most of the use cases based on our customers' requirements, I was able to do things myself.

In some critical situations, I have made use of assistance from the Palo Alto engineering team to resolve some issues. In some cases I didn't have access and they have super access. For example, if you want to see actual bandwidth, you have to go to the kernel level of the devices, and that access was restricted for me. This was handled by the Palo Alto team.

Generally, it doesn't take much time to deploy the product. Whenever a customer has a new branch, we create a customer inventory and order the hardware for them, depending on their requirements. We use 7K or 9K in data centers, and 2K or 3K for a branch. Once it is delivered, the customer will order the internet circuit. At that stage, we will work with the customer to create a diagram and, according to that, the customer will prepare their infrastructure network. We will then configure the SD-WAN devices per the requirements, such as software version and policies. Once it is deployed, the site will go live.

If you have knowledge of the Prisma SD-WAN product, you can do the setup without assistance from Palo Alto.

It is a growing product and Palo Alto gives you training for it. I have attended many programs from Palo Alto.

I would definitely recommend Prisma SD-WAN. It is a growing product, first of all and the Prisma SD-WAN team is doing a very good job of upgrading the platform. The product is very flexible and understandable. Everybody can work on it. The GUI is very friendly. You also have CLI access if you want. Our customers who use it don't require a top network administrator to work on their networks. Even an IT admin can work with the Prisma SD-WAN and modify things.

Overall, it makes things easy and it is cost-effective. There's no complexity in the network. Everything is in the portal and is available. You can administer devices and traffic in this single portal.

We use Prisma SD-WAN for nearly everything. It is deployed at all our remote locations across nine states, and we have cores in our data center. Each branch is connected to the cores.

A high-availability pair we use for our primary banking software is stood up at one of our vendors. All these devices have direct VPN tunnels to a pair strip in their data center. We stood up the HA pair with VM infrastructure and AWS, and all branches have direct VPN connections to those devices. This passes all the traffic for the branches and networks.

We have these devices deployed on AWS, but we're not using the AWS aspect to send policy or control the branch management. We do it from the local device or the hardware cores in our data center. As far as WAN, you can build direct tunnels. If we did management from the cloud, we would have direct VPN tunnels to that cloud service. 

Before we deployed Prisma SD-WAN, most of our branches were on a legacy T1 circuit over an MPLS. We were using Cisco routers, so we couldn't see networks with applications. We saw an immediate benefit as soon as we rolled these out to all the branches. We could start to see all the data flows and which endpoints were talking. It allowed us to build custom applications and quickly identify them by name when searching for data flows.

We previously only had a single T1 circuit, but Prisma SD-WAN enabled us to deploy two internet circuits at each site, whether it be fiber, DIA, or broadband like you have in your house. All of our locations have a primary and a backup. Sometimes, the second circuit is a cellular LTE or a Cradlepoint.

Prisma helps us troubleshoot endpoint issues. If a branch calls in and tells me they're having trouble accessing an application, I can immediately go into the dashboard to check the tunnels. I can tell them if a tunnel is down or missing. I can troubleshoot that tunnel, disable it, re-enable it, and try to get it back online.

It shortens the resolution time compared to our previous Cisco setup. You'd have to log into the router and type some commands to troubleshoot because everything was through the command line.

With Prisma, I only need to check the dashboard to see if there's an alarm on the home screen. You can click on that and go into greater depth to see if there's high latency or packet loss. The alert on the dashboard directs me pretty quickly to the device with an issue and helps me determine the nature of the problem.

Switching to SD-WAN has significantly reduced our outages. That was one of our primary reasons for switching to an SD-WAN vendor. The legacy hardware lacked visibility in Layer 2 at the switching level or Layer 3 routing. I had to log in to use the command line manually. This device has GUI and command line capabilities, so I get my reports straight from the dashboard, and I can export those to management. I know our company reported fewer outages. I don't remember that percentage, but it was a significant difference.

Prisma's analytics provide a lot of valuable data. I like the internet health chart that shows latency, dropped packets, MOS for data quality, etc. It also runs a continuous speed test in the background. I've used it multiple times to troubleshoot internet connections when the service provider has attempted to claim nothing is wrong with the circuit. It gives me data to send them showing we're not getting the speed we should, or there is constant packet loss.
I wouldn't say the Layer 7 intelligence provides deep application visibility, but it does provide some visibility. We rely on our next-gen firewalls, which are also Palo Alto. They work with this product to give a deeper view of Layer 7.

It has some machine-learning features. For example, it collects data in the background. You can look at the data flows to see that internet connectivity was poor at a given time, which correlates with a point on the data flow where the customer complained about a problem with the application. 

We can set various policies regarding which traffic goes where using a zone-based firewall. You can also set a policy based on events. We might implement a QoS mechanism where an application might have a higher priority. For example,  it might dedicate more bandwidth toward video calls under a given condition based on the policy. We can custom-build applications to ensure they're impacted the least according to the policy we have set.

With the policy in place, we don't need to interact with it as much. It does it for us, so we don't have to tweak too many settings, and it allows us to get pretty granular with it.

The solution formerly known as CloudGenix is now Prisma SD-WAN, so it can do zone-based firewalls. However, they do not put heavy encryption on the device. That's mostly going to be handled by the firewall service you use. It doesn't have to be Palo. It could be Zscaler or Check Point. Even though it's a Palo Prisma device, it works well with various vendors and allows you to do that aspect.

I have been using it now for a little over three years.

I think Prisma is highly stable. You're going to have some outages here and there, but I rarely see the direct branch-to-branch or branch-to-data center tunnels go down. 

Most of the tunnels that go down are third-party or standard VPN tunnels. That's your branch connection straight out to the internet, so you don't have to backhaul any of that data to the data center. It hits a cloud firewall, gets analyzed based on your firewall policies, and goes out directly to the internet.

It's simple to scale up Prisma SD-WAN, especially the Prisma Cloud firewall. We set that up on our Palo Alto Panorama firewall. It is one firewall with all these tunnels directed back to it. Prisma has something called a "cloud blade." It used to be a Docker container, but now it's some container that runs on their hosted servers out in the cloud.

This container was a huge script that auto-builds all these Prisma tunnels for you. It runs a script, configures the IPs and IPsec tunnels, and sets up all the security. It does that in the background, so you don't have to go in and configure two tunnels for every site deployed. If one of these tunnels goes down or a site gets removed, it deletes and clears out that VPN tunnel. When you deploy a new site, it runs a script every so often in the background. It detects a new one, builds it, deploys it, and then it all points to the same Prisma Cloud for the firewall.

We have roughly 2,300 users traverse these networks directly at the branch or using our global VPN solution. Everything goes across these same tunnels. I wouldn't describe our network as extensive. I would say it's a medium network. However, I don't think we'd have an issue with a more extensive network. These are built so you can configure all the tunnels with them. I don't think it would be a problem at all.

I rate Palo Alto support a seven out of ten. Customer support is our biggest pain point. The quality of support has gone down a little since we initially deployed this product. I don't know if this is due to turnover at Palo Alto or a lack of training. It is now taking one or two days to get an initial response that says, "Hey, we've looked into this, can you pull this data for us?" In the past, we'd immediately get a response. 

Neutral

We didn't have an SD-WAN solution previously. We had a legacy MPLS network with on-prem firewalls and a hosted VPN solution.

I was the lead engineer for everything, including the proof of concept, lab testing, and the initial building of the scripts we used for the device. I did the deployment of the first 150 branches before I handed the project off to another engineer.

We had a fairly small network team handling most of the physical deployment, while a dedicated cybersecurity team did the firewall policies, file blocking, etc. We had about eight people between those two teams. For the rest of the deployment, we paid for professional services through Palo Alto to have a dedicated engineer assist me and another team member with all the initial setup to get this deployed. That was roughly three to four people.

We paid for professional services. We bought the project when it was still CloudGenix before the Palo Alto acquisition. We did the initial setup and had a dedicated top-tier engineer come on-site to work through the diagrams with us.

From there, we built the first lab on the device. The engineer took that config off the device and created the initial jinja template with all the data in the config files then handed that over to us. He showed us how to use those templates and build our YAML file for each individual site, and he walked us through how to use the scripting he had put in place, which was Python on the back end. It was an easy process.

I think we have seen an ROI. We have a strict auditing and compliance process. That's one reason we have chosen this feature. We need these security features to meet the audit criteria.

The price is steep, but I don't know what we would've paid for the VMware solution. Meraki is a little cheaper, but Cisco is costly because of the hardware and all the licensing that goes with it. 

We didn't just adopt SD-WAN. We also purchased GlobalProtect and Palo Alto firewalls, so we got a package discount by buying multiple devices from the same vendor. In addition to the physical SD-WAN appliance, you need to buy the security license that provides encryption.

We did a demo at our site with multiple vendors. It was Meraki, Viptela, and VeloCloud. Our network architect scheduled these demos. 

Prisma performed the best during the demo. Meraki lacked the analytics in the dashboard we wanted for data flows and more. We had some negative experiences with Cisco's Viptela. We didn't like the product because it runs on Cisco hardware and has several issues.

It came down to VMware's VeloCloud and Prisma SD-WAN. Prisma blew the other one away in ease of deployment. It also provided much more information on the dashboard. That was three and a half years ago, and they've made massive improvements since then. Every two to three months, they push out a significant update that deploys more analytics or makes something more accessible. They continue refining and adding features, rolling out better reporting, etc.

I rate Prisma SD-WAN a nine out of ten. I've been happy with it aside from one pain point. It's been effortless to deploy. I recommend doing a demo. Measure Prisma against other products to see what fits your company's needs best. If you're looking for a cheap solution, Prisma may not be for you. The most important thing is to ask them to do a demo for you to see how it stacks against competing products. 

We have introduced many applications for our clients and they need to launch with very minimal latency. Running them through traditional processes is not sufficient for our network or for our customers' or clients' satisfaction. We have moved to the SD-WAN approach.

Our traditional network using Cisco routers is quite old and it's not very intelligent when it comes to troubleshooting. Prisma SD-WAN is very helpful for our network.

SD-WAN is very

• flexible
• easy to deploy
• easy to troubleshoot.

When it comes to supporting large, complex, network architectures, it's a very simple architecture. The main component is the fabric. It's very easy to troubleshoot if there is an issue happening in the underlying network. More specifically, there is a bypass feature that is very helpful.

And CloudBlade makes automation easy. We can check the logs because it collects the data from all the branch sites and analyzes the data. Those features make it very helpful for large networks.

It also has very high capacity and it can retain and analyze many thousands of connection and application details.

From a security point of view, it can analyze and filter the packets and detect malware and other anomalies in the packets. That feature is also helpful for a larger organization.

The hardware is more robust. When we are rebooting and resetting a device, it is very flexible. It reboots in between 10 seconds to three minutes. It's also quite easy to deploy and troubleshoot in a real-time scenario in the field. If something hangs at the hardware level, it recovers quickly.

Overall, the hardware, security features, and automation are a few of the key points that will help a large organization.

Also, WAN management is quite flexible and if something goes down it triggers an alert on the graphical user interface and the end-user or operations team can act accordingly. It has a very good feature, LQM (Link Quality Monitoring) that calculates link quality metrics and populates them on the dashboard. For WAN management, it's a good feature.

Event correlation and analysis capabilities do not help minimize the number of alarms from a single event. That is the problem. We are getting a lot of incidents, and there is some issue with the correlation. That is still a drawback. Sometimes we get many alerts when a device is going down, and when it goes up again the alerts are not automatically cleared. Some type of modification is required.

Another drawback I have observed is that Prisma SD-WAN has a tunnel to the Zscaler endpoint. It forms the tunnel through an API call and that is not sufficient from the client side. Improvement is needed to the parameters they're using for the Zscaler endpoint. There are new features, new protocols, that need to be applied so that it can be checked and work properly. Improvement is needed from Prisma to the Zscaler endpoint because when the tunnel goes down, there are no intelligent parameters, like an alert timer.

I have been using Palo Alto's Prisma SD-WAN for the last two and a half years, for my client.

The stability is very good.

The scalability is also good and robust.

We have a portal so that when we are facing an issue, we can get with the support team and raise a case.

Neutral

Previously, we were more aligned with a traditional network which was our Cisco routers. They were not intelligent, or multi-application oriented. SD-WAN is application-oriented and we can analyze the logs. There are many intelligent features. The troubleshooting is also easy.

Our network is very large. We have more than 10,000 routers and switches, and more than 600 sites. We have legacy, traditional Cisco, Juniper, and other routers, and most of them are at end-of-support.

With Cisco, there is a control plane and a data plane and so many protocols. By comparison, Prisma SD-WAN has flexible solutions. There is no complexity due to protocols and the control and data planes. It's very simple and it's also easy to understand the traffic flow.

The initial setup of Prisma is very straightforward. It took us one to two hours, maximum. We did it ourselves, following a setup process. 

There was an issue because some applications do not support this SD-WAN and the application packets are dropped by Prisma SD-WAN. There were a couple of challenges for us. Even now, after one year, Prisma SD-WAN is not supporting an application. Its packets are getting dropped. That is one of the drawbacks.

It has been deployed in a hybrid model. On the branch side, we have Instant-On Network (ION) 2K and 3K, and at our DC sites we have ION 9K and a hybrid model. And from the branch to DC there is a fabric running via the internet.

It doesn't require any maintenance. It's a one-rack-unit device. It can be placed in any small rack and requires only two internet connections and little power in DC volts.

It's worth the money we are paying for the features and availability and stability of the network.

The solution also gives us deep application visibility, with Layer 7 intelligence. Traffic engineering is not working on our side. That generally works on the ISP network. There is a security feature in Prisma and a security path setting. We need to create a policy and a zone and mention the policy rules in the zone. It will bind to the security binding and we can apply a global security policy.

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. 

We are using Prisma SD-WAN for testing and training purposes on our side. We deploy it for customers.

Our customers using Prisma SD-WAN have seen multiple unique benefits, including a complete application SLA. They can track application traffic flow and route traffic based on application slowness or round trip time, providing complete security and the best network optimization.

The most valuable features of Prisma SD-WAN are its ability to utilize Internet plus MPLS optimization path to route traffic as per the SLA, and its seamless integration with other security stacks.

The pricing model could be improved to make it more affordable for smaller companies.

The implementation of the solution is easy.

We usually help customers to implement the Palo Alto solutions.

Customers have seen significant ROI benefits.

Pricing can be an issue. Some customers may find it unaffordable due to their budget constraints.

We have another vendor providing an SD-WAN box within a price range of 10,000 to  20,000 thousand INR, suitable for budget-limited customers.

Integrating Prisma SD-WAN with third-party solutions is definitely required and it is recommended to utilize its AI capabilities.

We use this solution to enable better connectivity for utilizing the more available Internet broadband lines instead of the expensive MPLS lines.

The solution is deployed on the cloud. I'm using version 5.4.

There are 15 people using this solution in my organization, including network and security engineers. We currently don't have any plans to increase usage.

The reliability of the solution has improved our organization. We don't have any downtime unless there is a power outage. The network is more resilient and faster. It delivers applications in a timely manner. The performance has greatly improved due to the expansion of bandwidth and a reduction in costs. 

MPLS lines are the most expensive lines. After changing to a broadband line, the monthly cost of running the network is completely different.

Prisma SD-WAN also provides Panorama integration, although we haven't used it.

We use Prisma SD-WAN's event correlation and analysis capabilities to help minimize the number of alarms from a single event, but this is all done from the dashboard. This feature has made our network operations much more clear and more concise. Sifting through numerous alarms, especially if they're for related incidents, makes it cumbersome to focus on the problem that needs our attention.

Prisma SD-WAN enables branch services such as networking and security to be delivered from the cloud. It provides seamless integration with the Prisma core networks and traffic web filtering. This simplifies our WAN management. 

We're able to have one place where we can configure pretty much all of the features of our network. We can designate a device to use a certain set of features, policies, etc. It's just a matter of doing its local configuration and it's instantly on. We don't have to configure each device from scratch. We set the policy, upload the configuration, and that's it.

The move to Prisma SD-WAN definitely resulted in a reduction in outages because we usually have one WAN link. Regardless of whether the internet access is used from the hub site, ideally, Prisma Access allows us to have local internet access through the branch side. The benefits are numerous in that respect.

I like that the integration with Palo Alto is easy.

The dashboard is okay. The dashboard gives us enough flexibility to get the information needed so that we can act upon any issues or data that is represented. It serves our purpose for our use case. Like with any other product, it takes time to get acquainted with it.

The only con is the pricing because it's more premium. 

I have used this solution for less than a year.

It's a solid product.

Scalability is not an issue. We can have defined policies, defined routing, etc. Onboarding new sites isn't a problem.

I haven't needed to contact technical support in the past year. The product is performing well. From what I know from my colleagues, the support from Palo Alto is usually great.

I wasn't involved in deployment, but I was told that it was pretty straightforward. It became complex because they did a full-blown deployment and configured everything. Palo Alto did the POC.

If you're already invested in a Palo Alto product, it would be logical to use this solution. If not, there might be some other solutions that are more viable in terms of pricing.

I would rate this solution a nine out of ten. 

My advice is that everybody should do a proof of concept. First, read the basic white papers on Palo Alto. If the product seems to suit your needs, contact them and see what the POC will be and what the pricing will be like. The pricing is different for different companies. Larger enterprises get larger discounts. This also depends on how many sites will be incorporated. There are many factors. It's not a simple decision, but at least you know the product is good. It's on the premium end, but that's what Palo Alto is all about. If you want a top-notch solution, then Prisma is for you.

Our security team evaluated the solution and couldn't find any lacking features. I think it's suitable for large and complex enterprises.