In the shared network each instance is assigned a private IP address from a common pool of Oracle-provided IP addresses. An IP network allows you to define an IP subnet in your account. The address range of the IP network is determined by the IP address prefix that you specify while creating the IP network. These IP addresses aren’t part of the common pool of Oracle-provided IP addresses used by the shared network. When you add an instance to an IP network, the instance is assigned an IP address in that subnet. You can assign IP addresses to instances either statically or dynamically, depending on your business needs. So you have complete control over the IP addresses assigned to your instances.
Here are a few things that you can do with IP networks:
Bring your own IP addresses
In the shared network, private IP addresses are assigned to your instances from a common pool of IP addresses. These IP addresses aren’t persistent. If you stop or delete an instance, the private IP address that was assigned to that instance is returned to the shared pool of IP addresses and could be reassigned to an instance created by another tenant. So, if you’re using IP addresses from the shared pool to access your instances — over a VPN connection, for example — you must ensure that whenever you create or re-create an instance, the private IP address of that instance is included in the range of reachable routes, and whenever you delete an instance, that private IP address is removed from the list of reachable routes. Any applications running in your on-premises environment that access an instance using its private IP address might also need to be updated.
When you create an IP network, you specify the IP address prefix for that network. This allows you to allocate IP addresses to your instances as per your requirements, and gives you complete control over the IP addresses that are assigned to your instances. You can specify the private IP addresses you want to use for each instance, without worrying about conflicts with private IP addresses used by other tenants in a multitenant site.
The first unicast IP address of any IP network is reserved for the default gateway, the DHCP server, and the DNS server of that IP network.
Isolate instances by creating multiple IP networks
With an IP network you can isolate instances by creating separate IP networks and adding instances to specific networks. Traffic can flow between instances within the same IP network, but by default each network is isolated from other networks and from the public Internet.
Attach instances to multiple IP networks
Oracle-provided Oracle Linux and Windows images with release version 16.3.6 or later support up to eight virtual network interfaces (vNICS). If you use a private image, you can set up the image to support multiple vNICs. When you create an instance using these images, you can add each instance to up to eight different networks, including the shared network. An instance that has a public IP address as well as one or more private IP addresses from IP networks, can be set up as a gateway, to route packets to each of the IP networks that it is added to.
Only images with the release version 16.3.6 or later support eight vNICs. Instances created using older images don’t support multiple vNICs.
Assign static or dynamic IP addresses to instances
You can use static IP addresses to ensure that the IP address of an instance doesn’t change when an instance is stopped and restarted, or deleted and re-created. Here a static IP address means that the DHCP server on the IP network always assigns a specified IP address to a specified interface of an instance.
Alternatively, you can use dynamically assigned IP addresses for your instances, without having to add or remove these IP addresses from routes when you create or delete instances. Even when a dynamically assigned IP address is not being used by your instance, it can’t be assigned to another customer’s instance.
Associate a MAC address with a network interface
You can specify the MAC address for each network interface of your instance. You might need to do this if the MAC address of an instance is used for software licensing or other purposes.
Enable communication across IP networks or to external IP addresses
After creating private IP networks and adding instances to the networks, you can connect different IP networks by creating IP network exchanges. You can specify paths to destination subnets outside your IP networks by creating routes. An IP network exchange enables access between IP networks that have non-overlapping addresses, so that instances on these networks can exchange packets with each other without NAT. An IP network exchange can include multiple IP networks, but an IP network can be added to only one IP network exchange.
A route specifies the IP address of the destination as well as the vNICset that provides the next hop for routing packets. Using routes to direct traffic allows you to specify multiple routes to various destination subnets. If each route uses a vNICset that contains multiple vNICs, then egress load balancing and high availability is also ensured.
In IP networks, while ARP and DHCP are supported only within the scope of the local interface, other types of broadcast, like ARP, are not supported between different instances. So if you try arping any IP address, the answer comes with different MAC address, not the MAC address of the vNIC associated with the IP address.
Set up a VPN connection to instances attached to IP networks
You can simplify the set-up of a two-way VPN connection, which allows you to establish a secure connection between your Compute Classic instances and your data center. See Connecting to Instances in a Multitenant Site Using VPN.
Associate multiple public IP addresses with each instance
When you create an instance with multiple virtual interfaces, you can associate a public IP address with each vNIC that is added to an IP network. An instance can have up to eight vNICs. So if you create an instance and associate each of the eight vNICs with an IP network, you can associate up to eight public IP addresses with the instance.
The shared network, however, allows you to associate only one IP address with an instance. So if you create an instance with an interface on the shared network and without any interfaces on IP networks, you can associate only a single public IP address with the instance.
Create ACLs to control the flow of traffic to and from each interface on an instance
Using IP networks enables you to create access control lists (ACLs), which control the type of traffic that is permitted to and from each interface of your instances. ACLs are a collection of security rules, where each rule can specify the direction of traffic, a list of permitted sources and destinations, and the type of packet as well as the port that can be used at the source or destination.
Essentially, with IP networks, you have complete control over your network configuration. Using IP networks allows you to create a network architecture that mirrors and extends the architecture you use in your data center.
The following figure shows the interaction between the IP networks and the shared network for two customers in a multitenant site:
The graphic shows that Customer 1 has created two IP networks, 192.168.2.0/24 and 192.168.3.0/24. Customer 2 has created one IP network, 192.168.2.0/24, which overlaps with one of the subnets specified by Customer 1. However, there is no conflict in the overlapping IP addresses, because these networks aren’t connected with each other. Both Customer 1 and Customer 2 have set up a VPN tunnel to their instances. Traffic from Customer 1 is routed to Instance 3, which has the public IP address 126.96.36.199 and traffic from Customer 2 is routed to Instance 4, which has the public IP address 188.8.131.52. Customer 1 has also set up an IP network exchange to connect their two networks.
Considerations for Configuring vNICs and IP Networks
Here are a few points to keep in mind while setting up your IP networks and assigning vNICs to IP networks:
You can’t assign multiple vNICs on a single instance to the same IP network. Each vNIC on an instance must belong to a separate IP network.
You can attach a vNIC to either the shared network or to an IP network, not to both. Also, you can’t mix attributes from both networks for a single vNIC. For example, you can’t specify the
ipattribute with the
seclistattribute for a given vNIC.
If you connect two IP networks using an IP network exchange, traffic across those IP networks is routed through the default gateway.
If you want to connect IP networks by using an IP network exchange, it is recommended that you do this before creating instances with an interface on those IP networks. This ensures that routes are appropriately configured on instances by the DHCP client during instance initialization.
If you create an instance that has interfaces on multiple IP networks, ensure that you don’t also add those IP networks to the same IP network exchange. Doing so creates a loop within the network, leading to erratic network behavior.
You can update an IP network and change the specified IP address prefix for the network after you’ve created the network and attached instances to it. However, when you change an IP address prefix, it could cause the IP addresses currently assigned to existing instances to fall outside the specified IP network. If this happens, all traffic to and from those vNICs will be dropped.
If the IP address of an instance is dynamically allocated, stopping the instance orchestration and restarting it will reassign a valid IP address from the IP network to the instance.
However, if the IP address of an instance is static — that is, if the IP address is specified in the instance orchestration while creating the instance — then the IP address can’t be changed by stopping the instance orchestration and restarting it. You must manually update the orchestration to assign a valid IP address to the vNIC attached to that IP network.
It is therefore recommended that if you update an IP network, you only expand the network by specifying the same IP address prefix but with a shorter prefix length. For example, you can expand
192.168.1.0/20. Don’t, however, change the IP address of the network. This ensures that all IP addresses that have been currently allocated to instances remain valid in the updated IP network.