Introduction to Network Load Balancer

The Flexible Network Load Balancer service enables you to create a public or private network load balancer in your VCN. A public network load balancer has a public IP address that is accessible from the internet. A private network load balancer has an IP address from the hosting subnet, which is visible only within your VCN. You can configure multiple listeners for an IP address to load balance Layer 4 (TCP/UDP/ICMP) traffic. Both public and private load balancers can route data traffic to any backend server that is inside the VCN.

Public Network Load Balancer

To accept traffic from the internet, create a public network load balancer. The
service assigns it a public IP address that serves as the entry point for incoming
traffic. Associate the public IP address with a friendly DNS name through any DNS
vendor.

A public network load balancer can be either regional or availability domain-specific in scope. The subnet in which the network load balancer is created determines this scope. A public network load balancer created in a regional subnet is regional in scope. A public network load balancer created in an availability domain-specific subnet is availability domain-specific in scope. Network Load Balancer ensures high availability and accessibility even when one of the availability domains has an outage.

Note

You cannot specify a private subnet for your public load balancer. See Public vs. Private Subnets for more information.

Private Network Load Balancer

To isolate your network load balancer from the internet and simplify your security
posture, create a private network load balancer. The network load balancer assigns
it a private IP address that serves as the entry point for incoming traffic. The
network load balancer is accessible only from within the VCN that contains the host
regional subnet, or as further restricted by your security rules.

Network Load Balancer Reachability

The network load balancer does not directly respond to a client ICMP or TCP/UDP ping
packet. Instead, the network load balancer directs the packet to a backend server in
accordance with the load balancing policy. The backend server then returns a
response to the client.

Only private network load balancers support the ICMP protocol. The network load
balancer must also have the Source/Destination Header (IP, Port) Preservation
feature enabled. If this feature is not enabled, or if you are using a public
network load balancer, you can check your network load balancer’s reachability
through available listener-enabled protocols (TCP/UDP).

Using Private Network Load Balancer as Next Hop Route
Target with VCN Transit Routing

Use a private network load balancer as the next-hop private IP route target with VCN transit routing. This method enables the network load balancer to operate as a bump-in-the-wire layer 3 transparent load balancer to which packets are forwarded along the path to their final destination. Transit routing refers to a network topology in which your on-premises network uses a connected virtual cloud network (VCN) to reach Oracle resources or services beyond that VCN. Connect the on-premises network to the VCN with FastConnect or Site-to-Site VPN, and then configure the VCN routing so that traffic transits through the VCN to its destination beyond the VCN. See Transit Routing inside a hub VCN for more information.

The network load balancer routes user traffic to the firewall instances hosted behind
network load balancer in the Hub VCN using VCN route tables. This user traffic that
would otherwise flow from source directly to destination. In this mode, network load
balancer does not modify the client packet characteristics and preserves the client
source and destination IP header information. This method enables the firewall
appliances to inspect the original client packet and apply security policies before
forwarding it to the application backend servers in the spoke VCNs.

The following illustrates the network load balancer architecture.

#1 DRG Route Table

Destination

Target

10.0.0.0/24

Flex-NLB VIP IP

10.1.0.0/24

Flex-NLB VIP IP

#2 NLB Subnet Route Table

Destination

Target

172.16.0.0/16

DRG

#3 FW Untrust Subnet Route Table

Destination

Target

0.0.0.0/0

IGW

#4 FW Trust Subnet Route Table

Destination

Target

10.0.0.0/24

Hub Web LPG

10.1.0.0/24

Hub DB LPG

#5 Hub LPGs Subnet Route Table

Destination

Target

0.0.0.0/0

FW Trust Int IP

All Network Load Balancers

Your network load balancer has a backend set to route incoming traffic to your
compute instances. The backend set is a logical entity that includes:

• A list of backend servers

• A load balancing policy

• A health check policy

The backend servers (compute instances) associated with a backend set can exist
anywhere, as long as the associated network security groups (NSGs), security lists,
and route tables allow the intended traffic flow.

If your VCN uses network security groups (NSGs), you can associate your load balancer with an NSG. An NSG has a set of security rules that controls allowed types of inbound and outbound traffic. The rules apply only to the resources in the group. Contrast NSGs with a security list, where the rules apply to all the resources in any subnet that uses the list. See Network Security Groups for more information about NSGs.

If you prefer to use security lists for your VCN, the Load Balancing service can suggest appropriate security list rules. You also can configure them yourself through the Networking service. See Security Lists for more information. See Security Rules for detailed information comparing NSGs and security lists.

Oracle recommends that you distribute your backend servers across all availability
domains within the region.

Private IP Address Consumption

A public network load balancer created in a public subnet consumes one private IP
address from the host subnet.

A private network load balancer created in a single subnet consumes one private IP
address from the host subnet.