To complete this chapter, you should have a working knowledge of Border Gateway Protocol (BGP) and cloud networking.

In this section, we’ll learn how the basic building blocks of Prisma Access communicate with one another. This knowledge is critical in the later stages when building, planning, and troubleshooting to understand why certain components act differently from others.

Important concepts

Before we get started, we need to learn about the building blocks. We will dive much deeper into the individual components in the next few chapters, but it is important to gain a good understanding of what each component is for so that you can more easily imagine where each piece fits into the puzzle. We’ll start with a basic outline and gradually build upon what we’ve learned. This is what you need to know so that the following sections make sense.

Cloud infrastructure is the base on which everything is built. It is the embodiment of the tenant that is spun up. Any configuration changes you make here apply to everything; it is the cloud where everything...

As we saw earlier, the service infrastructure is what ties everything together. To ensure all the components can communicate with each other, a subnet is needed; this serves as the backbone of everything. IP addresses will be needed to set up internal VPN tunnels and BGP peers.

Since this subnet serves as your backbone network in the cloud, and the cloud is connected to your data centers, a range needs to be selected that does not overlap with any of the production networks. In most cases, an x.x.x.x/23 subnet should suffice to provide enough IP addresses to support the entire infrastructure. However, if the deployment calls for several thousands of remote users in several different locations globally or a large number of remote networks in many different countries, a larger subnet may be required.

As we touched on earlier, remote networks are deployed based on the bandwidth assigned to a specific compute location. Once bandwidth is assigned, one or more RN-SPN nodes are provisioned for a compute location, and remote networks can be connected to them. The first task when planning the Prisma Access deployment is to estimate how many remote offices there will be and what the bandwidth requirements will look like. Once you know how many sites and how much peak throughput is estimated to be required, you can calculate the amount of bandwidth you will need to purchase.

Consider how much bandwidth will be needed; for anything between 50 Mbps and 1,000 Mbps, a single RN-SPN node is spun up in a compute location, but going over 1,000 Mbps will cause a second node to be spun up and the assigned bandwidth to be divided between the two.

At this time, assigning 1,050 Mbps to a compute location would cause two nodes to be spun up; one node will be capable of...

At the time of writing, there are 116 locations available worldwide to select when deploying mobile user security processing nodes. These locations are spread across multiple major regions: the Americas, Europe, the Middle East, and Asia Pacific. There are also some smaller compute regions, such as the Netherlands, Canada, Ireland, and Hong Kong.

When planning out which countries need to be onboarded, you need to consider that each location that is onboarded will require at least one /24 subnet to serve as an IP pool for the mobile users in that country. For larger countries, multiple /24 subnets may be needed to account for the number of simultaneously connected users. These subnets are assigned to the MU-SPNs at random out of a larger global or regional pool by the service infrastructure. You can choose to use one large global pool or lots of smaller regional pools. If a regional pool is depleted, the global pool will be used to extract additional...

In this chapter, we covered the basic building blocks of what makes up Prisma Access and how these are connected. You should now be able to identify that an RN-SPN is used to connect a remote office, an SC-CAN is used to connect a data center, and an MU-SPN is used as an in-country gateway for mobile users.

In the next chapter, we’ll go over the activation process and how to deploy the infrastructure and Cortex Data Lake.