Working with Your New Provider Network

This solution at a glance:

When the Metacloud Support team configures a provider network for your organization, it is helpful to be aware of certain characteristics of a provider network and to follow some best practices to maximize its use.

Note: If your Metacloud network infrastructure is configured as a Cisco Managed Network, you can add a maximum of 10 provider networks. If it is a Customer Managed Network, there is no maximum.

Your Provider Network "Looks" Like Any Network Created with Neutron

After a provider network becomes available for use in one of your Metacloud projects, it "looks" like any Metacloud tenant network created by one of your users with the Metacloud Network service (neutron).

The feature that distinguishes a provider network from a tenant network is the router. Your provider network routes traffic on a device that is controlled by your organization, not the Aggregated Services Router (ASR), which is part of the Metacloud physical infrastructure managed by Cisco.

When it requested the provider network, your organization specified your router's gateway IP to Metacloud Support. In the Dashboard, you can see the gateway IP address of a router by clicking its hyperlinked name in the Routers table and viewing its Router Details page. 

In the command line interface (CLI) you can see the gateway IP of a network by taking the following steps:

1. View a list of networks including their subnets:

openstack network list
+--------------------------------------+---------------------------------+--------------------------------------+
| ID                                   | Name                            | Subnets                              |
+--------------------------------------+---------------------------------+--------------------------------------+
| 5d487e3b-c12d-4798-9ebf-65e26fa51837 | network1                        | c08c8edc-a7ff-4c9c-b77a-569ddbc359b4 |
| ceac0430-de31-45cd-85c5-c4ea6b5a124c | network2                        | cc8e5230-0c81-4916-b0b4-5668fe50695c |
+--------------------------------------+---------------------------------+--------------------------------------+

2. Run openstack subnet show <subnet_UUID> to view the gateway IP or the subnet. 

openstack subnet show cc8e5230-0c81-4916-b0b4-5668fe50695c
+------------------+--------------------------------------+
| Field            | Value                                |
+------------------+--------------------------------------+
| allocation_pools | 10.17.1.2-10.17.1.254                |
| cidr             | 10.17.1.0/24                         |
| dns_nameservers  |                                      |
| enable_dhcp      | True                                 |
| gateway_ip       | 10.17.1.1                            |
| host_routes      |                                      |
| id               | cc8e5230-0c81-4916-b0b4-5668fe50695c |
| ip_version       | 4                                    |
| name             | stage1 Tenant Subnet - 2701          |
| network_id       | ceac0430-de31-45cd-85c5-c4ea6b5a124c |
| project_id       | 8011c2377e9b4d86a953a4a9cee6df54     |
| subnetpool_id    | None                                 |
+------------------+--------------------------------------+

Address New Security Implications

A common use case for provider networks is to make datacenter resources accessible to instances running in your Metacloud environment. For example, a virtual Web server on a tenant network may need to query a bare metal database server on the provider network to fulfill data requests. This has security implications that must be addressed on the provider and tenant networks.

On the tenant network side, this means several possible actions, depending on your specific environment and security requirements:

  • Add security groups to allow appropriate ingress for traffic originating in the provider network. See Configuring Access and Security for Instances with CLI.
  • Create allowed-address pairs with which you can allow arbitrary mac_address/ip_address pairs to pass through a port regardless of the subnet associated with the network. For example, you may want to create an allowed-address pair on the virtual Web server for the database it is querying.
  • Create a VPN tunnel connecting an instance on the tenant network with a datacenter asset. This may be appropriate for particularly sensitive datacenter assets. See Configuring a VPN Tunnel to an Instance for more information and an example for creating an allowed-address pair.

On the provider network side, proper actions may include the following:

  • Update the access control list (ACL) on the provider network firewall to permit appropriate ingress from instances on the tenant network. 
  • As you add instances in the provider network, configure them with security groups to allow appropriate ingress from instances in the tenant network.

Monitor and Troubleshoot Your Organization's Resources

As previously mentioned, your provider network routes traffic on a device that is controlled by your organization. Unlike with the ASR, which routes tenant network traffic and is monitored by Metacloud Support, it is your organization's responsibility to monitor traffic, throughput, and bandwidth on your router.

Certain inter-network routing operations are particularly resource intensive, such as "hairpinning," in which a connection traverses the router to an external network and back in by connecting to an internal resource using its external IP address.

Watch for spikes in usage, especially those that trend over extended periods. Make scaling changes as necessary.  

Note: Make sure to notify Metacloud Support in advance of any internal equipment maintenance or upgrade activity.

If a Metacloud instance on your provider network becomes inaccessible, a good first step for troubleshooting practice is to inspect your organization's routers and switches, those "north" of the Metacloud network infrastructure, for problems.

Keep Track of Address Use

For tenant networks, the Metacloud Support team keeps track of address space usage and alerts your organization when consumption of IPs warrants the addition of new virtual LANs (VLANs). 

When your organization requests a provider network, it specifies an address space for the subnet. After the support team configures the provider network, it is the responsibility of your internal team to track the use of IP addresses, including floating IPs, to avoid conflicts and to know when to request additional provider networks.

Use Best Practices for Moving Instances to Provider Networks

Your organization may want to move instances from tenant networks to provider networks to assert tighter control over traffic or to circumvent issues such as network address translation (NAT) conflicting with Active Directory (AD) operations.

A best practice for moving instances is to snapshot and terminate them on the tenant network, and then recreate them on the provider network. The specific metadata associated with an instance, such as the network port, cannot be changed once that instance is launched. Therefore, the metadata associated with an existing instance would not "match" the new network location. 

Also, during the transition between networks, it is not possible to have the same set of instances in the old and new locations simultaneously.

For more best practices related to deleting instances, see Troubleshooting Unusable Resources from Deleted Projects.

 

 

 

Have more questions? Submit a request
Powered by Zendesk