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.

We are doing a proof of concept for Prisma SD-WAN and considering whether to migrate from our existing solution. We are attempting to replicate our existing technology and duplicate that traffic.

In POC testing, we're able to communicate from one site to another perfectly.

Prisma supports all of the applications we're currently using. 

Prisma could be a little cheaper. 

We are currently evaluating Prisma SD-WAN and haven't implemented it yet.

I rate Prisma SD-WAN nine out of 10 for stability.

I rate Prisma SD-WAN eight out of 10 for scalability. 

I rate Palo Alto support eight out of 10.

Positive

We are using an HP solution. Prisma SD-WAN is easier to manage and has more features. 

It's very easy to set up Prisma SD-WAN. 

Prisma SD-WAN is a good investment. 

I rate Prisma SD-WAN 10 out of 10. 

On-premises

The security offered by the solution is pretty good.

Prisma SD-WAN should provide more flexibility and scalability on the hardware. The solution's conversions and failover need to be improved.

I have been using Prisma SD-WAN for two years.

Prisma SD-WAN is a stable solution.

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

Our clients for Prisma SD-WAN are medium-sized businesses.

I rate the solution a four out of ten for scalability.

On a scale from one to ten, where one is difficult and ten is easy, I rate the solution's initial setup a five out of ten.

The solution’s deployment took a while.

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.

The solution's security framework has enhanced our data protection. The solution offers really good security. We faced some challenges while integrating Prisma SD-WAN into our existing infrastructure. The key is to presage the SD-WAN ION boxes prior so you can do a simple cutover. Do as much groundwork as possible, and then you can cutover to the new boxes.

Prisma SD-WAN is aiding our AI-driven initiatives because we can push our policy updates across the board. Earlier, if you needed to provision a new IT service, you'd need several resources to implement via the command line interface to individual boxes. Now, it happens with the push of a button, and it works its magic. We're standardizing the networks first, building automation, and then looking at AI.

Overall, I rate the solution a seven out of ten.

On-premises

Prisma SD-WAN provides security when remote users want to access an application or internal server. We recommend Prisma SD-WAN for users who want to connect to a VPN through their laptop and for users who have multiple applications and want to integrate them with our cloud.

The solution's most valuable feature is the visibility of the logs. In case of any errors, we can check the logs and resolve them as soon as possible.

The solution should include custom ports and group voice connections.

We have been using Prisma SD-WAN for the last six months.

The solution’s technical support is good. The technical support team's response time should be improved. The support's SLA timing always takes one or two hours, and sometimes it takes four to five hours.

I rate the solution’s technical support a seven or eight out of ten.

Positive

We have a dedicated team for Prisma SD-WAN, which handles the technical parts and pre-sales. Palo Alto is the market leader in security integration. It provides WildFire and an internal security portion. Prisma SD-WAN has, by default, an inbuilt artificial intelligence feature. The solution has Wildfire, GP, and a single pane of glass features available.

I will recommend Prisma SD-WAN to users in the mid-level market who have been using public applications. I will also recommend the solution to an enterprise customer, such as a bank or finance solution with over 10,000 users.

I would recommend the solution to other users.

Overall, I rate the solution a six out of ten.

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.

On-premises

The platform allows aggregating different media, such as fiber, DSL, and even 4G/5G, providing a cost-effective alternative to MPLS VPN.

The product provides efficient stability, security, and reliability features.

They could add more advanced security features to the product.

We have been working with Prisma SD-WAN for three years.

The platform is stable. 

The product is scalable. 

We were primarily working with VMware SD-WAN.

The initial setup is quite straightforward.

We provide full implementation training for our customers. Our engineers handle all the deployment tasks.

The platform's simplicity and advanced functionalities, like a dynamic command, are very beneficial. Due to its key technology, it's better than many other vendors.

Unlike hardware SD-WAN vendors like Cisco Meraki, it integrates security easily and effectively across devices. It allows the deployment of various security solutions on the same devices.

Currently, AI functionalities are limited to basic database querying and reporting. More advanced AI integration would be beneficial.

I recommend it to others and rate it a ten out of ten.

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.

On-premises

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. 

Hybrid Cloud

Amazon Web Services (AWS)