My Blog

IaaS for Apps – Building the Foundations: Deploying into IP Networks

by Philip Brown on 22nd March 2017 No comments

This is the second part in the IaaS Foundations for Applications – Building the Foundations series, Deploying into IP Networks. You can view part one about Orchestration Basics here and the next blog in the series, Downloads and Upload Images to OPC, here.

If you want to learn more about Cloud Infrastructure as a Service, why not watch our on demand webinar? Click here to see it now!

Below we will go through Deploying IP Networks Part One:

For the IaaS platform you have the ability to utilise IP Networks. IP Networks allow you to allocate up to 8 vNICs against an instance and each of these vNICs is on a separate subnet.  This is what the documentation states but for those who haven’t really had to deal with this side of infrastructure before you need to know more than this to understand how it relates to IaaS.

When you create IaaS instances in the Oracle Cloud you will get (by default) a public IP address and a private IP address.  The public IP address will be automatically generated unless you specify an IP reservation (which enables you to ‘keep’ a randomly assigned IP address outside the life of an instance).  The private IP address will automatically be assigned by Oracle. These random IP addresses which get assigned can be in different subnets and ranges and there will be no ‘order’ to them. This is fine but if you’re building out an infrastructure in the Oracle Cloud you might not want the a bunch of randomly assigned IP addresses.  There are quite a few reasons for using IP networks and that are defined here.

IP Networks  or ‘BYO networks’ can be used to ensure you know the IP addresses that will be assigned to your Cloud infrastructure and to potentially specify specific subnets to be ‘in the Cloud’.

A subnet is an IP range which you can allocate to an instance.  In this series of blogs, I’m going to specify a subnet within my Oracle Cloud on the following range 192.168.230.0/24.  This is the CIDR notation which specifies IP ranges and the number of addresses that you will get.  When Oracle creates an instance (when you’re using IP Networks!) it will allocate each instance an IP address in that range starting with 192.168.230.2 (192.168.230.1 is the default gateway).  Therefore if you have three instances each with a vNIC and that vNIC is attached to the IP Network 192.168.230.0/24 then the instances will have the addresses 192.168.230.2, 192.168.230.3 and 192.168.230.4 respectively.

So when I create an instance and I attached it to an IP Network that’s it?  Well no, not really.  You want to really ensure there is no public facing IP addresses; no use of the ‘shared’ network and no randomness with the associated IP addresses.  Even if you start using IP Networks that doesn’t necessarily mean you have no public facing IPs. If you want your instances to only have a specific IP address that choose (no randomness in anyway) address you will need a VPN connection and a IP Network.

enterprise cloud infrastructure for dummies download

Oracle Cloud and VPN Connections:

The Oracle Cloud supports VPN connections and it’s included when you sign up to the Oracle Cloud.  The VPN connection works between two gateways; the OPC gateway and an on-premises gateway.  Furthermore if you don’t have an on-premises gateway Oracle will supply you (for free) the ability to use the Corente VPN gateway.  Before you get going you need to understand that there is a matrix of options for VPNs and that also the Oracle Cloud Gateway will require a single OCPU of IaaS to run.

So for VPNs you can have:

  • Oracle Public Cloud Corente Gateway to On-Premises Corente Gateway
  • Oracle Public Cloud Corente Gateway to On-Premises 3rd Party Gateway (i.e. existing VPN solution)

Both these options can be used to enable VPNs to the ‘shared network’ and IP Networks.  This series of blogs will be looking how to enable this topology below and in the next blog I will provide some more examples of this ‘shared network’ and IP Networks constructs to help cement our understanding.

deploying-ip-networks

Deploying into IP Networks Part Two:

In this blog we are going to look into how an instance can be deployed into an IP network and then be made accessible only by the IP network.  The setup I have running is a Corente VPN using IP Networks.  This setup for using Corente and IP Networks is well documented and can be found here.

This particular instance was created using the standard UI for creating instances apart from a couple of core differences.  Firstly prior to creating an instance I pre-created a boot volume and data volume in the storage section of the Oracle Cloud.

Deploying into IP Networks Deploying into IP Networks

When you create the instance now with the UI you effectively are just creating the instance and not any of the storage volumes (which you do by default).  Remember that anything you create as part of the creation of the VM instance will only persist for the life of that instance, this includes the boot volume.  By creating the boot volume and data volume outside the creation of the instance you know that they will persist outside the life of the instance, hence all changes will be kept.

The next thing to note is that this instance was created with the shared network and IP network.

"networking": {

    "eth1": {

      "vnic": "/Compute-a999999/drbrown@redstack.com/PB_eth1",

      "ipnetwork": "/Compute-a999999/drbrown@redstack.com/Cloud-IaaS"                                                 },

    "eth0": {

…

     "nat": "ippool:/oracle/public/ippool"}

You specify the IP Network during instance creation and this instance has the first address in the range 192.168.230.2.  If I do an ifconfig -a on the instance I can see eth1 vNIC.

[root@c04b0c ~]# ifconfig -a




eth1      Link encap:Ethernet  HWaddr 02:E6:63:73:F6:5F

          inet addr:192.168.230.2  Bcast:192.168.230.255  Mask:255.255.255.0

…

Now my VPN Oracle Cloud Gateway in this example is running on 192.168.230.100 and I can ping the VPN from this machine. But if I try and ping an IP of a server on premises I cannot connect to it.

[root@c04b0c ~]# ping 192.168.230.100

PING 192.168.230.100 (192.168.230.100) 56(84) bytes of data.

64 bytes from 192.168.230.100: icmp_seq=1 ttl=64 time=1.66 ms

64 bytes from 192.168.230.100: icmp_seq=2 ttl=64 time=0.317 ms




[root@c04b0c ~]# ping 10.200.100.7

PING 10.200.100.7 (10.200.100.7) 56(84) bytes of data.

--- 10.200.100.7 ping statistics ---
 3 packets transmitted, 0 received, 100% packet loss, time 2349ms

The Corente setup for both the Cloud gateway and on-premises gateway know about the subnets which it manages but the bit that is missing is the local VM instance knowing where to route the 10.200.100.7 address to.  For this to work we need to add a local route to the VM instance.  You do this by logging in as OPC and then sudo su – root.

ip route add 10.200.100.7 via 192.168.230.100

PING 10.200.100.7 (10.200.100.7) 56(84) bytes of data.

64 bytes from 10.200.100.7: icmp_seq=1 ttl=61 time=11.5 ms

64 bytes from 10.200.100.7: icmp_seq=2 ttl=61 time=12.8 ms

Now as this instance still has access via the shared network and IP network so we can stop the instance and edit the JSON file and remove the shared network.

"networking": {

    "eth1": {

      "vnic": "/Compute-a999999/drbrown@redstack.com/PB_eth1",

      "ipnetwork": "/Compute-a999999/drbrown@redstack.com/Cloud-IaaS"                                                                                 }

When we restart the instance we see in the console that it no longer has a shared IP and just the private IP.  But there is still a chance this could change.

Deploying into IP Networks

If we have a number of instances and we just specify that they have IP Networks but don’t specify specific IP addresses for them then they will all get randomly allocated from the range when the instances are started.  This could mean if you create instance VM1, VM2, VM3 and start them in that order they will get the address 192.168.230.2, .3 and .4.  But if for whatever reason you start them in the order VM3, VM2, VM1 then VM3 will have the address 192.168.230.2 and not .4.  This might not be an issue but if you want to specify a specific IP address for a specific instance then you need to add in a sub-parameter into the IP Network.

"networking": {

    "eth1": {

      "vnic": "/Compute-a999999/drbrown@redstack.com/PB_eth1",

      "ipnetwork": "/Compute-a999999/drbrown@redstack.com/Cloud-IaaS",
       "ip": "192.168.230.2"

There are other sub-parameters that you can add and these can be found here.

READ MORE:

Want to learn more about Cloud Infrastructure as a Service? Click here to download a free copy of Enterprise Cloud Infrastructure for Dummies now!

Philip BrownIaaS for Apps – Building the Foundations: Deploying into IP Networks

Related Posts

Take a look at these posts

Join the conversation