What is the purpose and impact of the optimization?
What WSS POPs are physically unique?
Starting in January 2021, Symantec will begin renaming select points of presence (POPs) to better reflect their post-Google Cloud migration locations. As a result, some POPs will be renamed appropriately and we will also start indicating the type of each POP (“VPOP” or “compute POP”). These changes will also allow us to scale our existing POPs more efficiently and dramatically reduces the need for new IP ranges as we add capacity.
The changes will not negatively impact your performance because no compute POPs are being removed as part of this process. Some redundant IP ranges assigned to WSS Agent infrastructure will be removed because the IP addresses are no longer necessary now that we are fully migrated to Google Cloud. No IPsec IP addresses will be removed so your existing tunnel configurations will continue to function, as long as you are using a supported IPsec ingress IP address.
Any preparation required for the optimizations will be communicated to customer administrators via normal communications procedures prior to each POP-specific maintenance window. Most of the changes are very low-impact in nature but be sure to review the announcements carefully.
What to expect:
Moving forward, our published POP list will include the type of POP for transparency. There are two types:
The WSS migration to Google Cloud in Spring 2020 required “mapping” old data centers to Google Cloud Regions in order to make IPsec migration seamless for thousands of customers. The mapping was accomplished by simply moving the IP addresses from the old data centers to the nearest Google Cloud Region, collectively saving customers tens of thousands of work-hours by removing the need for them to change their tunnel configurations. While this mapping was extremely helpful in simplifying the migration for our IPsec customers, it is now a hindrance to transparency and can make selecting the nearest POP more difficult.
Thanks to its global private network and extensive interconnects with carriers, content providers, peering exchanges, and CDNs, our Google Cloud regional POPs are able to service a much larger geographical area than infrastructure hosted in colocation data centers, resulting in a smaller POP count, but better overall coverage. As a result, there were instances where a single Google Cloud region inherited IP addresses for more than one of our colo data centers.
During the migration, Google’s US Central Region, located in Iowa, became the home for the WSS IP addresses and infrastructure previously belonging to Dallas, Denver, and Chicago. Therefore, ever since the Google Cloud migration, Dallas, Denver, and Chicago have been VPOPs leveraging compute located in Iowa. There is no benefit in keeping those POP names since they are all really just one physical compute POP. The resulting Iowa POP will be designated “Des Moines.” Some VPOPs will not be renamed because they provide localization for a specific country.
No Adverse Changes to the Data Path
The path that your traffic takes will not degrade with these changes. In fact, in some cases, agent users will begin to leverage a slightly closer POP. This can happen when a VPOP is renamed to more accurately reflect the location of its corresponding compute. When a VPOP name is changed, it’s egress IP address geo-location is also changed to reflect the location of the compute POP.