Most popular misconceptions about networking

Question

00000001 + 00000001 = 00000011 alt text http://locobox.googlepages.com/red_x_round.png

Misconceptions about Networking*

Time to fess-up!... 'at some point' you thought you knew something, and it ended up not being correct, or not entirely correct due to a misconception about the subject.

Let's build a good list of popular misconceptions novice AND even some seasoned IT administrators have, explicitly about Networking. My hope is to build a very useful brain-dump to serve as a good resource for the members of this community.

I'll start with an extremely obvious example (items with the most votes up will be on top):

All addresses beginning with 169 come from the APIPA failover system

Only 169.254.0.0/16 is reserved for the APIPA assignation when the OS can't find an assigned address for a network interface (read:rfc3927).

*****Not to be mistaken with "Mistakes made by sysadmins"

I saw it a long time ago in a forum (someone asking a question), and always thought it was funny. — l0c0b0x, Jun 26 '09 at 18:18

score 27 · Answer 1 · answered May 22 '09 at 18:41

27

Myth: Allowing ICMP is insecure.

This one is a pet peeve of mine, and it's widespread enough to cause significant problems on the Internet. Aside from the handy diagnostics we all know and love, there's Path MTU Discovery and other things that break when ICMP is blocked.

answered May 22 '09 at 18:41

dwc

1,528
12
10

I too hate this, people see to think that the world of cracking revolves around ICMP, never mind the poor ISP who would love to help you but cant because to them its all down. yes you can do ICMP tunnels and other such naughties, but has anyone worried about filtering their DNS on the edge? cause btw you can do DNS tunnels too, – Bruce Grobler Jun 17 '09 at 07:43
I think this stems from an older concept of using ICMP to map interior networks, so that the attacker can develop a set of targets to go after once they find a means of breaching your firewall/DMZ. – Avery Payne Jun 26 '09 at 16:01

score 26 · Answer 2 · edited Apr 13 '17 at 12:14

26

Some people have religious believes about allowed and not allowed IP addresses. Yesterday I saw in one of the answers here that 'IP addresses ending in .0 or .255 are invalid' which is plain wrong.

Others still think that we have A, B, C - sized subnets only, while CIDR was ruling the world for quite a while.

Some claim that disabling ICMP responses will make my workstation invisible in its LAN segment, which is not true. You can still send ARP requests and in most cases machine will send ARP response although it has IP level firewall running.

Others say private subnets - 192.168.0.0/16 or 10.0.0.0/8 are 'not routable' - which is plain wrong again.

People get really surprised when they learn how upload saturation affects their download speeds. This very much depends on the queuing algorithms on both ends of bottleneck, but in case of typical ADSL connections upload can significantly affect download.

On the funny side: some still think that "The Internet is a Series of Tubes".

edited Apr 13 '17 at 12:14

Community

1

answered May 22 '09 at 09:38

pQd

29,561
5
64
106

1

It's not a dumptruck. Seriously, though, an informative post in itself, this (upload saturation, o rly?). – Kara Marfia May 22 '09 at 18:28
2

Private subnets *are* routable. However, you're not *supposed* to route them *to the public internet*, as it will lead to identity issues (who's at 10.1.1.1? Is it the machine in Milwaukie, or the machine in Prague?) – Avery Payne May 24 '09 at 18:47
@Avery Payne - yes you're right. moreover having overlapping private networks in one company [ for historic reasons ] is a source of joy/pain for anyone trying to figure out what's going on and why things do not work. – pQd May 24 '09 at 19:51
3

@Avery Pane, your right about the are routeable, but try advertise them to your provider and you will get a RIB failure, seeing as providers null route private subnets on the border routers and probably filter them on the bgp sessions (i hope they do anyway). But tunnel over your provider to all your remote sites and yes they are as routable as any IP address. :D its the same with a few other "Public" prefixes, e.g. 1.0.0.0/8 are null routed at most providers, or used for router loopbacks, and we are all waiting for the day ARIN/APNIC/etc,etc all decide to make it available. – Bruce Grobler Jun 17 '09 at 07:17
@Bruce Grobler agreed, although it's interesting that I had another discussion elsehwere that resulting in people telling me "yes, you can and /should/ place non-routable IP addresses into DNS that the public can see (resolve)". The intent was to make these machines reachable from the Internet. Meanwhile, on the sidelines, I was jumping up and down, waving red flags, trying to shout to them "Don't do it! You'll regret it!" – Avery Payne Jun 26 '09 at 15:58

score 15 · Answer 3 · answered May 22 '09 at 18:35

15

All Internet connections are created equal aka download speed is the only thing that matters

"I just found out what a T1 is, don't you know that my Comcast cable at home is 6x faster than our connection at work? Why don't we have that here?"

It doesn't come up any more, but it got to the point where I'd rather swallow staples than try to explain an SLA to yet another marketing guy. (OK, I had the same question when I was a workstation support scrub, I admit it!)

answered May 22 '09 at 18:35

Kara Marfia

7,892
5
32
56

1

Oh my... I get that all the time! Reaction = deep breaths focusing on the outcome> a more informed user (repeating "think of happy thoughts" about 30 times) – l0c0b0x May 22 '09 at 18:41
"Then why does the work connection seem so much faster?" often works (the answer of course being lower latency, and local DNS, and optionally web cache) – LapTop006 May 27 '09 at 13:31
LapTop006: it's most probably going to be the upload speed that speeds up the T1 compared to a home ADSL. I've never had any problems with latency or DNS with home connectivity. – Garry Harthill Jun 22 '09 at 01:12
2

A good article on this is "It's the latency, Stupid": http://rescomp.stanford.edu/~cheshire/rants/Latency.html . That being said, the comcast business connection at my home has similar latency and better uptime then both verizon and att t1's I have had.... – Kyle Brandt Oct 07 '09 at 11:24

score 14 · Answer 4 · edited Aug 04 '12 at 21:56

14

James Gosling cites Peter Deutsch with credit for the eight fallacies of distributed computing:

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.

The network is reliable

Latency is zero

Bandwidth is infinite

The network is secure

Topology doesn't change

There is one administrator

Transport cost is zero

The network is homogeneous

I have these on the wall of my cube facing the hallway. Sometimes I feel that I trip over more than one of these per day.

edited Aug 04 '12 at 21:56

alanc

1,500
9
12

answered May 24 '09 at 19:02

Bob Cross

237
1
4
14

1

Reminds me of the customer who moved their database to a datacenter halfway across the country (while leaving the rest of the app where it was) and then complains to us that our software is too slow... ;) – Kara Marfia May 24 '09 at 23:44
2

Maybe you should have explained that all that distance was using up the network pressure. If you want to have a remote site, you need to have pumping stations to account for the slow bit leaks in the pipes.... – Bob Cross May 25 '09 at 00:11
Beautiful! Absolutely beautiful! Time for me to crack out my poster-fu.... I want one of those! – Mei Jun 23 '09 at 22:58
1

In all fairness to the customer Kara, they do have a point. The way your software is written no doubt assumed "Latency is zero", which I see in almost all DB access software. – Zan Lynx Jun 26 '09 at 18:50

score 12 · Answer 5 · answered May 22 '09 at 14:23

12

An oldy, but a goody,

BPS (bits per second) and BAUD are the same thing - which they aren't. BAUD is the symbol rate. In many system, the symbols each encode 2 or more bits. e.g.,

+2v = 11
+1v = 10
-1v = 01
-2v = 00

answered May 22 '09 at 14:23

BIBD

1,826
10
29
44

score 9 · Answer 6 · edited Jun 21 '09 at 19:29

9

In practice...

802.11A != 54 Mbit/s, 802.11A ~ 27 Mbit/s

802.11B != 11 Mbit/s, 802.11B ~ 5 Mbit/s

802.11G != 54 Mbit/s, 802.11G ~ 22 Mbit/s

edited Jun 21 '09 at 19:29

Joseph

3,787
26
33

answered May 23 '09 at 05:14

James Moore

1,247
3
17
23

4

what about 802.11n ? 600 Mbit/s – Charles Faiga May 23 '09 at 07:40

score 8 · Answer 7 · edited Aug 26 '10 at 22:00

8

I hate when the network is blamed for something with an application running slow.

When everything works except your Outlook, stop upgrading the ticket to the networking team saying the network is down. Ignorant help desk workers are the bane of many administrators' existence.

edited Aug 26 '10 at 22:00

Peter Mortensen

2,319
5
23
24

answered May 22 '09 at 14:06

sclarson

3,624
21
20

Similarly, I hate when the application is blamed for something with the network is slow. – Matt Hanson Oct 05 '11 at 02:21
I've since moved back into a development role and completely agree with that as well :) – sclarson Oct 12 '11 at 14:16

score 7 · Answer 8 · answered Jun 21 '09 at 18:21

7

That doing stuff in "hardware" is always better performing than doing it in "software".

(which leads to the obvious question of where one draws the line between these two anyway, or if there's even a good distinction at all?)

answered Jun 21 '09 at 18:21

Oskar Duveborn

10,740
3
32
48

score 6 · Answer 9 · answered Jun 21 '09 at 18:50

6

That "MBps" and "mbps" are interchangeable. Even if I could contextually discern that 'millibits' are not a valid unit of measurement, there's still a factor of 8 difference between the two.

And don't even get me started on mebibits.

answered Jun 21 '09 at 18:50

goldPseudo

1,106
1
9
15

score 5 · Answer 10 · answered May 22 '09 at 13:29

In an Enterprise LAN environment, many people are still under the assumption that routing between vlans is slower than switching. With today's modern switches, both switching and routing are handled in hardware which can processes/forward these packets at the same speed.

score 5 · Answer 11 · edited Aug 26 '10 at 22:06

5

The misconception that using wireless means Internet access is much slower because it shows 54 MB/s whereas using an Ethernet connection shows 100 MB/s.

Needless to say it was hard explaining to the user that was only the local network speed and in actual fact the Internet speed for the site was only 8 mbps/ 900 KB/s.

Or alternatively, the users that demand you to supply a broadband connection, then when you tell them the wireless that they're using is connected to a broadband Internet connection they exclaim "No, I mean the blue cable!"

edited Aug 26 '10 at 22:06

Peter Mortensen

2,319
5
23
24

answered May 23 '09 at 04:26

Omegatron

121
1
4

Interesting... I've never heard/thought about this misconception (not saying it's out there, I'm sure it is). – l0c0b0x Jun 26 '09 at 19:38
1

Actually, IMHO there are other things to wireless which add a slight (but sensible) latency compared to cable. – Halil Özgür Dec 18 '10 at 11:13
Not to mention 100Mbps could be half duplex too! :-) – Omegatron Apr 01 '11 at 06:14

score 5 · Answer 12 · answered May 27 '09 at 10:30

The idea that dedicated hardware appliances are always better, more reliable and higher-performance than commodity and/or PC hardware - in practice, with today's costs.

It's basically what Cisco wants you to believe; sure, the NPE in the router chassis only has a ~300 MHz ARM processor, but it's got all these ASICs (Application Specific Integrated Circuits) just for fast packet forwarding, FIB routing lookups and so on.

While that may be true, and I generally do favour using proprietary gear of that sort for routers and switches for a variety of administrative and MTBF-related reasons, the fact is that in the era of 3 GHz processors and 8 GB of RAM, often the presence of ASICs and CAM just doesn't matter -- the PC can still smoke that router. Sure, all the stuff is done in CPU instead of offboarded to dedicated hardware, and sure, it's all in processes subject to the ravages of a contended userspace scheduling environment in a general-purpose OS, but when you have 20x the CPU power, sometimes it doesn't matter - it still comes out way ahead, and much cheaper.

I learned this again recently when dealing with a fairly high-end PIX buckling to increasing packet processing loads in a growing VoIP environment (high packets-per-second cripple routers much more so than overall throughput per se, and VoIP audio streams consist of very large amounts of very small packets); the Linux firewall I set up as a stopgap measure for inter-VLAN routing in the meantime blew that thing out of the water.

Ditto for BGP. There is still a vivacious debate in the Cisco world about the minimum router specs needed to hold one or more full BGP views of the ever-growing IPv4 routing table, since so many router models are generally capable of it were they not skimpy on the RAM. Well, you know, Quagga and a solid Linux server with a great NIC and low-interrupt I/O tweaks can do wonders. :-)

IME you can do BGP *or* (fairly) high speeds on a PC-based router, not both. Although by the time you're doing both the cost of a real router is worth it for the features. Even on the small side it can be good, for us Juniper J-series is a cheaper BGP router then a PC based server. — LapTop006, May 27 '09 at 13:37
I think mostly people choose to use Cisco not because of there apparent higher throughput of packets ( www.vyatta.com ) but the fact that we have all grown up with Cisco and trust Cisco, I know for a fact that some PC based routers could replace some of the equipment in my network and be far superior, but I grew up on Cisco and keep Cisco :D As well the features we get from cisco kit are unparalleled in the unix/linux router world, I would presonally despise not having route-maps and policy-maps (has anyone seen TC? then you know what I'm talking about :D) Thats my $0.0002 — Bruce Grobler, Jun 17 '09 at 07:09
You should look at the specs of a PIX. Surprise! It's just a PC! http://en.wikipedia.org/wiki/Cisco_PIX — Joseph, Jun 21 '09 at 19:56

score 5 · Answer 13 · answered Jun 21 '09 at 22:17

5

That MAc address duplication is not possible. It is, it's just pretty darned unlikely.

answered Jun 21 '09 at 22:17

Vatine

5,390
23
24

Oh yeah, always worth checking for. ARPwatch has saved me a couple of times. – Zan Lynx Jun 26 '09 at 18:56
Does anyone know just how likely? – David Hicks Jun 28 '09 at 22:44
Most manufacturers that run multible fabrication lines are probably using a PRNG of some sort to assign the lower 24 bits of the MAC (so as to not need to keep uniqueness between multiple production lines), so for those, you can estimate 50% chance of a collission of you have 2^12 (so 4096) network cards within the same broadcast domain. – Vatine Jun 29 '09 at 13:43
1

"it's just pretty darned unlikely" -- and is sometimes intentional ;) – Stefan Lasiewski Aug 26 '10 at 22:26

score 4 · Answer 14 · edited Aug 26 '10 at 22:15

4

That you need a cross-over cable to connect 2 computers with gigabit Ethernet. You dont! Patch does the trick!

edited Aug 26 '10 at 22:15

Peter Mortensen

2,319
5
23
24

answered May 22 '09 at 13:58

Nick Kavadias

10,758
7
36
47

7

Be aware this only works if at least of the network cards supports MDI/MDI-X sensing. Most do but there are still cards about that don't. – Nathan May 22 '09 at 16:23
We had a problem where a wiring guy installed a jack using 586B on the switch side and 586A at the desk. Every machine we tested worked except the customer's. – Joseph Jun 21 '09 at 19:33
1

MdiX is a requirement of GbE as far as I recall – Dave Cheney Jun 26 '09 at 17:41

score 4 · Answer 15 · answered May 22 '09 at 18:47

4

Cable type doesn't matter for the network as long as it's professionally crimped. This comes from an admin wondering why the brand new computers still access the internet slowly with their 100Base-T adapters. The network cable was Cat-3 IIRC.

answered May 22 '09 at 18:47

Joshua Nurczyk

738
6
17

romandas · Answer 16 · 2009-05-24T22:18:11.767

The misconception that a Ethernet switched network == a secure network. It doesn't.

Besides the ubiquitous presence of arp-poisoning tools like 'Cain & Abel' and their ilk, the fact that the CAM table will time out every so often (default 5 minutes on a Cisco switch) and thus flood unicast traffic like a hub translates to packet leakage and thus potential information leakage.

You can change the timeout value on managed switches to compensate for how much flooding you want to allow, but given that it's part of how Ethernet switching works, you cannot mitigate it completely.

score 3 · Answer 17 · answered Jun 21 '09 at 18:11

Myth: Doubling the bps of a link doubles the useful throughput.

As with many myths this can be true in some limited circumstances but it ignores the latency of the link and the performance limits of the end-systems and the protocols.

Increasing the bps reduces the time it takes for an system to get the data onto the link, it doesn't make the data move along the link faster. The time for the start of the first bit to arrive at the other end is the same as before but the delay until the last bit arrives is reduced.

score 3 · Answer 18 · answered Jun 22 '09 at 04:58

I have a few myths related to private networks (10.x.x.x, 192.168.x.x, etc.).

Myth 1: Private IPs can never appear on the public network. Therefore, it's not possible for a private IP that's not your own to appear in, say, a traceroute listing or the SMTP "Received by" headers.

Myth 2: It's not possible for an internet-facing DNS server to hand out private-network IP addresses.

Both these myths stem from the same misconception: that private IPs are truly private and that they never mix with public IPs. I believe the spec says only that private IPs shall never be routed on the public network. That is, if you try to find the route to some random private IP (assuming it's not on your own network), you won't get anywhere.

But that doesn't preclude private IPs appearing in the output or the result of some query. Internal mail servers, for example, don't have a public IP address, so what other IP address can they include in the Received-By header other than their own?

Likewise, a large institutional network may use different private networks among their numerous LANs. Packets that pass through their network will pick up the private IPs of the routers, even if the packet eventually makes its way back onto the public network. Thus, a traceroute can include the private IP of a router in its output.

Myth 3: Since private network addresses are not routable, two LANs that share the same private network address space can be connected via a bridge (such as a VPN) without any problems.

It won't work -- at least not in my experience. Let's say your work uses the 192.168.1.x network and you use the same one at home (as is typical of consumer routers). You establish a VPN connection from your home PC to work. At some point, you want to send a print job to a printer at work whose IP address is 192.168.1.10. Your home PC looks in its routing table to figure out where to send that packet. Which LAN should receive it: your home LAN or your work LAN? Answer: don't know. Maybe this one, maybe that one. One of them will get it, but it probably depends on your OS and VPN software to distinguish which one gets priority. If it's like the VPN software I've had experience with, your home LAN will get it and if there's not a device at 192.168.1.10, the packet will be dropped eventually.

Solution: when using a VPN, make sure both LANs are using different network spaces.

score 2 · Answer 19 · edited Aug 26 '10 at 22:10

2

How about the misconception that you can divide a link's bandwidth (in bits/sec) by 8 to accurately model how many bytes it will transit. I always bank on 75% (max) of eight-tenths of the link speed (i.e. for a 10 GBps link I bank on 600 MBps max).

edited Aug 26 '10 at 22:10

Peter Mortensen

2,319
5
23
24

answered May 22 '09 at 09:50

Chopper3

100,240
9
106
238

assuming it's tcp streams crossing the link - it all depends on the latency, protocol tuning, and number of concurrent connections. – pQd May 22 '09 at 09:55
1

Well, actually, divide by 8 works pretty well on lower speed serial links (DS1). Once the speed ramps up some, divide by 10 becomes more realistic. On ethernet, all bets are off. :-) – Brian Knoblauch May 22 '09 at 13:52
I divide by 10 to get usable bytes, always ends up very close, although larger links you often can't fill with only one host. – LapTop006 May 27 '09 at 13:32

score 2 · Answer 20 · edited Aug 26 '10 at 22:14

OK, here's something I just worked out that before had eluded me, for every packet you send it appears the average overhead is 38 bytes, this is including the IP and TCP Header (of course this value assumes all fields in the TCP header are used to the max, IP header size is a common value i.e. no DSCP values, etc., etc.), so to transfer say 2 MB (with packet sizes at 64 KB increasing your packets per second [bigger packets per second = smaller overhead] ) you're looking at 1.2 KB of overhead, not much but that equates to 6.78 MB for every 10 GB transferred, and 607.8 MB for every 1 TB transferred.

I feel better now :D

score 2 · Answer 21 · answered May 23 '09 at 07:46

2

I think the biggest misconception I see is that IP based networking can solve all our IT or technical needs.

The biggest example I see of this is VOIP. It is telecom infrastructure that is so incredibly expensive, resource intensive, and difficult to manage properly. Sure the deployments work... sort of, but I'm sure there could be much better systems with dedicated protocols / infrastructure.

answered May 23 '09 at 07:46

Kevin Nisbet

818
6
8

Actually VoIP is usually *HUGELY* cheaper then traditional telephony when done properly, old-style PABX's were 2-3x more then today's VoIP gear. – LapTop006 May 27 '09 at 13:34
3

If you running a small office off an asterisk box, you have an advantage. However, in the enterprise it's a massive undertaking with dismal results. Most large corporations deploy seperate networks for VOIP, since any time you run a file transfer all the phone calls stop working, or you have to buy more expensive routers that support rsvp. Finally, you need more (more expensive) IT people to build and maintain a network which has no down time, no packet loss, no jitter, and requires more bandwidth (unless you go with crappy voice quality). Early adopters got rid of their void networks. – Kevin Nisbet May 27 '09 at 20:25
You should always have your pbx coming in from a different internet connection from your lans internet commection. – XTZ Jun 26 '09 at 17:35
1

@XTZ - Not all IT departments do that... – J. Polfer Mar 30 '10 at 19:43

score 2 · Answer 22 · answered Jun 21 '09 at 20:39

That a home-style wireless access point (or two) can replace a wired network in a multi-user environment. Sure, your wireless connection at home handles up to 5 or so PCs, but you try getting it to deal with two classrooms of 30 children all trying to use laptops to log on to a Windows domain at the same time. You need a managed wireless system, or some fixed wired points to handle some (well, most) of the load. And a quick note to managed wireless system salespeople out there: yes, I'm sure your system has better performance than the competition, but it isn't infinite - there is only so much bandwidth you can squeeze out of the limited set of frequencies available to 802.11 wireless, you canna' change the laws of physics!

+ for the Scotty reference. :) – Zan Lynx Jun 26 '09 at 18:55 — Zan Lynx, Jun 26 '09 at 18:55

score 2 · Answer 23 · answered Jun 26 '09 at 17:17

That, if SMB File Sharing / NetBIOS doesn't work, that nothing else will work on the network (including browsing the WWW) and the whole network is down.

A former web-wired-educator turned sysadmin thought that when I was in high school. I do not know if she was disabused of the above notion.

score 1 · Answer 24 · answered Jun 22 '09 at 01:01

Myth: Adding more bandwidth to a connection will always make things faster.

Not so much. If your link isn't saturated, and you are trying to get data from China to the US, you may simply be going as fast as you can. It takes time (even at the speed of light) to get from the US to China, and making the link won't go faster if you only have a single data stream going between the sites.

score 1 · Answer 25 · answered Jun 26 '09 at 16:54

1

Fondly tweaking a socket with the SO_LINGER option to prevent TCP's TIME_WAIT state because "TIME_WAIT is, you know, so, you know, old and, you know, like, yucky".

answered Jun 26 '09 at 16:54

Alexander Gromnitsky

231
1
3

score 1 · Answer 26 · answered Jun 26 '09 at 17:33

1

That your management/boss, the "SR Network Admin" knows anything about real networking. -disgruntled Jr Network Admin.

answered Jun 26 '09 at 17:33

XTZ

183
1
1
10

Most popular misconceptions about networking

Misconceptions about Networking*

Let's build a good list of popular misconceptions novice AND even some seasoned IT administrators have, explicitly about Networking. My hope is to build a very useful brain-dump to serve as a good resource for the members of this community.

All addresses beginning with 169 come from the APIPA failover system

26 Answers26

Myth 1: Private IPs can never appear on the public network. Therefore, it's not possible for a private IP that's not your own to appear in, say, a traceroute listing or the SMTP "Received by" headers.

Myth 2: It's not possible for an internet-facing DNS server to hand out private-network IP addresses.

Myth 3: Since private network addresses are not routable, two LANs that share the same private network address space can be connected via a bridge (such as a VPN) without any problems.