1. Introduction to Networking in PSNC Openstack

PSNC network in Openstack environment is powered by Open vSwitch (OVS) and Open Virtual Network (OVN), offering scalable and flexible software-defined networking (SDN). OVS acts as a virtual switch, managing traffic between virtual machines, while OVN extends this functionality by adding logical networking elements like switches, routers, and security features. In this setup, OVN integrates with OpenStack's Neutron service, translating API calls into OpenFlow rules for OVS. It enables distributed networking, handling features like security groups, floating IPs, and load balancing. The distributed routing and switching architecture improves scalability and reduces latency. The distributed routers are configured directly on compute nodes, allowing traffic routing to occur at the node level, further enhancing scalability and reducing latency. For OpenStack users, this means efficient network automation, enhanced security with ACLs, and better performance due to distributed routing across nodes. OVN simplifies network management, making it ideal for large-scale OpenStack deployments with complex networking needs.

2. Overview of Available Public Networks

In the PSNC OpenStack environment, several public networks are available to users within the BST-PL2 region, each serving specific purposes for various connectivity needs. Below is a description of the key public networks provided in this region:

  • PSNC-EXT-PUB1-EDU: This is the primary external network that provides connectivity to the public internet. It allows virtual machines to interact with external systems and services directly. This network is typically used for purposes that require public access, such as SSH connectivity, hosting web services, external APIs, or any service needing direct internet exposure.

  • PSNC-EXT-IPV6-PUB2-EDU: This is IPv6 external networks that provides connectivity to the public internet using IPv6.

  • PSNC-INTERNAL-LAN: This network is designed for internal use and is accessible only through a secure VPN connection.  It provides a private pool of floating IPs that are accessible via VPN only, allowing for secure internal communications and services that do not require to be exposed by public internet access.

  • PSNC-STORAGE-MANILA: Dedicated to storage operations, this network is specifically for managing and accessing shared file systems via the Manila service in OpenStack. PSNC-STORAGE-MANILA connects VMs to storage resources, providing high-performance access for data-intensive applications and persistent storage needs.

These networks in the BST-PL2 region offer flexible options for connecting virtual machines, supporting a range of use cases from public internet access to secure internal communication and specialized storage access.

3. Using Public Networks in PSNC OpenStack

This section provides a guide on how to configure and use public networks in the PSNC OpenStack environment, covering the configuration of routers, reserving and assigning floating IPs, and setting up security rules to ensure secure and efficient connectivity for your virtual machines (VMs).

3.1. Configuring Routers and Connecting to Public Networks

To enable external connectivity for your internal networks, you need to configure a router and connect it to a public network, such as PSNC-EXT-PUB1-EDU.

  • Creating a Router: In OpenStack, routers connect your private internal network to an external public network. You can create a router via the OpenStack dashboard or CLI. This router will act as a gateway, allowing traffic to flow between your internal network and the public internet.

  • Connecting to an External Network: Once the router is created, connect its external interface to the public network (PSNC-EXT-PUB1-EDU). This connection is crucial for enabling floating IPs and allowing outbound traffic from VMs.

  • Connecting Internal Subnets: After configuring the external interface, you need to add your internal network (subnet) to the router. This step links your internal resources, like VMs, to the public network, making them accessible externally via floating IPs.

3.2. Reserving and Assigning Floating IPs

Floating IPs are required to expose a VM to the public internet using IPv4. These IPs are mapped to internal private IPs and enable your VMs to communicate externally. IPv6 addresses are exposed to the public without using floating ip.

  • Reserving a Floating IP: Floating IPs can be reserved from the PSNC-EXT-PUB1-EDU network using the OpenStack dashboard or CLI. Ensure you select the correct external network (PSNC-EXT-PUB1-EDU) when reserving the IP.

  • Assigning the IP to a VM: Once reserved, the floating IP must be associated with a VM. This process maps the public floating IP to the VM’s private IP, enabling external access. You can assign the IP to a specific network interface (port) on the VM, allowing it to communicate with external systems.

3.3. Security Rules

Security rules are essential to control the traffic flowing to and from your VMs. In OpenStack, security groups are used to define these rules.

  • Creating Security Groups: Security groups define the allowed traffic types (e.g., protocols, ports, IP ranges). You can create security groups with specific rules, such as opening ports for services like SSH (port 22) or HTTP (port 80) from the public internet.

  • Defining Inbound and Outbound Rules: Each security group can have both inbound (ingress) and outbound (egress) rules. Inbound rules control what traffic is allowed to enter the VM, while outbound rules specify what traffic is allowed to leave the VM. For example, you might define an inbound rule to allow traffic on port 80 (HTTP) and an outbound rule to allow all traffic to the internet.

  • VPN-Specific Rules: When working with internal networks like PSNC-INTERNAL-LAN, security groups can be used to limit access to specific IP ranges accessible only via VPN, enhancing the security of internal communications.

By configuring routers, assigning floating IPs, and setting up appropriate security rules, users can achieve a flexible and secure network setup. This enables VMs to be accessible from both public and private networks, with fine-grained control over network traffic.



  • No labels