Designing the topology was only the start. The real work was creating a clean address plan, configuring dynamic routing, and proving that every route was being learned correctly.
Cisco Packet Tracer
Cisco IOS
RIP
IPv4
/30 Subnetting
StatusCompleted
FocusNetworking
Core toolsCisco Packet Tracer · Cisco IOS · RIP
R1R2R3R4
Project overview
I configured a four-router topology in Cisco Packet Tracer and used RIP to enable IPv4 route exchange across point-to-point connections. The project connected network design, address planning, router configuration, and command-line verification into one complete workflow.
Technical details
How the system works.
A closer look at the architecture, implementation decisions, and validation behind this project.
01
Topology and address planning
The network uses four routers connected by point-to-point links. Before entering any IOS configuration, I treated the topology as an addressing problem: every interface needed to belong to the correct network, and every router-to-router link needed its own non-overlapping subnet.
I used /30 networks for the point-to-point connections. A /30 provides four addresses: one network address, two usable host addresses, and one broadcast address. That gives exactly one usable address to each router interface while avoiding a larger subnet with unused host capacity.
02
Dynamic routing with RIP
After configuring interface addresses, I enabled RIP and identified the connected networks each router should advertise. Each router began with knowledge of only its directly connected networks; RIP allowed neighboring routers to exchange that information and build routes to remote destinations.
RIP is a distance-vector protocol, so route selection is based on hop count. In this topology, that made it possible to see how a route learned from one neighbor continues to propagate until all four routers understand how to reach the complete network.
Directly connected networks provide the starting routes
RIP advertisements share reachable networks with neighbors
Hop count provides the route metric
03
Routing-table verification
Configuration was not complete until the routing tables showed the expected learned networks. I inspected the IOS routing information on each router and distinguished local or connected entries from routes learned through RIP.
I compared the next-hop address and outgoing interface against the topology. This let me verify not only that a destination appeared in the table, but also that the router planned to forward packets in the correct direction.
04
Troubleshooting method
When a route did not appear, I worked from the lowest-level dependency upward: interface state, IP address and mask, connected network, RIP advertisement, and finally the remote routing table. This prevented me from changing routing settings when the actual problem was an interface or addressing mismatch.
The project reinforced that network troubleshooting is evidence-driven. A successful topology is not defined by how the diagram looks; it is defined by what each router knows and where it will send the next packet.
Engineering approach
From idea to working system.
01
Plan the topology
I organized four routers around point-to-point links and mapped the networks that each router needed to advertise and learn.
02
Build the address plan
I applied /30 subnetting to the router-to-router links, creating focused address ranges for each point-to-point connection.
03
Configure and verify
I configured RIP through Cisco IOS, then inspected routing tables to confirm that routes propagated across the full topology.
Technical highlights
What this project demonstrates.
01
Four-router network topology
02
IPv4 route exchange with RIP
03
/30 point-to-point subnetting
04
Cisco IOS routing-table analysis
What I learned
This project strengthened my understanding of how logical address planning and routing protocols work together - and how to verify a network from the router's point of view.