Use case 1: Private hub and spoke with transparent VNF and spoke-to-spoke traffic

Figure 1 illustrates a transparent VNF being used within the transit (hub) VPC to process data traffic within the VPC spokes.

The following resources are configured:

• The VPC hub contains the private NLB, which is configured in "Routing mode" and the transparent VNFs are added to its pool to enable HA.
• VPC-spoke#1 contains a private IBM Cloud Application Load Balancer (ALB) for VPC with a pool that contains the workload subnets for zone1 (10.174.0.0/24) and zone2 (10.174.4.0/24).
• VPC-spoke#2 contains a private ALB with a pool that contains the workload subnet for zone1 (10.174.2.0/24).
• A transit gateway manages the interconnections between the hub and spokes.
• IP spoofing on the VNF interface is the next hop in the hub.

A workload in VPC-spoke#1 zone1 that needs to communicate with a workload in VPC-spoke#2 zone1 must traverse the VNF in the VPC-hub. An egress route from the VPC-spoke#1 subnet (10.174.0.0/24) destined for VPC-spoke#2 (10.174.2.0/24) that hops through the VPC-hub NLB (10.175.0.4), allows the outbound traffic to reach its destination. A similar egress route is created on VPC-spoke#2, which allows the response to also traverse VPC-hub. For workloads in VPC-spoke#1 zone2, a similar egress route is also created for outbound traffic.

Finally, because the NLB might fail over and require an update to the next hop, an ingress route is created with the source as the transit gateway to ensure that the NLB IP is updated on failover. The NLB can update custom routes only within its VPC (VPC-hub) and can't automatically update routes in the spoke VPCs.

Use case 2: Active/Active HA transparent VNF (single, multi-zone region VPC)

Figure 2 illustrates a transparent, highly available Active/Active Virtual Network Function (VNF). This deployment topology ensures that the network and its services are always on, always accessible, and that active sessions are always maintained without disruption.

Because this VNF is transparent, the client (source) makes a TCP request to the target virtual server instance (destination) at 10.241.66.5 instead of the firewall IP address.

An egress custom route was created to ensure client (10.241.0.6) data packets destined for the target (10.241.66.5) will hop through the NLB. Because the NLB is configured with routing mode enabled, TCP requests on all ports are forwarded automatically to their destination. Because the VNFs are in the NLB pool, they are the next hop after the NLB. In this Active/Active single region example, an egress route is also required to ensure that the return packet from the target will hop through the NLB on the return trip, then through the same VNF it was sent through, and finally back to the client. In this use case, the client is in a different zone than the target, but the target is in the same zone as the NLB and VNF.

Use case 3: Multi-zone, high availability using asymmetric routing

The following configuration can be used only with a route-mode-enabled private NLB with a weighted forwarding pool algorithm.

Figure 3 illustrates a private route-mode network load balancer (NLB) designed to provide multi-zone high availability through asymmetric routing. In this architecture, consumer traffic reaches the provider's hub VPC through a direct link, transit gateway, or the internet. The private route-mode NLB then forwards the traffic through a Transit Gateway to virtual server instances located in the spoke VPC. When weighted forwarding is enabled, traffic originating and terminating within the same zone follows a symmetric path. The design also supports asymmetric routing, allowing return traffic to take a different path from the original request without depending on an existing connection state.

For example, a request packet might enter the service through an NLB in Zone 1 and be forwarded to a virtual server in VPC 1, while the response packet returns through the NLB in Zone 2. Because forwarding is independent of the original connection path, the response is accepted and forwarded correctly. Configured weights continue to influence how traffic is distributed at each NLB, allowing operators to direct more traffic to higher-capacity backends while maintaining multi-zone high availability.

This architecture also provides regional high availability. Route advertisements are automatically withdrawn in the event of a zonal outage, the loss of all healthy firewall instances, or the unavailability of all healthy NLB appliances. This behavior helps prevent traffic from being directed to unavailable resources and ensures that traffic is routed only to healthy zones.

Before you begin

Ensure that you have the required IAM permissions to configure custom routing and enable IP spoofing.

Getting started

Follow these basic steps to configure high availability for supported IBM Cloud VNFs:

1. Review known issues for virtual network functions.
2. Configure VPC resources.
3. Configure security groups.
4. Deploy a VNF.
5. Create a network load balancer with routing mode.
6. Configure custom routes.

VNF limitations

High Availability (HA) Virtual Network Function (VNF) deployments have the following known limitation:

• The Virtual Network Function (VNF) must share one subnet with the Network Load Balancer (NLB).