Algeria AgencyNetwork & connectivity
The loop, the second DHCP and the switch under the desk
Five years of additions by whoever needed a port. The three faults that produces, and the order you unplug in to find them.
The companion article is about buying: what a switch does, counting ports before comparing, the power budget, managed against unmanaged. It describes a network somebody chose.
This one describes the network you actually have. Nobody designed it: it grew for five years, one port at a time, by whoever needed one that afternoon.
Three faults come out of that history and they recur everywhere: the loop, the second address server, and the switch nobody declared. None of the three is diagnosable from a catalogue.
One point about scope, because two pages in this pillar could tread on each other: here we stay inside the building, on equipment you own. The operator’s line, and what happens when it goes down, belong to the neighbouring network article.
The network nobody designed
There was no decision. There was one port too few one day, a small box bought on the corner another day, and a cable run over a door as a week’s workaround and left for three years.
This is not an organisational failing and there is no use presenting it as one. Every one of those acts was reasonable at the moment it was made, and the person who made it had a real problem at three o’clock on a Tuesday.
What it produces does have a recognisable signature, though, and that is what makes this article useful. Three symptoms, always the same, and none of them looks like what it is.
The first is an abrupt and total stop: everything freezes at once, without warning, and sometimes comes back on its own. The second is a device that loses its address or "has no internet" while the one next to it works. The third is a slowness that comes and goes with no obvious timetable.
The first is almost always a loop, the second almost always a second address server, and the third a physical cable problem. The next three sections take them in that order, which is the order of severity rather than of frequency.
The loop: the only fault that stops everything at once
A loop is a path that returns to itself: two ports of the same switch joined by a cable, or two switches joined by two cables instead of one.
What happens next is peculiar and worth understanding once, because it explains the violence of the symptom. Some messages are broadcast to everybody by construction; in a loop they circulate, duplicate on every turn, and saturate the network within seconds.
The visual sign is the best thing in this article and costs nothing to check: the switch lights all blink together, at the same rhythm, very fast, including on ports where nothing is working. A normal network blinks unevenly.
The second sign is temporal: this is the only fault on this page that stops everything, at the same time, in one go. A gradual failure is not a loop; a failure at nine fifteen that took out the tills, the phones and the cameras together almost always is.
And one thing that misleads people: the loop may have been created three weeks earlier and done nothing until this morning, because one of the two cables was connected at only one end. Look for what somebody plugged in, not for what somebody installed.
Why it happens in a perfectly ordinary office
This needs a section, because the first reaction is to look for somebody to blame and that is the least productive line of enquiry.
The commonest scenario is a tidy-up. A coiled cable has been lying behind a shelf for months with one end already connected that nobody ever noticed. Somebody cleans, finds the free end, and plugs it in — because a dangling cable is obviously a cable that ought to be plugged in.
The second scenario is a good technical intention: two switches already linked, somebody adds a second link "to make it faster" or "in case the first one fails". That is exactly the right idea, and it needs a function the small unmanaged boxes do not have.
The third is an office move, where everything is reconnected from memory on a Sunday and a wall cable finds both ports of the same device.
The useful consequence of those three stories is a practical conclusion: prevention is not a notice on a wall, it is taking loose cables out of circulation. A cable that is not within reach does not get plugged in by mistake.
The second address server
On a network, exactly one device should hand out addresses. When there are two, each hands out its own, and devices get one or the other depending on which answered first.
The symptom is recognisable above all others and it is the one that wastes the most time: two machines side by side, on the same wall socket, one works and the other does not — and the next day it is the reverse. Nothing physical behaves like that.
The origin is almost always a second operator box reconnected "to add ports", or a wireless access point left in router mode instead of access-point mode. Both hand out addresses by default, and nobody knows it when plugging them in.
The check takes a minute on a machine: look at the gateway shown by the machine that works, then at the one shown by the machine that does not. Two different values settle the question and hand you the culprit’s address into the bargain.
The correction is a setting, not a purchase: the second device keeps its ports and its wireless, and simply stops handing out addresses. It is the only fault in this article repaired without unplugging anything, which is why it deserves to be looked for first when the symptom is intermittent per machine.
The switch under the desk
The third character is a small five-port box, bought for fifteen hundred dinars, sitting on the floor behind a desk, often under a plant or in an open drawer.
It is written down nowhere. It appears on no plan, no installer’s invoice, no inventory, and the person who bought it left long ago. It works, generally very well, for years.
It is not a fault in itself, and it matters not to go to war against it: it solves a real problem, that of a single wall socket for three devices. What it does that is harmful lies elsewhere — it makes the network different from your idea of it.
The method for finding them all is a subtraction and an afternoon. Count the devices that actually answer on the network, count the wall sockets you know about, and look at the difference. A gap of seven on a twenty-socket installation means there are at least two boxes somewhere.
After that it is not a hunt but a census: each one is opened, labelled, noted on the plan from section 8, and kept if it does useful work. A device that is known and labelled has stopped being a problem, even if it is still on the floor.
The extended cable, and faults that come and go
The third symptom — slowness that comes and goes — is nearly always physical, and it is the category everybody looks at last because it is not interesting.
Four causes cover most of what we find. A cable extended with a joiner in the middle, which works but degrades everything passing through it. A flat cable slipped under a door or a mat, crushed a little more every day. A cable run in the same trunking as a power supply, over several metres. And a wall socket where a wire has worked loose.
These faults share a signature: they do not cut, they degrade. The device stays reachable, video stutters, a file transfer takes ten times too long, and everything returns to normal without anybody having done anything.
The second signature is that they follow a timetable, and that is where the next section becomes useful. A cable alongside a power supply degrades when the machine next to it starts; a cable under a door degrades when the door is open.
The repair is not a setting. A joiner is replaced by a single continuous cable, a crushed cable is replaced, a cable alongside power is moved twenty centimetres. Each is a few minutes’ work, and all of them are invisible to every software diagnostic method.
Catching an intermittent fault: the date before the diagnosis
The rule that saves the most time on this page is not technical: write down the exact time before looking for the cause. Three dated occurrences are worth more than three hours of investigation.
The reason is that memory summarises and errs in a specific direction: "it often happens in the morning" becomes, once dated, "it happens at ten past eleven, nearly always". The second formulation contains the answer and the first contains none.
What to note is four columns on a sheet taped near the machine concerned: the date, the time, what was not working, and what was happening in the premises at that moment. The fourth is the one nobody writes and it is the one that solves it.
Three correlations recur regularly among our clients and are worth looking for before anything else: a device starting up, a production machine or an air conditioner switching on, and a shift change that multiplies the connected devices.
A week of recording costs a few minutes a day and shortens everything else. It is also the only thing in this article a non-technical person can do alone, completely, and hand to somebody else in a usable state.
The order you unplug in
Looking for a loop by unplugging at random is a reliable way to spend the day on it and create a second fault. There is an order, it fits in five steps, and it works with no tools at all.
One: start from the main switch, the one connected to the operator’s box. Two: unplug one by one the cables going to the other switches, leaving each unplugged for thirty seconds before moving on.
Three: watch the lights during each attempt. When the synchronised blinking stops, the loop is in the branch you have just unplugged, and you have divided the problem by five in five minutes.
Four: repeat the same move inside that branch. Five, and this is the step everybody skips: write down what you unplugged and reconnected, in order, on the same sheet as the previous section.
That last note is what distinguishes a repair from a patch-up. It tells you what was connected before you intervened, which is the only information you will need if the symptom returns in three weeks — and a returning symptom is the rule rather than the exception on this kind of installation.
The plan you draw while searching
The neighbouring network article asks for a one-page diagram before any purchase, and it is right. What we ask for here is different and complementary: the plan is drawn during the search, not before it.
The difference is not rhetorical. A plan drawn calmly describes what you believe you have; a plan drawn while unplugging describes what is actually connected, which is precisely the missing information on an installation that has drifted.
The format fits on one A4 sheet and four symbols are enough: the operator’s box, each switch, each wall socket in use, and a line for every cable joining two of those things. No addresses, no brands, nothing else.
Two rules make the plan durable. Each switch carries the same number on it as the label stuck to it, and the plan carries a date. A plan with no date is a plan nobody dares believe after a year, and therefore a plan that gets redrawn.
It lives next to the main switch, in a sleeve. Not in a computer, for the reason that also applies to the account sheet in the hosting article: a document describing the network must not depend on the network to be read.
What has to go, and what can stay
At the end of the search you have a list of objects nobody had declared. The natural reaction is to remove them all, and it is the wrong one.
What has to go is short and clear: loose cables connected at one end only, joiners in the middle of a cable, flat extensions under doors, and any second device handing out addresses. Those four render no service that something else does not render better.
What can stay is longer than people expect. A small switch feeding three devices from a single socket does exactly the job it was bought for, and removing it obliges you to run a cable nobody is going to fund this year.
So what decides is not the object’s origin but its position: a box at the end of a chain, feeding workstations, is legitimate. The same box used to join two zones of the building is a central point of fragility, and that one gets replaced.
Adopting rather than removing has a consequence to accept: an adopted device enters the inventory, gets a label, appears on the plan and becomes your responsibility. That is the price, and it is lower than the price of a cabling job.
The rule that stops it coming back
Everything above redoes itself within eighteen months if nothing changes in the way things get plugged in. One rule is enough, and it is not the one people expect.
The ineffective rule is a prohibition: "nobody plugs anything in without telling somebody". It gets ignored because it asks a person with an urgent problem not to solve it, which never happens.
The rule that works is physical: unused cables are not within reach. They live in a closed box, in a store, and not coiled behind a shelf. That is all, and it removes the commonest cause of a loop.
The second half is labelling, because it changes what a person does when they want to plug something in. In front of a labelled socket you look at the plan; in front of a bare socket you try it.
Add a one-minute habit for any managed switches you already have: loop protection exists on them and is often disabled. It does not replace the two rules above — it turns a total stop into one port shutting itself down, which is one user’s outage instead of the company’s.
What we do, and what we refuse to do
What we refuse first: pricing an installation replacement to fix a loop. It is the easiest quotation to get accepted, because the client has just lived through a day of total stoppage, and it sells a construction job in place of a cable to unplug.
We also refuse to leave without the plan from section 8. An intervention that gets the network working again without leaving any trace of what was found guarantees us a second call within the year, which is excellent for us and bad for you.
And we do not remove the small switches we find simply because we did not put them there. They are counted, labelled and kept where their position allows, under the rule in section 10 — a device’s origin is not a technical criterion.
What we do fits in a day on an installation of twenty to forty sockets: the search for the three faults, the census, labelling both ends, the dated plan, and the cable box closed before we leave.
And one thing to do this week without us, for nothing: count the devices that answer on your network, count the wall sockets you believe you have, and look at the difference. That single number tells you whether there is anything to look for.
Frequently asked questions
Everything stopped at once and came back on its own. What was it?
Almost always a loop: a cable joining two ports of the same switch, or two switches joined twice. The confirming sign is visual and free — the lights all blink together, at the same rhythm, including on ports where nothing is working. It is the only fault that stops everything at the same time, with no progression.
Two machines side by side, one works and one does not. Why?
That is the signature of a second device handing out addresses — often an operator box reconnected to add ports, or an access point left in router mode. Compare the gateway shown on both machines: two different values settle it and give you the culprit’s address. The correction is a setting, not a purchase.
Should we remove the small switches nobody declared?
No, not on principle. What decides is position rather than origin: a box at the end of a chain feeding three workstations from one socket does useful work and should be adopted, labelled and put on the plan. The same box used to join two zones of the building is a central point of fragility, and that one gets replaced.
How do we find a loop with no equipment?
In five steps and with nothing bought. Start from the main switch, unplug the links to the other switches one by one leaving thirty seconds between each, watch the lights, and when the synchronised blinking stops the loop is in the branch you have just isolated. Repeat inside it. And write down what you unplug, in order.
The slowness comes and goes for no reason. Where do we start?
With the date, not the diagnosis. Note the exact time each occurrence, and above all what was happening in the premises at that moment. "It often happens in the morning" contains no answer; "it happens at ten past eleven" contains one. The three causes it most often reveals are a cable alongside a power supply, a cable crushed under a door, and a joiner in the middle of a cable.
How do we stop it happening again?
With a physical rule rather than an instruction: unused cables live in a closed box, not coiled behind a shelf. A prohibition asks somebody with an urgent problem not to solve it, which never happens. Add socket labelling, which changes what a person does in front of a socket: at a labelled one you look at the plan, at a bare one you try it.
Where we come in
The gap between devices that answer and outlets you think you have takes ten minutes to count. That gap is the boxes people put under desks.
- We look for the three faults in order, across a single day.
- We record what is plugged in under each desk and leave it with you in writing.
- We date the plan before leaving, even when the network is already working again.
If the gap is nil and nothing is slow, there is no loop to look for: call us the day something drops for no reason.
Read next
Switches and routers: count before comparing
A switch does not make a network faster. It decides how many devices fit, and how many of them can be powered over the cable.Firewalls and VPNs: what goes out matters more than what comes in
What arrives unrequested is already blocked by any router. The useful half is the other one, and it is the half nobody configures.March’s temporary rule: rereading a firewall six months later
A rule added for a week is never removed. How to reread a rule set in two hours, and how to take one out without breaking anything.
Let us talk about your project
A free audit, no commitment: we look at your online presence and tell you what is holding it back.