Is the OCI LPG still a powerful networking feature?

I will start this blog by quoting the title above: is the OCI LPG still a powerful networking feature? I will dedicate it to our LPG since the LPG helped to unblock one of our important OCI customers when they just enabled some new services, requiring a special networking posture in conjunction with the existing production network in place. We will be exploring the customer use case throughout the blog and at the end we will have the conclusion if the LPG is still a strong feature.

Nowadays, you will not see very often the LPG included in networking architectures since the DRG can handle with a high level of scalability most all connectivity scenarios, however, there are still some use cases when the LPG might save your day. 

So, you might ask, what is about, what is so special? Stay focus, the details are about to be revealed.

My customer is using a complex networking construct, including a hub and spoke architecture, two OCI Network Firewalls, one for east-west traffic and another for Internet ingress traffic through LBaaS with WAF enabled and four spoke VCNs where the services are configured. The two NFWs were configured in the Hub VCN acting as a central point for all traffic inspection.

A new request came in for spoke VCNs to connect to Internet using the NFW and NAT Gateway. This is almost easy and can be configured immediately. In theory yes, that is true, however, when it comes to implement it in a production network with the routing in place, we need to analyze twice and cut once.

Let’s look at a simplified networking diagram (only two spoke VCNs included) and especially at how the existing routing configuration is done:

Among other IP address space, the 172.16.0.0/12 space is extensively used by the customer for OCI, other CSPs and on-premises networks. It is not allocated as a contiguous space for a specific network or DC, it is just scattered, very scattered. Only the traffic to other CSP is the subject of inspection on the Private NFW.

The design phase of the production network uses the default route in many route tables to accommodate the 172.16.0.0/12 scattered way of assignment. In the above diagram the routing in place will send all the traffic from spokes with the destination other CSP to the HUB Private NFW for inspection. The on-premises 172.16 subnets are directly forwarded via the dedicated connection to on-premises.   

We have the information on how the routing is configured for production network and the way 172.16.0.0/12 range was used among different zones, now we need to implement the new request, spoke VCNs to connect to Internet using the NFW and NAT Gateway.

The solutions proposed:

1. Configure a new NFW (NAT NFW) in a new subnet in the HUB VCN with a route table containing a default route with the NATGW as next-hop. In the existing DRG VCN route table (used for transit routing) change the existing default route with the Private NFW as next-hop to specific 172.16.x.x/12 destinations for other CSP and configure a brand new default route with the NAT NFW as next-hop.
2. Configure a new VCN called HUB1 where the NAT NFW will be placed and attach a DRG VCN route table (for transit routing) with a default route and next-hop the NAT NFW. In the spoke VCNs DRG attachments route tables, configure static routes to 172.16.x.x/12 with the HUB VCN DRG attachment as next-hop and dynamically import HUB1 VCN DRG attachment. In this way we will obtain specific routes for 172.16.x.x/12 over HUB and Private NGW, and a default route for NAT traffic over HUB1 and NAT NFW. This solution will not require any change in the existing HUB VCN and Private NFW.
3. Configure a combination of NFW and NATGW in each and every spoke VCN which needs Internet access through NATGW.
4. Configure the new NAT NFW in a new subnet in the existing HUB VCN with a subnet route table configured with a default route with the NATGW as next-hop. From each and every Spoke VCN (four total in the production network) configure a local peering gateway to HUB VCN. Create one route table in the HUB VCN containing a default route with the NAT NFW as next-hop and attach it to all LPGs in the HUB VCN. Each and every spoke subnet route table will have a specific route to 172.16.0.0/12 with the DRG as next-hop and a default route with the LPG as next-hop. All the traffic for 172.16.x.x/12 will be sent to the DRG (where the existing routing logic for production network will be applied) and any other traffic will be sent to the LPG for the path: Spoke LPG -> HUB LPG -> NAT NFW -> NATGW -> Internet, without affecting in any ways the existing production routing configuration. 

Discussing the options with the customer we had the following outcome: 1 and 2 were rejected due to the fact that was impossible to aggregate the 172.16 ranges used in the other CSP to create a more specific route or set of routes, option 3 implies scalability issues and a higher cost of implementation since any spoke will need its own NFW.

The option 4 was received as the best solution from cost and scalability purposes (given de existing numner of VCNs and the future space for expansion). Additionally, option 4 did not required any maintenance window on the customer production network and the entire configuration can be done on the fly, not affecting the production traffic.

That being said, option 4 was the chosen one. Below is a simplified version of the winner:

Testing the new path for Internet destination over the NAT NFW and NATGW:

The solution was implemented very fast and the connectivity requirement was successfully deployed without affecting anything on the current production network. The LPG is still a powerful networking feature and it might unblock the customers in some important situations.