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"

Answer 1

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.

Answer 2

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".

Answer 3

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!)

Answer 4

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.

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. 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.

Answer 5

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

Answer 6

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

Answer 7

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.

Answer 8

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?)

Answer 9

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.

Answer 10

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.

Answer 11

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!"

Answer 12

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. :-)

Answer 13

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

Answer 14

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

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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).

Answer 20

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

Answer 21

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.

Answer 22

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!

Answer 23

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.

Answer 24

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.

Answer 25

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".

Answer 26

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