openstack networking cookbook


www.allitebooks.com OpenStack Networking Cookbook Harness the power of OpenStack Networking for public and private clouds using 90 hands-on recipes Sriram Subramanian Chandan Dutta Chowdhury BIRMINGHAM - MUMBAI www.allitebooks.com FM-2 OpenStack Networking Cookbook Copyright © 2015 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: October 2015 Production reference: 1030207 Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK. ISBN 978-1-78528-610-0 www.packtpub.com www.allitebooks.com FM-3 Credits Authors Sriram Subramanian Chandan Dutta Chowdhury Reviewers Daniel Aquino Yan Haifeng Sayali Lunkad Sarath Chandra Mekala Madhusudan H V Commissioning Editor Kartikey Pandey Acquisition Editor Vivek Anantharaman Content Development Editor Divij Kotian Technical Editor Bharat Patil Copy Editor Tasneem Fatehi Project Coordinator Nikhil Nair Proofreader Safis Editing Indexer Mariammal Chettiyar Graphics Jason Monteiro Production Coordinator Nilesh R. Mohite Cover Work Nilesh R. Mohite www.allitebooks.com FM-4 About the Authors Sriram Subramanian is an experienced professional with over 18 years of experience in building networking and network management products. Since 2011, he has been working with Juniper Networks leading engineering teams responsible for OpenStack Neutron plugins, VMware integration, and Network management products. He is a technologist with a passion for virtualization and cloud networking. He blogs regularly at http://www.innervoice. in/blogs and loves experimenting with new technologies and programming. I would like to dedicate this book to my family. I want to thank my wife, Kala, for her support during this entire project. Her give your best attitude motivates me to strive harder in managing my time and energy effectively. I also want to thank Appa and Amma for their patience and blessings, and a special thank you to my daughter, Navya, and our Labrador, Neige, for the joie de vivre they bring to my life. I extend a special thank you to my employer, Juniper Networks, and specifically my manager, Rakesh Manocha. The leadership team at Juniper has created an environment where individuals can pursue excellence through innovation. It has helped me expand my knowledge and capabilities beyond my imagination. I would like to express my gratitude to my publishers, Packt Publishing, and the reviewers who provided invaluable feedback. Finally, a big thank you to Chandan for being a great coauthor and helping me learn a whole lot more about OpenStack. www.allitebooks.com FM-5 Chandan Dutta Chowdhury is a tech lead at Juniper Networks Pvt. Ltd. working on OpenStack Neutron plugins. He has over 11 years of experience in the deployment of Linux-based solutions. In the past, he has been involved in developing Linux-based clustering and deployment solutions. He has contributed to setting up and maintaining a private cloud solution in Juniper Networks. He loves to explore technology and writes a blog at https://chandanduttachowdhury.wordpress.com. I would like to dedicate this book to my parents, Manju and Kiran Moy Dutta Chowdhury. They have been a source of inspiration and support throughout my life. I am thankful to my coauthor and manager, Sriram, who has motivated me to pursue challenges that I thought were beyond my reach. He has always provided me with encouraging and constructive feedback. I would like to thank Juniper Networks for providing a supportive environment and great opportunities to learn and explore new technology. I would like to thank Packt Publishing for their guidance and feedback. www.allitebooks.com FM-6 About the Reviewers Daniel Aquino currently holds the position of a system architect at Nasdaq. This role involves challenging and interesting problems in automation, and the deployment of infrastructure and applications at scale for both public and private cloud platforms. OpenStack is one of the cloud computing platforms that he is currently exploring. Yan Haifeng is a software engineer in HP's Cloud. He has participated in the development of OpenStack when he was still an undergraduate in a laboratory of South China Agricultural University. Before HP, he worked for Vipshop (building an enterprise private cloud platform) and ChinaNetCenter (building a public cloud and managed cloud for customers), both based on OpenStack. Haifeng blogs at http://yanheven.github.io/. Thanks to my first boss, Larf (Chen zhanqi) in Vipshop, who gave me the chance to participate in building a private cloud for Vipshop, and Chen Shake, who encouraged me a lot and guided me on the road to cloud computing. Sayali Lunkad is 23 years old and was born and brought up in India. She is currently living in Germany. She graduated with a bachelor's degree in computer science in 2014 from the Pune Institute of Computer Technology. She was a former intern in the Outreach Program for Women (now known as the Outreachy Program) working with the OpenStack foundation while still completing her degree course. After completing her bachelor's degree, she was freelancing for about one year, mainly working on open source projects such as OpenStack. She is a core reviewer for OpenStack. She is currently working at SUSE Linux as an OpenStack developer. I would like to thank my family, especially my mother, Smita Lunkad, for always having faith in me and being extremely supportive. www.allitebooks.com FM-7 Sarath Chandra Mekala holds a master's degree in communication systems from the Indian Institute Of Technology, Madras. He currently works as a technical lead at Juniper Networks and is responsible for integrating various Juniper devices such as EX and QFX switches and SRX/VSRX firewall devices with leading Open Source Cloud Orchestration Solutions such as OpenStack and CloudStack. Sarath has over 12 years of experience working on Java & J2EE based Network Management Systems. He has a wide array of skills spanning over web and server side programming, which he keeps cramming with new technologies and skills all the time. Sarath is multi-faceted and he prides himself as an intermediate level professional photographer, an avid sci-fi & fantasy reader, an aquarist, a budding gardener, a blogger, and a gastronomist. Sarath blogs at http://sarathblogs.blogspot.in/ I would like to thank my wife, Kalyani, for encouraging me along and my son, Abhiram, for the joy he brings to my life. Thanks to Sriram and Chandan for tagging me up for the review and the team at Packt Publishing for their support. Madhusudan H V works as a Staff Engineer at Juniper Networks. He has more than 11 years of experience in developing enterprise grade telecom and networking management applications. He loves coding and focuses on developing new applications that help solve day-to-day problems of network and datacenter administrators. Madhusudan is passionate about networking, virtualization, and cloud domains. He is a VMware Certification Professional (VCP) and Cisco Certified Network Associate (CCNA). Madhusudan is the author of a cloud-related technical blog at http://fastclouds.net/. Thanks to Sriram Subramanian for his guidance and support in my experiments with new technologies. I would also like to thank my wife, Nanditha, and my son, Alok, for supporting me in reviewing this book. www.allitebooks.com FM-8 www.PacktPub.com Support files, eBooks, discount offers, and more For support files and downloads related to your book, please visit www.PacktPub.com. Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at service@packtpub.com for more details. At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks. TM https://www2.packtpub.com/books/subscription/packtlib Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books. Why Subscribe? ff Fully searchable across every book published by Packt ff Copy and paste, print, and bookmark content ff On demand and accessible via a web browser Free Access for Packt account holders If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view 9 entirely free books. Simply use your login credentials for immediate access. www.allitebooks.com i Table of Contents Preface v Chapter 1: Getting Started with OpenStack Networking 1 Introduction 1 Creating a Subnet and Network using Horizon 3 Viewing the details of a Network using Horizon 5 Associating a Network to an instance using Horizon 8 Creating a Network using OpenStack CLI 11 Creating a Subnet using OpenStack CLI 14 Creating a Port without an associated instance using the OpenStack CLI 16 Associating a Port to an instance using OpenStack CLI 17 Configuring the networking quota in OpenStack 20 Chapter 2: Using Open vSwitch for VLAN-Based Networks 23 Introduction 23 Configuring Neutron to use the Open vSwitch mechanism driver 24 Configuring Neutron to use the VLAN type driver 26 Configuring the VLAN range to be used for the networks 27 Viewing the VLAN allotted for a Network 29 Creating a Network with a specific VLAN 31 Viewing the virtual interface information on the compute node 36 Viewing the virtual interface information on the Network node 41 Chapter 3: Exploring Other Network Types in Neutron 47 Introduction 48 Configuring Neutron to use the Linux bridge mechanism driver 48 Viewing the virtual interface information for Linux bridge on the compute node 50 Configuring Neutron to use a Flat network type 56 Creating a Flat Network using Horizon 57 Creating a Shared Network using Horizon 60 www.allitebooks.com ii Table of Contents Creating an External Network using Horizon 63 Setting up a simple web application – an introduction 66 Setting up a simple web application – setting up OpenStack Networks 68 Setting up a simple web application – creating instances 73 Chapter 4: Exploring Overlay Networks with Neutron 77 Introduction 77 Configuring Neutron to use a VXLAN type driver 78 Configuring a VNI Range for VXLAN Networks 80 Viewing a VNI assigned to a Neutron Network 81 Creating a Network with a specific VNI 84 Viewing the virtual interface information on the compute node for VXLAN tunnels 86 Viewing the virtual interface information on the network node for VXLAN tunnels 89 Configuring Neutron to use a GRE type driver 92 Viewing a virtual interface on the compute node for GRE tunnels 94 Chapter 5: Managing IP Addresses in Neutron 99 Introduction 100 Creating an instance with a specific IP address 100 Configuring multiple IP addresses for a virtual interface 104 Creating a redundant DHCP server per OpenStack Network 107 Starting the DHCP server on a specific network node 108 Increasing the number of IP addresses in a Network using the Horizon dashboard 111 Chapter 6: Using Routing Services in Neutron 115 Introduction 115 Configuring Neutron for Routing services 116 Creating a Router using the Horizon dashboard and Neutron CLI 118 Enabling instances on different Networks to communicate 120 Allowing the Virtual Machine instances to access the Internet 124 Providing access to a Virtual Machine from an external Network or the Internet 126 using Horizon 126 Creating and deleting a floating IP address using the Neutron CLI 130 Associating a floating IP address to a virtual machine using the Neutron CLI 132 Chapter 7: Using Neutron Security and Firewall Services 135 Introduction 135 Creating a security group using Horizon 136 Configuring the security group rules using Horizon 138 iii Table of Contents Creating a security group using CLI 144 Configuring the security group rules using CLI 145 Securing the traffic between instances on the same Network 146 Creating the security group rules to allow web traffic 151 Configuring Neutron for the Firewall service 154 Creating the Firewall rules 156 Creating the Firewall policies 159 Creating a Firewall 161 Viewing and verifying the Firewall rules on the Network node 164 Chapter 8: Using HAProxy for Load Balancing 169 Introduction 170 Installing and configuring the Neutron load balancer service plugin 170 Creating a load balancer pool using Horizon 172 Creating a load balancer pool using CLI 176 Adding a load balancer member using Horizon 177 Adding a load balancer member using CLI 181 Adding a load balancer health monitor using Horizon 182 Adding a load balancer health monitor using CLI 185 Creating a Virtual IP using Horizon 186 Creating a Virtual IP using CLI 189 Making the load balancer accessible to the Internet 191 Testing the load balancer 192 Viewing the load balancer on the network node 194 Chapter 9: Monitoring OpenStack Networks 197 Introduction 197 Monitoring the Virtual Machine bandwidth 199 Monitoring the L3 bandwidth 201 Monitoring the load balancer connection statistics 204 Monitoring the per project and per user bandwidth 206 Monitoring the host Network bandwidth 207 Chapter 10: Writing Your Own Neutron ML2 Mechanism Driver 209 Introduction 209 Creating a basic ML2 mechanism driver 210 Registering your ML2 mechanism driver with the Neutron server 212 Processing API requests for a Network 214 Processing API requests for a Subnet 217 Processing API requests for a Port 219 Chapter 11: Troubleshooting Tips for Neutron 223 Introduction 223 Troubleshooting a VM that does not get a DHCP IP address 224 iv Table of Contents Troubleshooting a VM that does not get an initial configuration 227 Troubleshooting a VM that does not get external Network access 229 Troubleshooting a VM not reachable from external Networks 231 Checking the status of the Neutron service 232 Checking the MAC address table on a virtual switch 234 Chapter 12: Advanced Topics 237 Introduction 237 Configuring Neutron for VPN as a service 238 Testing VPN as a service on Neutron 240 Using link aggregation on the compute node 249 Integrating networking in a Heat template 251 Index 257 v Preface OpenStack is an open source platform that leverages compute, network, and storage solutions to create private and public clouds. In the last couple of years, the adoption of OpenStack has increased dramatically and is being embraced by enterprises around the world. Networking is one of the pillars of OpenStack. A solid understanding of OpenStack Networking will help you implement a rich suite of services in your OpenStack cloud. This book helps you develop the practical knowledge of a wide range of OpenStack Networking concepts. This book starts with building blocks such as Network, Subnet, and Port. It then proceeds to cover OpenStack Networking technologies, such as Routers, Firewalls, and so on. Advanced topics such as the configuration of load balancers, VPN service to provide site-to-site connectivity, and development of a simple ML2 driver are also covered to help you build and manage the best networks for your OpenStack cloud. This book will cover you the following topics: ff How to build and manage virtual switching, routing, and firewall-based networks in OpenStack using Neutron ff How to develop plugins and drivers for Neutron to enhance the built-in networking capabilities ff How to monitor and automate OpenStack networks using tools such as Ceilometer and Heat What this book covers Chapter 1, Getting Started with OpenStack Networking, introduces you to the building blocks of OpenStack Networking, namely Network, Subnet, and Port. Chapter 2, Using Open vSwitch for VLAN-based Networks, shows you how to build and manage OpenStack networks using VLANs and Open vSwitch. Preface vi Chapter 3, Exploring Other Network Types in Neutrons, takes you through the different types of OpenStack networks with the help of a practical example. Chapter 4, Exploring Overlay Networks with Neutron, shows you how to build and manage the VXLAN-based and GRE-based networks in OpenStack. Chapter 5, Managing IP Addresses in Neutron, helps you understand the IP address allocation and DHCP-based address assignment features in OpenStack Neutron. Chapter 6, Using Routing Services in Neutron, explores how to leverage OpenStack routing capabilities to connect multiple networks. Chapter 7, Using Neutron Security and Firewall Services, shows you how to implement security groups and Firewall as a service in OpenStack in order to secure your cloud networks. Chapter 8, Using HAProxy for Load Balancing, takes you through the techniques to implement load balancing as a service in OpenStack using HAProxy. Chapter 9, Monitoring OpenStack Networks, shows you how to monitor your OpenStack networks using Ceilometer. Chapter 10, Writing Your Own ML2 Mechanism Driver, gives you a foundation on how to write your own custom ML2 mechanism driver for Neutron. Chapter 11, Troubleshooting Tips for Neutron, highlights the different OpenStack networking problems that you can run into and their solutions. Chapter 12, Advanced Topics, covers advanced topics, such as VPN as a Service and Networking using Heat template. What you need for this book To use this book, you will need computers or servers that have hardware virtualization capabilities. Kilo is the most recent release of OpenStack and is recommended to try out the recipes in this book. OpenStack supports different models of deployment and each chapter provides a high level setup that is relevant for the corresponding recipes. You can also use DevStack for most of the recipes, but we recommend creating a distributed OpenStack setup for in-depth learning. Preface vii Who this book is for This book is aimed at network and system administrators who want to deploy and manage the OpenStack-based cloud and IT infrastructure. If you have a basic knowledge of OpenStack and virtualization, this book will help you leverage the rich functionality of OpenStack Networking in your cloud deployments. Sections In this book, you will find several headings that appear frequently (Getting ready, How to do it, How it works, There's more, and See also). To give clear instructions on how to complete a recipe, we use these sections, as follows: Getting ready This section tells you what to expect in the recipe, and describes how to set up any software or any preliminary settings required for the recipe. How to do it… This section contains the steps required to follow the recipe. How it works… This section usually consists of a detailed explanation of what happened in the previous section. There's more… This section consists of additional information about the recipe in order to make the reader more knowledgeable about the recipe. See also This section provides helpful links to other useful information for the recipe. Conventions In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning. Preface viii Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "We can include other contexts through the use of the include directive." A block of code is set as follows: [ml2] . . . dhcp_agents_per_network = 2 Any command-line input or output is written as follows: openstack@controller:~$ cat author_openrc.sh export OS_TENANT_NAME=cookbook export OS_USERNAME=author export OS_PASSWORD=password export OS_AUTH_URL=http://controller:35357/v2.0 New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "In the left navigation menu, click on Identity and then Projects." Warnings or important notes appear in a box like this. Tips and tricks appear like this. Reader feedback Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of. To send us general feedback, simply e-mail feedback@packtpub.com, and mention the book's title in the subject of your message. If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors. Preface ix Customer support Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase. Downloading the example code You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. Downloading the color images of this book We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/ downloads/6100OS_ColorImages.pdf. Errata Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title. To view the previously submitted errata, go to https://www.packtpub.com/books/ content/support and enter the name of the book in the search field. The required information will appear under the Errata section. Preface x Piracy Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy. Please contact us at copyright@packtpub.com with a link to the suspected pirated material. We appreciate your help in protecting our authors and our ability to bring you valuable content. Questions If you have a problem with any aspect of this book, you can contact us at questions@ packtpub.com, and we will do our best to address the problem. 1 1 Getting Started with OpenStack Networking In this chapter, we will show you the following set of recipes covering the different ways to create and manage the core Neutron entities, namely Network, Subnet, and Port: ff Creating a Subnet and Network using Horizon ff Viewing the details of a Network using Horizon ff Associating a Network to an instance using Horizon ff Creating a Network using OpenStack CLI ff Creating a Subnet using OpenStack CLI ff Creating a Port without an associated instance using OpenStack CLI ff Associating a Port to an instance using OpenStack CLI ff Configuring the networking quota in OpenStack Introduction Businesses are increasingly adopting cloud-based solutions for their IT requirements. This move to cloud started with the server virtualization where a hardware server ran as a virtual machine on a hypervisor. The server hardware connects to the Network switches using Ethernet and IP to establish Network connectivity. However, as servers move from physical to virtual, the Network boundary also moves from the physical network to the virtual network. As the cloud platforms leverage virtualization, it is important that they support the physical and virtual networking effectively. Getting Started with OpenStack Networking 2 OpenStack is an open source cloud platform that helps build public and private clouds at scale. In OpenStack, the name for the OpenStack networking project is Neutron. The functionality of Neutron can be classified as core and service. In the rest of the book, the terms Neutron and OpenStack networking are used interchangeably. The OpenStack networking core functionality refers to the Layer 2 (L2) Network connectivity and basic IP address management for virtual machines. Neutron provides the core functionality using entities such as Network, Subnet, and Port. This chapter will provide you with recipes about managing these entities. The OpenStack networking service functionality deals with the Layer 3 (L3) to Layer 7 (L7) capabilities as defined in the OSI Network model. Neutron also works with the telemetry module called Ceilometer in order to let the cloud operators monitor the health of the OpenStack Networks. In order to implement the recipes covered in this chapter, you will need an OpenStack setup, as described here: Keystone Service Nova Service(s) Glance Service Neutron Server Neutron Agent(s) eth0 eth0eth1 eth1 Open vSwitch Open vSwitch Management Network Data Network Nova Service Neutron Agent(s) Controller and Network Node Compute Node This setup has one compute node and one node for the controller and networking services. For this chapter, you can also set up a single all-in-one environment. This book is based on OpenStack on the Ubuntu platform. For other platforms, such as Red Hat, the dashboard may have a different theme but there should not be any difference in the functionality. Chapter 1 3 Creating a Subnet and Network using Horizon Network and Subnet are the fundamental networking entities in OpenStack. Using these two entities, virtual machines or instances are provided with Network connectivity. The creation of a Subnet and Network go hand in hand. Both OpenStack CLI and Horizon support the creation of a Subnet and Network. This recipe explains how to create a Subnet and Network using Horizon. Getting ready In order to create a Network and Subnet, you will need the following information, minimally: ff The Network name ff The Subnet name ff The IP address range for the Subnet—the range should be in CIDR format How to do it… 1. Log in to the OpenStack Horizon dashboard. 2. In the left navigation menu, click on Project | Network | Networks. 3. Now click on the + Create Network button. The following screen will be displayed: 4. Enter the Network Name and click Next. 5. The next screen lets you create the Subnet that will be part of the Network. Getting Started with OpenStack Networking 4 6. Enter the Subnet Name and the address range in CIDR format, as shown in the following screenshot: 7. Click Next. In the next screen, all the fields are optional, so click on Create. 8. Once the Network and Subnet are created successfully, the entry will appear in the Networks table, as shown here: Chapter 1 5 The preceding steps covered the most commonly used workflow to create a Network and Subnet using Horizon. How it works… The Network and Subnet entities represent two basic Networking functionalities. A Network defines the Layer 2 (L2) boundary for all the instances that are associated with it. All the virtual machines in a Network are a part of the same L2 broadcast domain. The Subnet, on the other hand, is the range of IP addresses that are assigned to the virtual machines on the associated Network. OpenStack Neutron configures the DHCP server with this IP address range and it starts one DHCP server instance per Network, by default. OpenStack Neutron also allocates one IP to act as the gateway IP unless the user provides a specific IP address for the gateway. There's more… As you can see from the UI, it is possible to create a Network without a Subnet. You can choose between the IPv4 or IPv6 addressing schemes. The Subnet Details section allows operators to enable or disable DHCP for the Network. Optionally, you can also specify the DNS servers and IP pools. Viewing the details of a Network using Horizon Once a Network and Subnet have been created, you can use Horizon to view useful details such as the ID, Network Type, and Gateway IP. You can also view the topology of the Network that you just created. Getting ready For this recipe, you need to know the name of the Network whose details you want to view. How to do it… 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, click on Project | Network | Networks. Getting Started with OpenStack Networking 6 3. On the right-hand side, you will see a list of all the Networks. In the following screenshot, you can see two Networks: 4. To view the details of a particular Network, click on the Name of the Network: 5. In the preceding screen, the key fields to note are Network Type, Segmentation ID, and Gateway IP for the Subnet. Chapter 1 7 6. To view the topology, click on Network Topology in the left navigation panel: 7. As you can see, the two Networks are shown as vertical color-coded bars. The Subnets belonging to the Network are indicated at the end of the bars. How it works… When you create a Network, the Horizon dashboard makes a REST API call to Neutron to create a Network. During the installation, the OpenStack administrator configures Neutron with a tenant Network type. This Network type is used by Neutron to create the Network. Note that if you create and view the Network with a non-administrative role, some of the fields may not be displayed. While creating the Subnet, we did not select any gateway IP, so Neutron will automatically select the first IP address in the Subnet and configure this as the gateway IP for that Subnet. Getting Started with OpenStack Networking 8 Associating a Network to an instance using Horizon Once the Network and Subnet are created, the next step for the end user is to create an instance or virtual machine and associate the Network to the virtual machine. This recipe shows you how to accomplish this. Getting ready One of the prerequisites to create an instance is to add a virtual machine image to the Glance image service. In our example, we will add a CirrOS image and use this image to create an instance. How to do it… 1. Log in to the OpenStack Horizon dashboard using the appropriate credentials. 2. In the left navigation menu, click on Project | Compute | Instances. 3. Now click on the Launch Instance action on the right-hand side of the screen. The wizard to create and start an instance will be displayed: Chapter 1 9 4. Enter a name for the instance, choose a Flavor, select a source as Boot from image, and choose the desired image: Getting Started with OpenStack Networking 10 5. To associate the instance to a Network, click on the Networking tab at the top. You should see a screen where the Selected networks field is empty: 6. In the Available networks field, click on the + sign next to the Network to which the instance needs to be associated. Then click on Launch: Chapter 1 11 7. This should result in the creation and booting up of your instance and the Instances table is updated to show you the instance that was just created: This recipe showed you that as a part of instance creation, the Horizon GUI allows users to choose the Network to which the instance needs to be associated. How it works… As part of the instance creation process, the user chooses the Network to which the instance will be associated. The instance creation and scheduling is the responsibility of Nova and it sends a create Port request to Neutron in order to associate the instance to the selected Network. In response to the create Port request, Neutron will ensure that the virtual Network on the hypervisor server is configured so as to provide connectivity to the virtual machine. For the very first instance created on the Network, the Neutron server will also start a DHCP process on the Network node. This happens when DHCP is enabled on the corresponding Network. Once a virtual machine boots up, it will send a DHCP request. In response to this request, the DHCP server for that Network will respond with an IP address. There's more… If there is exactly one Network for a given tenant, then the dashboard automatically selects this Network when an instance is created. Additionally, note that the tenants can associate more than one Network to an instance. This will create multiple interfaces in the virtual machine. Creating a Network using OpenStack CLI We have seen how to use the Horizon dashboard to create a Network. Let's now do the same with OpenStack CLI. Several CLI commands offer additional capabilities when compared to the dashboard. So it is good to develop a sound knowledge of the CLI commands. www.allitebooks.com Getting Started with OpenStack Networking 12 Getting ready You will need the following information to create a Network using CLI: ff The login credentials for SSH to a node where the Neutron client packages are installed (usually the controller node) ff A shell RC file that initializes the environment variables for CLI How to do it… The next set of steps will show you how to use the Neutron CLI commands to create a Network: 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands: openstack@controller:~$ source author_openrc.sh 3. The contents of a typical shell RC file are as follows: openstack@controller:~$ cat author_openrc.sh export OS_TENANT_NAME=cookbook export OS_USERNAME=author export OS_PASSWORD=password export OS_AUTH_URL=http://controller:35357/v2.0 openstack@controller:~$ openstack 4. The command to create a Network is neutron net-create, and in the simplest form, the only argument required is the Network name: Chapter 1 13 5. You can view all the Networks created using the neutron net-list command: 6. One of the interesting command-line options for the neutron net-create command is the --tenant-id option. This option allows users with an administrative role to create a Network for another tenant. The following screenshot shows you how an administrative user (for an administrative project or tenant) creates a Network for a cookbook tenant: 7. The tenant ID argument works only when the user specifies the unique tenant ID. However, sometimes it is convenient to use the tenant name. The following command automates the conversion from the tenant to the tenant ID. The keyword, cookbook, is the tenant name used for this command: Getting Started with OpenStack Networking 14 How it works… When the user executes the neutron net-create command, the user name and tenant name attributes are taken from the shell environment variables that were initialized at the beginning. Neutron creates the Network with this user and tenant (or project). However, once the --tenant-id option is used, the Network is created on behalf of the tenant whose ID is specified. There's more… Users can specify several other arguments while creating Networks. These options are provider:network_type, --provider:segmentation_id, and router:external. While we will be taking a closer look at these parameters in the subsequent chapters, it is important to note that some of these options are available only if users have the administrative privilege. To view the details of a specific Network, you can use the neutron net-show command. Creating a Subnet using OpenStack CLI Similar to the CLI commands to create a Network, the next recipe will explore the CLI command to create a Subnet. The key aspect of the CLI commands for Subnet creation is that a Network Name is a mandatory attribute. Getting ready You will need the following information to get started: ff The login credentials for SSH to a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The next set of steps will show you how to use Neutron CLI to create a Subnet: 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe. Chapter 1 15 3. The command to create a Subnet is neutron subnet-create and the mandatory arguments are the Network name and IP address range in the CIDR format. However, it is a good practice to specify a name for the Subnet. For simplicity, we will choose the Network, CookbookNetwork2, that was created earlier because it does not have any associated Subnet yet: 4. Now, when we execute the neutron net-list command, we will see that CookbookNetwork2 has an associated Subnet that we just created: 5. Users can view the list of Subnets using the neutron subnet-list command: How it works… When the user executes the neutron subnet-create command, Neutron creates a Subnet with the specified IP address range and other parameters. Neutron also associates the Subnet with the specified Network. Getting Started with OpenStack Networking 16 Creating a Port without an associated instance using the OpenStack CLI Port is another building block in OpenStack Neutron. You will not find a way to create a Port using the Horizon dashboard. As we saw earlier in the Associating a Network to an instance using Horizon recipe, a Port is created implicitly as a part of the create instance operation from the dashboard. However, using CLI, some advanced networking configuration can be accomplished. This recipe shows you how to create a Port using OpenStack CLI. Getting ready You will need the following information to get started: ff The login credentials for SSH to a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The next set of steps will show you how to use Neutron CLI to create a Port: 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the previous recipe. 3. The command to create a Port is neutron port-create and the only mandatory parameter is the Network name. However, it is a good practice to specify a name for the Port: Chapter 1 17 4. Note that the Port has been assigned a MAC address as well as an IP address. 5. You can use the neutron port-list command to view a list of all the Ports in the system: How it works… A Port primarily represents an endpoint in a Network. The most common Ports in an OpenStack environment are the virtual interfaces in a virtual machine. When the neutron port-create command is executed, OpenStack Neutron allocates a unique MAC address to the Port. The Network name argument effectively helps Neutron in identifying a Subnet and then Neutron assigns an IP address to the Port from the list of available IP addresses in the Subnet. The post-create request is also the most common trigger to configure the physical and virtual Networks using the appropriate drivers. Associating a Port to an instance using OpenStack CLI The previous recipe showed you how to create a Port using CLI. The next recipe shows you how we can use an existing Port as part of the instance creation command. Getting ready For this recipe, you will have to identify the Port that you want to associate with an instance. For the instance creation itself, the software image needs to be identified. How to do it… The next set of steps will show you how to use the Nova and Neutron CLI commands to create an instance that uses an existing Port: 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron and Nova client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands as seen in the earlier recipes. Getting Started with OpenStack Networking 18 3. Execute the neutron port-list command and identify the ID of the Port that you want to use to create an instance. Make a note of the MAC and IP addresses assigned to the Port: 4. The CLI command to create an instance is nova boot. This command supports an argument called --nic that allows us to specify a Port ID that we want to associate with the instance: openstack@controller:~$ nova boot --flavor m1.tiny --image cirros- 0.3.3-x86_64 --nic port-id=ee6f30a1-6851-435a-89cd-a8e7390325a4 CLIPortVM 5. Note that the virtual machine name used in the command is CLIPortVM. If we execute the nova show command now, we can see the details about the instance: 6. In the preceding output, you can see that the IP address of the Port created using CLI has been assigned to the instance. 7. Log in to the Horizon dashboard and navigate to Network Topology, as discussed in the Viewing the details of a Network using Horizon recipe. In Network Topology, move the mouse pointer over the icon representing the instance and click on Open Console as shown here: Chapter 1 19 8. In the resulting window, log in to the instance. In our example, we will be using the CirrOS default username and password for the login. At the shell prompt of the instance, type ifconfig eth0. This command will show the virtual interface for this instance. The command output shows the MAC and IP addresses that are assigned to the virtual interface: Getting Started with OpenStack Networking 20 This recipe demonstrated how to associate a Port to an instance. At the end of the recipe, we can see that the MAC and IP addresses for this virtual interface (eth0) match those of the Port that we used in the nova boot command. How it works… We have seen that Neutron assigns an IP address and MAC address to a Port during their creation. When users execute the nova boot command with the --nic option, then Nova takes the IP and MAC addresses of the Port and uses this information to configure the virtual interface of the instance. There's more… This technique of creating a Port prior to the instance creation is helpful if a specific IP address needs to be assigned to an instance or virtual machine. While we will cover this in another recipe later in the book, it is important to note that this capability is not available using the Horizon dashboard. Configuring the networking quota in OpenStack Quotas are limits defined in OpenStack to ensure that the system resources and capacity are used in a systematic manner. Different users can be given different quota limits based on their requirement and priority. In this recipe, we will show you how to configure a quota related to networking at a project level and for the whole system. Getting ready The setting up and enforcement of the quota are done at the project level. If any user in the project tries to exceed the allotted quota, the system will reject the corresponding request. To configure the quota-related parameters, you need to have a good idea about the capacity, scale, and performance requirements of your OpenStack-based cloud. How to do it… The following steps will show you how to configure the networking-related quota: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. Chapter 1 21 2. In the left navigation menu, click on Identity and then Projects. In the Actions column, select Modify Quota for the tenant of your choice, as follows: 3. In the resulting window, the networking-related quotas are defined as shown in the following screenshot. Make the changes and click Save. Getting Started with OpenStack Networking 22 4. In order to change the networking-related quota at the whole system level, you need to change the settings in the Neutron server configuration file. 5. With the appropriate credentials, SSH into the node where the Neutron server is running. 6. Open the Neutron configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf 7. In the configuration file, look for a section starting with [quotas]. All the quota-related settings start with quota_. Edit these settings as required and save the file. 8. The Neutron server needs to be restarted for these settings to take effect. Restart the Neutron server using the following command: sudo service neutron-server restart How it works… All the quota settings are stored on a per project (tenant) basis. During the creation of a project using CLI or Horizon, OpenStack (Keystone) fetches the system-wide default quotas from the configuration files and associates them to the project (or tenant). Hereafter, even if the system-wide quotas are changed, the project-level quotas do not change automatically. However, the project-level quotas can be changed anytime using Horizon or CLI, and these changes take effect immediately. All the OpenStack commands and API calls are checked against the project-level quotas. If any commands or API calls violate the limits, they will be rejected with an appropriate error. 23 2 Using Open vSwitch for VLAN-Based Networks In this chapter, we will demonstrate how Open vSwitch can be used to create and manage VLAN-based Networks for OpenStack tenants. The following recipes will be covered in this chapter: ff Configuring Neutron to use the Open vSwitch mechanism driver ff Configuring Neutron to use the VLAN type driver ff Configuring the VLAN range to be used for the Networks ff Viewing the VLAN allotted for a Network ff Creating a Network with a specific VLAN ff Viewing the virtual interface information on the compute node ff Viewing the virtual interface information on the Network node Introduction As discussed in the first chapter, virtualization and cloud computing are pushing the network boundary from the physical network to the virtual network. The non-virtualized physical servers are connected to the physical network switches for connectivity. The shift from physical to virtual networking implies that the virtual machines should be connected to the virtual switches for connectivity. In order to allow the multiple networking technologies to interoperate, Neutron uses the concept of plugins. The Modular Layer 2 (ML2) is a type of core plugin that supports multiple drivers so that the plugin functionality can be extended and customized. The ML2 plugin comprises of type drivers and mechanism drivers. Using Open vSwitch for VLAN-Based Networks 24 Open vSwitch, popularly referred to as OVS, is one of the implementations of the virtual switches for the Linux platforms. It is an open source, production quality, virtual switch that supports the rich networking protocols and features. In order to implement these recipes, you will need an OpenStack setup as described here: Keystone Service Nova Service(s) Glance Service Neutron Server Neutron Agent(s) eth0 eth0eth1 eth1 Open vSwitch Open vSwitch Management Network Data Network Nova Service Neutron Agent(s) Controller and Network Node Compute Node This setup has one compute node and one node for the controller and networking services. For this chapter, you can also use a single all-in-one OpenStack setup. As discussed in the previous chapter, the core functionality of Neutron is to provide Layer 2 (L2) connectivity. Neutron provides this functionality through the use of a core plugin. All the recipes of this chapter assume that ML2 is the core plugin in the Neutron configuration file. Configuring Neutron to use the Open vSwitch mechanism driver The ML2 plugin can support many mechanisms to provide the core functionality. We will see how Open vSwitch can act as a mechanism driver for the ML2 plugin. Getting ready Using OVS as the mechanism driver requires changes to the ML2 plugin configuration file. We also have to configure OVS with a tenant network type and physical network alias. How to do it… The following steps will show you how to configure Open vSwitch as the mechanism driver for the ML2 plugin: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. Chapter 2 25 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure ML2 to use OVS as the mechanism driver: [ml2] ... mechanism_drivers = openvswitch 4. In the [ovs] section of the file, configure OVS with the tenant network type and physical bridge mapping: [ovs] ... tenant_network_type = vlan bridge_mappings = physnet1:br-eth1 5. In the previous step, br-eth1 represents the actual Open vSwitch instance that is bound to a physical interface and physnet1 represents the alias for the OVS instance. 6. The OVS instance, br-eth1, can be created using the following steps (assuming that the eth1 interface is used for the data traffic): openstack@controller:~$ sudo ovs-vsctl add-br br-eth1 openstack@controller:~$ sudo ovs-vsctl add-port br-eth1 eth1 7. Restart the Neutron and Open vSwitch services on the Controller and Network nodes of our setup, using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service openvswitch-switch restart openstack@controller:~$ sudo service neutron-openvswitch-agent restart 8. Repeat these steps for the compute node in the setup. 9. The next few steps will show you the changes that are needed on the Network node so that the Neutron agents can use the OVS-related drivers. 10. Edit the [DEFAULT] section of the DHCP agent configuration file located at /etc/ neutron/dhcp_agent.ini as follows: [DEFAULT] ... interface_driver = neutron.agent.linux.interface. OVSInterfaceDriver Using Open vSwitch for VLAN-Based Networks 26 Edit the [DEFAULT] section of the L3 agent configuration file located at /etc/neutron/l3_agent.ini as follows: [DEFAULT] ... interface_driver = neutron.agent.linux.interface. OVSInterfaceDriver 11. Edit the [securitygroup] section of the ML2 plugin configuration file located at /etc/neutron/plugins/ml2/ml2_conf.ini as follows: [securitygroup] ... firewall_driver = neutron.agent.linux.iptables_firewall. OVSHybridIptablesFirewallDriver 12. Restart the Neutron-related services as mentioned in step 7. How it works… As part of its startup, the Neutron server will load the core plugin, which in our case is the ML2 plugin. As the ML2 plugin allows multiple ways to implement the physical and virtual networks, it uses the mechanism_drivers attribute to load the desired drivers. The previous steps showed you how to configure OVS as the mechanism driver for ML2. The OVS mechanism driver needs additional information such as the bridge name and physical interface mapping so as to provide network connectivity. Hence, these mappings are also a part of the mechanism driver configuration. Configuring Neutron to use the VLAN type driver The ML2 plugin needs to be configured in order to use VLAN as the network type for all the tenant networks. Getting ready The ML2 plugin has a configuration file setting that needs to be updated so that the tenants can use VLAN as the tenant network type. Chapter 2 27 How to do it… The following steps will show you how to configure VLAN as the type driver and tenant network type: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure VLAN as the type driver and network type: [ml2] ... type_drivers = vlan tenant_network_types = vlan 4. Restart the Neutron and Open vSwitch services on the Controller and Network node of our setup, using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service openvswitch-switch restart openstack@controller:~$ sudo service neutron-plugin-openvswitch- agent restart 5. The first three steps have to be repeated for the compute node in our setup as shown previously. The command to restart OVS on the compute node is: openstack@compute:~$ sudo service openvswitch-switch restart How it works… During the startup, the Neutron server will load the core plugin, which in our case is the ML2 plugin. As the ML2 plugin allows multiple types of networks, it uses type_drivers to check which network type drivers to load. Finally, each tenant with a non-administrative role can use only certain network types. The tenant_network_types attribute indicates the network types. Configuring the VLAN range to be used for the networks In order to use VLAN as the network type, Neutron requires a range of VLAN identifiers. Each OpenStack Network will be associated with a unique VLAN identifier. This recipe shows you how to configure this range of VLAN IDs. Using Open vSwitch for VLAN-Based Networks 28 Getting ready The valid range for a VLAN ID is 1-4095. However, based on your OpenStack environment and the physical network, it is possible to use a subset of this range. How to do it… Configuring the VLAN ID range is a setting in the plugin configuration file. The following steps will show you how to set this range: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2_type_vlan] section of the file, configure the VLAN range: [ml2_type_vlan] ... network_vlan_ranges = physnet1:1001:1200 4. For this recipe, we have used a VLAN ID range of 1001 to 1200. 5. The keyword physnet1 represents the alias for the physical network. This refers to the OVS bridge that is bound to the physical Network adapter on the node. 6. These steps have to be repeated for all the nodes in your OpenStack setup including all the compute and Network nodes. How it works… When a network is created, Neutron will check the tenant network type first. In the case of the VLAN networks, Neutron will fetch the first unused VLAN ID from the range that was configured. This VLAN ID is then associated to the Network and also marked as used. Chapter 2 29 Viewing the VLAN allotted for a Network Open vSwitch configures the VLAN ID on the virtual port associated with a virtual machine instance. The underlying physical network must also be configured so as to allow the data traffic for the same VLAN ID. Hence, the knowledge of the VLAN ID allotted for a Network is very useful, especially while troubleshooting networking problems. This recipe shows you how to view the VLAN ID allotted for a Network. Getting ready The VLAN ID information is available only to users with an administrative role. Hence, for this recipe, you will need the appropriate credentials. How to do it… The following steps will show you how to view the VLAN ID allotted for a Network: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, click on Admin | System | Networks. 3. On the right-hand side, you will get a list of all the Networks in the setup, as shown in the following screenshot: Using Open vSwitch for VLAN-Based Networks 30 4. To view the details of a particular Network, click on the name of the Network. 5. In the preceding screenshot, we can observe that Network Type is vlan. 6. Segmentation ID represents the VLAN ID allotted for this particular Network. Therefore, we can see that the VLAN ID of 1001 has been assigned to this Network. 7. The same information can be viewed using the neutron net-show command of the Neutron CLI, as follows: How it works… When a Network is created, Neutron computes the first free VLAN ID from the range that was configured in the configuration file. This VLAN ID is stored as a segmentation ID in the Neutron database. Chapter 2 31 Creating a Network with a specific VLAN When the user creates a Network, the VLAN ID is automatically assigned to it. However, there can be situations when a Network is required to use a specific VLAN. This can happen when the physical network is preconfigured to carry a certain type of traffic using a specific VLAN ID. Getting ready You will need the following information to create a Network with a specific VLAN: ff The project (tenant) name for which the Network needs to be created ff A VLAN ID from the range configured in the ML2 configuration file How to do it… The following steps will show you how to create a Network with a specific VLAN ID: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, click on Admin | System and Networks. 3. On the right-hand side, we will get a list of all the Networks. As we logged in with an administrative role, we should be able to view all the networks across all the projects: www.allitebooks.com Using Open vSwitch for VLAN-Based Networks 32 4. Click on the + Create Network button to display the Create Network screen for the administrators. Note that this screen is different from the one shown for tenants, which is as follows: Chapter 2 33 5. Enter a name for the Network. Select a Project and select VLAN as Provider Network Type. Once you choose VLAN as the Network type, the screen will prompt you to provide more details as shown here: Using Open vSwitch for VLAN-Based Networks 34 6. Enter physnet1 as the value for Physical Network. This was the alias that was used when configuring OVS as the mechanism driver in the recipe titled Configuring Neutron to use the Open vSwitch mechanism driver. 7. In the Segmentation ID field, enter a VLAN ID from the range that was configured for Neutron. Note that if you enter a VLAN ID that is already in use, the create network request will fail. 8. Now click on Create Network. Once the network creation succeeds, the network will show in the list. Note that this mechanism creates a Network without a subnet. Therefore, you will see that the Subnets Associated column is empty: 9. Click on the Network name of the newly created Network to view its details. You can see that the Segmentation ID that we entered has been used to create the Network: Chapter 2 35 Users can use the + Create Subnet button to add a Subnet to this Network. The preceding steps showed you how a user with an administrative role could create a Network with a specific VLAN. How it works… When a network is created as shown in this recipe, the Neutron server validates the segmentation ID against the VLAN ID range configured in Neutron. If the segmentation ID falls within the range, Neutron will check whether the segmentation ID is already in use or not. If the ID is not in use, then the Network creation will succeed. Using Open vSwitch for VLAN-Based Networks 36 Viewing the virtual interface information on the compute node As tenants, users can create a Network, Subnet, and Instances. However, the underlying physical and virtual network details are hidden from them. This is important because the tenants should focus on their business requirements instead of the specific implementation details. However, the OpenStack administrators need to understand the physical and virtual networking details. This is required in order to troubleshoot any problems faced by the tenants. In this recipe, we will show you how an administrator can view the virtual interface (VIF) information for an instance running on a compute node. Getting ready As this recipe is described from the point of view of an administrator troubleshooting a tenant problem, the following information is required: ff The Tenant Network name ff The virtual machine instance whose VIF information is to be identified How to do it… The following steps will show you how to find the VIF information on a compute node: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, click on Admin | System | Instances. On the right-hand side, you will see a list of all the virtual machine instances. 3. Click the checkbox next to the virtual machine instance whose VIF details you want to see. Using the drop-down menu at the end of the row, select Console: Chapter 2 37 4. This should show the VNC console for the selected instance. Log in to the instance and execute the following command: $ ifconfig 5. You should see an output similar to the following screen. Note down the IP address, 70.70.70.2 in this case, and the MAC address (fa:16:3e:76:cb:e5): Using Open vSwitch for VLAN-Based Networks 38 6. In the left navigation menu, click on Admin | System | Networks. Click on the name of the Network to which the instance belongs. This will display the Network Detail for that Network. Note the Segmentation ID (VLAN ID), which is 1002 in our example: Chapter 2 39 7. You can also see the list of the OpenStack ports for that Network. Our virtual machine instance had an IP address of 70.70.70.2 and there is a Port corresponding to this IP address. Click on the Port Name to view the Port Detail. Note that the MAC and IP addresses match our virtual machine: 8. Pay attention to the ID of the port, especially the first 11 characters, a22f8551-57. 9. Now, log in to the compute node of your setup with the appropriate credentials and execute the following command: openstack@compute1:~$ sudo ovs-vsctl show Using Open vSwitch for VLAN-Based Networks 40 10. You should see an output as follows. The key thing to note is the OVS port named qvoa22f8551-57. As you can see, this port name matches the ID of the OpenStack port used for our virtual machine instance: 11. The tag used for our qvoa22f8551-57 port is 3. This is the tag used in OVS. When OVS forwards the packets from our virtual machine to the outside world, it must tag it with the VLAN ID of 1002 (Segmentation ID). We can verify this using the ovs-ofctl dump-flows br-int command. This command prints all the network flow information for the specific Open vSwitch instance. See the following highlighted output: Chapter 2 41 How it works… The OpenStack entities such as Network, port, and others are assigned a unique ID when they are created. These unique IDs are reused while configuring the physical and virtual network so that troubleshooting is easier. In the preceding example, we identified the port ID for the instance and using this ID, we were able to view the OVS and VLAN information on the compute node. These are usually the foremost steps in identifying the networking problems on a compute node. Viewing the virtual interface information on the Network node The previous recipe showed you how to identify the VIF information on the compute node. Now let's turn our attention to the Network node. While a virtual machine is instantiated on a compute node, the DHCP server for the entire tenant Network is started on the Network node. As multiple tenant networks can have overlapping IP addresses, the Network node uses the concept of namespaces to isolate one Network from the other. Getting ready As this recipe is described from the point of view of an administrator troubleshooting a tenant problem, the following information is required: ff The tenant Network name ff The virtual machine instance whose VIF information is to be identified How to do it… The previous recipe showed you how to view the ports associated with a Network on the Network Detail screen. This recipe shows you how to look for the DHCP-related information on the Network node: 1. In the left navigation menu, click on Admin | System | Networks. Click on the name of the Network to view the details of the network to which the virtual machine instance belongs. Using Open vSwitch for VLAN-Based Networks 42 2. In the details of the Network, we can see the Ports associated with this Network. The DHCP Port for the selected network is highlighted as follows: 3. Click on the Port name to view the DHCP Port Detail. Note that the DHCP IP address is 70.70.70.3 and the Port ID starts with 18cc6f06-2b as highlighted here: Chapter 2 43 4. Now log in to the network node of your setup (the Controller and Network node of our setup for this chapter) with the appropriate credentials and execute the following command: openstack@controller:~$ ip netns qdhcp-bd09066a-eafe-4241-a7b4-bc9d8056d82b 5. The output of the ip netns command lists all the Linux namespaces created on the node. In our setup, we can see a namespace called qdhcp-bd09066a-eafe- 4241-a7b4-bc9d8056d82b. This name is generated by Neutron by adding qdhcp and the unique ID for the Network. Using Open vSwitch for VLAN-Based Networks 44 6. To view the networking information and applications running in a namespace, we will need to start a command shell in the namespace. You can do this using the following command: openstack@controller:~$ sudo ip netns exec qdhcp-bd09066a-eafe- 4241-a7b4-bc9d8056d82b /bin/bash 7. Once this command is successful, you will get a new shell prompt. All the commands executed at this shell prompt are restricted to that namespace. Let's type the following ifconfig command at the prompt: 8. In the output of the ifconfig command, we can see an interface called tap18cc6f06-2b. You will notice that 18cc6f06-2b matches the first few characters of the DHCP port ID that we noted in step 3. 9. Neutron uses dnsmasq to provide DHCP services. We can confirm that the dnsmasq process is using the tap18cc6f06-2b interface with the ps command as shown here: Chapter 2 45 10. Next, we will check how the tap18cc6f06-2b interface is connected to the external physical network. For this, we will exit the namespace shell prompt and execute the following ovs-vsctl show command on the controller shell: 11. As seen in the preceding output, the tap18cc6f06-2b interface is bound to the OVS bridge, br-eth1. This in turn uses the eth1 physical interface of the network node. 12. As seen in the previous recipe, we can execute the ovs-ofctl dump-flows br-int command to confirm that the DHCP port is also using VLAN 1002 that was assigned to the tenant network. Using Open vSwitch for VLAN-Based Networks 46 How it works… Namespaces are constructs in Linux that allows the users to create a copy of a full TCP/ IP network stack including interfaces and routing tables. In the OpenStack networking, one DHCP server is started for each Network and an IP address from the corresponding subnet is assigned to the DHCP server. As the tenant networks can have similar or overlapping IP addresses, Neutron uses namespaces to isolate each DHCP server. As we saw in the previous recipe, Neutron uses unique IDs to identify the physical and virtual network information. The namespace name contained the unique ID of the tenant network. Moreover, the interface used by the DHCP server contained the unique ID of the Network port. 47 3 Exploring Other Network Types in Neutron OpenStack Networking supports different types of network in order to provide rich functionality and flexibility. In this chapter, we will show you the following set of recipes that cover a few specific network types supported in OpenStack: ff Configuring Neutron to use the Linux bridge mechanism driver ff Viewing the virtual interface information for Linux bridge on the compute node ff Configuring Neutron to use a Flat Network type ff Creating a Flat Network using Horizon ff Creating a shared Network using Horizon ff Creating an external Network using Horizon ff Setting up a simple web application – an introduction ff Setting up a simple web application – setting up OpenStack Networks ff Setting up a simple web application – creating instances Exploring Other Network Types in Neutron 48 Introduction In the previous chapter, we saw how OpenStack supports Open vSwitch as the mechanism for a VLAN network type. Similar to Open vSwitch, Linux bridge is a software bridge in a Linux host that is capable of providing virtual network connectivity to instances. In this chapter, we will see how to implement a network type called Flat Network. We will also see how to provide an external (say, the Internet) access to virtual machines (VMs). Finally, we will apply the concepts learned in this chapter to deploy a simple web application. In order to implement these recipes, you will need an OpenStack setup as described here: Keystone Service Nova Service(s) Glance Service Neutron Server Neutron Agent(s) eth0 eth0eth1 eth1 Open vSwitch Open vSwitch Management Network Data Network Nova Service Neutron Agent(s) Controller and Network Node Compute Node This setup has one compute node and one node for controller and networking services. For this chapter, you can also have a single all-in-one environment. As discussed in the previous chapter, the core functionality of Neutron is to provide a Layer 2 (L2) connectivity. Neutron provides this functionality through the use of a core plugin. All the recipes of this chapter assume that ML2 is the core plugin in the Neutron configuration file. Configuring Neutron to use the Linux bridge mechanism driver The ML2 plugin can support many mechanisms in order to provide the core functionality. We will see how a Linux bridge can act as a mechanism driver for the ML2 plugin. This recipe shows you how to configure an ML2 plugin with a Linux bridge as the mechanism driver. Chapter 3 49 Getting ready Configuring ML2 to use a Linux bridge as the mechanism driver requires changes to the ML2 plugin configuration file. We will also have to configure the Linux bridge with a tenant network type and the alias for the Linux bridge that is bound to the physical network adapter of the node. How to do it… The following steps will show you how to configure Linux as the mechanism driver for the ML2 plugin: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure ML2 to use the Linux bridge as the mechanism driver: [ml2] . . . mechanism_drivers = linuxbridge 4. In the [linux_bridge] section of the file, configure the Linux bridge with the tenant network type and physical interface mapping: [linux_bridge] tenant_network_type = vlan physical_interface_mappings = physnet1:eth1 5. In the previous step, physnet1 represents the alias and eth1 represents the physical interface that is added to the Linux bridge instance. 6. Restart the Neutron server and Linux bridge agent on Controller and Network node of our setup using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service neutron-plugin-linuxbridge- agent restart 7. Steps 2 to 5 have to be repeated for the compute node in our setup. On the compute node only the Linux bridge agent needs to be restarted. 8. On the Network node, a few changes are needed so that the Neutron agents can use Linux bridge-related drivers. Exploring Other Network Types in Neutron 50 9. Edit the [DEFAULT] section of the DHCP agent configuration file located at /etc/neutron/dhcp_agent.ini on the network node, as follows: [DEFAULT] … interface_driver = neutron.agent.linux.interface. BridgeInterfaceDriver 10. Edit the [DEFAULT] section of the L3 agent configuration file located at /etc/neutron/l3_agent.ini on the network node in the following way: [DEFAULT] … interface_driver = neutron.agent.linux.interface. BridgeInterfaceDriver 11. Edit the [securitygroup] section of the ML2 plugin configuration file located at /etc/neutron/plugins/ml2/ml2_conf.ini, as follows: [securitygroup] … firewall_driver = neutron.agent.linux.iptables_firewall. IptablesFirewallDriver 12. Restart the Linux Bridge agent on the Network node by executing service neutron-plugin-linuxbridge-agent restart. How it works… At the start of the Neutron server, it will load the core plugin, which in our case is ML2. As the ML2 plugin allows you to implement physical networks in multiple ways, it uses the mechanism_drivers attribute to load the desired drivers. The preceding steps showed you how to configure a Linux bridge as the mechanism driver for ML2. The Linux bridge mechanism driver needs additional information such as the bridge name and physical interface mapping in order to provide network connectivity. Hence, these mappings are also a part of the mechanism driver configuration. Viewing the virtual interface information for Linux bridge on the compute node Users can create Networks, Subnets, and instances as tenants. However, the underlying physical and virtual network details are hidden from them. This is important because tenants should focus on their business requirements instead of specific implementation details. However, administrators of the cloud platforms that have been built using OpenStack need to understand the physical and virtual networking details. This is required in order to troubleshoot any problems faced by the tenants. In this recipe, we will show you how an administrator can view the virtual interface (VIF) information for an instance that is running on a compute node. Chapter 3 51 Getting ready As this recipe is described from the point of view of an administrator who is troubleshooting a tenant problem, the following information is required: ff The tenant network name ff The VM instance whose VIF information is to be identified How to do it… The following steps will show you how to view the VIF information on a compute node when using the Linux bridge: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, navigate to Admin | System | Instances. On the right-hand side, you will see a list of all the VM instances. 3. Click on the checkbox next to the VM instance whose VIF details you want to see. Using the drop-down menu at the end of the row, select Console, as follows: 4. This should show the VNC console for the selected instance. Log in to the instance and execute the following command: $ ifconfig Exploring Other Network Types in Neutron 52 5. You should see an output similar to the following screen. Note down the IP address, 70.70.70.2 in this case, and the MAC address, (FA:16:3E:3E:F0:EB), as shown in the following screenshot: Chapter 3 53 6. In the left navigation menu, navigate to Project | Admin | Networks. Click on the name of the Network to which the instance belongs. This will display the Network Detail for this Network. Note the Segmentation ID (VLAN ID), which is 1002 in our example: Exploring Other Network Types in Neutron 54 7. You can also see the list of the OpenStack ports for this Network. Our VM instance has an IP address of 70.70.70.2 and there is a Port corresponding to this IP address. Click on the Port Name to view the Port Detail. Note that the MAC and IP addresses match our VM: 8. Pay attention to the ID of the port, especially the first 11 characters: 911185a6-06. 9. Now log in to the compute node of your setup with the appropriate credentials and execute the following command: openstack@compute:~$ brctl show 10. You should see an output as follows: Chapter 3 55 The preceding output shows two important things. The Linux bridge name, brq1e023dc6-7a, is derived from the ID of the Network and the Tap interface name, tap911185a6-06, is derived from the OpenStack Port used for our VM. The Tap interface is the entity that connects the virtual interface on the instance to the Linux bridge. The output of the brctl command also shows that eth1.1002 is the physical interface on the Linux bridge. This notation indicates that the traffic on that Linux bridge will be sent out on the eth1 physical interface with a VLAN tag of 1002. How it works… In the preceding example, we identified the Port ID for the instance, and using this ID, we were able to view the Linux bridge and VLAN information on the compute node. These are usually the foremost steps in identifying the networking problems on a compute node. We also saw that the Linux bridge name is derived from the ID of the OpenStack Network. This implies that when a Linux bridge is used as the mechanism driver, one bridge will be created for every OpenStack Network. The Linux bridge-based configuration on a compute node is pictorially depicted here: Physical Network Compute 1 eth0 eth0 tapXXXXX brqXXXXX eth1.1002Linux Bridge VM1 Compute 2 eth0 eth0 tapYYYYY brqXXXXX eth1.1002 Linux Bridge VM2 There's more… This recipe showed you how to identify the virtual interface on the compute node. On the Network node, there is no change due to the Linux bridge being a mechanism driver. You can refer to the recipe titled Viewing the virtual interface information on the Network node in Chapter 2, Using Open vSwitch for VLAN-Based Networks, to view the virtual interface on a Network node. Exploring Other Network Types in Neutron 56 Configuring Neutron to use a Flat network type A Flat Network is another network type that is supported by the OpenStack Neutron ML2 plugin. Flat Networks are useful when tenant network isolation is not a mandatory requirement. Another scenario for a Flat Network type could be the access to centralized storage for all the instances using a dedicated physical interface. Getting ready To use Flat Networks, the ML2 plugin's type driver and related settings need to be updated. Just as VLAN, the Flat Network type can work with an OVS or Linux bridge mechanism driver. In our example, we will use the Linux bridge mechanism driver. How to do it… The following steps will show you how to configure the Flat Network as the type driver and tenant network type: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure the Flat Network as the type driver and network type: [ml2] . . . type_drivers = flat tenant_network_types = flat 4. In the [ml2_type_flat] section of the file, configure the physical network names with the Flat Networks that are created: [ml2_type_flat] ... flat_networks = physnet1 5. As we used the Linux bridge as the mechanism driver, ensure that the Linux bridge physical interface mappings are configured appropriately. Refer to the first recipe of this chapter. Chapter 3 57 6. Restart the Neutron server and Linux bridge agent on Controller and Network Node of our setup using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service neutron-plugin-linuxbridge- agent restart 7. Steps 2 to 4 have to be repeated for the compute node in our setup. The command to restart the networking services on the compute node is as follows: openstack@controller:~$ sudo service neutron-plugin-linuxbridge- agent restart How it works… At the start of the Neutron server, it will load the core plugin, which in our case is ML2. As the ML2 plugin allows multiple types of networks, it uses type_drivers to see which network drivers to be loaded. Finally, each tenant with a non-administrative role can use only certain network types. The tenant_network_types attribute indicates the network types. A Flat Network is used when the L2 isolation between different tenant networks is not required. In this scenario, all the instances are a part of the same network. However, they can be a part of different subnetworks. Creating a Flat Network using Horizon In the case of a VLAN network type, we saw that the physical interface was separated in logical interfaces such as eth1.1002, eth1.1003, and so on. Moreover, each of these logical interfaces was placed on a Linux bridge corresponding to the OpenStack network. In contrast, Flat Networks are created by placing the physical interfaces directly on the Linux bridge. This means that you can have only one Flat Network per physical interface on the compute node. Due to this reason, only the users with an administrative role are allowed to create a Flat Network. Getting ready In order to create a Flat Network and Subnet, you will need the following information, minimally: ff The Network name ff The Subnet name and IP address range ff The physical network name—this information was configured in the ML2 plugin configuration file Exploring Other Network Types in Neutron 58 How to do it… The following steps will show you how to create a Flat Network using Horizon: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, navigate to Admin | System | Networks. 3. Click on the + Create Network button to display the following Create Network screen for administrators: 4. Enter a name for the Network. Select a Project to assign the Network to a specific tenant. Chapter 3 59 5. Select Flat as Provider Network Type. Once you choose Flat as the Network type, the screen will prompt you to provide more details, as shown in the following screenshot: 6. Enter physnet1 as the value for Physical Network. This was the alias used when configuring the Flat Network as the type driver in the previous recipe. 7. Now click on Create Network. Once the network creation succeeds, the network will show in the list. 8. Note that this mechanism creates a Network without a Subnet. Therefore, the next step is to create a Subnet for this Network. This step can be performed as a normal user associated with the Project to which this Network was added. Exploring Other Network Types in Neutron 60 How it works… The preceding steps showed how a user with an administrative role can create a Flat Network and assign it to a Project. When the tenant creates an instance using this Flat Network, Neutron will map the physical network name to the corresponding mechanism driver. The mechanism driver (Linux bridge or Open vSwitch) will then provision the virtual network. There's more… If your compute node has additional physical interfaces, then it is possible to create additional Flat Networks. To do this, the ML2 configuration file needs to be updated as follows: [ml2_type_flat] ... flat_networks = physnet1,physnet2 ... [linux_bridge] ... physical_interface_mappings = physnet1:eth1,physnet2:eth2 In the Create Network window, the administrative user can choose physnet2 for the second Flat Network. The previous example assumes that the Linux bridge is the mechanism driver but a similar configuration can be done for OVS as well. Creating a Shared Network using Horizon We have already seen situations where only the administrative users can create a Network. For example, only the administrators can create a Flat Network or a Network with a specific VLAN ID. In addition, we have seen that the administrative users can assign a Network to a particular tenant. OpenStack also allows administrators to share a Network among all the tenants. This recipe shows you how to accomplish this. Getting ready In order to create a shared network, you will need the following information: ff The Network name ff The Network type—for this recipe we will use a Flat Network ff The physical Network name—this information was configured in the ML2 plugin configuration file Chapter 3 61 How to do it… The following steps will show you how to create a Flat Network using Horizon: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, navigate to Admin | System | Networks. 3. Click on the + Create Network button to display the following Create Network screen for administrators: 4. Enter a name for the Network. Select a Project to assign the Network to a specific tenant. Exploring Other Network Types in Neutron 62 5. Select Provider Network Type as desired. For this recipe, we will choose Flat networks as Provider Network Type. Once you choose Flat as the Network type, the screen will prompt you to provide more details, as shown in the following screenshot: 6. Enter physnet1 as the value for Physical Network. This was the alias used when configuring the Flat Network as the type driver in the previous recipe. 7. Check the Shared checkbox. 8. Now click on Create Network. Once the network creation has succeeded, the network will show in the list. Chapter 3 63 How it works… A shared network is available to all the tenants independent of the project that was chosen during creation. All the tenants can use the shared network to create VM instances. However, only the administrative user of the project that was chosen during creation can edit or delete the shared Network. Similarly, only the administrative user of the project can add a Subnet to the shared Network. Creating an External Network using Horizon External Networks have a unique role to play with OpenStack Networking. As we have seen, the DHCP server assigns an IP address from the Subnet to each VM instance. These IP addresses are reachable only in the Network because tenant isolation is required. However, many common deployments require that the VM instances have access to outside networks including the Internet and also be reachable from the outside network. The main purpose of the external Networks is to allow the VMs to access networks outside the data center and Internet. They also allow the VMs to be accessed from the outside network. Getting ready As the external Networks have a special behavior associated with them, only users with an administrative role can create them. Besides the standard input such as the Network name and so on, it is important to identify the IP address range to be used for the external Network. This recipe assumes that the L3 agent on the Network node has been configured with the correct bridge information for the External Network access. How to do it… The following steps will show you how to create an external Network using Horizon: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. In the left navigation menu, navigate to Admin | System | Networks. Exploring Other Network Types in Neutron 64 3. Click on the + Create Network button to display the following Create Network screen for administrators: 4. Enter a name for the Network. Select a project to assign the Network to a specific tenant. 5. Select Provider Network Type as desired. For this recipe, we will choose Flat networks as Provider Network Type. Once you choose Flat as the Network type, the screen will prompt you to provide more details, as shown in the following screenshot: Chapter 3 65 6. Enter physnet1 as the value for Physical Network. This was the alias used when configuring the Flat Network as the type driver in the previous recipe. 7. Check the External Network checkbox. 8. Now click on Create Network. Once the network creation has succeeded, the network will show in the list. 9. The next important step is to create a Subnet for the newly created external Network. Exploring Other Network Types in Neutron 66 How it works… As described Earlier, external Networks are used in cases where the VM instances need an outside network access. External Networks can be used directly to attach the instances, and in this case, their behavior is the same as any other Network. However, the main use case for an External Network is in conjunction with the OpenStack router. We will describe this in detail in Chapter 6, Using Routing Services in Neutron. In either situation, an important element needs to be kept in mind. While creating a Subnet for an External Network, the Gateway IP needs to be carefully selected. This is because this IP address is already configured on the physical routers that will provide Internet access. Therefore, we cannot let OpenStack choose a Gateway IP arbitrarily. Setting up a simple web application – an introduction Now that we have seen several scenarios to create Networks and instantiate the VMs, let's take a practical example and apply this knowledge. In this 3-recipe series, you will learn how to use the OpenStack Networking capabilities to create a simple web application. In the first recipe, we will just introduce the components of the web application and desired network connectivity. The next two recipes will show you how to implement this using OpenStack. For simplicity, we will not focus on the exact software running in the VMs. We will just name the VMs as per our requirement. Getting ready A simple web application consists of a database and web application server. While both the database and web server are capable of being executed on the same server, for a good scale and performance, it is better to keep them on different servers. Chapter 3 67 The following image depicts the networking connections between the VMs in our web application. The DB-VM runs the database engine and Web-VM runs the web server: Database DB-VM Web-VM Web Server Web-Internet-Network DB-Access-Network Internet Router Web-Access-Network How to do it… The following steps will show you what kind of OpenStack networks need to be set up in order to accomplish this: 1. We will create a tenant Network for the Web Server to the Database connection called DB-Access-Network. The important thing for this Network will be to limit the number of IP addresses in the Subnet. 2. Next, we will create another tenant network for the Web Server to the Router called Web-Access-Network. Once again, we will limit the number of IP addresses in the Subnet. 3. The last network will be an External Network called Web-Internet-Network to provide Internet access to the Web Server. Exploring Other Network Types in Neutron 68 How it works… The database stores critical information. So, the network access to the DB-VM is available only from the Web-VM using the DB-Access-Network. Moreover, this network will also carry the database queries from the web application server to the database engine. In order to connect to the Internet, the Web Server needs to connect to a local router. The Web-Access-Network provides this connectivity. Finally, the Web-Internet-Network connects the local router to the Internet. Setting up a simple web application – setting up OpenStack Networks The previous recipe defined the different types of networks that we need to create in order to set up our web application. This recipe shows you the specific steps that are required to create the Networks and Subnets. We will refer to the earlier recipes about the Network and Subnet creation instead of going through it step by step. However, this recipe will highlight the important steps that are specific for the web application. Getting ready We will need to create three networks to connect the database, web application server, and Internet. The following steps assume that the Linux bridge is the mechanism driver and VLAN is the type driver configured in Neutron. This is important as the step to create an External Network requires the type of Network. For this recipe, we will use the following information to create the networks: Network name Subnet name Network address range Allocation pools DB-Access- Network DB-Access-Subnet 192.168.20.0/29 192.168.20.2,192.168.20.4 Web-Access- Network Web-Access- Subnet 192.168.30.0/29 192.168.30.2,192.168.30.4 Web-Internet- Network Web-Internet- Subnet 10.10.1.0/24 10.10.1.1,10.10.1.2 We will also need the Gateway IP address for the external Network. Chapter 3 69 How to do it… The following steps will show you how to create the three networks required for the web application: 1. Follow the steps mentioned in the recipe titled Creating a Subnet and Network using Horizon in Chapter 1, Getting Started with OpenStack Networking. Use the Network name, Subnet name, and Network address from the preceding table for DB-Access-Network. 2. Before clicking on the Create button to create the Network, enter 192.168.20.2,192.168.20.4 in the Allocation Pools field, as shown in the following screenshot. Note that there should not be any space after the comma: 3. Click on the Create button to create DB-Access-Network. Exploring Other Network Types in Neutron 70 4. Repeat these steps for Web-Access-Network. Once again, use the information in the preceding table. 5. The next step is to create the external Network called Web-Internet-Network. As this is an external Network, you will need administrative privileges. 6. Follow the steps mentioned in the recipe titled Creating External Networks using Horizon in this chapter. Ensure that the Project is the same as that of the previous two Networks. 7. The next step after the creation of Web-Internet-Network is to add the Subnet. For this, click on the name of the network to view the details. Then, click on + Create Subnet as shown here: Chapter 3 71 8. Enter Subnet Name, Network Address, and Gateway IP for the Subnet, as shown in the following screenshot. Then click on Next: Exploring Other Network Types in Neutron 72 9. In the Subnet Detail section, enter Allocation Pools as shown here and click on Create: Chapter 3 73 These steps should result in three networks being shown when you select Project | Network | Networks, as follows: As mentioned earlier, the External Networks are used in conjunction with the OpenStack routers. After the creation of the three networks, the next step is to create an OpenStack router. We need to associate Web-Access-Subnet as an interface on this router and use Web- Internet-Network as the gateway for this router. This will enable Internet access for the web application server. The sixth chapter will cover the steps in detail. How it works… As a specific tenant creates the web application, he also creates the two tenant networks, namely DB-Access-Network and Web-Access-Network. Access to the Internet is controlled and hence, the administrator creates the external Network called Web-Internet-Network on behalf of the tenant. Thus, the tenant effectively has all the three networks made available to him. Setting up a simple web application – creating instances With all the networks created, the final step is to create the two instances. The main step during an instance creation is to choose the correct Network for each of the VMs. Getting ready You will require the appropriate OS images for the Database VM as well as the Web VM. Exploring Other Network Types in Neutron 74 How to do it… The following steps will show you how to create the two VM instances for the web application: 1. Create an instance called DB-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that DB-Access-Network is chosen in the Selected networks field, as follows: Chapter 3 75 2. Create another instance called Web-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that both DB-Access-Network and Web-Access-Network are chosen in the Selected networks field, as shown in the following screenshot: Exploring Other Network Types in Neutron 76 3. Once the instances are active, the instances list will look as follows: These steps complete the setting up of the web application using two VMs and three OpenStack Networks. How it works… DB-VM and Web-VM will exchange the database-related messages over DB-Access-Network. The web traffic from and to the Internet will travel over Web-Access-Network and Web-Internet-Network. 77 4 Exploring Overlay Networks with Neutron In this chapter, we will cover the following recipes: ff Configuring Neutron to use a VXLAN type driver ff Configuring a VNI Range for VXLAN Networks ff Viewing a VNI assigned to a Neutron Network ff Creating a Network with a specific VNI ff Viewing the virtual interface information on the compute node for VXLAN tunnels ff Viewing the virtual interface information on the network node for VXLAN tunnels ff Configuring Neutron to use a GRE type driver ff Viewing a virtual interface on the compute node for GRE tunnels Introduction The OpenStack Neutron provides you with various ways to implement virtual networks in order to connect the virtual machine instances started by tenants. At a broad level, these network types can be classified in two categories—networks based on VLANs and networks based on overlays or tunnels. In the case of overlay networks, the virtual switch on the Hypervisor encapsulates the data packets from the VM in an IP packet and sends it to the destination Hypervisor. The virtual switch on the destination Hypervisor then de-encapsulates and delivers the data packet to the destination VM instance. The encapsulation process adds an identifier or a tunnel key to mark and identify the packets belonging to different virtual networks. Exploring Overlay Networks with Neutron 78 The OpenStack Neutron provides two ways to implement the overlay or tunnel-based virtual networks, namely VXLAN and GRE. In this chapter, we will see how to implement virtual networks using overlays and the ML2 plugin in Neutron. In order to implement these recipes, we will be using the following OpenStack setup with two nodes, one acting as the controller and network node and another as the compute node: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent eth0 eth0eth1 eth1 Open vSwitch Open vSwitch Management Network Data Network Nova Service Neutron Agent Controller and Network Node Compute Node IP: 10.0.0.1 IP: 10.0.0.2 Configuring Neutron to use a VXLAN type driver Virtual eXtensible LAN (VXLAN) is one of the overlaying drivers supported by the Neutron ML2 plugin. The process of tunneling involves encapsulating the data packets from the VM in a UDP packet. The VXLAN encapsulation process adds a special key called Virtual Network Identifier (VNI) in order to identify the network to which the data packet belongs. The OVS instance on the Hypervisor is responsible for encapsulating the data packets coming out of the VM. The Neutron ML2 plugin provides the OVS instance with all the information that is required to implement a virtual network using VXLAN. For example, the plugin provides information such as the VNI and IP address for the Virtual Tunnel End Point (VTEP) to the OVS instance. The VTEP IPs on the source and destination compute or network node are used while encapsulating the VXLAN packet. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for the OpenStack nodes ff The VTEP IP to be used for the node Chapter 4 79 How to do it… The following steps will show you how to configure Neutron to use a VXLAN type driver: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the controller and network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure VXLAN as type_driver and tenant_ network_type: [ml2] ... type_drivers = vxlan tenant_network_types = vxlan mechanism_drivers = openvswitch 4. In the [ovs] section, set local_ip to the VTEP IP address. OVS uses this IP to carry all the tunneled traffic. In our setup, the VTEP IP for the controller node is 10.0.0.1: [ovs] local_ip = 10.0.0.1 5. In the [agent] section, set tunnel_types to vxlan: [agent] tunnel_types = vxlan 6. Restart the Neutron server and Open vSwitch Agent on the controller and network node of our setup using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service neutron-plugin-openvswitch- agent restart 7. The first five steps have to be repeated for all the compute and network nodes. Remember to update local_ip on the compute nodes with the correct value. Restart the OVS agent on the compute and network nodes: openstack@controller:~$ sudo service neutron-plugin-openvswitch- agent restart Exploring Overlay Networks with Neutron 80 How it works… In this recipe, we configured the Neutron ML2 plugin to create virtual networks with a VXLAN type. We also configured Neutron to use Open vSwitch to implement the virtual network. The Neutron OVS L2 agent is responsible for configuring the local OVS instance on the compute and network nodes. The L2 agent runs as a daemon on the compute and network nodes. This daemon communicates with the Neutron server using Remote Procedure Call (RPC) to get the details of the virtual networks, as shown in the following image: Neutron Server Open vSwitch Controller Compute Node Neutron Agent RPC Messages Local Configuration OVS encapsulates the data packets from the VM using an outer UDP and IP packet. The outer IP packet uses the IP address configured as local_ip in the Neutron configuration file. There's more… Due to the encapsulation of the Layer 2 (L2) data packet in a Layer 3 (L3) packet, the size of the network packet increases. Hence, you may need to adjust the MTU settings on the underlying physical network. Configuring a VNI Range for VXLAN Networks In this recipe, we will see how to configure Neutron with the ML2 plugin in order to use a VXLAN Network Identifier (VNI) range. The ML2 plugin allows the customization of the range of VNI numbers in order to uniquely identify the virtual networks. VXLAN can support up to 16 million unique VNIs. Chapter 4 81 Getting ready For this recipe, you will need the following information: ff The SSH login credentials for the OpenStack controller node ff The VNI range to configure for the VXLAN-based virtual networks How to do it… The following steps will show you how to configure the VNI range for the ML2 plugin: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the controller and network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini In the [ml2_type_vxlan] section of the file, set vni_ranges to the appropriate range list. Multiple ranges can be provided using comma-separated values: [ml2_type_vxlan] vni_ranges = 1001:2000,3001:4000,5001:6000 3. Finally, restart the Neutron server on the controller node using the following command: openstack@controller:~$ sudo service neutron-server restart How it works… In this recipe, we configured the ML2 plugin in order to use the given range of VNIs while creating virtual networks based on VXLAN tunnels. When Neutron receives a request to create a virtual network, it allocates a VNI from this range to create the VXLAN-based virtual network. A range is described with the lower value and higher value separated by :. Viewing a VNI assigned to a Neutron Network In this recipe, we will see how to view the VNI assigned to a VXLAN-based virtual network. Knowing the VNI that is assigned to a virtual network is very useful to troubleshoot communication problems between the VMs or other network services. www.allitebooks.com Exploring Overlay Networks with Neutron 82 Getting ready For this recipe, you will need the following information: ff The SSH login credentials for the node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The following steps will show you how you can view the VNI using the OpenStack CLI: 1. Log in to a node with access to OpenStack. 2. Source your RC file to set up access credentials as an administrator. 3. You can view all the Networks created using the neutron net-list command: 4. Use the neutron net-show command to view further details for any network. In case the Network name is not unique, use its ID instead of the name: Chapter 4 83 We can also achieve the same using Horizon. The steps are as follows: 1. Log in to Horizon as an administrative user. 2. In the left navigation menu, navigate to Admin | Networks. This will list all the available virtual networks as shown in the following screenshot: 3. Click on the Network name for the network that you want to view: 4. This will open the network overview screen for the selected Network, which shows details such as Network Type, Segmentation ID, and so on. How it works… When the Neutron server receives a request to create a virtual network, it automatically allocates a VNI from the configured VNI range to use with the newly created virtual network. In this recipe, we looked at the ways to find the VNI associated with a virtual network. Exploring Overlay Networks with Neutron 84 Creating a Network with a specific VNI In this recipe, we will see how to create a VXLAN-based virtual network using a specific VNI. Normally, Neutron would automatically allocate a VNI for a VXLAN-based virtual network from the range of available VNIs, but there are situations when users need a network with a specific VNI. In such cases, an OpenStack administrator can create a virtual network with a manually assigned VNI. Getting ready For this recipe, you will need to access OpenStack as an administrator. You will also need the following information: ff The SSH login credentials for the node where the Neutron client packages are installed ff An administrative level access to OpenStack ff The Network name ff A VNI for the virtual network How to do it… The following steps will show you how to create a virtual network with a specific VNI using the OpenStack CLI: 1. Log in to a node with access to OpenStack. 2. Source your RC file to set up the access credentials as an administrator. 3. Use the following neutron net-create command to create the virtual network with a specific VNI, for example, using VNI 1010: Chapter 4 85 We can also achieve the same result using a Horizon interface in the following way: 1. Log in to Horizon as an administrative user. 2. Navigate to Admin | Networks. 3. Click on + Create Network and provide the desired Name. Provider Network Type should be set to VXLAN and Segmentation ID should be set to the required VNI: 4. Click on Create Network. This should create the virtual network with the provided VNI. Once it has been created, verify the network details by navigating to the Admin | Network Name link for the newly created virtual network: Exploring Overlay Networks with Neutron 86 5. This will open the Network Overview screen for the selected network, which shows details such as Network Type, Segmentation ID, and so on. How it works… In this recipe, we looked at creating a virtual network with a specific VNI. This procedure overrides the automatic allocation of a VNI for a virtual network and requires administrative access. An unused VNI in the range configured as a part of the VXLAN type driver should be used to create the virtual network. Viewing the virtual interface information on the compute node for VXLAN tunnels When a tenant launches a VM and attaches it to a virtual network, a virtual network interface is created on the compute node, which connects the VM to the OVS instance. In this recipe, we will identify the virtual network interface, which attaches a VM to the OVS instance on the VXLAN network. We will also look at the OVS configuration, which makes the communication between the VM and other members on the virtual network possible. Getting ready For this recipe, you should have the following information: ff The SSH login credentials for the node where the Neutron client packages are installed ff User-level access to OpenStack ff The name of the VM for which you want to identify the virtual interface How to do it… The following steps will show you how to identify an interface connecting a VM to a virtual network: 1. Log in to a node with access to OpenStack. 2. Import the OpenStack RC file to set up the user-level access credentials. Chapter 4 87 3. Use the nova list commands to identify the VM instance, virtual network, and IP associated with it. In this case, the VM is vm1 with an IP of 20.20.20.2 on the Chapter4_VXLAN_with_VNI virtual network, as shown in the following screenshot: 4. Next, we will use the neutron port-list command to find the port ID for the virtual interface associated with this VM, based on the VM IP that we determined in the previous step: 5. Now, we will log in to the compute node and check out the OVS configuration. 6. We can use the ovs-vsctl show command to look at the ports created on the OVS instance. The OVS port name is composed of a part of the Neutron Port ID. In the following listing, qvo2d538755-d5 is the port corresponding to our virtual interface ID of 2d538755-d5f9-49a6-9088-8f07d3e98875. It is connected to the br-int bridge and is configured with tag: 1 to mark all the packets entering this interface with VLAN 1: Exploring Overlay Networks with Neutron 88 7. Next, we will look at the flow configuration on OVS on the br-tun bridge, which sends the packets to the other Hypervisors through the VXLAN tunnels using the ovs-ofctl dump-flow br-tun command: 8. In the highlighted section of the output, we can see that the configuration strips the local VLAN 1 from the packets going out of the compute node and adds a tunnel key (VNI), 0x3f2. The VNI of 0x3f2 is the hexadecimal equivalent of 1010, which was used to create the OpenStack network. Chapter 4 89 How it works… When a VM is launched, OpenStack creates a virtual interface and attaches it to the OVS instance on the Hypervisor through a Linux bridge. For this discussion, we will focus on the OVS connectivity. The OVS instance on the Hypervisor has two bridges, br-int for communication in the Hypervisor and br-tun, which is used to communicate with the other Hypervisors using the VXLAN tunnels. Let's have a look at the following screenshot: OVS Patch link Compute Node VM1 Linux Bridge VLAN TAG VXLAN VNI br-tun NIC Tunnel to other Compute/ Network node br-int The OVS bridge, br-int, uses VLANs to segregate the traffic in the Hypervisors. These VLANs are locally significant to the Hypervisor. Neutron allocates a unique VNI for every virtual network. For any packet leaving the Hypervisor, OVS replaces the VLAN tag with the VNI in the encapsulation header. OVS uses local_ip from the plugin configuration as the source VTEP IP for the VXLAN packet. Viewing the virtual interface information on the network node for VXLAN tunnels The network node hosts network services such as DHCP, DNS, and so on for each virtual network. These services need to communicate with the other members on the virtual network. The network node runs an OVS instance to connect to the virtual network. In this recipe, we will look at the DHCP service running on the Network node and identify the virtual network interface, which connects this service to the virtual network. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for the controller and network node Exploring Overlay Networks with Neutron 90 How to do it… The following steps will show you how to identify an interface connecting a network service to the virtual network. In this recipe, we will look at the network interface for the DHCP service: 1. Log in to a node with access to OpenStack. 2. Next, we will find the DHCP server process that is associated with our virtual network. OpenStack uses dnsmasq to provide the following DNS and DHCP services on the virtual network: 3. From the previous step, we find that the dnsmasq process is bound to a virtual interface, tap32a8ae83-27. We can now look at the OVS configuration in order to identify the virtual interface port: 4. From the OVS configuration, we can see that the virtual network interface, tap32a8ae83-27, is connected to br-int and configured with tag: 2 to tag all the incoming packets from the DHCP server with VLAN 2. Chapter 4 91 5. Next, we will look at the flow configuration on OVS on the br-tun bridge, which sends the packets to the other Hypervisors through the VXLAN tunnels using the ovs-ofctl dump-flow br-tun command: 6. From the flow configuration, we can see that when the packet is sent out through the VXLAN tunnel, OVS strips the local VLAN tag and instead uses a tunnel ID to identify the virtual network. Exploring Overlay Networks with Neutron 92 How it works… Network services such as the DHCP server are started for each virtual network as soon as the first VM that is attached to the virtual network is launched. To provide the DHCP service, the DHCP agent node attaches a dnsmasq process to a virtual network interface attached to an OVS instance running on the network node. The OVS instance uses two bridges, br-int and br-tun, as described in the previous recipe, to connect the network service to the virtual network. Configuring Neutron to use a GRE type driver As described earlier, tunneled networks can also be implemented using the Generic Routing Encapsulation (GRE) protocol. GRE is a general-purpose point-to-point encapsulation protocol. The GRE header contains a 32-bit key which is used to identify a flow or virtual network in a tunnel. This recipe shows you how to configure the OpenStack Neutron in order to use GRE for virtual networking. Getting ready For this recipe, we will need the following information: ff An SSH-based access to the OpenStack controller node ff The IP address for the tunnel endpoint ff A range of tunnel IDs How to do it… The following steps will show you how to configure the GRE type driver for the ML2 plugin: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the controller and network node. 2. Open the Neutron ML2 plugin configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 3. In the [ml2] section of the file, configure GRE as the type driver and tenant network type: [ml2] ... type_drivers = gre Chapter 4 93 tenant_network_types = gre mechanism_drivers = openvswitch 4. In the [ml2_type_gre] section, update tunnel_id_range to the range of the tunnel IDs that can be used for the virtual networks: [ml2_type_gre] tunnel_id_ranges = 1:1000 5. In the [ovs] section, set local_ip to the IP address of the network card that you want to use in order to carry the tenant data traffic: [ovs] local_ip = 10.0.0.1 6. In the [agent] section, set tunnel_types to gre: [agent] tunnel_types = gre 7. Restart the Neutron and Open vSwitch Agent on the controller and network node of our setup using the following commands: openstack@controller:~$ sudo service neutron-server restart openstack@controller:~$ sudo service openvswitch-switch restart openstack@controller:~$ sudo service neutron-plugin-openvswitch- agent restart 8. Repeat the first six steps for the compute node. 9. Restart the Neutron OVS L2 agent on the compute node: openstack@controller:~$ sudo service neutron-plugin-openvswitch- agent restart How it works… In this recipe, we configured the ML2 plugin to create virtual networks with the GRE tunnels. The Neutron OVS L2 agent runs as a daemon on each Compute and Network node and is responsible for configuring the OVS instance for the GRE-based virtual network on the local Hypervisor. GRE is a general-purpose encapsulation protocol; in comparison, VXLAN was designed keeping in mind the requirements of virtual networking and multitenancy. Exploring Overlay Networks with Neutron 94 Viewing a virtual interface on the compute node for GRE tunnels This recipe shows you how to identify the virtual network interface used by a VM for a GRE- based virtual network. Viewing the network interface can be useful to troubleshoot the connectivity problems between the VMs and network services. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for the node where the Neutron client packages are installed ff User-level access to OpenStack ff The name of the VM for which you want to identify the virtual interface How to do it… 1. Log in to a node with access to OpenStack. 2. Import the OpenStack RC file to set up the user-level access credentials. 3. Use the nova list commands to identify the VM instance, virtual network, and IP associated with it. In this case, the VM is vm1 with an IP of 20.20.20.2 on the Chapter4_GRE virtual network: Chapter 4 95 4. Next, we will use the neutron port-list command to find the port ID for the virtual interface that is associated with this VM, based on the VM IP that we determined in the previous step: 5. We will now log in to the compute node and check out the OVS configuration. 6. We can use the ovs-vsctl show command to look at the ports created on the OVS instance. The OVS instance has two bridges, br-int to communicate with the VMs on this Hypervisor and br-tun to send the tunnel traffic to the other Hypervisors. In the following listing, qvod0edf043-59 is the port corresponding to our virtual interface ID of d0edf043-5928-4a99-aaba-c24248238aed and is configured with tag: 1 in order to mark all the packets entering this interface with VLAN 1: Exploring Overlay Networks with Neutron 96 7. Next, we will look at the flow configuration on OVS on the br-tun bridge, which sends the packets to the other Hypervisors through the VXLAN tunnels using the ovs-ofctl dump-flow br-tun command: 8. In the highlighted section of the output, we can see that the configuration strips the local VLAN 1 from the packets going out of the compute node and adds a tunnel key, 0x1. The GRE tunnel key 1 was allocated by Neutron for the Chapter4_GRE network. Chapter 4 97 How it works… The OVS configuration for the GRE-based virtual network is similar to those for the VXLAN networks. The OVS instance on the Hypervisor has two bridges, br-int for communication in the Hypervisor and br-tun, which is used to communicate with the other Hypervisors. The OVS bridge, br-int, uses VLANs to segregate the traffic in the Hypervisors. These VLANs are locally significant to the Hypervisor. OVS connects to the other Hypervisors using br-tun using GRE tunnels. It replaces the VLAN for any packet destined to a different Hypervisor with a GRE header, which contains a unique tunnel key that is allocated by the Neutron server for each virtual network. 99 Managing IP Addresses in Neutron We have seen that Subnet is a part of the core functionality in OpenStack Networking. The Subnet entity drives the IP address assignment and DHCP servers for the virtual machine instances. In this chapter, we will share the following recipes that will cover the IP address management capabilities in Neutron: ff Creating an instance with a specific IP address ff Configuring multiple IP addresses for a virtual interface ff Creating a redundant DHCP server per OpenStack Network ff Starting the DHCP server on a specific network node ff Increasing the number of IP addresses in a Network using the Horizon dashboard 5 Managing IP Addresses in Neutron 100 Introduction The DHCP servers and IP address management go hand in hand. The DHCP servers run on the network nodes in OpenStack. In order to implement the recipes, you will need an OpenStack setup, as shown here: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth0 eth1 Open vSwitch Management Network Data Network Nova Service Neutron Agent Neutron DHCP Agent Neutron OVS Agent Open vSwitch Open vSwitch eth0 eth0eth1 eth1 Controller and Network Node Compute Node Network Node This setup has one Compute Node, one dedicated Network Node, and one node for the controller and networking services. Some of the recipes require redundant network nodes in order to run redundant DHCP services. Therefore, a single all-in-one setup will not be sufficient. As mentioned earlier, a Subnet is part of the core services in the OpenStack Neutron. All the recipes of this chapter assume that ML2 is the core plugin in the Neutron configuration file. The recipes also assume that OVS is configured as the mechanism driver and VLAN is configured as the type driver as a part of the ML2 configuration. Creating an instance with a specific IP address The VM instances are typically used to host IT applications. Some applications require that a particular VM server should have a specific, fixed IP address. When DHCP is enabled, the virtual machine gets an IP address dynamically. This recipe shows you how we can assign a specific IP address to an instance. Chapter 5 101 Getting ready A VM with a specific IP address can only be created using the OpenStack CLI. It involves a Port creation followed by an instance creation. As a prerequisite, ensure that a Network is created with the following attributes: ff Network name: Cookbook-Network-5 ff Subnet name: Cookbook-Subnet-5 ff Subnet IP address range: 20.20.20.0/28 How to do it… The following steps will show you how to create a VM instance with a specific IP address: 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. The command to create a Port is neutron port-create, as follows: openstack@controller:~$ neutron port-create \ --name PortWithSpecificIP \ --fixed-ip subnet_id=f03d74b1-fc69-49c1-bda798c53ecbd183,ip_ address=20.20.20.5 Cookbook-Network-5 4. In the preceding command, we used the UUID of the Subnet and assigned 20.20.20.5 as the IP address for the Port. You can confirm that this port uses the specific IP address using the neutron port-list command: 5. The CLI command to create an instance is nova boot. This command supports an argument called --nic that allows us to specify a Port ID that we want to associate with the instance: openstack@controller:~$ nova boot --flavor m1.tiny \ --image cirros-0.3.3-x86_64 \ --nic port-id=9badd396-e95b-4c80-b6d2-c0140c186f91 CLIPortVM 6. Once the nova boot command is successful, the instance will also be visible in the Horizon dashboard. Managing IP Addresses in Neutron 102 7. Log in to the Horizon dashboard and navigate to Project | Network | Network Topology. In the Network Topology, move the mouse pointer over the icon representing the instance and click on Open Console, as shown in the following screenshot: 8. In the resulting window, log in to the instance. In our example, we will be using the CirrOS default username and password for the login. Chapter 5 103 9. At the shell prompt of the instance, type ifconfig eth0. This command will show the virtual interface for this instance. You can see that the IP address for this virtual interface (eth0) matches that of the Port that we used in the nova boot command: These steps showed you how to create a VM instance with a fixed IP address. How it works… When a Network is created, a DHCP port is automatically created. However, the ports associated with the VM instances are created as and when the instances are created using Horizon, but the Neutron CLI allows Ports to be created independent of an instance. The CLI also allows users to boot an instance using an existing port. In this recipe, we first created a Port and specified the IP address that it will use. This IP address must be in the range of the Subnet and must be unassigned. Once the Port is successfully created, we use the Port ID to boot an instance using the Nova CLI. This step ensures that the instance uses the specific IP address for the virtual interface. Managing IP Addresses in Neutron 104 Configuring multiple IP addresses for a virtual interface IP aliasing is a concept where multiple IP addresses are assigned to the same physical network interface. IP aliasing is useful in several scenarios. When multiple small applications running on different servers need to be consolidated into a single large server, the individual IP address for each application needs to be mapped to the same physical interface. As the physical servers get virtualized, there is a need to support IP aliasing for the virtual machine instances also. In Linux, IP aliasing is accomplished by creating subinterfaces on a real interface. In this recipe, we will see how multiple IP addresses can be allotted to a single virtual interface. Getting ready The different IP addresses for the same virtual interface can be a part of the same Subnet or two different Subnets. However, OpenStack does not allow a virtual interface to be associated with two different networks. Therefore, the different Subnets should be a part of the same OpenStack Network. How to do it… The following steps will show you how to configure multiple IP addresses for a single virtual interface: 1. Follow the steps mentioned in the recipe titled Creating a Subnet and Network using Horizon in Chapter 1, Getting Started with OpenStack Networking. Use Cookbook- Network-5 as the Network name, Cookbook-Subnet-1 as the Subnet name, and 20.20.20.0/28 as the Network address range: Chapter 5 105 2. Open the drop-down menu under the Actions column and click on Add Subnet: 3. Using a Subnet name as Cookbook-Subnet-2 and a Network address range of 30.30.30.0/28, create the second Subnet on the same network: 4. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 5. Source the shell RC file to initialize the environment variables required for the CLI commands. Managing IP Addresses in Neutron 106 6. Create a Port using the neutron port-create CLI, as follows: 7. In the preceding command, we specified two fixed IP addresses for the same port (hence, the same virtual interface). Also note that the neutron port-create command takes only one Network name as the parameter. 8. As shown in the previous recipe, create a VM instance using the nova boot command and specify the previous Port, as follows: openstack@controller:~$ nova boot --flavor m1.tiny \ --image cirros-0.3.3-x86_64 \ --nic port-id=9b24a25b-1bb1-4909-8a13-9a829944649e CLIPortVM 9. Once the VM boots up, you will notice that one of the IP addresses is assigned to the virtual interface. This is the limitation when using a DHCP server. The second IP address needs to be manually assigned to a subinterface on the same virtual interface. How it works… A single OpenStack Port maps to a single virtual interface in the VM instance. While the Port has multiple IP addresses, when the instance is booted, only one virtual interface is created and Neutron automatically picks one of the IP addresses and assigns it to the virtual interface. The second IP address has to be manually assigned to a subinterface using the ifconfig command. The additional benefit of this recipe is that the allocated IP address is stored on the DHCP server and will not be assigned to any other VM instance. Chapter 5 107 Creating a redundant DHCP server per OpenStack Network The DHCP server plays a critical role in the IP address management and initial network connectivity for a VM instance. The DHCP server is enabled via an agent on the network node. As it is a critical component, it is a good idea to have a redundant DHCP server per OpenStack Network. This recipe shows you how to configure Neutron to start more than one DHCP agent for each OpenStack Network. Getting ready In order to create more than one DHCP agent for each OpenStack Network, we will need to update a setting in the Neutron configuration file. How to do it… The following steps will show you how to configure multiple DHCP agents per OpenStack Network: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Open the Neutron configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf 3. In the [DEFAULT] section of the file, configure the number of DHCP agents per Network: [ml2] . . . dhcp_agents_per_network = 2 4. The previous step configured two DHCP agents per OpenStack network. How it works… When the first VM instance is created on a Network, Neutron creates the DHCP agents for the network. The number of the DHCP servers for a Network is based on the configuration file setting. If more than one DHCP agent is required for every Network, then Neutron will create the DHCP agents across the various Network nodes available in the OpenStack setup. Managing IP Addresses in Neutron 108 Starting the DHCP server on a specific network node OpenStack allows multiple Network nodes in a setup. By default, only one DHCP agent (or server) is associated per Network. In case there are multiple Network nodes, the Neutron server automatically schedules a DHCP agent for each Network. However, there could be situations when a particular Network requires a DHCP agent on a specific Network node. For example, for a Network with critical VMs, the user may request for the DHCP server to run on a more responsive Network node. Getting ready We will use the Horizon dashboard to show you how to ensure that the DHCP server for a given Network is started on a specific network node. This recipe requires a setup with two Network nodes as shown in the beginning of this chapter. We will use the Network named Cookbook-Network-5 for this recipe. How to do it… The following steps will show you how to add an additional DHCP agent to an existing Network: 1. Log in to the OpenStack Horizon dashboard using a user ID with an administrative role. 2. Navigate to Admin | System | Network to view the list of Networks: 3. As no instances have been created, you will notice that the number of DHCP agents is 0. Chapter 5 109 4. Click on the name of the Network—Cookbook-Network-5 in this case. 5. The Network Detail page includes information such as Subnets, Ports, and DHCP Agents, as shown in the following screenshot: 6. Click on the Add DHCP Agent button and select the Host that will run the DHCP agent. For this recipe, we will choose the networknode of our setup in order to run the DHCP agent: Managing IP Addresses in Neutron 110 7. Once the DHCP agent is successfully added to the Network, you will notice that a new DHCP port (representing the DHCP server) has now been created for the Network: The preceding steps showed you how to start the DHCP agent on a specific network node. How it works… The OpenStack Neutron automatically chooses a DHCP agent in order to create a DHCP port. This step happens internally when the first VM instance is created on a Network. The DHCP agent on the first registered network node is selected. The DHCP agent then proceeds to create the DHCP server (dnsmasq) as part of the DHCP Port creation. This recipe shows you how administrative users can force the DHCP agent on a specific network node to be used for a Network. There's more… This selection of a specific network node to run the DHCP server can also be performed using the Neutron CLI. The Neutron CLI command, neutron dhcp-agent-network-add, can be used for this purpose. Chapter 5 111 Increasing the number of IP addresses in a Network using the Horizon dashboard We have seen that, as a part of the Network creation, the user also creates a Subnet, which is essentially an IP address range. Consider a situation where a user creates a Subnet with a set of IP addresses. Once all the IP addresses of this Subnet are assigned to instances, any new instance created will not get an appropriate network connectivity. To increase the IP addresses in the same Network, the user will have to create another Subnet on the same Network. This recipe will show you how to do this. Getting ready To create another Subnet, the inputs that you will need are as follows: ff A range of IP addresses ff A name for the Subnet How to do it… The following steps will show you how to add another Subnet to a Network: 1. Log in to the OpenStack Horizon dashboard using the appropriate credentials. 2. In the left navigation menu, click on Project, then Network | Networks. 3. Now, click on the drop-down icon (triangle) next to the Edit Network button for the Network to which you want to add another Subnet: Managing IP Addresses in Neutron 112 4. Now, clicking on the Add Subnet option will show you a window, as follows: 5. Enter the Subnet Name and Network Address (IP range in a CIDR format) and click on Next. Then click on Create. Chapter 5 113 6. You can see that the Network now has a second Subnet (IP range) associated with it. This recipe showed you how to add multiple Subnets to a particular Network. This flexibility to add more IP addresses helps in cases where more VMs are created than initially planned. How it works… Neutron supports the multiple Subnets to be associated with each Network but such Subnets cannot have overlapping IP addresses. Using multiple Subnets, more instances can be part of a single Network. However, communication between the instances is limited to the instances that have an IP address in the same Subnet. In order for the instances across a Subnet to communicate, a Neutron router will be required. Using the Horizon dashboard, users can choose a Network only during the instance creation. Neutron will automatically assign the instance to the first Subnet in the Network. CLI allows users to force an instance onto a particular Subnet. 115 6 Using Routing Services in Neutron The first five chapters focused on the OpenStack Networking capabilities available as part of a Network. Now, we will delve deeper into OpenStack Networking and discuss the following recipes related to IP Routing: ff Configuring Neutron for Routing services ff Creating a Router using the Horizon dashboard and Neutron CLI ff Enabling instances on different Networks to communicate ff Allowing the Virtual Machine instances to access the Internet ff Providing access to a virtual machine from an external Network or the Internet using Horizon ff Creating and deleting a floating IP address using the Neutron CLI ff Associating a floating IP address to a virtual machine using the Neutron CLI Introduction We saw that the Network provides tenants with an isolated Layer 2 domain in which virtual machines can communicate with one another. However, in real-life deployment, you will find many scenarios where two or more networks need to communicate with each other. This connectivity between virtual machines across two different Layer 2 Networks is accomplished using a Router. The Router object in OpenStack provides VMs with Layer 3-based IP Routing services. Using Routing Services in Neutron 116 The OpenStack default Router runs on the Network nodes in OpenStack. In order to implement the recipes, you will need an OpenStack setup as described in the following figure: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex This setup has two compute nodes and one node for the controller and networking services. For this chapter, you can also use a setup with just one compute node. Compared to the earlier chapters, this setup has an additional Network called External Network. This Network allows the Network node to carry traffic from the VM instances to an external Network and vice versa. Configuring Neutron for Routing services As mentioned earlier, the OpenStack Networking functionalities can be classified as core and service. Routing or L3 networking is part of the service functionality and Neutron needs to be configured in order to support it. Getting ready We will configure the Neutron server as well as the Neutron L3 agent in order to enable the Routing functionality in OpenStack. For this chapter, we will assume that the Neutron ML2 plugin has been configured to use VLAN as the type driver and Open vSwitch as the mechanism driver. How to do it… The following steps will show you how to configure Neutron to provide Routing services in OpenStack: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network Node. Chapter 6 117 2. Open the neutron.conf configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf 3. In the [DEFAULT] section of the file, configure router as the service plugin for Neutron: [DEFAULT] ... service_plugins = router 4. Open the l3_agent.ini file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/l3_agent.ini 5. As we are using Open vSwitch as the mechanism driver, in the [DEFAULT] section of the file, we will configure interface_driver accordingly: [DEFAULT] ... interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver 6. The final step is to configure external_network_bridge in the l3_agent.ini file: [DEFAULT] ... external_network_bridge = br-ex How it works… Once router is added to the list of service plugins in the Neutron configuration file, the support for Router is enabled in OpenStack. You will see that the Horizon dashboard now has an option called Router when you navigate to Project | Network. The external Network bridge name is important when using the Open vSwitch mechanism driver. For a Linux bridge, the corresponding bridge is created automatically. This bridge is bound to the Ethernet interface that allows the traffic to be routed to networks that are external to OpenStack. Using Routing Services in Neutron 118 Creating a Router using the Horizon dashboard and Neutron CLI Once OpenStack is configured in order to support the Routing services, the next step is to create a Router. Similar to a Network, Subnet, and Port, a Router is a logical entity that is used by Neutron to provide connectivity between two different OpenStack Networks or Subnets. In this recipe, we will see how to create a Router using the Horizon dashboard and Neutron CLI. Getting ready The only information required to create a Router is the name of the Router. How to do it… The following steps will show you how to create a Router in OpenStack: 1. Log in to the OpenStack Horizon dashboard using the appropriate credentials. 2. In the left navigation menu, navigate to Projects | Network | Router. 3. Now click on + Create Router. In the resulting screen, enter the Router Name and click on the Create Router button: Chapter 6 119 4. The newly created Router should now appear in the Routers table: 5. We will now create another Router named Cookbook-Router-2 using the Neutron CLI. The command to create a Router using CLI is neutron router-create. If the command was successful, it should show you the following output: 6. You can delete this Router using the neutron router-delete command by specifying the Router name. How it works… As mentioned earlier, an OpenStack Router is the entity that represents Layer 3 IP Routing in OpenStack. A Router needs to be associated with subnetworks in order to provide a Routing functionality between these subnetworks. Using Routing Services in Neutron 120 OpenStack supports IP Routing using the Linux namespaces and iptables on the network node. This is a centralized model for Routing where the VM traffic that needs to go out of a Network is first sent to the network node and then the OpenStack Router on the network node routes it further. There's more… In the newer releases, OpenStack supports Distributed Virtual Routing (DVR) that allows each Hypervisor to support routing for a better scale and performance. Enabling instances on different Networks to communicate In order to make use of the OpenStack IP Routing capabilities, a Router needs to be associated with the desired subnetworks. Once this step is completed, the data traffic from one VM in a Subnet will be able to communicate with another VM in another Subnet. This recipe shows you how to associate subnetworks to a Router. While VMs will be able to communicate with one another, the VMs will not yet have access to the Internet. Getting ready First, we will create two Networks and a Router and then we will associate the two Networks (or the corresponding Subnet) to the Router. We will also create one VM in each of the Networks. For this recipe, we will use the following information to create the Networks: Network Name Subnet Name Network Address Range VM Instance Cookbook-Network-1 Cookbook-Subnet-1 20.20.20.0/28 Network-1-VM Cookbook-Network-2 Cookbook-Subnet-2 30.30.30.0/28 Network-2-VM How to do it… The following steps will show you how to create two Networks and one Router and then associate them together: 1. Follow the steps mentioned in the recipe titled Creating a Subnet and Network using the Horizon in Chapter 1, Getting Started with OpenStack Networking. Use the Network Name, Subnet Name, and Network Address from the preceding table for Cookbook-Network-1. Chapter 6 121 2. Repeat the previous steps for Cookbook-Network-2. Once again, use the information in the table. You should see a list of Networks as follows: 3. Create an instance called Network-1-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that Cookbook-Network-1 is chosen in the Selected networks field. 4. Create an instance called Network-2-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that Cookbook-Network-2 is chosen in the Selected networks field. 5. At this stage, you should see a list of instances, as follows: 6. Note that the two instances cannot ping each other as yet. 7. The next step is to create a Router called Cookbook-Router-1. Follow the steps mentioned in the recipe titled Creating a Router using the Horizon dashboard and Neutron CLI earlier in this chapter. Using Routing Services in Neutron 122 8. Click on the name of the Router to view the details of the Router: 9. To associate the Networks to the Router, click on + Add Interface: 10. Select Cookbook-Network-1 (and its associated Subnet) and then click on Add Interface. Chapter 6 123 11. Repeat this step to add Cookbook-Network-2 as the second interface in the Router. 12. Navigate to Project | Networks | Network Topology. Here, you will see that the two Networks are now connected via the Router: 13. At this stage, both the Networks are connected to each other via the Router. You can now execute the ping command from one VM to another. You will notice that the ping command succeeds. Note that you may have to check the security group settings in order to ensure that ICMP (ping) traffic is allowed. How it works… When a VM is created on a Network, we know that OpenStack creates a namespace with a prefix of qdhcp. Similarly, when the first interface is added to the Router, Neutron (using the L3 agent) creates a namespace with a prefix of qrouter. You can view these namespaces using the ip netns command on the Network node. The qrouter namespace represents the OpenStack Router. You can run the ifconfig command in the namespace and see that the Router has one interface on each of the Networks. The IP address assigned to these Router interfaces will be added as the default gateway on the respective VMs. This is how the Router provides an IP Routing service between the two Networks. Using Routing Services in Neutron 124 There's more… In case you use VXLAN as the overlay Network technology, then ensure that the TCP Maximum Transmission Unit (MTU) settings are configured appropriately on the DHCP server (dnsmasq). This will ensure that the VM instances have enough space for the Network protocols to carry all the header information. Without a proper MTU configuration, you may find that the ping commands between the VMs might fail. Another useful thing to note is that Routers can be used to route traffic between two Subnetworks in the same Network as well. Allowing the Virtual Machine instances to access the Internet Routers allow VMs across different Networks to communicate with each other. They also play another crucial role. Routers allow VMs to communicate with entities outside the OpenStack Network such as the Internet. In Chapter 3, Exploring Other Network Types in Neutron, we introduced the concept of an external Network. External Networks, when used with a Router, allow the VM instances to access the Internet. Getting ready In order to allow VMs to access the Internet, we will need two types of Networks. A tenant Network will be used to create an instance and associate it to a Router. Next, the Router needs to be connected to an External Network that has access to the Internet. Note that an OpenStack user with the administrator's privilege can create the External Network. This recipe assumes that the OpenStack administrator has followed the steps mentioned in the recipe titled Creating an External Networks using Horizon in Chapter 3, Exploring Other Network Types in Neutron and created an External Network called External-Network. How to do it… The following steps will show you how to allow VMs to access the Internet: 1. Follow the steps mentioned in the recipe titled Creating a Subnet and Network using the Horizon in Chapter 1, Getting Started with OpenStack Networking to create a Network named Cookbook-Network-1 and a Subnet IP range of 20.20.20.0/24: Chapter 6 125 2. Create an instance called Network-1-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that Cookbook-Network-1 is chosen in the Selected networks field. 3. The next step is to create a Router called Cookbook-Router-1. Follow the steps mentioned in the recipe titled Creating a Router using the Horizon dashboard and Neutron CLI earlier in this chapter. 4. As shown in the recipe titled Enabling instances on different Networks to communicate in this chapter, add Cookbook-Network-1 as an interface to Cookbook-Router-1. 5. Navigate to Project | Network | Routers. Click on Set Gateway under the actions column for the Router named Cookbook-Router-1: Using Routing Services in Neutron 126 6. In the Set Gateway window, select the external Network that the administrator has created for you. Click on the Set Gateway button. 7. At this stage, the VM instance, Network-1-VM, should be able to communicate with the IP addresses on the external Network Subnet. How it works… As discussed in Chapter 3, Exploring Other Network Types in Neutron, the external network is critical in order to provide you with Internet access. In the External Network, the Subnet IP range plays a crucial role. We know that a Router connects two Networks. When a Network is added as an interface to a Router, a Router port is created. The gateway IP addresses from the Network are then assigned to this Router port. Similarly, for the second Network, another Router port is created and associated with the gateway IP address of that Network. The OpenStack Router is implemented using the Linux namespaces. In the case of Internet access, a Router port is created using the External Network and is assigned an IP address from the corresponding Subnet. Neutron uses iptables to configure the SNAT rules for all the traffic trying to access the external network. The Router is then able to provide IP Routing between a VM on a tenant Network to a port on the external Network. This ensures that the VM traffic can reach the Internet while the VMs are not directly accessible from the Internet. There's more… This recipe showed you how to perform a Set Gateway operation using the Horizon dashboard. The same can also be accomplished using the OpenStack Neutron CLI. The command to set the gateway using an external Network is neutron router-gateway-set. A user can also clear the gateway using Horizon and the Neutron CLI (neutron router- gateway-clear). Providing access to a Virtual Machine from an external Network or the Internet using Horizon As mentioned in the previous recipe, Routers along with an external network can be used to provide VMs with access to the Internet. With the External Network set as a gateway on the Router, the VMs can access the Internet from their private IP address. However, the VM cannot be reached from the Internet using the private IP address. Chapter 6 127 What happens if you are running a web server in your VM? It may be important to allow the users to access the web server from the Internet. OpenStack extends the concept of the Router and external Network and supports the floating IP addresses that can be used to connect to a VM from the Internet. Getting ready Similar to the previous recipe, we will need two Networks and a Router to enable Internet access to the VM. This recipe also assumes that the OpenStack administrator has followed the steps mentioned in the recipe titled Creating an External Networks using Horizon in Chapter 3, Exploring Other Network Types in Neutron and created an External Network called External-Network. How to do it… The following steps will show you how to allow a VM to be accessible from the Internet: 1. Follow the steps mentioned in the recipe titled Creating a Subnet and Network using Horizon in Chapter 1, Getting Started with OpenStack Networking to create a Network named Cookbook-Network-1 and a Subnet IP range of 20.20.20.0/24: 2. The next step is to create a Router called Cookbook-Router-1. Follow the steps mentioned in the recipe titled Creating a Router using the Horizon dashboard and Neutron CLI earlier in this chapter. 3. As shown in the recipe titled Enabling instances on different Networks to communicate in this chapter, add Cookbook-Network-1 as an interface to Cookbook-Router-1. 4. As shown in the previous recipe, set the gateway on Cookbook-Router-1 using the External-Network. 5. Create an instance called Network-1-VM by following the steps of the recipe titled Associating a Network to an instance using Horizon in Chapter 1, Getting Started with OpenStack Networking. Ensure that Cookbook-Network-1 is chosen in the Selected networks field. Using Routing Services in Neutron 128 6. In the Actions column for the instance, select the Associate Floating IP action, as shown in the following screenshot: 7. In the resulting window, you will need to select a floating IP Address. If you did not allocate any floating IP address earlier, the window will say No floating IP addresses allocated. Click on the + symbol, as follows: Chapter 6 129 8. Once you click on the + symbol, the Allocate Floating IP screen will be displayed. This screen will let you choose the appropriate external Network. Select Pool and click on Allocate IP: 9. You will be taken back to the Manage Floating IP Associations screen once again. This time, an IP address will have been selected for the instance. Click on the Associate button to complete the assignment of the floating IP to an instance: Note that if your instance has multiple virtual network interfaces, you will be able to choose a floating IP address for each virtual interface. Using Routing Services in Neutron 130 How it works… We have seen that access to the Internet requires an external network. The Router uses an IP address from the Subnet of the external Network in order to provide an instance with Internet access. In the same fashion, when we need to access a VM from the Internet, we need an IP address from the External Network Subnet. This mechanism is referred to as assigning a floating IP address to the VM. The Manage Floating IP Associations screen shown in this recipe results in an additional IP address being assigned to the VM. Using this additional IP address, we can access the VM from the Internet. Creating and deleting a floating IP address using the Neutron CLI As seen in the previous recipe, we first selected an instance in order to create and associate a floating IP. For better planning, it may be required to create a set of floating IP addresses even if instances have not yet been created. We will now show you how a floating IP address can be created and deleted using the Neutron CLI. Getting ready As we have seen, floating IP addresses are chosen automatically from the specified external Network. Therefore, you will need the following information to create a Network using CLI: ff The name of the external Network—in our case, it will be External-Network ff The login credentials for SSH to a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands, as follows: openstack@controller:~$ source author_openrc.sh Chapter 6 131 3. The command to create a floating IP address is neutron floatingip-create, as shown here: 4. As you can see, the floating IP address of 192.168.57.8 was automatically selected by Neutron. 5. You can view all the floating IP addresses currently in the system by using the neutron floatingip-list command: 6. You can delete a floating IP address using the neutron floatingip-delete command by specifying the ID of the floating IP, as follows: We have now seen the different CLI commands related to the floating IP addresses. Using Routing Services in Neutron 132 How it works… When the neutron floatingip-create command is executed, Neutron takes the Subnet information of the specified External Network and automatically selects an IP address to be used as a floating IP address for an instance. This IP address can then be associated with an instance using the Horizon dashboard as shown in the previous recipe. This IP address can also be used with the Neutron CLI. There's more… Users can also create independent floating IP addresses using the Horizon GUI. This is done by selecting Project | Access & Security | Floating IPs on the GUI. Associating a floating IP address to a virtual machine using the Neutron CLI We have seen that the Neutron CLI allows users to create a floating IP address independent of the existence of an instance. We will now show you how to associate a floating IP address to an instance using CLI. Getting ready For this recipe, you will need to know the virtual interface or the Port of the instance to which you need to bind the floating IP address. You will also need the following information: ff The login credentials for SSH to a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… 1. Using the appropriate credentials, SSH into the OpenStack node where the Neutron client software packages are installed. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. Chapter 6 133 3. We will first execute the neutron port-list command to identify the ID of the virtual interface port to which the floating IP will be assigned. In our case, we will need to look for a port with an IP address of 20.20.20.9 (which is an internal IP address): 4. The next step is to identify the ID of the floating IP address. We will use the neutron floatingip-list command for this. Note that the selected floating IP does not have any fixed IP address assigned: 5. The command to associate a floating IP address to the virtual interface of an instance is neutron floatingip-associate, as follows: 6. Once the command is successful, you can execute the neutron floatingip- list command again and verify that the floating IP address has been associated to a fixed (internal) IP address: The preceding steps showed you how to associate a floating IP address to an instance using the Neutron CLI. Using Routing Services in Neutron 134 How it works… As discussed earlier, a floating IP address is an IP address from the Subnet of the External Network. A VM instance normally has a fixed (internal) IP address that is a part of the Subnet of the tenant Network. The CLI commands seen in this recipe allow us to associate and disassociate these two IP addresses (fixed and floating) from one another. There's more… You can use the neutron floatingip-disassociate command to remove the fixed IP to a floating IP mapping. 135 7 Using Neutron Security and Firewall Services In this chapter, we will look at the following recipes to create and manage the security rules with Neutron Security Groups and Firewalls: ff Creating a security group using Horizon ff Configuring the security group rules using Horizon ff Creating a security group using CLI ff Configuring the security group rules using CLI ff Securing the traffic between instances on the same Network ff Creating the security group rules to allow web traffic ff Configuring Neutron for the Firewall service ff Creating the Firewall rules ff Creating the Firewall policies ff Creating a Firewall ff Viewing and verifying the Firewall rules on the network node Introduction The OpenStack Neutron provides a comprehensive set of features to secure access to the network resources. Neutron provides two levels of security restrictions. Security groups control the traffic flow between two ports in a Network by applying security rules on the ports. Firewalls secure the traffic flowing across the Networks by applying security rules on the Router. Using Neutron Security and Firewall Services 136 To implement these recipes, we will use an OpenStack setup as described in the following image: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex This setup has two compute nodes and one node for the controller and networking services. Creating a security group using Horizon Security groups provide you with ways to control the Network traffic between ports in an OpenStack Network. Security group rules are applied at a Network port level. To apply port level security, we will start by creating a security group and then adding security rules to this group. The security groups are attached to the instances when they are launched. Getting ready For creating a security group, you will need the following information: ff The security group name ff A description for the security group How to do it… The following recipe will show you how to create a security group using Horizon: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Compute | Access & Security: Chapter 7 137 3. In the Security Groups tab, click on + Create Security Group. 4. Fill in an appropriate security group Name and Description: 5. Click the Create Security Group button. Once the security group has been created successfully, it should be listed in the table, as shown in the following screenshot: Using Neutron Security and Firewall Services 138 In the subsequent recipes, we will see how rules can be added to the security group in order to allow traffic. How it works… In this recipe, we created a security group. The security group bundles a set of rules, which can be associated to a Network port, and by default denies all access to the associated ports. Configuring the security group rules using Horizon Once a security group has been created, access to all the ports associated with the security group is denied. Security rules are then added to the group in order to allow only certain type of traffic, thereby securing the Network. The rules are defined using Network traffic attributes such as protocol (TCP, UDP, or ICMP), the direction of traffic flow, for example, entering the port (ingress) or exiting the port (egress), and the application port, that is, the UDP or TCP socket ports. Getting ready For this recipe, you will need the following information: ff The name of the security group to which the rules will be added ff The type of protocol to be allowed ff The direction of the traffic, that is, originating from the port (egress) or destined to the port (ingress) ff The protocol port or port range that should be allowed How to do it… The following steps will show you how to create the security group rules using Horizon: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Compute | Access & Security. 3. Select the entry in the security group table, and in the Actions column, select Manage Rules. For this example, we will use the default security group. 4. This will open the screen to manage the rules for a selected security group: Chapter 7 139 5. Add a new security rule by clicking +Add Rule. 6. Security rules can be added using the predefined templates by choosing application names in the Rule drop-down menu (for example, HTTP or SSH) or providing a custom port, protocol, and remote address combination: Using Neutron Security and Firewall Services 140 7. Select the rule type from the drop-down menu titled Rule. For this recipe, we will add a Custom TCP Rule. 8. Select the direction of the traffic flow in the menu, Direction: Chapter 7 141 9. Next, select whether you want to open a single port or multiple ports using the Open Port menu. In this example, we will open a single port: 10. In the Port textbox, enter the protocol port number to open it. For this example, we will use port 22. 11. In the Remote menu, choose a method of identifying the remote address; it can be either a CIDR type network address or the name of another security group. We will use CIDR for this example. Using Neutron Security and Firewall Services 142 12. In the CIDR menu, mention the Network address with a mask from which to allow traffic: Chapter 7 143 13. Click Add to create the security group rule: The new rule is now a part of the security group. In this example, we added a rule to allow access to port 22, which is used for SSH from any remote IP. How it works… A security group by default blocks all the traffic to and from the Network port that is associated with it. The user can then define the rules to open up the port for specific types of traffic. Each security group rule opens up a certain type of traffic on the Network port. In this recipe, we created a Custom rule to open a TCP port for the incoming (ingress) traffic. The rule can allow traffic based on its origin. The origin can be either a Classless Inter-Domain Routing (CIDR) Network or another security group. The IP address, 0.0.0.0/0, matches any source address. The reference implementation of security groups in OpenStack is provided using the iptables. In case a security group name is used as the origin, the packet trying to reach the associated port will be matched against both the security groups one after another. Either of these security groups may explicitly allow the packet. If the packet does not match any of the rules, it will be dropped. Using Neutron Security and Firewall Services 144 Creating a security group using CLI We have seen how to create a security group using Horizon; this recipe shows you how to create a security group using the CLI. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The name and description of the security group How to do it… The following steps will show you how to create a security group using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron security-group-create command to create a security group with the desired name and description: 4. To list the security groups defined for the tenant, use the security-group-list command: Chapter 7 145 5. To see the details of the security group that has been created, use the security- group-show command with the name or ID of the security group: The security group rules can also be deleted using the Neutron CLI command security-group-delete. How it works… In this recipe, we created a security group using the Neutron CLI. We can also list and view the newly created security group using the CLI commands. In case multiple security groups with the same name are present, use the security group ID with the delete or show commands. In the following recipes, we will learn about populating this security group with rules in order to allow specific traffic packets using the CLI commands. Configuring the security group rules using CLI In the previous section, we saw the creation of a security group using the Neutron CLI. In this recipe, we will see how to create the security group rules using the Neutron CLI. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The name of the security group, protocol, direction of the traffic flow, protocol port, and a remote CIDR network Using Neutron Security and Firewall Services 146 How to do it… The following steps will show you how to create a security group rule using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. To create a security group rule, use neutron security-group-rule-create, as follows: The Neutron CLI commands can also be used to list, view, and delete the security group rules. How it works… The security group rules open the associated port for certain type of traffic packets. To specify the type of traffic, we can provide parameters such as protocol, application port, direction of the traffic flow, source of traffic, and so on. When a packet arrives at the port that is associated with the security group, its parameters are matched against each security group rule. If the packet matches the traffic pattern defined in any of the rules, it is allowed to pass through the port. If none of the rules match the packet, the security group drops the packet. Securing the traffic between instances on the same Network In this recipe, we will see how to use security groups to secure the instances on the same Network. We will create a Network and launch two instances connected to the Network. We will then use security groups in order to restrict the traffic between VMs. Chapter 7 147 Getting ready For this recipe, you will need the following information: ff The name for the Network ff The name for the security group How to do it… 1. Log in to Horizon with the appropriate credentials. 2. Follow the recipe titled Creating a Subnet and Network using Horizon in Chapter 1, Getting Started with OpenStack Networking to create a Network and its Subnet. For this recipe, we will create a Network called Chapter7_Network1 with a Subnet IP range of 70.70.70.0/24: 3. Next, we will launch two VM instances named Chapter7_VM1 and Chapter7_VM2 on the Network, Chapter7_Network1, and associate them with the security group, Chapter7_SecurityGroup1, that was created in the previous recipe: Using Neutron Security and Firewall Services 148 4. Once the VMs are active, verify the security group and Network associated with them by selecting the VM from the Network list by clicking on the instance name such as Chapter7_VM1 and looking in the Overview tab: Chapter 7 149 5. We will now log in to one of the VMs and try to ping the IP of the second VM: 6. As discussed earlier, specific security group rules are required in order to allow specific types of traffic. As we have not created any rule for ping (ICMP) traffic, pinging between the VMs fail. 7. Now, we will add rules to the security group in order to allow pings from any source. To do this, we will navigate to the security group list and click on Manage Rules for the security group, Chapter7_SecurityGroup1: Using Neutron Security and Firewall Services 150 8. We will then add a rule to allow all incoming ICMP traffic to the port from any source CIDR network: 9. We can now repeat the following test to verify that pinging from one VM to another will work: With the security group rule in place, pinging from one VM to another is now allowed. Chapter 7 151 How it works… The security group drops all the packets by default. In this case, ping (ICPM) traffic between the instances was blocked initially as there was no explicit rule to allow the traffic. Once rules were added to allow all the ICMP packets, pinging between the VMs was allowed. Note that rules can also be defined with specific criteria such as the source address of the packet in order to provide more security. Creating the security group rules to allow web traffic In this recipe, you will learn how to allow web traffic. We will create rules to allow the traffic destined only to a web server running in a VM. Web traffic is associated with TCP ports 80 for HTTP and 443 for HTTPS. Getting ready For this recipe, you will need the following information: ff The name of the Network ff The name for the security group For this recipe, we will use the Chapter7_Network1 Network and the Chapter7_ SecurityGroup1 security group that we created in the previous recipe. How to do it… The following steps will show you how to open specific application-related protocol ports in a security group: 1. Log in to Horizon with the appropriate credentials. 2. Navigate to Project | Compute | Access & Security. Using Neutron Security and Firewall Services 152 3. Click on Manage Rules for the Chapter7_SecurityGroup1 security group to go to the security group management page: 4. Click on +Add Rule to add a new rule. We will select the rule type HTTP in the Rule menu and CIDR as 0.0.0.0/0 to allow HTTP traffic from all remote locations: Chapter 7 153 5. We will follow the same process to add a rule for HTTPS traffic: 6. On completing these steps, the Chapter7_SecurityGroup1 security group will show the rules to allow the web traffic of HTTP and HTTPS from all locations: With the preceding security group rules in place, web access on the ports associated with the Chapter7_SecurityGroup1 security group is allowed from any source. Using Neutron Security and Firewall Services 154 How it works… In this recipe, we saw the creation of security group rules to allow web access on the associated port. The associated port can be a VM, which is running a web application. To allow the traffic to reach the web server, we will need to open TCP port 80 and 443, which are the well-known ports for HTTP and HTTPS protocol, respectively. With this rule added, all the ports associated to the Chapter7_SecurityGroup1 security group will allow the passing of the web access traffic. Configuring Neutron for the Firewall service The OpenStack Networking functionalities can be classified as core and service. Firewall is part of the service functionality and Neutron needs to be configured in order to support it. In this recipe, we will configure the Neutron server as well as the Neutron FWaaS agent in order to enable the Firewall functionality in OpenStack. Getting ready For this recipe, we will assume that the Neutron ML2 plugin has been configured to use VLAN as the type driver and Open vSwitch as the mechanism driver. How to do it… The following steps will show you how to configure Neutron to provide a Firewall service in OpenStack: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Open the neutron.conf configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf 3. In the [DEFAULT] section of the file, configure firewall as the service plugin for Neutron. If service_plugins is already configured, add firewall to the list, separated by a comma: [DEFAULT] ... service_plugins = firewall Chapter 7 155 4. In the [service_providers] section of the file, add FIREWALL as a service provider. If service_provider is already configured, add FIREWALL to the list, separated by a comma: [service_providers] ... service_provider = FIREWALL:Iptables:neutron.agent.linux.iptables_ firewall.OVSHybridIptablesFirewallDriver:default 5. Add a [fwaas] section of the file, as shown here: [fwaas] driver = neutron_fwaas.services.firewall.drivers.linux.iptables_ fwaas.IptablesFwaasDriver enabled = True 6. Open the l3_agent.ini file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/l3_agent.ini 7. As we are using Open vSwitch as the mechanism driver, in the [DEFAULT] section of the file, we will configure interface_driver accordingly: [DEFAULT] ... interface_driver = neutron.agent.linux.interface. OVSInterfaceDriver 8. To configure the Horizon dashboard for Firewall, open the /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py file and set an enable_firewall option in the OPENSTACK_NEUTRON_NETWORK setting: 'enable_firewall' = True 9. Once the changes are done, restart neutron-server, neutron-l3-agent, and horizon for the changes to take effect. How it works… Once Firewall is added to the list of service plugins in the Neutron configuration file and the Horizon dashboard has been configured, the support for Firewall is enabled in OpenStack. You will see that Horizon now has an option called Firewall when you navigate to Project | Network. The configuration of Neutron with an iptables-based FWaaS plugin is now complete. In the following recipes, we will use the Firewall service in order to secure the network access. Using Neutron Security and Firewall Services 156 Creating the Firewall rules In OpenStack Neutron, Firewall provides security by configuring the access control at the Network Router, in contrast to the security group, which provided the access control at the Network port. The Firewall policies provide you with the access control over the traffic crossing the Network boundary. In Neutron, a Firewall service is composed of a Firewall policy, which in turn is composed of many Firewall rules. We will start exploring Firewall as a service by first looking at the Firewall rules. We will then create a Firewall policy by grouping these rules. Finally, we will define a Firewall that will use the Firewall policy that we created. Getting ready In this recipe, we will go through the process of creating a Firewall rule using Horizon. For this recipe, you will need the following information: ff The Firewall rule name ff The rule description ff The protocol to define the type of traffic, for example, TCP, UDP, or ICMP ff The type of action that the rule will add, for example, allow or deny a traffic type ff The source and destination of the traffic and their port or port-range How to do it… The following steps will show you how to create a Firewall from Horizon: 1. Log in to Horizon with the appropriate credentials. 2. Navigate to Project | Network | Firewall and click on the Firewall Rules tab: 3. Click on Add Rules to open the menu. Chapter 7 157 4. In the Add Rule menu, provide the rule Name, Description, Protocol, Action, Source, Destination IP, and Port or Port Range: 5. Click Add to create the Firewall rule: Using Neutron Security and Firewall Services 158 The Firewall rules can also be created using the CLI commands, as follows: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. To create a Firewall rule, use the neutron firewall-rule-create command: Once the rule has been created, the rule details are displayed. How it works… The Firewall rule consists of two parts. The first part is the match condition. When a packet arrives at the Network, the Firewall uses the match condition to select a packet for an action. The second part in the rule is the action to take when a packet matches the condition. In this recipe, we created a rule to allow the matching traffic on port 22 for a destination network with the 70.70.70.0/24 address, and once this condition matches, the rule defines the action to allow the packet. Chapter 7 159 Creating the Firewall policies A Firewall policy is a grouping of the Firewall rules. We will now create a Firewall policy and add the Firewall rules that we created earlier. The order of the rules in a Firewall policy is important and a different ordering may give you a different result. A Firewall policy may also be shared between tenants. Getting ready We will create the Firewall policy using Horizon. For this recipe, we will need the following information: ff The Firewall policy name ff The Firewall policy description ff Names of the Firewall rules to be added to the policy How to do it… The following steps will show you how to create a Firewall policy and add the Firewall rules to it: 1. Log in to Horizon with the appropriate credentials. 2. Navigate to Project | Network | Firewalls and click on Firewall Policies. 3. In the Add Policy menu, provide Policy Name and Description: Using Neutron Security and Firewall Services 160 4. In the Rules tab in the Add Policy menu, choose and add the Firewall rules in Available Rules to Selected Rules. Dragging them up or down can reorder the rules: 5. Click Add to create the Firewall policy: We can also use the Neutron CLI to create the Firewall policy using the following steps: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. Chapter 7 161 3. To create a Firewall policy, use the neutron firewall-policy-create command: In the preceding command, the Firewall rules should be provided as an ordered list. The ordering of the rules in the list determines the order in which the Network packets will be matched. How it works… A Firewall policy is composed of rules, which match a traffic packet based on parameters such as the protocol, application port, and so on. The rules can either allow or deny the traffic that matches the rule. This makes the ordering of the rules in a policy significant. For example, if a rule that allows SSH traffic from any location is placed before a rule that denies any traffic from CIDR 20.20.20.0/24, an attempt to connect to a VM using SSH from CIDR 20.20.20.0/24 will still be allowed. Creating a Firewall A Firewall is associated with a Firewall policy. In the previous two recipes, you learned how to create Firewall rules and a policy. We will now create a Firewall and associate it with the policy that we created in the previous section. Getting ready We will create the Firewall using Horizon. For this recipe, we will need the following information: ff The Firewall policy name ff The Firewall name ff The Firewall description Using Neutron Security and Firewall Services 162 How to do it… The following steps will show you how to create a firewall using Horizon: 1. Log in to Horizon with the appropriate credentials. 2. Navigate to Project | Network | Firewalls and click on the Firewalls tab and click on Create Firewalls. 3. In the Add Firewall menu, provide Name and Description and choose the Policy of the Firewall from the drop-down menu: 4. Click Add to create the Firewall: Chapter 7 163 We can also create the Firewall with the Neutron CLI using the following steps: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. To create a Firewall, use the neutron firewall-create command and provide the Firewall policy that should be associated with this Firewall: How it works… Once a Firewall has been created using a predefined policy, all the Firewall policy rules are automatically applied to the Routers that already exist or those that will be created later. The reference implementation of FWaaS applies the Firewall rules as an iptables configuration in the Router's namespace. The Firewall policy of a tenant is applied to all the Routers that the tenant owns. This behavior will change in the future version of Neutron and allow the user to associate the Firewall policy to the chosen Routers. In the next recipe, we will explore the iptables configuration in detail. Using Neutron Security and Firewall Services 164 Viewing and verifying the Firewall rules on the Network node We created a Firewall and its policies and rules in the previous recipes. The Neutron reference implementation uses iptables to provide FWaaS. As discussed earlier, FWaaS policies are implemented at the Routers. Neutron uses the Network's namespace to implement the Routers. In this recipe, we will fnd out how the Firewall policies and rules are converted to the iptables configuration by Neutron. Getting ready For this recipe, you will need the following information: ff An administrative user access to OpenStack ff A root or equivalent sudo access to the Network node How to do it… The following steps will show you how to view the Firewall rules on the Network node: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Use the CLI commands to list the Firewall, Firewall policy, Firewall rule, and Routers. Note the Router ID in the following image. We will use this ID to find the namespace corresponding to this Router on the Network node: Chapter 7 165 4. Log in to the network node as the root user (or an equivalent sudo user) account using SSH. 5. Use the ip netns command to locate the namespace for the Router. Neutron creates the Router's namespace using a qrouter prefix with the Router ID. 6. Start a shell in the Router's namespace using the ip netns exec command: Using Neutron Security and Firewall Services 166 7. List the iptables rules in this namespace using iptables –L –n –v, as follows: You can see that the Firewall rules have been converted to the iptables configuration and applied in the Router's namespace. Chapter 7 167 How it works… Linux network namespace is used by Neutron to implement a Router. When the Firewall rules are created, Neutron configures iptables in the Router's namespace to implement the Firewall rules. In this example, we can see that the Router ID, 7dff588c-942d-407a- a325-3afca137bc24, is used to create the qrouter-7dff588c-942d-407a-a325- 3afca137bc24 namespace. Neutron then creates the iptables configuration in this namespace in order to implement the Firewall rules. For every Firewall that is created by the tenant, Neutron creates a pair of the iptables chains and names them using a prefix of the Firewall's ID. In this example, the chains are named as neutron-l3-agent-iv46bfb1d38 and neutron-l3-agent- ov46bfb1d38 and represent the ingress (input) and egress (output) direction of the match, respectively. In the chains, the individual rule configuration matches the Firewall rules created by the user. 169 8 Using HAProxy for Load Balancing OpenStack Neutron provides Load Balancer as a Service to distribute traffic to your application that is running on the virtual machines. In this chapter, we will explore the Neutron load balancer service plugin with the following recipes: ff Installing and configuring the Neutron load balancer service plugin ff Creating a load balancer pool using Horizon ff Creating a load balancer pool using CLI ff Adding a load balancer member using Horizon ff Adding a load balancer member using CLI ff Adding a load balancer health monitor using Horizon ff Adding a load balancer health monitor using CLI ff Creating a Virtual IP using Horizon ff Creating a Virtual IP using CLI ff Making the load balancer accessible to the Internet ff Testing the load balancer ff Viewing the load balancer on the network node Using HAProxy for Load Balancing 170 Introduction Critical applications and services need to be resilient to failures and capable of handling high network traffic. One of the strategies to achieve the scale and high availability is using a load balancer. A load balancer distributes an incoming service request to a pool of servers, which process the request, thus providing a higher throughput. If one of the servers in the pool fails, the load balancer removes it from the pool and the subsequent service requests are distributed among the remaining servers. The load balancer acts as a frontend to a cluster of worker nodes, which provide the actual service. To implement these recipes, we will use an OpenStack setup, as described in the following image: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex This setup has two compute nodes and one node for the controller and networking services. Installing and configuring the Neutron load balancer service plugin This recipe shows you how to install and configure the Load Balancer as a Service (LBaaS) plugin in Neutron. The reference implementation of LBaaS in Neutron uses HAProxy along with the network namespace. Getting ready For this recipe, you will need the following information: ff The login credentials to the Controller and Network node Chapter 8 171 How to do it… The following steps will show you how to install the load balancer service with Neutron: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Install the packages required to provide the load balancer services using a package manager such as yum or apt on the Network node, as follows: openstack@controller:~$ sudo apt-get install python-neutron-lbaas neutron-lbaas-agent haproxy 3. Open the neutron.conf configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf 4. In the [DEFAULT] section of the file, configure load balancer as the service plugin for Neutron. If service_plugins is already configured, add the load balancer configuration to the list, separated by a comma: [DEFAULT] ... service_plugins = lbaas 5. In the [service_providers] section of the file, add LOADBALANCER as a service provider. If service_provider is already configured, add LOADBALANCER to the list, separated by a comma: [service_providers] ... service_provider = LOADBALANCER:Haproxy:neutron.services. loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriv er:default 6. Open the /etc/neutron/lbaas_agent.ini configuration file and update the device_driver and interface_driver settings: interface_driver = neutron.agent.linux.interface. OVSInterfaceDriver device_driver = neutron.services.loadbalancer.drivers.haproxy. namespace_driver.HaproxyNSDriver 7. To configure Horizon for the load balancer, open the /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py file and set an enable_lb option in the OPENSTACK_NEUTRON_NETWORK setting: 'enable_lb' = True Using HAProxy for Load Balancing 172 8. Restart neutron-server, neutron-lbaas-agent, and apache2 or the httpd server for the changes to take effect. How it works… The load balancer service in Neutron is supported using a service plugin. The reference implementation of the load balancer uses HAProxy as the service provider. The plugin spawns the instances of HAProxy in a Linux network namespace on the network node in order to act as a load balancer node. Creating a load balancer pool using Horizon A typical load balancer installation consists of a pool of servers called members, each of which will run an instance of the application. All the clients will connect to the service using a Virtual IP that is configured on the load balancer node, as shown in the following image: Client1 Client2 Subnet Member1 Member2 Load Balancer Node Virtual IP The load balancer node then forwards the traffic transparently to the member servers. To accomplish this, it can adopt various strategies in order to distribute the traffic load to member servers such as round robin, least connected, and so on. To configure the load balancer, we would need some member servers connected to a virtual network. For this recipe, we will host a web server on each member server. These servers will be connected to a virtual network on the same subnet. We will then use Neutron to configure the load balancer to distribute traffic to the member servers. Follow the Creating Network and Subnet using Horizon recipe in Chapter 1, Getting Started with OpenStack Networking to create a LoadBalancer_Net1 Network and its Subnet with a network address of 20.20.20.0/24. Chapter 8 173 The following table shows you the VM details: Virtual Machine name Role IP address Chapter8_vm1 A load balancer member 20.20.20.3 Chapter8_vm2 A load balancer member 20.20.20.4 Getting ready In this recipe, we will use Horizon to create a load balancer pool. A load balancer pool defines a group of servers on a Subnet to be used to process the service requests. The pool also defines the strategy of distributing the load among the member servers. To create a load balancer pool, you will need the following information: ff The name of the load balancer pool ff The description of the pool ff The Subnet associated with the pool ff An application protocol for the load balancer ff The method used to spread the load to the pool members How to do it… The following steps will show you how to create a load balancer pool using Horizon: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Network | Load Balancers: 3. Click on +Add Pool. 4. In the Add Pool screen, provide a Name for this pool. Using HAProxy for Load Balancing 174 5. Add a Description for the pool. 6. Select haproxy as Provider for this pool. 7. Select Subnet for this load balancer pool. For our example, we will use the 20.20.20.0/24 Subnet on LoadBalancer_Net1 as the CIDR. 8. Select the application Protocol for this pool. For our example, we will use HTTP as the protocol: 9. Select Method used by the load balancer in order to select a server for the new request traffic. We will use the ROUND_ROBIN method: Chapter 8 175 10. Click on Add to create the pool: The load balancer pool that you created should now be listed in the Pools table. Using HAProxy for Load Balancing 176 How it works… The load balancer pool in Neutron defines the attributes of the load balancer such as the Subnet and load distribution method. The pool is associated with a protocol such as HTTP, HTTPS, or TCP. The following load distribution methods are supported: ff Least Connection: This forwards a request to the member having the least number of client requests ff Round Robin: This evenly distributes the service request between the members but does not take into account the current load on a member ff Source IP: This always forwards the requests from a client to a certain member Creating a load balancer pool using CLI In the previous recipe, we saw how to create a load balancer pool using Horizon. In this recipe, we will use the Neutron CLI to create a load balancer pool. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The name of the load balancer pool ff The Subnet ID for the load balancer ff The method to use for the load balancing ff The protocol that needs to be load balanced How to do it… The following steps will show you how to create a load balancer pool using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron lb-pool-create command to create the load balancer pool: Chapter 8 177 4. Once created, Neutron will display the details of the load balancer pool. How it works… The load balancer pool defines the protocol, Subnet, and method used to distribute the requests among the load balancer members. Adding a load balancer member using Horizon When a load balancer receives a service request from the client, it forwards the request to one of the load balancer members running the application and the application does the actual request processing. In this recipe, we will use Horizon to add members to the load balancer pool that we created earlier. Getting ready To add a member to a load balancer pool, you will need the following information: ff The name of the load balancer pool ff The VM name or IP to add as the pool member Using HAProxy for Load Balancing 178 ff The weight associated with the pool member ff The port on the VM to which the traffic would be redirected by the load balancer How to do it… The following steps will show you how to add a load balancer pool member using Horizon: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Network | Load Balancers. 3. Select the Members tab. 4. Click on +Add Member. 5. In the Add Member screen, select the name of the load balancer pool in the Pool field: Chapter 8 179 6. Set Member Source as Select from active instances. It is also possible to add a member based on the IP address. The IP address of the member must be in the Subnet that is associated with the pool. 7. In the Member(s) field, select the VM instance to be added: 8. In the Weight text box, provide the member's weight. This is an indicator of the relative load handling capacity of the member with respect to the other members in the pool. A higher weight of a member indicates a higher request handling capability. Using HAProxy for Load Balancing 180 9. In Protocol Port, provide the port on the VM to which the traffic should be redirected: 10. Click Add to create the member: The newly added member is now displayed in the Members tab. Chapter 8 181 How it works… The load balancer member runs the application that processes the client requests. In this recipe, we added two members to the load balancer pool. The load balancer distributes the client request to these two member servers, which do the actual request processing. Adding a load balancer member using CLI In this recipe, we will add a load balancer member using the Neutron CLI. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The IP address of the member ff The protocol port of the application running in the member ff The name of the load balancer pool where this member will be added How to do it… The following steps will show you how to add a load balancer member using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron lb-member-create command to add the member to the load balancer pool. Optionally, you can also provide a weight for this member: Using HAProxy for Load Balancing 182 How it works… The weight of the member is a relative value that decides the ratio of requests that can be handled by a member. If one of the members in the pool is a more powerful machine, it can be given a higher weight. The load balancer will distribute a bigger percentage of the requests to the member with the higher weight. Adding a load balancer health monitor using Horizon In this recipe, you will learn how to create a heath monitor for the load balancer that monitors the health of the applications that are running on the member servers. Getting ready To create a health monitor for our load balancer, we will need the following information: ff The type of monitor ff The time interval between consecutive health check request sent by the monitor ff The amount of time to wait for a reply from the application ff The number of times the monitor will try to get a reply from the application How to do it… The following steps will show you how to add a heath monitor for the load balancer: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Network | Load Balancers. 3. Select the Monitors tab and click on Add New Monitor. 4. In the monitor screen, add the monitor Type. For our example, we will use HTTP as the monitor type. 5. In the Delay field, provide the time interval between consecutive health check request sent by the monitor. 6. In the Timeout field, enter the amount of time to wait for a reply from the application. 7. In the Max Retries field, enter the number of times that the monitor will try to get a reply from the application. Chapter 8 183 8. In case you selected an HTTP or HTTPS type monitor, you should provide the type of HTTP Method that the monitor should invoke in order to check the health of the application. For our example, we will use the GET method. 9. For an HTTP/HTTPS type monitor, you should also provide a URL for the application and Expected HTTP Status Code for a healthy application. We will use the URL / and a status code of 200: 10. Click on Add to create the monitor. 11. Click on the Pool tab to go back to the load balancer pool list. Using HAProxy for Load Balancing 184 12. In the Actions column, click on the drop-down menu and select Associate Monitor: 13. In the Associate Monitor screen, select the monitor that you want to associate with the load balancer pool and click on Associate: Now the health monitor is associated with the load balancer pool. How it works… The load balancer needs to keep a track of the health of the application that is running on its member servers. The health monitor associated with the load balancer is responsible for monitoring the application on the member servers and making sure that in case the application on a member fails, it is excluded from the pool and no further client requests are forwarded to that failed member. Chapter 8 185 Adding a load balancer health monitor using CLI In this recipe, we will create a health monitor to watch the health of the application that is running on the load balancer members using the Neutron CLI. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The type of monitor ff The time interval between consecutive health check request sent by the monitor ff The amount of time to wait for a reply from the application ff The number of times the monitor will try to get a reply from the application How to do it… The following steps will show you how to create and associate a health monitor with a load balancer pool: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron lb-healthmonitor-create command to create a load balancer health monitor: Using HAProxy for Load Balancing 186 4. Execute the neutron lb-healthmonitor-associate command to associate the health monitor that we created in the previous step with the load balancer pool: How it works… The Neutron CLI can be used to create a load balancer health monitor. The health monitor continuously checks the health of the member instances. The health monitor consists of a method to test the application health and an expected result. If the health test fails for a member, the load balancer excludes this member from the pool. If a previously failed member becomes healthy, it is added again to the load balancer pool. Creating a Virtual IP using Horizon The final step in the creation of the load balancer is to provide it with a Virtual IP address (VIP). The clients connect to the load balanced application using the VIP. In this recipe, we will associate a VIP to the load balancer pool using Horizon. Getting ready To create a VIP, you will need the following information: ff A name to identify the VIP ff The name of the load balancer pool ff The Subnet CIDR associated with this pool ff A free IP address in the Subnet for the VIP configuration ff The protocol port on which the load balancer will listen for the client request ff The protocol type ff The method of session persistence ff The connection limit for the load balancer Chapter 8 187 How to do it… The following steps will show you how to attach a VIP to a load balancer: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Network | Load Balancers. 3. Click on the Actions drop-down menu for a specific load balancer pool and select Add VIP: 4. In the Add VIP screen, provide Name for the VIP. 5. Add Description for the VIP. 6. Select the Subnet for the VIP; this should be the same Subnet that was used by the VM instance running the application that will use the load balancer. 7. Next, provide a free IP address in the Subnet that will be used at the VIP address by the load balancer. The clients connecting to the application will use this IP address. 8. Specify the port in the Protocol Port field. For our example, we will use port 80. 9. Specify the protocol in the Protocol list. We will use HTTP for our example. 10. Next, in Session Persistence, choose the method used to maintain the client sessions while balancing a service request. We will use SOURCE_IP to persist the session. Using HAProxy for Load Balancing 188 11. In the Connection Limit field, provide the maximum number of clients that the load balancer can handle. We will use -1 so that no limit is set for the number of client connections: Chapter 8 189 12. Click Add to create the VIP: The VIP is then displayed in the corresponding column of the Pools table. How it works… The clients connect to the VIP in order to access the application running on the load balancer members. For the client, it appears as though the application is running on a port on the VIP. The client is unaware of the existence of a load balancer and the two member servers. The VIP creation also defines the session persistence method in order to determine how the client session is maintained. Sessions can be maintained using the source IP, which uses the source IP of the request to determine the member that handles a service request. Session persistence can also be based on HTTP or application cookies. It is also possible to limit the number of connections that the load balancer will handle using the connection limit setting. Creating a Virtual IP using CLI In this recipe, we will use the Neutron CLI to create and associate a VIP with a load balancer pool. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The name of the VIP ff The name of the load balancer pool ff The Subnet CIDR associated with this pool ff A free IP address in the Subnet for the VIP configuration ff The protocol port ff The protocol type Using HAProxy for Load Balancing 190 How to do it… The following steps will show you how to create a VIP and associate it with a load balancer pool using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron lb-vip-create command to create a VIP for the load balancer pool: How it works… To create the VIP, the Neutron CLI creates a Port on the associated Subnet. The IP address of this Port is used as the VIP for the load balancer pool. The load balancer will distribute any request that it receives on the VIP and configured protocol port to the pool members to be processed. Chapter 8 191 Making the load balancer accessible to the Internet In this recipe, we will make our load balancer accessible to the Internet. Getting ready In the previous recipe, we created a VIP for our load balancer. The clients will access the service available behind the load balancer using this VIP. To make the service accessible through the Internet, the VIP must be reachable from the external Networks. In this recipe, we will associate a floating IP to the VIP of the load balancer. We will need the Neutron port ID of the load balancer's VIP. Use the neutron port-list command to look for the port associated with the address of the VIP. For this recipe, you will need the following information: ff The SSH login credentials for a node where the Neutron client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The Neutron port ID for the load balancer's VIP How to do it… The following steps will show you how to create a VIP and associate it with a load balancer pool using the Neutron CLI: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Execute the neutron floatingip-create command to make the VIP for the load balancer pool accessible from the external world: Using HAProxy for Load Balancing 192 With the floating IP associated with the load balancer's VIP, the clients can now access the application behind the load balancer over the Internet. How it works… The load balancer uses the VIP address to redirect the service requests to the member nodes. To make the services that are running on the member node available to the external world, the VIP address must be reachable from the Internet. This can be achieved by associating a floating IP with the VIP of the load balancer. Testing the load balancer We added two servers as the load balancer members. We also created a health monitor in order to keep a track of the health of the application that is running on the member servers and also associated a VIP with the load balancer. The following table summarizes our example setup: Virtual Machine name Role IP address Chapter8_vm1 A load balancer member 20.20.20.3 Chapter8_vm2 A load balancer member 20.20.20.4 The load balancer configuration is as follows: Resource IP address Subnet CIDR 20.20.20.0/24 Network name LoadBalancer_net1 Virtual IP 20.20.20.50 Application port 80 In this recipe, we will test the load balancer setup by connecting to its VIP and sending a request to the application. Getting ready For this recipe, you will need the following information: ff The VIP of the load balancer ff The protocol port of the load balancer Chapter 8 193 How to do it… The following steps will show you how to test the load balancer: 1. Log in to Horizon with the appropriate credentials. 2. Launch a VM on the LoadBalancer_net1 Network. This instance will act as the client machine to test the load balancer. We already added the load balancer member VMs in the previous recipe. 3. In the left navigation menu, navigate to Project | Network | Load Balancers and click on the Members tab: 4. The monitor associated with the load balancer has put the members in an inactive state as the application health test is failing currently. 5. Log in to each member VM and start a web server. For our test, we will use the following simple script to simulate a web server. Update the echo statement with the correct hostname when launching the script: while true; do echo -e 'HTTP/1.0 200 OK\r\n\r\nChapter8_vm1' | sudo nc -l -p 80 ; done 6. Once the scripts are running on both the members, the health monitor will update the status of the members to active: Using HAProxy for Load Balancing 194 7. Log in to the client VM on LoadBalancer_net1 and use the curl command to send an HTTP request to the VIP address: For the purpose of this example, we updated the VIP configuration in order to disable the session persistence. Due to this, the client requests are distributed in a Round-Robin fashion among the load balancer members. How it works… In this recipe, we saw the load balancer in action. The health monitor checks the status of the application running on the member nodes continuously and distributes the client requests to only the active members in the pool. In case a failed member becomes healthy, its status changes to active and it starts processing the client requests. Viewing the load balancer on the network node In the earlier recipes of this chapter, we configured the load balancer using both Horizon and the Neutron CLI. In this recipe, we will learn how Neutron implements the load balancer on the Network node. Chapter 8 195 Getting ready For this recipe, you need the following information: ff An administrative user access to OpenStack ff A root or equivalent sudo access to the Network node How to do it… The following steps will show you how to view the load balancer on the Network node: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the Neutron client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Use the Neutron CLI commands to list the load balancer. Note the load balancer ID. 4. Next, use the ip netns command and find the network namespace that matches the pool ID. The load balancer plugin has configured this namespace as the load balancer node: 5. Next, we will find the VIP that has been associated with the load balancer pool. Note the VIP assigned with the load balancer: Using HAProxy for Load Balancing 196 6. Use the ip netns command to verify that the VIP is configured in the namespace acting as the load balancer node: 7. Next, use the ip netns command to verify that the HAProxy process is bound to the VIP and is listening for traffic on the application port: How it works… Neutron uses the Linux network namespace as the load balancer node. The namespace is named using a prefix of qlbaas, the ID of the load balancer pool a711d27b-285d-4b05- b090-4fa72ab22059. The namespace is configured with the load balancer's VIP. In our example, the VIP address of 20.20.20.50 is used. The load balancer plugin starts a HAProxy process in this namespace that binds the VIP on the protocol port, 80, receives the client requests, and distributes them to the pool members. 197 9 Monitoring OpenStack Networks The recipes in this chapter will explore the various means to monitor the network resource utilization using Ceilometer. We will cover the following topics: ff Monitoring the Virtual Machine bandwidth ff Monitoring the L3 bandwidth ff Monitoring the load balancer connection statistics ff Monitoring the per project and per user bandwidth ff Monitoring the host Network bandwidth Introduction Due to the dynamic nature of virtual infrastructure and multiple users sharing the same cloud platform, the OpenStack administrator needs to track how the tenants use the resources. In this chapter, we will look at ways to monitor the usage of virtual and physical networking resources. The resource utilization data can be used to bill the users of a public cloud and to debug infrastructure-related problems. The data can also help in capacity planning by giving an estimate of the capacity of the physical devices and trends of resource usage. OpenStack Ceilometer project provides you with telemetry service. It can measure the usage of resources by collecting statistics across the various OpenStack components. The resource utilization data is collected over the message bus or by polling the various components. OpenStack Neutron provides Ceilometer with the statistics that are related to the virtual networks. Monitoring OpenStack Networks 198 The following figure shows you how Ceilometer interacts with the Neutron and Nova services: Compute Node Polling Network Usage DataCeilometer Compute Agent Network Node Neutron Metering Agent Neutron Metering Data Ceilometer Central Agent Ceilometer Collector Ceilometer API Ceilometer Controller Components Client Node Ceilometer Client Database To implement these recipes, we will use an OpenStack setup as described in the following image: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex This setup has two compute nodes and one node for the controller and networking services. Chapter 9 199 Monitoring the Virtual Machine bandwidth OpenStack Ceilometer collects the resource utilization of the VMs by running a Ceilometer compute agent on all the compute nodes. These agents collect the various metrics that are related to each VM running on the compute node. The data that is collected is periodically sent to the Ceilometer collector over the message bus. In this recipe, we will learn how to use the Ceilometer client to check the bandwidth utilization by a VM. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the OpenStack client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The following steps will show you how to determine the bandwidth utilization of a VM: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the OpenStack client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Use the nova list command to find the ID of the VM instance that you want to monitor: Monitoring OpenStack Networks 200 4. Use the ceilometer resource-list|grep command to find the resource ID of the network port associated with the VM. Note down the resource ID for the virtual port associated to the VM for use in the later commands. The virtual port resource ID is a combination of the VM ID and name of the tap interface for the virtual port, which is named instance--: 5. Use ceilometer meter-list –q resource= to find the meters associated with the network port on the VM: 6. Next, use ceilometer statistics –m –q resource= to view the network usage statistics. Use the meters that we discovered in the previous step in order to view the associated data: Ceilometer stores the port bandwidth data for the incoming and outgoing packets and the bytes and their rates. How it works… The OpenStack Ceilometer compute agent collects the statistics related to the network port connected to the VMs and posts them on the message bus. These statistics are collected by the Ceilometer collector daemon. Ceilometer client can be used to query a meter and filter the statistical data based on the resource ID. Chapter 9 201 Monitoring the L3 bandwidth The OpenStack Neutron provides you with metering commands in order to enable the monitoring of the Layer 3 (L3) traffic. The metering commands create a label that can hold a list of the packet matching rules. Neutron counts and associates any L3 packet that matches these rules with the metering label. In this recipe, we will learn how to use the L3 traffic monitoring commands of Neutron to enable packet counting. Getting ready For this recipe, we will use a VM connected to a network that in turn is connected to a router. The following figure describes the topology: Monitoring OpenStack Networks 202 We will use a network called private with a CIDR of 10.10.10.0/24. For this recipe, you will need the following information: ff The SSH login credentials for a node where the OpenStack client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The name of the L3 metering label ff The CIDR for which the traffic needs to be measured How to do it… The following steps will show you how to enable the monitoring of the traffic to or from any L3 network: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the OpenStack client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Use the neutron meter-label-create command to create a metering label. Note the label ID as this will be used later with the Ceilometer commands: Chapter 9 203 4. Use the neutron meter-label-rule-create command to create a rule that associates a network address to the label that we created in the previous step. In our case, we will count any packet that reaches the gateway from the CIDR 10.10.10.0/24 network to which the VM is connected: 5. Use the ceilometer meter-list command with a resource filter in order to find the meters associated with the label resource: 6. Use the ceilometer statistics command to view the number of packets matching the metering label: The packet counting has now been enabled and the bandwidth statistics can be viewed using Ceilometer. How it works… The Neutron monitoring agent implements the packet counting meter in the L3 router. It uses iptables to implement a packet counter. The Neutron L3 agent collects the counter statistics periodically and posts on the message bus, which is collected by the Ceilometer collector daemon. Monitoring OpenStack Networks 204 Monitoring the load balancer connection statistics We have seen earlier that the OpenStack Neutron provides a load balancer as a service. The load balancer service provides you with the statistics of the utilization for each instance created in the load balancer cluster. In this recipe, we will view the load balancer-related usage data collected by OpenStack Ceilometer. Getting ready For this recipe, we will need to create a load balancer setup. Use the recipes described in Chapter 8, Using HAProxy for Load Balancing to create a load balancer with two members in the pool. We will also create a virtual IP and health monitor as described in the chapter. The following table describes our load balancer setup: Virtual Machine Role IP address vm1 Member 20.20.20.3 vm2 Member 20.20.20.4 Virtual IP Virtual IP 20.20.20.50 Client-1 Client 20.20.20.51 For this recipe, you will need the following information: ff The SSH login credentials for a node where the OpenStack client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The following steps will show you how to view the statistics available for a load balancer instance: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the OpenStack client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. Chapter 9 205 3. Use the ceilometer statistics command to find the number of load balancer members and pools. The meters associated with the load balancer instances use the prefix, network.services.lb: 4. Next, use the ceilometer statistics command with the network.services. lb.total.connections meter in order to find the number of total connections served by the load balancer. Use the pool ID to query the connection per load balancer instance: 5. Use the ceilometer statistic command with the network.services. lb.incoming.bytes meter to find the number of bytes received by the load balancer: You can use the ceilometer meter-list command to find out the other metering data available for the load balancer. How it works… The Neutron load balancer agent collects the statistics for each instance of the load balancer that is created; the usage data is periodically reported to Ceilometer. The Ceilometer client can then be used to track the various metrics associated with the load balancer instances. Monitoring OpenStack Networks 206 Monitoring the per project and per user bandwidth In the first recipe, we looked at the monitoring of resource utilization for a VM. In a cloud shared by multiple tenants and users, it is important to gather information about the utilization of the resources by a user or by the whole project. In this recipe, you will learn how to use the Ceilometer client to monitor the network bandwidth utilization by a tenant or project and an individual user of OpenStack. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the OpenStack client packages are installed ff A shell RC file that initializes the environment variables for CLI ff The ID of the OpenStack tenant and user How to do it… The following steps will show you how to determine the bandwidth utilization of a VM: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the OpenStack client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. 3. Use ceilometer statistics with the network meters to view the network resource utilization. Use user= and project= to filter the utilization by the user ID and tenant ID, respectively. The tenant and project IDs are the same: The other meters can also be queried in a similar manner in order to find the resources used by a user or project. Chapter 9 207 How it works… All the usage data stored by Ceilometer is associated with a user and project. So, it is possible to retrieve the monitoring data for a given user or tenant (project). Monitoring the host Network bandwidth In the previous recipes, we looked at monitoring the virtual infrastructure resources. For the cloud administrator, it is also very important to know about the utilization of the physical resources. In this recipe, you will learn about monitoring the Network utilization statistics for a compute or network node. Ceilometer can collect the physical network statistics for the compute or network node using a central agent and SNMP. The Ceilometer central agent must be configured in order to collect the physical resource utilization data from the compute and network nodes. On the Compute and Network nodes, the SNMP daemon must be configured to provide the physical resource utilization data that is queried by the Ceilometer central agent. In this recipe, you will learn how to use the Ceilometer commands in order to view the physical network statistics of the Compute and Network nodes. For this recipe, we will view the statistics collected for the Compute node, compute1. Getting ready For this recipe, you will need the following information: ff The SSH login credentials for a node where the OpenStack client packages are installed ff A shell RC file that initializes the environment variables for CLI How to do it… The following steps will show you how to view the physical network utilization data for a Compute or Network Node: 1. Using the appropriate credentials, SSH into the OpenStack node installed with the OpenStack client packages. 2. Source the shell RC file to initialize the environment variables required for the CLI commands. Monitoring OpenStack Networks 208 3. Use the ceilometer meter-list command to query all the meters associated with the OpenStack node. For our example, we will use the node, compute1: 4. Next, use the ceilometer statistics command to view any of the meters associated with the node. For this example, we will view the incoming network packets, as follows: Use the Ceilometer commands with the other hardware meters to view the associated data for the node. How it works… The Ceilometer central agent periodically polls the SNMP agent on the OpenStack nodes and collects the hardware-related statistics. The hardware status data is then stored by Ceilometer and can be queried using the client. 209 10 Writing Your Own Neutron ML2 Mechanism Driver In this chapter, we will learn how to develop a custom ML2 mechanism driver for Neutron using the following recipes: ff Creating a basic ML2 mechanism driver ff Registering your ML2 mechanism driver with the Neutron server ff Processing API requests for a Network ff Processing API requests for a Subnet ff Processing API requests for a Port Introduction This chapter is targeted towards developers and we will use DevStack to develop the driver for the ML2 plugin. DevStack is a tool to install an all-in-one OpenStack node. DevStack also provides you with a development environment for OpenStack-related programming. Knowledge of the Python programming language is a prerequisite for this chapter. Before we dive into the recipes, let's understand how the plugin works. Writing Your Own Neutron ML2 Mechanism Driver 210 As discussed in the first chapter, Neutron supports the core networking features using entities such as Network, Subnet, and Port. These entities are implemented using virtual and physical networking technologies. In order to allow multiple networking technologies to interoperate, Neutron uses the concept of plugins. The following image shows the Neutron plugin model: Neutron Server Core Plugin (Type: ML2) Type Driver: VLAN, VXLAN, GRE Mechanism Driver: Open vSwitch, Linux Bridge L3 Service Plugin LBaaS Service Plugin Firewall Service Plugin ... ... As shown here, Neutron supports one core plugin. The Modular Layer 2 (ML2) is a type of a core plugin that supports multiple drivers so that the plugin functionality can be extended and customized. The ML2 plugin comprises of type drivers and mechanism drivers. Type drivers represent different types of networking technologies that provide the segmentation of Networks, for example, VLAN or VXLAN-based segmentation. The mechanism drivers on the other hand are software and hardware solutions that implement one or more of the Network type. In this chapter, we will see how to write a custom ML2 mechanism driver from scratch. We will implement a simple driver that logs the key Neutron API calls in a log file. We will also see how to extract crucial information that has been passed to the Neutron API. The source code used in this chapter is available on GitHub at https://github.com/ reachsrirams/packt-openstack-networking-cookbook. You will need all the files from the GitHub repository. The repository also contains a reference local.conf file that may be useful in your DevStack installation. Creating a basic ML2 mechanism driver The first step in the journey to write an ML2 mechanism driver is to create a basic driver class. This will also help us understand the code structure. Chapter 10 211 Getting ready As mentioned earlier, we will use DevStack in order to write and test our plugin. So, ensure that the DevStack environment is up and running successfully. How to do it… 1. With the appropriate credentials, SSH into your DevStack setup. 2. Ensure that all the driver files from the GitHub repository are copied to /opt/stack/ neutron/neutron/plugins/ml2/drivers. 3. The ch10_ml2_mech_driver.py file will be our main mechanism driver file, as follows: 4. The CookbookMechanismDriver class extends the MechanismDriver class of the Neutron API and overrides only the initialize method for now. 5. You can view the MechanismDriver class defined in the /opt/stack/ neutron/neutron/plugins/ml2/driver_api.py file. You will notice that the MechanismDriver class supports many methods related to the Network, Subnet, and Port. How it works… As ML2 is a core plugin, the driver is intended to support operations on the core objects, namely Network, Subnet, and Port. As seen in the MechanismDriver class, there are Python methods to create, delete, and update these core entities. These operations result in the addition, removal, and updates to the Neutron database. Writing Your Own Neutron ML2 Mechanism Driver 212 Registering your ML2 mechanism driver with the Neutron server Once the driver code is added, the next step is to register the driver with Neutron. In this recipe, we will see how to register the new mechanism driver with Neutron. We will also check whether our mechanism driver has been loaded and initialized successfully as we restart the Neutron server. Getting ready The previous recipe is the prerequisite for this recipe. The basic ML2 driver code is required to be placed at the location mentioned in the previous recipe. How to do it… 1. With the appropriate credentials, SSH into your DevStack setup. 2. Open the /etc/neutron/plugins/ml2/ml2_conf.ini configuration file using your desired editor. For example, the command for the vi editor will be as follows: 3. In the [ml2] section of the file, configure mechanism_drivers, as follows: 4. Next, open the /opt/stack/neutron/neutron.egg-info/entry_points. txt file using your desired editor. For example, the command for the vi editor will be as follows: Chapter 10 213 5. In the [neutron.ml2.mechanism_drivers] section of the file, configure the Python class that needs to be loaded for the mechanism driver named cookbook. Note that the mechanism driver name must match the one that is used in the ml2_conf.ini file as shown in step 3: 6. Restart the Neutron services in your DevStack setup. You will have to use the correct screen instance of your DevStack setup to run this operation. 7. Once the Neutron services have been restarted, we will verify that our basic mechanism driver has been loaded and initialized. To do this, open the Neutron server log file in your DevStack setup. In our DevStack setup, the corresponding file is /opt/stack/logs/q-svc.log. 8. In this file, search for the words Inside Mech. This will show the corresponding record in the Neutron server log file, as shown in the following screenshot: Writing Your Own Neutron ML2 Mechanism Driver 214 The presence of the Inside Mech Driver Initialize shows that our minimal mechanism driver was loaded successfully and it was also initialized by invoking the initialize() method of the driver. Downloading the example code You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www. packtpub.com/support and register to have the files e-mailed directly to you. How it works… During the startup, the Neutron server loads the core plugin based on the configuration in the neutron.conf file. In our example, we will use the ML2 plugin as the core plugin. The ML2 plugin, in turn, loads the ML2 type and mechanism drivers as specified in the ml2_conf.ini file. In this recipe, the ML2 plugin will attempt to load the mechanism drivers named openvswitch and cookbook. The ML2 plugin uses the entry_points.txt file in order to identify and load the Python class corresponding to the driver name specified in the ML2 configuration. There's more… As we are using the DevStack setup for the recipes in this chapter, it is better to include cookbook as the mechanism driver in the local.conf file. This will ensure that cookbook is added to the ml2_conf.ini file every time DevStack is restarted. You can find a reference local.conf file in the GitHub repository. Processing API requests for a Network Vendors and third-party application developers write custom ML2 mechanism drivers in order to integrate their products and applications with OpenStack. The main aspect of writing mechanism drivers is the implementation of specific methods related to the Network, Subnet, and Port. In this recipe, we will see how to process API requests specifically for a Network. Getting ready In this recipe, we will enhance our basic mechanism driver code and add two new methods in order to process API requests for a Network. Ensure that your DevStack setup is up and running, with cookbook as one of the mechanism drivers, as shown in the previous recipe. Chapter 10 215 How to do it… 1. With the appropriate credentials, SSH into your DevStack setup. 2. Open /opt/stack/neutron/neutron/plugins/ml2/drivers/ ch10_ml2_ mech_driver.py using an editor. 3. Add a new import statement, as highlighted in the following screenshot: 4. Update the class declaration statement, as follows: 5. CookbookMechanismDriver now extends the CookbookNetworkMechanismDriver class and as a result, inherits the following methods: 6. We will implement only create_network_postcommit and update_network_ post_commit in this driver code. As shown in the code, we will log the Network name and Network type values. Writing Your Own Neutron ML2 Mechanism Driver 216 7. Restart the Neutron services in your DevStack setup. You will have to use the correct screen instance to run this operation. 8. Once the Neutron services have been restarted, create an OpenStack Network using the neutron net-create CookbookNetwork1 CLI command where CookbookNetwork1 is the Network name. 9. To verify that our mechanism driver code was executed, open the DevStack log file for Neutron. In our DevStack setup, the log file was /opt/stack/log/q-svc.log. 10. This log file should contain the specific log messages as per the create_network_ postcommit method in our mechanism driver. Note that the previous Network name is not printed in the logs as of now: 11. Now, change the Network name using neutron net-update CookbookNetwork1 --name CookbookNetwork2 where CookbookNetwork2 is the new name of the Network. This will trigger the update_network_post_commit method of our mechanism driver. 12. Once the operation is successful, you will see that the DevStack log file contains a log message for the update_network_post_commit method: As you can see, this time the log message contain the previous and current Network names. How it works… In this recipe, we implemented two methods related to a Network. The ML2 mechanism driver API consists of the create, update and delete operations for the OpenStack Network. In addition, the API also supports methods to handle DB commit related triggers. Once the Network object has been committed to the database, the method xxxxx_network_ postcommit operation is invoked. In this recipe, we extracted and printed the Network name and Network type in the Neutron log file. Chapter 10 217 Each of these methods can also pass a context parameter. The context parameter is very important as it contains the details of the Network being created or updated. In the case of an update operation, context also contains the Network information prior to the current update. In this recipe, we saw how to extract the Network name and Network type as a part of handling the API requests. It is possible to fetch additional attributes of a Network such as the Segmentation ID along similar lines. Processing API requests for a Subnet The previous recipe showed you how Neutron invokes methods in a mechanism driver for Network-related operations. In this recipe, we will see how to process API requests for Subnets. Getting ready In this recipe, we will enhance our driver and implement the methods that will process API requests for a Subnet. Ensure that your DevStack setup is up and running, with cookbook as one of the mechanism drivers, as shown in the earlier recipe. How to do it… 1. With the appropriate credentials, SSH into your DevStack setup. 2. Open /opt/stack/neutron/neutron/plugins/ml2/drivers/ ch10_ml2_ mech_driver.py using an editor. 3. Add a new import statement, as highlighted in the following image: 4. Update the class declaration statement to include the Subnet driver class, as follows: Writing Your Own Neutron ML2 Mechanism Driver 218 5. CookbookMechanismDriver now extends the CookbookSubnetMechanismDriver and CookbookNetworkMechanismDriver classes. Hence, it inherits the following additional methods: 6. We will implement only create_subnet_postcommit method in this driver code. As shown in the code, we will log the Subnet name, its CIDR, and the Network that it belongs to. 7. Restart the Neutron services in your DevStack setup. You will have to use the correct screen instance to run this operation. 8. Once the Neutron services have been restarted, create a Subnet using neutron subnet-create --name CookbookSubnet2 CookbookNetwork2 10.20.30.0/24. 9. Here, CookbookSubnet2 refers to the Subnet name, CookbookNetwork2 refers to the Network, and 10.20.30.0/24 refers to the CIDR or IP address range. 10. To verify that our mechanism driver code was executed, open the DevStack log file for Neutron. In our DevStack setup, the log file was /opt/stack/log/q-svc.log. Chapter 10 219 11. This log file should contain the specific log messages as per the create_subnet_ postcommit method in our mechanism driver: As seen in the log file, the create_subnet_postcommit method of our mechanism driver was executed. How it works… In this recipe, we implemented a method related to the Subnet entity. Therefore, context that was passed to the driver methods contains information about the Subnet. In this recipe, we first logged the Subnet name and its CIDR. The Subnet entity has only the ID of the Network that it belongs to. We have to query the ML2 plugin database in order to fetch the details of the Network. The code in this recipe shows you how to access the ML2 plugin database and query it for the Network entity. Processing API requests for a Port We will conclude this chapter with a recipe that shows you how to process API requests for a Port. In real-world applications, the Port-related operations are used more frequently when compared to a Network or Subnet. As there are different types of Ports, this recipe will show you how to identify the Port type from the API requests. Getting ready Ensure that your DevStack setup is up and running, with cookbook as one of the mechanism drivers, as shown in the earlier recipe. How to do it… 1. With the appropriate credentials, SSH into your DevStack setup. 2. Open /opt/stack/neutron/neutron/plugins/ml2/drivers/ ch10_ml2_ mech_driver.py using an editor. Writing Your Own Neutron ML2 Mechanism Driver 220 3. Add a new import statement, as highlighted in the following image: 4. Update the class declaration statement to include the Port mechanism driver class, as follows: 5. CookbookMechanismDriver now extends the CookbookPortMechanismDriver, CookbookSubnetMechanismDriver, and CookbookNetworkMechanismDriver classes. Hence, it inherits the following additional methods: 6. We will implement only create_port_postcommit method in this driver code. In this recipe, we will log the Port type, its IP address, and the Network that it belongs to. 7. Restart the Neutron services in your DevStack setup. You will have to use the correct screen instance to run this operation. Chapter 10 221 8. Once the Neutron services have been restarted, create a Router and add an interface to it using the neutron router-create and neutron router-interface- add CLI commands: 9. To verify that our mechanism driver code was executed, open the DevStack log file for Neutron. In our DevStack setup, the log file was /opt/stack/log/q-svc.log. 10. This log file should contain the specific log messages as per the create_port_ postcommit method in our mechanism driver: When we add an interface to a Router, it triggers a Create Port method on the mechanism driver. As we can see from the logs, the Port type is network:router_interface. The log also shows the Network-related information for the Port. How it works… In this recipe, we implemented a mechanism driver related to the Port entity. Therefore, context that was passed to the driver methods contains information about the Port. However, unlike a Subnet, context also contains the corresponding Network information. Writing Your Own Neutron ML2 Mechanism Driver 222 In this recipe, we saw that you can extract the Port type information from the current Port context using the device_owner field. The Port type is useful in case different actions are required for the DHCP port, a VM instance port, or a Router Port. We also saw how to extract the IP address assigned to the Port. This is another useful attribute while building applications. Finally, we saw how to extract the Network information from the Port context. Mechanism drivers from the Network device vendors often use the Network type and Segmentation ID in order to configure the underlying physical network. 223 11 Troubleshooting Tips for Neutron In this chapter, we will cover the following recipes: ff Troubleshooting a VM that does not get a DHCP IP address ff Troubleshooting a VM that does not get an initial configuration ff Troubleshooting a VM that does not get External Network access ff Troubleshooting a VM not reachable from External Networks ff Checking the status of the Neutron service ff Checking the MAC address table on a virtual switch Introduction OpenStack provides users with lots of configuration options, but at the same time, it is up to the OpenStack administrator to make sure that the correct combination of runtime options has been configured. A large number of deployment options for OpenStack makes it very flexible, but at the same time, it can lead to errors and misconfiguration. In this chapter, we will look at systematic ways to troubleshoot an OpenStack setup for networking-related issues. Troubleshooting Tips for Neutron 224 We will use the following topology in order to implement various debugging recipes: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex Troubleshooting a VM that does not get a DHCP IP address In this recipe, we will troubleshoot a scenario where a VM on OpenStack that is connected to a DHCP enabled virtual network is unable to obtain an IP address. When a tenant attaches the first VM to a DHCP enabled virtual network in OpenStack, Neutron automatically starts a DHCP server for the virtual network. This DHCP server is responsible for providing an IP address to the VM instances created on the virtual network. Once a VM instance attached to a virtual network boots up, it is assigned an IP address from the DHCP server. In this recipe, we will see some of the possible reasons for a VM instance failing to receive an IP address. Getting ready The following information is required for this recipe: ff SSH-based login credentials for the Controller and Network node ff SSH-based login credentials for the Compute node How to do it… The following steps will show you how to troubleshoot your setup when the VM does not get an IP address: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Make sure that the DHCP agent is running on the Network node using the following command: service neutron-dhcp-agent status Chapter 11 225 3. Change the DHCP agent configuration in the /etc/neutron/dhcp_agent.ini file in order to enable verbose and debug level logging: verbose = True debug = True The DHCP agent log files are present in the /var/log/neutron directory. 4. Restart the DHCP agent with the new configuration changes using the following command: service neutron-dhcp-agent restart 5. Verify that the DHCP service process provided by dnsmasq is started on the virtual network. Use the ps command along with the Network ID in order to find the DHCP processes and DHCP interface: 6. Make sure that the Network node is connected to the data Network. On an Open vSwitch-based setup, use the ovs-vsctl show command to view the bridges created. The br-int bridge is the integration bridge and all the devices on the network, such as the VMs, DHCP server, Routers, and so on, connect to it. This bridge is connected to the tunnel bridge; br-tun in the case of overlay networks or physical networks such as br-eth1 in the case of VLAN-based networks using a patch port. In case the patch port is not configured, restarting the Open vSwitch agent will create it: service neutron-plugin-openvswitch-agent restart Troubleshooting Tips for Neutron 226 7. In case of overlay-based networking such as VXLAN or GRE, make sure that the tunnel endpoints on the hypervisors are configured with the proper IP address and are reachable from the Network node, and the tunnels ports are created on the OVS bridge, br-tun. 8. In a VLAN-based setup, make sure that the physical network bridges, such as br- eth1, are connected to the actual physical interface, eth1, and the physical network interface is up. 9. The preceding steps need to be repeated for the compute node that is hosting the VM instance. As an administrative user, log in to the Horizon dashboard and navigate to Admin | System | Instances. View the instances table to identify the compute node that is hosting a VM. Then, follow the same steps mentioned earlier to make sure that the VM has network connectivity through the integration bridge and physical network interface. 10. You can capture the Network packets using the tcpdump command on the physical network interface connecting the Network or Compute node in order to verify that the packets from the VM are able to reach the DHCP server. For example, if your tenant network is connected using eth1, use the following command to start a packet capture: tcpdump –i eth1 –n -v A packet flowing out of the VM goes through br-int and the patch port to br-ethN (the bridge connecting to the physical interface, ethN) for a VLAN-based Network or to br-tun for a tunnel-based Network. Finally, the packet flows to the physical interface used for the tenant Network. You can start a packet trace to troubleshoot the flow using tcpdump or wireshark at various points on the data path, such as br-int, br-eth1, or br-tun. The following figure shows you the various interfaces where a packet trace can be started for troubleshooting: OVS OVS Patch link Patch linkbr-eth1 br-tun Global VLAN TAG VXLAN VNI br-int br-int Local VLAN TAG Local VLAN TAG Linux Bridge Linux Bridge VM1 VM1 Compute Node Compute Node VLAN based networks Tunnel based networks eth1 NIC Connects to Top-Of-Rack Switch Tunnel to other Compute/Network Nodes Interfaces for packet tracing Chapter 11 227 11. DHCP communication happens over the UDP ports 67 and 68 for the DHCP server and client, respectively. Make sure that the security group rules attached to the VM are not preventing the DHCP communication. Please look at Chapter 7, Using Neutron Security and Firewall Services to learn about security groups in Neutron. 12. In case the VM gets attached to multiple virtual networks, make sure that the DHCP client is running for all the network cards that you want to configure the DHCP-provided IP address. Most of the cloud images configure the VM for the first network only. You will have to look at the documentation of the operating system to learn about the available DHCP client. On Ubuntu and RHEL-based distributions, you should be able to use the dhclient command with the interface name, while the CirrOS image uses udhcpc as a DHCP client. How it works… For every virtual network created by the tenant, Neutron starts at least one DHCP server. When the VM boots, it sends a DHCPDISCOVER broadcast message to request the DHCP server for its IP address. The DHCP server then allocates an IP address to the VM. In case the VM does not receive the DHCPOFFER message, we must make sure that the DHCP server is running, network connectivity between the VM and DHCP server is working, and no security group rule is preventing communication between the VM and DHCP server. Troubleshooting a VM that does not get an initial configuration Once the VM boots up, it receives its IP address from the DHCP server. The VM then queries the metadata service in order to get additional configuration data for its initial configuration. During its first boot, the VM tries to receive its configuration by connecting to the metadata server at a well-known IP address of 169.254.169.254 on Port 80. In this recipe, we will learn how to troubleshoot metadata service related problems. Getting ready For this recipe, you will need the following information: ff SSH-based login credentials for the Controller and Network node ff SSH-based login credentials for the Compute node Troubleshooting Tips for Neutron 228 How to do it… The following steps will show you how to check the health of the metadata service for a virtual network: 1. With the appropriate credentials, SSH into the Network node. In our setup, it will be the Controller and Network node. 2. Make sure that the metadata agent is running on the Network node using the following command: service neutron-metadata-agent status 3. Change the metadata agent configuration in the /etc/neutron/metadata_ agent.ini file in order to enable verbose and debug level logging. The metadata agent log files are present in the /var/log/neutron directory. 4. Restart the metadata agent with the new configuration changes using the following command: service neutron-metadata-service restart 5. The metadata service requires the metadata proxy to be started. The proxy service can be started either as a part of the DHCP namespace using neutron-dhcp- agent or as a part of the Router namespace using neutron-l3-agent. Make sure that the metadata proxy option is enabled in one of the configuration files, /etc/ neutron/dhcp_agent.ini or /etc/neutron/l3_agent.ini: enable_metadata_proxy = True 6. For this example, we enabled the metadata proxy as a part of neutron-l3-agent. Connect a shell to the Router namespace using the ip netns exec qrouter- exec bash command. Checking the iptables rules with iptables –t nat –n –L in the Router's namespace should show the configuration that is related to the metadata service, similar to the one shown in the following image: The traffic trying to reach the metadata service at the IP address of 169.254.169.254 on Port 80 is redirected to the Router's IP on Port 9697. How it works… Once a VM instance gets its IP address, it tries to retrieve further configuration by contacting the metadata service provided by OpenStack. The cloud-enabled VM images are installed with the cloud-init service, which is used to download an additional configuration from the metadata service. The metadata service is available at the well-known IP address of 169.254.169.254. Chapter 11 229 The Neutron metadata agent is responsible for starting this service. The metadata service provides the VM instance with configuration data, such as the hostname, SSH keys, and so on. The cloud-init service provides a host of other configuration options such as installing extra packages, running custom scripts, and others. Troubleshooting a VM that does not get external Network access In this recipe, we will look at some of the reasons where the VM might not get external Network access in OpenStack. To provide external access to your VM, you must fulfill the following prerequisites: ff Your VM must be connected to a Router ff The Router must have its external gateway set Getting ready The following information is required for this recipe: ff OpenStack Horizon access as an administrator ff SSH-based login credentials for the Controller and Network node ff SSH-based login credentials for the Compute node How to do it… The following steps will show you how to troubleshoot the VMs that are unable to access the external Networks: 1. Log in to Horizon and make sure that the VM is connected to a Router through the internal Network. This can be seen by navigating to Project | Network | Network Topology. 2. On Horizon, navigate to Project | Network | Router and make sure that the Router has its gateway set. Note the ID for this Router on the Router details screen; it will be used in the subsequent steps of debugging. 3. With the appropriate credentials, SSH into the Network node. In our setup, it will be the Controller and Network node. 4. Start a shell that is connected to the namespace for the Router using the following command: ip netns exec qrouter- exec bash. Troubleshooting Tips for Neutron 230 The IP address configured on the external Network for this Router is 192.168.0.5, which is shown in the following screenshot: 5. Use the iptables –t nat –L –n command to view the Source Network Address Translation (SNAT) configuration: You should be able to see the SNAT rules similar to the one in the preceding figure. When any VM connected to this Router tries to communicate with the outside world, the iptables rules use the external IP address on the Router to replace the source address of the packets going out. In this example, the external IP on the Router is 192.168.0.5 and it is used as the external IP for SNAT. How it works… The default L3 plugin on OpenStack provides external access to the VM instances using SNAT. It implements SNAT using iptables rules in the virtual Router. To enable SNAT on the Router, the tenant must set a gateway on the Router by connecting it to an external Network. The gateway IP of the virtual Router is used to translate packets going out to the external world. Chapter 11 231 Troubleshooting a VM not reachable from external Networks A tenant can associate a floating IP address to a VM in order to make it externally reachable. In this recipe, we will look at the possible reasons that block the access to the VM from external Networks. External access to the VM works by providing Destination Network Address Translation (DNAT) at the virtual Router. To accomplish this, the following points must be taken care of: ff Your VM must be connected to a virtual Router ff You must have an external Network available to provide a floating IP ff You must associate a floating IP to your VM Getting ready The following information is required for this recipe: ff SSH-based login credentials for the Controller and Network node ff SSH-based login credentials for the Compute node How to do it… The following steps will show you how to troubleshoot a VM that is not accessible from the external Networks: 1. On Horizon, navigate to Project | Network | Router and make sure that the Router has its gateway set. 2. On Horizon, navigate to Project | Compute | Instances and find the floating IP associated to the VM. For this example, we have associated a floating IP of 192.168.0.4 to the VM instance with an internal IP of 20.20.21.6: Troubleshooting Tips for Neutron 232 3. With the appropriate credentials, SSH into the Network node. In our setup, it will be the Controller and Network node. 4. Start a shell connected to the Router's namespace using the ip netns exec qrouter- exec bash command and check the iptables configuration for the NAT rules in the namespace with the following command: Iptables –t nat –L –n You should be able to see the NAT rules for the floating IP association: 5. If the VM has multiple network interfaces, make sure that the default route is set to the Network gateway for the interface that has the floating IP associated. The NAT rules redirect the traffic arriving at the floating IP of 192.168.0.4 to the internal IP of 20.20.21.6. It also changes the source IP of any packet from the VM to the outside world to the floating IP 192.168.0.4. How it works… To make a VM externally accessible, a floating IP must be associated with it. A floating IP is an externally accessible IP address and is allocated from an external Network of the tenant. When a floating IP is associated with a VM, Neutron configures the virtual Router to map the destination address of the incoming traffic on the floating IP to the VM's internal IP. Configuring the DNAT rules using iptables on the virtual Router can accomplish this. Checking the status of the Neutron service The first step towards troubleshooting OpenStack Networks would be to make sure that the Neutron service is running. In this recipe, we will look at ways to make sure that the Neutron server is running without any errors. Getting ready For this recipe, you will need the following information: ff SSH-based login credentials for the Controller and Network node Chapter 11 233 How to do it… The following steps will show you how to check whether the Neutron service is running with the proper configurations: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. In the /etc/neutron/neutron.conf file, make sure that you have correct core_plugin and service_plugins configured. For example, in the case of the ML2 plugin, the Neutron configuration is as follows: core_plugin = ml2 The service_plugins should include a list of advanced services such as a Router, Firewall, and lbaas, depending on your deployment: service_plugins = router,firewall,lbaas Make sure that the packages for these service plugins are installed and configured. 3. You may wish to enable verbose and debug level logging for the Neutron server in the neutron.conf file for troubleshooting. Keep in mind that enabling the debug and verbose log will produce extensive logging, which will use the disk space. Therefore, it is best to enable it only for the required duration of troubleshooting: verbose = True debug = True 4. If you are using the ML2 plugin, check the ML2 configuration files in the /etc/ neutron/plugins/ml2 directory as well. The ml2_conf.ini file is the main configuration file that includes the type and mechanism driver settings. 5. Depending on your ML2 driver setting, you may need to review the configuration file that is specific to the driver. All the ML2 configuration files are located in the /etc/ neutron/plugins/ml2 directory. Please refer to previous chapters to learn more about the configuration of the ML2 type and mechanism drivers that are appropriate for your deployment. 6. Execute the following command to find out the status of the Neutron server: service neutron-server status 7. If you have made any changes to the configuration files, restart the Neutron server in order to load the new configuration by executing the following command: service neutron-server restart 8. The Neutron server logs are present in /var/log/neutron/server.log. In case the Neutron server fails to start, the Neutron logs can help in troubleshooting. Troubleshooting Tips for Neutron 234 How it works… The Neutron server configuration allows verbose logging that can help in troubleshooting. The main configuration file for Neutron is neutron.conf and it contains the core and service plugin configurations. The Neutron server runs as a Linux service on the OpenStack Controller node and you can use the service commands to restart them if any configuration has been changed. Checking the MAC address table on a virtual switch As the devices connected to the virtual Network start to communicate with each other, the virtual switch on the Compute node learns the MAC addresses of the network interfaces. In this recipe, we will learn how to view the MAC address table of a virtual switch on an OpenStack Compute node. Getting ready For this recipe, you will require the following information: ff SSH-based login credentials for the Compute node How to do it… The following steps will show you how to check the MAC address table on the virtual switch: 1. With the appropriate credentials, SSH into the Compute node. 2. Use the ovs-appctl fdb/show command to view the MAC addresses learned by the Open vSwitch instance: ovs-appctl fdb/show br-int Chapter 11 235 3. For a Linux bridge-based deployment, follow the recipe Viewing virtual interface information on the Compute node in Chapter 2, Using Open vSwitch for VLAN-Based Networks to find the bridge name for the virtual Network. Use the brctl showmacs command with the bridge name to view the MAC addresses learned by a Linux bridge instance, for example, for a bridge, brq1e023dc6-7a, use the following command: brctl showmacs brq1e023dc6-7a The MAC address on the virtual switch corresponds to the MAC address of the network interface in the attached VMs. How it works… When the devices on the OpenStack Network communicate with each other, the virtual switches such as the Open vSwitch or Linux bridge will start learning the Layer 2 address (MAC address) of the devices connected to the Ports of the virtual Network by looking at the packets that traverse the switch. Learning how to view these MAC addresses on the virtual switch can help in understanding the flow of packets between devices such as the VM instances, Virtual Routers, and so on that the OpenStack tenants create. 237 12 Advanced Topics In this chapter, we will look at some of the advanced networking concepts in OpenStack Neutron in the following recipes: ff Configuring Neutron for VPN as a service ff Testing VPN as a service on Neutron ff Using link aggregation on the compute node ff Integrating networking in a Heat template Introduction We will discuss VPN, link aggregation on the compute node, and integration with OpenStack Heat project in this chapter. The Heat project in OpenStack provides you with an orchestration service to spawn resources such as VMs, Routers, and load balancers along with their Network connectivity. To implement these recipes, we will use an OpenStack setup as described in the following image: Keystone Service Nova Service Glance Service Neutron Server Neutron Agent(s) eth2eth1 Nova Service Nova Service Neutron Agent Neutron Agent eth0 eth0eth1 eth1eth0 Controller and Network Node Compute Node 1 Compute Node 2 Management Network Data Network External Network (Internet) br-int br-int br-intbr-ex This setup has two compute nodes and one node for the controller and networking services. Advanced Topics 238 Configuring Neutron for VPN as a service A Virtual Private Network (VPN) connects two endpoints on different Networks over a public Internet connection in such a way that the endpoints appear to be directly connected to each other. VPNs also provide you with the confidentiality and integrity of the transmitted data. VPN connectivity between two Networks can be implemented at different layers of an OSI stack. A VPN that connects the endpoints at Layer 2 is called L2 VPN while a VPN that connects the endpoints at Layer 3 (for example, an IP layer) is called L3 VPN. Neutron provides a service plugin that enables OpenStack users to connect two Networks using a VPN. The reference implementation of the VPN plugin in Neutron uses Openswan to create an IPSEC based L3 VPN. IPSEC is a suite of protocols that provides a secure connection between two endpoints by encrypting each IP packet transferred between them. An IPSEC endpoint consists of the following two parts: ff A daemon to negotiate session keys between the peer endpoints ff A component that uses the session keys to encrypt/decrypt the packets IPSEC uses the Internet Key Exchange (IKE) protocol in order to establish an authenticated session key. IPSEC can use various techniques for the authentication; OpenStack VPNaaS uses Pre-Shared Keys (PSK) as the authentication mechanism. Getting ready In this recipe, we will configure Neutron to use the reference VPNaaS plugin. For this recipe, you will need the following information: ff SSH-based login to the Controller and Network node How to do it… The following steps will show you how to install the VPN service plugin with Neutron: 1. With the appropriate credentials, SSH into the node where the Neutron server is running. In our setup, it will be the Controller and Network node. 2. Install the packages required to provide VPN services using a package manager such as yum or apt: openstack@controller:~$ sudo apt-get install python-neutron-vpnaas neutron-vpn-agent openswan 3. Open the neutron.conf configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/neutron.conf Chapter 12 239 4. In the [DEFAULT] section of the file, configure vpnaas as the service plugin for Neutron. If service_plugins is already configured, add the VPN service configuration to the list separated by a comma: [DEFAULT] ... service_plugins = vpnaas 5. Open the /etc/neutron/vpnaas_agent.ini configuration file and update the device_driver and interface_driver settings: interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver vpn_device_driver=neutron.services.vpn.device_drivers.ipsec. OpenSwanDriver 6. To configure the Horizon dashboard for VPNaaS, open the /usr/share/ openstack-dashboard/openstack_dashboard/local/local_settings.py file and set the enable_vpn option in the OPENSTACK_NEUTRON_NETWORK setting: 'enable_vpn' = True 7. Restart neutron-server, neutron-vpn-agent, and apache2 or http server for the changes to take effect: service neutron-server restart service neutron-vpn-agent restart On a RedHat- or CentOS-based system, restart apache, as follows: service httpd restart On Ubuntu, the following command restarts apache: service apache2 restart Once the changes take effect, log in to Horizon and verify that the VPN support has been enabled by navigating to Project | Network | VPN. How it works… OpenStack Neutron provides VPN as a service. To enable this feature, the VPN plugin must be installed and configured on the Controller and Network node. The configuration of Horizon must also be updated in order to enable support for the VPN service. Advanced Topics 240 Testing VPN as a service on Neutron This recipe simulates a VPN connection between two data center sites connected over a public Network. We will create a private Network connected to a Router to simulate a data center. The VPN service provided by Neutron will be configured between two such Routers in order to connect the two private Networks. Getting ready The following table describes the infrastructure required for testing the VPN service: Router Private Network Subnet CIDR VM Location Chapter12_ Router1 Chapter12_ Network1 Chapter12_ SubNet1 10.10.10.0/24 VM1 Site1 Chapter12_ Router2 Chapter12_ Network2 Chapter12_ SubNet2 10.10.20.0/24 VM2 Site2 In addition to this, we will use an external Network called public in order to simulate the Internet. The VPN connection will be made over the Internet (the public Network in this recipe) to connect the two Routers. The external Network, public, uses a CIDR of 192.168.0.0/24. The virtual Network components are connected in a topology described in the following figure: Site1 Network1 VM1 VPN EP1Router1 Site2 Network2 VM2 VPN EP2 Router2 Internet Chapter 12 241 Follow the Creating Network and Subnet using Horizon recipe in Chapter 1, Getting Started with OpenStack Networking to create the Networks Chapter12_Network1 and Chapter12_ Network2 with Subnets and CIDR as described in the preceding table. Launch two VMs, VM1 and VM2, connected to Chapter12_Network1 and Chapter12_network2, respectively. Follow the recipes in Chapter 6, Using Routing Services in Neutron to create the two Routers, Chapter12_Router1 and Chapter12_Router2. The Networks, Chapter12_Network1 and Chapter12_network2, are added to the Routers, Chapter12_Router1 and Chapter12_Router2, respectively. Next, set the gateway on both the Routers. Setting a gateway on the Routers will connect the Routers to the public Network and assign an IP address to the Router interface connected to the public Network. Once these steps have been completed, the Network Topology should look as follows: Note the IP addresses assigned to VM1 and VM2 once they have booted. Advanced Topics 242 The Router's public IP addresses are used to set up the VPN. The external IP of the Routers must be noted. To find the external IP of the Router, navigate to Project | Network | Router and click on the desired Router. The external IP of the Router can be found in the Router Details tab: The following table shows the IP addresses allocated to the Routers in our setup: Router Public IP address Chapter12_Router1 192.168.0.4 Chapter12_Router2 192.168.0.5 How to do it… The following steps will show you how to create a VPN service in order to test the VPN service plugin: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Network | VPN. 3. In the IKE Policies tab, click Add IKE Policy. Chapter 12 243 4. On the Add IKE Policy screen, add Name and Description for the policy: 5. The Add IKE Policy screen also allows changing the IKE options such as Encryption, Authorization, and so on. We will use the default settings. Advanced Topics 244 6. Click Add to create the IKE policy: 7. In the IPSec Policies tab, click Add IPSec Policy. 8. On the Add IPSec Policy screen, provide Name and Description for the IPSEC policy: 9. We will use the default settings for the rest of the options. Chapter 12 245 10. Click Add to create the IPSEC policy: 11. Next, we will create the VPN service. 12. In the VPN Services tab, click +Add VPN Service. 13. On the VPN Service screen, provide Name and Description for the VPN service: 14. In the Router drop-down menu, select the first Router, that is, Chapter12_Router1. 15. In the Subnet selection menu, choose the Subnet that has been added to the first Router, that is, Chapter12_SubNet1 with a CIDR of 10.10.10.0/24. Advanced Topics 246 16. Click Add to create the VPN service: 17. Repeat these steps to create another VPN service for the second Router with the Subnet, Chapter12_SubNet2, with a CIDR of 10.10.20.0/24: 18. In the IPSec Site Connections tab, click +Add IPSec Site Connection. 19. On the IPSec Site Connection screen, provide Name and Description for the connection; we will use Chapter12_IPSec_Connection1 and Chapter12 IPSec Connection1, respectively. 20. Choose VPN Service associated with this connection from the drop-down menu; we will choose Chapter12_VPN1. 21. Choose IKE Policy associated with this connection and IPSec Policy associated with this connection as Chapter12_IKE_policy1 and Chapter12_IPSec_Policy1. 22. In Peer Gateway public IPv4/IPv6 Address or FQDN and Peer Router Identity for authentication (Peer ID), provide the external IP of the peer Router. For our example, the external IP for the peer Router Chapter12_Router2 is 192.168.0.5. 23. In Remote peer subnet(s), provide the target Subnet that this VPN will connect to; for our example, we will use this VPN to connect to Chapter12_SubNet2, which has a CIDR of 10.10.20.0/24. Chapter 12 247 24. Finally, we will need to provide Pre-Shared Key (PSK) string that will be used by the connection; for this example, we will use Chapter12_Secret: Advanced Topics 248 25. Create another IPSEC site connection for the second Router. Choose Chapter12_VPN2 as the VPN service and Chapter12_IKE_policy1 and Chapter12_IPSec_Policy1 for the IKE and IPSEC policy, respectively. (As we will use the same cloud installation to implement the VPN connections, we can share the policies between the two VPN configurations.) Provide the external IP of Chapter12_Router1 for the peer Router's external IP or FQDN and 10.10.10.0/24 (the CIDR of Chapter12_SubNet1) as the remote peer Subnet(s): 26. Test the VPN connections by executing a ping command to the instances across the VPN connection. In this example, our VMs have an IP address of 10.10.10.3 for VM1 and 10.10.20.3 for VM2: Chapter 12 249 The VPN connections are now functional between the two Routers and the instances on the two Networks can communicate with each other. How it works… The private networks, Chapter12_Network1 and Chapter12_network2, are connected to their respective Routers. The Routers are assigned a public IP address by executing a set gateway operation. In our case, the Routers get a public IP from the CIDR 192.168.0.0/24 associated with the external Network, public. In this recipe, we configured an IPSEC-based VPN and connected the private Networks, Chapter12_Network1 and Chapter12_Network2. The Routers act as the VPN endpoints. While creating VPN site connections, information about the peer Router and the remote Subnet must be provided. The VPN service and site connection should be created for both the endpoints. The VPN service configuration uses a secret key, PSK, that is shared by both the peers. Using link aggregation on the compute node Link aggregation or bonding is a way to combine multiple physical network links to a logical link. Link aggregation is used as a means to provide higher bandwidth and redundancy against link failure. In this recipe, we will see how to configure link aggregation in order to connect the virtual switch on an OpenStack node to the physical switch. We will assume that the virtual switch used on the OpenStack node is Open vSwitch and configure link aggregation with Link Aggregation Control Protocol (LACP): SWITCH Hypervisor1 Hypervisor2 br-int br-int VM VM br-bond0 br-bond0 Advanced Topics 250 Getting ready For this recipe, we will need the following information: ff SSH-based login for the Compute and Network node ff Details of the Network interface to use for link aggregation How to do it… The following steps will show you how to configure link aggregation on a Compute or a Network node and update Neutron to use the bonded interface for the tenant data traffic: 1. With the appropriate credentials, SSH into the Compute node. 2. Add a bridge on the Open vSwitch using the ovs-vsctl add-br command: ovs-vsctl add-br br-bond0 3. Next, we will create the bonded interface on this bridge with the ovs-vsctl add- bond command: ovs-vsctl add-bond br-bond0 bond0 eth1 eth2 4. Then, enable LACP on the bonded interface: ovs-vsctl set port bond0 lacp=active 5. Update the physical switch configuration to enable the LACP-based link aggregation interface. Consult your switch documentation to get the exact configuration. 6. Open the /etc/neutron/plugins/ml2/ml2_conf.ini configuration file using your desired editor. For example, the command for the vi editor will be as follows: openstack@controller:~$ sudo vi /etc/neutron/plugins/ml2/ml2_conf. ini 7. In the [ovs] section, update bridge_mappings in order to use the newly created bridge for the tenant traffic: [ovs] bridge_mappings = physnet1:br-bond0 8. Restart the Open vSwitch L2 agent for the configuration change to take effect: service neutron-plugin-openvswitch-agent restart 9. Repeat these steps on all the Compute and Network nodes that need to use link aggregation. How it works… Link aggregation provides both redundancy and a higher bandwidth by combining multiple physical Network links in a logical link. Chapter 12 251 Integrating networking in a Heat template Nowadays, the installation of any nontrivial application spans more than one machine. Different machines provide specialized functions such as database servers, web servers, and many more. Heat is an OpenStack project that provides the users of OpenStack with the ability to start a group of connected resources such as VMs, Networks, Routers, and so on in order to create a complete infrastructure for deploying applications. The tenant communicates with the orchestration system using the Heat client. A Heat template describes the stack of infrastructure resources requested by the user. A template consists of the following sections: ff Version: This provides a version of the template format ff Description: This describes the purpose of the template ff Parameters: This section describes the user-defined parameters that are used in the template; it can describe the parameter type and validation logic for the parameters ff Resources: The resources section describes the resources that the template tries to create ff Outputs: The output section describes the output to be printed after the orchestration is complete The client submits the orchestration request using the Heat API on behalf of the user. The Heat engine parses, validates, and assigns user-specified values to the variables in the template. It then creates the resources defined in the template using various OpenStack clients in order to interact with individual services, as described in the following figure: CFN API NATIVE API CFN Templates HOT Templates HEAT ENGINE OpenStack APIs Neutron Nova Others... OpenStack Clients Heat Client Keystone Glance Cinder Others... In this recipe, we will learn about the Heat template constructs to manage the Network resources. Advanced Topics 252 Getting ready The following steps will show you how to use Heat to create a simple stack consisting of a newly created Network attached to a Router. To deploy this topology, we will need a Heat template. We will use the following template for our example: This file is available on GitHub at https://github.com/reachsrirams/packt- openstack-networking-cookbook/blob/master/Chapter12/Chapter12_Stack1. yaml. Clone this repository to your local machine. We will be using the Chapter12_Stack1. yaml file for our recipe. Chapter 12 253 How to do it… The following steps will show you how to create a simple stack of infrastructure using a Heat template: 1. Log in to Horizon with the appropriate credentials. 2. In the left navigation menu, navigate to Project | Orchestration | Stacks: 3. Click on +Launch Stack. 4. On the Select Template screen, select Template Source as File. Templates can be provided as a direct input, as a URL or file. For this example, we will use a File-based input: Advanced Topics 254 5. Next, click on Browse to locate and upload the Heat template file, Chapter12_Stack1.yaml, that we created earlier. 6. Click Next. 7. The Launch Stack screen is created based on the parameters described in the template file: 8. Click Launch to start the orchestration process: 9. Click on Stack Name to see the details of the stack. 10. The Topology tab shows the OpenStack resources created by Heat. Chapter 12 255 11. The Overview tab shows details such as Status of the stack, Stack Parameters, Outputs, and so on: 12. The Resources tab shows the resources used by the stack. How it works… The Heat engine parses, validates, and assigns values to the attributes in the template. Once the Heat template completes the validation process, the engine uses the OpenStack project clients to create the resources described in it. For example, for the Network-related resources, Heat uses the Neutron client in order to create the appropriate resources. 257 Index A allotted VLAN viewing, for Network 29, 30 API requests processing, for Network 214-217 processing, for Port 219-221 processing, for Subnet 217-219 C Ceilometer 2 Classless Inter-Domain Routing (CIDR) 143 CLI used, for adding load balancer health monitor 185, 186 used, for configuring security group rules 145, 146 used, for creating load balancer pool 176 used, for creating security group 144, 145 used, for creating Virtual IP 189, 190 Compute node link aggregation, using 249, 250 virtual interface, viewing for GRE tunnels 94-97 virtual interface information, viewing 50-55 virtual interface information, viewing for VXLAN tunnels 86-89 virtual interface information, viewing 36-41 D DB-Access-Network 67, 68 DB-VM 67, 68 DHCP server starting, on specific Network node 108-110 Distributed Virtual Routing (DVR) 120 E External Network about 116 creating, Horizon used 63-66 F Firewall creating 161-163 Neutron, configuring 154, 155 policies, creating 159-161 rules, creating 156-158 rules, verifying on Network node 164-167 rules, viewing on Network node 164-167 Flat Network about 48 creating, Horizon used 57-60 Neutron, configuring 56, 57 floating IP address associating, to virtual machine 132-134 creating, Neutron CLI used 130-132 deleting, Neutron CLI used 130-132 G Generic Routing Encapsulation (GRE) 92 GRE tunnels virtual interface, viewing on Compute node 94-97 GRE type driver Neutron, configuring 92, 93 H Heat template networking, integrating 251-255 258 Horizon used, for accessing virtual machine from External Network 126-129 used, for adding load balancer health monitor 182-184 used, for adding load balancer member 177-182 used, for associating network to instance 8-11 used, for configuring security group rules 138-143 used, for creating External Network 63-66 used, for creating Flat Network 57-60 used, for creating load balancer pool 172-176 used, for creating Network 3-5 used, for creating Router 118, 119 used, for creating security group 136-138 used, for creating Shared Network 60-63 used, for creating Subnet 3-5 used, for creating Virtual IP 186-189 used, for increasing IP addresses 111-113 used, for viewing details of Network 5-7 host Network bandwidth monitoring 207, 208 I Internet virtual machine instances, accessing 124-126 Internet Key Exchange (IKE) 238 IP addresses increasing in Network, Horizon dashboard used 111-113 L Layer 3 (L3) bandwidth monitoring 201-203 link aggregation about 249 using, on Compute node 249, 250 Link Aggregation Control Protocol (LACP) 249 Linux bridge virtual interface information, viewing on Compute node 50-55 load balancer about 170 connection statistics, monitoring 204, 205 internet accessibility 191, 192 health monitor, adding with CLI 185, 186 health monitor, adding with Horizon 182-184 testing 192-194 viewing, on Network mode 194-196 Load Balancer as a Service (LBaaS) plugin 170 load balancer member adding, CLI used 181, 182 adding, Horizon used 177-181 load balancer pool creating, CLI used 176 creating, Horizon used 172-176 load balancer service plugin configuring 170-172 installing 170-172 M MAC address table checking, on virtual switch 234, 235 ML2 mechanism driver about 209, 210 creating 210, 211 registering, with Neutron server 212-214 Modular Layer 2 (ML2) 23 multiple IP addresses configuring, for virtual interface 104-106 N Network allotted VLAN, viewing 29, 30 API requests, processing for 214-217 associating to instance, with Horizon 8-11 creating, Horizon used 3-5 creating, OpenStack CLI used 11-14 creating, with specific VLAN 31-35 creating, with specific VNI 84-86 details viewing, with Horizon 5-7 VLAN range, configuring 27, 28 Network node DHCP server, starting 108-110 Firewall rules, verifying 164-166 Firewall rules, viewing 164-166 259 load balancer, viewing on 194-196 virtual interface information, viewing 41-46 virtual interface information, viewing for VXLAN tunnels 89-92 Neutron about 2 configuring, for Firewall service 154, 155 configuring, for Flat Network 56, 57 configuring, for GRE type driver 92, 93 configuring, for Linux bridge mechanism driver 48-50 configuring, for Open vSwitch mechanism driver 24-26 configuring, for Routing services 116, 117 configuring, for VLAN type driver 26, 27 configuring, for VPN as a service 238, 239 configuring, for VXLAN type driver 78-80 status, checking 232, 234 VPN as a service, testing 240-249 Neutron CLI used, for associating floating IP address 132-134 used, for creating floating IP address 130-132 used, for creating Router 118, 119 used, for deleting floating IP address 130-132 Neutron Network VNI, viewing 82, 83 O OpenStack about 2, 223 networking quota, configuring 20-22 setting up 2 OpenStack CLI Port, associating to instance 17-20 Port, creating 16, 17 used, for creating Network 11-14 used, for creating Subnet 14, 15 OpenStack Network redundant DHCP server, creating 107 Open vSwitch mechanism driver Neutron, configuring 24-26 P per project bandwidth monitoring 206 per user bandwidth monitoring 206 Port API requests, processing for 219-222 associating, to instance with OpenStack CLI 17-20 creating, with OpenStack CLI 16, 17 Pre-Shared Keys (PSK) 238 Q quotas 20 R redundant DHCP server per OpenStack Network creating 107 Remote Procedure Call (RPC) 80 Router creating, Horizon dashboard used 118, 119 creating, Neutron CLI used 118, 119 instances, enabling on different Networks 120-124 virtual machine instances, accessing Internet 124-126 S security group creating, CLI used 144, 145 creating, Horizon used 136-138 rules configuring, CLI used 145, 146 rules configuring, Horizon used 138-143 rules, creating for web traffic 151-154 used, for securing traffic between instances 146-150 Shared Network creating, Horizon used 60-63 simple web application instances, creating 73-76 OpenStack Networks, setting up 68-73 setting up 66-68 260 specific IP address VM instance, creating with 100-103 specific VLAN Network, creating with 31-35 specific VNI used, for creating Network 84-86 Subnet API requests, processing for 217-219 creating, Horizon used 3-5 creating, OpenStack CLI used 14, 15 V Virtual eXtensible LAN (VXLAN) 78 virtual interface multiple IP addresses, configuring 104-106 viewing, on Compute node for GRE tunnels 94-97 virtual interface (VIF) information viewing, on Compute node 36-41 viewing, on Compute node for Linux bridge 50-55 viewing, on Compute node for VXLAN tunnels 86-89 viewing, on Network node 41-46 viewing, on Network node for VXLAN tunnels 89-92 Virtual IP creating, CLI used 189, 190 creating, Horizon used 186-189 virtual machine accessing from external Network, Horizon used 126-129 bandwidth, monitoring 199, 200 floating IP address, associating to 132-134 Virtual Network Identifier (VNI) about 78-80 range configuring, for VXLAN Networks 81 viewing 81-83 Virtual Private Network (VPN) 238 virtual switch MAC address table, checking 234, 235 Virtual Tunnel End Point (VTEP) 78 VLAN range configuring, for networks 27, 28 VLAN type driver Neutron, configuring 26, 27 VM, troubleshooting access from external Network, providing 231, 232 DHCP IP address, getting 224-227 external Network access, providing 229, 230 initial configuration, getting 227, 228 VPN as a service Neutron, configuring 238, 239 testing, on Neutron 240-249 VXLAN tunnels virtual interface information, viewing on Compute node 86-89 virtual interface information, viewing on Network node 89-92 VXLAN type driver Neutron, configuring 78-80 W Web-Access-Network 67, 68 Web-Internet-Network 67, 68 Web-VM 67, 68
还剩278页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 10 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

near40

贡献于2017-11-29

下载需要 10 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf