Coursework snapshot
- Coursework context
- Individual first-year networking coursework combining a Packet Tracer design with two Python client-server applications.
- Work completed
- I subnetted and routed the departmental network, added IPv6 and SSH administration, then implemented a TCP document-statistics service and UDP calculator.
- Technical focus
- IPv4 subnetting
- IPv6 addressing
- Static routing
- Router administration
- Python TCP sockets
- Python UDP sockets
- What it demonstrates
- The work joined network design to application protocols and exposed implementation defects that later informed my handling of framing, validation, transport reliability and error paths.
Designing the departmental network
My CMP109 assignment modelled a small organisation in Cisco Packet Tracer. Finance, marketing, sales, and customer-service departments each had their own LAN, with Cisco 1941 routers joined through a central 2960 switch.
Each department needed five workstations plus a default gateway. I selected /29 IPv4 networks, giving eight addresses per subnet and six usable host addresses. Consecutive ranges divided 192.168.0.0/24 into the departmental networks and a separate router transit network.
The topology used a star arrangement at the routing layer:
- one router per department
- one interface into the departmental LAN
- one interface into the shared transit segment
- static routes pointing towards the router responsible for each remote subnet
I documented the network address, host range, broadcast address, gateway, and next hop for each segment. I also made an addressing mistake in the marketing gateway and left the customer-service route incomplete. Those errors show exactly why an address plan needs to be validated rather than only described.
Adding IPv6
The same topology was configured for IPv6. I enabled IPv6 unicast routing on the routers, assigned /64 prefixes, used link-local addresses for neighbouring router hops, and allowed hosts to construct interface identifiers through EUI-64.
Working with both protocol versions on one topology helped separate the routing concepts from the notation:
- a host still needs a local prefix and a route off the subnet
- routers still need a path to each destination network
- link-local addresses provide on-link communication
- the configuration and neighbour-discovery behaviour differ from IPv4
Static routes were appropriate for the scale of this assignment. A larger or frequently changing environment would need a dynamic routing design and more deliberate failure handling.
Router administration
I restricted remote administration to SSH rather than Telnet and configured local administrative access on the routers.
The configuration used short passwords and 512-bit RSA keys that should not be copied into a current deployment. Cisco IOS also distinguishes between reversible password obfuscation and secure credential hashing; simply enabling the old password-encryption service does not make weak secrets safe.
The useful part of the exercise was establishing the management boundary: administrative access should use an encrypted protocol, be limited to authorised sources, use current cryptographic settings, and be kept separate from ordinary user traffic where possible.
TCP document statistics
The Python work moved the same networking concepts into code. The TCP exercise used a client to read a text file and send its contents to a listening server on the loopback interface.
The server:
- accepted a connection
- received the document data
- decoded it from UTF-8
- counted words with
split() - counted non-space characters
- sent the two results back to the client
TCP suited the exercise because the document and response needed an ordered, reliable byte stream. It also introduced a protocol-design issue: two values sent with consecutive sendall() calls are not guaranteed to arrive as two matching recv() calls. TCP preserves byte order, not message boundaries.
The TCP implementation contains several additional faults. The client attempts port 11000 while the server listens on 4445, so they cannot connect without correcting the endpoint. The client also opens one machine-specific absolute path and reads only 4,096 characters; the server performs one 4,096-byte recv(). A larger document could therefore be truncated even after the port was corrected. Finally, the client uses recvfrom() for the two replies even though the socket is a connected TCP stream.
A stronger version would share one endpoint configuration, accept a file path safely, define a response format, prefix messages with their length, read until the declared amount has arrived, use recv() for the stream response, and use context managers for the file and socket.
UDP calculator
The UDP exercise used a client to collect two numbers and an operation, then sent the three values as datagrams to a server. The server decoded them, selected an arithmetic function, and returned the result.
That design exposed the difference between the two transport protocols. UDP retains datagram boundaries but does not establish a session or guarantee delivery, order, or uniqueness. The code therefore had to retain the client’s address from recvfrom() so the response could be directed back to the sender.
The four operations were implemented as separate functions:
- addition
- subtraction
- multiplication
- division
As written, the UDP client and server use different ports, and the response conversion and send are indented below branches that exit the loop. The intended design is clear, but those faults must be corrected before it will run end to end.
What the exercises established
The Packet Tracer topology and the socket programmes worked at different scales, but they exercised the same chain:
- choose addressing and endpoints
- establish how data will move
- define what each side expects
- handle input and output
- test the path
- investigate where the configuration and the implementation disagree
This is early coursework, and the implementations are not production network services. They show the start of the progression into later segmentation, tunnelling, infrastructure, and security-monitoring work.