OpenStack/sanbox/DevStack Installation: Kilo

From DocWiki

Jump to: navigation, search

Contents

Introduction

This document describes how the Cisco RaaS, FWaaS and VPNaas Plugins interface with Community OpenStack Networking. OpenStack Networking (Neutron) ensures the network is not a bottleneck or limiting factor in a cloud deployment, and gives users self-service ability over network configurations. OpenStack Networking provides networking models for different applications or user groups. OpenStack Networking provides an extension framework that can deploy and manage additional network services — such as load balancing, firewalls, and virtual private networks (VPN).

The Cisco® Cloud Services Router 1000V (CSR 1000V) is a virtual-form-factor router that delivers comprehensive WAN gateway and network services functions into virtual and cloud environments. Using familiar, industry-leading Cisco IOS® XE Software networking capabilities, the CSR 1000V enables enterprises to transparently extend their WANs into provider-hosted clouds. Similarly, cloud providers themselves can use it to offer enterprise-class networking services to their tenants or customers.

Installing Base OS

Ubuntu

Install Ubuntu 14.04.1 LTS Linux Server

Install Ubuntu

Red Hat

Install RHEL7, CentOS7, or Fedora 20 version of Linux Server installed.

Red Hat Enterprise Linux 7

OpenStack Installation

OpenStack can be installed and deployed using software distributions, each of which add their own value to the cloud operating system. Some of them are:

  • DevStack: These features can also be used in a devstack environment. For instructions on installing and configuring devstack click Setting Up Devstack in Kilo

After performing one of the installations above, the Cisco CSR1kv in Openstack can be used to implement the following services:

  • Networking: CSR1kv can be used to implement Neutron’s L3 Routing service API. In this case, the life cycle of CSR1kv VMs are managed by a L3 routing service plugin using Nova. This service plugin also takes care of making the appropriate configurations in the CSR1kv VMs to realize the service API. The CSR1kv VMs are therefore also not visible to regular users. They are hidden in a different admin tenant. The only abstraction visible to the user is the Neutron Router. Neutron's L3 Routing service API in CSR1kv can be used either with the ML2 plugin or with the N1kv plugin. The installation steps are described in Section 4 CSR Instantiation as a neutron router.
  • Firewall: CSR1kv can also be used to implement Neutron’s Firewall service API. This implementation is dependent on the L3 Routing service in CSR1kv described in the Networking section above. Consequently, the CSR1kv VMs are never visible to regular users in this case either. The users only see the Neutron Firewall resources. The installation steps for FWaaS in CSR1kv are described in Section 5 Cisco FWaaS (ACL-based).
  • VPN: CSR1kv can also be used to implement Neutron’s IPSEC VPN service API. This implementation is dependent on the L3 Routing service in CSR1kv described in the Networking section above. As described in the Firewall section above, the CSR1kv VMs are never visible to regular users, who only see the Neutron VPN resources. The installation steps for VPNaaS in CSR1kv are described in Section 6 Cisco VPNaaS.

CSR Instantiation as a neutron router

Overview

Neutron’s routing service implemented in CSR1kv VM provides basic routing functionality between Neutron subnets and allows static routes to be specified. The Neutron routers can be attached to a Neutron external network. The routers then also provide source NAT functionality that enables a tenant’s VMs to initiate and establish communication with hosts outside of the OpenStack cloud. Such Neutron routers also support Neutron’s floating IP feature. Thereby an IP address on the external Neutron network/subnet can be mapped (by NAT) to an IP address on one of the internal subnets that the Neutron router is attached to. This allows a tenant’s VM to run application services that hosts outside of the cloud can use.

The diagram below shows Neutron’s routing model exemplified using a simple virtual topology. It contains one Neutron router, three internal Neutron networks A, B, and C and one external Neutron network.


Ext-neut net.JPG

This is the view visible to regular users in a tenant; the exposed abstraction is the Neutron router and not how it is implemented.

In an Openstack Neutron deployment with the N1kv monolithic core plugin, VLAN segmentation, and where CSR1kv VMs are realizing the Neutron routers, the above virtual topology is materialized as shown in the diagram below:

Topo virtual.JPG

The Neutron router is hosted in a CSR1kv started using OpenStack compute Nova. The CSR1kv VM has one virtual interface (VIF) connected to a special virtual management network, and another VIF connected to a per-tenant trunk network. The latter is used to carry tenant-traffic. For each Neutron subnet that the Neutron router is attached to, the VLAN of the corresponding Neutron network is trunked on the Neutron port to which the tenant traffic VIF is connected.

A Cisco CSR routing service plugin and an associated driver has been introduced to implement Neutron’s routing service in CSR1kv VMs. It uses Nova to spin up CSR1kv VMs on demand and interacts with a Cisco configuration agent that applies configurations inside the CSR1kv VMs. The diagram below shows the involved components and OpenStack services.

OpenStack mgmt net.JPG


The routing service plugin and the configuration agent communicate with each other using the normal OpenStack management network. Hence, the server where the configuration agent runs must have a network interface on that management network. More than one configuration agent can be deployed. They are automatically discovered and used by the routing service plugin.

The configuration agent must also be able to communicate with the CSR1kv VMs where the Neutron routers are to be hosted. This communication channel is used to apply configurations in the CSR1kv VMs through their management VIF. Since the spin up and deletion of CSR1kv VMs are done using Nova’s public REST API, all VIFs (and the management one in particular) can only be connected to Neutron networks. As a consequence, the communication channel for management must be a Neutron network. In the diagram above, it is called the virtual management network (WMN).

While nothing prevents the VMN from being the same as the normal OpenStack management network, it is for security reasons preferable to make it a separate network. The step-by-step instructions in this documentation wiki make this assumption. Just like the CSR1kv VMs management VIF, the server where a configuration agent runs must have a network interface on the virtual management network. The step-by-step instruction also covers how to do this.

Unless Nova’s scheduler is so configured the CSR1kv VM are spun up on the same compute server set as any other Nova VM. If the cloud administrator wants to constrain the compute host set for the CSR1kv VMs, Nova’s host aggregates feature together with the ‘AggregateInstanceExtraSpecsFilter’ can be used.

Installation

The CSR1kv routing service plugin and configuration agent are available at https://github.com/stackforge/networking-cisco/tree/stable/kilo

Note: This software is provided "as is," and in no event does Cisco warrant that the software is error free or that customer will be able to operate the software without problems or interruptions.

Perform the following for Red Hat, Ubuntu and RDO installations:

Plugin configuration/setup:

Setup keystone service for CSR1kv:

The default name of this tenant is ‘L3AdminTenant’. It can be overridden in the configuration file ‘/etc/neutron/cisco_router_plugin.ini’.

1. Create admin tenant that owns CSR1kv VMs:

keystone tenant-create --name L3AdminTenant --description "Owner of CSR1kv VMs”

2. Make service Neutron an admin user in tenant from step 1:

keystone user-role-add --user-id <UUID of service Neutron> --role-id <UUID of administrator role> --tenant-id <UUID of tenant created in step 1>

The UUID of service neutron (which is used as user) can be obtained by:

keystone user-get neutron

The UUID of the administrator role can be obtained by:

keystone role-get admin

3. Make service Neutron an admin user in ‘service’ tenant:

keystone user-role-add --user-id <UUID of service Neutron> --role-id <UUID of administrator role> --tenant-id <UUID of service tenant>

The UUID of service tenant can be obtained by:

keystone tenant-get service

Setup Nova and Glance services for CSR1kv VMs:

The default name of the flavor for the CSR1kv VMs is ‘csr1kv_router’. The default UUID of that flavor is 621. They can be overridden in the configuration file ‘/etc/neutron/cisco_router_plugin.ini’.

The steps below should be performed as user ‘neutron’ in tenant ‘L3AdminTenant’.

1. Create the Nova flavor for the CSR1kv:

 
nova flavor-create csr1kv_router 621 8192 0 4 --is-public False

2. Remove relevant quotas:

 
nova quota-update --cores -1 --instances -1 --ram -1 <UUID of ‘L3AdminTenant’>

3. Define the Glance image for the CSR1kv:

 
glance image-create --name csr1kv_openstack_img --owner <UUID of ‘L3AdminTenant’> --disk-format qcow2 --container-format bare --file <path to CSR1kv image> --property hw_vif_model=virtio --property hw_disk_bus=ide --property hw_cdrom_bus=ide

Setup Neutron for Cisco CSR1kv routing service plugin:

The default name of the virtual management network is ‘osn_mgmt_nw’. It can be overridden in the configuration file ‘‘/etc/neutron/cisco_router_plugin.ini’.

1. Edit the ‘etc/neutron.conf’ file and specify the CSR1kv routing service plugin:

service_plugins=networking_cisco.plugins.cisco.service_plugins.cisco_router_plugin.CiscoRouterPlugin

2. Create directory for CSR1kv configdrive template:

mkdir /opt/stack/data/neutron/cisco

3. Copy CSR1kv configdrive template to directory in step 2:

cp <root of networking-cisco directory>/networking_cisco/plugins/cisco/l3/configdrive_templates/csr1kv_cfg_template /opt/stack/data/neutron/cisco

4. Create the required N1kv port policy profiles. This requires logging in on the VSM using ssh where the following commands can be issued:

% configure terminal
% feature network-segmentation-manager
% port-profile type vethernet osn_mgmt_pp
% no shutdown
% state enabled
% publish port-profile
% end
% exit
% configure terminal
% feature network-segmentation-manager
% port-profile type vethernet osn_t1_pp
% no shutdown
% state enabled
% publish port-profile
% end
% exit
% configure terminal
% feature network-segmentation-manager
% port-profile type vethernet osn_t1_pp
% no shutdown
% state enabled
% publish port-profile
% end
% exit

5. Start Neutron server (or restart it if it was already running). The steps below should be performed as user ‘neutron’ in tenant ‘L3AdminTenant’.

6. Create required N1kv network profiles. In this example VLAN 100 is used for the virtual management network.

neutron cisco-network-profile-create --tenant-id <UUID of ‘L3AdminTenant’> --physical_network osn_phy_mgmt_network --segment_range 100-100 osn_mgmt_np vlan

neutron cisco-network-profile-create --tenant-id <UUID of ‘L3AdminTenant’> --physical_network osn_phy_network --sub_type VLAN osn_t1_np trunk

neutron cisco-network-profile-create --tenant-id <UUID of ‘L3AdminTenant’> --physical_network osn_phy_network --sub_type VLAN osn_t2_np trunk

7. Create the virtual management network: neutron net-create --tenant-id <UUID of ‘L3AdminTenant’> $osnMgmtNwName --n1kv:profile_id $nProfileId

8. Create the subnet for virtual management network. In this example the CIDR selected is 10.0.100.0/24 out of which .1-.20 are managed manually:

neutron subnet-create --name osn_mgmt_subnet --tenant-id <UUID of ‘L3AdminTenant’> --allocation-pool start=10.0.100.10,end=10.0.100.254 <UUID of virtual management network from step 6> 10.0.100.0/24 --disable-dhcp

Setup connectivity for Cisco configuration agent:

The steps below need to be repeated for every configuration agent that is deployed.

The steps below should be performed as user ‘neutron’ in tenant ‘L3AdminTenant’.

1. Create Neutron port for configuration agent. In this example we pick an IP address from the IP range that was earlier specified to be manually managed:

neutron port-create --name l3CfgAgent1 --tenant-id <UUID of ‘L3AdminTenant’> --fixed-ip ip_address=10.0.100.2 osn_mgmt_nw --n1kv:profile_id <UUID of port policy profile osn_mgmt_pp>

The UUID of port policy profile osn_mgmt_pp can be obtained by:

neutron cisco-policy-profile-list

2. Log in on the server where the configuration agent runs. Then (with super user privileges) issue the following commands to create the logical network interface to enable connectivity:

ip link add l3cfgagent_hs address <MAC address of Neutron port created in step 1> type veth peer name l3cfgagent_bs
ip link set l3cfgagent_hs up
ip link set l3cfgagent_bs up
ip -4 addr add 10.0.100.2/24 dev l3cfgagent_hs
ovs-vsctl -- --may-exist add-port br_int l3cfgagent_bs -- set interface l3cfgagent_bs external-ids:iface-id=<UUID of Neutron port created in step 1> -- set interface l3cfgagent_bs external-ids:attached-mac=<MAC address of Neutron port created in step 1> -- set interface l3cfgagent_bs external-ids:iface-status=active

With that the Cisco router service plugin should be operational.

Neutron L3 routing REST API operations on CSR

Step 1. Create two networks

Create two networks. The examples below create and internal (private) and external (public) network.

External Network Creation :

        neutron net-create public \--router:external True
        neutron subnet-create public 172.16.1.0/24

Internal Network Creation :

        neutron net-create private
        neutron subnet-create private 10.0.0.0/24

Step 2. Create the neutron router

Create the neutron router, and attach the public and private interfaces. The CSR acting as this neutron router will be launched in the tenant "L3AdminTenant"

    neutron router-create router1

Step 3. Attach the interfaces

Attach the public and private interfaces. The CSR acting as this neutron router will be launched in the tenant "L3AdminTenant"

neutron router-gateway-set <router1 ID> <public network ID>
neutron router-interface-add <router1 ID> <private subnet ID>

Step 4: Detach interfaces

neutron router-interface-delete <router1 ID> <private subnet ID>

Step 5 Delete router

Neutron router-delete <router1 ID>


DevStack Installation

For more details see Setting Up Devstack in Kilo


Cisco FWaaS (ACL-based)

Overview

FWaaS is an OpenStack Service that provides Firewall functionality. FwaaS provides security on network traffic between the public network the router and devices attached to the subnet by using a firewall. The firewall rules make up the firewall policy for the firewall as shown below. These are the basic resources. Firewall Rules ------ > Firewall Policy -------> Firewall. CSR supports Zone Based Firewalls which is not yet available in the community FWaaS API. Until that support is available, Cisco is implementing a basic firewall with an ACL based back-end in the CSR. The diagram below shows the OpenStack community FWaaS model:


Community FWaas.JPG


The diagram below shows the CSR FWaaS model:

CSR FWaas.JPG

A new Cisco CSR FWaaS Plugin and an associated driver have been introduced to convert OpenStack community firewall rules to ACL rules. For more information on Cisco’s ACL click the following link: Cisco IOS Security


An overview of the basic model is shown below:

FWaas resources.JPG

In the community model, the Firewall is applied on a Router or a set of Routers at the finest level of granularity. CSR applies the Firewall on traffic ingressing, egressing or on both directions of a network on a specific router interface for the network that is attached.

This is done by specifying a point of insertion of the firewall in the CSR on the L3 interface which can have networks and subnets attached to it. The rules are applied to inside traffic, outside traffic or both.

The CSR FWaas Service Plugin performs the following function:

  • Provides Additional Vendor extensions
    • Specifies the neutron port ID corresponding to a subnet (specific insertion point on the firewall)
    • Specifies the direction of traffic – inbound, outbound or both (specifies direction of traffic on the firewall)
  • Manages the database which tracks the configuration.
    • Firewall Policy and Rule databases are used as is from the community.
    • Base firewall table is used
    • An additional table (cisco_firewall_asssociations) is used by the Plugin to track the Cisco vendor extension attributes port id and direction for a specific firewall.
  • Validation is done by ensuring that it is a router interface.

The Plugin maps the OpenStack resource to the Cisco ACL via calls to the appropriate REST API.

The Firewall-as-a-Service (FWaaS) plug-in adds perimeter firewall management to Networking. FWaaS uses iptables to apply firewall policy to all Networking routers within a project. FWaaS supports one firewall policy and logical firewall instance per project. Whereas security groups operate at the instance-level, FWaaS operates at the perimeter to filter traffic at the neutron router.

Installation

The community FWaaS Kilo stable branch is available at https://github.com/openstack/neutron-fwaas/tree/stable/kilo

Standard Installation

For details on standard installation see Perform the following for Red Hat, Ubuntu and RDO installations

  • Plugin configuration/setup

Add neutron.services.firewall.plugins.cisco.cisco_fwaas_plugin. CSRFirewallPlugin to the service_plugins in neutron.conf. Restart the neutron server.

DevStack installations

Perform the following:

In the localrc file insert

enable_service cisco-fwaas

For more details see Setting Up Devstack in Kilo


Note: This software is provided "as is," and in no event does Cisco warrant that the software is error free or that customer will be able to operate the software without problems or interruptions.

Create / Update / Delete Firewall on CSR

Configuration

  • Validate configuration – L3 port should be associated with CSR. If it is not L3 port it is not validated
  • Create, update and delete
    • Neutron firewall – create policy
      •  Port id
      •  Direction
    • Work flow
      •  Create rule(s)
      •  Create policy (R1, R2)
      •  Create firewall

Cisco firewall rules and policies can be provisioned from Dashboard or via Neutron CLI. Cisco firewall rules and policies can be provisioned from Dashboard or via Neutron CLI. Cisco firewall can be provisoned via Neutron CLI. (Dashboard support is coming.) Refer to the following link for more details on "neutron firewall-rules" CLI: neutron firewall-rules

Provisioning CIsco firewall using Neutron CLI is described below.

  • Create Firewall*
  • Step 1: create firewall rule(s):
usage: neutron firewall-rule-create [-h] [-f {shell,table,value}] [-c COLUMN]
                                    [--max-width <integer>]
                                    [--variable VARIABLE] [--prefix PREFIX]
                                    [--request-format {json,xml}]
                                    [--tenant-id TENANT_ID] [--name NAME]
                                    [--description DESCRIPTION] [--shared]
                                    [--source-ip-address SOURCE_IP_ADDRESS]
                                    [--destination-ip-address DESTINATION_IP_ADDRESS]
                                    [--source-port SOURCE_PORT]
                                    [--destination-port DESTINATION_PORT]
                                    [--enabled {True,False}] --protocol
                                    {tcp,udp,icmp,any} --action {allow,deny}
Example: 
neutron firewall-rule-create --protocol icmp --action deny --name r1
  • Step 2: create firewall policy
usage: neutron firewall-policy-create [-h] [-f {shell,table,value}]
                                      [-c COLUMN] [--max-width <integer>]
                                      [--variable VARIABLE] [--prefix PREFIX]
                                      [--request-format {json,xml}]
                                      [--tenant-id TENANT_ID]
                                      [--description DESCRIPTION] [--shared]
                                      [--firewall-rules FIREWALL_RULES]
                                      [--audited]
                                      NAME
Example: 
neutron firewall-policy-create --firewall-rules r1 p1
  • Step 3: Identify firewall insertion point, i.e. port-id (interface) where the firewall to be applied
neutron port-list


  • Step 4: create firewall, with port-id and firewall direction
usage: neutron firewall-create [-h] [-f {html,json,shell,table,value,yaml}]
                               [-c COLUMN] [--max-width <integer>]
                               [--prefix PREFIX] [--request-format {json,xml}]
                               [--tenant-id TENANT_ID] [--name NAME]
                               [--description DESCRIPTION] [--shared]
                               [--admin-state-down]
                               POLICY
 
Example: 
neutron firewall-create --name f1 p1 --port-id f2c74188-b912-4822-971c-531b5ff7d25d --direction inside

  • Delete firewall*
neutron firewall-delete <firewall_name or firewall_uuid>
neutron firewall-policy-delete <firewall_policy_name or firewall_policy_uuid>
neutron firewall-rule-delete <firewall_rule_name or firewall_rule_uuid>
  • Update Firewall*
  • Update firewall rule
usage: neutron firewall-rule-update [-h] [--request-format {json,xml}]
                                    [--protocol {tcp,udp,icmp,any}]
                                    FIREWALL_RULE

Example:

neutron firewall-rule-update --protocol tcp r1
  • Update firewall policy


usage: neutron firewall-policy-update [-h] [--request-format {json,xml}]
                                      FIREWALL_POLICY

Example:

neutron firewall-policy-update --firewall-rules r2 p1
  • Update firewall
usage: neutron firewall-update -h [--request-format {json,xml}]
                               --policy POLICY
                               FIREWALL
                               --port-id <port_uuid>
                               --direction <inside|outside|both>

Example:


neutron firewall-update c34f68a0-efe9-484a-8a37-63dd5e06b2e2 --port-id e3103dba-3aa9-4ec0-a152-306ed7f38677 --direction inside
  • List firewalls rules, firewall policies, firewalls*
neutron firewall-rule-list
neutron firewall-policy-list
neutron firewall-list
  • Show firewall rule, firewall policy, firewall*
neutron firewall-rule-show <rule_uuid or rule_name>
neutron firewall-policy-show <policy_uuid or policy_name>
neutron firewall-show <firewall_uuid or firewall_name>

Cisco VPNaaS

Introduction

VPNaaS is an OpenStack service that provides a site-to-site IPSec connection between two clouds. This gives tenants a way to establish a secure connection between a private subnet in one cloud, and a private subnet(s) in another cloud. The overview of VPNaas is at Topology Overview

'Note: It provides 1:N connectivity of subnets, over a single connection. Unlike the other services, this service involves two clouds and not one, so the VPN setup is done on each cloud.

Standard Installation:

For details on standard installation see Perform the following for Red Hat, Ubuntu and RDO installations

For the neutron.conf file, the VPN plugin needs to be added to the list of service plugins:

  • service_plugins =
neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron_vpnaas.services.vpn.plugin.VPNDriverPlugin,neutron_fwaas.services.firewall.fwaas_plugin.FirewallPlugin
  • For the neutron_vpnaas.conf file we need to uncomment (only) the service driver for the CSR:
service_provider=VPN:cisco:neutron_vpnaas.services.vpn.service_drivers.cisco_ipsec.CiscoCsrIPsecVPNDriver:default
  • For the vpn_agent.ini file we need to make sure the Cisco device driver is uncommented:
vpn_device_driver=neutron_vpnaas.services.vpn.device_drivers.cisco_ipsec.CiscoCsrIPsecDriver

Use neutron commands (CLI or via Horizon) to create the router (CSR based), public/private network, public/private subnet, and floating IPs for use on public network.

DevStack Installation

For instructions on how to set up a CSR to provide site-to-site IPSec VPNaaS for an OpenStack cloud computing environment, using the Cisco Kilo and Juno+ OpenStack repositories, see [| DevStack Installation]

Setting Up Devstack in Kilo

This page describes how create and run a Devstack setup with that Cisco Cloud Service Router 1000V (CSR1kv) routing service plugin for the OpenStack Kilo release.


Note: Devstack is a constantly evolving set of bash scripts used to build a complete Openstack environment. The primarily targeted user group is openstack developers.

While Devstack is very useful, its high rate of change means that you will sometimes encounter problems.

Understanding of DevStack and various tools, including pip and apt-get, is essential to efficient use of DevStack. If you are not comfortable with these tools then you will probably have limited success running the CSR plugin using what is, after all, a development environment.

Ubuntu Devstack Installation and Setup for CSR1kv with N1kv

Prerequisites

The host on which you install DevStack must meet the following prerequisites:

  • The server must be running one of the two operating system flavors as the host OS
  • Ensure that any previous DevStack run is removed. In particular, ensure that any Openvswitch (OVS) or Linux bridges (and ports on such bridges) are removed.
  • The Ubuntu NetworkManager service should not be running on the host. NetworkManager attempts to manage the virtual interfaces that N1KV creates and that leads to installation failure. It is best to stop (and probably remove NetworkManager) by entering the following:
sudo service network-manager stop

Warning: Network manager can be completely removed by sudo apt-get purge network-manager. Stopping the NetworkManager service causes the host to lose network connectivity. Connectivity can be restored by editing the /etc/network/interfaces file appropriately for your interfaces (typically eth0) and then bring it up by sudo ifup eth0

Installation

Follow this procedure to install and configure DevStack with the CSR routing service plugin.

Step 1. Download the DevStack branch from the csr1kv_for_routing_kilo_minimal Cisco Devstack repo:

Step 2. Download the Neutron master branch from the Openstack Neutron repo on Github

* git clone https://github.com/openstack/neutron

Step 3. Obtaining Images N1kv VSM, VEM and CSR1kv

Obtain the N1kv VSM and VEM from the “Nexus 1000V switch for KVM” in Cisco.com Downloads

We have tested with the following:

VSM:

n1000v-dk9.5.2.1.SK1.3.0.135.iso
n1000v-dk9.5.2.1.SK1.3.0.124.iso
n1000v-dk9.5.2.1.SK1.3.0.105.iso

VEM:

nexus_1000v_vem-12.04-5.2.1.SK1.3.0.135.S0-0gdb.deb
nexus_1000v_vem-12.04-5.2.1.SK1.3.0.124.S0-1gdb.deb
nexus_1000v_vem-12.04-5.2.1.SK1.3.0.105.S0-4.deb

To obtain a CSR1000v software, go to the Cisco.com CSR1000v section: Downloads. On the right side under Support, select Download Software for this Product, select Cloud Services Router 1000V in the third pane on the right. Under Select a Software Type, select IOS XE software. Select the Cisco CSR 1000V Series Advanced Enterprise Services - QCOW2 image and then download. Please note version 3.14 or later CSR images (qcow2) are required.

Step 4. Select and edit the localrc file. There are three localrc files in the devstack branch. We recommend you use localrc.n1kv_and_csr1kv, which starts a full DevStack instance with all services and with the n1kv plugin.

Copy this file to ~/localrc and make the changes noted in the file.

A sample localrc file is available at :https://github.com/CiscoSystems/devstack/blob/csr1kv_for_routing_kilo_minimal/localrc.n1kv_and_csr1kv

Set the values of Q_CISCO_PLUGIN_VSM_ISO_IMAGE, Q_CISCO_PLUGIN_UVEM_DEB_IMAGE, Q_CISCO_CSR1KV_QCOW2_IMAGE to point to the location of the software you downloaded in step 3. Make sure all the unset values are set. Examples are provided via comments.

Step 5. Update environment variables

If you have your setup running through a proxy server, you will need to set the following environment variables. You will need to substitute your sever IP address for 172.19.148.60. You can also add the following to your localrc.


export PROXY_HOST=proxy.esl.cisco.com:80 (Note:proxy.esl.cisco.com:80 is an example. Please change it to something appropriate for your environment)

export https_proxy=https://$PROXY_HOST)

export http_proxy=http://$PROXY_HOST

export ftp_proxy=http://$PROXY_HOST

export HTTPS_PROXY=https://$PROXY_HOST

export HTTP_PROXY=http://$PROXY_HOST

export FTP_PROXY=http://$PROXY_HOST

printf \-v csr_ips '%s,' 10.0.100.\{1..100\};

export no_proxy="cisco.com,172.19.148.60,localhost,127.0.0.1,192.168.168.2,$\{csr_ips%,\}";


Step 6. Run the stack script:

./stack.sh

Once stack completes, you should have a working environment. The local.sh script automatically runs the configuration scripts needed to create the L3 Admin Tenant, the management network, register images, flavors, and so on.

Note: If you encounter problems, see the Troubleshooting section below.

Ubuntu Devstack Installation and Setup for CSR1kv with OVS/ML2

The instruction for installation and setup are at http://wikicentral.cisco.com/display/OPENSTACK/Installation+Instructions+for+CSR+with+ML2

Troubleshooting

Some common issues encountered during devstack installation are discussed here: Troubleshooting

Reference Information

TODO: OS link, VPN APIs, CSR pages,...

Reference Information

Rating: 4.0/5 (1 vote cast)

Personal tools