Version 1.0
Date: May 2, 2024
John Tzortzakakis
Sunil Cherukuri
Richard Gallagher
Mukhtiar Shaikh
Gary Matteson
Tanushree Kamath
In this document a “Best Practice” is marked with a Star like the following example. The remainder text is for explaining the rationale and for extra information.
Introduction
Access and Authorization
Prisma SD-WAN Portal Access (Strata Cloud Manager)
Accessing the ION Devices
Tenant Access using APIs
Strata Cloud Manager
Legacy Prisma SD-WAN
Tenants migrated to Strata Cloud Manager from Legacy SD-WAN Controller
Connecting IONs to the SD-WAN controller
Sites
Create Sites (Branches)
Create Sites (DC Sites)
Interface Settings
WAN Networks
Circuit Settings
High Availability Settings
ION Software Upgrade
Cloudblades
VPNs and GRE Tunnels
Policies
Generic
Path policy
Defaults and Paths
DC Group for Transit Traffic
Prisma SD-WAN (CloudGenix) Control Apps in Policy
QoS Policy
NAT Policy
Security Policy (ZBFW)
Performance Policy
Routing
Static Default Route
BGP Peer Authentication
BGP Edge Peer
Multicast
Network Management
Network Time Protocol
Syslog
Simple Network Management Protocol (SNMP)
IPFIX
Public Cloud Deployment
AWS Deployments
Azure Deployments
This guide captures Prisma SD-WAN Best Practices in a form of product settings, configurations, procedures that have been shown by experience to produce optimal results and that can be established or proposed suitable for widespread adoption.
This document describes the administrator's tasks, actions, and guidelines for deploying Prisma SD-WAN. It is not a training or configuration guide nor replaces the product documentation or professional services recommendations.
Architecture Overview
The Prisma SD-WAN architecture comprises a cloud-based SaaS controller and multiple ION data plane endpoints deployed at customer sites. Distinct from conventional networking devices like routers and switches, ION devices are centrally managed and orchestrated via the controller, which serves as the single source of truth and definitive authority for policy configuration, network topology, etc. The Prisma SD-WAN Controller provides an interactive graphical user interface to securely configure, provision, monitor, and troubleshoot the network.
See more at Prisma SD-WAN Security Architecture - Palo Alto Networks
ION Devices
The Prisma SD-WAN ION devices are responsible for handling data plane traffic. Before integrating into the network fabric and receiving policy configurations from the SaaS controller, each ION device must undergo an authentication and authorization process. This is achieved by using digital certificates to establish the initial secure TLS connection with the controller. The ION devices relay anonymized network and application metadata back to the controller through the secure TLS connection. The metadata include metrics such as bytes transferred, link capacity, voice MOS score, transaction error rate, transaction time, event notifications, alerts, alarms, etc. Note also that customer data traffic is never sent to the controller.
Find more in ION Datasheet
Simplified Management and Operations
The Prisma SD-WAN solution is shipped by default with numerous configuration and security best practices. For example, all public-facing WAN interfaces are fortified by default, disallowing any external inbound connections, thus enhancing network security. Features like VPN tunnel configurations, tunnel IP addressing, encryption profiles, and route propagation throughout the network fabric are automated, embedding best practices, thus eliminating the need for manual setup. The automatic generation of appropriate route maps while configuring the hub BGP core and edge peers further strengthens the integrity of the BGP routing domain, protecting it from potential routing issues.
For more information visit the Prisma SD-WAN Documentation page
Use Chrome Browser as your preferred browser
Although all popular browsers are supported the Chrome browser is the defacto browser that the Prisma SD-WAN QA team tests thoroughly.
The Prisma SD-WAN Strata Cloud Manager (SCM) can be accessed using a locally created tenant account or SAML-based (Security Assertion Markup Language) authentication. Integrate the SCM portal access with an enterprise authentication system or known federated identity management solutions like OKTA, PingID, etc. The authentication system may be enhanced for stronger multi-factor authentication (MFA). SAML allows customer-specific authentication and authorization schemes to allow granular user access or deny access to the SCM SD-WAN instance at the tenant level. Prisma SD-WAN supports SAML 2.0-compliant IdP authorities, including ADFS, Okta, PingFederate, and Salesforce.
Role Mapping and desired permissions are critical to the SAML-enabled authorization process. Before a user can access the Prisma SD-WAN as an authorized user, the role must be mapped to a Prisma SD-WAN role in the system. Through role mapping, user group memberships, as defined in the customer’s IdP system, will be mapped to Prisma SD-WAN authorized roles so that specific access can be granted to users at different levels.
All ION devices are shipped with the default username (elem-admin) and password. This password is changed to a randomized string when the device is claimed in the SCM portal. It is recommended that these login passwords be rotated every 60 or 90 days, depending on the customer’s info-sec policy. As a generic guideline, prefer to access the ION device with the portal UI option (ION Device Toolkit) over direct CLI access.
A limited number of configuration commands may be done on the ION devices directly, like Interface configs - IP, Speed/Duplex, Control Plane ciphers, etc. In the case of CLI access, the only option is the SSHv2 method (Telnet access is not supported). The ION can accept SSH connections by using a direct IP method or remote access from the portal. The remote access from the portal will log the entries and timestamps for audit purposes. It is recommended to use the Remote Access method, which uses SSH over the TLS connection where the device is online. If the device is offline, direct SSH over IP method can be used as a fallback. By default, the IPs of public circuits will not allow a direct SSH to the device due to security reasons.
Prisma SD-WAN systems use strong password authentication checks (avoiding weaker passwords) as a best practice. Note that portal UI configuration overwrites CLI commands.
Prisma SD-WAN’s RESTful architecture provides an ability to completely manage and control your network through automation. The instructions and APIs differ depending on the management platform being used: Strata CloudManger or the Legacy Prisma SD-WAN Management portal.
The service account needs to be granted appropriate roles and access to the applications and services that you intend to manage using APIs.
Once the service account with the appropriate roles is created, the client ID and client secret are used to generate the short-lived (15 minutes) JSON Web Token (JWT) which is used to authenticate the HTTPS request. This JWT is embedded as a Bearer token in the HTTPS header. Since the tokens are short-lived, they need to be renewed prior to expiration for a seamless RESTful transaction. More details on the Service Account can be found here https://pan.dev/sase/docs/service-accounts/
Customers using the legacy Prisma SD-WAN controller to manage their Prisma SD-WAN network need to create an Authentication Token for authentication purposes. Before creating the auth token, it is important to understand the following security measure available in Prisma SD-WAN by default.
All user profiles have IP Session Lock enabled by default. When an auth token is created, these properties are inherited by the token as well. This means when an auth token is generated, the client IP is bound to the token as the IP Session Lock is enabled. Any API request originating from a session IP that doesn’t match the client IP at creation will be rejected. If the end user intends to use the auth token on a VM, a cloud environment or intends to share it to a different user in the monitoring group, it is recommended you set IP Session Lock to disabled or configure the appropriate prefixes that need to be allowed on the User Profile.
To disable IP Session Lock, go to System -> Access Management -> User Access -> User Management menu.
Look for your user profile, click on edit and set IP Session Lock to disabled prior to creating the authentication token.
To create an Authentication Token, go to System -> Access Management -> Tenant Access -> Auth Tokens menu.
When creating an auth token, specify an appropriate role and expiry to enforce password rotation based on the enterprise's info-sec policy.
Do not use username/password authentication for automation when leveraging the legacy API’s Prisma SD-WAN API’s (https://pan.dev/sdwan/api/legacy/).
Tenants that were migrated to Strata Cloud Manager from the Legacy Prisma SD-WAN Controller, will have access to both sets of APIs and authentication mechanisms. It is recommended you migrate to using the auth token for authentication instead of username/password as the login API endpoint will be deprecated after migration to Strata Cloud Manager.
When an auth token is created, the user profile’s properties are inherited by the token as well. This means when an auth token is generated and the user profile has the IP Session Lock is enabled, the client IP is bound to the token. Any API request originating from a session IP that doesn’t match the client IP at creation will be rejected. If the end user intends to use the auth token on a VM, a cloud environment or intends to share it to a different user in the monitoring group, it is recommended you set IP Session Lock to disabled.
To manage IP Session Lock Settings, go to Manage -> Prisma SD-WAN -> Access Management -> Tenant Access -> Auth Token Session Lock.
Look for your email, click on edit and set IP Session Lock to disabled prior to creating the authentication token.
To create an authentication token to continue using tools, utilities and scripts written using Legacy Prisma SD-WAN APIs, go to Manage -> Prisma SD-WAN -> Access Management -> Tenant Access -> Auth Tokens
To claim an ION device, it must be powered on and connected to Prisma SD-WAN service. The ION must be able to connect to the Internet and have a DNS server configured. By default, the controller port of any ION is set for DHCP and is the preferred port. Other ports that may be used in DHCP mode “out-of-the-box” depend on the device model. If the ION does not have a dedicated controller interface, use Port1 or Internet1.
The following ION models table lists the interfaces shipped with DHCP enabled. The last column are the ports that can be used to connect to internet and initiate the Zero Touch Provisioning (ZTP) service:
| ION Model |
Controller Ports (default) |
DHCP enabled Interfaces (default) | Ports that can be used as Internet (default) |
|
ION 1000 |
N |
1-4 (All) |
1-2 |
|
ION 1200 |
N |
1-4 (All) |
All |
|
ION 2000 |
Y |
2-3 |
1-5 |
|
ION 3000 |
Controller-1 (2 ports) |
Internet 1-2 |
Internet 1-4 |
|
ION3200 |
N |
1-8 (All) |
1-2 |
|
ION5200 |
N |
1 - 22 (All) |
1-2 |
|
ION7000 |
Controller-1 (2 ports) |
Controller-1 & 2 |
1-2 |
|
ION 9000 |
Controller-1 (2 ports) |
Controller-1 & 2 |
1-2 |
|
ION9200 |
N |
1 - 22 (All) |
1-2 |
The Online-Restricted device status under the Unclaimed Devices list determines a successful connection to the SD-WAN service.
If DHCP is not enabled at a site, you must use the console cable to connect to the ION console port and configure a static IP address, DNS and IP gateway through the CLI: Assign a Static IP Address Using the Console
The device status will also stay offline if the SD-WAN controller port 443 is unreachable. See more at Allow IP Addresses in Firewall Configuration.
Note that in the case of the On-Premises Controller deployment, you must follow the guide for ZTP Service to Connect ION Device to On-Premises Controller.
With naming conventions, you can search and locate the Branch by its name on the list views. The site address search returns the latitude and longitude and correctly positions the site on the map. Sites without addresses appear in the middle of the map on the Atlantic Ocean.
Create a site with all essential configurations and validate its functionality. After the site is operational, this site can serve as a foundation for a site template. Importing a site template involves downloading previously utilized templates, adjusting them as per your requirements, and then re-importing the updated versions.
Configure Site-level prefixes for DC Sites
Always configure the site-level prefixes for DC Sites (this is not required for Branch sites). A Branch can use all DC’s for transit traffic (to unknown private or public prefixes) and pick a DC based on the DC Groups in the Path Policy. To send traffic to prefixes inside a DC, we need to configure DC Site-level Prefixes. A Branch will then send traffic to that prefix to the specific DC.
In steady-state conditions, all interfaces on the ION devices should run clean without any drops or errors. Interface-level errors can trigger an undesired chain of events, causing performance issues and destabilizing the network. Determining the root cause of the interface of errors can be tricky. Some of the common reasons for interface errors are misconfiguration or speed and duplex, wrong or bad cable and/or bursty traffic conditions, etc.
One common reason for interface-level errors is a speed and duplex mismatch. This usually results in CRC errors or drops. Prisma SD-WAN ION devices support both auto and hard-coded speed and duplex sensing. If interface errors are observed, ensure that the correct speed/duplex is configured.
Configure DNS (either external or internal, depending on the setup) under each interface. Since DNS is UDP-based, failure to reach a DNS server can result in a blackout, therefore configure multiple DNS servers for resiliency.
On the Cellular interface (cwan), the Firmware page displays the current firmwares available on the modem and the current recommended firmware and version. Upgrade the firmware when the recommended version is different from the current version for your specific carrier. The ION device downloads the new firmware from controller inventory and then upgrades the carrier firmware on the modem.
On the DC ION Core (LAN side) facing interface, there is no need to configure a circuit label if there is no need to build any Standard VPN tunnels from this LAN interface. In this case, you also do not need to configure the default gateway on this interface, since the next-hop reachability is via BGP. The Core BGP peer provides reachability information on the LAN side to the DC ION. In case BGP is not used (DC IONs not in HA setup), you will need a static default route on the DC ION.
In Prisma SD-WAN, a WAN network is a reference to your service provider viz. AT&T, Verizon, Comcast, BT, etc. Service Providers you subscribe to for Internet access need to be defined under Internet Circuits.
Similarly, Service Providers you subscribe to for MPLS or Private WAN access need to be defined under Private WAN Circuits.
First define all the providers across your entire estate, and use these references when defining your circuits (review section on Circuit Settings). This is important as it helps Prisma SD-WAN correlate incidents and performance degradation across different circuits and associate it with a specific service provider. Not having a consistent reference for a provider, may result in multiple incidents and inadequate correlation as the provider name is used as a key for correlation.
When configuring the site-level circuit details, a default name is pre-populated. It is recommended that you provide a meaningful circuit name, which will help troubleshoot path-related flow details.
Use abbreviations that include Site Name, Circuit Type, and Circuit Provider
As an example, a site in Chicago that has 1 Verizon ISP and 1 ATT MPLS circuit, the circuit labels can be named as “CHI-INET-VZN” and “CHI-MPLS-ATT”. Similarly a DC site in New York can have the circuit labels “NYC-DC-INET-VZN” and “NYC-DC-MPLS-ATT”. When looking at flow browser details, the path taken (to which destination site and which circuits) will be easy to observe.
Customers must add comments to configure a device, such as a site description, port labeling, and tags. The tags and descriptions help identify what the port is used for, and tags can also be used for automation purposes
Aggressive mode is the default mode and is recommended by Prisma SD-WAN for fast failure detection of links.
Hard code the Circuit speed settings
Circuit speed hardcoding will prevent a port from being negotiated into a sub-optimal setting. The WAN circuit speeds must be matched with carrier-provided specifications and specifically configured. The default values should not be trusted.
It is recommended to use a slightly lower value (1-2 %) for the Download/Upload BW on the circuit, from the values given by the Provider. This is to ensure that the ION QoS kicks in slightly before the circuit limit is reached, so as to ensure prioritization of the critical applications. For example, if the circuit is rated for 100M down, 50M up, you can configure the circuit settings for 99M down, 49M up. This ensures that the ION QoS starts kicking in at 99M down, 49M up and starts prioritizing applications according to the configured QoS policies.
Minimize the data usage of metered 5G/LTE backup links when other active paths are unavailable. With this best practice, you send data over metered links for business continuity only when the primary connection is unavailable, ensuring flexibility and agility at a lower cost.
By extending the VPN keepalive timer this will reduce the amount of data used on this cellular carrier, but by extending this timer it can reduce the failover time if the ION moves from using one DC ION to another DC ION in the DC Cluster.
When Creating a circuit, you must select a circuit category and a WAN (Carrier). You CANNOT use the same category twice at a site.
For example, you cannot designate two Internet Cable circuits at a site even if they are from different carriers. This is because the circuit category defines the Circuit Label and is used in path policy. Having two circuits at a site with Ethernet Internet as the circuit category would not allow you to differentiate between those circuits in a path policy. There are 30 Internet categories and 30 public categories, including ~ 20 named public or Private. These names can be changed, so often, two or more circuit categories may be modified to a convention, such as ACME-INTERNET-1 and ACME-INTERNET-2.
If a path policy requires the use of Overlay over a Private path (e.g., MPLS), make sure the WAN network matches at the branch site and data center. On the data center side, there could be multiple MPLS circuits from different carriers. Each carrier will have its own WAN network assigned. So, to make sure connectivity comes over the correct carrier circuit, the WAN network needs to match; otherwise, the VPN status won’t come up.
In HA deployments, the customer is expected to have two circuits. The circuits must be terminated directly on each of both devices and indirectly through the Hardware Fail to Wire interface. This setup is particularly helpful when performing RMA on any one of the devices and ensures the site has at least one circuit available on the remaining device to handle the traffic seamlessly.
DHCP IP address allocation can take longer resulting in longer switchover time. When using the site in Branch HA mode, make sure the interface IP is not DHCP enabled and it is statically configured. This is necessary to avoid situations when the DHCP server is not local and is not able to reach it. This can cause instability in the HA states and can get unpredictable.
Directly establishing the High Availability (HA) connection between devices is preferred only in cases where there are no southbound LAN switches present and exclusively only with 1200-S and 3200-L2 models with redundant ports.
The interface tracking of a LAN interface depends on the design. Each device will automatically track the state of the HA-control interface. Upon a failure of the interface, the device will immediately transition to a failed state, giving way to the other device in the HA group to become active. In addition, an administrator can optionally configure up to four non-HA control interfaces to track, and for each interface that goes down, the HA priority of the device will be reduced by the configured value.
Priority is assigned to devices to dictate preference during election. For example, certain topologies may require that a particular device be active while the other remains as a backup device. In such cases, an administrator can assign a higher priority to the device with higher preference to dictate which device becomes active during election, with the highest priority being 255. In the event of a process crash, each non-critical process will decrement the priority by 25 while a critical process will decrement the priority by 255.
The Advertisement Interval indicates how often the active device advertises its status to the backup. Three consecutive missed advertisements indicate that the active device has failed after which a backup device becomes active and takes over as the active device.
Before performing the software upgrade, it is important to download the software properly. You should download the software first and then perform the upgrade during a change window. That will ensure the code is already downloaded and minimize the downtime.
For a streamlined autoconfiguration of IPSec or GRE tunnels, explore the available options provided by CloudBlade. If Cloudblade integration exists avoid using manual configs due to the risk of misconfiguration and extra troubleshooting effort.
The CloudBlades are designed to be the source of any configuration settings they manage.
If a zone or device is not bound to an interface or subnet, it blocks all the traffic.
In general it is not advisable to set the state of any Cloudblade to “Disabled” unless you want to offboard the specific integration you have enabled via the Cloudblade. For most situations if you need to stop further changes by the cloudblade you should only use the “Paused” state.
If you do wish to gracefully offboard the specific Cloudblade then you should use the “Disabled” state and after some period of time “Uninstall”, please refer to the specific Cloudblade Integration guide for more details.
Note that there is a configuration convergence time period in each case.
GRE tunnels are stateless by design, the GRE tunnel is established when the standard VPN interface is created, and the parent interface is up. With the GRE keep-alive enabled or having a liveness probe configured on the standard VPN endpoint such that a failure can be detected and avoid traffic being black-holed.
Prisma SD-WAN supports Generic Routing Encapsulation (GRE) tunnels from branch or data center sites to standard VPN endpoints to integrate with cloud security services. Due to the insecure nature of GRE consider protecting the site with ZBFW policy. As an additional measure, consider the implementation of a NAT policy. With NAT you hide the internal addressing scheme being visible over GRE and can significantly decrease the attack vector.
When using an internet WAN, you can manually configure an IPSec or GRE tunnel to enable direct traffic flow between Prisma SD- WAN branch sites and non-Prisma SD-WAN sites.
Prisma SD-WAN provides two types of Policies - Simple and Advanced - for the Path, QoS, NAT, Security and Performance. Always consider starting with Simple policies, as this simplifies the policy management.
You may use the Advanced Policies in complex deployments where many variations of policies are needed for different SItes, or need to use inheritance and overloading of policies. With Advanced Policies, you can create Policy Sets and Policy Stacks which provide you more flexibility in grouping policy sets and rules, but can become complex.
Paths for default rules should be modified according to the customer environment, e.g. Paths should not reference “Any Private” or specific private categories if they are dual internet sites i.e public wan.
DO NOT configure metered cellular services into the default or enterprise default rules.
Configure 4g/5g as a path of last resort in path policies, any traffic could be passed over those paths, including non-critical business applications or non-productive Internet traffic, like YouTube, Facebook or Spotify. This could result in unplanned billing events
Policy Example of a Branch Site with MPLS, Internet and LTE for backup.
Each location should have a primary and secondary data center.
Each policy (Path and Qos) is configured with two default rules, a “Default”, used for internet bound traffic and an “Enterprise-Default”, used for all traffic destined to RFC1918 (private) address space. There is no need typically to configure additional rules that match ALL (internet or enterprise) traffic.
This will ensure the device-to-controller connectivity and App health probing works without any interruption.
If some of these paths have security appliances that are doing SSL decrypt in the path, then these paths should be excluded, or the Prisma SD-WAN controller FQDN/IPs are excluded as per the following document: Allow IP Addresses in Firewall Configuration
Validate that Application Probing is configured. The ION cannot validate App reachability over different paths (end to end) without application probing and will use its controller port by default. ION devices need to designate one port as a control
port to support application probing. A LAN port should be used for application probing if the ION controller port is connected to Out-Of-Band management.
A default Internet NAT rule is applied to all branches for supporting the outbound traffic from Enterprise to Global prefixes
UCaaS systems require that network solution providers disable the SIP ALG (Application Layer Gateway) for any traffic that crosses a NAT boundary destined for a SIP provider. The SIP traffic (via Path Policy) utilizes the internet link directly. As such, it uses the default NAT policy. Most of the UCaaS providers specified to disable SIP ALG.
Once created, add the Default-NATPolicySet to the stack, then create a new NAT Set with a rule that disables ALG and bind it to the new NAT Set to the new NAT Stack.
Performance Policy provides a flexible framework for the assurance of Application and Network SLAs.
* For Performance Policy there are two important metrics to consider; the total number of rules and the number of specific application IDs that match per rule.
* Multiply the total number of rules by the total number of application IDs matched, and check this against the policy rule config limits for the ION platform being used. The limits can be obtained from the Field Sizing Guide
* The branch ION determines if the SLA will be met in both the inbound and outbound direction on a per path basis. * * In the case that inbound (from the DC) loss exceeds the SLA the branch ION sends an in-band instruction attached to a packet to the DC ION instructing it to invoke FEC for the affected flow.
* If the number of VPNs actively invoking FEC meets the platform limit (above) then no further VPNs will be able to encode or decode recovery information.
* ION Device version 6.3.2 or higher is recommended when using Forward Error Correction.
* See more at Best Practices and Recommendations
For the most part learning a default route from a core BGP peer on the Hub device is sufficient. In case of a misconfiguration where the BGP learned default route is withdrawn, this static route will come into play ensuring the traffic gets routed to the core peer(s). It is recommended to enable next-hop tracking on this default route to ensure there is reachability to the appropriate next hop address.
Peer authentication with MD5 creates an MD5 digest of each packet sent as part of a BGP session. Specifically, portions of the IP and TCP headers, TCP payload, and a secret key are used to generate the digest. The receiving BGP speaker uses the same algorithm and secret key to regenerate the message digest. If the received and computed digests are not identical, the packet is discarded.
For an SD-WAN deployment where all traffic over MPLS needs to be encrypted - i.e only the MPLS overlay will be utilized, not the MPLS underlay - there is no need to setup BGP Edge peering on the DC/HUB IONs. The Edge peering on the DC ION to the MPLS router is only needed to learn Branch prefixes on the MPLS underlay. If no traffic is to be sent on the MPLS underlay, the DC ION does not need to learn the MPLS underlay prefixes. The DC ION needs to build the VPN tunnels for the MPLS overlay, so all it needs is reachability to the MPLS interfaces for the remote Branch IONs. This is accomplished by the next-hop gateway configuration on the MPLS facing interface on the DC ION. In such deployments, the DC ION only needs the BGP Core peering to the LAN Switch/Router, no BGP Edge peering is needed to the MPLS router. Make sure you have the circuit label (for the MPLS circuit) attached to the MPLS facing interface on the DC ION.
SPT Switchover is enabled by default. This indicates that once the first multicast packet is received, the multicast routing chooses the optimal path to relay information from the source to the receiver.
The Network Time Protocol (NTP) is recommended to be explicitly configured using a trusted time source and to use proper authentication.
Accurate and reliable time is required for syslog purposes, such as during forensic investigations of potential attacks, as well as for successful VPN connectivity when depending on certificates for authentication.
When you configure NTP, the time zone needs to be configured so that timestamps can be accurately correlated. There are usually two approaches to configuring the time zone for devices in a network with a global presence. If the SD-WAN Network spans globally it is recommended to configure all network devices with the Coordinated Universal Time (UTC). For a regional SD-WAN deployment, the other approach is to configure network devices with the local time zone.
Send logging information to an enterprise syslog server.
Send the Syslog messages over VPN or private underlay if allowed via policy. Use the Control port as the source interface.
This makes it possible to correlate and audit network and security events across network devices more effectively. syslog messages are transmitted using the UDP and in cleartext. For this reason, any protections that a network affords to management traffic (for example, encryption or out-of-band access) should be extended to include Syslog traffic.
Use the SNMP Version 3 (SNMPv3) agent which is an interoperable standards-based protocol for network management. SNMPv3 provides secure access to devices because it authenticates and optionally encrypts packets over the network. SNMP Traps can be sent directly to the SNMP servers.
SNMP 
Community strings are passwords that are applied to an ION device to restrict access, both read-only and read-write access, to the SNMP data on the device.
These community strings, as with all passwords, should be carefully chosen to ensure they are not trivial. Community strings should be changed at regular intervals and per network security policies. For example, the strings should be changed when a network administrator changes roles or leaves the company.
IPFIX is a protocol that allows network administrators to export detailed flow information, such as source and destination IP addresses, ports, protocol types, and packet counts, from network devices to a collector or analyzer. This information can be used for network traffic analysis, performance monitoring, and security audits. Internet Protocol Flow Information Export (IPFIX) is an IETF standard export protocol for sending Netflow packets. IPFIX is based on Netflow version 9. Prisma SD-WAN portal has a graphical flow browser and other network analytics tools available but sometimes for offline viewing and detailed investigation, IPFix exported flow details can be very useful.
Benefits of using IPFIX:
To deploy vION in AWS there are two options, first and the most simple is to use the AWS Transit Gateway Cloudblade which will automatically deploy a pair of vION (7108) and create the connectivity to the AWS Transit GW in each region you chose to deploy.
For more information refer to the following document:
AWS Transit Gateway CloudBlade Integration Guide
Optionally you can deploy a pair of HA vION in AWS using the Marketplace listing and specifically the “HA Greenfield'' CFT (Cloud Formation Template), this can be used in situations where the AWS Cloudblade may not meet all your requirements.
For more information refer to the following documents:
Virtual ION on AWS Deployment Guide
AWS Cloud-WAN Integration Guide (Tunnel-less Connect)
It’s important to remember that when using IONs in DC mode in HA that BGP is required on the Core/LAN side for route advertisement. In the case of AWS this is most commonly going to require BGP connections using a VPC Connect peering to a Transit Gateway or CloudWAN Edge Node.
To deploy vION in Azure there are two options, first and the most simple is to use the Azure vWAN with vION Cloudblade which will automatically deploy a pair of vION (7108) and create the connectivity to the Azure vWAN Hub in each region you chose to deploy.
For more information refer to the following document:
Azure Virtual WAN with vION CloudBlade Integration Guide
Optionally you can deploy a pair of HA vION in Azure using the Marketplace listing and specifically the “Prisma SD-WAN vION HA'' Solution Template, this can be used in situations where the Azure Cloudblade may not meet all your requirements.
For more information refer to the following document:
Virtual ION on Azure Deployment Guide
It’s important to remember that when using IONs in DC mode in HA that BGP is required on the Core/LAN side for route advertisement. In the case of Azure this is most commonly going to require BGP connections to an ARS (Azure Route Server) or Azure vWAN Hub.
— END OF THE DOCUMENT—
