Workflows for Using IP Networks

Topics

Workflow for Adding an Instance to an IP Network

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’s a workflow to set up IP networks and add an instance to an IP network:

Create the required IP networks. See Creating an IP Network.
(Optional) Create the required vNICsets. A Virtual NIC, or vNIC, is a virtual network interface card that enables an instance to be associated with a network. Instances created using Oracle-provided Oracle Linux or Windows images with the release version 16.3.6 or later support eight vNICs, enabling each instance to be associated with up to eight networks.
A Virtual NIC Set, or vNICset, is a collection of one or more vNICs. vNICsets are useful when you want to use multiple vNICs for the same action. For example, you use vNICsets to specify multiple vNICs as a source or a destination in a security rule. You can also use vNICsets in routes to specify multiple vNICs as the next hop destination for that route.
Create an instance with the required interfaces. While creating the instance, use the network attributes section to specify the interface that should be associated with the shared network, if any, and the interfaces that should be associated with your IP networks, as required. See Creating Instances.

Note:

For instances that are associated with an IP network, while creating the instance you can specify the vNICsets that you want to add each vNIC to. The vNICs are then automatically added to the specified vNICsets when the instance is created, and removed from the vNICsets when the instance is deleted.

If you create an instance by using an orchestration, then, to specify vNICsets in instance network attributes, see Subparameters for a Network Interface on an IP Network.

If you create an instance using the web console, then to specify vNICsets in the Create Instance wizard, see Creating an Instance from the Instances Page.

If you create an instance and don’t specify any vNICsets, the vNICs that are associated with IP networks are automatically added to the default vNICset.

If you have any existing instances that have vNICs associated with IP networks, if those vNICs aren’t explicitly added to a specified vNICset, they are automatically added to the default vNICset.

Workflow for Connecting IP Networks

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.

Connecting multiple IP networks using an IP network exchange is useful when you want a larger set of instances to be able to communicate with each other, but the currently defined IP network won’t support such a large number of instances.

For example, consider a scenario where you’ve created an IP network with a /28 subnet mask and you find that you want to use this IP network for, let’s say, 40 instances. You’d have to increase the size of the subnet by using a /26 subnet mask. However, in certain situations, you might not want to increase the size of the subnet. For example, increasing the size of the subnet might cause overlapping IP addresses with another subnet in your account or in your data center. This could be problematic if the overlapping address ranges are connected using an IP network exchange or if you have a VPN connection that includes the overlapping subnets at either end.

In such situations, rather than modifying an existing IP network, you can create another IP network and link it to one or more existing IP networks using an IP network exchange.

Here’s a workflow to enable communication across IP networks using an IP network exchange.

Create the required IP networks. See Creating an IP Network.
Create the required instances and specify the interfaces that should be added to the IP networks. See Creating Instances.
Create an IP network exchange. See Creating an IP Network Exchange.
Reference the IP network exchange in all the required IP networks. You can reference an IP network exchange in an IP network either when you create the IP network, or later, by updating the IP network.

Caution:

You must ensure that there’s no conflict in the range of IP addresses used in various IP networks, the IP addresses used in your on-premises network, or the range of private IP addresses used in the shared network. If IP networks with overlapping IP subnets are linked to an IP exchange, packets going to and from those IP networks are dropped.

See Creating an IP Network or Updating an IP Network

Instances on different IP networks that are part of the IP network exchange should now be able to communicate with each other using the IP addresses assigned from the participating IP networks. However, this communication is controlled by the security rules created and the ACLs applied to the relevant vNICsets.

For example, consider that you’ve added two instances to IP network 1 and two instances to IP network 2. You’ve also created vNICset 1 for the vNICs in IP network 1 and vNICset 2 for the vNICs in IP network 2. If you add both IP networks to the same IP network exchange, it establishes a channel for communication between the instances added to the two IP networks. However, whether the instances can communicate or not, and the protocol and port that they can use to communicate, depends on the ACLs that apply to each vNICset. See Workflow for Applying Access Control Lists.

Workflow for Creating Routes to External Destinations

Creating a route allows you to specify a preferred path for traffic to specified destinations outside your IP networks. A route specifies the IP address of the destination as well as the vNICset that provides the next hop for routing packets. A Virtual NIC Set, or vNICset, is a collection of one or more vNICs. You must specify a vNICset when you create a route. When a vNICset containing multiple vNICs is used in a route, Equal Cost Multipath (ECMP) anycast routing is implemented. Traffic routed by that route is load-balanced across all the vNICs in the vNICset. Using vNICsets with multiple vNICs also ensures high availability for traffic across the specified vNICs.

Here’s a workflow for creating a vNICset and using it in a route:

Create the required IP networks. See Creating an IP Network.
Create a vNICset. See Creating a vNICset.
Create the required instances and specify interfaces to be added to the IP networks. See Creating Instances.
Create a route. See Creating a Route.

Traffic to the specified destinations is now routed over the specified vNICs.

Note:

A route directs traffic to the specified next hop based on the destination address in the packet. To ensure that packets can access a vNIC in either the ingress or the egress direction, you must define the required security rules and apply them to a vNICset using an access control list. See Workflow for Applying Access Control Lists.

Workflow for Applying Access Control Lists

An access control list (ACL) is a collection of security rules that can be applied to a vNICset. ACLs determine whether a packet can be forwarded to or from a vNIC, based on the criteria specified in its security rules.

A security rule permits traffic from a specified source or to a specified destination. You must specify the direction of a security rule — either ingress or egress. In addition, you can specify the source or destination of permitted traffic, and the security protocol and port used to send or receive packets. Each of the parameters that you specify in a security rule provides a criterion that the type of traffic permitted by that rule must match. Only packets that match all of the specified criteria are permitted. If you don’t specify match criteria for any parameter, all traffic for that parameter is permitted. For example, if you don’t specify a security protocol, then traffic using any protocol and port is permitted.

When you create a security rule, you specify the ACL that it belongs to. ACLs apply to vNICsets. Each vNICset can reference multiple ACLs and each ACL can be referenced in multiple vNICsets. When an ACL is referenced in a vNICset, every security rule that belongs to the ACL applies to every vNIC that is specified in the vNICset.

A security rule allows you to specify the following parameters:

The flow direction — ingress or egress
(Optional) A source vNICset
(Optional) A list of source IP address prefix sets
(Optional) A destination vNICset
(Optional) A list of destination IP address prefix sets
(Optional) A list of security protocols
(Optional) The name of the ACL that contains this rule
(Optional) An option to disable the security rule

When you apply a security rule to a vNICset using an ACL, packets that match all the criteria in any one security rule applied to a vNIC are allowed.

For example, consider that you’ve created vnicset_a. In this vNICset, you’ve referenced acl_1 and acl_2. Now, consider that you’ve created a security rule secrule_ingress in which you’ve specified only the flow direction ingress and the ACL acl_2. Because you haven’t specified any other match criteria, this security rule allows all incoming traffic, and because this security rule is added to acl_2, it applies to every vNIC in vnicset_a.

In acl_1 and acl_2, you might have added other ingress security rules that include specific criteria for incoming packets, such as a source IP address range or a protocol or port. However, since incoming packets of any protocol and port and from any source match the criteria specified in secrule_ingress, those packets will be delivered to the relevant vNICs in vnicset_a despite other security rules that might filter out such traffic.

So, when creating security rules and adding them to ACLs keep your security rules as specific as possible. When you apply an ACL to a vNICset, check the other ACLs that apply to the same vNICset as well. If you’ve created very specific security rules and added them to an ACL, those rules might not apply when another ACL contains very permissive security rules applied to the same vNICset.

Here’s a workflow for creating a security rule and an ACL and applying the ACL to a vNICset:

Create the required IP networks. See Creating an IP Network.
(Optional) If you want to specify a vNICset as a source or destination in a security rule, create the required vNICsets. A vNICset is a collection of one or more vNICs. See Creating a vNICset.
Create the required instances and specify the interfaces that should be added to the IP networks and vNICsets that you’ve created. If you don’t specify the vNICsets that you want to associate a vNIC with, the vNIC is added to the default vNICset. See Creating Instances.

Note:

If you created instances prior to the 16.4.6 release and you didn’t add vNICs on those instances to any vNICset, then those vNICs are automatically added to the default vNICset.
(Optional) Create an IP address prefix set. An IP address prefix set contains a set of IPv4 addresses in the CIDR address prefix format. When you create a security rule, you can specify a list of IP address prefix sets as the source or destination for permitted traffic.

You can specify an IP address prefix set in multiple security rules.

To create an IP address prefix set, see Creating an IP Address Prefix Set.
(Optional) Create a security protocol. A security protocol allows you to specify a transport protocol and the source and destination ports to be used with the specified protocol. When you create a security rule, you can specify the security protocols that you want to use to permit traffic. Only packets that match the transport protocol and ports in any of the specified security protocols will be permitted. If you don’t specify protocols and ports in a security protocol, traffic is permitted over all protocols and ports.

You can specify a security protocol in multiple security rules. So if you have a protocol that you want to use in a number of security rules, you don’t have to create the protocol multiple times.

To create a security protocol, see Creating a Security Protocol for IP Networks.
Create an ACL. After creating the required ACL, you’ll reference it in the security rule and apply it to the required vNICsets. To create an ACL, see Creating an ACL.
Create a security rule specifying the parameters you require such as security protocols, source and destination vNICsets or IP address prefix sets, and the ACL that you want to add this security list to. Ensure that each of the objects that you reference in a security rule does exist. If you reference a security protocol or an IP address prefix set that doesn’t exist, the security rule won’t be used. Also, when you’re ready to apply a security rule, remember to specify the ACL that you want to add the security rule to. If you don’t specify an ACL, the security rule won’t be used.

To create a security rule, see Creating a Security Rule for IP Networks.
Create or update the vNICsets that you want to apply the ACL to, and specify the ACL that you want to associate with that vNICset. See Creating a vNICset or Updating a vNICset.

Workflow for Assigning a Public IP Address to a Network Interface

If you want an interface on your instances to be accessible from the public Internet, or if you want your instances to be able to communicate with other Oracle services on other IP networks, you can reserve a public IP address and associate that IP address with a vNIC on your instance.

You can reserve a public IP address from one of two IP pools:

/oracle/public/public-ippool: When you attach an IP address from this pool to an instance, you enable access between the public Internet and the instance.
/oracle/public/cloud-ippool: When you attach an IP address from this pool to an instance, the instance can communicate privately (that is, without traffic going over the public Internet) with other Oracle Cloud services, such as the REST endpoint of an Oracle Cloud Infrastructure Object Storage Classic account in the same region.

A public IP address or a cloud IP address can be associated with only one vNIC at a time. A vNIC can have two NAT IP addresses, one from each IP pool.

Here’s the workflow for reserving a NAT IP address and associating it with an instance.

Create an IP network. See Creating an IP Network.
Create an IP address reservation. When you reserve an IP address from a specified IP pool, an IPv4 address is allocated for your use. You can associate this IP address with a vNIC on one of your instances. See Reserving a Public IP Address for IP Networks
Associate the IP reservation with the vNIC on an instance. See Associating a Public IP Address with a vNIC.

If you selected the /oracle/public/public-ippool IP pool, then your instance can communicate with external hosts over the public Internet. If you selected the /oracle/public/cloud-ippool IP pool while creating an IP reservation, then your instance can communicate with other Oracle Cloud services, such as the REST endpoint of an Oracle Cloud Infrastructure Object Storage Classic account in the same region, without sending traffic over the public Internet. However, the routes, security rules, and ACLs required to enable traffic must be set up as well.

Workflow for Enabling SSH Access to an Instance Using IP Networks

When you create an instance with one or more interfaces added to IP networks, access to those interfaces depends on the vNICsets that each vNIC belongs to. Access control lists (ACLs) are applied to vNICsets to control the type of traffic that is allowed to and from vNICs in the vNICset.

Here’s a workflow for creating a vNICset and configuring the security rules and ACL required to enable SSH access to the vNICs in this vNICset.

Create an IP network. See Creating an IP Network.
Create an IP address reservation and specify the IP pool /oracle/public/public-ippool. See Reserving a Public IP Address for IP Networks.
Create an ACL. See Creating an ACL.
Create a vNICset and apply the ACL to the vNICset. See Creating a vNICset.
Create a security protocol with the protocol TCP and the destination port set 22. See Creating a Security Protocol for IP Networks.
(Optional) Create one or more IP address prefix sets to specify the IP addresses from which you want to permit SSH access. See Creating an IP Address Prefix Set.

If you want to permit SSH access from all sources, you don’t need to create an IP address prefix set.
Create the following security rules:
- Ingress security rule
  
  Specify the ACL and security protocol that you just created and the source IP address prefix set, if required. If no source is specified, SSH traffic from all sources is permitted. Specify the vNICset that you just created as the destination.
- (Optional) Egress security rule
  
  Note:
  
  This rule is required only if you want to initiate SSH requests from the vNICset to external destinations. You don’t need this security rule if the vNICs in the vNICset must respond to incoming SSH requests, but must not be allowed to initiate SSH requests.
  
  Specify the ACL and security protocol that you just created and specify the vNICset as the source. If required, specify the IP address prefix set as the destination. If no destination is specified, traffic to all destinations is permitted.
See Creating a Security Rule for IP Networks.
Finally, while creating an instance do the following:
- Add one interface to the IP network that you just created.
- Add the vNIC to the vNICset that you just created.
- Associate the vNIC with the IP address reservation that you just created.
See Creating Instances.

Subsequently, for any instance that you create, specify the same IP network and vNICset, and associate an IP reservation with the vNIC while creating the instance. When the instance is created, you can access its public IP address using SSH.