The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
To install VTC VM on an ESXi host:
The vCenter plugin gets installed when you register the VMM from the Cisco VTS GUI.
Step 1 | Go to Administration > Virtual Machine Manager. | ||
Step 2 | Click the Add
(+) button.
The Register VMM page is displayed. | ||
Step 3 | Enter the VMM Details: | ||
Step 4 | Click
Register.
After the VMM is registered successfully, the Plugin sections opens up. | ||
Step 5 |
Enter the following in the Plugin details section:
|
The following points need to be taken care of while you create a vDS.
Note |
|
If you are using vPC on the leaves:
Step 1 | Create one vDS switch for one or more vPC pairs. |
Step 2 | Enable
enhanced LACP.
See VMware documentation for the detailed procedure. |
Step 3 | Create a Link
Aggregation Group for each vDS.
See VMware documentation for the detailed procedure. |
Step 4 | You may remove the default port group that gets created as it will not be used. |
The VTSR VM acts as the control plane for the VTF. You need to install VTSR only if you plan to have a VTF in your set up.
Installing VTSR involves:
Generating an ISO file. See Generating an ISO for VTSR, for details.
Deploying the VTSR on the VMM. See Deploying VTSR on OpenStack or Deploying VTSR on VMWare, for details.
To create an ISO for VTSR:
Note | For an HA installation, you need to create two ISOs and deploy them separately. If you are upgrading from 2.5.2 or 2.5.2.1 to 2.6.0. you need to generate VTSR ISO again. |
Step 1 | Go to /opt/cisco/package/vts/share. | ||
Step 2 | Make a copy of
the vtsr_template.cfg template and edit for your VTSR instance. A sample
vtsr_template.cfg file is given below:
# This is a sample VTSR configuration file # Copyright (c) 2015 cisco Systems # Please protect the generated ISO, as it contains authentication data # in plain text. # VTS Registration Information: # VTS_ADDRESS should be the IP for VTS. The value must be either an ip or a mask. # VTS_ADDRESS is mandatory. If only the V4 version is specified, # The V4 management interface for the VTSR (NODE1_MGMT_NETWORK_IP_ADDRESS) # will be used. If the V6 version is specified, the V6 management interface # for the VTSR (NODE1_MGMT_NETWORK_IPV6_ADDRESS) must be specified and will be used. #VTS_ADDRESS="172.23.209.17" VTS_IPV6_ADDRESS="fded:1bc1:fc3e:96d0::1000:17" # VTS_REGISTRATION_USERNAME used to login to VTS. VTS_REGISTRATION_USERNAME="admin" # VTS_REGISTRATION_PASSWORD is in plaintext. VTS_REGISTRATION_PASSWORD="Cisco123!" # VTSR VM Admin user/password USERNAME="admin" PASSWORD="cisco123" # VTSR VM Network Configuration for Node 1: # NETWORK_IP_ADDRESS, NETWORK_IP_NETMASK, and NETWORK_IP_GATEWAY # are required to complete the setup. Netmask can be in the form of # "24" or "255.255.255.0" # The first network interface configured with the VTC VM will be used for # underlay connectivity; the second will be used for the management network. # For both the MGMT and UNDERLAY networks, a <net-name>_NETWORK_IP_GATEWAY # variable is mandatory; they are used for monitoring purposes. # # V6 is only supported on the mgmt network and dual stack is # currently not supported, so if both are specified V6 will take priority (and # requires VTS_IPV6_ADDRESS to be set). # The *V6* parameters for the mgmt network are optional. Note that if V6 is used for mgmt # it must be V6 on both nodes. Netmask must be the prefix length for V6. #NODE1_MGMT_NETWORK_IP_ADDRESS="172.23.209.19" #NODE1_MGMT_NETWORK_IP_NETMASK="255.255.255.192" #NODE1_MGMT_NETWORK_IP_GATEWAY="172.23.209.1" NODE1_MGMT_NETWORK_IPV6_ADDRESS="fded:1bc1:fc3e:96d0::1000:19" NODE1_MGMT_NETWORK_IPV6_NETMASK="64" NODE1_MGMT_NETWORK_IPV6_GATEWAY="fded:1bc1:fc3e:96d0::1" NODE1_UNDERLAY_NETWORK_IP_ADDRESS="82.82.82.19" NODE1_UNDERLAY_NETWORK_IP_NETMASK="255.255.255.0" NODE1_UNDERLAY_NETWORK_IP_GATEWAY="82.82.82.1" # AUX network is optional #NODE1_AUX_NETWORK_IP_ADDRESS="169.254.20.100" #NODE1_AUX_NETWORK_IP_NETMASK="255.255.255.0" #NODE1_AUX_NETWORK_IP_GATEWAY="169.254.20.1" # XR Hostname NODE1_XR_HOSTNAME="vtsr01" # Loopback IP and netmask NODE1_LOOPBACK_IP_ADDRESS="128.0.0.10" NODE1_LOOPBACK_IP_NETMASK="255.255.255.255" # VTSR VM Network Configuration for Node 2: # If there is no HA then the following Node 2 configurations will remain commented and # will not be used and Node 1 configurations alone will be applied # For HA , the following Node 2 configurations has to be uncommented # VTSR VM Network Configuration for Node 2 # NETWORK_IP_ADDRESS, NETWORK_IP_NETMASK, and NETWORK_IP_GATEWAY # are required to complete the setup. Netmask can be in the form of # "24" or "255.255.255.0" # The first network interface configured with the VTC VM will be used for # underlay connectivity; the second will be used for the management network. # For both the MGMT and UNDERLAY networks, a <net-name>_NETWORK_IP_GATEWAY # variable is mandatory; they are used for monitoring purposes. # # V6 is only supported on the mgmt network and dual stack is # currently not supported, so if both are specified V6 will take priority (and # requires VTS_IPV6_ADDRESS to be set). # The *V6* parameters for the mgmt network are optional. Note that if V6 is used for mgmt # it must be V6 on both nodes. Netmask must be the prefix length for V6. #NODE2_MGMT_NETWORK_IP_ADDRESS="172.23.209.20" #NODE2_MGMT_NETWORK_IP_NETMASK="255.255.255.192" #NODE2_MGMT_NETWORK_IP_GATEWAY="172.23.209.1" NODE2_MGMT_NETWORK_IPV6_ADDRESS="fded:1bc1:fc3e:96d0::1000:20" NODE2_MGMT_NETWORK_IPV6_NETMASK="64" NODE2_MGMT_NETWORK_IPV6_GATEWAY="fded:1bc1:fc3e:96d0::1" NODE2_UNDERLAY_NETWORK_IP_ADDRESS="82.82.82.20" NODE2_UNDERLAY_NETWORK_IP_NETMASK="255.255.255.0" NODE2_UNDERLAY_NETWORK_IP_GATEWAY="82.82.82.1" # AUX network is optional # Although Aux network is optional it should be either present in both nodes # or not present in both nodes. # It cannot be present on Node1 and not present on Node2 and vice versa #NODE2_AUX_NETWORK_IP_ADDRESS="179.254.20.200" #NODE2_AUX_NETWORK_IP_NETMASK="255.255.255.0" #NODE2_AUX_NETWORK_IP_GATEWAY="179.254.20.1" # XR Hostname NODE2_XR_HOSTNAME="vtsr02" # Loopback IP and netmask NODE2_LOOPBACK_IP_ADDRESS="130.0.0.1" NODE2_LOOPBACK_IP_NETMASK="255.255.255.255" | ||
Step 3 | Update the
following on
vtsr_template.cfg for your deployment.
| ||
Step 4 | Run the
build_vts_config_iso.sh vtsr script: This will generate the
ISO file that you need to attach to the VM before booting it.
For example: admin@dev:~$ /opt/cisco/package/vts/bin/build_vts_config_iso.sh vtsr /opt/cisco/package/vts/share/vtsr_template.cfg Validating input. validating Generating ISO File. Done! admin@dev:~$ ls -l -rw-r--r-- 1 admin vts-admin 360448 Jan 4 18:16 vtsr_node1_cfg.iso
|
Deploying the VTSR.ova is similar to XRNC.
Step 1 | Generate an ISO file for the VTSR VM. See Generating an ISO for VTSR . |
Step 2 | In the vSphere Client, select File > Deploy OVF Template. The Deploy OVF Template wizard appears. |
Step 3 | Select VTSR.ova from the source location, and click Next.The OVF template details are displayed. |
Step 4 | Click
Next to specify the destination. Enter the following
details:
|
Step 5 | Click Next to select the storage location to store the files for the template. The default values for virtual disk format and VM Storage Policy need not be changed. |
Step 6 | Click Next to set up the networks. Specify the first network as the Underlay Network and the second network as the Management Network. |
Step 7 | Click Next. Review the settings selections. |
Step 8 | Click Finish to start the deployment. |
Step 9 | After the deployment is complete, edit the VM settings. Add a CD/DVD Drive selecting Datastore ISO file and point to the vtsr.iso file which was generated and uploaded to the host. |
Step 10 | Power on the VM. |
Step 11 | To ensure VTSR
is configred with the proper Day Zero configuration, SSH to VTSR and then run:
RP/0/RP0/CPU0:vtsr01-vcenter#bash [xr-vm_node0_RP0_CPU0:~]$docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 31f6cbe6a048 vtsr:dev "/usr/bin/supervisord" 3 weeks ago Up 7 days vtsr |
Step 12 | Run either of
the following commands:
Or,
In the second option, 31 is the process ID, which you can get from Step11. An output similar to the below example is displayed: connecting to confd_cli root@host:/opt/cisco/package# confd_cli -u admin -C Welcome to the ConfD CLI admin connected from 127.0.0.1 using console on host host> en host# show running-config vtsr-? Possible completions: vtsr-config vtsr-day0-config host(config)# vtsr-config ? Possible completions: dhcp-relays global-config interfaces ip-routes l2-networks vm-macs vrfs vtfs host(config)# vtsr-config Do not press or Enter key when the VTSR is loading or getting registered with VTC. For vCenter, VTSR may take approximately 30-45 minutes to come up. |
The Day Zero configuration (OSPF, loopback0) has to be configured on VTSR using the vts-cli.sh script. You can apply the following templates:
Note | This procedure is not required in case you have VTF in L2 switch mode. Run vts-cli.sh, after you run sudo su -. |
vtsr-underlay-loopback-template. See Applying Loopback Template
vtsr-underlay-ospf-template. See Applying OSPF Template
admin@tb11-vtc:/opt/vts/bin$ ./vts-cli.sh Usage: vts-cli -<command> <Name> Valid commands are: vts-cli -createTemplate <templateName> -- creates template structure in VTC db. vts-cli -applyTemplate <templateName> -- collects template variables values & applies template to device. vts-cli -deleteTemplate <templateName> -- deletes template structure from VTC db. vts-cli -deleteTemplateConfig <templateName> -- deletes earlier applied template config from device. vts-cli -getTemplate <templateName> -- gets template structure from VTC db. vts-cli -getTemplateConfig <templateName> -- gets template configuration from VTS. vts-cli -bulkEditNtwksArp <tenantName> -- collects inputs for bulk edit of arp suppression of networks associated with a specific Tenant. vts-cli -listNetworks <tenantName> -- Lists L2 networks for a given Tenant. vts-cli -changeHostRole <host-name> -- change all host connections role from managed to unmanaged (or vice-versa)
If there are issues in running the commands, check the /opt/vts/bin/vts-cli.log to get more details.
Step 1 | On VTC (Master VTC in case of an HA setup), go to /opt/vts/bin. |
Step 2 | Run the
following command:
admin@VTC1:/opt/vts/bin$ vts-cli.sh -applyTemplate vtsr-underlay-loopback-template This will prompt you to input the parameters. For example: Enter device name: vtsr01 Enter loopback-interface-number: 0 Enter ipaddress: 100.100.100.100 Enter netmask: 255.255.255.255 Template vtsr-underlay-loopback-template successfully applied to device vtsr01 In case you have a VTSR HA setup, apply the template on both VTSRs. . The following message is shown if the configuration got applied correctly:Template vtsr-underlay-loopback-template successfully applied to device vtsr01 |
Step 1 | On VTC (Master VTC in case of an HA setup), go to /opt/vts/bin. |
Step 2 | Run the
following command:
admin@VTC1:/opt/vts/bin$ vts-cli.sh -applyTemplate vtsr-underlay-ospf-template This will prompt you to input the parameters. For example: Enter device name: vtsr01 Enter process-name: 100 Enter router-id: 10.10.10.10 Enter area-address: 0.0.0.0 Enter physical-interface: GigabitEthernet0/0/0/0 Enter loopback-interface-number: 0 Enter default-cost: 10 In case you have a VTSR HA setup, apply the template on both VTSRs. . The following message is shown if the configuration got applied correctly:Template vtsr-underlay-ospf-template successfully applied to device vtsr01
|
We recommend that you register the VMM via the VTS GUI, before you install VTF to ensure there are no errors later.
Before you install VTF, you must install VTSR and register it to VTS. See Installing VTSR, for details.
Also, verify whether VTSR is in sync with the VTC. If not, use the sync-from operation via VTS-GUI to synchronize the VTS configuration by pulling configuration from the device. See Synchronizing Configuration section in the Cisco VTS User Guide for more information on this feature.
Note | vCenter supports VTF in VTEP mode only. |
Set additional routes on VTC VM(s)— You need to add routes for all underlay networks into VTC for across-the-ToR underlay communication. For example, if SVI configuration across ToR from VTC is:
interface Vlan100 no shutdown no ip redirects ip address 33.33.33.1/24 no ipv6 redirects ip router ospf 100 area 0.0.0.0 ip pim sparse-modethen, below route needs to be added on VTC VM(s):
sudo route add -net 33.33.33.0/24 gw 2.2.2.1
Where, 2.2.2.1 is the SVI IP address on the local ToR from VTC VM(s).
Step 1 | Specify the VTF Mode in the System Settings. Go to Administration > System Settings page, select VTEP from the drop down. |
Step 2 | Go to Host Inventory and edit the host on which VTF (VTEP mode) installation needs to be done. |
Step 3 | On Host
Details, fill in all fields.
Ensure that you review the tooltips for important information about the entries. |
Step 4 | Select the
Virtual Switch. You have the following options:
To install VTF, select vtf-vtep |
Step 5 | Enter the VTF
details.
|
Step 6 | Verify the interfaces information. |
Step 7 | Check the Install VTF on Save check box, and click Save. |
Step 8 | Check the installation status in the Host Inventory page. |
Step 9 | Check the VTF registration status on Inventory > Virtual Forwarding Groups page. |
Before you VTF uninstall, go to Inventory > Virtual Forwarding Groups to verify that VTF is shown in Virtual Forwarding Groups page.
To uninstall VTF
Step 1 | Go to Host Inventory, and edit the host to change Virtual Switch type from vtf-vtep to not-defined. |
Step 2 | Click Save. |
Step 3 | Check the uninstallation status on the Host Inventory page to verify whether Installation status is unchecked and Virtual Switch is not-defined. |
Step 4 | Go to the Inventory > Virtual Forwarding Groups page, to verify that it does not show VTF that you uninstalled. |
Step 5 | Go to vCenter using vSphere Web Client. |
Step 6 | Go to Hosts and Clusters, click the VTF VM that got uninstalled from VTS GUI. |
Step 7 | Power off the VTF VM. |
Step 8 | Delete the VTF from disk |
To verify VTC VM installation:
Step 1 | Log in to the VTC VM just created using the VTC VM console. | ||
Step 2 | Ping the
management gateway.
In case ping fails, verify the VM networking to the management network. | ||
Step 3 | For the VTC VM
CLI, ping the underlay gateway.
In case the ping fails, verify VM networking to the underlay network.
| ||
Step 4 | Verify whether the VTS UI is reachable, by typing in the VTS management IP in the browser. |
To verify VTSR installation:
Step 1 | Log in to the
VTSR.
| ||
Step 2 | Ping the
underlay gateway IP address.
In case ping fails, verify underlay networking. | ||
Step 3 | Ping the VTC VM.
In case ping fails, verify underlay networking.
| ||
Step 4 | Run virsh list to make sure the nested VM is running. | ||
Step 5 | Verify whether
the Virtual Forwarding Group (VFG) group is created on VTS GUI, and VTSR is
part of the VFG group.
|
To verify VTF installation:
Step 1 | Log in to the
VTF VM / vhost.
| ||
Step 2 | Ping the
underlay gateway IP address.
In case ping fails, verify underlay networking. | ||
Step 3 | Ping the VTC VM
underlay IP address.
In case ping fails, verify underlay networking. | ||
Step 4 | Verify whether
the VTF CLI is available . To do this, run:
'sudo vppctl If the o/p command fails, run the following command to identify whether vpfa service is up and running: sudo service vpfa statusIf there are errors, try restarting the service. sudo service vpfa restart | ||
Step 5 | Verify whether
the VTF is part of the VFG, on VTS GUI.
|
The GUI password change will trigger the updating of password on all host agents which are running on the Physical computes. And if there are VTFs in your setup, then the VTSR and VTF passwords will also get updated.
Traffic disruption will happen only if you have VTFs installed (Virtual deployment) and it happens because of the vpfa process restart.
In case of a Physical deployment there will not be any traffic disruption.
Step 1 | Log in to VTS GUI and click on settings icon on the top-right corner and click Change Passphrase. | ||
Step 2 | Enter the current password, new password, then click Change Passphrase. | ||
Step 3 | Click
OK in the
Confirm Change Passphrase popup, to confirm.
|
You can use the Linux command ‘passwd’ to change the VTC VM password. After changing the password, you should use the new password for the subsequent SSH session to the VTC VM.
For an HA installation you must change the password on both Master and Slave with the command ‘passwd’.
Step 1 | Change the password from the Cisco VTS GUI. |
Step 2 | Download the password encryption tool from https://devhub.cisco.com/artifactory/list/vts-yum/2.6.0/salt/encrypt-pass-2.6.0.vts260-10.tar.gz. |
Step 3 | From the OpenStack director, open the file
neutron-cisco-vts.yaml and update the below field with newly encrypted password
with the tool ‘encrypt-password’.
VTSPassword: '' |
Step 4 | Redeploy the overcloud. |