Use Case: Null (black hole) Routing in OCI

May 31, 2023 | 3 minute read
Raffi Shahabazian
Principal Cloud Network Architect
Text Size 100%:

I’ve recently encountered a use case from a customer requirement on how to accomplish null (black hole) routing in OCI in a simple, consistent, and scalable manner.  While there are a few methods to accomplish this, it does require configurations in different areas which may not necessarily meet the customers’ requirements.

Since most architectures these days follow a hub-and-spoke model, I will use the following architecture to describe the null (black hole) routing solution.

OCI Hub and Spoke Architecture
OCI Hub and Spoke Architecture


However, before we look as to what is required and where it is required, let’s define what null (black hole) routing is:

Null (black hole) Routing – a route entry in a network route table for a given destination that goes nowhere.  It is silently discarded without being processed and forwarded.

Now that we have an understanding on what we’d like to accomplish, how do we go abouts doing this in a manner that is effective?  Let’s take a closer look at the routing for the hub-and-spoke architecture we are assuming for this blog to understand where we can make routing decisions:

OCI Hub and Spoke Architecture - Routing Decsion Points
OCI Hub and Spoke Architecture - Routing Decsion Points.                            


Based on the hub-and-spoke architecture, we can make routing decisions in the following locations:

  • Spoke VCN Compute Subnet(s)
  • DRG Route Tables
  • Hub VCN Subnet(s)
  • On the NVA

Let’s consider the following scenario:

We have a list of known IP addresses or CIDR blocks that need to be null routed.  We could allow the traffic to reach the hub VCN, which would route the traffic towards an NVA, and we could explicitly deny the traffic on the NVA, so it never makes it to the destination.  However, this could be cumbersome to manage and would add unnecessary load on the NVA to process network traffic that should never be routed, or null routed.  This will eliminate the hub VCN and the NVA as viable options for null routing traffic.

Additionally, we could leverage the Spoke VCN Compute Subnet(s) and their associated VCN route tables.  We could add static route entries and send the traffic to a private IP address to a compute VM.  However, what if I have many VCNs and each VCN has many VCN route tables?  I would need to update every VCN route table in every VCN and this could become unmanageable relatively quickly.  This will also allow room for error which could produce inconsistency in null routing behavior.

We still have the DRG route tables, but what could we do from DRG route table’s perspective?  We could add static routes, however, where would we direct the traffic to?  In this case, our best option is to create a new VCN that can be used as a Null Route VCN (or black hole VCN), attach it to the DRG, and add static routes for the destination CIDRs that need to be null (black hole) routed towards this empty VCN.  The following solution depicts the Null Route VCN design:

OCI Hub and Spoke Architecture - Null (black hole) Route
OCI Hub and Spoke Architecture - Null (black hole) Route


With this simple solution presented above, we can add static routes in each Spoke DRG route table and forward the traffic to the Null Route VCN, which will effectivlty Null (black hole) route the traffic.  Additionally, this soluition is less cumbersome to manage than updating individual VCN route tables.


Dynamic Routing Gateways

Raffi Shahabazian

Principal Cloud Network Architect

Previous Post

OCI DMZ common architectures - part 3 - type 2 demo

Radu Nistor | 10 min read

Next Post

How-to: exporting Prometheus data to Kafka

Julio Camara | 6 min read