Re: Common operational misconceptions
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
Re: Common operational misconceptions
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
Re: SSL Certificates
On Wed, Feb 15, 2012 at 6:49 PM, George Herbert wrote: > On Wed, Feb 15, 2012 at 4:17 PM, John Levine wrote: > The problem with anything related to Verisign at the moment is that > The possibility of their root certs being compromised is nonzero. The possibility of _ANY_ CA's root certs having been compromised is non-zero. There's no evidence published to indicate Verisign's CA key has been compromised, and it's highly unlikely. Just as there's no evidence of other CAs' root certificate keys being compromised. > There may be no problem; they also may be completely worthless. Until > there's full disclosure... [snip] They are not completely worthless until revoked, or distrusted by web browsers. There is a risk that any CA issued SSL certificate signed by _any_ CA may be worthless some time in the future, if the CA chosen is later found to have issued sufficient quantities fraudulent certificates, and sufficiently failed in their duties. I suppose if you buy a SSL certificate, you should be looking for your CA to have insurance to reimburse the cost of the certificate should that happen, and an ironclad "refund" clause in the agreement/contract under which a SSL cert is issued E.g. A guarantee such that the CA will refund the complete certification fee, or pay for the replacement of the SSL certificate with a new valid certificate issued by another fully trusted CA, and compensate for any tangible loss,resulting from the CA's signing certificate being marked as untrusted by major browsers, revoked, or removed from major browsers' trust list, due to any failure on the CA's part or compromise of their systems, resulting in loss of trust. -- -JH
Re: Wireless Recommendations
On Wed, Feb 15, 2012 at 8:41 PM, Joel jaeggli wrote: > On 2/15/12 20:14 , Mario Eirea wrote: >> This is my guess too, i guess there is some bleed over from their antenna >> arrays. > > Even the most directional sector antenna in the world has a back lobe... > and there there's the clients... Agreed. There is rarely a thing as a perfectly-directional antenna (not without a lot of shielding, I would presume). Since I would presume that all the radios are controlled by the same host, perhaps it could coordinate the 802.11 DCF and sequence CTS frames so that the various client and AP radios remain as spectrally orthogonal as possible. There's not much you can do about the clients transmitting RTSes, but it can be predicted to a certain extent. > there's no magic bullet you simply can't do it all in one ap with the > space available. Agreed. More, lower-power APs means better spectral efficiency and overall resilience. --j
Re: SSL Certificates
On Thu, Feb 16, 2012 at 12:17:00AM -, John Levine wrote: > >Almost everyone are basically just selling an "activation" with one of the > >SSL certificate authorities. > > > >I usually buy a "RapidSSL" (Verisign) certificate from > >https://www.sslmatrix.com/ -- they seem to have some of the best > >prices and the rapidssl enrollment process is very efficient (at least for > >the cheap automatically "validated" > >products). > > I get my RapidSSL and Comodo from these guys. Prices look about the same: > > http://www.cheapssls.com/ > > If you order a cert for example.com, Comodo's also work for www.example.com, > no > extra charge. > > R's, > John > Comodo ever get "fixed" ?? /bill
Re: Common operational misconceptions
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. 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:joe...@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.ristim...@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 > >> > > > > > > > > > > > > > > > > >
Re: Common operational misconceptions
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
RE: Common operational misconceptions
"ISIS is used in organizations other than ISPs" Any examples you can share of some other than ISPs? -Original Message- From: Joel jaeggli [mailto:joe...@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.ristim...@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 >> > > > > > >
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.ristim...@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 >> > > > > > >
and now for something completely different
Control of ground-state pluripotency by allelic regulation of Nanog Nature advance online publication 12 February 2012. doi:10.1038/nature10807 Authors: Yusuke Miyanari & Maria-Elena Torres-Padilla Pluripotency is established through genome-wide reprogramming during mammalian pre-implantation development, resulting in the formation of the naive epiblast. Reprogramming involves both the resetting of epigenetic marks and the activation of pluripotent-cell-specific genes such as Nanog and Oct4 (also known as Pou5f1). The tight regulation of these genes is crucial for reprogramming, but the mechanisms that regulate their expression in vivo have not been uncovered. Here we show that Nanog—but not Oct4—is monoallelically expressed in early pre-implantation embryos. Nanog then undergoes a progressive switch to biallelic expression during the transition towards ground-state pluripotency in the naive epiblast of the late blastocyst. Embryonic stem (ES) cells grown in leukaemia inhibitory factor (LIF) and serum express Nanog mainly monoallelically and show asynchronous replication of the Nanog locus, a feature of monoallelically expressed genes, but ES cells activate both alleles when cultured under 2i conditions, which mimic the pluripotent ground state in vitro. Live-cell imaging with reporter ES cells confirmed the allelic expression of Nanog and revealed allelic switching. The allelic expression of Nanog is regulated through the fibroblast growth factor–extracellular signal-regulated kinase signalling pathway, and it is accompanied by chromatin changes at the proximal promoter but occurs independently of DNA methylation. Nanog-heterozygous blastocysts have fewer inner-cell-mass derivatives and delayed primitive endoderm formation, indicating a role for the biallelic expression of Nanog in the timely maturation of the inner cell mass into a fully reprogrammed pluripotent epiblast. We suggest that the tight regulation of Nanog dose at the chromosome level is necessary for the acquisition of ground-state pluripotency during development. Our data highlight an unexpected role for allelic expression in controlling the dose of pluripotency factors in vivo, adding an extra level to the regulation of reprogramming.
RE: Common operational misconceptions
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.ristim...@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 >
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
Re: Common operational misconceptions
On 2012.02.15 22:12, Mark Andrews wrote: In message<4f3c6703.4050...@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
Re: Wireless Recommendations
On 2/15/12 20:14 , Mario Eirea wrote: > This is my guess too, i guess there is some bleed over from their antenna > arrays. Even the most directional sector antenna in the world has a back lobe... and there there's the clients... there's no magic bullet you simply can't do it all in one ap with the space available. > Mario Eirea > IT Department > Charter School IT > 20803 Johnson Street > Pembroke Pines, FL 33029 > Ph: 954-435-7827 > Cell: 305-742-6524 > Fax: 954-442-1762 > > From: Jonathan Lassoff [j...@thejof.com] > Sent: Wednesday, February 15, 2012 10:54 PM > To: fai...@snappydsl.net > Cc: nanog@nanog.org > Subject: Re: Wireless Recommendations > > On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz wrote: >> Is that because of Channel Spacing ? or some other reason ? > > I would presume channel spacing. In FCC-land, there are only 3 > non-overlapping 20 Mhz bandwidths available. > > --j > > >
Re: Common operational misconceptions
In message <4f3c76d5.9040...@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: ma...@isc.org
RE: Wireless Recommendations
This is my guess too, i guess there is some bleed over from their antenna arrays. Mario Eirea IT Department Charter School IT 20803 Johnson Street Pembroke Pines, FL 33029 Ph: 954-435-7827 Cell: 305-742-6524 Fax: 954-442-1762 From: Jonathan Lassoff [j...@thejof.com] Sent: Wednesday, February 15, 2012 10:54 PM To: fai...@snappydsl.net Cc: nanog@nanog.org Subject: Re: Wireless Recommendations On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz wrote: > Is that because of Channel Spacing ? or some other reason ? I would presume channel spacing. In FCC-land, there are only 3 non-overlapping 20 Mhz bandwidths available. --j
802.11 MAC Point Coordination Function
Hi All, I'm doing some research on 802.11 quality of service, congestion control, etc. I'm trying to find some information on the Point Coordination Function, a polling based access control method, but I'm having a hard time finding much in the way of vendor support. I have access to some cisco 1242's, 1140's and 1252's and I've been searching the Cisco's site and can't find a real answer on whether or not it's supported let alone how to configure it. Does anyone have any experience with this? Does Cisco have some special name for it aside from PCF? Any help would be appreciated! Thanks, Jeremy
Re: Wireless Recommendations
On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz wrote: > Is that because of Channel Spacing ? or some other reason ? I would presume channel spacing. In FCC-land, there are only 3 non-overlapping 20 Mhz bandwidths available. --j
Re: Wireless Recommendations
Is that because of Channel Spacing ? or some other reason ? Regards. Faisal Imtiaz Snappy Internet& Telecom 7266 SW 48 Street Miami, Fl 33155 Tel: 305 663 5518 x 232 Helpdesk: 305 663 5518 option 2 Email: supp...@snappydsl.net On 2/15/2012 7:00 PM, Mario Eirea wrote: Just be careful with Xirrus. A little known secret is that only 3 of those radios can be running in the 2.4ghz band at any time. Mario Eirea IT Department Charter School IT 20803 Johnson Street Pembroke Pines, FL 33029 Ph: 954-435-7827 Cell: 305-742-6524 Fax: 954-442-1762 From: Jonathan Lassoff [j...@thejof.com] Sent: Tuesday, February 07, 2012 2:50 PM To: Arzhel Younsi Cc: Mario Eirea; nanog@nanog.org Subject: Re: Wireless Recommendations On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi wrote: Xirrus say that they can support 640 clients with this device: http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series I heard about it a couple weeks ago, didn't try it yet. That's a pretty neat product -- it seems like it takes care of spectrally isolating clients by utilizing 4 - 8 radios per AP-box and 8 - 24 directional sector antennas. I feel like this addresses the suggestions that I and others gave to utilize more APs rather than a big central one, but it just packages it all into one box with many antennas. Cheers, jof
Re: Common operational misconceptions
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 > 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 > >
Re: Common operational misconceptions
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
Re: Common operational misconceptions
In message <4f3c6703.4050...@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: ma...@isc.org
Re: Anonymous planning a root-servers party
On 2/15/2012 2:40 PM, Grant Ridder wrote: I really don't think Anonymous is dumb enough to forget about anycast. Given their track record, it does seem advisable to take the threat seriously, whatever taking it seriously might mean... If i remember right, another group tried to take down the root servers within the past 5 or 6 years and only took out around 20 or 25. Some discussions about that I recall guessed that it was an experimental probe, for learning how to do a better attack. (Remember that 9/11 was a revision of a prior attack on the towers.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 5:49 PM, Carsten Bormann 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
Re: Common operational misconceptions
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
Re: Common operational misconceptions
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
Re: Common operational misconceptions
I whole-heartedly agree with that last one. -Grant On Wed, Feb 15, 2012 at 8:07 PM, Mario Eirea 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" 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
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" 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 message <4f3c2e47.80...@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: ma...@isc.org
Re: Common operational misconceptions
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
Re: Common operational misconceptions
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.
RE: Common operational misconceptions
> IPv6 is operational. How is this a misconception? It works fine for me... Nathan
Re: SSL Certificates
On Wed, Feb 15, 2012 at 4:17 PM, John Levine wrote: >>Almost everyone are basically just selling an "activation" with one of the >>SSL certificate authorities. >> >>I usually buy a "RapidSSL" (Verisign) certificate from >>https://www.sslmatrix.com/ -- they seem to have some of the best >>prices and the rapidssl enrollment process is very efficient (at least for >>the cheap automatically "validated" >>products). > > I get my RapidSSL and Comodo from these guys. Prices look about the same: > > http://www.cheapssls.com/ > > If you order a cert for example.com, Comodo's also work for www.example.com, > no > extra charge. The problem with anything related to Verisign at the moment is that they either don't know or haven't come clean yet how far the hackers got into their infrastructure over the last few years. The early February 2012 announcements were woefully devoid of actual content. The possibility of their root certs being compromised is nonzero. There may be no problem; they also may be completely worthless. Until there's full disclosure... -- -george william herbert george.herb...@gmail.com
Re: Common operational misconceptions
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
Re: Common operational misconceptions
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.
Re: Common operational misconceptions
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
Re: Common operational misconceptions
PKI is cryptographically secure. IDN is internationalized. IPv6 reduces router load by not allowing fragmentation. IPv6 is operational. Masataka Ohta
Re: SSL Certificates
>Almost everyone are basically just selling an "activation" with one of the SSL >certificate authorities. > >I usually buy a "RapidSSL" (Verisign) certificate from >https://www.sslmatrix.com/ -- they seem to have some of the best >prices and the rapidssl enrollment process is very efficient (at least for the >cheap automatically "validated" >products). I get my RapidSSL and Comodo from these guys. Prices look about the same: http://www.cheapssls.com/ If you order a cert for example.com, Comodo's also work for www.example.com, no extra charge. R's, John
Re: Common operational misconceptions
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 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: Anonymous planning a root-servers party
Mark Andrews wrote: > Or just slave the root zone. 1 million root servers is more robust > than the hundred or so we have today Good, I was serious to have said "not thousands but millions of" servers when I proposed anycast root servers. > and given the root is signed > you can verify the answers returned. With anycast, you can reach only a single server among servers sharing an address even if you find some server compromised, though you can try others with different addresses. But, as most attacks will be DOS, DNSSEC capable servers are weaker. Masataka Ohta
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 3:47 PM, John Kristoff 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 Sr Network Operator / Innovative Network Concepts
RE: Wireless Recommendations
Just be careful with Xirrus. A little known secret is that only 3 of those radios can be running in the 2.4ghz band at any time. Mario Eirea IT Department Charter School IT 20803 Johnson Street Pembroke Pines, FL 33029 Ph: 954-435-7827 Cell: 305-742-6524 Fax: 954-442-1762 From: Jonathan Lassoff [j...@thejof.com] Sent: Tuesday, February 07, 2012 2:50 PM To: Arzhel Younsi Cc: Mario Eirea; nanog@nanog.org Subject: Re: Wireless Recommendations On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi wrote: > Xirrus say that they can support 640 clients with this device: > http://www.xirrus.com/Products/Wireless-Arrays/XR-Series/XR-4000-Series > I heard about it a couple weeks ago, didn't try it yet. That's a pretty neat product -- it seems like it takes care of spectrally isolating clients by utilizing 4 - 8 radios per AP-box and 8 - 24 directional sector antennas. I feel like this addresses the suggestions that I and others gave to utilize more APs rather than a big central one, but it just packages it all into one box with many antennas. Cheers, jof
Re: SSL Certificates
On Jan 6, 2012, at 6:15, Michael Carey wrote: > Looking for a recommendation on who to buy affordable and reputable SSL > certificates from? Symantec, Thawte, and Comodo are the names that come to > mind, just wondering if there are others folks use. Almost everyone are basically just selling an "activation" with one of the SSL certificate authorities. I usually buy a "RapidSSL" (Verisign) certificate from https://www.sslmatrix.com/ -- they seem to have some of the best prices and the rapidssl enrollment process is very efficient (at least for the cheap automatically "validated" products). Ask -- http://askask.com/
Re: Common operational misconceptions
Telco provided VPN makes communication between your sites secure. If you can use (virtual) circuits, even better. -- Alg
Re: Common operational misconceptions
(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
Re: Anonymous planning a root-servers party
In message <5f40c962-ff7e-4197-bba5-5e891104b...@puck.nether.net>, Jared Mauch writes: > > On Feb 15, 2012, at 5:36 PM, George Bakos wrote: > > > As I hadn't seen it discussed here, I'll have to assume that many > > NANOGers haven't seen the latest rant from Anonymous: > >=20 > > "To protest SOPA, Wallstreet, our irresponsible leaders and the > > beloved bankers who are starving the world for their own selfish > > needs out of sheer sadistic fun, On March 31, the Internet will go > > Black.=20 > > In order to shut the Internet down, one thing is to be done. Down the > > 13 root DNS servers of the Internet. Those servers are as follow:" > >=20 > > http://pastebin.com/XZ3EGsbc > >=20 > > 13 servers. Ssh! Don't anybody mention anycast - it's a secret. > > As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on = > the . zone > > 2 day TTL on the served data pointing to the com zone, so any = > well-behaved server should only touch the root once every ~172800 = > seconds. > > This means the activity would have to be sustained and unmitigated for = > many hours (days) to have a significant impact. > > - Jared Or just slave the root zone. 1 million root servers is more robust than the hundred or so we have today and given the root is signed you can verify the answers returned. One can have your own, offical, F root server instance if you want. A number of ISP already have one. I think a number of the other root server operators do something similar. One can hijack one of the official address and replace the A and records with local address. This one does cause issues for any one wanting to lookup the hijacked address. One can use static-stub in named and simlar mechanisms in other nameservers to send root zone traffic to a local instance. On can use multiple views, match-recursive and forwarder zones in forward first mode to validate answer from the other view using tsig to reach the other view. You can also us this to get AD set on answers from your local zones. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 04:51:44PM -0600, Anton Kapela wrote: > On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson 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).
Re: Common operational misconceptions
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 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.l...@gmail.com http://www.linkedin.com/in/mlyon
Re: Common operational misconceptions
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: Anonymous planning a root-servers party
They could just mess with BGP announcements. If you can't route to the root servers they may as well not exist. -Eric On 16/02/2012, at 9:12 AM, Jared Mauch wrote: > > On Feb 15, 2012, at 5:36 PM, George Bakos wrote: > >> As I hadn't seen it discussed here, I'll have to assume that many >> NANOGers haven't seen the latest rant from Anonymous: >> >> "To protest SOPA, Wallstreet, our irresponsible leaders and the >> beloved bankers who are starving the world for their own selfish >> needs out of sheer sadistic fun, On March 31, the Internet will go >> Black. >> In order to shut the Internet down, one thing is to be done. Down the >> 13 root DNS servers of the Internet. Those servers are as follow:" >> >> http://pastebin.com/XZ3EGsbc >> >> 13 servers. Ssh! Don't anybody mention anycast - it's a secret. > > As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on the . > zone > > 2 day TTL on the served data pointing to the com zone, so any well-behaved > server should only touch the root once every ~172800 seconds. > > This means the activity would have to be sustained and unmitigated for many > hours (days) to have a significant impact. > > - Jared > >
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 4:36 PM, Chuck Anderson 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
Re: Common operational misconceptions
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
Re: Anonymous planning a root-servers party
On Feb 15, 2012, at 5:36 PM, George Bakos wrote: > As I hadn't seen it discussed here, I'll have to assume that many > NANOGers haven't seen the latest rant from Anonymous: > > "To protest SOPA, Wallstreet, our irresponsible leaders and the > beloved bankers who are starving the world for their own selfish > needs out of sheer sadistic fun, On March 31, the Internet will go > Black. > In order to shut the Internet down, one thing is to be done. Down the > 13 root DNS servers of the Internet. Those servers are as follow:" > > http://pastebin.com/XZ3EGsbc > > 13 servers. Ssh! Don't anybody mention anycast - it's a secret. As is TCP, which requires a 3-way handshake, oh and the 41 day TTL on the . zone 2 day TTL on the served data pointing to the com zone, so any well-behaved server should only touch the root once every ~172800 seconds. This means the activity would have to be sustained and unmitigated for many hours (days) to have a significant impact. - Jared
Re: Anonymous planning a root-servers party
I really don't think Anonymous is dumb enough to forget about anycast. If i remember right, another group tried to take down the root servers within the past 5 or 6 years and only took out around 20 or 25. -Grant On Wed, Feb 15, 2012 at 4:36 PM, George Bakos wrote: > As I hadn't seen it discussed here, I'll have to assume that many > NANOGers haven't seen the latest rant from Anonymous: > > "To protest SOPA, Wallstreet, our irresponsible leaders and the > beloved bankers who are starving the world for their own selfish > needs out of sheer sadistic fun, On March 31, the Internet will go > Black. > In order to shut the Internet down, one thing is to be done. Down the > 13 root DNS servers of the Internet. Those servers are as follow:" > > http://pastebin.com/XZ3EGsbc > > 13 servers. Ssh! Don't anybody mention anycast - it's a secret. > >
Anonymous planning a root-servers party
As I hadn't seen it discussed here, I'll have to assume that many NANOGers haven't seen the latest rant from Anonymous: "To protest SOPA, Wallstreet, our irresponsible leaders and the beloved bankers who are starving the world for their own selfish needs out of sheer sadistic fun, On March 31, the Internet will go Black. In order to shut the Internet down, one thing is to be done. Down the 13 root DNS servers of the Internet. Those servers are as follow:" http://pastebin.com/XZ3EGsbc 13 servers. Ssh! Don't anybody mention anycast - it's a secret.
Re: Common operational misconceptions
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
Models of DNS traffic and caches
Are there any analytic or simulation models of DNS traffic and caches? Say I have a DNS cache that handles two different kinds of traffic, DNSBL lookups that are almost never reused, and web page lookups that are frequently reused. Is there a model that will predict whether partitioning the cache would be a good idea, or capping TTL on the DNSBLs, or other sorts of tricks? Pointers are fine. TIA. R's, John -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
Re: Common operational misconceptions
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/ signature.asc Description: OpenPGP digital signature
Re: Common operational misconceptions
"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.
Re: Common operational misconceptions
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgppfxkBwFo1k.pgp Description: PGP signature
Re: Common operational misconceptions
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 : > 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
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
Re: Common operational misconceptions
On Wed, Feb 15, 2012 at 1:10 PM, Kenneth M. Chipps Ph.D. 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:j...@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
RE: Common operational misconceptions
Keep the discussion on the list. I would like to know as well. Kenneth M. Chipps Ph.D. -Original Message- From: John Kristoff [mailto:j...@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
Re: Common operational misconceptions
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
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
Re: IP Transit with netflow report?
+1 for Scrutinizer, but to be fair a lot of our former students work there. On Mon, Feb 13, 2012 at 6:02 AM, Matt Taylor wrote: > Scrutinizer! > > > On 13/02/2012, at 9:53 PM, Raphael MAUNIER wrote: > >> +1 >> >> Do it yourself :) >> >> You can have a look at As-Stats. It's easy to install and maintain >> >> https://neon1.net/as-stats/ >> >> Regards, >> -- >> Raphaël Maunier >> NEO TELECOMS >> CTO / Directeur Ingénierie >> AS8218 >> >> >> >> >> >> >> >> On 2/13/12 11:30 AM, "George Bonser" wrote: >> >>> nfdump + NfSen >>> >>> Do it yourself. >>> >>> -Original Message- From: ali baba [mailto:alibaba123...@gmail.com] Sent: Sunday, February 12, 2012 10:49 PM To: nanog@nanog.org Subject: Re: IP Transit with netflow report? Hi Everyone, Hope someone can help me out.. I have some IP Transit links with one of the Tier1s and I need to know the source<>destination of traffic passing though.. My provider gives me a straight "NO, we can provide this" and I am wondering if anyone knows of any providers who gives out netflow report? Cheers, AB >>> >> >> > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Dear RIPE: Please don't encourage phishing
On 2/15/12 8:32 AM, Mark Andrews wrote: > ... Before deciding to go the IDNA route, treating DNS > labels as UTF-8 was discussed, evaluated and rejected. well, sort of. we started with "idn" as a wg label. the smtp weenies opined that they'd never have a flag day and anything other than a boot encoding in LDH would harm LDH limited mailers, so ... the code point problem (or problems) was moved out of "infrastructure" and into "applications", so the work product was labeled "idna", which the successor wg had no alternative except to follow the "in a" set of dependencies and assumptions. as you observed, labels are length tagged binary blobs, and where the blobs consist of 7 bit ascii values in the 'a'-'z' range, case folding is performed in lookup. what happens outside of that range is a path not taken, though i tried in 2929 to leave that open for future work, the sentence which read "text labels can, in fact, include any octet value including zero octets but most current uses involve only [US-ASCII]." was, if memory serves, proposed by a co-author to have been more restrictive. i agree with the "rejected" statement, the "evaluated" and even the "discussed" overstate the room available after the smtp weenies weighed in on what was permissible in headers. -e
Re: Dear RIPE: Please don't encourage phishing
In message <86mx8kqpy7@seastrom.com>, "Robert E. Seastrom" writes: > > valdis.kletni...@vt.edu writes: > > > On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said: > > > >> Challenge taken. > >> > >> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, > >> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY > >> specify, in addition, how to use other charsets [something DNS does > >> not do, so it must be UTF-8]" > > > > (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) > > > > That requires overlooking the minor detail that the DNS RFC predates that > > by quite > > some time, and there's no combination of RFCs 2119 and 2277 that mandates > > retrofitting grandfathered protocols by fiat. > > > > It also requires overlooking the fact that 2277 is a BCP, not an Internet > > Standard, and > > as such isn't itself binding, merely A Good Idea. > > > > Nice try though. ;) > > Valdis, re-read the original assertion and challenge. > > Your attempt at RFC lawyering appears to be "Experimental" The Internationalised DNS uses IDNA suite of RFC's to encode UTF into A-labels. Before deciding to go the IDNA route, treating DNS labels as UTF-8 was discussed, evaluated and rejected. DNS labels are length tagged binary blobs with case folding of the 7 bit ascii values 'a'-'z' when performing lookups. If a server is fully compliant (and I don't think any is) answers should be returned in a case preserving manner, including owner names. The intent of RFC 1035 was to be able to use the DNS to store and retrieve binary data using binary keys. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Dear RIPE: Please don't encourage phishing
valdis.kletni...@vt.edu writes: > On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said: > >> Challenge taken. >> >> RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, >> "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY >> specify, in addition, how to use other charsets [something DNS does >> not do, so it must be UTF-8]" > > (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) > > That requires overlooking the minor detail that the DNS RFC predates that by > quite > some time, and there's no combination of RFCs 2119 and 2277 that mandates > retrofitting grandfathered protocols by fiat. > > It also requires overlooking the fact that 2277 is a BCP, not an Internet > Standard, and > as such isn't itself binding, merely A Good Idea. > > Nice try though. ;) Valdis, re-read the original assertion and challenge. Your attempt at RFC lawyering appears to be "Experimental" -r
Re: Dear RIPE: Please don't encourage phishing
On Wed, 15 Feb 2012 10:44:38 +0100, Stephane Bortzmeyer said: > Challenge taken. > > RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, > "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY > specify, in addition, how to use other charsets [something DNS does > not do, so it must be UTF-8]" (ooh.. an RFC lawyering fight. Goody goody, haven't had one in a while.. :) That requires overlooking the minor detail that the DNS RFC predates that by quite some time, and there's no combination of RFCs 2119 and 2277 that mandates retrofitting grandfathered protocols by fiat. It also requires overlooking the fact that 2277 is a BCP, not an Internet Standard, and as such isn't itself binding, merely A Good Idea. Nice try though. ;) pgpFmnL4w61nh.pgp Description: PGP signature
Re: Dear RIPE: Please don't encourage phishing
On Mon, Feb 13, 2012 at 05:21:02PM +1100, Mark Andrews wrote a message of 25 lines which said: > > utf-8 is the one used in the ietf community. > > I challenge you to find a RFC that say it is UTF-8. Challenge taken. RFC 2277, "IETF Policy on Character Sets and Languages", section 3.1, "Protocols MUST be able to use the UTF-8 charset [...] Protocols MAY specify, in addition, how to use other charsets [something DNS does not do, so it must be UTF-8]" RFC 5198 is a good reading, too. So, basically, in IETF land, if the encoding is not specified, it is UTF-8.
