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.
For simple network topology simulations, access to simulated nodes can be conducted through the Cisco Modeling Labs server’s management interface , Ethernet0. This is useful for simulation scenarios that do not require connection to external devices, and leverages the Cisco Modeling Labs server's management interface for communications with the virtual devices. No Flat or SNAT interfaces are configured or referenced, and no option is specified within the project’s
setting. In this minimal configuration, connections to the virtual nodes instances are facilitated through the Cisco Modeling Labs’s client Server management option.Telnet via Cisco Modeling Labs Client Console
SSH via Cisco Modeling Labs Client Console
Access via User Workspace Management Interface
Another option is to access the nodes in a running simulation through the User Workspace Management interface via a web browser. After entering log in credentials, click the My Simulations option to view a list of running simulations. Select the applicable simulation to view a list of nodes comprising the running simulation. To access a node, click one of the ports icons, representing Serial-0, Serial-1, or the Management port, associated with the desired node. As shown, a corresponding session is started for the selected node.
Depending on how the Cisco Modeling Labs environment has been set up by the system administrator, you may have several ways to externally connect to the nodes in a running simulation.
Bypass the Cisco Modeling Labs client and connect directly to nodes via Out of Band Management IP access using FLAT
If enabled by the system administrator, when designing your virtual network, you can specify that you want all nodes to be configured on a reserved management network. All management interfaces are connected to a shared management network segment known as FLAT. This set up will allow you to bypass the Cisco Modeling Labs client and connect directly via Telnet to the nodes.
Connecting to external devices using FLAT Inband access
Note | Your simulation continues to be driven through the Cisco Modeling Labs client GUI by communicating with the Cisco Modeling Labs server at its IP address that is bound to the relevant management port. |
Connecting to external devices using SNAT Inband access
As an alternative to Inband access using FLAT, you can set up the Static NAT (SNAT) approach. SNAT is a Layer-3 solution that leverages the use of an internal SNAT router to hide the IP addresses in your topology. This router, internal to the Cisco Modeling Labs server, translates IP addresses inbound and outbound which means that the addressing schemes used on the virtual topology are not propagated outside the virtual network.
When configured, an internal and an external address are assigned to the SNAT-assigned interface on the nodes. For example, configuring 10.11.12.1 as the internal address, and mapping it to 172.16.2.51 externally. Traffic sent to 172.16.2.51 will be translated to the correct internal address and presented to the appropriate node.
Note | Your simulation continues to be driven through the Cisco Modeling Labs client by communicating with the Cisco Modeling Labs server at its IP address that is bound to the relevant management port. |
There are situations when an external terminal client may be preferred over the Cisco Modeling Labs client for accessing the nodes’ console. Factors may just be familiarity, or to capture and save session commands and respective responses to configuration changes.
Standard Telnet Sessions
Note | The TCP port is a transient value generated upon spinning up the virtual node. If the party accessing the nodes does not have a Cisco Modeling Labs project login account, the project owner/administrator will need to provide the node access socket details. |
SSH Sessions
If using an external terminal emulator, an SSH session directed to the JumpHost socket will open a terminal session on the JumpHost. After entering user credentials (same as those for the Cisco Modeling Labs server), the logged in user will then manually initiate a Telnet session to the desired node using its management interface.
The Cisco Modeling Labs client is not required to access nodes within a running project simulation. When configured, the out-of-band (OOB) management network interface for the running nodes may be accessible by external (physical) devices. A variety of methods employ a Layer-2 connection through the Ethernet1 interface, designated as Flat. This can be useful when you want to grant access to nodes within a running project to users without Cisco Modeling Labs credentials.
Note | All running projects configured with Shared Flat Network as the Management Network will have their constituent nodes exposed to the Flat network interface with an IP address assigned from the provisioned Flat subnet range. As such, project users are able to access operating nodes beyond those associated with their specific project. |
Use Private Management Networks: When the simulation’s Management Network is set as Shared Flat Network, all nodes within the topology are assigned an IP address from the pool provisioned for the Flat network interface (Eth1) and are accessible to any user attached to the Eth1 interface. To provide additional isolation from other users, the topology may be optioned with an internal OOB management network. When set for private management, the simulation-nodes’ OOB interfaces are assigned, by default, addresses from the 10.255.0.0/24 range.
A private OOB management network may be established at the project-level with multiple simulations within a common project or per simulation. When a private OOB management network is implemented, access to the simulation’s virtual nodes is limited to the Cisco Modeling Labs client, or via SSH to the jumphost when external terminals are used.
By using an out-of-band (OOB) network connection to the Cisco Modeling Labs simulation, you can connect an external application to the Management port of any router node in the simulated network. All management ports will have an IP address on the OOB network, which is a separate network from the other interface IP addresses.
Step 1 | Log in to the Cisco Modeling Labs client. | ||
Step 2 | Verify you have connectivity to the Cisco Modeling Labs server. | ||
Step 3 | Open the Design perspective, if it is not already open. | ||
Step 4 | Open an existing topology or create your network topology. See Create a Topology for information on how to do this. | ||
Step 5 | Configure the OOB management network. The Shared flat network option is what enables the OOB connectivity. | ||
Step 6 | From the
toolbar, click the
Build Initial
Configurations tool.
| ||
Step 7 | After the build phase is completed, initiate the simulation by clicking the Launch Simulation tool in the toolbar, and then change to the Simulation perspective. | ||
Step 8 | (Optional) Enter
the
ping command
on the PC to confirm that the management port on a running node can be reached.
| ||
Step 9 | (Optional) In the
Cisco Modeling Labs client simulation, connect to a console port on a node and
confirm the management network IP address exists. Enter the
show ip interface
brief command to display the IP addresses. For this example, use the IP
address 172.16.1.51.
| ||
Step 10 | Launch and
configure a terminal emulator for a Telnet connection to the node management
port. In this example, the PuTTY application is used.
|
The following procedure describes how to configure a second FLAT network to your simulation. A FLAT network uses Layer 2 connectivity, in which the IP address information about your virtual network can be viewed externally.
Managing nodes via the Cisco Modeling Labs client or using terminal emulator sessions via OOB management interfaces work well when the access is exclusively used for management plane interactions. When external connectivity will be used for both management-plane and data-plane traffic exchanges with external devices, an In-Band management solution may be warranted. As shown in the following figure, the Flat (Eth1) interface is associated with an interface on the new-york node, to which an IP address from the Flat-interface address pool is assigned.
Using the L2 External (FLAT) object precludes the simultaneous use of the Out-of-Band management option. The Management Network option within
is not defined (<not specified>) as shown above.During the topology’s launch phase, an IP address from the range provisioned for the Flat (Eth1) interface (by default, 172.16.1.0/24) is assigned to the associated interface on new-york. The externally attached terminal or management device is then manually configured with an unused IP address within this scope. An alternative option is to enable DHCP services on the node as to offer an IP address to the attached workstation.
Note | In multiuser deployments, consideration must be given to DHCP scope and exclusion ranges applied to nodes within simulation environments and to coordinate the assignment ranges being facilitated by the Cisco Modeling Labs server during topology build/launch phases. Otherwise, multiple agents assigning addresses from overlapping pools might result in duplicate address assignments. |
Managing nodes via the Cisco Modeling Labs client or using terminal emulator sessions via OOB management interfaces work well when the access is exclusively used for management plane interactions. When external connectivity is used for both management-plane and data-plane traffic exchanges with external devices, an In-Band management solution may be required.
The following procedure describes how to connect your virtual network topology to physical devices that are external to the Cisco Modeling Labs server environment. In this procedure, you will be configuring a FLAT network. A FLAT network uses Layer-2 connectivity in which the IP address information about your virtual network can be viewed externally.
Note | We recommend that you first draw your intended design, and then label the devices with the appropriate IP addresses. |
Step 1 | Log in to the Cisco Modeling Labs client. | ||
Step 2 | Verify you have connectivity to the Cisco Modeling Labs server. | ||
Step 3 | Open the Design perspective, if it is not already open. | ||
Step 4 | Open an existing topology or create your network topology. See Create a Topology for information on how to do this. | ||
Step 5 | Click on the canvas to open the Topology tab in the Properties view and ensure that Management Network displays <not specified>. | ||
Step 6 | From the Palette view, under General, click the L2 External FLAT tool, and then click the canvas to add one FLAT cloud network icon to each corresponding node icon on the canvas. | ||
Step 7 | From the
Palette
view, under
Tools, click
the
Connect tool
and connect the
L2 External
FLAT to the desired nodes.
| ||
Step 8 | From the
toolbar, click the
Build Initial
Configurations tool.
The system automatically assigns an IP address to the node interface that is connected to the FLAT cloud during the Simulation phase, not the Build phase. | ||
Step 9 | After the build phase is completed, start the simulation by clicking the Launch Simulation tool in the toolbar, and then change to the Simulation perspective. | ||
Step 10 | Log in to the node that is connected to the FLAT network when its state has changed to ACTIVE. | ||
Step 11 | View the IP address assigned to the FLAT network and determine if it is on the same subnet as the gateway IP address provided by your system administrator. The L2 external address for each node can be viewed from the Simulations view or from each individual node. | ||
Step 12 | If the external
device is on a different subnet, define a default gateway or a broadcast domain
that points to the IP address of the gateway that the system administrator
supplies.
Prior to completing this step, if you do a show route, you will see that no default gateway is defined in the node. This is the default set up. This step allows you to inform the node what path to take in order to reach the external environment via the gateway. An alternative to defining a gateway or static route, with IOSv devices, is to enable DHCP on the interface used for external connectivity.
| ||
Step 13 | Test the
connection by pinging from the node to the external (physical) device. If
required, turn on
debug ip
icmp or use the
tracert
command to see the progress through the network.
If the ping does not work, confirm with your system administrator that the Cisco Modeling Labs server is configured to support FLAT connectivity and that the gateway IP address you have been provided is correct. If these items are correct, ping to each of the key devices in the path to determine where the failure occurs and notify your system administrator of the failure source if it is outside your Cisco Modeling Labs environment. |
A Flat interface may also be used to interconnect a group of physical lab devices to nodes running within a simulation.
By default, the node’s interface associated with the Flat object is assigned an IP address from the range provisioned to the Cisco Modeling Labs’ Ethernet1 interface during server installation. This is allotted when the node is spun up by OpenStack when the simulation is launched. Once fully active, the assigned interface address may be adjusted to meet the addressing requirements of the external environment (or the external device’s interface is configured with an appropriate address to interact with the node.) After confirming Layer-2 connectivity between the physical/virtual nodes, implement the necessary (static or dynamic) routing in both physical and virtual lab environments to complete the integration.
When a simulation is launched, an IP address from the Flat (Ethernet1) external address pool is assigned to the respective node interfaces connected to the external icon. While the example functionally matches that of the OOB_Management configuration, it differs in that the interfaces reserved for OOB (GigabitEthernet0/0) are not used. Instead, the next available infrastructure interface is selected for use (or manually allocated).
Note | The upstream (physical) switch interface should not have the BPDU_Guard feature enabled on the associated interface(s) as to prevent any BPDUs originating from virtual nodes from triggering an interface-shutdown. |
Traffic generated by an external source that crosses the virtualized network to another external destination device.
Integrating multiple, physical lab topologies (representing access-networks) to a simulated core topology.
Interconnecting multiple virtual lab scenarios or external virtual machines to a simulated core topology.
Scaling Cisco Modeling Labs topology sizes by interconnecting multiple Cisco Modeling Labs instances across separate servers.
The Cisco Modeling Labs server offers a second bridged interface to enable such test designs. Adding L2 External (FLAT) objects will, by default, be associated to the Flat (Eth1) interface. This default allocation may be manually overridden by editing the object’s properties as to use the server’s Flat1 (Eth2) interface.
Examination of the flat-2 object shows its association to the flat1 Host Network, and the respective iosv-1 interface (GigabitEthernet0/3) assigned an IP address from the Flat1 address pool (172.16.2.0/24 in the example). As additional L2 External (FLAT) objects are added to the canvas, they may remain associated with the default flat interface or edited as described to be associated with the flat1 interface.
When a simulation starts up, IP addresses from the internal infrastructure pool are assigned to their respective node interfaces by OpenStack’s Neutron services. Those interfaces are then mapped to their corresponding external address, also assigned by Neutron services. These internal to external IP mappings are maintained within the Neutron SNAT-Gateway.
Looking at the snat-1 object shows the internal and external addresses assigned to the SNAT gateway function associated with the GigabitEthernet0/1 interface within the new-york node during the spin-up of the project simulation. Manual configuration of the associated nodes is now required to enable traffic to traverse the SNAT gateway, where static routing statements must be added to the simulated device “attached” to the snat-1 object.
Note | The IP addresses shown above are default values that may be adjusted during the Cisco Modeling Labs server installation process. Viewing the Connectivity information in the User Workplace Management interface ensures that the correct details are employed. If the User Workplace Management interface is not available, the necessary details must be provided by the system administrator. |
The SNAT-attached nodes will require appropriated static routing commands applied to their running configurations. As with the single SNAT connection, these may be inserted via console sessions with each of the nodes after launching. This will also require configuration extraction prior to shutting down the simulation if the topology is expected to be run again.
Note | The node to snat-n links shown above do not represent Layer-3 links to distinct external devices. |
To set up a SNAT Network for inband access, complete the following steps:
Ensure that the system administrator has configured the Cisco Modeling Labs server to allow SNAT connections.
Ensure that the system administrator provides you with the internal and external IP addresses of the SNAT router.
Ensure that you have the IP address to the default gateway.
Ensure that you have the IP address of the external device to which the nodes will connect.
Step 1 | Log in to the Cisco Modeling Labs client. | ||
Step 2 | Verify you have connectivity to the Cisco Modeling Labs server. | ||
Step 3 | Open the Design perspective, if it is not already open. | ||
Step 4 | Open an existing topology or create your network topology. See Create a Topology for information on how to do this. | ||
Step 5 | Click on the
canvas to open the
Topology
tab in the
Properties view and ensure that
Management
Network displays
<not
specified>.
| ||
Step 6 | From the Palette view, under General, click the L3 External SNAT tool, and then click the canvas to add one SNAT cloud network icon to each corresponding node icon on the canvas. | ||
Step 7 | From the
Palette
view, under
Tools, click
the
Connect tool
and connect the
L3 External
SNAT to the desired nodes.
| ||
Step 8 | From the
toolbar, click the
Build Initial
Configurations tool.
The system automatically assigns the internal and external IP addresses to the node interface that is connected to the SNAT cloud during the Simulation phase, not the Build phase. Therefore, no assigned addresses are visible at this point. | ||
Step 9 | After the build phase is completed, start the simulation by clicking the Launch Simulation tool in the toolbar, and then change to the Simulation perspective. | ||
Step 10 | Log in to the node that is connected to the SNAT network when the status of the device has changed to ACTIVE. | ||
Step 11 | Create a static
route or define a default gateway for the external connection IP addresses that
point to the SNAT router’s internal IP address. For example, if the external
connections are part of the subnet 172.16.2.0/24, and the SNAT router’s
internal IP address is 10.11.11.1, then the route statement would be:
ip route 172.16.2.0 255.255.255.0 10.11.11.1 An alternative to defining a gateway or static route, with IOSv devices, is to enable DHCP on the interface used for external connectivity.
| ||
Step 12 | Test the
connection by pinging from the node to the external (physical) device. If
required, turn on
debug ip
icmp or use the
tracert
command to see the connectivity between the end points.
If the ping does not work, confirm with your system administrator that the Cisco Modeling Labs server is configured to support SNAT connectivity and that the gateway IP address you have been provided is correct. If these items are correct, ping to each of the key devices in the path to determine where the failure occurs and notify your system administrator of the failure source if it is outside your Cisco Modeling Labs environment. |