OSPF Stub Areas

You will find all the labs in the Bitsize series on my GitHub, link to repo: CML-bitsize-labs.

Learning Objectives

• Real-world troubleshooting in a small network
• Verify OSPF configurations.
• Ticket documentation

Lab Overview

This is a short one, a quick troubleshooting lab to test your skills to find the errors and practice how to handle it like a real-world ticket.

If you need to brush up on the concepts, I have some study notes that you are more than welcome to review, here is the link, I’m sure it will help you in your journey towards mastering OSPF, OSPF stub areas and virtual links.

Design decisions

This lab is designed to give you hands-on experience with troubleshooting OSPF. The lab topology is designed to be simple and easy to understand, while still providing enough complexity to allow you to practice the concepts of OSPF.

Lab Instructions

1. Setup: Clone the lab repository and navigate to the ./ospf/03-Troubleshooting folder. Review the provided startup configurations for the routers in the lab topology.
2. Configuration: Import the 03-OSPF_Troubleshooting_Lab.yaml file into the CML environment. Follow the instructions in the Lab Tasks to troubleshoot the OSPF on all the appropriate routers. Use the CLI to apply the necessary commands and verify your configuration.
3. Testing: After the troubleshooting, test the network connectivity to ensure that the hosts are able to comunicate with eachother.

Lab Tasks

1. Review the Lab Environment: Familiarize yourself with the lab environment and the routers involved.
2. Review the ticket: Read the ticket ticket.txt found in the folder.
3. Solve the ticket and document the changes: Verify configuration as you go along and document the changes in the lab-notebook.txt, you should also include the show commands you use to verify the configuration.

Walkthrough

1. Review the Lab Environment: When looking at the lab, you will see five devices. Two hosts (Ubuntu1 and Ubuntu3) in respective subnets, and three routers that make up the OSPF network: R1, R2 and R3.

2. Review the Ticket: The ticket describes a real-world issue where East Campus users cannot reach shared resources. This is a vague service desk ticket with no technical details—typical of production incidents.

3. Verify Basic Connectivity:
   • From Ubuntu1, attempt to ping Ubuntu3: ping 192.168.3.10
   • Expected: Should fail with “Destination host unreachable”
   • This confirms the issue exists
4. Check OSPF Neighbor Adjacencies:
   • SSH into R1 and run: show ip ospf neighbor
     • Should see R2 (1.1.1.1) in FULL state ✅
   • SSH into R2 and run: show ip ospf neighbor
     • Should see R1 (1.1.1.1) in FULL state ✅
     • Should see R3 (3.3.3.3) in EXSTART or EXCHANGE state ❌ (BUG!)
   • SSH into R3 and run: show ip ospf neighbor
     • Should see R2 (2.2.2.2) in EXSTART or EXCHANGE state ❌ (BUG!)
5. Diagnose the R2↔R3 Adjacency Failure:
   • On R2, run: show ip ospf interface Ethernet0/1
     • Check the “Network Type” field
     • Should show: POINT_TO_MULTIPOINT
   • On R3, run: show ip ospf interface Ethernet0/0
     • Check the “Network Type” field
     • Should show: BROADCAST (default)
   • Root Cause #1 Found: Network type mismatch prevents adjacency formation
6. Fix Bug #1 - Network Type Mismatch:
   • On R3, enter configuration mode: R3# configure terminal R3(config)# interface Ethernet0/0 R3(config-if)# ip ospf network broadcast R3(config-if)# end
   • Verify the change: R3# show ip ospf interface Ethernet0/0 (Network Type should now show BROADCAST)
   • Wait 30-40 seconds for adjacency to form
   • Verify on R2: show ip ospf neighbor (R3 should now be FULL)
7. Check OSPF Database for Missing Routes:
   • On R1, run: show ip ospf database
     • Look for loopback 3.3.3.3 in Area 0
     • It should now appear (was missing before)
   • Attempt ping again: ping 192.168.3.10
     • Still fails with “Destination host unreachable” ❌ (Second bug remains)
8. Diagnose Missing Routes in OSPF Database:
   • On R3, check the OSPF configuration: R3# show running-config | section router ospf
   • Look for the network statement for the 192.168.3.0/24 subnet
   • Should see something like: network 192.168.3.0 0.0.255.255 area 2
   • Root Cause #2 Found: Wildcard mask 0.0.255.255 is incorrect for a /24 network (should be 0.0.0.255)
9. Fix Bug #2 - Incorrect Wildcard Mask:
   • On R3, enter configuration mode: R3# configure terminal R3(config)# router ospf 1 R3(config-router)# no network 192.168.3.0 0.0.255.255 area 2 R3(config-router)# network 192.168.3.0 0.0.0.255 area 2 R3(config-router)# end
   • Save configuration: R3# write memory
10. Verify Both Fixes:
    • Check R3 configuration: R3# show running-config | include network (Should show correct wildcard: 0.0.0.255)
    • Check OSPF database on R1: R1# show ip ospf database (Should now include 3.3.3.3 and 192.168.3.0/24 routes)
    • Check routing table: R1# show ip route ospf (Should show route to 192.168.3.0/24)
11. Final Verification - End-to-End Connectivity:
    • From Ubuntu1, ping Ubuntu3: ``` ubuntu1$ ping -c 4 192.168.3.10 PING 192.168.3.10 (192.168.3.10) 56(84) bytes of data. 64 bytes from 192.168.3.10: icmp_seq=1 ttl=62 time=4.2 ms 64 bytes from 192.168.3.10: icmp_seq=2 ttl=62 time=3.8 ms 64 bytes from 192.168.3.10: icmp_seq=3 ttl=62 time=4.1 ms 64 bytes from 192.168.3.10: icmp_seq=4 ttl=62 time=3.9 ms — 192.168.3.10 statistics — 4 packets transmitted, 4 received, 0% packet loss ✅ SUCCESS
    • From Ubuntu3, ping Ubuntu1: ubuntu3$ ping -c 4 192.168.1.10 (Should also succeed with 0% packet loss) ```
12. Document the Solution:
    • Bug #1: R2 Ethernet0/1 configured with ip ospf network point-to-multipoint while R3 Ethernet0/0 used default broadcast type. This prevented OSPF adjacency formation.
    • Bug #2: R3 OSPF network statement used incorrect wildcard mask 0.0.255.255 instead of 0.0.0.255 for the 192.168.3.0/24 subnet, preventing the subnet from being advertised into OSPF.
    • Resolution: Changed R3 E0/0 network type to broadcast and corrected the wildcard mask. Both routers now have complete OSPF databases and all subnets are reachable.
13. Ticket Resolution:
    • Update ticket with findings
    • Mark as RESOLVED
    • East Campus users can now access shared resources

Replace printer in Catalyst Center with MAB

Lab Overview

The printer that will be added will be named Printer1. The task was to ensure that the new printer would be authenticated via MAB and placed in the correct VLAN (VLAN 30 for printers) in the network, and that this information would be visible in Catalyst Center. The lab is designed to simulate the process of adding a printer to a network that uses Cisco Identity Services Engine (ISE) for authentication and Cisco Catalyst Center for network management and visibility. Since both ISE and Catalyst Center is located outside of my regular homelab this lab will be more of a walkthrough that a hands-on lab that will test your capabilities. Still, just follow the steps and you will be able to complete the lab and learn how to MAB a printer in ISE with the help of Catalyst Center, and how to verify that the printer is authenticated and placed in the correct VLAN in Catalyst Center.

Want more labs?

You will find all the labs in the Bitsize series on my Github, link to repo: CML-bitsize-labs.

Learning Objectives

• Identify client devices at the switch level
• Understand MAC address tables and authentication sessions
• Familiarize yourself with Catalyst Center and ISE
• Manage endpoints in Cisco ISE
• Create and apply ISE authorization policies
• Assign VLANs via MAB
• Troubleshoot the end-to-end NAC flow

Lab Instructions

Prerequisites:

• Basic understanding of Cisco ISE and Catalyst Center
• An account on the Devnet Sandbox and access to the “Identity Services Engine 3.4” and “Catalyst Center Sandbox” or “Catalyst Center Always On” sandboxes.

Setup: Sign in to the Devnet Sandbox start page and reserve/launch the “Identity Services Engine 3.4” and the “Catalyst Center Sandbox” sandbox. Once the sandboxes is up and running and accessible, access the Catalyst Center GUI and the ISE GUI using the provided credentials. If you are using Windows you need to use AnyConnect client to connect to the VPN to access the sandbox.

Configuration: Follow the instructions in the Lab Tasks to configure ISE and Catalyst Center. Use the CLI to apply the necessary commands and verify your configuration.

Lab Tasks

1. Identify the Networks: Familiarize yourself with ISE and Catalyst Center in the devnet sandbox. The MAC address of printer1 is 1111.1111.1111, and it is connected to the switch port Gi1/0/12.

2. Configure ISE: Create the necessary groups, endpoints, and authorization policies in ISE to allow the printer to authenticate via MAB and be placed in VLAN 30.

3. Configure and Verify Catalyst Center: Configure Catalyst Center to check the printer’s authentication and VLAN assignment. Verify that Catalyst Center is properly integrated with ISE and that it can see the printer’s authentication status and VLAN assignment.

Walkthrough

This is a walkthrough of the lab, where you can find the commands and steps to complete the lab tasks.

### Identify the Networks Sign up to the Devnet Sandbox and review the lab topology to understand the network setup. Identify the switches, printers, and the ISE server that will be involved in the lab.

Look up the mac address of printer1: Access the switch that the printer is connected to, you can find the switch in the inventory of Catalyst Center, and use the Run Command feature to find the MAC address of printer1. To find the Inventory go to the main menu of Catalyst Center → Provisioning → Inventory. In the Command Runner, input the following command: show mac address-table and locate the MAC address of printer1. The output will be something like this:

          Mac Address Table
-------------------------------------------
Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
      1111.1111.1111    DYNAMIC     Gi1/0/12

Configure ISE:

Log in to the ISE GUI with your browser and sign in with the provided credentials given in an email sent from your friends at Cisco.

Create MAB Group: First you need to create a group for the printers in ISE, this will help you to apply specific policies for the printers. Navigate to Administration → Identity Management → Groups → Add. Create a group named “Printers” and save it.

Create Endpoint: Next, you need to create an endpoint for the printer in ISE. This will allow you to manage the printer’s authentication and authorization policies. We already have the MAC address of printer1, so we will use that to create the endpoint. Navigate to Context Visibility → Endpoints → Add. Create an endpoint with the following details:
mac address: 1111.1111.1111
Static Group Assignment: Printers

Save the endpoint.

Create Dynamic VLAN Profile: Now you need to create a dynamic VLAN profile that will assign the printer to VLAN 30 when it authenticates via MAB. Navigate to Policy → Results → Authorization → Authorization Profiles → Add. Create an authorization profile with the following details: Name: Permit_VLAN_30 Common Tasks → VLAN: → ID/name: 30 Save the profile.

Create new Policy Set: Add a new Policy Set for the printer, this will allow you to apply the authorization profile to the printer when it authenticates. Navigate to Policy → Policy Sets → Add.

Name the policy set “Printer Policy Set” and click on the plus icon in the Conditions field to add a new condition.

This will open the Conditions Studio. Drag the Wired_MAB condition from the Library to the new under the Editor section. Now save.

Now you will get back to the Policy Set page, giving you an overview of the newly created Policy Set. Make sure that Default Network Access is used in the Allowed Protocols / Server Sequence column. Save that as well. A check will be preformed to verify that the policy set is valid.

Continue in the Policy Set page, click on the arrow to the right of the Printer Policy Set (under the Vew column) to open the policy set. Under the Authorization Policy tab, create a new rule by clicking on the plus icon. Name the rule “Printer MAB Rule” and click on the plus icon in the Conditions field to add a new condition. In the Conditions Studio, in the Editor section, click on “Click to add an attribute” and click on “Identity Group” and select “IdentityGroupe” with attribute “Name”. On it check so it is marked as “Equals” and pick the value “Endpoint Identity Groupe:Printers”. Click on Use. Now you will get back to the Authorization Policy page. Next to the Conditions field click on Select from list in the profile column. Select the “Permit_VLAN_30” profile that we created earlier and click on Use. Now save the rule and the policy set.

We also have to ensure that the Authentication Policy is properly configured to allow MAB authentication. Navigate to the Authentication Policy tab in the same policy set and ensure that there is a rule that allows MAB authentication for wired devices. If there isn’t, create a new rule that allows MAB authentication for wired devices. The role should look something like this: Identity Group equals Printer Policy Set: Default Network Access: Wired_MAB.

Configure Catalyst Center:

Verify ISE Integration: Before we can verify the printer’s authentication and VLAN assignment in Catalyst Center, we need to ensure that Catalyst Center is properly integrated with ISE. This involves checking the connection status and ensuring that endpoint synchronization is enabled. Navigate to System → Settings → External Services → Authentication and Policy Servers in Catalyst Center. Here you should see the ISE server listed with a status of “Connected”. If it is not connected, you may need to troubleshoot the connection between Catalyst Center and ISE.

Verify Port Configuration: Navigate to Provisioning → Inventory in Catalyst Center and locate the switch and port that the printer is connected to (Gi1/0/12). Check the port configuration to ensure that it is set to allow MAB authentication and that it is not statically assigned to a different VLAN. It should look something like this:

Port: Gi1/0/12
Admin State: Up
Operational State: Connected
Access Mode: Access
Authentication: MAB
VLAN: 30 (after authentication)

Visualize the Authentication Status: Navigate to Assurance → Health → Clients in Catalyst Center. Here you should see the printer listed as a client device. Click on the printer’s entry to view detailed information about its authentication status, VLAN assignment, and the switch port it is connected to.

Test Connectivity:

In a real world scenario, you would now connect the printer to the network and verify that it authenticates via MAB and is placed in VLAN 30. You can use the Catalyst Center GUI to check the client’s status and ensure that it is correctly authenticated and assigned to the right VLAN. Ping the printer from another device in the same VLAN can also be used to verify connectivity.

The End

That’s it for this lab! You have successfully replaced a printer in the network using MAB authentication and used Catalyst Center to manage the configuration. If this was helpful in any way or even the slightest bit interesting, I’m a sucker for feedback, so please let me know if you have any suggestions or improvements. Please reach me on Github or Linkedin.

Resources

• NiKSec.com; Configuring Cisco ISE MAB Policy Sets
• Cisco Devnet Sandbox
• Cisco ISE Documentation
• Cisco Catalyst Center Documentation

OSPF Stub Areas

You will find all the labs in the Bitsize series on my GitHub, link to repo: CML-bitsize-labs.

Learning Objectives

• Implement OSPF normal areas and Stub Areas in a network topology.
• Implement Virtual Links in OSPF to connect non-backbone areas to the backbone area.
• Verify OSPF configurations.
• Document the OSPF Stub Area configuration in the Lab notebook text file.

Lab Overview

I’m glad you are here, in this lab we will be configuring OSPF Stub Areas in a network topology. We will also be implementing Virtual Links to connect a non-backbone area to the backbone area, and configuring OSPF to ensure connectivity with the rest of the network.

If you need to brush up on the concepts, I have some study notes that you are more than welcome to review, here is the link, I’m sure it will help you in your journey towards mastering OSPF, OSPF stub areas and virtual links.

Design decisions

This lab is designed to give you hands-on experience with configuring OSPF Stub Areas and Virtual Links. The lab topology is designed to be simple and easy to understand, while still providing enough complexity to allow you to practice the concepts of OSPF Stub Areas and Virtual Links. I have tried to make the lab instructions simple enough to guide you through the configuration process, but I encourage you to not use this as an tutorial and keep you in the “tutorial hell”. For the sake of not making the lab too complex, we will be using a simple topology with only a few routers and areas, but it will still provide you with the opportunity to practice the concepts of OSPF Stub Areas and Virtual Links, but what this lacks is real-world complexity, which is something you probably won’t find in a real-world scenario. The lab is designed to be completed in a reasonable amount of time, while still providing you with the opportunity to learn and practice the concepts of OSPF Stub Areas and Virtual Links.

Lab Instructions

1. Setup: Clone the lab repository and navigate to the 02-OSPF-Stub-Areas folder. Review the provided startup configurations for the routers in the lab topology.
2. Configuration: Import the 02-OSPF_Stub_Areas_Lab.yaml file into the CML environment. Follow the instructions in the Lab Tasks to configure OSPF Stub Areas on the appropriate routers. Use the CLI to apply the necessary commands and verify your configuration.
3. Testing: After configuring stub areas, test the network connectivity and routing tables to ensure that the stub areas are working as expected.

Lab Tasks

1. Review the Lab Environment: Familiarize yourself with the lab environment and the routers involved.

2. Configure OSPF area 0-4: Configure the appropriate routers to be part of the stub areas, ensuring that they are correctly connected to the backbone area (Area 0). One of the areas should be a normal area (not stub), one should be a normal stub area, one should be a totally stub area and one should be a NSSA-TS. Verify configuration as you go along and document the changes in the lab-notebook.txt, you should also include the show commands you use to verify the configuration.

3. Configure Virtual Links: If necessary, configure virtual links to connect non-backbone areas to the backbone area. Verify the configuration.

4. Verify Configuration: Use OSPF commands to verify that the stub areas are correctly configured and that the routers are advertising the correct routes.

5. Test Connectivity: Test the connectivity between different areas of the network to ensure that the OSPF Stub Areas are functioning correctly.

Walkthrough

1. Review the Lab Environment: We have a total of 8 routers in this lab, R1, R2, R3, R4, R5, R6, R7 and R8. None of the routers are configured with OSPF, but they have at least IP addresses and subnet masks configured on their interfaces. The interfaces connecting the routers are using p2p links (/30). The routes have tags in CML with the area they should be configured with.

2. Configure OSPF Areas

   • backbone area (Area 0): R1 and R2
     We first need to configure OSPF on R1 and R2, and assign them to Area 0. Open up the CLI for R1 and R2 and enter the following commands:
     

R1:
router ospf 1
router-id 1.1.1.1
network 10.10.10.0 0.0.0.3 area 0

R2:
router ospf 1
router-id   2.2.2.2
network 10.10.10.0 0.0.0.3 area 0

• Now we need to configure R3, R4 and R5 to be part of Area 1, We will configure Area 1 to be a normal area. Open up the CLI for R2, R3, R4 and R5 and enter the following commands:
  

R2:
router ospf 1
network 10.20.20.0 0.0.0.3 area 1
network 10.20.20.4 0.0.0.3 area 1

R3:
router ospf 1
router-id 3.3.3.3
network 10.20.20.8 0.0.0.3 area 1

R4:
router ospf 1
router-id 4.4.4.4
network 10.20.20.12 0.0.0.3 area 1

R5:
router ospf 1
router-id 5.5.5.5
network 10.20.20.8 0.0.0.3 area 1
network 10.20.20.12 0.0.0.3 area 1

• Now we need to configure R5 and R6 to be part of Area 2, and we will configure Area 2 to be a totally stubby area. Open up the CLI for R5 and R6 and enter the following commands:

R5:
router ospf 1
network 10.30.30.0 0.0.0.3 area 2
area 2 stub no-summary

R6:
router ospf 1
router-id 6.6.6.6
network 10.30.30.0 0.0.0.3 area 2
area 2 stub no-summary

• We need to configure Area 3 on R3, as a NSSA:
  

R3:
router ospf 1
network 10.40.40.0 0.0.0.3 area 3
area 3 nssa

R8:
router ospf 1
router-id 8.8.8.8
network 10.40.40.0 0.0.0.3 area 3
area 3 nssa

• And the last area, area 4, needs to be configured on R4, as a NSSA-TS:

R4:
router ospf 1
network 10.50.50.0 0.0.0.3 area 4
area 4 nssa no-summary

R7:
router ospf 1
router-id 7.7.7.7
network 10.50.50.0 0.0.0.3 area 4
area 4 nssa no-summary

1. Configure Virtual Links: If necessary, configure virtual links to connect non-backbone areas to the backbone area.

Since area 2, 3 and 4 are not directly connected to the backbone area (Area 0), they will need to configure with virtual links between R2 and the respective areas to connect them to Area 0. Open up the CLI for respective routers and enter the following commands:

R2:
router ospf 1
area 1 virtual-link 5.5.5.5
area 1 virtual-link 4.4.4.4
area 1 virtual-link 3.3.3.3

R5:
router ospf 1
area 1 virtual-link 2.2.2.2

R4:
router ospf 1
area 1 virtual-link 2.2.2.2

R3:
router ospf 1
area 1 virtual-link 2.2.2.2

This will create a virtual link between the routers, allowing area 2,3 and 4 to be connected to Area 0 through Area 1. It’s easy to think of it as a tunnel between the routers, allowing OSPF to exchange routing information between the two areas. It don’t matter if its a physical or virtual link, as long as the OSPF process is configured correctly, the routers will be able to exchange routing information and the network will function as expected.

1. Verify Configuration: Use OSPF commands to verify that the stub areas are correctly configured and that the routers are advertising the correct routes.
   • You can use the show ip ospf neighbor command to verify that the routers are forming adjacencies with their neighbors and that the correct areas are being advertised.
   • To confirm that area 2, 3 and 4 are stub areas, you can use the show ip ospf command to verify that the areas are configured as stub areas and that the correct routes are being advertised.
   • You can also use the show ip route command to verify that the correct routes are being advertised and that the routing tables are correct.
   • You can also use the show ip ospf database command to verify that the OSPF database is correct and that the correct routes are being advertised.
   • You can also use the show ip ospf interface command to verify that the interfaces are correctly configured and that the correct areas are being advertised on the interfaces.

• You can also use the show ip ospf virtual-links command to verify that the virtual links are correctly configured and that they are up and running. The virtual links work because all endpoints are ABRs and they share Area 1 as a normal transit area. Cisco IOS permits this even when the ABRs’ other areas are stub or NSSA types.

1. Test Connectivity: Test the connectivity between different areas of the network to ensure that the OSPF Stub Areas are functioning correctly.
   • You can use the ping command to test connectivity between different areas of the network. Ping from R1 to R6 should work, as well as pinging from R3 to R4, and from R5 to R6. Ping from R1 to R7 should also work Ping from R1 to R8 should also work
   • You can also use the show ip route command to verify that the correct routes are being advertised and that the routing tables are correct.

LAB OVERVIEW and DESIGN DECISIONS

Find the github repository for the lab files here

What is this lab about? And why should you care?

This lab is about designing and configuring an enterprise network using Cisco Modeling Labs (Cisco CML). Cisco CML is a powerful network simulation tool that allows users to create and test network designs in a virtual environment. By simulating a real-world enterprise network environment, users can experiment with various configurations and scenarios without the need for physical hardware, making it an ideal learning tool for those looking to enhance their networking skills.

Throughout this lab I will be sharing my design decisions, the challenges I faced, and the solutions I implemented to overcome those challenges. This lab is not only a learning resource for others but also a personal project for me to test and learn new technologies in a practical setting.

Requirements

You fins the labfiles in the GitHub repository, which includes the topology files, configuration files, and notes for each device in the lab. These files will be updated as I continue to work on the lab and add more devices and configurations.

To follow along with this lab, you will need to have access to Cisco Modeling Labs (Cisco CML with atleast Personal subscription) and a basic understanding of networking concepts, including routing protocols, switching, and network security. Familiarity with OSPF (Open Shortest Path First) will be particularly helpful, as it is the routing protocol used in this lab. Additionally, having some experience with network automation tools like Ansible will be beneficial, as I will be using Ansible for network management and automation in this lab. I will provide explanations to why I chose different technologies and configurations, but having a basic understanding of these concepts will help you get the most out of this lab and enhance your learning experience.

CML is hosted on a Proxmox server, if you want to set up a similar lab, you can follow the instructions in the Proxmox documentation to create a virtual environment for Cisco CML. Once you have Cisco CML set up, you can import the lab topology and configurations that I will be sharing in this series of posts. I would recomend that you have a decent machine to run this lab,with atleast 8 CPU cores and 32 GB RAM as Cisco CML can be resource-intensive, especially when running multiple devices and complex configurations Also make sure to allocate enough of space for the imaes and configurations, I would recommend at least 500 GB of SSD storage for the lab. So in summary, the recommended hardware specifications for running this lab are:

8–16 CPU‑kärnor, 32–64 GB RAM, och 500 GB SSD

If you want an awesome installation guide of CML, you can check out this video Youtube link by 0x2142 - Networking Nonsense, which provides a step-by-step guide to installing Cisco CML on Proxmox.

Goals

My goal with this enterprise lab is to create a comprehensive and practical learning environment for network engineers and students who want to understand the intricacies of enterprise network design and configuration.

The lab will cover a wide range of topics, including routing protocols, switching, security, and network management. Each device in the lab will have its own notes file, which will provide detailed information about its role in the network, its configuration, and any relevant details that may be useful for understanding the lab. I will write these notes in a blogging style to make it easier for users to follow along and grasp the concepts being presented.

The design decision for the lab will be based on a typical enterprise network architecture, which includes edge routers, core routers, distribution switches, access switches, firewalls, and other network devices. The lab will also include various scenarios and configurations to help users understand how to design and configure an enterprise network effectively.

Routers and switches:

• E1: This is the core router in the lab, which connects to the WAN and serves as the central point for routing traffic between different areas of the network. It will be configured with OSPF as the routing protocol and will have multiple interfaces connecting to the area routers (R1, R2, R3) and a DMZ for management and external access.
• R1: This is an area router that connects to E1 and serves as the gateway for devices in Area 10. It will be configured with OSPF and will have interfaces connecting to E1 and the internal network.
• R2: This is another area router that connects to E1 and serves as the gateway for devices in Area 20. It will also be configured with OSPF and will have interfaces connecting to E1 and the internal network.
• R3: This is the third area router that connects to E1 and serves as the gateway for devices in Area 30. It will be configured with OSPF and will have interfaces connecting to E1 and the internal network.
• Switches: The lab will also include various switches that connect to the area routers and provide connectivity for end devices in the internal network. These switches will be configured with VLANs and other features to simulate a real-world enterprise network environment.
• Firewalls: The lab will include firewalls that provide security for the internal network and the DMZ. These firewalls will be configured with access control lists (ACLs) and other security features to protect the network from external threats while allowing necessary traffic to pass through.

Ip plan:

Design decisions:

• I chose to use OSPF as the routing protocol for this lab because it is widely used in enterprise networks and provides a good balance of features and complexity for learning purposes.
• The lab is designed to simulate a real-world enterprise network, with a core router (E1) that connects to multiple area routers (R1, R2, R3). This design allows users to understand how to configure and manage a hierarchical network architecture.
• The use of a DMZ (Demilitarized Zone) in the lab allows users to understand how to configure security measures and manage traffic between the internal network and external resources. The DMZ will be connected to the core router (E1) and will include hosts that simulate servers and host services that need to be accessible from the outside world while still being protected from direct access to the internal network.
• Its also a playground for me to test and learn new technologies, so I will be adding more devices and configurations as I go along. The lab is designed to be flexible and adaptable, allowing users to experiment with different scenarios and configurations to enhance their learning experience.

Challenges and solutions:

When setting up the I started with the core router (E1) and then added the area routers. An issue i faces right away was to make the routes being visible to each other, which was due to the fact that I forgot to set the OSPF area for the interfaces on E1. Once I set the correct areas for each interface, the routes were visible and the lab was functioning as expected. This highlights the importance of paying attention to details when configuring network devices, as even a small oversight can lead to connectivity issues.

Also setting up the DMZ host to be able to ping the internal and external network was a bit tricky, and I ended up using two interfaces on the DMZ host, one connected to the DMZ network and another connected to the internal network, and then configuring routing on the DMZ host to allow it to communicate with both networks. This was a good learning experience in understanding how to configure routing and connectivity in a complex network environment. This might be something I will change later on, but for now it serves the purpose of allowing the DMZ host to communicate with both the internal and external networks while still being protected from direct access to the internal network.

One of the most important functions of the DMZ is ansible, which will be used for network automation and management. Setting up Ansible to work with the devices in the lab was of high importance, and ensuring easy access and configuration in the lab. installation of Ansible and other tools for management will be described in a later posts, stay tuned for that.

Conclusion

Congratulations on getting through the overview and design decisions of this enterprise lab! I hope this has sparked your interest in learning and following along with the upcoming posts in this series. If you have any questions or suggestions about the lab design, please feel free to reach out to me. I am always open to feedback and ideas for improving the lab and making it a better learning resource for everyone.

Till the next post, happy networking!

Troubleshooting OSPF

Find the github repository for the lab files here

Ticket ID: OSPF‑Troubleshooting‑INC0000456

OSPF Troubleshooting Ticket – E1 and R1

1. Summary OSPF adjacency is not forming between E1 and router R1. Layer‑2 communication is functioning, but OSPF does not reach FULL state. There is suspicion of mismatched interface parameters, subnet masks, or area configuration.

2. Environment Affected Devices
   • E1 (router‑ID 1.1.1.1)
   • R1 (router‑ID 10.10.10.10)
   • R2 (router‑ID 20.20.20.20)
   • R3 (router‑ID 30.30.30.30)
     
     Links
   • E1 ↔ R1: 10.20.0.0/30
   • E1 ↔ R2: 10.30.0.0/30
   • E1 ↔ R3: 10.40.0.0/30
     
     OSPF Areas
   • E1–R1: Area 10
   • E1–R2: Area 20
   • E1–R3: Area 30
   • E1 Loopback0: Area 0
3. Symptoms
   • show ip ospf neighbor on E1 shows no neighbors.
   • show ip ospf interface confirms OSPF is enabled on the correct interfaces on E1.
   • R1 reports no OSPF neighbor on Ethernet0/0.
   • Ping between E1 and R1 works, indicating Layer‑2 connectivity.
   • The routing table contains no OSPF‑learned routes.
4. Expected Behavior
   • E1 should establish adjacency with R1, R2, and R3 in their respective areas.
   • show ip ospf neighbor should display neighbors in FULL state.
   • OSPF routes should appear in the routing tables of all routers.

The Troubleshooting Process

My first step was to verify the interface parameters on both E1 and R1. Luckily theres a lot of ways to troubleshoot OSPF issues. I ran the following commands:

• show ip interface Ethernet0/1 on E1 and show ip interface Ethernet0/0 on R1 to check the IP address, subnet mask, and OSPF area configuration.
• show ip ospf neighbor to check the neighbor status, since I got no neighbors, this was the first indication that there was an issue with the OSPF configuration.
• show ip ospf interface to verify OSPF is enabled on the correct interfaces and to check the OSPF parameters.
• show ip ospf database to see if there were any OSPF LSAs being exchanged.
• show ip interface brief to check the status of the interfaces.

With this information, I found that the IP address on E1 was configured with a /30 subnet mask, while R1 was configured with a /24 subnet mask. This mismatch was likely the cause of the adjacency failure, as OSPF includes the subnet mask in its Hello packets, and a mismatch would prevent the routers from recognizing each other as neighbors.

After identifying the subnet mask mismatch, I updated the IP address configuration on R1 to match the /30 subnet mask used on E1. After making this change, I issued the show ip ospf neighbor command again, and this time I saw that E1 and R1 had successfully formed an OSPF adjacency and were in FULL state. The routing tables on both routers also started showing OSPF‑learned routes, confirming that the issue was resolved.

Next, I confirmed Layer‑2 connectivity by pinging the neighbor IP addresses and checking the ARP tables, by running the show arp command. And I got the expected results. These two commands confirmed that there were no issues with physical connectivity or basic IP reachability between E1 and R1. This helped me narrow down the issue to the OSPF configuration rather than a physical or Layer‑2 problem.

Finally, I confirmed that OSPF was running on the correct interfaces by using the commands: show ip protocols and show run | section ospf. This helped me ensure that OSPF was properly configured on both E1 and R1. Once this was confirmed, I confirmed that ospf also worked as expected on R2 and R3.

Conclusion

In conclusion, the OSPF adjacency issue between E1 and R1 was caused by a subnet mask mismatch. By verifying the interface parameters, OSPF configuration, and Layer‑2 connectivity, I was able to identify and resolve the issue. This troubleshooting process really shows the importance of attention to detail when configuring OSPF, as even a small mismatch in subnet masks can prevent routers from forming adjacencies and exchanging routing information.

It also shows the value of using a structured approach to troubleshooting, starting with basic connectivity checks and then moving on to more specific OSPF configuration verification. By following these steps, I was able to successfully resolve the OSPF adjacency issue and restore proper routing between E1 and R1, as well as R2 and R3.

01- Summarization Lab

You will find all the labs in the Bitsize series on my Github, link to repo: CML-bitsize-labs.

Learning Objectives

• Understand the concept of OSPF summarization and its benefits in reducing routing table size and improving network efficiency.
• Learn how to configure OSPF summarization on a router and verify its functionality.
• Gain hands-on experience with OSPF summarization in a lab environment.
• Develop troubleshooting skills related to OSPF summarization and its effects on network connectivity.

Lab Overview

Learn more about summarization in my Encore notebook on github: OSPF Summarization - Encor/CCNP Notebook

Lab Instructions

1. Setup: Clone the lab repository and navigate to the 01-summarization folder. Review the provided startup configurations for the routers in the lab topology.
2. Configuration: Import the cml_import.yaml file into the CML environment. Follow the instructions in the Lab Tasks to configure OSPF summarization on the appropriate routers. Use the CLI to apply the necessary commands and verify your configuration.
3. Testing: After configuring summarization, test the network connectivity and routing tables to ensure that the summarization is working as expected.

Lab Tasks

1. Identify the Networks: Review the network topology and identify the networks that need to be summarized.

R1 is part of area 10 of the OSPF network and is connected to R2 via a transit link. R1 has 3 loopback interfaces (lo1-3) that are part of the ospf area 10 and are advertised into the ospf network. The other loopback interfaces (lo4-6) are part of a external network and are not advertised into the OSPF network.

R1 has the following networks and configurations:

Interfaces:
Ethernet0/0: 10.10.0.2/30 #Transit to R2
lo1: 10.10.1.1/30 #Loopback1
lo2: 10.10.2.1/30 #Loopback2
lo3: 10.10.3.1/30 #Loopback3
lo4: 10.11.1.1/30 #Loopback4
lo5: 10.11.2.1/30 #Loopback5
lo6: 10.11.3.1/30 #Loopback6

Static routes in routing table:
10.11.1.0 255.255.255.252 Loopback4
10.11.2.0 255.255.255.252 Loopback5
10.11.3.0 255.255.255.252 Loopback6

Ospf:
router-id: 1.1.1.1
Area 10 - lo1, lo2, lo3
External - lo4, lo5, lo6

R2:

Ethernet0/0: 10.10.0.1/30 #Transit to R1
Ethernet0/1: 10.0.0.1/30 #Transit to R3

ospf:
router-id: 2.2.2.2
area 10 - ethernet0/0
area 0 - ethernet0/1

R3:

Ethernet0/0: 10.0.0.2/30 #Transit to R2
Ethernet0/1: 10.20.0.2/30 #Transit to R4

ospf:
router-id: 3.3.3.3
area 0 - ethernet0/0
area 20 - ethernet0/1

R4:

Ethernet0/0: 10.20.0.1/30 #Transit to R3

ospf: 
router-id: 4.4.4.4
area 20 - ethernet0/0

1. Configure Summarization: On R1, configure OSPF summarization for the loopback interfaces. Use the appropriate OSPF commands to create a summary route that encompasses all the loopback interfaces.

2. Verify Configuration: After configuring summarization, verify that the summary route is being advertised correctly. Use OSPF show commands to check the routing tables on R2 and R3 to ensure that they are receiving the summarized route.

Find these facts: Q1: What is the summary route that R1 is advertising for the loopback interfaces? Q2: What is the subnet mask of the summary route? Q3: Are the individual loopback interfaces still being advertised, or are they being replaced by the summary route?

Answers will be found below in the walkthrough section, but try to answer them on your own first before checking the walkthrough.

1. Test Connectivity: Test the connectivity from R2 and R3 to the loopback interfaces on R1. Use ping and traceroute commands to verify that the summarized route is functioning correctly and that the individual loopback interfaces are reachable.

Walkthrough

This is a walkthrough of the lab, where you can find the commands and steps to complete the lab tasks. It is recommended to attempt the lab on your own before referring to the walkthrough.

Identify the Networks: First off, the task is simple: Review the network topology and identify the networks that need to be summarized. That is done with the following command on R1:

show ip interface brief
show ip ospf interface

I like to first check the interfaces and their IP addresses with show ip interface brief to get an overview of the interfaces and their configurations. Then, I use show ip ospf interface to see which interfaces are part of the OSPF process and their associated areas.

From the output, we can identify that the loopback interfaces (lo1, lo2, lo3) are part of area 10 and are being advertised into the OSPF network. The other loopback interfaces (lo4, lo5, lo6) are not part of any OSPF area and are not being advertised into the OSPF network. These are the interfaces that we will be summarizing. Make sure they are configured as static routes in the routing table, which is done with the following command:

show ip route static

We also need to identify which roles the routers role in the OSPF network. This will be displayed with the following command on R1:

show ip ospf neighbor

This command will show us the OSPF neighbors and their associated areas. From the output, we can see that R1 is connected to R2 in area 10, and R2 is connected to R3 in area 0. R3 is connected to R4 in area 20. This means that R1 is an internal router in area 10, R2 is an ABR between area 10 and area 0, R3 is an ABR between area 0 and area 20, and R4 is an internal router in area 20.

Configure Summarization: To configure OSPF summarization on R1 for the loopback interfaces, we can use the following command in OSPF router configuration mode:

router ospf 1
area 10 range 10.10.0.0 255.255.252.0

This command tells R1 to summarize the routes in area 10 into a single summary route of 10.10.0.0/22.

Next is to inject the external routes into the OSPF network. This is done with the following command: ```router ospf 1 redistribute static subnets

<br>
This command tells R1 to redistribute the static routes (which are the loopback interfaces lo4, lo5, lo6) into the OSPF network as external routes.
<br>

**Verify Configuration**: After configuring summarization, we can verify that the summary route is being advertised correctly by checking the routing tables on R2 and R3. On R2, we can use the following command:

show ip route ospf ``` This command will show us the OSPF routes in the routing table. We should see the summary route of 10.10.0.0/22 and the external routes for the loopback interfaces lo4, lo5, lo6.

Answers to the Find the Facts questions: Find these facts:

Q1: What is the summary route that R1 is advertising for the loopback interfaces?
A1: 10.10.0.0/22

Q2: What is the subnet mask of the summary route?
A2: 255.255.252.0

Q3: Are the individual loopback interfaces still being advertised, or are they being replaced by the summary route?
A3: The individual loopback interfaces are replaced by the summary route.

Resources

• Cisco OSPF Documentation
• Cisco OSPF Configuration Guide
• Cisco OSPF Summarization Documentation

Installing Ansible on Ubuntu 22.04.5 LTS

You will find all the labs in the Bitsize series on my Github, link to repo: CML-bitsize-labs.

Step 1: Install Ansible and the required libraries

Make sure that you check which version of Ubuntu you are running, this guide will be compatible with the 22.0.4.5 LTS release of Ubuntu. To check the current version installed on WLS run this command

lsb_release -a

expected output:
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.5 LTS
Release:        22.04
Codename:       jammy

Now you can move on and update the system,adding the required repos in the apt installation reposotories and installing ansible.

sudo apt install software-properties-common
sudo apt-add-repository ppa:ansible/ansible
sudo apt update
sudo apt install ansible

Install the cml collection to be able to automate in with Ansible in CML. You will find the documentation here.

ansible-galaxy collection install cisco.cml

To be able to connect with CML, you need to have VIRL2. First install pip and the VIRL2 Client:

sudo apt install python3-pip -y
pip3 install virl2-client

# check if if virt2-client is installed property
python3 -c "import virl2_client; print('OK')"

Now its time to check so the correct versions are installed and that the filepaths are ok:

which ansible 
ansible --version
which python3

Expected output with comments for clarification:

#which ansible, where the ansible config files are stored
/usr/bin/ansible
#ansible --version, which version of ansible is running an data associated with it
ansible [core 2.17.14]
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.10.12 (main, Jan 26 2026, 14:55:28) [GCC 11.4.0] (/usr/bin/python3)
  jinja version = 3.0.3
  libyaml = True
#which python3, where the python config files are stored
/usr/bin/python3

To make it work on my WLS I had to install, since the default python3 on WLS is 3.10, the latest versions of httpx, httpcore and h11 to be able to use the virl2-client library. SSH and paramiko are also required to be able to use ansible with cml, but they should be installed with the virl2-client library.

python3 -m pip install --upgrade httpx httpcore h11

Step 2: Test the Ansible to ping the CML server

Now all the packages are upp to date and operational. So now you, if you don’t already have it, have to make a folder where you will store the python scripts, hosts.ini and playbooks, and cd into it.

mkdir ansible
cd ansible

We will start with a Ansible playbook to test the connection to CML, but before that we will need to create a host ini file and a playbook to be able to test the connection.

Lest start with the hosts.ini file, this is where you will store the information about the devices you want to connect to in CML. In my case its the localhost since I am running the playbooks on WLS, but if you are running it on a different machine you will have to change the ip to the ip of the machine where CML is running.

# hosts.ini file for ansible with cml
[cml]
localhost ansible_connection=local

Now we will create a playbook to test the connection to CML, this playbook will use the cml collection to connect to CML and get the version of CML we are running.

---
# playbook to test the connection to CML
- name: Test connection to CML
  hosts: cml
  gather_facts: no

  tasks:
    - name: Ping the CML server
      ansible.builtin.ping:

To run the playbook, use the following command:

ansible-playbook -i hosts.ini test_cml_connection.yml

If everything is working correctly, you should see a successful ping response from the CML server in the output of the playbook run. This confirms that Ansible is able to ping the CML server correctly.

Step 3: Create a node in a running lab with Ansible

Now that we have confirmed that Ansible can connect to CML, we can move on to creating a node in a running lab with Ansible. For this we will need to create a new python file that will create a new node in a running lab.

# create_node.py file to create a new node in a running lab
import urllib3
urllib3.disable_warnings()

from virl2_client import ClientLibrary

CML_URL = "https://YOUR_IP_TO_CML_SERVER"
USERNAME = "YOUR_USERNAME"
PASSWORD = "YOUR_PASSWORD"

LAB_NAME = "Enterprice Network Lab"   # The name of the lab you want to work with, make sure it is running before you run the script
NODE_NAME = "NewRouter1"    # The name of the node you want to create, make sure it is unique in the lab
NODE_DEFINITION = "iol-xe"    # The id of the node. For exampel: iosv, iosvl2, alpine, server, etc.

client = ClientLibrary(
    url=CML_URL,
    username=USERNAME,
    password=PASSWORD,
    ssl_verify=False
)

# Get the list of labs and find the lab we want to work with
labs = client.all_labs()
lab = None
for l in labs:
    if l.title == LAB_NAME:
        lab = l
        break

if lab is None:
    print(f"Labb '{LAB_NAME}' hittades inte.")
    exit(1)

# Create a new node in the lab. Make sure to adjust the x and y coordinates to place the node where you want it in the lab topology.
node = lab.create_node(
    label=NODE_NAME,
    node_definition=NODE_DEFINITION,
    x=100,
    y=100
)

lab.sync()

print(f"Node '{NODE_NAME}' created in lab '{LAB_NAME}'.")

Make sure to replace the CML_URL, USERNAME, PASSWORD, LAB_NAME, NODE_NAME and NODE_DEFINITION with the correct values for your lab. You can find the node definitions by looking at the nodes in your lab (Tools->Node and Image definitions -> Node definitions).

Then we will make a new playbook that will run the python script to create a new node in the lab.

---
- name: Create a new node in a running lab
hosts: cml
gather_facts: no


tasks:
  - name: Run the create_node.py script
    ansible.builtin.command: python3 create_node.py
    registers: output
    
  - name: Print the output of the script
    ansible.builtin.debug:
      msg: ""

So the last thing is to run the playbook to create a new node in the lab, use the following command:

ansible-playbook -i hosts.ini create_node.yml

If everything is working correctly, you should see a message in the output confirming that the node has been created in the lab. You can then go to the CML web interface and check that the new node has been added to the lab topology.

Conclusion

In this lab, we have successfully installed Ansible on Ubuntu 22.04.5 LTS, set up the necessary libraries to connect with CML, and created a new node in a running lab using Ansible and a Python script. This demonstrates the power of automation with Ansible and how it can be used to manage and interact with network labs like CML efficiently. I hope this guide has been helpful in getting you started with Ansible and CML, and that you can now explore more advanced automation tasks in your network labs!

I would love to hear your feedback on this lab and if you have any suggestions for improvements or additional topics you would like to see covered in future labs. Feel free to reach out to me on LinkedIn or through the GitHub repository.

Happy automating!