Skip links

Author: Brian Castelli

Essential Information about MetroAE Features

MetroAE v4.0 is officially here! It is available in both container and GitHub repo forms. Some of the bigger changes: No more MetroAE RPM for container management. Just grab the ‘metroae’ script from the repo, copy it to your Docker host, and run. If you

Docker CE

In my testing of the new MetroAE Croxley container deployment on CentOS 7, I have found the following installation instructions for Docker CE to be accurate and reliable: https://docs.docker.com/install/linux/docker-ce/centos/ Docker Community Edition (CE) is ideal for individual developers and small teams looking to get started

vsc_health: Get output of ‘show version’ failed: unable to open shell

We recently saw a user encounter this error when running vsc_health prior to upgrading an existing installation of VSP: unable to open shell. Please see: https://docs.ansible.com/ansible /network_debug_troubleshooting.html#unable-to-open-shell There are several other Forum topics on this error. For example: https://devops.nuagenetworks.net/forums/topic/unable-to-open-shell-error-take-2/. But this case was a bit different.

Q&A: Command to launch the Docker MetroAE Container

Question In the GitHub repo the DOCKER.md refers to the metroae command being used to launch the container as well as initiate automation deployments and workflows within. How can the container be launched from the command line with command examples? Answer When you run the

Can’t find id_rsa.pub error

We recently had a report of the following error during vsd-predeploy: TASK [vsd-predeploy : Get the public key for the current user] ************************************* fatal: [vsd1.xlelab.lab -> localhost]: FAILED! => {“changed”: true, “cmd”: [“cat”, “~/.ssh/id_rsa.pub”], “delta”: “0:00:00.022623”, “end”: “2018-10-09 10:57:24.514944”, “failed”: true, “msg”: “non-zero return code”,

Unable to open shell error: take 2

Have you seen this error? unable to open shell. Please see: https://docs.ansible.com/ansible /network_debug_troubleshooting.html#unable-to-open-shell We’ve written previously about a few ways to handle the situation when MetroÆ hits a problem connecting to the VSC using the Ansible sros_command and sros_config modules. The other topic focuses on making sure that you

Public key for .rpm is not installed

As part of the installation of VRS on Linux compute blades, MetroAE follows best practices and executes a yum update. It also installs mandatory prerequisite packages that VRS software requires. Under certain conditions, we have found that the package updates fail with an error message of

fallocate: Operation not supported

The VSP Install Guide makes a best-practice recommendation to use the fallocate command on a Linux hypervisor when copying the qcow2 image file. fallocate will tell the file system on the hypervisor to pre-allocate disk space for the file, preventing a potential out-of-space error as the qcow2 grows. The

Accessing MetroÆ behind a firewall

You can download MetroÆ from github.com as a zip file. It is just over 2 MB in size. scp the file to your MetroÆ host and unzip it. That will get the latest MetroÆ code into your server without Internet access. netaddr andn other packages

Can’t use jinja2 in deployment files

We recently saw a problem where a user was having trouble doing an install via ./metroae install_everything. The problem: metroae was completing without doing anything. In the output, every component type displayed a message like this: [WARNING]: Could not match supplied host pattern, ignoring: vstats PLAY

Invalid data failure: What is required input data?

We recently had a user stumble over input data validation. In MetroAE v3, all input data in your deployments folder is schema validated. This means that every file in your deployment must conform to the schema. This includes required data. In the case under discussion,

Not enough memory on KVM

Our lab machines tend to have small memory sizes. When we do our testing, we often ‘cheat’ by allocating less RAM for Nuage VMs that we spin up on hypervisors. This is *Not* acceptable in a production environment, but can be useful in a PoC

libvirt Error reading QCOW2: Permission denied

We faced a scenario in our lab that may be of interest to some of you. We re-purposed an old bare-metal server running CentOS 7.3 as a hypervisor/target server for a MetroÆ test. On our first attempt to install a VSD, we ran out of

Docker CE

In my testing of the new MetroAE Croxley container deployment on CentOS 7, I have found the following installation instructions for Docker CE to be accurate and reliable: https://docs.docker.com/install/linux/docker-ce/centos/ Docker Community Edition (CE) is ideal for individual developers and small teams looking to get started

TLS for VSC Connections to Forwarding Plane

By default, MetroAE will establish TLS OpenFlow channels from the VSCs to the forwarding-plane components, VRS and NSGv. TLS is required for NSGV/VNS, but not for VRS/VCS. In order to turn off TLS for your data-center VCS deployment, you would edit the following parameter in common.yml in

Unable to open shell error

We sometimes see an issue when running an install with MetroAE that results in the following error: 2018-10-27 15:42:48,890 p=17607 u=root |  fatal: [vsc2.mgmt.vnspoc.net -> localhost]: FAILED! => {     “changed”: false,     “failed”: true,     “msg”: “unable to open shell. Please see:https://docs.ansible.com/ansible/network_debug_troubleshooting.html#unable-to-open-shell” } If you follow

Setup error: network unreachable for pip

We recently saw a user experiencing an error running the MetroAE setup script: # ./metro-setup.sh Setting up Nuage Metro Automation Engine Checking user privileges…                                [  OK  ] Checking OS type…                                        [  OK  ] Checking OS version…                                     [  OK  ] Installing epel-release…                                 [  OK  ] Installing

vsd_health error on JMS: http instead of https

Recently, a MetroAE user reported seeing the following error when running vsd_health: TASK [vsd-health : Verify that JMS gateway is reachable on Master Node] ********fatal: [vsd1.nuagesdn.net -> localhost]: FAILED! => {“changed”: false, “content”: “”, “failed”: true, “msg”: “Status code was not [200]: Request failed: “, “redirected”:

Bitnami