In our new blog post, we will discuss how we can advertise to On-premise more specific IP addresses for OSN SaaS/PaaS when we are using FastConnect Private Peering or BGP over IPSec.
The scope is to deliver a solution for our customers asking for specific OSN IP addresses used by the SaaS/PaaS services the customer uses to be received on the On-premise.
We recently launched in all our regions the new DRG capabilities which can accomplish this scope. More details about the capabilities added are listed at below links:
a) The DRGv2 needs to be used. If you still have DRGv1 this needs to be upgraded to DRGv2: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingDRGs.htm section "Upgrading a DRG";
b) Confirm with Oracle that the public IP addresses assigned to your SaaS/PaaS are not changing over time and the service is reachable using the SGW being part of OSN;
Our example consists of receiving on the On-premise router the /32 IP addresses assigned to Object Storage in the Ashburn region. You can expand this example for any SaaS/PaaS reachable via the SGW which meets the point b) from the Prerequisites.
For testing purposes, we have a host at 172.31.0.2 located On-premise to check the connectivity once the routes are advertised to On-premise by using the /32 mask.
As we know, if we assign a route table to a DRG and a route entry using the SGW as a next-hop, the target routes can contain only Object Storage or All Oracle Services in OSN. We cannot use a destination CIDR for this purpose.
In order to accomplish the scope, we will use the DRGv2 feature and create static routes with the next-hop being the VCN attachment for VCN 1. Here is the magic, the DRGv2 terminating the customer FC or BGP over IPSec will send also the /32s we have configured.
1. Create the transit routing to OSN on VCN 1 by attaching a route table to the DRGv2, routing the traffic to the OSN via the SGW as next-hop:
rt_drg contains the following route entry:
2. Attach a route table to the SGW to return the traffic to 172.31.0.2 via the DRGv2:
3. On the DRGv2:
- create a new route table with a new import policy and attach the route table to the Virtual Circuit Attachment. In the import policy attached to the route table, do not import the IP prefixes received over the VCN 1 Attachment (we do not want to send all OSN IP Prefixes to On-premise);
- create static routes using the /32 bit mask for the Object Storage public IP addresses with the next-hop being the VCN 1 attachment;
The three IP addresses with /32 bit mask will be redistributed in BGP and the customer will receive them on the On-premise router.
Note: because we did not import dynamically the IP prefixes from VCN 1 attachment, the VCN 1 subnets will not be sent On-Premise via BGP. In order for sending the VCN 1 subnets to On-Premise, create in the same way static routes to the individual subnets or simply to the VCN CIDR with the VCN 1 attachments as next-hop.
[root@test-iperf3 opc]# ping objectstorage.us-ashburn-1.oraclecloud.com
PING objectstorage.us-ashburn-1.oci.oraclecloud.com (184.108.40.206) 56(84) bytes of data.
64 bytes from 220.127.116.11 (18.104.22.168): icmp_seq=1 ttl=60 time=4.48 ms
64 bytes from 22.214.171.124 (126.96.36.199): icmp_seq=2 ttl=60 time=3.03 ms
--- objectstorage.us-ashburn-1.oci.oraclecloud.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 3.038/3.760/4.482/0.722 ms
[root@test-iperf3 opc]# curl -v https://objectstorage.us-ashburn-1.oraclecloud.com
* About to connect() to objectstorage.us-ashburn-1.oraclecloud.com port 443 (#0)
* Trying 188.8.131.52...
* Connected to objectstorage.us-ashburn-1.oraclecloud.com (184.108.40.206) port 443 (#0)
Step 5 confirms that the connectivity is successfully established to Object Storage in the Ashburn region.