Prisma SD-WAN Reviews

My primary use case for Prisma SD-WAN is for companies with multiple sites distributed abroad. These companies need a centralized SD-WAN infrastructure capable of processing traffic at Layer 7. This infrastructure is particularly beneficial for organizations that require high-quality network traffic control, such as video and audio distribution, and providing support services via internet phones.

Prisma SD-WAN offers capabilities such as path selection based on Layer 7 attributes and application quality of service at the application level. It provides less than a second detection of failures to redirect traffic to other links. The infrastructure relies on SD-WAN gateway appliances, which can be physical or virtual, requiring zero-touch provisioning operations. This makes onboarding a remote site easy with near-zero system activities needed at the remote site. By reducing the need for expensive internet connections, Prisma SD-WAN allows customers to achieve cost savings.

I deal with various attack support use cases for multiple organizations. The most common use case is when enterprises are looking for easy failover of their links and better visibility into their network environments and traffic. It also supports integration with other vendors' products, like Slack or Teams, and integration with Prisma Access, a cloud-based firewall. We also have a cloud presence, but we need the licenses for firewalls or routers in the cloud. 

We have more than 700 tenants or users. I can't disclose customer names, but we have clients in retail, auto manufacturing, banks, and manufacturers of consumer products like toothpaste. I have clients ranging from the Australian time zone to the European time zones. There are some working in the United States, as well.

Prisma reduces the network engineers' workload by 40-60 percent. When there is a problem with traffic not reaching its destination, you'll get an alert to get it sorted out. The second benefit is security. Prisma SD-WAN has built-in VPN and fault-tolerance personnel functionality. It's integrated with cloud firewalls, and you can get the strength and availability of a SASE environment. 

You can replace your old routers and firewall with Prisma. It's like two devices in one. The portal provides a single pane of glass and zero-touch provisioning. You only need to get the device online, and you can do the rest through the portal. 

Prisma inspects packets for Layer 7 intelligence but doesn't provide all the intelligence that firewalls do. That's the job of a firewall, not ION boxes or SD-WAN devices. Prisma provides application-level visibility. For example, you can see the bandwidth consumption of Teams and Outlook or the consumption of SaaS applications versus in-house applications. With that level of detail, we can have security applied to traffic-based applications.

This gives you control over what application traffic should link. For example, let's say I have a link from AT&T and one from Verizon, but the Verizon link is not performing well in certain areas compared to AT&T. I can send my mission-critical applications to the AT&T link. Applications that aren't mission-critical, like Microsoft updates or file transfers can go to the Verizon link. 

You can steer traffic based on the application type, and it warns you if traffic isn't reaching a destination. For example, if Verizon isn't taking me to Google, the device will recognize that and redirect the traffic through AT&T. If the policy says to go to Verizon, with AT&T as a backup, it will ship to AT&T and start probing. These kinds of features are unique to Prisma. 

The application visibility features help you to support your SLAs. Before SD-WAN, most customers reported issues with voice communication, CUCM, and video conferencing. In those cases, the failover provides a seamless experience of voice, video, and real-time traffic.

Prisma simplifies troubleshooting. One recent example is that one of my customers was seeing certain links getting flapped. One alarm created one ticket each time it popped up, but that flap was five seconds, ten seconds, or a minute. Creating a ticket for a one-minute flap isn't an efficient use of tickets. With automation, you have one other feature of an event policy device. You can also automate with tools like Splunk and ITSM. You can set a rule where they only raise a ticket if it flaps five times within ten minutes or if the link is down for longer than two or three minutes. 

We have used automation for dealing with those kinds of minor things. There are other use cases, but this is the most common. You get email integration with all alerts, ITSM, and Splunk. Predefined cloud levels are also available on the portal. You can request it and integrate your ITSM with Prisma SD-WAN. The automation helps you quickly locate the root cause, so you don't need to dig through multiple layers of logs. In fact, you don't need to touch the device to get the logs. You can get it on a portal or through automation on your preferred monitoring tool.

Prisma's event correlation and analysis help minimize the number of alarms from one event. A year ago, Prisma SD-WAN rolled out an event separation feature. Let's say one link goes down, and it causes ten VPNs to go down, making a site unreachable. In that case, it triggers only one alarm that this site is partially inaccessible or has some fault. It will not trigger a separate notice for each VPN or application that isn't performing because of that. It will present one alarm showing that the IP is down. That significantly reduces downs the number of alerts in the portal. All the constituent alarms will still be there, and you can drill down to see those. 

Prisma has specific policies for event management you can use for sites under maintenance or those with a lower priority. For example, a branch site shouldn't have the same priority as the home office or the data center. You set priorities with the event policies. The administrators will focus on priority events they see in a portal at the same level. A link that goes down at the headquarters is a higher priority than a single VPN going down at a branch with two links. Under normal working conditions, both events will have the same priority. However, if you have this event policy set up, the administrator will see the priority levels for each ticket and prioritize tasks accordingly.

With Prisma, we can deliver branch services like networking and security from the cloud. We can have security integrations, including cloud-based firewalls like Zscaler and Prisma Access. You can also do some Zoom-based firewalling on these devices. Shifting from a legacy Layer 2 WAN to Prisma has reduced outages. Many things change when you move from legacy to SD-WAN. You must learn a lot in the initial stages, but once you are familiar with the changes, your job is almost 60 percent done. You don't need to focus on many tasks. The device takes care of them.

For Prisma SD-WAN, we use it as an intersite access for branches and also use the cloud proxy. We use Prisma Access for remote users, replacing our traditional PPA. We also consider the cloud to be part of the RN or remote networks.

Prisma centralizes everything, allowing us to remove NetFoundry and replace it with Prisma SD-WAN. It simplifies the onboarding process for users and allows us to replace our traditional connectivity solutions.

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.

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.

We used to have Panorama. Panorama is the centralized management platform for all the firewalls. In terms of centralized configuration management and troubleshooting, all the firewalls in the network are managed. 

Prisma is one step ahead, and it is a one-stop solution. Firstly, we used a different type of global coding VPN in our environment. For example, we use XYZ VPN to connect to the production network. We were using four to five types of VPNs. Prisma is the global VPN solution that it offers. They connect to Prisma via a single gateway, even maintaining security and segmentation. It's the centralized solution for managing all the configuration and VPN solutions. We have service connections to our data centers in AWS and Azure. If there are any workloads in AWS or Azure, users don't have specific connectivity to AWS and Azure nowadays. They can access all the required applications from Prisma. 

When you log in to the Palo Alto hub, a website where they have all the cloud-hosted portfolios, you will see many custom applications they are hosting in the cloud along with Prisma. For example, they have AIOps in the ignition firewall feature. 

Once you integrate that with Prisma, you have a centralized view of your network's security-related services. For example, you can see which firewalls have the antivirus profile enabled and which firewalls are missing this profile. You get a centralized view in a single dashboard. Additionally, for individual firewalls, whether physical servers or cloud-based firewalls, you must manage all these security policies, NAT policies, interfaces, etc. In Prisma, you manage everything in a single dashboard or configuration. Based on the service connection, you modify the route to have granular control of all the networks, making it quite useful to manage everything in a single dashboard.