User talk:Jani 1408

Introduction to Laasv
LaaSv2 goal is to provide a complete solution set for lab management.


 * An integrated dashboard providing insights, transparency and observability to inventory tracking, health monitoring, utilization and ownership, etc.
 * Letting the user focus on specific topology needs, abstracting out the complexity of lab management and device orchestration, automatically selecting the optimal devices to fulfill the user intent.
 * Orchestrating physical and virtual devices on-the-fly, along with a set of network services available in a service catalog, ready to be deployed in any testbed environment.
 * Pooling available resources across all Cisco labs, promoting sharing and on-demand reservation & use.

Jani 1408 (talk) 05:43, 6 June 2024 (UTC)

LaaSv2 Components
LaaSv2 consists of a control plane component and a lab agent component. The control plane is a centralized/single instance which is hosted on a private cloud. Each lab onboarded into LaaSv2 has a lab agent, which has connectivity to the lab management networks. This lab agent receives instructions from the control plane to e.g. configure a ToR to orchestrate some overlay links, clear a devices console, connect to a device CLI and load an image, etc.

Topology vs Testbed
In LaaSv2 terminology, a topology is a description of the testbed which the user wants. A topology consists of a set of nodes and links. The user can specify constraints for each node and link. For example, a node may have the constraint  and a link may have the constraint , meaning that when the topology is reserved, LaaSv2 will search for a cat9k device that is connected to a top of rack infra switch (aka ToR) which supports VXLAN. A user can also omit any constraints, meaning any kind of device (maybe a virtual machine) could be used to implement the node. Therefore, a topology is a virtual entity (a set of requirements / a specification for a testbed), while a testbed is a real, physical set of devices with the appropriate overlay network configured between them.

Topology

 * A Topology is a logical, abstract collection of nodes. It does not have a physical representation and does not consume any resource. Any user or group can have an unlimited number of topologies, regardless of the actual number of devices the user has access to.
 * A Topology can be thought as a factory – It will allow to create one or more physical instances (called testbeds). A testbed is instanciated from a topology by creating a reservation.
 * A testbed is made up from Nodes and Links. Nodes represent elements in the topology – for example Routers, Switches, Virtual machines, etc. Links represent the connection between those elements.
 * Both Nodes and Links can have a set of constraints and properties. A constraint will limit the scope of the node or link. For example, a node can have as constraint ‘Device needs to be in lab XX’, or ‘Device needs to be a Virtual machine’, or device must have OS IOSXE and platform
 * Similarly, link constraints limit the scope of the links that will be instantiated. For example, a link could have a constraint such as . e.g: need bandwidth of at least 1G
 * Properties can be thought as actions that will be done on the node or link. For example, a node property is ‘Image name’. It indicates when device is brought up, LaaSv2 will load the indicated image.

Testbed
An instance of a topology with a duration (lifetime). In a testbed:


 * All persistent devices are identified and reserved (locked).
 * All transient devices are created.
 * All top of rack switches are configured to implement the connections specified in the "links" section of the topology
 * Device pool/Lab are identified.
 * Can be fully described in a pyATS test YAML file, and ready to run a test job over it.

Domain
A domain is a context which stores a set of topologies and nodes. For example, a DE team developing NXOS images may frequently request a topology with an n7k device, so they may all be part of a domain which contains a topology called, as well as  , etc.

Lab
A lab represents a physical lab. Labs contain resources such as ToRs / infra switches, PDUs, terminal servers, TFTP servers, device pools, UUTs, plugin instances, etc. Some devices like ToRs, PDUs, console servers and TFTP servers exist directly under a lab, while UUTs are further grouped into device pools (explained in the next section).

Device Pool
A device pool is a set of UUTs, intended to allow more fine grained access control over the UUTs in a lab. For example, one team could be allowed to reserve devices from one device pool in the lab, and a different team could be allowed to reserve a different set of devices. Suppose a new wireless access point is being developed. There may be a set of these access points in a lab, and they can all belong to the same device pool. Perhaps only a small number of teams involved in the development of this product will have access to this device pool. There could also be another device pool containing a larger number of old / abundant switches which are allowed to be reserved by a wider set of users.

Connection Domain
A connection domain is a LaaSv2 concept which represents the ability to configure a connection between different UUT interfaces. For example, all of the UUT interfaces connected to the same L2 switch are in the same L2 connection domain. If there is a different L2 switch, then the UUT interfaces connected to it belong to a different L2 connection domain. If a trunk connection was added between the two L2 switches then there would be one single L2 connection domain instead of 2. Connection domains could even span multiple labs. For example, if there are Cisco Nexus 9300 devices in different labs but which support configuring a VXLAN link between them, the UUT interfaces connected to the 9300s would share a connection domain even though they aren't all in the same lab.

Roles
A role is a collection of privileges, as well as a name and a description string. A privilege is a string which represents some operation, e.g.  or. A role looks like this, from an API point of view:

Permissions
A user who has an owner role for a resource is allowed to grant access to others by creating a permission. A permission is an association between a usergroup, a role and an object_id. The object_id is the unique identifier for the resource (LaaSv2 assigns a UUID id for all resources). For example, a lab admin will have a permission which gives them the lab_owner role for their lab. They may grant roles to other usergroups for this lab, including even the lab_owner role, but in most cases they will want to grant a role with a more limited set of privileges. Note that if a lab admin assigned the lab_owner role to another usergroup, they are no longer the sole owner of the lab! A user may also delete any permissions which they have created, which revokes access.

Usergroups
A usergroup is a collection of users. LaaSv2 usergroups simply mirror Cisco (LDAP) groups, (i.e. Cisco groups are the source of truth). A sync every 30 minutes to update get the latest. An implementation detail: each user also has their own private usergroup, which only they are a part of. Whenever someone creates a resource in LaaSv2, their private usergroup is granted an owner role for that resource (i.e. LaaSv2 automatically creates a permission which assigns the associated owner role to the users private usergroup). For example, if someone has a role with the  privilege then they are allowed to create domains. When they create the domain, LaaSv2 automatically creates a permission which assigns their private usergroup the  role for the object_id (the resource identifier for that domain).

Physical Device
An actual physical DUT on the lab (Router, Switch, WLC, AP, etc.).

It belongs to Device pool -> Lab

Interface
A particular interface of a device. It will eventually be mapped to a topology interface.

It has zero or more tags, that can be used as a constraint to be mapped to a connection.

For example, a topology interface can request, and only the device interface with a tag called   will be candidates for the topology interface.

Static VM
A Virtual machine which is pre-provisioned. It will be imported to the inventory and won’t be destroyed

It belongs to the same Lab andas an associated vCenter host

vCenter Host
A lab can have zero or more vCenters. Each vCenter belongs to a lab.

Node
Basic building block of a topology. It will be mapped at reservation time to either a:


 * Physical device
 * Static VM
 * Dynamic VM
 * Container
 * External connection

External Connection Node
A virtual device that represents a connection with a particular destination, for example:


 * A connection to another topology
 * A connection to a management network

Reservations

 * To instantiate a topology and assign actual lab entities to it (like routers, switches, VMs, etc), a reservation must be created.
 * A reservation contains the time-domain information required to create a topology instance. These are the types of reservations:
 * or  reservation: Create an instant reservation
 * rerservation: Create a reservation for a specific time.

Jani 1408 (talk) 05:47, 6 June 2024 (UTC)

Add Lab to Laas
1.From Main Menu

2.select prefixes

3.fill the all data

4.click on create

TERMINAL SERVER:


 * Term Server Port: is from terminal server going to device's console port
 * Console Port: is port on the device labeled as  on Cisco devices
 * Conosle Cable: is cable connect between  to   on the device

To add terminal server port


 * 1) Select a terminal server to change
 * 2) Select Terminal Server Port from the menu
 * 3) Select Add Components from top right menu
 * 4) Select Terminal Server Ports
 * 5) Select Telnet or SSH from protocol accordingly
 * 6) * Fill out port number
 * 7) * Line number

Add Management Interface and IP


 * 1) Select a terminal server to change
 * 2) Select Interfaces from menu
 * 3) Click Add Interface from the top right corner
 * 4) Provide a name of the management interface
 * 5) Select Management Config
 * 6) Select Enable
 * 7) Fill out the info accordingly

pdu


 * PDU outlet: is the numeric number label on the PDU
 * Power Supply: is the device's power supply
 * Power cable: is the cable connecting between each PDU outlet to each device's power supply

Jani 1408 (talk) 06:00, 6 June 2024 (UTC)

Device pools
Every device in LaaSv2 must be in a device pool. A device pool is a collection of devices that share the same set of permissions. For example, you can create a device pool for the devices reserved to the testing team, another device pool for the devices used by developers, and another one for devices used for customer recreations.

Adding devices


 * 1) Click Devices on the menu
 * 2) Click Add Resources on the top right corner and select Device
 * 3) Add Management interface
 * 4) Add Interfaces
 * 5) Add Power Supplies, this the power supply on the device
 * 6) To connect the power supply to PDU; move the mouse over the name of the power supply port; select the connect symbol
 * 7) Select PDU and port
 * 8) Click Save to finish

Jani 1408 (talk) 06:04, 6 June 2024 (UTC)

Create Topology

 * once devices have been added to LaaSv2 DB and its links auto-learnt, LaaSv2 will create topologies with devices that are directly connected
 * Topologies can be edited or added using API, YAML, WebUI and/or migrated from LaaSv1

Create a topology from Topologies page

1.topologies from main menu

2.add topology

3.select device and drag to canvas page

4.create link between devices

5. add device properties and link properties Jani 1408 (talk) 06:10, 6 June 2024 (UTC)

Laas KT Videos
1.Introduction to Laas and details about Interface:

https://cisco.webex.com/recordingservice/sites/cisco/recording/6ecea9c54d0e4bc69df1cc0c8e43b768/playback

Password: ZigwjNi9

2.Test device, Ipam

https://cisco.webex.com/recordingservice/sites/cisco/recording/49c82cbcbd1a47b894387ec8624d2d99/playback

Password: nFRTPNP2

3.Topology

https://cisco.webex.com/recordingservice/sites/cisco/recording/c3a258b55376463eab1fb534f7679f75/playback

Password: iNEhXBE6

4.How to update Laas Version

https://cisco.webex.com/recordingservice/sites/cisco/recording/29240753181b4e94a3ba20f3baab1b6f/playback

Password: gMKZq3HS

5.Jira Tickets

https://cisco.webex.com/recordingservice/sites/cisco/recording/b34c631237cf464a85691d5fcba3e059/playback

Password: eFZkn9GP