mirror of
https://github.com/CiscoDevNet/cml-community.git
synced 2025-11-09 16:15:59 +00:00
Compare commits
2 Commits
ccnaprep
...
aaa-tacacs
| Author | SHA1 | Date | |
|---|---|---|---|
|
b2ba0f2670 | ||
|
|
fe7cc30ea4 |
@@ -1,34 +0,0 @@
|
||||
### 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.
|
||||
@@ -1,49 +0,0 @@
|
||||
### 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
|
||||
@@ -1,376 +0,0 @@
|
||||
# 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
|
||||
```
|
||||
@@ -1,18 +1,8 @@
|
||||
# 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.
|
||||
Simple topology for practicing AAA TACACS configuration in 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.
|
||||
@@ -80,7 +70,7 @@ 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 exec default start-stop group ISE-TACACS
|
||||
aaa accounting commands 1 default start-stop group AAA-TACACS
|
||||
aaa accounting commands 15 default start-stop group AAA-TACACS
|
||||
!
|
||||
|
||||
@@ -481,16 +481,6 @@ lab:
|
||||
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.
|
||||
@@ -558,7 +548,7 @@ lab:
|
||||
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 exec default start-stop group ISE-TACACS
|
||||
aaa accounting commands 1 default start-stop group AAA-TACACS
|
||||
aaa accounting commands 15 default start-stop group AAA-TACACS
|
||||
!
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
@@ -1,27 +0,0 @@
|
||||
# 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
|
||||
|
||||
*Details coming soon!*
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 179 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,5 +0,0 @@
|
||||
# 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!
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 162 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,5 +0,0 @@
|
||||
# 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.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 134 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,5 +0,0 @@
|
||||
# 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.
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 210 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,10 +0,0 @@
|
||||
# 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.
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 154 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,4 +0,0 @@
|
||||
# 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.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 180 KiB |
Binary file not shown.
File diff suppressed because it is too large
Load Diff
@@ -1,5 +0,0 @@
|
||||
# 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.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 222 KiB |
@@ -1,36 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,67 +0,0 @@
|
||||
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
|
||||
@@ -1,75 +0,0 @@
|
||||
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
|
||||
@@ -1,58 +0,0 @@
|
||||
# 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
|
||||
```
|
||||
@@ -1,94 +0,0 @@
|
||||
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
|
||||
@@ -1,270 +0,0 @@
|
||||
# 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.
|
||||
@@ -1,14 +0,0 @@
|
||||
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
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,58 +0,0 @@
|
||||
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
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 184 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 551 KiB |
@@ -1,8 +0,0 @@
|
||||
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
|
||||
@@ -1,8 +0,0 @@
|
||||
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
|
||||
Reference in New Issue
Block a user