Mailing List Archive

Switching VS Bridging
Collision Domain VS Broadcast Domain

L2 in general is the layer that the new folks often misunderstand.

I once had someone ask me what a hub was. That pretty much told me how
old I was....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/15/2012 2:47 PM, John Kristoff wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>

Keep the discussion on the list. I would like to know as well.

Kenneth M. Chipps Ph.D.

-----Original Message-----
From: John Kristoff [mailto:jtk@cymru.com]
Sent: Wednesday, February 15, 2012 2:47 PM
To: nanog@nanog.org
Subject: Common operational misconceptions

Hi friends,

As some of you may know, I occasionally teach networking to college students
and I frequently encounter misconceptions about some aspect of networking
that can take a fair amount of effort to correct.

For instance, a topic that has come up on this list before is how the
inappropriate use of classful terminology is rampant among students, books
and often other teachers. Furthermore, the terminology isn't even always
used correctly in the original context of classful addressing.

I have a handful of common misconceptions that I'd put on a top 10 list, but
I'd like to solicit from this community what it considers to be the most
annoying and common operational misconceptions future operators often come
at you with.

I'd prefer replies off-list and can summarize back to the list if there is
interest.

John

On Wed, Feb 15, 2012 at 1:10 PM, Kenneth M. Chipps Ph.D.
<chipps@chipps.com>wrote:

> Keep the discussion on the list. I would like to know as well.
>
> Kenneth M. Chipps Ph.D.
>
> -----Original Message-----
> From: John Kristoff [mailto:jtk@cymru.com]
> Sent: Wednesday, February 15, 2012 2:47 PM
> To: nanog@nanog.org
> Subject: Common operational misconceptions
>
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students
> and I frequently encounter misconceptions about some aspect of networking
> that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students, books
> and often other teachers. Furthermore, the terminology isn't even always
> used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but
> I'd like to solicit from this community what it considers to be the most
> annoying and common operational misconceptions future operators often come
> at you with.
>
> I'd prefer replies off-list and can summarize back to the list if there is
> interest.
>
> John
>
>
>
>
>

I don't know how many times I have "Network Administrators" ask questions
like this...
Speaking in the context of configuring an ipsec tunnel..

"I have my side built. Can you lock your side down to a specific
protocol? Our sets his device to TCP 104. Makes it nice for me when I set
my ACLs."

I am pretty sure that he meant protocol TCP and Port 104, but I do grind my
teeth when I have to go show them that a specific protocol number means
something completely different than what they were asking.

--
Mark Grigsby
Network Operations Manager
PCINW (Preferred Connections Inc., NW)
3555 Gateway St. Ste. 205
Springfield, OR 97477
Office 541-242-0808 ext 408
TF: 800-787-3806 ext 408
DID: 541-762-1171
Fax: 541-684-0283

On 02/15/12 14:47 -0600, John Kristoff wrote:
>Hi friends,
>
>As some of you may know, I occasionally teach networking to college
>students and I frequently encounter misconceptions about some aspect
>of networking that can take a fair amount of effort to correct.
>
>For instance, a topic that has come up on this list before is how the
>inappropriate use of classful terminology is rampant among students,
>books and often other teachers. Furthermore, the terminology isn't even
>always used correctly in the original context of classful addressing.
>
>I have a handful of common misconceptions that I'd put on a top 10 list,
>but I'd like to solicit from this community what it considers to be the
>most annoying and common operational misconceptions future operators
>often come at you with.
>
>I'd prefer replies off-list and can summarize back to the list if
>there is interest.

I almost always see someone fill in the 'default gateway' field when
they're configuring a temporary address on their computer to communicate
with a device on the local network.

On the topic of VLANs, it's common to think of 'trunking' and something
that happens between switches. It's hard to get someone to ponder the
fact that trunking isn't an all or nothing concept, and that a server can
be configured to speak vlan.

Confusing ftp, sftp, ftps. Or telnet, telnets, ssh.

Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X.

BGP does not magically load balance your ingress and egress traffic.

Just because it's down for you, doesn't mean it's down for everyone.

--
Dan White

Autoneg. The old timers that don't trust it after a few decades of decent code. Or those that lock one side and expect the other to adjust to that.

/Tias

15 feb 2012 kl. 21:47 skrev John Kristoff <jtk@cymru.com>:

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>

Auto-neg, as someone already mentioned.

MD5 makes BGP peering sessions more secure. There was a nice recent
NANOG rant on that one.

One of my favorites from corporate america; if you run one application
on a server you can put in that apps port in the firewall and block
everything else and the server will be happy. Evidently folks don't
know servers need to do things like make DNS queries, have remote access
to them, contact domain controllers or software update servers. *sigh*

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/

"Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X."

Good one.

Also, security as a whole seems to be confusing for folks. They've seen
"Firewall" with Harrison Ford and therefore the FW is some secret master
voodoo widget that only people from Area 51 can operate. They don't
understand "header manipulation" vs "payload".

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/15/2012 3:52 PM, Dan White wrote:
> Packet loss at hop X in traceroute/mtr does not necessarily point to a
> problem at hop X.

DNS only uses UDP
DNS only uses 512 byte UDP packets

or maybe just..

DNS is easy

--

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

ICMP is bad, and should be completely blocked for "security".

On Wed, Feb 15, 2012 at 02:47:15PM -0600, John Kristoff wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John

On Feb 15, 2012, at 23:36, Chuck Anderson wrote:

> security

That must be the top of the list:

Switches provide security (by traffic isolation)
DHCP provides security (by only letting in hosts we know)
MAC address filtering provides security (fill in the blanks…)
NAC provides security
NATs provide security
Firewalls provide security
Buying Vendor-_ provides security

Grüße, Carsten

On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson <cra@wpi.edu> wrote:
> ICMP is bad, and should be completely blocked for "security".

I can't tell if this reply is to say "this ought to be done" or if
"this is often done, and should not be."

Clarify?

-tk

ICMP is evil.
Firewalls can be configured default-permit.
Firewalls can be configured unidirectionally.
Firewalls will solve our security issues.
Antivirus will solve our security issues.
IDS/IPS will solve our security issues.
Audits and checklists will solve our security issues.
Our network will never emit abuse or attacks.
Our users can be trained.
We must do something; this is something; let's do this.
We can add security later.
We're not a target.
We don't need to read our logs.
What logs?

(with apologies to Marcus Ranum, from whom I've shamelessly
cribbed several of these)

---rsk

With security in mind:

Use other VLANs other than vlan1. Disable vlan1. Disable ports (physical
and logical) that aren't in use. Encrypt your passwords in your config, etc
etc etc...

On Wed, Feb 15, 2012 at 2:49 PM, Carsten Bormann <cabo@tzi.org> wrote:

> On Feb 15, 2012, at 23:36, Chuck Anderson wrote:
>
> > security
>
> That must be the top of the list:
>
> Switches provide security (by traffic isolation)
> DHCP provides security (by only letting in hosts we know)
> MAC address filtering provides security (fill in the blanks…)
> NAC provides security
> NATs provide security
> Firewalls provide security
> Buying Vendor-_ provides security
>
> Grüße, Carsten
>
>
>


--
Mike Lyon
408-621-4826
mike.lyon@gmail.com

http://www.linkedin.com/in/mlyon

On Wed, Feb 15, 2012 at 04:51:44PM -0600, Anton Kapela wrote:
> On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson <cra@wpi.edu> wrote:
> > ICMP is bad, and should be completely blocked for "security".
>
> I can't tell if this reply is to say "this ought to be done" or if
> "this is often done, and should not be."
>
> Clarify?

This thread is about misconceptions. What I said was a common
misconception that "all ICMP should be blocked for security reasons".
In reality, some kinds of ICMP are REQUIRED for proper functioning of
an internetwork for things like Path MTU Discovery (ICMP Fragmentation
Needed/Packet Too Big). Other kinds of ICMP are good to allow for
being nice to the users and applications by informing them of an error
immediately rather than forcing them to wait for a timeout (ICMP
Destination Unreachable).

(1) Block all ICMP (obviously some are required for normal operations,
unreachables, pMTU too large/DF set, etc).
(2) Block certain ports (blindly, w/o at least "established") taking out
legitimate ephemeral port usage.
(3) Local uRPF is unnecesary (or source spoofing mitigation in general)
(4) Automagical things are necessary (Microsoft proprietary, UPnP, Apple
Bonjour, mDNS, etc)
(5) WAN routing to multiple providers will automagically load-balance
automagically. or for that matter...
(6) IGP routing across multiple paths will automagically load-balance
automagically. Or for that matter...
(7) Port-channel (link aggregation) will load-balance automagically.
(8) Connectivity/throughput issues are always local or first-hop. (We
have a gig connection, why am I not getting a gig throughput)

I'm sure there are more, but those were at the top of my head :)

Jeff

Telco provided VPN makes communication between your sites secure.

If you can use (virtual) circuits, even better.


-- Alg

On Wed, Feb 15, 2012 at 3:47 PM, John Kristoff <jtk@cymru.com> wrote:
> I have a handful of common misconceptions that I'd put on a top 10 list,

By your classful addressing example, it sounds like these students are
what most nanog posters would consider to be entry-level.

RFC1918 is misused a lot by entry-level folks, most seem not to know
about 172.16.0.0/12

I think students should be able to learn how "traceroute" actually
works, which I have found, is a lot easier to teach as a conceptual
lesson than by just telling them "maybe the problem is in the return
path" without giving them any understanding of how or why.

MTU, Path MTU Detection, and MSS

NxGE isn't a serial 4Gbps link, and why this is so important

On the other hand, more than half of the CCIEs I have worked with are
clueless about all of the above. :-/
--
Jeff S Wheeler <jsw@inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts

traceroute shows _a_ path. Your packets might have taken a different
path. (& the return traffic yet another)

labeling something "backup link" on the network diagram doesn't make it one.

Lee


On 2/15/12, John Kristoff <jtk@cymru.com> wrote:
> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>

PKI is cryptographically secure.

IDN is internationalized.

IPv6 reduces router load by not allowing fragmentation.

IPv6 is operational.

Masataka Ohta

On 2012.02.15 15:47, John Kristoff wrote:

> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.

It is ok to use non-rfc1918 (allocated/assigned) IP space internally,
because this network will NEVER see the Internet.

Steve

On 2012.02.15 19:23, Steve Bertrand wrote:
> On 2012.02.15 15:47, John Kristoff wrote:
>
>> I have a handful of common misconceptions that I'd put on a top 10 list,
>> but I'd like to solicit from this community what it considers to be the
>> most annoying and common operational misconceptions future operators
>> often come at you with.
>
> It is ok to use non-rfc1918 (allocated/assigned) IP space internally,
> because this network will NEVER see the Internet.

...referring to space they don't own of course. Did a lot of IP address
re-design for companies who suddenly couldn't reach microsoft.com years ago.

ULA is the IPv6 equivalent of RFC1918

RFCs are standards (i.e. all of them, or RFC is synonymous with standard)

The words "Internet" and "Web" can be used interchangeably

Not only does NAT provide "security," but it's NECESSARY for "security."
Alternatively, you can't possibly be as secure without NAT than with.

Link capacity is how fast the bits move through the wire

Security is the responsibility of the Security Group

> IPv6 is operational.

How is this a misconception? It works fine for me...

Nathan

NANOG don't need no stinkin' glossary, everybody knows what our alphabet
soup means.

Getting a file by bittorrent will always be faster and stress the network
less than downloading it by FTP or HTTP.

The best wide-area network topology is exactly the same as that used by
the Bell network of decades ago.

Corollary of the above, the best back-up route between San Francisco
and Los Angeles in the event of a fiber cut in San Jose is Chicago
or Virginia, not Fresno or Bakersfield.

The only way to provide Metropolitan Optical Ethernet is to install a
Cisco router that costs over one million dollars.

Distance does not matter. Serve your site from California or Virginia,
and it will work in the panhandle of Oklahoma or the Australian outback
just as well as a closer location would.

Fiber is just too fast, all networking should be wireless.

No traffic is ever wasteful, just get bigger pipes and all problems
will be solved.