arunkumartechstar/ospf_project

Purpose and entry points

This repository automates deployment and validation of an OSPF lab on FRRouting Docker nodes hosted by GNS3. Its operational entry point is generate_and_push.py; generate_and_push_old.py is a legacy alternative. The main script supports generation-only, deployment, and validation-only modes.

Paths: generate_and_push.py, generate_and_push_old.py

Topology source of truth

The YAML inventory defines routers, interfaces, loopbacks, OSPF networks/areas, and configured container identifiers. It is the intended change boundary for adapting the lab topology without changing automation code.

Path: inventory/ospf_topology.yaml

Configuration rendering stage

The automation loads the inventory and renders a per-router FRR/vtysh configuration through Jinja2. The template translates topology fields into interface addressing and OSPF configuration; generated artifacts are written as router-specific .cfg files.

Paths: templates/frr_ospf.j2, configs/FFR-1.cfg, configs/FFR-2.cfg, configs/FFR-3.cfg

Container discovery and deployment boundary

The script operates from the GNS3 VM and uses the local Docker CLI as its control-plane boundary. It resolves configured or live GNS3 Docker containers by router/node name, copies rendered configuration into each container’s /etc/frr/frr.conf, and configures FRR daemon settings. Docker container IDs are ephemeral across GNS3 restarts, so live discovery is material to reliable deployment.

Path: generate_and_push.py

FRR process orchestration

Within each target container, deployment ensures zebra and OSPF daemon behavior is compatible with the generated configuration. Zebra must establish interface state before ospfd; FRR daemons are explicitly started/restarted against /etc/frr/frr.conf rather than relying on image defaults. This is the key runtime boundary between Python automation and the FRRouting control plane.

Paths: generate_and_push.py, templates/frr_ospf.j2

Validation flow

After deployment, the script invokes vtysh through Docker to inspect OSPF neighbor adjacencies and learned routes, then tests loopback reachability among routers. Validation can run independently, allowing operators to distinguish configuration rendering/deployment failures from OSPF convergence failures.

Path: generate_and_push.py

Runtime and infrastructure dependencies

Execution requires Python 3.8+ with PyYAML and Jinja2, Docker available on the GNS3 VM, GNS3 2.2.x topology nodes, and the frrouting/frr:v8.4.0 image. The designed lab is a three-router, Area 0 triangle; the automation itself is inventory-driven and can target expanded topologies if GNS3 links and inventory remain consistent.

Paths: requirement.txt, inventory/ospf_topology.yaml