Compare commits
38 Commits
aaa-tacacs
...
202c430cf4
Author | SHA1 | Date | |
---|---|---|---|
|
202c430cf4 | ||
|
00665a7564 | ||
|
3952e23fa0 | ||
|
e22d6a170b | ||
|
4106a62170 | ||
|
a0925ec081 | ||
|
0683e4af4a | ||
|
c9f06ab4c6 | ||
|
8d16025b29 | ||
|
54dc0a6c4e | ||
|
ad902c9602 | ||
|
385766c69f | ||
|
4cc9778d53 | ||
|
79c0df82aa | ||
|
2b5b77ceb2 | ||
|
ea6f212a88 | ||
|
ecae100078 | ||
|
0b7bb154f8 | ||
|
568e961235 | ||
|
1f510d7b08 | ||
|
a4205b4bfe | ||
|
9aabef36f5 | ||
|
a9cdfb5a71 | ||
|
a37d7651b3 | ||
|
8f1cbca437 | ||
|
0095977080 | ||
|
1e71172679 | ||
|
3d899609cf | ||
|
8a340d947c | ||
|
02ce8eb54e | ||
|
db9ef78ace | ||
|
5789f89faa | ||
|
e066d1a1c2 | ||
|
c6bfcb8f01 | ||
|
edc671c576 | ||
|
d7282f17ca | ||
|
8bf3652cf7 | ||
|
1b2a390acf |
3
.gitmodules
vendored
@@ -13,9 +13,6 @@
|
||||
[submodule "use-cases/ansible-cml"]
|
||||
path = use-cases/ansible-cml
|
||||
url = https://github.com/CiscoDevNet/ansible-cml
|
||||
[submodule "use-cases/cml-nxos-l3-edge-fabric"]
|
||||
path = use-cases/cml-nxos-l3-edge-fabric
|
||||
url = https://github.com/charliefenwick/cml-nxos-l3-edge-fabric
|
||||
[submodule "use-cases/sdwan-devops"]
|
||||
path = use-cases/sdwan-devops
|
||||
url = https://github.com/CiscoDevNet/sdwan-devops
|
||||
|
@@ -4,7 +4,7 @@
|
||||
|
||||
Community Contributed Content and Resources for Cisco Modeling Labs
|
||||
|
||||

|
||||

|
||||
|
||||
## Repository Description
|
||||
|
||||
@@ -31,7 +31,7 @@ A great way to make your repo easy for others to use is to provide a link to a [
|
||||
|
||||
If you are new to Cisco Modeling Labs, you can explore and test drive CML within [DevNet Sandbox](https://developer.cisco.com/site/sandbox/). Just search for "Cisco Modeling" from the Sandbox Catalog.
|
||||
|
||||

|
||||

|
||||
|
||||
## Getting help
|
||||
|
||||
@@ -41,10 +41,7 @@ Instruct users how to get help with this code; this might include links to an is
|
||||
|
||||
If you have questions, concerns, bug reports, etc., please create an issue against this repository.
|
||||
|
||||
If you've questions on using CML, here are some places to checkout:
|
||||
|
||||
* [Cisco Modeling Labs Support](https://developer.cisco.com/docs/modeling-labs/#!support)
|
||||
* [Cisco Modeling Labs Webex Teams Space](https://eurl.io/#bWHTbWz1Z)
|
||||
If you've questions on using CML, post them to our [CML community](https://developer.cisco.com/docs/modeling-labs/#!support).
|
||||
|
||||
## Getting involved
|
||||
|
||||
|
74
documentation/cml_on_hyperv.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# CML on Hyper-V
|
||||
These instructions explain how to deploy CML as a virtual machine (VM) that runs on Hyper-V on Windows. (When deploying to Hyper-V, you do not need to install VMware Workstation on your local system.) You will need a version of Windows that supports and provides the Hyper-V feature. Recent versions of Windows Pro and Windows Enterprise should work. Windows Server 2016 should also include Hyper-V, but the steps to deploy on Windows Server may differ slightly. These instructions will probably not work on other editions of Windows, such as Windows 11 Home. YMMV.
|
||||
|
||||
These instructions were tested on Windows 11 Enterprise but should work for other editions of Windows that meet the requirements.
|
||||
|
||||
## Requirements
|
||||
- Windows 10 Pro/Enterprise or later, Server 2016 or later
|
||||
- Hyper-V windows feature installed and enabled
|
||||
|
||||
## Setup
|
||||
### Enable Hyper-V
|
||||
To enable Hyper-V on Windows refer to these [instructions](https://learn.microsoft.com/en-us/virtualization/hyper-v-on-windows/). The steps below are a summary of what is provided in the linked documentation.
|
||||
- Open the **Control Panel**
|
||||
- Click **Programs** and then **Programs and Features**
|
||||
- Click **Turn Windows Features on or off**
|
||||
- Check the checkbox for the top-level **Hyper-V** feature to enable all Hyper-V features
|
||||
- Click **OK**
|
||||
- Reboot when asked
|
||||
|
||||
### Create Hyper-V Bridged Network
|
||||
By default, the CML VM will only be visible from your local host OS where Hyper-V is running. If you would like to access the CML VM from a different host on your network, you must create a bridged network in Hyper-V. You will also need to create a Hyper-V bridged network if you would like to send traffic into a lab running on the CML VM from another host or device on your network. See the CML documentation on [external connectors](https://developer.cisco.com/docs/modeling-labs/external-connectors/) for further information.
|
||||
|
||||
If you only plan to access the CML instance or the labs running in CML from the local machine where Hyper-V is running, you can skip these steps.
|
||||
|
||||
- Launch the Hyper-V GUI
|
||||
- In the menu on the right of the screen, click **Virtual Switch Manager**
|
||||
- In the **Create virtual switch** section, select **External** and click **Create Virtual Switch**
|
||||
- From the list of external network cards, select a network card connected to your local network
|
||||
- Click **OK** to save the changes
|
||||
|
||||
If you skip the above steps and decide later to utilize external network connections, you can follow the above instructions later. However, you will need to edit the virtual machine settings (created below) and change the associated _Virtual Switch_ to one created above to enable external connections.
|
||||
|
||||
### Create Hyper-V Virtual Machine
|
||||
Before proceeding with the following steps, make sure to [download the latest CML ISO](https://developer.cisco.com/docs/modeling-labs/downloading-files-for-cml-installation/). For this step you do **NOT** need the _refplat_ ISO image, only the ISO for the _bare metal installation_.
|
||||
|
||||
#### Initial Creation
|
||||
- Open the Hyper-V GUI from the windows start menu
|
||||
- In the menu on the right of the screen, click **New** and **Virtual Machine** to open the **New Virtual Machine Wizard**
|
||||
- Click **Next** on the **Before You Begin** screen if it was not previously dismissed
|
||||
- On the **Specify a Name and Location** screen, use a **Name** without spaces to avoid quoting/escaping issues
|
||||
- On the **Specify Generation** screen, select **Generation 2**
|
||||
- On the **Assign Memory** screen, assign sufficient memory to meet the requirements for CML, as well as any labs you wish to run. Refer to the [CML documentation](https://developer.cisco.com/docs/modeling-labs/system-requirements/).
|
||||
- Do **NOT** use dynamic memory
|
||||
- **ATTENTION** Using dynamic memory with the CML VM will have a negative impact on the performance on your labs running in the CML VM. The nodes in your network simulation use nested virtualization, and using dynamic memory in Hyper-V can cause _significant_ performance problems because of page swapping.
|
||||
- On the **Configure Networking** screen, connect the network adapter to either the external network (created above) or the default Hyper-V virtual switch (if you wish to only access CML from the host machine)
|
||||
- On the **Connect Virtual Hard Disk** screen, assign sufficient disk space to meet the requirements for CML, as well as labs you wish to run. Refer to the [CML documentation](https://developer.cisco.com/docs/modeling-labs/system-requirements/).
|
||||
- On the **Installation Options** screen, select **Install an Operating System Later**
|
||||
- Click **Finish** to create the VM. Note the name of the VM you created for the following steps.
|
||||
|
||||
#### Additional Settings
|
||||
- Right click the virtual machine you just created in the **Virtual Machines** list and select **Settings**
|
||||
- Click the **Security** tab in the left menu
|
||||
- In the **Security Settings** section, uncheck **Enable Secure Boot** on the right to disable it
|
||||
- Click the **Processor** tab in the left menu
|
||||
- In the **Processor** section, adjust **Number of Virtual Processors** according to the CML requirements and your lab demands. Refer to the [CML documentation](https://developer.cisco.com/docs/modeling-labs/system-requirements/).
|
||||
- Click the **SCSI Controller** tab in the left menu
|
||||
- In the **SCSI Controller** section, select **DVD Drive** and click **Add**.
|
||||
- Under the **Media** section, select **Image File** and click **Browse** to select the CML bare metal installation ISO you downloaded earlier
|
||||
- Click **OK** to save the configuration changes. Do **NOT** start the VM yet.
|
||||
|
||||
### Enable Nested Virtualization
|
||||
- Open a PowerShell prompt as an administrator
|
||||
- Run
|
||||
```powershell
|
||||
PS C:\> Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
|
||||
```
|
||||
`<VMName>` should be replaced with your VM name from above. Quote appropriately if it contains spaces.
|
||||
|
||||
|
||||
### Boot the Virtual Machine and configure CML
|
||||
- Double click the CML VM in the **Virtual Machines** list
|
||||
- Click the green **Start** button in the toolbar
|
||||
- Follow the [CML instructions](https://developer.cisco.com/docs/modeling-labs/bare-metal-installation-bare-metal-installation/) for a bare metal installation
|
||||
|
34
documentation/cml_on_nutanix.md
Normal file
@@ -0,0 +1,34 @@
|
||||
### CML on Nutanix CE
|
||||
|
||||
##### Requirements:
|
||||
- Installed and configured Nutanix CE node (or cluster) from https://www.nutanix.com/uk/products/community-edition
|
||||
- Downloaded CML installation ISO/OVA and refplat ISO image
|
||||
|
||||
##### Install CML from ISO
|
||||
- Upload install and refplat ISOs to datastore. Go to Settings and Image Configuration. Select correct storage container (Images in our case) and other details and click Save.
|
||||
- Wait until upload task is completed.
|
||||
- Go to Settings/VM and click 'Create VM'. Fill name of VM, select number of vCPUs, cores, memory.
|
||||
- Switch BIOS Configuration to UEFI. If you need secure boot, switch cdrom from IDE to SATA.
|
||||
- Update cdrom settings and insert CML iso there:
|
||||
- Add new disk, select correct storage container (VMs in our case)
|
||||
- Add also at least one NIC
|
||||
- Save VM, open ssh connection to CVM and enable nested virtualization on CML VM:
|
||||
```shell
|
||||
nutanix@NTNX-d295a2f4-A-CVM:10.0.10.90:~$ acli vm.list
|
||||
VM name VM UUID
|
||||
cml-ova-import-test b7854f03-3117-453e-9221-2611eefe0b94
|
||||
cml-test-2.8.0dev e56f7e8d-a663-4826-b128-8e98ba8f1c84
|
||||
ova-cml-test a1dce5ed-5d12-4096-a48f-293c35837f88
|
||||
ubuntu-test-vm d5c8d107-d58f-4d6f-a585-77ef494cf2a5
|
||||
nutanix@NTNX-d295a2f4-A-CVM:10.0.10.90:~$ acli vm.update cml-test-2.8.0dev cpu_passthrough=true
|
||||
cml-test-2.8.0dev: pending
|
||||
cml-test-2.8.0dev: complete
|
||||
```
|
||||
- Power on VM and launch VM console. Proceed with CML setup. Insert refplat ISO to cdrom when needed.
|
||||
|
||||
##### Installing CML from OVA:
|
||||
In Nutanix CE, there is no option how to import OVA, you need Prism central from paid version. There should be OVA import feature in GUI - more info is here: https://portal.nutanix.com/page/documents/kbs/details?targetId=kA03200000099TXCAY
|
||||
|
||||
In Nutanix CE, untar OVA file and upload vmdk disk into image storage container.
|
||||
When creating VM, just use 'Clone from Image Service'.
|
||||
Everything else is same as when installing from ISO.
|
49
documentation/cml_on_proxmox.md
Normal file
@@ -0,0 +1,49 @@
|
||||
### CML on Proxmox
|
||||
|
||||
##### Requirements:
|
||||
- Installed and configured Proxmox node (or cluster) from https://www.proxmox.com/en/downloads
|
||||
- Downloaded CML installation ISO/OVA and refplat ISO image
|
||||
|
||||
##### Install CML from ISO
|
||||
|
||||
- Import install and refplat ISOs via GUI (Folder View / Storage / local storage / ISO images / Upload or Download from URL)
|
||||
If upload is not working (wrong file extension error), copy ISO files to /var/lib/vz/template/iso/ (or any other ISO compatible storage) on Proxmox host via shell.
|
||||
- Start creating new VM
|
||||
- General tab
|
||||
- fill VM name
|
||||
- OS tab
|
||||
- switch storage to one where ISOs were uploaded
|
||||
- select CML install ISO from ISO image dropdown
|
||||
- System tab
|
||||
- select VirtIO SCSI single controller
|
||||
- switch BIOS to OVMF (UEFI)
|
||||
- select some storage for EFI disk
|
||||
- Disks tab
|
||||
- set disk size to at least 32GB
|
||||
- CPU tab
|
||||
- set needed number of Sockets and Cores
|
||||
- CPU type must be set to 'host' to support nested virtualization
|
||||
- Memory tab
|
||||
- set amount of memory
|
||||
- Network tab
|
||||
- choose correct network/MTU etc for first interface (if more interfaces are needed, they must be added after VM creation via Hardware / Add / Network Device option)
|
||||
|
||||
Finish VM creation. Start VM and follow install instructions. Switch install iso for refplat when needed.
|
||||
|
||||
##### Install CML from OVA
|
||||
|
||||
- Import reflat ISO via GUI (Folder View / Storage / local storage / ISO images / Upload or Download from URL)
|
||||
If upload is not working (wrong file extension error), copy ISO file to /var/lib/vz/template/iso/ (or any other ISO compatible storage) on Proxmox host via shell.
|
||||
- Copy OVA file to folder for example /var/lib/vz/template/ova/ on Proxmox host.
|
||||
- Unzip OVA with 'tar -xf cml2_2.7.0-5_amd64-21.ova' command.
|
||||
- From /var/lib/vz/template/ova/ run import commad: `qm importovf 107 cml2_2.7.0-5_amd64-21_SHA256.ovf local-lvm`. 107 is VM id, choose some not used already, and local-lvm is VMs storage.
|
||||
- Go to Proxmox GUI and open newly created VM (id 107 in our case).
|
||||
- Edit HW of VM:
|
||||
- switch BIOS to OVMF (UEFI)
|
||||
- add new HW 'EFI disk'
|
||||
- set processor type to 'host'
|
||||
- change SCSI controller to 'VirtIO SCSI single'
|
||||
- add Network Device and set model to 'VirtIO Paravirtualized' (add more NICs if needed)
|
||||
- add CD/DVD Drive and select appropriate storage and iso image
|
||||
|
||||
Boot VM and complete CML installaion
|
376
lab-topologies/aaa-tacacs-exploration/README.ios-nxos.md
Normal file
@@ -0,0 +1,376 @@
|
||||
# Exploring AAA / TACACS Device Administration Configuration in IOS and NX-OS.
|
||||

|
||||
|
||||
Verifying the identity of the people who log into network, what each person is allowed to do on a network device, and tracking what was done is a critical part of network operations. Collectively these are known as "Triple A Services", or Authentication, Authorization, and Accounting. Another name used is "Role Based Access Control", or RBAC.
|
||||
|
||||
TACACS+ is a common protocol used for RBAC / AAA on network devices, and this lab explores how to configure AAA on both IOS and NX-OS devices.
|
||||
|
||||
> RADIUS is another protocol that can be used for device administration with AAA.
|
||||
|
||||
A TACACS server must be available on the network for devices to send AAA requests to for validation. This lab leverages an open source `tac_plus` server as a lightweight service that can be easily installed on an Ubuntu host within the topology. For more information on `tac_plus` see the documentation for [`tac_plus`](https://manpages.ubuntu.com/manpages/trusty/man8/tac_plus.8.html) and [`tac_plus.conf`](https://manpages.ubuntu.com/manpages/trusty/man5/tac_plus.conf.5.html). The starting config for `aaa-server` installs `tac_plus` and deploys a basic TACACS configuration to support IOS and NX-OS hosts connecting for user authentication, role based authorization (administrator and operator), and accounting. The configuration file `tac_plus.conf` is located at `/etc/tacacs/tac_plus.conf`. You can modify this configuraiton file and restart `tac_plus` (`sudo systemctl restart tac_plus`) as part of your own learning.
|
||||
|
||||
> Command authorization is not part of this lab guide, and the `tac_plus` server is ***NOT*** configured for command authorization as part of the initial configuration. Though you can update the `tac_plus.conf` file and experiment with command authorization on your own.
|
||||
|
||||
# Configuring an IOS device for TACACS device administration
|
||||
|
||||
## Starting Configuration on `ios01`
|
||||
|
||||
`ios01` has the following configuration applied as startup configuration to enable inbound SSH from `desktop` that is locally authenticated.
|
||||
|
||||
```
|
||||
ip domain name lab.intra
|
||||
crypto key generate rsa general-keys modulus 2048
|
||||
!
|
||||
aaa new-model
|
||||
!
|
||||
username cisco priv 15 secret cisco
|
||||
```
|
||||
|
||||
|
||||
## Ensuring the serial / console leverages local authentication
|
||||
To provide safety and fallback access to devices, we will force the console line to only use local admin accounts.
|
||||
|
||||
```
|
||||
aaa authentication login CONSOLE local
|
||||
aaa authorization console
|
||||
aaa authorization exec CONSOLE local
|
||||
!
|
||||
line con 0
|
||||
login authentication CONSOLE
|
||||
authorization exec CONSOLE
|
||||
!
|
||||
```
|
||||
|
||||
## Configuring TACACS server as default AAA
|
||||
|
||||
Start by identitying the interface that TACACS packets should be sourced from. This is often important because TACACS servers typically only respond to known hosts/addresses.
|
||||
|
||||
```
|
||||
ip tacacs source-interface Ethernet0/0
|
||||
```
|
||||
|
||||
Now create the TACACS server entry for the server. Be sure to double check the "key" (secret) used for communications.
|
||||
|
||||
> Note: Be careful to NOT add an extra "space" after the key. This can cause problems on some platforms.
|
||||
|
||||
```
|
||||
tacacs server aaa-server
|
||||
address ipv4 192.168.0.10
|
||||
key tacacs123
|
||||
!
|
||||
```
|
||||
|
||||
Create a `aaa group` that includes the TACACS server. In a production environment, you would typically have at least 2 TACASC servers configured for fallback.
|
||||
|
||||
```
|
||||
aaa group server tacacs+ AAA-TACACS
|
||||
server name aaa-server
|
||||
!
|
||||
```
|
||||
|
||||
Test that the TACACS server is responding successfully.
|
||||
|
||||
```
|
||||
test aaa group tacacs+ iosadmin admin123 legacy
|
||||
```
|
||||
|
||||
Configure the authentication, authorization, and accounting policies.
|
||||
|
||||
```
|
||||
aaa authentication login default group AAA-TACACS local
|
||||
aaa authorization exec default group AAA-TACACS local
|
||||
!
|
||||
aaa accounting exec default start-stop group AAA-TACACS
|
||||
aaa accounting commands 1 default start-stop group AAA-TACACS
|
||||
aaa accounting commands 15 default start-stop group AAA-TACACS
|
||||
!
|
||||
```
|
||||
|
||||
## Testing the configuration
|
||||
|
||||
Open the console for the `aaa-server` and monitor the service "journal"
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
```
|
||||
|
||||
Open the console for the `desktop` and attempt to connect to `ios01` with SSH as the `iosadmin` user.
|
||||
|
||||
```
|
||||
ssh iosadmin@192.168.0.1
|
||||
```
|
||||
|
||||
After you log in, run a command to verify access.
|
||||
|
||||
```
|
||||
show ip interface brief
|
||||
```
|
||||
|
||||
Check the output on the `aaa-server`. You should see messages for both the `authentication` and `authorization`
|
||||
|
||||
```
|
||||
# Examples
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5704]: login query for 'iosadmin' port tty2 from 192.168.0.1 accepted
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: connect from 192.168.0.1 [192.168.0.1]
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: Start authorization request
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: do_author: user='iosadmin'
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: user 'iosadmin' found
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: exec authorization request for iosadmin
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: exec is explicitly permitted by line 4
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: nas:service=shell (passed thru)
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: nas:cmd* (passed thru)
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: added 1 args
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: out_args[0] = service=shell input copy discarded
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: out_args[1] = cmd* input copy discarded
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: out_args[2] = priv-lvl=15 compacted to out_args[0]
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: 1 output args
|
||||
Oct 07 21:30:36 aaa-server tac_plus[5705]: authorization query for 'iosadmin' tty2 from 192.168.0.1 accepted
|
||||
```
|
||||
|
||||
Stop the journalctl monitor (`Cntrl-c`), and open the accounting log.
|
||||
|
||||
```
|
||||
tail -f /var/log/tac_plus.acct
|
||||
```
|
||||
|
||||
> Note: If the command fails and the file isn't found, return to the SSH session to the router and run a couple commands. The file isn't created until an accounting message is sent to the server.
|
||||
|
||||
Run some more commands on `ios01`. Try some that are `priv 15` as well as `priv 1`
|
||||
|
||||
```
|
||||
! Priv 1
|
||||
show ip route
|
||||
! Priv 15
|
||||
write mem
|
||||
```
|
||||
|
||||
Verify the accounting logs were received.
|
||||
|
||||
Logout from the router, and log in as `iosoper`. Verify through the same logs that the user is given the correct access.
|
||||
|
||||
# Configuring an NX-OS device for TACACS device administration
|
||||
|
||||
## Enabling and configuring TACACS for AAA on `nxos01`
|
||||
The Nexus network operating system requires features to be `enabled` before they can become available for configuration. Start by enabling `tacacs+`.
|
||||
|
||||
```
|
||||
feature tacacs+
|
||||
```
|
||||
|
||||
Next configured `aaa-server` as a tacacs-server.
|
||||
|
||||
```
|
||||
tacacs-server host 192.168.0.10 key tacacs123
|
||||
```
|
||||
|
||||
Create a server group for TACACS servers. Like with IOS, typically you would configured at least 2 `tacacs-server` entries for redundancy.
|
||||
|
||||
> Nexus switches typically leverage a dedicated management interface (`mgmt0`) that is in a dedicated `management` VRF. Be sure to configure the settings on the group, otherwise the switch will default to using the "global" or "default" VRF to reach the TACACS server, which may fail.
|
||||
|
||||
```
|
||||
aaa group server tacacs+ AAA-TACACS
|
||||
server 192.168.0.10
|
||||
use-vrf management
|
||||
source-interface mgmt0
|
||||
```
|
||||
|
||||
Test that the TACACS server is responding successfully.
|
||||
|
||||
> Be sure to use the correct username for NX-OS devices.
|
||||
|
||||
```
|
||||
test aaa group AAA-TACACS nxosadmin admin123
|
||||
```
|
||||
|
||||
Now configure `aaa authentication login` to leverage the server.
|
||||
|
||||
> NX-OS automatically falls back to try `local` authentication if the TACACS servers are unreachable. So it is ***not*** explicitly added like with IOS.
|
||||
|
||||
```
|
||||
aaa authentication login default group AAA-TACACS
|
||||
```
|
||||
|
||||
Unlike IOS, NX-OS automatically performs `exec` authorization as part of the `authentication login` process. So no `aaa authorization` command is required.
|
||||
|
||||
> If you explore the configuration commands, you will see `aaa authorization commands` as an option. This would check for explicit per-command authorization from the TACACS server whenever a user attempts to run a command. Command authorization is also supported on IOS devices.
|
||||
>
|
||||
> Command authorization is not part of this lab guide, and the `tac_plus` server is ***NOT*** configured for command authorization as part of the initial configuration. Though you can update the `tac_plus.conf` file and experiment with command authorization on your own.
|
||||
|
||||
Lastly, enable AAA accounting
|
||||
|
||||
```
|
||||
! Track "enable" mode, and priv 15 and 1 commands
|
||||
aaa accounting default group AAA-TACACS
|
||||
```
|
||||
|
||||
## Testing the configuration
|
||||
|
||||
Open the console for the `aaa-server` and monitor the service "journal"
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
```
|
||||
|
||||
Open the console for the `desktop` and attempt to connect to `nxos01` with SSH as the `nxosadmin` user.
|
||||
|
||||
```
|
||||
ssh nxosadmin@192.168.0.2
|
||||
```
|
||||
|
||||
After you log in, verify role assigment.
|
||||
|
||||
```
|
||||
show user-account nxosadmin
|
||||
|
||||
! Output
|
||||
user:nxosadmin
|
||||
roles:network-admin vdc-admin
|
||||
account created through REMOTE authentication
|
||||
Credentials such as ssh server key will be cached temporarily only for this user
|
||||
account
|
||||
Local login not possible
|
||||
```
|
||||
|
||||
Check the output on the `aaa-server`. You should see messages for both the `authentication` and `authorization`
|
||||
|
||||
```
|
||||
# Examples
|
||||
Oct 14 17:37:45 aaa-server tac_plus[5888]: connect from 192.168.0.2 [192.168.0.2]
|
||||
Oct 14 17:37:45 aaa-server tac_plus[5888]: pap-login query for 'nxosadmin' port 0 from 192.168.0.2 accepted
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: connect from 192.168.0.2 [192.168.0.2]
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: Start authorization request
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: do_author: user='nxosadmin'
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: user 'nxosadmin' found
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: exec authorization request for nxosadmin
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: exec is explicitly permitted by line 20
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: nas:service=shell (passed thru)
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: nas:cmd= (passed thru)
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: nas:cisco-av-pair* svr:absent/deny -> delete cisco-av-pair* (i)
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: nas:shell:roles* svr:shell:roles="network-admin vdc-admin" -> replace with shell:roles="network-admin vdc-admin" (f)
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: replaced 2 args
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5889]: authorization query for 'nxosadmin' 0 from 192.168.0.2 accepted
|
||||
Oct 14 17:37:46 aaa-server tac_plus[5890]: connect from 192.168.0.2 [192.168.0.2]
|
||||
```
|
||||
|
||||
Stop the journalctl monitor (`Cntrl-c`), and open the accounting log.
|
||||
|
||||
```
|
||||
tail -f /var/log/tac_plus.acct
|
||||
```
|
||||
|
||||
You should see a `start` message for when you logged into the switch.
|
||||
|
||||
```
|
||||
Oct 14 17:40:41 192.168.0.2 nxosadmin 0 192.168.0.11 start task_id=192.168.0.11@pts/3 start_time=1728927636 timezone=UTC service=none
|
||||
```
|
||||
|
||||
Run the command `show version`. You will ***NOT*** see accounting messages on the server. NX-OS only supports command accounting for "admin" commands.
|
||||
|
||||
Run the command `copy run start`. You should see a message such as:
|
||||
|
||||
```
|
||||
Oct 14 17:51:51 192.168.0.2 nxosadmin 0 192.168.0.11 stop task_id=192.168.0.11@pts/3 start_time=1728928303 timezone=UTC cmd=copy running-config startup-config (SUCCESS) service=none
|
||||
```
|
||||
|
||||
Try to configure a loopback interface.
|
||||
|
||||
```
|
||||
config t
|
||||
interface loop1
|
||||
```
|
||||
|
||||
You should see an accounting message.
|
||||
|
||||
```
|
||||
Oct 14 17:51:04 192.168.0.2 nxosadmin 0 192.168.0.11 stop task_id=192.168.0.11@pts/3 start_time=1728928256 timezone=UTC cmd=configure terminal ; interface loopback1 (SUCCESS) service=none
|
||||
```
|
||||
|
||||
Disconnect from the SSH session to `nxos01`. You should see a `stop` message in the accounting log.
|
||||
|
||||
```
|
||||
Oct 14 17:40:44 192.168.0.2 nxosadmin 0 192.168.0.11 stop task_id=192.168.0.11@pts/3 start_time=1728927638 timezone=UTC stop_time=1728927638 service=none
|
||||
```
|
||||
|
||||
Logout from the router, and log in as `tacoper`. Verify through the same logs that the user is given the correct access.
|
||||
|
||||
# Other useful commands and references
|
||||
|
||||
### Network Device Debug commands
|
||||
|
||||
***IOS:***
|
||||
|
||||
```
|
||||
debug aaa authentication
|
||||
debug aaa authorization
|
||||
debug aaa accounting
|
||||
|
||||
debug tacacs authentication
|
||||
debug tacacs authorization
|
||||
debug tacacs accounting
|
||||
```
|
||||
|
||||
***NX-OS:***
|
||||
|
||||
|
||||
```
|
||||
debug aaa aaa-requests
|
||||
debug tacacs aaa-requests
|
||||
```
|
||||
|
||||
### Network Device Show commands
|
||||
|
||||
**IOS:***
|
||||
|
||||
|
||||
```
|
||||
show tacacs
|
||||
show aaa sessions
|
||||
```
|
||||
|
||||
***NX-OS:***
|
||||
|
||||
|
||||
```
|
||||
show tacacs-server
|
||||
show user-account
|
||||
```
|
||||
|
||||
### Test AAA
|
||||
|
||||
**IOS:***
|
||||
|
||||
|
||||
```
|
||||
test aaa group tacacs+ iosadmin admin123 legacy
|
||||
```
|
||||
|
||||
**NX-OS:***
|
||||
|
||||
|
||||
```
|
||||
test aaa group AAA-TACACS nxosadmin admin123
|
||||
```
|
||||
|
||||
|
||||
### aaa-server logs
|
||||
|
||||
***tac_plus logs:***
|
||||
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
tail -f /var/log/tac_plus.acct
|
||||
tail -f /var/log/tac_plus.log
|
||||
```
|
||||
|
||||
### tac_plus server maintenance
|
||||
|
||||
***tac_plus srevice:***
|
||||
|
||||
|
||||
```
|
||||
systemctl status tac_plus
|
||||
sudo systemctl stop tac_plus
|
||||
sudo systemctl start tac_plus
|
||||
```
|
193
lab-topologies/aaa-tacacs-exploration/README.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# Exploring AAA / TACACS Configuration for IOS
|
||||
> Note: An alternative topology file [aaa-exploration-ios-nxos.yaml](aaa-exploration-ios-nxos.yaml) is available that adds a NX-OS switch to the topology and walks through configuring TACACS on this data center platform as well.
|
||||
|
||||

|
||||
|
||||
Verifying the identity of the people who log into network, what each person is allowed to do on a network device, and tracking what was done is a critical part of network operations. Collectively these are known as "Triple A Services", or Authentication, Authorization, and Accounting. Another name used is "Role Based Access Control", or RBAC.
|
||||
|
||||
TACACS+ is a common protocol used for RBAC / AAA on network devices, and this lab explores how to configure AAA on both IOS and NX-OS devices.
|
||||
|
||||
> RADIUS is another protocol that can be used for device administration with AAA.
|
||||
|
||||
A TACACS server must be available on the network for devices to send AAA requests to for validation. This lab leverages an open source `tac_plus` server as a lightweight service that can be easily installed on an Ubuntu host within the topology. For more information on `tac_plus` see the documentation for [`tac_plus`](https://manpages.ubuntu.com/manpages/trusty/man8/tac_plus.8.html) and [`tac_plus.conf`](https://manpages.ubuntu.com/manpages/trusty/man5/tac_plus.conf.5.html). The starting config for `aaa-server` installs `tac_plus` and deploys a basic TACACS configuration to support IOS and NX-OS hosts connecting for user authentication, role based authorization (administrator and operator), and accounting. The configuration file `tac_plus.conf` is located at `/etc/tacacs/tac_plus.conf`. You can modify this configuraiton file and restart `tac_plus` (`sudo systemctl restart tac_plus`) as part of your own learning.
|
||||
|
||||
> Command authorization is not part of this lab guide, and the `tac_plus` server is ***NOT*** configured for command authorization as part of the initial configuration. Though you can update the `tac_plus.conf` file and experiment with command authorization on your own.
|
||||
|
||||
## Starting Configuration
|
||||
|
||||
`rtr1` has the following configuration applied as startup configuration to enable inbound SSH from `desktop` that is locally authenticated.
|
||||
|
||||
```
|
||||
ip domain name lab.intra
|
||||
crypto key generate rsa general-keys modulus 2048
|
||||
!
|
||||
aaa new-model
|
||||
!
|
||||
username cisco priv 15 secret cisco
|
||||
```
|
||||
|
||||
|
||||
## Ensuring the serial / console leverages local authentication
|
||||
To provide safety and fallback access to devices, we will force the console line to only use local admin accounts.
|
||||
|
||||
```
|
||||
aaa authentication login CONSOLE local
|
||||
aaa authorization console
|
||||
aaa authorization exec CONSOLE local
|
||||
!
|
||||
line con 0
|
||||
login authentication CONSOLE
|
||||
authorization exec CONSOLE
|
||||
!
|
||||
```
|
||||
|
||||
## Configuring TACACS server as default AAA
|
||||
|
||||
Start by identitying the interface that TACACS packets should be sourced from. This is often important because TACACS servers typically only respond to known hosts/addresses.
|
||||
|
||||
```
|
||||
ip tacacs source-interface Ethernet0/0
|
||||
```
|
||||
|
||||
Now create the TACACS server entry for the server. Be sure to double check the "key" (secret) used for communications.
|
||||
|
||||
> Note: Be careful to NOT add an extra "space" after the key. This can cause problems on some platforms.
|
||||
|
||||
```
|
||||
tacacs server aaa-server
|
||||
address ipv4 192.168.0.10
|
||||
key tacacs123
|
||||
!
|
||||
```
|
||||
|
||||
Create a `aaa group` that includes the TACACS server. In a production environment, you would typically have at least 2 TACASC servers configured for fallback.
|
||||
|
||||
```
|
||||
aaa group server tacacs+ AAA-TACACS
|
||||
server name aaa-server
|
||||
!
|
||||
```
|
||||
|
||||
Test that the TACACS server is responding successfully.
|
||||
|
||||
```
|
||||
test aaa group tacacs+ tacadmin admin123 legacy
|
||||
```
|
||||
|
||||
Configure the authentication, authorization, and accounting policies.
|
||||
|
||||
```
|
||||
aaa authentication login default group AAA-TACACS local
|
||||
aaa authorization exec default group AAA-TACACS local
|
||||
!
|
||||
aaa accounting exec default start-stop group AAA-TACACS
|
||||
aaa accounting commands 1 default start-stop group AAA-TACACS
|
||||
aaa accounting commands 15 default start-stop group AAA-TACACS
|
||||
!
|
||||
```
|
||||
|
||||
## Testing the configuration
|
||||
|
||||
Open the console for the `tacacs-server` and monitor the service "journal"
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
```
|
||||
|
||||
Open the console for the `desktop` and attempt to connect to `rtr1` with SSH as the `tacadmin` user.
|
||||
|
||||
```
|
||||
ssh tacadmin@192.168.0.1
|
||||
```
|
||||
|
||||
After you log in, run a command to verify access.
|
||||
|
||||
```
|
||||
show ip interface brief
|
||||
```
|
||||
|
||||
Check the output on the `tacacs-server`. You should see messages for both the `authentication` and `authorization`
|
||||
|
||||
```
|
||||
# Examples
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5704]: login query for 'tacadmin' port tty2 from 192.168.0.1 accepted
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: connect from 192.168.0.1 [192.168.0.1]
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: Start authorization request
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: do_author: user='tacadmin'
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: user 'tacadmin' found
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: exec authorization request for tacadmin
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: exec is explicitly permitted by line 4
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:service=shell (passed thru)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:cmd* (passed thru)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: added 1 args
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[0] = service=shell input copy discarded
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[1] = cmd* input copy discarded
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[2] = priv-lvl=15 compacted to out_args[0]
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: 1 output args
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: authorization query for 'tacadmin' tty2 from 192.168.0.1 accepted
|
||||
```
|
||||
|
||||
Stop the journalctl monitor (`Cntrl-c`), and open the accounting log.
|
||||
|
||||
```
|
||||
tail -f /var/log/tac_plus.acct
|
||||
```
|
||||
|
||||
> Note: If the command fails and the file isn't found, return to the SSH session to the router and run a couple commands. The file isn't created until an accounting message is sent to the server.
|
||||
|
||||
Run some more commands on `rtr1`. Try some that are `priv 15` as well as `priv 1`
|
||||
|
||||
```
|
||||
! Priv 1
|
||||
show ip route
|
||||
! Priv 15
|
||||
write mem
|
||||
```
|
||||
|
||||
Verify the accounting logs were received.
|
||||
|
||||
Logout from the router, and log in as `tacoper`. Verify through the same logs that the user is given the correct access.
|
||||
|
||||
## Other useful commands
|
||||
|
||||
### Debugs on the router
|
||||
|
||||
```
|
||||
debug aaa authentication
|
||||
debug aaa authorization
|
||||
debug aaa accounting
|
||||
|
||||
debug tacacs authentication
|
||||
debug tacacs authorization
|
||||
debug tacacs accounting
|
||||
```
|
||||
|
||||
### Show commands on router
|
||||
|
||||
```
|
||||
show tacacs
|
||||
show aaa sessions
|
||||
```
|
||||
|
||||
### Test AAA
|
||||
|
||||
```
|
||||
test aaa group tacacs+ tacadmin admin123 legacy
|
||||
```
|
||||
|
||||
### tacacs-server logs
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
tail -f /var/log/tac_plus.acct
|
||||
tail -f /var/log/tac_plus.log
|
||||
```
|
||||
|
||||
### tac_plus server maintenance
|
||||
|
||||
```
|
||||
systemctl status tac_plus
|
||||
sudo systemctl stop tac_plus
|
||||
sudo systemctl start tac_plus
|
||||
```
|
@@ -0,0 +1,673 @@
|
||||
annotations:
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 192.168.0.10
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -565.0
|
||||
y1: -74.0
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 192.168.0.11
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -325.0
|
||||
y1: -73.0
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 192.168.0.1
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -446.3066108896985
|
||||
y1: 47.653305444849266
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 8
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -559.75
|
||||
y1: -55.5
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 8
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -318.75
|
||||
y1: -53.5
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
TACACS Accounts
|
||||
tacadmin / admin123 (priv 15)
|
||||
tacoper / oper123 (priv 1)
|
||||
|
||||
TACACS Secret
|
||||
tacacs123
|
||||
|
||||
TACACS Log Files
|
||||
journalctl -fu tac_plus
|
||||
tail -f /var/log/tac_plus.acct
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -960.4378534132434
|
||||
y1: -244.7193548844158
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 8
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -443.7290720829766
|
||||
y1: 67.39536041488296
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#0C0C0C'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: Exploring AAA / TACACS Configuration for IOS
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 13
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -962.0997946295324
|
||||
y1: -292.6838112360871
|
||||
z_index: 3
|
||||
nodes:
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: internet
|
||||
node_definition: external_connector
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -640
|
||||
y: -240
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: null
|
||||
label: internet-sw
|
||||
node_definition: unmanaged_switch
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -640
|
||||
y: -120
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i1
|
||||
label: port1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i2
|
||||
label: port2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i3
|
||||
label: port3
|
||||
slot: 3
|
||||
type: physical
|
||||
- id: i4
|
||||
label: port4
|
||||
slot: 4
|
||||
type: physical
|
||||
- id: i5
|
||||
label: port5
|
||||
slot: 5
|
||||
type: physical
|
||||
- id: i6
|
||||
label: port6
|
||||
slot: 6
|
||||
type: physical
|
||||
- id: i7
|
||||
label: port7
|
||||
slot: 7
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: user-data
|
||||
content: |-
|
||||
#cloud-config
|
||||
hostname: tacacs-server
|
||||
manage_etc_hosts: True
|
||||
system_info:
|
||||
default_user:
|
||||
name: cisco
|
||||
password: cisco
|
||||
chpasswd: { expire: False }
|
||||
ssh_pwauth: True
|
||||
ssh_authorized_keys:
|
||||
- your-ssh-pubkey-line-goes-here
|
||||
|
||||
# Install requirements for tac_plus
|
||||
package_update: true
|
||||
packages:
|
||||
- wget
|
||||
- make
|
||||
- gcc
|
||||
- flex
|
||||
- bison
|
||||
- libwrap0-dev
|
||||
|
||||
write_files:
|
||||
# Create the tac_plus configuration file
|
||||
- path: /etc/tacacs/tac_plus.conf
|
||||
content: |
|
||||
key = tacacs123
|
||||
group = netadmin {
|
||||
default service = permit
|
||||
service = exec {
|
||||
priv-lvl = 15
|
||||
}
|
||||
}
|
||||
group = netoper {
|
||||
default service = permit
|
||||
service = exec {
|
||||
priv-lvl = 1
|
||||
}
|
||||
}
|
||||
user = tacadmin {
|
||||
login = cleartext admin123
|
||||
member = netadmin
|
||||
}
|
||||
user = tacoper {
|
||||
login = cleartext oper123
|
||||
member = netoper
|
||||
}
|
||||
# Create a systemd service to manage tac_plus
|
||||
- path: /etc/systemd/system/tac_plus.service
|
||||
content: |
|
||||
[Unit]
|
||||
Description=tac_plus Service
|
||||
After=network.target
|
||||
[Service]
|
||||
Type=simple
|
||||
ExecStart=/tacacs/sbin/tac_plus -G -C /etc/tacacs/tac_plus.conf -d 8 -d 16 -l /var/log/tac_plus.log
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
runcmd:
|
||||
# Download tac_plus source code and un-tar it
|
||||
- wget https://shrubbery.net/pub/tac_plus/tacacs-F4.0.4.28.tar.gz -O /opt/tacacs-F4.0.4.28.tar.gz
|
||||
- cd /opt && tar -xzf tacacs-F4.0.4.28.tar.gz
|
||||
# Compile and install tac_plus
|
||||
- cd /opt/tacacs-F4.0.4.28 && ./configure --prefix=/tacacs && make && make install
|
||||
# Enable and start the systemd service
|
||||
- systemctl enable tac_plus
|
||||
- systemctl start tac_plus
|
||||
# Configure "inside" network adapter
|
||||
# Note: ens2 is connected to internet through NAT ext-con and
|
||||
# required to download the software
|
||||
- ip address add 192.168.0.10/24 dev ens3
|
||||
- ip link set up dev ens3
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: ubuntu-22-04-20240126
|
||||
label: tacacs-server
|
||||
node_definition: ubuntu
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -520
|
||||
y: -120
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: ens2
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i1
|
||||
label: ens3
|
||||
slot: 1
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: lab-sw
|
||||
node_definition: unmanaged_switch
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -400
|
||||
y: -120
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i1
|
||||
label: port1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i2
|
||||
label: port2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i3
|
||||
label: port3
|
||||
slot: 3
|
||||
type: physical
|
||||
- id: i4
|
||||
label: port4
|
||||
slot: 4
|
||||
type: physical
|
||||
- id: i5
|
||||
label: port5
|
||||
slot: 5
|
||||
type: physical
|
||||
- id: i6
|
||||
label: port6
|
||||
slot: 6
|
||||
type: physical
|
||||
- id: i7
|
||||
label: port7
|
||||
slot: 7
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname rtr1
|
||||
!
|
||||
! In order to avoid entering a configuration dialog
|
||||
! on boot, please ensure that all ethernet interfaces
|
||||
! have some ip configuration present here such as the
|
||||
! example below:
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
no ip domain lookup
|
||||
ip domain name lab.intra
|
||||
crypto key generate rsa general-keys modulus 2048
|
||||
!
|
||||
aaa new-model
|
||||
!
|
||||
username cisco priv 15 secret cisco
|
||||
!
|
||||
interface Eth0/0
|
||||
no shutdown
|
||||
ip address 192.168.0.1 255.255.255.0
|
||||
exit
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: rtr1
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -400
|
||||
y: 0
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname desktop
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
# Network Settings
|
||||
ip address add 192.168.0.11/24 dev eth0
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n5
|
||||
image_definition: null
|
||||
label: desktop
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -280
|
||||
y: -120
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i1
|
||||
label: eth1
|
||||
slot: 1
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n1
|
||||
n2: n0
|
||||
i1: i0
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: ext-sw-port0<->ext-conn-0-port
|
||||
- id: l1
|
||||
n1: n2
|
||||
n2: n1
|
||||
i1: i0
|
||||
i2: i3
|
||||
conditioning: {}
|
||||
label: aaa-server_0-ens2<->ext-sw-port3
|
||||
- id: l2
|
||||
n1: n2
|
||||
n2: n3
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: aaa-server_0-ens3<->ext-sw_0-port0
|
||||
- id: l3
|
||||
n1: n4
|
||||
n2: n3
|
||||
i1: i1
|
||||
i2: i1
|
||||
conditioning: {}
|
||||
label: router1_0-Ethernet0/0<->ext-sw_0-port1
|
||||
- id: l4
|
||||
n1: n5
|
||||
n2: n3
|
||||
i1: i0
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: desktop-0-eth0<->ext-sw_0-port2
|
||||
lab:
|
||||
description: Simple topology for practicing AAA TACACS configuration in IOS.
|
||||
notes: |-
|
||||
# Exploring AAA / TACACS Configuration for IOS
|
||||
|
||||
Verifying the identity of the people who log into network, what each person is allowed to do on a network device, and tracking what was done is a critical part of network operations. Collectively these are known as "Triple A Services", or Authentication, Authorization, and Accounting. Another name used is "Role Based Access Control", or RBAC.
|
||||
|
||||
TACACS+ is a common protocol used for RBAC / AAA on network devices, and this lab explores how to configure AAA on both IOS and NX-OS devices.
|
||||
|
||||
> RADIUS is another protocol that can be used for device administration with AAA.
|
||||
|
||||
A TACACS server must be available on the network for devices to send AAA requests to for validation. This lab leverages an open source `tac_plus` server as a lightweight service that can be easily installed on an Ubuntu host within the topology. For more information on `tac_plus` see the documentation for [`tac_plus`](https://manpages.ubuntu.com/manpages/trusty/man8/tac_plus.8.html) and [`tac_plus.conf`](https://manpages.ubuntu.com/manpages/trusty/man5/tac_plus.conf.5.html). The starting config for `aaa-server` installs `tac_plus` and deploys a basic TACACS configuration to support IOS and NX-OS hosts connecting for user authentication, role based authorization (administrator and operator), and accounting. The configuration file `tac_plus.conf` is located at `/etc/tacacs/tac_plus.conf`. You can modify this configuraiton file and restart `tac_plus` (`sudo systemctl restart tac_plus`) as part of your own learning.
|
||||
|
||||
> Command authorization is not part of this lab guide, and the `tac_plus` server is ***NOT*** configured for command authorization as part of the initial configuration. Though you can update the `tac_plus.conf` file and experiment with command authorization on your own.
|
||||
|
||||
## Starting Configuration
|
||||
|
||||
`rtr1` has the following configuration applied as startup configuration to enable inbound SSH from `desktop` that is locally authenticated.
|
||||
|
||||
```
|
||||
ip domain name lab.intra
|
||||
crypto key generate rsa general-keys modulus 2048
|
||||
!
|
||||
aaa new-model
|
||||
!
|
||||
username cisco priv 15 secret cisco
|
||||
```
|
||||
|
||||
|
||||
## Ensuring the serial / console leverages local authentication
|
||||
To provide safety and fallback access to devices, we will force the console line to only use local admin accounts.
|
||||
|
||||
```
|
||||
aaa authentication login CONSOLE local
|
||||
aaa authorization console
|
||||
aaa authorization exec CONSOLE local
|
||||
!
|
||||
line con 0
|
||||
login authentication CONSOLE
|
||||
authorization exec CONSOLE
|
||||
!
|
||||
```
|
||||
|
||||
## Configuring TACACS server as default AAA
|
||||
|
||||
Start by identitying the interface that TACACS packets should be sourced from. This is often important because TACACS servers typically only respond to known hosts/addresses.
|
||||
|
||||
```
|
||||
ip tacacs source-interface Ethernet0/0
|
||||
```
|
||||
|
||||
Now create the TACACS server entry for the server. Be sure to double check the "key" (secret) used for communications.
|
||||
|
||||
> Note: Be careful to NOT add an extra "space" after the key. This can cause problems on some platforms.
|
||||
|
||||
```
|
||||
tacacs server aaa-server
|
||||
address ipv4 192.168.0.10
|
||||
key tacacs123
|
||||
!
|
||||
```
|
||||
|
||||
Create a `aaa group` that includes the TACACS server. In a production environment, you would typically have at least 2 TACASC servers configured for fallback.
|
||||
|
||||
```
|
||||
aaa group server tacacs+ AAA-TACACS
|
||||
server name aaa-server
|
||||
!
|
||||
```
|
||||
|
||||
Test that the TACACS server is responding successfully.
|
||||
|
||||
```
|
||||
test aaa group tacacs+ tacadmin admin123 legacy
|
||||
```
|
||||
|
||||
Configure the authentication, authorization, and accounting policies.
|
||||
|
||||
```
|
||||
aaa authentication login default group AAA-TACACS local
|
||||
aaa authorization exec default group AAA-TACACS local
|
||||
!
|
||||
aaa accounting exec default start-stop group AAA-TACACS
|
||||
aaa accounting commands 1 default start-stop group AAA-TACACS
|
||||
aaa accounting commands 15 default start-stop group AAA-TACACS
|
||||
!
|
||||
```
|
||||
|
||||
## Testing the configuration
|
||||
|
||||
Open the console for the `tacacs-server` and monitor the service "journal"
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
```
|
||||
|
||||
Open the console for the `desktop` and attempt to connect to `rtr1` with SSH as the `tacadmin` user.
|
||||
|
||||
```
|
||||
ssh tacadmin@192.168.0.1
|
||||
```
|
||||
|
||||
After you log in, run a command to verify access.
|
||||
|
||||
```
|
||||
show ip interface brief
|
||||
```
|
||||
|
||||
Check the output on the `tacacs-server`. You should see messages for both the `authentication` and `authorization`
|
||||
|
||||
```
|
||||
# Examples
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5704]: login query for 'tacadmin' port tty2 from 192.168.0.1 accepted
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: connect from 192.168.0.1 [192.168.0.1]
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: Start authorization request
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: do_author: user='tacadmin'
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: user 'tacadmin' found
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: exec authorization request for tacadmin
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: exec is explicitly permitted by line 4
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:service=shell (passed thru)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:cmd* (passed thru)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: nas:absent, server:priv-lvl=15 -> add priv-lvl=15 (k)
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: added 1 args
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[0] = service=shell input copy discarded
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[1] = cmd* input copy discarded
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: out_args[2] = priv-lvl=15 compacted to out_args[0]
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: 1 output args
|
||||
Oct 07 21:30:36 tacacs-server tac_plus[5705]: authorization query for 'tacadmin' tty2 from 192.168.0.1 accepted
|
||||
```
|
||||
|
||||
Stop the journalctl monitor (`Cntrl-c`), and open the accounting log.
|
||||
|
||||
```
|
||||
tail -f /var/log/tac_plus.acct
|
||||
```
|
||||
|
||||
> Note: If the command fails and the file isn't found, return to the SSH session to the router and run a couple commands. The file isn't created until an accounting message is sent to the server.
|
||||
|
||||
Run some more commands on `rtr1`. Try some that are `priv 15` as well as `priv 1`
|
||||
|
||||
```
|
||||
! Priv 1
|
||||
show ip route
|
||||
! Priv 15
|
||||
write mem
|
||||
```
|
||||
|
||||
Verify the accounting logs were received.
|
||||
|
||||
Logout from the router, and log in as `tacoper`. Verify through the same logs that the user is given the correct access.
|
||||
|
||||
## Other useful commands
|
||||
|
||||
### Debugs on the router
|
||||
|
||||
```
|
||||
debug aaa authentication
|
||||
debug aaa authorization
|
||||
debug aaa accounting
|
||||
|
||||
debug tacacs authentication
|
||||
debug tacacs authorization
|
||||
debug tacacs accounting
|
||||
```
|
||||
|
||||
### Show commands on router
|
||||
|
||||
```
|
||||
show tacacs
|
||||
show aaa sessions
|
||||
```
|
||||
|
||||
### Test AAA
|
||||
|
||||
```
|
||||
test aaa group tacacs+ tacadmin admin123 legacy
|
||||
```
|
||||
|
||||
### tacacs-server logs
|
||||
|
||||
```
|
||||
journalctl -fu tac_plus
|
||||
tail -f /var/log/tac_plus.acct
|
||||
tail -f /var/log/tac_plus.log
|
||||
```
|
||||
|
||||
### tac_plus server maintenance
|
||||
|
||||
```
|
||||
systemctl status tac_plus
|
||||
sudo systemctl stop tac_plus
|
||||
sudo systemctl start tac_plus
|
||||
```
|
||||
title: Snack Minute AAA TACACS Exploration
|
||||
version: 0.2.2
|
1007
lab-topologies/aaa-tacacs-exploration/aaa-exploration-ios-nxos.yaml
Normal file
BIN
lab-topologies/aaa-tacacs-exploration/topology-ios-nxos.jpg
Normal file
After Width: | Height: | Size: 78 KiB |
BIN
lab-topologies/aaa-tacacs-exploration/topology.jpg
Normal file
After Width: | Height: | Size: 76 KiB |
33
lab-topologies/ccna-prep/README.md
Normal file
@@ -0,0 +1,33 @@
|
||||
# CCNA Prep CML Resources
|
||||
The CCNA Prep Program is a study resource put together by the Learning and Certifications team within Cisco to help engineers working towards earning their CCNA certification. Each session dives into a topic from the CCNA blueprint, exploring it through a hands on/labs driven approach. These hands on labs are run on Cisco Modeling Labs and include full lab guides that can be used after the session for anyone to practice and hone their skills as they prepare for their CCNA Exam. We are sharing the CML topology files with the CML Community for fun, learning and inspiration.
|
||||
|
||||

|
||||
|
||||
> Sign up for CCNA Prep and access recordings from sessions at: [CCNA Prep Program](https://learningnetwork.cisco.com/s/ccna-live-stream)
|
||||
|
||||
## CCNA Prep Hosts
|
||||
The current hosts of the CCNA Prep Program are:
|
||||
|
||||
**Hank Preston:** I'm a Principal Engineer at Cisco Systems, and my journey in network engineering began with the CCNA. Over the years, I've earned multiple certifications, including CCNP, CCIE, and DevNet Expert. My passion for networking and teaching has led me to help engineers worldwide through Cisco's learning and certification programs.
|
||||
|
||||
**Patrick Gargano:** As a Lead Content Advocate and Instructor at Cisco Learning & Certifications, I am responsible for developing and delivering official Cisco course content. I started my CCNA journey in 2000 when I became a Cisco Networking Academy instructor. Since then, I've authored Cisco Press books and achieved multiple Cisco certifications. The CCNA was a pivotal point in my career, and I'm excited to share my experiences and insights with you.
|
||||
|
||||
## Season 1 (Fall 2024) - Back to Basics
|
||||
|
||||
1. [Mastering VLAN Configuration: Unlock the power of VLANs](s1e1/README.md)
|
||||
1. [Spanning Tree Protocol (STP) Unleashed: Navigate network efficiency](s1e2/README.md)
|
||||
1. [Building Resilient Links with EtherChannel: Gain EtherChannel excellence](s1e3/README.md)
|
||||
1. [Routing Fundamentals & Static Routes: Master concepts and static routes](s1e4/README.md)
|
||||
1. [Conquering OSPF: Optimize your network with OSPF](s1e5/README.md)
|
||||
1. [The Router's Guild: Adventures in AD, Metrics, and Prefix Lengths](s1e4/README.md)
|
||||
1. [GET a Head(er) of REST APIs for the CCNA Certification](s1e7/README.md)
|
||||
|
||||
## Season 2 (Spring 2025) - IP Services
|
||||
|
||||
1. [DHCP in Action: Streamlining Network Client Address Management](s2e1/README.md)
|
||||
1. [DNS Deepdive: Exploring a Backbone of Network Communication”](s2e2/README.md)
|
||||
1. [Navigating NAT: Bridging Private Networks to the Internet](s2e3/README.md)
|
||||
1. [Securing Network Access: From Telnet to SSH](s2e4/README.md)
|
||||
1. [Syncing Success: The Role of NTP in Network Operations](s2e5/README.md)
|
||||
1. [The Syslog Detective: Unraveling Network Mysteries](s2e6/README.md)
|
||||
1. [Simplifying SNMP: Delivery Data for Network Operation Dashboards](s2e7/README.md)
|
BIN
lab-topologies/ccna-prep/ccnaprep-01.jpg
Normal file
After Width: | Height: | Size: 179 KiB |
BIN
lab-topologies/ccna-prep/s1e1/CCNA Prep S01 E01 Lab Guide.pdf
Normal file
5
lab-topologies/ccna-prep/s1e1/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Mastering VLAN Configuration: Unlock the Power of VLANs
|
||||
|
||||
*Abstract*: Join our exciting live stream to master VLAN configuration and discover the complete capabilities of VLANs in your network. Whether you're just starting out or seeking to enhance your existing skills, this session will offer valuable insights and practical techniques to improve your network management. Don't miss this chance to elevate your networking expertise to new heights!
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e1/s1e1-vlan.jpeg
Normal file
After Width: | Height: | Size: 162 KiB |
BIN
lab-topologies/ccna-prep/s1e2/CCNA Prep S01 E02 Lab Guide.pdf
Normal file
1833
lab-topologies/ccna-prep/s1e2/CCNA_Prep_2024_S1E2_STP.yaml
Normal file
5
lab-topologies/ccna-prep/s1e2/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Spanning Tree Protocol (STP) Unleashed: Navigate Network Efficiency
|
||||
|
||||
*Abstract:* Navigate the landscape of network optimization with this live stream event dedicated to the Spanning Tree Protocol (STP). Our subject matter experts will guide through the essentials of STP configuration and management, ensuring you can navigate network efficiency with confidence. In addition, you'll be equipped with the necessary tools and knowledge to optimize your network. Get ready to master the Spanning Tree Protocol and see its full capabilities in action.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e2/s1e2-stp.jpeg
Normal file
After Width: | Height: | Size: 134 KiB |
BIN
lab-topologies/ccna-prep/s1e3/CCNA Prep S01 E03 Lab Guide.pdf
Normal file
1753
lab-topologies/ccna-prep/s1e3/CCNA_Prep_2024_S1E3_EtherChannel.yaml
Normal file
5
lab-topologies/ccna-prep/s1e3/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Building Resilient Links with EtherChannel: Gain EtherChannel Excellence
|
||||
*Abstract:* Learn the secrets to establishing robust and efficient network links in our comprehensive live stream event on EtherChannel. This session is crafted to provide a thorough understanding of EtherChannel concepts and configurations, helping you achieve excellence in network resilience and performance. Enhance your network management skills and master the art of building resilient links with EtherChannel.
|
||||
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e3/s1e3-etherchannel.jpeg
Normal file
After Width: | Height: | Size: 210 KiB |
BIN
lab-topologies/ccna-prep/s1e4/CCNA Prep S01 E04 Guide.pdf
Normal file
10
lab-topologies/ccna-prep/s1e4/README.md
Normal file
@@ -0,0 +1,10 @@
|
||||
# Routing Fundamentals & Static Routes: Master Concepts and Static Routes
|
||||
*Abstract:* Ready to advance your networking skills? Dive into our specialized live stream on Routing Fundamentals and Static Routes. Designed to lay a strong foundation in routing principles, this session provides the practical knowledge required to effectively configure static routes. Gain critical insights and hands-on tools to master routing concepts and ensure your network operates smoothly and efficiently. By the end of this session, you will have enhanced your network management capabilities.
|
||||
|
||||
> CCNA Prep returned to this topology for a second session:
|
||||
> **The Router's Guild: Adventures in AD, Metrics, and Prefix Lengths**
|
||||
>
|
||||
> Starting where Episode 4 left off, this session will revisit the concepts of administrative distance, metric, and prefix length, and how they are used to build the routing table and make packet forwarding decisions.
|
||||
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e4/s1e4-staticroute.jpeg
Normal file
After Width: | Height: | Size: 154 KiB |
BIN
lab-topologies/ccna-prep/s1e5/CCNA Prep S01 EP05 Lab Guide.pdf
Normal file
4
lab-topologies/ccna-prep/s1e5/README.md
Normal file
@@ -0,0 +1,4 @@
|
||||
# Conquering OSPF: Optimize Your Network with OSPF
|
||||
*Abstract:* Maximize your network's potential with our in-depth focus on OSPF. This live stream event is tailored to help you master OSPF and optimize your network through dynamic routing and effective path selection. Perfect for networking professionals aiming to deepen their expertise, you'll be provided with the skills needed to ensure your network runs at peak performance. Join us to conquer OSPF and elevate your network optimization skills.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e5/s1e5-ospf.jpeg
Normal file
After Width: | Height: | Size: 180 KiB |
BIN
lab-topologies/ccna-prep/s1e7/CCNA Prep S01 E07 Lab Guide.pdf
Normal file
1178
lab-topologies/ccna-prep/s1e7/CCNA_Prep_2024_S1E7_REST_APIs.yaml
Normal file
5
lab-topologies/ccna-prep/s1e7/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# GET a Head(er) of REST APIs for the CCNA Certification
|
||||
|
||||
*Abstract:* It is time to dive into network automation skills needed to succeed in the journey towards your CCNA certification. Learn everything you need to describe authentication, decode any possible CRUD operation, and handle JSON and XML results when working with REST APIs in this bonus CCNA Prep webinar.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s1e7/s1e7-rest.jpeg
Normal file
After Width: | Height: | Size: 222 KiB |
922
lab-topologies/ccna-prep/s2e1/CCNA_Prep_2025_-_S2E1_-_DHCP.yaml
Normal file
@@ -0,0 +1,922 @@
|
||||
annotations:
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 192.168.1.0/24
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -440.0
|
||||
y1: -120.0
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 192.168.2.0/24
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 40.0
|
||||
y1: -120.0
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#1820C8'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: DHCP Client
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 4.334521504159601
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#1820C8'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: DHCP Client
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 120.0
|
||||
y1: 4.334521504159601
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#1820C8'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: DHCP Server
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -331.9199341364389
|
||||
y1: -240.0
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: ''
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 160.0
|
||||
y1: -200.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: OSPF AREA 0
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 16
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -200.0
|
||||
y1: 40.0
|
||||
z_index: 4
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 10.1.1.0/30
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -193.49821774376065
|
||||
y1: -191.33095699168084
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: DNS Server 8.8.8.8
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 95.2436807701726
|
||||
y1: -348.7528058356377
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#1820C8'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: DHCP Client
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 37.8327392479203
|
||||
y1: -226.9964354875213
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 'CCNA Exam Prep: Back to Networking Basics with Hank Preston and
|
||||
Patrick Gargano (Season 2)'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -1125.258776447585
|
||||
y1: -407.1581438914021
|
||||
z_index: 6
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: 'DHCP in Action: Streamlining Network Client Address Management'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 18
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -1127.7286604756591
|
||||
y1: -380.50714500921066
|
||||
z_index: 7
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#4557D2'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
In this lab, we will explore how to:
|
||||
* Configure a router as an IPv4 DHCP Client
|
||||
* Configure a Router as an IPv4 DHCP Server
|
||||
* Configure an IPv4 DHCP Relay
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -1140.7773154740125
|
||||
y1: 22.337510119328677
|
||||
z_index: 8
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#2A3FCC'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
Dynamic Host Configuration Protocol (DHCP) is a network protocol
|
||||
that lets network administrators manage and automate the assignment
|
||||
of IP addresses.
|
||||
Without DHCP for IPv4, the administrator must manually assign
|
||||
and configure IP addresses, preferred DNS servers, and default
|
||||
gateways.
|
||||
As the network grows in size, this becomes an administrative
|
||||
problem when devices are moved from one internal network to another.
|
||||
|
||||
Related CCNA v1.1 exam topic:
|
||||
4.3 Explain the role of DHCP and DNS within the network
|
||||
4.6 Configure and verify DHCP client and relay
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -1132.1896418060846
|
||||
y1: -324.20038804830887
|
||||
z_index: 9
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 0
|
||||
border_style: ''
|
||||
color: '#70BE58'
|
||||
thickness: 1
|
||||
type: rectangle
|
||||
x1: -513.2157309182571
|
||||
y1: -270.3112384285854
|
||||
x2: 765.0004137890356
|
||||
y2: 338.9822192837643
|
||||
z_index: -3
|
||||
nodes:
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname RTR1
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
int e0/0
|
||||
ip address 10.1.1.1 255.255.255.252
|
||||
no shut
|
||||
!
|
||||
int e0/1
|
||||
ip address 192.168.1.1 255.255.255.0
|
||||
no shut
|
||||
!
|
||||
router ospf 1
|
||||
network 10.1.1.0 0.0.0.3 area 0
|
||||
network 192.168.1.0 0.0.0.255 area 0
|
||||
router-id 0.0.0.1
|
||||
!
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: RTR1
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -280
|
||||
y: -201
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname RTR2
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
int e0/0
|
||||
ip address 10.1.1.2 255.255.255.252
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
int e0/1
|
||||
ip address 192.168.2.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
int e0/3
|
||||
ip nat outside
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
router ospf 1
|
||||
network 10.1.1.0 0.0.0.3 area 0
|
||||
network 192.168.2.0 0.0.0.255 area 0
|
||||
router-id 0.0.0.2
|
||||
default-information originate
|
||||
!
|
||||
access-list 1 permit any
|
||||
!
|
||||
ip nat inside source list 1 interface e0/3 overload
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: null
|
||||
label: RTR2
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -1
|
||||
y: -199
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname PC2
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
iface eth0 inet dhcp
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: PC2
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 160
|
||||
y: -40
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname PC1
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
iface eth0 inet dhcp
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: PC1
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -440
|
||||
y: -40
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: hostname ASW1
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: ASW1
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -280
|
||||
y: -40
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: 'hostname ASW2
|
||||
|
||||
'
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n5
|
||||
image_definition: null
|
||||
label: ASW2
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 0
|
||||
y: -40
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n6
|
||||
image_definition: null
|
||||
label: Internet
|
||||
node_definition: external_connector
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 120
|
||||
y: -320
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port
|
||||
slot: 0
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n0
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i1
|
||||
conditioning: {}
|
||||
label: RTR1-Ethernet0/0<->RTR2-Ethernet0/0
|
||||
- id: l1
|
||||
n1: n0
|
||||
n2: n4
|
||||
i1: i2
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: RTR1-Ethernet0/1<->ASW1-Ethernet0/1
|
||||
- id: l2
|
||||
n1: n1
|
||||
n2: n5
|
||||
i1: i2
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: RTR2-Ethernet0/1<->ASW2-Ethernet0/1
|
||||
- id: l3
|
||||
n1: n4
|
||||
n2: n3
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: ASW1-Ethernet0/0<->PC1-eth0
|
||||
- id: l4
|
||||
n1: n5
|
||||
n2: n2
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: ASW2-Ethernet0/0<->PC2-eth0
|
||||
- id: l5
|
||||
n1: n1
|
||||
n2: n6
|
||||
i1: i4
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: RTR2-Ethernet0/3<->Internet-port
|
||||
lab:
|
||||
description: ''
|
||||
notes: |-
|
||||
<html><head><style>body {
|
||||
color: black;
|
||||
}
|
||||
</style></head><body><p><strong>CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano -- Season 2</strong></p>
|
||||
<h1 id="dhcp-in-action-streamlining-network-client-address-management">DHCP in Action: Streamlining Network Client Address Management</h1>
|
||||
<p>Dynamic Host Configuration Protocol (DHCP) is a network protocol that lets network administrators manage and automate the assignment of IP addresses.
|
||||
Without DHCP for IPv4, the administrator must manually assign and configure IP addresses, preferred DNS servers, and default gateways. As the network grows in size, this becomes an administrative problem when devices are added or moved from one internal network to another.</p>
|
||||
<p>Related CCNA v1.1 exam topic:</p>
|
||||
<ul>
|
||||
<li>4.3 Explain the role of DHCP and DNS within the network</li>
|
||||
<li>4.6 Configure and verify DHCP client and relay</li>
|
||||
</ul>
|
||||
<p>In this lab, we will explore how to:</p>
|
||||
<ul>
|
||||
<li>Configure a router as an IPv4 DHCP Client</li>
|
||||
<li>Configure a Router as an IPv4 DHCP Server </li>
|
||||
<li>Configure an IPv4 DHCP Relay </li>
|
||||
</ul>
|
||||
<h2 id="setup-and-scenario">Setup and Scenario</h2>
|
||||
<p>In this set of lab-based demonstrations, you are the network engineer for a growing organization tasked with updating the network to support new network needs. The network was originally deployed using static IPv4 addresses on all hosts and servers since the network was small, but now the network has grown and requires that IPv4 address assignment be automated and centralized on a DHCP server. </p>
|
||||
<p>You've been asked to: </p>
|
||||
<ul>
|
||||
<li>Configure RTR2 E0/3 to request and receive a dynamic IPv4 address from the ISP.</li>
|
||||
<li>Configure RTR1 as an IPv4 DHCP server for the RTR1 LAN and RTR2 LAN.</li>
|
||||
<li>Configure RTR2 as an IPv4 DHCP Relay Agent for the RTR2 LAN.</li>
|
||||
</ul>
|
||||
<p><em>Be sure to <strong>START</strong> the lab before continuing to the demo labs but do not power on PC1 or PC2 for now.</em></p>
|
||||
<h2 id="part-1-reviewing-the-current-state-of-the-network">Part 1: Reviewing the Current State of the Network</h2>
|
||||
<p>Before we jump into configuring DHCP across the network, let's check the current status of the network and how it is operating. </p>
|
||||
<h3 id="step-1">Step 1</h3>
|
||||
<p>Open a console connection to RTR1 and RTR2 and verify the OSPF configuration.</p>
|
||||
<pre>
|
||||
RTR1# <b>show run | section ospf</b>
|
||||
router ospf 1
|
||||
router-id 0.0.0.1
|
||||
network 10.1.1.0 0.0.0.3 area 0
|
||||
network 192.168.1.0 0.0.0.255 area 0
|
||||
|
||||
RTR2# <b>show run | section ospf</b>
|
||||
router ospf 1
|
||||
router-id 0.0.0.2
|
||||
network 10.1.1.0 0.0.0.3 area 0
|
||||
network 192.168.2.0 0.0.0.255 area 0
|
||||
default-information originate
|
||||
</pre>
|
||||
Notice that both RTR1 and RTR2 are configured with OSPF process ID 1 and that all network statements are assigned to area 0. RTR2 is also configured with the `default-information originate` command that allows RTR2 to advertise a default route to other OSPF routers as long as RTR2 has a default route in its own routing table. RTR2 does not currently have a default route but this will be corrected in the next steps.
|
||||
|
||||
### Step 2
|
||||
Verify the routing tables on RTR1 and RTR2
|
||||
|
||||
<pre>
|
||||
RTR1# <b>show ip route</b>
|
||||
<... output omitted ...>
|
||||
|
||||
Gateway of last resort is not set
|
||||
|
||||
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
|
||||
C 10.1.1.0/30 is directly connected, Ethernet0/0
|
||||
L 10.1.1.1/32 is directly connected, Ethernet0/0
|
||||
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
|
||||
C 192.168.1.0/24 is directly connected, Ethernet0/1
|
||||
L 192.168.1.1/32 is directly connected, Ethernet0/1
|
||||
O 192.168.2.0/24 [110/20] via 10.1.1.2, 2w3d, Ethernet0/0
|
||||
|
||||
RTR2# <b>show ip route</b>
|
||||
<... output omitted ...>
|
||||
|
||||
Gateway of last resort is not set
|
||||
|
||||
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
|
||||
C 10.1.1.0/30 is directly connected, Ethernet0/0
|
||||
L 10.1.1.2/32 is directly connected, Ethernet0/0
|
||||
O 192.168.1.0/24 [110/20] via 10.1.1.1, 2w3d, Ethernet0/0
|
||||
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
|
||||
C 192.168.2.0/24 is directly connected, Ethernet0/1
|
||||
L 192.168.2.1/32 is directly connected, Ethernet0/1
|
||||
</pre>
|
||||
|
||||
<p>RTR1 is learning about the RTR2 LAN (192.168.2.0/24) and RTR2 is learning about the RTR1 LAN (192.168.1.0/24).</p>
|
||||
<p>Also notice that RTR2 does not currently have a default route to advertise to RTR1.</p>
|
||||
<h3 id="step-3">Step 3</h3>
|
||||
<p>Verify the interfaces on RTR2</p>
|
||||
<pre>
|
||||
RTR2# <b>show ip interface brief</b>
|
||||
Interface IP-Address OK? Method Status Protocol
|
||||
Ethernet0/0 10.1.1.2 YES TFTP up up
|
||||
Ethernet0/1 192.168.2.1 YES TFTP up up
|
||||
Ethernet0/2 unassigned YES TFTP administratively down down
|
||||
Ethernet0/3 unassigned YES unset administratively down down
|
||||
</pre>
|
||||
|
||||
<p>The internet-facing Ethernet0/3 interface is currently administratively down and has not IP address configured. You will correct this in the next part of the lab.</p>
|
||||
<h2 id="part-2-configure-a-router-as-an-ipv4-dhcp-client">Part 2: Configure a router as an IPv4 DHCP Client</h2>
|
||||
<p>The RTR2 Ethernet 0/3 interface is connected to the "Internet" external connector node in CML. This node acts as an ISP that provides dynamic IPv4 addresses to its clients. In this part of the lab, you will enable RTR2 to request and receive an IPv4 DHCP address on interface Ethernet 0/3. RTR2 will also automatically create a default route pointing to the ISP. RTR2 should then advertise this default route to RTR1 via OSPF.</p>
|
||||
<h3 id="step-1">Step 1</h3>
|
||||
<p>Configure RTR2 E0/3 as an IPv4 DHCP client and enable the interface. After the interface comes up, it should take about 10 seconds for the E0/3 to received its IPv4 address.</p>
|
||||
<pre>
|
||||
RTR2# <b>conf t</b>
|
||||
Enter configuration commands, one per line. End with CNTL/Z.
|
||||
RTR2(config)# <b>interface E0/3</b>
|
||||
RTR2(config-if)# <b>ip address dhcp</b>
|
||||
RTR2(config-if)# <b>no shutdown</b>
|
||||
RTR2(config-if)#
|
||||
*Jan 3 16:48:43.228: %LINK-3-UPDOWN: Interface Ethernet0/3, changed state to up
|
||||
RTR2(config-if)#
|
||||
*Jan 3 16:48:44.228: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/3, changed state to up
|
||||
RTR2(config-if)#
|
||||
<mark>*Jan 3 16:48:50.386: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/3 assigned DHCP address 192.168.255.141, mask 255.255.255.0, hostname RTR2</mark>
|
||||
</pre>
|
||||
|
||||
<p>In the highlighted text above, notice that the interface is now configured with the 192.168.255.141/24 address. Use the <code>show ip interface brief</code> command to confirm the new DHCP address.</p>
|
||||
<h3 id="step-2">Step 2</h3>
|
||||
<p>Verify the routing table on RTR1 and RTR2. Both routers should now have a default route in its routing table.</p>
|
||||
<pre>
|
||||
RTR1# <b>show ip route</b>
|
||||
<... output omitted ...>
|
||||
|
||||
<mark>Gateway of last resort is 10.1.1.2 to network 0.0.0.0</mark>
|
||||
|
||||
<mark>O*E2 0.0.0.0/0 [110/1] via 10.1.1.2, 00:06:47, Ethernet0/0</mark>
|
||||
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
|
||||
C 10.1.1.0/30 is directly connected, Ethernet0/0
|
||||
L 10.1.1.1/32 is directly connected, Ethernet0/0
|
||||
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
|
||||
C 192.168.1.0/24 is directly connected, Ethernet0/1
|
||||
L 192.168.1.1/32 is directly connected, Ethernet0/1
|
||||
O 192.168.2.0/24 [110/20] via 10.1.1.2, 2w3d, Ethernet0/0
|
||||
|
||||
RTR2# <b>show ip route </b>
|
||||
<... output omitted ...>
|
||||
|
||||
<mark>Gateway of last resort is 192.168.255.1 to network 0.0.0.0</mark>
|
||||
|
||||
<mark>S* 0.0.0.0/0 [254/0] via 192.168.255.1</mark>
|
||||
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
|
||||
C 10.1.1.0/30 is directly connected, Ethernet0/0
|
||||
L 10.1.1.2/32 is directly connected, Ethernet0/0
|
||||
O 192.168.1.0/24 [110/20] via 10.1.1.1, 2w3d, Ethernet0/0
|
||||
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
|
||||
C 192.168.2.0/24 is directly connected, Ethernet0/1
|
||||
L 192.168.2.1/32 is directly connected, Ethernet0/1
|
||||
192.168.255.0/24 is variably subnetted, 2 subnets, 2 masks
|
||||
C 192.168.255.0/24 is directly connected, Ethernet0/3
|
||||
L 192.168.255.141/32 is directly connected, Ethernet0/3
|
||||
|
||||
</pre>
|
||||
RTR2 is automatically configured with a static default route thanks to DHCP. RTR1 is learning the default route via OSPF thanks to an External Type 5 LSA being advertised by RTR2 because of the default-information originate command.
|
||||
|
||||
### Step 3
|
||||
Verify connectivity from RTR1 and RTR2 to a public Internet address.
|
||||
|
||||
<pre>
|
||||
RTR1# <b>ping 8.8.8.8</b>
|
||||
Type escape sequence to abort.
|
||||
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
|
||||
!!!!!
|
||||
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
|
||||
|
||||
RTR2# <b>ping 8.8.8.8</b>
|
||||
Type escape sequence to abort.
|
||||
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
|
||||
!!!!!
|
||||
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
|
||||
</pre>
|
||||
Since RTR2 is configured with NAT (which will be covered in Season 2, Episode 3), both RTR1 and RTR2 are able to reach a public Internet address.
|
||||
|
||||
## Part 3: Configure a Router as an IPv4 DHCP Server
|
||||
The Cisco IOS DHCP server is a full DHCP server implementation that assigns and manages IPv4 addresses from specified address pools within the device to DHCP clients. The DHCP server can be configured to assign additional parameters such as the IPv4 address of the DNS server and the default gateway. In this part of the lab, you will configure RTR1 as an IPv4 DHCP server for the RTR1 LAN and the RTR2 LAN.
|
||||
|
||||
### Step 1
|
||||
Configure the IPv4 DHCP pool for the RTR1 LAN (192.168.1.0/24) and exclude the first five addresses of that network. Use the pool name RTR1_LAN.
|
||||
|
||||
<pre>
|
||||
RTR1(config)# <b>ip dhcp pool RTR1_LAN</b>
|
||||
RTR1(dhcp-config)# <b>network 192.168.1.0 /24</b>
|
||||
RTR1(dhcp-config)# <b>default-router 192.168.1.1</b>
|
||||
RTR1(dhcp-config)# <b>dns-server 8.8.8.8</b>
|
||||
RTR1(dhcp-config)# <b>domain-name lab.example</b>
|
||||
RTR1(dhcp-config)# <b>lease 0 12</b>
|
||||
RTR1(dhcp-config)#exit
|
||||
RTR1(config)# <b>ip dhcp excluded-address 192.168.1.1 192.168.1.5</b>
|
||||
</pre>
|
||||
In the configuration example above the, IPv4 addresses are assigned from the address pool 192.168.1.0/24 with a lease time of 12 hours. Additional parameters are the default gateway, domain name, and DNS server. Also, IPv4 addresses from 192.168.1.1 to 192.168.1.5 are not assigned to the end devices. Use the ``?`` option under the DHCP pool to investigate the different configuration options available.
|
||||
|
||||
### Step 2
|
||||
Use the `show ip dhcp pool RTR1_LAN` command to investigate the DHCP pool configuration.
|
||||
<pre>
|
||||
RTR1# <b>show ip dhcp pool RTR1_LAN</b>
|
||||
|
||||
Pool RTR1_LAN :
|
||||
Utilization mark (high/low) : 100 / 0
|
||||
Subnet size (first/next) : 0 / 0
|
||||
Total addresses : 254
|
||||
Leased addresses : 0
|
||||
Excluded addresses : 5
|
||||
Pending event : none
|
||||
1 subnet is currently in the pool :
|
||||
Current index IP address range Leased/Excluded/Total
|
||||
192.168.1.1 192.168.1.1 - 192.168.1.254 0 / 5 / 254
|
||||
</pre>
|
||||
The output confirms that 5 addresses are excluded from the total range and that there are currently no leased addresses.
|
||||
|
||||
### Step 3
|
||||
Enable DHCP debugging on RTR1 and then start the PC1 device.
|
||||
|
||||
<pre>
|
||||
RTR1# <b>debug ip dhcp server events</b>
|
||||
DHCP server event debugging is on.
|
||||
RTR1# <b>debug ip dhcp server packet</b>
|
||||
DHCP server packet debugging is on.
|
||||
</pre>
|
||||
|
||||
<p>Right-click on PC1 and select <strong>Start</strong>.</p>
|
||||
<p>Within a few seconds you should see some DHCP debugging messages. If you scroll through them, you should find the four DHCP messages exchanged between PC1 and RTR1:</p>
|
||||
<pre>
|
||||
*Jan 6 15:34:45.855: <mark>DHCPD: DHCPDISCOVER</mark> received from client 0152.5400.1529.f9 on interface Ethernet0/1.
|
||||
|
||||
*Jan 6 15:34:47.856: <mark>DHCPD: Sending DHCPOFFER</mark> to client 0152.5400.1529.f9 (192.168.1.6).
|
||||
|
||||
*Jan 6 15:34:47.859: <mark>DHCPD: DHCPREQUEST received</mark> from client 0152.5400.1529.f9 on interface Ethernet0/1
|
||||
|
||||
*Jan 6 15:34:47.859: <mark>DHCPD: Sending DHCPACK</mark> to client 0152.5400.1529.f9 (192.168.1.6).
|
||||
</pre>
|
||||
In the output above, PC1 was assigned the 192.168.1.6 address by the DHCP server on RTR1.
|
||||
|
||||
|
||||
### Step 4
|
||||
Verify the IPv4 configuration on PC1 and test connectivity to the Internet.
|
||||
|
||||
Open the console on PC1. Use the `ip addr show dev eth0` command to verify its IPv4 configuration. PC1 will have an IP address from the 192.168.1.0/24 network.
|
||||
|
||||
<pre>
|
||||
PC1:~$ <b>ip addr show dev eth0</b>
|
||||
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
|
||||
link/ether 52:54:00:15:29:f9 brd ff:ff:ff:ff:ff:ff
|
||||
inet 192.168.1.6/24 scope global eth0
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 fe80::5054:ff:fe15:29f9/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
</pre>
|
||||
|
||||
<p>Use the <code>ip route list</code> command to verify the PC's routing table. You should see the default gateway set to 192.168.1.1 which is the IP address of RTR1 E0/1.</p>
|
||||
<pre>
|
||||
PC1:~$ <b>ip route list</b>
|
||||
<mark>default via 192.168.1.1 dev eth0 metric 202 </mark>
|
||||
172.17.0.0/16 dev docker0 scope link src 172.17.0.1
|
||||
192.168.1.0/24 dev eth0 scope link src 192.168.1.6
|
||||
</pre>
|
||||
|
||||
<p>From the command prompt, ping the public DNS server at <strong>8.8.8.8</strong>. This ping should be successful.</p>
|
||||
<p>Open a VNC connection to PC1 and use the browser to test connectivity to <strong>www.cisco.com</strong>. This test should also be successful since the DHCP server is configured to provide clients with the DNS server's IP address (8.8.8.8)</p>
|
||||
<h3 id="step-5">Step 5</h3>
|
||||
<p>Configure the IPv4 DHCP pool for the RTR2 LAN (192.168.2.0/24) and exclude the first five addresses of that network. Use the pool name RTR2_LAN.</p>
|
||||
<pre>
|
||||
RTR1(config)# <b>ip dhcp pool RTR2_LAN</b>
|
||||
RTR1(dhcp-config)# <b>network 192.168.2.0 /24</b>
|
||||
RTR1(dhcp-config)# <b>default-router 192.168.2.1</b>
|
||||
RTR1(dhcp-config)# <b>dns-server 8.8.8.8</b>
|
||||
RTR1(dhcp-config)# <b>domain-name lab.example</b>
|
||||
RTR1(dhcp-config)# <b>lease 0 12</b>
|
||||
RTR1(dhcp-config)#exit
|
||||
RTR1(config)# <b>ip dhcp excluded-address 192.168.2.1 192.168.2.5</b>
|
||||
</pre>
|
||||
|
||||
<h3 id="step-6">Step 6</h3>
|
||||
<p>Start a packet capture on the link between RTR1 and RTR2 to capture the DHCP messages sent from PC2.</p>
|
||||
<p> Right-click the link between RTR1 and RTR2 and click <strong>Packet Capture</strong>. In the packet capture tab, select Settings and add a BPF filter for DHCP packets. Cick <strong>Apply</strong> and then click <strong>Start</strong>.</p>
|
||||
<p> Right-click on PC2 and select <strong>Start</strong> to boot up the device.</p>
|
||||
<p> Return to the packet capture tab. You should not see any DHCP messages crossing the link between RTR1 and RTR2. Recall that DHCP messages from PC2 (DHCP Discover and DHCP Request) are broadcast messages and don't get forwarded off the local LAN by default. You will correct this issue in the next part of the lab.</p>
|
||||
<h2 id="part-4-configure-an-ipv4-dhcp-relay">Part 4: Configure an IPv4 DHCP Relay</h2>
|
||||
<p> A DHCP relay agent is any host that forwards DHCP packets between clients and servers. Relay agents are used for forwarding requests and replies between clients and servers when they are not on the same subnet. DHCP requests are sent as broadcasts, and because routers don't forward broadcasts, you need a relay functionality to reach the DHCP server. In this part of the lab, you will configure RTR2 E0/1 as a DHCP relay agent. This will allow PC2 DHCP messages to be forwarded to RTR1.</p>
|
||||
<p> To configure the DHCP relay agent to forward packets to a DHCP server, you need to enter the interface configuration mode using the interface interface command. Then, use the <code>ip helper-address</code> command to specify that the interface will forward UDP broadcasts, including BOOTP and DHCP, to the specified server address.</p>
|
||||
<p> The <code>ip helper-address</code> command should be issued on the interface where the DHCP broadcasts are received.</p>
|
||||
<p>These steps show how DHCP requests are processed when DHCP relay is used:</p>
|
||||
<ol>
|
||||
<li><p>A DHCP client broadcasts a DHCP request.</p>
|
||||
</li>
|
||||
<li><p>The DHCP relay device includes option 82 and sends the DHCP request as a unicast packet to the DHCP server. Option 82 includes remote ID and circuit ID information.</p>
|
||||
</li>
|
||||
<li><p>The DHCP server responds to the DHCP relay.</p>
|
||||
</li>
|
||||
<li><p>The DHCP relay strips off option 82 and sends the response to the DHCP client.</p>
|
||||
<h3 id="step-1">Step 1</h3>
|
||||
<p>Configure the DHCP relay functionality on RTR2 E0/1.</p>
|
||||
</li>
|
||||
</ol>
|
||||
<pre>
|
||||
RTR2(config)# <b>interface E0/1</b>
|
||||
RTR2(config-if)# <b>ip helper-address 10.1.1.1</b>
|
||||
</pre>
|
||||
|
||||
<p>The <code>ip helper-address</code> command tells RTR2 that any broadcasts received on E0/1 will be sent to the 10.1.1.1 address which is configured on RTR1 E0/0.</p>
|
||||
<p>Stop and re-start PC2 to trigger the client's DHCP process again.</p>
|
||||
<h3 id="step-2">Step 2</h3>
|
||||
<p>Return to the packet capture tab to observe the DHCP messages that are now crossing the link between RTR1 and RTR2. Your output should be similar to what is shown below:</p>
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Time</th>
|
||||
<th>Source</th>
|
||||
<th>Destination</th>
|
||||
<th>Protocol</th>
|
||||
<th>Info</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td><code>0.000000</code></td>
|
||||
<td><code>192.168.2.1</code></td>
|
||||
<td><code>10.1.1.1</code></td>
|
||||
<td><code>DHCP</code></td>
|
||||
<td><code>DHCP Discover - Transaction ID 0xba02f774</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0.001355</code></td>
|
||||
<td><code>10.1.1.1</code></td>
|
||||
<td><code>192.168.2.1</code></td>
|
||||
<td><code>DHCP</code></td>
|
||||
<td><code>DHCP Offer - Transaction ID 0xba02f774</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0.002901</code></td>
|
||||
<td><code>192.168.2.1</code></td>
|
||||
<td><code>10.1.1.1</code></td>
|
||||
<td><code>DHCP</code></td>
|
||||
<td><code>DHCP Request - Transaction ID 0xba02f774</code></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><code>0.003654</code></td>
|
||||
<td><code>10.1.1.1</code></td>
|
||||
<td><code>192.168.2.1</code></td>
|
||||
<td><code>DHCP</code></td>
|
||||
<td><code>DHCP ACK - Transaction ID 0xba02f774</code></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<p>The packet capture confirms that DHCP Discover and DHCP Request received on RTR2 E0/1 are being relayed to 10.1.1.1 on RTR1. Click through the captured packets to investigate the option fields in the DHCP header.</p>
|
||||
<h3 id="step-3">Step 3</h3>
|
||||
<p>Verify the IPv4 configuration on PC2 and test connectivity to the Internet.</p>
|
||||
<p>Open the console on PC2 and access the command prompt. Use the <code>ip addr show dev eth0</code> command to verify its IPv4 configuration. PC1 will have an IP address from the 192.168.2.0/24 network.</p>
|
||||
<p>Use the <code>ip route list</code> command to verify the PC's routing table. You should see the default gateway set to 192.168.2.1 which is the IP address of RTR2 E0/1.</p>
|
||||
<p>From the command prompt, ping the public DNS server at <strong>8.8.8.8</strong>. This ping should be successful.</p>
|
||||
<p>Open a VNC connection to PC2 and use the browser to test connectivity to <strong>www.cisco.com</strong>. This test should be successful.</p>
|
||||
<h3 id="step-4">Step 4</h3>
|
||||
<p>Return to RTR1 and inspect the DHCP debugging output. You should see the following messages:</p>
|
||||
<p><pre>
|
||||
*Jan 6 16:21:01.881: DHCPD: DHCPDISCOVER received from client 0152.5400.1f04.4d <mark>through relay 192.168.2.1.</mark></p>
|
||||
<p>*Jan 6 16:21:01.881: DHCPD: Sending DHCPOFFER to client 0152.5400.1f04.4d (192.168.2.7).</p>
|
||||
<p>*Jan 6 16:21:01.883: DHCPD: DHCPREQUEST received from client 0152.5400.1f04.4d on interface Ethernet0/0</p>
|
||||
<p>*Jan 6 16:21:01.883: DHCPD: Client is Selecting (<mark>DHCP Request with Requested IP = 192.168.2.7, Server ID = 10.1.1.1</mark>)</p>
|
||||
<p>*Jan 6 16:21:01.883: DHCPD: Sending DHCPACK to client 0152.5400.1f04.4d (192.168.2.7).
|
||||
</pre>
|
||||
Notice that RTR1 is aware that the DHCP Discover message was relayed from 192.168.2.1 and the DHCP client (PC2) is being serviced by the DHCP server located at 10.1.1.1.</p>
|
||||
</body></html>
|
||||
title: CCNA Prep 2025 - S2E1 - DHCP
|
||||
version: 0.2.2
|
BIN
lab-topologies/ccna-prep/s2e1/CCNA_Prep_DHCP_Guide.pdf
Normal file
5
lab-topologies/ccna-prep/s2e1/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# DHCP in Action: Streamlining Network Client Address Management
|
||||
|
||||
*Abstract:* Review the essential role of Dynamic Host Configuration Protocol (DHCP) in managing network client address assignments in this practical, demonstration focused live event. Gain insights into configuring and verifying DHCP clients and relay agents, and reinforce how DHCP simplifies IP address distribution. Through real-world examples, you'll practice the skills needed to effectively manage and troubleshoot DHCP in your network environment as you prepare for your CCNA Exam.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e1/s2e1-dhcp.jpeg
Normal file
After Width: | Height: | Size: 71 KiB |
BIN
lab-topologies/ccna-prep/s2e2/CCNA Prep S02 E02 Lab Guide.pdf
Normal file
1296
lab-topologies/ccna-prep/s2e2/CCNA_Prep_2025_S2E2_DNS_Deepdive.yaml
Normal file
5
lab-topologies/ccna-prep/s2e2/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# DNS Deepdive: Exploring a Backbone of Network Communication
|
||||
|
||||
*Abstract:* Step into the dynamic world of DNS in this engaging, lab focused live event. Discover how to configure basic DNS servers and clients while unraveling the mystery of how domain names translate into IP addresses. Through practical demonstrations, you'll see firsthand how DNS keeps your network running smoothly and efficiently, mastering this vital technology before you take your CCNA exam.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e2/s2e2-dns.jpeg
Normal file
After Width: | Height: | Size: 83 KiB |
1127
lab-topologies/ccna-prep/s2e3/CCNA_Prep_2025_-_S2E3_-_NAT.yaml
Normal file
BIN
lab-topologies/ccna-prep/s2e3/CCNA_Prep_S02E03_NAT_Guide.pdf
Normal file
5
lab-topologies/ccna-prep/s2e3/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Navigating NAT: Bridging Private Networks to the Internet
|
||||
|
||||
*Abstract:* Explore the critical role of Network Address Translation (NAT) in providing Internet access for networks using private IP addresses. In this live session, you'll review the configuration of NAT using static and pool techniques. The practical insights into how NAT enables efficient connectivity between private networks and the wider Internet will prepare you for your CCNA exam.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e3/s2e3-nat.jpg
Normal file
After Width: | Height: | Size: 52 KiB |
BIN
lab-topologies/ccna-prep/s2e4/CCNA Prep S02 E04 Lab Guide.pdf
Normal file
@@ -0,0 +1,885 @@
|
||||
annotations:
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'CCNA Exam Prep: Back to Networking Basics with Hank Preston and
|
||||
Patrick Gargano'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: -80.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'Securing Network Access: From Telnet to SSH'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 18
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: -40.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
No doubt you've heard that SSH is better than telnet because, well "security". But what does that mean?
|
||||
Is it really a problem? And how exactly do you ensure secure device administration? Well, we will tackle all
|
||||
this in the following lab with the following exercises:
|
||||
|
||||
In this lab you will explore device adminstration with some hands on exercises focused on:
|
||||
|
||||
* Enabling Telnet device administration, and seeing why it might not be the most secure
|
||||
* Creating local administrator accounts on network devices
|
||||
* Migrating to SSH from Telnet for device administration
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 0.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |2-
|
||||
|
||||
host user/pass: cisco / cisco
|
||||
network enable password: enablepass
|
||||
network telnet password: telnetpass
|
||||
network admin user/pass: admin / adminpass
|
||||
network oper user/pass: oper / operpass (read-only)
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |
|
||||
Credentials:
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: ____________
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#7FF0FA'
|
||||
thickness: 2
|
||||
type: rectangle
|
||||
x1: -483.21004499370474
|
||||
y1: 310.36986501888595
|
||||
x2: 538.6848224811145
|
||||
y2: 117.88725898435627
|
||||
z_index: 4
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#F593E1'
|
||||
thickness: 2
|
||||
type: rectangle
|
||||
x1: 61.89486747481904
|
||||
y1: 310.77931009652815
|
||||
x2: 306.0242893998466
|
||||
y2: 265.1398836171298
|
||||
z_index: 4
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: Inside
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -475.31049493075153
|
||||
y1: 318.42773531686413
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: Outside
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 69.73658407878582
|
||||
y1: 317.76716539660475
|
||||
z_index: 5
|
||||
nodes:
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: internet
|
||||
node_definition: external_connector
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 320
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname rtr01
|
||||
!
|
||||
! In order to avoid entering a configuration dialog
|
||||
! on boot, please ensure that all ethernet interfaces
|
||||
! have some ip configuration present here such as the
|
||||
! example below:
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
ip host rtr01.example.com 10.0.0.1
|
||||
ip host sw01.example.com 192.168.0.2
|
||||
ip name-server 192.168.255.1
|
||||
ip domain name example.com
|
||||
ip dns server
|
||||
ip dns primary example.com soa 192.168.0.1 admin@example.com 21600 900 7776000 86400
|
||||
!
|
||||
ip dhcp excluded-address 192.168.0.1 192.168.0.10
|
||||
ip dhcp pool inside
|
||||
network 192.168.0.0 /24
|
||||
default-router 192.168.0.1
|
||||
dns-server 10.0.0.1
|
||||
domain-name example.com
|
||||
exit
|
||||
!
|
||||
ip access-list standard NAT
|
||||
permit 192.168.0.0 0.0.0.255
|
||||
!
|
||||
ip nat inside source list NAT interface e0/0 overload
|
||||
!
|
||||
interface e0/1
|
||||
description Link to Inside Hosts
|
||||
ip address 192.168.0.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
interface e0/0
|
||||
description Link to Internet
|
||||
ip address dhcp
|
||||
ip nat outside
|
||||
no shut
|
||||
!
|
||||
!
|
||||
interface loopback0
|
||||
ip address 10.0.0.1 255.255.255.255
|
||||
!
|
||||
line vty 0 4
|
||||
no login
|
||||
transport input none
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: null
|
||||
label: rtr01
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 24
|
||||
y: 361
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname sw01
|
||||
ip domain name example.com
|
||||
!
|
||||
vtp version 2
|
||||
vtp mode transparent
|
||||
!
|
||||
vlan 10
|
||||
name inside-network
|
||||
!
|
||||
interface e0/0
|
||||
description Link to rtr01
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface e0/1
|
||||
description Link to netadmin
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface vlan 10
|
||||
description Switch Management Interface
|
||||
ip address 192.168.0.2 255.255.255.0
|
||||
no shutdown
|
||||
!
|
||||
ip route 0.0.0.0 0.0.0.0 192.168.0.1
|
||||
ip name-server 10.0.0.1
|
||||
!
|
||||
line vty 0 4
|
||||
no login
|
||||
transport input none
|
||||
!
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: sw01
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -200
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname netadmin
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: netadmin
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -440
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: ext-sw
|
||||
node_definition: unmanaged_switch
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 160
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i1
|
||||
label: port1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i2
|
||||
label: port2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i3
|
||||
label: port3
|
||||
slot: 3
|
||||
type: physical
|
||||
- id: i4
|
||||
label: port4
|
||||
slot: 4
|
||||
type: physical
|
||||
- id: i5
|
||||
label: port5
|
||||
slot: 5
|
||||
type: physical
|
||||
- id: i6
|
||||
label: port6
|
||||
slot: 6
|
||||
type: physical
|
||||
- id: i7
|
||||
label: port7
|
||||
slot: 7
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname outside-host
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n5
|
||||
image_definition: null
|
||||
label: outside-host
|
||||
node_definition: alpine
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 160
|
||||
y: 520
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n2
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: sw01-Ethernet0/0<->rtr01-Ethernet0/1
|
||||
- id: l1
|
||||
n1: n3
|
||||
n2: n2
|
||||
i1: i0
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: netadmin-eth0<->sw01-Ethernet0/1
|
||||
- id: l2
|
||||
n1: n1
|
||||
n2: n4
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: rtr01-Ethernet0/0<->ext-sw-port0
|
||||
- id: l3
|
||||
n1: n4
|
||||
n2: n0
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: ext-sw-port1<->internet-port
|
||||
- id: l4
|
||||
n1: n5
|
||||
n2: n4
|
||||
i1: i0
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: outside-host-eth0<->ext-sw-port2
|
||||
lab:
|
||||
description: Discover why SSH is the preferred choice over Telnet for secure network
|
||||
management in this insightful event. Through hands-on activities, master the ins
|
||||
and outs to configuring SSH on Cisco switches and routers, ensuring encrypted
|
||||
and authenticated remote access. Understand the security implications of using
|
||||
SSH, and elevate your skills in managing network devices securely and efficiently.
|
||||
Join us as you prepare for your CCNA exam.
|
||||
notes: |-
|
||||
**CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano**
|
||||
|
||||
# Securing Network Access: From Telnet to SSH
|
||||
|
||||
> Discover why SSH is the preferred choice over Telnet for secure network management in this insightful event. Through hands-on activities, master the ins and outs to configuring SSH on Cisco switches and routers, ensuring encrypted and authenticated remote access. Understand the security implications of using SSH, and elevate your skills in managing network devices securely and efficiently. Join us as you prepare for your CCNA exam.
|
||||
|
||||
No doubt you've heard that SSH is better than telnet because, well "security". But what does that mean? Is it really a problem? And how exactly do you ensure secure device adminsistration? Well, we will tackle all this in the following exercices:
|
||||
|
||||
In this lab you will explore device adminstration with some hands on exercises focused on:
|
||||
|
||||
* Enabling Telnet device administration, and seeing why it might not be the most secure
|
||||
* Creating local administrator accounts on network devices
|
||||
* Migrating to SSH from Telnet for device administration
|
||||
|
||||
> This lab touches on several topics from the [CCNA v1.1 Topics List](https://learningcontent.cisco.com/documents/marketing/exam-topics/200-301-CCNA-v1.1.pdf)
|
||||
> 2.8 Describe network device management access (Telnet, SSH, HTTP, HTTPS, console, TACACS+/RADIUS, and cloud managed)
|
||||
> 4.8 Configure network devices for remote access using SSH
|
||||
> 5.3 Configure and verify device access control using local passwords
|
||||
|
||||
## Setup and Scenario
|
||||
This setup of lab based demonstrations includes a small network made up of an IOS based switch and router, that provides internet access to a `netadmin` host. There is also an `outside-host` that will be used for some testing. The network is preconfigured to provide connectivity to the Internet for the `netadmin` host with DHCP, DNS, and NAT services provided by `rtr01`. `sw01` is configured with a management IP address, and there are DNS entries for both network devices configured to allow `netadmin` to reach the devices by name.
|
||||
|
||||
```
|
||||
netadmin:~$ ping -c 2 sw01
|
||||
|
||||
PING sw01 (192.168.0.2): 56 data bytes
|
||||
64 bytes from 192.168.0.2: seq=0 ttl=42 time=0.975 ms
|
||||
64 bytes from 192.168.0.2: seq=1 ttl=42 time=1.418 ms
|
||||
|
||||
netadmin:~$ ping -c 2 rtr01
|
||||
|
||||
PING rtr01 (10.0.0.1): 56 data bytes
|
||||
64 bytes from 10.0.0.1: seq=0 ttl=42 time=1.447 ms
|
||||
64 bytes from 10.0.0.1: seq=1 ttl=42 time=1.125 ms
|
||||
```
|
||||
|
||||
Go ahead and open the console for the `netadmin` host and try out the above pings yourself. "Pinging" is fun :-)!!
|
||||
|
||||
> Note: The credentials for `netadmin` and `outside-host` are `cisco / cisco`.
|
||||
|
||||
*Be sure to **START** the lab before continuing to the demo labs.*
|
||||
|
||||
## Setting up initial IP based device management with Telnet
|
||||
Using serial (console) connectivity to configure and operate networking equipment requires the engineer be in physical proximity to the device so that a cable can be plugged from the devices port into their laptop. This is fine during initial setup or emergency troubleshooting, but it isn't very convenient when you want to add a VLAN to a switch, update a router's static routes, or run some show commands to understand the current state of the network. The ability to log into the network devices over "the network" is a far more convenient option.
|
||||
|
||||
> There are dedicated "terminal server" or "console server" appliances that can be provide the direct connection to serial ports on devices and offer network administrators access over the network. Many organizations do deploy these to aid in remote adminstration of devices, but even when they are available, console based administration is typically reserved for times when devices are unreachable over the network. Upgrades, troubleshooting, etc.
|
||||
|
||||
While it is highly recommended that network devices only be administered using a secure protocol like SSH, we'll begin this lab by configuring telnet to fully explore how (and why) secure network access can be configured.
|
||||
|
||||
1. We'll start by verifying that we can NOT log into the network devices with telnet at the start of the lab. Open the console for `netadmin`. The username/password to log in is `cisco/cisco`.
|
||||
1. Attempt to use telnet to log into the `rtr01`. DNS is configured so you can use the hostname.
|
||||
|
||||
```
|
||||
telnet rtr01
|
||||
|
||||
# Output
|
||||
telnet: can't connect to remote host (10.0.0.1): Connection refused
|
||||
```
|
||||
|
||||
1. Repeat for `sw01`.
|
||||
1. Now that we've seen that telent does NOT work, we'll learn how to enable it.
|
||||
|
||||
1. Open the console for `rtr01` and enter enable mode.
|
||||
1. To access the CLI for a network device over the network, you connect to a "VTY line", or "virtual teletype line". Different network devices have different numbers of VTY lines. The IOS router and switch in this lab each have 5 lines, numbered 0 -> 4. Another common number of lines is 16, numbered 0 -> 15.
|
||||
1. Add the following configuration to `rtr01`. To enable `login` over the VTY lines and to allow communication on the line with `telnet`.
|
||||
|
||||
```
|
||||
line vty 0 4
|
||||
login
|
||||
transport input telnet
|
||||
```
|
||||
|
||||
1. You should get a console message like the below. This is an exmaple of a very useful message to the administrator. While we've turned on logging in via telnet on the lines, the router will NOT allow that to happen until a password is set. Because once telnet administration is enabled, anyone connected to the network could begin administering the device. Security is important!
|
||||
|
||||
```
|
||||
% Login disabled on line 2, until 'password' is set
|
||||
```
|
||||
|
||||
* You will actually see several of these messages, 5 to be exact. Why do you think that is?
|
||||
|
||||
<details><summary>Answer:</summary>
|
||||
You are configuring 5 different lines at the same time, indicated by `line vty 0 4`. So one message per "line" being configured.</details>
|
||||
|
||||
1. So go ahead and add the password to the `line vty 0 4` configuration block.
|
||||
|
||||
```
|
||||
password telnetpass
|
||||
```
|
||||
|
||||
> Note: If you left `config-line` mode, you will need to re-enter with `line vty 0 4`.
|
||||
|
||||
1. Now return to the console for `netadmin` and try to connect with telnet. When you are prompted for the `Password:`, use the newly configured `telnetpass` that you just set.
|
||||
|
||||
```
|
||||
telnet rtr01
|
||||
|
||||
# Output
|
||||
Connected to rtr01
|
||||
|
||||
Entering character mode
|
||||
Escape character is '^]'.
|
||||
|
||||
User Access Verification
|
||||
|
||||
Password:
|
||||
rtr01>
|
||||
```
|
||||
|
||||
1. Now enter enable mode. Did it work? Why not?
|
||||
|
||||
<details><summary>Answer</summary>
|
||||
While the network device does NOT mind allowing unauthenticated privileged mode access over the console port, an `enable password` (or `secret`) is required for over the network administration.</details>
|
||||
|
||||
1. Return to the console for `rtr01` and set an enable secret.
|
||||
|
||||
```
|
||||
enable secret enablepass
|
||||
```
|
||||
|
||||
1. And now go back to the console for `netadmin` and try to enter enable mode again.
|
||||
1. Ta-da... you can now administer `rtr01` remotely from your network administration workstation, from anywhere on the network.
|
||||
1. Disconnect by typing `exit`.
|
||||
1. Repeat the configuration to enable telnet administration on `sw01` and verify that you can login and access enable mode from `netadmin`.
|
||||
1. Make sure to `exit` from the connection to `sw01` when you are done.
|
||||
|
||||
## Understanding why clear text protocols like Telnet are a bad idea
|
||||
Great work... maybe. I'm sure you've heard by now that "telnet bad, ssh good" but why? "Security" you may say. You might even know that the issue is because "telnet isn't encrypted". Both true, but let's see if we can experience this with our own eyes.
|
||||
|
||||
> ***Pro Tip!:*** CML allows you to "split" the Panes display into multiple sections to allow the viewing of two or more different interfaces (ie Console, VNC, or Packet Capture) at the same time. This feature is particularly handy when doing a packet capture, so you can see the captured packets while performing actions on a node.
|
||||
>
|
||||
> Click the `+` button on the right side of the "Panes" to split the window. Then "click" within the section before opening starting the capture. You can also "drag" a window from one pane to another.
|
||||
|
||||
1. Right-click the link between `netadmin` and `sw01` and choose "Packet Capture".
|
||||
1. Click the gear icon to open the settings for the capture. Add the following BPF filter and "Apply" the settings change.
|
||||
|
||||
```
|
||||
tcp port 23
|
||||
```
|
||||
|
||||
> Why tcp port 23?
|
||||
> <details><summary>Answer</summary>
|
||||
> Telnet is an application that uses TCP and operates on port 23.</details>
|
||||
|
||||
1. Start the packet capture.
|
||||
1. Now return to the console for `netadmin` and connect to `rtr01` with telnet. Go ahead and enter the password to login.
|
||||
1. Now look at the packet capture and click on Frame 6 that shows "Telnet Data..." in the Info column. Click on the frame and expand the `Telnet` section in the packet details. What do you see?
|
||||
<details><summary>Answer:</summary>
|
||||
You'll see the login message sent by `rtr01` to `netadmin` in clear text. </details>
|
||||
1. Change to page 2 and look at Frame 12, 14, 16, and the other "Telnet Data..." frames sourced by `netadmin`. What do you see?
|
||||
<details><summary>Answer:</summary>
|
||||
What you should see is the password you entered to log into the router, one (or two) characters at a time.</details>
|
||||
|
||||
> Note: The frame numbers above should match for you if you created the filter, started the capture, and then used `telnet rtr01` from `netadmin` and logged in with the password immediately. If you aren't seeing the expected data within the frame numbers indicated, click and check the "Telnet Data..." frames until you find them.
|
||||
|
||||
So now you see why "telnet bad". Anyone who has access to the network packets that have a telnet session running can see everything that is sent in both directions. And you don't need to do it frame by frame. There are many programs that can be used to analyze network streams, find telnet applications, capture the output and search for credentials.
|
||||
> So why is "SSH good"? Because as an encrypted protocol, an attack like this isn't possible. You'll be able to try this out yourself and see it in action later!
|
||||
|
||||
## Configuring local user accounts for managing network devices
|
||||
Now the network team can all log into the network devices remotely from the convenience of anywhere on the network. However, everyone uses the same telnet password. Providing individual accounts to each user is a standard procedure for organizations and applications. There are many reasons to go down this path including:
|
||||
|
||||
* Allowing for accurate auditing of who is connected to the network and making changes
|
||||
* Providing different levels of access to different people. Often called "Role Based Access Control" or "RBAC"
|
||||
* Being able to disable access to individuals without effecting an entire team
|
||||
|
||||
There is another reason we are going to enable individual user accounts in this lab, SSH access requires it to be setup. And that's our ultimate destination :-)
|
||||
|
||||
1. Go ahead and log into `rtr1`. Either with the direct console connection, or through telnet from `netadmin`.
|
||||
1. Enter configuration mode, and create a new admin user on the router.
|
||||
|
||||
```
|
||||
username admin secret adminpass
|
||||
```
|
||||
|
||||
> Note: Be careful to ***NOT*** add a space after the password. If you do, the space becomes PART of the password. This is a common mistake that can lead to you being unable to log in and access your router. The author of this lab guide has made this mistake many many times.
|
||||
|
||||
1. Now you need to update the VTY configuration to use the "local" username/passwords rather than the telnet password that was configured.
|
||||
|
||||
```
|
||||
line vty 0 4
|
||||
login local
|
||||
```
|
||||
|
||||
* It is also a good idea to remove the telnet password that we won't be using anymore.
|
||||
|
||||
```
|
||||
line vty 0 4
|
||||
no password
|
||||
```
|
||||
|
||||
1. Now return to the `netadmin` host and try to log into `rtr01` with telnet once again. Use the `admin / adminpass` credentials you just configured.
|
||||
|
||||
```
|
||||
telnet rtr01
|
||||
|
||||
# Output
|
||||
Connected to rtr01
|
||||
|
||||
Entering character mode
|
||||
Escape character is '^]'.
|
||||
|
||||
|
||||
|
||||
User Access Verification
|
||||
|
||||
Username: admin
|
||||
Password:
|
||||
rtr01>
|
||||
```
|
||||
|
||||
1. Go ahead and enter "enable" mode. You should be prompted for the enable password, this will be the same `enablepass` that you configured before.
|
||||
|
||||
### Adding privilege to user accounts
|
||||
Now we'll enhance the login process by adding a "privilege level" to the user accounts. This isn't required, but it is a common configuration that will place "administrators" automatically into "enable" mode. We can also use it to provide "read only" access to "operator" users.
|
||||
|
||||
Cisco IOS uses "privilege levels" to track access levels. `priv 15` is the same as "Privileged EXEC mode" (ie "enable mode"), and `priv 1` is the same "User EXEC mode".
|
||||
|
||||
1. From the CLI of `rtr01` (either console or using the telnet access), add `priv 15` to the `admin` user.
|
||||
|
||||
```
|
||||
username admin priv 15
|
||||
```
|
||||
|
||||
1. Now try to reconnect with telnet to the router.
|
||||
> If you configured the above from the telnet connection, `exit` out to disconnect and reconnect.
|
||||
1. Did you see any difference?
|
||||
|
||||
<details><summary>Answer:</summary>
|
||||
You should now have been dropped into `Priveleged EXEC mode` automatically.</details>
|
||||
|
||||
1. Handy right? Create a new account with `priv 15` for yourself with whatever username and password you want to use. You can do all this with a single line of configuration.
|
||||
|
||||
```
|
||||
username carl priv 15 secret carlpass
|
||||
```
|
||||
|
||||
1. Create one more user, `oper` with the secret password `operpass` that has `priv 1`.
|
||||
|
||||
```
|
||||
username oper priv 1 secret operpass
|
||||
```
|
||||
|
||||
1. Take a look at the configuration for the user accounts.
|
||||
|
||||
```
|
||||
show run | section username
|
||||
|
||||
# Output
|
||||
username admin privilege 15 secret 9 $9$JTuPJ0yjNpNuNk$hCbbeDhhX8DStDn5BKbOlJ7LWjvKkZP.wnFmZdNhwHA
|
||||
username carl privilege 15 secret 9 $9$O1J7C4XQ8aE/rU$TcDZQXJiv3h1c7gkqdgUqKJEhCydXfY2yz6hZzxWJbI
|
||||
username oper secret 9 $9$cjBNZ2V.CJT.fU$BDC0biwbJ8Wn.Lw1uau53B3jQhlFqYoEG5VF2BjpitY
|
||||
```
|
||||
|
||||
* What do you notice about them?
|
||||
|
||||
<details><summary>Answer:</summary>
|
||||
A couple things should jump out at you. First, the passwords (or secrets) are encrypted using a method that is (currently) difficult to break. This is indicated by `secret 9` in the output. Older versions of IOS used methods other than `9` to "hide" passwords in configurations. Most of them are considered insecure today. `secret 9` is the best practice used today. Second, `username oper` lacks a `priv 1` element to the configuration. This is because `priv 1` is the lowest privilege level and the default. </details>
|
||||
|
||||
### Configuring `sw01`
|
||||
Before moving onto SSH, go ahead and configure `sw01`.
|
||||
|
||||
1. Create user accounts for `admin` and `oper` with appropriate `priv` levels
|
||||
1. Update the VTY lines to use the newly created user accounts.
|
||||
1. Remove the telnet password
|
||||
|
||||
## Migrating from Telnet to SSH for managing network devices
|
||||
Excellent work so far. Just one more thing to do, enable SSH and make our device administration secure. Well, there are a couple of steps needed to enable SSH, but let's get to it!
|
||||
|
||||
1. Log into `rtr01` from the console or with the `admin` account and telnet.
|
||||
1. From "Privileged EXEC mode" (enable mode) and NOT "Configuration Mode", create an RSA key-pair.
|
||||
|
||||
> Note: If you enter this command from `config` mode, you'll get an error message about deprecation of the command. Keys should now be generated from "enable mode".
|
||||
|
||||
```
|
||||
crypto key generate rsa general-keys modulus 2048
|
||||
|
||||
# Output
|
||||
The name for the keys will be: rtr01.example.com
|
||||
|
||||
% The key modulus size is 2048 bits
|
||||
|
||||
% Generating crypto RSA keys in background ...
|
||||
```
|
||||
|
||||
* `rsa` is the type of key we are generating `ec` is an alternative key generation mechanism, but it won't work for SSH.
|
||||
* `general-keys` means we are creating a single key that can be used by the router for both signing and encryption.
|
||||
* `modulus 2048` indicates we are creating a `2048` bit key. The more bits, the more secure. `2048` is generally considered secure today, however some organizations opt for larger bit sizes for more security.
|
||||
|
||||
|
||||
1. If you are on the console, or watching the console output, you'll also see this output.
|
||||
|
||||
```
|
||||
*Mar 9 14:08:48.049: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named rtr01.example.com has been generated or imported by crypto-engine
|
||||
*Mar 9 14:08:48.050: %SSH-5-ENABLED: SSH 2.0 has been enabled
|
||||
*Mar 9 14:08:48.732: %CRYPTO_ENGINE-5-KEY_ADDITION: A key named rtr01.example.com.server has been generated or imported by crypto-engine
|
||||
```
|
||||
|
||||
> Note: The "name" of the RSA key is in the format of `<HOSTNAME>.<DOMAIN NAME>`. This means that if you have NOT configured either of these on your network device, you will get an error message. The initial configuration for this lab included both `hostname <HOSTNAME>` and `ip domain name <DOMAIN NAME>` configuration.
|
||||
|
||||
* In the console log message, notice the `SSH-5-ENABLED` message. SSH is typically already setup to be "enabled" on an IOS device, but in order for it to work there needs to be a "key" that can be used to encrypt the traffic. As soon as you create the key, the device will enable SSH.
|
||||
* `SSH 2.0` is enabled. The version `2.0` is significant because earlier versions of SSH are insecure today and shouldn't be used. Some network devices may default to an earlier version and should be explicitly configured for `ip ssh version 2`. Newer devices likely only support version 2.
|
||||
|
||||
1. Go ahead and try to connect to `rtr01` with SSH from `netadmin`.
|
||||
|
||||
```
|
||||
ssh admin@rtr01
|
||||
|
||||
# Output
|
||||
ssh: connect to host rtr01 port 22: Connection refused
|
||||
```
|
||||
|
||||
* Why didn't it work? We say that SSH was enabled already?
|
||||
|
||||
<details><summary>Answer:</summary>
|
||||
The reason is because while SSH is indeed "enabled" on the router, we need to update the configuration for the VTY lines to allow SSH "input". Remember that we configured `transport input telnet`.</details>
|
||||
|
||||
1. Update the configuration of the VTY lines to support SSH.
|
||||
|
||||
```
|
||||
line vty 0 4
|
||||
transport input ssh
|
||||
```
|
||||
|
||||
> Note: You could enable both telnet and ssh at the same time with `transport input telnet ssh`, and if you are making this change remotely without console access to the router, that is recommended. But once you've verified that SSH is working, don't forget to remove it as a supported input protocol or you are still vulnerable.
|
||||
|
||||
1. Now try to log into `rtr01` with SSH again.
|
||||
|
||||
```
|
||||
ssh admin@rtr01
|
||||
|
||||
# Output
|
||||
The authenticity of host 'rtr01 (10.0.0.1)' can't be established.
|
||||
RSA key fingerprint is SHA256:uKLBCGaK0AWdqR6NOVbvSFjB6Mc0GMiRGH7xcI7+X0w.
|
||||
This key is not known by any other names
|
||||
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
|
||||
Warning: Permanently added 'rtr01' (RSA) to the list of known hosts.
|
||||
(admin@rtr01) Password:
|
||||
|
||||
|
||||
rtr01#
|
||||
```
|
||||
|
||||
* You will first be asked if you want to trust the fingerprint for the SSH key. The best practice for security would be to check the shown fingerprint against the known fingerprint for the device you are connecting to. Unfortunately, there isn't an easy way to find the fingerprint for an SSH key for an IOS device, and calculating it is out of scope for this lab or the CCNA. So just type "yes" at the prompt.
|
||||
* Once you connect the first time to a router, your computer will store the fingerprint and verify it on future connections to the router. If the fingerprint changes, you'll be warned something is different. This could indicate a security problem, ***OR*** it could indicate that key changed on the device. A key change can happen if a device is replaced or upgraded. The key can also change if an administrator manually changes it.
|
||||
* Provide the password for the `admin` user and log in.
|
||||
1. Disconnect with SSH and try to log in with telnet. This should fail.
|
||||
|
||||
### Verifying Encryption
|
||||
Setup a new packet capture between `netadmin` and `sw01`, but use the filter `tcp port 22` for SSH traffic. With it running, log back into `rtr01` with SSH. Then checkout the packets captured. You'll see many packets setting up the secure communications, and then "Encrypted packets" being sent. If you look at those you'll find that you can NOT read the messages being sent between the devices.
|
||||
|
||||
### Configuring SSH on `sw01`
|
||||
Now go ahead and configure `sw01` for SSH with the same approach we used on `rtr01`.
|
||||
|
||||
1. Create a new RSA key
|
||||
1. Change the VTY transport method to only support SSH
|
||||
|
||||
## SSH from anywhere... even the Internet?
|
||||
So far we've been testing SSH access from our "trusted host", `netadmin`. But can we also access the router from "the Internet"
|
||||
|
||||
1. Find the "public IP" for `rtr01`. This will be the IP address on interface 'E0/0'.
|
||||
|
||||
```
|
||||
show ip int brief
|
||||
|
||||
# Output
|
||||
Interface IP-Address OK? Method Status Protocol
|
||||
Ethernet0/0 192.168.255.196 YES DHCP up up
|
||||
Ethernet0/1 192.168.0.1 YES TFTP up up
|
||||
Ethernet0/2 unassigned YES TFTP administratively down down
|
||||
Ethernet0/3 unassigned YES TFTP administratively down down
|
||||
Loopback0 10.0.0.1 YES TFTP up up
|
||||
```
|
||||
|
||||
> ***Note:*** The IP address assigned to YOUR `Ethernet0/0` interface will mostly likely differ from the above output. This is because the IP address is assigned with DHCP from the CML server itself. Make note of YOUR address for the next command.
|
||||
|
||||
1. Open up the console for `outside-host` and try to SSH into the router using the "public IP".
|
||||
|
||||
* ***Remember to use the IP address from YOUR output in the below command.***
|
||||
|
||||
```
|
||||
ssh admin@<YOUR E0/0 IP address>
|
||||
```
|
||||
|
||||
1. After answering "yes" to accept the fingerprint, this should work just like from `netadmin`. This is because the VTY lines are "available" from all router Interfaces. Even more reason to use SSH instead of a clear text protocol like telnet.
|
||||
|
||||
1. Now that you are connected, checkout the output from a couple of handy `show commands`.
|
||||
|
||||
```
|
||||
show ssh
|
||||
show users
|
||||
show crypto key mypubkey rsa
|
||||
```
|
||||
|
||||
## Great Job!
|
||||
Excellent work on this lab! You've successfully enabled SSH on your network devices and seen why it is a much better choice than Telnet. This is by no means the end to device administration. Here are some other topics to look into.
|
||||
|
||||
1. How can you limit management access to a network device? Maybe you do NOT want the Internet to be able to log into your router - even if it is secure?
|
||||
1. How do TACACS+ and RADIUS fit into device administration? How would they be configured?
|
||||
title: CCNA Prep 2025 S2E4 Telnet to SSH
|
||||
version: 0.2.2
|
5
lab-topologies/ccna-prep/s2e4/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Securing Network Access: From Telnet to SSH
|
||||
|
||||
*Abstract:* Discover why SSH is the preferred choice over Telnet for secure network management in this insightful event. Through hands-on activities, master the ins and outs to configuring SSH on Cisco switches and routers, ensuring encrypted and authenticated remote access. Understand the security implications of using SSH, and elevate your skills in managing network devices securely and efficiently. Join us as you prepare for your CCNA exam.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e4/s2e4-ssh.jpg
Normal file
After Width: | Height: | Size: 100 KiB |
BIN
lab-topologies/ccna-prep/s2e5/CCNA Prep S02 E05 Lab Guide.pdf
Normal file
@@ -0,0 +1,709 @@
|
||||
annotations:
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'CCNA Exam Prep: Back to Networking Basics with Hank Preston and
|
||||
Patrick Gargano'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: -80.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'Syncing Success: The Role of NTP in Network Operations'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 18
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: -40.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
NTP is how IT systems can "synchronize their watches". These IT systems can be network devices
|
||||
like switches and routers, end user computers and mobile devices, and servers hosting the
|
||||
critical applications we rely on. The "systems" also include the unimaginable number of IOT
|
||||
devices that exist around us in cars, planes, trains, ships, manufacturing plants, and so on.
|
||||
So yeah, NTP is a foundational protocol that is often overlooked, until something goes wrong
|
||||
with it...
|
||||
|
||||
In this lab you will NTP with some hands on exercises focused on:
|
||||
|
||||
* Asking a router and switch "what time is it?" and manually setting the time.
|
||||
* Configuring the NTP client in IOS to synchronize the clock with an NTP server.
|
||||
* Configuring the NTP server in IOS to act as a time source for other clients
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 0.0
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |2-
|
||||
|
||||
host user/pass: cisco / cisco
|
||||
network enable password: enablepass
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'Credentials:
|
||||
|
||||
'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: ____________
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#7FF0FA'
|
||||
thickness: 2
|
||||
type: rectangle
|
||||
x1: -483.21004499370474
|
||||
y1: 310.36986501888595
|
||||
x2: 763.2100449937047
|
||||
y2: 260.47255474961986
|
||||
z_index: 0
|
||||
nodes:
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: internet
|
||||
node_definition: external_connector
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 240
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname rtr01
|
||||
!
|
||||
! In order to avoid entering a configuration dialog
|
||||
! on boot, please ensure that all ethernet interfaces
|
||||
! have some ip configuration present here such as the
|
||||
! example below:
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
ip host rtr01.example.com 10.0.0.1
|
||||
ip host sw01.example.com 192.168.0.2
|
||||
ip host ntpserver.example.com 192.168.100.100
|
||||
ip name-server 192.168.255.1
|
||||
ip domain name example.com
|
||||
ip dns server
|
||||
ip dns primary example.com soa 192.168.0.1 admin@example.com 21600 900 7776000 86400
|
||||
!
|
||||
ip dhcp excluded-address 192.168.0.1 192.168.0.10
|
||||
ip dhcp pool inside
|
||||
network 192.168.0.0 /24
|
||||
default-router 192.168.0.1
|
||||
dns-server 10.0.0.1
|
||||
domain-name example.com
|
||||
exit
|
||||
!
|
||||
ip access-list standard NAT
|
||||
permit 192.168.0.0 0.0.0.255
|
||||
permit 192.168.100.0 0.0.0.255
|
||||
!
|
||||
ip nat inside source list NAT interface e0/0 overload
|
||||
!
|
||||
interface e0/1
|
||||
description Link to Inside Hosts
|
||||
ip address 192.168.0.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
interface e0/0
|
||||
description Link to Internet
|
||||
ip address dhcp
|
||||
ip nat outside
|
||||
no shut
|
||||
!
|
||||
interface e0/2
|
||||
description Link to Lab NTP Server
|
||||
ip address 192.168.100.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
interface loopback0
|
||||
ip address 10.0.0.1 255.255.255.255
|
||||
!
|
||||
line vty 0 4
|
||||
no login
|
||||
transport input none
|
||||
!
|
||||
do clock set 00:00:00 01 Jan 1993
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: null
|
||||
label: rtr01
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 0
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname sw01
|
||||
ip domain name example.com
|
||||
!
|
||||
vtp version 2
|
||||
vtp mode transparent
|
||||
!
|
||||
vlan 10
|
||||
name inside-network
|
||||
!
|
||||
interface e0/0
|
||||
description Link to rtr01
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface e0/1
|
||||
description Link to netadmin
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface vlan 10
|
||||
description Switch Management Interface
|
||||
ip address 192.168.0.2 255.255.255.0
|
||||
no shutdown
|
||||
!
|
||||
ip route 0.0.0.0 0.0.0.0 192.168.0.1
|
||||
ip name-server 10.0.0.1
|
||||
!
|
||||
line vty 0 4
|
||||
no login
|
||||
transport input none
|
||||
!
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: sw01
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -200
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname netadmin
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: netadmin
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -440
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname ntpserver
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
# Static IP address
|
||||
ip address add 192.168.100.100/24 dev eth0
|
||||
ip route add default via 192.168.100.1
|
||||
# NTP Server Setup
|
||||
echo 'NTPD_OPTS="-l -N"' > /etc/conf.d/ntpd
|
||||
service ntpd start
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: ntpserver
|
||||
node_definition: alpine
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 0
|
||||
y: 520
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n2
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: sw01-Ethernet0/0<->rtr01-Ethernet0/1
|
||||
- id: l1
|
||||
n1: n3
|
||||
n2: n2
|
||||
i1: i0
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: netadmin-eth0<->sw01-Ethernet0/1
|
||||
- id: l2
|
||||
n1: n4
|
||||
n2: n1
|
||||
i1: i0
|
||||
i2: i3
|
||||
conditioning: {}
|
||||
label: outside-host-eth0<->rtr01-Ethernet0/2
|
||||
- id: l3
|
||||
n1: n1
|
||||
n2: n0
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: rtr01-Ethernet0/0<->internet-port
|
||||
lab:
|
||||
description: Delve into the importance of Network Time Protocol (NTP) in maintaining
|
||||
synchronized time across network devices. In this session, review the steps to
|
||||
configure NTP for both client and server modes. Discover why synchronized time
|
||||
is crucial for accurate event logging, seamless coordination of network operations,
|
||||
and effective security measures. Master this important topic in “time” to take
|
||||
your exam.
|
||||
notes: |-
|
||||
**CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano**
|
||||
|
||||
# Syncing Success: The Role of NTP in Network Operations
|
||||
|
||||
> Delve into the importance of Network Time Protocol (NTP) in maintaining synchronized time across network devices. In this session, review the steps to configure NTP for both client and server modes. Discover why synchronized time is crucial for accurate event logging, seamless coordination of network operations, and effective security measures. Master this important topic in “time” to take your exam.
|
||||
|
||||
Time and the passage of time is inescapble in life and network engineering. There are many "time" related topics that come up while you study for your CCNA. There is latency, how long it takes takes for a data packet to move from the source to destination. And jitter, how much variation in that time between different packets.
|
||||
|
||||
In this lab we are going to explore NTP, or Network Time Protocol. NTP is how IT systems can "synchronize their watches". These IT systems can be network devices like switches and routers, end user computers and mobile devices, and servers hosting the critical applications we rely on. The "systems" also include the unimaginable number of IOT devices that exist around us in cars, planes, trains, ships, manufacturing plants, and so on. So yeah, NTP is a foundational protocol that is often overlooked, until something goes wrong with it...
|
||||
|
||||
In this lab you will NTP with some hands on exercises focused on:
|
||||
|
||||
* Asking a router and switch "what time is it?" and manually setting the time.
|
||||
* Configuring the NTP client in IOS to synchronize the clock with a known good source - an NTP server.
|
||||
* Configuring the NTP server in IOS to act as a time source for other clients
|
||||
|
||||
> This lab touches on the following topic from the [CCNA v1.1 Topics List](https://learningcontent.cisco.com/documents/marketing/exam-topics/200-301-CCNA-v1.1.pdf)
|
||||
> 4.2 Configure and verify NTP operating in a client and server mode
|
||||
|
||||
## Setup and Scenario
|
||||
This setup of lab based demonstrations includes a small network made up of an IOS based switch and router, that provides internet access to a `netadmin` host. The network is preconfigured to provide connectivity to the Internet for the `netadmin` host with DHCP, DNS, and NAT services provided by `rtr01`. `sw01` is configured with a management IP address, and there are DNS entries for both network devices configured to allow `netadmin` to reach the devices by name.
|
||||
|
||||
*Be sure to **START** the lab before continuing to the demo labs.*
|
||||
|
||||
```
|
||||
netadmin:~$ ping -c 2 sw01
|
||||
|
||||
PING sw01 (192.168.0.2): 56 data bytes
|
||||
64 bytes from 192.168.0.2: seq=0 ttl=42 time=0.975 ms
|
||||
64 bytes from 192.168.0.2: seq=1 ttl=42 time=1.418 ms
|
||||
|
||||
netadmin:~$ ping -c 2 rtr01
|
||||
|
||||
PING rtr01 (10.0.0.1): 56 data bytes
|
||||
64 bytes from 10.0.0.1: seq=0 ttl=42 time=1.447 ms
|
||||
64 bytes from 10.0.0.1: seq=1 ttl=42 time=1.125 ms
|
||||
```
|
||||
|
||||
Go ahead and open the console for the `netadmin` host and try out the above pings yourself. "Pinging" is fun :-)!!
|
||||
|
||||
> Note: The credentials for `netadmin` are `cisco / cisco`.
|
||||
|
||||
|
||||
## Finding an available NTP server
|
||||
Before we dive into this lab and explore configuring NTP to keep network time in sync, we need to find an available NTP server that is reachable from our lab. There are many publicly available NTP providers that can be freely leveraged by anyone around the world. Two sources for time provided by reliable clusters of NTP servers are [NIST (National Institute of Standards and Technology)](https://tf.nist.gov/tf-cgi/servers.cgi) and [pool.ntp.org](https://www.ntppool.org/en/).
|
||||
|
||||
The NTP server addresses for these sources are:
|
||||
|
||||
* NIST - `time.nist.gov`
|
||||
* NTP Pool - `pool.ntp.org`
|
||||
|
||||
If you are running this lab from a CML server in your home lab, or a cloud provider, you should be able to leverage either of these NTP server addresses.
|
||||
|
||||
While these sources are trusted worldwide, some companies block access to these public NTP servers from within private networks and opt to provide their own NTP servers for internal systems. This means that if you are running this lab on a CML server that is hosted on a network that blocks access to public NTP servers, you'll need to check with the IT team to find the address for a reachable NTP server to query.
|
||||
|
||||
To test to see if the public servers are reachable, follow these steps.
|
||||
|
||||
1. Open the console to `netadmin` and login.
|
||||
1. Use the `ntpd` service to query the public servers.
|
||||
|
||||
```
|
||||
ntpd -dw -p pool.ntp.org -p time.nist.gov
|
||||
```
|
||||
|
||||
> Note: End the `ntpd` query by pressing `Cntrl-C` (`^C`).
|
||||
|
||||
1. If you see output that looks like the below, these public servers are NOT available for you to leverage for this lab.
|
||||
|
||||
```
|
||||
ntpd: 'pool.ntp.org' is 104.234.67.234
|
||||
ntpd: 'time.nist.gov' is 132.163.97.4
|
||||
ntpd: sending query to 132.163.97.4
|
||||
ntpd: sending query to 104.234.67.234
|
||||
ntpd: timed out waiting for 132.163.97.4, reach 0x00, next query in 1s
|
||||
ntpd: 'time.nist.gov' is 132.163.97.4
|
||||
ntpd: timed out waiting for 104.234.67.234, reach 0x00, next query in 1s
|
||||
```
|
||||
|
||||
1. See if you can find an available NTP server for your lab environment. For example, suppose you are told an NTP server is available at `10.1.1.1`. Let's test that address.
|
||||
|
||||
```
|
||||
ntpd -dw -p 10.1.1.1
|
||||
|
||||
# Output
|
||||
ntpd: sending query to 10.1.1.1
|
||||
ntpd: reply from 10.1.1.1: offset:+36.082774 delay:0.002821 status:0x24 strat:3 refid:0x05f1c00a rootdelay:0.001083 reach:0x01
|
||||
```
|
||||
|
||||
* This output shows a reachable NTP server. Don't worry about the details of the output just now.
|
||||
|
||||
1. What should you do if the public servers aren't reachable AND you can't find information on an available server? Never fear! We have included an NTP server in the lab that can be used. It might not have exact accurate time, but it will work for the lab. This NTP server is available at `ntpserver.example.com`.
|
||||
|
||||
```
|
||||
ntpd -dw -p ntpserver.example.com
|
||||
|
||||
# Output
|
||||
ntpd: 'ntpserver.example.com' is 192.168.100.100
|
||||
ntpd: sending query to 192.168.100.100
|
||||
ntpd: reply from 192.168.100.100: offset:-0.191950 delay:0.002921 status:0x24 strat:1 refid:0x00000000 rootdelay:0.000000 reach:0x01
|
||||
```
|
||||
|
||||
## Checking the current date/time on the router
|
||||
So NTP can be used to set the time on network devices, but how do you check what the current clock is set to on an IOS router or switch?
|
||||
|
||||
1. Open up the console to `rtr01`, and enter enable mode.
|
||||
1. Run the command `show clock` to check the current time on the router.
|
||||
|
||||
```
|
||||
show clock
|
||||
|
||||
# Output
|
||||
00:11:51.832 UTC Fri Jan 1 1993
|
||||
```
|
||||
|
||||
1. Well.. unless you've gone back in time to the early nineties, the time displayed by the router probably doesn't look close to accurate.
|
||||
1. Let's go ahead and "fix" the time manually. Check the current time on your computer and use the following command to correct the time.
|
||||
|
||||
> ***Note: The timezone setting on the router is UTC, be sure to convert your local time to UTC before setting the time in this step.***
|
||||
|
||||
```
|
||||
clock set 19:49:00 23 March 2025
|
||||
|
||||
! Command Format
|
||||
clock set <MM:HH:SS> <1-31> <MONTH> <YEAR>
|
||||
|
||||
# Output
|
||||
Mar 23 19:49:00.000: %SYS-6-CLOCKUPDATE: System clock has been updated from 00:00:46 UTC Fri Jan 1 1993 to 19:49:00 UTC Sun Mar 23 2025, configured from console by console.
|
||||
```
|
||||
|
||||
1. Verify the time was updated correctly with `show clock`.
|
||||
|
||||
Excellent job! The clock on the router is right and we can all go out for some dinner and watch a movie right?
|
||||
|
||||
## Configuring NTP client to maintain time sync
|
||||
Unfortunately dinner and the movie is going to have to wait. It is just a fact of modern computing that computers eventually experience a time drift. Typically they drift slower over time. There are many contributing factors to time loss for computers, but it does happen. A little bit every day. And even if computers did NOT lose time, there is another reason why configuring NTP to maintain sync is important. How accurate were you when you configured the manual time in the previous step? Were you accurate to the second? To the millesecond? Accurate time for computers is important for a lot of applications.
|
||||
|
||||
So now that I've convinced you that we need a little help to keep our router's clock accurate, let us finally dive into NTP and use it to keep our router in sync.
|
||||
|
||||
> In the following steps, use the best NTP server for your particular lab environment. If a public NTP server is reachable, use that. If you have a private NTP server address that works, leverage that one. And if neither the public or private NTP servers are an option, then you can use `ntpserver.example.com`.
|
||||
|
||||
1. Back on the console for `rtr01` check the current status of NTP with the following commands.
|
||||
|
||||
```
|
||||
show ntp status
|
||||
|
||||
# Output
|
||||
%NTP is not enabled.
|
||||
```
|
||||
|
||||
```
|
||||
show ntp associations
|
||||
|
||||
# No output
|
||||
```
|
||||
|
||||
> Okay, NTP is not running.
|
||||
|
||||
1. Now enter configuration mode and configure the `ntp server` for your router.
|
||||
|
||||
```
|
||||
ntp server ntpserver.example.com
|
||||
```
|
||||
|
||||
1. Return to enable mode and check the status of NTP.
|
||||
|
||||
```
|
||||
show ntp status
|
||||
|
||||
# Example Output
|
||||
Clock is unsynchronized, stratum 2, reference is 192.168.100.100
|
||||
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
|
||||
ntp uptime is 74900 (1/100 of seconds), resolution is 4000
|
||||
reference time is EB8AE8C3.CC49BC90 (20:08:35.798 UTC Sun Mar 23 2025)
|
||||
clock offset is 18494.9973 msec, root delay is 1.95 msec
|
||||
root dispersion is 18499.91 msec, peer dispersion is 3.88 msec
|
||||
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
|
||||
system poll interval is 64, last update was 5 sec ago.
|
||||
```
|
||||
|
||||
* There is a lot of detail in the output above, much of it beyond the scope for the CCNA candidate.
|
||||
* The first line indicates that the router is currently `unsynchronized` with the server (ie `reference`)
|
||||
* `clock offset is 18494.9973 msec` indicates that there is an 18 second difference between the router's clock and the server. In this case our router is 18 seconds behind. If it was ahead, the value would be negative. This "offset" is why we are currently `unsynchronized`
|
||||
|
||||
1. NTP does NOT make large changes to a systems time, this could be disruptive to services. Rather it makes small adjustment with the goal being to bring the client into sync overtime. This process can take several minutes to hours depending on network conditions and the amount of offset involved.
|
||||
* You can speed up the process of synchronization by manually updating a devices clock to be closer to the NTP server.
|
||||
|
||||
1. Another handy show command is `show ntp associations`.
|
||||
|
||||
```
|
||||
show ntp associations
|
||||
|
||||
# Output
|
||||
address ref clock st when poll reach delay offset disp
|
||||
*~192.168.100.100 . 1 65 64 1 0.945 18495.1 7938.9
|
||||
* sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured
|
||||
```
|
||||
|
||||
* The output from this command will show the NTP status in a table format. Key details to note are:
|
||||
* The `*` indicating the currently selected reference clock
|
||||
* The `~` indicating that this is a "configured" server. Which most of your NTP servers will be.
|
||||
* The `offset` to indicate how far apart the client and server are from a time perspective
|
||||
|
||||
While NTP brings this router into sync with the server, we'll move onto enable the router to act as an NTP server for other network clients.
|
||||
|
||||
## Enabling an IOS router to act as an NTP server
|
||||
Now that we've got our edge router setup to keep its own clock in sync with a trusted NTP server, we want to set it up to provide time to other network devices. You might wonder, why not just have each and every device ask the same trusted server? Well, there are a few different reasons...
|
||||
|
||||
* Efficient use of bandwidth. NTP isn't a big drain on network resources, but even small packets add up if you have hundreds or thousands of devices asking "what time is it" every minute. So having a "local" NTP server for other devices to query for time is a great solution for effeciency.
|
||||
* What happens if the public server can't be reached, or needs to be changed? It's much easier to have just a single device to update than every device on the network
|
||||
* Distributing the load on the NTP servers themselves. NTP is designed to be setup in a distributed "tree" hierarchy. Where the initial reference time source is passed from tier to tier of NTP servers and eventually to clients. Distributing the load like this is better for the network overall
|
||||
|
||||
Speaking of the "tiers" of NTP servers, NTP has the concept of the "stratum" of the NTP server. Stratum is an integer from 1 - 15 that indicates how close to the reference clock this particular source is. A stratum of `1` is the base reference. A stratum of `2` is a server that directly learned the time from the `stratum 1` server. NTP clients can be configured with multiple NTP servers for redundancy. The client will prefer a lower stratum source over a higher stratum source.
|
||||
|
||||
Now that we've got some background information laid out, let's get the configuring!
|
||||
|
||||
1. Open the console for `rtr01` and enter configuration mode.
|
||||
1. Enable the router to act as an NTP server with a stratum of 5 with this command.
|
||||
|
||||
```
|
||||
ntp master 5
|
||||
```
|
||||
|
||||
1. Let's test that the NTP server is working, open the console for `netadmin` and send an NTP query to the router.
|
||||
|
||||
```
|
||||
ntpd -dw -p rtr01
|
||||
```
|
||||
|
||||
* The goal is that you'll get output that looks like this where we get a good reply from the server.
|
||||
|
||||
```
|
||||
ntpd: reply from 10.0.0.1: offset:-18.652104 delay:0.001246 status:0x24 strat:5 refid:0x01017f7f rootdelay:0.000000 reach:0x01
|
||||
```
|
||||
|
||||
* If you get output that looks like this that indicates the "peer is unsynced", this is an indication that `rtr01` hasn't fully synchronized it's own time with its configured NTP server.
|
||||
|
||||
```
|
||||
ntpd: reply from 10.0.0.1: peer is unsynced
|
||||
```
|
||||
|
||||
* If you are seeing the above in your test, remove the configured NTP server on `rtr01` and repeat the query.
|
||||
|
||||
```
|
||||
no ntp server ntpserver.example.com
|
||||
```
|
||||
|
||||
> In a "real network", the best solution would be to wait for the router to complete its synchronization. But with virtualized and simulated network devices like in this lab, the added overhead of simulation might prevent NTP from getting "fully healthy" and synchronized.
|
||||
|
||||
Once you've got a healthy result from the `ntpd` query test, your new NTP server is ready to go!
|
||||
|
||||
## Using NTP to synchronize `sw01` from `rtr01`
|
||||
We've setup the site router to act as an NTP server, let's use it to keep the switch's clock accurate!
|
||||
|
||||
1. Opening the console for `sw01` and check the current time. If it is "close" to the accurate time you can leave it alone. If it is wildly different from accurate, go ahead and manually fix it.
|
||||
1. Now configure the switch to use `rtr01` as its NTP server. You can use the IP address for the router, or the DNS name.
|
||||
|
||||
```
|
||||
ntp server rtr01.example.com
|
||||
```
|
||||
|
||||
1. Give it a few seconds for the initial NTP query to be sent and processed and check the status.
|
||||
|
||||
```
|
||||
show ntp status
|
||||
|
||||
# Output
|
||||
Clock is unsynchronized, stratum 6, reference is 10.0.0.1
|
||||
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
|
||||
ntp uptime is 2900 (1/100 of seconds), resolution is 4000
|
||||
reference time is EB8C338C.B3B64790 (19:39:56.702 UTC Mon Mar 24 2025)
|
||||
clock offset is -18902.4981 msec, root delay is 1.00 msec
|
||||
root dispersion is 19097.90 msec, peer dispersion is 189.44 msec
|
||||
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
|
||||
system poll interval is 64, last update was 15 sec ago.
|
||||
```
|
||||
|
||||
* Although the clock is indicated as unsynchronized, the synchronization process has started.
|
||||
* The switch reports a `stratum 6` with a reference of `10.0.0.1`. `10.0.0.1` is `rtr01`, and remember we configured it for `stratum 5`. The switch adds `1` to the stratrum value for its own clock.
|
||||
* Check the current clock offset for your network, how off is your time?
|
||||
|
||||
|
||||
If you'd like to see the network get "in-sync", give it some time and check the status. You should see the offset shrink until it disappears and the status goes to `Clock is synchronized`. For example:
|
||||
|
||||
```
|
||||
sw01#show ntp status
|
||||
Clock is synchronized, stratum 6, reference is 10.0.0.1
|
||||
nominal freq is 250.0000 Hz, actual freq is 250.1250 Hz, precision is 2**10
|
||||
ntp uptime is 249000 (1/100 of seconds), resolution is 4000
|
||||
reference time is EB8C3EB1.3541469D (20:27:29.208 UTC Mon Mar 24 2025)
|
||||
clock offset is -91.5236 msec, root delay is 1.00 msec
|
||||
root dispersion is 200.51 msec, peer dispersion is 64.49 msec
|
||||
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is -0.000499999 s/s
|
||||
system poll interval is 64, last update was 49 sec ago.
|
||||
```
|
||||
|
||||
## Great Job!
|
||||
That's all there is to the basic setup for NTP on network devices. It isn't a complicated protocol, but it is an important one.
|
||||
|
||||
As with many topics in networking, there are more topic areas you could explore. Accurate time is very important in network operations, and one way to disrupt a network is to inject incorrect time from unauthorized NTP servers. NTP supports authentication between servers and clients to make sure only "trusted" servers are used.
|
||||
|
||||
So for now, have a great ***time*** in your CCNA preparation studies!
|
||||
title: CCNA Prep 2025 S2E5 NTP Basics
|
||||
version: 0.2.2
|
5
lab-topologies/ccna-prep/s2e5/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Syncing Success: The Role of NTP in Network Operations
|
||||
|
||||
*Abstract:* Delve into the importance of Network Time Protocol (NTP) in maintaining synchronized time across network devices. In this session, review the steps to configure NTP for both client and server modes. Discover why synchronized time is crucial for accurate event logging, seamless coordination of network operations, and effective security measures. Master this important topic in “time” to take your exam.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e5/s2e5-ntp.jpg
Normal file
After Width: | Height: | Size: 121 KiB |
1094
lab-topologies/ccna-prep/s2e6/CCNA_Prep_2025_S2E6_Syslog.yaml
Normal file
BIN
lab-topologies/ccna-prep/s2e6/CCNA_Prep_S02E06_Syslog_Guide.pdf
Normal file
5
lab-topologies/ccna-prep/s2e6/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# The Syslog Detective: Unraveling Network Mysteries
|
||||
|
||||
*Abstract:* Step into the shoes of a network detective in this engaging live event, where Syslog serves as your investigative tool. Learn how to configure Syslog to capture and analyze crucial network events, uncovering the hidden clues within your infrastructure. Through hands-on exercises, we’ll master syslog’s role in solving network mysteries by piecing together performance insights, troubleshooting issues, and enhancing security monitoring. Join us to become a Syslog sleuth and complete your CCNA Preparation.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e6/s2e6-syslog.jpg
Normal file
After Width: | Height: | Size: 72 KiB |
934
lab-topologies/ccna-prep/s2e7/CCNA_Prep_2025_S2E7_SNMP.yaml
Normal file
@@ -0,0 +1,934 @@
|
||||
annotations:
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'CCNA Exam Prep: Back to Networking Basics with Hank Preston and
|
||||
Patrick Gargano'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -471.6817382409052
|
||||
y1: -26.525460120105087
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'Simplifying SNMP: Delivering Data for Network Operation Dashboards'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 18
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -478.8116768915578
|
||||
y1: 17.039509205221208
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
CCNA 1.1 Exam Topic
|
||||
4.4 Explain the function of SNMP in network operations
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -483.68829366711856
|
||||
y1: 211.52777439162983
|
||||
z_index: 2
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |2-
|
||||
|
||||
host user/pass: cisco / cisco
|
||||
network enable password: enablepass
|
||||
telnet password: telnetpass
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: 'Credentials:
|
||||
|
||||
'
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: ____________
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 10
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -480.0
|
||||
y1: 440.0
|
||||
z_index: 3
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#7FF0FA'
|
||||
thickness: 2
|
||||
type: rectangle
|
||||
x1: -483.21004499370474
|
||||
y1: 310.36986501888595
|
||||
x2: 763.2100449937047
|
||||
y2: 260.47255474961986
|
||||
z_index: 0
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
Network Monitoring is critical to security and troubleshooting tasks. As your network grows and evolves,
|
||||
centralized monitoring becomes even more important. SNMP is a protocol that allows you to remotely monitor
|
||||
a wide range of settings and counters, be alerted when there are changes, and even remotely make configuration changes.
|
||||
|
||||
In this lab you will explore how SNMP works and how to configure and verify SNMP on Cisco devices.
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -481.93824659111294
|
||||
y1: 62.64675567294343
|
||||
z_index: 4
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#808080FF'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: ''
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 400.19267871188174
|
||||
y1: 190.55284132635407
|
||||
z_index: 6
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: false
|
||||
text_content: |-
|
||||
Concepts:
|
||||
- SNMP Manager or NMS
|
||||
- SNMP Agent
|
||||
- MIB and OID
|
||||
- SNMP Set, Get, Trap, Inform
|
||||
- SNMP versions
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 337.4106520219703
|
||||
y1: 316.30633613768475
|
||||
z_index: 7
|
||||
nodes:
|
||||
- boot_disk_size: null
|
||||
configuration: []
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: internet
|
||||
node_definition: external_connector
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 240
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: port
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname rtr01
|
||||
!
|
||||
! In order to avoid entering a configuration dialog
|
||||
! on boot, please ensure that all ethernet interfaces
|
||||
! have some ip configuration present here such as the
|
||||
! example below:
|
||||
!
|
||||
interface range Ethernet 0/0 - 3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
ip host rtr01.example.com 10.0.0.1
|
||||
ip host sw01.example.com 192.168.0.2
|
||||
ip host ntpserver.example.com 192.168.100.100
|
||||
ip name-server 192.168.255.1
|
||||
ip domain name example.com
|
||||
ip dns server
|
||||
ip dns primary example.com soa 192.168.0.1 admin@example.com 21600 900 7776000 86400
|
||||
ntp server 192.168.100.100
|
||||
!
|
||||
ip dhcp excluded-address 192.168.0.1 192.168.0.10
|
||||
ip dhcp pool inside
|
||||
network 192.168.0.0 /24
|
||||
default-router 192.168.0.1
|
||||
dns-server 10.0.0.1
|
||||
domain-name example.com
|
||||
exit
|
||||
!
|
||||
ip access-list standard NAT
|
||||
permit 192.168.0.0 0.0.0.255
|
||||
permit 192.168.100.0 0.0.0.255
|
||||
!
|
||||
ip nat inside source list NAT interface e0/0 overload
|
||||
!
|
||||
interface e0/1
|
||||
description Link to Inside Hosts
|
||||
ip address 192.168.0.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
interface e0/0
|
||||
description Link to Internet
|
||||
ip address dhcp
|
||||
ip nat outside
|
||||
no shut
|
||||
!
|
||||
interface e0/2
|
||||
description Link to Lab NTP Server
|
||||
ip address 192.168.100.1 255.255.255.0
|
||||
ip nat inside
|
||||
no shut
|
||||
!
|
||||
interface loopback0
|
||||
ip address 10.0.0.1 255.255.255.255
|
||||
!
|
||||
enable secret enablepass
|
||||
!
|
||||
line vty 0 4
|
||||
transport input telnet
|
||||
login
|
||||
password telnetpass
|
||||
!
|
||||
do clock set 00:00:00 01 Jan 1993
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: null
|
||||
label: rtr01
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 0
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
hostname sw01
|
||||
ip domain name example.com
|
||||
!
|
||||
vtp version 2
|
||||
vtp mode transparent
|
||||
!
|
||||
vlan 10
|
||||
name inside-network
|
||||
!
|
||||
interface e0/0
|
||||
description Link to rtr01
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface e0/1
|
||||
description Link to netadmin
|
||||
switchport mode access
|
||||
spanning-tree portfast
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface loopback0
|
||||
ip address 1.1.1.1 255.255.255.255
|
||||
!
|
||||
interface vlan 10
|
||||
description Switch Management Interface
|
||||
ip address 192.168.0.2 255.255.255.0
|
||||
no shutdown
|
||||
!
|
||||
ip route 0.0.0.0 0.0.0.0 192.168.0.1
|
||||
ip name-server 10.0.0.1
|
||||
!
|
||||
line vty 0 4
|
||||
no login
|
||||
transport input none
|
||||
!
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: sw01
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -200
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname netadmin
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: netadmin
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -440
|
||||
y: 360
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname snmp_nms
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
# Static IP address
|
||||
ip address add 192.168.100.100/24 dev eth0
|
||||
ip route add default via 192.168.100.1
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: SNMP-NMS
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: -1
|
||||
y: 500
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
slot: 0
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n2
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: sw01-Ethernet0/0<->rtr01-Ethernet0/1
|
||||
- id: l1
|
||||
n1: n3
|
||||
n2: n2
|
||||
i1: i0
|
||||
i2: i2
|
||||
conditioning: {}
|
||||
label: netadmin-eth0<->sw01-Ethernet0/1
|
||||
- id: l2
|
||||
n1: n1
|
||||
n2: n0
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: rtr01-Ethernet0/0<->internet-port
|
||||
- id: l3
|
||||
n1: n1
|
||||
n2: n4
|
||||
i1: i3
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: rtr01-Ethernet0/2<->desktop-0-eth0
|
||||
lab:
|
||||
description: 'Discover the essential role of Simple Network Management Protocol
|
||||
(SNMP) in network operations during this interactive live event. Review why SNMP
|
||||
is a fundamental tool for monitoring and managing network performance, and how
|
||||
it provides critical insights into device status and operational health. Through
|
||||
practical exercises, you''ll see SNMP''s capabilities in action, enabling efficient
|
||||
network management and proactive troubleshooting. '
|
||||
notes: |-
|
||||
**CCNA Exam Prep: Back to Networking Basics with Hank Preston and Patrick Gargano -- Season 2**
|
||||
|
||||
# Simplifying SNMP: Delivering Data for Network Operation Dashboards
|
||||
|
||||
Network Monitoring is critical to security and troubleshooting tasks. As your network grows and evolves,
|
||||
centralized monitoring becomes even more important. SNMP is a protocol that allows you to remotely monitor
|
||||
a wide range of settings and counters, be alerted when there are changes, and even remotely make configuration changes.
|
||||
|
||||
In this lab you will explore how SNMP works and how to configure and verify SNMP on Cisco devices.
|
||||
|
||||
Related CCNA v1.1 exam topic:
|
||||
* 4.4 Explain the function of SNMP in network operations
|
||||
|
||||
In this lab, we will:
|
||||
* Explore SNMP and its different versions
|
||||
* Configure and verify SNMPv2c
|
||||
* Configure and verify SNMPv3
|
||||
* Explore the SNMP message format and MIB using the snmpwalk command
|
||||
|
||||
## Setup and Scenario
|
||||
In this set of lab-based demonstrations, you are a network engineer tasked with configuring SNMPv2c on a Cisco switch and SNMPv3 on a Cisco router.
|
||||
|
||||
You've been asked to:
|
||||
|
||||
* Configure the sw01 switch to send SNMPv2c traps to the NMS server.
|
||||
* Configure the rtr01 router to send SNMPv3 traps to the NMS server.
|
||||
|
||||
*Be sure to **START** the lab before continuing to the demo lab.*
|
||||
|
||||
> Note: The credentials for all devices are shown in the CML topology.
|
||||
|
||||
## Part 1: Explore SNMP and its different versions
|
||||
Before we jump into configuring SNMP, let's explore how SNMP operates and how it evolved over time.
|
||||
|
||||
SNMP has become the standard for network management. It is a simple, easy-to-implement protocol and is supported by nearly all vendors. SNMP defines how management information is exchanged between SNMP managers and SNMP agents. It uses the UDP transport mechanism on ports 162 and 162 to retrieve and send management information, such as MIB variables.
|
||||
|
||||
SNMP is typically used to gather environment and performance data such as device CPU usage, memory usage, interface traffic, interface error rate, and so on.
|
||||
|
||||
The SNMP manager periodically polls the SNMP agents on managed devices by querying the device for data. Agents can generate SNMP traps, which are unsolicited notifications that are sent from agent to manager. SNMP traps are event-based and provide almost real-time event notifications.
|
||||
|
||||
There are three important concepts when it comes to SNMP:
|
||||
* The SNMP manager or network management system (NMS) collects management data from managed devices via polling or trap messages.
|
||||
* The SNMP agent is found on a managed network device, it locally organizes data and sends it to the manager.
|
||||
* The Management Information Base (MIB) represents a virtual information storage location that contains collections of managed objects. Within the MIB, there are objects that relate to different defined MIB modules (for example, the interface module). Objects in the MIB are referenced by their object ID (OID), which specifies the path from the tree root to the object. For example, system identification data is located under 1.3.6.1.2.1.1. Some examples of system data include the system name (OID 1.3.6.1.2.1.1.5), system location (OID 1.3.6.1.2.1.1.6), and system uptime (OID 1.3.6.1.2.1.1.3).
|
||||
|
||||
You can use the [Cisco SNMP SNMP Object Navigator](
|
||||
https://snmp.cloudapps.cisco.com/Support/SNMP/do/BrowseOID.do?local=en) to locate and identify different OID values
|
||||
|
||||
There are three different versions of SNMP:
|
||||
* SNMP version 1: SNMPv1 is the initial version of SNMP. SNMPv1 security is based on communities that are nothing more than passwords: plaintext strings that allow any SNMP-based application that knows the strings to gain access to the management information of a device. There are typically three communities in SNMPv1: read-only, read-write, and trap.
|
||||
* SNMP version 2c: SNMPv2 was the first attempt to fix SNMPv1 security flaws. However, SNMPv2 never really took off. The only prevalent version of SNMPv2 today is SNMPv2c, which contains SNMPv2 protocol enhancements but leaves out the security features that no one could agree on. The letter "c" designates v2c as being "community-based," which means that it uses the same authentication mechanism as v1: community strings.
|
||||
* SNMP version 3: SNMPv3 is the latest version. It adds support for strong authentication and private communication between managed entities. You can define a secure policy for each group, and optionally you can limit the IP addresses to which its members can belong. You have to define encryption and hashing algorithms and passwords for each user. SNMPv3 introduces three levels of security:
|
||||
* Security level ``noAuthNoPriv``: No authentication is required, and no privacy (encryption) is provided.
|
||||
|
||||
* Security level ``authNoPriv``: Authentication is required, but no encryption is provided.
|
||||
|
||||
* Security level ``authPriv``: In addition to authentication, encryption is also used.
|
||||
|
||||
## Part 2: Configure and verify SNMPv2c on sw01
|
||||
Let's deploy SNMPv2c on the sw01 switch to send traps to the SNMP_NMS device.
|
||||
|
||||
### Step 1
|
||||
Configure an access-list for SNMPv2 use on sw01.
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>ip access-list standard SNMP-NMS</b>
|
||||
sw01(config-std-nacl)# <b>permit host 192.168.100.100</b>
|
||||
sw01(config-std-nacl)# <b>exit</b>
|
||||
</pre>
|
||||
|
||||
This ACL will be used to specify exactly where SNMP **get** and **set** messages should be coming from. In this lab, the 192.168.100.0/24 network is the management network, and the SNMP manager is located at 192.168.100.100
|
||||
|
||||
Note that the Alpine Linux server in this lab is not yet configured as a NMS.
|
||||
|
||||
### Step 2
|
||||
Configure general SNMP information. Specify a location for the device, some contact information, and a chassis value.
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>snmp-server location RCD</b>
|
||||
sw01(config)# <b>snmp-server contact ccnaprep@example.com</b>
|
||||
sw01(config)# <b>snmp-server chassis-id Cisco IOL-L2 Switch sw01</b>
|
||||
</pre>
|
||||
|
||||
### Step 3
|
||||
SNMPv2c using a community string-based authentication. Access can be limited further by using an access list. Create a read-only community named CCNAPREP that is limited by the SNMP-NMS ACL
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>snmp-server community CCNAPREP ro SNMP-NMS</b>
|
||||
</pre>
|
||||
|
||||
### Step 4
|
||||
Configure 192.168.100.100 as a trap receiver using SNMPv2c and the community CCNAPREP.
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>snmp-server host 192.168.100.100 version 2c CCNAPREP</b>
|
||||
</pre>
|
||||
|
||||
### Step 5
|
||||
Configure interface index persistence.
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>snmp-server ifindex persist</b>
|
||||
</pre>
|
||||
|
||||
Network monitoring systems record throughput and other interface statistics using SNMP polling. Each interface is referenced by its unique index number, which is dynamically assigned by the IOS during bootup. The index of each interface can be determined with the command ``show snmp mib ifmib ifindex``. The dynamic assignment aspect of this can be problematic for documentation. Therefore, it is a good idea to instruct the system to keep a persistent list of interfaces, rather than a dynamic one. The use of this command creates a file stored in NVRAM.
|
||||
|
||||
Use the ``show snmp mib ifmib ifindex`` command to verify the current interface indexes.
|
||||
|
||||
<pre>
|
||||
sw01# <b>show snmp mib ifmib ifindex </b>
|
||||
Ethernet0/1: Ifindex = 2
|
||||
Ethernet0/3: Ifindex = 4
|
||||
<mark>Loopback0: Ifindex = 8</mark>
|
||||
Ethernet0/0: Ifindex = 1
|
||||
Null0: Ifindex = 6
|
||||
Vlan10: Ifindex = 7
|
||||
Ethernet0/2: Ifindex = 3
|
||||
SR0: Ifindex = 5
|
||||
</pre>
|
||||
|
||||
Notice that the Loopback 0 interface in the output above has an index value of 8. Your actual values might differ.
|
||||
|
||||
### Step 6
|
||||
Enable SNMP to send a trap to the NMS server when an interface on the switch goes down or up.
|
||||
|
||||
<pre>
|
||||
sw01(config)# <b>snmp-server enable traps snmp linkdown linkup </b>
|
||||
</pre>
|
||||
|
||||
This final SNMP configuration command actually enables the forwarding of traps to the configured trap receiver. As a part of this command, traps can be limited (as they can be in the ``snmp-server host`` command). For this lab, you will send a trap to the NMS anytime an interface goes down or up.
|
||||
|
||||
### Step 7
|
||||
Start a Packet Capture on the link between rtr01 and the NMS server and filter the capture to UDP port 162.
|
||||
|
||||
### Step 8
|
||||
Verify SNMP configuration
|
||||
|
||||
To verify that traps are being sent, issue the command ``debug snmp packets`` and then shutdown the Loopback 0 interface. You should see debug output indicating that an SNMP packet was sent. It might take a few moments for the switch to start sending traps and for them to appear in the packet capture.
|
||||
|
||||
<pre>
|
||||
sw01# <b>debug snmp packets</b>
|
||||
sw01# config t
|
||||
sw01(config)# <b>interface loopback 0</b>
|
||||
sw01(config-if)# <b>shut</b>
|
||||
sw01(config-if)#
|
||||
*Apr 26 01:10:18.534: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
|
||||
*Apr 26 01:10:18.534: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
|
||||
sw01(config-if)#
|
||||
*Apr 26 01:10:18.534: SNMP: Queuing packet to 192.168.100.100
|
||||
*Apr 26 01:10:18.534: SNMP: V2 Trap, reqid 10, errstat 0, erridx 0
|
||||
sysUpTime.0 = 2047407
|
||||
snmpTrapOID.0 = snmpTraps.3
|
||||
ifIndex.8 = 8
|
||||
ifDescr.8 = Loopback0
|
||||
ifType.8 = 24
|
||||
lifEntry.20.8 = administratively down
|
||||
<mark>*Apr 26 01:10:18.784: SNMP: Packet sent via UDP to 192.168.100.100</mark>
|
||||
</pre>
|
||||
|
||||
Notice in the output that a packet was sent to 192.168.100.100 using UDP, and that the message references the Loopback0 interface and shows that the interface was manually shutdown.
|
||||
|
||||
### Step 9
|
||||
Verify the SNMP packet in the Packet Capture.
|
||||
|
||||
Click the captured packet and open the SNMP line in the packet details. Expand all the available lines. You will see that CML does not interpret or convert the ASCII values for the individual OID entries in the SNMP packet. You will need Wireshark to help you with that. Wireshark is a free and open-source network protocol analyzer used for troubleshooting, analyzing, and debugging network problems. It captures and displays network traffic, allowing users to examine data at the packet level. This tool is valuable for network administrators, security professionals, and developers to understand how applications communicate and identify potential security issues. Although CML's Packet Capture tool is very powerful, for advanced packet analysis, Wireshark is invaluable.
|
||||
|
||||
> You can download Wireshark [here](https://www.wireshark.org/download.html).
|
||||
|
||||
In CML, click the ``Download`` button in the Packet Capture window to save the PCAP to your PC. Open the PCAP file using Wireshark. Expand the SNMP line and all its entries. This time you will be able to read in clear text the information contained in the SNMP packet. You should see the index value of the interface (8), the name of the interface (Loopback0), and the status of the interface (administratively down).
|
||||
|
||||
### Step 10
|
||||
Verify general SNMP settings using the ``show snmp`` command.
|
||||
|
||||
<pre>
|
||||
sw01# <b>show snmp</b>
|
||||
<mark>Chassis: Cisco IOL-L2 Switch sw01
|
||||
Contact: ccnaprep@example.com
|
||||
Location: RCD</mark>
|
||||
0 SNMP packets input
|
||||
0 Bad SNMP version errors
|
||||
0 Unknown community name
|
||||
0 Illegal operation for community name supplied
|
||||
0 Encoding errors
|
||||
0 Number of requested variables
|
||||
0 Number of altered variables
|
||||
0 Get-request PDUs
|
||||
0 Get-next PDUs
|
||||
0 Set-request PDUs
|
||||
0 Input queue packet drops (Maximum queue size 1000)
|
||||
0 Dispatcher queue packet drops (Maximum queue size 75)
|
||||
1 SNMP packets output
|
||||
0 Too big errors (Maximum packet size 1500)
|
||||
0 No such name errors
|
||||
0 Bad values errors
|
||||
0 General errors
|
||||
0 Response PDUs
|
||||
<mark>1 Trap PDUs</mark>
|
||||
Packets currently in SNMP process input queue: 0, max 1000
|
||||
Packets currently in SNMP PDU dispatcher queue: 0, max 75
|
||||
SNMP global trap: enabled
|
||||
|
||||
<mark>SNMP logging: enabled
|
||||
Logging to 192.168.100.100.162, 0/10, 1 sent, 0 dropped.</mark>
|
||||
</pre>
|
||||
|
||||
The output confirms the basic SNMP settings and how many trap messages were sent to the NMS.
|
||||
|
||||
### Step 11
|
||||
Verify the SNMP configuration found in the running-config on sw01.
|
||||
|
||||
<pre>
|
||||
sw01# <b>show run | section snmp</b>
|
||||
snmp-server community CCNAPREP RO SNMP-NMS
|
||||
snmp-server location RCD
|
||||
snmp-server contact ccnaprep@example.com
|
||||
snmp-server chassis-id Cisco IOL-L2 Switch sw01
|
||||
snmp-server enable traps snmp linkdown linkup
|
||||
snmp-server host 192.168.100.100 version 2c CCNAPREP
|
||||
snmp ifmib ifindex persist
|
||||
</pre>
|
||||
|
||||
## Part 3: Configure and verify SNMPv3 on rtr01
|
||||
Let's deploy SNMPv3 on the rtr01 router to send traps to the SNMP-NMS device. The configuration for SNMPv3 is quite different to what you did on sw01 for SNMPv2c. For SNMPv3, instead of a community string, you need to configure the following:
|
||||
|
||||
* SNMP view: Views specify which MIB objects are visible to a particular group.
|
||||
* SNMP group: Groups are used to combine users and assign them to specific views and security levels.
|
||||
* SNMP user: Once groups and views are defined, users are assigned to a specific group.
|
||||
|
||||
In summary, views define what information is visible, groups define who can access that information, and users are assigned to groups to inherit the access permissions. This layered approach provides flexibility and granular control over SNMPv3 access on Cisco devices.
|
||||
|
||||
### Step 1
|
||||
Configure an access-list for SNMPv3 use on rtr01.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>ip access-list standard SNMP-NMS</b>
|
||||
rtr01(config-std-nacl)# <b>permit host 192.168.100.100</b>
|
||||
rtr01(config-std-nacl)# <b>exit</b>
|
||||
</pre>
|
||||
|
||||
This ACL is identical to the ACL you configured on sw01 and limits access to the router's MIB .
|
||||
|
||||
### Step 2
|
||||
Configure a SNMPv3 view called SNMP-RO that includes the entire ``iso`` tree from the MIB.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server view SNMP-RO iso included</b>
|
||||
</pre>
|
||||
|
||||
In a production network, you would want to restrict the view to a smaller subset of MIBs.
|
||||
|
||||
### Step 3
|
||||
Configure a read-only SNMPv3 group with the highest level of security supported and assigned the ACL defined in Step 1.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server group ADMIN v3 priv read SNMP-RO access SNMP-NMS</b>
|
||||
</pre>
|
||||
|
||||
A read-only SNMP group is configured with the name ADMIN, it is set to SNMPv3 with authentication and encryption required, and only allows access to the host permitted in the SNMP-NMS ACL.
|
||||
|
||||
### Step 4
|
||||
Configure a SNMPv3 user, assign it to the ADMIN group, and use SHA-1 and AES-128 for authentication and encryption.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server user USER1 ADMIN v3 auth sha cisco12345 priv aes 128
|
||||
cisco54321</b>
|
||||
rtr01(config)#
|
||||
Jan 1 01:52:49.896: Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...
|
||||
</pre>
|
||||
|
||||
Once the user is created, you should get a message at the console indicating that the internal SNMP process is starting up.
|
||||
|
||||
### Step 5
|
||||
Configure a SNMPv3 trap receiver at 192.168.100.100 and assign the user created in Step 4.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server host 192.168.100.100 version 3 priv USER1</b>
|
||||
</pre>
|
||||
|
||||
### Step 6
|
||||
Enable SNMP trap sending to send a trap to the NMS server when an interface on the router goes down or up.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server enable traps snmp linkdown linkup </b>
|
||||
</pre>
|
||||
|
||||
### Step 7
|
||||
Configure interface index persistence.
|
||||
|
||||
<pre>
|
||||
rtr01(config)# <b>snmp-server ifindex persist</b>
|
||||
</pre>
|
||||
|
||||
### Step 8
|
||||
Save your configuration to NVRAM and reload the rtr01 router.
|
||||
|
||||
<pre>
|
||||
rtr01# <b>copy run start</b>
|
||||
Destination filename [startup-config]?
|
||||
Building configuration...
|
||||
[OK]
|
||||
rtr01# <b>reload</b>
|
||||
Proceed with reload? [confirm]
|
||||
</pre>
|
||||
|
||||
> Note: Because of a bug in the Cisco IOL image in CML, you need to reboot the router after starting the SNMPv3 process to ensure that the next steps work correctly. Configuration of SNMPv3 in a production network does NOT require a device reboot.
|
||||
|
||||
### Step 8
|
||||
After the router reboots and you can log back into Privileged EXEC mode, start a Packet Capture on the link between rtr01 and the NMS server and filter the capture to UDP port 162.
|
||||
|
||||
### Step 9
|
||||
Verify SNMP configuration
|
||||
|
||||
To verify that traps are being sent, issue the command ``debug snmp packets`` and shutdown the E0/0 interface and then re-enable it. You should see debug output indicating that two SNMP packets were sent. It might take a few moments for the router to start sending traps and for them to appear in the packet capture.
|
||||
|
||||
<pre>
|
||||
rtr01# <b>debug snmp packets</b>
|
||||
SNMP packet debugging is on
|
||||
rtr01# <b>conf t</b>
|
||||
Enter configuration commands, one per line. End with CNTL/Z.
|
||||
rtr01(config)# <b>interface e0/0</b>
|
||||
rtr01(config-if)# <b>shutdown</b>
|
||||
rtr01(config-if)#
|
||||
Apr 26 01:10:18.534: %LINK-5-CHANGED: Interface Ethernet0/0, changed state to administratively down
|
||||
Apr 26 01:10:19.534: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
|
||||
rtr01(config-if)# <b>no shutdown</b>
|
||||
rtr01(config-if)#
|
||||
Apr 26 01:10:20.534: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
|
||||
rtr01(config-if)#
|
||||
Apr 26 01:10:21.534: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
|
||||
rtr01(config-if)#
|
||||
Apr 26 01:10:22.534: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address 192.168.255.184, mask 255.255.255.0, hostname rtr01
|
||||
rtr01(config-if)#
|
||||
Apr 26 01:10:23.534: SNMP: Queuing packet to 192.168.100.100
|
||||
Apr 26 01:10:23.534: SNMP: V2 Trap, reqid 1, errstat 0, erridx 0
|
||||
sysUpTime.0 = 754478
|
||||
snmpTrapOID.0 = snmpTraps.3
|
||||
ifIndex.1 = 1
|
||||
ifDescr.1 = Ethernet0/0
|
||||
ifType.1 = 6
|
||||
lifEntry.20.1 = administratively down
|
||||
Apr 26 01:10:24.534: SNMP: Queuing packet to 192.168.100.100
|
||||
Apr 26 01:10:24.534: SNMP: V2 Trap, reqid 2, errstat 0, erridx 0
|
||||
sysUpTime.0 = 754479
|
||||
snmpTrapOID.0 = snmpTraps.4
|
||||
ifIndex.1 = 1
|
||||
ifDescr.1 = Ethernet0/0
|
||||
ifType.1 = 6
|
||||
lifEntry.20.1 = up
|
||||
<mark>Apr 26 01:10:25.534: SNMP: Packet sent via UDP to 192.168.100.100
|
||||
Apr 26 01:10:25.534: SNMP: Packet sent via UDP to 192.168.100.100</mark>
|
||||
</pre>
|
||||
|
||||
Notice that in the output above, two traps were sent after the interface was brought back up. Your results might differ but you should still get two traps captures in the Packet Capture window.
|
||||
|
||||
Disable debugging with the ``do undebug all`` command.
|
||||
|
||||
### Step 10
|
||||
Decrypt the SNMPv3 PCAP using Wireshark.
|
||||
|
||||
Notice that the ``Info`` column of the Packet Capture window shows that the PDU is encrypted and that the private key is unknown. You will need to download the PCAP from CML and use Wireshark to decrypt the SNMPv3 packet.
|
||||
|
||||
Click the ``Download`` button in the Packet Capture window and open the PCAP in Wireshark on your PC.
|
||||
|
||||
Right-click one of the SNMPv3 packets displayed in the top window in Wireshark, select ``Protocol Preferences`` from the menu, select ``Simple Network Management Protocol`` and then select ``Users Table``.
|
||||
|
||||
Click the ``+`` button to create a new user entry. Enter the following values:
|
||||
|
||||
User: USER1
|
||||
Authentication Model: SHA-1
|
||||
Password: cisco12345
|
||||
Privacy Protocol: AES
|
||||
Privacy password: cisco54321
|
||||
|
||||
Click ``Ok`` to save the USER1 table entry.
|
||||
|
||||
Fully expand the ``msgData: encryptedPDU`` entry. In the last expanded field, you will see information relating to the Ethernet 0/0 interface ("administratively down" or "up" depending on the SNMPv3 packet you have selected.
|
||||
|
||||
# Step 11
|
||||
Verify the SNMPv3 configuration on rtr01.
|
||||
|
||||
<pre>
|
||||
rtr01# <b>show snmp</b>
|
||||
Chassis: 131184943
|
||||
0 SNMP packets input
|
||||
0 Bad SNMP version errors
|
||||
0 Unknown community name
|
||||
0 Illegal operation for community name supplied
|
||||
0 Encoding errors
|
||||
0 Number of requested variables
|
||||
0 Number of altered variables
|
||||
0 Get-request PDUs
|
||||
0 Get-next PDUs
|
||||
0 Set-request PDUs
|
||||
0 Input queue packet drops (Maximum queue size 1000)
|
||||
0 Dispatcher queue packet drops (Maximum queue size 75)
|
||||
2 SNMP packets output
|
||||
0 Too big errors (Maximum packet size 1500)
|
||||
0 No such name errors
|
||||
0 Bad values errors
|
||||
0 General errors
|
||||
0 Response PDUs
|
||||
2 Trap PDUs
|
||||
Packets currently in SNMP process input queue: 0, max 1000
|
||||
Packets currently in SNMP PDU dispatcher queue: 0, max 75
|
||||
SNMP global trap: disabled
|
||||
|
||||
SNMP logging: enabled
|
||||
Logging to 192.168.100.100.162, 0/10, 2 sent, 0 dropped.
|
||||
|
||||
rtr01# <b>show snmp group</b>
|
||||
groupname: ADMIN security model:v3 priv
|
||||
contextname: <no context specified> storage-type: nonvolatile
|
||||
readview : SNMP-RO writeview: <no writeview specified>
|
||||
notifyview: *tv.FFFFFFFF.FFFFFFFF.FFFFFFFF.F
|
||||
row status: active access-list: SNMP-NMS
|
||||
|
||||
rtr01# <b>show snmp user </b>
|
||||
|
||||
User name: USER1
|
||||
Engine ID: 800000090300AABBCC012F00
|
||||
storage-type: nonvolatile active
|
||||
Authentication Protocol: SHA
|
||||
Privacy Protocol: AES128
|
||||
Group-name: ADMIN
|
||||
</pre>
|
||||
|
||||
### Step 12
|
||||
Install SNMP and SNMP tools on the SNMP-NMS device and perform a SNMP walk on the rtr01 device.
|
||||
|
||||
``snmpwalk`` is a command-line utility used to retrieve a subtree of management values from a network device using SNMP GETNEXT requests. It's essentially a tool that automates the process of querying multiple SNMP-enabled devices for information, instead of having to query each device individually. This allows you to gather a wide range of data from devices like routers, switches, and other network infrastructure.
|
||||
|
||||
<pre>
|
||||
snmp_nms:~$ <b>sudo apk add net-snmp</b>
|
||||
fetch http://dl-cdn.alpinelinux.org/alpine/v3.14/main/x86_64/APKINDEX.tar.gz
|
||||
fetch http://dl-cdn.alpinelinux.org/alpine/v3.14/community/x86_64/APKINDEX.tar.gz
|
||||
(1/4) Installing net-snmp-libs (5.9.3-r1)
|
||||
(2/4) Installing net-snmp-agent-libs (5.9.3-r1)
|
||||
(3/4) Installing net-snmp (5.9.3-r1)
|
||||
(4/4) Installing net-snmp-openrc (5.9.3-r1)
|
||||
Executing busybox-1.33.1-r8.trigger
|
||||
OK: 1215 MiB in 334 packages
|
||||
|
||||
snmp_nms:~$ <b>sudo apk add net-snmp-tools</b>
|
||||
(1/1) Installing net-snmp-tools (5.9.3-r1)
|
||||
Executing busybox-1.33.1-r8.trigger
|
||||
OK: 1216 MiB in 335 packages
|
||||
|
||||
snmp_nms:~$ <b>snmpwalk -v3 -u USER1 -l authPriv -a SHA -A "cisco12345" -x AES -X "cisco54321" 192.168.100.1 1.3.6.1.2.1.1</b>
|
||||
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software [Dublin], Linux Software (X86_64BI_LINUX-ADVENTERPRISEK9-M), Version 17.12.1, RELEASE SOFTWARE (fc5)
|
||||
Technical Support: http://www.cisco.com/techsupport
|
||||
Copyright (c) 1986-2023 by Cisco Systems, Inc.
|
||||
Compiled Thu 27-Jul-23 22:33 by m
|
||||
SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.9.1.1
|
||||
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1072907) 2:58:49.07
|
||||
SNMPv2-MIB::sysContact.0 = STRING:
|
||||
SNMPv2-MIB::sysName.0 = STRING: rtr01.example.com
|
||||
SNMPv2-MIB::sysLocation.0 = STRING:
|
||||
SNMPv2-MIB::sysServices.0 = INTEGER: 78
|
||||
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
|
||||
</pre>
|
||||
|
||||
In the ``snmpwalk`` command above, you must specify the following parameters:
|
||||
* SNMP version
|
||||
* the user name
|
||||
* the level of securty (auth and priv)
|
||||
* the level of SHA authentication and the password
|
||||
* the level of AES encryption and the password
|
||||
* the IP address of the device to check (rtr01)
|
||||
* the OID your want to view (in this case, the router's system information)
|
||||
|
||||
In the example above, the OID specified pulls system and IOS version information from a device.
|
||||
|
||||
Use the ``snmpwalk`` command and explore other OID values, like 1.3.6.1.2.1.4.24 (routing table) or 1.3.6.1.2.1.2.2.1.8 (operational status of the devices interfaces.)
|
||||
|
||||
Congratulations! You have completed the lab. You learned how to configure and verify SNMPv2c and SNMPv3, as well as use Wireshark and ``snmpwalk`` to analyze and gather OIDs from Cisco routers and switches.
|
||||
title: CCNA Prep 2025 S2E7 SNMP
|
||||
version: 0.2.2
|
BIN
lab-topologies/ccna-prep/s2e7/CCNA_Prep_S02E07_SNMP_Guide.pdf
Normal file
5
lab-topologies/ccna-prep/s2e7/README.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Simplifying SNMP: Delivering Data for Network Operation Dashboards
|
||||
|
||||
*Abstract:* Discover the essential role of Simple Network Management Protocol (SNMP) in network operations during this interactive live event. Review why SNMP is a fundamental tool for monitoring and managing network performance, and how it provides critical insights into device status and operational health. Through practical exercises, you'll see SNMP's capabilities in action, enabling efficient network management and proactive troubleshooting.
|
||||
|
||||

|
BIN
lab-topologies/ccna-prep/s2e7/s2e7-snmp.jpg
Normal file
After Width: | Height: | Size: 84 KiB |
23
lab-topologies/cml-free/vlan-tasks/README.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# VLAN Tasks
|
||||
|
||||
## Introduction
|
||||
|
||||
These topologies are designed to work with CML Free and give the learner VLAN-centric configuration
|
||||
and verification tasks to perform. The tasks themselves align with the CCNA exam blueprint's tasks
|
||||
2.1 and 2.2.
|
||||
|
||||

|
||||
|
||||
## Getting Started
|
||||
|
||||
The `topology.yaml` file is the initial starting point. Import it into CML using the **Import** button
|
||||
from the CML Dashboard.
|
||||
|
||||
Within the lab, click the **GUIDE** button to view the instructions.
|
||||
|
||||
## Using the Solution
|
||||
|
||||
If you get stuck or just want to check your work, import the `topology-solution.yaml` file in the same
|
||||
way you imported `topology.yaml`. This provides you with the nodes configured correctly and a sample
|
||||
`traceroute` output verifying the correct path is taken.
|
||||
|
BIN
lab-topologies/cml-free/vlan-tasks/screenshot.png
Normal file
After Width: | Height: | Size: 234 KiB |
822
lab-topologies/cml-free/vlan-tasks/topology-solution.yaml
Normal file
@@ -0,0 +1,822 @@
|
||||
annotations:
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#F8EFBB'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: rectangle
|
||||
x1: 440.0
|
||||
y1: 40.0
|
||||
x2: 440.0
|
||||
y2: 120.0
|
||||
z_index: 0
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#C4D9F0'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: rectangle
|
||||
x1: 440.0
|
||||
y1: 387.0
|
||||
x2: 436.0
|
||||
y2: 120.0
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLAN 10
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 800.0
|
||||
y1: 56.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLAN 20
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 798.0
|
||||
y1: 485.0
|
||||
z_index: 4
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#5FD34A'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: ellipse
|
||||
x1: 649.1808510638298
|
||||
y1: 261.84574468085106
|
||||
x2: 26.10638297872339
|
||||
y2: 39.93794326241135
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLANs 10 and 20 ONLY trunked here.
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -15.497049430398334
|
||||
y1: 188.37721292720124
|
||||
z_index: 6
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
line_end: arrow
|
||||
line_start: null
|
||||
thickness: 1
|
||||
type: line
|
||||
x1: 320.0
|
||||
y1: 200.0
|
||||
x2: 609.8262411347517
|
||||
y2: 222.16312056737587
|
||||
z_index: 7
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#5FD34A'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: ellipse
|
||||
x1: 836.3120567375887
|
||||
y1: 261.78014184397153
|
||||
x2: 26.10638297872339
|
||||
y2: 41.52836879432627
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLANs 10 and 20 ONLY trunked here.
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 990.8754995421232
|
||||
y1: 171.1980648504783
|
||||
z_index: 6
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
line_end: arrow
|
||||
line_start: null
|
||||
thickness: 1
|
||||
type: line
|
||||
x1: 1060.2659574468087
|
||||
y1: 198.9787234042553
|
||||
x2: 876.4468085106384
|
||||
y2: 222.16312056737587
|
||||
z_index: 8
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
Use 192.168.10.1/24 for VLAN 10
|
||||
Use 192.168.20.1/24 for VLAN 20
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 920.0
|
||||
y1: 320.0
|
||||
z_index: 9
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
IP address 192.168.10.2
|
||||
Login:
|
||||
cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 480.0
|
||||
y1: 80.0
|
||||
z_index: 10
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
IP address 192.168.20.2
|
||||
Login:
|
||||
cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 587.0857921413347
|
||||
y1: 419.83431685653386
|
||||
z_index: 10
|
||||
smart_annotations: []
|
||||
nodes:
|
||||
- boot_disk_size: 16
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname PC
|
||||
# configurable user account
|
||||
ip addr add 192.168.10.2/24 dev eth0
|
||||
ip route add default via 192.168.10.1
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: 100
|
||||
cpus: 1
|
||||
data_volume: 0
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: PC
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: 512
|
||||
tags: []
|
||||
x: 742
|
||||
y: 91
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: 16
|
||||
configuration:
|
||||
- name: iosxe_config.txt
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname server
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
ifconfig eth0 inet 192.168.20.2 netmask 255.255.255.0
|
||||
route add default gw 192.168.20.1
|
||||
# no password for tc user by default
|
||||
TC_PASSWORD=
|
||||
cpu_limit: 100
|
||||
cpus: 1
|
||||
data_volume: 0
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: server-tcl-11-1
|
||||
label: server
|
||||
node_definition: server
|
||||
parameters: {}
|
||||
ram: 128
|
||||
tags: []
|
||||
x: 552
|
||||
y: 440
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
!
|
||||
hostname RTR
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip cef
|
||||
login on-success log
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
multilink bundle-name authenticated
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
memory free low-watermark processor 81225
|
||||
!
|
||||
!
|
||||
spanning-tree mode rapid-pvst
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface Ethernet0/0
|
||||
no ip address
|
||||
!
|
||||
interface Ethernet0/0.10
|
||||
encapsulation dot1Q 10
|
||||
ip address 192.168.10.1 255.255.255.0
|
||||
!
|
||||
interface Ethernet0/0.20
|
||||
encapsulation dot1Q 20
|
||||
ip address 192.168.20.1 255.255.255.0
|
||||
!
|
||||
interface Ethernet0/1
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
interface Ethernet0/2
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
interface Ethernet0/3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
!
|
||||
no ip http server
|
||||
no ip http secure-server
|
||||
ip ssh bulk-mode 131072
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
!
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
logging synchronous
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
login
|
||||
transport input none
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: RTR
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 941
|
||||
y: 260
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
service compress-config
|
||||
!
|
||||
hostname SW1
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip audit notify log
|
||||
ip audit po max-events 100
|
||||
ip cef
|
||||
login on-success log
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
vtp mode transparent
|
||||
vtp version 1
|
||||
multilink bundle-name authenticated
|
||||
!
|
||||
crypto pki trustpoint TP-self-signed-131184641
|
||||
enrollment selfsigned
|
||||
subject-name cn=IOS-Self-Signed-Certificate-131184641
|
||||
revocation-check none
|
||||
rsakeypair TP-self-signed-131184641
|
||||
hash sha256
|
||||
!
|
||||
!
|
||||
crypto pki certificate chain TP-self-signed-131184641
|
||||
certificate self-signed 01
|
||||
3082032E 30820216 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030
|
||||
30312E30 2C060355 04030C25 494F532D 53656C66 2D536967 6E65642D 43657274
|
||||
69666963 6174652D 31333131 38343634 31301E17 0D323530 32323331 34343933
|
||||
345A170D 33353032 32333134 34393334 5A303031 2E302C06 03550403 0C25494F
|
||||
532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3133 31313834
|
||||
36343130 82012230 0D06092A 864886F7 0D010101 05000382 010F0030 82010A02
|
||||
82010100 97F955E7 550CEB36 937AD820 21DD1ED4 A1CC9477 7367A640 BEA04847
|
||||
8B5AB68E C47DDF62 21F19260 2574A025 EDEA4F96 453E0BF7 B6C2DF09 7D1D74F3
|
||||
91575A00 ADE1F99B 0E2075BB 3F620FCF 00CC6436 CBC80C99 2B426098 FF480AAE
|
||||
33B67914 851BBDF2 320BBA3F 1D36FCF0 115AA0C4 5D58E385 D9B6F736 0E592909
|
||||
1A63FDE5 FF2A4BD1 F34BDE50 B07B5270 DAC09EAA EB9C75AE 3E980FD3 35CB9663
|
||||
60198D19 327915A8 358A2A84 BE33A78C 626F1AB4 20D1C06C 848A55F6 FC05BA75
|
||||
DE6A61D0 07380927 E9DC8329 61365E78 B6744D4F 3C4BE570 703808AB 96BE5E95
|
||||
0660814D 59747251 8D38756E 3F48706D CFDB3C9E F5A67AB5 3B14E416 9515A44B
|
||||
93BD71A9 02030100 01A35330 51301D06 03551D0E 04160414 8A026A3B 1C7C62DB
|
||||
323FC051 12FEED9F BAB36CA8 301F0603 551D2304 18301680 148A026A 3B1C7C62
|
||||
DB323FC0 5112FEED 9FBAB36C A8300F06 03551D13 0101FF04 05300301 01FF300D
|
||||
06092A86 4886F70D 01010B05 00038201 010065F3 CE4548DF 6CD09CF8 8EE03FB0
|
||||
EFD0F2F1 8FCC274A 16684E91 7918FA7C A14911D2 D1E2FDFC B9387841 9B5FDFBA
|
||||
7B3CA330 8EE304DA 8F7AB174 20CD050F 5DFE51A5 29FA236C 4616BB18 9F91D9BF
|
||||
5883E2E8 FF444E31 9D47291C 1BDE4C1D 1AF1B9EB B55A3F6A 01FCC107 EA65CFC5
|
||||
7A458842 B4D765BF 3825B21B 4E973BE1 578D09E8 FD96E752 F5051703 EA50D1DB
|
||||
21A04A24 C9B993D5 964379CE F4EE20E8 70855783 AD366AEE D2B83412 E5713542
|
||||
55064B43 CBE43CE6 D267B60A EFD76F93 6E980FDC 721A56A8 E48E06DD C996C9E5
|
||||
2200D4E5 39D05D5A 69770F2E 33964A27 D31350FB E1A44BFA 983273C4 0CEEDDC4
|
||||
9055D03A 35B7100F 73C7741F A4EA546B 746C
|
||||
quit
|
||||
!
|
||||
!
|
||||
memory free low-watermark processor 80589
|
||||
!
|
||||
!
|
||||
spanning-tree mode pvst
|
||||
spanning-tree extend system-id
|
||||
!
|
||||
!
|
||||
vlan internal allocation policy ascending
|
||||
!
|
||||
vlan 10
|
||||
name PCs
|
||||
!
|
||||
vlan 20
|
||||
name SERVERs
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface Ethernet0/0
|
||||
switchport trunk encapsulation dot1q
|
||||
switchport trunk allowed vlan 10,20
|
||||
switchport mode trunk
|
||||
!
|
||||
interface Ethernet0/1
|
||||
switchport access vlan 10
|
||||
!
|
||||
interface Ethernet0/2
|
||||
switchport trunk encapsulation dot1q
|
||||
switchport trunk allowed vlan 10,20
|
||||
switchport mode trunk
|
||||
!
|
||||
interface Ethernet0/3
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
!
|
||||
ip http server
|
||||
ip http secure-server
|
||||
ip ssh bulk-mode 131072
|
||||
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
!
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
logging synchronous
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
login
|
||||
transport input ssh
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: SW1
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 740
|
||||
y: 263
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
service compress-config
|
||||
!
|
||||
hostname SW2
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip audit notify log
|
||||
ip audit po max-events 100
|
||||
ip cef
|
||||
login on-success log
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
vtp mode transparent
|
||||
vtp version 1
|
||||
multilink bundle-name authenticated
|
||||
!
|
||||
crypto pki trustpoint TP-self-signed-131184643
|
||||
enrollment selfsigned
|
||||
subject-name cn=IOS-Self-Signed-Certificate-131184643
|
||||
revocation-check none
|
||||
rsakeypair TP-self-signed-131184643
|
||||
hash sha256
|
||||
!
|
||||
!
|
||||
crypto pki certificate chain TP-self-signed-131184643
|
||||
certificate self-signed 01
|
||||
3082032E 30820216 A0030201 02020101 300D0609 2A864886 F70D0101 0B050030
|
||||
30312E30 2C060355 04030C25 494F532D 53656C66 2D536967 6E65642D 43657274
|
||||
69666963 6174652D 31333131 38343634 33301E17 0D323530 32323331 34343933
|
||||
375A170D 33353032 32333134 34393337 5A303031 2E302C06 03550403 0C25494F
|
||||
532D5365 6C662D53 69676E65 642D4365 72746966 69636174 652D3133 31313834
|
||||
36343330 82012230 0D06092A 864886F7 0D010101 05000382 010F0030 82010A02
|
||||
82010100 CF90789C 82BAC8C4 7415DD3D 50A3585C 1DA872DB 6A5D7AED EC39BA0D
|
||||
C264E3F4 14A4A7B1 CA13155E 806DB41D EF43F041 672053EB CDE6B54A 80F5FA64
|
||||
F5564647 03E1038B 5C6AE1FE B3D31A18 E542C7ED C8550553 9B5C27FC BF943A96
|
||||
57E50792 C3FBCC79 265E2011 043E5796 55BA5CB8 61A28B8B A11E0CF9 FDE5C63A
|
||||
04F20604 9E076B08 92AF67D5 D796AEDA B3BFD526 657BE2E5 59956F36 F2F9B667
|
||||
7E3BF299 B6C0CB6F 8FE8FA6C 41AE9970 C14F3390 C044AAAE 30AA3204 CB9B0534
|
||||
93064AE5 6D7836DB DEDD5668 828D035B 6807EF38 ECE035B6 A18401CA 39162EA3
|
||||
87D247A3 E7D9121C 7FB777C8 66CC7208 618D71A8 C64A6D98 A6F4C47D 5F0FCBA2
|
||||
78CE6A4D 02030100 01A35330 51301D06 03551D0E 04160414 9D23C421 B20479C0
|
||||
3859F14B D632B6F2 C9EFE989 301F0603 551D2304 18301680 149D23C4 21B20479
|
||||
C03859F1 4BD632B6 F2C9EFE9 89300F06 03551D13 0101FF04 05300301 01FF300D
|
||||
06092A86 4886F70D 01010B05 00038201 01006D6C A797D963 FFD56DF9 AC76FD0A
|
||||
46A1589B 6725478D C67CEAB2 535FDB14 729D5908 4A84ED28 D6C52A2A 5E36647A
|
||||
29854FDA 0355B011 F7AD59C9 DD5EB0AC A24ADE7A C54E86EF DC44F3DB DDE1A56A
|
||||
06063D62 3928131D A3858542 641B6086 6D6D5D1C D5B3DE7D D17F9993 397AA85C
|
||||
1E0C8938 AED3F88A 3440BA61 F3B791DE BFD4E61A E6494E0E F671BDE1 A14F779F
|
||||
DE374560 A039A550 1906D3BA A3705333 66C4E1EA E3637BA4 2B130BDE 735441F3
|
||||
F70E8182 7C2FAF28 9DA8D764 31037F40 BE0CEF7F 41EE59F7 AF57057B 7522E470
|
||||
13DA08DF 3E75B6BA A749C4F2 3F51D1BE 9F8584C0 FC6985CC 2F28D95A 6B5E0DE1
|
||||
306580FE C08012D1 94952A78 EA64C795 7A9A
|
||||
quit
|
||||
!
|
||||
!
|
||||
memory free low-watermark processor 80589
|
||||
!
|
||||
!
|
||||
spanning-tree mode pvst
|
||||
spanning-tree extend system-id
|
||||
!
|
||||
!
|
||||
vlan internal allocation policy ascending
|
||||
!
|
||||
vlan 10
|
||||
name PCs
|
||||
!
|
||||
vlan 20
|
||||
name SERVERs
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface Ethernet0/0
|
||||
switchport access vlan 20
|
||||
!
|
||||
interface Ethernet0/1
|
||||
switchport trunk encapsulation dot1q
|
||||
switchport trunk allowed vlan 10,20
|
||||
switchport mode trunk
|
||||
!
|
||||
interface Ethernet0/2
|
||||
!
|
||||
interface Ethernet0/3
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
!
|
||||
ip http server
|
||||
ip http secure-server
|
||||
ip ssh bulk-mode 131072
|
||||
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
!
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
logging synchronous
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
login
|
||||
transport input ssh
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: SW2
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 552
|
||||
y: 265
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n3
|
||||
n2: n2
|
||||
i1: i1
|
||||
i2: i1
|
||||
conditioning: {}
|
||||
label: SW1-Ethernet0/0<->RTR-Ethernet0/0
|
||||
- id: l1
|
||||
n1: n3
|
||||
n2: n0
|
||||
i1: i2
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: SW1-Ethernet0/1<->PC-eth0
|
||||
- id: l2
|
||||
n1: n4
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: SW2-Ethernet0/0<->server-eth0
|
||||
- id: l3
|
||||
n1: n4
|
||||
n2: n3
|
||||
i1: i2
|
||||
i2: i3
|
||||
conditioning: {}
|
||||
label: SW2-Ethernet0/1<->SW1-Ethernet0/2
|
||||
lab:
|
||||
description: ''
|
||||
notes: |-
|
||||
# CCNA: Implement Multiple VLANs and Basic Routing Between the VLANs
|
||||
In this lab you need to do the following:
|
||||
- Implement VLAN assignments on two switches
|
||||
- Configure a dot1q trunk between those switches
|
||||
- Configure a dot1q trunk between one switch and a router that will handle the routing for the VLANs
|
||||
- Configure VLAN trunking on that router to act as a gateway between VLANs
|
||||
- Verify that connectivity exists between hosts in the lab on each VLAN, and that the connectivity goes through the router
|
||||
|
||||
All nodes have been pre-configured. Login to `PC` and run `traceroute -n 192.168.20.2`. That will trace the path between the PC and the server. Your output
|
||||
should look like the following. Note: the `-n` argument skips DNS lookups to make the `traceroute` run faster.
|
||||
|
||||
```
|
||||
PC:~$ traceroute -n 192.168.20.2
|
||||
traceroute to 192.168.20.2 (192.168.20.2), 30 hops max, 46 byte packets
|
||||
1 192.168.10.1 1.036 ms 0.803 ms 0.805 ms
|
||||
2 192.168.20.2 3.595 ms 1.691 ms 1.708 ms
|
||||
```
|
||||
In the output above, **192.168.10.1** is `RTR`, which is performing the routing between the VLANs.
|
||||
title: Sample Lab 1 FREE (VLAN Configuration) Solution
|
||||
version: 0.3.0
|
682
lab-topologies/cml-free/vlan-tasks/topology.yaml
Normal file
@@ -0,0 +1,682 @@
|
||||
annotations:
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#F8EFBB'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: rectangle
|
||||
x1: 440.0
|
||||
y1: 40.0
|
||||
x2: 440.0
|
||||
y2: 120.0
|
||||
z_index: 0
|
||||
- border_color: '#808080FF'
|
||||
border_radius: 2
|
||||
border_style: ''
|
||||
color: '#C4D9F0'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: rectangle
|
||||
x1: 440.0
|
||||
y1: 387.0
|
||||
x2: 436.0
|
||||
y2: 120.0
|
||||
z_index: 1
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLAN 10
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 800.0
|
||||
y1: 56.0
|
||||
z_index: 3
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000FF'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLAN 20
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 798.0
|
||||
y1: 485.0
|
||||
z_index: 4
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#5FD34A'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: ellipse
|
||||
x1: 649.1808510638298
|
||||
y1: 261.84574468085106
|
||||
x2: 26.10638297872339
|
||||
y2: 39.93794326241135
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLANs 10 and 20 ONLY trunked here.
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: -15.497049430398334
|
||||
y1: 188.37721292720124
|
||||
z_index: 6
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
line_end: arrow
|
||||
line_start: null
|
||||
thickness: 1
|
||||
type: line
|
||||
x1: 320.0
|
||||
y1: 200.0
|
||||
x2: 609.8262411347517
|
||||
y2: 222.16312056737587
|
||||
z_index: 7
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#5FD34A'
|
||||
rotation: 0
|
||||
thickness: 1
|
||||
type: ellipse
|
||||
x1: 836.3120567375887
|
||||
y1: 261.78014184397153
|
||||
x2: 26.10638297872339
|
||||
y2: 41.52836879432627
|
||||
z_index: 5
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: VLANs 10 and 20 ONLY trunked here.
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 990.8754995421232
|
||||
y1: 171.1980648504783
|
||||
z_index: 6
|
||||
- border_color: '#808080FF'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
line_end: arrow
|
||||
line_start: null
|
||||
thickness: 1
|
||||
type: line
|
||||
x1: 1060.2659574468087
|
||||
y1: 198.9787234042553
|
||||
x2: 876.4468085106384
|
||||
y2: 222.16312056737587
|
||||
z_index: 8
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
Use 192.168.10.1/24 for VLAN 10
|
||||
Use 192.168.20.1/24 for VLAN 20
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 920.0
|
||||
y1: 320.0
|
||||
z_index: 9
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
IP address 192.168.10.2
|
||||
Login:
|
||||
cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 480.0
|
||||
y1: 80.0
|
||||
z_index: 10
|
||||
- border_color: '#00000000'
|
||||
border_style: ''
|
||||
color: '#000000'
|
||||
rotation: 0
|
||||
text_bold: true
|
||||
text_content: |-
|
||||
IP address 192.168.20.2
|
||||
Login:
|
||||
cisco / cisco
|
||||
text_font: monospace
|
||||
text_italic: false
|
||||
text_size: 12
|
||||
text_unit: pt
|
||||
thickness: 1
|
||||
type: text
|
||||
x1: 587.0857921413347
|
||||
y1: 421.2179892684938
|
||||
z_index: 10
|
||||
smart_annotations: []
|
||||
nodes:
|
||||
- boot_disk_size: 16
|
||||
configuration:
|
||||
- name: node.cfg
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname PC
|
||||
# configurable user account
|
||||
ip addr add 192.168.10.2/24 dev eth0
|
||||
ip route add default via 192.168.10.1
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
cpu_limit: 100
|
||||
cpus: 1
|
||||
data_volume: 0
|
||||
hide_links: false
|
||||
id: n0
|
||||
image_definition: null
|
||||
label: PC
|
||||
node_definition: desktop
|
||||
parameters: {}
|
||||
ram: 512
|
||||
tags: []
|
||||
x: 742
|
||||
y: 91
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: 16
|
||||
configuration:
|
||||
- name: iosxe_config.txt
|
||||
content: |-
|
||||
# this is a shell script which will be sourced at boot
|
||||
hostname server
|
||||
# configurable user account
|
||||
USERNAME=cisco
|
||||
PASSWORD=cisco
|
||||
ifconfig eth0 inet 192.168.20.2 netmask 255.255.255.0
|
||||
route add default gw 192.168.20.1
|
||||
# no password for tc user by default
|
||||
TC_PASSWORD=
|
||||
cpu_limit: 100
|
||||
cpus: 1
|
||||
data_volume: 0
|
||||
hide_links: false
|
||||
id: n1
|
||||
image_definition: server-tcl-11-1
|
||||
label: server
|
||||
node_definition: server
|
||||
parameters: {}
|
||||
ram: 128
|
||||
tags: []
|
||||
x: 552
|
||||
y: 440
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: eth0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
!
|
||||
hostname RTR
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip cef
|
||||
login on-success log
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
multilink bundle-name authenticated
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
memory free low-watermark processor 81225
|
||||
!
|
||||
!
|
||||
spanning-tree mode rapid-pvst
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface Ethernet0/0
|
||||
no ip address
|
||||
no shutdown
|
||||
!
|
||||
interface Ethernet0/1
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
interface Ethernet0/2
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
interface Ethernet0/3
|
||||
no ip address
|
||||
shutdown
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
!
|
||||
no ip http server
|
||||
no ip http secure-server
|
||||
ip ssh bulk-mode 131072
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
!
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
logging synchronous
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
login
|
||||
transport input none
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n2
|
||||
image_definition: null
|
||||
label: RTR
|
||||
node_definition: iol-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 941
|
||||
y: 260
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
no service password-encryption
|
||||
service compress-config
|
||||
!
|
||||
hostname SW1
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip cef
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
vtp mode transparent
|
||||
spanning-tree mode pvst
|
||||
spanning-tree extend system-id
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface GigabitEthernet0/0
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/1
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/2
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/3
|
||||
negotiation auto
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
ip http server
|
||||
ip http secure-server
|
||||
!
|
||||
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n3
|
||||
image_definition: null
|
||||
label: SW1
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 740
|
||||
y: 263
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
- boot_disk_size: null
|
||||
configuration:
|
||||
- name: ios_config.txt
|
||||
content: |-
|
||||
service timestamps debug datetime msec
|
||||
service timestamps log datetime msec
|
||||
no service password-encryption
|
||||
service compress-config
|
||||
!
|
||||
hostname SW2
|
||||
!
|
||||
boot-start-marker
|
||||
boot-end-marker
|
||||
!
|
||||
!
|
||||
!
|
||||
no aaa new-model
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
ip cef
|
||||
no ipv6 cef
|
||||
!
|
||||
!
|
||||
!
|
||||
vtp mode transparent
|
||||
spanning-tree mode pvst
|
||||
spanning-tree extend system-id
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
interface GigabitEthernet0/0
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/1
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/2
|
||||
negotiation auto
|
||||
!
|
||||
interface GigabitEthernet0/3
|
||||
negotiation auto
|
||||
!
|
||||
ip forward-protocol nd
|
||||
!
|
||||
ip http server
|
||||
ip http secure-server
|
||||
!
|
||||
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
!
|
||||
control-plane
|
||||
!
|
||||
!
|
||||
line con 0
|
||||
exec-timeout 0 0
|
||||
line aux 0
|
||||
line vty 0 4
|
||||
!
|
||||
!
|
||||
end
|
||||
cpu_limit: null
|
||||
cpus: null
|
||||
data_volume: null
|
||||
hide_links: false
|
||||
id: n4
|
||||
image_definition: null
|
||||
label: SW2
|
||||
node_definition: ioll2-xe
|
||||
parameters: {}
|
||||
ram: null
|
||||
tags: []
|
||||
x: 552
|
||||
y: 265
|
||||
interfaces:
|
||||
- id: i0
|
||||
label: Loopback0
|
||||
mac_address: null
|
||||
type: loopback
|
||||
- id: i1
|
||||
label: Ethernet0/0
|
||||
mac_address: null
|
||||
slot: 0
|
||||
type: physical
|
||||
- id: i2
|
||||
label: Ethernet0/1
|
||||
mac_address: null
|
||||
slot: 1
|
||||
type: physical
|
||||
- id: i3
|
||||
label: Ethernet0/2
|
||||
mac_address: null
|
||||
slot: 2
|
||||
type: physical
|
||||
- id: i4
|
||||
label: Ethernet0/3
|
||||
mac_address: null
|
||||
slot: 3
|
||||
type: physical
|
||||
links:
|
||||
- id: l0
|
||||
n1: n3
|
||||
n2: n2
|
||||
i1: i1
|
||||
i2: i1
|
||||
conditioning: {}
|
||||
label: SW1-Ethernet0/0<->RTR-Ethernet0/0
|
||||
- id: l1
|
||||
n1: n3
|
||||
n2: n0
|
||||
i1: i2
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: SW1-Ethernet0/1<->PC-eth0
|
||||
- id: l2
|
||||
n1: n4
|
||||
n2: n1
|
||||
i1: i1
|
||||
i2: i0
|
||||
conditioning: {}
|
||||
label: iol-l2-0-Ethernet0/0<->server-eth0
|
||||
- id: l3
|
||||
n1: n4
|
||||
n2: n3
|
||||
i1: i2
|
||||
i2: i3
|
||||
conditioning: {}
|
||||
label: iol-l2-0-Ethernet0/1<->SW1-Ethernet0/2
|
||||
lab:
|
||||
description: ''
|
||||
notes: |-
|
||||
# CCNA: Implement Multiple VLANs and Basic Routing Between the VLANs
|
||||
In this lab you need to do the following:
|
||||
- Implement VLAN assignments on two switches
|
||||
- Configure a dot1q trunk between those switches
|
||||
- Configure a dot1q trunk between one switch and a router that will handle the routing for the VLANs
|
||||
- Configure VLAN trunking on that router to act as a gateway between VLANs
|
||||
- Verify that connectivity exists between hosts in the lab on each VLAN, and that the connectivity goes through the router
|
||||
title: Sample Lab 1 FREE (VLAN Configuration)
|
||||
version: 0.3.0
|
@@ -10,8 +10,37 @@ A valid vEOS image can be downloaded the through Arista support portal. https://
|
||||
|
||||
### Notes
|
||||
|
||||
This node definition uses recommended values for vEOS instances. However, lowering the DRAM to 1.5GB should theoritically work but YMMV.
|
||||
This node definition uses recommended values for vEOS instances. However, lowering the DRAM to 1.5GB should theoritically work but YMMV.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> For day0 configuration (`veos_usr.dat` file on ISO drive labeled `ARISTA_CONFIG_DRIVE`) to work, you must boot the QCOW2 image from Arista, allow it to install the full `vEOS-lab.swi` image, touch the file `/mnt/flash/kickstart-config`, then shut the system down. This image will become your base QCOW2 image to load into CML.
|
||||
|
||||
* First boot the raw image:
|
||||
|
||||
```
|
||||
...
|
||||
Data in /mnt/flash/vEOS-lab.swi differs from previous boot image on /mnt/flash.
|
||||
Saving new boot image to /mnt/flash...
|
||||
...
|
||||
localhost login: admin
|
||||
localhost>en
|
||||
localhost#bash
|
||||
|
||||
Arista Networks EOS shell
|
||||
|
||||
[admin@localhost ~]$ sudo cat /mnt/flash/.CloudInitLogs
|
||||
Execute sudo mount /dev/disk/by-label/ARISTA_CONFIG_DRIVE /tmp/userdata8c9kqk8e
|
||||
Output:
|
||||
Erorr : b'mount: /tmp/userdata8c9kqk8e: WARNING: source write-protected, mounted read-only.\n'
|
||||
Caught exception [Errno 2] No such file or directory: '/mnt/flash/kickstart-config'. Ignoring KVM CloudInit
|
||||
Execute sudo umount /tmp/userdata8c9kqk8e
|
||||
Output:
|
||||
Erorr : b''
|
||||
CloudInit done !
|
||||
|
||||
[admin@localhost ~]$ sudo touch /mnt/flash/kickstart-config
|
||||
[admin@localhost ~]$ sudo shutdown -h now
|
||||
```
|
||||
|
||||
* [Collapse/Flatten](https://blog.programster.org/qemu-img-cheatsheet#collapse-all-images) image as normal and copy to a new image definition.
|
||||
|
||||
|
@@ -1,24 +1,28 @@
|
||||
id: vEOS
|
||||
general:
|
||||
description: Arista vEOS
|
||||
description: |-
|
||||
Arista vEOS.
|
||||
|
||||
Username: admin Password: <no-password> / admin
|
||||
nature: switch
|
||||
read_only: false
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: true
|
||||
physical:
|
||||
- eth0
|
||||
- eth2
|
||||
- eth3
|
||||
- eth4
|
||||
- eth5
|
||||
- eth6
|
||||
- eth7
|
||||
- eth9
|
||||
- eth10
|
||||
- eth11
|
||||
- eth12
|
||||
- eth13
|
||||
- Ma1
|
||||
- Et1
|
||||
- Et2
|
||||
- Et3
|
||||
- Et4
|
||||
- Et5
|
||||
- Et6
|
||||
- Et7
|
||||
- Et8
|
||||
- Et9
|
||||
- Et10
|
||||
- Et11
|
||||
- Et12
|
||||
serial_ports: 1
|
||||
default_count: 5
|
||||
loopback:
|
||||
@@ -45,6 +49,7 @@ sim:
|
||||
nic_driver: virtio
|
||||
boot:
|
||||
timeout: 180
|
||||
uses_regex: false
|
||||
inherited:
|
||||
image:
|
||||
ram: true
|
||||
@@ -61,4 +66,33 @@ inherited:
|
||||
configuration:
|
||||
generator:
|
||||
driver: null
|
||||
provisioning:
|
||||
volume_name: ARISTA_CONFIG_DRIVE
|
||||
media_type: iso
|
||||
files:
|
||||
- name: veos_usr.dat
|
||||
editable: true
|
||||
content: |-
|
||||
%EOS-STARTUP-CONFIG-START%
|
||||
!
|
||||
no aaa root
|
||||
!
|
||||
username admin privilege 15 role network-admin secret 0 admin
|
||||
!
|
||||
switchport default mode access
|
||||
!
|
||||
logging console debugging
|
||||
!
|
||||
hostname inserthostname-here
|
||||
!
|
||||
interface Ethernet1
|
||||
!
|
||||
interface Management1
|
||||
!
|
||||
ip routing
|
||||
!
|
||||
end
|
||||
%EOS-STARTUP-CONFIG-END%
|
||||
%CLOUDHA-CONFIG-START%
|
||||
%CLOUDHA-CONFIG-END%
|
||||
schema_version: 0.0.1
|
||||
|
36
node-definitions/cisco/ucspe/README.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# UCS Platform Emulator (UCSPE)
|
||||
|
||||
## Introduction
|
||||
|
||||
The UCS Platform Emulator is an all-in-one VM that provides a UCS Fabric Interconnect/UCS Manager experience.
|
||||
It supports loadable firmware and compute operations.
|
||||
|
||||
The UCSPE releases are discussed in Cisco [community posts](https://community.cisco.com/t5/custom/page/page-id/customFilteredByMultiLabel?board=6011-docs-dc-ucs&labels=ucs%20platform%20emulator).
|
||||
|
||||
## Image Support
|
||||
|
||||
All UCSPE images should work in CML; however, KVM is not an officially supported hypervisor. To use UCSPE,
|
||||
download the respective OVA image from one of the version-specific community posts (the downloads require
|
||||
login and are linked from the community).
|
||||
|
||||
Then, extract the vmdk file from the OVA with the `tar` command. This is built-in on macOS and Linux, and
|
||||
you can perform these same steps on WSL on Windows.
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
tar -xf UCSPE_4.2.2aS9.ova UCSPE_4.2.2aS9-disk1.vmdk
|
||||
```
|
||||
|
||||
Next, convert the vmdk file to qcow2 format using the `qemu-img` tool (part of the `qemu` package).
|
||||
|
||||
Example:
|
||||
|
||||
```bash
|
||||
qemu-img convert -c -f vmdk -O qcow2 UCSPE_4.2.2aS9-disk1.vmdk ucspe_4.2.2aS9s.qcow2
|
||||
```
|
||||
|
||||
The `-c` argument is optional, but provides some compression, thus making for a smaller overall qcow2 file
|
||||
size.
|
||||
|
||||
Once converted, upload the qcow2 file to CML and create a new image definition for the _UCSPE_ node.
|
67
node-definitions/cisco/ucspe/ucspe.yaml
Normal file
@@ -0,0 +1,67 @@
|
||||
id: ucspe
|
||||
general:
|
||||
description: |-
|
||||
UCS Platform Emulator
|
||||
|
||||
1 vCPU / 2 GB RAM
|
||||
|
||||
[Cisco Community Documentation](https://community.cisco.com/t5/custom/page/page-id/customFilteredByMultiLabel?board=6011-docs-dc-ucs&labels=ucs%20platform%20emulator)
|
||||
nature: server
|
||||
read_only: false
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: false
|
||||
physical:
|
||||
- ethernet0
|
||||
- ethernet1
|
||||
- ethernet2
|
||||
serial_ports: 1
|
||||
min_count: 3
|
||||
default_count: 3
|
||||
ui:
|
||||
visible: true
|
||||
description: |-
|
||||
UCS Platform Emulator
|
||||
|
||||
1 vCPU / 2 GB RAM
|
||||
|
||||
Cisco UCS Platform Emulator is the Cisco UCS Manager application bundled into a virtual machine (VM).The
|
||||
VM includes software that emulates hardware communications for the Cisco Unified Computing System
|
||||
(Cisco UCS) hardware that is configured and managed by Cisco UCS Manager. For example, you can use
|
||||
Cisco UCS Platform Emulator to create and test a supported Cisco UCS configuration, or to duplicate an
|
||||
existing Cisco UCS environment for troubleshooting or development purposes.
|
||||
label_prefix: ucspe-
|
||||
icon: server
|
||||
label: UCSPE
|
||||
sim:
|
||||
linux_native:
|
||||
libvirt_domain_driver: kvm
|
||||
driver: server
|
||||
disk_driver: virtio
|
||||
ram: 2048
|
||||
cpus: 1
|
||||
cpu_limit: 100
|
||||
nic_driver: e1000
|
||||
boot_disk_size: 20
|
||||
boot:
|
||||
timeout: 900
|
||||
uses_regex: true
|
||||
completed:
|
||||
- 'login:'
|
||||
inherited:
|
||||
image:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
node:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
configuration:
|
||||
generator:
|
||||
driver: null
|
||||
schema_version: 0.0.1
|
@@ -3,15 +3,20 @@ configuration:
|
||||
generator:
|
||||
driver: csr1000v
|
||||
provisioning:
|
||||
volume_name: disk
|
||||
volume_name: CDROM
|
||||
media_type: iso
|
||||
files:
|
||||
- name: iosxe_config.txt
|
||||
content: hostname inserthostname_here
|
||||
content: |-
|
||||
platform console serial
|
||||
hostname C9800-CL
|
||||
!
|
||||
end
|
||||
editable: true
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: true
|
||||
min_count: 4
|
||||
default_count: 4
|
||||
loopback:
|
||||
- Loopback0
|
||||
@@ -29,17 +34,19 @@ inherited:
|
||||
image:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: false
|
||||
boot_disk_size: false
|
||||
node:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: false
|
||||
boot_disk_size: false
|
||||
general:
|
||||
description: Cisco Catalyst 9800 Wireless Controller for Cloud
|
||||
nature: switch
|
||||
read_only: true
|
||||
read_only: false
|
||||
schema_version: 0.0.1
|
||||
boot:
|
||||
timeout: 300
|
||||
@@ -47,6 +54,7 @@ boot:
|
||||
- 'Would you like to enter the initial configuration dialog? [yes/no]:'
|
||||
- '%SYS-5-RESTART: System restarted'
|
||||
- 'INFO: Press RETURN to get started!'
|
||||
uses_regex: false
|
||||
sim:
|
||||
linux_native:
|
||||
cpus: 2
|
||||
@@ -54,18 +62,21 @@ sim:
|
||||
driver: server
|
||||
libvirt_domain_driver: kvm
|
||||
nic_driver: virtio
|
||||
ram: 8192
|
||||
ram: 6144
|
||||
cpu_limit: 100
|
||||
video:
|
||||
memory: 16
|
||||
model: vga
|
||||
memory: 1
|
||||
pyats:
|
||||
os: iosxe
|
||||
series: csr1000v
|
||||
config_extract_command: show run
|
||||
use_in_testbed: true
|
||||
ui:
|
||||
description: |-
|
||||
Cisco Catalyst 9800 Wireless Controller for Cloud
|
||||
|
||||
8 GB DRAM, 2 vCPU
|
||||
6 GB DRAM, 2 vCPU
|
||||
|
||||
[CCO Link](https://www.cisco.com/c/en/us/support/wireless/catalyst-9800-wireless-controllers-cloud/tsd-products-support-series-home.html)
|
||||
group: Others
|
||||
|
75
node-definitions/freebsd/FreeBSD.yaml
Normal file
@@ -0,0 +1,75 @@
|
||||
id: FreeBSD
|
||||
general:
|
||||
nature: server
|
||||
description: FreeBSD with "nuage-init" (a limited version of cloud-init).
|
||||
read_only: false
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: true
|
||||
physical:
|
||||
- vtnet0
|
||||
- vtnet1
|
||||
- vtnet2
|
||||
- vtnet3
|
||||
- vtnet4
|
||||
- vtnet5
|
||||
- vtnet6
|
||||
- vtnet7
|
||||
serial_ports: 1
|
||||
loopback:
|
||||
- lo0
|
||||
min_count: 1
|
||||
default_count: 2
|
||||
ui:
|
||||
visible: true
|
||||
label_prefix: fBSD-
|
||||
icon: server
|
||||
label: FreeBSD
|
||||
sim:
|
||||
linux_native:
|
||||
libvirt_domain_driver: kvm
|
||||
driver: server
|
||||
disk_driver: sata
|
||||
ram: 1024
|
||||
cpus: 1
|
||||
cpu_limit: 100
|
||||
nic_driver: virtio
|
||||
boot:
|
||||
completed:
|
||||
- 'login:'
|
||||
timeout: 300
|
||||
uses_regex: false
|
||||
inherited:
|
||||
image:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
node:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
configuration:
|
||||
generator:
|
||||
driver: server
|
||||
provisioning:
|
||||
volume_name: cidata
|
||||
media_type: iso
|
||||
files:
|
||||
- name: meta-data
|
||||
editable: true
|
||||
content: |-
|
||||
instance-id: freebsd-01
|
||||
local-hostname: freebsd-01
|
||||
- name: user-data
|
||||
editable: true
|
||||
content: |-
|
||||
#cloud-config
|
||||
users:
|
||||
- name: cisco
|
||||
plain_text_passwd: cisco
|
||||
groups: wheel
|
||||
schema_version: 0.0.1
|
58
node-definitions/freebsd/README.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# FreeBSD in CML
|
||||
|
||||
Instructions for running a basic FreeBSD node in Cisco Modeling Lab.
|
||||
|
||||
# Deployable image
|
||||
|
||||
A pre-built FreeBSD image is available
|
||||
[here](https://download.freebsd.org/snapshots/VM-IMAGES/14.1-STABLE/amd64/Latest/FreeBSD-14.1-STABLE-amd64-BASIC-CLOUDINIT.ufs.qcow2.xz).
|
||||
|
||||
In Linux the above image can be decomressed with:
|
||||
|
||||
xz --decompress FreeBSD-14.1-STABLE-amd64-BASIC-CLOUDINIT.ufs.qcow2.xz
|
||||
|
||||
From there the qcow2 file can be imported into CML.
|
||||
|
||||
By default the FreeBSD image is configured to use DHCP. It also supports a
|
||||
native serial console which is ideal for CML.
|
||||
|
||||
# FreeBSD node definition
|
||||
|
||||
A FreeBSD [node definition](FreeBSD.yaml) is include in this directory.
|
||||
|
||||
# Limitations and future work
|
||||
|
||||
The FreeBSD 14.1 "Basic Cloud-init" image comes with "nuage-init" rather than
|
||||
"cloud-init". Nuage-init does not support all options that are available in
|
||||
cloud-init. A base configuration is provided in this
|
||||
[node definition](FreeBSD.yaml).
|
||||
|
||||
If the CML node has Internet connectivity it is possible to use the package
|
||||
manager to install cloud-init. This will allow you to use cloud-init on
|
||||
subsequent boots. This approach may have limited utility if you are using
|
||||
Terraform to provision the CML node.
|
||||
|
||||
## Nuage-init: MAC address required
|
||||
|
||||
If you are attempting to use Nuage-init in order to set an IP address please
|
||||
have a look at the [source code](https://github.com/freebsd/freebsd-src/blob/f35ccf46c7c6cb7d26994ec5dc5926ea53be0116/libexec/nuageinit/nuageinit#L283-L293).
|
||||
|
||||
Nuage-init will explicitly check to see that there is an ```ethernets```
|
||||
section with a ```match``` subsection. The only working match clause is the
|
||||
```macaddress``` clause. If you do not explicitly state the MAC address of
|
||||
your NIC it will not be able to set an IP address. Both DHCP and IPv6 are
|
||||
supported.
|
||||
|
||||
The following ```user-data``` example will set the IP address of the NIC with
|
||||
the specified MAC address to 192.0.2.10/24.
|
||||
|
||||
```yaml
|
||||
network:
|
||||
version: 2
|
||||
ethernets:
|
||||
id0:
|
||||
match:
|
||||
macaddress: 'aa:bb:cc:00:11:22'
|
||||
addresses:
|
||||
- 192.0.2.10/24
|
||||
```
|
94
node-definitions/openbsd/OpenBSD.yaml
Normal file
@@ -0,0 +1,94 @@
|
||||
id: OpenBSD
|
||||
general:
|
||||
description: OpenBSD Firewall / Router / Server / Host
|
||||
nature: firewall
|
||||
read_only: false
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: true
|
||||
physical:
|
||||
- em0
|
||||
- em1
|
||||
- em2
|
||||
- em3
|
||||
- em4
|
||||
- em5
|
||||
- em6
|
||||
- em7
|
||||
serial_ports: 1
|
||||
default_count: 2
|
||||
loopback:
|
||||
- lo0
|
||||
ui:
|
||||
visible: true
|
||||
label_prefix: oBSD-
|
||||
icon: firewall
|
||||
label: OpenBSD
|
||||
sim:
|
||||
linux_native:
|
||||
libvirt_domain_driver: kvm
|
||||
driver: server
|
||||
disk_driver: sata
|
||||
ram: 1024
|
||||
cpus: 1
|
||||
nic_driver: e1000
|
||||
cpu_limit: 100
|
||||
boot:
|
||||
timeout: 300
|
||||
completed:
|
||||
- 'login:'
|
||||
uses_regex: false
|
||||
inherited:
|
||||
image:
|
||||
ram: true
|
||||
cpus: true
|
||||
data_volume: false
|
||||
boot_disk_size: false
|
||||
cpu_limit: true
|
||||
node:
|
||||
ram: true
|
||||
cpus: true
|
||||
data_volume: false
|
||||
boot_disk_size: false
|
||||
cpu_limit: true
|
||||
configuration:
|
||||
generator:
|
||||
driver: server
|
||||
provisioning:
|
||||
volume_name: cidata
|
||||
media_type: iso
|
||||
files:
|
||||
- name: meta-data
|
||||
editable: true
|
||||
content: |-
|
||||
instance-id: openbsd
|
||||
local-hostname: openbsd
|
||||
- name: user-data
|
||||
editable: true
|
||||
content: |-
|
||||
#cloud-config
|
||||
# Docs: https://cloudinit.readthedocs.io/en/latest/explanation/about-cloud-config.html
|
||||
|
||||
hostname: openbsd76p1
|
||||
|
||||
write_files:
|
||||
- path: /etc/motd
|
||||
content: |
|
||||
##########################################################
|
||||
## A sample message of the day. ##
|
||||
##########################################################
|
||||
- name: network-config
|
||||
editable: true
|
||||
content: |-
|
||||
#cloud-config
|
||||
# Docs: https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v1.html
|
||||
network:
|
||||
version: 1
|
||||
config:
|
||||
- type: physical
|
||||
name: em0
|
||||
subnets:
|
||||
- type: dhcp
|
||||
- name: vendor-data
|
||||
editable: true
|
||||
schema_version: 0.0.1
|
270
node-definitions/openbsd/README.md
Normal file
@@ -0,0 +1,270 @@
|
||||
# OpenBSD-CML
|
||||
|
||||
Instructions for building an OpenBSD node in Cisco Modeling Lab
|
||||
|
||||
## Why OpenBSD in CML?
|
||||
|
||||
OpenBSD is standards-compliant, has good documentation, and is secure.
|
||||
|
||||
OpenBSD can act as a router, a routed layer 3 firewall, a NAT boundary, a
|
||||
bridging Layer-3 firewall, an end host, a webserver, a load balancer, and many
|
||||
other roles not mentioned here.
|
||||
|
||||
# Deployable image
|
||||
|
||||
A pre-built OpenBSD CML image is available
|
||||
[here](https://cml-images.nerdops.io/).
|
||||
|
||||
The instructions below were used to create the image.
|
||||
|
||||
# Create a qcow2 OpenBSD VM
|
||||
|
||||
## Create the VM
|
||||
|
||||
Resources required for initially building the VM can differ from the resources
|
||||
required for running an instance of that VM in CML.
|
||||
|
||||
As resources in CML are generally scarce I suggest starting with a fairly
|
||||
minimal configuration while building the VM. Although it's generally possible
|
||||
to increase the resources at runtime it's hard to decrease them.
|
||||
|
||||
* RAM: 1GB
|
||||
* Disk: 8GB
|
||||
* CPU: 1
|
||||
* Network: single interface with Internet access (used to install patches and
|
||||
upgrades)
|
||||
|
||||
When running an instance of this VM in CML it is possible (and even likely)
|
||||
that you will add aditional network interfaces or increase the RAM or Disk
|
||||
space. RAM, Disk, and Network are all easily increased in your CML config.
|
||||
|
||||
During the install process OpenBSD will either install a single-CPU kernel or a
|
||||
multi-CPU kernel. If you want to use a multi-CPU kernel you will need to
|
||||
create the VM with more than one CPU. It is possible to change the kernel
|
||||
after the fact but it's easier to just create the VM with more than one
|
||||
CPU. As this is a destined for a lab environment I suggest creating the VM
|
||||
with only one CPU.
|
||||
|
||||
Although I used VMWare to build this image it should be mostly the same to use
|
||||
other platforms (VirtualBox, QEMU, KVM, etc).
|
||||
|
||||
## Install OpenBSD
|
||||
|
||||
I used the amd64
|
||||
[install76.iso](https://cdn.openbsd.org/pub/OpenBSD/7.6/amd64/install76.iso)
|
||||
image to perform a base install. I did not install games nor any of the x11
|
||||
packages (just to save space).
|
||||
|
||||
I used ```cisco``` for the root password. I disabled root SSH logins out of
|
||||
habit.
|
||||
|
||||
### Partitioning
|
||||
|
||||
Although auto partitioning is sufficient for this, I created a single
|
||||
partition in order to both use the entire disk and to avoid the need to create
|
||||
a swap partition.
|
||||
|
||||
### Users
|
||||
|
||||
I created a second user named ```cisco``` with the same password.
|
||||
|
||||
## First boot
|
||||
|
||||
Once the base system is installed reboot and log in as root.
|
||||
|
||||
Right away you should check for updates:
|
||||
|
||||
syspatch
|
||||
pkg_add -u
|
||||
|
||||
### Install additional packages
|
||||
|
||||
This is an exellent opportunity to install some of the packages that are
|
||||
useful for network operations. Of course, it may be possible to install
|
||||
these packages later if your labs have Internet connectivity.
|
||||
|
||||
If you intend to use ```cloud-init``` you will need to install git:
|
||||
|
||||
pkg_add git
|
||||
|
||||
#### Install now
|
||||
|
||||
The benefit of installing packages now is that they will be available
|
||||
for use immediately on all instances of the node. The downsiide is that
|
||||
it will occupy more space on the image.
|
||||
|
||||
These packages have been extremely useful through the years:
|
||||
|
||||
pkg_add mtr-- wget gnuwatch nmap wireguard-tools
|
||||
|
||||
Please note the ```--``` in ```mtr--```. If ```mtr``` is specified without
|
||||
the ```--``` the ```pkg_add``` command will ask the user which version is
|
||||
desired; normal MTR or MTR with GTK support. By using the ```--``` suffix the
|
||||
non-GTK version is installed.
|
||||
|
||||
#### Install later
|
||||
|
||||
If there is Internet connectivity for the instance at runtime it is also
|
||||
possible to install these packages later. This will save space on the image.
|
||||
|
||||
To install at runtime, become root on the instance and run the following
|
||||
command:
|
||||
|
||||
pkg_add mtr-- wget gnuwatch nmap wireguard-tools
|
||||
|
||||
Alternatively, if you are using ```cloud-init``` you can include a
|
||||
```packages``` section in your ```user-data``` file. For example:
|
||||
|
||||
```yaml
|
||||
#cloud-config
|
||||
packages:
|
||||
- mtr--
|
||||
- wget
|
||||
- gnuwatch
|
||||
- nmap
|
||||
- wireguard-tools
|
||||
```
|
||||
|
||||
### Add username and password hints
|
||||
|
||||
If some other admin tries to use your newly minted node it would be nice if
|
||||
they can easily see what username and password to use. This will appear on
|
||||
the serial console.
|
||||
|
||||
Update the ```/etc/gettytab``` file. Replace the existing default section with
|
||||
this:
|
||||
|
||||
default:\
|
||||
:np:im=\r\n%s/%m (%h) (%t)\r\n\
|
||||
************************\r\n\
|
||||
* Console login *\r\n\
|
||||
* username = root *\r\n\
|
||||
* password = cisco *\r\n\
|
||||
* *\r\n\
|
||||
* General login (SSH) *\r\n\
|
||||
* username = cisco *\r\n\
|
||||
* password = cisco *\r\n\
|
||||
************************\r\n\
|
||||
\r\n:sp#1200:
|
||||
|
||||
### Enable IP forwarding
|
||||
|
||||
Enable IP forwarding. By default this is turned off. This isn't strictly
|
||||
required for an end host nor webserver; but it's a step easily missed.
|
||||
|
||||
echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf
|
||||
|
||||
### cloud-init
|
||||
|
||||
```cloud-init``` is a tool that allows you to configure a VM on first boot.
|
||||
This allows you to configure a VM without having to use the VM's console.
|
||||
|
||||
#### Install cloud-init
|
||||
|
||||
There is no pre-built ```cloud-init``` package for OpenBSD. However, it's not
|
||||
difficult to install it from source:
|
||||
|
||||
git clone https://github.com/canonical/cloud-init.git
|
||||
cd cloud-init
|
||||
./tools/build-on-openbsd
|
||||
|
||||
If it was successful you should see several ```cloud-init``` commands
|
||||
in ```/etc/rc.local```. These commands will be run on boot.
|
||||
|
||||
#### Configure cloud-init
|
||||
|
||||
By it's very nature ```cloud-init``` is typically used with a cloud provider
|
||||
with access to the Internet. As the intent here is to build a VM that will run
|
||||
inside a CML environment it is necessary to configure ```cloud-init``` to look
|
||||
for a local data source.
|
||||
|
||||
Edit ```/etc/cloud/cloud.cfg``` and add the following:
|
||||
|
||||
datasource_list: ["NoCloud"]
|
||||
datasource:
|
||||
NoCloud:
|
||||
fs_label: cidata
|
||||
|
||||
The configuration above will look for a mounted CDROM with a label of
|
||||
```cidata``` during the boot process. The following files will be read (if
|
||||
present):
|
||||
|
||||
* ```meta-data```
|
||||
* ```user-data```
|
||||
* ```network-config```
|
||||
* ```vendor-data```
|
||||
|
||||
The files above are optional. Please note that they do not have a file
|
||||
extension (there is no ```.yml``` extension).
|
||||
|
||||
#### Configure the boot process
|
||||
|
||||
By default ```cloud-init``` will populate the ```/etc/rc.local``` file. The
|
||||
```ds-identify``` command will be run by default but is not required since
|
||||
the datasource is already configured. I recommend commenting out this line
|
||||
in order to speed up the boot process.
|
||||
|
||||
### Enable logins on serial console
|
||||
|
||||
Enable serial console to provide a login prompt
|
||||
Edit ```/etc/ttys``` so that ```tty00``` reads as:
|
||||
|
||||
tty00 "/usr/libexec/getty std.9600" vt220 on secure
|
||||
|
||||
This file uses a combination of tabs and spaces. It will work fine if you only
|
||||
use spaces. Copying and pasting from this README will work fine.
|
||||
|
||||
NB: you can output to a serial console without being able to login on it. This
|
||||
step enables that login.
|
||||
|
||||
## Snapshot
|
||||
|
||||
Now is a good time to create a snapshot of your VM. This point in the install
|
||||
it's still fairly easy to install future patches and additional software.
|
||||
|
||||
## Finalize the image
|
||||
|
||||
These commands will enable output to the serial console needed for CML and
|
||||
cleanup the original network interface. It's hard to undo these (but not
|
||||
impossible).
|
||||
|
||||
# remove the network interface config that was created by the installer:
|
||||
rm /etc/hostname.em0
|
||||
# remove the SSH host keys that were generated during the boot:
|
||||
rm /etc/ssh/ssh_host_*
|
||||
# remove the configuration files that cloud-init created:
|
||||
rm -r /var/lib/cloud
|
||||
rm -r /var/run/cloud-init
|
||||
# redirect the default console to the serial console:
|
||||
echo "set tty com0" > /etc/boot.conf
|
||||
# shutdown and power off the VM:
|
||||
shutdown -p now
|
||||
|
||||
## Create a clone of the VM
|
||||
|
||||
This is the last step before exporting your image to a qcow2 file.
|
||||
|
||||
If you attempt to convert the VMWare image to a qcow2 image from the
|
||||
snapshotted VMDKs above you will end up with a non-bootable image. I do not
|
||||
understand why. I suspect it is due to how qemu-img handles snapshots. For
|
||||
best success I recommend you clone your VM to get a flattened VMDK image. I
|
||||
had success with ```Clone to Template...``` in VMWare.
|
||||
|
||||
## Convert VM to qcow2
|
||||
|
||||
This step is not required if you already have a qcow2 image. VMWare provides
|
||||
a series of VMDK files which need to be converted.
|
||||
|
||||
Copy all of the VMDK files from your image to someplace where you can run the
|
||||
```qemu-img``` tool (available in Linux).
|
||||
|
||||
qemu-img convert -f vmdk -O qcow2 <base filename.vmdk> <target qcow2 filename>
|
||||
|
||||
If you receive an error you may be specifying the wrong base VMDK file. Look
|
||||
for the smallest VMDK file and use it.
|
||||
|
||||
Now you can export your qcow2 image for use in CML.
|
||||
|
||||
## OpenBSD node definition
|
||||
|
||||
An OpenBSD [node definition](OpenBSD.yaml) is include in this directory.
|
14
node-definitions/sonic/README.md
Normal file
@@ -0,0 +1,14 @@
|
||||
This directory contains the node definition for SONiC
|
||||
|
||||
|
||||
# Notes
|
||||
|
||||
default username and password are admin/YourPaSsWoRd
|
||||
mgmt interface defaults to dhcp
|
||||
|
||||
download community image here: https://sonic.software
|
||||
documentation can be found here: https://github.com/sonic-net/sonic/wiki
|
||||
|
||||

|
||||
|
||||

|
58
node-definitions/sonic/SONiCv.yaml
Normal file
@@ -0,0 +1,58 @@
|
||||
id: SONiCv
|
||||
general:
|
||||
nature: switch
|
||||
read_only: false
|
||||
device:
|
||||
interfaces:
|
||||
has_loopback_zero: true
|
||||
physical:
|
||||
- Eth0
|
||||
- Ethernet0
|
||||
- Ethernet4
|
||||
- Ethernet8
|
||||
- Ethernet12
|
||||
- Ethernet16
|
||||
- Ethernet20
|
||||
- Ethernet24
|
||||
- Ethernet28
|
||||
serial_ports: 1
|
||||
default_count: 9
|
||||
loopback:
|
||||
- Loopback0
|
||||
ui:
|
||||
visible: true
|
||||
label_prefix: SONiCv-
|
||||
icon: switch
|
||||
label: SONiC Virtual Switch (VM)
|
||||
sim:
|
||||
linux_native:
|
||||
libvirt_domain_driver: kvm
|
||||
driver: server
|
||||
disk_driver: virtio
|
||||
ram: 4096
|
||||
cpus: 2
|
||||
cpu_limit: 100
|
||||
nic_driver: e1000
|
||||
efi_boot: false
|
||||
boot:
|
||||
completed:
|
||||
- sonic login
|
||||
timeout: 240
|
||||
uses_regex: false
|
||||
inherited:
|
||||
image:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
node:
|
||||
ram: true
|
||||
cpus: true
|
||||
cpu_limit: true
|
||||
data_volume: true
|
||||
boot_disk_size: true
|
||||
configuration:
|
||||
generator:
|
||||
driver: null
|
||||
schema_version: 0.0.1
|
BIN
readme_images/cml-lab.png
Normal file
After Width: | Height: | Size: 331 KiB |
Before Width: | Height: | Size: 78 KiB |
BIN
readme_images/sandbox-catalog-cml.png
Normal file
After Width: | Height: | Size: 100 KiB |
BIN
readme_images/sonic-boot.png
Normal file
After Width: | Height: | Size: 184 KiB |
BIN
readme_images/sonic-ifconfig.png
Normal file
After Width: | Height: | Size: 551 KiB |
131
scripts/brk2iterm/Pipfile.lock
generated
@@ -18,78 +18,79 @@
|
||||
"default": {
|
||||
"jinja2": {
|
||||
"hashes": [
|
||||
"sha256:4a3aee7acbbe7303aede8e9648d13b8bf88a429282aa6122a993f0ac800cb369",
|
||||
"sha256:bc5dd2abb727a5319567b7a813e6a2e7318c39f4f487cfe6c89c6f9c7d25197d"
|
||||
"sha256:0137fb05990d35f1275a587e9aee6d56da821fc83491a0fb838183be43f66d6d",
|
||||
"sha256:85ece4451f492d0c13c5dd7c13a64681a86afae63a5f347908daf103ce6d2f67"
|
||||
],
|
||||
"index": "pypi",
|
||||
"markers": "python_version >= '3.7'",
|
||||
"version": "==3.1.4"
|
||||
"version": "==3.1.6"
|
||||
},
|
||||
"markupsafe": {
|
||||
"hashes": [
|
||||
"sha256:00e046b6dd71aa03a41079792f8473dc494d564611a8f89bbbd7cb93295ebdcf",
|
||||
"sha256:075202fa5b72c86ad32dc7d0b56024ebdbcf2048c0ba09f1cde31bfdd57bcfff",
|
||||
"sha256:0e397ac966fdf721b2c528cf028494e86172b4feba51d65f81ffd65c63798f3f",
|
||||
"sha256:17b950fccb810b3293638215058e432159d2b71005c74371d784862b7e4683f3",
|
||||
"sha256:1f3fbcb7ef1f16e48246f704ab79d79da8a46891e2da03f8783a5b6fa41a9532",
|
||||
"sha256:2174c595a0d73a3080ca3257b40096db99799265e1c27cc5a610743acd86d62f",
|
||||
"sha256:2b7c57a4dfc4f16f7142221afe5ba4e093e09e728ca65c51f5620c9aaeb9a617",
|
||||
"sha256:2d2d793e36e230fd32babe143b04cec8a8b3eb8a3122d2aceb4a371e6b09b8df",
|
||||
"sha256:30b600cf0a7ac9234b2638fbc0fb6158ba5bdcdf46aeb631ead21248b9affbc4",
|
||||
"sha256:397081c1a0bfb5124355710fe79478cdbeb39626492b15d399526ae53422b906",
|
||||
"sha256:3a57fdd7ce31c7ff06cdfbf31dafa96cc533c21e443d57f5b1ecc6cdc668ec7f",
|
||||
"sha256:3c6b973f22eb18a789b1460b4b91bf04ae3f0c4234a0a6aa6b0a92f6f7b951d4",
|
||||
"sha256:3e53af139f8579a6d5f7b76549125f0d94d7e630761a2111bc431fd820e163b8",
|
||||
"sha256:4096e9de5c6fdf43fb4f04c26fb114f61ef0bf2e5604b6ee3019d51b69e8c371",
|
||||
"sha256:4275d846e41ecefa46e2015117a9f491e57a71ddd59bbead77e904dc02b1bed2",
|
||||
"sha256:4c31f53cdae6ecfa91a77820e8b151dba54ab528ba65dfd235c80b086d68a465",
|
||||
"sha256:4f11aa001c540f62c6166c7726f71f7573b52c68c31f014c25cc7901deea0b52",
|
||||
"sha256:5049256f536511ee3f7e1b3f87d1d1209d327e818e6ae1365e8653d7e3abb6a6",
|
||||
"sha256:58c98fee265677f63a4385256a6d7683ab1832f3ddd1e66fe948d5880c21a169",
|
||||
"sha256:598e3276b64aff0e7b3451b72e94fa3c238d452e7ddcd893c3ab324717456bad",
|
||||
"sha256:5b7b716f97b52c5a14bffdf688f971b2d5ef4029127f1ad7a513973cfd818df2",
|
||||
"sha256:5dedb4db619ba5a2787a94d877bc8ffc0566f92a01c0ef214865e54ecc9ee5e0",
|
||||
"sha256:619bc166c4f2de5caa5a633b8b7326fbe98e0ccbfacabd87268a2b15ff73a029",
|
||||
"sha256:629ddd2ca402ae6dbedfceeba9c46d5f7b2a61d9749597d4307f943ef198fc1f",
|
||||
"sha256:656f7526c69fac7f600bd1f400991cc282b417d17539a1b228617081106feb4a",
|
||||
"sha256:6ec585f69cec0aa07d945b20805be741395e28ac1627333b1c5b0105962ffced",
|
||||
"sha256:72b6be590cc35924b02c78ef34b467da4ba07e4e0f0454a2c5907f473fc50ce5",
|
||||
"sha256:7502934a33b54030eaf1194c21c692a534196063db72176b0c4028e140f8f32c",
|
||||
"sha256:7a68b554d356a91cce1236aa7682dc01df0edba8d043fd1ce607c49dd3c1edcf",
|
||||
"sha256:7b2e5a267c855eea6b4283940daa6e88a285f5f2a67f2220203786dfa59b37e9",
|
||||
"sha256:823b65d8706e32ad2df51ed89496147a42a2a6e01c13cfb6ffb8b1e92bc910bb",
|
||||
"sha256:8590b4ae07a35970728874632fed7bd57b26b0102df2d2b233b6d9d82f6c62ad",
|
||||
"sha256:8dd717634f5a044f860435c1d8c16a270ddf0ef8588d4887037c5028b859b0c3",
|
||||
"sha256:8dec4936e9c3100156f8a2dc89c4b88d5c435175ff03413b443469c7c8c5f4d1",
|
||||
"sha256:97cafb1f3cbcd3fd2b6fbfb99ae11cdb14deea0736fc2b0952ee177f2b813a46",
|
||||
"sha256:a17a92de5231666cfbe003f0e4b9b3a7ae3afb1ec2845aadc2bacc93ff85febc",
|
||||
"sha256:a549b9c31bec33820e885335b451286e2969a2d9e24879f83fe904a5ce59d70a",
|
||||
"sha256:ac07bad82163452a6884fe8fa0963fb98c2346ba78d779ec06bd7a6262132aee",
|
||||
"sha256:ae2ad8ae6ebee9d2d94b17fb62763125f3f374c25618198f40cbb8b525411900",
|
||||
"sha256:b91c037585eba9095565a3556f611e3cbfaa42ca1e865f7b8015fe5c7336d5a5",
|
||||
"sha256:bc1667f8b83f48511b94671e0e441401371dfd0f0a795c7daa4a3cd1dde55bea",
|
||||
"sha256:bec0a414d016ac1a18862a519e54b2fd0fc8bbfd6890376898a6c0891dd82e9f",
|
||||
"sha256:bf50cd79a75d181c9181df03572cdce0fbb75cc353bc350712073108cba98de5",
|
||||
"sha256:bff1b4290a66b490a2f4719358c0cdcd9bafb6b8f061e45c7a2460866bf50c2e",
|
||||
"sha256:c061bb86a71b42465156a3ee7bd58c8c2ceacdbeb95d05a99893e08b8467359a",
|
||||
"sha256:c8b29db45f8fe46ad280a7294f5c3ec36dbac9491f2d1c17345be8e69cc5928f",
|
||||
"sha256:ce409136744f6521e39fd8e2a24c53fa18ad67aa5bc7c2cf83645cce5b5c4e50",
|
||||
"sha256:d050b3361367a06d752db6ead6e7edeb0009be66bc3bae0ee9d97fb326badc2a",
|
||||
"sha256:d283d37a890ba4c1ae73ffadf8046435c76e7bc2247bbb63c00bd1a709c6544b",
|
||||
"sha256:d9fad5155d72433c921b782e58892377c44bd6252b5af2f67f16b194987338a4",
|
||||
"sha256:daa4ee5a243f0f20d528d939d06670a298dd39b1ad5f8a72a4275124a7819eff",
|
||||
"sha256:db0b55e0f3cc0be60c1f19efdde9a637c32740486004f20d1cff53c3c0ece4d2",
|
||||
"sha256:e61659ba32cf2cf1481e575d0462554625196a1f2fc06a1c777d3f48e8865d46",
|
||||
"sha256:ea3d8a3d18833cf4304cd2fc9cbb1efe188ca9b5efef2bdac7adc20594a0e46b",
|
||||
"sha256:ec6a563cff360b50eed26f13adc43e61bc0c04d94b8be985e6fb24b81f6dcfdf",
|
||||
"sha256:f5dfb42c4604dddc8e4305050aa6deb084540643ed5804d7455b5df8fe16f5e5",
|
||||
"sha256:fa173ec60341d6bb97a89f5ea19c85c5643c1e7dedebc22f5181eb73573142c5",
|
||||
"sha256:fa9db3f79de01457b03d4f01b34cf91bc0048eb2c3846ff26f66687c2f6d16ab",
|
||||
"sha256:fce659a462a1be54d2ffcacea5e3ba2d74daa74f30f5f143fe0c58636e355fdd",
|
||||
"sha256:ffee1f21e5ef0d712f9033568f8344d5da8cc2869dbd08d87c84656e6a2d2f68"
|
||||
"sha256:0bff5e0ae4ef2e1ae4fdf2dfd5b76c75e5c2fa4132d05fc1b0dabcd20c7e28c4",
|
||||
"sha256:0f4ca02bea9a23221c0182836703cbf8930c5e9454bacce27e767509fa286a30",
|
||||
"sha256:1225beacc926f536dc82e45f8a4d68502949dc67eea90eab715dea3a21c1b5f0",
|
||||
"sha256:131a3c7689c85f5ad20f9f6fb1b866f402c445b220c19fe4308c0b147ccd2ad9",
|
||||
"sha256:15ab75ef81add55874e7ab7055e9c397312385bd9ced94920f2802310c930396",
|
||||
"sha256:1a9d3f5f0901fdec14d8d2f66ef7d035f2157240a433441719ac9a3fba440b13",
|
||||
"sha256:1c99d261bd2d5f6b59325c92c73df481e05e57f19837bdca8413b9eac4bd8028",
|
||||
"sha256:1e084f686b92e5b83186b07e8a17fc09e38fff551f3602b249881fec658d3eca",
|
||||
"sha256:2181e67807fc2fa785d0592dc2d6206c019b9502410671cc905d132a92866557",
|
||||
"sha256:2cb8438c3cbb25e220c2ab33bb226559e7afb3baec11c4f218ffa7308603c832",
|
||||
"sha256:3169b1eefae027567d1ce6ee7cae382c57fe26e82775f460f0b2778beaad66c0",
|
||||
"sha256:3809ede931876f5b2ec92eef964286840ed3540dadf803dd570c3b7e13141a3b",
|
||||
"sha256:38a9ef736c01fccdd6600705b09dc574584b89bea478200c5fbf112a6b0d5579",
|
||||
"sha256:3d79d162e7be8f996986c064d1c7c817f6df3a77fe3d6859f6f9e7be4b8c213a",
|
||||
"sha256:444dcda765c8a838eaae23112db52f1efaf750daddb2d9ca300bcae1039adc5c",
|
||||
"sha256:48032821bbdf20f5799ff537c7ac3d1fba0ba032cfc06194faffa8cda8b560ff",
|
||||
"sha256:4aa4e5faecf353ed117801a068ebab7b7e09ffb6e1d5e412dc852e0da018126c",
|
||||
"sha256:52305740fe773d09cffb16f8ed0427942901f00adedac82ec8b67752f58a1b22",
|
||||
"sha256:569511d3b58c8791ab4c2e1285575265991e6d8f8700c7be0e88f86cb0672094",
|
||||
"sha256:57cb5a3cf367aeb1d316576250f65edec5bb3be939e9247ae594b4bcbc317dfb",
|
||||
"sha256:5b02fb34468b6aaa40dfc198d813a641e3a63b98c2b05a16b9f80b7ec314185e",
|
||||
"sha256:6381026f158fdb7c72a168278597a5e3a5222e83ea18f543112b2662a9b699c5",
|
||||
"sha256:6af100e168aa82a50e186c82875a5893c5597a0c1ccdb0d8b40240b1f28b969a",
|
||||
"sha256:6c89876f41da747c8d3677a2b540fb32ef5715f97b66eeb0c6b66f5e3ef6f59d",
|
||||
"sha256:6e296a513ca3d94054c2c881cc913116e90fd030ad1c656b3869762b754f5f8a",
|
||||
"sha256:70a87b411535ccad5ef2f1df5136506a10775d267e197e4cf531ced10537bd6b",
|
||||
"sha256:7e94c425039cde14257288fd61dcfb01963e658efbc0ff54f5306b06054700f8",
|
||||
"sha256:846ade7b71e3536c4e56b386c2a47adf5741d2d8b94ec9dc3e92e5e1ee1e2225",
|
||||
"sha256:88416bd1e65dcea10bc7569faacb2c20ce071dd1f87539ca2ab364bf6231393c",
|
||||
"sha256:88b49a3b9ff31e19998750c38e030fc7bb937398b1f78cfa599aaef92d693144",
|
||||
"sha256:8c4e8c3ce11e1f92f6536ff07154f9d49677ebaaafc32db9db4620bc11ed480f",
|
||||
"sha256:8e06879fc22a25ca47312fbe7c8264eb0b662f6db27cb2d3bbbc74b1df4b9b87",
|
||||
"sha256:9025b4018f3a1314059769c7bf15441064b2207cb3f065e6ea1e7359cb46db9d",
|
||||
"sha256:93335ca3812df2f366e80509ae119189886b0f3c2b81325d39efdb84a1e2ae93",
|
||||
"sha256:9778bd8ab0a994ebf6f84c2b949e65736d5575320a17ae8984a77fab08db94cf",
|
||||
"sha256:9e2d922824181480953426608b81967de705c3cef4d1af983af849d7bd619158",
|
||||
"sha256:a123e330ef0853c6e822384873bef7507557d8e4a082961e1defa947aa59ba84",
|
||||
"sha256:a904af0a6162c73e3edcb969eeeb53a63ceeb5d8cf642fade7d39e7963a22ddb",
|
||||
"sha256:ad10d3ded218f1039f11a75f8091880239651b52e9bb592ca27de44eed242a48",
|
||||
"sha256:b424c77b206d63d500bcb69fa55ed8d0e6a3774056bdc4839fc9298a7edca171",
|
||||
"sha256:b5a6b3ada725cea8a5e634536b1b01c30bcdcd7f9c6fff4151548d5bf6b3a36c",
|
||||
"sha256:ba8062ed2cf21c07a9e295d5b8a2a5ce678b913b45fdf68c32d95d6c1291e0b6",
|
||||
"sha256:ba9527cdd4c926ed0760bc301f6728ef34d841f405abf9d4f959c478421e4efd",
|
||||
"sha256:bbcb445fa71794da8f178f0f6d66789a28d7319071af7a496d4d507ed566270d",
|
||||
"sha256:bcf3e58998965654fdaff38e58584d8937aa3096ab5354d493c77d1fdd66d7a1",
|
||||
"sha256:c0ef13eaeee5b615fb07c9a7dadb38eac06a0608b41570d8ade51c56539e509d",
|
||||
"sha256:cabc348d87e913db6ab4aa100f01b08f481097838bdddf7c7a84b7575b7309ca",
|
||||
"sha256:cdb82a876c47801bb54a690c5ae105a46b392ac6099881cdfb9f6e95e4014c6a",
|
||||
"sha256:cfad01eed2c2e0c01fd0ecd2ef42c492f7f93902e39a42fc9ee1692961443a29",
|
||||
"sha256:d16a81a06776313e817c951135cf7340a3e91e8c1ff2fac444cfd75fffa04afe",
|
||||
"sha256:d8213e09c917a951de9d09ecee036d5c7d36cb6cb7dbaece4c71a60d79fb9798",
|
||||
"sha256:e07c3764494e3776c602c1e78e298937c3315ccc9043ead7e685b7f2b8d47b3c",
|
||||
"sha256:e17c96c14e19278594aa4841ec148115f9c7615a47382ecb6b82bd8fea3ab0c8",
|
||||
"sha256:e444a31f8db13eb18ada366ab3cf45fd4b31e4db1236a4448f68778c1d1a5a2f",
|
||||
"sha256:e6a2a455bd412959b57a172ce6328d2dd1f01cb2135efda2e4576e8a23fa3b0f",
|
||||
"sha256:eaa0a10b7f72326f1372a713e73c3f739b524b3af41feb43e4921cb529f5929a",
|
||||
"sha256:eb7972a85c54febfb25b5c4b4f3af4dcc731994c7da0d8a0b4a6eb0640e1d178",
|
||||
"sha256:ee55d3edf80167e48ea11a923c7386f4669df67d7994554387f84e7d8b0a2bf0",
|
||||
"sha256:f3818cb119498c0678015754eba762e0d61e5b52d34c8b13d770f0719f7b1d79",
|
||||
"sha256:f8b3d067f2e40fe93e1ccdd6b2e1d16c43140e76f02fb1319a05cf2b79d99430",
|
||||
"sha256:fcabf5ff6eea076f859677f5f0b6b5c1a51e70a376b0579e0eadef8db48c6b50"
|
||||
],
|
||||
"markers": "python_version >= '3.7'",
|
||||
"version": "==2.1.5"
|
||||
"markers": "python_version >= '3.9'",
|
||||
"version": "==3.0.2"
|
||||
},
|
||||
"pyyaml": {
|
||||
"hashes": [
|
||||
|
87
scripts/cml-autostart/README.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# README
|
||||
|
||||
This script adds lab autostart capability to CML. It's implemented in a very
|
||||
simple way without any additional dependencies to install.
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> It's important to understand that this mechanism is very simple and also very
|
||||
> insecure. You need to provide a password for a user of the system in clear
|
||||
> text as part of the configuration. If you are not comfortable to provide a
|
||||
> password that is stored in clear text on the server, then this solution is not
|
||||
> for you. Also, if the system uses external authentication via LDAP, then this
|
||||
> solution is likely not for you.
|
||||
|
||||
## Installation
|
||||
|
||||
Simply copy the `autostart.sh` script to the CML server. Either via scp or
|
||||
simply copying/pasting it into a file on the CML server (for example, via the
|
||||
Cockpit terminal). From there, run the script which then installs it:
|
||||
|
||||
```plain
|
||||
$ sudo bash ./autostart.sh
|
||||
installing defaults ✅
|
||||
installing script ✅
|
||||
installing service unit ✅
|
||||
*****************************************************
|
||||
* ⚠️ IMPORTANT! ⚠️ *
|
||||
* you need to ensure that you change the username *
|
||||
* and password for a user of the system that can *
|
||||
* start the labs in /etc/default/cml-autostart *
|
||||
* *
|
||||
* Add the string "(autostart)" to the description *
|
||||
* of each lab that you wish to start automatically. *
|
||||
*****************************************************
|
||||
$
|
||||
```
|
||||
|
||||
Then configure the defaults (e.g. change the password) as outlined in the next
|
||||
section.
|
||||
|
||||
## Configuration
|
||||
|
||||
The autostart script basically looks at all labs that the user has access to
|
||||
(users with admin rights will see all labs, the script passes the "show_all"
|
||||
flag so if a non-admin user runs this, they will see all labs they have access
|
||||
to).
|
||||
|
||||
A lab that has `(autostart)` in the lab description will be started when the
|
||||
system comes up and is ready.
|
||||
|
||||
The string that triggers the autostart is configured in the `TITLE_REGEX`
|
||||
variable. It is treated as a regular expression.
|
||||
|
||||
Configuration (with defaults) is done in `/etc/default/cml-autostart`:
|
||||
|
||||
```bash
|
||||
USERNAME="admin"
|
||||
PASSWORD="password-that-needs-to-be-changed"
|
||||
TITLE_REGEX="\(autostart\)"
|
||||
```
|
||||
|
||||
After installation, at least the password needs to be changed.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> The user configured should be a general admin user that has visibility to all
|
||||
> potential labs that might need to be auto-started.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If labs do not start as expected, check the service unit output:
|
||||
|
||||
```bash
|
||||
sudo systemctl status cml-autostart.service
|
||||
```
|
||||
|
||||
More details are available in the journal:
|
||||
|
||||
```bash
|
||||
sudo journalctl -u cml-autostart.service
|
||||
```
|
||||
|
||||
If that's not sufficient to pin-point the issue, enable debugging in the script
|
||||
by removing the comment in `/usr/local/bin/cml-autostart.sh` from the line that
|
||||
says `# set -x`. If the script has been changed and debugging is enabled then
|
||||
the service can be triggered again by `systemctl start cml-autostart.service`.
|
||||
Then show the status and / or look at the journal output again.
|
124
scripts/cml-autostart/autostart.sh
Normal file
@@ -0,0 +1,124 @@
|
||||
#!/bin/bash
|
||||
|
||||
set -e
|
||||
|
||||
ensure_dir() {
|
||||
local install_dir="$1"
|
||||
if ! test -d "$install_dir"; then
|
||||
echo "Error: $install_dir isn't there"
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
install_default() {
|
||||
local install_dir="/etc/default"
|
||||
ensure_dir $install_dir
|
||||
cat >"$install_dir/cml-autostart" <<EOF
|
||||
USERNAME="admin"
|
||||
PASSWORD="password-that-needs-to-be-changed"
|
||||
TITLE_REGEX="\(autostart\)"
|
||||
EOF
|
||||
chown root:root "$install_dir/cml-autostart"
|
||||
chmod 0600 "$install_dir/cml-autostart"
|
||||
}
|
||||
|
||||
install_script() {
|
||||
local install_dir="/usr/local/bin"
|
||||
ensure_dir $install_dir
|
||||
cat >"$install_dir/cml-autostart.sh" <<EOF
|
||||
#!/bin/bash
|
||||
|
||||
# set variables
|
||||
HOST="ip6-localhost"
|
||||
# the /etc/default/cml-autostart needs to define and these need to be present
|
||||
# in the environment!
|
||||
# - USERNAME
|
||||
# - PASSWORD
|
||||
# - TITLE_REGEX
|
||||
|
||||
# set -x
|
||||
|
||||
API="https://\${HOST}/api/v0"
|
||||
|
||||
# wait until the system is ready
|
||||
until [ "true" = "\$(curl -skX GET \$API/system_information | jq -r .ready)" ]; do
|
||||
echo "Waiting for controller to be ready..."
|
||||
sleep 5
|
||||
done
|
||||
|
||||
# get authentication token
|
||||
TOKEN=\$(curl -skX POST "\${API}/authenticate" \\
|
||||
-H "Content-Type: application/json" \\
|
||||
-d '{"username":"'\${USERNAME}'","password":"'\${PASSWORD}'"}' |
|
||||
jq -r .)
|
||||
|
||||
# get all labs
|
||||
LABS=\$(curl -skX GET "\${API}/labs?show_all=true" \\
|
||||
-H "Authorization: Bearer \${TOKEN}")
|
||||
|
||||
while read -r lab; do
|
||||
labinfo=\$(curl -skX GET "\${API}/labs/\${lab}" \\
|
||||
-H "Authorization: Bearer \${TOKEN}")
|
||||
description=\$(echo \$labinfo | jq -r '.lab_description')
|
||||
title=\$(echo \$labinfo | jq -r '.lab_title')
|
||||
if [[ "\${description}" =~ \${TITLE_REGEX} ]]; then
|
||||
curl -skX PUT "\${API}/labs/\${lab}/start" \\
|
||||
-H "Authorization: Bearer \${TOKEN}"
|
||||
echo "Lab '\${title}' (ID: \${lab}) start initiated"
|
||||
fi
|
||||
done <<<\$(echo \$LABS | jq -r '. | join("\n")')
|
||||
exit
|
||||
EOF
|
||||
chown root:root "$install_dir/cml-autostart.sh"
|
||||
chmod a+x "$install_dir/cml-autostart.sh"
|
||||
}
|
||||
|
||||
install_service_unit() {
|
||||
local install_dir="/etc/systemd/system"
|
||||
ensure_dir $install_dir
|
||||
cat >"$install_dir/cml-autostart.service" <<EOF
|
||||
[Unit]
|
||||
Description=Autostart CML Labs based on description text
|
||||
After=network.target
|
||||
After=virl2.target
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
EnvironmentFile=/etc/default/cml-autostart
|
||||
ExecStart=/usr/local/bin/cml-autostart.sh
|
||||
User=virl2
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
EOF
|
||||
chown root:root "$install_dir/cml-autostart.service"
|
||||
systemctl daemon-reload
|
||||
systemctl &>/dev/null enable cml-autostart.service
|
||||
}
|
||||
|
||||
if [[ $EUID -ne 0 ]]; then
|
||||
echo "This script must be run as root." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
echo -n "installing defaults"
|
||||
install_default
|
||||
echo -e "\t✅"
|
||||
echo -n "installing script"
|
||||
install_script
|
||||
echo -e "\t✅"
|
||||
echo -n "installing service unit"
|
||||
install_service_unit
|
||||
echo -e "\t✅"
|
||||
|
||||
cat <<EOF
|
||||
*****************************************************
|
||||
* ⚠️ IMPORTANT! ⚠️ *
|
||||
* you need to ensure that you change the username *
|
||||
* and password for a user of the system that can *
|
||||
* start the labs in /etc/default/cml-autostart *
|
||||
* *
|
||||
* Add the string "(autostart)" to the description *
|
||||
* of each lab that you wish to start automatically. *
|
||||
*****************************************************
|
||||
EOF
|
@@ -51,7 +51,10 @@
|
||||
"properties": {
|
||||
"linux_native": {
|
||||
"$ref": "#/schemas/LinuxNativeSimulation"
|
||||
}
|
||||
},
|
||||
"parameters": {
|
||||
"$ref": "#/schemas/NodeParameters"
|
||||
}
|
||||
},
|
||||
"required": [
|
||||
"linux_native"
|
||||
@@ -435,7 +438,8 @@
|
||||
"cpu_model": {
|
||||
"type": "string",
|
||||
"minLength": 1,
|
||||
"maxLength": 32
|
||||
"maxLength": 64,
|
||||
"pattern": "^[a-zA-Z\\d-]{1,32}(,[+!?^-][a-z\\d._]{1,16})*(?![\\n\\t])$"
|
||||
},
|
||||
"nic_driver": {
|
||||
"type": "string",
|
||||
@@ -487,16 +491,13 @@
|
||||
"type": "string",
|
||||
"description": "Video Model.",
|
||||
"enum": [
|
||||
"std",
|
||||
"cirrus",
|
||||
"vmware",
|
||||
"qxl",
|
||||
"xenfb",
|
||||
"tcx",
|
||||
"cg3",
|
||||
"xen",
|
||||
"virtio",
|
||||
"none",
|
||||
"vga"
|
||||
"vga",
|
||||
"vmvga"
|
||||
]
|
||||
},
|
||||
"memory": {
|
||||
@@ -506,14 +507,26 @@
|
||||
"description": "Video Memory."
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
"enable_rng": {
|
||||
"type": "boolean",
|
||||
"description": "If set, use a random number generator."
|
||||
},
|
||||
"enable_tpm": {
|
||||
"type": "boolean",
|
||||
"description": "If set, enable an emulated TPM 2.0."
|
||||
}
|
||||
},
|
||||
"oneOf": [
|
||||
{
|
||||
"properties": {
|
||||
"libvirt_domain_driver": {
|
||||
"enum": [
|
||||
"kvm"
|
||||
"kvm",
|
||||
"docker",
|
||||
"iol",
|
||||
"lxc",
|
||||
"none"
|
||||
]
|
||||
}
|
||||
},
|
||||
@@ -547,6 +560,15 @@
|
||||
}
|
||||
]
|
||||
},
|
||||
"NodeParameters": {
|
||||
"type": "object",
|
||||
"additionalProperties": {
|
||||
"type": "string",
|
||||
"nullable": true
|
||||
},
|
||||
"description": "Key-value pairs of custom node SMBIOS parameters.",
|
||||
"example": {"smbios.bios.vendor": "Lenovo"}
|
||||
},
|
||||
"Interfaces": {
|
||||
"type": "object",
|
||||
"additionalProperties": false,
|
||||
@@ -845,7 +867,9 @@
|
||||
"description": "The type of the configuration media.",
|
||||
"enum": [
|
||||
"iso",
|
||||
"fat"
|
||||
"fat",
|
||||
"raw",
|
||||
"ext4"
|
||||
]
|
||||
},
|
||||
"volume_name": {
|
||||
@@ -914,7 +938,7 @@
|
||||
"cloud",
|
||||
"firewall",
|
||||
"access_point",
|
||||
"wlc"
|
||||
"wl"
|
||||
]
|
||||
},
|
||||
"label": {
|
||||
|
8
virl-base-images/sonic/SONiCv-20240406-8.yaml
Normal file
@@ -0,0 +1,8 @@
|
||||
id: SONiCv-20240406-8
|
||||
node_definition_id: SONiCv
|
||||
description: ''
|
||||
label: SONiC Virtual Switch (Build 20240406)
|
||||
disk_image: sonic-vs-20240406-8.qcow2
|
||||
read_only: false
|
||||
disk_subfolder: SONiCv-20240406-8
|
||||
schema_version: 0.0.1
|
8
virl-base-images/sonic/SONiCv-Enterprise-4.2.0.yaml
Normal file
@@ -0,0 +1,8 @@
|
||||
id: SONiCv-Enterprise-4.2.0
|
||||
node_definition_id: SONiCv
|
||||
description: ''
|
||||
label: SONiCv Enterprise 4.2.0 (Dell)
|
||||
disk_image: Enterprise_SONiC_OS_4.2.0.qcow2
|
||||
read_only: false
|
||||
disk_subfolder: SONiCv-Enterprise-4.2.0
|
||||
schema_version: 0.0.1
|