- SAP Managed Tags:
Introduction
When organizations adopt RISE with SAP S/4HANA Cloud, private edition, one of the key considerations is the selection of IP address space. Large organizations often struggle to maintain a non-overlapping IP address management throughout its various business units, departments and regional setups. The SAP ERP system is one of the central components requiring access from various employees which are often distributed globally. RISE with SAP S/4HANA Cloud, private edition can be seen as an extension to a customer-owned corporate data center allowing them to connect in a secure way with a wide selection of connectivity options. RISE with SAP private cloud landscapes are hosted in a dedicated Virtual Private Cloud which is a virtually isolated network in a public cloud provider or in an SAP Data Center depending on customer’s choice. To assure the same secure framework your organization stipulates while providing all the features and capabilities SAP offers, a private connection to the landscape is required.
While it is essential that all relevant business entities can access the resources in the SAP private cloud, certain limitations do apply when planning the IP addressing.
This article only focuses on RISE with SAP S/4HANA Cloud, private edition. If you are looking for key differences between private and public edition, their capabilities and different security frameworks, please follow these two very good article:
Difference between SAP S/4HANA :Public Vs Private edition : RISE with SAP
BYOIP - bring your own IP
To avoid any impediments from the start, there are no pre-defined ranges which are assigned to the SAP private cloud. Customers always bring their own IP address space which fits into their IP address scheming. This allows for the most flexibility and independence for each customer. BYOIP enables customers to design and implement custom network architectures tailored to their specific needs. Customers can configure on-premise routing tables, firewall rules, and network policies according to their preferences and requirements. This decision allows customers to choose not only private but also public IP addresses. Recommendation is to only use public IP addresses if they are customer-owned, otherwise routing issues will occur.
Landscape Sizing: planning ahead
The minimal viable CIDR range to deploy RISE with SAP S/4HANA Cloud, Private Edition for a customer is a /23 subnet (in total 512 IP addresses). The only exception here is GCP where a /22 subnet is needed to cater the additional IP address requirements for GCFS.
Depending on the amount of SAP systems to be migrated, additional space should be reserved upfront. In the smallest landscape deployment with a /23 subnet, both the Prod01-1 and its short-distance DR counterpart Prod01-2 in the second availability zone will be equipped with a /25 subnet (each with a total of 128 IP addresses) while the remaining IP addresses are used for providing the landscape with central services, gateway subnets or are reserved for future use-cases like outbound NAT, WAF etc
While the diagram depicts an AWS setup, a similar configuration is applicable for Azure and Google Cloud.
The Prod01-1 and Prod01-2 subnets will be used to deploy SAP systems workload. Per VM, 3-4 IP addresses are calculated from the Prod subnet to cover the need for separating between services running on the VM, e.g., for DBs, each DB tenant gets an own IP on the same HANA server. Additionally, internal load-balancers, Web Dispatchers and Cloud Connectors are deployed in the same subnet. Thus, a /25-subnet can host around 30-40 systems.
SAP strongly advises customers to invest time into the initial sizing and IP address planning. Subnets cannot be increased in size, and only additional ones can be deployed. However, this may require the deployment of additional address space in the Virtual Private Cloud.
Additionally, the following limitations do apply per cloud provider
- On Azure, if you are connected via VNET peering and a new address space is added post deployment, the peering must be resynced which requires a short downtime and manual interaction on both end of the peering
- On AWS, a maximum of 5 CIDR ranges can be applied to a VPC. This limit can not be circumvented. Additionally AWS has various limitations when adding a new CIDR range, see full list here
In deployment scenarios with long distance DR, a second Virtual Private Cloud will deployed in a different region. This VPC must follow the same IP addressing guidelines as the main site.
Known reserved IP address ranges
The following ranges can not be used in the RISE with SAP private cloud subscription:
| Cloud provider | Prefix range | Reason |
| all | 100.64.0.0/10 | CGNAT space, SAP admin central infrastructure services, container services |
| all | 147.204.0.0/16 | SAP provided anycast, internal admin services |
| all | 169.145.0.0/16 | SAP owned address space |
| all | 198.18.0.0 /15 | Various use-cases |
| Azure | 224.0.0.0/4 | Multicast |
| Azure | 255.255.255.255/32 | Broadcast |
| Azure | 127.0.0.0/8 | Loopback |
| Azure | 169.254.0.0/16 | Link-local |
| Azure | 168.63.129.16/32 | Internal DNS, DHCP, and Azure Load Balancer health probe |
| AWS | 172.17.0.0/16 | AWS services |
| AWS | 169.254.0.0/16 | Link-local |
| AWS | * | several conditions apply when adding an additional CIDR range, see AWS documentation |
| GCP | 169.254.0.0/16 | Link-local |
| GCP | 127.0.0.0/8 | Loopback |
| GCP | 224.0.0.0/4 | Multicast |
| GCP | 255.255.255.255/32 | Broadcast |
| GCP | 199.36.153.4/30 and 199.36.153.8/30 | Private Google Access-specific virtual IP addresses |
| GCP | 0.0.0.0/8 | Current (local) network RFC 1122 |
| GCP | certain public IP addresses | Public IP addresses for Google APIs and services, including Google Cloud netblocks. |
| GCP | 172.17.0.0/16 | GCP uses this for their internal third party products |
Please confirm the restrictions with each cloud provider. These restrictions can not be circumvented. This also means if you are using these IP addresses on-premise, you will not be able to access the RISE with SAP private cloud since those can not be routed back to on-premise.
Other limitations and restrictions
- there is currently no IPv6 support
