Cisco SVO admin plane is responsible for turning up the shelf virtualization orchestration services for the network elements (NE). It is a web user interface that facilitates the installation of the SVO software and configures the NE instances and orchestrates high availability (HA) services.

The admin plane is supported both on the external server and the SVO card. The admin plane allows you to create, update, manage, and delete SVO NE instances.

To achieve high availability for the exernal server, the SVO software is installed on two servers in local and remote locations. In the case of the SVO card, two SVO line cards are installed in two different chassis of the ROADM node. The two external servers or two SVO cards are connected by two intercommunication links—through the HA network (primary link) and through the devices network (secondary link). Both links are used for the communication between the admin planes. The primary link is also responsible for replicating all the configuration transactions that are performed on each active SVO instance to the related standby SVO instance.

All the networking configuration data required by the admin plane is present in a file shared by both the SVO cards or external servers. When creating a new SVO instance, you can configure the management interface address, while the other parameters are automatically selected by the admin plane based on the constraints defined in the configuration file.

The admin planes coordinate to automatically assign active and standby roles to the SVO instances. The admin planes can also perform an automatic switchover that promotes the standby instance to active when software or hardware faults affect the active instance.

The Cisco SVO admin plane allows you to:

• Create the super user for the SVO card model or the admin user for the external server model.

• Create, update, or delete SVO instances of type ROADM, OLA, DGE, or TXP. You can also view the details of the SVO instances.

  Note	The first SVO instance created on the SVO card is always a ROADM instance. Subsequent SVO instances can be OLA, DGE, or TXP.

• Control, monitor, and performs health checks of the SVO instances.

• Auto switch SVO instances during a software or hardware fault in the SVO cards or servers.

• Force a manual switch between the active and standby SVO instances.

• View parameters of the network configuration file.

• View a list of allowed and blocked IP addresses

• Troubleshoot using diagnostics. A zip file containing the log files from the admin plane can be downloaded.

• Reset the SVO card to factory defaults. This action erases all containers and configurations on the SVO card.

The following table highlights the differences between the two types of system installation.

Network configuration file defines all the information that is related to the servers and the networking infrastructure that is required to set up the SVO functionalities. See Required Network Resources section to define the networks.

The network.yml configuration file starts with the server-name field. The server-name field refers to the name field of the server in which the installation executes.

The configuration files that are used for the installation in high availability networks on two servers or VMs contain different values in the server-name field for the respective servers.

The network.yml configuration file contains two main sections, one for each server or VM of the cluster.

For each server section, there are three fields:

• name—Server name (editable)

• mgmt-port—Not editable (value is 443)

• ha-agent-port—Not editable (value is 5480)

SVO network architecture is based on four networks. Each section in a network.yml file defines the following networks:

• Management—The management ports of the admin plane and SVO instances belong to this network.

• High Availability—This network is used for SVO database replication and communication between the admin planes.

• Private HA Network—This network is used only for communicating between the admin plane and the local SVO instances in certain processes such as node activation. It doesn’t use external networking resources.

• Devices—This network is used for connecting the NCS 2000 devices. The devices must be reachable through this subnet. If the admin plane is unable to communicate with its peer server on the primary high availability network, it uses a link on this network as an alternative way to communicate.

The Private HA Network is local to the server or VM. The other three networks are exposed outwards and they must have three different subnets.

The following table describes the fields in the network.yml configuration files.

The following sections contain one example of network.yml file for IPv4 configuration and one for IPv6 configuration.

To create the configuration file, use one of the following templates.

server-name: VM1

servers:
  - name: VM1
    mgmt-port: 443
    ha-agent-port: 5480
    mgmt:
      name: management
      host-nic-name: ens192
      ipv4:
        ip: 10.58.233.0
        prefix: 24
        gateway: 10.58.233.1
        host-nic: 10.58.233.75
        adminplane: 10.58.233.76
    ha:
      name: hanetwork
      host-nic-name: ens224
      ha-port: 10001
      ipv4:
        ip: 192.168.1.0
        prefix: 24
        gateway: 192.168.1.1
        adminplane: 192.168.1.4
        host-nic: 192.168.1.2
    haprivate:
      name: haprivate
      ipv4:
        ip: 192.168.3.0
        prefix: 24
        gateway: 192.168.3.1
        adminplane: 192.168.3.2
    devices:
      name: devices
      host-nic-name: ens256
      ha-port: 10002
      ipv4:
        ip: 192.168.2.0
        prefix: 24
        gateway: 192.168.2.1
        adminplane: 192.168.2.4
        host-nic: 192.168.2.2

  - name: VM2
    mgmt-port: 443
    ha-agent-port: 5480
    mgmt:
      name: management
      host-nic-name: ens192
      ipv4:
        ip: 10.58.233.0
        prefix: 24
        gateway: 10.58.233.1
        host-nic: 10.58.233.77
        adminplane: 10.58.233.78
    ha:
      name: hanetwork
      host-nic-name: ens224
      ha-port: 10001
      ipv4:
        ip: 192.168.1.0
        prefix: 24
        gateway: 192.168.1.1
        adminplane: 192.168.1.5
        host-nic: 192.168.1.3
    haprivate:
      name: haprivate
      ipv4:
        ip: 192.168.3.0
        prefix: 24
        gateway: 192.168.3.1
        adminplane: 192.168.3.2
    devices:
      name: devices
      host-nic-name: ens256
      ha-port: 10002
      ipv4:
        ip: 192.168.2.0
        prefix: 24
        gateway: 192.168.2.1
        adminplane: 192.168.2.5
        host-nic: 192.168.2.3

server-name: VM1

servers:
  - name: VM1
    mgmt-port: 443
    ha-agent-port: 5480
    mgmt:
      name: management
      host-nic-name: ens192
      ipv4:
        ip: 10.58.233.0
        prefix: 24
        gateway: 10.58.233.1
        adminplane: 10.58.233.72
      ipv6:
        ip: 2001:420:4491:2004::233:0
        prefix: 112
        gateway: 2001:420:4491:2004::233:2
        host-nic: 2001:420:4491:2004::233:70
        adminplane: 2001:420:4491:2004::233:72
    ha:
      name: hanetwork
      host-nic-name: ens224
      ha-port: 10001
      ipv4:
        ip: 192.168.80.0
        prefix: 24
        gateway: 192.168.80.1
        adminplane: 192.168.80.2
      ipv6:
        ip: 2001:db8:abc:111::0
        prefix: 64
        gateway: 2001:db8:abc:111::1
        adminplane: 2001:db8:abc:111::4
        host-nic: 2001:db8:abc:111::2
    haprivate:
      name: haprivate
      ipv4:
        ip: 192.168.3.0
        prefix: 24
        gateway: 192.168.3.1
        adminplane: 192.168.3.2
    devices:
      name: devices
      host-nic-name: ens256
      ha-port: 10002
      ipv4:
        ip: 192.168.81.0
        prefix: 24
        gateway: 192.168.81.1
        adminplane: 192.168.81.2
      ipv6:
        ip: 2001:db8:abc:222::0
        prefix: 64
        gateway: 2001:db8:abc:222::1
        adminplane: 2001:db8:abc:222::4
        host-nic: 2001:db8:abc:222::2

  - name: VM2
    mgmt-port: 443
    ha-agent-port: 5480
    mgmt:
      name: management
      host-nic-name: ens192
      ipv4:
        ip: 10.58.233.0
        prefix: 24
        gateway: 10.58.233.1
        adminplane: 10.58.233.73
      ipv6:
        ip: 2001:420:4491:2004::233:0
        prefix: 112
        gateway: 2001:420:4491:2004::233:2
        host-nic: 2001:420:4491:2004::233:71
        adminplane: 2001:420:4491:2004::233:73
    ha:
      name: hanetwork
      host-nic-name: ens224
      ha-port: 10001
      ipv4:
        ip: 192.168.83.0
        prefix: 24
        gateway: 192.168.83.1
        adminplane: 192.168.83.3
      ipv6:
        ip: 2001:db8:abc:111::0
        prefix: 64
        gateway: 2001:db8:abc:111::1
        adminplane: 2001:db8:abc:111::5
        host-nic: 2001:db8:abc:111::3
    haprivate:
      name: haprivate
      ipv4:
        ip: 192.168.3.0
        prefix: 24
        gateway: 192.168.3.1
        adminplane: 192.168.3.3
    devices:
      name: devices
      host-nic-name: ens256
      ha-port: 10002
      ipv4:
        ip: 192.168.84.0
        prefix: 24
        gateway: 192.168.84.1
        adminplane: 192.168.84.3
      ipv6:
        ip: 2001:db8:abc:222::0
        prefix: 64
        gateway: 2001:db8:abc:222::1
        adminplane: 2001:db8:abc:222::5
        host-nic: 2001:db8:abc:222::3

The hardware recommendation is based on the Cisco UCS configuration with the VMWare ESXi-7.0U1c.

Note	In VMWare ESXi, configure the Security Policy of virtual switches as follow: Allow promiscuous mode: yes Allow forged transmits: yes Allow MAC changes: yes

• Cisco UCS-C220-M5SX

• 32 CPUs (2x Intel Xeon Gold 5218 CPU @ 2.30GHz)

• 256GB RAM

• 2x 480GB SSD (Raid)

• MLOM NIC for additional network interfaces

The following are the recommended OS versions.

• CentOS Linux release 7.9.2009 (Docker Engine 19.03.8)

• CentOS Linux release 8.3.2011 (Docker Engine 20.10.5)

Note	CentOS 7 active support ends in December 2024 (recommended) CentOS 8 active support ends in December 2021

The following sections provide information on the resources that are required to define SVO instances.

In case of high availability, it is recommended to have the same resources on both the VMs.

Network resources that must be planned in the design phase are related to three different subnets.

The following table describes the different networks.

The following figure illustrates the management of an NE before and after the introduction of SVO.

Note

For each virtual NE, represented by a SVO instance, there is a single management IP address. The status of the management interface, Up or Down, is aligned with the status of the SVO, active or standby. If SVO is active, the management interface is Up. If SVO is standby, the management interface is Down. The status, active or standby, is orchestrated by admin plane.

In the following table, the data to define the size of the subnets to set up HA network and the description of each network and its usage.

An SVO instance is a software virtualization of the physical NCS 2000 node that has been configured to manage. SVO instances are of types—ROADM, OLA, DGE, and TXP. In an SVO card model, you can configure a maximum of one ROADM SVO instance and up to 30 OLA DGE, or TXP SVO instances.

In an external server model, you can configure any number of ROADM, OLA, DGE, or TXP SVO instances.

You can create, update and delete SVO instances using the admin plane. Each SVO instance runs as an active instance on one server and as a standby instance on the other server. It is also possible to manually switch the roles of the SVO instance between active and standby.

The peer admin planes that are running on the local and remote server respectively have two intercommunication links, one through the HA network (primary link) and the other through the devices network (secondary link).

The table displays the SVO instances that were created. Each row has two entries relating to the local and remote SVO card or server. In each row, the first entry is the local instance and the second entry is the remote instance. The details are:

• Name—Name of the SVO instance.

• IP Address—The IP address of the SVO instance. It is IPv4 for the SVO card model, and IPv6 or IPv4 for the external server model.

• SW version—SW version on the server.

• State—State of the SVO instance.

• App State—State of the SVO application that is running on the SVO instance.

  • During a manual switching process, the App State field displays different statuses such as SWITCHING, SWITCH_DONE, or UP.

  • The App State field displays ACTIVATING or ACTIVATE_RESTART only after the SVO web UI has requested the admin plane to orchestrate the activation process.

• Role —Role of the SVO instance. The roles are ACTIVE, STANDBY, NONE, and UNKNOWN. In case of issues or specific SVO states, special tags are displayed such as NOT_RESPONDING, STARTING,STOPPED, or BAD_CLUSTER.

  Note	The green icon indicates the reachability of the SVO instance to the connected NCS 2000 device. If the active SVO instance is unable to reach the NCS 2000 device due to a network segregation, it performs an auto-switch.

• Up Time—Up time of the SVO instance.

• Type—Label for the SVO instance.

• Action—A set of actions can be performed on the SVO instance:

  • Details of the SVO instance—Click this icon to view the summary of the local and remote SVO instance.

  • Edit SVO Instance—Click this icon to edit the memory size of the SVO instance.

  • Switch SVO Instance—Click this icon to manually switch the SVO instance between servers.

    Note	A switch operation is possible only if both the SVO instances are up and running and the role of the instances are Active and Standby.

  • Delete SVO Instance—Click this icon to delete an SVO instance.

    Note	This icon is disabled when a switch operation is in progress.

The IP Filtering Policy page displays two sets of IP addresses:

• Allowed List—Contains a list of available IP addresses.

• Denied List—Contains a list of blocked IP addresses.

The list of allowed and denied IP addresses displayed on this page are stored in two separate files on the file system of the local and remote server.

The IP lists are applicable only to the devices network. During the creation of the SVO instance, the denied list prevents the admin plane from selecting any IP address that is on the list for the IPv4 and IPv6 addresses whereas the allowed list permits the admin plane to select any IP address that is in the list.

The IP list cannot be modified on this page at runtime. In case there are updates to be made, the relevant file is modified in the file system and the admin plane is restarted.

To view these IP addresses in the admin plane:

1. Log into the Cisco SVO Admin Plane.

2. Click Networks in the left panel and choose IP Filtering.