Mailing List Archive

1 2 3 4 5 6 7 8 9  View All
Re: Common operational misconceptions [ In reply to ]
"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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
>
>
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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/
Re: Common operational misconceptions [ In reply to ]
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.
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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 :)
Re: Common operational misconceptions [ In reply to ]
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.
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
>>
>
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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.
Re: Common operational misconceptions [ In reply to ]
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.
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
>
>
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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
Re: Common operational misconceptions [ In reply to ]
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.
RE: Common operational misconceptions [ In reply to ]
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.
Re: Common operational misconceptions [ In reply to ]
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

1 2 3 4 5 6 7 8 9  View All