X

Best Practices from Oracle Development's A‑Team

More specific IP addresses for OSN using the new DRGv2 capability

Andrei Stoian
Principal Solutions Architect | A-Team - Cloud Solution Architects

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) https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingDRGs.htm

b) https://blogs.oracle.com/cloud-infrastructure/post/introducing-global-connectivity-and-enhanced-cloud-networking-with-the-dynamic-routing-gateway

1. Prerequisites

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;

2. Networking Topology

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.

Note: Object Storage uses public IP addresses that might change during the time. It is used solely to perform the necessary configuration and testing.

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.

3. OCI Configuration

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.

4. On-premise router verification

app-server1# sh ip bgp
BGP table version is 0, local router ID is 10.0.0.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 134.70.24.1/32   10.0.0.2                               0 31898 i
*> 134.70.28.1/32   10.0.0.2                               0 31898 i
*> 134.70.32.1/32   10.0.0.2                               0 31898 i

Total number of prefixes 3

5. Check the connectivity to Object Storage from 172.31.0.2:

[root@test-iperf3 opc]# ping objectstorage.us-ashburn-1.oraclecloud.com
PING objectstorage.us-ashburn-1.oci.oraclecloud.com (134.70.24.1) 56(84) bytes of data.
64 bytes from 134.70.24.1 (134.70.24.1): icmp_seq=1 ttl=60 time=4.48 ms
64 bytes from 134.70.24.1 (134.70.24.1): icmp_seq=2 ttl=60 time=3.03 ms
^C
--- 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 134.70.28.1...
* Connected to objectstorage.us-ashburn-1.oraclecloud.com (134.70.28.1) port 443 (#0)

Step 5 confirms that the connectivity is successfully established to Object Storage in the Ashburn region.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha