Virtual Networks and Subnets

Designing and Implementing SAP Infrastructure: Virtual Networks and Subnets

Introduction: The Foundation of SAP Cloud Connectivity

In the modern enterprise landscape, SAP environments have migrated from traditional on-premises data centers to cloud platforms like Azure, AWS, and Google Cloud. While the application logic and database management remain central to SAP operations, the underlying networking architecture has become the silent engine that determines performance, security, and reliability. When we talk about virtual networks (VNets) and subnets in the context of SAP, we are discussing the logical boundaries that house your critical business data and application services.

Why does this matter so much for SAP specifically? SAP systems are notoriously sensitive to latency, throughput, and network security. A single misconfiguration in a subnet range or a poorly defined routing table can lead to significant degradation in application performance, or worse, expose sensitive financial and personal data to unauthorized access. By mastering the design of virtual networks and subnets, you ensure that your SAP production, development, and quality assurance environments are isolated, manageable, and performant. This lesson will guide you through the architectural principles, configuration steps, and best practices required to build a network environment that supports the high demands of an SAP ecosystem.

Core Architectural Concepts

Before diving into configurations, we must establish a clear understanding of the fundamental building blocks of cloud networking. At the heart of this is the Virtual Network (VNet), which acts as your private, isolated section of the cloud provider's network. Think of the VNet as your virtual data center. Within this data center, you divide your resources into smaller, manageable chunks called subnets.

Virtual Networks (VNets)

A VNet is the fundamental unit of network isolation. It provides a private address space where you can deploy your virtual machines, database instances, and load balancers. When you define a VNet, you must specify a CIDR (Classless Inter-Domain Routing) block, such as 10.0.0.0/16. This CIDR block defines the total pool of IP addresses available for your entire network environment. It is crucial to choose this range carefully, as resizing a VNet later can be a complex and disruptive process.

Subnets

Subnets are subdivisions within your VNet. They allow you to segment your network into distinct logical areas based on function or security requirements. For an SAP deployment, you typically create different subnets for different tiers of the application architecture, such as:

• Database Subnet: Reserved exclusively for your SAP HANA or other database instances.
• Application Subnet: Used for SAP application servers (ASCS, ERS, and PAS/AAS).
• Management/Jumpbox Subnet: Used for administrative access, such as Bastion hosts or management gateways.
• Integration/DMZ Subnet: Used for traffic coming from or going to external systems or the internet.

Callout: Why Subnet Segmentation is Critical for SAP In a flat network architecture, an application server and a database server might reside in the same IP address space with no internal firewalling. By implementing subnet segmentation, you can apply Network Security Groups (NSGs) to each subnet. This ensures that only the application servers can communicate with the database on specific ports (e.g., SQL ports), effectively blocking any other traffic from reaching the database directly. This "defense-in-depth" approach is a mandatory requirement for any security-conscious SAP implementation.

Planning Your IP Address Strategy

A common mistake made by junior infrastructure architects is failing to plan for growth. When you define your VNet and subnets, you must consider the future expansion of your SAP landscape. SAP landscapes are rarely static; you will likely add new application servers, scale out your database, or integrate new modules over time.

The CIDR Calculation Method

When calculating your address space, use the following logic:

1. Identify the total number of hosts: Estimate the maximum number of virtual machines (VMs) you expect to have in the next three to five years.
2. Add headroom: Always double your estimate to account for unexpected growth or temporary testing environments.
3. Choose the mask: Determine the subnet mask based on the required IP count. For example, a /24 subnet provides 256 addresses, but you actually get 251 usable addresses after accounting for the cloud provider's reserved addresses (usually five per subnet).

Tip: Reserved IP Addresses Always remember that cloud providers reserve the first four and the last IP addresses in every subnet for internal services (e.g., the network address, the gateway, and the DNS server). If you create a /29 subnet, you might think you have 8 addresses, but you only have 3 usable ones. Always size your subnets larger than your initial requirements.

Implementing Subnets for SAP Tiers

A typical SAP implementation involves a multi-tier architecture. Let’s look at how to structure this using a logical design. Imagine we have a VNet with the address space 10.10.0.0/16.

By separating these, you gain the ability to apply granular security policies. For instance, the snet-db subnet should have an NSG that allows ingress traffic only from the snet-app subnet on specific HANA ports (like 3xx15). All other ingress traffic should be explicitly denied.

Practical Configuration: Infrastructure as Code

While you can configure these networks through the cloud portal, industry standard dictates that you use Infrastructure as Code (IaC) like Terraform. This ensures that your network environment is reproducible, version-controlled, and free from human error.

Below is an example of a Terraform snippet to define a VNet and its associated subnets:

# Define the Virtual Network
resource "azurerm_virtual_network" "sap_vnet" {
  name                = "vnet-sap-prod"
  address_space       = ["10.10.0.0/16"]
  location            = "East US"
  resource_group_name = azurerm_resource_group.sap_rg.name
}

# Define the Database Subnet
resource "azurerm_subnet" "db_subnet" {
  name                 = "snet-db"
  resource_group_name  = azurerm_resource_group.sap_rg.name
  virtual_network_name = azurerm_virtual_network.sap_vnet.name
  address_prefixes     = ["10.10.1.0/24"]
}

# Define the Application Subnet
resource "azurerm_subnet" "app_subnet" {
  name                 = "snet-app"
  resource_group_name  = azurerm_resource_group.sap_rg.name
  virtual_network_name = azurerm_virtual_network.sap_vnet.name
  address_prefixes     = ["10.10.2.0/24"]
}

Explanation of the Code

• azurerm_virtual_network: This block initializes the VNet with the specified address space. By setting it to /16, we have allocated a large pool that can be further divided.
• azurerm_subnet: These blocks carve out specific segments of that address space. Notice how the address_prefixes are non-overlapping (10.10.1.0/24 and 10.10.2.0/24). This is critical; if these ranges overlapped, the routing table would become ambiguous, and connectivity would fail.

Network Security Groups (NSGs) and Routing

Creating subnets is only half the battle. You must control the traffic flow between them. This is achieved through Network Security Groups (NSGs) and User-Defined Routes (UDRs).

Network Security Groups (NSGs)

An NSG acts as a virtual firewall. You can apply it to a subnet or a specific network interface (NIC) on a VM. For SAP, we recommend applying NSGs at the subnet level to maintain consistent security policies across all VMs within that tier.

Best Practice Rules for SAP NSGs:

1. Deny-All by Default: Start with a rule that denies all incoming traffic unless explicitly allowed.
2. Restrict Management Access: Only allow SSH/RDP access from specific management subnets or VPN gateways.
3. HANA Communication: Only allow the SAP application server IPs to talk to the HANA database on the required ports.
4. Monitoring Traffic: Ensure your monitoring tools (like SAP Landscape Management or cloud-native monitors) have access to the necessary ports.

User-Defined Routes (UDRs)

By default, all subnets within a VNet can communicate with each other. Sometimes, you need to force traffic through a specific appliance, such as a virtual firewall or a Network Virtual Appliance (NVA). This is where UDRs come into play. You can create a route table that says "all traffic destined for the internet must pass through the NVA," rather than going directly out through the cloud provider's gateway.

Warning: Routing Loops When implementing UDRs, be extremely careful. A misconfigured route table can lead to routing loops where packets bounce between the firewall and the subnet gateway, resulting in total network isolation. Always test routing changes in a sandbox environment before applying them to production.

Advanced Networking: Peering and Connectivity

In larger organizations, you will often find multiple SAP landscapes (e.g., one for North America, one for Europe) or a separate VNet for shared services. To allow these VNets to communicate, you use VNet Peering.

VNet Peering

Peering allows you to connect two VNets as if they were a single network. Traffic between peered VNets travels over the cloud provider's high-speed backbone, ensuring low latency. This is essential for scenarios where your SAP Application Servers might be in one VNet and your shared database management or backup service is in another.

Hybrid Connectivity

Most SAP environments require connection back to the corporate office or an on-premises data center. This is typically achieved via:

• Site-to-Site VPN: An encrypted tunnel over the public internet. Good for smaller environments or proof-of-concepts.
• ExpressRoute / Direct Connect: A dedicated, private physical connection between your data center and the cloud provider. This is the industry standard for production SAP environments because it provides guaranteed bandwidth and consistent latency, which is critical for SAP GUI and RFC traffic.

Common Pitfalls and How to Avoid Them

Even experienced architects encounter issues when deploying SAP network infrastructure. Below are the most common pitfalls:

1. IP Address Exhaustion: As mentioned earlier, not planning for growth is the most common mistake. Once a VNet is created, you cannot easily change the address space if you run out of IPs.
   • Solution: Always start with a generous address space. If you are uncertain, go larger.
2. Overly Permissive NSGs: Creating "allow all" rules to quickly troubleshoot connectivity issues often leads to these rules being left in place, creating a security hole.
   • Solution: Use the "Principle of Least Privilege." Only open the exact ports and source IPs required for the communication to work.
3. Ignoring Latency: SAP systems are extremely sensitive to network latency. If your application server is in a different region from your database, your users will experience significant delays.
   • Solution: Always deploy your application and database servers in the same region and, if possible, the same availability zone.
4. Lack of Monitoring: Many teams set up their network and forget it. When performance issues arise, they have no visibility into where the bottleneck is.
   • Solution: Enable flow logging (like Azure Network Watcher or AWS VPC Flow Logs) to analyze traffic patterns and diagnose connectivity issues.

Step-by-Step Implementation Strategy

If you are tasked with setting up a new SAP environment, follow this structured approach:

1. Requirement Gathering: Document the number of SAP systems, the number of app servers per system, and the expected integration points (e.g., third-party web services).
2. Address Space Planning: Map out the IP ranges for each environment (Sandbox, Dev, QA, Prod). Ensure no ranges overlap.
3. VNet/Subnet Creation: Use IaC (Terraform) to deploy the VNet and subnets.
4. Security Definition: Define NSG rules based on the SAP port requirements (consult the official SAP TCP/IP ports documentation).
5. Connectivity Setup: Configure your VPN or ExpressRoute connection.
6. Validation: Run connectivity tests (e.g., using telnet or nc) to verify that the app server can reach the database on the expected ports.
7. Documentation: Keep a network diagram updated. A visual representation is essential for troubleshooting during an incident.

Comparison Table: Connectivity Options

Frequently Asked Questions (FAQ)

Q: Can I change the address space of a VNet after deployment? A: In most cloud platforms, you cannot change the address space of a VNet once it is created if there are existing subnets or resources attached to it. You would have to delete the resources, modify the VNet, and recreate them. Plan carefully from the start.

Q: Why do I need to separate my app servers and database servers into different subnets? A: Aside from security, it allows you to apply different routing policies and monitoring configurations. For example, you might want to mirror traffic from your database subnet to a security appliance for deep packet inspection, but not apply that same overhead to your application subnet.

Q: What is the impact of network latency on SAP? A: High latency leads to slow SAP GUI response times, timeout errors during RFC calls, and degraded database performance. SAP generally requires sub-millisecond latency between the application server and the database server for optimal performance.

Q: Should I use a flat network for small SAP deployments? A: No. Even for small deployments, you should follow the tiered approach. It is much harder to "re-architect" a flat network into a tiered one later than it is to build it correctly from the start.

Q: How do I handle external traffic coming into my SAP system? A: You should use a Web Dispatcher or a Load Balancer in a dedicated DMZ subnet. Never expose your application servers or database servers directly to the internet.

Key Takeaways

1. Plan for Growth: Always define your IP address space with future expansion in mind. Re-architecting a network due to IP exhaustion is a painful and disruptive experience.
2. Segment by Tier: Use subnets to isolate your SAP database, application, and management tiers. This is the foundation of a secure and manageable SAP infrastructure.
3. Apply Least Privilege: Network Security Groups should strictly control traffic. Default to "deny all" and only open the specific ports required for SAP communication.
4. Use Infrastructure as Code: Manual configuration in the portal leads to drift and errors. Use Terraform or similar tools to ensure your network design is consistent and version-controlled.
5. Prioritize Latency: For production environments, ensure that your network architecture minimizes hops and latency. Use dedicated private connections like ExpressRoute for performance-critical systems.
6. Visibility is Key: Implement flow logging and monitoring from day one. You cannot troubleshoot network issues effectively if you do not have data on traffic flow and blocked packets.
7. Document Everything: Maintain accurate network diagrams. In an emergency, knowing the IP ranges and routing paths is the difference between a quick resolution and a prolonged outage.

By following these principles, you will build a resilient network foundation that supports the complex needs of SAP. Remember that networking in the cloud is not just about connectivity; it is about performance, security, and the ability to scale as your business grows. Take the time to design your network thoroughly, and your SAP environment will be all the more stable for it.