Yes, the transit routing between different on-premises sites using OCI as a transport network is still very popular, still a subject that is raising potential solutions to achieve the goal of using the OCI backbone to connect different on-premises sites. Even if we have a strong mechanism to prevent the OCI network to be used as a transit network, one of the most popular idea I’m receiving to resolve this is to use static routing in the DRG attachments route table.
You might ask where and how to use the static routing to achieve the goal. How do we know if this type of configuration works? Now, the most important question is, will the static routing really resolves the problem and “fool” OCI to permit the transit routing between on-premises sites?
This is what I’m going to present you and at the end to have a conclusion. Let’s explore it by drawing a networking diagram that will present the concept. In this example I’m using two on-premises sites, Bank Location 1 and 2. The scope is for user at 192.168.0.10 from Bank Location 1 to be able to communicate with user at 172.28.0.1 from Bank Location 2 using the OCI Backbone as a transit network.
In-between the two DRGs, there we have a remote peering connection and static routes configured to use the RPCs on the FastConnect VC DRG attachment route table:
DRG A
DRG B
Remember that no dynamic route import for the remote sites are going to happen on DRGs for each remote sites, only static routing. Let’s verify if CPE 1 and 2 did received the routes advertised by each DRG after the static route was configured in the FastConnect VC attachment route table:
CPE 1
CPE 2
That is fine, this is the expected results, since once the static route is configured, the DRGs starts to announce the routes to CPEs.
Both CPEs announced the respective routes to the DRGs. Each DRG will in turn announce the routes to the remote region via the RPC:
DRG 1
DRG 2
Ok, so now we are all set from the routing configuration. All routes were successfully propagated and we should be ready to test the traffic between our hosts:
The above output shows a complete failure of our ICMPs probes. This means that OCI cannot be “fooled” even if static routes are in place and will simply not act as a transit network between different on-premises sites.
Back in 2023 in the blog A routing scenario, transit traffic on OCI we discussed about how we can achieve this goal. For reference, you really need to have a VM or Firewall or OCI NFW to receive the traffic and send it out to the remote site. In this way, the traffic will “appear” as being generated by the OCI and not from on-premises.
This concludes our discussion. I do hope this blog will answer many questions regarding the OCI transit routing.