The Cisco Virtual
Topology System (VTS) is a standards-based, open, overlay management and
provisioning system for data center networks. It automates DC overlay fabric
provisioning for both physical and virtual workloads.
Cisco VTS provides a
network virtualization architecture and software-defined networking (SDN)
framework that meets the requirements of multitenant data centers for cloud
services. It enables a policy-based approach for overlay provisioning.
Cisco VTS automates
complex network overlay provisioning and management tasks through integration
with cloud orchestration systems such as OpenStack and VMware vCenter and
abstracts out the complexity involved in managing heterogeneous network
environments. The solution can be managed from the embedded Cisco VTS GUI or
entirely by a set of northbound Representational State Transfer (REST) APIs
that can be consumed by orchestration and cloud management systems.
Cisco VTS provides:
standards based solution
Cisco Nexus 2000,
3000, 5000, 7000, and 9000 Series Switches. For more information, see Supported
(Virtual Topology Forwarder [VTF])
VTS performs the
role of an overlay orchestrator in data-center networks. In this role, it
manages configuration on the data center leaf and spine devices. The
configuration of the devices is dependent on the type of overlay service that
the Cisco VTS user intends to create. The Cisco VTS user in this context could
either be manual users interfacing via GUI or APIs, or could be virtual machine
managers like OpenStack or vSphere. Since the device configuration is derived
from overlay service instances, Cisco VTS holds the ‘desired’ device
configuration in its database.
Whenever, there is
a change to the overlay service instances, it generates desired device
configuration and applies them to the relevant set of devices. This is the
prime functionality of an orchestrator. Changing any of the device
configuration outside of Cisco VTS (For example, using CLI or other
programmatic interfaces to the device), can result in service disruption. Hence
Cisco VTS always reconciles its view of the device configuration and pushes
that to the devices. Cisco VTS holds the master database of all device
configuration in the fabric.
However, there are
some practical use cases where Cisco VTS accommodates out-of-band device
- Day0 underlay
configuration—Cisco VTS is an overlay manager, but overlays cannot be
established without an underlay. Underlay configuration on each leaf/spine
device is unique. Typically, such underlay configuration is laid out even
before Cisco VTS can manage the overlays. Assuming all the devices in the
fabric are physically connected, the data center administrator establishes the
underlay configuration by manually connecting to the devices and configuring
them OR using an underlay manager to perform this. When Cisco VTS performs a
scan of the fabric inventory and discovers the topology, it is expected that
all the underlay configuration has been fully established. At this point, Cisco
VTS treats all the pre-existing device configuration to be Day0 configuration.
Day0 configuration is synced up from the devices and stored in VTS database as
a baseline. All overlay service configuration is built on top of this day-0
- DayN underlay
configuration—While Cisco VTS manages overlay specific device configuration,
there is always the need for the fabric operators to customize device underlay
configuration. Typical operations include physical link management, applying
link specific features, managing underlay routing protocols and setting up the
security. Recognizing this need, Cisco VTS supports the concept of 'device'
templates. These are essentially device configuration parameters exposed to the
VTS user using GUI/APIs. VTS users can customize device configuration using
device templates and use that to create the consolidated device configuration.
- DayN overlay
configuration—While the overlay specific configuration pushed by Cisco VTS is
sufficient to establish overlays, every deployment may require some
customization around this configuration. Since VTS holds the master device
configuration, it is essential that any customization flows through Cisco VTS.
To address this, Cisco VTS supports the concept of a 'service' template.
Service templates allow the Cisco VTS user to extend the service specific
device configuration via GUI/API.
templates always 'augment' the configuration. They cannot modify or remove
configuration that is constructed by the VTS service layer.
We recommend that
you do not modify device configuration outside of VTS. Doing so, can result in
misconfiguration of devices and will result in service outage. If there is a
real need to do so, you may follow one of the three models of device
configuration to achieve the desired customization.