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.

A few for me that come to mind which haven't been covered yet.

*) Latency, jitter, etc when pinging a router means packets going
through the router suffer the same fate.

Never fails that I get a call about the latency changes that occur every
60 seconds, especially on software based routers. uh, huh.

*) admin/admin is okay in a private network behind a firewall

Oh, look, a console port!

*) Assign arbitrary MTUs in a layer 2 transport network based on exactly
what customers order.

*) MTU/packet/frame/ping size means the same thing on all vendors.

*) If Wireshark looks right, it must be right (unless Windows discarded
1 (and only 1) layer of 802.1q tags)

*) Upgrades should always be done, even when there's no relevant
security or functionality that is needed in newer code.

Amazing how many code changes break things which don't necessarily show
up in test environments but will show in production networks (Your mpls
worked for months with an invalid router-id configured, and then broke
when you change codes? DHCP worked fine, but after upgrade quit
accepting <300 byte DHCP packets?).


Jack

In message <4F3C2E47.80903@dougbarton.us>, Doug Barton writes:
>
> DNS only uses UDP
> DNS only uses 512 byte UDP packets
>
> or maybe just..
>
> DNS is easy

Or that it is correct/does no harm to filter fragmented packet / icmp.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Something that makes me crawl out of my skin is when they refer to an access point as "router".

-Mario Eirea

On Feb 15, 2012, at 3:47 PM, "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
>

I whole-heartedly agree with that last one.

-Grant

On Wed, Feb 15, 2012 at 8:07 PM, Mario Eirea <meirea@charterschoolit.com>wrote:

> Something that makes me crawl out of my skin is when they refer to an
> access point as "router".
>
> -Mario Eirea
>
> On Feb 15, 2012, at 3:47 PM, "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
> >
>
>

On 2012.02.15 19:55, Nathan Eisenberg wrote:
>> IPv6 is operational.
>
> How is this a misconception? It works fine for me...

Imagine an operator who is v6 ignorant, with a home provider who
implements v6 half-assed, and tries to access a v6 site that has perhaps
v6-only accessible nameservers, when their provider who 'offers' v6 has
resolvers that operate only over v4.

*huge* misconception about the operational status of IPv6 (imho).

Steve

On 2012.02.15 19:19, Masataka Ohta wrote:

> IPv6 is operational.

This is an intriguing statement. Any ops/eng I know who have claimed
this, actually know what they are talking about, so it is factual. I've
never heard anyone claim this in a way that could be a misconception.

I state further in this sub-thread how the opposite could be true though :)

Steve

On Wed, Feb 15, 2012 at 5: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:

as a segue to....

> NATs provide security

In message <4F3C6703.4050607@gmail.com>, Steve Bertrand writes:
> On 2012.02.15 19:55, Nathan Eisenberg wrote:
> >> IPv6 is operational.
> >
> > How is this a misconception? It works fine for me...
>
> Imagine an operator who is v6 ignorant, with a home provider who
> implements v6 half-assed, and tries to access a v6 site that has perhaps
> v6-only accessible nameservers, when their provider who 'offers' v6 has
> resolvers that operate only over v4.
>
> *huge* misconception about the operational status of IPv6 (imho).

This doesn't prove that IPv6 is not operational. All it proves is
people can misconfigure things. If you provide the recursive
nameservers with IPv6 access they will make queries over IPv6 even
if they only accept queries over IPv4.

If you want to know if your resolver talks IPv6 to the world and
supports 4096 EDNS UDP messages the following query will tell you.

dig edns-v6-ok.isc.org txt

Similarly for IPv4.

dig edns-v4-ok.isc.org txt

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Mark Andrews wrote:

> This doesn't prove that IPv6 is not operational. All it proves is
> people can misconfigure things.

How do operators configure their equipments to treat
ICMP packet too big generated against multicast and
unicast?

Note that, even if they do not enable inter-subnet
multicast in their domains, the ICMP packets may
still transit over or implode within their domains.

Note also that some network processors can't efficiently
distinguish ICMP packets generated against multicast and
unicast.

Masataka Ohta

Not understanding RFC1918. Actually got read the riot act by someone
because I worked for an organization that used 10.0.0.0/8 and that was
"their" network and "they" owned it.

Chuck

2012/2/15 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>

> Mark Andrews wrote:
>
> > This doesn't prove that IPv6 is not operational. All it proves is
> > people can misconfigure things.
>
> How do operators configure their equipments to treat
> ICMP packet too big generated against multicast and
> unicast?
>
> Note that, even if they do not enable inter-subnet
> multicast in their domains, the ICMP packets may
> still transit over or implode within their domains.
>
> Note also that some network processors can't efficiently
> distinguish ICMP packets generated against multicast and
> unicast.
>
> Masataka Ohta
>
>

In message <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes:
> Mark Andrews wrote:
>
> > This doesn't prove that IPv6 is not operational. All it proves is
> > people can misconfigure things.
>
> How do operators configure their equipments to treat
> ICMP packet too big generated against multicast and
> unicast?

Well you need to go out of your way to get a ICMP PTB for IPv6
multicast as the default is to fragment multicast packets at the
source at network minimum mtu (RFC3542 - May 2003). That's not to
say it won't happen.

As for generation of PTB you rate limit them the way you do for
IPv4.

> Note that, even if they do not enable inter-subnet
> multicast in their domains, the ICMP packets may
> still transit over or implode within their domains.
>
> Note also that some network processors can't efficiently
> distinguish ICMP packets generated against multicast and
> unicast.

And why do you need to distingish them? You look at the inner
packet not the ICMP source if you want to rate limit return traffic.

> Masataka Ohta
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 2012.02.15 22:12, Mark Andrews wrote:
> In message<4F3C6703.4050607@gmail.com>, Steve Bertrand writes:
>> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>>> IPv6 is operational.
>>>
>>> How is this a misconception? It works fine for me...
>>
>> Imagine an operator who is v6 ignorant, with a home provider who
>> implements v6 half-assed, and tries to access a v6 site that has perhaps
>> v6-only accessible nameservers, when their provider who 'offers' v6 has
>> resolvers that operate only over v4.
>>
>> *huge* misconception about the operational status of IPv6 (imho).
>
> This doesn't prove that IPv6 is not operational. All it proves is
> people can misconfigure things. If you provide the recursive
> nameservers with IPv6 access they will make queries over IPv6 even
> if they only accept queries over IPv4.
>
> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
>
> dig edns-v6-ok.isc.org txt
>
> Similarly for IPv4.
>
> dig edns-v4-ok.isc.org txt

Thank you :)

Steve

"IS-IS is a legacy protocol that nobody uses"


15.02.2012 22:47, John Kristoff kirjoitti:
> 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
>

How widespread would you say the use of IS-IS is?

Even more as to which routing protocols are used, not just in ISPs, what
percent would you give to the various ones. In other words X percent of
organizations use OSPS, Y percent use EIGRP, and so on.

-----Original Message-----
From: Antti Ristimäki [mailto:antti.ristimaki@gmx.com]
Sent: Wednesday, February 15, 2012 10:47 PM
To: John Kristoff
Cc: nanog@nanog.org
Subject: Re: Common operational misconceptions

"IS-IS is a legacy protocol that nobody uses"


15.02.2012 22:47, John Kristoff kirjoitti:
> 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 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> How widespread would you say the use of IS-IS is?
>
> Even more as to which routing protocols are used, not just in ISPs, what
> percent would you give to the various ones. In other words X percent of
> organizations use OSPS, Y percent use EIGRP, and so on.

Using EIGRP implies your routed IGP dependent infrastructure is a
monoculture. That's probably infeasible without compromise even if you
are largely a Cisco shop.

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristimäki [mailto:antti.ristimaki@gmx.com]
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> "IS-IS is a legacy protocol that nobody uses"
>
>
> 15.02.2012 22:47, John Kristoff kirjoitti:
>> 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
>>
>
>
>
>
>
>

"ISIS is used in organizations other than ISPs" Any examples you can share
of some other than ISPs?

-----Original Message-----
From: Joel jaeggli [mailto:joelja@bogus.com]
Sent: Wednesday, February 15, 2012 11:58 PM
To: Kenneth M. Chipps Ph.D.
Cc: nanog@nanog.org
Subject: Re: Common operational misconceptions

On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> How widespread would you say the use of IS-IS is?
>
> Even more as to which routing protocols are used, not just in ISPs,
> what percent would you give to the various ones. In other words X
> percent of organizations use OSPS, Y percent use EIGRP, and so on.

Using EIGRP implies your routed IGP dependent infrastructure is a
monoculture. That's probably infeasible without compromise even if you are
largely a Cisco shop.

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristimäki [mailto:antti.ristimaki@gmx.com]
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> "IS-IS is a legacy protocol that nobody uses"
>
>
> 15.02.2012 22:47, John Kristoff kirjoitti:
>> 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
>>
>
>
>
>
>
>

Mark Andrews wrote:

> Well you need to go out of your way to get a ICMP PTB for IPv6
> multicast as the default is to fragment multicast packets at the
> source at network minimum mtu (RFC3542 - May 2003). That's not to
> say it won't happen.

Yes, it will happen, because RFC3542 was, as was discussed
in IETF, written not to prohibit multicast PMTUD.

So, the problem is real.

> As for generation of PTB you rate limit them the way you do for
> IPv4.

A problem is that a lot of ICMP packet too big against unicast
is generated, because PMTUD requires hosts periodically try to
send a packet a little larger than the current PMTU.

BTW, that's why IPv6, which inhibit fragmentation by routers,
is no better than IPv4 with fragmentation enabled, because,
periodic generation of ICMP packet too big by routers is as
painful as periodic fragmentation by routers.

>> Note also that some network processors can't efficiently
>> distinguish ICMP packets generated against multicast and
>> unicast.

> And why do you need to distingish them?

We don't need to. Instead, we can just give up to use PMTUD
entirely and just send packets of 1280B or less. A problem
is that a tunnel over 1280B PMTU must always fragment 1280B
payload.

> You look at the inner
> packet not the ICMP source if you want to rate limit return traffic.

That is a possible problem.

Destination address of inner packet is located far inside
of the ICMP (beyond 64B) that it can not be used for
intrinsic filtering capability of some network processors.

Masataka Ohta

Some recent questions from interview and lab sessions I took.

- I've allowed vlan X on trunk but still its not working? why do I have to
create it on every switch?
- any-any rules on firewall with AV enabled is better.
- ACL inboud/outbout misconcept. Always end up cutting the rope.
- BGP is for ISPs only.
- MPLS is for security and is fast.

Regards,

Aftab A. Siddiqui


On Thu, Feb 16, 2012 at 11:00 AM, Kenneth M. Chipps Ph.D. <chipps@chipps.com
> wrote:

> "ISIS is used in organizations other than ISPs" Any examples you can share
> of some other than ISPs?
>
> -----Original Message-----
> From: Joel jaeggli [mailto:joelja@bogus.com]
> Sent: Wednesday, February 15, 2012 11:58 PM
> To: Kenneth M. Chipps Ph.D.
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> > How widespread would you say the use of IS-IS is?
> >
> > Even more as to which routing protocols are used, not just in ISPs,
> > what percent would you give to the various ones. In other words X
> > percent of organizations use OSPS, Y percent use EIGRP, and so on.
>
> Using EIGRP implies your routed IGP dependent infrastructure is a
> monoculture. That's probably infeasible without compromise even if you are
> largely a Cisco shop.
>
> ISIS is used in organizations other than ISPs.
>
> > -----Original Message-----
> > From: Antti Ristimäki [mailto:antti.ristimaki@gmx.com]
> > Sent: Wednesday, February 15, 2012 10:47 PM
> > To: John Kristoff
> > Cc: nanog@nanog.org
> > Subject: Re: Common operational misconceptions
> >
> > "IS-IS is a legacy protocol that nobody uses"
> >
> >
> > 15.02.2012 22:47, John Kristoff kirjoitti:
> >> 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 12: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

I think one of the most damaging fundamental misconceptions which is
not only rampant among students, but, also enterprise IT professionals
is the idea that NAT is a security tool and the inability to conceive of the
separation between NAT (header mutilation) and Stateful Inspection
(policy enforcement).

Owen

On Feb 15, 2012, at 6:16 PM, Steve Bertrand wrote:

> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>> IPv6 is operational.
>>
>> How is this a misconception? It works fine for me...
>
> Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4.
>
> *huge* misconception about the operational status of IPv6 (imho).
>
> Steve

By that definition, IPv4 is non-operational.

You can break anything if you try hard enough.

Owen

On 16/02/2012 07:45, Owen DeLong wrote:
>
> On Feb 15, 2012, at 6:16 PM, Steve Bertrand wrote:
>
>> On 2012.02.15 19:55, Nathan Eisenberg wrote:
>>>> IPv6 is operational.
>>>
>>> How is this a misconception? It works fine for me...
>>
>> Imagine an operator who is v6 ignorant, with a home provider who implements v6 half-assed, and tries to access a v6 site that has perhaps v6-only accessible nameservers, when their provider who 'offers' v6 has resolvers that operate only over v4.
>>
>> *huge* misconception about the operational status of IPv6 (imho).
>>
>> Steve
>
> By that definition, IPv4 is non-operational.
>
> You can break anything if you try hard enough.

This being well demonstrated by most of the "Internet" access provided
by hotels, for example.

--
Paul

On 15 Feb 2012, at 20:50, "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.

When I took an A level computing course in the 90s the course material still talked about primary stor and backing stor, batch jobs and the like...

Needless to say I quit in disgust but the point is that the people who write these courses are often woefully out of touch.

--
Leigh


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

> When I took an A level computing course in the 90s the course material
> still talked about primary stor and backing stor, batch jobs and the
> like...

I was working with a lot of batch jobs in my first development role in 1993, and still supporting overnight scheduling to make best use of the Cray by 1999. I still leave the occasional big data set crunching overnight now. I'll grant you it's not exactly mainstream computing, but it's not exactly up there with drum memory either...

The concept that a computer can do things when a person isn't there, or without the need for clicking things, is probably not a bad one to impart.

Regards,
Tim.

This isn't so much a list of misconceptions that recent students have as a list of misconceptions that security management have…

On 15 Feb 2012, at 22:52, Rich Kulawiec wrote:

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

> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
>
> dig edns-v6-ok.isc.org txt
>
> Similarly for IPv4.
>
> dig edns-v4-ok.isc.org txt

Both PowerDNS recursor 3.3 and Nominum CNS 3.0.5 have problems
with these queries. They both get the TC answer from 149.20.64.58 /
2001:4f8:0:2::8. Then:

- CNS tries with 4000 EDNS UDP size (4000 is the CNS documented max
UDP size), gets another TC.

- PowerDNS doesn't try to used EDNS at all.

Then they both try TCP and get a RST. And then they return SERVFAIL.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

"You can trust your supplier's marketing literature."

Heck, maybe just "You can trust your supplier."

==ml

> 15.02.2012 22:47, John Kristoff kirjoitti:
> >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
> >
>

--
Michael W. Lucas
http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/
Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery
mwlucas@BlackHelicopters.org, Twitter @mwlauthor

The idea that the network will always match the documentation.

I have walked into many projects where this is not the case, but a
Junior Admin working with me can't seem to get around the fact that
the Visio we were handed isn't to be trusted and we've got to
double-check everything.

-Brett Lykins

On Feb 15, 2012, at 3:47 PM, 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

On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:

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

I think he left off "In Japan". There's been a lot of local politics as it relates to the broken nature of IPv6 in japan. When its there, it's not globally accessible in many cases (at the consumer or last-mile level). Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".

IPv6 is operational and does work, but like any protocol there are issues. If you are unaware, take a look at what people are trying to put into IPv4 still at IETF. The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real. Me? I can't wait to have this behind us. (Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it. Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).

- Jared

Teach the TCP/IP model ...

On 16/02/2012, 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
>
>

On Feb 16, 2012, at 4:31 AM, Jared Mauch wrote:

>
> On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:
>
>>> IPv6 is operational.
>>
>> How is this a misconception? It works fine for me...
>
> I think he left off "In Japan". There's been a lot of local politics as it relates to the broken nature of IPv6 in japan. When its there, it's not globally accessible in many cases (at the consumer or last-mile level). Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".
>
> IPv6 is operational and does work, but like any protocol there are issues. If you are unaware, take a look at what people are trying to put into IPv4 still at IETF. The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real. Me? I can't wait to have this behind us. (Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it. Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).
>
> - Jared

Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.

Owen

On Wed, 15 Feb 2012 22:26:11 -0500
Charles Mills <w3yni1@gmail.com> wrote:

> Not understanding RFC1918. Actually got read the riot act by someone
> because I worked for an organization that used 10.0.0.0/8 and that was
> "their" network and "they" owned it.

Once upon a time, a now deservedly defunct organization called
marchFIRST, was brought in to do a security assessment of a university
network I was involved in and one issue I recall them "identifying" was
that the university was not "RFC 1918 compliant". The following
statement was also made:

As part of the Forum of Incident Response and Security Teams (FIRST)
Coalition, there is no firewall between the DePaul University data
network and the Coalition network.

*plonk*

John

I help with networking curriculum and labs here at the University of
Maine, especially for network security.

There seems to be (even among faculty) a gross misunderstanding of
Layer-2. Nearly every textbook starts with IP, and talks about it as
if we were 20 years in the past.

I've found starting off with some history on Ethernet (Maine loves Bob
Metcalfe) becomes a very solid base for understanding; how "Ethernet"
today is very different; starting with hubs, bridges, collisions, and
those problems, then introducing modern switching, VLANs, broadcast
domain's etc.

Then expanding on that by introducing Layer-3 starting with its
relationship to L-2 (ARP, how packets are manipulated when a host
makes the determination if a packet is on link or needs to be routed,
etc).




On Thu, Feb 16, 2012 at 8:03 AM, Owen DeLong <owen@delong.com> wrote:
>
> On Feb 16, 2012, at 4:31 AM, Jared Mauch wrote:
>
>>
>> On Feb 15, 2012, at 7:55 PM, Nathan Eisenberg wrote:
>>
>>>> IPv6 is operational.
>>>
>>> How is this a misconception?  It works fine for me...
>>
>> I think he left off "In Japan".  There's been a lot of local politics as it relates to the broken nature of IPv6 in japan.  When its there, it's not globally accessible in many cases (at the consumer or last-mile level).  Most (all?) major backbones are IPv6 capable these days, but in some cases it's 6PE vs "native".
>>
>> IPv6 is operational and does work, but like any protocol there are issues.  If you are unaware, take a look at what people are trying to put into IPv4 still at IETF.  The fact that the IPv6 day went so well last year, and the IPv6 launch is coming quickly is a reminder its real.  Me?  I can't wait to have this behind us.  (Oh, and if you're not at least routing your IPv6 space to your lab/NOC LAN, get on it.  Even if you have to poke the 'security' guys who think you need an IPv6 NAT in the eye).
>>
>> - Jared
>
> Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.
>
> Owen
>
>



--
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System
http://www.networkmaine.net/

Wouldn't know about that part. You would have to ask an ntt employee.

Jared Mauch

On Feb 16, 2012, at 8:03 AM, Owen DeLong <owen@delong.com> wrote:

> Yes, I'm well aware of the problems being created by the attempts by NTT to force the government to let them be a residential ISP.

On 2/16/2012 8:17 AM, Ray Soucy wrote:
> I've found starting off with some history on Ethernet (Maine loves Bob
> Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> today is very different; starting with hubs, bridges, collisions, and
> those problems, then introducing modern switching, VLANs, broadcast
> domain's etc.

It's a bit dated (1998) but I always thought Rich Siefert covered "the
basics" very well...
http://www.amazon.com/Gigabit-Ethernet-Technology-Applications-High-Speed/dp/0201185539

Jeff

Mario Eirea (meirea) writes:
> Something that makes me crawl out of my skin is when they refer to an access point as "router".

I have colleagues that work with radio and wireless, and they crawl out
of *their* skin when I call an access point an access point, and they tell
me it's a station :)

Mark Andrews (marka) writes:
> If you want to know if your resolver talks IPv6 to the world and
> supports 4096 EDNS UDP messages the following query will tell you.
>
> dig edns-v6-ok.isc.org txt
>
> Similarly for IPv4.
>
> dig edns-v4-ok.isc.org txt
>

9.8.1P1 on a dual stacked native v6 host: I'm seeing TC on both answers,
the difference is the TCP answer comes through on v4 but v6 gives SERVFAIL.

Don't see any v6 fragments (that'd be a problem since PF doesn't handle
them on this host).

P.

In message <20120216.130143.74691634.sthaug@nethelp.no>, sthaug@nethelp.no writes:
> > If you want to know if your resolver talks IPv6 to the world and
> > supports 4096 EDNS UDP messages the following query will tell you.
> >
> > dig edns-v6-ok.isc.org txt
> >
> > Similarly for IPv4.
> >
> > dig edns-v4-ok.isc.org txt
>
> Both PowerDNS recursor 3.3 and Nominum CNS 3.0.5 have problems
> with these queries. They both get the TC answer from 149.20.64.58 /
> 2001:4f8:0:2::8. Then:

I stated very clearly the conditions under which the queries would
resolve.

> - CNS tries with 4000 EDNS UDP size (4000 is the CNS documented max
> UDP size), gets another TC.
>
> - PowerDNS doesn't try to used EDNS at all.
>
> Then they both try TCP and get a RST. And then they return SERVFAIL.

Correct. Those servers are deliberately configured to not answer
TCP as they are for testing the EDNS UDP path. They also put out
a answer that will exactly fill a 4096 byte EDNS UDP message which
is the default and largest EDNS UDP size advertised by named. This
allows someone running named to test their firewall configuration
to ensure that it will let through any EDNS UDP reply, size wise,
that can occur. As IPv4 and IPv6 are often configured independently
we provide a way to test each independently.


> Steinar Haug, Nethelp consulting, sthaug@nethelp.no
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Or a security vendor, or a security publication... the whole "top ten"
delivered as ten individual clicks with pay-per-view banner ads on each
page and a bazillion tracker cookies.... arrrrrrgh.....

Jeff

On 2/16/2012 5:26 AM, Chris Campbell wrote:
> This isn't so much a list of misconceptions that recent students have as a list of misconceptions that security management have…
>
> On 15 Feb 2012, at 22:52, Rich Kulawiec wrote:
>
>> 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
>>
>

On 2012-02-16 14:51 , Mark Andrews wrote:
[..]
> that can occur. As IPv4 and IPv6 are often configured independently
> we provide a way to test each independently.

Could you make that label also for both IPv4/IPv6, that way, one could
figure out if the query ends up being answered over IPv4 or IPv6...
though then maybe the content would need to have a IPv4/IPv6 label in
it. Maybe it is even more useful to show the source of the querier?

Greets,
Jeroen

On Thu, Feb 16, 2012 at 08:27:14AM -0500, Jeff Kell wrote:
> On 2/16/2012 8:17 AM, Ray Soucy wrote:
> > I've found starting off with some history on Ethernet (Maine loves Bob
> > Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> > today is very different; starting with hubs, bridges, collisions, and
> > those problems, then introducing modern switching, VLANs, broadcast
> > domain's etc.
>
> It's a bit dated (1998) but I always thought Rich Siefert covered "the
> basics" very well...
> http://www.amazon.com/Gigabit-Ethernet-Technology-Applications-High-Speed/dp/0201185539

I like this free Juniper online training to introduce people to Layer 2 and
Layer 3 and how they interact:

https://learningportal.juniper.net/juniper/user_fasttrack_home.aspx

"Networking Fundamentals" eLearning course.

We run IS-IS at the University of Pennsylvania as the IGP for
IPv6. I know of a few other non-ISPs too but I won't speak for
them. At the time we initially deployed IPv6, it was pretty
much one of the few safe choices (OSPFv3 implementations were
very new then).

--Shumon.

On Thu, Feb 16, 2012 at 12:00:04AM -0600, Kenneth M. Chipps Ph.D. wrote:
> "ISIS is used in organizations other than ISPs" Any examples you can share
> of some other than ISPs?
>
> -----Original Message-----
> From: Joel jaeggli [mailto:joelja@bogus.com]
> Sent: Wednesday, February 15, 2012 11:58 PM
> To: Kenneth M. Chipps Ph.D.
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
> > How widespread would you say the use of IS-IS is?
> >
> > Even more as to which routing protocols are used, not just in ISPs,
> > what percent would you give to the various ones. In other words X
> > percent of organizations use OSPS, Y percent use EIGRP, and so on.
>
> Using EIGRP implies your routed IGP dependent infrastructure is a
> monoculture. That's probably infeasible without compromise even if you are
> largely a Cisco shop.
>
> ISIS is used in organizations other than ISPs.


--
Shumon Huque
University of Pennsylvania.

In message <20120216134437.GB65401@macbook.bluepipe.net>, Phil Regnauld writes:
> Mark Andrews (marka) writes:
> > If you want to know if your resolver talks IPv6 to the world and
> > supports 4096 EDNS UDP messages the following query will tell you.
> >
> > dig edns-v6-ok.isc.org txt
> >
> > Similarly for IPv4.
> >
> > dig edns-v4-ok.isc.org txt
> >
>
> 9.8.1P1 on a dual stacked native v6 host: I'm seeing TC on both answers,
> the difference is the TCP answer comes through on v4 but v6 gives SERVFAIL.

You will see TC between dig and the resolver. If you see TC between the resolver
and the server it will fail as neither server answers over TCP. If you are seeing
TC between the resolver and the server and the TCP query is being answers then
something in the path is intercepting the DNS queries.

> Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> them on this host).

You should see something like this on the wire. The second query is to answer
dig's query over TCP.

01:19:30.421959 IP6 2001:470:1f00:820:6965:eba7:eff6:1242.64345 > 2001:4f8:0:2::8.53: 44698% [1au] TXT? edns-v6-ok.isc.org. (47)
01:19:30.591828 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (0|1232) 53 > 64345: 44698*- 1/0/1 TXT[|domain]
01:19:30.592851 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (1232|1232)
01:19:30.593889 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (2464|1232)
01:19:30.593963 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (3696|408)
01:19:30.596552 IP6 2001:470:1f00:820:6965:eba7:eff6:1242.61500 > 2001:4f8:0:2::8.53: 60740% [1au] TXT? edns-v6-ok.isc.org. (47)
01:19:30.767351 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (0|1232) 53 > 61500: 60740*- 1/0/1 TXT[|domain]
01:19:30.768362 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (1232|1232)
01:19:30.769399 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (2464|1232)
01:19:30.769473 IP6 2001:4f8:0:2::8 > 2001:470:1f00:820:6965:eba7:eff6:1242: frag (3696|408)

> P.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

In message <4F3D0C45.9020100@unfix.org>, Jeroen Massar writes:
> On 2012-02-16 14:51 , Mark Andrews wrote:
> [..]
> > that can occur. As IPv4 and IPv6 are often configured independently
> > we provide a way to test each independently.
>
> Could you make that label also for both IPv4/IPv6, that way, one could
> figure out if the query ends up being answered over IPv4 or IPv6...
> though then maybe the content would need to have a IPv4/IPv6 label in
> it. Maybe it is even more useful to show the source of the querier?
>
> Greets,
> Jeroen

I don't really see much benefit in that other than satisfying
curiosity.

Also this is a stock stand server + firewall to block TCP. It would
require a custom server to sent back the source address and that
requires getting ops to run it. That's not to say that it can't
be done but it becomes more than a simple request.

Mark

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

Not understanding RFC1918 also gets my vote.
Don't call them "unroutable", ever.
I like it when I hear people say "if you type a net 10 address into a
router, it will reject it".
What do they think people do with those networks anyway?
Call them "private" or "RFC1918" networks/address spaces/ranges.

I don't know if it's really a common misconception, but worth underlining
to people, especially in these days of IPv4 kinkiness, the expectation of
global address uniqueness in the IP model. (Yes, NATs are probably here to
stay, but they corrupt the model in a number of ways and hacks result.)

Encourage people to use technically precise language.
When reporting or discussing problems, at the IP layer at least, always get
the answers to these questions:

- What is the source IP addresses (including external NAT IP if
applicable)?
- What is the destination IP address
- What is the application being used?
- What is the error message or behavior if any?
- Did this ever work and, if so, what date and time did it stop working?

Tony

On Wed, Feb 15, 2012 at 10:26 PM, Charles Mills <w3yni1@gmail.com> wrote:

> Not understanding RFC1918. Actually got read the riot act by someone
> because I worked for an organization that used 10.0.0.0/8 and that was
> "their" network and "they" owned it.
>
> Chuck
>
>

Borderline dns-ops, sorry folks! - but this is interesting
as we've been talking about ipv6 being operational, and this
is part of it...

Mark Andrews (marka) writes:
>
> If you are seeing TC between the resolver and the server and the TCP query is being answers then
> something in the path is intercepting the DNS queries.

TC is on the answer from the remote server to my resolver, so yeah, seems
like something is messing with the packets.

> > Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> > them on this host).
>
> You should see something like this on the wire. The second query is to answer
> dig's query over TCP.

I'm not seeing fragments as you are.

Here's what I see:

14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841 TXT? edns-v6-ok.isc.org. (36)
14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561: 52841*-| 0/0/0 (36)
14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS val 2571957531 ecr 0], length 0
14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags [R.], seq 0, ack 1112939463, win 0, length 0

Cheers,
Phil

On 2/16/2012 7:17 AM, Ray Soucy wrote:
> There seems to be (even among faculty) a gross misunderstanding of
> Layer-2. Nearly every textbook starts with IP, and talks about it as
> if we were 20 years in the past.

Understanding all layers and how they can interact stacked within layers
is a big issue. Granted, they aren't coming out of school, but I've seen
old Sonet/TDM guys trying to figure out transport of Ethernet and it has
been a nightmare on dealing with terminology.

It at first started with trying to explain that vlan based switching is
not Layer-3. :(

Use your imagination when they finally got into MPLS, which kindly takes
the OSI model like a flat piece of paper and wads it up.


Jack

On 02/16/12 05:17, Ray Soucy wrote:
> I've found starting off with some history on Ethernet (Maine loves Bob
> Metcalfe) becomes a very solid base for understanding; how "Ethernet"
> today is very different; starting with hubs, bridges, collisions, and
> those problems, then introducing modern switching, VLANs, broadcast
> domain's etc.

There was an old cruddy 1950s building on the UCB campus called Stanley
Hall. (Now there's a new, nice, modern building on the UCB campus
called Stanley Hall in place of the old one.) The old building had both
UCB net and Lawrence Berkeley Lab (LBNL) net running through it. The
LBNL net was fed from fiber using a 10base-FL-to-AUI repeater. The AUI
connected into the coax spine.

The cool thing is that the coax spine was provisioned exactly as you
would expect in an old ethernet textbook. The spine ran through the
hallway (usually just tied to a pipe, but sometimes with a J-hook) and
every 1.5 meters, there was a vampire tap and (usually) a transceiver
with an AUI cable connected to it that went into an office and dropped
down through the ceiling.

Amazingly, the UCB network was somewhat more modern. There were DEC
Delni MPTs (or "AUI hubs") coming off the UCB coax. There were even
some 10base-T hubs and concentrators that fed offices that had newer
cat-3 or even cat-5 wiring.

It was great to take students on tours through this operational museum.
(Well, the LBNL net was sort of operational. It would just stop
working for minutes on end and then come back mysteriously.) You could
basically see the first 10-15 years of the evolution of ethernet, and it
was installed and working.

The new Stanley is plumbed to the gills with cat-5e, gigabit switches,
and vlans all over the place. A modern LAN, yes, but no sense of history.

michael

I would say that the average University is more of an unusual ISP than a non-ISP.

Almost every University I know of has a networking group that functions like an ISP for the various departments of the college(s) as well as providing essentially residential ISP services to their
residence halls and in some cases fraternities, faculty housing, etc.

From a networking perspective they tend to operate much more like an ISP than an enterprise.

One of the key defining differences (IMHO) is that an enterprise (mostly) trusts the employees connected to its network whereas an ISP and a University cannot.

Owen

On Feb 16, 2012, at 6:08 AM, Shumon Huque wrote:

> We run IS-IS at the University of Pennsylvania as the IGP for
> IPv6. I know of a few other non-ISPs too but I won't speak for
> them. At the time we initially deployed IPv6, it was pretty
> much one of the few safe choices (OSPFv3 implementations were
> very new then).
>
> --Shumon.
>
> On Thu, Feb 16, 2012 at 12:00:04AM -0600, Kenneth M. Chipps Ph.D. wrote:
>> "ISIS is used in organizations other than ISPs" Any examples you can share
>> of some other than ISPs?
>>
>> -----Original Message-----
>> From: Joel jaeggli [mailto:joelja@bogus.com]
>> Sent: Wednesday, February 15, 2012 11:58 PM
>> To: Kenneth M. Chipps Ph.D.
>> Cc: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>
>> On 2/15/12 21:04 , Kenneth M. Chipps Ph.D. wrote:
>>> How widespread would you say the use of IS-IS is?
>>>
>>> Even more as to which routing protocols are used, not just in ISPs,
>>> what percent would you give to the various ones. In other words X
>>> percent of organizations use OSPS, Y percent use EIGRP, and so on.
>>
>> Using EIGRP implies your routed IGP dependent infrastructure is a
>> monoculture. That's probably infeasible without compromise even if you are
>> largely a Cisco shop.
>>
>> ISIS is used in organizations other than ISPs.
>
>
> --
> Shumon Huque
> University of Pennsylvania.

With telcos increasingly implementing Metro Ethernet Forum (MEF) networks, I have found that telco technicians tasked with maintaining and operating these carrier Ethernet networks appear to disregard common high availability practices. For instance, after diagnosing a routing protocol neighbor flap (consistently 20-30 seconds) and isolating the problem to the carrier MEF network, the carrier technician told me that the problem was a spanning tree convergence that took their primary and back-up links down during convergence, but that "this is no big deal because the network was only down for 20-30 seconds".

-----Original Message-----
From: John Kristoff [mailto:jtk@cymru.com]
Sent: Wednesday, February 15, 2012 12: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


This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.

In message <20120216165308.GE65401@macbook.bluepipe.net>, Phil Regnauld writes:
> Borderline dns-ops, sorry folks! - but this is interesting
> as we've been talking about ipv6 being operational, and this
> is part of it...
>
> Mark Andrews (marka) writes:
> >
> > If you are seeing TC between the resolver and the server and the TCP query is being answers then
> > something in the path is intercepting the DNS queries.
>
> TC is on the answer from the remote server to my resolver, so yeah, seems
> like something is messing with the packets.
>
> > > Don't see any v6 fragments (that'd be a problem since PF doesn't handle
> > > them on this host).
> >
> > You should see something like this on the wire. The second query is to answer
> > dig's query over TCP.
>
> I'm not seeing fragments as you are.
>
> Here's what I see:
>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841 TXT? edns-v6-ok.isc.org. (36)
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561: 52841*-| 0/0/0 (36)
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags [S], seq 1112939462, win 65535, optio
> ns [mss 1440,nop,wscale 6,sackOK,TS val 2571957531 ecr 0], length 0
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags [R.], seq 0, ack 1112939463, win 0, l
> ength 0

Which means you are seeing named in fallback mode, or have configured named to not take EDNS to
this server. In anycase your firewall is misconfigured/broken if it is blocking fragments.

> Cheers,
> Phil
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

I'm surprised I haven't seen QoS mentioned! If you're teaching college
students, you might want to go over stuff that directly relates to what
they're doing at home, or misconceptions they might make in a small
WAN/ISP environment.

*Why disabling ICMP doesn't increase security and only hurts the web* *(path
MTU discovery, diagnostics)
*How NAT breaks end-to-end connectivity (fun one..., took me hours to
explain to an old boss why doing NAT at the ISP level was horrendously
wrong)
*Not to be afraid of ACLs on an edge router. Understanding what
does/doesn't affect cpu utilization
*Layer 3 Switch vs Router. Old concepts like switch vs router need to be
clarified...
*When vendors and numbers lie ;) aka *oversubscription*!
*MAC is not security
*Irrelevant security concepts (smurf attacks, ping of death). More focus
should be on real modern day security concerns, like layer 7 exploits,
router software 0days, VLAN hopping, and UDP floods and BGP spoofing. This
might be a good place to explain why downloading IOS firmware from
thepiratebay is a bad idea :)

This is just coming from a sysadmin who likes to play with network gear and
once endured college networking classes.

Thanks!
Andreas


On Wed, Feb 15, 2012 at 1:47 PM, 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
>
>

Or more to the point, it is a misconception that traffic is
symetrical (the path out and the path back are the same) whereas in
the present network, symetrical paths are the exception rather than
the rule, especially as your radius increases.

On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
> traceroute shows _a_ path. Your packets might have taken a different
> path. (& the return traffic yet another)


---
Wayne Bouchard
web@typo.org
Network Dude
http://www.typo.org/~web/

On Thu, 16 Feb 2012, Wayne E Bouchard wrote:

> Or more to the point, it is a misconception that traffic is
> symetrical (the path out and the path back are the same) whereas in
> the present network, symetrical paths are the exception rather than
> the rule, especially as your radius increases.

To add to that, I feel pretty sure in stating that many of the people on
this list, at one point or another, have either had people tell them that
asymmetric routing is "bad", or have had to explain why asymmetric routing
across 'the Internet' is not "bad", even if it can make troubleshooting a
'network problem' somewhat more involved. The path from A to B is not
necessarily the same as the path from B to A.

jms

Alot of people are unclear on how hard it is for someone to sniff internet
traffic if the aren't physically located at or near one of the endpoints
IE: connected to the same access point or same switch.

2012/2/15 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
>
>
>

Seems like dig doesn't always advertise a big enough buffer, I was having
the same issue as you. If you set the buffer size on the command line it
works as directed.

Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
;; Truncated, retrying in TCP mode.
;; Connection to 149.20.64.58#53(149.20.64.58) for
edns-v4-ok.isc.orgfailed: connection refused.
Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096

; <<>> DiG 9.7.3-P3 <<>> edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;edns-v4-ok.isc.org. IN TXT

;; ANSWER SECTION:
edns-v4-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK"
"EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"
<snip>
"EDNS-4"

;; Query time: 176 msec
;; SERVER: 149.20.64.58#53(149.20.64.58)
;; WHEN: Fri Feb 17 10:22:08 2012
;; MSG SIZE rcvd: 4096




On 17 February 2012 05:53, Phil Regnauld <regnauld@nsrc.org> wrote:

> Borderline dns-ops, sorry folks! - but this is interesting
> as we've been talking about ipv6 being operational, and this
> is part of it...
>
> Mark Andrews (marka) writes:
> >
> > If you are seeing TC between the resolver and the server and the TCP
> query is being answers then
> > something in the path is intercepting the DNS queries.
>
> TC is on the answer from the remote server to my resolver, so
> yeah, seems
> like something is messing with the packets.
>
> > > Don't see any v6 fragments (that'd be a problem since PF doesn't
> handle
> > > them on this host).
> >
> > You should see something like this on the wire. The second query is to
> answer
> > dig's query over TCP.
>
> I'm not seeing fragments as you are.
>
> Here's what I see:
>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841
> TXT? edns-v6-ok.isc.org. (36)
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561:
> 52841*-| 0/0/0 (36)
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags
> [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
> val 2571957531 ecr 0], length 0
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags
> [R.], seq 0, ack 1112939463, win 0, length 0
>
> Cheers,
> Phil
>
>


--
Daniel Griggs
Network Operations
e: daniel@fx.net.nz
d: +64 4 4989567

Right, asymmetric paths are the norm for many inter-provider
communications.
A related misconception is that asymmetric paths are problematic.
Another mis-conception related to path is that more (visible) hops are bad
with the corollary that routers introduce (significant) latency.
Of course, propagation delay is the most significant contributor to latency
in WAN environments (or serialization delay for low-speed links).

Tony

On Thu, Feb 16, 2012 at 3:35 PM, Wayne E Bouchard <web@typo.org> wrote:

> Or more to the point, it is a misconception that traffic is
> symetrical (the path out and the path back are the same) whereas in
> the present network, symetrical paths are the exception rather than
> the rule, especially as your radius increases.
>
> On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
> > traceroute shows _a_ path. Your packets might have taken a different
> > path. (& the return traffic yet another)
>
>

In message <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg@mail.gmail.com>, Daniel Griggs writes:
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/plain; charset=ISO-8859-1
>
> Seems like dig doesn't always advertise a big enough buffer, I was having
> the same issue as you. If you set the buffer size on the command line it
> works as directed.

Well you were supposed to ask your recursive server, not ask the
authoritative server directly. We were talking about testing the
path from the recursive server (which you may not have log in access
to) to the authoritative server. If you want to ask the authoritative
server directly then +edns=0 or +dnssec or +bufsize=4096 or you can
use dig from BIND 9.9.0 which sets the ad flag and enables edns
(version 0) by default.

% dig edns-v6-ok.isc.org txt
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.7.3-P3 <<>> edns-v6-ok.isc.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;edns-v6-ok.isc.org. IN TXT

;; ANSWER SECTION:
edns-v6-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK" <snipped>

;; AUTHORITY SECTION:
edns-v6-ok.isc.org. 7199 IN NS edns-v6-ok.isc.org.

;; ADDITIONAL SECTION:
edns-v6-ok.isc.org. 7199 IN AAAA 2001:4f8:0:2::8

;; Query time: 174 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 17 09:36:37 2012
;; MSG SIZE rcvd: 4127

%


> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 149.20.64.58#53(149.20.64.58) for
> edns-v4-ok.isc.orgfailed: connection refused.
> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096
>
> ; <<>> DiG 9.7.3-P3 <<>> edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;edns-v4-ok.isc.org. IN TXT
>
> ;; ANSWER SECTION:
> edns-v4-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK"
> "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"
> <snip>
> "EDNS-4"
>
> ;; Query time: 176 msec
> ;; SERVER: 149.20.64.58#53(149.20.64.58)
> ;; WHEN: Fri Feb 17 10:22:08 2012
> ;; MSG SIZE rcvd: 4096
>
>
>
>
> On 17 February 2012 05:53, Phil Regnauld <regnauld@nsrc.org> wrote:
>
> > Borderline dns-ops, sorry folks! - but this is interesting
> > as we've been talking about ipv6 being operational, and this
> > is part of it...
> >
> > Mark Andrews (marka) writes:
> > >
> > > If you are seeing TC between the resolver and the server and the TCP
> > query is being answers then
> > > something in the path is intercepting the DNS queries.
> >
> > TC is on the answer from the remote server to my resolver, so
> > yeah, seems
> > like something is messing with the packets.
> >
> > > > Don't see any v6 fragments (that'd be a problem since PF doesn't
> > handle
> > > > them on this host).
> > >
> > > You should see something like this on the wire. The second query is to
> > answer
> > > dig's query over TCP.
> >
> > I'm not seeing fragments as you are.
> >
> > Here's what I see:
> >
> > 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841
> > TXT? edns-v6-ok.isc.org. (36)
> > 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561:
> > 52841*-| 0/0/0 (36)
> > 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags
> > [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
> > val 2571957531 ecr 0], length 0
> > 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags
> > [R.], seq 0, ack 1112939463, win 0, length 0
> >
> > Cheers,
> > Phil
> >
> >
>
>
> --
> Daniel Griggs
> Network Operations
> e: daniel@fx.net.nz
> d: +64 4 4989567
>
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <br>Seems like dig doesn&#39;t always advertise a big enough buffer, I was =
> having the same issue as you. If you set the buffer size on the command lin=
> e it works as directed.<br><br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"ht=
> tp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.=
> 20.64.58">149.20.64.58</a><br>
> ;; Truncated, retrying in TCP mode.<br>;; Connection to 149.20.64.58#53(149=
> .20.64.58) for <a href=3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>=
> failed: connection refused.<br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"h=
> ttp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149=
> .20.64.58">149.20.64.58</a> +bufsize=3D4096<br>
> <br>; &lt;&lt;&gt;&gt; DiG 9.7.3-P3 &lt;&lt;&gt;&gt; <a href=3D"http://edns=
> -v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.20.64.58"=
> >149.20.64.58</a> +bufsize=3D4096<br>;; global options: +cmd<br>;; Got answ=
> er:<br>
> ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 18209<br>;;=
> flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br>;; WA=
> RNING: recursion requested but not available<br><br>;; OPT PSEUDOSECTION:<b=
> r>
> ; EDNS: version: 0, flags:; udp: 4096<br>;; QUESTION SECTION:<br>;<a href=
> =3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 =A0=A0=A0 I=
> N=A0=A0=A0 TXT<br><br>;; ANSWER SECTION:<br><a href=3D"http://edns-v4-ok.is=
> c.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 0=A0=A0=A0 IN=A0=A0=A0 TXT=A0=A0=A0=
> &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot;=
> &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot;=
> <br>
> &lt;snip&gt;<br>&quot;EDNS-4&quot;<br><br>;; Query time: 176 msec<br>;; SER=
> VER: 149.20.64.58#53(149.20.64.58)<br>;; WHEN: Fri Feb 17 10:22:08 2012<br>=
> ;; MSG SIZE=A0 rcvd: 4096<br><br><br><br><br><div class=3D"gmail_quote">On =
> 17 February 2012 05:53, Phil Regnauld <span dir=3D"ltr">&lt;<a href=3D"mail=
> to:regnauld@nsrc.org">regnauld@nsrc.org</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"> =A0 =A0 =A0 =A0Borderline dns-ops, sorry fo=
> lks! - but this is interesting<br>
> =A0 =A0 =A0 =A0as we&#39;ve been talking about ipv6 being operational, and=
> this<br>
> =A0 =A0 =A0 =A0is part of it...<br>
> <div class=3D"im"><br>
> Mark Andrews (marka) writes:<br>
> &gt;<br>
> &gt; If you are seeing TC between the resolver and the server and the TCP q=
> uery is being answers then<br>
> &gt; something in the path is intercepting the DNS queries.<br>
> <br>
> </div> =A0 =A0 =A0 =A0TC is on the answer from the remote server to my reso=
> lver, so yeah, seems<br>
> =A0 =A0 =A0 =A0like something is messing with the packets.<br>
> <div class=3D"im"><br>
> &gt; &gt; =A0 =A0 Don&#39;t see any v6 fragments (that&#39;d be a problem s=
> ince PF doesn&#39;t handle<br>
> &gt; &gt; =A0 =A0 them on this host).<br>
> &gt;<br>
> &gt; You should see something like this on the wire. =A0The second query is=
> to answer<br>
> &gt; dig&#39;s query over TCP.<br>
> <br>
> </div> =A0 =A0 =A0 =A0I&#39;m not seeing fragments as you are.<br>
> <br>
> =A0 =A0 =A0 =A0Here&#39;s what I see:<br>
> <br>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 &gt; 2001:4f8:0:2::8.53: 5284=
> 1 TXT? <a href=3D"http://edns-v6-ok.isc.org" target=3D"_blank">edns-v6-ok.i=
> sc.org</a>. (36)<br>
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 &gt; 2001:2000:1080:d::2.64561: 5284=
> 1*-| 0/0/0 (36)<br>
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 &gt; 2001:4f8:0:2::8.53: Flag=
> s [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS =
> val 2571957531 ecr 0], length 0<br>
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 &gt; 2001:2000:1080:d::2.53262: Flag=
> s [R.], seq 0, ack 1112939463, win 0, length 0<br>
> <br>
> =A0 =A0 =A0 =A0Cheers,<br>
> =A0 =A0 =A0 =A0Phil<br>
> <br>
> </blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Griggs<br>Networ=
> k Operations<br>e: <a href=3D"mailto:daniel@fx.net.nz" target=3D"_blank">da=
> niel@fx.net.nz</a><br>d: +64 4 4989567<br>
>
> --001636c5b8ca93b4eb04b91b7066--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 02/15/12 23:34, Owen DeLong wrote:
> I think one of the most damaging fundamental misconceptions which is
> not only rampant among students, but, also enterprise IT professionals
> is the idea that NAT is a security tool and the inability to conceive of the
> separation between NAT (header mutilation) and Stateful Inspection
> (policy enforcement).

Another misconception is that RFC 1918 somehow
implies/specifies/requires NAT. The idea of using private address
without NATing them seems to totally bewilder some people. And they
often can't wrap their heads around the possibility of routing RFC 1918
space internally and also not using NAT. (This causes them to be even
more confused at the fact that RFC 4193 specifies ULA for IPv6, but
there is no stateful NAT currently specified.)

Concepts/words that often get confused:

Difference between 'allocation' and 'assignment' in IP addressing.

Use of the word "IP" alone to mean "IP address," e.g.:

Person: "Does that server have an IP assigned?"
Me: "Yeah, it's got a whole stack."

Then, of course, there's the silly situation where people mean to say
"rogue" but they type "rouge" as in "rouge DHCP server," "rouge RA
advertiser," etc.

michael

Andreas Echavez wrote:

> *Why disabling ICMP doesn't increase security and only hurts the web* *(path
> MTU discovery, diagnostics)

That PMTUD works is a misconception.

> *How NAT breaks end-to-end connectivity (fun one..., took me
> hours to explain to an old boss why doing NAT at the ISP level
> was horrendously wrong)

That's another misconception.

While NAT breaks the end to end connectivity, it can be
restored by end systems by reversing translations by NAT,
if proper information on the translations are obtained
through some protocol such as UPnP.

Masataka Ohta

2012/2/16 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
> Andreas Echavez wrote:
>> *How NAT breaks end-to-end connectivity (fun one..., took me
>>  hours to explain to an old boss why doing NAT at the ISP level
>>  was horrendously wrong)
>
> That's another misconception.
>
> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.
>
>                                        Masataka Ohta
>

UPnP can scale to about the size of an average home use, but it's
worth jack squat at the ISP level when NAT44 comes into play. UPnP is
not an ISP grade solution, it's a consumer one.

Josh Hoppes wrote:

>> While NAT breaks the end to end connectivity, it can be
>> restored by end systems by reversing translations by NAT,
>> if proper information on the translations are obtained
>> through some protocol such as UPnP.

> UPnP can scale to about the size of an average home use,

It depends on how you use UPnP and version of it.

E.g. security to control UPnP gateway is not a problem
if the gateway is configured statically.

> but it's
> worth jack squat at the ISP level when NAT44 comes into play.

NAT44 or 444 means you only need small scale UPnP cascaded.

> UPnP is
> not an ISP grade solution, it's a consumer one.

As I said "such as", PCP may be fine. But, recently, I found
several fundamental defects in it, some if which are already
corrected but the discussion is still continuing in its WG.

Masataka Ohta

On Fri, 17 Feb 2012 10:11:22 +0900, Masataka Ohta said:

> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.

You got a front end NAT. You got 3 boxes behind it that all
want to listen for inbound connections on port 49734.

Let me know how that works out for you.

Valdis.Kletnieks@vt.edu wrote:

>> While NAT breaks the end to end connectivity, it can be
>> restored by end systems by reversing translations by NAT,
>> if proper information on the translations are obtained
>> through some protocol such as UPnP.
>
> You got a front end NAT. You got 3 boxes behind it that all
> want to listen for inbound connections on port 49734.
>
> Let me know how that works out for you.

It's just like your box can't listen for inbound connections
at address 131.112.32.132 (address of my box).

However, if UPnP box is configured properly, your box behind
it can listen for inbound connections on some ports at some
public address.

Issues on stability and advertisements of the port numbers
are not very different from those of addresses, which may
be assigned by DHCP.

Masataka Ohta

End user devices will not benefit from end-to-end connectivity (e.g.,
globally routeable IPv4 addresses as opposed to being in a RFC1918
space behind NAT).

If I have a wildcard DNS record, *.example.edu AAAA 2001:db8::5, then
adding in an explicit record, x.example.edu AAAA 2001:db8::5, will
make no visible difference.

There is no legitimate reason for a user to use BitTorrent (someone
will probably disagree with this).

Our organization is not running out of IPv4 addresses so we don't need
IPv6. (Similarly: Our orginization is running out of IPv4 addresses so
that's why we need IPv6.)

I can't use IPv6 because I still need to serve IPv4 clients.

Any IP that starts with 192 is a private IP and any IP that starts
with 169 is a self-assigned.

Authentication by client IP address alone is sufficient.

Long passwords requiring letters, numbers, and symbols with a
no-repeat policy and a 90-day maximum password age are very secure.

+1 for "We should drop all ICMP(v6) traffic." (Related: "I can't ping
the box so it must be down.")

+1 for "NAT is security".

Regarding "DNS only uses UDP", I give out a technical test during
interviews and one of the questions is basically "Use iptables to
block incoming DNS traffic" and all applicants so far have only
blocked UDP port 53.

On Feb 16, 2012, at 5:11 PM, Masataka Ohta wrote:

> Andreas Echavez wrote:
>
>> *Why disabling ICMP doesn't increase security and only hurts the web* *(path
>> MTU discovery, diagnostics)
>
> That PMTUD works is a misconception.
>

It actually works where people have not made active efforts to break it.

>> *How NAT breaks end-to-end connectivity (fun one..., took me
>> hours to explain to an old boss why doing NAT at the ISP level
>> was horrendously wrong)
>
> That's another misconception.
>
> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.
>

Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.

Owen

On Fri, 17 Feb 2012 11:07:59 +0900, Masataka Ohta said:
> Valdis.Kletnieks@vt.edu wrote:
>
> >> While NAT breaks the end to end connectivity, it can be
> >> restored by end systems by reversing translations by NAT,
> >> if proper information on the translations are obtained
> >> through some protocol such as UPnP.
> >
> > You got a front end NAT. You got 3 boxes behind it that all
> > want to listen for inbound connections on port 49734.
> >
> > Let me know how that works out for you.
>
> It's just like your box can't listen for inbound connections
> at address 131.112.32.132 (address of my box).
>
> However, if UPnP box is configured properly, your box behind
> it can listen for inbound connections on some ports at some
> public address.

No, you said specifcially that it can be restored by end system*S*
plural. Yes, I can get one box listening. Now tell me how to get
the second and third boxes listening on the same port. If you can't
do that, then in fact, it is *not* possible to restore *full* end-to-end
connectivity.

> -----Original Message-----
> From: Owen DeLong
> Sent: Thursday, February 16, 2012 8:48 PM
> To: Masataka Ohta
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
>
> On Feb 16, 2012, at 5:11 PM, Masataka Ohta wrote:
>
> > Andreas Echavez wrote:
> >
> >> *Why disabling ICMP doesn't increase security and only hurts the
> web*
> >> *(path MTU discovery, diagnostics)
> >
> > That PMTUD works is a misconception.
> >
>
> It actually works where people have not made active efforts to break
> it.

Modern (RFC 4821) PMTUD that is used by default by Solaris and Microsoft does not require ICMP and works well. For Linux you have to enable it:

/proc/sys/net/ipv4/tcp_mtu_probing = 1 or 2 (I believe the default is still 0 which means it relies on ICMP for PMTUD by default and you must turn on RFC 4821 PMTUD). If you're relying on ICMP for PMTUD, still, then yeah, you probably run into problems from time to time but fewer stacks use that method of PMTUD these days.

Valdis.Kletnieks@vt.edu wrote:

> No, you said specifcially that it can be restored by end system*S*
> plural.

Yes, end to end connectivity is restored.

However, that end to end connectivity is restored does not
mean your boxes can use 131.112.32.132 nor port 49734.

> Yes, I can get one box listening. Now tell me how to get
> the second and third boxes listening on the same port.

Perhaps, you misunderstand how end systems behind NAT
must interact with UPnP or something like that to be
able to restore the end to end connectivity.

End systems behind UPnP boxes are allocated disjoint
sets of global port numbers, only among which, end
systems can use as their global port numbers.

End systems can obtain information on port numbers
they can use through UPnP or something like that.

Thus, there is no port number collision at the global
side of the UPnP box.

Similar mechanism is described in draft-ohta-e2e-nat-00.txt

Masataka Ohta

On Feb 16, 2012, at 18:08, Jack Bates wrote:

> It at first started with trying to explain that vlan based switching is not Layer-3. :(

Ah, one of the greatest misconceptions still around in 2012:

-- OSI Layer numbers mean something.
or
-- Somewhere in the sky, there is an exact definition of what is layer 2, layer 3, layer 4, layer 5 (!), layer 7
or
-- my definition is righter than yours

Grüße, Carsten

On Feb 16, 2012, at 23:41, Michael Sinatra wrote:

> Use of the word "IP" alone to mean "IP address," e.g.:
>
> Person: "Does that server have an IP assigned?"
> Me: "Yeah, it's got a whole stack."

Yeah, and
P: "Can you give me your email?"
M: "All 20 GB of it?"

Grüße, Carsten

I believe he understands just fine. However, his point (and I agree with him) is that
if you are behind NAT, it isn't full end-to-end functionality, even if it does allow some
degraded form of end-to-end connectivity with significant limitations which are not
present in the absence of NAT.

"I can't use your address" is inherent in the network.
"I can't use whatever port number I want on my side of the connection" is not.

Owen

On Feb 16, 2012, at 10:24 PM, Masataka Ohta wrote:

> Valdis.Kletnieks@vt.edu wrote:
>
>> No, you said specifcially that it can be restored by end system*S*
>> plural.
>
> Yes, end to end connectivity is restored.
>
> However, that end to end connectivity is restored does not
> mean your boxes can use 131.112.32.132 nor port 49734.
>
>> Yes, I can get one box listening. Now tell me how to get
>> the second and third boxes listening on the same port.
>
> Perhaps, you misunderstand how end systems behind NAT
> must interact with UPnP or something like that to be
> able to restore the end to end connectivity.
>
> End systems behind UPnP boxes are allocated disjoint
> sets of global port numbers, only among which, end
> systems can use as their global port numbers.
>
> End systems can obtain information on port numbers
> they can use through UPnP or something like that.
>
> Thus, there is no port number collision at the global
> side of the UPnP box.
>
> Similar mechanism is described in draft-ohta-e2e-nat-00.txt
>
> Masataka Ohta

On 2/16/2012 8:30 PM, Carsten Bormann wrote:
> On Feb 16, 2012, at 18:08, Jack Bates wrote:
>
>> It at first started with trying to explain that vlan based switching is not Layer-3. :(
> Ah, one of the greatest misconceptions still around in 2012:
>
> -- OSI Layer numbers mean something.
> or
> -- Somewhere in the sky, there is an exact definition of what is layer 2, layer 3, layer 4, layer 5 (!), layer 7
> or
> -- my definition is righter than yours
>
At the same time, it's shocking how many network people I come across
with no real grasp of even what OSI means by each layer, even if it's
only in theory. Just having a grasp of that makes all the world of
difference when it comes to troubleshooting. Start at layer 1 and work
upwards (unless you're able to make appropriate intuitive leaps.) Is it
physically connected? Are the link lights flashing? Can traffic route to
it, etc. etc.

Paul

George Bonser wrote:

> Modern (RFC 4821) PMTUD that is used by default by
> Solaris and Microsoft does not require ICMP and
> works well. For Linux you have to enable it:

It depends on how you define "work well".

As the RFC says:

indication of some significantly disruptive event in the network,
such as a router failure or a routing change to a path with a smaller
MTU.

it can not react against PMTU changes very well.

It is seemingly working well means there is not much PMTU
changes, which means we had better assumes some PMTU
(1280B, for example) and use it without PMTUD.

Masataka Ohta

Owen DeLong wrote:

> I believe he understands just fine. However, his point (and I agree with him) is that
> if you are behind NAT, it isn't full end-to-end functionality, even if it does allow some
> degraded form of end-to-end connectivity with significant limitations which are not
> present in the absence of NAT.

I'm not interested in your own definitions on end-to-end
something.

For correct terminologies, you should read Saltzer's
original paper.

As for "in the absence of NAT", RFC3102 may also be helpful
to you.

Abstract

This document examines the general framework of Realm Specific IP
(RSIP). RSIP is intended as a alternative to NAT in which the end-
to-end integrity of packets is maintained.

Masataka Ohta

On Feb 17, 2012, at 07:50, Paul Graydon wrote:

> what OSI means

Yet another common misconception popping up:

-- You can talk about the OSI model in the present tense

(That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
Just never expect OSI terms to have a precise meaning in today's networks.
1978 is now a third of a century ago...
If you need precision, you need to spell out what you mean in today's terms.)

Grüße, Carsten

In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
> At the same time, it's shocking how many network people I come across
> with no real grasp of even what OSI means by each layer, even if it's
> only in theory. Just having a grasp of that makes all the world of
> difference when it comes to troubleshooting. Start at layer 1 and work
> upwards (unless you're able to make appropriate intuitive leaps.) Is it
> physically connected? Are the link lights flashing? Can traffic route to
> it, etc. etc.

I wouldn't call it a "misconception", but I want to echo Paul's
comment. I would venture over 90% of the engineers I work with
have no idea how to troubleshoot properly. Thinking back to my own
education, I don't recall anyone in highschool or college attempting
to teach troubleshooting skills. Most classes teach you how to
build things, not deal with them when they are broken.

The basic skills are probably obvious to someone who might design
course material if they sat down and thought about how to teach
troubleshooting. However, there is one area that may not be obvious.
There's also a group management problem. Many times troubleshooting
is done with multiple folks on the phone (say, customer, ISP and
vendor). Not only do you have to know how to troubleshoot, but how
to get everyone on the same page so every possible cause isn't
tested 3 times.

I think all college level courses should include a "break/fix"
exercise/module after learning how to build something, and much of that
should be done in a group enviornment.

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

This list is awesome. Is anyone consolidating it? I'm still catching up
on the thread....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 1:05 AM, Carsten Bormann wrote:
> On Feb 17, 2012, at 07:50, Paul Graydon wrote:
>
>> what OSI means
> Yet another common misconception popping up:
>
> -- You can talk about the OSI model in the present tense
>
> (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
> It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
> Just never expect OSI terms to have a precise meaning in today's networks.
> 1978 is now a third of a century ago...
> If you need precision, you need to spell out what you mean in today's terms.)
>
> Grüße, Carsten
>
>
>

Actually I taught in a three year tech program for a while and although
trouble shooting was not in the curriculum, and as far as I know it
isn't anywhere, several of us adjunct faculty did teach it and got
reprimanded for it as part of our classes. So much for the education
industry understanding the needs of business. I taught basic PC
hardware and NT networking at the time. We would actually have the
students assemble a PC and then in a subsequent class bring up a
network. I got pretty good at nailing then with bugs while they were on
breaks. Heck, they had to go out to smoke. They would come back with a
network or PC that was no longer working. I would then have them
explain what they saw, what they thought was wrong, justify it BEFORE
they could take any corrective action. I also used some classroom
scenarios - they could ask me anything that they could physically learn
if they could tell me how they would check that. I let them run bad
rabbit trails if it looked like it would cement the right way. It
taught some step by step processes.

BTW, the best trouble shooting course I have ever taken was the Kepner
Trego Problem Analysis/Decision Analysis class. Caterpillar used it but
I have not seen it run anywhere in years. It is hard-nosed and may not
be glitzy enough for today. If you have a junior tech who isn't getting
there, I suggest - get their book and see if it helps. NO, I do not
sell them or have stock in the company and NO, it will not do any good
unless he reads it. I still use methodologies I learned in the class.


Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

-----Original Message-----
From: Leo Bicknell [mailto:bicknell@ufp.org]
Sent: Friday, February 17, 2012 9:29 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
> At the same time, it's shocking how many network people I come across
> with no real grasp of even what OSI means by each layer, even if it's
> only in theory. Just having a grasp of that makes all the world of
> difference when it comes to troubleshooting. Start at layer 1 and
work
> upwards (unless you're able to make appropriate intuitive leaps.) Is
it
> physically connected? Are the link lights flashing? Can traffic route
to
> it, etc. etc.

I wouldn't call it a "misconception", but I want to echo Paul's
comment. I would venture over 90% of the engineers I work with
have no idea how to troubleshoot properly. Thinking back to my own
education, I don't recall anyone in highschool or college attempting
to teach troubleshooting skills. Most classes teach you how to
build things, not deal with them when they are broken.

The basic skills are probably obvious to someone who might design
course material if they sat down and thought about how to teach
troubleshooting. However, there is one area that may not be obvious.
There's also a group management problem. Many times troubleshooting
is done with multiple folks on the phone (say, customer, ISP and
vendor). Not only do you have to know how to troubleshoot, but how
to get everyone on the same page so every possible cause isn't
tested 3 times.

I think all college level courses should include a "break/fix"
exercise/module after learning how to build something, and much of that
should be done in a group enviornment.

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

Let me simplify that. If you are over 35 you know how to troubleshoot.

Yes, I'm going to get flamed. Yes, there are exceptions in both directions.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 8:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and work
>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>> physically connected? Are the link lights flashing? Can traffic route to
>> it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with
> have no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to
> build things, not deal with them when they are broken.
>
> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how
> to get everyone on the same page so every possible cause isn't
> tested 3 times.
>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of that
> should be done in a group enviornment.
>

+1

Mario Eirea
________________________________________
From: Leo Bicknell [bicknell@ufp.org]
Sent: Friday, February 17, 2012 9:29 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
> At the same time, it's shocking how many network people I come across
> with no real grasp of even what OSI means by each layer, even if it's
> only in theory. Just having a grasp of that makes all the world of
> difference when it comes to troubleshooting. Start at layer 1 and work
> upwards (unless you're able to make appropriate intuitive leaps.) Is it
> physically connected? Are the link lights flashing? Can traffic route to
> it, etc. etc.

I wouldn't call it a "misconception", but I want to echo Paul's
comment. I would venture over 90% of the engineers I work with
have no idea how to troubleshoot properly. Thinking back to my own
education, I don't recall anyone in highschool or college attempting
to teach troubleshooting skills. Most classes teach you how to
build things, not deal with them when they are broken.

The basic skills are probably obvious to someone who might design
course material if they sat down and thought about how to teach
troubleshooting. However, there is one area that may not be obvious.
There's also a group management problem. Many times troubleshooting
is done with multiple folks on the phone (say, customer, ISP and
vendor). Not only do you have to know how to troubleshoot, but how
to get everyone on the same page so every possible cause isn't
tested 3 times.

I think all college level courses should include a "break/fix"
exercise/module after learning how to build something, and much of that
should be done in a group enviornment.

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

Hammer, you are at least 75% right. You will get flamed and in most
cases, the 35 year age is close to right.

But then in Programming where I spent most of my IT time since Feb 1963,
few current programmers have skills that they need to be really
successful. Same thing.

It is the fault of the educational system like one school district here
that teaches Alice, VB and then two days of C++ to High School Kids.
Heck, they will fiddle with Alice on their own. They need some exposure
to one of the SQL's and how to build some tables, maybe a good script
language, some command line on SQL+ and unix or PostgresSQL and linux if
the school can't afford the unix licenses.

The fun and games is more important than the substance and it goes into
the colleges in spades.

BTW, I am a school board member who votes 1:8 often on things.... But
let me give you a perspective, one of the board members called Golf an
"Essential Life Skill." Maybe, but how about balancing a checkbook...

Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055


-----Original Message-----
From: -Hammer- [mailto:bhmccie@gmail.com]
Sent: Friday, February 17, 2012 9:52 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

Let me simplify that. If you are over 35 you know how to troubleshoot.

Yes, I'm going to get flamed. Yes, there are exceptions in both
directions.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 8:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and
work
>> upwards (unless you're able to make appropriate intuitive leaps.) Is
it
>> physically connected? Are the link lights flashing? Can traffic route
to
>> it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with
> have no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to
> build things, not deal with them when they are broken.
>
> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how
> to get everyone on the same page so every possible cause isn't
> tested 3 times.
>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of
that
> should be done in a group enviornment.
>

Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.

A short example, probably not the best but the one that comes to mind right now:

Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.

I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.

Mario Eirea
________________________________________
From: -Hammer- [bhmccie@gmail.com]
Sent: Friday, February 17, 2012 9:52 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

Let me simplify that. If you are over 35 you know how to troubleshoot.

Yes, I'm going to get flamed. Yes, there are exceptions in both directions.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 8:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and work
>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>> physically connected? Are the link lights flashing? Can traffic route to
>> it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with
> have no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to
> build things, not deal with them when they are broken.
>
> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how
> to get everyone on the same page so every possible cause isn't
> tested 3 times.
>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of that
> should be done in a group enviornment.
>

On 2/17/2012 1:05 AM, Carsten Bormann wrote:
> On Feb 17, 2012, at 07:50, Paul Graydon wrote:
>
>> what OSI means
>
> Yet another common misconception popping up:
>
> -- You can talk about the OSI model in the present tense
>
> (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
> It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
> Just never expect OSI terms to have a precise meaning in today's networks.
> 1978 is now a third of a century ago...
> If you need precision, you need to spell out what you mean in today's terms.)
>

Actually, I find it makes a perfect troubleshooting guideline in today's
world; at least up to layer 4. I'm not saying it's a perfect match to
troubleshooting a variety of MPLS problems, but it is a reminder that
there are dependencies which must be checked.

In dealing with transport companies, the model is still a good
representation of their service levels. It isn't uncommon to find their
products defined as layer 2 services (ranging from tdm/sonet services to
ethernet switching services), layer 3 services (often handled by their
ISP department), and MPLS services (which can range from p2p transport
to l3vpn).

Which brings up my final point. Until we quit naming things l2vpn or
l3vpn, OSI still applies. :P


Jack

I agree with this 100%.

Having worked with many people over the last 40 years, the good trouble shooters understood how things
were suppose to work. This helps immeasurably in determining where to start looking.

On 02/17/2012 10:12 AM, Mario Eirea wrote:
> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>
> A short example, probably not the best but the one that comes to mind right now:
>
> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>
> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>
> Mario Eirea
> ________________________________________
> From: -Hammer- [bhmccie@gmail.com]
> Sent: Friday, February 17, 2012 9:52 AM
> To: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory. Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>> physically connected? Are the link lights flashing? Can traffic route to
>>> it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment. I would venture over 90% of the engineers I work with
>> have no idea how to troubleshoot properly. Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills. Most classes teach you how to
>> build things, not deal with them when they are broken.
>>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting. However, there is one area that may not be obvious.
>> There's also a group management problem. Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor). Not only do you have to know how to troubleshoot, but how
>> to get everyone on the same page so every possible cause isn't
>> tested 3 times.
>>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of that
>> should be done in a group enviornment.
>>
>
>


--
Stephen Clark
*NetWolves*
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark@netwolves.com
http://www.netwolves.com

>From: Owen DeLong owen@delong.com

>Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.

I understand why you say that - NAT did yeoman's work in address conservation.  However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model.  Some of these approaches have found their way into business proceses. 

An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!" 

To this, the response "so what?" is not unreasonable - organizations which have built up processes and products around the non-end-to-end model may or may not see a benefit in changing their ways.  Asserting that there is something wrong with existing, succesful business practices is not, by itself, compelling. 

While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which it's normal operations.  The more NAT for v6 gets fought, the more folks will fight to preserve it.  Time could be better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance for non-NAT-based solutions to those various groups.

David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com

----- Original Message -----
> From: "Ridwan Sami" <rms2176@columbia.edu>

> There is no legitimate reason for a user to use BitTorrent (someone
> will probably disagree with this).

Yeah, no.

You've clearly never tried to download a Linux installer DVD.

Cheers,
-- jr 'among dozens of other legitimate uses' a
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:

> This list is awesome. Is anyone consolidating it? I'm still catching up on the thread....


I was thinking of making a checklist out of it.

- Jared

>> There is no legitimate reason for a user to use BitTorrent (someone
>> will probably disagree with this).

There is no democratic basis -for- copy"right", so far for "legitimate".

Well said. An American tragedy.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:01 AM, Brandt, Ralph wrote:
> Hammer, you are at least 75% right. You will get flamed and in most
> cases, the 35 year age is close to right.
>
> But then in Programming where I spent most of my IT time since Feb 1963,
> few current programmers have skills that they need to be really
> successful. Same thing.
>
> It is the fault of the educational system like one school district here
> that teaches Alice, VB and then two days of C++ to High School Kids.
> Heck, they will fiddle with Alice on their own. They need some exposure
> to one of the SQL's and how to build some tables, maybe a good script
> language, some command line on SQL+ and unix or PostgresSQL and linux if
> the school can't afford the unix licenses.
>
> The fun and games is more important than the substance and it goes into
> the colleges in spades.
>
> BTW, I am a school board member who votes 1:8 often on things.... But
> let me give you a perspective, one of the board members called Golf an
> "Essential Life Skill." Maybe, but how about balancing a checkbook...
>
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services
> Telephone +1 717.506.0802
> FAX +1 717.506.4358
> Email Ralph.Brandt@pateam.com
> 5095 Ritter Rd
> Mechanicsburg PA 17055
>
>
> -----Original Message-----
> From: -Hammer- [mailto:bhmccie@gmail.com]
> Sent: Friday, February 17, 2012 9:52 AM
> To: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both
> directions.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
> Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory. Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting. Start at layer 1 and
> work
>>> upwards (unless you're able to make appropriate intuitive leaps.) Is
> it
>>> physically connected? Are the link lights flashing? Can traffic route
> to
>>> it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment. I would venture over 90% of the engineers I work with
>> have no idea how to troubleshoot properly. Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills. Most classes teach you how to
>> build things, not deal with them when they are broken.
>>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting. However, there is one area that may not be obvious.
>> There's also a group management problem. Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor). Not only do you have to know how to troubleshoot, but how
>> to get everyone on the same page so every possible cause isn't
>> tested 3 times.
>>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of
> that
>> should be done in a group enviornment.
>>
>

On 2/17/2012 9:18 AM, Steve Clark wrote:
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

Ran into this not too long ago with a transport problem. The behavior I
was seeing was indicative of the transport not stripping their outer
tag. They put wireshark on a windows laptop and sent me the traffic
captures. While I didn't know that M$ decided to do something silly like
removing a single tag, all indicators were that the M$ stack "fixed"
whatever was broken prior to wireshark. We took a capture from another
device and proved the problem.

Which is a common transport problem I often see, "Our configuration
looks right, it must be on your end."


Jack

Mario,
I was kinda having fun and kinda not. My point is that the 40-50
year olds that were doing this 30 years ago grew up understanding things
in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those
confused). Hex. etc. Move on to the OSI model and it's the same thing.
Voltage. Amplitude. Binary. etc. I think that this generation that I'm
referring to is a great generation because we were at the beginning of
the Internet blooming. There are folks on this forum that go back
further. Into DARPA. Before DARPA was just chapter 1 one every single
Cisco Press book. They have a unique understanding of the layers. I had
that understanding in my 20s. The technology is so complicated these
days that many folks miss those fundamentals and go right into VSS on
the 6500s or MPLS over Juniper. In the end, it all comes in time.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:12 AM, Mario Eirea wrote:
> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>
> A short example, probably not the best but the one that comes to mind right now:
>
> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>
> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>
> Mario Eirea
> ________________________________________
> From: -Hammer- [bhmccie@gmail.com]
> Sent: Friday, February 17, 2012 9:52 AM
> To: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory. Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>> physically connected? Are the link lights flashing? Can traffic route to
>>> it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment. I would venture over 90% of the engineers I work with
>> have no idea how to troubleshoot properly. Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills. Most classes teach you how to
>> build things, not deal with them when they are broken.
>>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting. However, there is one area that may not be obvious.
>> There's also a group management problem. Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor). Not only do you have to know how to troubleshoot, but how
>> to get everyone on the same page so every possible cause isn't
>> tested 3 times.
>>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of that
>> should be done in a group enviornment.
>>
>

If you do, please share it. Thank you.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:36 AM, Jared Mauch wrote:
> On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:
>
>> This list is awesome. Is anyone consolidating it? I'm still catching up on the thread....
>
> I was thinking of making a checklist out of it.
>
> - Jared

Original poster who started thread said he would.

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- <bhmccie@gmail.com> wrote:

> If you do, please share it. Thank you.
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:36 AM, Jared Mauch wrote:
>
>> On Feb 17, 2012, at 9:29 AM, -Hammer- wrote:
>>
>> This list is awesome. Is anyone consolidating it? I'm still catching up
>>> on the thread....
>>>
>>
>> I was thinking of making a checklist out of it.
>>
>> - Jared
>>
>
>

On Fri, 17 Feb 2012 08:29:42 -0600
-Hammer- <bhmccie@gmail.com> wrote:

> This list is awesome. Is anyone consolidating it? I'm still catching
> up on the thread....

I'm collecting all responses, many of which have been sent to me off
list. I was waiting for the thread to eventually end before
summarizing it. Thanks everyone.

John

On 2/17/2012 10:04 AM, John Kristoff wrote:
> I was waiting for the thread to eventually end

Greatest misconception of all.


Jack

>
> It depends on how you define "work well".
>
> As the RFC says:
>
> indication of some significantly disruptive event in the network,
> such as a router failure or a routing change to a path with a
> smaller
> MTU.
>
> it can not react against PMTU changes very well.
>
> It is seemingly working well means there is not much PMTU changes,
> which means we had better assumes some PMTU (1280B, for example) and
> use it without PMTUD.
>
> Masataka Ohta

It depends on the OS and the method being used. If you set the option to "2" on Linux, it will do MTU probing constantly and react to MTU changes. Also, the MTU for a given path only "lives" for 5 minutes anyway (by default) and is "rediscovered" with Linux. (value in /proc/sys/net/ipv4/route/mtu_expires) but other operating systems may behave in other ways.

I agree that if one tries hard enough, they can ensure a broken path and there are always people who seem to devote a lot of energy to that end. There's nothing that can be done about them but there is much the OS can try to do to defeat them at their task.

I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times)

I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-)

Mario Eirea

________________________________________
From: -Hammer- [bhmccie@gmail.com]
Sent: Friday, February 17, 2012 10:51 AM
To: Mario Eirea
Cc: nanog@nanog.org
Subject: Re: Common operational misconceptions

Mario,
I was kinda having fun and kinda not. My point is that the 40-50
year olds that were doing this 30 years ago grew up understanding things
in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those
confused). Hex. etc. Move on to the OSI model and it's the same thing.
Voltage. Amplitude. Binary. etc. I think that this generation that I'm
referring to is a great generation because we were at the beginning of
the Internet blooming. There are folks on this forum that go back
further. Into DARPA. Before DARPA was just chapter 1 one every single
Cisco Press book. They have a unique understanding of the layers. I had
that understanding in my 20s. The technology is so complicated these
days that many folks miss those fundamentals and go right into VSS on
the 6500s or MPLS over Juniper. In the end, it all comes in time.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 9:12 AM, Mario Eirea wrote:
> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>
> A short example, probably not the best but the one that comes to mind right now:
>
> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>
> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>
> Mario Eirea
> ________________________________________
> From: -Hammer- [bhmccie@gmail.com]
> Sent: Friday, February 17, 2012 9:52 AM
> To: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory. Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>> physically connected? Are the link lights flashing? Can traffic route to
>>> it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment. I would venture over 90% of the engineers I work with
>> have no idea how to troubleshoot properly. Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills. Most classes teach you how to
>> build things, not deal with them when they are broken.
>>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting. However, there is one area that may not be obvious.
>> There's also a group management problem. Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor). Not only do you have to know how to troubleshoot, but how
>> to get everyone on the same page so every possible cause isn't
>> tested 3 times.
>>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of that
>> should be done in a group enviornment.
>>
>

On 2/17/2012 10:18 AM, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good
> trouble shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

This is dead on and why I always start classes with a refresher on the
OSI model. While the model isn't perfect it lets technicians and
engineers construct a reasonable model of how things *ought* to be
working. While you certainly will run into devices that bend or even
break the rules (sometimes for good reasons) its much easier to
understand the exceptions if you know the normal operation for a
repeater, bridge, or router.

--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On Fri, Feb 17, 2012 at 10:33:12AM -0500, Jay Ashworth wrote:
> ----- Original Message -----
> > From: "Ridwan Sami" <rms2176@columbia.edu>
>
> > There is no legitimate reason for a user to use BitTorrent (someone
> > will probably disagree with this).
>
> Yeah, no.
>
> You've clearly never tried to download a Linux installer DVD.

Nevermind that Bram Cohen is preparing to tackle TV with a
BitTorrent-related protocol (no further details known yet).

Sent from my iPhone

On Feb 17, 2012, at 7:48, Jack Bates <jbates@brightok.net> wrote:

>
>
> On 2/17/2012 9:18 AM, Steve Clark wrote:
>> Having worked with many people over the last 40 years, the good trouble
>> shooters understood how things
>> were suppose to work. This helps immeasurably in determining where to
>> start looking.
>>
>
> Ran into this not too long ago with a transport problem. The behavior I was seeing was indicative of the transport not stripping their outer tag. They put wireshark on a windows laptop and sent me the traffic captures. While I didn't know that M$ decided to do something silly like removing a single tag, all indicators were that the M$ stack "fixed" whatever was broken prior to wireshark. We took a capture from another device and proved the problem.
>
> Which is a common transport problem I often see, "Our configuration looks right, it must be on your end."
>
>
> Jack
>


If i had a dollar for everytime i've heard that from a telco, i'd be a
rich man...

On Fri, Feb 17, 2012 at 06:52, -Hammer- <bhmccie@gmail.com> wrote:
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.

"Necessity is the mother of invention"

Long before there was a Grainger (and Home Depot) in
every city, and you could get parts shipped overnight,
one had to "make do", and "making do" meant being
able to figure things out to be able to "git r done"
with what you had on hand, or could figure out.

When working on my Grandfather's farm, I did not
look for work to do (actually, I looked for ways
not to do any work :-), but if the project required
pulling out the oxy-acetylene torch to cut and
weld something onto the tractor to get something
done, that is what you had to do, so you did it.
If the TV went on the blink (they all did then),
you opened up the back, looked for fried
components, and if one of the resistors was
smoking, you soldered in a replacement. Or
you took the tubes down to the local drugstore
and tested them. Even if you had no idea what
you were doing, you were willing (and expected)
to give it a shot, and try to fix it. More often
than not you learned something along the way,
even if it took hours to figure it out (and had to
repair your repair a few times :-). For those
without the capabilities, you took it to the shop,
where someone else did the troubleshooting
and repair.

Along the line, the costs of technicians to
do that type of work started to exceed the
cost of simply replacing the entire unit
(how many people remember when going
to the auto dealer that the cost of the parts
far exceeded the cost of the labor? Now it
is the other way around). Troubleshooting
became a lost art. "Swap 'til you drop"
became the mantra. It became the cost
effective way to do repairs.

There are advantages to the new way of
disposable devices, but almost no one
knows how they work anymore, and they
do not care to know. The members of this
list are likely to be sufficiently self selected
to be in the minority of actually wanting to
know.

There is a (small) backlash of people who
are trying to get back into the world of
actually building things, and understanding
how they work (popularized by such things
as Make magazine, and Maker Faires).

Gary

On Fri, Feb 17, 2012 at 08:46:02AM -0800, Mike Lyon wrote:
> Sent from my iPhone
>
> On Feb 17, 2012, at 7:48, Jack Bates <jbates@brightok.net> wrote:
>
> >
> >
> > On 2/17/2012 9:18 AM, Steve Clark wrote:
> >> Having worked with many people over the last 40 years, the good trouble
> >> shooters understood how things
> >> were suppose to work. This helps immeasurably in determining where to
> >> start looking.
> >>
> >
> > Ran into this not too long ago with a transport problem. The behavior I was seeing was indicative of the transport not stripping their outer tag. They put wireshark on a windows laptop and sent me the traffic captures. While I didn't know that M$ decided to do something silly like removing a single tag, all indicators were that the M$ stack "fixed" whatever was broken prior to wireshark. We took a capture from another device and proved the problem.
> >
> > Which is a common transport problem I often see, "Our configuration looks right, it must be on your end."
>
> If i had a dollar for everytime i've heard that from a telco, i'd be a
> rich man...

That and "I'm getting a good ping response here" while I've got the cable
at my end unplugged from the equipment.

--
Mike Andrews, W5EGO
mikea@mikea.ath.cx
Tired old sysadmin

I often struggle with the concept of teaching someone how to
troubleshoot. We have young guys coming in all the time and it is
often an area in which they need to hone their skills. I found this
article a while back and I keep it bookmarked, its the best article
I've seen that lays it all out pretty clearly.

http://packetlife.net/blog/2010/mar/10/the-science-of-network-troubleshooting/

-Marcel

I'm guessing, but I believe the author would fall into the under 35 category ;-)

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- <bhmccie@gmail.com> wrote:
> Mario,
>    I was kinda having fun and kinda not. My point is that the 40-50 year
> olds that were doing this 30 years ago grew up understanding things in
> order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those
> confused). Hex. etc. Move on to the OSI model and it's the same thing.
> Voltage. Amplitude. Binary. etc. I think that this generation that I'm
> referring to is a great generation because we were at the beginning of the
> Internet blooming. There are folks on this forum that go back further. Into
> DARPA. Before DARPA was just chapter 1 one every single Cisco Press book.
> They have a unique understanding of the layers. I had that understanding in
> my 20s. The technology is so complicated these days that many folks miss
> those fundamentals and go right into VSS on the 6500s or MPLS over Juniper.
> In the end, it all comes in time.
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:12 AM, Mario Eirea wrote:
>>
>> Well, I will argue this. I think the important factor in any
>> troubleshooting is having a real understanding of how the system works. That
>> is, how different things interact with each others to achieve a specific
>> goal. The biggest problem I see is that many people understand understand
>> the individual parts but when it comes to understanding the system as a
>> whole they fall miserably short.
>>
>> A short example, probably not the best but the one that comes to mind
>> right now:
>>
>> Someone replaces a device on the network with a new one. They give it the
>> same IP address as the old device. They don't understand why the router cant
>> communicate with it at first and then starts working. The people
>> "understand" ARP, but cant correlate one event with another.
>>
>> I guess if your 35 you have seen this at least once and can fix it. But
>> what happens if you have never seen this problem or a related one? At this
>> point your going to have to really troubleshoot, not just go on experience.
>>
>> Mario Eirea
>> ________________________________________
>> From: -Hammer- [bhmccie@gmail.com]
>> Sent: Friday, February 17, 2012 9:52 AM
>> To: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>
>> Yes, I'm going to get flamed. Yes, there are exceptions in both
>> directions.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>>
>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
>>> Graydon wrote:
>>>>
>>>> At the same time, it's shocking how many network people I come across
>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>> only in theory.  Just having a grasp of that makes all the world of
>>>> difference when it comes to troubleshooting.  Start at layer 1 and work
>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>> physically connected? Are the link lights flashing? Can traffic route to
>>>> it, etc. etc.
>>>
>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>> comment.  I would venture over 90% of the engineers I work with
>>> have no idea how to troubleshoot properly.  Thinking back to my own
>>> education, I don't recall anyone in highschool or college attempting
>>> to teach troubleshooting skills.  Most classes teach you how to
>>> build things, not deal with them when they are broken.
>>>
>>> The basic skills are probably obvious to someone who might design
>>> course material if they sat down and thought about how to teach
>>> troubleshooting.  However, there is one area that may not be obvious.
>>> There's also a group management problem.  Many times troubleshooting
>>> is done with multiple folks on the phone (say, customer, ISP and
>>> vendor).  Not only do you have to know how to troubleshoot, but how
>>> to get everyone on the same page so every possible cause isn't
>>> tested 3 times.
>>>
>>> I think all college level courses should include a "break/fix"
>>> exercise/module after learning how to build something, and much of that
>>> should be done in a group enviornment.
>>>
>>
>

wasn't tv already tackled by dvb-iptv + multicast (oh wait, multicast,
that stuff that hardly ever globally works on ipv4 ;)

(yes, i'm that old that i even know what a tv was ;)

On Fri, 17 Feb 2012, Eugen Leitl wrote:

> On Fri, Feb 17, 2012 at 10:33:12AM -0500, Jay Ashworth wrote:
>> ----- Original Message -----
>>> From: "Ridwan Sami" <rms2176@columbia.edu>
>>
>>> There is no legitimate reason for a user to use BitTorrent (someone
>>> will probably disagree with this).
>>
>> Yeah, no.
>>
>> You've clearly never tried to download a Linux installer DVD.
>
> Nevermind that Bram Cohen is preparing to tackle TV with a
> BitTorrent-related protocol (no further details known yet).
>

>
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with have no
> idea how to troubleshoot properly. Thinking back to my own education,
> I don't recall anyone in highschool or college attempting to teach
> troubleshooting skills. Most classes teach you how to build things,
> not deal with them when they are broken.

Look for people who grew up on a farm. They are used to figuring out how to fix things they haven't seen before and generally attempt to gain knowledge of the fundamental principles of how things work so they can apply those principles in a similar situation. For example, such a person may know enough about troubleshooting both gasoline and diesel engines and might have a better understanding of the underlying fundamentals of internal combustion engines to do a passable job troubleshooting something they have never seen before (air, fuel, timing). There is a certain APPROACH to troubleshooting that transcends various fields. Some naturally have a talent for it, others aren't so good at it. Such people might be better in a multi-vendor network when there is a problem. You can generally spot those people not by what they know, but by the quality of the questions they ask. They generally know what they want to accomplish or what they are looking for, but they might want to know how that is done with this particular vendor's command set or how this particular vendor processes traffic.

Some are natural designers, some are natural troubleshooters, some are natural documenters/support staff and they LIKE doing it. It takes all of those skills.

One important thing to keep in mind, too, is that by identifying the skills and natural talents of your line staff, you yourself are being a value multiplier to your organization. You are making best use of the resources that you have at your disposal and are improving the efficiency of the organization as an organic entity. So this benefits everyone in the entire organization, including you.

On Fri, Feb 17, 2012 at 10:18:57AM -0500, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to start
> looking.

Don't forget that a lot of the best figure things out *while*
troubleshooting things they don't (yet) understand.

Give curious people good tools and interesting problems -- the rest will
sort itself out.

Mark Grigsby <mark@pcinw.net> writes:

> Speaking in the context of configuring an ipsec tunnel..

Once upon a time:

Admin: "We need Port 50 and Port 51 for the tunnel!"
Me: "You mean IP protocol 50 and 51?"
Admin: "It the same! You have no clue!"

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------

> BTW, I am a school board member who votes 1:8 often on things.... But
> let me give you a perspective, one of the board members called Golf an
> "Essential Life Skill." Maybe, but how about balancing a checkbook...
>
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services

One of the best courses I ever had was in 9th grade math class when Mr. Martin taught us how to do taxes. And I mean even long forms with all the schedules and stuff for people who had investments and small sole proprietor businesses. It was a great practical math application, though it was mostly just arithmetic, some of the example cases were quite complex with estimated taxes, carrying forward losses from previous years, depreciation, etc. It gave us some context in which we could understand why we might need to learn math in real life and made taxes less daunting when we got older. Thanks, Mr. Martin!

Mathias Wolkert <tias@netnod.se> writes:

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

Autoneg is black magic. Doesn't work. You have manually configure duplex
and speed on one side !!!!1!

SCNR

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------

On Fri, 17 Feb 2012, Jens Link wrote:

> Mathias Wolkert <tias@netnod.se> writes:
>
>> 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.

you are referring to ehh *kuch* certain internet exchanges *kuch* ? :P

auto mdi/mii breaks teh internets! oeh noes! (not on any equipment we've
owned for the past 15 years... funny how that works ;)

>
> Autoneg is black magic. Doesn't work. You have manually configure duplex
> and speed on one side !!!!1!
>
> SCNR
>
> Jens
> --
> -------------------------------------------------------------------------
> | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
> | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
> -------------------------------------------------------------------------
>

On Feb 17, 2012, at 11:33 AM, John Osmon wrote:

On Fri, Feb 17, 2012 at 10:18:57AM -0500, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to start
> looking.

Don't forget that a lot of the best figure things out *while*
troubleshooting things they don't (yet) understand.

Give curious people good tools and interesting problems -- the rest will
sort itself out.

Quote I have hear over the years


"Problems are opportunities for learning - Just wish I was not doing so much learning some days...."

> Long before there was a Grainger (and Home Depot) in every city, and
> you could get parts shipped overnight, one had to "make do", and
> "making do" meant being able to figure things out to be able to "git r
> done"
> with what you had on hand, or could figure out.
>
> When working on my Grandfather's farm, I did not look for work to do
> (actually, I looked for ways not to do any work :-), but if the project
> required pulling out the oxy-acetylene torch to cut and weld something
> onto the tractor to get something done, that is what you had to do, so
> you did it.

Yep, when looking for troubleshooters, look for people that grew up/worked on a farm.

I absolutely agree. They approach things from a completely different mindset.

On 2/17/2012 12:00 PM, Gary Buhrmaster wrote:
> If the TV went on the blink (they all did then), you opened up the
> back, looked for fried components, and if one of the resistors was
> smoking, you soldered in a replacement. Or you took the tubes down to
> the local drugstore and tested them.

Wow... would be handy if Radio Shack stocked router modules and blades,
and chassis to test your suspect ones? :)

(Yes, remember the tube testers as well...)

Jeff

I am grateful you have not used the hardware I have in the past 15 years.

I haven't seen anything recently not do it, but when interfacing with a customer who knows what old stuff they may be using.

Jared Mauch

On Feb 17, 2012, at 12:41 PM, Sven Olaf Kamphuis <sven@cb3rob.net> wrote:

> auto mdi/mii breaks teh internets! oeh noes! (not on any equipment we've owned for the past 15 years... funny how that works ;)

>
> Wow... would be handy if Radio Shack stocked router modules and
> blades,
> and chassis to test your suspect ones? :)
>
> (Yes, remember the tube testers as well...)
>
> Jeff

Heh, that's been a notion I have had for a while. Opening an all-night shop somewhere in Silicon Valley that sold patch cords, memory sticks, disk drives, maybe even common router blades, optics modules, fans, etc. Sell it for a bit more margin than the going rate for the "day" shops and ONLY be open at night/early morning, say 7pm to 11am. Maybe do some "remote hands" work, too.

Fry's wanted $55 for a 1 meter LC-LC multi-mode patch cord yesterday at the store on Arques in Sunnyvale.

In a message written on Fri, Feb 17, 2012 at 06:06:52PM +0000, George Bonser wrote:
> Heh, that's been a notion I have had for a while. Opening an all-night shop somewhere in Silicon Valley that sold patch cords, memory sticks, disk drives, maybe even common router blades, optics modules, fans, etc. Sell it for a bit more margin than the going rate for the "day" shops and ONLY be open at night/early morning, say 7pm to 11am. Maybe do some "remote hands" work, too.

I've repeatedly asked $BIG_COLO_PROVIDERS to offer a vending machine
in the lobby next to the one with sodas that sold Cat 5, Fiber,
SFP's, USB sticks, and so on. Even at a moderate margin I suspect it
would be quite profitable to them, and quite welcomed by customers who
show up in the middle of the night when nothing is open and need parts.

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

----- Original Message -----
> From: "Mike Andrews" <mikea@mikea.ath.cx>

> > > Which is a common transport problem I often see, "Our
> > > configuration looks right, it must be on your end."
> >
> > If i had a dollar for everytime i've heard that from a telco, i'd be
> > a rich man...
>
> That and "I'm getting a good ping response here" while I've got the
> cable at my end unplugged from the equipment.

"The problem's leaving here fine!"

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

To find counterfeit they teach you what good money looks like. When you
are looking at a sniffer trace you are generally looking for something
that is not right.



Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

-----Original Message-----
From: Scott Helms [mailto:khelms@ispalliance.net]
Sent: Friday, February 17, 2012 11:24 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

On 2/17/2012 10:18 AM, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good
> trouble shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

This is dead on and why I always start classes with a refresher on the
OSI model. While the model isn't perfect it lets technicians and
engineers construct a reasonable model of how things *ought* to be
working. While you certainly will run into devices that bend or even
break the rules (sometimes for good reasons) its much easier to
understand the exceptions if you know the normal operation for a
repeater, bridge, or router.

--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------

On 02/17/2012 04:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and work
>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>> physically connected? Are the link lights flashing? Can traffic route to
>> it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with
> have no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to
> build things, not deal with them when they are broken.
The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
troubleshooting. Not sure if they still do, or if trainers even bother
to mention it (mine did back when I did it several years ago)

> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how
> to get everyone on the same page so every possible cause isn't
> tested 3 times.
Never trust what you can't prove yourself, that includes vendors and
customers. Every now and then I forget this and find hours later that
I've wasted a whole bunch of time because I trusted when someone said
something that it actually was the case. It's really often better to
test something a third time even if Vendor and Customer tell you
something is a particular way.

>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of that
> should be done in a group enviornment.
>
Definitely. I've learnt more in my time from breaking things than I've
ever learnt setting them up; however the education system is focused on
breadth of knowledge, not depth. Students are expected to be able to
regurgitate ridiculous amounts of facts and figures, so that they pass
standardised tests, not understand how to actually use them.

Paul

Leo Bicknell <bicknell@ufp.org> writes:

> I've repeatedly asked $BIG_COLO_PROVIDERS to offer a vending machine
> in the lobby next to the one with sodas that sold Cat 5, Fiber,
> SFP's, USB sticks, and so on.

Hmm.....

http://gearomat.com/

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------

On Feb 17, 2012, at 6:52 AM, -Hammer- wrote:

> Let me simplify that. If you are over 35 you know how to troubleshoot.
>

Is this a statement or something to be added to the list of misconceptions that are commonplace out there?

Not trying to be flip... Honestly asking the question. I can see it going either way, frankly. ;-)

Owen

Exactly right. They have some much information floating around in their
heads many of them cannot fit it together. But once they get on the job, all
of those little synapses rapidly connect, and then the light comes on.

Higher education is just like drivers education. You did not learn to drive
in drivers education. You learned how to drive by driving. Higher education
gives you the foundation on which to learn.

-----Original Message-----
From: Paul Graydon [mailto:paul@paulgraydon.co.uk]
Sent: Friday, February 17, 2012 12:33 PM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

On 02/17/2012 04:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and
>> work upwards (unless you're able to make appropriate intuitive
>> leaps.) Is it physically connected? Are the link lights flashing? Can
>> traffic route to it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with have
> no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to build
> things, not deal with them when they are broken.
The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
troubleshooting. Not sure if they still do, or if trainers even bother to
mention it (mine did back when I did it several years ago)

> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how to
> get everyone on the same page so every possible cause isn't tested 3
> times.
Never trust what you can't prove yourself, that includes vendors and
customers. Every now and then I forget this and find hours later that I've
wasted a whole bunch of time because I trusted when someone said something
that it actually was the case. It's really often better to test something a
third time even if Vendor and Customer tell you something is a particular
way.

>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of
> that should be done in a group enviornment.
>
Definitely. I've learnt more in my time from breaking things than I've ever
learnt setting them up; however the education system is focused on breadth
of knowledge, not depth. Students are expected to be able to regurgitate
ridiculous amounts of facts and figures, so that they pass standardised
tests, not understand how to actually use them.

Paul

On Feb 17, 2012, at 7:20 AM, David Barak wrote:

>> From: Owen DeLong owen@delong.com
>
>> Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.
>
> I understand why you say that - NAT did yeoman's work in address conservation. However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model. Some of these approaches have found their way into business proceses.
>
Yes... An unfortunate and very damaging side effect to be sure.

> An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!"
>
> To this, the response "so what?" is not unreasonable - organizations which have built up processes and products around the non-end-to-end model may or may not see a benefit in changing their ways. Asserting that there is something wrong with existing, succesful business practices is not, by itself, compelling.
>

People who make money selling weapons don't necessarily see a benefit to peace. People who avoid the high costs of toxic waste disposal by putting it into ground water don't necessarily see a benefit to having an EPA or laws that prohibit doing so.

If you're not party to the war and you're not one of the people whose water supply is affected by the toxins flowing into it, then, the response "so what?" may seem reasonable from your perspective.

NAT is much the same way. It is a form of toxic pollutant that has damaging effects outside of the business that has chosen to deploy NAT. At best, it started out as a necessary evil for address conservation. Dependence on it beyond that seems to me to be akin to a form of drug addiction.

> While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which it's normal operations. The more NAT for v6 gets fought, the more folks will fight to preserve it. Time could be better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance for non-NAT-based solutions to those various groups.
>

And I do exactly that when presented with actual use cases where people believe NAT is needed.

You can find several instances of my having done that in previous NANOG threads.

Owen

Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p

Owen
(Who grew up on a PDP-11 in his high-school and still remembers 1777300 and its significance to anyone who has used a larger PDP system)

On Feb 17, 2012, at 7:51 AM, -Hammer- wrote:

> Mario,
> I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it all comes in time.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:12 AM, Mario Eirea wrote:
>> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>>
>> A short example, probably not the best but the one that comes to mind right now:
>>
>> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>>
>> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>>
>> Mario Eirea
>> ________________________________________
>> From: -Hammer- [bhmccie@gmail.com]
>> Sent: Friday, February 17, 2012 9:52 AM
>> To: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>
>> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>>> At the same time, it's shocking how many network people I come across
>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>> only in theory. Just having a grasp of that makes all the world of
>>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>> physically connected? Are the link lights flashing? Can traffic route to
>>>> it, etc. etc.
>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>> comment. I would venture over 90% of the engineers I work with
>>> have no idea how to troubleshoot properly. Thinking back to my own
>>> education, I don't recall anyone in highschool or college attempting
>>> to teach troubleshooting skills. Most classes teach you how to
>>> build things, not deal with them when they are broken.
>>>
>>> The basic skills are probably obvious to someone who might design
>>> course material if they sat down and thought about how to teach
>>> troubleshooting. However, there is one area that may not be obvious.
>>> There's also a group management problem. Many times troubleshooting
>>> is done with multiple folks on the phone (say, customer, ISP and
>>> vendor). Not only do you have to know how to troubleshoot, but how
>>> to get everyone on the same page so every possible cause isn't
>>> tested 3 times.
>>>
>>> I think all college level courses should include a "break/fix"
>>> exercise/module after learning how to build something, and much of that
>>> should be done in a group enviornment.
>>>
>>

This reminds me of what I think is the biggest root misconception of the 20th and 21st centuries:

Rapid step-by-step training can replace conceptual education on the fundamentals.

In other words, we have moved from the old-school of teaching people why things work and how they work to a newer school of teaching people how to complete specific tasks. This has had the following negative effects, IMHO:

1. When the only tool you have is a hammer, you try to mold every problem into a nail.
2. When you only know a procedure for doing something and don't understand the fundamentals
of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
and hope everything works this time.
3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.

I once worked with a director of QA that epitomized this. It was a small company, so, as director, he was directly responsible for most of the tasks in the QA lab. He was meticulous in following directions which was a good thing. However, when he reached a step where he did not get the expected result, he was limited to telling the engineers that the test failed at step X and would not make any effort to identify or resolve the problem and would literally block the entire QA process waiting for engineering to resolve the issue before he would continue testing. Worse, he would not test independent pieces of the system in parallel, so, when he blocked on one system failing, he wouldn't test the others, either. Further investigation revealed that this was because he didn't actually know which systems were or were not dependent on each other. He was so completely immersed in the procedural school of thought that he was literally unwilling to accept conceptual knowledge or develop an understanding of the theory and principles of operation of any of the systems.

Owen

On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote:

> I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times)
>
> I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-)
>
> Mario Eirea
>

On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
> Now, come on... If you're in the 40-50 range, you should have put octal
> before hex. :p

IBM S/360 definitely preferred hex. And EBCDIC.

I give I give. I should have. But I left a bunch of stuff out and the
folks that I'm referring to know it. One of the fun things I do with
network guys is ask them about canonical bit ordering across routers.
Always causes the room to go quiet. Them someone of the appropriate age
group will speak up after he's done laughing.

The best thing I have ever figured out to tell less experienced (I
didn't say younger) folks is to start at the bottom of the stack and
work your way up. That's the way many of us troubleshoot. Is the cable
on the floor? That's bad. If not, is the ARP entry incomplete? That's
bad. If not, is the route missing? That's bad. If not, can you reach the
route? Try this radical command that was invented by Steve Jobs while
working on his first IPhone (They won't know who Vint Cerf or anyone
else is and by using Steves name they will trust you)(I run Android):
telnet 1.2.3.4 1433
What? It answered? So the SQL service is running? Then it ain't the
network dude....
So many times people don't pick up on that. But when they do, it's like
a light bulb went off and they see the world differently. Like
subnetting....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 12:49 PM, Owen DeLong wrote:
> Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p
>
> Owen
> (Who grew up on a PDP-11 in his high-school and still remembers 1777300 and its significance to anyone who has used a larger PDP system)
>
> On Feb 17, 2012, at 7:51 AM, -Hammer- wrote:
>
>> Mario,
>> I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it all comes in time.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 9:12 AM, Mario Eirea wrote:
>>> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>>>
>>> A short example, probably not the best but the one that comes to mind right now:
>>>
>>> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>>>
>>> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>>>
>>> Mario Eirea
>>> ________________________________________
>>> From: -Hammer- [bhmccie@gmail.com]
>>> Sent: Friday, February 17, 2012 9:52 AM
>>> To: nanog@nanog.org
>>> Subject: Re: Common operational misconceptions
>>>
>>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>>
>>> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>>>
>>> -Hammer-
>>>
>>> "I was a normal American nerd"
>>> -Jack Herer
>>>
>>>
>>>
>>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>>>> At the same time, it's shocking how many network people I come across
>>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>>> only in theory. Just having a grasp of that makes all the world of
>>>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>>> physically connected? Are the link lights flashing? Can traffic route to
>>>>> it, etc. etc.
>>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>>> comment. I would venture over 90% of the engineers I work with
>>>> have no idea how to troubleshoot properly. Thinking back to my own
>>>> education, I don't recall anyone in highschool or college attempting
>>>> to teach troubleshooting skills. Most classes teach you how to
>>>> build things, not deal with them when they are broken.
>>>>
>>>> The basic skills are probably obvious to someone who might design
>>>> course material if they sat down and thought about how to teach
>>>> troubleshooting. However, there is one area that may not be obvious.
>>>> There's also a group management problem. Many times troubleshooting
>>>> is done with multiple folks on the phone (say, customer, ISP and
>>>> vendor). Not only do you have to know how to troubleshoot, but how
>>>> to get everyone on the same page so every possible cause isn't
>>>> tested 3 times.
>>>>
>>>> I think all college level courses should include a "break/fix"
>>>> exercise/module after learning how to build something, and much of that
>>>> should be done in a group enviornment.
>>>>
>

Well put and great example Owen.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 12:59 PM, Owen DeLong wrote:
> This reminds me of what I think is the biggest root misconception of the 20th and 21st centuries:
>
> Rapid step-by-step training can replace conceptual education on the fundamentals.
>
> In other words, we have moved from the old-school of teaching people why things work and how they work to a newer school of teaching people how to complete specific tasks. This has had the following negative effects, IMHO:
>
> 1. When the only tool you have is a hammer, you try to mold every problem into a nail.
> 2. When you only know a procedure for doing something and don't understand the fundamentals
> of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
> are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
> and hope everything works this time.
> 3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.
>
> I once worked with a director of QA that epitomized this. It was a small company, so, as director, he was directly responsible for most of the tasks in the QA lab. He was meticulous in following directions which was a good thing. However, when he reached a step where he did not get the expected result, he was limited to telling the engineers that the test failed at step X and would not make any effort to identify or resolve the problem and would literally block the entire QA process waiting for engineering to resolve the issue before he would continue testing. Worse, he would not test independent pieces of the system in parallel, so, when he blocked on one system failing, he wouldn't test the others, either. Further investigation revealed that this was because he didn't actually know which systems were or were not dependent on each other. He was so completely immersed in the procedural school of thought that he was literally unwilling to accept conceptual knowledge or develop an understanding of the theory and principles of operation of any of the systems.
>
> Owen
>
> On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote:
>
>> I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times)
>>
>> I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-)
>>
>> Mario Eirea
>>
>

I find a lot of new folks have a hard time with the difference in
port numbers and protocol numbers.

I just went through this with a CC<something-more-than NA>, but with
virtually no hands-on experience a few minutes ago. Very disturbing
when a person can take the higher level tests, but still can't
understand the basics. All they do is use the certification testing
programs and memorize everything they can. :-(


grrr....
scott

> From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Fri Feb 17 13:11:28 2012
> To: Owen DeLong <owen@delong.com>
> Subject: Re: Common operational misconceptions
> From: Valdis.Kletnieks@vt.edu
> Date: Fri, 17 Feb 2012 14:04:45 -0500
> Cc: "nanog@nanog.org" <nanog@nanog.org>
>
> On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
> > Now, come on... If you're in the 40-50 range, you should have put octal
> > before hex. :p
>
> IBM S/360 definitely preferred hex. And EBCDIC.

And the _real_ number crunchers used ones-complement arithmetic. Which led to
to mahines that couldn't add -- they did addition by 'complement and subtract'.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2/17/12 11:04 AM, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 17 Feb 2012 10:49:13 PST, Owen DeLong said:
>> Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p
>
> IBM S/360 definitely preferred hex. And EBCDIC.
>

GCOS - 36 bits and Octal and BCD (ASCII added later)
DEC 10 and 20 - 36 bits and Octal
PDP-8 - Octal

- --tep

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREDAAYFAk8+qEEACgkQPu53fhcIEuBr9gCfU46kCDPbmgSVQGAw5nnOsrNO
hJ4AnRpr4Ig46x5JZlcK+kL43JGFcbCS
=cSWb
-----END PGP SIGNATURE-----

Owen DeLong <owen@delong.com> writes:

> 1. When the only tool you have is a hammer, you try to mold every problem into a nail.

Ack.

> 2. When you only know a procedure for doing something and don't understand the fundamentals
> of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
> are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
> and hope everything works this time.

But procedures are important. How else can you get enough exper^Widiots
working for little money. "Big Macs vs. The Naked Chef" is great:

http://www.joelonsoftware.com/articles/fog0000000024.html


> 3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.

There are no problems! Can't be. And if there are they hire external
experts. BTDT. Those are well paid jobs.

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------

> missing? That's bad. If not, can you reach the route? Try this radical
> command that was invented by Steve Jobs while working on his first IPhone
> (They won't know who Vint Cerf or anyone else is and by using Steves name
> they will trust you)(I run Android):
> telnet 1.2.3.4 1433
> What? It answered? So the SQL service is running? Then it ain't the network
> dude....

steve jobs knew how to operate a computer?

the guy that renamed apple computer to "apple" :P

i thought he just knew how to come up with overheating cases and shiney
designs to put -around- the computers (well until the chips fell out of
their sockets due to the heat or they caught fire :P they had woz for the
computer stuff remember :P

the guy that first turned a perfectly open computer platform
manufacturer capable of keeping the ibm pc out of the market
for many decades to come into a gadget for the managers desk,
and then came back to turn a unix workstation manufacturer into an
electronics toys (iphones) company.

the question is: where would apple have been all those years, if steve
jobs wasn't around to screw it up every time :P

(and where are the BMCs in their mac-mini "servers" ;)

2 video chips.. but no bmc..hmm.