INGIniousThis lab will allow you to:
- Diagnose: use vtysh to inspect BGP roles and peering relationships between AS (see [1]).
- Fix: identify and resolve configuration errors related to BGP roles enforcement
In this lab, you will need to verify and enforce the following interdomain routing policies based on BGP roles:
- Routes learned from a customer must be exported to all neighbors (customers, peers, and providers).
- Routes learned from a peer or a provider must be exported only to customers.
These policies are enforced using BGP Roles and OTC (Only-To-Customer) attribute as defined in .
Lab Presentation
This image represents the correct topology (without errors) that you should obtain after debugging [2].
Each router should advertises its loopback address as a BGP prefix.
This lab contains a preconfigured network infrastructure, but several intentional errors have been introduced, including incorrect BGP roles configuration. It's up to you to identify and fix them!
📥 Download the Base Lab
To begin the exercise, you need to download the archive [3]. It contains the base configuration with errors to fix.
Diagnostic Tools
vtysh is the unified command-line interface of FRRouting (the routing software used in the containers).
It allows you to configure and inspect all routing protocols (BGP, OSPF, RIP, etc.) from a single interface.
Useful commands for diagnosing BGP:
# Access vtysh on r5 root@r5:/# vtysh r5# # All following commands are run inside vtysh # Displays the active BGP configuration show running-config # Display BGP neighbor summary (session status, local pref values...) show bgp ipv6 summary # Display the complete BGP routing table (learned routes) show bgp ipv6 unicast # Display routes advertised to the neighbors show bgp neighbors <IP> advertised-routes # Display BGP roles (local / remote) show bgp neighbor <IP> json
show bgp neighbor ... command lets you view useful information such as localRole and remoteRole. Try experimenting with its various options. It's a great way to verify that roles are correctly configured and consistent on both sides.Recommended Approach
Explore the topology
Examine the
lab.conffile to understand which containers are defined and how they are connected. Use the image above to visualize the connections.Connect to containers
Use Kathara to start the lab and connect to each router/container:
cd ./variant_X # Start the lab, automatically opens terminals kathara lstart # Open a terminal kathara connect [node_name] # Remove containers kathara wipe
Inspect the configuration
Pay special attention to BGP roles configuration and verify that each relationship (customer, provider, peer) is correctly defined on both sides.
Fix the errors
📌 Important Rules:
- ❌ Do not modify the
lab.conffile (it is correct and contains no errors) - ❌ Do not create new files (all corrections are made in existing files)
- ✅ Respect the exact folder structure of the provided archive (relative paths are important)
Modify the files and report these changes to the corresponding files on your host machine (those that will be re-archived).
- ❌ Do not modify the
Validate your fixes locally
cd ./variant python3 -m kathara_lab_checker --config correction_student.yaml --no-cache --lab . # or kathara_lab_checker --config correction_student.yaml --no-cache --lab .
Submit your solution
Once all tests pass locally (remember to add more), compress the entire
variant_Xfolder into a .zip file and upload it below.
- Kathara: Documentation | Installation | Commands
- FRRouting Documentation: BGP Commands | BGP Roles
- Computer Network online syllabus: BGP example
- BGP Roles (RFC 9234): Link
| [1] | Reference to BGP Roles / RFC 9234 (see links above) |
| [2] | This topology is taken from the Computer Networks online syllabus |
| [3] | This file gives an high score, the goal is to reach 100%. |