Skip links

Tag: vsc

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: /network_debug_troubleshooting.html#unable-to-open-shell There are several other Forum topics on this error. For example: But this case was a bit different. This case was caused by

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 or lab/test setup. Modifying the

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 your Croxley deployment: # <

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: [ -> localhost]: FAILED! => {     “changed”: false,     “failed”: true,     “msg”: “unable to open shell. Please see:” } If you follow the URL provided in the

Converting from build_vars.yml to deployments for Croxley

With the introduction of Croxley, MetroÆ supports a new, schema-validated method of user input. The implementatino is such that now each section of the old build_vars.yml file now has its own file: vsds.yml vscs.yml common.yml and so on As an aid to hep you convert from the older format to