Is the Overlay IP CIDR range for SAP on AWS just a secondary CIDR range added to same VPC?
I was reading the docs on HA configurations for SAP on AWS, and I see that you need a non-overlapping CIDR range to draw your overlay IP from. Is that just a secondary CIDR range that you need to add to the VPC in which your SAP cluster lives?
- Newest
- Most votes
- Most comments
Hi, Good question! The overlay IP has to be assigned from a range that is explicitly outside of the CIDR ranges assigned to your VPC. I suggest getting your network administrator to allocate a CIDR that is not assigned within AWS or on-prem for this purpose but is still with the RFC 1918 ranges.
- 10.0.0.0 – 10.255.255.255 (10/8 prefix)
- 172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
- 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
If you use the 10/8 prefix in AWS we often see a 172 or a 192 IP address used as an overlay to help differentiate.
To explain further, the purpose of an overlay is to be able to make a connection, regardless of which AZ (and subnet) your primary node is running in. Subnets can not span across AZs, so the connection is made using a pointer in a route table which routes the overlay IP to the primary node and is updated using clustering software. If the IP address was allocated from a CIDR within the VPC this would conflict with standard routes.
Hope that helps.
NOTE: This answer is provided by the SAP on AWS specialty team and is accurate at the time of publish. Please check comments as the answer may have changed/services evolved.
Relevant content
- asked 2 years ago
AWS OFFICIALUpdated 2 years ago- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated a month ago
- AWS OFFICIALUpdated 2 years ago
Got it--the OIP is not just not a part of primary CIDR range of VPC but also not part of any CIDR range from the VPC. Having learned all of my networking knowledge in an AWS context, I could still use more clarification on what the network admin would do when I get them to "allocate a CIDR that is not assigned within AWS or on-prem for this purpose but is still within the RFC 1918 ranges." Is this purely logical: like, it only lives in the network admin's documentation/spreadsheet, route tables in AWS, and the HA extension server's configurations? Like, there's no actual "provisioning" of a network or subnet anywhere?
Yes, your assumptions are correct. It is not actually provisioned. An IPAM might help https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html but the only purpose is so that it is not used elsewhere.