vSIM overview

vSIM overview

The Nokia Virtualized 7750 SR and 7950 XRS Simulator (vSIM) is a Virtualized Network Function (VNF) that simulates the control, management, and forwarding functions of a 7750 SR or 7950 XRS router.

The vSIM runs the same Service Router Operating System (SR OS) as 7750 SR and 7950 XRS hardware-based routers and, therefore, has the same feature set and operational behavior as those platforms. Configuration of interfaces, network protocols, and services on the vSIM are performed the same way as they are on physical 7750 SR and 7950 XRS systems. vSIM software is designed to run on x86 virtual machines (VMs) deployed on industry-standard Intel servers. In this document, vSIM refers to the guest software running on a VM and to the set of those VMs that comprise a network element.

The vSIM is suitable for labs, training and education, network simulation, or to emulate a device under test (DUT) in preparation for deployment into a production network. It is not intended for deployment in an actual production network.

NFV enables network functions that previously depended on custom hardware to be deployed on commodity hardware using standard IT virtualization technologies. For network operators, the benefits of NFV include:

  • reduced CAPEX by using industry-standard hardware that is potentially easier to upgrade

  • reduced OPEX (space, power, cooling) by consolidation of multiple functions on fewer physical platforms

  • faster and simpler testing and rollout of new services

  • more flexibility to scale capacity up or down, as needed

  • ability to move or add network functions to a location without necessarily needing new equipment

vSIM concept

The vSIM software is designed for a standard virtualization environment in which the hypervisor software running on a host machine creates and manages one or more VMs that consume a subset of the host machine resources. Each VM is an abstraction of a physical machine with its own CPU, memory, storage, and interconnect devices. Each vSIM can be viewed as a Virtual Network Function (VNF) made up of one or more VNF components (VNF-C) spanning one or more compute servers. For a vSIM, each VNF-C is a VM that emulates one card slot of a physical router, or a complete physical router in the case of one integrated model.

The SR OS is the guest operating system of each VNF-C VM. vSIM VMs can be deployed in combination with other VMs on the same server, including VMs that run guest operating systems other than the SR OS.

Note: Care must be taken not to over-subscribe host resources; vSIM VMs must have dedicated CPU cores and dedicated vRAM memory to ensure stability. In addition, combining vSIM VMs with other VMs that have intensive memory access requirements on the same CPU socket should be generally avoided for stability reasons. See Creating and starting a vSIM VM on a Linux KVM host for more information about this topic.

vSIM concept shows the general concept of a vSIM.

Figure 1. vSIM concept

The host machine supporting a vSIM VM must be a qualified x86 machine that may range from a laptop to a dedicated server.

The host machine must run a hypervisor that is compatible with the vSIM software. QEMU-KVM and VMware are the only supported hypervisors.

See Host machine requirements for more information about the minimum requirements of the host server and the supported hypervisors for the vSIM.

vSIM deployment models

The vSIM can be deployed as one of two models: integrated or distributed. The deployment model depends entirely on the configured chassis type of the vSIM system.

Integrated model

The integrated vSIM model uses a single VM to emulate the physical router. All functions and processing tasks of the emulated router, including control, management and data plane, are performed by the resources of the single VM.

An integrated vSIM is created when the configured chassis type is SR-1, SR-1s, IXR-R6, IXR-ec, or IXR-e2. All other chassis types require a ‟distributed” model of deployment.

Note: SR-1 and SR-1s do not refer to the following chassis types, which require a distributed model of deployment:

  • 7750 SR-1x-48D

  • 7750 SR-1-24D

  • 7750 SR-1-48D

  • 7750 SR-1-92S

  • 7750 SR-1-46S

  • 7750 SR-1x-92S

  • 7750 SR-1se

While SR-1, SR-1s, IXR-ec, and IXR-e2 chassis types are single VM combined systems without redundancy support, the IXR-R6 chassis type can have two combined VMs to allow for redundancy. The IXR-R6 otherwise behaves as an integrated model, as both VMs have combined CPM/IOM components.

Distributed model

The distributed vSIM model uses two or more VMs (VNFCs) connected to a common internal network to emulate a single physical router (VNF).

In a distributed system (vSIM), each VM is specialized, supporting either control plane processing (CPM) or datapath functions (IOM or XCM).

A distributed vSIM supports one CPM or two hot-redundant CPMs in the same active-standby model as the emulated physical router so that if the active CPM fails, the standby can take over immediately, with minimal or no impact to packet forwarding, services, or control plane sessions. These can be placed on different hosts to provide hardware and software resiliency.

A distributed vSIM is created when the configured chassis type is anything other than ‟SR-1”, ‟SR-1s”, ‟IXR-R6”, or ‟IXR-ec”.

The VMs of a distributed vSIM must be able to communicate privately over an internal network dedicated to the router being emulated. The internal network behaves similar to the switch fabric of a physical router.

Each CPM and IOM/XCM of a specific vSIM instance must be connected to the fabric network of that instance. The fabric network is a Layer 2 broadcast domain over which the VMs of the vSIM send messages to each other for purposes of discovery, inter-card communication and synchronization, inter-IOM data traffic, and so on. The MTU of network interfaces associated with vSIM internal fabric interfaces must be set to 9000 bytes. Packets sent over the fabric by each IOM/XCM or CPM are Ethernet encapsulated (without 802.1Q VLAN tags) and frames with a multicast/broadcast destination MAC address must be delivered to all the VMs of the vSIM instance.

Supported vSIM configurations

For a vSIM to properly simulate a particular 7750 SR or 7950 XRS router configuration, the SR OS software running on each of its component VMs must read the SMBIOS information (see Sysinfo for information about SMBIOS parameters), which must have the following configured:

  • chassis type of the emulated router

    The chassis type must be set identically for all VMs that make up one chassis or system.

  • slot number corresponding to each VM

  • card type represented by each VM

  • equipped MDAs/XMAs in each VM emulating an IOM or XCM card

  • SFM (switch fabric module) that virtually connects the slot to the rest of the system

    The SFM must be set identically for all VMs that make up one chassis or system.

  • chassis topology of the system

    When this value is set to XRS-40, the slot is part of an extended 7950 XRS chassis. This must be set identically for all VMs that make up one 7950 XRS-40 system.

Note: Before the Release 16.0, the chassis-topology attribute was not supported and VMs emulating a 7950 XRS-20 or 7950 XRS-20e card would automatically boot as being part of an extended 7950 XRS-40 system. With Release 16.0 and later software, a VM emulating a 7950 XRS-20 or7950 XRS-20e card automatically boots as being part of a standalone XRS-20 system.

vSIM software can only simulate valid 7750 SR and 7950 XRS router configurations. For example, with real physical hardware, you cannot install a 7950 XRS CPM-X20 in an SR-12 chassis or pass data traffic through a 7950 XRS chassis with only one CPM-X20 and no XCMs installed. The same rules apply to vSIMs.

vSIM configuration should always start with a decision about the chassis type to be emulated. vSIM supports the following chassis types:

  • 7750 SR-7

  • 7750 SR-12

  • 7750 SR-12e

  • 7750 SR-a4

  • 7750 SR-a8

  • 7750 SR-1e

  • 7750 SR-2e

  • 7750 SR-3e

  • 7750 SR-1

  • 7750 SR-1s

  • 7750 SR-2s

  • 7750 SR-7s

  • 7750 SR-14s

  • 7750 SR-1x-48D

  • 7750 SR-1-24D

  • 7750 SR-1-48D

  • 7750 SR-1-92S

  • 7750 SR-1-46S

  • 7750 SR-1x-92S

  • 7750 SR-1se

  • 7750 SR-2se

  • 7950 XRS-20

  • 7950 XRS-20e

  • 7250 IXR-6

  • 7250 IXR-10

  • 7250 IXR-R4

  • 7250 IXR-R6

  • 7250 IXR-s

  • 7250 IXR-e

  • 7250 IXR-X

  • 7250 IXR-X3

  • 7250 IXR-ec

  • 7250 IXR-e2

  • 7250 IXR-R6d

  • 7250 IXR-R6dl

The chassis, sfm, and chassis-topology SMBIOS parameters determine the total number of card slots available, the eligible card types in each slot position and the minimum configuration of cards to create a functional system.

If a VM of a vSIM emulates a physical card with I/O ports (for example, an IOM or XCM) then specific MDAs compatible with that card can be virtually equipped. I/O ports on these MDAs map to VM vNIC interfaces as described later in this document. The MDA types that are compatible with a card adhere to physical hardware rules.

Appendix A: vSIM supported hardware summarizes all currently supported valid combinations of chassis type, SFM type, card type, XIOM type and MDA type that may be represented by one single vSIM VM.

vSIM networking

A vSIM VM can have one or more virtual NIC ports. Depending on the hypervisor, each vNIC port presented to a vSIM VM can be one of the following types:

  • VirtIO (KVM)

  • E1000 (KVM and VMware)

For each of the above options, the virtual NIC port that is presented to the guest is internally connected to a logical interface within the host. The logical host interface may map directly to a physical NIC port/VLAN or it may connect to a vSwitch within the host. If a vNIC port is connected to a vSwitch, a physical NIC port/VLAN must be added as a bridge port of the vSwitch to enable traffic to reach other external hosts.

Note: SR-IOV and PCI pass-through are not supported technologies for vSIM VMs.

Each vSIM VM supports up to 20 virtual NIC ports. Depending on the card-type emulated by the VM, this may be more or less than the actual number of I/O ports supported by the card-type. Additional ports may be configured on the vSIM, but they will have no external connectivity and will remain in the down state.

Note: Throughput on vSIM ports is limited to no more than 250 pps.

vSIM software packaging

The vSIM software is part of the VSR software package that is available for download from the Nokia Support Portal as a ZIP file in one of the following formats, depending on the machine on which the VSR is installed:

  • vSIM-KVM ZIP archive file

    The vSIM-KVM ZIP archive filename uses the format Nokia-vSIM-KVM-yy.m.Rx.zip (release specific version). For example, Nokia-vSIM-KVM-21.2.R1.zip.

    The vSIM-KVM ZIP archive file contains the following:

    • a QCOW2 disk image file. The sros-vsim.qcow2 disk image should be used when creating VSR-I VMs on Linux KVM machines using libvirt or OpenStack.

    • a MIBs directory containing MIB files

    • a support directory containing YANG files

    • MD5 and SHA256 checksums for files in the zip

  • vSIM-VMware ZIP archive file

    The vSIM-VMware ZIP archive filename uses the format Nokia-vSIM-VMware-yy.m.Rx.zip (release specific version). For example, Nokia-vSIM-VMware-21.2.R1.zip.

    The vSIM-KVM ZIP archive file contains the following:

    • an OVA file. The sros-vsim.ova archive file is used for onboarding a VSR-I VM into a VMware environment. This OVA contains an OVF descriptor file and a VMDK disk image containing the VSR software. The OVA file can be used to instantiate a VSR-I VM using either vCloud Director or the vSphere Web Client interacting with a vCenter Server.

    • a MIBs directory containing MIB files

    • a support directory containing YANG files

    • MD5 and SHA256 checksums for files in the zip

Note: Do not use the files contained in the Nokia-VSR-VMware or Nokia-VSR-KVM ZIP files. These files should only be used for VSR deployments. See the VSR VNF Installation and Setup Guide for more information.
Note: TIMOS content is created under the cf3:/TIMOS directory. This location cannot be edited.