ANK |
VIRLDEV-4878 |
IOSvL2 generated config inconsistent. In IOS (XE, XR, NX-OSv) we
have (or equivalent):
username cisco privilege 15 secret cisco
line vty 0 4
login local
this is missing in the IOSvL2 configuration and might cause
automation tools to fail if they assume that logging in using
'cisco/cisco' gives them automatic privilege level 15
('enabled') access.
Workaround: Add the configuration manually, if needed.
|
ANK |
VIRLDEV-4739 |
ANK creates an exception when trying to generate a VRF
configuration for NX-OSv and NX-OSv 9000: "Error generating
network configurations: 'dict' object has no attribute 'vrf'.
More information may be available in the debug log." This is a
known limitation in ANK.
Workaround: None.
|
BBE |
VIRLDEV-5159 |
The browser based editor might occasionally generate invalid CML
files. This has been observed with large topologies (hundreds of
nodes). In such a case, the CML server refuses to start the
topology.
Workaround: Double check the generated links or use VM
Maestro.
|
BBE |
VIRLDEV-3730 |
Topology is not loading in browser based editor when remote .virl
file option is selected. Files can be located on Git or via an
arbitrary URL.
Workaround: Save the file locally first.
|
BBE |
VIRLDEV-6066 |
The Browser-Based Editor (BBE) does not support IOS XRv 9000
nodes. If a topology uses an IOS XRv 9000 node, attempting to
open the topology in the BBE results in a blank page. No
topology is shown on the canvas.
Workaround : Use VM Maestro if you need to use IOS XRv
9000 nodes.
|
STD |
VIRLDEV-4877 |
With CML 1.3, the product is restricted to a single project and
user. This change manifests in two areas:
-
removal of 'Add' and 'Import' buttons for project and
user creation
-
ability to run simulations of multiple projects at the
same time
This change is in line with the positioning of the 'personal
edition' where the product is designed to be used by individuals
('single user').
|
STD |
VIRLDEV-4468 |
In situations with low free disk space, CML core software
upgrades might fail. This is also dependent on the size of the
configured Cinder file (block storage for VM images). The default
for that file is 20GB.
Workaround: Ensure that enough disk
space is available.
|
STD |
VIRLDEV-5042 |
Very large topologies between 100 and 300 nodes might misbehave
when leaving ANK configuration generation parameters at default
which produces huge topology files due to generation of a full
iBGP mesh. This can manifest in:
-
timeouts while waiting for ANK to generate the
topology
-
errors when displaying configuration differences in VM
Maestro
-
errors when downloading the resulting topology file in VM
Maestro or in UWM
-
runtime errors where nodes might not be coming up or put
too much strain on system resources due to unrealistic
configurations.
Example: A 300 node topology with default ANK settings
will produce 300x300 = 90,000 iBGP configurations for the
topology which will result in a >>10MB topology file.
Workaround: If ANK configuration generation is required,
it is suggested to use valid constraints like multiple ASs,
route reflectors and other means to split the simulation domain
into more manageable chunks.
Note that even if you are not using ANK to generate full
configurations, it is still possible to generate IP addresses
and default accounts but not full configurations by running ANK
in "infrastructure only" mode. In the UI, click on the topology
background, and set the "Infrastructure Only" property to true
in the topology's AutoNetkit page in the Properties view before
invoking ANK to Build Initial Configurations.
|
STD |
VIRLDEV-4345 |
Connecting to statically assigned console ports is slow when
accessing these ports in fast sequence (as with SecureCRT
opening a set of ports at the same time).
Workaround: Manually open the ports in sequence.
|
STD |
VIRLDEV-4588 |
Docker image names cannot contain upper case letters.
Workaround: Use lower case image names
|
STD |
VIRLDEV-4710 |
The rules governing the effective name of an LXC image are not
consistent between creation, modification, and use in the
simulation. The name is produced as a combination of the owning
project, subtype name, and version suffix set by the user when
the image is created. The use of subtype name can be overridden
by the subtype definition's baseline_image attribute, usually to
make use of a different subtype's installed images by that
subtype.
Workaround: Do not set this property for custom LXC
subtypes. It is also recommended that an LXC image, when being
added, is not marked for use by a specific project, and that the
Modify container function is not used to alter the suffix of the
name.
|
STD |
VIRLDEV-4819 |
Machines with high CPU count might require a different amount of
database and front-end processes to be able to deal with
requests.
Symptoms of the issue can be:
By default, the values are set for small machines which should be
fine for CMLrsonal edition. CML has the ability to adjust these
settings based on built-in empirical values which are applied
whenever a rehost is run.
Alternatively, run ' salt-call -linfo state.sls
openstack.worker_pool ' or use the
virl_setup script, menu item 'Maintenance
→ 3 Reset OpenStack worker pools'.
|
STD |
VIRLDEV-5326 |
Docker by default creates SNAT / MASQUERADING iptables entries
for the default docker0 bridge. This can interfere with
simulation network traffic when used IPv4 networks are
overlapping.
The default 172.17.0.0/16 masquerading entry has been removed.
However, there is at least one entry left for the Docker
registry with a /32 address which cannot be used in any
simulation.
Workaround: Don't use the 172.17.0.0/16 network whenever
possible. Check the masqueraded IP addresses currently in use by
the local registry by typing sudo iptables -L -v
-tnat
Example (excerpt):
0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:5000
|
STD |
VIRLDEV-5360 |
When configuring 'logging console' in cases where neither the
Jumphost nor the LXC Management node are available (e.g. off),
configuration extraction may fail due to unexpected output as
the extraction mechanism is falling back to use theconsole.
Also, configuration extraction might fail when consoles are
opened via UWM.
Workaround: Don't configure any logging on the console
and / or don't turn off the management LXC / Jumphost. Don't
have consoles open via UWM when extracting configurations.
|
STD |
VIRLDEV-5365
|
When the local time of the host computer that runs the VM is in a
timezone >0 (e.g. east of Greenwich), NTP might step the
clock back at system start which might confuse STD and therefore
results in a licensing issue due to invalid time.
Workaround: Restart STD/UWM using sudo salt-call
-linfo state.sls virl.restart
|
STD |
VIRLDEV-5387 |
NTP does not sync under certain circumstances. If this happens,
please contact the Cisco Technical Assistance Center (TAC).
Workaround: Restart NTPd using sudo systemctl
restart ntp , check with ntpq -p.
Sometimes, it was sometimes necessary to kill the nptd process
manually:
sudo systemctl stop
ntp killall ntpd
sudo systemctl start
|
STD |
VIRLDEV-6250 |
In version 1.5.145, the CML back end does not respect the
virl_local_ip setting when reporting its IP
address in web service responses.
Background : You would use virl_local_ip
if you're running your CML server behind a firewall that does
NAT. While you can configure VM Maestro's web services to use
the CML server's public IP address, the web services responses
from the back end will reference the CML server's primary
interface's (private) IP address. One symptom is that VM Maestro
will be able to launch a simulation, but then it will be unable
to telnet to the devices in the simulation because it's trying
to connect to CML server's private IP address. (You will also
see the CML server's private IP address in the Connect to...
menus in VM Maestro when you right-click on a node in a running
simulation.) To solve this problem in earlier CML 1.3, you could
set the virl_local_ip property to the CML
server's public IP address. In web service responses, the CML
server would use the value of the virl_local_ip
property instead of its primary interface's IP address.
How to check? The virl_local_ip property
has never been exposed in the UWM's System Configuration pages.
If you are not sure whether you're using the
virl_local_ip property, you can check:
-
Log in to the CML server's console (SSH to the system or
open the Console in VMware).
-
Run the following commands
crudini --get /etc/virl/virl-core.ini DEFAULT virl_local_ip
crudini --get /etc/virl/virl.cfgi DEFAULT virl_local_ip
-
If those commands return no output at all, then you are
not using virl_local_ip,
-
If those commands return one or more lines that include
the virl_core_ip property, then you are using the
virl_local_ip feature.
Workaround : None. If you need to use this setting, do
NOT upgrade to CML 1.5 at this time. Cisco is planning
to release a bug fix update to the 1.5 release to address this
problem. Once that update is available, you will be able to
upgrade to 1.5 without losing the functionality provided by the
virl_local_ip property.
|
STD |
VIRLDEV-5415 |
Multiple CML instances should not be connected to the same
FLAT/FLAT1 network segment as MAC address clashes can occur for
IOSv-L2 VMs in that case due to MAC address
handling for those VMs.
Workaround: If you would like to run multiple CML
installations on the same FLAT segment, and you would like to
run simulations using the FLAT management setting, set the
decimal value for the new configuration key to a different value
for each installation that shares the FLAT segment:
sudo crudini --set /etc/virl/virl-core.ini orchestration first_mgmt_mac_byte $((0x5a))
sudo service virl-std restart
The '$((0x5a))' is translated by bash into 90. The default is 94
(0x5e).
Constraints on the value of first_mgmt_mac_byte:
|
STD |
VIRLDEV-6187 |
Default cluster network settings are not configurable in a
non-cluster installation. A cluster (internal) network is used
and configured on interface br4 of all CML hosts, with a /24
subnet that defaults to 172.16.10.0/24. In case that default
network is being used in the customer's network, and the CML
host needs to interact with hosts in this network, the user
should be allowed to change the default cluster network even in
a non-cluster installation.
Workaround : Configure the CML installation as a cluster
with zero compute nodes. It will effectively function as a
standalone installation, but it will permit you to customize the
cluster network configuration settings.
|
Live Vis |
VIRLDEV-5085 |
In LiveVis, when selecting the 'Clear Log' option a pop-up
message might include a "Prevent this page from opening
additional dialogs". If the user selects that option may prevent
the system from collecting further log messages. This is a known
issue and it is also browser dependent.
This image virl-1-3-live-vis-clear.png is not available in
preview/cisco.com
Workaround: Do not select this option when offered by
the browser.
|
Live Vis |
VIRLDEV-4899 |
Downloading the Syslog as CSV from within Live Vis is not working
on Safari and results in a page error. This is a known
limitation with the Safari browser.
This image virl-1-3-live-vis-download-csv.png is not available in
preview/cisco.com
Workaround: Use a different browser like Firefox or
Chrome.
|
Live Vis |
VIRLDEV-4898 |
Extracting configurations from a running topology within Live
Visualization is not working as expected when using Safari. The
document returned is shown as XML text, rendered in the browser
and is not offered to 'save' into the Downloads folder. This is
a known limitation.
Workaround: Use a different browser like Firefox or
Chrome or save the resulting XML text manually into a .virl
file.
|
Live Vis |
VIRLDEV-4698 |
In Live Visualization, NX-OSv interfaces are listed twice in the
interface table, one time showing IP, other showing None. When
retrieving the interface table from an NX-OSv device, some entries
show twice in the output. This is only cosmetic and might cause a
spurious extra line being drawn.
|
Live Vis |
VIRLDEV-4223 |
Live Visualization might not work properly when changing the UWM
port. UWM offers the ability to change it's listening port from
19400 to another port. When doing so, this might have side
effects in Live Visualization.
Workaround: Do not change the UWM port.
|
Live Vis |
VIRLDEV-4202 |
The overlay menu button to switch among different overlays might
get blocked after updating Live Vis Web server port. In UWM, it
is possible to change the Live Vis Web server port from 19402 to
a different port. This might result in a blocked overlay menu
button (not showing any entries). The image below illustrates
the correct menu behavior whereas when broken, the entire drop
down part of the menu is missing.
This image virl-1-3-live-vis-physical.png is not available in
preview/cisco.com
Workaround: None
|
Live Vis |
VIRLDEV-4695 |
In Live Visualization, the 'Physical Live' Overlay does not
correctly show physical links for XRv nodes. This is a known
defect.
Workaround: None
|
Live Vis |
VIRLDEV-4306 |
IOS XRv 9000 is not fully supported in Live Visualization.
Workaround: None
|
Live Vis |
VIRLDEV-4922 |
In Live Visualization, the 'Collect Log' action fails for
NX-OSv.
Workaround: None
|
Live Vis |
VIRLDEV-4949 |
Sometimes, BGP VPNv4 links are not being drawn in Live
Visualization.
Workaround: None
|
Live Vis |
VIRLDEV-4342 |
Large (80-300+) topologies might not render properly and perform
slower than expected in Live Vis. Workaround: None
|
Live Vis |
VIRLDEV-5035 |
Live Vis does not fully support NX-OSv 9000.
Workaround: None
|
UWM |
VIRLDEV-5061 |
Preview of a topology before launching the simulation does not
render properly with certain browsers. This happens with Windows
and Internet Explorer. IE is not a supported browser.
Workaround: Switch to Chrome or Firefox to prevent the
issue from showing.
|
UWM |
VIRLDEV-2167 |
When importing projects into the system, the uwmadmin password in
virl.ini was out of sync with the database. To avoid this issue,
the uwmadmin project is skipped when importing projects into the
system.
Workaround: Manually change the password after importing
to get the correct password into the system.
|
UWM |
./. |
When configuring networks in UWM, OpenStack Neutron networks may
not be created OK when configuring the same name server twice
(identical name servers)
Workaround: You must choose different name servers.
|
UWM |
VIRLDEV-6084 |
Some updates may fail if more than one update process is run at
the same time.
Workaround : Only run one update process at a time.
System update processes include updates applied in the UWM pages
For example, do not run two separate CML Software updates at
once, and do not run a CML Software update at the same time as a
System Configuration change is being applied.
|
UWM |
VIRLDEV-6097 |
If the maintenance mode is enabled, and the admin tries to
upgrade LXC images via the page, the upgrade will fail with an error.
Workaround : disable maintenance mode before going to the page.
|
UWM |
VIRLDEV-6249 |
If you have a CML cluster controller configured with cluster
enabled but no compute nodes associated with the controller,
some changes will report job failures as part of the
change. These system configuration changes are trying to push
configuration changes to the cluster compute nodes without
checking first whether there are any cluster compute nodes
available.
Workaround : None. If no cluster compute nodes are
configured, it is safe to ignore the failure of jobs related to
making changes on the compute nodes.
|
UWM |
VIRLDEV-6261 |
In the page, there is a list of packages to install in
the first table. If you select all on that first table
and then press the Upgrade button, the request will be
denied with an HTTP 400 error.
Woarkaround : This error is triggered by bad behavior of
the
select all functionality on that table. Selecting
packages individually works as expected.
|
UWM |
VIRLDEV-6271 |
When making changes, attempting to change the primary project
name at the same time as attempting to make the other system
configuration changes will cause those other system
configuration changes to fail.
Workaround : when changing the primary project, just make
that one change. Once the primary project has been changed, you
may return to the UWM to make the other system configuration
changes.
|
VM Maestro |
VIRLDEV-4434 |
In VM Maestro, use external browser for both ANK vis and Live
Vis. We've had reports about using the internal browser for ANK
and Live Visualization from within VM Maestro.
This image virl-1-3-vmm-web-browser.png is not available in
preview/cisco.com
Workaround:
Use an external browser, configure as shown above.
|
VM Maestro |
./. |
Terminal preference for detached internal terminals - this
function has been deprecated in VM Maestro 1.2.4 onwards.
Workaround : You can manual 'tear' the terminal pane from
the main VM Maestro window. Use this in conjunction with the VM
Maestro preference (Cisco terminal) - "multiple tabs for one
simulation".
|
VM Maestro |
VIRLDEV-3525 |
In VM Maestro (1.2.8 build 474), the scroll bar in the dialog doesn't work properly on OS X 10.11 and
newer.
This image virl-1-3-vmm-osx-scrolling.png is not available in
preview/cisco.com
Workaround: Configure scroll bars to 'always show' in the
General section of the System preferences as shown above.
|
VM Maestro |
VIRLDEV-4680 |
Under rare circumstances, the Telnet menu is missing on a few
nodes in the simulation
Workaround: None
|
VM Maestro |
VIRLDEV-4820 |
Occasionally, the message 'Unexpected end of input
within/between OBJECT entries' can observed in VM Maestro's
Simulations panel. This is mostly cosmetic as it
recovers automatically.
Workaround: None
|
VM Maestro |
VIRLDEV-5042 |
While running ANK, when clicking 'yes' on "View configuration
changes dialog" the dialog disappears resulting in 'Unable to
connect to Vis Server' error in console. This happens for large
topologies.
Workaround: None
|
VM Maestro |
VIRLDEV-6061 |
If a node is part of a site when the network simulation is
launched, you cannot start a traffic capture on the node.
Workaround : before launching the simulation, ungroup the
site. That is, select the site and select from the main menu before launching a simulation
with the topology.
|
VM Maestro |
VIRLDEV-6288 |
Sometimes, installing a new version of VM Maestro on an OS X
system that already has VM Maestro installed leads OS X to
report that the application is damaged.
This image vmm_is_damaged.png is not available in
preview/cisco.com
Workaround:
1) The most likely cause of that error on OS X is a combination
of OS X’s default security settings, lack of signing of the OS X
version, and some terrible error reporting from OS X. Try
this:
-
Open the OS X System Preferences
-
Click Security & Privacy
-
Click General.
-
If necessary, click the little lock on the bottom to
unlock the page.
-
Switch the option to say “Allow apps downloaded from”
> Anywhere.
-
Close the Security & Privacy dialog
-
Now try to launch VM Maestro.
-
If that works, you can now go back and change your
Security & Privacy setting back to their
defaults.
Unfortunately, since Sierra, that Security & Privacy dialog
no longer shows in the security preferences. In that case, your
options are:
|
VMs |
VIRLDEV-3616 |
When running ASAv nodes using the bundled ASAv image, the
console of the ASAv is bound to the serial port. By default,
'vanilla' ASAv images downloaded from CCO are having their console
bound to the 'VGA' screen which is accessible in CML using the VNC
option. However, access to the console is EITHER on the
serial port OR on the VGA screen, never both. Since it is not
known where the console is bound to (serial or VGA), both options
are offered to the user but only one option will succeed.
|
VMs |
VIRLDEV-5092 |
NX-OSv / NX-OSv 9000 nodes remain UNREACHABLE and connect to
monitor port doesn't connect.
-
NX-OSv (Titanium) nodes might not be available on the
management interface. This is a reference platform issue
where sometimes the Mgmt0 interface is stuck in
'down/up' state. E.g. the interface is 'admin up' but
the link is indicated as 'down'.
Workaround: Manually issue a 'shut / no shut'
sequence on the management interface of the affected
node
-
NX-OSv 9000 nodes create unnecessary broadcast traffic on
the management interface. This is a reference platform
issue where NX-OSv 9000 nodes respond to frames not
owned by the node which might result in a broadcast
storm of IP redirect packets on the management
network.
Workaround: Configure 'no ip directed-broadcast'
on the management interface of NX-OSv 9000 nodes.
-
NX-OSv 9000 nodes occasionally (less than 5 in 100
launches) do not become reachable even with the
aforementioned workaround. A restart of the affected
node usually resolves this.
|
VMs |
VIRLDEV-4682 |
The subtype for Ostinato has changed between OpenStack Kilo and
OpenStack Mitaka. When upgrading to CML 1.3 from 1.2 and thus
staying on the OpenStack Kilo release, the Ostinato 0.8.1 image
will not be used due to the mismatch in the subtype
(lxc-ostinato vs. lxc-ostinato-drone).
Workaround: Change subtype for affected nodes to
'lxc-ostinato-drone'
|
VMs |
VIRLDEV-4955 |
IOS XRv 9000 duplicate management IP configuration. IOS XRv 9000
nodes acquire the same IP for both the XR operating system layer
and its associated management interface as well as for an
underlying Linux layer which uses the same 'physical'
interface.
Workaround: None
|
VMs |
./. |
IOSv 15.6(2)T - On boot-up the following (similar) message may be
observed:%SYS-3-CPUHOG: Task is running for (1997)msecs, more
than (2000)msecs (0/0),process = TTY Background.-Traceback=
114ECF8z 130425z 15E20Ez 15DF30z 15DD3Dz 157D75z 158A2Bz 1589BFz
159B67z 153672z 3C9740Az 3C868CEz 3C89BEFz 5125F91z 491D86Cz
492E540z - Process "Crypto CA", CPU hog, PC 0x00157D2C
Workaround: This is cosmetic and can be ignored.
|
|
./. |
Versions older than of NX-OSv 9000 7.0.3.I6.1 require 8GB of
memory. Starting with the I6 release, the memory footprint has
been reduced to 4G.
Workaround: When installing the image, a flavor with 4GB
is created. When using an older version, make sure to create and
assign the appropriate flavor which allocates 8GB of memory.
|
|
./. |
When IOS XRv 9000 is booting, if you enter text at the console,
the boot will drop to a CLI login prompt for the admin user.
This prompt prevents the pre- blocks CVAC, causing initial
configuration application to be abandoned.
Workaround : Do not open a console until the node becomes
reachable, or don't enter any text into the console (not even
enter to check if any output will be generated), or enter a
valid pair of credentials (which are named neither cisco nor
admin) as soon as the prompt appears.
|
|
VIRLDEV-6074 |
CML has provided support for a reference platform image based on
the Nexus 9k code since December 2016. This subtype for this
image is NX-OSv 9000. Cisco has changed the name of this image
to Nexus 9000v. CML has no Nexus 9000v subtype.
Workaround : None. Just use the NX-OSv 9000 for Nexus
9000v images.
|
|
VIRLDEV-6416 |
Default NX-OSv 9000 memory allocation is not sufficient. When
launching a topology simulation that uses multiple NX-OSv 9000
nodes, some of them will fail to boot.
The "flavor" used by default for NX-OSv 9000 was changed to use 4
GB of RAM with the release of NX-OSv 9000 version 7.0.3.I6.1,
but that memory allocation has proved to be too small in
practice. We continue to work with the Nexus team to determine
optimal default resource settings for NX-OSv 9000 and the other
router VM images, and future releases of CML will increase the
memory allocation for the default NX-OSv 9000 flavor.
Workaround : If you need to use NX-OSv 9000 nodes now, we
recommend replacing the NX-OSv 9000 flavor with a new flavor
that has a larger memory allocation.
-
Login to the UWM as the uwmadmin, and navigate to .
-
Click the Delete icon in the
Options column for the NX-OSv
9000 flavor to delete the default flavor.
-
Click the Add button to add a new
flavor.
-
On the Create Flavor form, enter the values
-
Name: NX-OSv 9000
-
RAM (MB): 6144
-
Virtual CPUs: 2
-
Disk (GB): 0
-
Click the Create button.
Simulations that you launch after making this change will use the
new flavor and the 6 GB memory allocation for all NX-OSv 9000
nodes.
|