Device settings belong in a repository, not in somebody's memory. Once every change is visible, justified and reversible, network management stops being guesswork.
Done Dynamics works on router configuration and switch configuration, VLAN segmentation, multi-link management, firmware planning and the takeover of undocumented networks. One principle sits at the centre of how we work: configuration is code. What lives on the device is not the only copy — the repository holds the reference; every change is recorded with its diff and its reason, and a bad rule is reverted in minutes. This principle works the same way in a small office and in a ten-location business. On site around Alanya and Antalya, remotely across Turkey.
In most organisations, network device settings live in the device memory and in the heads of a couple of people. When that person leaves or the device fails, the knowledge goes with it. This problem was solved on the software side years ago, and the same solution applies to networks.
Every device configuration is kept in a version-controlled repository. What sits on the device is not the only copy; the repository holds the reference. If a device burns out, the configuration does not go with it — the same file is written to its replacement.
When a rule is added, exactly what changed is visible line by line. This ends the arguments: was the device touched, what changed, who did it — all of it stays on record. Network management that relies on spoken memory stops working past a certain size.
A single mistyped access rule can take internet away from an entire floor. With the previous version sitting in the repository, rollback does not wait for anyone to diagnose the mistake. The old state is restored first, service returns, and the cause is examined afterwards.
The reason is written next to the record: which request, who asked, what date. Being able to answer why a rule exists a year later is the precondition for ever simplifying the rule set. Rules without a stated reason are never removed, because nobody dares remove them.
Routing or VLAN changes carry outage risk. Before every planned change a backup is taken, and both the steps to apply and the steps to revert are written in advance. If the work does not finish inside the window, the written rollback plan decides what happens next — not a discussion.
The live configuration on the device is compared periodically against the repository. A difference means somebody touched the device by hand and did not record it. This audit is the only practical way to stop a network from quietly becoming undocumented again.
Where this approach pays off most visibly is during an incident. When the network slows down or a department loses internet, the first question is always the same: what changed yesterday? Without version-controlled configuration there is no answer; everyone reports what they remember, and fault finding turns into guesswork. With a repository, the answer takes thirty seconds: the last change was made at this time, this line was added, and here is the reason.
The second payoff comes at hardware replacement. Swapping in a new switch for one that burned out is a multi-day rediscovery exercise if you do not hold its configuration. With the file in the repository, the same job takes half an hour. The same applies at a new branch opening: with role-based templates, the new location is not designed from scratch but produced from a pattern.
Routing, multiple links and prioritisation. Get these three right and users never notice the network exists.
Which destination leaves through which interface. In small networks static entries are sufficient and easy to read. As the number of locations and subnets grows, a hand-written table becomes error prone; at that threshold we move to dynamic routing so adding a new subnet does not mean touching every device individually.
Dynamic routing adapts automatically, but a bad configuration propagates the fault automatically too. Our decision point: if location count and rate of change are low, routing stays static and documented; where there are redundant links and many subnets, dynamic routing goes in with strict limits on what is advertised where.
Plugging in two internet lines is not redundancy; until failover rules are written, the second line simply sits idle. Whether a link works is measured by reachability to a real target — an interface showing physically up is not enough, because the modem can be up while the internet is gone. Failover timing and fallback behaviour are stated explicitly in the configuration.
Using two links together rather than as spare is possible, but not every application tolerates it. A session that changes link mid-flight drops. So we build load sharing per session, and pin sensitive destinations such as banking and accounting to a fixed link.
Who goes first when the link is full. Voice calls and point-of-sale transactions are latency sensitive; backups and update downloads are not. Without prioritisation, one large download ruins telephony for the whole office. This is the cheapest performance gain available without upgrading the link.
Every port opened outward stands with a written reason beside it. Forwards accumulated over the years, whose purpose nobody remembers, are the quietest risk item in a network. On inherited networks, one of the first things we do is extract this list and match every line to an owner.
A large share of network problems originate not at the router but in the switching layer: a wrong trunk setting, aggregation configured on one side only, an accidental loop, or an exceeded PoE budget. Getting this layer right makes every later diagnosis easier.
VLANs and trunking
Guest, staff, camera, point-of-sale and server traffic separated into their own VLANs. Without separation, a device on the guest network can reach the camera recording server. Traffic between switches travels over trunk ports; which VLANs are permitted on which trunk is restricted, and the allow-everything default is never left in place.
Link aggregation (LACP)
Running several cables between two switches, or to a server, and using them as one logical link. Bandwidth rises and the connection survives a single cable failure. The configuration must match at both ends; aggregation configured on one side only produces a loop.
Spanning tree and loop prevention
The classic event that stops a network dead: two ports patched into the same switch. Once a loop forms, broadcast traffic multiplies and the network locks up within seconds. Spanning tree prevents this, but left at defaults the root device is chosen arbitrarily; we pin the root ourselves and enable loop protection on edge ports.
Port security
What a device plugged into the spare socket in the meeting room can do. Unused ports shut down, device count and identity limits on active ports, port-based authentication in sensitive areas. Not handing the entire network to anyone with physical access is a decision made during deployment, not afterwards.
PoE budget
Cameras, access points and IP phones draw power from the switch. If total draw exceeds the switch PoE budget, devices start dropping one by one and the cause goes unfound for weeks. During deployment the power class per device is summed, the budget is calculated, and headroom is left for growth.
Broadcast domain and segment size
When hundreds of devices share one flat network, broadcast traffic creates needless load and fault isolation gets harder. Keeping segments at a sensible size buys both performance and easier diagnosis. The split is decided by the nature of the traffic, not by device count alone.
The decision to update a network device is made by reading what the patch fixes — not by the size of the version number.
Updating a network device carries a different risk from updating a server: if it goes wrong you cannot fix it remotely, because the path you would use to fix it runs through that very device. So our default is to wait, and our exception is to hurry.
A flaw allowing unauthenticated remote access does not wait; it goes in at the first suitable window, out of hours if necessary. A release fixing a cosmetic interface bug goes on the planned calendar. We make this distinction per release note rather than applying a blanket update-everything or touch-nothing policy.
Planned updates run in windows announced in advance. The order inside each window is fixed: backup first, then a trial on a non-critical device, then the rest. Updating the whole network at once makes rollback impossible the moment something goes wrong.
Devices whose vendor support has ended are kept on a separate list, and that list is reported to management regularly. These devices will not receive a patch when the next flaw appears; the risk is a budget line, not a technical footnote. Replacement is planned from this list, rather than decided in a hurry the day a device fails.
A backup is measured not by the existence of a file but by how quickly that file brings a device back up. So we do not just take backups; we exercise the restore procedure regularly and for real.
In networks where every device was built its own way, maintenance cost grows with variety rather than with device count.
Floor switches are configured from one template; access points from another, branch routers from another. What is learned on one device applies to the next, incident response speeds up, and adding hardware no longer requires a redesign.
A device name should reveal location, floor and role. On a monitoring screen, the difference between SW-ALY-F2-01 and switch3 is the difference between knowing and not knowing where to go when an alert arrives at midnight. Conventions are set at the start; retrofitting them is painful.
Every port carries a note about what is connected to it: which room, which device, which floor. This single habit ends hours of cable tracing in the field. A documented port outlives a physically labelled cable.
A predictable relationship is established between VLAN numbers and address blocks. Anyone who knows the scheme can look at an address and say which segment of which location it belongs to, without memorising anything. In growing networks this directly lowers the error rate.
Most networks we inherit look similar: unlabelled cables in the rack, static addresses nobody can explain, port forwards opened years ago and forgotten, and a device or two whose management password has been lost. This picture is rarely anyone's negligence — it comes from a network passing through hands that never met each other over many years.
In the first phase we change nothing. We establish what exists first, because a change made without understanding produces the hardest kind of fault to find. Once mapping is complete, improvement proposals are presented in order of risk and each one is applied in its own planned window.
Documentation comes before deployment; every change made before the map exists is a risk.
Devices, versions, ports, VLANs and addresses are documented. On undocumented networks this is the longest part of the job, and it cannot be skipped.
Role-based configuration templates, naming conventions, VLAN and addressing schemes are written. You hold the documents before deployment begins.
Changes are applied in a planned window, with a backup taken and rollback steps written down. Every step is committed to the configuration repository.
VLAN separation, failover, aggregation, PoE budget and priority rules are actually tested, and the results are reported.
Drift detection, firmware calendar, configuration backup and capacity reporting run as an ongoing service.
Quoting improvements on an undocumented network is not honest; without knowing what exists, nobody can say what needs fixing. So we split the work in two: first a fixed-fee inventory and documentation exercise, then a risk-ordered improvement plan built on what it reveals. The output of the documentation phase belongs to you, not to us — the diagrams, the inventory and the configuration repository stay with you. Ongoing management is written as a separate line, because a network without drift detection and a firmware calendar starts quietly losing its documentation from the day it is built.
No. Most enterprise-grade routers and switches share the same concepts: VLANs, trunking, aggregation, spanning tree, priority rules. Command syntax differs between vendors; the design decisions do not. We prefer to work with whatever hardware you already own. If new equipment is needed, we hand over the selection criteria in writing — port count, PoE budget, vendor support horizon, management interface — and leave the decision to you. Locking into a single vendor has a cost too, and that is worth discussing up front.
You do. The configuration repository belongs to you, and we hold access to it. If our paths separate at any point, the complete configuration of your network, its change history and its documentation stay with you. We put this in the contract. We do not think a working model that holds configuration hostage is defensible; a provider should earn its value by doing the work well, not by withholding knowledge.
Some changes can be applied without interruption: adding a VLAN, writing descriptions, adjusting monitoring. Others unavoidably cause a short outage: device reboots, trunk reconfiguration, a spanning tree root change. We state in advance which category each planned change falls into and move the disruptive ones into an out-of-hours window. We also give a written duration estimate; if the work does not finish inside the window, the rollback plan takes over.
From a configuration standpoint, usually yes — older devices can still be managed and brought under templates. The real question is whether they still receive security patches. A device past vendor end-of-support cannot be updated when a new flaw appears, and that risk cannot be closed by configuration. We keep these devices on a separate list and report the risk they carry along with replacement priorities. Replacing all of them at once is unrealistic for most organisations, so we order the work by risk.
Both. Configuration, monitoring, firmware updates and most fault diagnosis run remotely. Work that requires physical presence is separate: initial installation, cabling and labelling, patch panel tidy-up, hardware replacement and physical mapping. We work on site around Alanya and Antalya; across Turkey we manage remotely and, when hands-on work is needed, proceed through a planned visit or in coordination with a local team.
It is stated in the contract and its scope is agreed beforehand. The distinction we draw is this: an outage affecting an entire location and a problem affecting one user are not equally urgent. During an outage a remote session starts immediately; if the cause is configuration, rollback takes minutes, and if it is a hardware failure, spare equipment and an on-site visit take over. This is why we recommend keeping spare hardware for critical devices — procurement time, not diagnosis, is usually what sets the real response duration.
There are three lines. The first is takeover and documentation: inventory, mapping and template authoring. This is one-off and fixed-fee, scoped by how undocumented the current network is. The second is project work: new deployments, segmentation, hardware replacement. Those are quoted separately with a defined scope. The third is ongoing management: drift detection, firmware calendar, configuration backup, monitoring and incident response, billed as a monthly service fee. If hardware is required it appears as a separate item.
That is the most common starting point we see, and it is not a problem. The first job is inventory: which device is where, which version it runs, what is connected to which port. Then the logical map: VLANs, address blocks, routing. We change nothing during this phase and only record — because changing what you do not yet understand is the most expensive mistake available. When documentation is finished you hold a diagram, an inventory and a configuration repository. Improvement proposals come after that, ordered by risk.
Related services
Network design, cabling, segmentation and monitoring — the layer device configuration sits inside.
Rule sets, content filtering and logging; the security layer designed alongside router configuration.
Site-to-site and client VPN; routing and address planning run on the same config discipline.
The servers at the edge of the network: hosting, backup and access management planned together.
Ongoing management owning drift detection, the firmware calendar and incident response.
Book a free 30-minute discovery call with our team.
Our network and cyber security work is carried out by a team holding internationally recognised Cisco certification.
Issued by Cisco · Holder: Devrim Tunçer
A certification covering security operations centre (SOC) competency: security monitoring, incident response and analysis of network attacks. It is the foundation we rely on for intrusion detection, log correlation and post-incident response work.
Cisco training certificate · completed January 2023
Covers networking fundamentals: routing, switching, IP addressing and network security. The knowledge base we draw on for enterprise network setup and segmentation.