Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Can You Screw up a Network?

Cliff posted more than 8 years ago | from the learning-through-problem-solving dept.

Networking 87

aztektum asks: "Like a lot of Slashdot readers, I have setup my own home network. It isn't tricked out with all the fanciest hardware, but I do have a switch, BSD based firewall, I have configured e-mail (again on BSD), NFS and Samba, as well as remote access services like SSH and FTP. Now my line of work isn't networking or computer related at all. This is a personal hobby and a fairly new one for me (relatively speaking compared to others). I'm looking to learn more about managing problems with networks, but have no idea where to start. With such a small setup and only supporting two users (myself and a roommate) this isn't exactly enterprise level with enterprise level ups and downs. What are some ways I can screw up my network to troubleshoot problems and gain some insight? Also, what are some reference materials that you have found to be educational with relation to network administration?"

Sorry! There are no comments related to the filter you selected.

2 dhcp servers (1)

HotNeedleOfInquiry (598897) | more than 8 years ago | (#14013650)

on the same network is always fun.

Re:2 dhcp servers (0)

Anonymous Coward | more than 8 years ago | (#14013769)

It is, but on a home network it just isn't as fun to try to hunt the promiscuitous DHCP down versus trying to find it on a LAN of several large buildings (our main area is around 1 square Km, so that can be fun, and it happenned not long ago). And since you plugged it yourself, it's even easier, and you already know what'll happen... And there may not be enough networked equipment for that to cause problems (nor even enough DHCP use to even notice anything for many days).

Better Yet, (2, Funny)

Doc Squidly (720087) | more than 8 years ago | (#14013835)

Put all the user and computers in Active Directory in the Domian Controller OU.

Yes, I've seen it done.

Re:2 dhcp servers (1)

bamf (212) | more than 8 years ago | (#14021681)

Not if you have even half a brain.

Multiple dhcp servers is sensible.

Your roommate's computer (2, Funny)

PM4RK5 (265536) | more than 8 years ago | (#14013653)

Use a very small piece of scotch tape, and place it over only the right or left four copper traces on the end of an ethernet cable. Then plug the cable back into its jack.

When done right, it will take a VERY long time for your roommate to realize why the network isn't working quite right.

Re:Your roommate's computer (1)

pv2b (231846) | more than 8 years ago | (#14013725)

Another way to screw your server up would be to paste random one-liners certain people have in their signatures.

Re:Your roommate's computer (3, Funny)

lanswitch (705539) | more than 8 years ago | (#14014476)

This guy [] is an expert in network management. His site contains lots of useful tips.

Re:Your roommate's computer (0)

Anonymous Coward | more than 8 years ago | (#14028494)

When done right, it will take a VERY long time for your roommate to realize why the network isn't working quite right.

Not really. It would quickly become obvious that the problem was a bad patch cable. I have dozens of catalyst switches sitting in racks behind me right now. Sometimes a cable goes bad. It happens. It usually takes me less than five minutes of troubleshooting to figure out that is what the problem is.

Reference Materials (2, Funny)

pyrrhonist (701154) | more than 8 years ago | (#14013667)

Also, what are some reference materials that you have found to be educational with relation to network administration?

This [] should help with Windows networks.

Re:Reference Materials (1)

pv2b (231846) | more than 8 years ago | (#14013671)

Either I'm missing out on understanding some incredibly funny (or unfunny) joke, or you linked to the wrong book.

Re:Reference Materials (1)

roblaird (633935) | more than 8 years ago | (#14013693)

The joke being when working on Windows networks, you'll need a drink.

Re:Reference Materials (1)

pv2b (231846) | more than 8 years ago | (#14013714)

I considered that, but I don't think I'd mess around with mixing drinks if I had just spent 16 hours straight troubleshooting intermittent problems with roaming profiles. So I thought it was unlikely.

I'd probably just go for something strong and undiluted. (If it weren't for the fact that I don't drink alcohol.)

Re:Reference Materials (1)

mink (266117) | more than 8 years ago | (#14027677)

My common answer to any brain stumper is:
This problem can be fixed with a screwdriver, but I am all out of orange juice.

Re:Reference Materials (1)

pyrrhonist (701154) | more than 8 years ago | (#14013923)

It's for LAN parties.

Linksys router (1)

HotNeedleOfInquiry (598897) | more than 8 years ago | (#14013672)

I had one at work for awhile. It was set up to route a static IP to 10.10.1.XXX. If a network node with an IP address of 10.10.2.XXX tried to go out its gateway, it would lock up solid. Took a while to find that one. Course if you don't have a Linksys router, you can't play that game.

Re:Linksys router (1)

dtfinch (661405) | more than 8 years ago | (#14013750)

It'd help if you gave a model number and firmware version.

Re:Linksys router (1)

HotNeedleOfInquiry (598897) | more than 8 years ago | (#14013811)

BEFVPN41, all versions of firmware up to what was current a couple of months ago.

Troubleshoot? (1, Insightful)

Anonymous Coward | more than 8 years ago | (#14013681)

What are some ways I can screw up my network to troubleshoot problems and gain some insight?

Well, if you're the one who deliberately screwed it up in the first place you'd pretty much have to be an Alzheimer's victim for it to require "troubleshooting".

Real advice: Ask someone else to screw it up for you.

Re:Troubleshoot? (1)

OakDragon (885217) | more than 8 years ago | (#14030167)

Real advice: Ask someone else to screw it up for you.

And by posting on AskSlashdot, you probably have hundreds of thousands in the volunteer pool.

Clone some ethernet NICs (2, Informative)

HotNeedleOfInquiry (598897) | more than 8 years ago | (#14013684)

With the same MAC number and try to use them.

Give us access (2, Funny)

pv2b (231846) | more than 8 years ago | (#14013694)

Open sshd to permit access from the outside world, as well as root logins. Then post your root password and your IP address in a reply to this thread.

That is bound to screw *something* up sooner or later.

Screw up networks (3, Funny)

secolactico (519805) | more than 8 years ago | (#14013700)

Install windows 2000 + IIS 5, no service pack, on one machine.

Install solaris 2.6 or 2.7, default install (full + OEM). Don't patch anything. Don't close any service.

Ditch the firewall.

Wait 10 minutes.


But seriously, with a network that simple, the only problems you are likely to encouter are mis-configuration on the firewall and physical (wiring) trouble.

Re:Screw up networks (1)

aztektum (170569) | more than 8 years ago | (#14014491)

The purpose of the question (which I submitted a week ago, I had forgotten about it) wasn't to focus on my home network per se. I was trying to get discussion going, get links to network reference material, pick up pointers, etc... I guess I worded it too specifically. Oops!

Humor (3, Funny)

flood6 (852877) | more than 8 years ago | (#14013720)

What are some ways I can screw up my network

-You should have hosted a site on it and posted the link.

-Go buy some new Sony CDs

I couldn't decide which response was funnier, so you get them both.

Slashdot Effect (2, Funny)

_Splat (22170) | more than 8 years ago | (#14013721)

Put up a web server and link it from /. For added effect, get it linked from as well.


Re:Slashdot Effect (1)

tonsofpcs (687961) | more than 8 years ago | (#14032596)

Ok, how is this?
My site []

Not any different... (1)

toleraen (831634) | more than 8 years ago | (#14013757)

from learning anything else. How do you learn to use new things in general? Apply the same methods to networking. Try and do stuff. Setup static IPs, set up static routes, if it's a wireless network at all, play with different channels, security types, etc. If you can set up a BSD firewall (properly), you probably don't need to learn much more with a 2 person network besides how to use ethereal properly. If you want to learn actual networking, ebaying for a couple of routers/switches and making your own little lab is a real good way to go. Get a few quad port network cards and setup 'em up on different vlans to play with routing.

Also, what are some reference materials that you have found to be educational with relation to network administration?"

CiscoPress books if you want to learn too much. I've got about 10 of 'em...they helped me pass the cisco certs, and I learned a load about everything with networks. However, as soon as I graduated I got into something completely different than networking, so I don't know how well they'll actually help ya with a real network. They are nicely done though.

Be wary of Vacuums! (1)

bergeron76 (176351) | more than 8 years ago | (#14013770)

There's an old addage in the IT industry about a server that crashed every night at 7pm. It crashed because the janitor unplugged the server and plugged in his vacuum.

That adage holds true to this day. Particularly if you have a roommate (or in my case a daughter), that happens to plug a vacuum into an overloaded electrical circuit. A breaker will trip, your servers/network will go down, and you'll ultimately learn the importance of UPS'es.

Unless of course, you're lucky enough to be off-grid.

In which case, you probably won't have a roommate, or a vacuum.

Re:Be wary of Vacuums! (1)

bitingduck (810730) | more than 8 years ago | (#14013990)

There's an old addage in the IT industry about a server that crashed every night at 7pm. It crashed because the janitor unplugged the server and plugged in his vacuum.

Reminds me of a problem I had with NT for a while. I would come in to work in the morning and a large fraction of the time see the blue screen of death. Eventually I figure out that it happened when Norton Anti-Virus was starting an autoscan. Every time the autoscan started, up came the blue screen. If I ran it manually it behaved fine.

Re:Be wary of Vacuums! (1)

dtfinch (661405) | more than 8 years ago | (#14014129)

I think this is a variant of this [] story where every friday night, a cleaning lady would unplug the life support to a particular hospital bed to plug in a floor polisher, killing a patient every friday that the bed was occupied. The article mentions several variants, including one where a system goes down the same time each day for several minutes.

Re:Be wary of Vacuums! (1)

lilmouse (310335) | more than 8 years ago | (#14024339)


My little brother blew a UPS by plugging a vacuum cleaning into it.


Re:Be wary of Vacuums! (1)

Webmoth (75878) | more than 8 years ago | (#14047384)

That's nothing, I had a customer plug a UPS into a power strip, then plug the power strip into the UPS and then wonder why the system went down after a few minutes.

Easy way (1)

scheme (19778) | more than 8 years ago | (#14013788)

Take a electrical cord and cut it in half. Take an ethernet cord and do the same. Connect the live and ground wires from the electrical cord to any of the wires in the ethernet cord. Plug the ethernet cord into your switch and then plug the electrical cord into your router. You'll quickly get a screwed up network.

P.S. If you actually do this, don't blame me for any of the consequences.

Re:Easy way (2, Funny)

Daxster (854610) | more than 8 years ago | (#14014316) []

Try this at home, really! One day the local salesmen reps of a major networking company (that rhymes with Nabisco) came by to talk to my boss. Since he was on the phone they came in and talked to me so I showed them the etherkiller. I think it scared the shit out of them. I also got yelled at by my boss since he thinks we might not ever get warranty support again.

Re:Easy way (1)

jrockway (229604) | more than 8 years ago | (#14014473)

I've done this. It didn't kill any NIC that I connected it to, including:

* A PIX.
* A no-name switch.
* An Intel on-board NIC.
* An Apple iMac (the original) NIC.

I wired the cable such that every other pin was hot, and the rest were ground. You'd think it would at least cause some trouble, but it didn't.

Re:etherkiller myths (2, Interesting)

anticypher (48312) | more than 8 years ago | (#14015307)

Etherkillers shouldn't cause any immediate problems for anything up to 240V, you really need 480V or higher to start frying things. Electrical safety laws require isolation of up to 500VAC for a period of 48 hours, hence the isolation block on all NICs. The point where a card will start to smoke is usually higher than the breakdown voltage on the insulation of the wiring, cat5 or cat6 will break down at 350-600VAC, so its difficult to get enough voltage directly into a NIC to cause anything spectacular to happen. That I'm conversant in such matters is a good indication not to ever get me in a bad mood.

I once worked in a building that was on three phase power, where the outlets in each of the two wings off the main building were on different phases. The main wiring closet was in the main building, and the end points were plugged into PCs and hubs on a different phase. So there was 138VAC between the PCs and the main ethernet switches. NICs in PCs would last a few weeks before quietly failing, ports in switches lasted about two months. Every 3 months or so the company would just have to replace an entire 24 port blade. It was cheaper for them to keep their smartnet contracts up to date than to insist on an electrician fixing the problem since their lease was almost finished. The company that followed them into the building nearly burned it down the first week because of the improper electrical wiring, and much hilarity ensued.

the AC

You should have tried harder to destroy the PIX

Re:etherkiller myths (1)

Bishop (4500) | more than 8 years ago | (#14015428)

There was a lot more wrong there then three phase power. My server room has three phase power. Most servers have redundant power supplies and are plugged into two different phases. I don't have any failing nics. It sounds like there was some big grounding faults.

The next time you run into an issue like this get an isolating transformer, two switches with fiber ports, and a short length of fiber. Problem solved. People like to think fiber is expensive. It isn't.

More shops should use fiber. Once in place fiber does not have to be upgraded. The same multimode fiber used for old 56kbit/s links can be used for 10Gbit/s. You may need a little pigtail to convert from the old bayonet connectors to the new MTRJ but that is not an issue. The only downside is that it is a little harder to replace the fiber ends compared to an RJ45 connector. But any shop large enough to use fiber can afford the kit to replace the connectors, or hire one of the many contractors to make an onsite visit.

Re:etherkiller myths (1)

anticypher (48312) | more than 8 years ago | (#14015972)

There was a lot more wrong there then three phase power

Oh, yes. Whatever was going on there indicated a serious problem. Each wing of the building was on a single phase of the 3-phase building supply. Each wing was isolated by a little walkway between the buildings, so in theory you couldn't have a secretary touching the chassis of a PC in one building at the same time as one in another building. They never counted on a bunch of shielded twisted pair cables being pulled to complete the circuit. The only NICs to burn out were in the two wings, the main building never had the problem.

The ethernet cables should have been isolated at both ends, but obviously weren't. Even if one end had a problem, the other end should not have cared. We suspected that the ground in the main building was actually hot. The ground wires on the sockets went a couple centimetres into the conduit and no further, just enough to fool a casual inspection. The ethernet connectors had metal frames with a wire that went to a foil shield around the pairs, which probably was the closest thing to ground in the building.

I wasn't on that site in any kind of technical role. There was one tech who swapped the NICs every time they stopped working, and the people who installed the network just came by every couple months when all the ethernet ports were burned out and swapped a card. Fibre, or any kind of an upgrade or change were out of the question.

I learned more about intransigent bureaucracy at that job than any other place in my long career. That building burned partly down because of the electrical problem soon after we left.

the AC

stupid ideas (1)

BenTheDewpendent (180527) | more than 8 years ago | (#14013814)

get a few extra clients. lock permissions down with a GPO at the machine level and try to install software and expect it to work properly.

mess your local DNS up and install some software like a proxy.

install a windows box and dont patch up and put it in the DMZ and then once its good an infected you will have lots of traffic to track down

fact of the matter is. If you know what your doing your network isn't going to be that bad. I talk to people all day at the enterprise level and see issues that can be nobody but the admin or network admins fault but have no clue as to what they are doing.

you could always hire a consultant.

Don't break it if it's not broken.

Google (1)

pYrOmiLkMaN (827068) | more than 8 years ago | (#14013829)

How about google, I hear they have great references and information.

just a few thoughts (2, Interesting)

Hardwyred (71704) | more than 8 years ago | (#14013836)

Take a hub and plug it into your switch. You have to use a hub for this to work, or if you have a really cheesy switch I guess it could work without the hub. Now take an ethernet cable and plug both ends into the hub. Viola, instant layer 2 loop.
Run an ethernet cable (yours perhaps) next to a space heater/box fan/large electric motor of your choice. Periodicaly turn that motor on and off. Instant link loss due to a spike on the line. WARNING, this one could jack up your switch/computer so be sensible.
If you are really green, give your roommate and your computer the same IP.
Take a short ethernet cable and untwist it (take it out of its shielding and untwist the wires). Put it back together in various ways and see how fast/slow your download rates become.

Re:just a few thoughts (1)

Andy Dodd (701) | more than 8 years ago | (#14015836)

"Run an ethernet cable (yours perhaps) next to a space heater/box fan/large electric motor of your choice. Periodicaly turn that motor on and off. Instant link loss due to a spike on the line."

While this might BRIEFLY cause the NIC's link detection to fail (not likely), it will have little to no effect on data transfer through the line.

10/100/1000BaseT uses differential signaling for a reason.

Re:just a few thoughts (1)

Hardwyred (71704) | more than 8 years ago | (#14018321)

actually, all of these are from my experience here at home. That one in particular will cause my intel pro 100 nic running 100full to drop link for about half to 1 second. If you are moving any data, windows freaks out. Fun to troubleshoot.

Re:just a few thoughts (1)

tzanger (1575) | more than 8 years ago | (#14016458)

Run an ethernet cable (yours perhaps) next to a space heater/box fan/large electric motor of your choice. Periodicaly turn that motor on and off. Instant link loss due to a spike on the line. WARNING, this one could jack up your switch/computer so be sensible.

You need a really poor equipment for that to be effective. Ethernet signals are differentially signalled, and the PHY should be subtracting the common mode noise to improve reliability. I deal with big electric motors all the time (50-500HP) and they can cause some really nasty dips/spikes on your power and induce all kinds of noise, especially if connected to a VFD. But have I ever had link loss due to this? Never. Shitty performance at times (again only with a VFD, ATL starting shouldn't ever cause any kind of noticeable network loss beyond a retransmit) but never link loss.

I can screw it up! (1)

RapterOfParadox (317576) | more than 8 years ago | (#14013849)

Let me work on it for 10 minutes. It'll be screwed up then. (As I chuck my router and DSL modem in the middle of the road and grab my car keys.) Yeah, I've been working on getting my home network working for the past two hours! I need a beer.

Re:I can screw it up! (1)

RapterOfParadox (317576) | more than 8 years ago | (#14013867)

Ok, so I go to /. and post a message. What do you know, 30 seconds later my home network starts working again. Thanks /.!

Re:I can screw it up! (1)

anticypher (48312) | more than 8 years ago | (#14015350)

30 seconds later my home network starts working again

Thanks /.

You are welcome. The bill is in the mail.

the AC

Easy (0)

Anonymous Coward | more than 8 years ago | (#14013858)

"What are some ways I can screw up my network to troubleshoot problems and gain some insight?"

1. Create a website
2. Reference said website on front page Slashdot article
3. Troubleshoot

Personal Experience (0)

Anonymous Coward | more than 8 years ago | (#14013915)

If you want to screw a perfectly functioning network have your yuppie Technical Director employ a "Network Administrator" who's experience was stated as "Unix expert" (Read: his mac was plugged into a solaris network by someone else.) Immediately promote him to Manager (so they can talk fashion) and then he'll "re-design" the network (to impress everyone with the efficiency and synergy) and sure as shit really does stink outside the RDF the thing will be screwed!

How to screw up your network... (1)

mysidia (191772) | more than 8 years ago | (#14013972)

Build and use one of these guys [] . That should do the trick.

Re:How to screw up your network... (0)

Anonymous Coward | more than 8 years ago | (#14014017)

(P.S. no, don't really; the consequences of attempting to actually make/use an etherkiller could be dire; breaking stuff, and worse)

Just wait, it'll screw itself up. (4, Informative)

dtfinch (661405) | more than 8 years ago | (#14013976)

Eventually hardware fails, always. Notice the signs that something is about to fail so that you can replace it when in a timely manner and with little downtime, or none in some cases. If you know you'll have to take a server down, figure out how to replace it without data loss or downtime. With an MSDFS root, which Samba does well, phasing out a dying or obsolete server is relatively easy. Otherwise, you'll just have to fiddle with the DNS and maybe give the new server the same IP. You can also look into clustering, but the cost and complexity can be prohibitive for smaller companies, and possibly for home experimentation.

Always keep good backups. If someone comes to you and says they deleted an important file last week, be able to get it back without a full restore. Also, be able to do a full restore of a server, and know it'll work. If the server catches fire, have a plan to replace it within the hour.

Make some ethernet cables. Buy some raw cable, and end plugs, and put them together the right way. The ordering is very important. Not only must each end match, but the color coded twisted wire pairs must be arranged in a certain, non-obvious way or else you'll experience severe noise and crosstalk problems.

Mix older (bargain) gigabit hardware, different brands. Some card-switch or switch-switch combinations have slightly hard to diagnose problems. If you ping, you'll have zero packet loss. But if you transfer a file, sometimes speed will drop down to 20kb/s or so, and it'll only happen in one direction. I've seen buggy drivers cause this too. When packets are sent in rapid sequence, every other packet is lost, and the send window shrinks until it's sending only one packet at a time, and waiting for an ack before sending the next.

Get a really, really long ethernet cable and use it to plug a windows pc to a switch. Let it autodetect the speed. If it's long enough, it'll still detect 100mbit or 1 gigabit, and then fail to connect. You'll have to force it to 10mbit, or get better cabling, or use a switch, hub, or some other repeater to break it into two short connections.

Again, get a really long ethernet cable, and put a sharp kink in it. You do this by making a small loop, then trying to force it straight by pulling instead of carefully undoing the loop. Line quality will suffer dearly, even though you may still be able to connect. The best fix is often to buy a new cable. Any sort of sharp bend will cause problems.

Have fun with Windows name resolution. Windows PC's seem to be able to find each other pretty well just using WINS or broadcasts, but only after checking DNS first, which goes out to your ISP's servers if you don't have your own DNS server(s) set up. These requests tend to fail almost immediately without delay, so the issue can go unnoticed. This allows your network to be hacked a bit more easily from the outside, and also allows internet problems to translate into delays in local name resolution. This sort of problem is easy to create and easy to fix, and plagues some small businesses that lack experienced or knowledgeable IT staff.

Re:Just wait, it'll screw itself up. (1)

GigsVT (208848) | more than 8 years ago | (#14015649)

Linux used to do similar DNS shenanigans.

Used to be if you did "ssh user@bob" where bob was a local machine in your local DNS server, Linux would do "AAAA bob." (notice the dot on the end) which would get sent to the root DNS servers asking for a TLD named bob. Then it would do "A bob.", another root query that would always fail. Finally it would add your search domain and do "AAAA", which would also fail because no one runs IPv6. Then it would finally do the right thing and do "A", which your name server can resolve.

I didn't notice this either until our internet connection went down and internal DNS resultion started taking 20 seconds to succeed.

They've changed it to be slightly less braindead now, but IIRC it still does at least one query that end up at the root name servers, for each internal name resolution request.

Re:Just wait, it'll screw itself up. (1)

00110011 (917752) | more than 8 years ago | (#14017285)

Isn't that caused by the lookup order setting in /etc/host.conf ?

Re:Just wait, it'll screw itself up. (1)

GigsVT (208848) | more than 8 years ago | (#14021111)

nah, in host.conf, that's all under "bind".. This was all behavior of the glibc bind resolver. Like I said it's slightly less braindead now I think.

Re:Just wait, it'll screw itself up. (0)

Anonymous Coward | more than 8 years ago | (#14018823)

How long do I have to wait to be hacked if my machines are sending local name resolution requests to my ISP's DNS servers and how long of a delay does it actually create for local name resolution? Also in regards to local name resolution what role does ARP play? Just curious... from an inexperienced IT staff member.

Re:Just wait, it'll screw itself up. (1)

dtfinch (661405) | more than 8 years ago | (#14019073)

You'll probably never be hacked in that way. It's just a possibility. About 5 seconds, until the DNS lookup tries out. Now that I've looked it up, an exception to that is NetBIOS which tries WINS and broadcast first, so Windows file sharing doesn't have have the same delay. An exception to that exception is Windows XP which by default tries to connect to a UNC path via WebDAV (http) first, and falls back to normal file sharing when that fails.

ARP matches IP addresses (not names) to MAC addresses.

Too bad AC's don't get reply notifications.

build a DNS server (1)

caffeinex36 (608768) | more than 8 years ago | (#14014091)

and have your cat jump on the keyboard... DNS is fun to learn.....but to the people who know enough to be dangerous, it can bring a network down like kryptonite and superman. -Rob

EASY!!! (1)

netkid91 (915818) | more than 8 years ago | (#14014185)

sudo rm -rf/*

The problem with managing problems... (3, Informative)

mysidia (191772) | more than 8 years ago | (#14014334)

Is you need more nodes and more complexity -- your network is too simple, so there is fairly little that can go wrong compared to real networks.

Try reinstalling and switching your systems' OSes, especially the BSD firewall's -- provided your hardware and wiring are good, the OS is the most likely thing to mess up anyways.

I.E. Are you sure BSD is the best OS to use for that firewall? Maybe trying to run the fireewall of of VMS or something else could have interesting results.

Increase the demand on your network is the main thing; if you don't get to have problems, you can always try to tune for performance, stability, security, by switching things around and changing configurations --- try to find as many configurations that work as possible and figure out what works best.

Figure out the way to add as many units as possible and to make the network arrangement as complex and spread out as possible --- the more complexity, the more devices, nodes, etc, involved -- the more likely _something_ will go wrong; find a way to get 3 or 4 windows machines in there with serious demands on them, and something's almost certain to break.

WiFi (1)

TubeSteak (669689) | more than 8 years ago | (#14014413)

Plug in a few Wireless access points & set them all to the same SSiD & channel. Now start transferring large files between the two waps while large numbers of random people are using it. Will bring network to its knees.

Cable tricks and other tricks (3, Interesting)

Kymermosst (33885) | more than 8 years ago | (#14014428)

Take an ethernet cable and flex it back and forth (crease-style). Works best with solid conductor cable (I hardly ever see braided anyway). Chances are you'll seriously thin out or break a wire, and if it's one of the right four, you'll have issues.

Two DHCP servers on the same LAN is fun.

Plug a crossover cable between two ports on your switch. See what happens (most should disable both ports, but some freak out).

Crimp your own ethernet cables. That leads to all kinds of fun the first few times you try it.

Meh.. I'm not good at breaking stuff, that's all I can think of.

Re:Cable tricks and other tricks (2, Interesting)

anticypher (48312) | more than 8 years ago | (#14015130)

Crimp your own ethernet cables

I have a box of subtly bad ethernet cables from a reputable commercial source (its now marked "special cables for special lusers"), nice molded strain reliefs with tab protectors.

Normal straight through ethernet cables are wired like this:

These cables are wired similar to:

There are also some crossovers with similar polarity problems.

With just one of the directions having the wrong polarity, depending on which brands of NICs on each end, there are all kinds of bizarre problems. Sometimes things work (cisco to intel, but not with auto-negotiate), sometimes you get errors (realtek 81x9), sometimes link status doesn't come up in one direction but is fine in the other direction, sometimes nothing at all works.

I hand these out to people I don't like, those who beg cables off me for "just a few days".

the AC

Try building a firewall script... by hand... (3, Interesting)

WoTG (610710) | more than 8 years ago | (#14014564)

OK, maybe this is flamebait... maybe not.

The first time I tried to setup a really locked down network (i.e. better than a NAT by allowing specific outgoing traffic only) I screwed up royally. Actually, I still would have significant difficulties without a good GUI.

For a crash course in the difference between UDP and TCP and how IP ports work and what NATs do, IMHO, there's nothing better than actually trying to create a "secure" firewall that still lets you do the stuff you normally expect. E.g. email, web, P2P (take your pick), streaming media, DNS resolution (which is way more complex than I would have imagined).

setup a honeynet and queueing (3, Interesting)

pr0m (707575) | more than 8 years ago | (#14014626)

setup a honeynet on a network that connects to the internet through the same router as your private lan. i found this challenging because i had to think of the worse case scenarios to mitigate with the firewall on the router. be sure to implement a working queue with altq so that your private network gets a higher priority than the honeynet on outbound traffic. it's also interesting because you learn about how "hackers", "crackers", and "script kiddies" launch attacks and what they do with the machines that they take over.

guest account (4, Interesting)

dimss (457848) | more than 8 years ago | (#14014657)

Create SSH-accessible "guest" account on your router or server. Set password to "guest". They will come to your network within 24 hours. Make sure they can't do much with this account! Most probably they will try to download local exploits and other nasty tools.

I have created "guest" account on my Linksys router three days ago. Someone from Romania discovered this account next morning. They downloaded some binary files and tried to run them. Idiots! Binaries were for i386 but Linksys router is MIPS :)

Re:guest account (1)

Leffe (686621) | more than 8 years ago | (#14015459)

test:test is also a good account:password combination. Most bots will try it.

UPS (2, Funny)

Alef (605149) | more than 8 years ago | (#14014827)

[...] with enterprise level ups and downs.

Did anyone else read that as Uninterruptible Power Supply?

I actually pondered for a brief second on what a "down" was...

How do I screw up a network? (5, Informative)

anticypher (48312) | more than 8 years ago | (#14014901)

By touching it. There's always an assistant named Murphy looking over my shoulder, but she usually waits until I'm in the shower or leaving on vacation before "helping".

Your question is really "How do I introduce layer 1 and 2 problems into my home LAN, since all layer 3 routing is limited to a NAT box with a single default route?". The lower layers are a good place to start, since half of all your problems come from there, save the routing problems for a future ask/. question.

Others have already pointed out the joys of having dueling DHCP servers, subtly mis-configured DNS servers, overlength cables and the like. Keep an eye out for others throwing out bad ethernet cables with broken catch-tabs, frayed insulation, sharp kinks or intermittent wiring, and put them into critical places in your network. They may not fail right away, but will wait until you host a lan party at your place or you have a few hours to get a report done. Her name is Murphy, she's a bitch and she'll gladly pay you a visit when you least want her around.

Start to learn what kind of traffic is on your local network. Get ethereal, snort and ntop running, and see what the packets look like. Chances are you'll find some things that look suspicious, you'll learn a lot by figuring out how DHCP handshakes work, how often ARPs happen, what other protocols are on your net besides IP. Since you are running a BSD, you can pretty safely put the box on the outside of the firewall (it probably is the firewall) and watch all the constant crap scanning the internet. That's a great way to learn how to tune firewall rules by hand, and you will break things along the way.

To really start to learn how layer 2 networking almost works, grab some old cisco kit off of eBay. I've seen 2900 switches for US$20. Plug something slightly pro into your network, start simple, just get a cheap used cisco/hp/3com switch off eBay that can do 802.1q vlans, spanning-tree, and snmp. Your BSD ethernet card can be configured to do .1q, so there is a lot of learning there by creating multiple separate vlans, one for each machine. A single router and switch with 802.1q vlans can make some pretty complicated networking topologies without massive amounts of wiring. Then you can break your network by plugging a crossover cable into two ports and watching spanning tree open up one of them. Bonus points if you create a topology where by creating a spanning tree loop, your main gateway or server port is the one that goes into blocking mode (you need a minimum of two switches to do that).

To break things in subtle and non-obvious ways, try changing your address ranges from the usual to something unusual like, doing the netmask/subnet/broadcast calculations in your head for practice. Then misconfigure the netmasks on each device, notice how one machine can ping another, but not the other way around. Try building multiple separate segments rather than multiple subnets on a single wire, this will force traffic to use your router, and really show netmask problems more clearly.

To really break things, instead of using reserved RFC1918 addresses behind your NAT box, use a public network range like Sure, it will break one major site, but you shouldn't be wasting your time there :-)

Since you already have a BSD running, do you leave it on 24/24? If so, its time to start loading up the real tools like cacti [] , nagios [] , and smokeping [] . It helps if you have an SNMP capable switch on your network, but configuring your own SNMP [] can be quite a learning experience as well. With graphs showing what is happening on your net and the internet over time, you will start to see the cycles of congestion every evening and maintenance times every sunday at wee hours. The most frustrating problems in networking aren't the ones where something is immediately obviously broken, its the long term ones which require constant monitoring to see.

To simulate the life of a typical network admin, take only one shower per week. Calculate the LD50 of caffeine for your body mass and consume that per day. Set your alarm clock for an hour after you go to bed, repeat all night long. Never show up to work before noon, but never go home before 3AM. If this doesn't steer you away from learning more about networking, you are on the path to he^H^Ha career in net adminning, you poor soul. All these superfluous bits of wisdom are also part of the networking world, even if not obvious to a beginner.

the AC

Combine your ssh remote login with poor passwords (4, Informative)

jonadab (583620) | more than 8 years ago | (#14015038)

Your ssh remote login *will* get noticed by port scanners, and both dictionary and brute force attacks will be made against it, particularly if it is running on the standard port (22 IIRC). You can help the attackers to compromise your system if any of the passwords of any of the users who can log in in this fashion -- especially passwords on accounts the attackers can guess must exist, such as your own preferred username or an account that is usually present on most systems, and extra-especially the root account -- are attackable via dictionary or brute force. For instance, if one of these users has a password that is only ten characters long and contains only letters, that is a potential point of entry onto your network. On the other hand, if you want to *prevent* them from getting in, use passwords that are longer, contain non-alphabetic characters, and not based on dictionary words (but pronounceable so that you can easily remember them), e.g., passwords like Frolliga_Bruckenovich or grazzivian-CHOXXI or SpoyBan8CritNox or cetera. (I don't mean these specific examples, but hopefully you get the idea -- passwords that are hard to brute-force don't have to be hard to remember. The more paranoid you are, the more syllables you add, and remember that a certain amount of paranoia is part of any sysadmin's job description.)

Another thing you could do to allow attackers to gain access is to completely ignore security bulletins and never install updates.

Depends... (1)

afabbro (33948) | more than 8 years ago | (#14015290)

If you're serious, a good place to start is a CCNA cert. I'm not big on certs, but the CCNA is generally well-regarded. You can get a book with a simulator CD and that's about all you'll need.

If you want to get beyond that (CCNP or CCIE), you need some real network gear (i.e., real routers and switches). I'm not saying that Cisco certs are the end-all of network knowledge, but if your goal is to really learn about networks, then they're good guideposts.

Another fine thing to digest is Stevens' classic book TCP/IP Illustrated, Volume 1 [] .

Easiest Way To Screw It Up. (1)

BishonenAngstMagnet (797469) | more than 8 years ago | (#14015326)

Switch your entire topology to good ol' 802.5. Let the good times roll.

Start from the bottom, and work your way up. (4, Informative)

amper (33785) | more than 8 years ago | (#14015373)

Wow. Taking a brief look at the responses here, I can't believe how complicated most of the answers are.

You want to know what makes a network tick? Start from the bottom and work your way up. That is, follow the OSI Protocol Stack Model, and start from Layer 1, the Physical Media, and learn why it is that Ethernet (or your choice of PHY) works the way it does. Then move up to Layer 2, the Data Link Layer, which in the case of Ethernet would be CSMA/CD, then move up to Layer 3, the Network Layer, which in most cases these days is TCP/IP (though TCP/IP really sort of covers Layer 4, the Transport Layer, as well).

Allow me to suggest the many excellent books by O'Reilly that will tell you everything you need to know.

Do not use the Cisco or Microsoft books. While most of the information there will be correct, some of it will be specific to Cisco and Microsoft's proprietary implementations. I feel it is always best to learn the generic, standardized protocols before branching out into proprietary protocols.

Check out these books from your library, or buy them. Used or new doesn't really matter all that much, as the basic protocols have not changed much in the past 15 years or so.

1. O'Reilly - Ethernet: The Definitive Guide
2. O'Reilly - Internet Core Protocols: The Definitive Guide
3. O'Reilly - TCP/IP Network Administration
4. O'Reilly - Building Internet Firewalls

That will get you started. Then, you might want to know something about other types of networks:

5. O'Reilly - 802.11 Wireless Networks: The Definitive Guide
6. O'Reilly - T1: A Survival Guide

With those six books, you'll have a solid grounding in how networks network, and how internetworks, internetwork. Once you have that, you'll have a pretty good idea of how to screw up a network. You'll also have a pretty good idea of what more advanced topics you'd like to know more about.

One old book that is out of print and difficult to find that I highly recommend is Inside AppleTalk, 2nd. Edition, from Addison-Wesley. It's the definitive book for AppleTalk, and you might want to know about AppleTalk, even though it is falling out of favor.

Re:Start from the bottom, and work your way up. (1)

pclminion (145572) | more than 8 years ago | (#14029114)

Wow. Taking a brief look at the responses here, I can't believe how complicated most of the answers are. [...] With those six books, you'll have a solid grounding in how networks network, and how internetworks, internetwork.

Your response to overly complicated answers is to suggest that he read six books? Wow, I'd hate to have to deal with something that you actually find "complicated!"

Re:Start from the bottom, and work your way up. (1)

andy_shepard (315539) | more than 8 years ago | (#14037067)

What are you, illiterate or something?

Re:Start from the bottom, and work your way up. (1)

WuphonsReach (684551) | more than 8 years ago | (#14038417)

Books like that are a lifetime investment. I can reach behind my shoulder here in my office and pull down 3 books on basic LAN topology (written in the early 90s), a pair of books specifically dealing with TCP/IP and a pair of books that deal with linking LANs together. Oh, and 2 old study guides for the MCSE tests dealing with TCP/IP and Networking Essentials. And that doesn't even get into the half a dozen books on firewalls, security, and locking down a network/server.

And even though those books are 5-10+ years old, a lot of what is in them still applies to modern day networks.

Heck, my personal rule of thumb for anyone in the tech field. Read at least one new book per quarter. Find an area that you don't know enough about or need to brush up on and get a book that covers that subject.

The big advantage of dead-tree print is that you can mark your place, measure your progress in covering the material, and you don't have to be chained to the screen to read it.

Different MTU (1)

isj (453011) | more than 8 years ago | (#14016205)

Configure different MTUs on the machines.
It is quite difficult to troubleshot because simple pings, telnet, etc. works just fine. Any larger transfer that uses full-size ethernet packets will not work. The symptoms are.. interesting and erratic. "ls" on NFS drives works unless there is too many files. telnet usually works until something sends more than 1500 bytes in one go. ping works fine. arp works fine. nslookup works fine.

Another way: play packet WTF (2, Insightful)

dubl-u (51156) | more than 8 years ago | (#14016314)

Another great way to learn about your network is to install a packet sniffer like Ethereal [] . Capture some packets, pick a random one, and try to figure out what the hell it's for.

For the advanced version of the game, do something specific (bring a DHCP machine up; do an FTP transfer; surf a web site) and write down what you think goes on on the network. Then capture the packets and see how close you can get.

By learning what a network looks like when it's working normally, you'll have a much better chance of figuring out problems when they happen.

Create New instead of Edit (1)

karearea (234997) | more than 8 years ago | (#14017112)

Many years ago, I took a job running the polytech network after being there as a student for 1 1/2 years.

The main server was Netware 3.12 (I assume there are some people who remember that). Anyway during my first week, I had to go in to make a small change to the server's autoexec file (autoexec.cnf?). To cut what could be a long story short, I created a new file rather than edited the current one.

Needless to say things didn't quite work after that. It took me about 1/2 an hour to make enough floppies for the remote boot DOS/Windows 3.1 workstations and then another couple of hours to work out what the hell I did and then fix it.

I think one of the biggest causes of issues in networks is from bad config changes - corrupt/missing files, typos ( vs

So ... if you want to stuff things and then fix them - destroy config files and learn how to recreate them.

Re:Create New instead of Edit (0)

Anonymous Coward | more than 8 years ago | (#14021119)

Just in case anyone really cares its autoexec.ncf

Answering a different question... (1)

jbert (5149) | more than 8 years ago | (#14019206)

I don't think you can really do what you describe. This sort of thing is all about problem solving, the detective work you do to find the cause (and then solution) when you are having some problem. If you know the answer to begin with, you can't go through the process.

If your ultimate goal is to learn more about networking, then I'd say you can learn a lot by running a network analyser (ethereal is a very good gui tool which understand a lot of protocols. It can also read tcpdump files, which is handy).

Look at the traffic on your network. Do you understand all of it (if not, go and read up)? Now reboot one of your boxes. Can you pick out the boot sequence traffic? Did any of it surprise you? Read some more.

Ideally, get a heterogenous network going. Stick a windows box on there. Repeat the above questions.

Set up some local file sharing protocols (e.g., samba, nfs, webdav) and shares. Watch the traffic. You'll see authorisation protocols in there now too.

Until something goes wrong, I'd say this is the best way to learn. There is a lot of detail in these protocols. And additionally, the best way to quickly fix a network when it is broken is to know what it looks like when it is running normally, which is something you have to do beforehand.

Last top tips:

- network problems are much easier to diagnose with 3 boxes. Given the problem "A and B can't talk X (or are very slow talking X)" there is a lot of trouble to shoot. Reducing that to "A and B can't talk X, but A and C can. Hmmm...and B and C can't" narrows the field quite a lot.

- always check the basics first. Things get more complex (and take longer to analyse) as you head up the network stack, so check the lowest layers first. Which are the lowest layers? Go and read a book on TCP/IP and always remember that the lowest layer is physical, so always check its plugged in...

Oh, where to begin...!? (1)

martinultima (832468) | more than 8 years ago | (#14021066)

OK, here's a couple ideas:
  1. Delete /etc/inittab. First remove all forms of removable media (eg, floppy, CD-ROM) from the system. Glue the case shut. In fact, weld it shut for best results. Then, as root, run: rm /etc/inittab. Works every time.

  2. The "Old Machine" Problem. Move everything to a really really old box. For best results no more than 32MB RAM. Have the thing running the absolute latest available software, preferrably optimized for the absolute latest available hardware, and then pull up all the big-ass programs – Firefox,

  3. 101 Uses for Jolt Cola. Dump some of that stuff on your router and it's guaranteed to screw the thing up big-time. Don't waste too much though, that stuff's expensive.

Enjoy! And don't sue me if you actually had the nerve to take my advice!

Staple your cables (2, Interesting)

Phreakiture (547094) | more than 8 years ago | (#14021829)

Just as simple as that.... In stapling up your cables to walls, joists, studs or whatever, drive a staple through the cable.

I did that at least two times while setting up my home network. The first one shorted out a pair, and the cable was fine as soon as I removed the staple. The second one apparently severed a conductor, but then bridged it. That cable worked just fine until I removed the staple.

Needless to say, I have since acquired a cable-safe staple gun. It has a wire guide on its tip (you straddle the cable with the guide and it keeps the cable out of the way of the outcoming staple) and it uses rounded staples.

Here's a few ideas (1)

anewsome (58) | more than 8 years ago | (#14027199)

* Use the same static IP on a couple of devices

* Use the wrong netmask on your network on a few random devices (really hard to find if really done by accident)

* Create a bad static route at your firewall

Or if you really want to make a mess of things... (1)

martinultima (832468) | more than 8 years ago | (#14031259)

While all these other guys seem to have good ideas for how to make a real mess of things, if you really want to blow stuff up may I suggest that you just load your equipment up with C4. Never failed once. Although you might want to run away really really fast and preferrably change your name & move to another state.

Start a benchmarking service game giveaway. (1)

Roskolnikov (68772) | more than 8 years ago | (#14031440)

like the other posters, open up a web service; make the front end really neat, put a speedometer gauge on it.

post a java applet that measures bandwidth to your *clients* and list below the speedometer (which shows aggregate bandwidth used)
the highest sustained throughput for say the top 30 users.

then post it to slashdot and boing boing as a contest, with the top rated clients winning a nintendo revolution, xbox 360 and playstation3 dream system.

after the above (a hard days work) go to sleep and when you wake up you'll find a brand new world awaits.

Real problems I've run into (1)

Webmoth (75878) | more than 8 years ago | (#14047098)

One customer had a thinnet coax network. Connections were going bad, and the network was frequently down. We advised the customer to upgrade the network to CAT5 ethernet (this was in 2001 so the cost was reasonable). Customer didn't want to spend any money on the network until it was working properly.

Another customer had installed CAT5 cabling. No jacks; he terminated it with plugs. NICs would link up, you could ping anything all day long, but as soon as you tried to do anything that put a load on the network it would all puke out. I inspected the cabling and discovered that while each end was pinned out the same (as it should be), they were not paired properly. This allowed connectivity, but it also allowed signal loss and interference. I reterminated them properly, and everything was fine.

We had a network interface with a Realtek chipset in our mail server. It would lock up randomly, requiring a power cycle of the server. Eventually I discovered I could consistently lock it up by sending out a message with particular (but not malicious) content. Immediately replaced the NIC. (I know of software vendors who refuse to support an installation where a Realtek NIC is present.)

Install anything made by TrendNet.

Install a router/firewall with a DHCP server that doesn't retain its lease database thru reboots and power cycles.

Run your network cable where you can run over it with your chair, underneath a chair mat with those pointy things, or smash it in a door jamb.

Attempt to connect an early-90s 3com hub or switch to any other hub or switch. They don't like to autonegotiate with other autonegotiate devices.

Change the IP address of your mail server, then ask your DNS host to change the MX record... but their policy requires they send you an email requiring your response to confirm the change BEFORE they will change it.

Register your domain name using an email address in that domain.

Misplace a period in a DNS zone file. On a real, live DNS server at an ISP. Watch the phone melt down.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?