From keegan.holley at sungard.com  Wed Feb  1 00:02:03 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 1 Feb 2012 01:02:03 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
Message-ID: <CABO8Q6S+HvK=sL=LSE8xZTnx_86uCxu_GurH-Gj1mSYfPtLBcw@mail.gmail.com>

That may not be a bad idea.  Have you gotten your company's lawyers
involved? They may be able to get some sort of court action started and get
things moving. They may also be able to compel the ISP's to act.


2012/1/31 Kelvin Williams <kwilliams at altuscgi.com>

> I hope none of you ever get hijacked by a spammer housed at Phoenix NAP.
>  :)
>
> We're still not out of the woods, announcing /24s and working with upper
> tier carriers to filter out our lists.  However, I just got this response
> from Phoenix NAP and found it funny.  The "thief" is a former customer,
> whom we terminated their agreement with.  They then forged an LOA,
> submitted it to CWIE.net and Phoenix NAP and resumed using space above and
> beyond their terminated agreement.  So now any request for assistance to
> stop our networks from being announced is now responded to with an
> instruction to contact the thief's lawyer.
>
> kw
>
> ---------- Forwarded message ----------
> From: Kelvin Williams <kwilliams at altuscgi.com>
> Date: Tue, Jan 31, 2012 at 7:43 PM
> Subject: Re: [#135346] Unauthorized BGP Announcements
> To: noc at phoenixnap.com
>
>
> We'll be forwarding this to our peers in the industry--rather funny that
> Phoenix NAP would rather send us to the attorney of the people stealing our
> space than bothering to perform an ARIN WHOIS search, or querying any of
> the IRRs.
>
> Interesting...  Very interesting...  So, who all do you have
> there--spammers and child pornographers?  Is this level of protection what
> you give to them all?
>
>
>
> On Tue, Jan 31, 2012 at 7:30 PM, Brandon S <BrandonS at phoenixnap.com>
> wrote:
>
> > Hello,
> >
> > Thank you for your email. Please direct any further questions regarding
> > this issue to the following contact.
> >
> > Bennet Kelley
> > 100 Wilshire Blvd.
> > Suite 950
> > Santa Monica, CA 90401
> > bkelley at internetlawcenter.net
> >
> > Telephone
> > 310-452-0401
> >
> > Facsimile
> > 702-924-8740
> >
> > --
> > Brandon S.
> > NOC Services Technician
> >
> > ** We want to hear from you!**
> > We care about the quality of our service. If you?ve received
> > anything less than a prompt response or exceptional service or would like
> > to share any
> > feedback regarding your experience, please let us know by sending an
> email
> > to management:
> > supportfeedback at phoenixnap.com
> >
> > --
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
>
>
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow
>
>

From marka at isc.org  Wed Feb  1 00:14:42 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 01 Feb 2012 17:14:42 +1100
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: Your message of "Tue, 31 Jan 2012 18:00:44 -0800."
 <D73AF1AF-B75E-49B6-937A-5FBE770AD83D@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <D73AF1AF-B75E-49B6-937A-5FBE770AD83D@virtualized.org>
Message-ID: <20120201061442.A55381C96CD2@drugs.dv.isc.org>


In message <D73AF1AF-B75E-49B6-937A-5FBE770AD83D at virtualized.org>, David Conrad
 writes:
> On Jan 31, 2012, at 5:52 PM, Mark Andrews wrote:
> >> "We have a contractual relationship with our customer to announce =
> that =3D
> >> space.  We have neither a contractual relationship (in this context) =
> =3D
> >> with the RIR nor the RIR's customer.  The RIR and/or the RIR's =
> customer =3D
> >> should resolve this issue with our customer."
> >=20
> > And if I have a contract to commit murder that doesn't mean that
> > it is right nor legal.  A contract can't get you out of dealing
> > with the law of the land and in most place in the world "aiding and
> > abetting" is illegal.
> 
> You appear to be making a large number of assumptions on limited =
> evidence. In the case I'm familiar with, I can assure you that no laws =
> were being broken (even if all the parties were in the same country, =
> which they weren't).  However, this is getting off-topic and I don't =
> want to hijack the thread.  The issue of route hijacking is quite =
> serious and it will be interesting to see how this all works out.

And would sidr have helped.
 
> Regards,
> -drc
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From saku at ytti.fi  Wed Feb  1 01:32:00 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 1 Feb 2012 09:32:00 +0200
Subject: Console Server Recommendation
In-Reply-To: <15445673-C219-467D-BB5F-98C873B04355@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
Message-ID: <20120201073200.GA23107@pob.ytti.fi>

On (2012-01-31 11:09 -0800), Owen DeLong wrote:
 
> > - IP address mappable to a console port. So that accessing device normally
> >  is 'ssh router' and via OOB 'ssh router.oob' no need to train people
> 
> How about normal is 'ssh device' and OOB is 'console device'?

Home-baked systems are certainly good option to many, but for some of us it
means we need to either hire worker to design, acquire, build and support
them or consultant. And as you can find devices which support above
requirements (opengear) TCO for us is simply just lower to buy one ready.

'console device' is what we do today, which is script someone needs to
maintain (it picks up from DNS TXT records OOB and port where to connect).
I prefer giving each port an IP and just use it via ssh (at least cyclades
and opengear do this), if you are brave you could even setup same IP
address for console and on-band loop, but I found that to be suboptimal, as
you sometimes want to connect to OOB even when on-band is working.

> There are other tools that do this, such as rancid. I'm not sure I see significant advantage
> to integrating it.

This was exactly for easy integration to rancid, if you cannot puke all
config easily from one place, doing rancid module is lot more work. Few of
the boxes I've seen, need to have some files hacked via linux cli and are
PITA to backup.
But as it was nice to have, it by no means is no show-stopper.

> I agree that RS232 on a management plane would be a better choice. Personally,
> I like the idea of having both RS232 and ethernet on dedicated management plane.
> The RS232 allows you to deal with failures on the ethernet and the ethernet provides
> support for image transfers, etc.

You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all
myself. Probably it's easier to sell this at day1 with RS232 port, as it is
required in many RFPs and when everyone has migrated to ethernet OOB,
phase-out RS232.
So people please add to your 'nice to have' requirements in RFP, proper OOB
:). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to
control-plane console not responding)

> I will point out that the intel mobo OOB has not completely eliminated the need for
> IPKVM in the datacenter. YMMV.

This is bit drifting on the subject, but what are you missing specifically?
You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get
IDE redirection, to boot the remote box from your laptop CDROM. And you get
API to automatically install factory fresh boxes without ever touching the
boxes.


-- 
  ++ytti


From goemon at anime.net  Wed Feb  1 01:41:59 2012
From: goemon at anime.net (goemon at anime.net)
Date: Tue, 31 Jan 2012 23:41:59 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201015257.39A071C95D68@drugs.dv.isc.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
Message-ID: <Pine.LNX.4.64.1201312341020.25698@sasami.anime.net>

On Wed, 1 Feb 2012, Mark Andrews wrote:
> And if I have a contract to commit murder that doesn't mean that
> it is right nor legal.  A contract can't get you out of dealing
> with the law of the land and in most place in the world "aiding and
> abetting" is illegal.

the topic at hand would appear to be more 'willful negligence' than 
'aiding and abetting'. punitive damages could apply.

-Dan


From kwilliams at altuscgi.com  Wed Feb  1 02:58:51 2012
From: kwilliams at altuscgi.com (Kelvin Williams)
Date: Wed, 1 Feb 2012 03:58:51 -0500
Subject: Thanks & Let's Prevent this in the Future.
Message-ID: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>

First off, I'd like to thank everyone on this list who have reached out
today and offered us help with our hijacked network space.  It's so
refreshing to see that there are still so many who refuse to leave a
man/woman down.

I'm not going to place any blame, its useless.  There were lies, there were
incompetencies, and there was negligence but that is now water under the
bridge.

However, I think that we as network operators have a duty to each other to
make sure we don't allow a downstream customer wreck the operations of
another entity who has been rightfully allocated resources.

A few months ago, when establishing a new peering relationship I was
encouraged (actually required) to utilize one of the IRRs.  I took the time
to register all of my routes, ASNs, etc.  However, as I learned today, this
was probably done in vain.  Too many people won't spend the extra
30-seconds to verify the information listed there or in ARINs WHOIS.

I don't care what a customer tells me, too many times I've found they
aren't 100% honest either for malicious/fraudulent reasons or they are
unknowing.  So, for our networks or the networks we manage, we want to
verify what a customer is saying to prevent what happened to us today.

I'd like to get a conversation going and possibly some support of an
initiative to spend that extra 30-seconds to verify ownership and
authorization of network space to be advertised.  Additionally, if someone
rings your NOC's line an industry-standard process of verifying "ownership"
and immediately responding by filtering out announcements. There's no sense
in allowing a service provider to be impaired because a spammer doesn't
want to give up clean IP space.  Do you protect a bad customer or the
Internet as a whole?  I pick the Internet as a whole.

How can we prevent anyone else from ever enduring this again?  While we may
never stop it from ever happening, spammers (that's what we got hit by
today) are a dime a dozen and will do everything possible to hit an Inbox,
so how can we establish a protocol to immediate mitigate the effects of an
traffic-stopping advertisement?

I thought registering with IRRs and up-to-date information in ARINs WHOIS
was sufficient, apparently I was wrong.  Not everyone respects them, but
then again, they aren't very well managed (I've got several networks with
antiquated information I've been unable to remove, it doesn't impair us
normally, but its still there).

What can we do?  Better yet, how do we as a whole respond when we encounter
upstream providers who refuse to look at the facts and allow another to
stay down?

kw

-- 
Kelvin Williams
Sr. Service Delivery Engineer
Broadband & Carrier Services
Altus Communications Group, Inc.


"If you only have a hammer, you tend to see every problem as a nail." --
Abraham Maslow

From leigh.porter at ukbroadband.com  Wed Feb  1 03:12:41 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 1 Feb 2012 09:12:41 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <6F4B982A-90D3-4568-B4EB-29E98C95A479@ukbroadband.com>


On 1 Feb 2012, at 09:01, "Kelvin Williams" <kwilliams at altuscgi.com> wrote:

> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.

It's amazing isn't it. It isn't only fraud and maliciousness that this prevents. 

A number of times I have been asked to advertise space or open filters for space based on typos and people not understanding address notation and CIDR. So it's with doing if only to prevent this.

-- 
Leigh


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


From hank at efes.iucc.ac.il  Wed Feb  1 03:13:57 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 01 Feb 2012 11:13:57 +0200
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.g
 mail.com>
Message-ID: <5.1.0.14.2.20120201110350.00c51a30@efes.iucc.ac.il>

At 03:58 01/02/2012 -0500, Kelvin Williams wrote:

Those ISPs that are good network citizens have done it already.  Those who 
don't care and who haven't done it yet - won't do it in the future.  The 
only recourse you have is exactly what you have done.

-Hank

>How can we prevent anyone else from ever enduring this again?  While we may
>never stop it from ever happening, spammers (that's what we got hit by
>today) are a dime a dozen and will do everything possible to hit an Inbox,
>so how can we establish a protocol to immediate mitigate the effects of an
>traffic-stopping advertisement?
>
>I thought registering with IRRs and up-to-date information in ARINs WHOIS
>was sufficient, apparently I was wrong.  Not everyone respects them, but
>then again, they aren't very well managed (I've got several networks with
>antiquated information I've been unable to remove, it doesn't impair us
>normally, but its still there).
>
>What can we do?  Better yet, how do we as a whole respond when we encounter
>upstream providers who refuse to look at the facts and allow another to
>stay down?
>
>kw
>
>--
>Kelvin Williams
>Sr. Service Delivery Engineer
>Broadband & Carrier Services
>Altus Communications Group, Inc.
>
>
>"If you only have a hammer, you tend to see every problem as a nail." --
>Abraham Maslow



From hmurray at megapathdsl.net  Wed Feb  1 04:12:19 2012
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 01 Feb 2012 02:12:19 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked 
 Networks)
Message-ID: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>

I'm not a lawyer nor an operator.

> Imagine that instead of www.google.com, it was www.whitehouse.gov

> At some point, I suspect that this gets service to get it fixed RIGHT NOW.
> At some point, the guys informing you it's RIGHT NOW show up with badges.

Where is Milo Medin when we need him?

> The question is, when is it badges?  It can be construed as a denial of
> service attack on the addresses' rightful owners.  They will respond to any
> major government site being hijacked.  Probably to Apple or Google.  Likely
> to a Tier-1 ISPs internal infrastructure. 

How long should it take to fix a problem like this?

Why didn't one of the players upstream from the bad guy pull their plug or 
drop the bogus announcement?  Why didn't any of the players between the first 
upstream and the tier 1s apply pressure?

Do existing contracts cover this case?  If not, what needs to be fixed?  Is a 
RFC needed so the lawyers have something to reference?

Would a session to discuss this at a NANOG gathering help?


> a) law enforcement doesn't understand the problem. and b) the law moves
> very slowly. 

It might be a good idea to make sure that somebody in law enforcement does 
understands what happened here so they can think about what who needs to do 
what the next time something like this happens.  (Make sure that operators 
know how to get in touch with somebody who knows.)


-- 
These are my opinions, not necessarily my employer's.  I hate spam.





From brian_mk at live.com  Wed Feb  1 04:32:07 2012
From: brian_mk at live.com (Brian)
Date: Wed, 1 Feb 2012 10:32:07 +0000 (UTC)
Subject: IP KVM suggestions
References: <mailman.1976.1327950320.46019.nanog@nanog.org>
 <4F270787.403@gmail.com>
Message-ID: <loom.20120201T111713-788@post.gmane.org>

> On 1/30/2012 11:05 AM, nanog-request <at> nanog.org wrote:
> > ------------------------------
> >
> > Message: 8
> > Date: Mon, 30 Jan 2012 12:09:16 -0600
> > From: "Express Web Systems" <mailinglists <at> expresswebsystems.com>
> > To: "'NANOG'" <nanog <at> nanog.org>
> > Subject: RE: IP KVM suggestions
> > Message-ID: <033601ccdf7a$481d0f90$d8572eb0$@com>
> > Content-Type: text/plain;	charset="us-ascii"
> >
> >> > I have a need for a small, portable, web based IP kvm with decent
> >> > features that doesn't break the bank.  Preferably something that
> >> > supports ISO mounting from http or ftp and USB connectivity.  Would
> >> > also prefer something browser independent.  Small plugin like the
> >> > Raritan devices would be acceptable too. It will be used internally for
> >> > Remote access while building devices pre deployment to customers.  Any
> >> > suggestions?
> >> > 
> >> > Thanks!
> >> > 
> >> > Blake

Brian <brian_mk)<at> live.com> writes:

Hi Blake,

Are you familiar with the PX device (http://minicom.com/kvm_px.htm)? We have it 
placed at several customer sites, and so far extremely reliable. It comes with 
VM included, but can with a special power cable also give you remote power 
control. I give it two thumbs up.

Cheers,
Brian






From mailinglist at theflux.net  Wed Feb  1 09:32:58 2012
From: mailinglist at theflux.net (TFML)
Date: Wed, 1 Feb 2012 10:32:58 -0500
Subject: US DOJ victim letter
In-Reply-To: <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
References: <201201201908.q0KJ8u6C045030@mail.r-bonomi.com>
 <CB482859.5D359%carlos@race.com> <20120127181626.GC21814@lab.pobox.com>
 <Pine.LNX.4.61.1201271503160.24418@soloth.lewis.org>
 <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
Message-ID: <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>

If the IP list is pointing to DNS servers, they maybe referring to the following:

http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf

On Jan 31, 2012, at 7:38 PM, Phil Dyer wrote:

> On Fri, Jan 27, 2012 at 3:23 PM, Jon Lewis <jlewis at lewis.org> wrote:
>> On Fri, 27 Jan 2012, Bryan Horstmann-Allen wrote:
> 
>>> Bit odd, if it's a phish. Even more odd if it's actually from the Fed.
>> 
>> 
>> It's definitely real, but seems like they're handling it as incompetently as
>> possible.
> 
> 
> Yep. That sounds about right.
> 
> Man, I'm feeling left out. I kinda want one now.
> 
> phil
> 



From obriapqz at bc.edu  Wed Feb  1 09:59:06 2012
From: obriapqz at bc.edu (Christopher O'Brien)
Date: Wed, 1 Feb 2012 10:59:06 -0500
Subject: Console Server Recommendation
In-Reply-To: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
Message-ID: <4F29614A.6050307@bc.edu>

On 1/30/12 11:08 AM, Ray Soucy wrote:
> What are people using for console servers these days?  We've
> historically used retired routers with ASYNC ports, but it's time for
> an upgrade.
>
> OpenGear seems to have some nice stuff, anyone else?
>

I've been using Western Telematic TSM-40 console servers and have been 
very happy with the price point and feature set.

Also, I aggregate console connections from different parts of my campus 
over my existing fiber plant using TC Communications TC1880 Async Fiber 
MUXs.  This combination has served me well.


From gbonser at seven.com  Wed Feb  1 11:00:43 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 17:00:43 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>

> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if
> someone rings your NOC's line an industry-standard process of verifying
> "ownership"
> and immediately responding by filtering out announcements. There's no
> sense in allowing a service provider to be impaired because a spammer
> doesn't want to give up clean IP space.  Do you protect a bad customer
> or the Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we
> may never stop it from ever happening, spammers (that's what we got hit
> by
> today) are a dime a dozen and will do everything possible to hit an
> Inbox, so how can we establish a protocol to immediate mitigate the
> effects of an traffic-stopping advertisement?

One problem is the number of routing registries and the requirements differ for them.  The nefarious operator can enter routes in an IRR just as easily as a legitimate operator.  There was a time when some significant networks used the IRRs for their filtration policy.  I'm not sure how many still do.

But generally speaking, if someone calls me and I can verify that they really are a POC for the entity that is assigned an address allocation (generally some verification method beyond email if the subnet their MX record points to is part of the hijacking!) then I am going to do whatever I can to help them out provided what they are asking for is reasonable and within my capabilities.  It shouldn't be too hard to verify.  If someone claims to be with a commercial entity of Foo.COM then the entity is likely listed in the phone book and a phone call can take care of my personal verification requirement.  

Back in the days of Cyberpromo and Sanford Wallace, what I did was used TCP wrappers on my mail server so that when I received a connection from a Cyberpromo net block, I hairpinned the connection back to his MX server using netcat so when he connected to me, the HELO he received was from his own mail server, which gladly accepted mail from Cyberpromo.  He could pump mail to me all day long if he wanted to, but his mailq wasn't going to get any smaller.

The problem of email spam is an interesting one that has been battled for a very long time and is probably better discussed on a list dedicated to that topic.



From owen at delong.com  Wed Feb  1 11:07:42 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 09:07:42 -0800
Subject: Console Server Recommendation
In-Reply-To: <20120201073200.GA23107@pob.ytti.fi>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
Message-ID: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>


On Jan 31, 2012, at 11:32 PM, Saku Ytti wrote:

> On (2012-01-31 11:09 -0800), Owen DeLong wrote:
> 
>>> - IP address mappable to a console port. So that accessing device normally
>>> is 'ssh router' and via OOB 'ssh router.oob' no need to train people
>> 
>> How about normal is 'ssh device' and OOB is 'console device'?
> 
> Home-baked systems are certainly good option to many, but for some of us it
> means we need to either hire worker to design, acquire, build and support
> them or consultant. And as you can find devices which support above
> requirements (opengear) TCO for us is simply just lower to buy one ready.
> 

I would hardly call conserver software a home-baked solution unless you'd
also call anything based on OSS a "home-baked solution".

You'd have to configure the tserv, ssh, and/or DNS in order to achieve
ssh device.oob, and you have to configure the tserv and the conserver
software in order to achieve what I suggested.

> 'console device' is what we do today, which is script someone needs to
> maintain (it picks up from DNS TXT records OOB and port where to connect).

If you use the conserver software, console isn't a script someone needs to
maintain, it's the client portion of the conserver software package.

> I prefer giving each port an IP and just use it via ssh (at least cyclades
> and opengear do this), if you are brave you could even setup same IP
> address for console and on-band loop, but I found that to be suboptimal, as
> you sometimes want to connect to OOB even when on-band is working.
> 

This takes away several of the other features from your list however, that are
implemented using the conserver software.

>> I agree that RS232 on a management plane would be a better choice. Personally,
>> I like the idea of having both RS232 and ethernet on dedicated management plane.
>> The RS232 allows you to deal with failures on the ethernet and the ethernet provides
>> support for image transfers, etc.
> 
> You can get that from Nexus7k and Sup7. I wouldn't use the RS232 at all
> myself. Probably it's easier to sell this at day1 with RS232 port, as it is
> required in many RFPs and when everyone has migrated to ethernet OOB,
> phase-out RS232.
> So people please add to your 'nice to have' requirements in RFP, proper OOB
> :). (Can't tell how many times we've had to power-cycle CSCO or JNPR due to
> control-plane console not responding)
> 

I've never seen a case where the control plane console failed to respond and I didn't
need to reboot the router to bring the control-plane back to life anyway. It's not like a
router can (usefully) continue for very long with a dead/locked-up control plane.

>> I will point out that the intel mobo OOB has not completely eliminated the need for
>> IPKVM in the datacenter. YMMV.
> 
> This is bit drifting on the subject, but what are you missing specifically?
> You get VNC KVM, all the way from boot to bios, to GUI or CLI. You also get
> IDE redirection, to boot the remote box from your laptop CDROM. And you get
> API to automatically install factory fresh boxes without ever touching the
> boxes.

Only so long as the BIOS doesn't lose its mind which happens with some
unfortunate regularity. With a good IPKVM such as the Raritans, I get
everything you just described with the added advantage of still being able
to connect to a server when it's BIOS has lost its mind. As nice as those
devices sound, they still have some failure modes that stop short of being
my ideal OOB solution.

Owen



From saku at ytti.fi  Wed Feb  1 11:24:44 2012
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 1 Feb 2012 19:24:44 +0200
Subject: Console Server Recommendation
In-Reply-To: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
Message-ID: <20120201172444.GA27031@pob.ytti.fi>

On (2012-02-01 09:07 -0800), Owen DeLong wrote:
 
> I would hardly call conserver software a home-baked solution unless you'd
> also call anything based on OSS a "home-baked solution".

Home-baked, i.e. it's not product you can get shipped and it'll work out of
the box and you have organization supporting it.
The shipping solutions are really nothing else than embedded linux running
conserver or equivalent, opengear even gives many of their oftware for
free.
It's certainly not difficult to roll one yourself, but for many of us, TCO
is lot more than just buying opengear.

> This takes away several of the other features from your list however, that are
> implemented using the conserver software.

The required list is satisfied by multiple offerings, including giving IP
address to console port. So there are products in the market doing exactly
what I want at cost which I'd be hard to reproduce even if I calculate my
time as free.

> I've never seen a case where the control plane console failed to respond
> and I didn't need to reboot the router to bring the control-plane back to
> life anyway. It's not like a router can (usefully) continue for very long
> with a dead/locked-up control plane.

Lot of people don't have way to remotely power cycle devices, if OOB is
separate management-plane, you can power cycle control-plane remotely. It's
probably <50USD BOM addition to list price, which server guys have enjoyed
for over decade and Cisco has been trying to introduce to networking guys.

> Only so long as the BIOS doesn't lose its mind which happens with some
> unfortunate regularity. With a good IPKVM such as the Raritans, I get

If you can access BIOS from console, you can access it via vPRO/AMT. If you
run into more exotic problem, it's cheaper just to swap that 50<100usd
motherboard than to investigate what happened.

-- 
  ++ytti


From drc at virtualized.org  Wed Feb  1 11:37:48 2012
From: drc at virtualized.org (David Conrad)
Date: Wed, 1 Feb 2012 09:37:48 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
Message-ID: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>

On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>> "We have a contractual relationship with our customer to announce that space.  We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's customer should resolve this issue with our customer."
> Contracts are generally not a valid reason to be breaking laws.

Which law?

Regards,
-drc



From jlewis at lewis.org  Wed Feb  1 11:51:58 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Wed, 1 Feb 2012 12:51:58 -0500 (EST)
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
Message-ID: <Pine.LNX.4.61.1202011215350.2201@soloth.lewis.org>

On Wed, 1 Feb 2012, George Bonser wrote:

> One problem is the number of routing registries and the requirements 
> differ for them.  The nefarious operator can enter routes in an IRR just 
> as easily as a legitimate operator.  There was a time when some 
> significant networks used the IRRs for their filtration policy.  I'm not 
> sure how many still do.

A few do, but IRR data really can't be trusted as a means of 
authenticating authority to advertise IP space.  It's a nice system for 
automating route filter updates (between the customer and 
provider...i.e. I add data to an IRR, and Level3 auto-updates my prefix 
filter), but when anyone can put anything into the IRR dbs, obviously 
everyone using the IRR dbs isn't going to stop someone from hijacking 
someone else's space.

As a regional ISP / hosting provider, my policy for accepting BGP routes 
from customers has been to check RIR whois data, make sure the space 
appears to be owned by the customer, and if there's any question, ask for 
clarification and/or an LOA from the customer showing that they are 
authorized to use the space.  Every customer gets a prefix filter that 
allows them to announce only what we've verified they're authorized to 
announce.

Level3, I suppose, just trusts customers won't announce space they 
shouldn't.  The alternative, which I've dealt with with some other "Tier 
1's" is that they require customers to provide an LOA every time they want 
to add a CIDR to their prefix filter.  That's more paper work for me and 
for them, and tends to be slower, as someone has to manually approve 
(maybe manually apply) the change request.

Given what we have available today, there's security or convenience...pick 
one.

It seems like the IRR thing could reasonably easily be solved if the RIRs 
got more deeply involved.

Suppose, as an ARIN member, I used ARIN's IRR.  I'd start out by 
registering my maintainer object, my ASN, my routes, and an as-set. 
Then, when I wanted to add customer ASNs to my as-set, the system wouldn't 
allow me to do so unless the customer had already registered their ASN 
with my ASN as an approved provider/path.  The customer, if they had no 
ASN, would be responsible for updating their route (PI or PA) in the IRR 
db, stating my ASN is a valid origin for their route. This would solve the 
problem of larger providers like Level3 blindly accepting my as-set 
because all the authentication/authorization would already have been done 
before the data went into the IRR db.  Things get a little more 
complicated when I pick up a customer who has "out of region" objects, 
i.e. RIPE IPs/ASN, but if all the RIRs worked together and standardized 
how the information is maintained, it could work.  i.e. When I try to add 
the RIPE ASN to my as-set, ARIN's system would check RIPE's system to see 
if that ASN's owner had set my ASN as a valid provider/path for their ASN.

This seems so simple, either it should have been implemented a decade or 
more ago, or perhaps I'm overlooking something.  It wouldn't stop route 
advertisements from providers who don't care / don't filter, but it would 
make systems like Level3's more secure...and if all the "Tier 1's" adopted 
similar automated filter generators based on the RIR IRR dbs, it would 
stop unauthorized announcements from getting far.

> The problem of email spam is an interesting one that has been battled 
> for a very long time and is probably better discussed on a list 
> dedicated to that topic.

Definitely...but the issue here is ownership/authorization to use IP 
space, and how stop unauthorized BGP announcements when providers don't or 
won't filter their BGP customers.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From morrowc.lists at gmail.com  Wed Feb  1 11:55:30 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 1 Feb 2012 12:55:30 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>
References: <20120201101219.3A9D7800037@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <CAL9jLaZgKjCjzx__KTJw2CH1S5MyvzUu7c66VMkcP1hHQsz3Hw@mail.gmail.com>

On Wed, Feb 1, 2012 at 5:12 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
> I'm not a lawyer nor an operator.
>
>> Imagine that instead of www.google.com, it was www.whitehouse.gov
>
>> At some point, I suspect that this gets service to get it fixed RIGHT NOW.
>> At some point, the guys informing you it's RIGHT NOW show up with badges.
>
> Where is Milo Medin when we need him?

how would he be helping?

>> The question is, when is it badges? ?It can be construed as a denial of
>> service attack on the addresses' rightful owners. ?They will respond to any
>> major government site being hijacked. ?Probably to Apple or Google. ?Likely
>> to a Tier-1 ISPs internal infrastructure.
>
> How long should it take to fix a problem like this?

the YT/pk-telecom incident lasted: 2hr 15mins according to renesys
(http://www.renesys.com/blog/2008/02/pakistan-hijacks-youtube-1.shtml)

I think for a few reasons this ONLY lasted 2hrs... one at least being
pktelecom getting some pain from this hijack, plus they PROBABLY
didn't mean to do what they did. (Oops, we fat-fingered, lets fix
that...)

Why did this take even 2hrs? why is the currrent incident lasting
(lasted?) as long as it has? what system(s) would make this problem
better? Danny refers to 'resource certification', I think he's
pointing at RPKI[1], how far out is this? (seems like ~5+ yrs or so
til useful deployment arrives, not even counting router-code for this
appearing in the main set of deployed devices).

-chris
[1]: <http://www.afrinic.net/membership/certification.htm>  (other
RIR's are also represented, this was just the first relevant answer in
bing)

(all discussion of laws is ridiculous... which jurisdiction, which
law, which .... forget about any reasonable answer here)


From owen at delong.com  Wed Feb  1 11:55:02 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 09:55:02 -0800
Subject: Console Server Recommendation
In-Reply-To: <20120201172444.GA27031@pob.ytti.fi>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
 <20120201172444.GA27031@pob.ytti.fi>
Message-ID: <05509014-2199-43C0-9BD2-AF4744934458@delong.com>


On Feb 1, 2012, at 9:24 AM, Saku Ytti wrote:

> On (2012-02-01 09:07 -0800), Owen DeLong wrote:
> 
>> I would hardly call conserver software a home-baked solution unless you'd
>> also call anything based on OSS a "home-baked solution".
> 
> Home-baked, i.e. it's not product you can get shipped and it'll work out of
> the box and you have organization supporting it.
> The shipping solutions are really nothing else than embedded linux running
> conserver or equivalent, opengear even gives many of their oftware for
> free.
> It's certainly not difficult to roll one yourself, but for many of us, TCO
> is lot more than just buying opengear.
> 

It's a product you can download, compile, configure and it works out of the box.

It is pretty well supported by the authors and they have been very responsive to
each and every question/feature/other request I have made to them, no matter
how stupid. In fact, it has been better supported in my experience than most
boxed software.

conserver doesn't replace the opengear products, it's a software package that
sits next to them and provides increased functionality of the type you suggested
would be desirable.

It's no more difficult to configure conserver than to set up the DNS to do what
you were suggesting with SSH.

>> This takes away several of the other features from your list however, that are
>> implemented using the conserver software.
> 
> The required list is satisfied by multiple offerings, including giving IP
> address to console port. So there are products in the market doing exactly
> what I want at cost which I'd be hard to reproduce even if I calculate my
> time as free.
> 

I think you are misunderstanding and thinking I propose conserver as a
replacement for MRV/Cyclades/etc. I do not. I propose it as a way to get
most of the features you wanted that aren't present in those boxes by
adding it to them.

It has the additional advantage that it can provide the same functionality
transparently across a wide variety of tserv hardware so that you can
use multiple manufacturers over time and keep that transparent for the
most part.

>> I've never seen a case where the control plane console failed to respond
>> and I didn't need to reboot the router to bring the control-plane back to
>> life anyway. It's not like a router can (usefully) continue for very long
>> with a dead/locked-up control plane.
> 
> Lot of people don't have way to remotely power cycle devices, if OOB is
> separate management-plane, you can power cycle control-plane remotely. It's
> probably <50USD BOM addition to list price, which server guys have enjoyed
> for over decade and Cisco has been trying to introduce to networking guys.
> 

Agreed. Nonetheless, power cycling the box vs. power cycling the control plane
isn't a huge difference from my perspective.

>> Only so long as the BIOS doesn't lose its mind which happens with some
>> unfortunate regularity. With a good IPKVM such as the Raritans, I get
> 
> If you can access BIOS from console, you can access it via vPRO/AMT. If you
> run into more exotic problem, it's cheaper just to swap that 50<100usd
> motherboard than to investigate what happened.
> 

Tell me that again when your device looses it's mind and the vPRO/AMT doesn't
come up with a workable IP address. RS-232 does NOT have this problem.


Owen



From tony at lavanauts.org  Wed Feb  1 12:15:28 2012
From: tony at lavanauts.org (Antonio Querubin)
Date: Wed, 1 Feb 2012 08:15:28 -1000 (HST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <alpine.LRH.2.02.1202010813460.2419@sol.manaikaika.com>

On Wed, 1 Feb 2012, David Conrad wrote:

> On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>>> "We have a contractual relationship with our customer to announce that space.  We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's customer should resolve this issue with our customer."
>> Contracts are generally not a valid reason to be breaking laws.
>
> Which law?

I think if you provided more specific details of your example, I suspect 
some of us could probably come up with some specific laws that may have 
been broken :)

Antonio Querubin
e-mail:  tony at lavanauts.org
xmpp:  antonioquerubin at gmail.com


From gbonser at seven.com  Wed Feb  1 12:15:35 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 18:15:35 +0000
Subject: Console Server Recommendation
In-Reply-To: <05509014-2199-43C0-9BD2-AF4744934458@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
 <20120201172444.GA27031@pob.ytti.fi>
 <05509014-2199-43C0-9BD2-AF4744934458@delong.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5A7@RWC-MBX1.corp.seven.com>

> It's a product you can download, compile, configure and it works out of
> the box.
> 
> It is pretty well supported by the authors and they have been very
> responsive to each and every question/feature/other request I have made
> to them, no matter how stupid. In fact, it has been better supported in
> my experience than most boxed software.
> 
> conserver doesn't replace the opengear products, it's a software
> package that sits next to them and provides increased functionality of
> the type you suggested would be desirable.
> 
> It's no more difficult to configure conserver than to set up the DNS to
> do what you were suggesting with SSH.

On Ubuntu Linux:  

apt-get install conserver-server
apt-get install conserver-client

You need one conserver server and can have as many clients as you want.  

Getting the software installed is pretty much dead simple. Configuring it is pretty darned intuitive, too.

> I think you are misunderstanding and thinking I propose conserver as a
> replacement for MRV/Cyclades/etc. I do not. I propose it as a way to
> get most of the features you wanted that aren't present in those boxes
> by adding it to them.

Exactly.  It is extremely handy for providing a standard interface / set of features if you have a mix of different console server hardware.  It is simply a layer of abstraction that lives above the console server hardware and allows you to buffer content, share sessions, etc.

 
> It has the additional advantage that it can provide the same
> functionality transparently across a wide variety of tserv hardware so
> that you can use multiple manufacturers over time and keep that
> transparent for the most part.

+1  sure makes things simple if you have different gear at different sites or have changed vendors over the years and have legacy stuff still in service.




From frnkblk at iname.com  Wed Feb  1 12:15:53 2012
From: frnkblk at iname.com (Frank Bulk)
Date: Wed, 1 Feb 2012 12:15:53 -0600
Subject: Console Server Recommendation
In-Reply-To: <4F29614A.6050307@bc.edu>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <4F29614A.6050307@bc.edu>
Message-ID: <00a101cce10d$88dfbb10$9a9f3130$@iname.com>

We use WTI, too, just don't like it that it reboots to apply a change.

Frank

-----Original Message-----
From: Christopher O'Brien [mailto:obriapqz at bc.edu] 
Sent: Wednesday, February 01, 2012 9:59 AM
To: nanog at nanog.org
Subject: Re: Console Server Recommendation

On 1/30/12 11:08 AM, Ray Soucy wrote:
> What are people using for console servers these days?  We've
> historically used retired routers with ASYNC ports, but it's time for
> an upgrade.
>
> OpenGear seems to have some nice stuff, anyone else?
>

I've been using Western Telematic TSM-40 console servers and have been 
very happy with the price point and feature set.

Also, I aggregate console connections from different parts of my campus 
over my existing fiber plant using TC Communications TC1880 Async Fiber 
MUXs.  This combination has served me well.





From gbonser at seven.com  Wed Feb  1 12:16:46 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 18:16:46 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>

> >> "We have a contractual relationship with our customer to announce
> that space.  We have neither a contractual relationship (in this
> context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's
> customer should resolve this issue with our customer."
> > Contracts are generally not a valid reason to be breaking laws.
> 
> Which law?
> 
> Regards,
> -drc
> 

Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.

Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.

There obviously must be a remedy for two parties attempting to utilize the same resource at the same time, particularly when one party is the rightfully in control of that resource's use.  It might be civil rather than criminal but the rightful owner of the resource would have a good case.


From bill at herrin.us  Wed Feb  1 12:47:21 2012
From: bill at herrin.us (William Herrin)
Date: Wed, 1 Feb 2012 13:47:21 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
Message-ID: <CAP-guGWm5dZTf0Hx=z-9+PpopuRNZUswjX=+_eTJd-jHA5uixA@mail.gmail.com>

On Wed, Feb 1, 2012 at 12:37 PM, David Conrad <drc at virtualized.org> wrote:
> On Jan 31, 2012, at 8:53 PM, Antonio Querubin wrote:
>>> "We have a contractual relationship with our customer to announce that space. ?We have neither a contractual relationship (in this context) with the RIR nor the RIR's customer. ?The RIR and/or the RIR's customer should resolve this issue with our customer."
>> Contracts are generally not a valid reason to be breaking laws.
>
> Which law?

Tortious interference at the very least. Or did you mean criminal law
as opposed to common law?

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From lists at billmerriam.com  Wed Feb  1 12:54:02 2012
From: lists at billmerriam.com (Bill Merriam)
Date: Wed, 1 Feb 2012 13:54:02 -0500
Subject: ATT, IPv6 and 6RD
Message-ID: <20120201135402.1eecd24d@kilo.billmerriam.com>

I now have ATT IPv6 over their residential ADSL broadband.  They
deployed using 6RD which means every time your IPv4 address changes
your IPv6 address changes also.  Does anybody have a clue why they
chose to use 6RD instead of the much more fully-assed TR-187 for their
deployment?

Saying they're dimwits doesn't count.

Bill


From nanog at hostleasing.net  Wed Feb  1 13:15:02 2012
From: nanog at hostleasing.net (Randy Epstein)
Date: Wed, 01 Feb 2012 14:15:02 -0500
Subject: UCE: Re: Fiber outage in Miami
In-Reply-To: <CAGSJx7sFN_W31Jq9zwrKodBgPwmVjWiEBWGQqtCjLD237spBTw@mail.gmail.com>
Message-ID: <CB4EF949.5B00F%nanog@hostleasing.net>



On 1/30/12 11:53 AM, "Joe Marr" <jimmy.changa007 at gmail.com> wrote:

>I've yet to hear back from them on the reason for the outage and
>explanation on why our "redundant" darkfiber pairs both were down.

They cut ALL THE FIBER going into MI1 .. At the same time.

Randy




From trejrco at gmail.com  Wed Feb  1 13:16:58 2012
From: trejrco at gmail.com (TJ)
Date: Wed, 1 Feb 2012 14:16:58 -0500
Subject: ATT, IPv6 and 6RD
In-Reply-To: <20120201135402.1eecd24d@kilo.billmerriam.com>
References: <20120201135402.1eecd24d@kilo.billmerriam.com>
Message-ID: <CALOgxGZ=V9sB2j90ACSj4uW3OvCH1ccenLh4Aigt1RkA94GvFw@mail.gmail.com>

On Wed, Feb 1, 2012 at 13:54, Bill Merriam <lists at billmerriam.com> wrote:

> I now have ATT IPv6 over their residential ADSL broadband.  They
> deployed using 6RD which means every time your IPv4 address changes
> your IPv6 address changes also.  Does anybody have a clue why they
> chose to use 6RD instead of the much more fully-assed TR-187 for their
> deployment?
>
>
My guess: 6RD pretty readily solves the last-5-miles / provisioning
problems - assuming the CPE supports it.  Oh, and they expect you to expect
your address to change.

Out of curiosity - are they giving you a single /64, or something more
reasonable / generous?
Also OOC - how is the IPv6/6RD throughput & latency, compared to
native/NATed IPv4?


/TJ

From paul4004 at gmail.com  Wed Feb  1 13:53:54 2012
From: paul4004 at gmail.com (PC)
Date: Wed, 1 Feb 2012 12:53:54 -0700
Subject: US DOJ victim letter
In-Reply-To: <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>
References: <201201201908.q0KJ8u6C045030@mail.r-bonomi.com>
 <CB482859.5D359%carlos@race.com>
 <20120127181626.GC21814@lab.pobox.com>
 <Pine.LNX.4.61.1201271503160.24418@soloth.lewis.org>
 <CAB+BaiO8RC-pan-GYPv7yJUc3CTk2SWapj8BN0-8morHzJiJyg@mail.gmail.com>
 <FE8E6728-7DDA-4CC6-8ADA-F448C53117DE@theflux.net>
Message-ID: <CAJAdsD=cnKjtsB2owLgq3zmeRZw66k5J+Ty891WP1xkTzfbZ0w@mail.gmail.com>

I received one on an IP block that were SWIPed to me.

Has anyone written a regular expression which matches the rogue dns server
IP ranges in question?

   - 85.255.112.0 through 85.255.127.255;
   - 67.210.0.0 through 67.210.15.255;
   - 93.188.160.0 through 93.188.167.255;
   - 77.67.83.0 through 77.67.83.255;
   - 213.109.64.0 through 213.109.79.255;
   - 64.28.176.0 through 64.28.191.255;



On Wed, Feb 1, 2012 at 8:32 AM, TFML <mailinglist at theflux.net> wrote:

> If the IP list is pointing to DNS servers, they maybe referring to the
> following:
>
> http://www.us-cert.gov/reading_room/DNS-recursion033006.pdf
>
> On Jan 31, 2012, at 7:38 PM, Phil Dyer wrote:
>
> > On Fri, Jan 27, 2012 at 3:23 PM, Jon Lewis <jlewis at lewis.org> wrote:
> >> On Fri, 27 Jan 2012, Bryan Horstmann-Allen wrote:
> >
> >>> Bit odd, if it's a phish. Even more odd if it's actually from the Fed.
> >>
> >>
> >> It's definitely real, but seems like they're handling it as
> incompetently as
> >> possible.
> >
> >
> > Yep. That sounds about right.
> >
> > Man, I'm feeling left out. I kinda want one now.
> >
> > phil
> >
>
>
>

From cmadams at hiwaay.net  Wed Feb  1 14:06:38 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:06:38 -0600
Subject: Console Server Recommendation
In-Reply-To: <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
References: <CALFTrnOinwxic_uz+AjpmnGq=ryTgupH5D5pexRt13bCTD07Ng@mail.gmail.com>
 <20120131091136.GA22047@pob.ytti.fi>
 <15445673-C219-467D-BB5F-98C873B04355@delong.com>
 <20120201073200.GA23107@pob.ytti.fi>
 <3C0E3475-9AEA-4418-A3B1-E9ABCA25CD93@delong.com>
Message-ID: <20120201200638.GD10680@hiwaay.net>

Once upon a time, Owen DeLong <owen at delong.com> said:
> I would hardly call conserver software a home-baked solution unless you'd
> also call anything based on OSS a "home-baked solution".

Console server hardware: buy appliance, plug it in, set password/IP
Home-baked box: buy server (or buy parts and assemble), buy a serial
   card (make sure it is supported by Linux/BSD distribution of choice),
   install/configure OS, install/configure console server software

Which one is worth my company's time for me to install?  If you are
going to install and maintain hundreds of them, the second might come
out ahead eventually (assuming you script the install/configure steps),
but the first is going to win almost all the time.

I build stuff for personal use, but at work, we look for canned
solutions to most needs.  I have a couple of Linux firewalls where I
wanted some extra flexibility, but we've got an Avocent console server
(of course, Avocent is also a customer, and it is good to give a
customer a little business).
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From drc at virtualized.org  Wed Feb  1 14:10:00 2012
From: drc at virtualized.org (David Conrad)
Date: Wed, 1 Feb 2012 12:10:00 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>

On Feb 1, 2012, at 10:16 AM, George Bonser wrote:

>>>> "We have a contractual relationship with our customer to announce
>>>> that space.  We have neither a contractual relationship (in this
>>>> context) with the RIR nor the RIR's customer.  The RIR and/or the RIR's
>>>> customer should resolve this issue with our customer."
>>> Contracts are generally not a valid reason to be breaking laws.
>> Which law?
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.

I'm told IP addresses aren't property.

> Or let's say I operated a TV station

As I understand it, radio frequencies are subject to international treaties. In signatory countries, laws can be enacted to enforce the provisions of those treaties. As far as I'm aware, there are no treaties dealing with IP addresses or how those addresses are announced.

> It might be civil rather than criminal but the rightful owner of the resource would have a good case.

"Owner"?

Long ago, Mitch Kapor (I believe) described the Internet addressing system working because of the "Tinkerbelle Effect", that is (to paraphase), it works because everyone believes it is in their best interests that it works.  However, as we've seen when push comes to shove, the Tinkerbelle Effect can break down.  Thus, you get perfectly justifiable arguments for stuff like RPKI/BGPSEC and the equivalent of the Protocol Police.  This does have the potential for unintended (and intended) consequences...

Regards,
-drc



From cmadams at hiwaay.net  Wed Feb  1 14:10:12 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:10:12 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <20120201201012.GE10680@hiwaay.net>

Once upon a time, George Bonser <gbonser at seven.com> said:
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.

That's covered under trespassing laws.

> Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.

That's covered under FCC regulations on use of public spectrum.

AFAIK there's no law covering the use of what party X considers their 32
bit numbers (assigned by party A) by party Y.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From nathan at atlasnetworks.us  Wed Feb  1 14:16:23 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Wed, 1 Feb 2012 20:16:23 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>

> AFAIK there's no law covering the use of what party X considers their
> 32 bit numbers (assigned by party A) by party Y.
 
So, to pose the obvious question: Should there be?

(I honestly don't know the answer is to this question, and am asking in earnest for opinions on the subject)

Nathan




From me at anuragbhatia.com  Wed Feb  1 14:25:03 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 2 Feb 2012 01:55:03 +0530
Subject: Question regarding anycasting in CDN setup
Message-ID: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>

Hello everyone!

I have a small question and was wondering if someone could help me with
that.

Question is - why companies like Google, Amazon are having partial
anycasting in CDN setups? E.g if we pick a random hostname from url of
Picasa picture - lh3.googleusercontent.com - this one is further a cname
string and at the end you will find different A records when checked from
different locations.

E.g when checked from my local system (in India):

;; QUESTION SECTION:
;lh3.googleusercontent.com. IN A

;; ANSWER SECTION:
lh3.googleusercontent.com. 86276 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 176 IN A 209.85.175.132





Next, lookup from a server in Europe:

;; QUESTION SECTION:
;lh3.googleusercontent.com. IN A

;; ANSWER SECTION:
lh3.googleusercontent.com. 86400 IN CNAME
googlehosted.l.googleusercontent.com.
googlehosted.l.googleusercontent.com. 300 IN A 209.85.148.132


thus different IPs in both cases.

I understand that Google is doing anycasting on core DNS servers, and thus
we always hit nearest DNS server and all DNS servers are sort of
independent and carry different A records for CDN strings which point to
local cache server IP addresses. And here's confirmation:

anurag at laptop:~$ dig googleusercontent.com. ns +short
ns2.google.com.
ns3.google.com.
ns4.google.com.
ns1.google.com.



Picking ns1.google.com. and asking IP for
googlehosted.l.googleusercontent.com. from different locations:

anurag at laptop:~$ dig @ns1.google.com googlehosted.l.googleusercontent.com.
a +short
209.85.175.132


anurag at server7:~$ dig @ns1.google.com googlehosted.l.googleusercontent.com.
a +short
209.85.148.132



As expected - same server (which appears same but is different) giving
different values - thus I am actually hitting different servers in both
cases.

Now my question here is - why this setup and not simply using having a A
record for googlehosted.l.googleusercontent.com. which comes from any
anycasted IP address space? Why not anycasting at CDN itself rather then
only at DNS layer?


Can someone explain?


Thanks!

-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From cmadams at hiwaay.net  Wed Feb  1 14:25:43 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Wed, 1 Feb 2012 14:25:43 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <20120201202543.GF10680@hiwaay.net>

Once upon a time, Nathan Eisenberg <nathan at atlasnetworks.us> said:
> > AFAIK there's no law covering the use of what party X considers their
> > 32 bit numbers (assigned by party A) by party Y.
>  
> So, to pose the obvious question: Should there be?
> 
> (I honestly don't know the answer is to this question, and am asking in earnest for opinions on the subject)

Personally, I'd rather see the networking community work it out
internally, rather than invite government intervention (I hardly think
it would stop at regulating 32/128 bit numbers).

Besides, how would that work?  Say ARIN assigns US company X (operating
only in the US) a block, but German company Y (with no US operations)
starts announcing the same block.  How are US or German laws going to
help, when the parties have no common jurisdiction?

There need to be better ways to notify (and get action from) upstreams,
upstreams/peers of upstreams, etc.  Since not all peering is public
knowledge, it can be difficult to know who needs notification, so some
type of clearinghouse would be good.  Maybe a mailing list, made up of
network operators, in some type of group, ... :-)

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From sethm at rollernet.us  Wed Feb  1 14:28:44 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 01 Feb 2012 12:28:44 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
Message-ID: <4F29A07C.1000400@rollernet.us>

On 2/1/12 10:16 AM, George Bonser wrote:
> 
> Let's say I had a business in space in a building I was leasing at 100 Main Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to a building up the block but put the 100 Main Street address on my new location and continued to use that address for my business.
> 
> Or let's say I operated a TV station on channel 37 that was allocated to you but you terminate my operating contract.  So I lease/erect a new transmitter and continue broadcasting on channel 37.
> 
> There obviously must be a remedy for two parties attempting to utilize the same resource at the same time, particularly when one party is the rightfully in control of that resource's use.  It might be civil rather than criminal but the rightful owner of the resource would have a good case.
> 

The FCC has teeth if someone decided to disregard them. There is no
analogue in the world of IP address assignments.

~Seth


From cgucker at onesc.net  Wed Feb  1 14:36:46 2012
From: cgucker at onesc.net (Charles Gucker)
Date: Wed, 1 Feb 2012 15:36:46 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <CALB2hAf74FzSA4zdiJ-YrT4o_94qWm28TQ5GrZN2Z0MhW+W57A@mail.gmail.com>

On Wed, Feb 1, 2012 at 3:25 PM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Hello everyone!
>
> I have a small question and was wondering if someone could help me with
> that.
>
> Question is - why companies like Google, Amazon are having partial
> anycasting in CDN setups? E.g if we pick a random hostname from url of
> Picasa picture - lh3.googleusercontent.com - this one is further a cname
> string and at the end you will find different A records when checked from
> different locations.

The simple answer for this is, Google cannot be expected to have a
local cache of every image supplied to them globally on every server.
 So they use unicast servers behind a DNS based geo load balancer
configuration.     As for DNS, every anycasted node is expected to be
able to resolve any DNS request that is made.

It's all a matter of disk and acceptable delay in providing the data
from the "closest" disk.

charles


From jared at puck.nether.net  Wed Feb  1 14:40:58 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 15:40:58 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <07DB7F4C-C4F1-4DAA-845E-075F63AFFC70@puck.nether.net>


On Feb 1, 2012, at 3:10 PM, Chris Adams wrote:

> AFAIK there's no law covering the use of what party X considers their 32
> bit numbers (assigned by party A) by party Y.

The US bankruptcy courts have treated these as property that can be
sold/transferred comparable to other assets.  (See threads re: borders,
microsoft, etc in 2011).

This does have the effect of being at least a cite in any further
litigation, even if the position is not upheld on appeal.

- Jared



From jared at puck.nether.net  Wed Feb  1 14:47:05 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 15:47:05 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <83650C5A-D243-4D1A-BDFD-C097417D6A05@puck.nether.net>


On Feb 1, 2012, at 3:25 PM, Anurag Bhatia wrote:

> I have a small question and was wondering if someone could help me with
> that.
> 
> Question is - why companies like Google, Amazon are having partial
> anycasting in CDN setups? E.g if we pick a random hostname from url of
> Picasa picture - lh3.googleusercontent.com - this one is further a cname
> string and at the end you will find different A records when checked from
> different locations.

The real answer to this is highly variable based on criteria that are unknown
by many people outside of the operators at these networks.

what is fairly well known:

1) Anycast can be used to provide low latency queries for stateless (UDP) and
   state full protocols (TCP).
2) Query responses will vary based on node hit and/or source IP address the
   query comes from.  Source address is used to attempt traffic localization.

   This can be defeated by using another resolver on purpose, or inadvertently
   (eg: corporate VPN may cause you to use a CDN node that is non-local by using
    corp DNS).
3) CDNs vary the response based upon uptime/load and other unknown policy criteria.
   They don't want to send you to a server that is down, nor one that is overloaded.

The secret is in the sauce here and is complex enough that it's not easy to perfect.

Also, be careful equating Anycast w/ CDN.  They are not the same thing but sometimes
are related.  (e.g.: cousins)

	- Jared

From gbonser at seven.com  Wed Feb  1 14:49:47 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 20:49:47 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <FABE3FD6-B5D4-4801-91FC-9B324D83FC46@virtualized.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F7DD@RWC-MBX1.corp.seven.com>

> 
> I'm told IP addresses aren't property.

Neither is the address painted on your curb.  So it's ok for me to paint over the number in front of your house and paint your house number on my curb, right?

The issue isn't about property.  It is about stealing an ADDRESS making impossible for the legitimate holder of that ADDRESS to do business.  




From gbonser at seven.com  Wed Feb  1 14:54:39 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 20:54:39 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F7FA@RWC-MBX1.corp.seven.com>

Take the ex-customer and their immediate upstream providers to small claims and sue each of them for the maximum amount for your time and trouble in dealing with the issue.  If they don't show, get a judgment and put a lien on their stuff until they pay up.

I am not a lawyer and I am not telling you what you should do, only saying what I would consider doing in such an instance.




From gbonser at seven.com  Wed Feb  1 15:00:55 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 21:00:55 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>

> So, to pose the obvious question: Should there be?
> 
> (I honestly don't know the answer is to this question, and am asking in
> earnest for opinions on the subject)
> 
> Nathan
> 
> 

Well, calling the law on someone is kind of the whiner's way out anyway.  It would seem that the community could agree on a set of standards for dealing with such problems and if you don't agree to those standards, nobody routes your traffic.  In other words, if network A finds network B announcing allocated space belonging to network A and network A makes them (network B) and their upstream provider(s) aware and they refuse to stop the announcement, there should be a mechanism by which the community can agree to filter Network B's AS  *and* the AS of the upstream(s) until the situation is rectified.  That's a pretty big hammer but verifying someone's legitimate claim on address space isn't that hard, in most cases.  




From ikiris at gmail.com  Wed Feb  1 15:07:01 2012
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 1 Feb 2012 15:07:01 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
Message-ID: <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>

On Wed, Feb 1, 2012 at 15:00, George Bonser <gbonser at seven.com> wrote:

> > So, to pose the obvious question: Should there be?
> >
> > (I honestly don't know the answer is to this question, and am asking in
> > earnest for opinions on the subject)
> >
> > Nathan
> >
> >
>
> Well, calling the law on someone is kind of the whiner's way out anyway.
>  It would seem that the community could agree on a set of standards for
> dealing with such problems and if you don't agree to those standards,
> nobody routes your traffic.  In other words, if network A finds network B
> announcing allocated space belonging to network A and network A makes them
> (network B) and their upstream provider(s) aware and they refuse to stop
> the announcement, there should be a mechanism by which the community can
> agree to filter Network B's AS  *and* the AS of the upstream(s) until the
> situation is rectified.  That's a pretty big hammer but verifying someone's
> legitimate claim on address space isn't that hard, in most cases.
>
>
The problem is no one will actually blacklist a big ASN because its not in
the individual best interest, which scales greatly with size. RPKI is
pretty much the only real fix for this if the chain until the major carrier
refuses to delist, and RPKI has it's own issues.

-Blake

From marka at isc.org  Wed Feb  1 15:13:44 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 02 Feb 2012 08:13:44 +1100
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: Your message of "Wed, 01 Feb 2012 14:10:12 MDT."
 <20120201201012.GE10680@hiwaay.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
Message-ID: <20120201211344.2B9291CA11AB@drugs.dv.isc.org>


In message <20120201201012.GE10680 at hiwaay.net>, Chris Adams writes:
> Once upon a time, George Bonser <gbonser at seven.com> said:
> > Let's say I had a business in space in a building I was leasing at 100 Main
>  Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to
>  a building up the block but put the 100 Main Street address on my new locati
> on and continued to use that address for my business.
> 
> That's covered under trespassing laws.
> 
> > Or let's say I operated a TV station on channel 37 that was allocated to yo
> u but you terminate my operating contract.  So I lease/erect a new transmitte
> r and continue broadcasting on channel 37.
> 
> That's covered under FCC regulations on use of public spectrum.
> 
> AFAIK there's no law covering the use of what party X considers their 32
> bit numbers (assigned by party A) by party Y.

If you present a false letter of authority you are committing fraud.
If you continue to use address after the lease is up it is trespass
/ theft / breach of contract.

I'm sure there are lots more laws that can apply.  Counterfieting,
wire fraud.  Breaches of various Telecommunication Acts, etc.  You
might have juristictional issues.

In the case of the Internet we have a authority for handing out
numbers for use on  the Internet (IANA).  Courts all over the world
do recognise that authority directly or indirectly by recognising
the RIRs.

There are enough analogs in common law to almost everything that
happens on the Internet for there to no be the need for specific
"Internet" laws.   It's just that having a "Internet" law makes it
easier to prosecute.

Mark
> -- 
> Chris Adams <cmadams at hiwaay.net> 
> Systems and Network Administrator - HiWAAY Internet Services 
> I don't speak for anybody but myself - that's enough trouble.  
>
-- 
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742
INTERNET: marka at isc.org


From gbonser at seven.com  Wed Feb  1 15:21:01 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 1 Feb 2012 21:21:01 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
 <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>

> The problem is no one will actually blacklist a big ASN because its not
> in the individual best interest, which scales greatly with size. RPKI
> is pretty much the only real fix for this if the chain until the major
> carrier refuses to delist, and RPKI has it's own issues.
> 
> -Blake

Sadly, you're right. But my guess is that such a blacklisting would have to be done for only a very short period of time and once it is done once or twice, it would never need to be done again.  But it probably is too big a hammer.

Until there is some sort of registry that is the source of truth and is easy to use (distributed?), we're going to keep repeating this process.  


From ikiris at gmail.com  Wed Feb  1 15:35:08 2012
From: ikiris at gmail.com (Blake Dunlap)
Date: Wed, 1 Feb 2012 15:35:08 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F823@RWC-MBX1.corp.seven.com>
 <CAJvB4tmLd1A53M76aimbO+uxenX5f8c9eppqpdF00t5niU5WXw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F87D@RWC-MBX1.corp.seven.com>
Message-ID: <CAJvB4tkUxu6jRBRUpjK2-mnEax4-=w8RVU2jqcsyseqSx-gdfw@mail.gmail.com>

On Wed, Feb 1, 2012 at 15:21, George Bonser <gbonser at seven.com> wrote:

> > The problem is no one will actually blacklist a big ASN because its not
> > in the individual best interest, which scales greatly with size. RPKI
> > is pretty much the only real fix for this if the chain until the major
> > carrier refuses to delist, and RPKI has it's own issues.
> >
> > -Blake
>
> Sadly, you're right. But my guess is that such a blacklisting would have
> to be done for only a very short period of time and once it is done once or
> twice, it would never need to be done again.  But it probably is too big a
> hammer.
>
> Until there is some sort of registry that is the source of truth and is
> easy to use (distributed?), we're going to keep repeating this process.
>
>
The issue isn't getting the AS blacklisted, the issue is getting people to
use the blacklist. Would you trust your router accepting entire ASNs to
someone else's list? Would your boss agree to allow others to shut down
access to a potentially major entity on the internet for something that
doesn't directly impact you?

I just don't see it ever happening, and anything short of that is no
deterrent for the above.

If you can't target the enablers with any kind of stick, then the only
other option is RPKI which prevents the actual hijack, but that has it's
own issues, due to the same benefits.

-Blake

From heather.schiller at verizon.com  Wed Feb  1 15:44:07 2012
From: heather.schiller at verizon.com (Schiller, Heather A)
Date: Wed, 1 Feb 2012 16:44:07 -0500
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
Message-ID: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>


AS8300 started announcing one of the Rove Digital dns changer IP ranges. (The IP ranges the FBI is sending 'you are infected' letters about)  Swisscom's announcement is less specific than the prefixes being announced by ISC during the remediation effort, so it's not impacting traffic... But AS8300 seems to announce less specifics a lot.  Last fall they announced 63/8 and half of that is allocated to 701. AFAIK, we weren't notified they were going to announce a less specific of our space.  As long as folks have pullup routes, and don't have an outage that withdraws their announcements, then Swisscom should only be getting darknet traffic.  The record for AS8300 says 'Test' and the entry for it in CIDR report says "This AS is not currently used to announce prefixes in the global routing table, nor is it used as a visible transit AS."  .. But their announcements certainly do show up in the global routing table, whether they are transiting for someone or not, they could get traffic for anything that doesn't have a more specific.  Given the recent YAHT (yet another hijack thread) it's worth pointing out that hijacking more specifics is bad, but less specifics can be bad as well. (Not suggesting that is the case here..)  

I searched around and couldn't find any mention of what they might be testing.  Anyone know?  

route-views>sh ip bgp 85.255.112.0/20
BGP routing table entry for 85.255.112.0/20, version 2177063753
Paths: (11 available, no best path)
  Not advertised to any peer
  6079 3303 8300 (history entry)
    207.172.6.20 from 207.172.6.20 (207.172.6.20)
      Origin IGP, metric 85, localpref 100, external
      Dampinfo: penalty 495, flapped 2 times in 00:24:37
  3277 3267 174 3303 8300 (history entry)
    194.85.102.33 from 194.85.102.33 (194.85.4.4)
      Origin IGP, localpref 100, external
      Community: 3277:3267 3277:65321 3277:65323 3277:65330
      Dampinfo: penalty 501, flapped 2 times in 00:24:22
....

 --Heather

From patrick at ianai.net  Wed Feb  1 16:01:19 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 1 Feb 2012 17:01:19 -0500
Subject: Extra Westin reservation
Message-ID: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>

Apparently I accidentally made two hotel reservations for the Westin Gas Lamp.  Made one, then thought I changed it, but just got confirmation I have two.

I have until 6 PM to cancel.  If you want it, ping me before 5 PM PST.

-- 
TTFN,
patrick



From jeroen at unfix.org  Wed Feb  1 16:12:36 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Wed, 01 Feb 2012 23:12:36 +0100
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
Message-ID: <4F29B8D4.6040603@unfix.org>

On 2012-02-01 22:44 , Schiller, Heather A wrote:
> 
> AS8300 started announcing one of the Rove Digital dns changer IP ranges.
[..]
> I searched around and couldn't find any mention of what they might be testing.  Anyone know?  

They do internal aggregation of common prefixes to keep their internal
tables small, see for instance this rather old preso:

http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

These prefixes should of course not be leaked outside their own network.

I would say, kick them either directly (yell offlist if you want direct
contacts) or spam the SwiNOG list and you will get a response quickly too.

Greets,
 Jeroen


From hmurray at megapathdsl.net  Wed Feb  1 16:14:02 2012
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 01 Feb 2012 14:14:02 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked 
 Networks)
In-Reply-To: Message from Christopher Morrow <morrowc.lists@gmail.com> of "Wed,
 01 Feb 2012 12:55:30 EST."
 <CAL9jLaZgKjCjzx__KTJw2CH1S5MyvzUu7c66VMkcP1hHQsz3Hw@mail.gmail.com>
Message-ID: <20120201221402.12950800037@ip-64-139-1-69.sjc.megapath.net>

>> Where is Milo Medin when we need him?
> how would he be helping?

He would have pulled the plug.

The story is from the very early days of the internet, probably long before 
NANOG existed.

Milo worked at NASA and found a cracker from Finland on one of NASAs 
machines.  The link from Finland to the rest of the world went through Norway 
to NASA.  (That's THE link, there was only one link connecting all of 
Scandinavia to the rest of the net.)  So Milo called the guy in Finland and 
said "Please fix it".  The reply was "We can't do anything.  We respect civil 
liberties."  Soon he got the message because  he wasn't connected to the net 
any more.

If anybody has a good URL for the story, please let me know.  I found one 
reference in google-books that said 1988.

-----

> AFAIK there's no law covering the use of what party X considers their 32 bit
> numbers (assigned by party A) by party Y.

Do contracts cover that?  I'd expect that the paperwork for peer-peer, 
customer-ISP and ISP-backbone links would include some nice broad legalese 
about not doing nasty things.


> Besides, how would that work?  Say ARIN assigns US company X (operating only
> in the US) a block, but German company Y (with no US operations) starts
> announcing the same block.  How are US or German laws going to help, when
> the parties have no common jurisdiction? 

The law could be written to apply to the company bringing the bogus 
announcements across the US border.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.





From jared at puck.nether.net  Wed Feb  1 16:22:11 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 1 Feb 2012 17:22:11 -0500
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <4F29B8D4.6040603@unfix.org>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
Message-ID: <F4F5570D-8696-4BBD-8D73-D14045FD1A60@puck.nether.net>


On Feb 1, 2012, at 5:12 PM, Jeroen Massar wrote:

> On 2012-02-01 22:44 , Schiller, Heather A wrote:
>> 
>> AS8300 started announcing one of the Rove Digital dns changer IP ranges.
> [..]
>> I searched around and couldn't find any mention of what they might be testing.  Anyone know?  
> 
> They do internal aggregation of common prefixes to keep their internal
> tables small, see for instance this rather old preso:
> 
> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
> 
> These prefixes should of course not be leaked outside their own network.
> 
> I would say, kick them either directly (yell offlist if you want direct
> contacts) or spam the SwiNOG list and you will get a response quickly too.

One could just filter their as-path from 701/702/703 in the interim to get them to address it.

- jared

From sethm at rollernet.us  Wed Feb  1 16:43:26 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Wed, 01 Feb 2012 14:43:26 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
Message-ID: <4F29C00E.4050704@rollernet.us>

On 2/1/12 1:13 PM, Mark Andrews wrote:
> In message <20120201201012.GE10680 at hiwaay.net>, Chris Adams writes:
>> Once upon a time, George Bonser <gbonser at seven.com> said:
>>> Let's say I had a business in space in a building I was leasing at 100 Main
>>  Street, Podunk, USA.  Now let's say you didn't renew the lease so I moved to
>>  a building up the block but put the 100 Main Street address on my new locati
>> on and continued to use that address for my business.
>>
>> That's covered under trespassing laws.
>>
>>> Or let's say I operated a TV station on channel 37 that was allocated to yo
>> u but you terminate my operating contract.  So I lease/erect a new transmitte
>> r and continue broadcasting on channel 37.
>>
>> That's covered under FCC regulations on use of public spectrum.
>>
>> AFAIK there's no law covering the use of what party X considers their 32
>> bit numbers (assigned by party A) by party Y.
> 
> If you present a false letter of authority you are committing fraud.
> If you continue to use address after the lease is up it is trespass
> / theft / breach of contract.
> 
> I'm sure there are lots more laws that can apply.  Counterfieting,
> wire fraud.  Breaches of various Telecommunication Acts, etc.  You
> might have juristictional issues.
> 
> In the case of the Internet we have a authority for handing out
> numbers for use on  the Internet (IANA).  Courts all over the world
> do recognise that authority directly or indirectly by recognising
> the RIRs.
> 
> There are enough analogs in common law to almost everything that
> happens on the Internet for there to no be the need for specific
> "Internet" laws.   It's just that having a "Internet" law makes it
> easier to prosecute.
> 


Phoenix NAP colluding to hijack address space and then balking when it
was brought to their attention is a perfect example someone could use to
say why "we" need to be regulated. And I'm sure it will eventually
happen again with different players. Either we all play nice and
self-regulate or someone else will start doing it for us, and probably
not in a way we'll be happy with but have to learn to live with.

~Seth


From patrick at ianai.net  Wed Feb  1 16:48:37 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Wed, 1 Feb 2012 17:48:37 -0500
Subject: Extra Westin reservation
In-Reply-To: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>
References: <606683D5-2BFF-438B-ADCC-28859D32D72B@ianai.net>
Message-ID: <ACCCA046-5E88-4F54-BC18-3EFAF094A303@ianai.net>

And it's gone.

-- 
TTFN,
patrick

On Feb 1, 2012, at 5:01 PM, Patrick W. Gilmore wrote:

> Apparently I accidentally made two hotel reservations for the Westin Gas Lamp.  Made one, then thought I changed it, but just got confirmation I have two.
> 
> I have until 6 PM to cancel.  If you want it, ping me before 5 PM PST.
> 
> -- 
> TTFN,
> patrick
> 



From ops.lists at gmail.com  Wed Feb  1 18:26:15 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 2 Feb 2012 05:56:15 +0530
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <4F29B8D4.6040603@unfix.org>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
Message-ID: <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>

It is "brilliant" because you can kiss goodbye to multihoming if you
have, say, a /24 that you want to hang off, say, L3 and cogent.

You'd get the covering L3 /9 announcement is all, visible to swisscom ..

On Thu, Feb 2, 2012 at 3:42 AM, Jeroen Massar <jeroen at unfix.org> wrote:
>
> They do internal aggregation of common prefixes to keep their internal
> tables small, see for instance this rather old preso:
>
> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mike at mikejones.in  Wed Feb  1 18:38:22 2012
From: mike at mikejones.in (Mike Jones)
Date: Thu, 2 Feb 2012 00:38:22 +0000
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
Message-ID: <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>

On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
<snip>
> Now my question here is - why this setup and not simply using having a A
> record for googlehosted.l.googleusercontent.com. which comes from any
> anycasted IP address space? Why not anycasting at CDN itself rather then
> only at DNS layer?

You are confusing anycasting with offering different results.

I can have an anycast DNS setup where all my servers give the same
response (example: most DNS providers), I can also have a single DNS
server give 192.0.2.80 out to queries sourced from a US IP Address,
198.51.100.80 for queries sourced from a German IP Address and
203.0.113.80 to queries sourced from a Chinese address (djbdns has a
module for this for example).

I would guess that google probably have a highly customised algorithm
which uses a combination of source IP and the node that your query
arrived at as part of the process for deciding what answer to give
you, along with dozens of other internal factors.

Although I do sometimes wonder why they use CNAME chains in cases
where the same servers are authoritative for the target name anyway.

If you were wondering why they direct you to the unicast addresses for
the local datacentre instead of just giving an anycast address which
your nearest datacentre would answer, well their algorithm might
decide that it wants to serve you content from the second closest
datacentre because the closest one is near capacity, anycast can't do
that.

- Mike


From annkwok80 at gmail.com  Wed Feb  1 08:32:22 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Wed, 1 Feb 2012 09:32:22 -0500
Subject: Question about prefix list
Message-ID: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>

Hi

I read this prefix list.

Can I know why there is "le 24" after network block in /22 and /21

Why don't have "le 24" after /24?

I also saw another prefix list before. They use "le 32" instead of  "le 24"

What are their different?

ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
ip prefix-list prefix-filter-as100 seq 50 permit 178.88.74.0/24

Thank you so much

From wouter at terrean.net  Wed Feb  1 19:43:37 2012
From: wouter at terrean.net (Wouter van der Vaart)
Date: Thu, 2 Feb 2012 02:43:37 +0100
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
References: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <9E8AB7C0-2031-49F7-8D5D-051AEF6FAAD7@terrean.net>

Hi Ann,

The le parameter can be included to match all more-specific prefixes within a par ten prefix up to a specified length. FE: 202.168.136.0/22 le 25 will match 202.168.136.0/22 and all prefixes contained therein with a length of 24 or less.

They appear to be blocking everything with a length longer dan /24 (so /25 /26 etc etc.)

the last line doesn't have this because it's only 1 /24 subnet.

Regards,

Wouter
On Feb 1, 2012, at 15:32 , Ann Kwok wrote:

> Hi
> 
> I read this prefix list.
> 
> Can I know why there is "le 24" after network block in /22 and /21
> 
> Why don't have "le 24" after /24?
> 
> I also saw another prefix list before. They use "le 32" instead of  "le 24"
> 
> What are their different?
> 
> ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
> ip prefix-list prefix-filter-as100 seq 50 permit 178.88.74.0/24
> 
> Thank you so much




From randy at psg.com  Wed Feb  1 19:50:32 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 10:50:32 +0900
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
 <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
Message-ID: <m2ehueatqv.wl%randy@psg.com>

> It is "brilliant" because you can kiss goodbye to multihoming if you
> have, say, a /24 that you want to hang off, say, L3 and cogent.
> 
> You'd get the covering L3 /9 announcement is all, visible to swisscom ..
> 
>> They do internal aggregation of common prefixes to keep their internal
>> tables small, see for instance this rather old preso:
>>
>> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt

why should swisscom pay for your traffic engineering?

randy


From rs at seastrom.com  Wed Feb  1 19:51:13 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Wed, 01 Feb 2012 20:51:13 -0500
Subject: This network is too good...
Message-ID: <86d39yknou.fsf@seastrom.com>


Hi all,

Any thoughts on products that screw up networks in deterministic (and
realistic found-in-the-wild) ways?  I'm thinking of stuff like
PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
whatever...

(I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
will screw up your whole network and you don't even have to configure
it to do so!")

I'm all-ears like Ross Perot.

Thanks,

-r



From randy at psg.com  Wed Feb  1 19:52:19 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 10:52:19 +0900
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
References: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <m2d39yatnw.wl%randy@psg.com>

> ip prefix-list prefix-filter-as100 seq 10 permit 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit 203,178.88.0/21 le 24
                                                      ^

randy


From bicknell at ufp.org  Wed Feb  1 20:21:35 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 1 Feb 2012 18:21:35 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <20120202022135.GA11800@ussenterprise.ufp.org>

In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E. Seastrom wrote:
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
> 
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")

The only good L2 solutions I've ever seen are expensive commercial
testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
easy to configure to simulate varous loss or latency patterns.

What tool is right depends on if you want to test at L2 (simulate a
circuit/cable with a particular problem) or L3 (just a router in the
middle dropping packets), or testing an end user application.  L2,
particularly if you want to simulate things like a duplex mismatch is
hard, and not often needed.

If your goal is to test applications against network conditions, OSX has
a nifty new tool, "Network Link Conditioner".  It's basically just
dummynet with various throughput, delay, and packet loss settings but it
makes it dead simple to select from various pull downs.

http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner

I bring it up mainly because if you want to set your own DummyNet
settings for other testing it's a nice database of average case
performance for a number of link types!

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120201/23977490/attachment-0001.bin>

From ops.lists at gmail.com  Wed Feb  1 20:26:18 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Thu, 2 Feb 2012 07:56:18 +0530
Subject: AS8300 - Swisscom hijacking.. Just what are you testing?
In-Reply-To: <m2ehueatqv.wl%randy@psg.com>
References: <B9EBD2474913AD4A995B8C7B8BEF8C0E14FD65EEC8@FHDP1LUMXC7V43.us.one.verizon.com>
 <4F29B8D4.6040603@unfix.org>
 <CAArzuoux-XaA9JGFdN5c8fyFhHrh1r1wcV4ghMEPgXvVCe89Nw@mail.gmail.com>
 <m2ehueatqv.wl%randy@psg.com>
Message-ID: <CAArzuouxfy+O5aMGcoOW5p7K0f5Qit1OHx0MDpwuKWMMYi2hbQ@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:20 AM, Randy Bush <randy at psg.com> wrote:
>>> They do internal aggregation of common prefixes to keep their internal
>>> tables small, see for instance this rather old preso:
>>>
>>> http://www.swinog.ch/meetings/swinog7/BGP_filtering-swinog.ppt
>
> why should swisscom pay for your traffic engineering?

Nobody at all is asking them to pay for it.  But do you seriously
expect their routing tables to become full to bursting because, for
example, they checked the ARIN route registry, RADB etc instead of
blindly using minimum prefix size defaults?

Or are swamp space legacy IP ranges with minimum prefix size of /24
that easy to get in this day and age?

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mysidia at gmail.com  Wed Feb  1 20:43:51 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 1 Feb 2012 20:43:51 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <4F29C00E.4050704@rollernet.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
Message-ID: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>

On Wed, Feb 1, 2012 at 4:43 PM, Seth Mattinen <sethm at rollernet.us> wrote:

> Phoenix NAP colluding to hijack address space and then balking when it
> was brought to their attention is a perfect example someone could use to
> say why "we" need to be regulated. And I'm sure it will eventually
>

There are always going to be some bad actors,  and some negligent
participants who get taken advantage of by bad actors.  There's no way to
guarantee a service provider capable of hijacking space does not fall into
the category of negligent facilitator.

Simple government regulation is of limited value, since the problem network
may be overseas.   Also,  separate networks that adhere to different rules
should  not have to follow the internet's conventions  --  if they want to
implement their own local variant of TCP/IP on their computers connected
over private connections but not connect to the internet, and therefore
follow their own address management system,  in a free society, people
should be free to do this with their computers;  the last thing we ever
need are governments mandating global uniqueness of IP addresses, ASN
numbers, Port numbers,  or other aspects of the engineering of private
computer networks.



I would say a service provider entering into a contractual relationship
with any other network that does not allow the service provider to make and
enforce their own network access TOS and routing policies and disconnect
downstream networks as necessary to protect network stability or comply
with upstream routing policies and what the RFCs and IANA say regarding
internet address management,  is negligent,  from the community's point of
view, in that they are not taking the reasonable care that is expected  and
necessary of service providers participating in the internet.



Agreement to implement RPKI by RIRs and  the RIR community would solve the
problem but has other drawbacks.


What the internet really needs is  Tier1 and Tier2 providers participating
in the internet who  "care", regardless of the popularity or size of
netblocks or issues involved.   And by "care", I mean,  providers
efficiently investigating reports of hijacking or rogue announcement,  and
taking switft responsible actions, without  bureaucratic processes
requiring   years   and reams of paperwork, or any attempt to shrug off
responsibility they have as intermediary.

--
-JH

From tmaufer at gmail.com  Wed Feb  1 21:05:24 2012
From: tmaufer at gmail.com (Thomas Maufer)
Date: Wed, 1 Feb 2012 19:05:24 -0800
Subject: This network is too good...
In-Reply-To: <20120202022135.GA11800@ussenterprise.ufp.org>
References: <86d39yknou.fsf@seastrom.com>
 <20120202022135.GA11800@ussenterprise.ufp.org>
Message-ID: <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>

IWL's "Maxwell" is probably what you want:

http://www.iwl.com/press-releases/new-capabilities-for-maxwell-the-network-impairment-system.html

Good luck breaking stuff!





On Wednesday, February 1, 2012, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E.
Seastrom wrote:
>> Any thoughts on products that screw up networks in deterministic (and
>> realistic found-in-the-wild) ways?  I'm thinking of stuff like
>> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
>> whatever...
>>
>> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
>> will screw up your whole network and you don't even have to configure
>> it to do so!")
>
> The only good L2 solutions I've ever seen are expensive commercial
> testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
> easy to configure to simulate varous loss or latency patterns.
>
> What tool is right depends on if you want to test at L2 (simulate a
> circuit/cable with a particular problem) or L3 (just a router in the
> middle dropping packets), or testing an end user application.  L2,
> particularly if you want to simulate things like a duplex mismatch is
> hard, and not often needed.
>
> If your goal is to test applications against network conditions, OSX has
> a nifty new tool, "Network Link Conditioner".  It's basically just
> dummynet with various throughput, delay, and packet loss settings but it
> makes it dead simple to select from various pull downs.
>
>
http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner
>
> I bring it up mainly because if you want to set your own DummyNet
> settings for other testing it's a nice database of average case
> performance for a number of link types!
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>

-- 

~tom

+1 408 890-7548 (Google Voice)

From streiner at cluebyfour.org  Wed Feb  1 21:25:01 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 1 Feb 2012 22:25:01 -0500 (EST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
 <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202012216140.27888@whammy.cluebyfour.org>

On Wed, 1 Feb 2012, Jimmy Hess wrote:

> What the internet really needs is  Tier1 and Tier2 providers participating
> in the internet who  "care", regardless of the popularity or size of
> netblocks or issues involved.   And by "care", I mean,  providers
> efficiently investigating reports of hijacking or rogue announcement,  and
> taking switft responsible actions, without  bureaucratic processes
> requiring   years   and reams of paperwork, or any attempt to shrug off
> responsibility they have as intermediary.

I agree completely, however the boondoggle in large networks often isn't 
the people in the trenches, it's the management buy-in that's often needed 
to take what could be perceived by non-technical types as as a risky 
(exposure to litigation or other legal/contractual entanglements) 
and unusual action of filtering out bad advertisement XYZ.  I've been 
through similar actions that ended up resulting in litigation. 
Depositions aren't fun.

In many big outfits like that, getting management to wrap their heads 
around something like this requires a cultural shift from the mindset 
where actions like this are usually initiated by legal/LEO action.

jms


From fernando at gont.com.ar  Wed Feb  1 21:38:09 2012
From: fernando at gont.com.ar (Fernando Gont)
Date: Thu, 02 Feb 2012 00:38:09 -0300
Subject: Fwd: IPv6 RA-Guard: Advice on the implementation (feedback requested)
Message-ID: <4F2A0521.7000100@gont.com.ar>

Folks,

Not sure if I had posted on this list about RA-Guard evasion issues.
Anyway...nowadays most implementations remain vulnerable.

If you care to get this fixed, please provide feedback about this I-D on
the IETF *v6ops* mailing-list <v6ops at ietf.org>, and CC me if possible
(please see below).

Thanks!

Best regards,
Fernando




-------- Original Message --------
Subject: RA-Guard: Advice on the implementation  (feedback requested)
Date: Wed, 01 Feb 2012 21:44:29 -0300
From: Fernando Gont <fgont at si6networks.com>
Organization: SI6 Networks
To: IPv6 Operations <v6ops at ietf.org>

Folks,

We have just published a revision of our I-D "Implementation Advice for
IPv6 Router Advertisement Guard (RA-Guard)"
<http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-implementation-01.txt>.

In essence, this is the problem statement, and what this I-D is about:

* RA-Guard is essential to have feature parity with IPv4.

* Most (all?) existing RA-Guard implementations can be trivially evaded:
if the attacker includes extension headers in his packets, the RA-Guard
devices fail to identify the Router Advertisement messages. -- For
instance, THC's "IPv6 attack suite" (<http://www.thc.org/thc-ipv6/>)
contains tools that can evade RA-Guard as indicated.

* The I-D discusses this problem, and provides advice on how to
implement RA-Guard, such that the aforementioned vulnerabilities are
eliminated, we have an effective RA-Guard device, and hence
feature-parity with IPv4.

We'd like feedback on this I-D, including high-level comments on whether
you support the proposal in this I-D.

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1





From randy at psg.com  Wed Feb  1 21:53:57 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 12:53:57 +0900
Subject: antisocial security
Message-ID: <m21uqdc2lm.wl%randy@psg.com>

from a stateside host

psg.com:/usr/home/randy> dig ssa.gov. ns

; <<>> DiG 9.4.3-P2 <<>> ssa.gov. ns
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37734
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;ssa.gov.                       IN      NS

;; ANSWER SECTION:
ssa.gov.                24370   IN      NS      dns1.ssa.gov.
ssa.gov.                24370   IN      NS      dns6.ssa.gov.
ssa.gov.                24370   IN      NS      dns5.ssa.gov.
ssa.gov.                24370   IN      NS      dns2.ssa.gov.

;; ADDITIONAL SECTION:
dns1.ssa.gov.           34072   IN      A       199.173.231.82
dns2.ssa.gov.           34073   IN      A       199.173.231.83
dns5.ssa.gov.           34073   IN      A       137.200.4.30
dns6.ssa.gov.           34074   IN      A       137.200.4.31

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Feb  2 03:45:15 2012
;; MSG SIZE  rcvd: 165

psg.com:/usr/home/randy> dig +short @199.173.231.82 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @199.173.231.83 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @137.200.4.30 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
psg.com:/usr/home/randy> dig +short @137.200.4.31 www.ssa.gov. any
www.socialsecurity.gov.
CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=

psg.com:/usr/home/randy> traceroute 199.173.231.82
traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 40 byte packets
 1  r0.sea.rg.net (147.28.0.4)  0.314 ms  1.224 ms  0.202 ms
 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.306 ms  0.349 ms
 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.355 ms  0.305 ms  0.228 ms
 4  144.232.3.126 (144.232.3.126)  0.352 ms  0.379 ms  0.353 ms
 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  14.365 ms  1.081 ms  1.075 ms
 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  1.097 ms  1.127 ms  1.082 ms
 7  0.ge-1-2-0.XT2.DCA6.ALTER.NET (152.63.40.46)  73.575 ms  73.635 ms  73.528 ms
 8  GigabitEthernet7-0-0.GW8.DCA6.ALTER.NET (152.63.40.81)  75.535 ms  75.595 ms  75.545 ms
 9  ssa-gw.customer.alter.net (152.179.9.34)  76.652 ms  76.522 ms  76.671 ms
10  * *^C
psg.com:/usr/home/randy> traceroute 137.200.4.30
traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 40 byte packets
 1  r0.sea.rg.net (147.28.0.4)  0.378 ms  0.253 ms  0.332 ms
 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.394 ms  0.339 ms
 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.348 ms  0.263 ms  0.214 ms
 4  144.232.3.126 (144.232.3.126)  66.830 ms  0.345 ms  0.323 ms
 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  0.977 ms  1.006 ms  1.100 ms
 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  26.587 ms  1.173 ms  1.086 ms
 7  0.ge-7-0-0.XL2.RDU1.ALTER.NET (152.63.33.38)  86.052 ms  86.084 ms  86.024 ms
 8  POS7-0.GW5.RDU1.ALTER.NET (152.63.35.177)  83.282 ms  83.371 ms  83.145 ms
 9  157.130.212.98 (157.130.212.98)  85.254 ms  84.998 ms  85.170 ms
10  137.200.1.123 (137.200.1.123)  92.646 ms  92.727 ms  92.762 ms
11  *^C

so they have a firewall, but i can get there.

but from tokyo

rair.psg.com:/Users/randy> dig +short @199.173.231.82 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @199.173.231.83 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @137.200.4.30 www.ssa.gov. any
;; connection timed out; no servers could be reached
rair.psg.com:/Users/randy> dig +short @137.200.4.31 www.ssa.gov. any
;; connection timed out; no servers could be reached


rair.psg.com:/Users/randy> traceroute 199.173.231.82
traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  5.528 ms  2.325 ms  2.504 ms
 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  6.912 ms  9.912 ms  11.519 ms
 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.684 ms  5.820 ms  5.621 ms
 4  tky001lip21.iij.net (210.149.34.101)  8.553 ms  6.054 ms  6.600 ms
 5  tky001bb10.iij.net (58.138.100.217)  5.350 ms  5.412 ms  5.058 ms
 6  tky001bf00.iij.net (58.138.80.1)  11.748 ms
    tky001bf01.iij.net (58.138.80.5)  5.268 ms  7.389 ms
 7  sjc002bf01.iij.net (216.98.96.62)  104.972 ms
    sjc002bf02.iij.net (206.132.169.109)  106.686 ms
    sjc002bf01.iij.net (216.98.96.62)  105.618 ms
 8  sjc002bb10.iij.net (206.132.169.2)  126.691 ms
    sjc002bb10.iij.net (206.132.169.6)  134.246 ms
    sjc002bb10.iij.net (206.132.169.10)  108.460 ms
 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  110.772 ms  109.116 ms  114.488 ms
10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  102.308 ms  106.149 ms  109.410 ms
11  0.so-7-3-0.xt2.dca6.alter.net (152.63.0.245)  187.469 ms  183.993 ms  194.484 ms
12  gigabitethernet7-0-0.gw8.dca6.alter.net (152.63.40.81)  259.830 ms  234.873 ms  186.634 ms
13  * * *
^C
rair.psg.com:/Users/randy> traceroute 137.200.4.30
traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  10.197 ms  1.979 ms  4.218 ms
 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  9.268 ms  6.284 ms  6.184 ms
 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.913 ms  10.127 ms  6.532 ms
 4  tky001lip21.iij.net (210.149.34.101)  7.983 ms  6.036 ms  6.199 ms
 5  tky001bb10.iij.net (58.138.100.217)  5.774 ms  21.691 ms  7.265 ms
 6  tky001bf01.iij.net (58.138.80.5)  9.906 ms
    tky008bf00.iij.net (58.138.80.9)  8.371 ms
    tky001bf01.iij.net (58.138.80.5)  5.930 ms
 7  sjc002bf00.iij.net (216.98.96.186)  117.184 ms  113.652 ms
    sjc002bf01.iij.net (216.98.96.62)  104.728 ms
 8  sjc002bb10.iij.net (206.132.169.10)  114.864 ms
    sjc002bb10.iij.net (206.132.169.6)  111.701 ms
    sjc002bb10.iij.net (206.132.169.10)  142.274 ms
 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  123.611 ms  115.159 ms  112.298 ms
10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  111.010 ms  104.429 ms  108.738 ms
11  0.so-1-2-0.xl2.rdu1.alter.net (152.63.27.38)  349.150 ms  209.448 ms  207.871 ms
12  pos7-0.gw5.rdu1.alter.net (152.63.35.177)  222.413 ms  208.135 ms  269.150 ms
13  * *^C

and, i noticed the problem because i can not get to the web site at
http://www.ssa.gov/ from tokyo.

randy


From randy_94108 at yahoo.com  Wed Feb  1 22:13:38 2012
From: randy_94108 at yahoo.com (Randy)
Date: Wed, 1 Feb 2012 20:13:38 -0800 (PST)
Subject: Question about prefix list
In-Reply-To: <CACwqZxjZwUDqbcB+PUM=0+noH9oWogtEeXPxAz_vLed68fxf8w@mail.gmail.com>
Message-ID: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>

Ann,
the commas not withstanding, the le/ge operands as applicable to prefix-lists simply mean "less-than or equal-to" or greater-than or "equal-to" wrt netmasks in CIDR speak.

In you prefix-list below, the le operand means -
allow following ranges:

/22,/23,/24 deny all else
for the /21
it means allow /21 thru /24

Anything without an operand means an exact-match(permit/deny)

Homework for you:

What do the following do:

1) ip prefix-list foo deny 0.0.0.0/0 le32
2) ip prefix-list foo permit 0.0.0/0 le 32

Understand the above and you will understand how operands work in prefix-lists.
./Randy


--- On Wed, 2/1/12, Ann Kwok <annkwok80 at gmail.com> wrote:

> From: Ann Kwok <annkwok80 at gmail.com>
> Subject: Question about prefix list
> To: nanog at nanog.org
> Date: Wednesday, February 1, 2012, 6:32 AM
> Hi
> 
> I read this prefix list.
> 
> Can I know why there is "le 24" after network block in /22
> and /21
> 
> Why don't have "le 24" after /24?
> 
> I also saw another prefix list before. They use "le 32"
> instead of? "le 24"
> 
> What are their different?
> 
> ip prefix-list prefix-filter-as100 seq 10 permit
> 202,168.136.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 20 permit
> 202,22.92.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 30 permit
> 202,21.148.0/22 le 24
> ip prefix-list prefix-filter-as100 seq 40 permit
> 203,178.88.0/21 le 24
> ip prefix-list prefix-filter-as100 seq 50 permit
> 178.88.74.0/24
> 
> Thank you so much
> 


From owen at delong.com  Wed Feb  1 22:54:17 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 1 Feb 2012 20:54:17 -0800
Subject: antisocial security
In-Reply-To: <m21uqdc2lm.wl%randy@psg.com>
References: <m21uqdc2lm.wl%randy@psg.com>
Message-ID: <D4C1B367-5E9D-4EF1-B41C-C23AEA9C539F@delong.com>

It's not uncommon (although I would agree it is ill advised) practice for some
web sites that think they cater only to an audience in a particular geography
to block access outside of that geography. I ran across this when my credit
union would not let me connect to their web server from S. Korea.

However, I took it up with the credit union rather than NANOG. Is there a
reason you bring this up here instead of with the SSA?

Owen

On Feb 1, 2012, at 7:53 PM, Randy Bush wrote:

> from a stateside host
> 
> psg.com:/usr/home/randy> dig ssa.gov. ns
> 
> ; <<>> DiG 9.4.3-P2 <<>> ssa.gov. ns
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37734
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
> 
> ;; QUESTION SECTION:
> ;ssa.gov.                       IN      NS
> 
> ;; ANSWER SECTION:
> ssa.gov.                24370   IN      NS      dns1.ssa.gov.
> ssa.gov.                24370   IN      NS      dns6.ssa.gov.
> ssa.gov.                24370   IN      NS      dns5.ssa.gov.
> ssa.gov.                24370   IN      NS      dns2.ssa.gov.
> 
> ;; ADDITIONAL SECTION:
> dns1.ssa.gov.           34072   IN      A       199.173.231.82
> dns2.ssa.gov.           34073   IN      A       199.173.231.83
> dns5.ssa.gov.           34073   IN      A       137.200.4.30
> dns6.ssa.gov.           34074   IN      A       137.200.4.31
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Feb  2 03:45:15 2012
> ;; MSG SIZE  rcvd: 165
> 
> psg.com:/usr/home/randy> dig +short @199.173.231.82 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @199.173.231.83 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @137.200.4.30 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> psg.com:/usr/home/randy> dig +short @137.200.4.31 www.ssa.gov. any
> www.socialsecurity.gov.
> CNAME 7 3 60 20120224201936 20120125195419 21905 ssa.gov. XSnBe3L3rTcD2FO778x43NOJaVf2OeMoSN8hBOSJFqfUfXAyH9qE5X1Q +tuRgigLs4qE7Fr40GI7SANxkltYdICJbEfvYikKMDW/hi8wp8mKHYQP SmXRGZz3ZizUaLb1DNTTWePIJDCrwEkZ5oVSEqoaV5xjDnWQ0twwILve I3Q=
> 
> psg.com:/usr/home/randy> traceroute 199.173.231.82
> traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 40 byte packets
> 1  r0.sea.rg.net (147.28.0.4)  0.314 ms  1.224 ms  0.202 ms
> 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.306 ms  0.349 ms
> 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.355 ms  0.305 ms  0.228 ms
> 4  144.232.3.126 (144.232.3.126)  0.352 ms  0.379 ms  0.353 ms
> 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  14.365 ms  1.081 ms  1.075 ms
> 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  1.097 ms  1.127 ms  1.082 ms
> 7  0.ge-1-2-0.XT2.DCA6.ALTER.NET (152.63.40.46)  73.575 ms  73.635 ms  73.528 ms
> 8  GigabitEthernet7-0-0.GW8.DCA6.ALTER.NET (152.63.40.81)  75.535 ms  75.595 ms  75.545 ms
> 9  ssa-gw.customer.alter.net (152.179.9.34)  76.652 ms  76.522 ms  76.671 ms
> 10  * *^C
> psg.com:/usr/home/randy> traceroute 137.200.4.30
> traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 40 byte packets
> 1  r0.sea.rg.net (147.28.0.4)  0.378 ms  0.253 ms  0.332 ms
> 2  r1.sea.rg.net (147.28.0.5)  0.340 ms  0.394 ms  0.339 ms
> 3  sl-gw20-sea-3-2-1.sprintlink.net (144.232.9.61)  0.348 ms  0.263 ms  0.214 ms
> 4  144.232.3.126 (144.232.3.126)  66.830 ms  0.345 ms  0.323 ms
> 5  0.xe-11-3-0.BR2.SEA7.ALTER.NET (204.255.168.217)  0.977 ms  1.006 ms  1.100 ms
> 6  0.ge-2-3-0.XT2.SEA7.ALTER.NET (152.63.104.21)  26.587 ms  1.173 ms  1.086 ms
> 7  0.ge-7-0-0.XL2.RDU1.ALTER.NET (152.63.33.38)  86.052 ms  86.084 ms  86.024 ms
> 8  POS7-0.GW5.RDU1.ALTER.NET (152.63.35.177)  83.282 ms  83.371 ms  83.145 ms
> 9  157.130.212.98 (157.130.212.98)  85.254 ms  84.998 ms  85.170 ms
> 10  137.200.1.123 (137.200.1.123)  92.646 ms  92.727 ms  92.762 ms
> 11  *^C
> 
> so they have a firewall, but i can get there.
> 
> but from tokyo
> 
> rair.psg.com:/Users/randy> dig +short @199.173.231.82 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @199.173.231.83 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @137.200.4.30 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> rair.psg.com:/Users/randy> dig +short @137.200.4.31 www.ssa.gov. any
> ;; connection timed out; no servers could be reached
> 
> 
> rair.psg.com:/Users/randy> traceroute 199.173.231.82
> traceroute to 199.173.231.82 (199.173.231.82), 64 hops max, 52 byte packets
> 1  192.168.0.1 (192.168.0.1)  5.528 ms  2.325 ms  2.504 ms
> 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  6.912 ms  9.912 ms  11.519 ms
> 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.684 ms  5.820 ms  5.621 ms
> 4  tky001lip21.iij.net (210.149.34.101)  8.553 ms  6.054 ms  6.600 ms
> 5  tky001bb10.iij.net (58.138.100.217)  5.350 ms  5.412 ms  5.058 ms
> 6  tky001bf00.iij.net (58.138.80.1)  11.748 ms
>    tky001bf01.iij.net (58.138.80.5)  5.268 ms  7.389 ms
> 7  sjc002bf01.iij.net (216.98.96.62)  104.972 ms
>    sjc002bf02.iij.net (206.132.169.109)  106.686 ms
>    sjc002bf01.iij.net (216.98.96.62)  105.618 ms
> 8  sjc002bb10.iij.net (206.132.169.2)  126.691 ms
>    sjc002bb10.iij.net (206.132.169.6)  134.246 ms
>    sjc002bb10.iij.net (206.132.169.10)  108.460 ms
> 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  110.772 ms  109.116 ms  114.488 ms
> 10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  102.308 ms  106.149 ms  109.410 ms
> 11  0.so-7-3-0.xt2.dca6.alter.net (152.63.0.245)  187.469 ms  183.993 ms  194.484 ms
> 12  gigabitethernet7-0-0.gw8.dca6.alter.net (152.63.40.81)  259.830 ms  234.873 ms  186.634 ms
> 13  * * *
> ^C
> rair.psg.com:/Users/randy> traceroute 137.200.4.30
> traceroute to 137.200.4.30 (137.200.4.30), 64 hops max, 52 byte packets
> 1  192.168.0.1 (192.168.0.1)  10.197 ms  1.979 ms  4.218 ms
> 2  tokyo10-f01.flets.2iij.net (210.149.34.66)  9.268 ms  6.284 ms  6.184 ms
> 3  tokyo10-ntteast1.flets.2iij.net (210.149.34.113)  5.913 ms  10.127 ms  6.532 ms
> 4  tky001lip21.iij.net (210.149.34.101)  7.983 ms  6.036 ms  6.199 ms
> 5  tky001bb10.iij.net (58.138.100.217)  5.774 ms  21.691 ms  7.265 ms
> 6  tky001bf01.iij.net (58.138.80.5)  9.906 ms
>    tky008bf00.iij.net (58.138.80.9)  8.371 ms
>    tky001bf01.iij.net (58.138.80.5)  5.930 ms
> 7  sjc002bf00.iij.net (216.98.96.186)  117.184 ms  113.652 ms
>    sjc002bf01.iij.net (216.98.96.62)  104.728 ms
> 8  sjc002bb10.iij.net (206.132.169.10)  114.864 ms
>    sjc002bb10.iij.net (206.132.169.6)  111.701 ms
>    sjc002bb10.iij.net (206.132.169.10)  142.274 ms
> 9  gigabitethernet1-1.gw2.sjc7.alter.net (152.179.48.1)  123.611 ms  115.159 ms  112.298 ms
> 10  0.so-0-0-1.xl4.sjc7.alter.net (152.63.51.50)  111.010 ms  104.429 ms  108.738 ms
> 11  0.so-1-2-0.xl2.rdu1.alter.net (152.63.27.38)  349.150 ms  209.448 ms  207.871 ms
> 12  pos7-0.gw5.rdu1.alter.net (152.63.35.177)  222.413 ms  208.135 ms  269.150 ms
> 13  * *^C
> 
> and, i noticed the problem because i can not get to the web site at
> http://www.ssa.gov/ from tokyo.
> 
> randy



From Erik.Amundson at oati.net  Wed Feb  1 23:05:09 2012
From: Erik.Amundson at oati.net (Erik Amundson)
Date: Wed, 1 Feb 2012 23:05:09 -0600
Subject: not excactly on-topic Server Cabinet question
Message-ID: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>

I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...

I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.

Does anyone sell anything like this?

I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.

Any suggestions?  Feel free to reply off-list.

- Erik


From medin at google.com  Thu Feb  2 01:37:29 2012
From: medin at google.com (Milo Medin)
Date: Wed, 1 Feb 2012 23:37:29 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
Message-ID: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>

>> Where is Milo Medin when we need him?

> how would he be helping?



He would have pulled the plug.



The story is from the very early days of the internet, probably long before

NANOG existed.



Milo worked at NASA and found a cracker from Finland on one of NASAs

machines.  The link from Finland to the rest of the world went through
Norway

to NASA.  (That's THE link, there was only one link connecting all of

Scandinavia to the rest of the net.)  So Milo called the guy in Finland and

said "Please fix it".  The reply was "We can't do anything.  We respect
civil

liberties."  Soon he got the message because  he wasn't connected to the
net

any more.



If anybody has a good URL for the story, please let me know.  I found one

reference in google-books that said 1988.



Hmm, is this how people talk about you after you are dead?  J



Dave Burstein dropped me a note about this thread ? I don?t usually follow
NANOG much these days.  So I figured I should respond to make sure all the
facts were straight.



Let me clarify what happened in the case of the Finnish idiot.  At the
time, I worked for NASA and among other things ran the root nameserver at
Ames (ns.nasa.gov).   We managed systems very tightly, and the root was
instrumented well and was notifying that someone at one of the larger
Finnish universities was trying the usual measures to break into the
machine.  We saw these all the time ? people tried the usual tftp or other
tricks, and moved on when they didn?t get satisfaction.  But this
particular individual just kept on trying different things over the course
of a couple days, and distinguished himself as being a real pain.



So I figured I needed to take some action.   I went to the NIC database,
and called up the University?s POC for the address block, saying that one
of their students was attempting to break into a US Government computing
resource (a criminal offense) and violating the AUP of the networks that
connected them.  They refused to act ? basically saying that they didn?t
feel bound by US law, blah blah, etc?  So then I called up the Nordunet
guys in Stockholm, who connected all Scandinavian countries together via a
128 Kbps link to the JVNC supercomputer center in Princeton.  As I recall,
no one returned my call or my emails, though Mats and company usually were
quite on the ball.



The probing was continuing on the root, so I decided to call my friend
Elise Gerich at the NSFnet, and ask her if she wouldn?t put in a null route
to the university in Finland in the core backbone network, figuring that
cutting off the connectivity to the university would get someone?s
attention.  She said that she would really prefer I call Sergio Heker at
Princeton, who managed the link and could install a null route there where
the link came in as a more targeted solution.



When I told Sergio what was happening (one of the root?s being attacked),
and that no one was doing anything about it, he said he would take care of
it.  Instead of installing a null route, he walked into the machine room
where the main JVNC nodes were located, walked to the satellite DSU that
connected JVNC to Stockholm, and pushed the loopback button.    So it is
really Sergio who deserves credit for this story, not me.  No more probes
on the root server.  J



I am told the following morning the grad student responsible for this was
met by a group of angry system administrators as he entered his office.
The conversation went like something this according to one of the people
there:



IT admin: Did you notice that the Internet is down today?

Student:  I noticed that ? is something broken with our connection?

IT admin:  In fact, not only our university can?t talk to the Internet,
 but no one in Finland can.

Student:  Oh, really?

IT admin: In fact, no one in all of Scandinavia can reach the Internet
today.

Student: Wow, that is a big problem.  Why are talking to me about it?

IT admin:  Because it is all YOUR fault! Stop messing around with those
NASA servers!



The connection was restored later that day, and no one from Finland tried
breaking into the root anymore, at least not while I was still there at
Ames.  I don?t believe the grad student was ever jailed, though I suspect
he may have needed a fresh set of underwear that day.  This is the story as
best as I can remember it, and it was around 1990 as opposed to 1988 as I
recall.



Back in the old days, people cared about policing bad behavior.  I could
tell you tons of stories where people had to take action to keep the
routing system safe from abuse.  If there was routing braindamage, people
would just fix it.  The old AUP served as the enforcement vehicle.  Now of
course things are much more complicated, and folks are less concerned with
?public health? than honoring contracts, etc?  But it was not always this
way.



Thanks,

Milo

From gbonser at seven.com  Thu Feb  2 01:53:53 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 2 Feb 2012 07:53:53 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>

> Back in the old days, people cared about policing bad behavior. 

And I believe that is all that is needed today.  We simply, as a community, need to decide that we aren't going to tolerate such behavior.  It really is that simple.  The problem seems to be getting people to act.  In fact, as this demonstrations, actions don't have to be taken often.  Generally, once the big hammer is used, it gets the point across.

Thank you, Milo, for being part of the solution.



From jaap at NLnetLabs.nl  Thu Feb  2 02:10:05 2012
From: jaap at NLnetLabs.nl (Jaap Akkerhuis)
Date: Thu, 02 Feb 2012 09:10:05 +0100
Subject: antisocial security
In-Reply-To: <m21uqdc2lm.wl%randy@psg.com>
References: <m21uqdc2lm.wl%randy@psg.com>
Message-ID: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>

    
    and, i noticed the problem because i can not get to the web site at
    http://www.ssa.gov/ from tokyo.
    
Lot's of .gov web sites are not available outside (at least what
somebody thinks is outside) the US.

	jaap


From randy at psg.com  Thu Feb  2 02:13:24 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 02 Feb 2012 17:13:24 +0900
Subject: antisocial security
In-Reply-To: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
Message-ID: <m2ipjpac0r.wl%randy@psg.com>

> Lot's of .gov web sites are not available outside (at least what
> somebody thinks is outside) the US.

it turns out to be local to my net segment ip space, we think.  it is
reachable from other networks in japan and even at least two other
segments in iij.

still debugging

randy


From goemon at anime.net  Thu Feb  2 02:12:20 2012
From: goemon at anime.net (goemon at anime.net)
Date: Thu, 2 Feb 2012 00:12:20 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <20120201211344.2B9291CA11AB@drugs.dv.isc.org>
 <4F29C00E.4050704@rollernet.us>
 <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202020010280.24668@sasami.anime.net>

On Wed, 1 Feb 2012, Jimmy Hess wrote:
> What the internet really needs is  Tier1 and Tier2 providers participating
> in the internet who  "care", regardless of the popularity or size of
> netblocks or issues involved.   And by "care", I mean,  providers
> efficiently investigating reports of hijacking or rogue announcement,  and
> taking switft responsible actions, without  bureaucratic processes
> requiring   years   and reams of paperwork, or any attempt to shrug off
> responsibility they have as intermediary.

caring doesn't make money. terminating abusive customers is lost revenue.

what needs to happen is retaining abusive customers needs to be more 
expensive than letting them go.

-Dan


From denys at visp.net.lb  Thu Feb  2 03:16:40 2012
From: denys at visp.net.lb (Denys Fedoryshchenko)
Date: Thu, 02 Feb 2012 11:16:40 +0200
Subject: antisocial security
In-Reply-To: <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
Message-ID: <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>

 On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
> and, i noticed the problem because i can not get to the web site at
>     http://www.ssa.gov/ from tokyo.
>
> Lot's of .gov web sites are not available outside (at least what
> somebody thinks is outside) the US.
>
> 	jaap
 Just tested:
 Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine

 ---
 System administrator
 Denys Fedoryshchenko
 Virtual ISP S.A.L.


From ffo at sesp.ch  Thu Feb  2 03:59:24 2012
From: ffo at sesp.ch (Florian Forster)
Date: Thu, 2 Feb 2012 09:59:24 +0000
Subject: AW: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <E620221E2BB25445BC0BD66F19DAD78623513E81@sesp12.sesp.ch>

Rittal can offer an electric lock system, we had those in combination with
legic cards
KABA made the card reader

Sry the link is in german
http://www.thede.de/uploads/media/B-Net_9106_TS8_de.pdf

greets


-----Urspr?ngliche Nachricht-----
Von: Erik Amundson [mailto:Erik.Amundson at oati.net] 
Gesendet: Donnerstag, 2. Februar 2012 06:05
An: nanog at nanog.org
Betreff: [SPAM] not excactly on-topic Server Cabinet question

I apologize for this being off-topic in the NANOG list, but I'm hoping some
of you have experience with the particulars of what I'm looking for...

I am looking for a server cabinet which has an electric latching mechanism
on it.  I want to use my existing security system and proximity card reader,
but have a cabinet door that would open when the card reader is read.

Does anyone sell anything like this?

I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via
Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.

Any suggestions?  Feel free to reply off-list.

- Erik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5595 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120202/8d9b4fe9/attachment.bin>

From rs at seastrom.com  Thu Feb  2 04:57:23 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Thu, 02 Feb 2012 05:57:23 -0500
Subject: US DOJ victim letter
In-Reply-To: <20120128163047.GA25420@vacation.karoshi.com.>
 (bmanning@vacation.karoshi.com's message of "Sat, 28 Jan 2012 16:30:47 +0000")
References: <30970.1327688588@turing-police.cc.vt.edu>
 <CB485770.5A9A7%nanog@hostleasing.net>
 <CAMDXq5OiJ-gXeZW=MmLCD_PznnHyGfHjiMs=i1k2e_b1-S27OA@mail.gmail.com>
 <20120128163047.GA25420@vacation.karoshi.com.>
Message-ID: <86wr85iju4.fsf@seastrom.com>


bmanning at vacation.karoshi.com writes:

> I missed the part where ARIN turned over its address database
> w/ associatedd registration information to the Fed ... I mean
> I've always advocated for LEO access, but ther has been
> significant pushback fromm the community on unfettered access
> to that data.  As I recall, there are even policies and
> processes to limit/restrict external queries to prevent a DDos
> of the whois servers.  And some fairly strict policies on who
> gets dumps of the address space.  As far as I know (not very
> far) bundling the address database -and- the registration data
> are not available to mere mortals.
>
> So - just how DID the Fed get the data w/o violating ARIN policy?

Hi Bill,

In case you're not trolling here (occam's razor says I'm giving you
too much credit), a few points:

   1) There has been substantial involvement by Federal LE at ARIN PPMs
   in terms of pushing for policy that makes WHOIS data more accurate...
   including one person who served on the ARIN AC after he went to work
   in the private sector.

   2) LE can type "show ip bgp" too and only needs to hit a whois server
   once per ASN.

   3) There is a bulk whois policy.  Whether "hi, we now have the
   reins of a compromised botnet or whatever and want to reach out to
   let people know that they're pwn3d" falls under the rubric of
   "Internet operational or technical research purposes pertaining to
   Internet operations" is left as an exercise to the reader.

   Section 3.1 of the NRPM says that Bulk Whois "... point of contact
   information will not include data marked as private."

   As I outlined in #2 above, a full or partial dump is not really
   something that's necessary.

   https://www.arin.net/resources/agreements/bulkwhois.pdf

I'm pretty confident there were no policy violations here.

-r



From bmanning at vacation.karoshi.com  Thu Feb  2 05:23:19 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 2 Feb 2012 11:23:19 +0000
Subject: US DOJ victim letter
In-Reply-To: <86wr85iju4.fsf@seastrom.com>
References: <30970.1327688588@turing-police.cc.vt.edu>
 <CB485770.5A9A7%nanog@hostleasing.net>
 <CAMDXq5OiJ-gXeZW=MmLCD_PznnHyGfHjiMs=i1k2e_b1-S27OA@mail.gmail.com>
 <20120128163047.GA25420@vacation.karoshi.com.> <86wr85iju4.fsf@seastrom.com>
Message-ID: <20120202112319.GA23067@vacation.karoshi.com.>

On Thu, Feb 02, 2012 at 05:57:23AM -0500, Robert E. Seastrom wrote:
> 
> bmanning at vacation.karoshi.com writes:
> 
> > I missed the part where ARIN turned over its address database
> > w/ associatedd registration information to the Fed ... I mean
> > I've always advocated for LEO access, but ther has been
> > significant pushback fromm the community on unfettered access
> > to that data.  As I recall, there are even policies and
> > processes to limit/restrict external queries to prevent a DDos
> > of the whois servers.  And some fairly strict policies on who
> > gets dumps of the address space.  As far as I know (not very
> > far) bundling the address database -and- the registration data
> > are not available to mere mortals.
> >
> > So - just how DID the Fed get the data w/o violating ARIN policy?
> 
> Hi Bill,
> 
> In case you're not trolling here (occam's razor says I'm giving you
> too much credit), a few points:
> 
>    1) There has been substantial involvement by Federal LE at ARIN PPMs
>    in terms of pushing for policy that makes WHOIS data more accurate...
>    including one person who served on the ARIN AC after he went to work
>    in the private sector.
> 
>    2) LE can type "show ip bgp" too and only needs to hit a whois server
>    once per ASN.
> 
>    3) There is a bulk whois policy.  Whether "hi, we now have the
>    reins of a compromised botnet or whatever and want to reach out to
>    let people know that they're pwn3d" falls under the rubric of
>    "Internet operational or technical research purposes pertaining to
>    Internet operations" is left as an exercise to the reader.
> 
>    Section 3.1 of the NRPM says that Bulk Whois "... point of contact
>    information will not include data marked as private."
> 
>    As I outlined in #2 above, a full or partial dump is not really
>    something that's necessary.
> 
>    https://www.arin.net/resources/agreements/bulkwhois.pdf
> 
> I'm pretty confident there were no policy violations here.
> 
> -r

	sigh... will have to look elsewhere for the tri-lateral commission.

/bill


From marka at isc.org  Thu Feb  2 06:08:14 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 02 Feb 2012 23:08:14 +1100
Subject: antisocial security
In-Reply-To: Your message of "Thu, 02 Feb 2012 11:16:40 +0200."
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
Message-ID: <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>


In message <f81ab141f9b5e72fe1e725230b2a7393 at visp.net.lb>, Denys Fedoryshchenko
 writes:
>  On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
> > and, i noticed the problem because i can not get to the web site at
> >     http://www.ssa.gov/ from tokyo.
> >
> > Lot's of .gov web sites are not available outside (at least what
> > somebody thinks is outside) the US.
> >
> > 	jaap
>  Just tested:
>  Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine

As is Australia.  I suspect it is just a "normal" snafu.
 
>  ---
>  System administrator
>  Denys Fedoryshchenko
>  Virtual ISP S.A.L.
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From sethm at rollernet.us  Thu Feb  2 10:03:55 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 02 Feb 2012 08:03:55 -0800
Subject: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <4F2AB3EB.9050905@rollernet.us>

On 2/1/12 9:05 PM, Erik Amundson wrote:
> I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...
> 
> I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.
> 
> Does anyone sell anything like this?
> 
> I've looked into Rittal, APC, Hoffman, Wrightline (now Eaton), Knurr (via Liebert/Emerson), Middle Atlantic, and Panduit.  So far, nothing.
> 
> Any suggestions?  Feel free to reply off-list.
> 

APC has it, but it's part of access control package AP9361 so I don't
know what the part number of the latch handle alone would be.

~Seth


From morrowc.lists at gmail.com  Thu Feb  2 11:20:41 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 2 Feb 2012 12:20:41 -0500
Subject: antisocial security
In-Reply-To: <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>
References: <m21uqdc2lm.wl%randy@psg.com>
 <201202020810.q128A5mY034136@bartok.nlnetlabs.nl>
 <f81ab141f9b5e72fe1e725230b2a7393@visp.net.lb>
 <20120202120814.DB34D1CC20E8@drugs.dv.isc.org>
Message-ID: <CAL9jLaZp=f+CAUue_kkcksS9BPk+L+wVy_hEd--TTMdy322MiA@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:08 AM, Mark Andrews <marka at isc.org> wrote:
>
> In message <f81ab141f9b5e72fe1e725230b2a7393 at visp.net.lb>, Denys Fedoryshchenko
> ?writes:
>> ?On Thu, 02 Feb 2012 09:10:05 +0100, Jaap Akkerhuis wrote:
>> > and, i noticed the problem because i can not get to the web site at
>> > ? ? http://www.ssa.gov/ from tokyo.
>> >
>> > Lot's of .gov web sites are not available outside (at least what
>> > somebody thinks is outside) the US.
>> >
>> > ? ? jaap
>> ?Just tested:
>> ?Lebanon, Greece, Saudi Arabia, Netherlands, Germany - all is fine
>
> As is Australia. ?I suspect it is just a "normal" snafu.

most likely this is a case of someone on the same /24 (or larger
supernet) where randy's machine lives at home 'hacked' (or port
scanned, or was used in a synflood or .... you get the point) one of
several US .gov assets :( 'eventually' that supernet should be removed
from filters.

-chris
weeee!


From rps at maine.edu  Thu Feb  2 11:32:44 2012
From: rps at maine.edu (Ray Soucy)
Date: Thu, 2 Feb 2012 12:32:44 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
Message-ID: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>

> So, to pose the obvious question: Should there be [a law against prefix hijacking]?




So far the track record of the US government trying to make laws
regarding technology and the Internet has been less than stellar.

The DMCA is already bad enough, but we continue to see things like
PROTECT IP and SOPA pop up in attempts to hand over even more control
of the Internet to those with enough money to buy the votes; at great
cost to service providers and universities, mind you.

Over the past few years it has become blatantly obvious that entire
industries are trying to gain special control over the Internet.  The
RIAA and the MPAA both being openly guilty:

"Candidly, those who count on quote 'Hollywood' for support need to
understand that this industry is watching very carefully who's going
to stand up for them when their job is at stake, don't ask me to write
a check for you when you think your job is at risk and then don't pay
any attention to me when my job is at stake."

Chris Dodd, CEO MPAA in response to Obama position on SOPA.

With attempts at government control of DNS already underway, I think
handing over control of BGP would be a dream come true for these guys.

No thank you,

I think the Internet is doing just fine.

If anything, I think we need the US government to roll back excessive
copyright and software patent law, and push for the repeal of the
DMCA.

Just my 5 cents.




-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From nathan at atlasnetworks.us  Thu Feb  2 12:23:09 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 2 Feb 2012 18:23:09 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B696683@ex-mb-1.corp.atlasnetworks.us>

> > So, to pose the obvious question: Should there be [a law against
> prefix hijacking]?

While I'm certain that's largely rooted in lawmakers who are not technically savvy, I wonder if we-as-an-industry couldn't (or, shouldn't) be doing more to move internal values and policies into defensible legal standards.

> So far the track record of the US government trying to make laws
> regarding technology and the Internet has been less than stellar.
> 
> The DMCA is already bad enough, but we continue to see things like
> PROTECT IP and SOPA pop up in attempts to hand over even more control
> of the Internet to those with enough money to buy the votes; at great
> cost to service providers and universities, mind you.

The best we-as-an-industry seem to be able to contribute to the problem is strongly worded and expertly backed petitions to Congress.  We're in permanent legislative fire-fighting mode, and we seem to be losing ground at an alarming pace.
 
> Over the past few years it has become blatantly obvious that entire
> industries are trying to gain special control over the Internet.  The
> RIAA and the MPAA both being openly guilty:
> 
> "Candidly, those who count on quote 'Hollywood' for support need to
> understand that this industry is watching very carefully who's going
> to stand up for them when their job is at stake, don't ask me to write
> a check for you when you think your job is at risk and then don't pay
> any attention to me when my job is at stake."
> 
> Chris Dodd, CEO MPAA in response to Obama position on SOPA.
 
You and I agree that this is a disturbing concept - I doubt there are many dissenting opinions on this list (which is its own monoculture issue for another day).

> With attempts at government control of DNS already underway, I think
> handing over control of BGP would be a dream come true for these guys.
 
Indeed - and I don't think anyone is suggesting that we hand operational control of BGP to the courts.  I'm more curious about legally codifying RIR allocations (obviously, this is a complex and regional issue, but since the two parties in the OP were both US based companies, we can at least begin to have this conversation).

Again, I don't know what the right answer is.  I'm just turning this over in my brain, and it seems to me that the current state of affairs is too fragile.  There is no 'drivers test' before you get your AS number.  There are few consequences for hijackers and the service providers who support them - especially if those providers are very large.  There is historical precedent for government regulation in non-virtual industries helping to curb the chaos.

Hypothesis: If operators could recover their damages via the legal system from a service provider for aiding and abetting the hijacking of their ARIN assigned space, it would encourage a great deal more due-diligence in the service provider space.  With nothing to gain, and money to lose, companies will expect their netops people to behave as good netizens.

Thoughts?

Nathan


From brunner at nic-naa.net  Thu Feb  2 12:58:36 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Thu, 02 Feb 2012 13:58:36 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
Message-ID: <4F2ADCDC.4070400@nic-naa.net>

On 2/2/12 12:32 PM, Ray Soucy wrote:
>> So, to pose the obvious question: Should there be [a law against prefix hijacking]?
> 
> 
> 
> So far the track record of the US government trying to make laws
> regarding technology and the Internet has been less than stellar.
...

While I agree with Ray's points, I want to point out that "new law" to
address (obvious pun) disruptive announcements may not be necessary --
at least, I blew off the better part of a day writing to Peter Dengate
Thrush and Rod Beckstrom that arbitrary bad acts in the public
addressing system were the proper concern of the entity tasked with
the technical coordination of unique endpoint identifiers.

I didn't expect much from the recipients -- I've known Peter too long
and never could be bothered to share Rod's twinkle, but while one
prefix announcement may harm one set of downstreams, rapid sustained
announcement and withdrawal will harm the DFZ, a much larger kettle of
digital fish.

One could claim that absent convergence limiting effect on the DFZ no
prefix bogosity has general adverse effect (but some prefixes are more
interesting than others, so that isn't a policy without nuances), and
enjoy watching the state actors and non-state actors and ordinary
venal idiots and very ordinary fatfingered idiots*
prepend/announce/withdraw with gleeful abandon, or one could assert
that autonomous reallocations of limited resources has general adverse
effect in addition to the local effect on downstreams, and associate
coordinated corrective reallocations with autonomous reallocations.
That's "pulling the plug" on retarded dictators, embezzlers, and the
latent mil-wits who view the DNS and BGP infrastructures as legitimate
military targets.

I don't expect progress overnight, in fact I wrote the former Chair
and current CEO of that "entity tasked with the technical coordination
of unique endpoint identifiers" with no expectations at all
(knowledge, supra), but policy response (including errors, see PIPA,
SOPA, et seq.) to bad acts in one set of identifiers can be extended
to policy response (including errors, resolvers have no monopoly on
errors) on the other set of identifiers.

So, new law? I don't think its necessary.

YMMV,
Eric


From gbonser at seven.com  Thu Feb  2 15:22:04 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 2 Feb 2012 21:22:04 +0000
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <4F2ADCDC.4070400@nic-naa.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
 <4F2ADCDC.4070400@nic-naa.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>

> 
> So, new law? I don't think its necessary.
> 
> YMMV,
> Eric


The problems are manifold.  First of all, a nation's laws only extend to the borders of that nation.  The UN is not a government, it is a diplomatic body so it really can't enact anything either.  The Internet community is global and if we agree to a certain standard of behavior and consequences for violating that standard, we can police it ourselves just fine.  The fundamental problem is there is no absolute "source of truth" in who is entitled to use which resource.  So there is little people can really do with any certainty until such a place exists.  What we need is a registry that we all agree is valid and agree to go by what it says and if you announce a route that belongs to someone else without their permission and you are made aware of that fact and continue to announce the route, you are subject to having your traffic shunned until you are in compliance.  That resource (the registry) should absolutely not be maintained by the UN or any government entity as that will make it unusable.  It is something the community has the technology to do, it just requires the resources and the will to do it.



From shacolby at bluejeans.com  Thu Feb  2 15:50:09 2012
From: shacolby at bluejeans.com (Shacolby Jackson)
Date: Thu, 2 Feb 2012 13:50:09 -0800
Subject: This network is too good...
In-Reply-To: <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>
References: <86d39yknou.fsf@seastrom.com>
 <20120202022135.GA11800@ussenterprise.ufp.org>
 <CA+HC509T_jyOV42ZXq220f1t5+_i9jP4Z6M=ADNaeHaMB02MnQ@mail.gmail.com>
Message-ID: <CACEOnk_tAQWc2iWB7Cpysw6RQC5Pq1gNVMO2cbebgM9rsN_xOQ@mail.gmail.com>

I know people who have been very happy with Apposite. They have a couple
different lines that can simulate a lot of different conditions.

http://www.apposite-tech.com

I know they call them WAN simulators but I know a company that strictly
uses them for layer2 to simulate congestion between switches, etc.


On Wed, Feb 1, 2012 at 7:05 PM, Thomas Maufer <tmaufer at gmail.com> wrote:

> IWL's "Maxwell" is probably what you want:
>
>
> http://www.iwl.com/press-releases/new-capabilities-for-maxwell-the-network-impairment-system.html
>
> Good luck breaking stuff!
>
>
>
>
>
> On Wednesday, February 1, 2012, Leo Bicknell <bicknell at ufp.org> wrote:
> > In a message written on Wed, Feb 01, 2012 at 08:51:13PM -0500, Robert E.
> Seastrom wrote:
> >> Any thoughts on products that screw up networks in deterministic (and
> >> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> >> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> >> whatever...
> >>
> >> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> >> will screw up your whole network and you don't even have to configure
> >> it to do so!")
> >
> > The only good L2 solutions I've ever seen are expensive commercial
> > testing.  DummyNet, on a L3 aware FreeBSD box is extremely useful and
> > easy to configure to simulate varous loss or latency patterns.
> >
> > What tool is right depends on if you want to test at L2 (simulate a
> > circuit/cable with a particular problem) or L3 (just a router in the
> > middle dropping packets), or testing an end user application.  L2,
> > particularly if you want to simulate things like a duplex mismatch is
> > hard, and not often needed.
> >
> > If your goal is to test applications against network conditions, OSX has
> > a nifty new tool, "Network Link Conditioner".  It's basically just
> > dummynet with various throughput, delay, and packet loss settings but it
> > makes it dead simple to select from various pull downs.
> >
> >
>
> http://www.thegeeksclub.com/simulate-internet-connectivity-speed-mac-os-lion-107-network-link-conditioner
> >
> > I bring it up mainly because if you want to set your own DummyNet
> > settings for other testing it's a nice database of average case
> > performance for a number of link types!
> >
> > --
> >       Leo Bicknell - bicknell at ufp.org - CCIE 3440
> >        PGP keys at http://www.ufp.org/~bicknell/
> >
>
> --
>
> ~tom
>
> +1 408 890-7548 (Google Voice)
>

From jra at baylink.com  Thu Feb  2 16:38:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 2 Feb 2012 17:38:57 -0500 (EST)
Subject: Verisign deep-hacked.  For months.
Message-ID: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>

Oh, my.

http://finance.yahoo.com/news/Key-Internet-operator-rb-2857339070.html

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


From zaid at zaidali.com  Thu Feb  2 17:30:40 2012
From: zaid at zaidali.com (Zaid Ali)
Date: Thu, 02 Feb 2012 15:30:40 -0800
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
Message-ID: <CB505A31.346A9%zaid@zaidali.com>

I love this

VeriSign said its executives "do not believe these attacks breached the
servers that support our Domain Name System network,"

"Oh my God," said Stewart Baker, former assistant secretary of the
Department of Homeland Security and before that the top lawyer at the
National Security Agency. "That could allow people to imitate almost any
company on the Net."

Sounds like another opportunity for <insert congress person> to propose
SOPA-2

Zaid  

On 2/2/12 2:38 PM, "Jay Ashworth" <jra at baylink.com> wrote:

>Oh, my.
>
>http://finance.yahoo.com/news/Key-Internet-operator-rb-2857339070.html
>
>Cheers,
>-- jra
>-- 
>Jay R. Ashworth                  Baylink
>jra at baylink.com
>Designer                     The Things I Think                       RFC
>2100
>Ashworth & Associates     http://baylink.pitas.com         2000 Land
>Rover DII
>St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
>1274
>




From kemp at network-services.uoregon.edu  Thu Feb  2 17:32:17 2012
From: kemp at network-services.uoregon.edu (John Kemp)
Date: Thu, 02 Feb 2012 15:32:17 -0800
Subject: new routeviews collector: TELX Atlanta
Message-ID: <4F2B1D01.2040702@network-services.uoregon.edu>


We just brought up a new collector at the
TELX Atlanta facility.    Peering information is at:
http://www.peeringdb.com/view.php?asn=6447&peerParticipantsPublics_mPage=2

    route-views.telxatl.routeviews.org

If anyone is interested an peering and sharing
full views, please e-mail us at help at routeviews.org.
Much thanks to the TELX guys.  They have gone
above and beyond in helping us get this going.

John Kemp (kemp at routeviews.org)
help at routeviews.org




From mysidia at gmail.com  Thu Feb  2 18:00:13 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 2 Feb 2012 18:00:13 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <alpine.LRH.2.02.1201311850380.2177@sol.manaikaika.com>
 <31D1D7E5-7548-4AB2-9051-1064DB7C8B4C@virtualized.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9F5BD@RWC-MBX1.corp.seven.com>
 <20120201201012.GE10680@hiwaay.net>
 <8C26A4FDAE599041A13EB499117D3C286B694AD0@ex-mb-1.corp.atlasnetworks.us>
 <CALFTrnP0pAtBJOJWTzzcad0hvq2_3DjferwOkckHqycT+sE_OQ@mail.gmail.com>
 <4F2ADCDC.4070400@nic-naa.net>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA152B@RWC-MBX1.corp.seven.com>
Message-ID: <CAAAwwbXs8gmQrxM_H9sdU_PoUGqf24uJmd7X0JWhLZZYEizWUw@mail.gmail.com>

On Thu, Feb 2, 2012 at 3:22 PM, George Bonser <gbonser at seven.com> wrote:


> The fundamental problem is there is no absolute "source of truth" in who
> is entitled to use which resource.
>

Well, the "absolute truth" would be the whois service maintained by the
RIRs, regarding who is the contact for what resource.

Now if we could only agree on one IRR for every region,   require
authorization by the RIR listed  contact   to  gain  the ability to create
IRR  entries for that resource,    and make publication of a route into the
IRR  an actual requirement,  we would have just that.


However,  it would be just as subject to  government interference,  in the
form of orders to the IRR database maintainer to delete certain networks.

-- 
-Mysid

From ops.lists at gmail.com  Thu Feb  2 18:26:17 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 3 Feb 2012 05:56:17 +0530
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CB505A31.346A9%zaid@zaidali.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
Message-ID: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>

So what part of VRSN got broken into?  They do a lot more than just DNS.

On Fri, Feb 3, 2012 at 5:00 AM, Zaid Ali <zaid at zaidali.com> wrote:
>
> VeriSign said its executives "do not believe these attacks breached the
> servers that support our Domain Name System network,"
>
> "Oh my God," said Stewart Baker, former assistant secretary of the
> Department of Homeland Security and before that the top lawyer at the
> National Security Agency. "That could allow people to imitate almost any
> company on the Net."



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From nanog-post at rsuc.gweep.net  Thu Feb  2 18:28:41 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Thu, 2 Feb 2012 19:28:41 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
Message-ID: <20120203002840.GA80793@gweep.net>

On Thu, Feb 02, 2012 at 07:53:53AM +0000, George Bonser wrote:
> > Back in the old days, people cared about policing bad behavior. 
> 
> And I believe that is all that is needed today.  We simply, as a
> community, need to decide that we aren't going to tolerate such
> behavior.  It really is that simple.  The problem seems to be getting
> people to act.  In fact, as this demonstrations, actions don't have
> to be taken often.  Generally, once the big hammer is used, it gets
> the point across.

The suits won, and many nerds either threw in with them or revealed 
their affinity for the easy life and gave up. Being principled and 
turning away dirty money or exercising the "fire the customer" clause 
tends to be disliked by corporate officers.


-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From jsw at inconcepts.biz  Thu Feb  2 18:34:37 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Thu, 2 Feb 2012 19:34:37 -0500
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
 <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
Message-ID: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>

On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
<ops.lists at gmail.com> wrote:
> So what part of VRSN got broken into? ?They do a lot more than just DNS.

Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
Illuminet is also in the business of recording telephone calls, SMS
messages, etc. for law enforcement.

That means that a "breach" at "VeriSign" could be nothing, or it could
give bad guys access to a lot more than any breach or leak reported to
date.  Who knows?
-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From zaid at zaidali.com  Thu Feb  2 18:42:27 2012
From: zaid at zaidali.com (Zaid Ali)
Date: Thu, 02 Feb 2012 16:42:27 -0800
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
Message-ID: <CB506D08.34718%zaid@zaidali.com>

That part is ambiguous at the moment since Verisign has not released
details. Symantec has bought the SSL part of the business and claim that
the SSL acquired network is not compromised. Sounds like lots of
assumptions being drawn.

Zaid

On 2/2/12 4:26 PM, "Suresh Ramasubramanian" <ops.lists at gmail.com> wrote:

>So what part of VRSN got broken into?  They do a lot more than just DNS.
>
>On Fri, Feb 3, 2012 at 5:00 AM, Zaid Ali <zaid at zaidali.com> wrote:
>>
>> VeriSign said its executives "do not believe these attacks breached the
>> servers that support our Domain Name System network,"
>>
>> "Oh my God," said Stewart Baker, former assistant secretary of the
>> Department of Homeland Security and before that the top lawyer at the
>> National Security Agency. "That could allow people to imitate almost any
>> company on the Net."
>
>
>
>-- 
>Suresh Ramasubramanian (ops.lists at gmail.com)




From johnl at iecc.com  Thu Feb  2 19:56:38 2012
From: johnl at iecc.com (John Levine)
Date: 3 Feb 2012 01:56:38 -0000
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120203015638.38650.qmail@joyce.lan>

See my new blog entry: 

World notices that Verisign said three months ago that they had a
security breach two years ago

http://jl.ly/2012/02/02#vrsnbreach

R's,
John


From randy at psg.com  Thu Feb  2 20:00:23 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 11:00:23 +0900
Subject: Verisign deep-hacked.  For months.
In-Reply-To: <20120203015638.38650.qmail@joyce.lan>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <20120203015638.38650.qmail@joyce.lan>
Message-ID: <m2ehuc7k20.wl%randy@psg.com>

At 3 Feb 2012 01:56:38 -0000, John Levine wrote:
> World notices that Verisign said three months ago that they had a
> security breach two years ago

i thought news was only supposed to be at eleven


From jcurran at arin.net  Thu Feb  2 20:02:01 2012
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2012 02:02:01 +0000
Subject: Regarding Hijacked Networks 
In-Reply-To: <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
Message-ID: <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>

On Jan 31, 2012, at 9:03 PM, Owen DeLong wrote:

> Not to put a damper on things, but, is there actually any law that precludes use of integers as internet addresses contrary to the registration data contained in RIR databases?

ARIN spends a bit of time on these types of questions.

The right to exclusive use a particular block Internet addresses is 
indeed provided by contract with ARIN, but the context is within the 
registration system itself.  We are not aware of any law in ARIN's 
service region which would preclude other parties from configuring 
equipment with any numbers they wish.  Note also - if someone thinks 
that they have a right of exclusive use of a particular block Internet 
addresses because of convictions that the addresses themselves are 
"property" (whatever that means), the outcome still doesn't change;
i.e. there is still no law or regulation as best we can determine 
which prevents someone from configuring their own equipment with 
any particular block of IP addresses... (and I would advise some
very careful thought before advocating that such be changed.[*])

In the end, the registry simple reflects a set of numbers managed for 
uniqueness by the policies set by the community.  Since the Internet 
relies on unique host identifiers, it's a pretty useful database, but 
that usefulness is predicated on people actually making use of it...
One would think that ISP's wouldn't accept routes accept from the 
parties not listed on an address block, but that is not universally 
the case, and correcting that other than at the point of injection
is rather problematic unless we have some relatively easy way to 
build, propagate, and verify routing assertions by the address 
holder (e.g. RPKI, as noted by Danny and Randy)

ARIN is slowly but steadily working on getting RPKI rolled out in 
production this year... folks interested in gaining some hands-on 
RPKI experience in the meantime can participate in ARIN's RPKI Pilot;
we have more than 50 organizations participating at this time - 
<https://www.arin.net/resources/rpki.html>

FYI,
/John

John Curran
President and CEO
ARIN

p.s.  [*] As previously noted in this discussion, address blocks may
      sometimes be hijacked based on acts that _are_ violation of law 
      (e.g fraud), but the mechanisms for dealing with such are quite 
      slow by default (at least in the US.)  That doesn't mean that 
      they can't work faster, but only that timeliness increases when 
      there are numerous harmed parties are plainly evident to the law 
      enforcement folks.  Given the potential impact from abuse or even 
      human error for any orders affecting the Internet, the delay may 
      even be an important feature of the present system.




From randy at psg.com  Thu Feb  2 20:57:37 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 11:57:37 +0900
Subject: Regarding Hijacked Networks 
In-Reply-To: <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
Message-ID: <m2aa507hem.wl%randy@psg.com>

my arin email addy and password work on the arin main web site.  they do
not work on https://rpki-pilot.arin.net/, pita

where is the trust anchor for the publication point published?

randy


From juuso.lehtinen at gmail.com  Thu Feb  2 21:01:33 2012
From: juuso.lehtinen at gmail.com (Juuso Lehtinen)
Date: Thu, 2 Feb 2012 19:01:33 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>

You have pretty much two approaches:
-Special built hardware network emulators
-Network emulator software running on generic PC

Special built HW:
If you need extreme accuracy, i.e., delay generation to micro/nanosecond
accuracy, you need to go with special purpose boxes. Special built HW also
usually provides line rate throughput, regardless of impairments you are
applying.

I have experience using Anue Systems GEM/XGEM and Calnex Paragon-X network
emulators. Both tools are special built hardware platforms that allow
generating various network impairments (delay, jitter, packet reordering,
packet loss, CRC errors, etc.).

In my opinion Anue is easier to use. It provides Web GUI where you can
configure different impairment profiles. Calnex on the other hand requires
you to install a Client software on your Windows PC. In the end, both
products support pretty much the same features. There are some differences
if you are doing specific testing with network synchronization protocols,
like SyncE or 1588v2 (PTPv2).

Network emulator SW on generic PC:
I have very little experience on running SW based network emulators. I used
to play with one that was running on Linux box - unfortunately I cannot
remember the software name. The linux software was ok for introducing
packet loss, but way inaccurate when it comes to delay insertion. If
accuracy of tens of milliseconds is good enough for you, the software based
approach might be good for you.

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:

>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r
>
>
>

From jcurran at arin.net  Thu Feb  2 21:13:48 2012
From: jcurran at arin.net (John Curran)
Date: Fri, 3 Feb 2012 03:13:48 +0000
Subject: Regarding Hijacked Networks 
In-Reply-To: <m2aa507hem.wl%randy@psg.com>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
 <m2aa507hem.wl%randy@psg.com>
Message-ID: <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>

On Feb 2, 2012, at 9:57 PM, Randy Bush wrote:

> my arin email addy and password work on the arin main web site.  they do
> not work on https://rpki-pilot.arin.net/, pita

Randy - 

That's correct for the pilot - follow the link at the top of the page which says: 
"If you don't have a log in and want to take part in this pilot, click [here].

Thanks,
/John

John Curran
President and CEO
ARIN




From JTyler at fiberutilities.com  Thu Feb  2 21:20:08 2012
From: JTyler at fiberutilities.com (Jensen Tyler)
Date: Thu, 2 Feb 2012 21:20:08 -0600
Subject: This network is too good...
In-Reply-To: <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>
References: <86d39yknou.fsf@seastrom.com>
 <CAF2UKmMOLZ7Vi+q0TYongmXZ6HUt+mEUmdQ6LyS3AjJLH15Krg@mail.gmail.com>
Message-ID: <1A8A762BD508624A8BDAB9F5E1638F94601CC98D0D@comsrv01.fg.local>

netem - http://www.linuxfoundation.org/collaborate/workgroups/networking/netem 

"netem provides Network Emulation functionality for testing protocols by emulating the properties of wide area networks. The current version emulates variable delay, loss, duplication and re-ordering." 

I have used this in the lab, works OK. You can use it with the bridge util to stay layer 2.

-----Original Message-----
From: Juuso Lehtinen [mailto:juuso.lehtinen at gmail.com] 
Sent: Thursday, February 02, 2012 9:02 PM
To: Robert E. Seastrom
Cc: nanog at nanog.org
Subject: Re: This network is too good...

You have pretty much two approaches:
-Special built hardware network emulators
-Network emulator software running on generic PC

Special built HW:
If you need extreme accuracy, i.e., delay generation to micro/nanosecond
accuracy, you need to go with special purpose boxes. Special built HW also
usually provides line rate throughput, regardless of impairments you are
applying.

I have experience using Anue Systems GEM/XGEM and Calnex Paragon-X network
emulators. Both tools are special built hardware platforms that allow
generating various network impairments (delay, jitter, packet reordering,
packet loss, CRC errors, etc.).

In my opinion Anue is easier to use. It provides Web GUI where you can
configure different impairment profiles. Calnex on the other hand requires
you to install a Client software on your Windows PC. In the end, both
products support pretty much the same features. There are some differences
if you are doing specific testing with network synchronization protocols,
like SyncE or 1588v2 (PTPv2).

Network emulator SW on generic PC:
I have very little experience on running SW based network emulators. I used
to play with one that was running on Linux box - unfortunately I cannot
remember the software name. The linux software was ok for introducing
packet loss, but way inaccurate when it comes to delay insertion. If
accuracy of tens of milliseconds is good enough for you, the software based
approach might be good for you.

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:

>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways?  I'm thinking of stuff like
> PacketStorm, Dummynet, etc.  Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r
>
>
>


From randy at psg.com  Thu Feb  2 21:24:21 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 12:24:21 +0900
Subject: Regarding Hijacked Networks 
In-Reply-To: <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>
References: <CANEysbFGHpDOYOEPou4o5jNzZ9G0qsJyW0PQgosagikQbEDaJQ@mail.gmail.com>
 <7B85F9D8-BA9E-4341-9242-5EB514895B4C@virtualized.org>
 <20120201015257.39A071C95D68@drugs.dv.isc.org>
 <65E48EB1-A51C-4C70-9629-CD7477D6877B@delong.com>
 <E7346720-1357-43E6-88CA-24AC5A99BAE9@corp.arin.net>
 <m2aa507hem.wl%randy@psg.com>
 <0AF293C9-4329-45DA-B34B-868BC6C84440@arin.net>
Message-ID: <m2obtg8uqi.wl%randy@psg.com>

>> my arin email addy and password work on the arin main web site.  they
>> do not work on https://rpki-pilot.arin.net/, pita
> That's correct for the pilot - follow the link at the top of the page
> which says: "If you don't have a log in and want to take part in this
> pilot, click [here].

been there, done that.  no tee shirt.  but more importantly, no trust
anchor!

randy


From dave.nanog at alfordmedia.com  Thu Feb  2 23:01:45 2012
From: dave.nanog at alfordmedia.com (Dave Pooser)
Date: Thu, 02 Feb 2012 23:01:45 -0600
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CAAAwwbVxtg3dVsNm-WSY7XJbjVjKd+hdSo-4bxB8vLQG=HpnRA@mail.gmail.com>
Message-ID: <CB50C437.863FE%dave.lists@alfordmedia.com>

On 2/1/12 8:43 PM, "Jimmy Hess" <mysidia at gmail.com> wrote:

>Simple government regulation is of limited value, since the problem
>network
>may be overseas.

So government regulation won't work....

>What the internet really needs is  Tier1 and Tier2 providers participating
>in the internet who  "care", regardless of the popularity or size of
>netblocks or issues involved.

...and all we need is for billion-dollar corporations to start putting
moral rectitude ahead of profits.

Well, heck, that should start happening any day now! And then FedEx will
deliver my unicorn!
</snark>

IMO, as long as the consequences for address hijacking boil down to "a
bunch of nerds will be unhappy with you," of COURSE we will continue to
see more hijackings. It's profitable (for spammers and other criminals)
and there is no shortage of sociopaths in this world. If there were a
chance of coordinated shunning of those upstreams that tolerate hijacking
then the moral rectitude/profits calculus would change, but there is no
such chance. So we're left with coordinated governmental action, RPKI, or
anarchy.

A thought experiment: Imagine this happens in IPv6 space. Absent the
element of scarcity, does it become simpler to just get more IPs for your
legitimate company than to spend time fighting with the thieves and their
collection of negligent or colluding upstreams? And what does that do for
the Internet if more and more companies decide to just abandon their V6
space to the squatters rather than contesting it?
-- 
DP




From goemon at anime.net  Thu Feb  2 23:06:02 2012
From: goemon at anime.net (goemon at anime.net)
Date: Thu, 2 Feb 2012 21:06:02 -0800 (PST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <20120203002840.GA80793@gweep.net>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
Message-ID: <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>

On Thu, 2 Feb 2012, Joe Provo wrote:
> The suits won, and many nerds either threw in with them or revealed
> their affinity for the easy life and gave up. Being principled and
> turning away dirty money or exercising the "fire the customer" clause
> tends to be disliked by corporate officers.

bottom line -- the only way to fix this problem is for bad behavior to 
become more expensive than good behavior. it's the only thing the pointy 
hairs will understand.

-Dan


From randy at psg.com  Thu Feb  2 23:59:35 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 14:59:35 +0900
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
Message-ID: <m2ipjo8njs.wl%randy@psg.com>

>> The suits won, and many nerds either threw in with them or revealed
>> their affinity for the easy life and gave up. Being principled and
>> turning away dirty money or exercising the "fire the customer" clause
>> tends to be disliked by corporate officers.
> bottom line -- the only way to fix this problem is for bad behavior to
> become more expensive than good behavior. it's the only thing the
> pointy hairs will understand.

i just love to read geeks discussing legal and financial solutions.
just about as educational as watching lawyers and cfos discussing
engineering.

seeing as we are purportedly engineers, perhaps we could discuss a
technical engineering approach to prefix misorigination?

randy


From joelja at bogus.com  Fri Feb  3 00:51:28 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 02 Feb 2012 22:51:28 -0800
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <m2ipjo8njs.wl%randy@psg.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com>
Message-ID: <4F2B83F0.2080600@bogus.com>

On 2/2/12 21:59 , Randy Bush wrote:
>>> The suits won, and many nerds either threw in with them or revealed
>>> their affinity for the easy life and gave up. Being principled and
>>> turning away dirty money or exercising the "fire the customer" clause
>>> tends to be disliked by corporate officers.
>> bottom line -- the only way to fix this problem is for bad behavior to
>> become more expensive than good behavior. it's the only thing the
>> pointy hairs will understand.
> 
> i just love to read geeks discussing legal and financial solutions.
> just about as educational as watching lawyers and cfos discussing
> engineering.
> 
> seeing as we are purportedly engineers, perhaps we could discuss a
> technical engineering approach to prefix misorigination?

I hear there's this thing called RPKI that does origin validation, it's
a shame that TCP MD5 shared secrets are already considered to hard to
manage in this community.

> randy
> 



From randy at psg.com  Fri Feb  3 01:02:03 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 03 Feb 2012 16:02:03 +0900
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <4F2B83F0.2080600@bogus.com>
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com> <4F2B83F0.2080600@bogus.com>
Message-ID: <m2bopg8kno.wl%randy@psg.com>

> I hear there's this thing called RPKI that does origin validation

<pedantic>

well, not exactly.  to quote myself from the other week in another forum

--

Just to be clear, as people keep calling BGP security 'RPKI'

In the current taxonomy, there are three pieces, the RPKI, RPKI-based
origin validation, and then path validation.

RPKI is the X.509 based hierarchy with is congruent with the internet IP
address allocation administration, the IANA, RIRS, ISPs, ...  It is the
substrate on which the next two are based.  It is currently deployed in
four of the five administrative regions, ARIN in North America being the
sad and embarrassing exception.

RPKI-based origin validation uses some of the RPKI data to allow a
router to verify that the autonomous system announcing an IP address
prefix is in fact authorized to do so.  This is not crypto checked so
can be violated.  But it prevents the vast majority of accidental
'hijackings' on the internet today, e.g. the famous Pakastani accidental
announcement of YouTube's address space.  RPKI-based origin validation
is in shipping code from Cisco, and will be shipping by Juniper in q2.

Path validation uses the full crypto information of the RPKI to make up
for the embarrassing mistake that, like much of the internet BGP was
designed with no thought to securing the BGP protocol itself from being
gamed/violated.  It allows a receiver of a BGP announcement to formally
cryptographically validate that the originating autonomous system was
truely authorized to announce the IP address prefix, and that the
systems through which the announcement passed were indeed those which
the sender/forwarder at each hop intended.

Sorry to drone on, but these three really need to be differentiated.

randy


From aservin at lacnic.net  Fri Feb  3 06:16:01 2012
From: aservin at lacnic.net (Arturo Servin)
Date: Fri, 3 Feb 2012 10:16:01 -0200
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
Message-ID: <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>


	One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors.

	We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are "signed" but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies:

http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/

http://www.labs.lacnic.net/rpkitools/looking_glass/


Regards,
-as
	

On 1 Feb 2012, at 06:58, Kelvin Williams wrote:

> First off, I'd like to thank everyone on this list who have reached out
> today and offered us help with our hijacked network space.  It's so
> refreshing to see that there are still so many who refuse to leave a
> man/woman down.
> 
> I'm not going to place any blame, its useless.  There were lies, there were
> incompetencies, and there was negligence but that is now water under the
> bridge.
> 
> However, I think that we as network operators have a duty to each other to
> make sure we don't allow a downstream customer wreck the operations of
> another entity who has been rightfully allocated resources.
> 
> A few months ago, when establishing a new peering relationship I was
> encouraged (actually required) to utilize one of the IRRs.  I took the time
> to register all of my routes, ASNs, etc.  However, as I learned today, this
> was probably done in vain.  Too many people won't spend the extra
> 30-seconds to verify the information listed there or in ARINs WHOIS.
> 
> I don't care what a customer tells me, too many times I've found they
> aren't 100% honest either for malicious/fraudulent reasons or they are
> unknowing.  So, for our networks or the networks we manage, we want to
> verify what a customer is saying to prevent what happened to us today.
> 
> I'd like to get a conversation going and possibly some support of an
> initiative to spend that extra 30-seconds to verify ownership and
> authorization of network space to be advertised.  Additionally, if someone
> rings your NOC's line an industry-standard process of verifying "ownership"
> and immediately responding by filtering out announcements. There's no sense
> in allowing a service provider to be impaired because a spammer doesn't
> want to give up clean IP space.  Do you protect a bad customer or the
> Internet as a whole?  I pick the Internet as a whole.
> 
> How can we prevent anyone else from ever enduring this again?  While we may
> never stop it from ever happening, spammers (that's what we got hit by
> today) are a dime a dozen and will do everything possible to hit an Inbox,
> so how can we establish a protocol to immediate mitigate the effects of an
> traffic-stopping advertisement?
> 
> I thought registering with IRRs and up-to-date information in ARINs WHOIS
> was sufficient, apparently I was wrong.  Not everyone respects them, but
> then again, they aren't very well managed (I've got several networks with
> antiquated information I've been unable to remove, it doesn't impair us
> normally, but its still there).
> 
> What can we do?  Better yet, how do we as a whole respond when we encounter
> upstream providers who refuse to look at the facts and allow another to
> stay down?
> 
> kw
> 
> -- 
> Kelvin Williams
> Sr. Service Delivery Engineer
> Broadband & Carrier Services
> Altus Communications Group, Inc.
> 
> 
> "If you only have a hammer, you tend to see every problem as a nail." --
> Abraham Maslow


From rs at seastrom.com  Fri Feb  3 06:59:30 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Fri, 03 Feb 2012 07:59:30 -0500
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
In-Reply-To: <m2bopg8kno.wl%randy@psg.com> (Randy Bush's message of "Fri,
 03 Feb 2012 16:02:03 +0900")
References: <CAF=Lu+YGvXSkODidSMhaaEXsq++KQu8m8sh3fn9T5Mrq83f+xQ@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CA017E@RWC-MBX1.corp.seven.com>
 <20120203002840.GA80793@gweep.net>
 <Pine.LNX.4.64.1202022105160.32170@sasami.anime.net>
 <m2ipjo8njs.wl%randy@psg.com> <4F2B83F0.2080600@bogus.com>
 <m2bopg8kno.wl%randy@psg.com>
Message-ID: <86mx90xebx.fsf@seastrom.com>


Randy Bush <randy at psg.com> writes:

> well, not exactly.  to quote myself from the other week in another forum
>
> [ 30 lines deleted ]
>
> Sorry to drone on, but these three really need to be differentiated.

The truly wonderful thing about the evolution of BGP security is its
elegant simplicity.  It is good to know that the barriers to entry for
the IRR system (templates, objects, "Dear Colleague" emails from the
auto-dbm robot, etc) have been eradicated in favor of simple,
easy-to-understand and maintain maintain digital certificate chains.
I predict epic uptake the likes of which we haven't seen since I filed
my last NACR.

-r



From richard.barnes at gmail.com  Fri Feb  3 07:09:43 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 3 Feb 2012 08:09:43 -0500
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>
Message-ID: <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html>
<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209>



On Fri, Feb 3, 2012 at 7:16 AM, Arturo Servin <aservin at lacnic.net> wrote:
>
> ? ? ? ?One option is to use RPKI and origin validation. But it won't help much unless prefix holders create their certificates and ROAs and networks operators use those to validate origins. It won't solve all the issues but at least some fat fingers/un-expierience errors.
>
> ? ? ? ?We are running an experiment to detect route-hijacks/missconf using RPKI. So far, not many routes are "signed" but at least we can periodically check our own prefix (or any other with ROAs) to detect some inconsistencies:
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/rest/all/pfx/200.7.84.0/
>
> http://www.labs.lacnic.net/rpkitools/looking_glass/
>
>
> Regards,
> -as
>
>
> On 1 Feb 2012, at 06:58, Kelvin Williams wrote:
>
>> First off, I'd like to thank everyone on this list who have reached out
>> today and offered us help with our hijacked network space. ?It's so
>> refreshing to see that there are still so many who refuse to leave a
>> man/woman down.
>>
>> I'm not going to place any blame, its useless. ?There were lies, there were
>> incompetencies, and there was negligence but that is now water under the
>> bridge.
>>
>> However, I think that we as network operators have a duty to each other to
>> make sure we don't allow a downstream customer wreck the operations of
>> another entity who has been rightfully allocated resources.
>>
>> A few months ago, when establishing a new peering relationship I was
>> encouraged (actually required) to utilize one of the IRRs. ?I took the time
>> to register all of my routes, ASNs, etc. ?However, as I learned today, this
>> was probably done in vain. ?Too many people won't spend the extra
>> 30-seconds to verify the information listed there or in ARINs WHOIS.
>>
>> I don't care what a customer tells me, too many times I've found they
>> aren't 100% honest either for malicious/fraudulent reasons or they are
>> unknowing. ?So, for our networks or the networks we manage, we want to
>> verify what a customer is saying to prevent what happened to us today.
>>
>> I'd like to get a conversation going and possibly some support of an
>> initiative to spend that extra 30-seconds to verify ownership and
>> authorization of network space to be advertised. ?Additionally, if someone
>> rings your NOC's line an industry-standard process of verifying "ownership"
>> and immediately responding by filtering out announcements. There's no sense
>> in allowing a service provider to be impaired because a spammer doesn't
>> want to give up clean IP space. ?Do you protect a bad customer or the
>> Internet as a whole? ?I pick the Internet as a whole.
>>
>> How can we prevent anyone else from ever enduring this again? ?While we may
>> never stop it from ever happening, spammers (that's what we got hit by
>> today) are a dime a dozen and will do everything possible to hit an Inbox,
>> so how can we establish a protocol to immediate mitigate the effects of an
>> traffic-stopping advertisement?
>>
>> I thought registering with IRRs and up-to-date information in ARINs WHOIS
>> was sufficient, apparently I was wrong. ?Not everyone respects them, but
>> then again, they aren't very well managed (I've got several networks with
>> antiquated information I've been unable to remove, it doesn't impair us
>> normally, but its still there).
>>
>> What can we do? ?Better yet, how do we as a whole respond when we encounter
>> upstream providers who refuse to look at the facts and allow another to
>> stay down?
>>
>> kw
>>
>> --
>> Kelvin Williams
>> Sr. Service Delivery Engineer
>> Broadband & Carrier Services
>> Altus Communications Group, Inc.
>>
>>
>> "If you only have a hammer, you tend to see every problem as a nail." --
>> Abraham Maslow
>


From streiner at cluebyfour.org  Fri Feb  3 08:25:29 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 3 Feb 2012 09:25:29 -0500 (EST)
Subject: [#135346] Unauthorized BGP Announcements (follow up to Hijacked
 Networks)
In-Reply-To: <CB50C437.863FE%dave.lists@alfordmedia.com>
References: <CB50C437.863FE%dave.lists@alfordmedia.com>
Message-ID: <Pine.LNX.4.64.1202030923480.5976@whammy.cluebyfour.org>

On Thu, 2 Feb 2012, Dave Pooser wrote:

> ...and all we need is for billion-dollar corporations to start putting
> moral rectitude ahead of profits.
>
> Well, heck, that should start happening any day now! And then FedEx will
> deliver my unicorn!
> </snark>

Your unicorn has been impounded by Customs.

jms


From jra at baylink.com  Fri Feb  3 09:31:05 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 3 Feb 2012 10:31:05 -0500 (EST)
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
Message-ID: <29407925.356.1328283065834.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jeff Wheeler" <jsw at inconcepts.biz>

> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
> <ops.lists at gmail.com> wrote:
> > So what part of VRSN got broken into? They do a lot more than just
> > DNS.
> 
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

"Illuminet"?

Shea and Wilson would be proud.

Cheers,
-- jr 'and somewhere, an evil geek is dry-washing his hands' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From bmanning at vacation.karoshi.com  Fri Feb  3 10:09:39 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Fri, 3 Feb 2012 16:09:39 +0000
Subject: [POLITICS] ICANN elections
Message-ID: <20120203160939.GA5520@vacation.karoshi.com.>


There are four really good candidates.  Please consider sending in a statement of
support for one of them.

/bill

----- Forwarded message -----

Date: Fri, 03 Feb 2012 09:38:06 +1000
To: Bill Manning <bmanning at karoshi.com>
Subject: Comment Period for ICANN Board Seat 9 Election

Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
the Address Supporting Organization Address Council (ASO AC) is
responsible for the appointment of a representative to serve on Seat
Number 9 of the ICANN Board.

The ASO AC is pleased to announce the following four candidates for its
upcoming appointment.

The Candidates are:

    - Thomas Eric Brunner-Williams
    - Martin J. Levy
    - William Manning
    - Raymond Alan Plzak

In accordance with the ASO AC election procedures, a comment period is
now open. A short biography is available and supporting comment
facilities for each candidate may be found at:

http://aso.icann.org/people/icann-board-elections/2012-elections/

The comment period will close at 23:59 UTC on 19 April 2012. Comments
will be moderated.

ASO Secretariat
secretariat at aso.icann.org

----- End forwarded message -----


From rubensk at gmail.com  Fri Feb  3 10:40:13 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Fri, 3 Feb 2012 14:40:13 -0200
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
References: <20670730.288.1328222336994.JavaMail.root@benjamin.baylink.com>
 <CB505A31.346A9%zaid@zaidali.com>
 <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
 <CAPWAtb+Eyjm6uszO38LAArY46mh_T7F-nrmtaLggN=j3d29SUw@mail.gmail.com>
Message-ID: <CAGFn2k0FyweJS_8TMzY22s2O0xzFaW6jeOVKth=7OVFVSq7=WQ@mail.gmail.com>

On Thu, Feb 2, 2012 at 10:34 PM, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> On Thu, Feb 2, 2012 at 7:26 PM, Suresh Ramasubramanian
> <ops.lists at gmail.com> wrote:
>> So what part of VRSN got broken into? ?They do a lot more than just DNS.
>
> Indeed, VeriSign owns Illuminet, who are mission-critical for POTS.
> Illuminet is also in the business of recording telephone calls, SMS
> messages, etc. for law enforcement.

Wasn't this division acquired by TNS ?
http://www.bizjournals.com/washington/stories/2009/05/04/daily5.html


Rubens


From Sandra.Murphy at sparta.com  Fri Feb  3 10:43:29 2012
From: Sandra.Murphy at sparta.com (Murphy, Sandra)
Date: Fri, 3 Feb 2012 16:43:29 +0000
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <2288A74A-F1FE-4E87-A12F-30866EF6EAB3@lacnic.net>,
 <CACB24MvY0qDkq47iCrwm4HXSHqw_MTtmMNN8xu5aEZGPsJNAOg@mail.gmail.com>
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60852BF@Hermes.columbia.ads.sparta.com>

Thanks for the reminder, Richard.

Yes, as I announced earlier (see
http://mailman.nanog.org/pipermail/nanog/2012-January/044493.html
- the message with the corrected date), there is an interim sidr meeting on 
Thu *9* Feb in San Diego.

Registration is free.  
Registration is easy (email).  
Registration is open to all.
Registration is open ended.
Registration is encouraged (so we know how many to expect).  

As the message says, see the sidr wiki http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209 for agenda and a list of attendees.

--Sandy Murphy

________________________________________
From: Richard Barnes [richard.barnes at gmail.com]
Sent: Friday, February 03, 2012 8:09 AM
To: Arturo Servin
Cc: nanog
Subject: Re: Thanks & Let's Prevent this in the Future.

In related news, the IETF working group that is writing standards for
the RPKI is having an interim meeting in San Diego just after NANOG.
They deliberately chose that place/time to make it easy for NANOG
attendees to contribute, so comments from this community are
definitely welcome.
<http://www.ietf.org/mail-archive/web/sidr/current/msg03923.html>
<http://trac.tools.ietf.org/wg/sidr/trac/wiki/InterimMeeting20120209>


<snip>

From brunner at nic-naa.net  Fri Feb  3 11:09:23 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Fri, 03 Feb 2012 12:09:23 -0500
Subject: [POLITICS] ICANN elections
In-Reply-To: <20120203160939.GA5520@vacation.karoshi.com.>
References: <20120203160939.GA5520@vacation.karoshi.com.>
Message-ID: <4F2C14C3.6060800@nic-naa.net>

What Bill said.

Comments to the website
(http://aso.icann.org/people/icann-board-elections/2012-elections/)
are moderated, so any statements of support won't show up (except to
the person who makes the statement) until the moderator has gotten a
round tuit.

The [s]electorate to be persuaded is here:
http://aso.icann.org/people/address-council/address-council-members/

Cheers,
Eric

> There are four really good candidates.  Please consider sending in a statement of
> support for one of them.
> 
> /bill
> 
> ----- Forwarded message -----
> 
> Date: Fri, 03 Feb 2012 09:38:06 +1000
> To: Bill Manning <bmanning at karoshi.com>
> Subject: Comment Period for ICANN Board Seat 9 Election
> 
> Consistent with the ASO Memorandum of Understanding and ICANN Bylaws,
> the Address Supporting Organization Address Council (ASO AC) is
> responsible for the appointment of a representative to serve on Seat
> Number 9 of the ICANN Board.
> 
> The ASO AC is pleased to announce the following four candidates for its
> upcoming appointment.
> 
> The Candidates are:
> 
>     - Thomas Eric Brunner-Williams
>     - Martin J. Levy
>     - William Manning
>     - Raymond Alan Plzak
> 
> In accordance with the ASO AC election procedures, a comment period is
> now open. A short biography is available and supporting comment
> facilities for each candidate may be found at:
> 
> http://aso.icann.org/people/icann-board-elections/2012-elections/
> 
> The comment period will close at 23:59 UTC on 19 April 2012. Comments
> will be moderated.
> 
> ASO Secretariat
> secretariat at aso.icann.org
> 
> ----- End forwarded message -----
> 
> 
> 


From hvgeekwtrvl at gmail.com  Fri Feb  3 12:55:17 2012
From: hvgeekwtrvl at gmail.com (james machado)
Date: Fri, 3 Feb 2012 10:55:17 -0800
Subject: [rt-users] External Auth using Active Directory 2008
In-Reply-To: <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
References: <84E70F84D007E14BBD13A402719AF27C15832CC1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120201233243.GF5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C15833CF1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120202171716.GL5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583405E@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120203173218.GN5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
Message-ID: <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>

I would use ldapsearch on that machine to make sure you can bind to
the AD server using the login credentials in your Site_Config.  Make
sure you are using the proper certificates to connect via the TLS you
have configured.  I've noticed that being one of the biggest problems
with ldap and Windows 2008 and 2008 R2 AD servers.

james


From hvgeekwtrvl at gmail.com  Fri Feb  3 12:56:44 2012
From: hvgeekwtrvl at gmail.com (james machado)
Date: Fri, 3 Feb 2012 10:56:44 -0800
Subject: [rt-users] External Auth using Active Directory 2008
In-Reply-To: <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>
References: <84E70F84D007E14BBD13A402719AF27C15832CC1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120201233243.GF5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C15833CF1@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120202171716.GL5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583405E@SN2PRD0102MB153.prod.exchangelabs.com>
 <20120203173218.GN5178@jibsheet.com>
 <84E70F84D007E14BBD13A402719AF27C1583726E@SN2PRD0102MB153.prod.exchangelabs.com>
 <CADVasu5kFwjv_joBkN3Y+dHDNF9v5AfsbNQHZUemuGQw1voHEw@mail.gmail.com>
Message-ID: <CADVasu7+OQJTnML_ggVkAFfh_5J3hF4F075pHdd0No73-ixQqQ@mail.gmail.com>

my apologies - fat fingered the email address

 james


From cscora at apnic.net  Fri Feb  3 12:59:49 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 4 Feb 2012 04:59:49 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202031859.q13IxniU018235@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 04 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              395820
    Prefixes after maximum aggregation:                          169388
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     191947
Total ASes present in the Internet Routing Table:                 40003
    Prefixes per ASN:                                              9.89
Origin-only ASes present in the Internet Routing Table:           32689
Origin ASes announcing only one prefix:                           15521
Transit ASes present in the Internet Routing Table:                5393
Transit-only ASes present in the Internet Routing Table:            142
Average AS path length visible in the Internet Routing Table:       4.3
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               315
    Unregistered ASNs in the Routing Table:                         120
Number of 32-bit ASNs allocated by the RIRs:                       2257
Number of 32-bit ASNs visible in the Routing Table:                1921
Prefixes from 32-bit ASNs in the Routing Table:                    4672
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            120
Number of addresses announced to Internet:                   2512081104
    Equivalent to 149 /8s, 187 /16s and 80 /24s
    Percentage of available address space announced:               67.8
    Percentage of allocated address space announced:               67.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      167934

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    97613
    Total APNIC prefixes after maximum aggregation:               31507
    APNIC Deaggregation factor:                                    3.10
Prefixes being announced from the APNIC address blocks:           93918
    Unique aggregates announced from the APNIC address blocks:    39044
APNIC Region origin ASes present in the Internet Routing Table:    4648
    APNIC Prefixes per ASN:                                       20.21
APNIC Region origin ASes announcing only one prefix:               1238
APNIC Region transit ASes present in the Internet Routing Table:    731
Average APNIC Region AS path length visible:                        4.3
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:    140
Number of APNIC addresses announced to Internet:              635833440
    Equivalent to 37 /8s, 230 /16s and 12 /24s
    Percentage of available APNIC address space announced:         80.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148115
    Total ARIN prefixes after maximum aggregation:                75385
    ARIN Deaggregation factor:                                     1.96
Prefixes being announced from the ARIN address blocks:           120087
    Unique aggregates announced from the ARIN address blocks:     49290
ARIN Region origin ASes present in the Internet Routing Table:    14884
    ARIN Prefixes per ASN:                                         8.07
ARIN Region origin ASes announcing only one prefix:                5683
ARIN Region transit ASes present in the Internet Routing Table:    1577
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               804133824
    Equivalent to 47 /8s, 238 /16s and 27 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     98052
    Total RIPE prefixes after maximum aggregation:                52278
    RIPE Deaggregation factor:                                     1.88
Prefixes being announced from the RIPE address blocks:            89929
    Unique aggregates announced from the RIPE address blocks:     55955
RIPE Region origin ASes present in the Internet Routing Table:    16285
    RIPE Prefixes per ASN:                                         5.52
RIPE Region origin ASes announcing only one prefix:                7995
RIPE Region transit ASes present in the Internet Routing Table:    2598
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1322
Number of RIPE addresses announced to Internet:               498585736
    Equivalent to 29 /8s, 183 /16s and 208 /24s
    Percentage of available RIPE address space announced:          80.3

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38255
    Total LACNIC prefixes after maximum aggregation:               8059
    LACNIC Deaggregation factor:                                   4.75
Prefixes being announced from the LACNIC address blocks:          37876
    Unique aggregates announced from the LACNIC address blocks:   19445
LACNIC Region origin ASes present in the Internet Routing Table:   1569
    LACNIC Prefixes per ASN:                                      24.14
LACNIC Region origin ASes announcing only one prefix:               442
LACNIC Region transit ASes present in the Internet Routing Table:   294
Average LACNIC Region AS path length visible:                       4.3
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   440
Number of LACNIC addresses announced to Internet:              95986568
    Equivalent to 5 /8s, 184 /16s and 163 /24s
    Percentage of available LACNIC address space announced:        63.6

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8951
    Total AfriNIC prefixes after maximum aggregation:              2087
    AfriNIC Deaggregation factor:                                  4.29
Prefixes being announced from the AfriNIC address blocks:          6957
    Unique aggregates announced from the AfriNIC address blocks:   2150
AfriNIC Region origin ASes present in the Internet Routing Table:   512
    AfriNIC Prefixes per ASN:                                     13.59
AfriNIC Region origin ASes announcing only one prefix:              163
AfriNIC Region transit ASes present in the Internet Routing Table:  115
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             30867968
    Equivalent to 1 /8s, 215 /16s and 2 /24s
    Percentage of available AfriNIC address space announced:       46.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2474      11102         982   Korea Telecom (KIX)
17974     1723        503          36   PT TELEKOMUNIKASI INDONESIA
 7545     1642        303          85   TPG Internet Pty Ltd
 4755     1529        385         155   TATA Communications formerly 
 7552     1408       1064           7   Vietel Corporation
 9829     1167        989          28   BSNL National Internet Backbo
 9583     1123         82         483   Sify Limited
 4808     1102       2051         313   CNCGROUP IP network: China169
24560     1014        385         167   Bharti Airtel Ltd., Telemedia
17488      934        161         224   Hathway IP Over Cable Interne

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3445       3807         201   bellsouth.net, inc. 
 7029     3211       1017         199   Windstream Communications Inc
18566     2093        382         177   Covad Communications 
 1785     1865        680         125   PaeTec Communications, Inc.
20115     1627       1552         627   Charter Communications 
 4323     1609       1062         384   Time Warner Telecom
22773     1498       2910         109   Cox Communications, Inc.
30036     1437        253         743   Mediacom Communications Corp 
19262     1386       4683         400   Verizon Global Networks 
 7018     1305       7007         851   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1712        480          15   Corbina telecom
 2118     1391         99          14   EUnet/RELCOM Autonomous Syste
15557     1096       2161          64   LDCOM NETWORKS
34984      643        188         172   BILISIM TELEKOM
 6830      642       1927         412   UPC Distribution Services
20940      602        195         467   Akamai Technologies European 
12479      561        642          54   Uni2 Autonomous System
31148      532         37           9   FreeNet ISP
 3320      531       8162         397   Deutsche Telekom AG
 8551      530        360          81   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1735        323         170   TVCABLE BOGOTA 
28573     1618       1083          72   NET Servicos de Comunicao S.A
 8151     1336       2995         344   UniNet S.A. de C.V. 
 7303     1260        757         180   Telecom Argentina Stet-France
26615      887        640          33   Tim Brasil S.A.
11172      697         95          75   Servicios Alestra S.A de C.V 
27947      650         73          99   Telconet S.A
22047      581        322          17   VTR PUNTO NET S.A. 
 3816      550        237          91   Empresa Nacional de Telecomun
 7738      550       1050          31   Telecomunicacoes da Bahia S.A

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1131        958          13   TEDATA
24863      834        155          43   LINKdotNET AS number
 6713      485        649          18   Itissalat Al-MAGHRIB
 3741      280        939         229   The Internet Solution 
15706      238         32           6   Sudatel Internet Exchange Aut
33776      237         13          13   Starcomms Nigeria Limited
29571      214         17          12   Ci Telecom Autonomous system 
12258      197         28          62   Vodacom Internet Company 
24835      193         80           8   RAYA Telecom - Egypt
16637      163        664          82   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3445       3807         201   bellsouth.net, inc. 
 7029     3211       1017         199   Windstream Communications Inc
 4766     2474      11102         982   Korea Telecom (KIX)
18566     2093        382         177   Covad Communications 
 1785     1865        680         125   PaeTec Communications, Inc.
10620     1735        323         170   TVCABLE BOGOTA 
17974     1723        503          36   PT TELEKOMUNIKASI INDONESIA
 8402     1712        480          15   Corbina telecom
 7545     1642        303          85   TPG Internet Pty Ltd
20115     1627       1552         627   Charter Communications 

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3211        3012      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1865        1740      PaeTec Communications, Inc.
 8402      1712        1697      Corbina telecom
17974      1723        1687      PT TELEKOMUNIKASI INDONESIA
10620      1735        1565      TVCABLE BOGOTA 
 7545      1642        1557      TPG Internet Pty Ltd
28573      1618        1546      NET Servicos de Comunicao S.A
 4766      2474        1492      Korea Telecom (KIX)
 7552      1408        1401      Vietel Corporation

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
37.77.128.0/21        8492     Siris
37.77.152.0/21       44176     RIPE Network Coordination Cen

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:80      /12:231     
/13:458     /14:817     /15:1466    /16:12151   /17:6170    /18:10294   
/19:20359   /20:28181   /21:29140   /22:39550   /23:36869   /24:206457  
/25:1189    /26:1430    /27:786     /28:43      /29:59      /30:14      
/31:0       /32:18      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     2841          3211      Windstream Communications Inc
 6389     2115          3445      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
 8402     1691          1712      Corbina telecom
10620     1629          1735      TVCABLE BOGOTA 
30036     1396          1437      Mediacom Communications Corp 
11492     1117          1154      Cable One 
 1785     1063          1865      PaeTec Communications, Inc.
15557     1046          1096      LDCOM NETWORKS
 7011     1033          1149      Citizens Utilities 

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:499       2:475       4:14        5:1         6:3         8:378    
  12:1954     13:1        14:595      15:11       16:3        17:6      
  20:9        23:125      24:1725     27:1187     31:852      32:65     
  33:2        34:2        36:9        37:161      38:791      40:114    
  41:3108     42:92       43:1        44:3        46:1279     47:3      
  49:322      50:514      52:13       54:2        55:8        56:3      
  57:38       58:958      59:491      60:344      61:1186     62:927    
  63:2000     64:4147     65:2287     66:4421     67:2048     68:1167   
  69:3149     70:916      71:410      72:1794     74:2646     75:452    
  76:323      77:963      78:913      79:498      80:1221     81:877    
  82:562      83:538      84:582      85:1163     86:746      87:910    
  88:341      89:1539     90:253      91:4473     92:540      93:1555   
  94:1338     95:1134     96:417      97:310      98:811      99:38     
 100:20      101:138     103:737     106:4       107:143     108:142    
 109:1467    110:687     111:837     112:429     113:525     114:596    
 115:757     116:860     117:722     118:906     119:1249    120:356    
 121:682     122:1627    123:1064    124:1338    125:1360    128:538    
 129:189     130:213     131:590     132:164     133:21      134:231    
 135:59      136:214     137:152     138:285     139:140     140:489    
 141:261     142:378     143:400     144:509     145:70      146:484    
 147:227     148:724     149:274     150:168     151:194     152:446    
 153:170     154:7       155:398     156:211     157:367     158:156    
 159:513     160:329     161:243     162:341     163:188     164:532    
 165:397     166:556     167:455     168:765     169:147     170:833    
 171:110     172:4       173:1757    174:591     175:414     176:468    
 177:470     178:1246    180:1176    181:64      182:703     183:274    
 184:430     185:1       186:2028    187:853     188:1030    189:1168   
 190:5444    192:5979    193:5525    194:4330    195:3390    196:1299   
 197:180     198:3615    199:4359    200:5710    201:1728    202:8404   
 203:8598    204:4343    205:2443    206:2747    207:2817    208:4064   
 209:3558    210:2724    211:1475    212:1976    213:1841    214:855    
 215:93      216:4984    217:1472    218:553     219:341     220:1243   
 221:555     222:321     223:274    

End of report


From jg at freedesktop.org  Fri Feb  3 13:29:00 2012
From: jg at freedesktop.org (Jim Gettys)
Date: Fri, 03 Feb 2012 14:29:00 -0500
Subject: bufferbloat videos are up.
Message-ID: <4F2C357C.9070407@freedesktop.org>

If people have heard of bufferbloat at all, it is usually just an
abstraction despite having had personal experience with it. Bufferbloat
can occur in your operating system, your home router, your broadband
gear, wireless, and almost anywhere in the Internet. Most still think
that if experience poor Internet speed means they must need more
bandwidth, and take vast speed variation for granted. Sometimes, adding
bandwidth can actually hurt rather than help. Most people have no idea
what they can do about bufferbloat.

So I?ve been working to put together several demos to help make
bufferbloat concrete, and demonstrate at least partial mitigation. The
mitigation shown may or may not work in your home router, and you need
to be able to set both upload and download bandwidth. People like Fred
Baker, with fiber to his house and Cisco routers, need not pay attention....

Two of four cases we commonly all suffer from at home are:

 1. Broadband bufferbloat (upstream)
 2. Home router bufferbloat (downstream)

Rather than attempt to show worst case bufferbloat which can easily
induce complete failure, I decided to demonstrate these two cases of
?typical? bufferbloat as shown by the ICSI data. As the bufferbloat
varies widely as theICSI data
<http://gettys.files.wordpress.com/2010/12/uplink_buffer_all.png>shows
<http://gettys.files.wordpress.com/2010/12/downlink_buffer_all.png>,
your mileage will also vary widely.
There are two versions of the video:

 1. A short bufferbloat video
    <http://www.youtube.com/watch?v=npiG7EBzHOU>, of slightly over 8
    minutes, which includes both demonstrations, but elides most of the
    explanation. It?s intent is to get people ?hooked? so they will want
    to know more.
 2. The longer version of the video
    <http://www.youtube.com/watch?v=-D-cJNtKwuw>clocks in at 21 minutes,
    includes both demonstrations, but gives a simplified explanation of
    bufferbloat?s cause, to encourage people to dig yet further.

Best regards,
Jim Gettys





From bhmccie at gmail.com  Fri Feb  3 14:10:00 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 14:10:00 -0600
Subject: IPv6 dual stacking and route tables
Message-ID: <4F2C3F18.3080804@gmail.com>

So, we are preparing to add IPv6 to our multi-homed (separate routers 
and carriers with IBGP) multi-site business. Starting off with a lab of 
course. Circuits and hardware are a few months away. I'm doing the 
initial designs and having some delivery questions with the carrier(s). 
One interesting question came up. There was a thread I found (and have 
since lost) regarding what routes to accept. Currently, in IPv4, we 
accept a default route only from both carriers at both sites. Works 
fine. Optimal? No. Significantly negative impact? No. In IPv6, I have 
heard some folks say that in a multi-homed environment it is better to 
get the full IPv6 table fed into both of your edge routers. Ok. Fine. 
Then, The thread I was referring to said that it is also advisable to 
have the entire IPv4 table fed in parallel. Ok. I understand we are 
talking about completely separate protocols. So it's not a layer 3 
issue. The reasoning was that DNS could potentially introduce some latency.

"If you have a specific route to a AAAA record but a less specific route 
to an A record the potential is for the trip to take longer."

That was the premise of the thread. I swear I googled it for 20 minutes 
to link before giving up. Anyway, can anyone who's been thru this 
provide any opinions on why or why not it is important to accept the 
full IPv6 table AND the full IPv4 table? I have the hardware to handle 
it I'm just not sure long term what the reasoning would be for or 
against. Again, I'm an end customer. Not a carrier. So my concern is (A) 
my Internet facing applications and (B) my users who eventually will 
surf IPv6.

Any guidance would be appreciated. Thanks.




-Hammer-

"I was a normal American nerd"
-Jack Herer




From ryan at u13.net  Fri Feb  3 14:20:03 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 3 Feb 2012 15:20:03 -0500
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <5C7B4C2E-AD2E-4165-B6BA-FBDCF72BBBF6@u13.net>


On Feb 3, 2012, at 3:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency.
> 
> "If you have a specific route to a AAAA record but a less specific route to an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> -Hammer-

We have been accepting our upstreams' connected and customer routes only (v4) and full routes (v6) without issue.  I can't say that I have previously heard of the DNS performance example/concern you provided above

From tagno25 at gmail.com  Fri Feb  3 14:25:51 2012
From: tagno25 at gmail.com (Philip Dorr)
Date: Fri, 3 Feb 2012 14:25:51 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>

You should accept the full v6 table, because some IPs may not,
currently, be reachable via one of the carriers.

On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a AAAA record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>


From streiner at cluebyfour.org  Fri Feb  3 14:27:34 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 3 Feb 2012 15:27:34 -0500 (EST)
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <Pine.LNX.4.64.1202031524460.5976@whammy.cluebyfour.org>

On Fri, 3 Feb 2012, -Hammer- wrote:

> "If you have a specific route to a AAAA record but a less specific route to 
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to 
> link before giving up. Anyway, can anyone who's been thru this provide any 
> opinions on why or why not it is important to accept the full IPv6 table AND 
> the full IPv4 table? I have the hardware to handle it I'm just not sure long 
> term what the reasoning would be for or against. Again, I'm an end customer. 
> Not a carrier. So my concern is (A) my Internet facing applications and (B) 
> my users who eventually will surf IPv6.

We currently take full v4 and v6 routes, however we do not yet have 
end-users officially on v6 (users doing their own 6to4 tunnels and stuff 
like Teredo notwithstanding), so I don't have any experience with the 
A/AAAA resolution asymmetry you're describing.

jms


From cb.list6 at gmail.com  Fri Feb  3 14:28:01 2012
From: cb.list6 at gmail.com (Cameron Byrne)
Date: Fri, 3 Feb 2012 12:28:01 -0800
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <CAD6AjGTnVoSVUXKGb9BbhyQj9NGiPqC6C5c7NQRd7Dv72oj0jg@mail.gmail.com>

On Fri, Feb 3, 2012 at 12:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
> So, we are preparing to add IPv6 to our multi-homed (separate routers and
> carriers with IBGP) multi-site business. Starting off with a lab of course.
> Circuits and hardware are a few months away. I'm doing the initial designs
> and having some delivery questions with the carrier(s). One interesting
> question came up. There was a thread I found (and have since lost) regarding
> what routes to accept. Currently, in IPv4, we accept a default route only
> from both carriers at both sites. Works fine. Optimal? No. Significantly
> negative impact? No. In IPv6, I have heard some folks say that in a
> multi-homed environment it is better to get the full IPv6 table fed into
> both of your edge routers. Ok. Fine. Then, The thread I was referring to
> said that it is also advisable to have the entire IPv4 table fed in
> parallel. Ok. I understand we are talking about completely separate
> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
> potentially introduce some latency.
>
> "If you have a specific route to a AAAA record but a less specific route to
> an A record the potential is for the trip to take longer."
>
> That was the premise of the thread. I swear I googled it for 20 minutes to
> link before giving up. Anyway, can anyone who's been thru this provide any
> opinions on why or why not it is important to accept the full IPv6 table AND
> the full IPv4 table? I have the hardware to handle it I'm just not sure long
> term what the reasoning would be for or against. Again, I'm an end customer.
> Not a carrier. So my concern is (A) my Internet facing applications and (B)
> my users who eventually will surf IPv6.
>
> Any guidance would be appreciated. Thanks.
>
>

Well.  I don't really follow the above text.

But, the principle is the same for IPv4 or IPv6.  If you take a full
or partial table, your router can make a better choice than just
getting default  (only maybe, BGP is never guaranteeing anything about
performance).

That said, in v6, it is a little bit more important, IMHO, to take the
ISP routes instead of just a default since the v6 peering is not as
robust out on the Internet.  There are still turf wars going on or
some SPs are still not peering IPv6 in all the places they peer for
IPv4.  Less peering = longer latency. But, this situation has improved
dramatically in the last 12 months.

In the end, my guidance is to take "provider routes" or "customer
route" + default.  This helps your router make an educated guess
without absorbing all the churn and gunk that a full BGP feed hits
your router with.  Make the SP trim those routes on their side so you
don't see it.

CB
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>


From jeroen at unfix.org  Fri Feb  3 14:28:38 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 03 Feb 2012 21:28:38 +0100
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <4F2C4376.4070307@unfix.org>

On 2012-02-03 21:10 , -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers
> and carriers with IBGP) multi-site business. Starting off with a lab of
> course.

Dear "Hammer",

Welcome to the 21th century. 2012 is going to "the year" (they claim,
again ;) of IPv6 thus it is better to start before the big launch event
that is this year, (of which there was also one back in in 2004:
http://www.global-ipv6.org/ for the folks who have IPv6 for some time
now ;) Better late than never some would say.

> Circuits and hardware are a few months away. I'm doing the
> initial designs and having some delivery questions with the carrier(s).
> One interesting question came up. There was a thread I found (and have
> since lost) regarding what routes to accept. Currently, in IPv4, we
> accept a default route only from both carriers at both sites. Works
> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
> heard some folks say that in a multi-homed environment it is better to
> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
> Then, The thread I was referring to said that it is also advisable to
> have the entire IPv4 table fed in parallel. Ok. I understand we are
> talking about completely separate protocols. So it's not a layer 3
> issue.

The only advantage of more routes, in both IPv4 and IPv6 is that the
path selection can be better. An end-host does not make this decision
where packets flow, thus having a full route or not should not matter
much, except that the route might be more optimal. No DNS involvement
here yet.

The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
Lion and up which does not follow that spec and in which it cannot be
turned off either, which is awesome when you are debugging things...)

Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.

Chrome has it's own HE implementation, thus if you run Chrome on a Mac
you will have sometimes one sometimes another connect depending on if
you are using Safari or Chrome for instance as Safari does use the
system provided things. Ping will pick another again etc. It will be
quite random all the time.

The fun with the Mac OS X implementation is that it keeps a local cache
of per-destination latency/speed information.

If you thus have two default routes, be that IPv4 or IPv6, and your
routers are swapping paths between either and thus don't have a stable
outgoing path those latencies will vary and thus the pretty HE
algorithms will be very confused.

This is likely why your "source" recommended to have a full path, as per
sub-prefix the path will become more stable and established than if you
are doing hot-potato with two defaults.

Greets,
 Jeroen



From bhmccie at gmail.com  Fri Feb  3 14:37:44 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 14:37:44 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C4376.4070307@unfix.org>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
Message-ID: <4F2C4598.5060505@gmail.com>

Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online 
and offline responses. That was fast. The struggle is that I'm having 
trouble seeing how/why it would matter other than potential latency on 
the IPv4 side. IPv6 conversations usually involve taking the full table 
when dealing with multi-homed/multi-site setups. IPv4 I didn't really 
consider (taking the full table) until I mentioned this to some of my 
vendors technical folks and it caused a lot of reflection. Not on the L3 
part. Just on the DNS part. This appears to be a tough subject area when 
it comes to V4/V6 deployment strategies. The bottom line is that I'll 
take whatever the carrier feeds in V6. Just trying to see where I would 
be missing out by not doing the same in V4. Again, I have the hardware 
to support it and I really have no reason not to do it. I just want to 
be able to justify to myself why I'm doing it.

A lot of kinks to work out this year.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:28 PM, Jeroen Massar wrote:
> On 2012-02-03 21:10 , -Hammer- wrote:
>
>> So, we are preparing to add IPv6 to our multi-homed (separate routers
>> and carriers with IBGP) multi-site business. Starting off with a lab of
>> course.
> Dear "Hammer",
>
> Welcome to the 21th century. 2012 is going to "the year" (they claim,
> again ;) of IPv6 thus it is better to start before the big launch event
> that is this year, (of which there was also one back in in 2004:
> http://www.global-ipv6.org/ for the folks who have IPv6 for some time
> now ;) Better late than never some would say.
>
>> Circuits and hardware are a few months away. I'm doing the
>> initial designs and having some delivery questions with the carrier(s).
>> One interesting question came up. There was a thread I found (and have
>> since lost) regarding what routes to accept. Currently, in IPv4, we
>> accept a default route only from both carriers at both sites. Works
>> fine. Optimal? No. Significantly negative impact? No. In IPv6, I have
>> heard some folks say that in a multi-homed environment it is better to
>> get the full IPv6 table fed into both of your edge routers. Ok. Fine.
>> Then, The thread I was referring to said that it is also advisable to
>> have the entire IPv4 table fed in parallel. Ok. I understand we are
>> talking about completely separate protocols. So it's not a layer 3
>> issue.
> The only advantage of more routes, in both IPv4 and IPv6 is that the
> path selection can be better. An end-host does not make this decision
> where packets flow, thus having a full route or not should not matter
> much, except that the route might be more optimal. No DNS involvement
> here yet.
>
> The trick comes with Happy-Eyeballs alike setups (especially Mac OSX
> Lion and up which does not follow that spec and in which it cannot be
> turned off either, which is awesome when you are debugging things...)
>
> Due to HE (Happy-Eyeballs) setups, which can differ per OS and per tool.
>
> Chrome has it's own HE implementation, thus if you run Chrome on a Mac
> you will have sometimes one sometimes another connect depending on if
> you are using Safari or Chrome for instance as Safari does use the
> system provided things. Ping will pick another again etc. It will be
> quite random all the time.
>
> The fun with the Mac OS X implementation is that it keeps a local cache
> of per-destination latency/speed information.
>
> If you thus have two default routes, be that IPv4 or IPv6, and your
> routers are swapping paths between either and thus don't have a stable
> outgoing path those latencies will vary and thus the pretty HE
> algorithms will be very confused.
>
> This is likely why your "source" recommended to have a full path, as per
> sub-prefix the path will become more stable and established than if you
> are doing hot-potato with two defaults.
>
> Greets,
>   Jeroen
>
>


From jeroen at unfix.org  Fri Feb  3 14:47:00 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 03 Feb 2012 21:47:00 +0100
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C4598.5060505@gmail.com>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
 <4F2C4598.5060505@gmail.com>
Message-ID: <4F2C47C4.3050303@unfix.org>

On 2012-02-03 21:37 , -Hammer- wrote:
> Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
> and offline responses. That was fast. The struggle is that I'm having
> trouble seeing how/why it would matter other than potential latency on
> the IPv4 side. IPv6 conversations usually involve taking the full table
> when dealing with multi-homed/multi-site setups. IPv4 I didn't really
> consider (taking the full table) until I mentioned this to some of my
> vendors technical folks and it caused a lot of reflection. Not on the L3
> part. Just on the DNS part. This appears to be a tough subject area when
> it comes to V4/V6 deployment strategies. The bottom line is that I'll
> take whatever the carrier feeds in V6. Just trying to see where I would
> be missing out by not doing the same in V4. Again, I have the hardware
> to support it and I really have no reason not to do it. I just want to
> be able to justify to myself why I'm doing it.

Why you want non-defaults in both IPv4 and IPv6:
 - more possible paths
 - less chances of blackholes.

And of course, those paths will be more stable and you don't get
hot-potato swapping between two defaults.

And that in turn allows the Happy Eyeballs mechanisms to do their jobs
much better as they keep a history per host or prefix, they assume IPv6
/48's and IPv4 /24's from what I have seen, in some cases.

Greets,
 Jeroen



From bhmccie at gmail.com  Fri Feb  3 15:04:18 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 03 Feb 2012 15:04:18 -0600
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C47C4.3050303@unfix.org>
References: <4F2C3F18.3080804@gmail.com> <4F2C4376.4070307@unfix.org>
 <4F2C4598.5060505@gmail.com> <4F2C47C4.3050303@unfix.org>
Message-ID: <4F2C4BD2.4080904@gmail.com>

OK. Looking forward to getting the lab up. Since I can handle the volume 
I'll take both tables. At least in the lab. Looking forward to doing 
some experiments with DNS just to see what all the fuss is about. Looks 
like I'll need to order a Mac for the lab. No harm there. :)

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/3/2012 2:47 PM, Jeroen Massar wrote:
> On 2012-02-03 21:37 , -Hammer- wrote:
>> Thanks Jeroen (and Ryan/Philip/Cameron/Justin/Etc.) for all the online
>> and offline responses. That was fast. The struggle is that I'm having
>> trouble seeing how/why it would matter other than potential latency on
>> the IPv4 side. IPv6 conversations usually involve taking the full table
>> when dealing with multi-homed/multi-site setups. IPv4 I didn't really
>> consider (taking the full table) until I mentioned this to some of my
>> vendors technical folks and it caused a lot of reflection. Not on the L3
>> part. Just on the DNS part. This appears to be a tough subject area when
>> it comes to V4/V6 deployment strategies. The bottom line is that I'll
>> take whatever the carrier feeds in V6. Just trying to see where I would
>> be missing out by not doing the same in V4. Again, I have the hardware
>> to support it and I really have no reason not to do it. I just want to
>> be able to justify to myself why I'm doing it.
> Why you want non-defaults in both IPv4 and IPv6:
>   - more possible paths
>   - less chances of blackholes.
>
> And of course, those paths will be more stable and you don't get
> hot-potato swapping between two defaults.
>
> And that in turn allows the Happy Eyeballs mechanisms to do their jobs
> much better as they keep a history per host or prefix, they assume IPv6
> /48's and IPv4 /24's from what I have seen, in some cases.
>
> Greets,
>   Jeroen
>
>


From ryan at u13.net  Fri Feb  3 15:44:33 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Fri, 3 Feb 2012 16:44:33 -0500
Subject: IPv6 dual stacking and route tables
In-Reply-To: <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>
References: <4F2C3F18.3080804@gmail.com>
 <CABidiTLDRTAqqcbn1Qnmrr5RZGMJLVEg6c9aptu+Z98_6+XQdg@mail.gmail.com>
Message-ID: <D9A448B4-1D5B-48A0-AF1F-1CE17D1FA958@u13.net>


On Feb 3, 2012, at 3:25 PM, Philip Dorr wrote:

> You should accept the full v6 table, because some IPs may not,
> currently, be reachable via one of the carriers.

Definitely agreed here, and this is why we take full v6 tables.  Especially since one of our upstreams does not peer with at least one other large network; if we took just a default from them, we would likely be sending them traffic which they in turn do not have a route for whereas the other upstream of ours does.

> 
> On Fri, Feb 3, 2012 at 2:10 PM, -Hammer- <bhmccie at gmail.com> wrote:
>> So, we are preparing to add IPv6 to our multi-homed (separate routers and
>> carriers with IBGP) multi-site business. Starting off with a lab of course.
>> Circuits and hardware are a few months away. I'm doing the initial designs
>> and having some delivery questions with the carrier(s). One interesting
>> question came up. There was a thread I found (and have since lost) regarding
>> what routes to accept. Currently, in IPv4, we accept a default route only
>> from both carriers at both sites. Works fine. Optimal? No. Significantly
>> negative impact? No. In IPv6, I have heard some folks say that in a
>> multi-homed environment it is better to get the full IPv6 table fed into
>> both of your edge routers. Ok. Fine. Then, The thread I was referring to
>> said that it is also advisable to have the entire IPv4 table fed in
>> parallel. Ok. I understand we are talking about completely separate
>> protocols. So it's not a layer 3 issue. The reasoning was that DNS could
>> potentially introduce some latency.
>> 
>> "If you have a specific route to a AAAA record but a less specific route to
>> an A record the potential is for the trip to take longer."
>> 
>> That was the premise of the thread. I swear I googled it for 20 minutes to
>> link before giving up. Anyway, can anyone who's been thru this provide any
>> opinions on why or why not it is important to accept the full IPv6 table AND
>> the full IPv4 table? I have the hardware to handle it I'm just not sure long
>> term what the reasoning would be for or against. Again, I'm an end customer.
>> Not a carrier. So my concern is (A) my Internet facing applications and (B)
>> my users who eventually will surf IPv6.
>> 
>> Any guidance would be appreciated. Thanks.
>> 
>> 
>> 
>> 
>> -Hammer-
>> 
>> "I was a normal American nerd"
>> -Jack Herer
>> 
>> 
>> 
> 



From cidr-report at potaroo.net  Fri Feb  3 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 3 Feb 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201202032200.q13M00AS097487@wattle.apnic.net>

BGP Update Report
Interval: 26-Jan-12 -to- 02-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            53901  3.1%      29.0 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683           39445  2.3%     646.6 -- BENINTELECOM
 3 - AS5800            33859  1.9%     117.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 4 - AS12479           25806  1.5%     154.5 -- UNI2-AS France Telecom Espana SA
 5 - AS9829            25640  1.5%      36.9 -- BSNL-NIB National Internet Backbone
 6 - AS32528           23059  1.3%    7686.3 -- ABBOTT Abbot Labs
 7 - AS23154           20656  1.2%    5164.0 -- SANMINA-SCI Sanmina-SCI Corporation
 8 - AS20632           20258  1.2%     519.4 -- PETERSTAR-AS PeterStar
 9 - AS7029            18611  1.1%       7.2 -- WINDSTREAM - Windstream Communications Inc
10 - AS6713            18375  1.1%      37.7 -- IAM-AS
11 - AS24560           18180  1.0%      46.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - AS31148           16044  0.9%      24.7 -- FREENET-AS FreeNet ISP
13 - AS6066            12493  0.7%    6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
14 - AS9583            11691  0.7%      11.9 -- SIFY-AS-IN Sify Limited
15 - AS17974           11635  0.7%       8.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
16 - AS5976            11626  0.7%     118.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - AS4538            11580  0.7%      22.7 -- ERX-CERNET-BKB China Education and Research Network Center
18 - AS6503            11445  0.7%       7.0 -- Axtel, S.A.B. de C.V.
19 - AS37004           11269  0.7%     433.4 -- SUBURBAN-AS
20 - AS43348           10512  0.6%      79.6 -- TATARINOVA-AS PE Tatarinova Alla Ivanovna


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126            9346  0.5%    9346.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528           23059  1.3%    7686.3 -- ABBOTT Abbot Labs
 3 - AS6066            12493  0.7%    6246.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 4 - AS23154           20656  1.2%    5164.0 -- SANMINA-SCI Sanmina-SCI Corporation
 5 - AS10209            3894  0.2%    3894.0 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center
 6 - AS5868             1677  0.1%    1677.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 7 - AS53362            1001  0.1%    1001.0 -- MIXIT-AS - Mixit, Inc.
 8 - AS16045             830  0.1%     830.0 -- SPEKTAR-AD Spektar AD
 9 - AS27295             670  0.0%     670.0 -- GENICA - Genica Corporation
10 - AS36980             660  0.0%     660.0 -- JOHNHOLT-ASN
11 - AS28683           39445  2.3%     646.6 -- BENINTELECOM
12 - AS53222            1770  0.1%     590.0 -- 
13 - AS19226             565  0.0%     565.0 -- AURA-SOUTH - A.U.R.A
14 - AS17408            3247  0.2%     541.2 -- ABOVE-AS-AP AboveNet Communications Taiwan
15 - AS28123             527  0.0%     527.0 -- 
16 - AS52861            1575  0.1%     525.0 -- 
17 - AS20632           20258  1.2%     519.4 -- PETERSTAR-AS PeterStar
18 - AS5863              473  0.0%     473.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - AS49047             471  0.0%     471.0 -- PCSI-ASN Pentacomp Systemy Informatyczne S.A.
20 - AS27689             465  0.0%     465.0 -- Laboratorio Nacional de Inform?tica Avanzada AC


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 148.164.14.0/24   20619  1.1%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 2 - 84.204.132.0/24   20117  1.1%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 130.36.34.0/24    11529  0.6%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11529  0.6%   AS32528 -- ABBOTT Abbot Labs
 5 - 122.161.0.0/16    10190  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 6 - 217.170.24.0/21    9346  0.5%   AS29126 -- DATIQ-AS Datiq B.V.
 7 - 62.36.252.0/22     8037  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/24    6528  0.3%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 150.225.0.0/16     6247  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
10 - 204.29.239.0/24    6246  0.3%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
11 - 62.36.249.0/24     6087  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
12 - 62.36.241.0/24     5537  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 194.63.9.0/24      5387  0.3%   AS1273  -- CW Cable and Wireless Worldwide plc
14 - 62.36.210.0/24     5289  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 190.67.172.0/22    5051  0.3%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
16 - 111.125.126.0/24   4975  0.3%   AS17639 -- COMCLARK-AS ComClark Network & Technology Corp.
17 - 205.73.118.0/24    4667  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - 205.73.116.0/23    4553  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - 198.182.50.0/23    3894  0.2%   AS10209 -- SYNOPSYS-AS-JP-AP Japan HUB and Data Center
20 - 202.153.174.0/24   3193  0.2%   AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb  3 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 3 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202032200.q13M00Vs097482@wattle.apnic.net>

This report has been generated at Fri Feb  3 21:12:45 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        27-01-12    396272      229808
        28-01-12    395687      230060
        29-01-12    396508      229971
        30-01-12    396324      229998
        31-01-12    396621      229745
        01-02-12    396817      230146
        02-02-12    397186      229608
        03-02-12    397625      230080


AS Summary
         40099  Number of ASes in routing system
         16816  Number of ASes announcing only one prefix
          3445  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      109882880  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 03Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     398212   230080   168132    42.2%   All ASes

AS6389      3445      204     3241    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3260     1427     1833    56.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS18566     2093      413     1680    80.3%   COVAD - Covad Communications
                                               Co.
AS4766      2478     1005     1473    59.4%   KIXS-AS-KR Korea Telecom
AS22773     1499      118     1381    92.1%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS4755      1528      197     1331    87.1%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS2118      1391       76     1315    94.5%   RELCOM-AS OOO "NPO Relcom"
AS4323      1610      386     1224    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1624      407     1217    74.9%   NET Servicos de Comunicao S.A.
AS1785      1868      789     1079    57.8%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1408      363     1045    74.2%   VIETEL-AS-AP Vietel
                                               Corporation
AS19262     1386      401      985    71.1%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1735      766      969    55.9%   Telmex Colombia S.A.
AS8402      1653      726      927    56.1%   CORBINA-AS OJSC "Vimpelcom"
AS7303      1260      366      894    71.0%   Telecom Argentina S.A.
AS26615      885       33      852    96.3%   Tim Celular S.A.
AS8151      1337      550      787    58.9%   Uninet S.A. de C.V.
AS18101      935      156      779    83.3%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS4808      1102      344      758    68.8%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS24560     1010      299      711    70.4%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS30036     1437      753      684    47.6%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS9498       878      206      672    76.5%   BBIL-AP BHARTI Airtel Ltd.
AS9394       878      210      668    76.1%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS7545      1642      998      644    39.2%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1098      457      641    58.4%   LEVEL3 Level 3 Communications
AS17676      687       74      613    89.2%   GIGAINFRA Softbank BB Corp.
AS17974     1724     1121      603    35.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS11172      698      113      585    83.8%   Alestra, S. de R.L. de C.V.
AS15557     1096      511      585    53.4%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS4804       660       95      565    85.6%   MPX-AS Microplex PTY LTD

Total      44305    13564    30741    69.4%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        37.77.176.0/21       AS16082 SPITFIRE Spitfire Network Services Autonomous System
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        80.88.10.0/24        AS33774 DJAWEB
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET Com-ToNet
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.80.130.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        205.189.0.0/24       AS54372 DROPBOX-CORP - Dropbox, Inc.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - KNOLOGY,  Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mpetach at netflight.com  Fri Feb  3 16:01:54 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Fri, 3 Feb 2012 14:01:54 -0800
Subject: This network is too good...
In-Reply-To: <86d39yknou.fsf@seastrom.com>
References: <86d39yknou.fsf@seastrom.com>
Message-ID: <CAEmG1=rQkeQ2Y6BddDvN++-0rDtaEMkJxw5=WTammbc5NCQNvg@mail.gmail.com>

On Wed, Feb 1, 2012 at 5:51 PM, Robert E. Seastrom <rs at seastrom.com> wrote:
>
> Hi all,
>
> Any thoughts on products that screw up networks in deterministic (and
> realistic found-in-the-wild) ways? ?I'm thinking of stuff like
> PacketStorm, Dummynet, etc. ?Dial up jitter, latency, tail drop, RED,
> whatever...
>
> (I know someone's gonna say "Just buy a Brand Z FubarSwitch 3k, they
> will screw up your whole network and you don't even have to configure
> it to do so!")
>
> I'm all-ears like Ross Perot.
>
> Thanks,
>
> -r

Definite +1 for dummynet on freebsd; I've used in the lab at layer 2 in
bridge mode, and layer 3 both, for doing testing.  latency introduction
is good down to a few ms, but isn't accurate below that--but for most
of what we do, in terms of simulating latency and loss/jitter, it works
like a charm.

Matt


From owen at delong.com  Fri Feb  3 17:02:23 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 3 Feb 2012 15:02:23 -0800
Subject: IPv6 dual stacking and route tables
In-Reply-To: <4F2C3F18.3080804@gmail.com>
References: <4F2C3F18.3080804@gmail.com>
Message-ID: <5E284873-1AE5-42C9-9E8D-EA8D040A1412@delong.com>


On Feb 3, 2012, at 12:10 PM, -Hammer- wrote:

> So, we are preparing to add IPv6 to our multi-homed (separate routers and carriers with IBGP) multi-site business. Starting off with a lab of course. Circuits and hardware are a few months away. I'm doing the initial designs and having some delivery questions with the carrier(s). One interesting question came up. There was a thread I found (and have since lost) regarding what routes to accept. Currently, in IPv4, we accept a default route only from both carriers at both sites. Works fine. Optimal? No. Significantly negative impact? No. In IPv6, I have heard some folks say that in a multi-homed environment it is better to get the full IPv6 table fed into both of your edge routers. Ok. Fine. Then, The thread I was referring to said that it is also advisable to have the entire IPv4 table fed in parallel. Ok. I understand we are talking about completely separate protocols. So it's not a layer 3 issue. The reasoning was that DNS could potentially introduce some latency.
> 
> "If you have a specific route to a AAAA record but a less specific route to an A record the potential is for the trip to take longer."
> 
> That was the premise of the thread. I swear I googled it for 20 minutes to link before giving up. Anyway, can anyone who's been thru this provide any opinions on why or why not it is important to accept the full IPv6 table AND the full IPv4 table? I have the hardware to handle it I'm just not sure long term what the reasoning would be for or against. Again, I'm an end customer. Not a carrier. So my concern is (A) my Internet facing applications and (B) my users who eventually will surf IPv6.
> 
> Any guidance would be appreciated. Thanks.
> 
> 
> 
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 

On a purely theoretical level, mores specific routes are always better than default.

So, on a purely theoretical level:

IDEAL:			Full routes, both protocols
	Advantage:  Most information available, theoretically best decisions possible.
	Disadvantage:	Router cost rivals national debt of third-world country.

Second best:		Full routes IPv6, default or partial routes IPv4
	Advantage:  Lots of information available, theoretically best IPv6 decisions.
	Disadvantage:  IPv6 might outperform IPv4 (not really a problem in most cases)
	Bigger disadvantage: Some IPv4 destinations might get blackholed from time to time.

Third choice:		Default both protocols
	Advantage:  At least you're still dual-stacked.
	Disadvantage: All the disadvantages applied to IPv4 above now apply to IPv6, too.

Worst choice:	Don't implement IPv6
	Advantage:  Absolutely none.
	Disadvantage: You can reach progressively less and less of the internet over time.

However, the real answer is more complex than that. Sometimes the route that looks the best in BGP might not actually be the best and so in some cases with full tables you might send to the provider with the less effective path even though default would have had you going via the more effective path. These circumstances are rare, however, but, BGP has lots of knobs and depending on how well you and your upstreams set those knobs, your experience can be radically better or worse as a result.

If your trip to the A destination via default takes longer than your trip to the AAAA destination via specifics, I'm not seeing a problem. Clients that have IPv6 capability will get a better user experience and clients that don't have IPv6 will get the same experience they got with default-based IPv4 prior to you implementing IPv6.

Owen



From robertg at garlic.com  Fri Feb  3 19:25:46 2012
From: robertg at garlic.com (Robert Glover)
Date: Fri, 03 Feb 2012 17:25:46 -0800
Subject: AT&T / prodigy.net mail admin
Message-ID: <4F2C891A.4090403@garlic.com>

Hello,

Can an AT&T mail admin contact me off-list please?  I have attempted to 
get a resolution for an issue through the normal channels and have not 
gotten anywhere.

Sincerely,
Bobby Glover
Director of Information Services
SVI Incorporated


From merlyn at geeks.org  Fri Feb  3 20:36:55 2012
From: merlyn at geeks.org (Doug McIntyre)
Date: Fri, 3 Feb 2012 20:36:55 -0600
Subject: not excactly on-topic Server Cabinet question
In-Reply-To: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
References: <635D17EE85D35A49B8F278998E6C3404647C8EB4DB@EXVS.dev.oati.local>
Message-ID: <20120204023655.GA18107@geeks.org>

On Wed, Feb 01, 2012 at 11:05:09PM -0600, Erik Amundson wrote:
> I apologize for this being off-topic in the NANOG list, but I'm hoping some of you have experience with the particulars of what I'm looking for...
> 
> I am looking for a server cabinet which has an electric latching mechanism on it.  I want to use my existing security system and proximity card reader, but have a cabinet door that would open when the card reader is read.
> 
> Does anyone sell anything like this?

Chatsworth has a solution..

http://www.chatsworth.com/Products/Environmental-Monitoring-and-Security/Electronic-Locking-Systems/



From swmike at swm.pp.se  Fri Feb  3 22:09:56 2012
From: swmike at swm.pp.se (Mikael Abrahamsson)
Date: Sat, 4 Feb 2012 05:09:56 +0100 (CET)
Subject: bufferbloat videos are up.
In-Reply-To: <4F2C357C.9070407@freedesktop.org>
References: <4F2C357C.9070407@freedesktop.org>
Message-ID: <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>

On Fri, 3 Feb 2012, Jim Gettys wrote:

> 2. The longer version of the video

Good visualisation. Just a little nitpicking, 802.11 is 54 megabit, not 
megahertz. It should also be pointed out that 802.11 is half duplex, which 
might affect things.

Also, you might want to point out in your material that large buffers are 
there to handle bursts on TCP sessions over high RTT. Your suggestion to 
improve interactive performance hurts high speed TCP high RTT sessions. 
This is probably what most people want to do, but it would be good to 
point it out. Doing a promotion for ECN support in equipment would also be 
good, because introduing WRED with high drop probability a low buffer fill 
will really hurt performance for TCP transfers. ECN will help to avoid 
restransmissions, which just wastes bw.

Where does your 100ms buffer size recommendation come from? The classical 
one is 2xRTT, with a lot of platforms developed around 2000 sized at 600ms 
of buffering (because 300 ms RTT seems like a decent value to choose for 
"max RTT" I guess). At megabit speeds I'd say to achieve your goal having 
100ms FIFO buffering is too high anyway, so to handle your problem you 
need "fairqueue" to look at flows and put persistent buffer filling TCP 
sessions in "the background". This would also mean TCP would be able to 
use full bw without hurting interactivity.

Also, for some operating systems (Linux is the one I know about), there is 
a tendency to have high buffers not only in the IP stack, but also high 
FIFO buffers towards the hardware, in the device driver. I engaged the 
linux-usb mailing list about this, and I did see some talk that indicated 
that people understood the problem.

So basically I agree with your problem statement, however I think it would 
be benficial if your proposed solution was a bit more specific, or at 
least pointed more in that direction. To propose a solution that sounds 
more like "limit buffers to 100ms or less and everything will be fine" 
would indeed remove some of the problem, but it would hurt performance for 
some applications.

The problem you're describing has been know for 25 years, unfortunately 
not by the right people in the business, especially the ones making high 
volume low cost home equipment.

-- 
Mikael Abrahamsson    email: swmike at swm.pp.se


From bicknell at ufp.org  Fri Feb  3 22:29:40 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 3 Feb 2012 22:29:40 -0600
Subject: bufferbloat videos are up.
In-Reply-To: <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>
References: <4F2C357C.9070407@freedesktop.org>
 <alpine.DEB.2.00.1202040451570.8029@uplift.swm.pp.se>
Message-ID: <418169E5-A04B-459D-88B7-22C78D6182BF@ufp.org>


On Feb 3, 2012, at 10:09 PM, Mikael Abrahamsson wrote:

> So basically I agree with your problem statement, however I think it would be benficial if your proposed solution was a bit more specific, or at least pointed more in that direction. To propose a solution that sounds more like "limit buffers to 100ms or less and everything will be fine" would indeed remove some of the problem, but it would hurt performance for some applications.

The key to the solution is better Adaptive Queue Management, or AQM.  As long as we have to decide on fixed queue sizes for all traffic, we're forced to cater to the most common traffic type.

It would be nice to put queues of different RTT into different queues.  Today that is basically impossible.

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







From matt at mattreath.com  Sat Feb  4 01:40:55 2012
From: matt at mattreath.com (Matthew Reath)
Date: Sat, 4 Feb 2012 01:40:55 -0600
Subject: Question about prefix list
In-Reply-To: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>
References: <1328156018.36060.YahooMailClassic@web181110.mail.ne1.yahoo.com>
Message-ID: <ff66073bc8c812da166670a74b7221be.squirrel@mail.mattreath.com>

> Ann,
> the commas not withstanding, the le/ge operands as applicable to
> prefix-lists simply mean "less-than or equal-to" or greater-than or
> "equal-to" wrt netmasks in CIDR speak.
>
> In you prefix-list below, the le operand means -
> allow following ranges:
>
> /22,/23,/24 deny all else
> for the /21
> it means allow /21 thru /24
>
> Anything without an operand means an exact-match(permit/deny)
>
> Homework for you:
>
> What do the following do:
>
> 1) ip prefix-list foo deny 0.0.0.0/0 le32
> 2) ip prefix-list foo permit 0.0.0/0 le 32
>
> Understand the above and you will understand how operands work in
> prefix-lists.
> ./Randy
>
>
> --- On Wed, 2/1/12, Ann Kwok <annkwok80 at gmail.com> wrote:
>
>> From: Ann Kwok <annkwok80 at gmail.com>
>> Subject: Question about prefix list
>> To: nanog at nanog.org
>> Date: Wednesday, February 1, 2012, 6:32 AM
>> Hi
>>
>> I read this prefix list.
>>
>> Can I know why there is "le 24" after network block in /22
>> and /21
>>
>> Why don't have "le 24" after /24?
>>
>> I also saw another prefix list before. They use "le 32"
>> instead of? "le 24"
>>
>> What are their different?
>>
>> ip prefix-list prefix-filter-as100 seq 10 permit
>> 202,168.136.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 20 permit
>> 202,22.92.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 30 permit
>> 202,21.148.0/22 le 24
>> ip prefix-list prefix-filter-as100 seq 40 permit
>> 203,178.88.0/21 le 24
>> ip prefix-list prefix-filter-as100 seq 50 permit
>> 178.88.74.0/24
>>
>> Thank you so much
>>
>
>

Here is how I look at prefix lists 


Lets say I have the following:
ip prefix-list EXAMPLE permit 202.21.148.0/22 le 24

What this essentially means is match any prefixes that match the first 22
bits of 202.21.148.0 with a prefix length less than or equal to /24.

The third octet (148) is 10010100 in binary, the /22 would be at
100101|00. So we would match anything that has the same bits set before
the divider or the /22 mark.

Matching prefixes would be:
202.21.148.0/22
202.21.148.0/23
202.21.150.0/23
202.21.148.0/24
202.21.149.0/24
202.21.150.0/24
202.21.151.0/24

Hope that makes sense.

--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From matt at mattreath.com  Sat Feb  4 01:55:20 2012
From: matt at mattreath.com (Matthew Reath)
Date: Sat, 4 Feb 2012 01:55:20 -0600
Subject: Please help our simple bgp
In-Reply-To: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
References: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
Message-ID: <ad888288ddfe04e7150ac1716439c4b2.squirrel@mail.mattreath.com>

> Hello
>
> Our router is running simple bgp. "one BGP router, two upstreams (each
> 100M
> from ISP A and ISP B)
> We are getting full feeds tables from them
>
> We discover the routes is going to ISP A only even the bandwidth 100M is
> full
>
> Can we set the weight to change to ISP B to use ISP B as preference
> routes?
>
> Can the following configuration work?
> What suggest to this weight no. too?
>
>  neighbor 1.2.3.4 description ISP B
>  neighbor 1.2.3.4 remote-as 111
>  neighbor 1.2.3.4 weight 2000
>
> If this works, how is ISP B upstream connection is down?
>
> Can it still be failover to ISP A automatically?
>
> If it won't work, Do you have any suggestion?
>
> Thank you for your help
>

Ann,

I've done this for a few customers that have requested it. Some engineers
complain that advertising /24 routes dilutes the Internet routing tables,
which is true in some regards.  However, this does work in many situations
to "balance" things out.

Check out my blog post that walks through this procedure:
http://mattreath.com/2012/01/29/bgp-load-balancing/

-Matt


--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From grupo.ipv6 at gmail.com  Sat Feb  4 06:45:21 2012
From: grupo.ipv6 at gmail.com (Grupo IPv6)
Date: Sat, 4 Feb 2012 10:45:21 -0200
Subject: Some Smokeping doubts
Message-ID: <CANuE+sDX8TD7cujDxGFv=pcFUK6tr3KqEGLiuPAD3_SQn+3TjA@mail.gmail.com>

Hi all,


I?m using Smokeping (http://oss.oetiker.ch/smokeping/) and I have some
doubs that maybe you can answer:

-          Why Smokeping needs to be connected to internet even when I have
only one Target to a host in my LAN ?

-          What is exactly the Standard deviation calculated at the bottom
right of the graphs? Can it be interpreted as Jitter? Or is there another
way to know the jitter?

-          Why sometimes when I add a new host, for the first minute I get
a list of errors saying that the RDD file doesn?t exist? This happens
commonly? Is there any way to solve this problem?

Many thanks,

Gabriel

From mysidia at gmail.com  Sat Feb  4 10:51:25 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 4 Feb 2012 10:51:25 -0600
Subject: Please help our simple bgp
In-Reply-To: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
References: <CACwqZxjBp_R_b-r-9zdB+4xSO1mPmfaYhg8nuDwnt7g2i6RXTg@mail.gmail.com>
Message-ID: <CAAAwwbWL8gZA2Pq=W+rd5uDi_o0ki1NtG0cfXFhVuHhxYqMeKg@mail.gmail.com>

On Mon, Jan 30, 2012 at 8:27 PM, Ann Kwok <annkwok80 at gmail.com> wrote:

> We discover the routes is going to ISP A only even the bandwidth 100M is
> full
>
> Can we set the weight to change to ISP B to use ISP B as preference routes?
> Can the following configuration work?
>

Tuning weights and  localpreference values can influence traffic that your
equipment sends _to_ ISP A and ISP B.   These options do not control what
incoming traffic  gets forwarded into your network _from_  ISP A or ISP
B;   you need a separate strategy for incoming bits.


The config you listed should do just what the vendor documentation says it
does, so I can't say it doesn't "work";  it just  does nothing to help
remedy the situation.

That is, if you have two ISP links each 100M full duplex;  and one of them
is at 100% outbound usage,   increasing the weight of all the other
neighbor's paths  assuming the set of prefixes received over BGP are the
same,   will mean that ISP B is the preferred next-hop for each path;
which means ISP A  outgoing utilization should drop to near 0,  and  then
ISP B  should be just as fully utilized as ISP A  is currently.



You could instead identify some specific paths that are heavy users or
would carry a high percentage of the outgoing traffic,   and  use
filters/route maps  to  adjust local preference  of specific paths,  to
take outgoing load off ISP A.

or  increase the weight for 128.0.0.0/1   on routes received from ISP B,
and allow your outgoing traffic  to rest of the address space  to utilize
ISP A, for example.


But the preferred fix for this problem would be to upgrade ISP A and ISP B
links to at least double their current capacity.



Weight is a vendor-specific parameter,  local to your router.  I would
consider increasing the default local preference for ISP A first, by the
way,


But as long as you only have one router on which ISP A and ISP B sessions
land,
when you have an identical prefix from ISP A and B,  the outgoing path
through
ISP B  is to be preferred by your local router,  if the path has a higher
weight.



"  What suggest to this weight no. too? "

With weights the magnitude of the numbers and the numerical difference
between weights is not significant;  it just matters if one path has a
higher weight, or both paths have equal weight.

I would suggest weights that are uniformly spaced apart and easy to
remember, e.g. 100 200 300 400.    When you want to add  ISP C  later,  you
will also have flexibility  without re-assigning your existing weights.


If this works, how is ISP B upstream connection is down?
>
> Can it still be failover to ISP A automatically?
>
> If it won't work, Do you have any suggestion?
>
> Thank you for your help
>



-- 
-JH

From mike-nanog at tiedyenetworks.com  Sat Feb  4 13:08:18 2012
From: mike-nanog at tiedyenetworks.com (Mike)
Date: Sat, 04 Feb 2012 11:08:18 -0800
Subject: bgp history lookup tool?
Message-ID: <4F2D8222.5000304@tiedyenetworks.com>

Hi,

I am trying to diagnose an event yesterday where our provider appears to 
have dropped our routes and we were inaccessible from outside our 
provider. I thought somewhere someone was keeping a searchable database 
of bgp announce/withdrawals and it would be useful to have a peek and 
see if any such event concerning our prefix/as was seen anywhere.

Mike-


From morrowc.lists at gmail.com  Sat Feb  4 13:10:50 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 4 Feb 2012 14:10:50 -0500
Subject: bgp history lookup tool?
In-Reply-To: <4F2D8222.5000304@tiedyenetworks.com>
References: <4F2D8222.5000304@tiedyenetworks.com>
Message-ID: <CAL9jLaakqMHFgF2vnpbE8tNQKse4A2dAqdL6FvAWHKyEcm3ntQ@mail.gmail.com>

ris.ripe.net

bgpplay.routeviews.org ?

On Sat, Feb 4, 2012 at 2:08 PM, Mike <mike-nanog at tiedyenetworks.com> wrote:
> Hi,
>
> I am trying to diagnose an event yesterday where our provider appears to
> have dropped our routes and we were inaccessible from outside our provider.
> I thought somewhere someone was keeping a searchable database of bgp
> announce/withdrawals and it would be useful to have a peek and see if any
> such event concerning our prefix/as was seen anywhere.
>
> Mike-
>


From prt at prt.org  Sat Feb  4 13:12:47 2012
From: prt at prt.org (Paul Thornton)
Date: Sat, 04 Feb 2012 19:12:47 +0000
Subject: bgp history lookup tool?
In-Reply-To: <4F2D8222.5000304@tiedyenetworks.com>
References: <4F2D8222.5000304@tiedyenetworks.com>
Message-ID: <4F2D832F.9020402@prt.org>

On 04/02/2012 19:08, Mike wrote:
> Hi,
> 
> I am trying to diagnose an event yesterday where our provider appears to
> have dropped our routes and we were inaccessible from outside our
> provider. I thought somewhere someone was keeping a searchable database
> of bgp announce/withdrawals and it would be useful to have a peek and
> see if any such event concerning our prefix/as was seen anywhere.

RIPE's RIS does this - http://ris.ripe.net

Paul.


From eric at roxanne.org  Sun Feb  5 14:21:58 2012
From: eric at roxanne.org (Eric Gauthier)
Date: Sun, 5 Feb 2012 15:21:58 -0500
Subject: ISP access in Hebron, KY
Message-ID: <20120205202158.GA15605@roxanne.org>

Hello,

We're looking for DIA in the 20 - 50mbps range for a
warehouse we have in Hebron, KY.  CinBell has been a
bit "slow" to respond to our DS3 requets, so I'm 
wondering who else in town has their own facilities
(also wondering who might be a good for a backup 
circuit)?

Thanks!

Eric :)


From jra at baylink.com  Sun Feb  5 14:29:07 2012
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 5 Feb 2012 15:29:07 -0500 (EST)
Subject: Super Sunday
Message-ID: <28660078.796.1328473747740.JavaMail.root@benjamin.baylink.com>

What, no whacky weekend thread?

NBC and the NFL are, for the first time, televising the Super Bowl and its
preshow on the Internet... using a Silverlight app (so I hope you Linux people
don't enjoy football).

It's supposed to be available to tablets too, as a second-screen cast with 
selectable angles and such, but Verizontal has an exclusive on mobile, so the
target page should bounce cellphones, unless a) they lie or b) they weren't 
smart enough to IP block the carrier ranges.

  http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/

It will be interesting to see how this works out.  

Enjoy the game.  Especially if you have a Big Wall to watch it on.

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


From dave at temk.in  Sun Feb  5 12:21:27 2012
From: dave at temk.in (Dave Temkin)
Date: Sun, 05 Feb 2012 13:21:27 -0500
Subject: [NANOG-announce] Tutorials starting today, some available via webcast!
Message-ID: <4F2EC8A7.1030602@temk.in>

For the first time, NANOG will be webcasting (and archiving) some of our tutorials.

Beginning at 2PM PT, you can see John Kristoff give an Introduction to Shell and Perl Scripting for Network 
Operators, with a break from 3:30-4 and then starting back at 4PM PT with Intermediate Perl Scripting for 
Network Operators.  Both tutorials will be available later for review.

You may see all streaming options at http://www.nanog.org/streaming.php

-Dave Temkin
For the NANOG Program Committee

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From rgasnick at milestechnologies.com  Sun Feb  5 17:36:13 2012
From: rgasnick at milestechnologies.com (Ray Gasnick III)
Date: Sun, 5 Feb 2012 18:36:13 -0500
Subject: UDP port 80 DDoS attack
Message-ID: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>

We just saw a huge flux of traffic occur this morning that spiked one of our upstream ISPs gear and killed the layer 2 link on another becuase of a DDoS attack on UDP port 80.



Wireshark shows this appears to be from a compromised game server (call of duty) with source IPs in a variety of different prefixes.



Only solution thus far was to dump the victim IP address in our block into the BGP Black hole community with one of our 2 providers and completely stop advertising to the other.



Anybody see this recently and have any tips on mitigation,  reply on or off list.



Thank You,

Ray Gasnick III
CISSP, Technology Specialist: Network Security & Infrastructure
Miles Technologies
www.milestechnologies.com<http://www.milestechnologies.com/>

Phone: (856) 439-0999 x127
Direct: (856) 793-3821
How am I doing?  Email my manager at itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com>

Computer Networking ? IT Support ? Business Software ? Website Design ? Online Marketing & PR


From j at arpa.com  Sun Feb  5 17:48:51 2012
From: j at arpa.com (jamie rishaw)
Date: Sun, 5 Feb 2012 17:48:51 -0600
Subject: Superbowl traffic.
Message-ID: <CABL6YZQuvHfmH_OSmfAkxwtAcbnSTQm4PFXcmeYOtWOxVZPAdQ@mail.gmail.com>

(yeah, i used a (C) term , so sue me)

akam reporting ~17M hits/sec..
anyone seeing clearly identifiable traffic spikes (presumably due to sb)?

reply offlist if you want to submit data but don't want to be outed as
divulging corp info, but graphs and/or raw datars would be awesome
sauce. data will be aggregated/anonymized unless requested otherwise.

? ? ? ? ? ? ? ?^^ yes, you can configure your router for awesomesauce.
 so HDICMRFT flak will be nulled.  :-p

-j
-- 
"sharp, dry wit; brash in his dealings" - Forbes

X-Ob-Zing: "it's very hard not to be condescending when you're
explaining..to an idiot." -BMaher
/*     - teh jamie. ;     uri -> http://about.me/jgr     */


From fredrik at i2b.se  Sun Feb  5 17:47:11 2012
From: fredrik at i2b.se (Fredrik Holmqvist / I2B)
Date: Mon, 06 Feb 2012 00:47:11 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <273be36298d3b47f04ef10bab7c38112@imap>

Hi.

We had a customer that was attacked by the same "game server feature".
We received aprox 10 Gbit of traffic against the customer.

The attacker sends spoofed packets to the game server with the target
IP as "source", the gameserver sends replies back via UDP to the target
host. The attacker sends a couple of hundred packets per second and thus
generating a 10 Mbit UDP flood.

There is fixes/workarounds for the game servers, just a matter of the
admin taking care of it.
See: http://rankgamehosting.ru/index.php?showtopic=1320

The "attacking" IPs aren't spoofed, so just compile a list and send
e-mails to each provider.

We had 1000+ IPs gathered and sent 100+ abuse e-mails, only received
reply from less than 20%.
Sad that people care so little about mitigating DDoS/UDP/ICMP floods.


On Sun, 5 Feb 2012 18:36:13 -0500, Ray Gasnick III
<rgasnick at milestechnologies.com> wrote:
> We just saw a huge flux of traffic occur this morning that spiked one
> of our upstream ISPs gear and killed the layer 2 link on another
> becuase of a DDoS attack on UDP port 80.
> 
> 
> 
> Wireshark shows this appears to be from a compromised game server
> (call of duty) with source IPs in a variety of different prefixes.
> 
> 
> 
> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.
> 
> 
> 
> Anybody see this recently and have any tips on mitigation,  reply on
> or off list.
> 
> 
> 
> Thank You,
> 
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com<http://www.milestechnologies.com/>
> 
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at
> itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com>
> 
> Computer Networking ? IT Support ? Business Software ? Website Design
> ? Online Marketing & PR

-- 
Fredrik Holmqvist
I2B (Internet 2 Business)
070-740 5033



From keegan.holley at sungard.com  Sun Feb  5 18:21:51 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 19:21:51 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>

There aren't very many ways to combat DDOS.  That's why it's so popular.
Some ISP's partner with a company that offers a tunnel based scrubbing
service where they DPI all your traffic before they send it to you.  If you
only have a few upstreams it may be helpful to you.  I spoke to them last
year but we have too many links and too many blocks to use it.  I think the
name of the company was prolexic.  They're also a L3 VAR if you have L3
links.  There isn't alot of BGP (AFAIK) magic that doesn't involve cutting
someone off to save the rest of your customers.

2012/2/5 Ray Gasnick III <rgasnick at milestechnologies.com>

> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.
>
>
>
> Wireshark shows this appears to be from a compromised game server (call of
> duty) with source IPs in a variety of different prefixes.
>
>
>
> Only solution thus far was to dump the victim IP address in our block into
> the BGP Black hole community with one of our 2 providers and completely
> stop advertising to the other.
>
>
>
> Anybody see this recently and have any tips on mitigation,  reply on or
> off list.
>
>
>
> Thank You,
>
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure
> Miles Technologies
> www.milestechnologies.com<http://www.milestechnologies.com/>
>
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at itmanager at milestechnologies.com
> <mailto:itmanager at milestechnologies.com>
>
> Computer Networking ? IT Support ? Business Software ? Website Design ?
> Online Marketing & PR
>
>
>

From mpalmer at hezmatt.org  Sun Feb  5 18:30:39 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Mon, 6 Feb 2012 11:30:39 +1100
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <20120206003039.GZ11857@hezmatt.org>

On Sun, Feb 05, 2012 at 06:36:13PM -0500, Ray Gasnick III wrote:
> We just saw a huge flux of traffic occur this morning that spiked one of
> our upstream ISPs gear and killed the layer 2 link on another becuase of a
> DDoS attack on UDP port 80.

Yep, we've got a customer who's been hit with it a couple of times (5Gbps
the first time, 3Gbps the second).  For hysterical raisins, we don't
actually control the network for this particular customer, but the network
provider did pretty much what you did -- blackholed the victim IP.  We've
mitigated the problem by using a full-time traffic-scrubbing service -- the
hope is that the scrubbing service will pay for all the traffic and only the
good stuff will get through.  Only time will tell if it works.  We also had
to renumber the customer, as the attacks were obviously remembering the old
IP and still knocking it off the network even after the DNS was repointed at
the scrubbing service.

- Matt

-- 
"I'm tempted to try Gentoo, but then I learned that its installer is in
Python, and, well, a base Python install on my system is something like
fifty megabytes (for what?  oh, right, we NEED four XML libraries, I
forgot)."  -- Dave Brown, ASR



From rdobbins at arbor.net  Sun Feb  5 18:58:50 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 00:58:50 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
Message-ID: <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>


On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:

> There aren't very many ways to combat DDOS. 

Start with the various infrastructure/host/service BCPs, and S/RTBH, as outlined in this preso:

<https://files.me.com/roland.dobbins/dweagy>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 18:59:46 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 14:59:46 -1000
Subject: Super Sunday
References: <28660078.796.1328473747740.JavaMail.root@benjamin.baylink.com>
Message-ID: <A35872790F4D45119C1BC224552BE35F@owner59e1f1502>

Jay Ashworth wrote:
> What, no whacky weekend thread?
> 
> NBC and the NFL are, for the first time, televising the Super Bowl and its
> preshow on the Internet... using a Silverlight app (so I hope you Linux people
> don't enjoy football).
> 
> It's supposed to be available to tablets too, as a second-screen cast with
> selectable angles and such, but Verizontal has an exclusive on mobile, so the
> target page should bounce cellphones, unless a) they lie or b) they weren't
> smart enough to IP block the carrier ranges.
> 
>  http://mashable.com/2012/02/04/watch-super-bowl-xlvi-online/
> 
> It will be interesting to see how this works out.
> 
> Enjoy the game.  Especially if you have a Big Wall to watch it on.
> 
> Cheers,
> -- jr 'we want pictures' a


Halftime observations from 72.253.0.0/16:

On Vizio 37" 1080p display:
Local NBC affiliate via off-air antenna= flawless 720p picture.
Local NBC affiliate re-broadcast via Dish Network=flawless 1080i picture.
Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i picture.

On Samsung 23" 1080p monitor via Dell 2.8GHz GX270 with 7Mbps down:
Low resolution (appears to be less than VHS), sometimes jerky, picture.






From jra at baylink.com  Sun Feb  5 19:03:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 5 Feb 2012 20:03:57 -0500 (EST)
Subject: Super Sunday
In-Reply-To: <A35872790F4D45119C1BC224552BE35F@owner59e1f1502>
Message-ID: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Michael Painter" <tvhawaii at shaka.com>

> On Vizio 37" 1080p display:
> Local NBC affiliate via off-air antenna= flawless 720p picture.
> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
> picture.
> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
> picture.

I don't suppose you have the MPEG bitrates on those... :-)

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


From keegan.holley at sungard.com  Sun Feb  5 19:10:39 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:10:39 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
Message-ID: <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>

An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
and RTBH?  The first four will not work against a DDOS attack and the last
one just kills the patient so he does not infect other patients.  As I said
earlier beyond traffic scrubbing offsite there isn't much defense against
DDOS.

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 7:21 AM, Keegan Holley wrote:
>
> > There aren't very many ways to combat DDOS.
>
> Start with the various infrastructure/host/service BCPs, and S/RTBH, as
> outlined in this preso:
>
> <https://files.me.com/roland.dobbins/dweagy>
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>
>
>

From rdobbins at arbor.net  Sun Feb  5 19:20:11 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:20:11 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
Message-ID: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>


On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:

> An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping, and RTBH?

Actually, no, that isn't the focus of the preso.

> The first four will not work against a DDOS attack

This is incorrect - suggest you read the preso.

> and the last one just kills the patient so he does not infect other patients. 

S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest you read the preso.

There's been a lot of discussion on this topic on NANOG, suggest you take a look through the archives.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From glen.kent at gmail.com  Sun Feb  5 19:20:54 2012
From: glen.kent at gmail.com (Glen Kent)
Date: Mon, 6 Feb 2012 06:50:54 +0530
Subject: Optimal IPv6 router
Message-ID: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>

Hi,

Most routers today are basically IPv4 routers, with IPv6 thrown in.
They are however designed keeping IPv4 in mind.

With IPv6 growing, if we were to design a native IPv6 router, with
IPv4 functionality thrown in, then is it possible to design a more
optimal IPv6 router, than what exists today?

Glen


From rdobbins at arbor.net  Sun Feb  5 19:22:38 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:22:38 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
Message-ID: <0793C62F-214E-4105-885E-469562751463@arbor.net>


On Feb 6, 2012, at 8:20 AM, Dobbins, Roland wrote:

> Actually, no, that isn't the focus of the preso.

More info here:

<https://files.me.com/roland.dobbins/l53gjr>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 19:23:51 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 15:23:51 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
Message-ID: <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>

Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Michael Painter" <tvhawaii at shaka.com>
>
>> On Vizio 37" 1080p display:
>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>> picture.
>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>> picture.
>
> I don't suppose you have the MPEG bitrates on those... :-)
>
> Cheers,
> -- jra

No, but that's my next project.  I just received the ATSC dongle from AVerMedia.

Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we 
made it with 2 hours to spare.<g>

Best,

--Michael 



From mike.lyon at gmail.com  Sun Feb  5 19:27:52 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 5 Feb 2012 17:27:52 -0800
Subject: Super Sunday
In-Reply-To: <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
Message-ID: <-3886999636273882100@unknownmsgid>

Sent from my iPhone

On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:

> Jay Ashworth wrote:
>> ----- Original Message -----
>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>
>>> On Vizio 37" 1080p display:
>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>> picture.
>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>> picture.
>>
>> I don't suppose you have the MPEG bitrates on those... :-)
>>
>> Cheers,
>> -- jra
>
> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>
> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we made it with 2 hours to spare.<g>
>
> Best,
>
> --Michael
>

What gear were you using for the sports bar?

-mike


From keegan.holley at sungard.com  Sun Feb  5 19:37:34 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:37:34 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
Message-ID: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
>
> > An entire power point just to recommend ACL's, uRPF, CPP, DHCP snooping,
> and RTBH?
>
> Actually, no, that isn't the focus of the preso.
>
> > The first four will not work against a DDOS attack
>
> This is incorrect - suggest you read the preso.
>

The ACL's are configured on the routers belonging to the victim AS which
will not save their access pipe if it's overrun unless I'm missing
something.  uRPF may help with spoofed traffic, but sometimes causes
problems with multi-homing and is often more harmful than helpful depending
on the network design.

>
> > and the last one just kills the patient so he does not infect other
> patients.
>
> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
> you read the preso.
>

Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
It also isn't as widely supported as it should be. I never said DDOS was
hopeless, there just aren't a wealth of defenses against it.

From rdobbins at arbor.net  Sun Feb  5 19:43:52 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:43:52 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>


On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:

> Source RTBH often falls victim to rapidly changing or spoofed source IP"s. 

S/RTBH can be rapidly shifted in order to deal with changing purported source IPs, and it isn't limited to /32s.  It's widely supported on Cisco and Juniper gear (flowspec is a better choice on Juniper gear).

If folks don't want to read the presos or search through the archives, that's fine, of course.  The fact is that there are quite a few things that operators can and should do in order to mitigate DDoS attacks; and making the perfect the enemy of the merely good only helps the attackers, doesn't it?

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From tvhawaii at shaka.com  Sun Feb  5 19:47:03 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 15:47:03 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
Message-ID: <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>

Mike Lyon wrote:
> Sent from my iPhone
>
> On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:
>
>> Jay Ashworth wrote:
>>> ----- Original Message -----
>>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>>
>>>> On Vizio 37" 1080p display:
>>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>>> picture.
>>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>>> picture.
>>>
>>> I don't suppose you have the MPEG bitrates on those... :-)
>>>
>>> Cheers,
>>> -- jra
>>
>> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>>
>> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but 
>> we made
>> it with 2 hours to spare.<g>
>>
>> Best,
>>
>> --Michael
>>
>
> What gear were you using for the sports bar?
>
> -mike

I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog system.  Works great.
http://www.zeevee.com/hdbridge



From keegan.holley at sungard.com  Sun Feb  5 19:50:23 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 20:50:23 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
Message-ID: <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>

2012/2/5 Dobbins, Roland <rdobbins at arbor.net>

>
> On Feb 6, 2012, at 8:37 AM, Keegan Holley wrote:
>
> > Source RTBH often falls victim to rapidly changing or spoofed source
> IP"s.
>
> S/RTBH can be rapidly shifted in order to deal with changing purported
> source IPs, and it isn't limited to /32s.  It's widely supported on Cisco
> and Juniper gear (flowspec is a better choice on Juniper gear).
>
> I was referring to support from ISP's not from hardware vendors.

If folks don't want to read the presos or search through the archives,
> that's fine, of course.  The fact is that there are quite a few things that
> operators can and should do in order to mitigate DDoS attacks; and making
> the perfect the enemy of the merely good only helps the attackers, doesn't
> it?
>
> Yes but assuming everything discussed at a conference is instantly adopted
by the entire industry gives one false hope no?

From rdobbins at arbor.net  Sun Feb  5 19:54:01 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Mon, 6 Feb 2012 01:54:01 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CABO8Q6RttiH6NjsTwKpq_8ZCaN8fdOwjYJAYnkRH+GR5k0grVg@mail.gmail.com>
Message-ID: <B65E1D8C-B8D2-468C-B6E5-D6519F1B4AC6@arbor.net>


On Feb 6, 2012, at 8:50 AM, Keegan Holley wrote:

> Yes but assuming everything discussed at a conference is instantly adopted by the entire industry gives one false hope no?

I'm certainly not making that assumption - hence the presos.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From joelja at bogus.com  Sun Feb  5 20:01:41 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Sun, 05 Feb 2012 18:01:41 -0800
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <4F2F3485.2020503@bogus.com>

On 2/5/12 17:20 , Glen Kent wrote:
> Hi,
> 
> Most routers today are basically IPv4 routers, with IPv6 thrown in.
> They are however designed keeping IPv4 in mind.
> 
> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

Asic based forwarding engines with ipv6 support are more than a decade
old at this point.

If one looks at an asr9000 or an MX or T that looks like an ipv6 router
to me.

> Glen
> 



From Valdis.Kletnieks at vt.edu  Sun Feb  5 20:07:57 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 05 Feb 2012 21:07:57 -0500
Subject: Optimal IPv6 router
In-Reply-To: Your message of "Mon, 06 Feb 2012 06:50:54 +0530."
 <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <107963.1328494077@turing-police.cc.vt.edu>

On Mon, 06 Feb 2012 06:50:54 +0530, Glen Kent said:

> Most routers today are basically IPv4 routers, with IPv6 thrown in.
Not sure if this statement is troll bait or flame bate. Probably both. ;)

I see Joel has already confirmed my memory that vendors had ASICs
doing IPv6 forwarding last century.

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

OK, I'll bite.  What would qualify as a "native IPv6" router?  Is this
another concept as silly as "hardware vs software based" routers?

And whaqt would be the definition of "more optimal"?  Just fixing
the current feature parity mismatch with the IPv4 side, or you got
some new routing paradigm in mind or something?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120205/9bf86740/attachment.bin>

From mike.lyon at gmail.com  Sun Feb  5 20:20:40 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 5 Feb 2012 18:20:40 -0800
Subject: Super Sunday
In-Reply-To: <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
 <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
Message-ID: <-2382828026831401363@unknownmsgid>

When i did a sports bar of about 24 HD TVs, i used gear from here:

http://www.neoprointegrator.com/products.php

Good product, good support.

-mike

Sent from my iPhone

On Feb 5, 2012, at 17:47, Michael Painter <tvhawaii at shaka.com> wrote:

> Mike Lyon wrote:
>> Sent from my iPhone
>>
>> On Feb 5, 2012, at 17:24, Michael Painter <tvhawaii at shaka.com> wrote:
>>
>>> Jay Ashworth wrote:
>>>> ----- Original Message -----
>>>>> From: "Michael Painter" <tvhawaii at shaka.com>
>>>>
>>>>> On Vizio 37" 1080p display:
>>>>> Local NBC affiliate via off-air antenna= flawless 720p picture.
>>>>> Local NBC affiliate re-broadcast via Dish Network=flawless 1080i
>>>>> picture.
>>>>> Local NBC affiliate re-broadcast via DirecTV Network=flawless 1080i
>>>>> picture.
>>>>
>>>> I don't suppose you have the MPEG bitrates on those... :-)
>>>>
>>>> Cheers,
>>>> -- jra
>>>
>>> No, but that's my next project.  I just received the ATSC dongle from AVerMedia.
>>>
>>> Getting the SuperBowl in HD (and the house-sound in sync) to all 32 displays at the sportsbar has been a challenge, but we made
>>> it with 2 hours to spare.<g>
>>>
>>> Best,
>>>
>>> --Michael
>>>
>>
>> What gear were you using for the sports bar?
>>
>> -mike
>
> I'm integrating the b520 modulator(s) into our exisiting 16 Ch. analog system.  Works great.
> http://www.zeevee.com/hdbridge
>


From mohta at necom830.hpcl.titech.ac.jp  Sun Feb  5 20:52:30 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 06 Feb 2012 11:52:30 +0900
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
Message-ID: <4F2F406E.5060205@necom830.hpcl.titech.ac.jp>

Glen Kent wrote:

> With IPv6 growing, if we were to design a native IPv6 router, with
> IPv4 functionality thrown in, then is it possible to design a more
> optimal IPv6 router, than what exists today?

It depends on what you want routers to do.

As I am working on Tbps photonic routers with fiber delay lines,
the bottleneck is at constant time (nano seconds order) electric
route look up.

There, several simple 4M*16bit SRAMs is fine for IPv4 with mostly
/24 routing table entries.

IPv6 was better because TLA had was merely 13bit long with only
8192 entries.

However, as the idea of TLA was abandoned long before and a lot
more than /24 is, seemingly, necessary for route look up of IPv6
backbone, I'm afraid IPv6 needs large amount of power consuming
content addressable memories.

Without any (defacto) standard prefix length at the IPv6 backbone,
it is simply impossible to say "optimal".

						Masataka Ohta


From steve.bertrand at gmail.com  Sun Feb  5 21:08:19 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Sun, 05 Feb 2012 22:08:19 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <4F2F4423.8040803@gmail.com>

On 2012.02.05 20:37, Keegan Holley wrote:
> 2012/2/5 Dobbins, Roland<rdobbins at arbor.net>

>> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>> you read the preso.
>>
>
> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
> It also isn't as widely supported as it should be. I never said DDOS was
> hopeless, there just aren't a wealth of defenses against it.

This is so very easily automated. Even if you don't actually want to 
trigger the routes automatically, finding the sources you want to 
blackhole is as simple as a monitor port, tcpdump and some basic Perl.

...and as far as this not having been deployed in many ISPs (per your 
next message)... their mitigation strategies should be asked up front, 
and if they don't have any (or don't know what you speak of), find a new 
ISP.

Steve


From tvhawaii at shaka.com  Sun Feb  5 21:23:44 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sun, 5 Feb 2012 17:23:44 -1000
Subject: Super Sunday
References: <25630107.824.1328490237846.JavaMail.root@benjamin.baylink.com>
 <B1FA751D3847460B96D2DE8DD7A4961C@owner59e1f1502>
 <-3886999636273882100@unknownmsgid>
 <6A32CE5ECA4543018459FEDAC15C2084@owner59e1f1502>
 <-2382828026831401363@unknownmsgid>
Message-ID: <BD06F18B23A446E18FD743072E68618E@owner59e1f1502>

Mike Lyon wrote:
> When i did a sports bar of about 24 HD TVs, i used gear from here:
> 
> http://www.neoprointegrator.com/products.php
> 
> Good product, good support.
> 
> -mike


Looks like a well designed product...Thanks!

Any idea of what the 'Tahoe' costs (we have 16 sources)? 

--Michael


From keegan.holley at sungard.com  Sun Feb  5 21:30:20 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Sun, 5 Feb 2012 22:30:20 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F2F4423.8040803@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
Message-ID: <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>

2012/2/5 Steve Bertrand <steve.bertrand at gmail.com>

> On 2012.02.05 20:37, Keegan Holley wrote:
>
>> 2012/2/5 Dobbins, Roland<rdobbins at arbor.net>
>>
>
>  S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>>> you read the preso.
>>>
>>>
>> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.
>>
>
> This is so very easily automated. Even if you don't actually want to
> trigger the routes automatically, finding the sources you want to blackhole
> is as simple as a monitor port, tcpdump and some basic Perl.
>

This is still vulnerable to spoofing which could cause you to filter
legitimate traffic and make the problem worse.  Not saying that S/RTBH is a
bad idea.  RTBH is effective and a great idea just not very elegant.


>
> ...and as far as this not having been deployed in many ISPs (per your next
> message)... their mitigation strategies should be asked up front, and if
> they don't have any (or don't know what you speak of), find a new ISP.
>

You sometimes have to weigh the pro's and cons.  You can't always pick the
guys with the coolest knobs.

From steve.bertrand at gmail.com  Sun Feb  5 21:40:19 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Sun, 05 Feb 2012 22:40:19 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
 <CABO8Q6TcybzxOBzuab2dxqWecKOU37dGcDaJ1hqWfgF9dAZG2g@mail.gmail.com>
Message-ID: <4F2F4BA3.6080305@gmail.com>

On 2012.02.05 22:30, Keegan Holley wrote:
  > 2012/2/5 Steve Bertrand <steve.bertrand at gmail.com
>     On 2012.02.05 20 <tel:2012.02.05%2020>:37, Keegan Holley wrote:
>         Source RTBH often falls victim to rapidly changing or spoofed
>         source IP"s.
>         It also isn't as widely supported as it should be. I never said
>         DDOS was
>         hopeless, there just aren't a wealth of defenses against it.
>
>
>     This is so very easily automated. Even if you don't actually want to
>     trigger the routes automatically, finding the sources you want to
>     blackhole is as simple as a monitor port, tcpdump and some basic Perl.
>
>
> This is still vulnerable to spoofing which could cause you to filter
> legitimate traffic and make the problem worse.  Not saying that S/RTBH
> is a bad idea.  RTBH is effective and a great idea just not very elegant.

Agreed. Diligence does play a role. However, the times I have 
implemented and used (s/)RTBH, I thought it was most elegant. I love its 
simplicity and effectiveness.

>     ...and as far as this not having been deployed in many ISPs (per
>     your next message)... their mitigation strategies should be asked up
>     front, and if they don't have any (or don't know what you speak of),
>     find a new ISP.
>
>
> You sometimes have to weigh the pro's and cons.  You can't always pick
> the guys with the coolest knobs.

Agreed. But to me, DDOS mitigation is not just a cool knob. If my ISP 
can help mitigate a 1Gb onslaught so my 100Mb pipe isn't overwhelmed, 
that's more functional than cool. Ranks right up there with IPv6 ;)

Steve


From mtinka at globaltransit.net  Sun Feb  5 22:19:43 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 12:19:43 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CANEysbH_n5SCCtvyv80aJQqNxN6kNJiVF_UADFu+0tQcUfEq1g@mail.gmail.com>
 <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
Message-ID: <201202061219.47007.mtinka@globaltransit.net>

On Wednesday, February 01, 2012 02:57:46 AM Tony McCrory 
wrote:

> Surely something is better than nothing.  Advertise the
> /24's and the /25's, see what happens.

The fact that the hijacking ISP's upstreams accepted routes 
through their network that didn't belong to that ISP is bad 
enough.

That we should still be able to advertise anything without 
an appropriate filter being in place and expecting it to 
work (even if it's with good intention, as in this case) is 
equally as bad.

A big fail to our community, for up to this day, not 
implementing basic routing and forwarding filters that would 
do away with all this cruft in the first place.

Clearly the Youtube/Pakistan/PCCW incident has long been 
forgotten.

But that's life, I guess...

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/072dee90/attachment.bin>

From ops.lists at gmail.com  Sun Feb  5 22:26:51 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 6 Feb 2012 09:56:51 +0530
Subject: Hijacked Network Ranges
In-Reply-To: <201202061219.47007.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CANEysbH_n5SCCtvyv80aJQqNxN6kNJiVF_UADFu+0tQcUfEq1g@mail.gmail.com>
 <CAG9TQPmSMVZ9NoL5JBFx8uLuzRn2GPogc8zsBBtdrGu6bMptJQ@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
Message-ID: <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>

I had this happen to me in 2008 -
http://www.gossamer-threads.com/lists/nanog/users/110097
Total pain in the ass when it does happen.  Funnily enough in that
case it was another downstream of the same ISP who was pulling this
stunt ..

--srs

On Mon, Feb 6, 2012 at 9:49 AM, Mark Tinka <mtinka at globaltransit.net> wrote:
>
>
> The fact that the hijacking ISP's upstreams accepted routes
> through their network that didn't belong to that ISP is bad
> enough.
>
> That we should still be able to advertise anything without
> an appropriate filter being in place and expecting it to
> work (even if it's with good intention, as in this case) is
> equally as bad.



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From mtinka at globaltransit.net  Sun Feb  5 22:49:49 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 12:49:49 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9DDF8@RWC-MBX1.corp.seven.com>
References: <CAKGDpZ75Vs+s1+1XzDjQhzswR8Y7mC7_jOuAtYjBqrJDLguXTw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9DDF8@RWC-MBX1.corp.seven.com>
Message-ID: <201202061249.52468.mtinka@globaltransit.net>

On Wednesday, February 01, 2012 12:10:32 PM George Bonser 
wrote:

> Customer relationship with Kelvin's firm terminated and
> they contracted for service elsewhere but are apparently
> attempting to maintain the use of the address
> allocation(s) they received from Kelvin's firm.  They
> apparently did this by misrepresenting the fact that
> they were entitled to use that address space.

We've been in such situations without customers requesting 
us either to:

	a) Block certain addresses across their transit
	   links in order to mitigate DoS attacks.

	b) Announce address space which does not necessarily
	   belong to them, even though they aren't being
	   nefarious.


In either case, a quick check of the RIR WHOIS database to 
qualify consistency in information does not hurt. Yes, WHOIS 
records aren't always the most up-to-date, but it's a fairly 
good representation of the truth most of the time, 
especially since 'inetnum' objects tend to be managed by the 
RIR's themselves, last time I checked.

This is quickly making the case for RPKI.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/4fb90542/attachment.bin>

From mtinka at globaltransit.net  Sun Feb  5 23:01:20 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 13:01:20 +0800
Subject: Thanks & Let's Prevent this in the Future.
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
References: <CANEysbEnLj4ck7EZsL14KS9KHvOH_+z8K3TexB81HdTmiyng0w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09C9E402@RWC-MBX1.corp.seven.com>
Message-ID: <201202061301.23850.mtinka@globaltransit.net>

On Thursday, February 02, 2012 01:00:43 AM George Bonser 
wrote:

> One problem is the number of routing registries and the
> requirements differ for them.  The nefarious operator
> can enter routes in an IRR just as easily as a
> legitimate operator.  There was a time when some
> significant networks used the IRRs for their filtration
> policy.  I'm not sure how many still do.

I've dealt with AfriNIC and APNIC WHOIS databases, and they 
normally control the 'inetnum' and inet6num' entries that go 
into the WHOIS databases. So there is some degree of 
certainty that what is in there is generally true.

You're right, anyone can create an IRR record, and it's 
quite terrible how easy it is to create false information 
that could break another person's network. This is why we 
don't generally trust IRR or PeeringDB data when verifying 
downstream prefixes which we should permit through our 
filters. We rely on the RIR 'inetnum' and 'inet6num' records 
for that.

My memory fails me on what ARIN do, but before AfriNIC was 
established and the majority of Africa's prefixes were 
allocated by RIPE and ARIN, I recall the ARIN policy (SWIP 
templates, et al) being a hassle-rich experience that 
anything else is long forgotten :-).

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/c1be930d/attachment.bin>

From mtinka at globaltransit.net  Sun Feb  5 23:07:39 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 13:07:39 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
Message-ID: <201202061307.39935.mtinka@globaltransit.net>

On Monday, February 06, 2012 12:26:51 PM Suresh 
Ramasubramanian wrote:

> I had this happen to me in 2008 -
> http://www.gossamer-threads.com/lists/nanog/users/110097
> Total pain in the ass when it does happen.  Funnily
> enough in that case it was another downstream of the
> same ISP who was pulling this stunt ..

Clearly the joy of running a clean network is not shared by 
all :-).

Yes, it is a little bit of extra hassle having to update 
filters when your downstreams make change requests 
(including verification, e.t.c.). But when some of our 
upstreams make us go through this, I'm much happier they do 
than they if they didn't. Some are even asking us to "fax" 
documents of such requests; a little extreme, but okay, I'll 
bite :-).

We do have some upstreams who are pretty lax about this. But 
we certainly are not, and as a result, are yet to put one of 
our customers or the Internet in jeopardy because we let one 
through the cracks.

It's 2012, we really shouldn't be seeing this type of thing 
anymore, particularly after what happened in Pakistan.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/1b01d2e1/attachment.bin>

From morrowc.lists at gmail.com  Sun Feb  5 23:14:20 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 6 Feb 2012 00:14:20 -0500
Subject: Hijacked Network Ranges
In-Reply-To: <201202061307.39935.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
Message-ID: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>

On Mon, Feb 6, 2012 at 12:07 AM, Mark Tinka <mtinka at globaltransit.net> wrote:

> It's 2012, we really shouldn't be seeing this type of thing
> anymore, particularly after what happened in Pakistan.

s/pakistan/pakistan,nyc(ntt),minneapolis(ntt),level3's incidents, .../

there's lots of people that have fallen victim of:
  o not having filters at all (pccw/pktel)
  o filtering using old/stale data (ntt/l3)

why aren't filters applied at all? ("its hard, people keep asking me
to update them, bah! work!")
why aren't filter data bases kept up to date? ("its hard, i have to
email something to radb/altdb/etc... bah, work!")
why aren't checks of the filter data simple and mechanical? (and
accurate?) ("Bah! work! plus, have you looked at the ouptput? bah!
work!")

resource certification would at least get us to the point where
checking the data in the IRR is 'easy', it's not going to get people
to PUT FILTERS ON CUSTOMER SESSIONS, and it's not going to get people
to update their IRR objects (add AND DELETE!!!)

-chris


From mtinka at globaltransit.net  Mon Feb  6 00:35:35 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 14:35:35 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
Message-ID: <201202061435.39053.mtinka@globaltransit.net>

On Monday, February 06, 2012 01:14:20 PM Christopher Morrow 
wrote:

>   o not having filters at all (pccw/pktel)

Well, we know what this leads to (part of the reasons you 
find some eBGP sessions carrying /25's or longer + RFC 1918 
space is because of this).

>   o filtering using old/stale data (ntt/l3)

Well, we think that this problem resolves itself rather 
well:

	o If a customer is not getting traffic hitting a
 	  prefix, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer is not seeing their prefix on the
	  Internet, they'll check with their upstream on if
	  their prefix is being received and propagated.

	o If a customer starts announcing a new prefix
	  without updating their upstream, one e-mail or
	  phone call to the upstream will get this fixed.


In all cases above, it's better not to have an unauthorized 
prefix in the yonder than have open filters, because one is 
more likely to quickly get resolved without any colleteral 
than the other.

> why aren't filters applied at all? ("its hard, people
> keep asking me to update them, bah! work!")

Well, so was running the Internet without BGP communities or 
prefix lists or AS_PATH filters, until they appeared. And 
while some folk still use so-called "distribute lists" 
today, it's fine with me as long as they maintain secure 
operations with whatever solution they choose, hard or easy.

Some ISP's have automated this process either by using 
internal IRR software, or scripting web GUI's that their NOC 
can use to simply stick in the prefix, select which router 
to update, and bam!

Compared to the alternative, this is a small price to pay.

> why aren't filter data bases kept up to date? ("its hard,
> i have to email something to radb/altdb/etc... bah,
> work!")...

That's why we use the RIPE RR. They have a cool web GUI that 
you can use to edit on object, including IRR data (and 
they're respected by all other major RR's and operators):

	https://apps.db.ripe.net/webupdates/


It certainly beats the old "MAIL FROM" system, although I 
believe that is still operational.

> why aren't checks of the filter data simple and
> mechanical? (and accurate?) ("Bah! work! plus, have you
> looked at the ouptput? bah! work!")

See above.

We manually check the RIR WHOIS database. I'm sure some 
networks might automate this with an internal system that 
checks the RIR WHOIS database, and probably integrates with 
their provisioning system that can automatically create and 
update filters on routers. I don't know...

But it's certainly better than the alternative.

> resource certification would at least get us to the point
> where checking the data in the IRR is 'easy', it's not
> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
> and it's not going to get people to update their IRR
> objects (add AND DELETE!!!)

I support RPKI, but also realize that operator support will 
take a very long time for various reasons, e.g., education, 
delayed software upgrades, persistence with older methods, 
fear of centralization, e.t.c.

In such a case, operators will need to support "Invalid" and 
"NotFound" states of origin information for a long time. As 
adoption and deployment increases, operators can begin 
dropping "Invalid" results, "NotFound" results, or both. Or 
even mark them down with poor LOCAL_PREF values so as not to 
use those routes for forwarding unless it is really 
necessary.

At some point, when diffusion of RPKI is sufficiently 
prolific, anything that does not return a "Valid" result 
will be dropped. This should force every operator around the 
world to support it, much like the large carriers forced us 
all to use IRR's just so they won't ignore our routes, 
wherever we are in the world.

But before all this happens, we have to prevent more 
hijacks. And we have to use the tools we have today.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/ea1bda25/attachment.bin>

From goemon at anime.net  Mon Feb  6 00:41:53 2012
From: goemon at anime.net (goemon at anime.net)
Date: Sun, 5 Feb 2012 22:41:53 -0800 (PST)
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>

On Mon, 6 Feb 2012, Christopher Morrow wrote:
> why aren't filters applied at all?

filters don't generate revenue.

-Dan


From gbonser at seven.com  Mon Feb  6 00:53:59 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 6 Feb 2012 06:53:59 +0000
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CB249F@RWC-MBX1.corp.seven.com>

> To: Christopher Morrow
> Cc: nanog at nanog.org
> Subject: Re: Hijacked Network Ranges
> 
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.
> 
> -Dan

Don't agree with the implied notion that a commercial network provider won't do anything that doesn't produce revenue.  They do all sorts of things that don't produce revenue, like purchase door locks and security cameras.  This is along the same avenue only for their networking which is their core competency.



From steve at pirk.com  Mon Feb  6 00:55:17 2012
From: steve at pirk.com (steve pirk [egrep])
Date: Sun, 5 Feb 2012 22:55:17 -0800
Subject: Verisign deep-hacked. For months.
In-Reply-To: <CB506D08.34718%zaid@zaidali.com>
References: <CAArzuou_GeCOQwsXHza_iykuKH-S44hQWutzVeSh9JSJ2AoKFw@mail.gmail.com>
 <CB506D08.34718%zaid@zaidali.com>
Message-ID: <CAK4no05X34E9Ok3JyrkZSfEq4XesUNmMs4CrfotBQvGBamKpjg@mail.gmail.com>

On Thu, Feb 2, 2012 at 16:42, Zaid Ali <zaid at zaidali.com> wrote:

> That part is ambiguous at the moment since Verisign has not released
> details. Symantec has bought the SSL part of the business and claim that
> the SSL acquired network is not compromised. Sounds like lots of
> assumptions being drawn.
>
> Zaid
>
>
I am thinking it is related to the Chinese hacking of Gmail accounts in the
fall of 2010. Symantic acquired the SSL business in August 2010. The
hacking could have been in the spring for all we know. Google uses Thwate
as it's CA, but Thwate has "Builtin Object Token: Verisign Class 3 Public
Primary Certificate Authority" as it's root.

Seems to me part of the problem was traced back to browsers not checking
revoked certs via the browser CRLs. Didn't some in the chain have revoked
certs still installed?

-- 
steve pirk
yensid
"father... the sleeper has awakened..." paul atreides - dune
Google+ pirk.com

From mtinka at globaltransit.net  Mon Feb  6 01:04:18 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 15:04:18 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <201202061504.21817.mtinka@globaltransit.net>

On Monday, February 06, 2012 02:41:53 PM goemon at anime.net 
wrote:

> filters don't generate revenue.

Neither does traffic - that does generate revenue - not 
reaching your customer.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/5a76e4f5/attachment.bin>

From morrowc.lists at gmail.com  Mon Feb  6 01:06:24 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 6 Feb 2012 02:06:24 -0500
Subject: Hijacked Network Ranges
In-Reply-To: <201202061435.39053.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
Message-ID: <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>

On Mon, Feb 6, 2012 at 1:35 AM, Mark Tinka <mtinka at globaltransit.net> wrote:
> On Monday, February 06, 2012 01:14:20 PM Christopher Morrow

> We manually check the RIR WHOIS database. I'm sure some

do you have customers with 10k long prefix lists? it gets hard when
the lists get long, or the data is for downstream folks of your
customer. Good that someone's checking though, I'd love to see this
part automated.

>> resource certification would at least get us to the point
>> where checking the data in the IRR is 'easy', it's not
>> going to get people to PUT FILTERS ON CUSTOMER SESSIONS,
>> and it's not going to get people to update their IRR
>> objects (add AND DELETE!!!)
>
> I support RPKI, but also realize that operator support will
> take a very long time for various reasons, e.g., education,
> delayed software upgrades, persistence with older methods,
> fear of centralization, e.t.c.
>
> In such a case, operators will need to support "Invalid" and
> "NotFound" states of origin information for a long time. As

RPKI doesn't necessarily mean that the router knows anything about
certificates in the short-term. I think there's a time when 'the
resource certification system' (which is really, today, the rpki)
holds cert/roa data that you could use to filter what the IRR tells
you for a customer. You could even do this in any automated manner!

> adoption and deployment increases, operators can begin
> dropping "Invalid" results, "NotFound" results, or both. Or
> even mark them down with poor LOCAL_PREF values so as not to
> use those routes for forwarding unless it is really
> necessary.

The time between the previous and next paragraphs though is when all
isp's will need to beat the drums with their customers saying: "Hey,
you REALLY need to get that shit into the 'resource certification
system' (rpki), NOW." (because shortly we'll stop accepting your
"invalid" routes... and then the interwebs won't be able to find you,
and we'll all be sad.)

> At some point, when diffusion of RPKI is sufficiently
> prolific, anything that does not return a "Valid" result
> will be dropped. This should force every operator around the
> world to support it, much like the large carriers forced us
> all to use IRR's just so they won't ignore our routes,
> wherever we are in the world.
>
> But before all this happens, we have to prevent more
> hijacks. And we have to use the tools we have today.

sure... it's not working so well though :(


From m.hallgren at free.fr  Mon Feb  6 01:24:37 2012
From: m.hallgren at free.fr (Michael Hallgren)
Date: Mon, 06 Feb 2012 08:24:37 +0100
Subject: Hijacked Network Ranges
In-Reply-To: <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061219.47007.mtinka@globaltransit.net>
 <CAArzuosbONqwXhW4ozv8_Ry90RiPbuO7CiWymM4Be9epKvZEjg@mail.gmail.com>
 <201202061307.39935.mtinka@globaltransit.net>
 <CAL9jLabUzVFZ=nk6OZAfQgx6xAgkvA1yCEyB+7Be-DvWXQyMuw@mail.gmail.com>
 <Pine.LNX.4.64.1202052241390.2009@sasami.anime.net>
Message-ID: <1328513077.26894.0.camel@home>

Le dimanche 05 f?vrier 2012 ? 22:41 -0800, goemon at anime.net a ?crit :
> On Mon, 6 Feb 2012, Christopher Morrow wrote:
> > why aren't filters applied at all?
> 
> filters don't generate revenue.

... but at times, they prevent loss of... ...

mh

> 
> -Dan
> 




From jsw at inconcepts.biz  Mon Feb  6 01:33:29 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 6 Feb 2012 02:33:29 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F2F4423.8040803@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <4F2F4423.8040803@gmail.com>
Message-ID: <CAPWAtbKCqBQOVxmzJH3z4nJyWsUYVA1LyWPJ_y5f4fucRE++uQ@mail.gmail.com>

On Sun, Feb 5, 2012 at 10:08 PM, Steve Bertrand
<steve.bertrand at gmail.com> wrote:
> This is so very easily automated. Even if you don't actually want to trigger
> the routes automatically, finding the sources you want to blackhole is as

What transit providers are doing flow-spec, or otherwise, to allow
their downstreams to block malicious traffic by SOURCE address?

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From dr at cluenet.de  Mon Feb  6 01:34:26 2012
From: dr at cluenet.de (Daniel Roesen)
Date: Mon, 6 Feb 2012 08:34:26 +0100
Subject: Optimal IPv6 router
In-Reply-To: <107963.1328494077@turing-police.cc.vt.edu>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
Message-ID: <20120206073426.GB8779@srv03.cluenet.de>

On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks at vt.edu wrote:
> OK, I'll bite.  What would qualify as a "native IPv6" router?

Perhaps those which were designed with IPv4+IPv6 in mind from day 1,
both in hardware and software - like Juniper/JUNOS. In contrast to other
the gear where IPv6 was always an aftermath, which shows in both
hardware (limits of performance, functionality and scaling) as well as
software (every feature gets implemented twice, even if the feature
itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
on XR]).

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From mtinka at globaltransit.net  Mon Feb  6 01:59:29 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 15:59:29 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
Message-ID: <201202061559.32377.mtinka@globaltransit.net>

On Monday, February 06, 2012 03:06:24 PM Christopher Morrow 
wrote:

> do you have customers with 10k long prefix lists? it gets
> hard when the lists get long, or the data is for
> downstream folks of your customer. Good that someone's
> checking though, I'd love to see this part automated.

No, we don't have customers with 10,000-long prefix lists, 
but we have planned to implement automation (either using 
the IRR Toolset or home-grown solutions) to make this 
possible as a means to scaling, should that time arise.

As it is now, throwing NOC staff at the problem for the 
volumes we have works well enough. But this is, by no means, 
a panacea as we scale up.

Heck, one must even worry whether a some router 
configurations can take that many lines. But there are other 
ways around that.

> RPKI doesn't necessarily mean that the router knows
> anything about certificates in the short-term. I think
> there's a time when 'the resource certification system'
> (which is really, today, the rpki) holds cert/roa data
> that you could use to filter what the IRR tells you for
> a customer. You could even do this in any automated
> manner!

Well, given validation information will be available within 
a network, one may use it in non-obvious ways to implement 
policy.

> The time between the previous and next paragraphs though
> is when all isp's will need to beat the drums with their
> customers saying: "Hey, you REALLY need to get that shit
> into the 'resource certification system' (rpki), NOW."
> (because shortly we'll stop accepting your "invalid"
> routes... and then the interwebs won't be able to find
> you, and we'll all be sad.)

Well, we have all seen how doing this with DNSSEC, IPv6 and 
4-byte ASN's worked out.

We need to understand that different operators and different 
customers will have varying reasons as to why they can't yet 
"do the right thing". There is abundant evidence of this 
with other similar initiatives.

Adoption will have to be incremental. During that time, the 
Internet must not break.

> sure... it's not working so well though :(

Not for lack of having some kind of solution.

What we have today may not be the best, most scalable 
option, but it is one nonetheless. Automating it (like what 
RPSL does) is how you can make it scale to some extent, but 
it's still the same solution.

We can't just sit around waiting for RPKI. There will be 
some reason why some of us can't deploy it, while someone 
else is thinking up its successor. Rinse, repeat.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/7de69fc1/attachment.bin>

From ops.lists at gmail.com  Mon Feb  6 04:46:53 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Mon, 6 Feb 2012 16:16:53 +0530
Subject: Hijacked Network Ranges
In-Reply-To: <201202061559.32377.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
Message-ID: <CAArzuov2k_sjeoDRTwTq_=EnWjCFsFfUot=8TWUT4nKZZKH2Rg@mail.gmail.com>

That and rely on external telemetry (argus and friends..)

On Mon, Feb 6, 2012 at 1:29 PM, Mark Tinka <mtinka at globaltransit.net> wrote:
>
> Well, given validation information will be available within
> a network, one may use it in non-obvious ways to implement
> policy.



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From alexb at ripe.net  Mon Feb  6 04:47:23 2012
From: alexb at ripe.net (Alex Band)
Date: Mon, 6 Feb 2012 11:47:23 +0100
Subject: Hijacked Network Ranges
In-Reply-To: <201202061559.32377.mtinka@globaltransit.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061435.39053.mtinka@globaltransit.net>
 <CAL9jLaYfjVd_rHSptnBgaxUhmcLEFvxBnBMRZL7DPmtyL9ureg@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
Message-ID: <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>

With regards to RPKI, I'd like to point out what is possible now, and what the maturity is of the implementations. All RIRs have a system up an running. As John Curran pointed out in an earlier message, ARIN will have a production system up this year, but right now you can already gain experience with their testbed: https://www.arin.net/resources/rpki.html

If you create your ROAs there, there are actually quite some parties who will already validate this information. Of course, basing an actual routing decision on this is a second step; for that we'll need more and better quality data. As it stands there are about 1400 IPv4 and 300 IPv6 announcements that have a ROA associated with them. There are some public test beds up that will give a valid route a higher pref, and an invalid one a lower pref. So create a ROA for your announcements, and then watch it show up on actual RPKI-capable Cisco and Juniper routers:

EuroTransit have made their instance of the RIPE NCC RPKI Validator public, so you can easily verify the validity of your announcement here by searching for it:
http://rpki01.fra2.de.euro-transit.net:8080/bgp-preview

Then you can log in on a public Juniper here:
193.34.50.25, 193.34.50.26
telnet username: rpki
password: testbed

Try commands such as: 
- show validation session detail
- show validation statistics
- show validation database
- show route protocol bgp 204.127.128.0/17
- show route protocol bgp validation-state valid

You can also log into a public Cisco here:
rpki-rtr.ripe.net
telnet username: ripe
no password

Try commands such as:
- sh ip bgp rpki table
- sh ip bgp rpki server
- sh ip bgp 93.175.146.0/24
- sh ip bgp ipv6 unicast rpki table
- sh ip bgp ipv6 unicast 2001:630::/32

Both routers are configured along these lines:
https://www.ripe.net/certification/router-configuration

and talk to the RIPE NCC RPKI Validator service available here:
https://www.ripe.net/certification/tools-and-resources

Try it out, and give feedback!

Cheers,

Alex

P.S. RFCs 6480-6493 have been published. A big thank you goes out to all the people who made that possible.


On 6 Feb 2012, at 08:59, Mark Tinka wrote:

> On Monday, February 06, 2012 03:06:24 PM Christopher Morrow 
> wrote:
> 
>> do you have customers with 10k long prefix lists? it gets
>> hard when the lists get long, or the data is for
>> downstream folks of your customer. Good that someone's
>> checking though, I'd love to see this part automated.
> 
> No, we don't have customers with 10,000-long prefix lists, 
> but we have planned to implement automation (either using 
> the IRR Toolset or home-grown solutions) to make this 
> possible as a means to scaling, should that time arise.
> 
> As it is now, throwing NOC staff at the problem for the 
> volumes we have works well enough. But this is, by no means, 
> a panacea as we scale up.
> 
> Heck, one must even worry whether a some router 
> configurations can take that many lines. But there are other 
> ways around that.
> 
>> RPKI doesn't necessarily mean that the router knows
>> anything about certificates in the short-term. I think
>> there's a time when 'the resource certification system'
>> (which is really, today, the rpki) holds cert/roa data
>> that you could use to filter what the IRR tells you for
>> a customer. You could even do this in any automated
>> manner!
> 
> Well, given validation information will be available within 
> a network, one may use it in non-obvious ways to implement 
> policy.
> 
>> The time between the previous and next paragraphs though
>> is when all isp's will need to beat the drums with their
>> customers saying: "Hey, you REALLY need to get that shit
>> into the 'resource certification system' (rpki), NOW."
>> (because shortly we'll stop accepting your "invalid"
>> routes... and then the interwebs won't be able to find
>> you, and we'll all be sad.)
> 
> Well, we have all seen how doing this with DNSSEC, IPv6 and 
> 4-byte ASN's worked out.
> 
> We need to understand that different operators and different 
> customers will have varying reasons as to why they can't yet 
> "do the right thing". There is abundant evidence of this 
> with other similar initiatives.
> 
> Adoption will have to be incremental. During that time, the 
> Internet must not break.
> 
>> sure... it's not working so well though :(
> 
> Not for lack of having some kind of solution.
> 
> What we have today may not be the best, most scalable 
> option, but it is one nonetheless. Automating it (like what 
> RPSL does) is how you can make it scale to some extent, but 
> it's still the same solution.
> 
> We can't just sit around waiting for RPKI. There will be 
> some reason why some of us can't deploy it, while someone 
> else is thinking up its successor. Rinse, repeat.
> 
> Mark.



From rubensk at gmail.com  Mon Feb  6 05:07:58 2012
From: rubensk at gmail.com (Rubens Kuhl)
Date: Mon, 6 Feb 2012 09:07:58 -0200
Subject: Optimal IPv6 router
In-Reply-To: <107963.1328494077@turing-police.cc.vt.edu>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
Message-ID: <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>

>> With IPv6 growing, if we were to design a native IPv6 router, with
>> IPv4 functionality thrown in, then is it possible to design a more
>> optimal IPv6 router, than what exists today?
>
> OK, I'll bite. ?What would qualify as a "native IPv6" router? ?Is this
> another concept as silly as "hardware vs software based" routers?

Join them and create a router where IPv6 is ASIC-forwarded and IPv4
gets to use a CPU. Market perspectives for such a product are very
shy, but would fit the description.


Rubens


From david at davidswafford.com  Mon Feb  6 05:22:35 2012
From: david at davidswafford.com (David Swafford)
Date: Mon, 6 Feb 2012 06:22:35 -0500
Subject: ISP access in Hebron, KY
In-Reply-To: <20120205202158.GA15605@roxanne.org>
References: <20120205202158.GA15605@roxanne.org>
Message-ID: <CAA8=vb7C7nR1YYcXxQAXfSQFAvRs62xdd24WtiF+o3t8UgfTGA@mail.gmail.com>

Level 3 might be available.  I'm pretty sure TWTC is though -- they're
one of the bigger players in Dayton.

David.


On Sun, Feb 5, 2012 at 3:21 PM, Eric Gauthier <eric at roxanne.org> wrote:
> Hello,
>
> We're looking for DIA in the 20 - 50mbps range for a
> warehouse we have in Hebron, KY. ?CinBell has been a
> bit "slow" to respond to our DS3 requets, so I'm
> wondering who else in town has their own facilities
> (also wondering who might be a good for a backup
> circuit)?
>
> Thanks!
>
> Eric :)
>


From mtinka at globaltransit.net  Mon Feb  6 06:03:46 2012
From: mtinka at globaltransit.net (Mark Tinka)
Date: Mon, 6 Feb 2012 20:03:46 +0800
Subject: Hijacked Network Ranges
In-Reply-To: <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>
References: <CANEysbE7GiFM++ykwiO0nBmfPvWHw_KSPUFDPfNbM5Y2TL1kMw@mail.gmail.com>
 <201202061559.32377.mtinka@globaltransit.net>
 <89460018-6616-4EB9-B2B7-0518F7FF0DAF@ripe.net>
Message-ID: <201202062003.46979.mtinka@globaltransit.net>

On Monday, February 06, 2012 06:47:23 PM Alex Band wrote:

> With regards to RPKI, I'd like to point out what is
> possible now, and what the maturity is of the
> implementations. All RIRs have a system up an running.
> As John Curran pointed out in an earlier message, ARIN
> will have a production system up this year, but right
> now you can already gain experience with their testbed:
> https://www.arin.net/resources/rpki.html

This is great, Alex! Thanks.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/faaaa89c/attachment.bin>

From dennis at justipit.com  Mon Feb  6 06:22:38 2012
From: dennis at justipit.com (dennis)
Date: Mon, 6 Feb 2012 07:22:38 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
Message-ID: <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>

The point is well taken that cloud scrubbing can be an essential component 
of mitigating a volumetric flood.  However, it is important to note that 
DDOS attacks do not only consist of volumetric floods.  Current attacks 
often incorporate a multi-vectored attack campaign including a combination 
of low and slow and application layer attacks on upper layer protocols, ie. 
DNS & HTTP(s).  These campaigns are designed to fly under the triggers of 
other flow based analysis (cloud scrubbing) protections in place today.   As 
with any security protection a layered approach is required in order to 
protect the  perimeter from DDOS.  In addition to the previous 
recommendations of ACL, uRPF, RTBH, CoPP, inspection of the full stack is 
required.    The best protection today includes a detector capable of 
inspecting the full stack and signaling back to the cloud scrubbing station 
to swing the route if the attack becomes volumetric.   The premise device 
should have technique in order to challenge the source and counter the 
attack with intelligence.    I'm aware of two vendors offering some of these 
capabilities today, Radware and Arbor.



--------------------------------------------------
From: "Keegan Holley" <keegan.holley at sungard.com>
Sent: Sunday, February 05, 2012 8:37 PM
To: "Dobbins, Roland" <rdobbins at arbor.net>
Cc: "NANOG Group" <nanog at nanog.org>
Subject: Re: UDP port 80 DDoS attack

> 2012/2/5 Dobbins, Roland <rdobbins at arbor.net>
>
>>
>> On Feb 6, 2012, at 8:10 AM, Keegan Holley wrote:
>>
>> > An entire power point just to recommend ACL's, uRPF, CPP, DHCP 
>> > snooping,
>> and RTBH?
>>
>> Actually, no, that isn't the focus of the preso.
>>
>> > The first four will not work against a DDOS attack
>>
>> This is incorrect - suggest you read the preso.
>>
>
> The ACL's are configured on the routers belonging to the victim AS which
> will not save their access pipe if it's overrun unless I'm missing
> something.  uRPF may help with spoofed traffic, but sometimes causes
> problems with multi-homing and is often more harmful than helpful 
> depending
> on the network design.
>
>>
>> > and the last one just kills the patient so he does not infect other
>> patients.
>>
>> S/RTBH - as opposed to D/RTBH - doesn't kill the patient.  Again, suggest
>> you read the preso.
>>
>
> Source RTBH often falls victim to rapidly changing or spoofed source IP"s.
> It also isn't as widely supported as it should be. I never said DDOS was
> hopeless, there just aren't a wealth of defenses against it.
> 


From leigh.porter at ukbroadband.com  Mon Feb  6 07:39:10 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 6 Feb 2012 13:39:10 +0000
Subject: Optimal IPv6 router
In-Reply-To: <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <CAGFn2k2XhhHpWT4mav12PA3g7U8ut6VHPQh3BUnxyse9OAmYpQ@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786449B070@EALPO1.ukbroadband.com>

> >> With IPv6 growing, if we were to design a native IPv6 router, with
> >> IPv4 functionality thrown in, then is it possible to design a more
> >> optimal IPv6 router, than what exists today?
> >
> > OK, I'll bite. ?What would qualify as a "native IPv6" router? ?Is
> this
> > another concept as silly as "hardware vs software based" routers?
> 
> Join them and create a router where IPv6 is ASIC-forwarded and IPv4
> gets to use a CPU. Market perspectives for such a product are very
> shy, but would fit the description.

And where half the useful features just don't support IPv6.

Make it support draft-ietf-mpls-ldp-ipv6 and we're away :)

--
Leigh Porter


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


From bicknell at ufp.org  Mon Feb  6 08:18:46 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 6 Feb 2012 06:18:46 -0800
Subject: Optimal IPv6 router
In-Reply-To: <20120206073426.GB8779@srv03.cluenet.de>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
Message-ID: <20120206141846.GB52936@ussenterprise.ufp.org>

In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
> on XR]).

IOS-XR is fully AFI-agnostic, as far as I can tell.  It also updated
the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar
syntax.  I think also that all of the platforms on which IOS-XR
runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in
hardware, with features.

While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has
one very cool feature.  You can pass parameters in route policy.  Many
networks maintain slightly different versions of policies like
"peer-in/peer-out" due to various load balancing or preference needs,
with a 5-15 stanza policy repeated over and over.  When you have to
update one of the stanzas in all policies it becomes a big mess.
In IOS-XR, you can write a generic policy and then call with with
parameters:

route-policy generic-out($routeCommunity)
  ... ! Do all the common things
  if community matches-any $routeCommunity then
    accept
  endif
  drop
end-policy

community-set send-to-private-peers
  1234:5678
end-set

route-policy private-peer-out
  apply generic-out(send-to-private-peers)
end-policy

community-set send-to-public-peers
  1234:4321
end-set

route-policy public-peer-out
  apply generic-out(send-to-public-peers)
end-policy

With a little bit of careful thought you can really collapse down the
policy to be much shorter, easier to understand, and have almost no
cut-and-paste in it, which should reduce errors when updating in the
future.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120206/935a7f4d/attachment.bin>

From glen.kent at gmail.com  Mon Feb  6 08:48:29 2012
From: glen.kent at gmail.com (Glen Kent)
Date: Mon, 6 Feb 2012 20:18:29 +0530
Subject: Optimal IPv6 router
In-Reply-To: <20120206073426.GB8779@srv03.cluenet.de>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
Message-ID: <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>

On Mon, Feb 6, 2012 at 1:04 PM, Daniel Roesen <dr at cluenet.de> wrote:
> On Sun, Feb 05, 2012 at 09:07:57PM -0500, Valdis.Kletnieks at vt.edu wrote:
>> OK, I'll bite. ?What would qualify as a "native IPv6" router?
>
> Perhaps those which were designed with IPv4+IPv6 in mind from day 1,
> both in hardware and software - like Juniper/JUNOS. In contrast to other

Not just that.

I had meant that the HW is optimized for IPv6 and also as a side
effect does IPv4. This router could be designed assuming that you'll
have more IPv6 traffic to forward than IPv4.

> the gear where IPv6 was always an aftermath, which shows in both
> hardware (limits of performance, functionality and scaling) as well as
> software (every feature gets implemented twice, even if the feature
> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
> on XR]).

Yes, thats what i had in mind.

One example that comes to my mind is that a few existing routers cant
do line rate routing for IPv6 traffic as long as the netmask is < 65.
Also routers have a limited TCAM size for storing routes with masks >
64. These routers were primarily designed for IPv4 and also support
IPv6.

I was wondering what we could optimize on if we only design an IPv6
router (assume an extreme case where it does not even support IPv4).

Glen
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
>


From joelja at bogus.com  Mon Feb  6 09:35:39 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 06 Feb 2012 07:35:39 -0800
Subject: Optimal IPv6 router
In-Reply-To: <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <CAPLq3UMwZE-_jUeeR-EH4+mmmfTfaM_GRJHV9naUa5psa1i4HA@mail.gmail.com>
Message-ID: <4F2FF34B.6060109@bogus.com>

On 2/6/12 06:48 , Glen Kent wrote:

> One example that comes to my mind is that a few existing routers
> cant do line rate routing for IPv6 traffic as long as the netmask is
> < 65.

I'm sorry that's  bs. It's trivial to partition a cam in order to do
/128s in a single lookup. that's actually the worst case scenario, a
more efficient packing will result in lower power consumption and memory
use. potentially that results in multiple lookups which in no way
implies you're not going to meet your pps target.

> Also routers have a limited TCAM size for storing routes with masks
> > 64. These routers were primarily designed for IPv4 and also
> support IPv6.

All routers don't use tcams for fib lookups. M T MX devices do not use
cams for fib for example.

limited cam partitioning schemes exist in ip4 as well,
big cams have a cost power wise, and bom wise, parititioning them in a
way that meets the developers view of the distribution of route lengths
can be beneficial and be used to build products suitable for lots of
roles but probably not being a internet core router. standard juniper
ex8200 line cards for example are just peachy for a datacenter but not
so much for a internet core device and the bom feature set and price
reflect that.

> I was wondering what we could optimize on if we only design an IPv6 
> router (assume an extreme case where it does not even support IPv4).

right now if I take a platform that uses a  large CAM like a force 10
e1200i ej line card, I can adjust the cam allocation to do basically
nothing but ipv6, given the default balance between ipv4 and ipv6 doing
so more that doubles the number of ipv6 routes I can expect to hold.

> Glen
>> 
>> Best regards, Daniel
>> 
>> -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP:
>> 0xA85C8AA0
>> 
> 
> 



From surfer at mauigateway.com  Mon Feb  6 14:11:52 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 6 Feb 2012 12:11:52 -0800
Subject: Hijacked Network Ranges
Message-ID: <20120206121152.D490B6EE@resin11.mta.everyone.net>

--- mtinka at globaltransit.net wrote:
From: Mark Tinka <mtinka at globaltransit.net>

A big fail to our community, for up to this day, not 
implementing basic routing and forwarding filters that would 
do away with all this cruft in the first place.

Clearly the Youtube/Pakistan/PCCW incident has long been 
forgotten.
-----------------------------------


I know of folks in charge of BGP enabled networks (with downstream BGP 
customers as well) that have never heard of the Youtube/Pakistan/PCCW 
incident and don't care if they put extra routes in the table and I 
doubt that is an isolated situation.  Further, I doubt it will change 
unless they're forced to care by technology somehow.  An unfortunate 
situation for sure...

scott


From mpetach at netflight.com  Mon Feb  6 14:51:55 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 6 Feb 2012 12:51:55 -0800
Subject: 2012.02.06 NANOG54 monday morning session notes are up
Message-ID: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>

I posted my notes from this morning's session at

http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt

in case people find them to be useful.

Thanks!

Matt


From annkwok80 at gmail.com  Mon Feb  6 15:41:03 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Mon, 6 Feb 2012 16:41:03 -0500
Subject: Switch and router
Message-ID: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>

Hello

There is big congestion between router and switch

I read some documents about flowcontral

Do I disable or adjust flowcontral at the same?

Can flowcontral solve the congestion issue?

How can I adjust flowcontral in cisco router and HP switch?

Thank you so much

From fdelmotte1 at mac.com  Mon Feb  6 15:56:08 2012
From: fdelmotte1 at mac.com (Fabien Delmotte)
Date: Mon, 06 Feb 2012 22:56:08 +0100
Subject: Switch and router
In-Reply-To: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
Message-ID: <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>

Hi
Forget flow control, because you will use buffer and at the someone will not understant pause frame.
Another issue is : with pause frame you block all the traffic from the outbound port ... So very dangerous.
Best way : big pipe.

Regards

Fabien

Envoy? de mon iPad

Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :

> Hello
> 
> There is big congestion between router and switch
> 
> I read some documents about flowcontral
> 
> Do I disable or adjust flowcontral at the same?
> 
> Can flowcontral solve the congestion issue?
> 
> How can I adjust flowcontral in cisco router and HP switch?
> 
> Thank you so much


From regnauld at nsrc.org  Mon Feb  6 16:09:08 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Mon, 6 Feb 2012 23:09:08 +0100
Subject: 2012.02.06 NANOG54 monday morning session notes are up
In-Reply-To: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>
References: <CAEmG1=q6Rcmg21MnEeRpLOzdThPCTdDCuzho2W_tdA-5XM3ijQ@mail.gmail.com>
Message-ID: <20120206220908.GF5356@macbook.bluepipe.net>

Matthew Petach (mpetach) writes:
> I posted my notes from this morning's session at
> 
> http://kestrel3.netflight.com/2012.02.06-nanog54-morning-session.txt
> 
> in case people find them to be useful.

	For those of us not attenting, this is invaluable. Thanks a lot
	for this work, Matt.

	Cheers,
	Phil


From sven at cb3rob.net  Mon Feb  6 19:43:00 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Tue, 7 Feb 2012 01:43:00 +0000 (UTC)
Subject: UDP port 80 DDoS attack
In-Reply-To: <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
Message-ID: <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>

>> It also isn't as widely supported as it should be. I never said DDOS was
>> hopeless, there just aren't a wealth of defenses against it.

there is a fix for it, it's called "putting a fuckton of ram in -most- 
routers on the internet" and keeping statistics for each destination 
ip:destination port:outgoing interface so that none of them individually 
can (entirely/procentually compared to other traffic) flood the outgoing 
interface on that router... end result, if enough routers are structured
like that, is that ddos attacks will be come completely useless.

keyword here, is terabytes of ram.

statistic tables on very basic ipv4 stuff alone would already take 
multiple 100's of gigabytes...

(keep in mind, this won't be "cpu work", its just using the table entry 
size * dest ip as an offset and reading it out ;)

the good news is, ram doesn't cost a flying fuck anymore...

it just requires a complete re-think of router design, but then again, 
with the prices that cisco and juniper charge we expect a bit more than a 
1960's telephone exchange look and feel device, or we might as well use 1 
linux box/blade per 20gbit/s throughput and consider that whole thing a 
"hotpluggable interface". cisco and juniper, at the moment, sell faster 
versions of their crap from the 1990s, but not much effort went into 
completely re-designing the stuff to be suitable for the internet as it is 
today, they still forward all packets they can get their hands on, and 
besides rather simple stuff like QoS, not much effort went into 
inteligently spreading the capacity available on the outgoing interface 
(at least for that individual router) over all the possible targets.

now, if an outgoing interface is 10ge, and 10mbit traffic should go to 
1.2.3.4 and 20ge (ddos) traffic should go to 4.3.2.1, i'd say, a router 
should give 1.2.3.4 the full 10ge, as it is available, and lower volume 
should basically just get a higher priority.

we have not quite worked out the formula yet... but it should be something 
along those lines (simply to say, any destination ip can never fill more 
than half of the outgoing interface, doesn't quite cover it, it needs some 
"intelligent adjustment of the percentage")..

basically...
table:

destip
destport
packetcounter

every so and so many packets/timeslices,whatever that packetcounter is 
decreased by 1

every packet, the packet counter is incremented

after inactivity for that ip for timeperiod x, the packet counter is 
cleared.

with ipv4, this "destip" entry is such a small (32 bit) integer that its 
better to just not store the ip itself but rather just throw more ram at 
it and use the ip address number as the offset in the array

(for faster lookups, preferably in hardware logic).


the same thing could be applied to pretty much every other concept still 
done with slow lookups nowadays (arp, routes, etc)... throw more ram at it 
and use the destination as the offset, who cares if 99.9% of the ram is 
not actually used. for the price of a juniper, you can buy a truck full of 
ram chips ;).. it's faster that way, and it allows us to do a lot of 
things, like not passing potential ddos floods in the first place, and 
intelligently allowing everyone, not an equal share of the traffic 
capacity, but the part they need.

if you don't mind wasting 50% of the available capacity the formula to 
determine wether to forward a packet or not is 
quite simple, if you also want to give a destip 100% of the traffic in 
situations where there is no other traffic, it becomes a bit more 
complicated..

as stated before, we haven't quite worked it out in full yet, but in any 
case... this would require for at least 30% of the routers that currently 
are on the internet and are 110 kg heavy "1960s telephone exchange models" 
to be replaced with 2012 style hardware, not "just faster cisco 7200 like 
things".


From robertg at garlic.com  Mon Feb  6 20:01:57 2012
From: robertg at garlic.com (Robert Glover)
Date: Mon, 06 Feb 2012 18:01:57 -0800
Subject: Any Covad / MegaPath folks around?
Message-ID: <4F308615.1030707@garlic.com>

Hi,

Looks like the Connect portal has been down for hours.  Can someone from 
Covad / MegaPath ping me off-list?

Thanks!

Sincerely,
Bobby Glover
Director of Information Services
South Valley Internet


From mpetach at netflight.com  Mon Feb  6 20:04:20 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 6 Feb 2012 18:04:20 -0800
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
Message-ID: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>

My notes from the second half of today's NANOG 54
talks are now up at

http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt

for those catching up remotely before the videos
get posted up.

Off to the Beer and Gear now.  ^_^

Thanks!

Matt


From jsw at inconcepts.biz  Mon Feb  6 22:12:26 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Mon, 6 Feb 2012 23:12:26 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
 <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
Message-ID: <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>

On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis <sven at cb3rob.net> wrote:
> there is a fix for it, it's called "putting a fuckton of ram in -most-
> routers on the internet" and keeping statistics for each destination
> ip:destination port:outgoing interface so that none of them individually can
> (entirely/procentually compared to other traffic) flood the outgoing
> interface on that router... end result, if enough routers are structured
> like that, is that ddos attacks will be come completely useless.

There are two obvious problems with your approach.

First, adding the policers you suggest, at the scale needed, is a
little harder than you imagine.  It's not a simple matter of the cost
of RAM but also power/heat density per port.

Second, if you re-engineer every router on the Internet to prevent an
interface from being congested by malicious flow(s) destined for one
particular destination IP:port, then DDoS attacks will simply target
multiple ports or multiple destination IP addresses that are likely to
traverse a link they are able to congest.

If you want to dramatically increase the cost of routers in order to
solve the problem of DDoS with one deft (and expensive) move, you have
to imagine that the people behind DDoS attacks aren't complete idiots,
and will actually spend some time thinking about how to defeat your
system.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From packetjockey at gmail.com  Mon Feb  6 22:23:20 2012
From: packetjockey at gmail.com (Rafael Rodriguez)
Date: Mon, 6 Feb 2012 20:23:20 -0800
Subject: Optimal IPv6 router
In-Reply-To: <20120206141846.GB52936@ussenterprise.ufp.org>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <20120206141846.GB52936@ussenterprise.ufp.org>
Message-ID: <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>

You can do the same with Junos (calling a 'generic' policy as a sub-routine).

Sent from my iPhone

On Feb 6, 2012, at 6:18, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Mon, Feb 06, 2012 at 08:34:26AM +0100, Daniel Roesen wrote:
>> itself is completely AFI-agnostic - see e.g. IOS/IOS-XE [can't comment
>> on XR]).
> 
> IOS-XR is fully AFI-agnostic, as far as I can tell.  It also updated
> the CLI to be consistently "ipv4 ..." or "ipv6 ..." with similar
> syntax.  I think also that all of the platforms on which IOS-XR
> runs (GSR, CRS-1/3, ASR9000) can all run full line rate IPv6 in
> hardware, with features.
> 
> While much of the IOS-XR vrs JunOS is personal preference, IOS-XR has
> one very cool feature.  You can pass parameters in route policy.  Many
> networks maintain slightly different versions of policies like
> "peer-in/peer-out" due to various load balancing or preference needs,
> with a 5-15 stanza policy repeated over and over.  When you have to
> update one of the stanzas in all policies it becomes a big mess.
> In IOS-XR, you can write a generic policy and then call with with
> parameters:
> 
> route-policy generic-out($routeCommunity)
>  ... ! Do all the common things
>  if community matches-any $routeCommunity then
>    accept
>  endif
>  drop
> end-policy
> 
> community-set send-to-private-peers
>  1234:5678
> end-set
> 
> route-policy private-peer-out
>  apply generic-out(send-to-private-peers)
> end-policy
> 
> community-set send-to-public-peers
>  1234:4321
> end-set
> 
> route-policy public-peer-out
>  apply generic-out(send-to-public-peers)
> end-policy
> 
> With a little bit of careful thought you can really collapse down the
> policy to be much shorter, easier to understand, and have almost no
> cut-and-paste in it, which should reduce errors when updating in the
> future.
> 
> -- 
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/


From keegan.holley at sungard.com  Mon Feb  6 22:58:42 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Mon, 6 Feb 2012 23:58:42 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <73D3547A154D4F9AB0C61976A60C207B@usa.corp.radware.com>
 <Pine.LNX.4.64.1202070126150.14602@a84-22-97-10.cb3rob.net>
 <CAPWAtb+3yQjUmmJvfqOGqa2VY7j2WaSCmidcrvtfsHGY=HZQfg@mail.gmail.com>
Message-ID: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>

2012/2/6 Jeff Wheeler <jsw at inconcepts.biz>

> On Mon, Feb 6, 2012 at 8:43 PM, Sven Olaf Kamphuis <sven at cb3rob.net>
> wrote:
> > there is a fix for it, it's called "putting a fuckton of ram in -most-
> > routers on the internet" and keeping statistics for each destination
> > ip:destination port:outgoing interface so that none of them individually
> can
> > (entirely/procentually compared to other traffic) flood the outgoing
> > interface on that router... end result, if enough routers are structured
> > like that, is that ddos attacks will be come completely useless.
>
> There are two obvious problems with your approach.
>
> First, adding the policers you suggest, at the scale needed, is a
> little harder than you imagine.  It's not a simple matter of the cost
> of RAM but also power/heat density per port.
>

Since when are policers implemented in ram?  You're talking FPGA if you
want to be able to make forwarding/filtering decisions assuming it's
possible which it isn't you're 1 million dollar boxes suddenly become
hundred million dollar boxes.  Then there's v6 info..

>
> Second, if you re-engineer every router on the Internet to prevent an
> interface from being congested by malicious flow(s) destined for one
> particular destination IP:port, then DDoS attacks will simply target
> multiple ports or multiple destination IP addresses that are likely to
> traverse a link they are able to congest.
>


Not to mention that the routers themselves become an attack vector.  This
cache will have a finite limit because there's no such thing as an infinite
amount of cache among other flaws.  When that limit is reached it will do
something no one want's it to do and that will become the new DDOS attack.

>
> If you want to dramatically increase the cost of routers in order to
> solve the problem of DDoS with one deft (and expensive) move, you have
> to imagine that the people behind DDoS attacks aren't complete idiots,
> and will actually spend some time thinking about how to defeat your
> system.
>
> Not to mention cost?  You're not going to get a tier I ISP to upgrade to
this new super router (assuming it's possible to build such a things)
without an act of congress or at least the FCC.  They won't even spend
enough on fiber to bring broadband into rural areas.

From dr at cluenet.de  Tue Feb  7 00:32:07 2012
From: dr at cluenet.de (Daniel Roesen)
Date: Tue, 7 Feb 2012 07:32:07 +0100
Subject: Optimal IPv6 router
In-Reply-To: <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>
References: <CAPLq3UPr7C9sfdCmqgnALRFuviwujh+F3hir_X1yg8aWasO3tA@mail.gmail.com>
 <107963.1328494077@turing-police.cc.vt.edu>
 <20120206073426.GB8779@srv03.cluenet.de>
 <20120206141846.GB52936@ussenterprise.ufp.org>
 <28549ED9-622F-4F58-B2ED-5E09DBD8748B@gmail.com>
Message-ID: <20120207063207.GA23688@srv03.cluenet.de>

On Mon, Feb 06, 2012 at 08:23:20PM -0800, Rafael Rodriguez wrote:
> You can do the same with Junos (calling a 'generic' policy as a
> sub-routine).

You cannot pass parameters.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0


From peterehiwe at gmail.com  Tue Feb  7 00:37:06 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Tue, 7 Feb 2012 07:37:06 +0100
Subject: DOS ATTACK ON BGP , LPTS ??
Message-ID: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>

Hi ,
What is the best way to mitigate DOS attack against the bgp process of a
router , is LPTS on IOS-XR enough ?
Rgds
Peter

From rdobbins at arbor.net  Tue Feb  7 00:40:27 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Tue, 7 Feb 2012 06:40:27 +0000
Subject: DOS ATTACK ON BGP , LPTS ??
In-Reply-To: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
References: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
Message-ID: <EEF5841A-5CDB-4F19-8FFF-F9217C8C16B1@arbor.net>


On Feb 7, 2012, at 1:37 PM, Peter Ehiwe wrote:

> What is the best way to mitigate DOS attack against the bgp process of a router , 

iACLs and CoPP:

<https://files.me.com/roland.dobbins/prguob

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From peterehiwe at gmail.com  Tue Feb  7 00:52:20 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Tue, 7 Feb 2012 07:52:20 +0100
Subject: DOS ATTACK ON BGP , LPTS ??
In-Reply-To: <D2155AE4-2A2A-46F4-A0AC-C2007B8DAAB2@arbor.net>
References: <CADECfTUJZpgxECBh=6MGZjCejn83gW8rOpO3_t7hJCcJ+EcbFQ@mail.gmail.com>
 <EEF5841A-5CDB-4F19-8FFF-F9217C8C16B1@arbor.net>
 <CADECfTUYsj+kz4xmWSjs2c7XPmK9mzH_tkBTNNWwTht0wdbQvw@mail.gmail.com>
 <D2155AE4-2A2A-46F4-A0AC-C2007B8DAAB2@arbor.net>
Message-ID: <CADECfTUaifA3TXUZkonwPwc62r01VJtR8TH_OJKXstACMniuYw@mail.gmail.com>

Thanks Roland,
Does anyone have a recommended value for tuning LPTS based on experience ?
Rgds
Peter

On Tue, Feb 7, 2012 at 7:45 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Feb 7, 2012, at 1:43 PM, Peter Ehiwe wrote:
>
> > What is the attacker spoofs the correct peering address ,
>
> In that case, work with your peer(s) to get them to deploy anti-spoofing
> filters at their edges.
>
> > then iACL may not suffice , from experience is the default policer
> values for LPTS enough for XR routers
>
> Hard to say - look at CoPP/LPTS tuning.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
>                The basis of optimism is sheer terror.
>
>                          -- Oscar Wilde
>
>


-- 
Warm Regards

Peter(CCIE 23782).

From me at anuragbhatia.com  Tue Feb  7 02:46:19 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Tue, 7 Feb 2012 14:16:19 +0530
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
In-Reply-To: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
References: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
Message-ID: <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>

Thanks for sharing notes Matt.

Does anyone has archived video links of event? I enjoyed watching a couple
of sessions on live stream but due to low bandwidth it was pain to see in
pause-play-pause-play manner. Link to video archive will be very useful.


Thanks.

On Tue, Feb 7, 2012 at 7:34 AM, Matthew Petach <mpetach at netflight.com>wrote:

> My notes from the second half of today's NANOG 54
> talks are now up at
>
> http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt
>
> for those catching up remotely before the videos
> get posted up.
>
> Off to the Beer and Gear now.  ^_^
>
> Thanks!
>
> Matt
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From mpetach at netflight.com  Tue Feb  7 03:42:48 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 7 Feb 2012 01:42:48 -0800
Subject: 2012.02.06 NANOG54 day1 afternoon session notes
In-Reply-To: <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>
References: <CAEmG1=rFts8PvX4m1djoWewbrpk0fpVRX_VOEi=2Pa4JrJko-A@mail.gmail.com>
 <CAJ0+aXYDL82vN9wZ9qpEDiw2wo7_=ga+1NxV0iuZw7z67sZU6A@mail.gmail.com>
Message-ID: <CAEmG1=r-rf5m+Zx4jVKENHdzZhTbnxFX7hrwxnKFB-5tvGsFyQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 12:46 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:
> Thanks for sharing notes Matt.
>
> Does anyone has archived video links of event? I enjoyed watching a couple
> of sessions on live stream but due to low bandwidth it was pain to see in
> pause-play-pause-play manner. Link to video archive will be very useful.

The archived video streams will generally be posted on the website
within a month or so;  it just requires a wee bit of patience.  ^_^

Thanks!

Matt

> Thanks.
>
> On Tue, Feb 7, 2012 at 7:34 AM, Matthew Petach <mpetach at netflight.com>
> wrote:
>>
>> My notes from the second half of today's NANOG 54
>> talks are now up at
>>
>> http://kestrel3.netflight.com/2012.02.06-nanog54-afternoon-session.txt
>>
>> for those catching up remotely before the videos
>> get posted up.
>>
>> Off to the Beer and Gear now. ?^_^
>>
>> Thanks!
>>
>> Matt
>>
>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia
> Linkedin: http://linkedin.anuragbhatia.com
>


From annkwok80 at gmail.com  Tue Feb  7 07:32:21 2012
From: annkwok80 at gmail.com (Ann Kwok)
Date: Tue, 7 Feb 2012 08:32:21 -0500
Subject: Switch and router
In-Reply-To: <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
Message-ID: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>

Hello

Thank you for your help

But we can't increase the pipe as we are using 10G switch.

The congestion happens when the traffic is using 7G

Any idea?

In addition, how to determine the congestion happens in router or switch.

Thank you

On Mon, Feb 6, 2012 at 4:56 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:

> Hi
> Forget flow control, because you will use buffer and at the someone will
> not understant pause frame.
> Another issue is : with pause frame you block all the traffic from the
> outbound port ... So very dangerous.
> Best way : big pipe.
>
> Regards
>
> Fabien
>
> Envoy? de mon iPad
>
> Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :
>
> > Hello
> >
> > There is big congestion between router and switch
> >
> > I read some documents about flowcontral
> >
> > Do I disable or adjust flowcontral at the same?
> >
> > Can flowcontral solve the congestion issue?
> >
> > How can I adjust flowcontral in cisco router and HP switch?
> >
> > Thank you so much
>

From streiner at cluebyfour.org  Tue Feb  7 08:04:35 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 7 Feb 2012 09:04:35 -0500 (EST)
Subject: Switch and router
In-Reply-To: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202070853100.24619@whammy.cluebyfour.org>

On Tue, 7 Feb 2012, Ann Kwok wrote:

> Thank you for your help
>
> But we can't increase the pipe as we are using 10G switch.
>
> The congestion happens when the traffic is using 7G
>
> Any idea?
>
> In addition, how to determine the congestion happens in router or switch.

Different manufacturers and platforms have different ways of indicating 
the presence of congestion.  Some will not explicitly report it, so you 
end up having to go back and look at performance statistics on your devices
(per-interface traffic, overall traffic and/or traffic per ASIC group, 
CPU/memory/buffer utilization, link errors, overruns, etc).

Whichever manufacturers you use will likely have lots of resources 
available through their websites/support channels for troubleshooting 
congestion.

I'm going to go out on a limb here and take a guess that Ann = Deric, 
using a different address?

jms

> On Mon, Feb 6, 2012 at 4:56 PM, Fabien Delmotte <fdelmotte1 at mac.com> wrote:
>
>> Hi
>> Forget flow control, because you will use buffer and at the someone will
>> not understant pause frame.
>> Another issue is : with pause frame you block all the traffic from the
>> outbound port ... So very dangerous.
>> Best way : big pipe.
>>
>> Regards
>>
>> Fabien
>>
>> Envoy? de mon iPad
>>
>> Le 6 f?vr. 2012 ? 22:41, Ann Kwok <annkwok80 at gmail.com> a ?crit :
>>
>>> Hello
>>>
>>> There is big congestion between router and switch
>>>
>>> I read some documents about flowcontral
>>>
>>> Do I disable or adjust flowcontral at the same?
>>>
>>> Can flowcontral solve the congestion issue?
>>>
>>> How can I adjust flowcontral in cisco router and HP switch?
>>>
>>> Thank you so much
>>
>

From jgreco at ns.sol.net  Tue Feb  7 08:28:25 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Tue, 7 Feb 2012 08:28:25 -0600 (CST)
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>
Message-ID: <201202071428.q17ESPLA083237@aurora.sol.net>

> Since when are policers implemented in ram?  You're talking FPGA if you
> want to be able to make forwarding/filtering decisions assuming it's
> possible which it isn't you're 1 million dollar boxes suddenly become
> hundred million dollar boxes.  Then there's v6 info..

Of course it's not possible ... if you use a crummy design.  It's trivial
to come up with non-completely-crummy designs.  For example, adding a
front-end where you take a hash of source-ip/dest-ip and run it through
a smallish hash table, you can use that as a filter to eliminate a lot
of traffic that's just normal and non-interesting.  You want to take a
closer look at the traffic that's heaviest (read: most hits) or new and
significant (read: diff against an hour ago).  You probably don't want
to do this just per-IP, but likely also per-network.  And you probably
don't want to use just this one technique, you want to combine it with
others.  And you probably need to consider the types of attacks that
are known, likely, etc., and design accordingly, because this one little
example I've provided is just one part of a comprehensive solution, but
it is capable of dealing with any amount of traffic and it would be a
very useful filter to start pulling out potentially interesting stuff.

This stuff isn't *easy*.  Fine.  But it certainly *is* possible.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From rsm at fast-serv.com  Tue Feb  7 10:55:03 2012
From: rsm at fast-serv.com (Randy McAnally)
Date: Tue, 7 Feb 2012 11:55:03 -0500
Subject: Switch and router
In-Reply-To: <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
Message-ID: <20120207165202.M37729@fast-serv.com>

On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
> Hello
> 
> Thank you for your help
> 
> But we can't increase the pipe as we are using 10G switch.
> 
> The congestion happens when the traffic is using 7G

If you cannot increase bandwidth, then you must increase the TX queue (in QOS
and/or port buffer).

~Randy



From gbonser at seven.com  Tue Feb  7 12:05:03 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 18:05:03 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <201202071428.q17ESPLA083237@aurora.sol.net>
References: <CABO8Q6QQQz5tYwq9MgwaL0SkDPjRA4gMd_=kVoFYgakVsiB5ZA@mail.gmail.com>
 <201202071428.q17ESPLA083237@aurora.sol.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBA094@RWC-MBX1.corp.seven.com>

> Of course it's not possible ... if you use a crummy design.  It's
> trivial to come up with non-completely-crummy designs.  For example,
> adding a front-end where you take a hash of source-ip/dest-ip and run
> it through a smallish hash table, you can use that as a filter to
> eliminate a lot of traffic that's just normal and non-interesting.  You
> want to take a closer look at the traffic that's heaviest (read: most
> hits) or new and significant (read: diff against an hour ago).  You
> probably don't want to do this just per-IP, but likely also per-
> network. 

I think one of the problems is that with modern bot-nets, traffic can be generated by a huge number of hosts and assuming your DoS traffic is coming from a source that can be blocked might be an unreasonable expectation.  You can't assume that you are going to get a flood of traffic from some source that you can pin down and block.  You might get flood of traffic from tens of thousands of source IPs from all over the world with each one sending only a very small amount AND the source IPs constantly changing.  They might even be sending traffic that looks perfectly legitimate on the surface and might need to be profiled/fingerprinted in some manner at layer 4.  It isn't as easy as just handling it at the router.  And there is no guarantee the source IP of the traffic is really where it is coming from since there are still a good number of providers out there who don't install packet filters on their customer links.  They accept any traffic their customer sends them even if the source IP isn't within the customer's network range.  So that is part of the game, too.  If you have 10,000 hosts sending packets with spoofed IP addresses where the goal is to get you to block the apparent source network, as soon as you block those source addresses, the DoS has succeeded.


> And you probably don't want to use just this one technique,
> you want to combine it with others.  

I think "probably" is the wrong word here.  The word "certainly" leaps to mind.

> And you probably need to consider
> the types of attacks that are known, likely, etc., and design
> accordingly, because this one little example I've provided is just one
> part of a comprehensive solution, but it is capable of dealing with any
> amount of traffic and it would be a very useful filter to start pulling
> out potentially interesting stuff.

The problem is that you have a game of cat and mouse with what amounts to an infinite supply of mice.  It takes cooperation between the source and the provider networks.  The "eyeball" heavy networks need to ensure they can't source bogus traffic.  Having gear these days where the ACLs are in hardware has greatly reduced the CPU expense of filtering on edge ports but the human resource expense of maintaining those is still high unless automation is brought into the mix so that those filters are changed when the addresses served by a port change.

> This stuff isn't *easy*.  Fine.  But it certainly *is* possible.

Of course it isn't easy.  It is designed to be difficult.  But there is plenty of "low hanging fruit" out there still.



From gbonser at seven.com  Tue Feb  7 12:06:28 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 18:06:28 +0000
Subject: Switch and router
In-Reply-To: <20120207165202.M37729@fast-serv.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
 <20120207165202.M37729@fast-serv.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBA0AB@RWC-MBX1.corp.seven.com>

> 
> On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
> > Hello
> >
> > Thank you for your help
> >
> > But we can't increase the pipe as we are using 10G switch.
> >
> > The congestion happens when the traffic is using 7G
> 
> If you cannot increase bandwidth, then you must increase the TX queue
> (in QOS and/or port buffer).
> 
> ~Randy
> 

Or the congestion could be further upstream or the flows might be high latency TCP and are being throttled because of the network latency. There could be any number of issues.



From sven at cb3rob.net  Tue Feb  7 12:04:52 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Tue, 7 Feb 2012 18:04:52 +0000 (UTC)
Subject: Switch and router
In-Reply-To: <20120207165202.M37729@fast-serv.com>
References: <CACwqZxgHFNCiioO+3wi_q_NDvTHLBtDVXEFJqHYGpPJXoe574A@mail.gmail.com>
 <D1AC84E0-29C1-4BC2-A732-A023B76D9476@mac.com>
 <CACwqZxgiOCP0g-jOoFHTqkaDSRXD-ygnvkOsrqwUEFf1XWP5dQ@mail.gmail.com>
 <20120207165202.M37729@fast-serv.com>
Message-ID: <Pine.LNX.4.64.1202071800490.7180@a84-22-97-10.cb3rob.net>

"increase pipe" = port trunking/etherchannel/port bonding whatever your 
supplier calls it. just use 2 or 4 ports instead of just one.

ieee 802.3ad/lacp/link aggregation, etc.... all the same stuff. ;)

provided you have another interface on/for your router ofcourse (your 
switch probably has plenty ;)

also an option (for cisco)...

int gix/x/x
max-reserved-bandwidth 1

(i'd say, 1% of 10ge should about cover all the needs for inband layer-2 
related stuff as a few kbit/s already should suffice ;)

1% being the minimum you can set this to.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Tue, 7 Feb 2012, Randy McAnally wrote:

> On Tue, 7 Feb 2012 08:32:21 -0500, Ann Kwok wrote
>> Hello
>>
>> Thank you for your help
>>
>> But we can't increase the pipe as we are using 10G switch.
>>
>> The congestion happens when the traffic is using 7G
>
> If you cannot increase bandwidth, then you must increase the TX queue (in QOS
> and/or port buffer).
>
> ~Randy
>
>


From xionox at gmail.com  Tue Feb  7 13:19:42 2012
From: xionox at gmail.com (Arzhel Younsi)
Date: Tue, 7 Feb 2012 20:19:42 +0100
Subject: Wireless Recommendations
In-Reply-To: <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
Message-ID: <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>

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.

On Wed, Feb 1, 2012 at 02:09, Mario Eirea <meirea at charterschoolit.com> wrote:
> Aruba AP 105. This version comes with a virtual controller that can manage 16 APs without the need of an additional controller. For high capacity areas I would go with Ruckus.
>
> -Mario Eirea
>
> On Jan 31, 2012, at 11:46 AM, "Joel jaeggli" <joelja at bogus.com> wrote:
>
>> On 1/30/12 12:46 , Jim Gonzalez wrote:
>>> Hi,
>>>
>>> ? ? ? ? ? ? ? ?I am looking for a Wireless bridge or Router that will
>>> support 600 wireless clients concurrently (mostly cell phones). ?I need it
>>> for a proof of concept.
>>
>> an aruba controller and 8 dual radio aps.
>>
>>>
>>>
>>>
>>>
>>> Thanks in advance
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1416 / Virus Database: 2109/4778 - Release Date: 01/31/12
>


From source_route at yahoo.com  Tue Feb  7 13:43:24 2012
From: source_route at yahoo.com (Philip Lavine)
Date: Tue, 7 Feb 2012 11:43:24 -0800 (PST)
Subject: issues with Level3 in NYC
Message-ID: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>

Anybody having issues with peering with Level3 in NYC

From jof at thejof.com  Tue Feb  7 13:50:20 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Tue, 7 Feb 2012 11:50:20 -0800
Subject: Wireless Recommendations
In-Reply-To: <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
Message-ID: <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>

On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi <xionox at gmail.com> 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


From me at anuragbhatia.com  Tue Feb  7 13:57:18 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Wed, 8 Feb 2012 01:27:18 +0530
Subject: issues with Level3 in NYC
In-Reply-To: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>
References: <1328643804.47714.YahooMailNeo@web30801.mail.mud.yahoo.com>
Message-ID: <CAJ0+aXb=hgO8dVfMHeZP7-Fkn9XuFvmGUAW-f9B=VA=odYM8yA@mail.gmail.com>

I checked couple of main networks from NYC site via Level3's looking
glass<http://lookingglass.level3.net/>.
It went fine.

What's your network's ASN?

On Wed, Feb 8, 2012 at 1:13 AM, Philip Lavine <source_route at yahoo.com>wrote:

> Anybody having issues with peering with Level3 in NYC
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From mpetach at netflight.com  Tue Feb  7 15:01:51 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 7 Feb 2012 13:01:51 -0800
Subject: 2012.02.07 NANOG54 day 2 morning session notes
Message-ID: <CAEmG1=o6ui8L+GjVBr-gHV0Djekz2G9cFe1oFaCyiGvQaPWTTg@mail.gmail.com>

I've posted my notes from the morning session at

http://kestrel3.netflight.com/2012.02.07-nanog54-morning-session.txt

for those who find them useful.

Off to grab lunch now!

BTW--wouldn't deploying the telex proxy require ISPs to do
away with BCP 38 in their networks?

Just curious.

Thanks!

Matt


From matt at mattreath.com  Tue Feb  7 15:31:21 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 15:31:21 -0600
Subject: Firewalls in service provider environments
Message-ID: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>

All,

Looking for some recommendations on firewall placement in service provider
environments.  I'm of the school of thought that in my SP network I do as
little firewalling/packet filtering as possible. As in none, leave that to
my end users or offer a "managed" firewall solution where if a customer
signs up for the extra service I put him in a VRF or VLAN that is "behind"
a firewall and manage that solution for them. Otherwise I don't prefer to
have a firewall inline in my service provider network for all customer
traffic to go through. I can accomplish filtering of known bad ports on my
edge routers either facing my customers or upstream providers.

What is the group's thought on this?

-Matt

--
Matt Reath
CCIE #27316 (SP)
matt at mattreath.com | http://mattreath.com
Twitter: http://twitter.com/mpreath



From leigh.porter at ukbroadband.com  Tue Feb  7 15:42:34 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 7 Feb 2012 21:42:34 +0000
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Matthew Reath [mailto:matt at mattreath.com]
> Sent: 07 February 2012 21:34
> To: nanog at nanog.org
> Subject: Firewalls in service provider environments
> 
> All,
> 
> Looking for some recommendations on firewall placement in service
> provider
> environments.  I'm of the school of thought that in my SP network I do
> as
> little firewalling/packet filtering as possible. As in none, 

I had a vendor actually suggest that that ALL my customer traffic should traverse a firewall. I asked why and they said "Ahhh it the internet, must have firewall". I suppose this must have been a great firewall.

So yes I would agree with you, firewall nothing for your customers unless they are paying you for a specific service. Filtering known bad ports, well, what's a known bad port? Bad for one person may be quite important for another. Whilst filtering port 25 outbound may help prevent some bots from emanating spam, it certainly does a lot to annoy other people.

--
Leigh Porter


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


From streiner at cluebyfour.org  Tue Feb  7 15:46:04 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Tue, 7 Feb 2012 16:46:04 -0500 (EST)
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <Pine.LNX.4.64.1202071636030.24619@whammy.cluebyfour.org>

On Tue, 7 Feb 2012, Matthew Reath wrote:

> Looking for some recommendations on firewall placement in service provider
> environments.  I'm of the school of thought that in my SP network I do as
> little firewalling/packet filtering as possible. As in none, leave that to
> my end users or offer a "managed" firewall solution where if a customer
> signs up for the extra service I put him in a VRF or VLAN that is "behind"
> a firewall and manage that solution for them. Otherwise I don't prefer to
> have a firewall inline in my service provider network for all customer
> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.

I tend to agree with this, and I think you'll find that most providers 
agree with that as well.

There are several reasons for this:
1. Firewalls present another point of failure, and SPs are generally loath 
to force customer traffic* through another choke point.
2. Many firewall appliances are stateful.  Multihomed customers and 
stateful firewalls can be a major headache.  Asymmetric routing through 
stateful firewalls is pretty much a non-starter.
3. You (the customer) know your applications and internal network better 
than the SP does.  It makes sense for you to manage your firewalls/NAT/
internal LAN.  If you can't or don't want to do this, hire a consultant to 
do the work for you.
4. Most SPs would not want the liability of managing firewall service.
5. Dropping packets at the SP edge could be done, but I think most SPs 
would only want to do so in extraordinary circumstances.

* - As you mentioned, unless the SP offers, and those customers 
specifically pay for a firewalled service.

jms


From matt at mattreath.com  Tue Feb  7 15:52:04 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 15:52:04 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
Message-ID: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>

>
>
>> -----Original Message-----
>> From: Matthew Reath [mailto:matt at mattreath.com]
>> Sent: 07 February 2012 21:34
>> To: nanog at nanog.org
>> Subject: Firewalls in service provider environments
>>
>> All,
>>
>> Looking for some recommendations on firewall placement in service
>> provider
>> environments.  I'm of the school of thought that in my SP network I do
>> as
>> little firewalling/packet filtering as possible. As in none,
>
> I had a vendor actually suggest that that ALL my customer traffic should
> traverse a firewall. I asked why and they said "Ahhh it the internet, must
> have firewall". I suppose this must have been a great firewall.
>
> So yes I would agree with you, firewall nothing for your customers unless
> they are paying you for a specific service. Filtering known bad ports,
> well, what's a known bad port? Bad for one person may be quite important
> for another. Whilst filtering port 25 outbound may help prevent some bots
> from emanating spam, it certainly does a lot to annoy other people.
>
> --
> Leigh Porter
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>

>From a filtering perspective there are some know worm ports and such that
we usually have a template created for.

Here is the template we typically use (or a variant of it):

<-- snippet -->
access-list 102 deny   ip 10.0.0.0 0.255.255.255 any
access-list 102 deny   ip 172.16.0.0 0.15.255.255 any
access-list 102 deny   ip 192.168.0.0 0.0.255.255 any
access-list 102 deny   ip 0.0.0.0 0.255.255.255 any
access-list 102 deny   ip 127.0.0.0 0.255.255.255 any
access-list 102 deny   ip 224.0.0.0 15.255.255.255 any
access-list 102 deny   ip host 255.255.255.255 any
access-list 102 deny   tcp any any eq 135
access-list 102 deny   udp any any eq 135
access-list 102 deny   udp any any eq netbios-ns
access-list 102 deny   tcp any any eq 139
access-list 102 deny   udp any any eq netbios-ss
access-list 102 deny   tcp any any eq 445
access-list 102 deny   tcp any any eq 593
access-list 102 deny   tcp any any eq 4444
access-list 102 deny   tcp any any eq 9996
access-list 102 deny   tcp any any eq 5554
access-list 102 deny   tcp any any eq 8888
access-list 102 deny   tcp any any eq 7778
access-list 102 deny   tcp any any eq 8594
access-list 102 deny   tcp any any eq 8563
access-list 102 deny   tcp any any eq 1434
<-- end snippet -->

This blocks some common worm ports as well as traffic sourced outside of
our network from reserved address space.

-Matt




From bill at herrin.us  Tue Feb  7 16:10:35 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 7 Feb 2012 17:10:35 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
Message-ID: <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:52 PM, Matthew Reath <matt at mattreath.com> wrote:
> Here is the template we typically use (or a variant of it):
>
> <-- snippet -->
> access-list 102 deny ? ip 10.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 172.16.0.0 0.15.255.255 any
> access-list 102 deny ? ip 192.168.0.0 0.0.255.255 any
> access-list 102 deny ? ip 0.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 127.0.0.0 0.255.255.255 any
> access-list 102 deny ? ip 224.0.0.0 15.255.255.255 any
> access-list 102 deny ? ip host 255.255.255.255 any
> access-list 102 deny ? tcp any any eq 135
> access-list 102 deny ? udp any any eq 135
> access-list 102 deny ? udp any any eq netbios-ns
> access-list 102 deny ? tcp any any eq 139
> access-list 102 deny ? udp any any eq netbios-ss
> access-list 102 deny ? tcp any any eq 445
> access-list 102 deny ? tcp any any eq 593
> access-list 102 deny ? tcp any any eq 4444
> access-list 102 deny ? tcp any any eq 9996
> access-list 102 deny ? tcp any any eq 5554
> access-list 102 deny ? tcp any any eq 8888
> access-list 102 deny ? tcp any any eq 7778
> access-list 102 deny ? tcp any any eq 8594
> access-list 102 deny ? tcp any any eq 8563
> access-list 102 deny ? tcp any any eq 1434
> <-- end snippet -->

One of my customers has a list like that. They can't understand why
one in every hundred or so TCP connections on port 443 fails.

Hint: you forgot "access-list 102 permit tcp any any established"
after "access-list 102 deny   ip host 255.255.255.255 any". The
destination port in one direction is the source port in the other and
many of those are dynamic source ports picked by Windows. Unless you
restrict that filter to just packets attempting to initiate a new
connection, you're shooting yourself in the foot.

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Tue Feb  7 16:22:38 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 7 Feb 2012 17:22:38 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:31 PM, Matthew Reath <matt at mattreath.com> wrote:
> Looking for some recommendations on firewall placement in service provider
> environments. ?I'm of the school of thought that in my SP network I do as
> little firewalling/packet filtering as possible. As in none, leave that to
> my end users or offer a "managed" firewall solution where if a customer
> signs up for the extra service I put him in a VRF or VLAN that is "behind"
> a firewall and manage that solution for them. Otherwise I don't prefer to
> have a firewall inline in my service provider network for all customer
> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.
>
> What is the group's thought on this?

Hi Matthew,

It Depends.

High end business customers (of the BGP speaking variety) generally
appreciate having a remote triggered black hole facility. That's a
kind of firewall. http://tools.ietf.org/html/rfc5635

Business customers in general shouldn't be filtered unless they buy a
managed firewall service from you. Don't tamper with their DNS either!

When you get down to the residential and Internet Cafe type users,
there is some common filtering you should consider:

TCP SYN to port 25 outbound from your dynamic IP customers should
generally be disallowed except to your local mail servers. 99 times
out of 100, connections originating to this port from dynamic IP
customers will be Email Spam from an infected PC. This will hurt you.
It will hurt you with spam complaints. It will hurt you with adverse
action by RBL providers. It will hurt you with damage to your
reputation and brand.

http://www.spamhaus.org/faq/answers.lasso?section=isp%20spam%20issues#133


Blocking TCP and UDP 137, 138, 139 and 445 is not terribly unusual.
These are associated with Microsoft file sharing protocols. Off the
LAN and outside the enterprise anybody actually open to this traffic
is generally asking to be hacked. Then a spam bot is installed and you
have another problem customer who isn't paying you enough to deal with
that crap.

Regards,
Bill Herrin





-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From gbonser at seven.com  Tue Feb  7 16:34:07 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 7 Feb 2012 22:34:07 +0000
Subject: Firewalls in service provider environments
In-Reply-To: <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>

> 
> Here is the template we typically use (or a variant of it):
> 
> <-- snippet -->
> access-list 102 deny   ip 10.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 172.16.0.0 0.15.255.255 any
> access-list 102 deny   ip 192.168.0.0 0.0.255.255 any
> access-list 102 deny   ip 0.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 127.0.0.0 0.255.255.255 any
> access-list 102 deny   ip 224.0.0.0 15.255.255.255 any
> access-list 102 deny   ip host 255.255.255.255 any

I typically also include traffic to/from:

TCP/UDP port 0
169.254.0.0/16
192.0.2.0/24
198.51.100.0/24
203.0.113.0/24

Been wondering if I should also block 198.18.0.0/15 as well.





From matt at mattreath.com  Tue Feb  7 16:35:44 2012
From: matt at mattreath.com (Matthew Reath)
Date: Tue, 7 Feb 2012 16:35:44 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
Message-ID: <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>

> On Tue, Feb 7, 2012 at 4:52 PM, Matthew Reath <matt at mattreath.com> wrote:
>> Here is the template we typically use (or a variant of it):
>>
>> <-- snippet -->
>> access-list 102 deny ? ip 10.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 172.16.0.0 0.15.255.255 any
>> access-list 102 deny ? ip 192.168.0.0 0.0.255.255 any
>> access-list 102 deny ? ip 0.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 127.0.0.0 0.255.255.255 any
>> access-list 102 deny ? ip 224.0.0.0 15.255.255.255 any
>> access-list 102 deny ? ip host 255.255.255.255 any
>> access-list 102 deny ? tcp any any eq 135
>> access-list 102 deny ? udp any any eq 135
>> access-list 102 deny ? udp any any eq netbios-ns
>> access-list 102 deny ? tcp any any eq 139
>> access-list 102 deny ? udp any any eq netbios-ss
>> access-list 102 deny ? tcp any any eq 445
>> access-list 102 deny ? tcp any any eq 593
>> access-list 102 deny ? tcp any any eq 4444
>> access-list 102 deny ? tcp any any eq 9996
>> access-list 102 deny ? tcp any any eq 5554
>> access-list 102 deny ? tcp any any eq 8888
>> access-list 102 deny ? tcp any any eq 7778
>> access-list 102 deny ? tcp any any eq 8594
>> access-list 102 deny ? tcp any any eq 8563
>> access-list 102 deny ? tcp any any eq 1434
>> <-- end snippet -->
>
> One of my customers has a list like that. They can't understand why
> one in every hundred or so TCP connections on port 443 fails.
>
> Hint: you forgot "access-list 102 permit tcp any any established"
> after "access-list 102 deny   ip host 255.255.255.255 any". The
> destination port in one direction is the source port in the other and
> many of those are dynamic source ports picked by Windows. Unless you
> restrict that filter to just packets attempting to initiate a new
> connection, you're shooting yourself in the foot.
>
> Regards,
> Bill Herrin
>
>
>
>
> --
> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
>

Yeah agreed.  The only place this gets applied is inbound on the interface
facing an upstream provider. ACLs ingress from end customers are much
different. In theory this could cause issues with externally initiated
traffic that use lets say 8888 as its random source port.

-Matt






From jared at puck.nether.net  Tue Feb  7 16:46:36 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 7 Feb 2012 17:46:36 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
Message-ID: <2F517843-FA2E-4198-8E8C-2055DEE7B523@puck.nether.net>

Yes, you should.

On Feb 7, 2012, at 5:34 PM, George Bonser wrote:

> Been wondering if I should also block 198.18.0.0/15 as well.



From matt at overloaded.net  Tue Feb  7 16:59:35 2012
From: matt at overloaded.net (Matt Buford)
Date: Tue, 7 Feb 2012 16:59:35 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
Message-ID: <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt at mattreath.com> wrote:

> > One of my customers has a list like that. They can't understand why
> > one in every hundred or so TCP connections on port 443 fails.
> >
> > Hint: you forgot "access-list 102 permit tcp any any established"
> > after "access-list 102 deny   ip host 255.255.255.255 any". The
> > destination port in one direction is the source port in the other and
> > many of those are dynamic source ports picked by Windows. Unless you
> > restrict that filter to just packets attempting to initiate a new
> > connection, you're shooting yourself in the foot.
>
> Yeah agreed.  The only place this gets applied is inbound on the interface
> facing an upstream provider. ACLs ingress from end customers are much
> different. In theory this could cause issues with externally initiated
> traffic that use lets say 8888 as its random source port.
>

If you apply the ACL you showed as an inbound ACL on your provider facing
interfaces, you will be breaking any connections that exit your network
with source ports from your list of bad ports.  For example, you connect
out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
dropped by your ACL.

This seems to be a common mistake, and is often missed because it manifests
as one-in-thousands failures of TCP connections.  People tend to just try a
second time and it works and never investigate why they had one random
failure.

From morrowc.lists at gmail.com  Tue Feb  7 16:59:47 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 7 Feb 2012 17:59:47 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
Message-ID: <CAL9jLaY8Fki-3Kn0uTMHEApiJqa3fC1FbOUMW9mLp2N5f2ScpA@mail.gmail.com>

On Tue, Feb 7, 2012 at 4:42 PM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
>
>
>> -----Original Message-----
>> From: Matthew Reath [mailto:matt at mattreath.com]
>> Sent: 07 February 2012 21:34
>> To: nanog at nanog.org
>> Subject: Firewalls in service provider environments
>>
>> All,
>>
>> Looking for some recommendations on firewall placement in service
>> provider
>> environments. ?I'm of the school of thought that in my SP network I do
>> as
>> little firewalling/packet filtering as possible. As in none,
>
> I had a vendor actually suggest that that ALL my customer traffic should traverse a firewall. I asked why and they said "Ahhh it the internet, must have firewall". I suppose this must have been a great firewall.

'of china'! ha! hahaha.... anyway.

> So yes I would agree with you, firewall nothing for your customers unless they are paying you for a specific service. Filtering known bad ports, well, what's a known bad port? Bad for one person may be quite important for another. Whilst filtering port 25 outbound may help prevent some bots from emanating spam, it certainly does a lot to annoy other people.
>

I think for a purely SP network, transit-provider core links sort of
thing, why filter anything at all? why filter anything that's not
destined to your own equipment? You can't possibly know what some
customer (or set of customers) are going to do with their traffic, so
you can't possibly filter it sanely/safely.

for a consumer ISP, provided your TOS says it's ok, why not filter
some common problems:
  tcp/25
  ... not much else really... and REALLY you just want to send tcp/25
-> 587 on your mail-relays (or redirect to internal use addresses on
the relays).

If customers (in either case) want to pay you for 'security services'
then rock some filters on their CPE, with the option to move that
upstream to your PE if you have to (too much crap on customer link).

-chris


From mysidia at gmail.com  Tue Feb  7 18:51:16 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 7 Feb 2012 18:51:16 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
Message-ID: <CAAAwwbXcE-1PhPNoNN9DL9XZ8M9qz7Q_c=wwTNY_i0ri1pdPUg@mail.gmail.com>

On Tue, Feb 7, 2012 at 3:31 PM, Matthew Reath <matt at mattreath.com> wrote:

> traffic to go through. I can accomplish filtering of known bad ports on my
> edge routers either facing my customers or upstream providers.
>

I wouldn't want my provider breaking my connectivity in the name of
security. My thought on this is:  by all means filter, firewall, and
mangle  packets addressed  From/To service provider equipment  (for
example, port 22 TCP packets sent to the address of the ISP router),  in
order to protect ISP network,     But, with some minor exceptions, in your
role as ISP, internal firewalls should be separate from customer networks,
and,  never ever filter, firewall, or mangle packets _forwarded_ by service
provider equipment To/From customer networks.

If you manage the downstream network,  the customer has requested special
filtering or restrictions,  or  a pattern of abuse has been detected from a
certain downstream that can be temporarily mitigated with a filter,  that's
a different story.

It is acceptable to drop packets to enforce network policy, such as no-spam
rules that a customer or host has violated,  for example:  all IP packets
to a host.   It is acceptable to drop erroneous packets, such as ones with
an incorrect checksum or source IP that the  customer has not been
assigned,  or has not informed the provider that they were assigned.

I would say it's in general unacceptable for an ISP to discriminate against
packets addressed to or sourced from specific port numbers.

That's actually breaking connectivity.

There's no such thing as a "bad port number";   there are port numbers that
certain applications have abused;    the entire port range should be
available for any host as indicated by the various RFCs that define the
protocol.


If packets with any valid bit pattern in the source port or destination
port field are dropped, based on a valid bit pattern in that field, then
that is really a breakage of proper connectivity by the provider.


What is the group's thought on this?
> -Matt
>
--
-JH

From rdobbins at arbor.net  Tue Feb  7 19:00:00 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 01:00:00 +0000
Subject: 2011 Worldwide Infrastructure Report available for download.
Message-ID: <C35D7438-2408-49C9-836A-EAD12B88D9B0@arbor.net>


[Apologies if you've already seen this announcement in other forums.]

We've just posted the 2011 Worldwide Infrastructure Security Report for download at this URL:

<http://www.arbornetworks.com/report>

This year's WWISR contains responses and data from 114 network operators in all major geographical regions.  The WWISR is based upon input from the global operational community, and, as such, is unique in its focus on the operational security aspects of public-facing networks.

Many of you contributed to the survey which forms the foundation of the report; as always, we're grateful for your insight and participation, and welcome your feedback and comments.

Thanks much!

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From ops.lists at gmail.com  Tue Feb  7 19:45:34 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 8 Feb 2012 07:15:34 +0530
Subject: Firewalls in service provider environments
In-Reply-To: <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <CAP-guGXcc6JUn=67-YnMAGL36+zxMFLzT4s-2U1+V1Ax+ij78Q@mail.gmail.com>
Message-ID: <CAArzuovzrprSvt+kj-+O_2y4PC9j78pUBL0-W+JRbYZm3uXjFw@mail.gmail.com>

On Wed, Feb 8, 2012 at 3:52 AM, William Herrin <bill at herrin.us> wrote:

> High end business customers (of the BGP speaking variety) generally
> appreciate having a remote triggered black hole facility. That's a
> kind of firewall. http://tools.ietf.org/html/rfc5635

While I 100% agree that sticking a stateful firewall into a SP
environment is several kinds of dumb, I wouldn't run it wide open and
unfiltered either.

There are several things that a SP should definitely be looking at,
that'd still describe as a firewall, and are not the "stateful
firewall / IDS / IPS magic black box" half the posters in this thread
are instinctively reacting to.   For the record, yes, I agree those
are a bad idea.

But how about these -  All these are going to be implemented to a
greater or a lesser degree, and in different places, depending on how
you define SP (selling only transit OC-48s?  T1..T3 to end user
corporations?  Datacenter hosting?)

1. S/RTBH

2. Netflow based devices (Arbor, Tivoli TNPFA flow analyzers, etc)

3. DDoS mitigation - possibly resold as an extra service [built
inhouse / provided by other vendors or your upstream tier 1]

4. Router ACLs to get rid of common worm traffic

5. Filtering both ways to prevent async routing to bypass your filters
(http://irbs.net/internet/nanog/0408/0405.html and in that thread,
http://irbs.net/internet/nanog/0408/0465.html for a fun example)

6.  Putting different customers into different VLANs rather than
packing everybody into a single VLAN - that way they don't spoof
unused IPs on the same VLAN (that is, unused IPs anywhere in your IP
space .. and this is, like #5, a rather old attack that I haven't seen
in a while, it used to be very popular with spammers some years back,
and sticking your customers into separate VLANs anyway makes a lot of
sense from a management perspective, leave alone the security
implications)

--srs

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From ops.lists at gmail.com  Tue Feb  7 19:47:41 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Wed, 8 Feb 2012 07:17:41 +0530
Subject: Firewalls in service provider environments
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
Message-ID: <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>

On Wed, Feb 8, 2012 at 4:04 AM, George Bonser <gbonser at seven.com> wrote:
> I typically also include traffic to/from:
>
> TCP/UDP port 0
> 169.254.0.0/16
> 192.0.2.0/24
> 198.51.100.0/24
> 203.0.113.0/24
>
> Been wondering if I should also block 198.18.0.0/15 as well.

suresh at frodo 17:46:08 :~$ nslookup 1.113.0.203.bogons.cymru.com
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
Name:   1.113.0.203.bogons.cymru.com
Address: 127.0.0.2

Also available as a bgp feed, for years now.   Saves you updating your
martian ACLs from time to time.

-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From ryan at u13.net  Tue Feb  7 21:20:07 2012
From: ryan at u13.net (Ryan Rawdon)
Date: Tue, 7 Feb 2012 22:20:07 -0500
Subject: report botnet C&C?
Message-ID: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>

Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?

From steve.bertrand at gmail.com  Tue Feb  7 21:20:13 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Tue, 07 Feb 2012 22:20:13 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBB5C5@RWC-MBX1.corp.seven.com>
 <CAArzuou_yr8aCtxQzg50CnHh7hy2zbPkbpXKjDsYiZxtLWvK_w@mail.gmail.com>
Message-ID: <4F31E9ED.90506@gmail.com>

On 2012.02.07 20:47, Suresh Ramasubramanian wrote:
> On Wed, Feb 8, 2012 at 4:04 AM, George Bonser<gbonser at seven.com>  wrote:
>> I typically also include traffic to/from:
>>
>> TCP/UDP port 0
>> 169.254.0.0/16
>> 192.0.2.0/24
>> 198.51.100.0/24
>> 203.0.113.0/24
>>
>> Been wondering if I should also block 198.18.0.0/15 as well.
>
> suresh at frodo 17:46:08 :~$ nslookup 1.113.0.203.bogons.cymru.com
> Server:         127.0.0.1
> Address:        127.0.0.1#53
>
> Non-authoritative answer:
> Name:   1.113.0.203.bogons.cymru.com
> Address: 127.0.0.2
>
> Also available as a bgp feed, for years now.   Saves you updating your
> martian ACLs from time to time.

Amen. v4 and v6 lists are available via free BGP feed (via v4 and v6 
peering) from Cymru. Dynamic simplicity within community's finest standards.

Works wonders for those who have s/RTBH deployed.



From rdobbins at arbor.net  Tue Feb  7 21:23:03 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 03:23:03 +0000
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>


On Feb 8, 2012, at 10:20 AM, Ryan Rawdon wrote:

> Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?

Probably the abuse contact for the network in question, if contact info is available.  

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

		The basis of optimism is sheer terror.

			  -- Oscar Wilde



From lists at 1337.mx  Tue Feb  7 21:26:56 2012
From: lists at 1337.mx (toor)
Date: Wed, 8 Feb 2012 11:26:56 +0800
Subject: report botnet C&C?
In-Reply-To: <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
 <DAF7F985-3A7A-4141-8993-637F86D21B2E@arbor.net>
Message-ID: <CALjCmpkUGPKbZTS5ALUxt=trqaqtqCrTXDOTHT+WP33Hm6HRSA@mail.gmail.com>

It may be worth reporting it to Shadow Server:
http://www.shadowserver.org/wiki/pmwiki.php/Contact/ContactUs

On Wed, Feb 8, 2012 at 11:23 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Feb 8, 2012, at 10:20 AM, Ryan Rawdon wrote:
>
>> Assuming it is not a futile/wasted effort, where is the current best place/resource to report an active botnet C&C to?
>
> Probably the abuse contact for the network in question, if contact info is available.
>
> -----------------------------------------------------------------------
> Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
>
> ? ? ? ? ? ? ? ?The basis of optimism is sheer terror.
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?-- Oscar Wilde
>
>


From graham at g-rock.net  Tue Feb  7 21:55:12 2012
From: graham at g-rock.net (graham)
Date: Tue, 07 Feb 2012 21:55:12 -0600
Subject: Anyone from Kraus Electronic/CableTV lurking?
Message-ID: <CB574E40.4B565%graham@g-rock.net>

I tried to reach Kraus Electronic / Cable TV through various means. Anyone
know how to reach their NOC?
They?re announcing 12.198.32.0/20 (they only been swiped a /22), which is
getting into my 12.198.40.0/22 assignment.

On hold with AT&T, of course.

-graham

From morrowc.lists at gmail.com  Tue Feb  7 22:23:38 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 7 Feb 2012 23:23:38 -0500
Subject: Anyone from Kraus Electronic/CableTV lurking?
In-Reply-To: <CB574E40.4B565%graham@g-rock.net>
References: <CB574E40.4B565%graham@g-rock.net>
Message-ID: <CAL9jLaaQ1OC2mLBHvF+D+_YDzXTbUruc=zRUZm-C6PVEx=DWdw@mail.gmail.com>

On Tue, Feb 7, 2012 at 10:55 PM, graham <graham at g-rock.net> wrote:
> I tried to reach Kraus Electronic / Cable TV through various means. Anyone
> know how to reach their NOC?
> They?re announcing 12.198.32.0/20 (they only been swiped a /22), which is
> getting into my 12.198.40.0/22 assignment.
>
> On hold with AT&T, of course.
>

if only there were some way... for isp's to keep track of their
assignments to their customers, and say tell everyone else in the
world in a fashion that's mechanically useful.

:(

(Oddly I thought ATT prefix + packet filtered all their customers?
maybe this customer shrank out of their /20 and you got their
seconds?)

-chris


From graham at g-rock.net  Tue Feb  7 22:30:50 2012
From: graham at g-rock.net (graham)
Date: Tue, 07 Feb 2012 22:30:50 -0600
Subject: Anyone from Kraus Electronic/CableTV lurking?
In-Reply-To: <CAL9jLaaQ1OC2mLBHvF+D+_YDzXTbUruc=zRUZm-C6PVEx=DWdw@mail.gmail.com>
Message-ID: <CB57569A.4B570%graham@g-rock.net>


> 
> (Oddly I thought ATT prefix + packet filtered all their customers?
> maybe this customer shrank out of their /20 and you got their
> seconds?)
> 
> -chris

I thought so too; they were pretty explicit with mine ;-)

However, someone worked some magic somewhere ... I am seeing part of my nets
come back to life.

-graham




From kilobit at gmail.com  Wed Feb  8 01:56:25 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 08:56:25 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
Message-ID: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>

Roland,
On Mon, Feb 6, 2012 at 2:43 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> S/RTBH can be rapidly shifted in order to deal with changing purported source IPs, and it isn't limited to /32s.

The big drawback with S/RTBH is that it is a DoS method in itself.

Say eyeball provider X has implemented automated S/RTBH, and I have a
grudge against them.
I would simply DoS a couple of the subscribers with spoofed source IP
addresses from google, youtube, netflow and hulu.
The automated S/RTBH drops all packets coming from those IP addresses.
Presto; many angry consumers call the ISP's helpdesk.

The same goes for hosting networks, I just need to identify what kind
of service my intended victim is dependent on. (i.e. paypal).
Then DoS any part of the hosters network with spoofed source addresses
of paypal, the automated S/RTBH makes sure the entire hosting network
is not able to reach paypal anymore.
Presto, mission achieved.

Bas


From gbonser at seven.com  Wed Feb  8 02:04:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 08:04:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: bas 
> Sent: Tuesday, February 07, 2012 11:56 PM
> To: Dobbins, Roland; nanog
> Subject: Re: UDP port 80 DDoS attack
> 
> Say eyeball provider X has implemented automated S/RTBH, and I have a
> grudge against them.
> I would simply DoS a couple of the subscribers *with spoofed source IP*
> addresses from google, youtube, netflow and hulu.
> The automated S/RTBH drops all packets coming from those IP addresses.
> Presto; many angry consumers call the ISP's helpdesk.

Comes back to providers allowing "spoofed" traffic into their networks from customers.  That seems to me to be the low-hanging fruit here.



From mpetach at netflight.com  Wed Feb  8 02:05:09 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Wed, 8 Feb 2012 00:05:09 -0800
Subject: 2012.02.07 NANOG54 day 2 notes, afternoon session
Message-ID: <CAEmG1=r7S1L7hF+DemP-7X+e1Ks28WFetTdG1gKB=0Tvb1HY7w@mail.gmail.com>

I'm so sorry; I thought I would have time to send these
out after the peering track, but I got pulled into some
conversations which ended up lasting until 2330 hours,
and ran right on through the social event.  So, the
afternoon session notes ended up having to wait until
I got back to my room.  Apologies for the delay,
they're now up at

http://kestrel3.netflight.com/2012.02.07-nanog54-afternoon-session.txt

and apache has been restarted on the box
for those who tried to get the notes earlier
and got nothing but a timeout.

Thanks!

Matt


From rdobbins at arbor.net  Wed Feb  8 02:29:31 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 08:29:31 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
Message-ID: <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>


On Feb 8, 2012, at 2:56 PM, bas wrote:

> The big drawback with S/RTBH is that it is a DoS method in itself.

I'm not an advocate of *automated* S/RTBH, and I am an advocate of whitelisting various well-known 'golden networks/IPs' via prefix-lists in order to avoid this issue in part; also, note that the concept of partial service recovery incorporates the notion of some legitimate traffic/users being blocked in order to maintain the availability of the targeted server/service/application for the majority of legitimate traffic/users. 

Also note that S/RTBH isn't a universal panacea; it's just one tool in the toolbox.  flowspec is more flexible due to its layer-4 granularity; and other types of tools such as IDMS are even more flexible and incorporate much richer classification technology.

It's important to understand that this isn't a theoretical discussion - I've personally utilized/helped others to utilize S/RTBH to successfully mitigate large-scale DDoS attacks, and it's a lowest-common-denominator in terms of a somewhat dynamic mitigation mechanism.  Let's not make the perfect the enemy of the merely good.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From keegan.holley at sungard.com  Wed Feb  8 02:31:05 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 03:31:05 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>

2012/2/8 George Bonser <gbonser at seven.com>

>
>
> > -----Original Message-----
> > From: bas
> > Sent: Tuesday, February 07, 2012 11:56 PM
> > To: Dobbins, Roland; nanog
> > Subject: Re: UDP port 80 DDoS attack
> >
> > Say eyeball provider X has implemented automated S/RTBH, and I have a
> > grudge against them.
> > I would simply DoS a couple of the subscribers *with spoofed source IP*
> > addresses from google, youtube, netflow and hulu.
> > The automated S/RTBH drops all packets coming from those IP addresses.
> > Presto; many angry consumers call the ISP's helpdesk.
>
> Comes back to providers allowing "spoofed" traffic into their networks
> from customers.  That seems to me to be the low-hanging fruit here.
>
>
>
How do you stop it?  Granted, traffic from 10/8 or 127.0.0.1 coming in via
an upstream is obvious, but that's about it.  There's nothing in a packet
that will tell you where it came from compared to the source IP field in
the IP header.  uRPF is a problem for anyone who's sufficiently multihomed
since it causes asymmetric routing.

From gbonser at seven.com  Wed Feb  8 03:03:48 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:03:48 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>



>From: Keegan Holley 

>How do you stop it?? 

A provider knows what destination IP traffic they route TO a customer, don't they?  That should be the only source IPs they accept FROM a customer.


If you don't route it TO the customer, you shouldn't accept it FROM the customer unless you have made special arrangements with them and verified they are entitled to source the traffic from the desired IPs.




From keegan.holley at sungard.com  Wed Feb  8 03:12:21 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 04:12:21 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>

It works in theory, but to get every ISP and hosting provider to ACL their
edges and maintain those ACL's for every customer no matter how large might
be a bit difficult.  Also, what about non-BGP customers or customers that
just accept a default route? Or even customers that just want return
traffic to come in a different link for some reason.  ISP's would suddenly
become giant traffic registries.

2012/2/8 George Bonser <gbonser at seven.com>

>
>
> >From: Keegan Holley
>
> >How do you stop it?
>
> A provider knows what destination IP traffic they route TO a customer,
> don't they?  That should be the only source IPs they accept FROM a customer.
>
>
> If you don't route it TO the customer, you shouldn't accept it FROM the
> customer unless you have made special arrangements with them and verified
> they are entitled to source the traffic from the desired IPs.
>
>
>
>

From gbonser at seven.com  Wed Feb  8 03:51:15 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:51:15 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>



>From: Keegan Holley 
> Subject: Re: UDP port 80 DDoS attack

> It works in theory, but to get every ISP and hosting provider to ACL their edges and maintain those ACL's for every customer no matter how large might be a bit difficult.? 

You don't have to ACL in most cases. RPF works for most.  There will be a few, relatively darned few, that you will need to ACL, but RPF takes care of a large number of them.

Besides, I never meant to imply that this business was easy and not "difficult".


> Also, what about non-BGP customers or customers that just accept a default route?  

I don't follow.  The ISP still knows what traffic gets routed TO them.  You only accept FROM them what you route TO them, even if you hand them a default route.


> Or even customers that just want return traffic to come in a different link for some reason.

Still don't follow.  I am not talking about having a firewall that is stateful.  I am talking packet by packet.  If you don't route it to them, you don't accept it from them unless you have made arrangements otherwise, which will be a small percentage of your customers. Sure, some might be multihomed but it is easy enough to verify that they have the networks in question SWIPed to them or a call to the other provider can clear that up in a few minutes.  It isn't THAT hard.


> ISP's would suddenly become giant traffic registries.


No, we have registries to act as registries, the ISPs should be checking them, and double checking.  It isn't something that is going to change every day or every week. Once you get it set up, it is going to be stable for a while.  Sure, it means a little more work in setting up a customer, but it also means that if all your neighbors do the same thing, you field many fewer calls dealing with stupid DoS crap.



From gbonser at seven.com  Wed Feb  8 03:56:44 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 09:56:44 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>

> No, we have registries to act as registries, the ISPs should be
> checking them, and double checking.  It isn't something that is going
> to change every day or every week. Once you get it set up, it is going
> to be stable for a while.  Sure, it means a little more work in setting
> up a customer, but it also means that if all your neighbors do the same
> thing, you field many fewer calls dealing with stupid DoS crap.
> 

I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.



From kilobit at gmail.com  Wed Feb  8 07:03:19 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 14:03:19 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
Message-ID: <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>

On Wed, Feb 8, 2012 at 10:56 AM, George Bonser <gbonser at seven.com> wrote:
> I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.

Most of us prevent their customers from sending out spoofed traffic.

77% of all networks seem to think so.
http://spoofer.csail.mit.edu/summary.php

However the remaining networks allow spoofed traffic to egress their networks.

When that traffic enters my network, I have no method whatsoever to
differentiate it from any other traffic.
I could ask my upstream where they see it coming from, which will be
quite hard if they do not have pretty fancy systems.
But if they receive it from a peer, I am as good as lost in trying to
find the culprit.

Bas


From kilobit at gmail.com  Wed Feb  8 07:07:19 2012
From: kilobit at gmail.com (bas)
Date: Wed, 8 Feb 2012 14:07:19 +0100
Subject: UDP port 80 DDoS attack
In-Reply-To: <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
Message-ID: <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>

On Wed, Feb 8, 2012 at 9:29 AM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Feb 8, 2012, at 2:56 PM, bas wrote:
>
>> The big drawback with S/RTBH is that it is a DoS method in itself.
>
> I'm not an advocate of *automated* S/RTBH, and I am an advocate of whitelisting various well-known 'golden networks/IPs'

So I would need to find out which networks you would have classified
as "golden" and use those as sources for my DDoS.

Either I can achieve DoS with S/RTBH, or I can abuse the "golden
networks" to circumvent S/RTBH.

As far as I see it S/RTBH is in no way a solution against smart
attackers, of course it does help against all the kiddie attacks out
there.

Bas


From rdobbins at arbor.net  Wed Feb  8 07:15:37 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Wed, 8 Feb 2012 13:15:37 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
 <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
Message-ID: <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>

On Feb 8, 2012, at 8:07 PM, bas wrote:

> As far as I see it S/RTBH is in no way a solution against smart attackers, of course it does help against all the kiddie attacks out
> there.

Once again, I've used S/RTBH myself and helped others use it many, many times, including to defend against attacks with shifting purported source IPs.  flowspec, IDMS and other tools are very useful as well, but S/RTBH is supported on a lot of hardware, if operators choose to configure it.

It is not a panacea.  It is one tool in the toolbox.  

Folks can either choose to make use of it or choose not to do so; it is operationally proven, it does work, and it's certainly better than nothing.  YMMV.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From matt at mattreath.com  Wed Feb  8 08:25:18 2012
From: matt at mattreath.com (Matthew Reath)
Date: Wed, 8 Feb 2012 08:25:18 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
Message-ID: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>

> On Tue, Feb 7, 2012 at 4:35 PM, Matthew Reath <matt at mattreath.com> wrote:
>
>> > One of my customers has a list like that. They can't understand why
>> > one in every hundred or so TCP connections on port 443 fails.
>> >
>> > Hint: you forgot "access-list 102 permit tcp any any established"
>> > after "access-list 102 deny   ip host 255.255.255.255 any". The
>> > destination port in one direction is the source port in the other and
>> > many of those are dynamic source ports picked by Windows. Unless you
>> > restrict that filter to just packets attempting to initiate a new
>> > connection, you're shooting yourself in the foot.
>>
>> Yeah agreed.  The only place this gets applied is inbound on the
>> interface
>> facing an upstream provider. ACLs ingress from end customers are much
>> different. In theory this could cause issues with externally initiated
>> traffic that use lets say 8888 as its random source port.
>>
>
> If you apply the ACL you showed as an inbound ACL on your provider facing
> interfaces, you will be breaking any connections that exit your network
> with source ports from your list of bad ports.  For example, you connect
> out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
> into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
> dropped by your ACL.
>
> This seems to be a common mistake, and is often missed because it
> manifests
> as one-in-thousands failures of TCP connections.  People tend to just try
> a
> second time and it works and never investigate why they had one random
> failure.
>

Good point. Adding in an established entry, although may open you up for
TCP/SYN sort of packets is a better trade off than affecting customer
traffic.

-Matt



From morrowc.lists at gmail.com  Wed Feb  8 09:01:33 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 8 Feb 2012 10:01:33 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
Message-ID: <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>

On Wed, Feb 8, 2012 at 9:25 AM, Matthew Reath <matt at mattreath.com> wrote:

> Good point. Adding in an established entry, although may open you up for
> TCP/SYN sort of packets is a better trade off than affecting customer
> traffic.

'established' is explicitly NOT 'syn' ...
maybe you meant 'ack flood' ? (or rst flood? or .... but certainly not
syn flood)


From keegan.holley at sungard.com  Wed Feb  8 09:12:50 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:12:50 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
Message-ID: <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>

Providers don't even check the registries for bgp advertisements. See the thread on hijacked routes for proof.   Not to mention how do you handle a small transit AS?  Do you trust that they have the correct filters as well?  Do you start reading their AS paths and try to filter based on the registry for folks down stream?  Then there's the RLDRAM issue.  Most edge boxes will just run out if ACL's.  Lastly there's no contractual obligation to play traffic cop for the entire Internet so providers would be dropping traffic that they can legitimately bill for.

Sent from my iPhone

On Feb 8, 2012, at 4:56 AM, George Bonser <gbonser at seven.com> wrote:

>> No, we have registries to act as registries, the ISPs should be
>> checking them, and double checking.  It isn't something that is going
>> to change every day or every week. Once you get it set up, it is going
>> to be stable for a while.  Sure, it means a little more work in setting
>> up a customer, but it also means that if all your neighbors do the same
>> thing, you field many fewer calls dealing with stupid DoS crap.
>> 
> 
> I'll put it another way. Any provider that does not police their customer traffic has no business whining about DoS problems.
> 
> 


From keegan.holley at sungard.com  Wed Feb  8 09:18:29 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:18:29 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
Message-ID: <A8AD3365-BD70-48D8-86A1-1815EEA878C0@sungard.com>



On Feb 8, 2012, at 4:51 AM, George Bonser <gbonser at seven.com> wrote:

> 
> 
>> From: Keegan Holley 
>> Subject: Re: UDP port 80 DDoS attack
> 
>> It works in theory, but to get every ISP and hosting provider to ACL their edges and maintain those ACL's for every customer no matter how large might be a bit difficult.  
> 
> You don't have to ACL in most cases. RPF works for most.  There will be a few, relatively darned few, that you will need to ACL, but RPF takes care of a large number of them.
> 

RPF on the whole Internet would pretty much lead to an instant outage.  What happens when you have two upstreams and one has an incoming route to you but your out going route for which ever of their customers talking to you doesn't agree?  Instant outage.  Multiply that by the entire table and then add churn.  I'd give it a week before everyone turned it off,  if you could even get them to enable it to begin with.
 
> 
>> Also, what about non-BGP customers or customers that just accept a default route?  
> 
> I don't follow.  The ISP still knows what traffic gets routed TO them.  You only accept FROM them what you route TO them, even if you hand them a default route.
> 
> 
>> Or even customers that just want return traffic to come in a different link for some reason.
> 
> Still don't follow.  I am not talking about having a firewall that is stateful.  I am talking packet by packet.  If you don't route it to them, you don't accept it from them unless you have made arrangements otherwise, which will be a small percentage of your customers. Sure, some might be multihomed but it is easy enough to verify that they have the networks in question SWIPed to them or a call to the other provider can clear that up in a few minutes.  It isn't THAT hard.
> 
> 
>> ISP's would suddenly become giant traffic registries.
> 
> 
> No, we have registries to act as registries, the ISPs should be checking them, and double checking.  It isn't something that is going to change every day or every week. Once you get it set up, it is going to be stable for a while.  Sure, it means a little more work in setting up a customer, but it also means that if all your neighbors do the same thing, you field many fewer calls dealing with stupid DoS crap.
> 
> 


From morrowc.lists at gmail.com  Wed Feb  8 09:33:49 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Wed, 8 Feb 2012 10:33:49 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
Message-ID: <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>

On Wed, Feb 8, 2012 at 10:12 AM, Keegan Holley
<keegan.holley at sungard.com> wrote:
> Providers don't even check the registries for bgp advertisements. See the thread on hijacked routes for proof. ? Not to mention how do you handle a small transit AS? ?Do you trust that they

to be fair: "Some Providers do not check registries for 'right to use'
information about prefixes their customers wish to announce to them
over BGP."


From ariev at vayner.net  Wed Feb  8 09:28:24 2012
From: ariev at vayner.net (Arie Vayner)
Date: Wed, 8 Feb 2012 17:28:24 +0200
Subject: [c-nsp] ASR opinions..
In-Reply-To: <201202011150.48562.mtinka@globaltransit.net>
References: <COL111-W278BAD1227E170E373779DDA2C0@phx.gbl>
 <201109021756.56518.mtinka@globaltransit.net>
 <CAOMUSPY+F0ens+7sHDOFMJpJdBiVdVn0t6fYTF7RHGPKaSB_Dw@mail.gmail.com>
 <201202011150.48562.mtinka@globaltransit.net>
Message-ID: <CAP9danc2E3pFzHtcSYfZqisq-GVQjo55WJR7qy-2M+i07mCTQA@mail.gmail.com>

Mark,

I made sure with the BU, and they confirmed that ASR1001 with 8GB RAM can
handle 1M routes per the data sheet.
The difference between ASR1001 and ASR1002 with EFP5 is due to a more
powerful integrated RP on ASR1001 (Not really RP2, but closer to RP2 than
RP1) and more memory (4GB is max on RP1)

Arie

On Wed, Feb 1, 2012 at 5:50 AM, Mark Tinka <mtinka at globaltransit.net> wrote:

> On Tuesday, January 31, 2012 06:38:10 AM Christopher J.
> Pilkington wrote:
>
> > Does anyone have a link to a definitive document clearly
> > showing FIB numbers for the ASR1001?  I've got an email
> > into our Cisco SE, but I don't think they're motivated
> > to sell us a lower-end box. :-)
>
> On that link, Tables 1 and 3 contradict each other re: the
> ASR1001.
>
> However, I confirmed with our SE, and he says no way the
> ASR1001 supports anything more than 512,000 v4 entries and
> 128,000 v6 entries (which is Table 3).
>
> Maybe someone on the list from Cisco can help fix the
> documentation.
>
> Mark.
>

From keegan.holley at sungard.com  Wed Feb  8 09:53:16 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 10:53:16 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <367B263E-3E18-48C6-829F-1F8C84FFFAEF@arbor.net>
 <CAEs2ZiJAP6gMZVE6XY_xb+cCD26e6hA1rHY19T-Rby8zFbg8Xw@mail.gmail.com>
 <57E4018B-5E7E-4F0E-97E5-C8220A99ACD1@arbor.net>
Message-ID: <CABO8Q6Qrp3qrbWk0KO+TqA=M63sYUXcT2rijm0DS-bHxSsLcKA@mail.gmail.com>

2012/2/8 Dobbins, Roland <rdobbins at arbor.net>

> On Feb 8, 2012, at 8:07 PM, bas wrote:
>
> > As far as I see it S/RTBH is in no way a solution against smart
> attackers, of course it does help against all the kiddie attacks out
> > there.
>
> Once again, I've used S/RTBH myself and helped others use it many, many
> times, including to defend against attacks with shifting purported source
> IPs.  flowspec, IDMS and other tools are very useful as well, but S/RTBH is
> supported on a lot of hardware, if operators choose to configure it.
>
> It is not a panacea.  It is one tool in the toolbox.
>
> Folks can either choose to make use of it or choose not to do so; it is
> operationally proven, it does work, and it's certainly better than nothing.
>  YMMV.
>
>
I agree.  I think RTBH is a broadsword not a scalpel.  It's a tool in the
tool box and there is a danger of dropping legitimate traffic with both
S/RTBH and D/RTBH.  BGP isn't a security protocol.  It's not even that
great of a routing protocol.

From twilde at cymru.com  Wed Feb  8 10:55:48 2012
From: twilde at cymru.com (Tim Wilde)
Date: Wed, 08 Feb 2012 11:55:48 -0500
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <4F32A914.7060304@cymru.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/7/2012 10:20 PM, Ryan Rawdon wrote:
> Assuming it is not a futile/wasted effort, where is the current
> best place/resource to report an active botnet C&C to?

Team Cymru is always happy to hear about C&Cs, your best bet for
sending to us is to use support at cymru.com.

Thanks,
Tim Wilde

- -- 
Tim Wilde, Software Engineer, Team Cymru, Inc.
twilde at cymru.com | +1-847-378-3333 | http://www.team-cymru.org/
-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAk8yqRQACgkQluRbRini9tiX9ACeOLiCon9Hz8TQ8MOdTbL5Jbvx
Tl0AmgMu135iJScJwbx3kxbwMaqWuaBm
=Hldr
-----END PGP SIGNATURE-----


From ktokash at hotmail.com  Wed Feb  8 10:59:23 2012
From: ktokash at hotmail.com (keith tokash)
Date: Wed, 8 Feb 2012 08:59:23 -0800
Subject: IPv6 explicit BGP group configs
Message-ID: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>


Hi,

I'm prepping an environment for v6 and I'm wondering what, if
 any, benefit there is to splitting v4 and v6 into separate groups.  
We're running Junipers and things are fairly neat and ordered; we have 
multiple links to a few providers in many sites, so we group them and 
apply the policies at the group level.  We could stick the new v6 
neighbors into the same group and apply the policies at the neighbor 
level, or create new groups (i.e. Level3 and Level3v6).

This 
might sound a little nit-picky, but I'm concerned that there's a nuance 
I'm not thinking of right now and I don't want to be "that guy" who puts
 something in place and is cursed for a decade.

Thanks,
Keith Tokash 		 	   		  

From bicknell at ufp.org  Wed Feb  8 11:25:19 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Feb 2012 09:25:19 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <20120208172519.GA62714@ussenterprise.ufp.org>

In a message written on Wed, Feb 08, 2012 at 08:59:23AM -0800, keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).

I'm going to answer with a very specific bit of administriva, but
I think it illustrates the sort of thing you want to think about.

When adding a BGP address family like IPv6 it can be done by sending
the routes down an existing BGP session (e.g. IPv4 transport carrying
IPv4 and IPv6 routes), or by having two sessions, an IPv4 transport
with IPv4 routes, and an IPv6 transport with IPv6 routes.

Most ISP's do the latter.   There are a pile of reasons, but here's
one of the easiest.  Imagine a world in the future where we are
removing IPv4 from the network as we're now IPv6 only.  If one
transport was used, it must now be torn down and rebuilt over IPv6,
causing an outage for everything and a lot of work for your engineers.
If you used two transports, you can remove the IPv4 and the IPv6
keeps working just fine.

Lather, rince, reapply to everything you can do on routers.  How you
group config statements, how you write your management tools, and so on.
I would generally advise, where possible, to treat them like ships in
the night.  Keep them in separate areas.  It allows you to add IPv6
without disturbing IPv4, and some day will allow you to remove IPv4
without disturbing IPv6.

YMMV.  Batteries not included.  Not all vendors support all features.
No warranty expressed or implied.  Do not taunt happy fun ball.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120208/41f43e3e/attachment.bin>

From Grzegorz at Janoszka.pl  Wed Feb  8 11:33:17 2012
From: Grzegorz at Janoszka.pl (Grzegorz Janoszka)
Date: Wed, 08 Feb 2012 18:33:17 +0100
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <4F32B1DD.10502@Janoszka.pl>

On 08-02-12 17:59, keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).

Sometimes we have the same group for v4 and v6, but in most cases we
have different ones. One of the basic reasons is different max-pref setting.

Most policies can be used in two address families, you can also match
prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
policies you have to have at least two terms - one for v4 prefixes, one
for v6 prefixes.

-- 
Grzegorz Janoszka


From joelja at bogus.com  Wed Feb  8 11:36:50 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 08 Feb 2012 09:36:50 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
Message-ID: <4F32B2B2.1090407@bogus.com>

On 2/8/12 08:59 , keith tokash wrote:
> 
> Hi,

I've done it either way, I prefer to put the v6 peers in a different
group  than the v4 peers so that I can group the policies at the group
rather than neighbor level.

> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.  
> We're running Junipers and things are fairly neat and ordered; we have 
> multiple links to a few providers in many sites, so we group them and 
> apply the policies at the group level.  We could stick the new v6 
> neighbors into the same group and apply the policies at the neighbor 
> level, or create new groups (i.e. Level3 and Level3v6).
> 
> This 
> might sound a little nit-picky, but I'm concerned that there's a nuance 
> I'm not thinking of right now and I don't want to be "that guy" who puts
>  something in place and is cursed for a decade.
> 
> Thanks,
> Keith Tokash 		 	   		  
> 



From bicknell at ufp.org  Wed Feb  8 11:58:21 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 8 Feb 2012 09:58:21 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <4F32B1DD.10502@Janoszka.pl>
References: <COL103-W2405E59FCEA3D3AEA3283AAE7A0@phx.gbl>
 <4F32B1DD.10502@Janoszka.pl>
Message-ID: <20120208175821.GA64216@ussenterprise.ufp.org>

In a message written on Wed, Feb 08, 2012 at 06:33:17PM +0100, Grzegorz Janoszka wrote:
> Most policies can be used in two address families, you can also match
> prefixes, but you cannot have v4 and v6 prefixes in one term. So in your
> policies you have to have at least two terms - one for v4 prefixes, one
> for v6 prefixes.

Another thing IOS-XR fixes!

route-policy my-example
  if destination in my-ipv4-prefix-list or destination in my-ipv6-prefix-list then
    set community 1234
    set med 0
    done
  endif
end-policy

In 99.99% of the cases it allows you to have one policy for both IPv4
and IPv6, and add the parameter passing I discussed the other day and
it's almost like something was thinking of routing engineers when they
wrote it. :P

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120208/7a4ad2b5/attachment.bin>

From gbonser at seven.com  Wed Feb  8 12:26:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 18:26:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>

> 77% of all networks seem to think so.
> http://spoofer.csail.mit.edu/summary.php

And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.

> However the remaining networks allow spoofed traffic to egress their
> networks.
> 
> When that traffic enters my network, I have no method whatsoever to
> differentiate it from any other traffic.

I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.

> I could ask my upstream where they see it coming from, which will be
> quite hard if they do not have pretty fancy systems.

At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.


> But if they receive it from a peer, I am as good as lost in trying to
> find the culprit.

Agreed.  That's why it is important to stop it at the source.

> Bas


From keegan.holley at sungard.com  Wed Feb  8 12:42:48 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Wed, 8 Feb 2012 13:42:48 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
Message-ID: <CABO8Q6QN+9TFNMRJOnt8JHJRGyQNdJ2Qyvso+RmopQe9cnGKXw@mail.gmail.com>

2012/2/8 George Bonser <gbonser at seven.com>

> > 77% of all networks seem to think so.
> > http://spoofer.csail.mit.edu/summary.php
>
> And it would be the remaining 23% that really need to understand how
> difficult they are making life for the rest of the Internet.
>

23% of 4.29 billion addresses is still more than enough to ruin anyone's
day.

From Sandra.Murphy at sparta.com  Wed Feb  8 12:49:27 2012
From: Sandra.Murphy at sparta.com (Murphy, Sandra)
Date: Wed, 8 Feb 2012 18:49:27 +0000
Subject: remote participation - IETF sidr wg interim meeting
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6086E96@Hermes.columbia.ads.sparta.com>

A WebEx session has been arranged for remote participation in the interim sidr meeting Thu 9 Mar.

Below is the WebEx announcement of the meeting.

--Sandy

=======================================================
The IETF SIDR co-chairs invite you to attend this online meeting. 
Topic: IETF WebEx 
Date: Thursday, February 9, 2012 
Time: 9:00 am, Pacific Standard Time (San Francisco, GMT-08:00) 
Meeting Number: 969 770 530 
Meeting Password: (This meeting does not require a password.) 

------------------------------------------------------- 
To join the online meeting (Now from mobile devices!) 
------------------------------------------------------- 
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&RT=MiM0 
2. If requested, enter your name and email address. 
3. If a password is required, enter the meeting password: (This meeting does not require a password.) 
4. Click "Join". 
To view in other time zones or languages, please click the link: 
https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&ORT=MiM0 

------------------------------------------------------- 
To join the audio conference only 
------------------------------------------------------- 
To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. 
Call-in toll-free number (US/Canada): 1-877-668-4490 
Call-in toll number (US/Canada): 1-408-792-6300 
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC&ED=190625237&tollFree=1 
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 
Access code:969 770 530 

------------------------------------------------------- 
For assistance 
------------------------------------------------------- 
1. Go to https://workgreen.webex.com/workgreen/mc 
2. On the left navigation bar, click "Support". 

You can contact support at: 
amorris at amsl.com 
1-510-492-4081 

To add this meeting to your calendar program (for example Microsoft Outlook), click this link: 
https://workgreen.webex.com/workgreen/j.php?ED=190625237&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=ANsxg25yn/5HHE9KPUeXZtnbWAMNqdqowJxTiz7JHE8=&RT=MiM0 

The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php. 

Sign up for a free trial of WebEx 
http://www.webex.com/go/mcemfreetrial 
http://www.webex.com 

CCP:+14087926300x969770530# 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. 

From nicolai-nanog at chocolatine.org  Wed Feb  8 13:04:33 2012
From: nicolai-nanog at chocolatine.org (Nicolai)
Date: Wed, 8 Feb 2012 13:04:33 -0600
Subject: report botnet C&C?
In-Reply-To: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
Message-ID: <20120208190433.GA19246@vectra.student.iastate.edu>

On Tue, Feb 07, 2012 at 10:20:07PM -0500, Ryan Rawdon wrote:
> Assuming it is not a futile/wasted effort, where is the current best
> place/resource to report an active botnet C&C to?

I don't know if there's a single best option, but there are several good
ones.  In addition to Cymru I'd mention abuse.ch, which runs several
public botnet C&C trackers.

 http://www.abuse.ch

Nicolai


From drew.weaver at thenap.com  Wed Feb  8 13:23:27 2012
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 8 Feb 2012 14:23:27 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
Message-ID: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>

Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)

-Drew


-----Original Message-----
From: George Bonser [mailto:gbonser at seven.com] 
Sent: Wednesday, February 08, 2012 1:27 PM
To: bas; nanog
Subject: RE: UDP port 80 DDoS attack

> 77% of all networks seem to think so.
> http://spoofer.csail.mit.edu/summary.php

And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.

> However the remaining networks allow spoofed traffic to egress their 
> networks.
> 
> When that traffic enters my network, I have no method whatsoever to 
> differentiate it from any other traffic.

I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.

> I could ask my upstream where they see it coming from, which will be 
> quite hard if they do not have pretty fancy systems.

At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.


> But if they receive it from a peer, I am as good as lost in trying to 
> find the culprit.

Agreed.  That's why it is important to stop it at the source.

> Bas



From drew.weaver at thenap.com  Wed Feb  8 13:27:20 2012
From: drew.weaver at thenap.com (Drew Weaver)
Date: Wed, 8 Feb 2012 14:27:20 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <273be36298d3b47f04ef10bab7c38112@imap>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <273be36298d3b47f04ef10bab7c38112@imap>
Message-ID: <F3318834F1F89D46857972DD4B411D70052CA02412@exchange>

Hi,

Just a general note on the UDP 80 style DoS attacks.

I'm not entirely certain that UDP 80 attacks are always related to the gameserver bug that you're citing below.

We have seen in the wild php scripts that are hard coded to use UDP 80 to deliver DoS attacks towards their targets.

Basically it's just GET /script.php?ip.of.victim and instant UDP 80 flood, I've also seen perl versions of the same script.. most notably UDP.PL

What would be interesting is to see just how much UDP 80 traffic exists on the Internet at any given moment.

I don't know if Arbor's ATLAS really tracks traffic in that way but it would be interesting to get a semi-global view of just how many PPS/BPS are being wasted on these types of floods.

Maybe even as a research paper =)

-Drew


-----Original Message-----
From: Fredrik Holmqvist / I2B [mailto:fredrik at i2b.se] 
Sent: Sunday, February 05, 2012 6:47 PM
To: nanog at nanog.org
Subject: Re: UDP port 80 DDoS attack

Hi.

We had a customer that was attacked by the same "game server feature".
We received aprox 10 Gbit of traffic against the customer.

The attacker sends spoofed packets to the game server with the target IP as "source", the gameserver sends replies back via UDP to the target host. The attacker sends a couple of hundred packets per second and thus generating a 10 Mbit UDP flood.

There is fixes/workarounds for the game servers, just a matter of the admin taking care of it.
See: http://rankgamehosting.ru/index.php?showtopic=1320

The "attacking" IPs aren't spoofed, so just compile a list and send e-mails to each provider.

We had 1000+ IPs gathered and sent 100+ abuse e-mails, only received reply from less than 20%.
Sad that people care so little about mitigating DDoS/UDP/ICMP floods.


On Sun, 5 Feb 2012 18:36:13 -0500, Ray Gasnick III <rgasnick at milestechnologies.com> wrote:
> We just saw a huge flux of traffic occur this morning that spiked one 
> of our upstream ISPs gear and killed the layer 2 link on another 
> becuase of a DDoS attack on UDP port 80.
> 
> 
> 
> Wireshark shows this appears to be from a compromised game server 
> (call of duty) with source IPs in a variety of different prefixes.
> 
> 
> 
> Only solution thus far was to dump the victim IP address in our block 
> into the BGP Black hole community with one of our 2 providers and 
> completely stop advertising to the other.
> 
> 
> 
> Anybody see this recently and have any tips on mitigation,  reply on 
> or off list.
> 
> 
> 
> Thank You,
> 
> Ray Gasnick III
> CISSP, Technology Specialist: Network Security & Infrastructure Miles 
> Technologies 
> www.milestechnologies.com<http://www.milestechnologies.com/>
> 
> Phone: (856) 439-0999 x127
> Direct: (856) 793-3821
> How am I doing?  Email my manager at
> itmanager at milestechnologies.com<mailto:itmanager at milestechnologies.com
> >
> 
> Computer Networking ? IT Support ? Business Software ? Website Design 
> ? Online Marketing & PR

--
Fredrik Holmqvist
I2B (Internet 2 Business)
070-740 5033



From matt at mattreath.com  Wed Feb  8 13:28:41 2012
From: matt at mattreath.com (Matthew Reath)
Date: Wed, 8 Feb 2012 13:28:41 -0600
Subject: Firewalls in service provider environments
In-Reply-To: <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
 <CAL9jLaZ_VrKhT0V4k85qFN7jRkcDDcwYj_e4+HsvE9f7ee-pzw@mail.gmail.com>
Message-ID: <eaa0923a170c9499a91402401253e064.squirrel@mail.mattreath.com>

> On Wed, Feb 8, 2012 at 9:25 AM, Matthew Reath <matt at mattreath.com> wrote:
>
>> Good point. Adding in an established entry, although may open you up for
>> TCP/SYN sort of packets is a better trade off than affecting customer
>> traffic.
>
> 'established' is explicitly NOT 'syn' ...
> maybe you meant 'ack flood' ? (or rst flood? or .... but certainly not
> syn flood)
>

If I had an 'established' entry on an inbound ACL to filter traffic coming
from my upstream provider wouldn't SYN ACK (2nd step in handshake) packets
be allowed to pass the ACL because of this?

But I see your point a connection initiation from external sources with
just the SYN flag set would not be allowed.  However if a session is
initiated internally the returning SYN ACK from the external server would
be allowed as would ACK and data packets with ACK set.





From gbonser at seven.com  Wed Feb  8 13:50:42 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 8 Feb 2012 19:50:42 +0000
Subject: UDP port 80 DDoS attack
In-Reply-To: <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
 <CAL9jLaYVq8_97KxUzg-FoW+jaD_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: christopher.morrow
> 
> to be fair: "Some Providers do not check registries for 'right to use'
> information about prefixes their customers wish to announce to them
> over BGP."

Maybe not but I would think that in practice it would be something like:

1. Provider initially filters traffic based on the address range they have issued to the customer.
2. If the customer brings their own IP addresses, the provider does a quick check to see if those have been SWIPed to the customer
3. If the customer wants the filtration opened up to include additional IPs, the do the same as #2
4. If the customer has no record of having control of those IPs, a quick call to the listed assignee of those numbers would verify that the customer is mutual and is properly sourcing traffic in that IP range and filters are adjusted accordingly. 

In about 99% of cases that would be the end of the story and everything runs merrily along after that.  Sure, there are going to be corner cases but if someone starts playing whack-a-mole with IP address assignments and is asking for frequent changes, that might be a tip-off that they might be trouble.

It *does* involve maintaining some record of the configuration settings someplace in case of equipment changes/failures, etc. but that would be a small price to pay for reducing the amount of time spent chasing DoS complaints.  It has to be a community effort with a set of best practices developed and applied by the community.  


From me at anuragbhatia.com  Wed Feb  8 13:51:17 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 01:21:17 +0530
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
Message-ID: <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>

Nice explanation!


Thanks Mike.

Appreciate it.

On Thu, Feb 2, 2012 at 6:08 AM, Mike Jones <mike at mikejones.in> wrote:

> On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
> <snip>
> > Now my question here is - why this setup and not simply using having a A
> > record for googlehosted.l.googleusercontent.com. which comes from any
> > anycasted IP address space? Why not anycasting at CDN itself rather then
> > only at DNS layer?
>
> You are confusing anycasting with offering different results.
>
> I can have an anycast DNS setup where all my servers give the same
> response (example: most DNS providers), I can also have a single DNS
> server give 192.0.2.80 out to queries sourced from a US IP Address,
> 198.51.100.80 for queries sourced from a German IP Address and
> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
> module for this for example).
>
> I would guess that google probably have a highly customised algorithm
> which uses a combination of source IP and the node that your query
> arrived at as part of the process for deciding what answer to give
> you, along with dozens of other internal factors.
>
> Although I do sometimes wonder why they use CNAME chains in cases
> where the same servers are authoritative for the target name anyway.
>
> If you were wondering why they direct you to the unicast addresses for
> the local datacentre instead of just giving an anycast address which
> your nearest datacentre would answer, well their algorithm might
> decide that it wants to serve you content from the second closest
> datacentre because the closest one is near capacity, anycast can't do
> that.
>
> - Mike
>



-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From me at anuragbhatia.com  Wed Feb  8 13:58:07 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 01:28:07 +0530
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
Message-ID: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>

Mike

 I can also have a single DNS
> server give 192.0.2.80 out to queries sourced from a US IP Address,
> 198.51.100.80 for queries sourced from a German IP Address and
> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
> module for this for example).


I have never did such setup, but I assume it works as you say. I wonder how
it finds a US based system from IP quickly (since it's DNS server)?


Thanks.
On Thu, Feb 9, 2012 at 1:21 AM, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Nice explanation!
>
>
> Thanks Mike.
>
> Appreciate it.
>
> On Thu, Feb 2, 2012 at 6:08 AM, Mike Jones <mike at mikejones.in> wrote:
>
>> On 1 February 2012 20:25, Anurag Bhatia <me at anuragbhatia.com> wrote:
>> <snip>
>> > Now my question here is - why this setup and not simply using having a A
>> > record for googlehosted.l.googleusercontent.com. which comes from any
>> > anycasted IP address space? Why not anycasting at CDN itself rather then
>> > only at DNS layer?
>>
>> You are confusing anycasting with offering different results.
>>
>> I can have an anycast DNS setup where all my servers give the same
>> response (example: most DNS providers), I can also have a single DNS
>> server give 192.0.2.80 out to queries sourced from a US IP Address,
>> 198.51.100.80 for queries sourced from a German IP Address and
>> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
>> module for this for example).
>>
>> I would guess that google probably have a highly customised algorithm
>> which uses a combination of source IP and the node that your query
>> arrived at as part of the process for deciding what answer to give
>> you, along with dozens of other internal factors.
>>
>> Although I do sometimes wonder why they use CNAME chains in cases
>> where the same servers are authoritative for the target name anyway.
>>
>> If you were wondering why they direct you to the unicast addresses for
>> the local datacentre instead of just giving an anycast address which
>> your nearest datacentre would answer, well their algorithm might
>> decide that it wants to serve you content from the second closest
>> datacentre because the closest one is near capacity, anycast can't do
>> that.
>>
>> - Mike
>>
>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
> Linkedin: http://linkedin.anuragbhatia.com
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From brett at the-watsons.org  Wed Feb  8 14:04:22 2012
From: brett at the-watsons.org (Brett Watson)
Date: Wed, 8 Feb 2012 12:04:22 -0800
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
 <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
Message-ID: <A6F55B28-8153-48C0-82A9-8CF13BE0BDD9@the-watsons.org>


On Feb 8, 2012, at 11:58 AM, Anurag Bhatia wrote:

> Mike
> 
> I can also have a single DNS
>> server give 192.0.2.80 out to queries sourced from a US IP Address,
>> 198.51.100.80 for queries sourced from a German IP Address and
>> 203.0.113.80 to queries sourced from a Chinese address (djbdns has a
>> module for this for example).
> 
> 
> I have never did such setup, but I assume it works as you say. I wonder how
> it finds a US based system from IP quickly (since it's DNS server)?

Here is *one* method if you obtain a feed of geo-ip data from someone like Maxmind:

http://phix.me/geodns/


Several DNS providers have different methods and different geo-ip data vendors.

-b

From nanog-post at rsuc.gweep.net  Wed Feb  8 14:07:30 2012
From: nanog-post at rsuc.gweep.net (Joe Provo)
Date: Wed, 8 Feb 2012 15:07:30 -0500
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
 <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
Message-ID: <20120208200730.GA12862@gweep.net>

On Thu, Feb 09, 2012 at 01:28:07AM +0530, Anurag Bhatia wrote:
[snip]
> I have never did such setup, but I assume it works as you say. I wonder how
> it finds a US based system from IP quickly (since it's DNS server)?
 

Drop "ip geolocation" or "internet geolocation" into Your Favorite 
Search Engine. Short answer is some folks just refer to databases
published/generated by others, some folks use DNS guesses, and some
folks measure packet arrival. And most often, there is a combination 
of methods used.

-- 
         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG


From mpetach at netflight.com  Wed Feb  8 14:46:33 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Wed, 8 Feb 2012 12:46:33 -0800
Subject: 2012.02.08 NANOG54 day 3 morning session notes
Message-ID: <CAEmG1=odct+tn66dX7AF0-YE0WZp3BVvQpGeXgtoGNLG-uPHeQ@mail.gmail.com>

I've posted my notes from this morning's session
at

http://kestrel3.netflight.com/2012.02.08-nanog54-morning-session.txt

I wonder if perhaps we don't keep asking for NEBS
compliance just because we don't have another
easy acronym to put on the RFQs that represents
what *our* industry needs, vs the telco industry?

Thanks again for another awesome NANOG!

Matt


From jra at baylink.com  Wed Feb  8 15:16:33 2012
From: jra at baylink.com (Jay Ashworth)
Date: Wed, 8 Feb 2012 16:16:33 -0500 (EST)
Subject: 2012.02.08 NANOG54 day 3 morning session notes
In-Reply-To: <CAEmG1=odct+tn66dX7AF0-YE0WZp3BVvQpGeXgtoGNLG-uPHeQ@mail.gmail.com>
Message-ID: <18674615.1407.1328735793144.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Matthew Petach" <mpetach at netflight.com>

> I've posted my notes from this morning's session
> at
> 
> http://kestrel3.netflight.com/2012.02.08-nanog54-morning-session.txt
> 
> I wonder if perhaps we don't keep asking for NEBS
> compliance just because we don't have another
> easy acronym to put on the RFQs that represents
> what *our* industry needs, vs the telco industry?

Well, there is a difference between NEBS Compliant (which lots of people
make, and lots can use) and NEBS Certified (which entails paying money to
Telcordia, I think, and probably requires 23" racking, which most of us
don't care about...

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


From henry at AegisInfoSys.com  Wed Feb  8 15:23:35 2012
From: henry at AegisInfoSys.com (Henry Yen)
Date: Wed, 8 Feb 2012 16:23:35 -0500
Subject: Firewalls in service provider environments
In-Reply-To: <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
Message-ID: <20120208212335.GX3627@nntp.AegisInfoSys.com>

On Wed, Feb 08, 2012 at 08:25:18AM -0600, Matthew Reath wrote:
> > If you apply the ACL you showed as an inbound ACL on your provider facing
> > interfaces, you will be breaking any connections that exit your network
> > with source ports from your list of bad ports.  For example, you connect
> > out from x.x.x.x:8888 to y.y.y.y:80, then the response packets coming back
> > into your network will be from y.y.y.y:80 to x.x.x.x:8888 and will be
> > dropped by your ACL.

> Good point. Adding in an established entry, although may open you up for
> TCP/SYN sort of packets is a better trade off than affecting customer
> traffic.

I've always thought that reflexive access lists were quite elegant,
and a much better method than established, albeit for edge networks.

Do they not work in the SP space?

--
Henry Yen                                       Aegis Information Systems, Inc.
Senior Systems Programmer                       Hicksville, New York


From marka at isc.org  Wed Feb  8 16:14:22 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 09 Feb 2012 09:14:22 +1100
Subject: UDP port 80 DDoS attack
In-Reply-To: Your message of "Wed, 08 Feb 2012 19:50:42 -0000."
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6TFRhXY-aLB4URW6e-iUu8Wd1z2RidOsUzr8+QrQkqmvw@mail.gmail.com>
 <3CFD7DF4-2396-4168-9B0F-9F70783CA3F4@arbor.net>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <21C0E0A6-99FB-4385-9355-629BDB5ECD9B@sungard.com>
 <CAL9jLaYVq8_97KxUzg-FoW+ja
 D_cS43Mf3r1LjOASAJgyCaF6A@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561@RWC-MBX1.corp.seven.com>
Message-ID: <20120208221422.D2EB31D05153@drugs.dv.isc.org>


In message <596B74B410EE6B4CA8A30C3AF1A155EA09CBE561 at RWC-MBX1.corp.seven.com>, G
eorge Bonser writes:
> 
> 
> > -----Original Message-----
> > From: christopher.morrow
> >=20
> > to be fair: "Some Providers do not check registries for 'right to use'
> > information about prefixes their customers wish to announce to them
> > over BGP."
> 
> Maybe not but I would think that in practice it would be something like:
> 
> 1. Provider initially filters traffic based on the address range they have =
> issued to the customer.
> 2. If the customer brings their own IP addresses, the provider does a quick=
>  check to see if those have been SWIPed to the customer
> 3. If the customer wants the filtration opened up to include additional IPs=
> , the do the same as #2
> 4. If the customer has no record of having control of those IPs, a quick ca=
> ll to the listed assignee of those numbers would verify that the customer i=
> s mutual and is properly sourcing traffic in that IP range and filters are =
> adjusted accordingly.=20
> 
> In about 99% of cases that would be the end of the story and everything run=
> s merrily along after that.  Sure, there are going to be corner cases but i=
> f someone starts playing whack-a-mole with IP address assignments and is as=
> king for frequent changes, that might be a tip-off that they might be troub=
> le.
> 
> It *does* involve maintaining some record of the configuration settings som=
> eplace in case of equipment changes/failures, etc. but that would be a smal=
> l price to pay for reducing the amount of time spent chasing DoS complaints=
> .  It has to be a community effort with a set of best practices developed a=
> nd applied by the community. =20

And with cryptographically signed assignments this can be completely
automated.  Tie the DHCPv6 server into the RPKI system and DHCPv6
PD can do the right stuff so that the other ISP serving the customer
can know that these address are legal from the customer.

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


From cra at WPI.EDU  Wed Feb  8 17:41:41 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 8 Feb 2012 18:41:41 -0500
Subject: RoadRunner/Adelphia AS14065 contact
In-Reply-To: <4F0DEDA5.7070000@gmail.com>
References: <4F0DEDA5.7070000@gmail.com>
Message-ID: <20120208234141.GZ5968@angus.ind.WPI.EDU>

On Wed, Jan 11, 2012 at 12:14:29PM -0800, chk wrote:
> If there is a Roadrunner contact monitoring the list can you please  
> contact me off list regarding a routing issue from ns1/2.adelphia.net

Did you ever get any response?  I'm having a similar issue:

For the past couple months, we have been unable to query the
authoritative DNS servers for adelphia.net on IP addresses
75.180.129.58 and 75.180.129.59 from our campus network IP block
130.215.0.0/16, using either TCP or UDP:

>dig +short +norec @75.180.129.58 adelphia.net. mx
;; connection timed out; no servers could be reached

>dig +short +norec @75.180.129.59 adelphia.net. mx
;; connection timed out; no servers could be reached

>dig +tcp +short +norec @75.180.129.58 adelphia.net. mx
;; communications error to 75.180.129.58#53: end of file

>dig +tcp +short +norec @75.180.129.59 adelphia.net. mx
;; communications error to 75.180.129.59#53: end of file

This is causing email failures to anyone with an @adelphia.net email
address.

I can ping the DNS servers from 130.215.0.0/16:

>ping  -c3 75.180.129.58 
PING 75.180.129.58 (75.180.129.58) 56(84) bytes of data.
64 bytes from 75.180.129.58: icmp_req=1 ttl=241 time=26.9 ms
64 bytes from 75.180.129.58: icmp_req=2 ttl=241 time=26.7 ms
64 bytes from 75.180.129.58: icmp_req=3 ttl=241 time=26.7 ms

--- 75.180.129.58 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 26.711/26.797/26.953/0.110 ms

>ping -c3 75.180.129.59
PING 75.180.129.59 (75.180.129.59) 56(84) bytes of data.
64 bytes from 75.180.129.59: icmp_req=1 ttl=241 time=25.9 ms
64 bytes from 75.180.129.59: icmp_req=2 ttl=241 time=26.1 ms
64 bytes from 75.180.129.59: icmp_req=3 ttl=241 time=25.5 ms

--- 75.180.129.59 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 25.523/25.871/26.120/0.285 ms

And I can make a TCP port 53 connection which gets immediately closed:

>telnet 75.180.129.58 53
Trying 75.180.129.58...
Connected to 75.180.129.58.
Escape character is '^]'.
Connection closed by foreign host.

>telnet 75.180.129.59 53
Trying 75.180.129.59...
Connected to 75.180.129.59.
Escape character is '^]'.
Connection closed by foreign host.

It is acting as if there is an ACL or firewall rule that is blocking
130.215.0.0/16 from accessing DNS port 53 on the DNS servers at
75.180.129.58 and 75.180.129.59.

I've already ruled out any firewalls on our end, as well as any
routing issues.  I can see the UDP port 53 packets going out, but
there is no reply.  I can see the 3-way TCP port 53 handshake packets
going out and coming in, but the other end closes the connection
immediately.

If I use a non-130.215.0.0/16 source IP from my router, I get a normal
response via both UDP and TCP:

% dig -b 207.210.142.142 +short +norec @75.180.129.58 adelphia.net. mx
10 cdptpa-smtpin01.mail.rr.com.
20 cdptpa-smtpin02.mail.rr.com.

% dig -b 207.210.142.142 +short +tcp +norec @75.180.129.58 adelphia.net. mx
10 cdptpa-smtpin01.mail.rr.com.
20 cdptpa-smtpin02.mail.rr.com.

I'd appreciate if someone could help me find a clueful contact at
TW/RoadRunner/Adelphia/Comcast/whoever they are now.  I've tried all
the contacts in WHOIS for adelphia.net, the IP block, and ASN.  I've
tried the NOC List on puck.nether.net--no matches.

Thanks,
Chuck


From johnl at iecc.com  Wed Feb  8 20:03:30 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 02:03:30 -0000
Subject: Slow IN-ADDR.ARPA responses
Message-ID: <20120209020330.6513.qmail@joyce.lan>

I'm seeing surprisingly slow responses from some of the IN-ADDR
servers, like 300ms or more.  Are they being attacked by script
kiddies of something?

R's,
John



From markk at arin.net  Wed Feb  8 20:23:59 2012
From: markk at arin.net (Mark Kosters)
Date: Thu, 9 Feb 2012 02:23:59 +0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209020330.6513.qmail@joyce.lan>
Message-ID: <CB589765.59670%markk@arin.net>

Hi John

I checked the traffic graphs for the server we operate
(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
of any report of issues with the other operators.

Regards,
Mark

On 2/8/12 9:03 PM, "John Levine" <johnl at iecc.com> wrote:

>I'm seeing surprisingly slow responses from some of the IN-ADDR
>servers, like 300ms or more.  Are they being attacked by script
>kiddies of something?
>
>R's,
>John
>
>



From marka at isc.org  Wed Feb  8 20:37:23 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 09 Feb 2012 13:37:23 +1100
Subject: RoadRunner/Adelphia AS14065 contact
In-Reply-To: Your message of "Wed, 08 Feb 2012 18:41:41 CDT."
 <20120208234141.GZ5968@angus.ind.WPI.EDU>
References: <4F0DEDA5.7070000@gmail.com>
 <20120208234141.GZ5968@angus.ind.WPI.EDU>
Message-ID: <20120209023723.1C36B1D076A4@drugs.dv.isc.org>


In message <20120208234141.GZ5968 at angus.ind.WPI.EDU>, Chuck Anderson writes:
> On Wed, Jan 11, 2012 at 12:14:29PM -0800, chk wrote:
> > If there is a Roadrunner contact monitoring the list can you please  
> > contact me off list regarding a routing issue from ns1/2.adelphia.net
> 
> Did you ever get any response?  I'm having a similar issue:
> 
> For the past couple months, we have been unable to query the
> authoritative DNS servers for adelphia.net on IP addresses
> 75.180.129.58 and 75.180.129.59 from our campus network IP block
> 130.215.0.0/16, using either TCP or UDP:
> 
> >dig +short +norec @75.180.129.58 adelphia.net. mx
> ;; connection timed out; no servers could be reached
> 
> >dig +short +norec @75.180.129.59 adelphia.net. mx
> ;; connection timed out; no servers could be reached
> 
> >dig +tcp +short +norec @75.180.129.58 adelphia.net. mx
> ;; communications error to 75.180.129.58#53: end of file
> 
> >dig +tcp +short +norec @75.180.129.59 adelphia.net. mx
> ;; communications error to 75.180.129.59#53: end of file
> 
> This is causing email failures to anyone with an @adelphia.net email
> address.
> 
> I can ping the DNS servers from 130.215.0.0/16:
> 
> >ping  -c3 75.180.129.58 
> PING 75.180.129.58 (75.180.129.58) 56(84) bytes of data.
> 64 bytes from 75.180.129.58: icmp_req=1 ttl=241 time=26.9 ms
> 64 bytes from 75.180.129.58: icmp_req=2 ttl=241 time=26.7 ms
> 64 bytes from 75.180.129.58: icmp_req=3 ttl=241 time=26.7 ms
> 
> --- 75.180.129.58 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2001ms
> rtt min/avg/max/mdev = 26.711/26.797/26.953/0.110 ms
> 
> >ping -c3 75.180.129.59
> PING 75.180.129.59 (75.180.129.59) 56(84) bytes of data.
> 64 bytes from 75.180.129.59: icmp_req=1 ttl=241 time=25.9 ms
> 64 bytes from 75.180.129.59: icmp_req=2 ttl=241 time=26.1 ms
> 64 bytes from 75.180.129.59: icmp_req=3 ttl=241 time=25.5 ms
> 
> --- 75.180.129.59 ping statistics ---
> 3 packets transmitted, 3 received, 0% packet loss, time 2002ms
> rtt min/avg/max/mdev = 25.523/25.871/26.120/0.285 ms
> 
> And I can make a TCP port 53 connection which gets immediately closed:
> 
> >telnet 75.180.129.58 53
> Trying 75.180.129.58...
> Connected to 75.180.129.58.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> >telnet 75.180.129.59 53
> Trying 75.180.129.59...
> Connected to 75.180.129.59.
> Escape character is '^]'.
> Connection closed by foreign host.
> 
> It is acting as if there is an ACL or firewall rule that is blocking
> 130.215.0.0/16 from accessing DNS port 53 on the DNS servers at
> 75.180.129.58 and 75.180.129.59.
> 
> I've already ruled out any firewalls on our end, as well as any
> routing issues.  I can see the UDP port 53 packets going out, but
> there is no reply.  I can see the 3-way TCP port 53 handshake packets
> going out and coming in, but the other end closes the connection
> immediately.
> 
> If I use a non-130.215.0.0/16 source IP from my router, I get a normal
> response via both UDP and TCP:
> 
> % dig -b 207.210.142.142 +short +norec @75.180.129.58 adelphia.net. mx
> 10 cdptpa-smtpin01.mail.rr.com.
> 20 cdptpa-smtpin02.mail.rr.com.
> 
> % dig -b 207.210.142.142 +short +tcp +norec @75.180.129.58 adelphia.net. mx
> 10 cdptpa-smtpin01.mail.rr.com.
> 20 cdptpa-smtpin02.mail.rr.com.
> 
> I'd appreciate if someone could help me find a clueful contact at
> TW/RoadRunner/Adelphia/Comcast/whoever they are now.  I've tried all
> the contacts in WHOIS for adelphia.net, the IP block, and ASN.  I've
> tried the NOC List on puck.nether.net--no matches.
> 
> Thanks,
> Chuck
> 

Sounds like a bad "bogus" acl.

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


From johnl at iecc.com  Wed Feb  8 20:46:31 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 02:46:31 -0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <CB589765.59670%markk@arin.net>
Message-ID: <20120209024631.7962.qmail@joyce.lan>

>I checked the traffic graphs for the server we operate
>(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
>of any report of issues with the other operators.

Actually, the A server is the only one that's responding quickly,
viewed from my DSL line hanging off gblx:

A   26ms
B   83ms
C  308ms
D  136ms
E  248ms
F   96ms

An acquaintance at LinkedIn tells me that they're seeing the same issue.

Doing a traceroute to the C server, it looks pretty snappy as far as
London, then slow as soon as it's in Afrinic's network.  I think it's
usually faster than that.  For the E server, the link between HE in
California and Australia seems slow.

R's,
John


From khomyakov.andrey at gmail.com  Wed Feb  8 22:54:46 2012
From: khomyakov.andrey at gmail.com (Andrey Khomyakov)
Date: Wed, 8 Feb 2012 23:54:46 -0500
Subject: BGP history in enterprise?
Message-ID: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>

Looking for something to keep track of BGP route changes in a large
enterprise. Found http://www.ibgplay.org/, but I can't seem to get in touch
with them to obtain that free license needed to start the service.
Does anyone know of something that would do what bgplay does or
alternatively how to get in touch with the ibgplay folks for that license...

Thanks,

--Andrey

From nenolod at systeminplace.net  Wed Feb  8 23:11:10 2012
From: nenolod at systeminplace.net (William Pitcock)
Date: Wed, 8 Feb 2012 23:11:10 -0600
Subject: report botnet C&C?
In-Reply-To: <20120208190433.GA19246@vectra.student.iastate.edu>
References: <D58BB17D-423C-40F6-B8AD-C93E4BA5D5B5@u13.net>
 <20120208190433.GA19246@vectra.student.iastate.edu>
Message-ID: <CC6A7792-C9E6-4577-A05E-5908FEB0FDD3@systeminplace.net>

hi,

On Feb 8, 2012, at 1:04 PM, Nicolai wrote:

> On Tue, Feb 07, 2012 at 10:20:07PM -0500, Ryan Rawdon wrote:
>> Assuming it is not a futile/wasted effort, where is the current best
>> place/resource to report an active botnet C&C to?
> 
> I don't know if there's a single best option, but there are several good
> ones.  In addition to Cymru I'd mention abuse.ch, which runs several
> public botnet C&C trackers.

DroneBL does investigate and track C&Cs, or at least, did when I ran it.  I would assume that it still does, so you may wish to contact them.

William



From me at anuragbhatia.com  Thu Feb  9 03:41:14 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 9 Feb 2012 15:11:14 +0530
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209024631.7962.qmail@joyce.lan>
References: <CB589765.59670%markk@arin.net>
 <20120209024631.7962.qmail@joyce.lan>
Message-ID: <CAJ0+aXYZ0XkPDpJZHLnxy52iNb9B8_zO3MmoCUeAjXpuWmiaQQ@mail.gmail.com>

Hi John


I have seen similar cases in past with root servers itself. Usually
problems are that local anycasted node here goes down and thus traffic is
redirected to other nearest server in Europe causing high latency. Can you
share traceroute result of a good Vs bad node say A Vs C. Can you see both
coming from within your country?

On Thu, Feb 9, 2012 at 8:16 AM, John Levine <johnl at iecc.com> wrote:

> >I checked the traffic graphs for the server we operate
> >(a.in-addr-servers.arpa) and it has normal traffic loads. Have not heard
> >of any report of issues with the other operators.
>
> Actually, the A server is the only one that's responding quickly,
> viewed from my DSL line hanging off gblx:
>
> A   26ms
> B   83ms
> C  308ms
> D  136ms
> E  248ms
> F   96ms
>
> An acquaintance at LinkedIn tells me that they're seeing the same issue.
>
> Doing a traceroute to the C server, it looks pretty snappy as far as
> London, then slow as soon as it's in Afrinic's network.  I think it's
> usually faster than that.  For the E server, the link between HE in
> California and Australia seems slow.
>
> R's,
> John
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From sven at cb3rob.net  Thu Feb  9 07:07:50 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 9 Feb 2012 13:07:50 +0000 (UTC)
Subject: UDP port 80 DDoS attack
In-Reply-To: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
Message-ID: <Pine.LNX.4.64.1202091305420.22348@a84-22-97-10.cb3rob.net>


> Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)
>
> -Drew

yes, very smart idea... which makes it completely impossible to have 
multihomed networks or simply kick out tunnel originated traffic over 
default gateways ... so, no, thanks.

we usually do it the other way around, if providers block "spoofed" 
traffic, we tell them to put their serverfarms somewhere else as thats not 
very optimized for tunnel termination at their facilities :P

(yes leaseweb, that means you ;)

>
>
> -----Original Message-----
> From: George Bonser [mailto:gbonser at seven.com]
> Sent: Wednesday, February 08, 2012 1:27 PM
> To: bas; nanog
> Subject: RE: UDP port 80 DDoS attack
>
>> 77% of all networks seem to think so.
>> http://spoofer.csail.mit.edu/summary.php
>
> And it would be the remaining 23% that really need to understand how difficult they are making life for the rest of the Internet.
>
>> However the remaining networks allow spoofed traffic to egress their
>> networks.
>>
>> When that traffic enters my network, I have no method whatsoever to
>> differentiate it from any other traffic.
>
> I'm not really thinking about traffic coming from the Internet.  I'm thinking about its originating location.  Correct, once it gets into the Internet, you really have no way to tell.
>
>> I could ask my upstream where they see it coming from, which will be
>> quite hard if they do not have pretty fancy systems.
>
> At that point the game is really hard, agreed.  And if it is distributed, it could be coming from any number of places or from every single one of their upstreams.
>
>
>> But if they receive it from a peer, I am as good as lost in trying to
>> find the culprit.
>
> Agreed.  That's why it is important to stop it at the source.
>
>> Bas
>
>


From streiner at cluebyfour.org  Thu Feb  9 10:18:45 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 9 Feb 2012 11:18:45 -0500 (EST)
Subject: BGP history in enterprise?
In-Reply-To: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>
References: <CAB31LOOugj-Ys8npH=HEdB8DphGhE5K66=ZNHyS+cmQj1Pyv6A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202091117410.3280@whammy.cluebyfour.org>

On Wed, 8 Feb 2012, Andrey Khomyakov wrote:

> Looking for something to keep track of BGP route changes in a large
> enterprise. Found http://www.ibgplay.org/, but I can't seem to get in touch
> with them to obtain that free license needed to start the service.
> Does anyone know of something that would do what bgplay does or
> alternatively how to get in touch with the ibgplay folks for that license...

If you're looking for changes that make it into the global BGP view, try 
http://bgplay.routeviews.org/

jms


From leigh.porter at ukbroadband.com  Thu Feb  9 11:31:39 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 9 Feb 2012 17:31:39 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
Message-ID: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Brent Jones [mailto:brent at brentrjones.com]
> Sent: 27 January 2012 06:33
> To: Rodrick Brown
> Cc: nanog list
> Subject: Re: 10G switchrecommendaton
> 
> On Thu, Jan 26, 2012 at 8:40 PM, Rodrick Brown
> <rodrick.brown at gmail.com>wrote:
> 
> > Not to mention Arista's cli runs a busybox Linux inside!
> >
> > Sent from my iPhone
> >
> >
> >
> Last I checked, Arista used Fedora Linux, with x86 dual-core CPUs and
> 4GB
> RAM.
> Their CLI was written in Python or Perl as well, and they encourage
> hacking
> it for cool new things.

Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing.

So a couple of evals on the way...

--
Leigh





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


From adrian.minta at gmail.com  Thu Feb  9 11:59:27 2012
From: adrian.minta at gmail.com (Adrian Minta)
Date: Thu, 09 Feb 2012 19:59:27 +0200
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <4F34097F.2030504@gmail.com>

Cisco has finally release a new 10G switch, Catalyst 4500-X:
http://www.cisco.com/en/US/products/ps12332/index.html

Does anyone know the price range, or the FCS date for this ?



From mehmet at icann.org  Thu Feb  9 12:16:42 2012
From: mehmet at icann.org (Mehmet Akcin)
Date: Thu, 9 Feb 2012 10:16:42 -0800
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <20120209020330.6513.qmail@joyce.lan>
References: <20120209020330.6513.qmail@joyce.lan>
Message-ID: <DA01FEF1-14E3-4064-A9C5-579068EDAF7A@icann.org>


On Feb 8, 2012, at 6:03 PM, John Levine wrote:

> I'm seeing surprisingly slow responses from some of the IN-ADDR
> servers, like 300ms or more.  Are they being attacked by script
> kiddies of something?
> 
> R's,
> John
> 
> 


We operate B.* and we don't see anything unusual in our locations.

thanks

Mehmet


From gbonser at seven.com  Thu Feb  9 14:24:44 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 20:24:44 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>

> 
> Based on this thread I has Arista in today for a show'n'tell and it is
> pretty impressive both in terms of features (features that you actually
> use) and pricing.
> 
> So a couple of evals on the way...
> 
> --
> Leigh

It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.





From johnl at iecc.com  Thu Feb  9 14:38:45 2012
From: johnl at iecc.com (John Levine)
Date: 9 Feb 2012 20:38:45 -0000
Subject: Slow IN-ADDR.ARPA responses
In-Reply-To: <DA01FEF1-14E3-4064-A9C5-579068EDAF7A@icann.org>
Message-ID: <20120209203845.45692.qmail@joyce.lan>

>We operate B.* and we don't see anything unusual in our locations.

Seems to have been routing problems with C.  The B server looks fine
from here, too.  Thanks, all.

R's,
John


From efinley.lists at gmail.com  Thu Feb  9 14:55:52 2012
From: efinley.lists at gmail.com (Elliot Finley)
Date: Thu, 9 Feb 2012 13:55:52 -0700
Subject: 10G switchrecommendaton
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
Message-ID: <CACRGtSO2NN4kCB0PDMZ4zF0Jzj-_UB5EC6p-5HkCu84t0Sy0FQ@mail.gmail.com>

On Thu, Feb 9, 2012 at 10:31 AM, Leigh Porter
<leigh.porter at ukbroadband.com> wrote:
> Based on this thread I has Arista in today for a show'n'tell and it is pretty impressive both in terms of features (features that you actually use) and pricing.
>
> So a couple of evals on the way...

Let us know how the eval goes if you would.

Thanks,
Elliot


From ltd at interlink.com.au  Thu Feb  9 15:13:13 2012
From: ltd at interlink.com.au (lincoln dale)
Date: Fri, 10 Feb 2012 08:13:13 +1100
Subject: 10G switchrecommendaton
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
Message-ID: <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com> wrote:

> It's pretty good gear.  The only problem I've had with it is the
> limitation of IGMP not working on mLAG VLANs.
>

IGMP should work just fine with MLAG.  IGMP state is sync'd between the
MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com)

From gbonser at seven.com  Thu Feb  9 15:17:21 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 21:17:21 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>

Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs)

SJC-AGS-01#sho ver
Arista DCS-7124S-F
Hardware version:    06.02
Serial number:       JSH10130054
System MAC address:  001c.7308.752f

Software image version: 4.6.4
Architecture:           i386
Internal build version: 4.6.4-434606.EOS464

Sure, we can discuss it.



From: lincoln dale [mailto:ltd at interlink.com.au]
Sent: Thursday, February 09, 2012 1:13 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.

IGMP should work just fine with MLAG.  IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com<mailto:ltd at aristanetworks.com>)

From ltd at interlink.com.au  Thu Feb  9 15:47:19 2012
From: ltd at interlink.com.au (lincoln dale)
Date: Fri, 10 Feb 2012 08:47:19 +1100
Subject: 10G switchrecommendaton
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
Message-ID: <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>

hi George,

IGMPv3 snooping has been supported since EOS 4.7.  Its enabled by default
in EOS 4.8.x.

In terms of specifics, there is support for both IGMPv3 snooping & IGMPv3
querier. There isn't currently support for IGMPv3 snooping querier.


cheers,

lincoln.

On Fri, Feb 10, 2012 at 8:17 AM, George Bonser <gbonser at seven.com> wrote:

>  Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping:
> %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface
> Port-Channel1 (message repeated 34 times in 625.028 secs)****
>
> ** **
>
> SJC-AGS-01#sho ver****
>
> Arista DCS-7124S-F****
>
> Hardware version:    06.02****
>
> Serial number:       JSH10130054****
>
> System MAC address:  001c.7308.752f****
>
> ** **
>
> Software image version: 4.6.4****
>
> Architecture:           i386****
>
> Internal build version: 4.6.4-434606.EOS464****
>
> ** **
>
> Sure, we can discuss it.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* lincoln dale [mailto:ltd at interlink.com.au]
> *Sent:* Thursday, February 09, 2012 1:13 PM
> *To:* George Bonser
> *Cc:* Leigh Porter; nanog list
> *Subject:* Re: 10G switchrecommendaton****
>
> ** **
>
> On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com> wrote:
> ****
>
> It's pretty good gear.  The only problem I've had with it is the
> limitation of IGMP not working on mLAG VLANs.****
>
>
> IGMP should work just fine with MLAG.  IGMP state is sync'd between the
> MLAG pair. Happy to talk about this more off-list if you wish.
>
>
> cheers,
>
> lincoln.
> (ltd at aristanetworks.com)****
>

From gbonser at seven.com  Thu Feb  9 16:48:31 2012
From: gbonser at seven.com (George Bonser)
Date: Thu, 9 Feb 2012 22:48:31 +0000
Subject: 10G switchrecommendaton
In-Reply-To: <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>
References: <CAAiP323LPCZ-8SpbwAcK4p5owuryc30CK5CJ8_8c5_hwYX07yg@mail.gmail.com>
 <9890E31B-1D18-415B-AACF-65F193E19332@gmail.com>
 <BDF3A810-1FF5-496D-8E86-51238D371D32@eddieparra.net>
 <CA7E867D448D8B489EFF2E97E266038A1DAD3CC1@RA-EX01.raprinting.com>
 <7B378EB3C047B74A899746268AB04539250D0B99@ORD1EXD04.RACKSPACE.CORP>
 <2666B4D5-ECD6-44C8-BF8C-26336E71770E@gmail.com>
 <CAOC=LuU7S3tMDOy8m+FF7rTgWLyR1poL616+ku+tAhYyd-owwA@mail.gmail.com>
 <D181DDABABE57E4DB72FEE00331478644A17B4@EALPO1.ukbroadband.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC03F4@RWC-MBX1.corp.seven.com>
 <CAAUJCVNkJ9dEBeywQvOmxr5OuTH+o7n2o0aQ1LDvv_D5dN6bnA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC0481@RWC-MBX1.corp.seven.com>
 <CAAUJCVP+eDV0A5yFM9nZfbmu9Cijv=MqXrkNj54SwurO4qqR4Q@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC05E4@RWC-MBX1.corp.seven.com>

Hi, Lincoln,

*sigh*

Ok, I see what happened.  We just went through a software upgrade cycle on that unit and it got upgraded to the end of 4.6 instead of being upgraded to the latest release version of EOS. Looks like another upgrade needs to be done, probably to 4.8.3

Thanks.

George


From: lincoln dale [mailto:ltd at interlink.com.au]
Sent: Thursday, February 09, 2012 1:47 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

hi George,

IGMPv3 snooping has been supported since EOS 4.7.  Its enabled by default in EOS 4.8.x.

In terms of specifics, there is support for both IGMPv3 snooping & IGMPv3 querier. There isn't currently support for IGMPv3 snooping querier.


cheers,

lincoln.
On Fri, Feb 10, 2012 at 8:17 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
Feb  9 07:42:21 SJC-AGS-01 IgmpSnooping: %IGMPSNOOPING-4-IGMPV3_UNSUPPORTED: IGMPv3 querier detected on interface Port-Channel1 (message repeated 34 times in 625.028 secs)

SJC-AGS-01#sho ver
Arista DCS-7124S-F
Hardware version:    06.02
Serial number:       JSH10130054
System MAC address:  001c.7308.752f

Software image version: 4.6.4
Architecture:           i386
Internal build version: 4.6.4-434606.EOS464

Sure, we can discuss it.



From: lincoln dale [mailto:ltd at interlink.com.au<mailto:ltd at interlink.com.au>]
Sent: Thursday, February 09, 2012 1:13 PM
To: George Bonser
Cc: Leigh Porter; nanog list
Subject: Re: 10G switchrecommendaton

On Fri, Feb 10, 2012 at 7:24 AM, George Bonser <gbonser at seven.com<mailto:gbonser at seven.com>> wrote:
It's pretty good gear.  The only problem I've had with it is the limitation of IGMP not working on mLAG VLANs.

IGMP should work just fine with MLAG.  IGMP state is sync'd between the MLAG pair. Happy to talk about this more off-list if you wish.


cheers,

lincoln.
(ltd at aristanetworks.com<mailto:ltd at aristanetworks.com>)


From davidianwalker at gmail.com  Thu Feb  9 00:13:03 2012
From: davidianwalker at gmail.com (David Walker)
Date: Thu, 9 Feb 2012 16:43:03 +1030
Subject: Firewalls in service provider environments
In-Reply-To: <20120208212335.GX3627@nntp.AegisInfoSys.com>
References: <00e97c634d3eccbc93c729dd9287bd3c.squirrel@mail.mattreath.com>
 <D181DDABABE57E4DB72FEE003314786449CD6A@EALPO1.ukbroadband.com>
 <27254847074d9b716c9e9dfc1b892661.squirrel@mail.mattreath.com>
 <CAP-guGVcXmY0hGYqrgFvEStxCqBxN=A3c84U7OTuBcpZ_GxzUQ@mail.gmail.com>
 <9ce5637555e82fbfd41a224272678cf6.squirrel@mail.mattreath.com>
 <CAALUyuRJ4pob=97fk=ph39ey3zvpbNC4COtzMBaeOai+LfDGxw@mail.gmail.com>
 <62055779754543ae83e3c0fe4cdad677.squirrel@mail.mattreath.com>
 <20120208212335.GX3627@nntp.AegisInfoSys.com>
Message-ID: <CABE=bRN+6FkJiYWp1s9O71Z6-A6YVyJEmppuwu-omMoTsBU2iQ@mail.gmail.com>

I'm an end user but I refer to these from time to time:

http://www.ietf.org/rfc/rfc3013.txt
http://www.ietf.org/rfc/rfc3871.txt

I suppose the salient question is what kind of customers are we talking about.

Best wishes.


From steve.bertrand at gmail.com  Wed Feb  8 17:49:43 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 08 Feb 2012 18:49:43 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
Message-ID: <4F330A17.2010806@gmail.com>

On 2012.02.08 14:23, Drew Weaver wrote:
> Stop paying transit providers for delivering spoofed packets to the edge of your network and they will very quickly develop methods of proving that the traffic isn't spoofed, or block it altogether. =)

I firmly believe in this recourse, amongst others...

If you know that your provider allows spoofed traffic, let the community 
know about it.

In all aspects of life, a problem must be 'fixed' at the source. All of 
the small-medium size ops have to connect to the big-boys somewhere, and 
what I've seen in this industry is that the big-boys are generally 
compliant.

Steve


From justine at cs.washington.edu  Thu Feb  9 19:01:06 2012
From: justine at cs.washington.edu (Justine Sherry)
Date: Thu, 9 Feb 2012 17:01:06 -0800
Subject: Middlebox Report and Thank You!
Message-ID: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>

Hello NANOG!

I emailed you a few months ago asking for help understanding typical
middlebox deployments in enterprise networks. 57 of you responded - thank
you so much!

Several of you asked if I'd share the data post-study; I've put together a
brief report on our findings here:
http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
If you have any questions, comments, or feedback, please don't hesitate to
contact me.

Thanks again for your help and support for our research!

Best,
Justine

From chesteve at gmail.com  Thu Feb  9 19:20:11 2012
From: chesteve at gmail.com (Christian Esteve)
Date: Thu, 9 Feb 2012 23:20:11 -0200
Subject: Middlebox Report and Thank You!
In-Reply-To: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
References: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
Message-ID: <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>

Thank you Justine!

your research recalled me to a recent middlebox-related publication:

"An Untold Story of Middleboxes in Cellular Networks"
by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and
Ming Zhang, Proceedings of SIGCOMM 2011.
(http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf)

In the news:
MIT Technology Review
http://www.technologyreview.com/communications/38435/?a=f
Slashdot
http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones
cnet news
http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/


Keep on your good work!

Cheers,
Christian

-- 
Christian Esteve Rothenberg, Ph.D.
Converged Networks Division (DRC)
Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
esteve at cpqd.com.br
www.cpqd.com.br

On Thu, Feb 9, 2012 at 23:01, Justine Sherry <justine at cs.washington.edu> wrote:
>
> Hello NANOG!
>
> I emailed you a few months ago asking for help understanding typical
> middlebox deployments in enterprise networks. 57 of you responded - thank
> you so much!
>
> Several of you asked if I'd share the data post-study; I've put together a
> brief report on our findings here:
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
> If you have any questions, comments, or feedback, please don't hesitate to
> contact me.
>
> Thanks again for your help and support for our research!
>
> Best,
> Justine




--
Christian


From tknchris at gmail.com  Thu Feb  9 21:00:50 2012
From: tknchris at gmail.com (chris)
Date: Thu, 9 Feb 2012 22:00:50 -0500
Subject: Middlebox Report and Thank You!
In-Reply-To: <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>
References: <CAGoufOA8O-cP6mxGW5iKzcVX9xXQ7HU=MPGD6Rh4LFpWQUpduQ@mail.gmail.com>
 <CAEj5p9SMz__TVkhAMoyX7hEMiPKhbP8X1nkXbZ72srA2GfU-yg@mail.gmail.com>
Message-ID: <CAKnNFz82tw7usn-G7KVDSx5m2bUVbfS8BSV+UBa07LCd2bONgA@mail.gmail.com>

Look how much time people waste with those all in one devices :) As soon as
I get the feeling something is very appliancey I run the other direction

On Thu, Feb 9, 2012 at 8:20 PM, Christian Esteve <chesteve at gmail.com> wrote:

> Thank you Justine!
>
> your research recalled me to a recent middlebox-related publication:
>
> "An Untold Story of Middleboxes in Cellular Networks"
> by Zhaoguang Wang, Zhiyun Qian, Qiang Xu, Zhuoqing Morley Mao, and
> Ming Zhang, Proceedings of SIGCOMM 2011.
> (http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p374.pdf)
>
> In the news:
> MIT Technology Review
> http://www.technologyreview.com/communications/38435/?a=f
> Slashdot
>
> http://mobile.slashdot.org/story/11/08/26/159225/Mobile-Carriers-Impose-Handicaps-On-Smartphones
> cnet news
>
> http://news.cnet.com/8301-30686_3-20107040-266/carriers-may-be-handicapping-cell-phone-networks/
>
>
> Keep on your good work!
>
> Cheers,
> Christian
>
> --
> Christian Esteve Rothenberg, Ph.D.
> Converged Networks Division (DRC)
> Tel.:+55 19-3705-4479 / Cel.: +55 19-8193-7087
> esteve at cpqd.com.br
> www.cpqd.com.br
>
> On Thu, Feb 9, 2012 at 23:01, Justine Sherry <justine at cs.washington.edu>
> wrote:
> >
> > Hello NANOG!
> >
> > I emailed you a few months ago asking for help understanding typical
> > middlebox deployments in enterprise networks. 57 of you responded - thank
> > you so much!
> >
> > Several of you asked if I'd share the data post-study; I've put together
> a
> > brief report on our findings here:
> > http://www.eecs.berkeley.edu/Pubs/TechRpts/2012/EECS-2012-24.pdf
> > If you have any questions, comments, or feedback, please don't hesitate
> to
> > contact me.
> >
> > Thanks again for your help and support for our research!
> >
> > Best,
> > Justine
>
>
>
>
> --
> Christian
>
>

From keegan.holley at sungard.com  Thu Feb  9 22:21:48 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 9 Feb 2012 23:21:48 -0500
Subject: UDP port 80 DDoS attack
In-Reply-To: <4F330A17.2010806@gmail.com>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
 <CABO8Q6S=OiE-dbw-MstMe5tDwX4Sk+qJY=pHNkB0VWgQ=tQr=Q@mail.gmail.com>
 <33D26C1C-E098-43BD-833D-0C288B5F0279@arbor.net>
 <CABO8Q6QuoU6=0YfaLH_ZcMHwN-hOcWSJhQ1nZXJEFRiRonsJBA@mail.gmail.com>
 <B8DFDDB0-CDDE-403E-A782-CCBECE248FB0@arbor.net>
 <CAEs2ZiK0V5yNU3ni6HGt6vbGpnbNquvxsq0uWrbpYO94EFYeDg@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBBF99@RWC-MBX1.corp.seven.com>
 <CABO8Q6TE8tEDo22OnwdOvSQ+34CB-4BfBixd_duFZL=+htXfVA@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC01E@RWC-MBX1.corp.seven.com>
 <CABO8Q6RfMn0Np-RYFQ7YBP94bftwu0kHTtiO5ufxRdyGBsKe=w@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBC06E@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBCE53@RWC-MBX1.corp.seven.com>
 <CAEs2ZiKXF+XuGhqwfxcGSM=x0SP7y7W5O2pFhhxx9tXULcfjig@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CBE3C9@RWC-MBX1.corp.seven.com>
 <F3318834F1F89D46857972DD4B411D70052CA02411@exchange>
 <4F330A17.2010806@gmail.com>
Message-ID: <CABO8Q6THE8wi7e7gfkxNF74hvfwhNSiz=TRFXdz-R1bbP89_vg@mail.gmail.com>

2012/2/8 Steve Bertrand <steve.bertrand at gmail.com>

> On 2012.02.08 14:23, Drew Weaver wrote:
>
>> Stop paying transit providers for delivering spoofed packets to the edge
>> of your network and they will very quickly develop methods of proving that
>> the traffic isn't spoofed, or block it altogether. =)
>>
>
> I firmly believe in this recourse, amongst others...
>

How do you tell the spoofed packets from the non-spoofed ones?  Especially
if you have more than one provider.

>
> If you know that your provider allows spoofed traffic, let the community
> know about it.
>

According to a company wide NDA I'm only allowed to disclose that to the
best of my knowledge my upstreams permits packets sent from users or other
NSP's who may or may not permit or generate packets.  The source IP
addresses are checked to be valid 32 bit numbers before being sent to my
routers. My upstreams to the best of their knowledge have never sent me a
single spoofed packet and will refrain from doing so unless they receive
written consent from me, in triplicate. ;)

>
> In all aspects of life, a problem must be 'fixed' at the source. All of
> the small-medium size ops have to connect to the big-boys somewhere, and
> what I've seen in this industry is that the big-boys are generally
> compliant.
>

As long as compliant means completely indifferent to your concerns and
unwilling to change or compromise in any meaningful while sucking money
away faster than the government.  They are all very very compliant and a
pleasure to do business with.

From jtk at cymru.com  Fri Feb 10 10:53:49 2012
From: jtk at cymru.com (John Kristoff)
Date: Fri, 10 Feb 2012 10:53:49 -0600
Subject: UDP port 80 DDoS attack
In-Reply-To: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
References: <7F48F1B1D2983A49AFC2A39FAC634039AE924E9CF1@miles-exch01.miles.office>
Message-ID: <20120210105349.77eb72b3@w520.localdomain>

On Sun, 5 Feb 2012 18:36:13 -0500
Ray Gasnick III <rgasnick at milestechnologies.com> wrote:

> Only solution thus far was to dump the victim IP address in our block
> into the BGP Black hole community with one of our 2 providers and
> completely stop advertising to the other.

Drew mentioned udp.pl and I also it could have been this script running
on some compromised Unix-based host(s) as well.  If the traffic did not
appear to be widely distributed, that is, not spoofed, then this is
even more likely.  If that was the case, filtering based on the sender
address(es) may help better mitigate the attack without taking the
target entirely offline for everyone else.

John


From smb at cs.columbia.edu  Fri Feb 10 10:56:57 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 11:56:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
Message-ID: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>

I received the enclosed note, apparently from RIPE (and the headers check out).
Why are you sending messages with clickable objects that I'm supposed to use to
change my password?

-------

From: RIPE_DBannounce at ripe.net
Subject: Advisory notice on passwords in the RIPE Database
Date: February 9, 2012 1:16:15 PM EST
To: XXXXXXXX

[Apologies for duplicate e-mails]

Dear Colleagues,

We are contacting you with some advice on the passwords used in the RIPE
Database.  There is no immediate concern and this notice is only advisory.
At the request of the RIPE community, the RIPE NCC recently deployed an
MD5 password hash change.

Before this change was implemented, there was a lot of discussion on the
Database Working Group mailing list about the vulnerabilities of MD5
passwords with public hashes.  The hashes can now only be seen by the user
of the MNTNER object.  As a precaution, now that the hashes are hidden,
we strongly recommend that you change all MD5 passwords used by your MNTNER
objects in the RIPE Database at your earliest convenience.  When choosing
new passwords, make them as strong as possible.

To make it easier for you to change your password(s) we have improved
Webupdates.  On the modify page there is an extra button after the "auth:"
attribute field.  Click this button for a pop up window that will encrypt
a password and enter it directly into the "auth:" field.

Webupdates: https://apps.db.ripe.net/webupdates/search.html

There is a RIPE Labs article explaining details of the security changes
and the new process to modify a MNTNER object in the RIPE Database:
https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database

We are sending you this email because this address is referenced in the
MNTNER objects in the RIPE Database listed below.

If you have any concerns about your passwords or need further advice please
contact our Customer Services team at ripe-dbm at ripe.net.  (You cannot reply
to this email.)

Regards,

Denis Walker
Business Analyst
RIPE NCC Database Group

Referencing MNTNER objects in the RIPE Database:
maint-rgnet







From richard.barnes at gmail.com  Fri Feb 10 11:18:29 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 10 Feb 2012 09:18:29 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
Message-ID: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>

So because of phishing, nobody should send messages with URLs in them?



On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
> I received the enclosed note, apparently from RIPE (and the headers check out).
> Why are you sending messages with clickable objects that I'm supposed to use to
> change my password?
>
> -------
>
> From: RIPE_DBannounce at ripe.net
> Subject: Advisory notice on passwords in the RIPE Database
> Date: February 9, 2012 1:16:15 PM EST
> To: XXXXXXXX
>
> [Apologies for duplicate e-mails]
>
> Dear Colleagues,
>
> We are contacting you with some advice on the passwords used in the RIPE
> Database. ?There is no immediate concern and this notice is only advisory.
> At the request of the RIPE community, the RIPE NCC recently deployed an
> MD5 password hash change.
>
> Before this change was implemented, there was a lot of discussion on the
> Database Working Group mailing list about the vulnerabilities of MD5
> passwords with public hashes. ?The hashes can now only be seen by the user
> of the MNTNER object. ?As a precaution, now that the hashes are hidden,
> we strongly recommend that you change all MD5 passwords used by your MNTNER
> objects in the RIPE Database at your earliest convenience. ?When choosing
> new passwords, make them as strong as possible.
>
> To make it easier for you to change your password(s) we have improved
> Webupdates. ?On the modify page there is an extra button after the "auth:"
> attribute field. ?Click this button for a pop up window that will encrypt
> a password and enter it directly into the "auth:" field.
>
> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>
> There is a RIPE Labs article explaining details of the security changes
> and the new process to modify a MNTNER object in the RIPE Database:
> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>
> We are sending you this email because this address is referenced in the
> MNTNER objects in the RIPE Database listed below.
>
> If you have any concerns about your passwords or need further advice please
> contact our Customer Services team at ripe-dbm at ripe.net. ?(You cannot reply
> to this email.)
>
> Regards,
>
> Denis Walker
> Business Analyst
> RIPE NCC Database Group
>
> Referencing MNTNER objects in the RIPE Database:
> maint-rgnet
>
>
>
>
>
>


From smb at cs.columbia.edu  Fri Feb 10 11:28:22 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 12:28:22 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>

If they're intended as a path to log in with a typed password, that's correct.
Sad, but correct.

On Feb 10, 2012, at 12:18 PM, Richard Barnes wrote:

> So because of phishing, nobody should send messages with URLs in them?
> 
> 
> 
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>> 
>> -------
>> 
>> From: RIPE_DBannounce at ripe.net
>> Subject: Advisory notice on passwords in the RIPE Database
>> Date: February 9, 2012 1:16:15 PM EST
>> To: XXXXXXXX
>> 
>> [Apologies for duplicate e-mails]
>> 
>> Dear Colleagues,
>> 
>> We are contacting you with some advice on the passwords used in the RIPE
>> Database.  There is no immediate concern and this notice is only advisory.
>> At the request of the RIPE community, the RIPE NCC recently deployed an
>> MD5 password hash change.
>> 
>> Before this change was implemented, there was a lot of discussion on the
>> Database Working Group mailing list about the vulnerabilities of MD5
>> passwords with public hashes.  The hashes can now only be seen by the user
>> of the MNTNER object.  As a precaution, now that the hashes are hidden,
>> we strongly recommend that you change all MD5 passwords used by your MNTNER
>> objects in the RIPE Database at your earliest convenience.  When choosing
>> new passwords, make them as strong as possible.
>> 
>> To make it easier for you to change your password(s) we have improved
>> Webupdates.  On the modify page there is an extra button after the "auth:"
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.
>> 
>> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>> 
>> There is a RIPE Labs article explaining details of the security changes
>> and the new process to modify a MNTNER object in the RIPE Database:
>> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>> 
>> We are sending you this email because this address is referenced in the
>> MNTNER objects in the RIPE Database listed below.
>> 
>> If you have any concerns about your passwords or need further advice please
>> contact our Customer Services team at ripe-dbm at ripe.net.  (You cannot reply
>> to this email.)
>> 
>> Regards,
>> 
>> Denis Walker
>> Business Analyst
>> RIPE NCC Database Group
>> 
>> Referencing MNTNER objects in the RIPE Database:
>> maint-rgnet
>> 
>> 
>> 
>> 
>> 
>> 
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From randy at psg.com  Fri Feb 10 11:29:30 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:29:30 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <m2sjiivbph.wl%randy@psg.com>

> So because of phishing, nobody should send messages with URLs in them?

more and more these days, i have taken to not clicking the update messages, 
but going to the web site manyually to get it.

waaaay to much phishing, and it is getting subtle and good.

randy


From corey at sequestered.net  Fri Feb 10 11:32:37 2012
From: corey at sequestered.net (Corey Quinn)
Date: Fri, 10 Feb 2012 09:32:37 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>


On Feb 10, 2012, at 9:29 AM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> waaaay to much phishing, and it is getting subtle and good.


Concur.

It seems as if they're no longer written by non-native English speakers, which goes a long way towards making them more insidious.  While still perfectly intelligible, most folks who use English as a second language don't speak in the same voice as, say, Wells Fargo corporate communications.


-- Corey 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/f2ba6f11/attachment.bin>

From bill at herrin.us  Fri Feb 10 11:35:56 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 12:35:56 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>

On Fri, Feb 10, 2012 at 12:18 PM, Richard Barnes
<richard.barnes at gmail.com> wrote:
> On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>> [...]
>> attribute field.  Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.

> So because of phishing, nobody should send messages with URLs in them?

url != clickable object


No problem with URLs in email.

No problem with clickable objects that are unrelated to security.

Minor problem with URLs that lead to changing passwords but can be
mitigated by making the URL very plain and easy to read, even by a
non-techie. They'll at least have to see the thing, even if the mail
client automagically makes it clickable.

Big problem with clickable objects which lead to PII (personally
identifiable information) or passwords. That's how phishing works -- a
disguised url that you either see at all or whose incorrect nature
slips right past your brain. The only known working solution is to
train folks to *never* click security-related URLs in email. Copy and
paste only, and only if they're readable and read right.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jra at baylink.com  Fri Feb 10 11:37:01 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 12:37:01 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
Message-ID: <27959862.1933.1328895421815.JavaMail.root@benjamin.baylink.com>

> It seems as if they're no longer written by non-native English
> speakers, which goes a long way towards making them more insidious.
> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

Most people who use English as their milk language don't speak in the same
voice as Wells Fargo Corporate Communications.  :-)

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


From bicknell at ufp.org  Fri Feb 10 11:37:01 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 09:37:01 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <20120210173701.GA79917@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.
> 
> waaaay to much phishing, and it is getting subtle and good.

We know how to sign and encrypt web sites.

We know how to sign and encrypt e-mail.

We even know how to compare keys between the web site and e-mail via a
variety of mechanisms.

We know how to sign DNS.

Remind me again why we live in this sad word Randy (correcly) described?

There's no reason my mail client shouldn't validate the signed e-mail
came from the same entity as the signed web site I'd previously logged
into, and give me a green light that the link actually points to said
same web site with the same key.  It should be transparent, and secure
for the user.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/a33ed5fb/attachment.bin>

From dwhite at olp.net  Fri Feb 10 11:37:52 2012
From: dwhite at olp.net (Dan White)
Date: Fri, 10 Feb 2012 11:37:52 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
Message-ID: <20120210173752.GA5173@dan.olp.net>

The line gets crossed when you send an unsolicited message that includes a
clickable change password link, that a phisher would find interesting
to emulate.

After the fact, if a phisher gets one of your customers to click on such a
link, you'd like to tell them them in response, or preemptively, that your
company never asks for sensitive information via email.

With good policies in place, the customer should not be receiving clickable
links via email that ask them for a password, except for a scenario where
they've actively generated that email in response to an "I forgot my
password" link on a website.

On 02/10/12?09:18?-0800, Richard Barnes wrote:
>So because of phishing, nobody should send messages with URLs in them?
>
>
>
>On Fri, Feb 10, 2012 at 8:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:
>> I received the enclosed note, apparently from RIPE (and the headers check out).
>> Why are you sending messages with clickable objects that I'm supposed to use to
>> change my password?
>>
>> -------
>>
>> From: RIPE_DBannounce at ripe.net
>> Subject: Advisory notice on passwords in the RIPE Database
>> Date: February 9, 2012 1:16:15 PM EST
>> To: XXXXXXXX
>>
>> [Apologies for duplicate e-mails]
>>
>> Dear Colleagues,
>>
>> We are contacting you with some advice on the passwords used in the RIPE
>> Database. ?There is no immediate concern and this notice is only advisory.
>> At the request of the RIPE community, the RIPE NCC recently deployed an
>> MD5 password hash change.
>>
>> Before this change was implemented, there was a lot of discussion on the
>> Database Working Group mailing list about the vulnerabilities of MD5
>> passwords with public hashes. ?The hashes can now only be seen by the user
>> of the MNTNER object. ?As a precaution, now that the hashes are hidden,
>> we strongly recommend that you change all MD5 passwords used by your MNTNER
>> objects in the RIPE Database at your earliest convenience. ?When choosing
>> new passwords, make them as strong as possible.
>>
>> To make it easier for you to change your password(s) we have improved
>> Webupdates. ?On the modify page there is an extra button after the "auth:"
>> attribute field. ?Click this button for a pop up window that will encrypt
>> a password and enter it directly into the "auth:" field.
>>
>> Webupdates: https://apps.db.ripe.net/webupdates/search.html
>>
>> There is a RIPE Labs article explaining details of the security changes
>> and the new process to modify a MNTNER object in the RIPE Database:
>> https://labs.ripe.net/Members/denis/securing-md5-hashes-in-the-ripe-database
>>
>> We are sending you this email because this address is referenced in the
>> MNTNER objects in the RIPE Database listed below.
>>
>> If you have any concerns about your passwords or need further advice please
>> contact our Customer Services team at ripe-dbm at ripe.net. ?(You cannot reply
>> to this email.)
>>
>> Regards,
>>
>> Denis Walker
>> Business Analyst
>> RIPE NCC Database Group
>>
>> Referencing MNTNER objects in the RIPE Database:
>> maint-rgnet
>>
>>
>>
>>
>>
>>
>
>

-- 
Dan White
BTC Broadband
Ph  918.366.0248 (direct)   main: (918)366-8000
Fax 918.366.6610            email: dwhite at olp.net
http://www.btcbroadband.com


From jeroen at unfix.org  Fri Feb 10 11:46:43 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Fri, 10 Feb 2012 18:46:43 +0100
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <4F355803.4040402@unfix.org>

On 2012-02-10 18:37 , Leo Bicknell wrote:
[..]

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

That is a rather nice idea. Most people, especially the common ones, do
not use PGP or heck even S/MIME though and only when one is included in
the web-of-trust can one actually verify these. Of course when that is
done, one should be able to match up email address and website URL quite
easily and your trick will work, at least one can then state:
  "the sender, who is verified by trust, is pointing to his/her
   own website."

The problem still lies in the issue that most people, even on this very
list, do not use PGP or S/MIME. (and that there are two standards does
not help much there either ;)

Greets,
 Jeroen


From randy at psg.com  Fri Feb 10 11:48:18 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:48:18 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <m2pqdma8bh.wl%randy@psg.com>

> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

my paranoid side is not comfortable with the certs that come for free
with my browser.  see the ietf dane wg.

randy


From randy at psg.com  Fri Feb 10 11:51:01 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 09:51:01 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <4C9F8DC3-2FCB-457A-BAB9-195264C42ACF@sequestered.net>
Message-ID: <m2obt6a86y.wl%randy@psg.com>

> While still perfectly intelligible, most folks who use English as a
> second language don't speak in the same voice as, say, Wells Fargo
> corporate communications.

yep.  if it's intelligible, it can't really be from wells fargo corp
comms.

randy


From Valdis.Kletnieks at vt.edu  Fri Feb 10 11:51:02 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 12:51:02 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 09:37:01 PST."
 <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <76758.1328896262@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:

> We know how to sign and encrypt web sites.
>
> We know how to sign and encrypt e-mail.
>
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
>
> We know how to sign DNS.
>
> Remind me again why we live in this sad word Randy (correcly) described?

Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
        supposed to be smarter than this."
Anakin Skywalker: "Apparently not."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/f5dde42b/attachment.bin>

From jra at baylink.com  Fri Feb 10 12:00:10 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:00:10 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>
Message-ID: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> Big problem with clickable objects which lead to PII (personally
> identifiable information) or passwords. That's how phishing works -- a
> disguised url that you either see at all or whose incorrect nature
> slips right past your brain. The only known working solution is to
> train folks to *never* click security-related URLs in email. Copy and
> paste only, and only if they're readable and read right.

And right there, Bill, is the part we so rarely understand, and it kills us:

Even lots of *technical* people just don't understand what "a security-
related URL" *is*, and there's almost always no way to teach them.

So it's necessary to throw the baby out with the bathwater, and tell them
never to click on a link...  MUA's that support HTML at all, much less
they fail to tell the user when a text URL doesn't match the actual link,
are the underlying culprits here...

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


From bicknell at ufp.org  Fri Feb 10 12:01:06 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 10:01:06 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <4F355803.4040402@unfix.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org>
Message-ID: <20120210180106.GB80127@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote:
> The problem still lies in the issue that most people, even on this very
> list, do not use PGP or S/MIME. (and that there are two standards does
> not help much there either ;)

The problem space is still certificate management.

I bet (nearly) everyone on the list uses an e-mail client that can
decode S/MIME.  mutt, pine, Outlook, OSX Mail, gmail, they all do
it.  We all have browsers that do SSL.

OSX at least has a central certificate store (Keychain), although
it's not up to the tasks of the world I wish to have.  Other OS's
provide no central store, so each application maintains their own
key store.  We have a very real problem of pre-loading the key
store, for instance root certificate trust for X.509 certificates.

We need a central certificate store on every platform, easy, secure ways
to transfer/sync it (to say, moble devices), and a bit of UI goo.
Imagine a capability as simple as being able to add a description to a
cert in your key store.  I should be able to download my bank's cert,
verify it (call and check finger print, check a trusted third party,
web of trust, probably multiple ways, automated, would be best) and then
tag it "Leo's Bank".

When I get e-mail from it, or go to it with my web browser it should now
say "Leo's Bank" in all of my software, telling me not only do I have
the little padlock, but it's the certificate I personally validated.

When I click on a link in e-mail it should pass the URL AND KEY to
the next program (e.g. my browser).  My browser can then silently
load if they are the same, or give me a big pop up "The person who
sent this e-mail is different from the person who runs this web
site."

It's all UI.  No new technology, protocols, encryption formats or other
things are needed.  It's making end user software act in a responsible
way.

Of course I'd also prefer my bank allowed me to provide my certificate
to them, and they crypto authenticated me (perhaps in addition to
passwords and pins).  This should all be two-way.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/de56882a/attachment.bin>

From bhmccie at gmail.com  Fri Feb 10 12:03:53 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 10 Feb 2012 12:03:53 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <76758.1328896262@turing-police.cc.vt.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <76758.1328896262@turing-police.cc.vt.edu>
Message-ID: <4F355C09.6050808@gmail.com>

Leo,
     This has nothing to do with the competency of the folks on the 
nanog list. It's a safe rule in general. Why? Because the stupid on the 
Internet outnumbers all of us. It's just easier to not send clickable 
links then it is to have the call center lit up because your users are 
getting hijacked.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/10/2012 11:51 AM, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 10 Feb 2012 09:37:01 PST, Leo Bicknell said:
>
>> We know how to sign and encrypt web sites.
>>
>> We know how to sign and encrypt e-mail.
>>
>> We even know how to compare keys between the web site and e-mail via a
>> variety of mechanisms.
>>
>> We know how to sign DNS.
>>
>> Remind me again why we live in this sad word Randy (correcly) described?
> Obi-Wan Kenobi: "(shocked) How could this have happened?? We're
>          supposed to be smarter than this."
> Anakin Skywalker: "Apparently not."
>


From randy at psg.com  Fri Feb 10 12:04:10 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 10:04:10 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <m2k43ua7l1.wl%randy@psg.com>

> We know how to sign and encrypt e-mail.

there is a public key distribution and trust problem

> We know how to sign DNS.

not very reliably yet

randy


From malayter at gmail.com  Fri Feb 10 12:26:15 2012
From: malayter at gmail.com (Ryan Malayter)
Date: Fri, 10 Feb 2012 10:26:15 -0800 (PST)
Subject: Iran blocking essentially all encyrpted protocols
Message-ID: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>

Haven't seen this come through on NANOG yet:
http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars

Can anyone with the ability confirm that TCP/443 traffic from Iran has
stopped?


From d3e3e3 at gmail.com  Fri Feb 10 12:28:12 2012
From: d3e3e3 at gmail.com (Donald Eastlake)
Date: Fri, 10 Feb 2012 13:28:12 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <CAF4+nEH2oX+BTj7sA7RD_kpXRA4edL8JTBBt+cERaSQqMdcy-A@mail.gmail.com>

Probably better than Iran doing man-in-the-middle...

Thanks,
Donald
=============================
?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell)
?155 Beaver Street,?Milford, MA 01757 USA
?d3e3e3 at gmail.com


On Fri, Feb 10, 2012 at 1:26 PM, Ryan Malayter <malayter at gmail.com> wrote:
> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
>


From jra at baylink.com  Fri Feb 10 12:29:34 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:29:34 -0500 (EST)
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?

Lauren scooped you on Privacy by about 6 minutes.  :-)

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


From james at smithwaysecurity.com  Fri Feb 10 12:35:49 2012
From: james at smithwaysecurity.com (James Smith)
Date: Fri, 10 Feb 2012 14:35:49 -0400
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>
References: <31899020.1967.1328898574799.JavaMail.root@benjamin.baylink.com>
Message-ID: <CEEA6F7F607649E3913DDDEB6079DFF7@smithwaIntell>

correct, it's down in Iran,
A few of my contacts got back to me confirming this  a few hours ago.

-----Original Message----- 
From: Jay Ashworth
Sent: Friday, February 10, 2012 2:29 PM
To: NANOG
Subject: Re: Iran blocking essentially all encyrpted protocols

----- Original Message -----
> From: "Ryan Malayter" <malayter at gmail.com>

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?

Lauren scooped you on Privacy by about 6 minutes.  :-)

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



From bill at herrin.us  Fri Feb 10 12:52:45 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 13:52:45 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
References: <CAP-guGXScbK_Dzc5dMdxF4Jr4CHgV_0iMd-Xkxei9WX5tkusOA@mail.gmail.com>
 <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGWBT_hA-Dneut55BP7ddpq94yxjnYrJPFjz6urkVYuM7A@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:00 PM, Jay Ashworth <jra at baylink.com> wrote:
>> From: "William Herrin" <bill at herrin.us>
>> Big problem with clickable objects which lead to PII (personally
>> identifiable information) or passwords. That's how phishing works -- a
>> disguised url that you either see at all or whose incorrect nature
>> slips right past your brain. The only known working solution is to
>> train folks to *never* click security-related URLs in email. Copy and
>> paste only, and only if they're readable and read right.
>
> And right there, Bill, is the part we so rarely understand, and it kills us:
>
> Even lots of *technical* people just don't understand what "a security-
> related URL" *is*, and there's almost always no way to teach them.
>
> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

Hi Jay,

And if we could just train people to never send or accept email
attachments, we could get rid of email-spread viruses. Not gonna
happen -- the functionality is too useful.

Security isn't just about what you can train someone to do... it's
also about what you can convince them to do when you're not standing
behind them watching -- the instructions that they're willing to
internalize. You can't convince people never to click links in an
email. It's too useful.

You might, however, be able to convince the average person that if a
link they clicked from an email asks for a password or asks for any
personal information then the message was probably from an
impersonator trying to steal the user's identity and they should
report it immediately lest they be victimized.

Regards,
Bill


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From jra at baylink.com  Fri Feb 10 12:59:36 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 13:59:36 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAP-guGWBT_hA-Dneut55BP7ddpq94yxjnYrJPFjz6urkVYuM7A@mail.gmail.com>
Message-ID: <662122.1983.1328900376952.JavaMail.root@benjamin.baylink.com>

---- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> And if we could just train people to never send or accept email
> attachments, we could get rid of email-spread viruses. Not gonna
> happen -- the functionality is too useful.
> 
> Security isn't just about what you can train someone to do... it's
> also about what you can convince them to do when you're not standing
> behind them watching -- the instructions that they're willing to
> internalize. You can't convince people never to click links in an
> email. It's too useful.

I did admit that it was throwing the baby out with the bathwater.

Being able to drive across someone's golf course to get to work is
convenient for me as well, but I'm still forbidden to do it.  This is a
tragedy of the commons problem -- since the biggest target for zombies
on PCs is probably spambots ...

> You might, however, be able to convince the average person that if a
> link they clicked from an email asks for a password or asks for any
> personal information then the message was probably from an
> impersonator trying to steal the user's identity and they should
> report it immediately lest they be victimized.

Yup.  Just like Steve just did in the posting that started this.

Y'know: the thing that only looked like a phish.

Cheers,
-- jr 'and don't even get me started on e-cards' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From cscora at apnic.net  Fri Feb 10 12:59:54 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 11 Feb 2012 04:59:54 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202101859.q1AIxsq7018374@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 11 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              397602
    Prefixes after maximum aggregation:                          169606
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     192311
Total ASes present in the Internet Routing Table:                 40086
    Prefixes per ASN:                                              9.92
Origin-only ASes present in the Internet Routing Table:           32739
Origin ASes announcing only one prefix:                           15528
Transit ASes present in the Internet Routing Table:                5400
Transit-only ASes present in the Internet Routing Table:            147
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               328
    Unregistered ASNs in the Routing Table:                         127
Number of 32-bit ASNs allocated by the RIRs:                       2272
Number of 32-bit ASNs visible in the Routing Table:                1947
Prefixes from 32-bit ASNs in the Routing Table:                    4674
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            137
Number of addresses announced to Internet:                   2513929424
    Equivalent to 149 /8s, 215 /16s and 132 /24s
    Percentage of available address space announced:               67.8
    Percentage of allocated address space announced:               67.8
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      168841

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    98087
    Total APNIC prefixes after maximum aggregation:               31681
    APNIC Deaggregation factor:                                    3.10
Prefixes being announced from the APNIC address blocks:           94410
    Unique aggregates announced from the APNIC address blocks:    39147
APNIC Region origin ASes present in the Internet Routing Table:    4652
    APNIC Prefixes per ASN:                                       20.29
APNIC Region origin ASes announcing only one prefix:               1239
APNIC Region transit ASes present in the Internet Routing Table:    737
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         20
Number of APNIC region 32-bit ASNs visible in the Routing Table:    143
Number of APNIC addresses announced to Internet:              635706656
    Equivalent to 37 /8s, 228 /16s and 29 /24s
    Percentage of available APNIC address space announced:         80.6

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148238
    Total ARIN prefixes after maximum aggregation:                75329
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           120188
    Unique aggregates announced from the ARIN address blocks:     49415
ARIN Region origin ASes present in the Internet Routing Table:    14905
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5689
ARIN Region transit ASes present in the Internet Routing Table:    1576
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               804413120
    Equivalent to 47 /8s, 242 /16s and 94 /24s
    Percentage of available ARIN address space announced:          63.9

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     98764
    Total RIPE prefixes after maximum aggregation:                52358
    RIPE Deaggregation factor:                                     1.89
Prefixes being announced from the RIPE address blocks:            90594
    Unique aggregates announced from the RIPE address blocks:     56087
RIPE Region origin ASes present in the Internet Routing Table:    16308
    RIPE Prefixes per ASN:                                         5.56
RIPE Region origin ASes announcing only one prefix:                7997
RIPE Region transit ASes present in the Internet Routing Table:    2598
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1344
Number of RIPE addresses announced to Internet:               500587080
    Equivalent to 29 /8s, 214 /16s and 90 /24s
    Percentage of available RIPE address space announced:          80.6

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38648
    Total LACNIC prefixes after maximum aggregation:               8064
    LACNIC Deaggregation factor:                                   4.79
Prefixes being announced from the LACNIC address blocks:          38261
    Unique aggregates announced from the LACNIC address blocks:   19517
LACNIC Region origin ASes present in the Internet Routing Table:   1572
    LACNIC Prefixes per ASN:                                      24.34
LACNIC Region origin ASes announcing only one prefix:               439
LACNIC Region transit ASes present in the Internet Routing Table:   290
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   441
Number of LACNIC addresses announced to Internet:              96512392
    Equivalent to 5 /8s, 192 /16s and 169 /24s
    Percentage of available LACNIC address space announced:        63.9

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   9015
    Total AfriNIC prefixes after maximum aggregation:              2096
    AfriNIC Deaggregation factor:                                  4.30
Prefixes being announced from the AfriNIC address blocks:          7029
    Unique aggregates announced from the AfriNIC address blocks:   2148
AfriNIC Region origin ASes present in the Internet Routing Table:   511
    AfriNIC Prefixes per ASN:                                     13.76
AfriNIC Region origin ASes announcing only one prefix:              164
AfriNIC Region transit ASes present in the Internet Routing Table:  117
Average AfriNIC Region AS path length visible:                      4.6
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             30893056
    Equivalent to 1 /8s, 215 /16s and 100 /24s
    Percentage of available AfriNIC address space announced:       46.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2471      11101         979   Korea Telecom (KIX)
17974     1729        503          36   PT TELEKOMUNIKASI INDONESIA
 7545     1642        303          85   TPG Internet Pty Ltd
 4755     1532        385         156   TATA Communications formerly 
 7552     1393       1064           7   Vietel Corporation
 9829     1172        989          28   BSNL National Internet Backbo
 4808     1149       2112         314   CNCGROUP IP network: China169
 9583     1124         83         482   Sify Limited
24560     1014        385         167   Bharti Airtel Ltd., Telemedia
18101      950        130         155   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3442       3807         201   bellsouth.net, inc. 
 7029     3391       1014         159   Windstream Communications Inc
18566     2093        382         177   Covad Communications 
 1785     1868        680         125   PaeTec Communications, Inc.
20115     1625       1550         631   Charter Communications 
 4323     1610       1062         385   Time Warner Telecom
22773     1511       2910         109   Cox Communications, Inc.
30036     1392        244         751   Mediacom Communications Corp 
19262     1386       4687         396   Verizon Global Networks 
 7018     1307       6995         849   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1719        480          15   Corbina telecom
 2118     1385         97          13   EUnet/RELCOM Autonomous Syste
15557     1095       2161          63   LDCOM NETWORKS
34984      650        188         172   BILISIM TELEKOM
 6830      644       1927         413   UPC Distribution Services
20940      608        195         470   Akamai Technologies European 
12479      584        642          53   Uni2 Autonomous System
31148      538         37           9   FreeNet ISP
 3320      533       8450         399   Deutsche Telekom AG
 8551      530        360          81   Bezeq International

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1751        324         162   TVCABLE BOGOTA 
28573     1655       1085          69   NET Servicos de Comunicao S.A
 8151     1475       3003         342   UniNet S.A. de C.V. 
 7303     1263        758         182   Telecom Argentina Stet-France
26615      896        664          33   Tim Brasil S.A.
11172      694         95          75   Servicios Alestra S.A de C.V 
27947      655         67         105   Telconet S.A
22047      581        322          17   VTR PUNTO NET S.A. 
 3816      551        237          91   Empresa Nacional de Telecomun
 7738      550       1050          31   Telecomunicacoes da Bahia S.A

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1235        958          13   TEDATA
24863      829        155          43   LINKdotNET AS number
 6713      485        649          18   Itissalat Al-MAGHRIB
 3741      278        939         229   The Internet Solution 
15706      238         32           6   Sudatel Internet Exchange Aut
33776      236         13          14   Starcomms Nigeria Limited
12258      197         28          62   Vodacom Internet Company 
24835      193         80           8   RAYA Telecom - Egypt
29571      189         17          11   Ci Telecom Autonomous system 
16637      163        664          82   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3442       3807         201   bellsouth.net, inc. 
 7029     3391       1014         159   Windstream Communications Inc
 4766     2471      11101         979   Korea Telecom (KIX)
18566     2093        382         177   Covad Communications 
 1785     1868        680         125   PaeTec Communications, Inc.
10620     1751        324         162   TVCABLE BOGOTA 
17974     1729        503          36   PT TELEKOMUNIKASI INDONESIA
 8402     1719        480          15   Corbina telecom
28573     1655       1085          69   NET Servicos de Comunicao S.A
 7545     1642        303          85   TPG Internet Pty Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3391        3232      Windstream Communications Inc
18566      2093        1916      Covad Communications 
 1785      1868        1743      PaeTec Communications, Inc.
 8402      1719        1704      Corbina telecom
17974      1729        1693      PT TELEKOMUNIKASI INDONESIA
10620      1751        1589      TVCABLE BOGOTA 
28573      1655        1586      NET Servicos de Comunicao S.A
 7545      1642        1557      TPG Internet Pty Ltd
 4766      2471        1492      Korea Telecom (KIX)
22773      1511        1402      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
37.98.200.0/21       56687     Nimad Rah Khoozestan PLC
37.98.208.0/20        8374     Polkomtel S.A.

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:80      /12:231     
/13:458     /14:816     /15:1469    /16:12130   /17:6197    /18:10311   
/19:20471   /20:28291   /21:29233   /22:39842   /23:37018   /24:207333  
/25:1195    /26:1434    /27:775     /28:169     /29:59      /30:14      
/31:0       /32:18      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3047          3391      Windstream Communications Inc
 6389     2112          3442      bellsouth.net, inc. 
18566     2042          2093      Covad Communications 
 8402     1698          1719      Corbina telecom
10620     1645          1751      TVCABLE BOGOTA 
30036     1351          1392      Mediacom Communications Corp 
11492     1118          1155      Cable One 
 1785     1065          1868      PaeTec Communications, Inc.
15557     1045          1095      LDCOM NETWORKS
 8452     1041          1235      TEDATA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:505       2:689       4:14        5:1         6:3         8:385    
  12:1958     13:1        14:596      15:11       16:3        17:7      
  20:9        23:133      24:1724     27:1197     31:901      32:65     
  33:2        34:2        36:9        37:177      38:776      40:115    
  41:3174     42:93       43:1        44:3        46:1281     47:3      
  49:322      50:512      52:13       54:2        55:9        56:3      
  57:38       58:962      59:491      60:344      61:1195     62:949    
  63:2008     64:4130     65:2285     66:4426     67:2039     68:1174   
  69:3159     70:927      71:412      72:1795     74:2654     75:463    
  76:322      77:976      78:936      79:502      80:1228     81:881    
  82:569      83:529      84:582      85:1154     86:742      87:919    
  88:334      89:1547     90:271      91:4479     92:538      93:1328   
  94:1357     95:1084     96:418      97:310      98:814      99:38     
 100:4       101:141     103:776     106:65      107:152     108:150    
 109:1486    110:694     111:848     112:432     113:530     114:597    
 115:763     116:868     117:727     118:899     119:1254    120:361    
 121:683     122:1621    123:1071    124:1337    125:1369    128:542    
 129:189     130:212     131:589     132:164     133:21      134:231    
 135:60      136:216     137:153     138:286     139:145     140:488    
 141:262     142:385     143:411     144:520     145:70      146:484    
 147:242     148:728     149:274     150:165     151:196     152:447    
 153:170     154:7       155:403     156:211     157:368     158:156    
 159:515     160:322     161:244     162:341     163:187     164:529    
 165:391     166:556     167:457     168:762     169:147     170:832    
 171:111     172:2       173:1733    174:603     175:416     176:515    
 177:481     178:1247    180:1180    181:65      182:715     183:278    
 184:425     185:1       186:2050    187:842     188:1031    189:1169   
 190:5474    192:5970    193:5525    194:4327    195:3393    196:1299   
 197:181     198:3619    199:4378    200:5718    201:1736    202:8496   
 203:8625    204:4346    205:2440    206:2736    207:2804    208:4069   
 209:3566    210:2747    211:1477    212:2042    213:1847    214:864    
 215:96      216:5000    217:1477    218:548     219:340     220:1252   
 221:558     222:325     223:280    

End of report


From sh.vahabzadeh at gmail.com  Fri Feb 10 13:03:06 2012
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Fri, 10 Feb 2012 22:33:06 +0330
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
Message-ID: <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>

Yes I am from Iran and outgoing TCP/443 has been stoped ;)

--
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:

> Haven't seen this come through on NANOG yet:
> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
> 
> Can anyone with the ability confirm that TCP/443 traffic from Iran has
> stopped?
> 


From malayter at gmail.com  Fri Feb 10 13:11:18 2012
From: malayter at gmail.com (Ryan Malayter)
Date: Fri, 10 Feb 2012 11:11:18 -0800 (PST)
Subject: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't
 encourage phishing)
In-Reply-To: <20120210180106.GB80127@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
Message-ID: <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>



On Feb 10, 12:01?pm, Leo Bicknell <bickn... at ufp.org> wrote:
> OSX at least has a central certificate store (Keychain), although
> it's not up to the tasks of the world I wish to have. ?Other OS's
> provide no central store, so each application maintains their own
> key store.

Windows has had its own centralized certificate store and APIs since
NT 4.0's release in 1996.

Firefox and Java are the only mainstream software can think of on
Windows that insists on using their own certificate stores (really
just a "pile of world-readable files") instead of the built-in per-
machine+per-user certificate store on Windows.


From jcdill.lists at gmail.com  Fri Feb 10 13:12:03 2012
From: jcdill.lists at gmail.com (JC Dill)
Date: Fri, 10 Feb 2012 11:12:03 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
References: <30780538.1943.1328896810308.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F356C03.8060808@gmail.com>

On 10/02/12 10:00 AM, Jay Ashworth wrote:
> Even lots of*technical*  people just don't understand what "a security-
> related URL"*is*, and there's almost always no way to teach them.

Freakonomics recently aired a story about the problem of getting Doctors 
to follow hand hygiene rules and wash their hands as frequently as they 
are supposed to (upon entering and leaving each patient's room) to avoid 
spreading disease.  One of the biggest problems with changing behavior 
with doctors (and with technical people) is that the smarter people are, 
the more they chafe at being told they aren't doing things the correct way.

The most effective step they took to counter-act the hand-washing 
problems was using a screen-saver on all the public terminals, showing 
the consequences of not-washing - an image of a petri dish showing the 
bacteria results from a hand-print of a doctor's hand.

http://www.freakonomics.com/2012/01/24/how-to-get-doctors-to-wash-their-hands-visual-edition/


If you wanted to have a similar effect at $workplace, try a similar 
visual (e.g. a mockup of 2 screenshots, first clicking on a link in 
email then typing in a password on a webpage with a phishing URL (with a 
typo)) as the screen saver on all company computers; as the first slide 
in all in-house ppt presentations; on the wall at all card-lock entry 
doors, etc.

jc


From rsk at gsp.org  Fri Feb 10 13:16:12 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 10 Feb 2012 14:16:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <D566F764-8028-41A5-8323-7E5DBA4D2C2B@cs.columbia.edu>
Message-ID: <20120210191612.GA13913@gsp.org>

On Fri, Feb 10, 2012 at 12:28:22PM -0500, Steven Bellovin wrote:
> If they're intended as a path to log in with a typed password, that's correct.
> Sad, but correct.

I agree.  Training your customers/clients to click on URLs in email
messages is precisely equivalent to training them to be phish victims.

I teach people to (carefully!) bookmark the sites that they use which
require passwords, and to always use those bookmarks -- that is, *never*
to use the links in any mail message or on any web page.

(Of course, an attacker in control of their browser could manipulate the
bookmarks, but there is little reason for an attacker who's already gotten
that far to do so.)

---rsk


From jra at baylink.com  Fri Feb 10 13:44:29 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 14:44:29 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F356C03.8060808@gmail.com>
Message-ID: <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "JC Dill" <jcdill.lists at gmail.com>

> If you wanted to have a similar effect at $workplace, try a similar
> visual (e.g. a mockup of 2 screenshots, first clicking on a link in
> email then typing in a password on a webpage with a phishing URL (with a
> typo)) as the screen saver on all company computers; as the first slide
> in all in-house ppt presentations; on the wall at all card-lock entry
> doors, etc.

The problem is you need the 3rd visual...

a picture of an abandoned factory, with the doors flapping in the wind, 
bceause the company went out of business because someone got spearphished.

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


From Valdis.Kletnieks at vt.edu  Fri Feb 10 13:53:14 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 14:53:14 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 14:44:29 EST."
 <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>
References: <13990481.1993.1328903069177.JavaMail.root@benjamin.baylink.com>
Message-ID: <116972.1328903594@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:

> a picture of an abandoned factory, with the doors flapping in the wind,
> bceause the company went out of business because someone got spearphished.

Has this ever been spotted in the wild?  Serious question - most of the well-publicized
spearphishing attacks lately the victim company is still around.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/da396d23/attachment.bin>

From jra at baylink.com  Fri Feb 10 13:57:02 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 14:57:02 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <116972.1328903594@turing-police.cc.vt.edu>
Message-ID: <27384450.2017.1328903822394.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> On Fri, 10 Feb 2012 14:44:29 EST, Jay Ashworth said:
> > a picture of an abandoned factory, with the doors flapping in the wind,
> > bceause the company went out of business because someone got spearphished.
> 
> Has this ever been spotted in the wild? Serious question - most of the
> well-publicized spearphishing attacks lately the victim company is still 
> around.

I don't know that we would have any way to know that a demised company went
down due to a spearphish... but yes, I was exaggerating.

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


From marshall.eubanks at gmail.com  Fri Feb 10 14:07:15 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Fri, 10 Feb 2012 15:07:15 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
Message-ID: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>

And in response

http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/

(quoting) :

?Basically, say you want to look like an XMPP chat instead of SSL,? he
writes to me, referring to a protocol for instant messaging as the
decoy for the encrypted SSL communications. ?Obfsproxy should start
up, you choose XMPP, and obfsproxy should emulate XMPP to the point
where even a sophisticated [deep packet inspection] device cannot find
anything suspicious.?

Regards
Marshall

On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
<sh.vahabzadeh at gmail.com> wrote:
> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>
> --
> Regards,
> Shahab Vahabzadeh, Network Engineer and System Administrator
>
> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 ?C2EE 76A2 46C2 5367 BF90
>
> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>
>> Haven't seen this come through on NANOG yet:
>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>
>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>> stopped?
>>
>


From bicknell at ufp.org  Fri Feb 10 14:08:26 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 12:08:26 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <7f28e83f-a4da-4c47-9e03-77ff4dcf7062@f30g2000yqh.googlegroups.com>
Message-ID: <20120210200826.GA85969@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 11:11:18AM -0800, Ryan Malayter wrote:
> Windows has had its own centralized certificate store and APIs since
> NT 4.0's release in 1996.

You are correct that I maligned Windows in a way I shouldn't have
done.  Indeed, I've been very impressed with the software they make
to manage certificates in the enterprise before, making it quite
easy to roll out per user certificates for VPN's or E-Mail and dump
it in the certificate store.

I think my view was incorrectly colored by the fact that the API
is not used by many programs (open source in particular) where as
OSX has had some traction with the Keychain.

It would be nice to get something approximating a cross platform API,
even if all that means is the ability to do the same operations on all
major platforms.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/cd0fb21b/attachment.bin>

From smb at cs.columbia.edu  Fri Feb 10 14:20:57 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 15:20:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <8D6F5DEF-21AF-43C0-B6AC-6E718D527646@cs.columbia.edu>


On Feb 10, 2012, at 12:29 30PM, Randy Bush wrote:

>> So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Yup -- I wrote about that a while back (https://www.cs.columbia.edu/~smb/blog/2011-10/2011-10-02.html)
> 
> waaaay to much phishing, and it is getting subtle and good.
> 


What's the line -- "I know I'm paranoid, but am I paranoid enough?"

		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From smb at cs.columbia.edu  Fri Feb 10 14:26:12 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 10 Feb 2012 15:26:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <7A06A06D-5A68-4806-B8C1-7020707C36BB@cs.columbia.edu>


On Feb 10, 2012, at 12:37 01PM, Leo Bicknell wrote:

> In a message written on Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
>> more and more these days, i have taken to not clicking the update messages, 
>> but going to the web site manyually to get it.
>> 
>> waaaay to much phishing, and it is getting subtle and good.
> 
> We know how to sign and encrypt web sites.
> 
> We know how to sign and encrypt e-mail.
> 
> We even know how to compare keys between the web site and e-mail via a
> variety of mechanisms.
> 
> We know how to sign DNS.
> 
> Remind me again why we live in this sad word Randy (correcly) described?
> 
> There's no reason my mail client shouldn't validate the signed e-mail
> came from the same entity as the signed web site I'd previously logged
> into, and give me a green light that the link actually points to said
> same web site with the same key.  It should be transparent, and secure
> for the user.

The really hard parts are (a) getting the users to pay attention to the
validation state (or, more precisely, the lack thereof on a phishing
email, and (b) get them to do it *correctly*.

Some of the browser password managers have protection against phishing as
a very useful side-effect: if they don't recognize the URL, they won't pony
up the correct login and password.  That's much better than hoping that
someone notices the absence of a little icon that means "this was signed".

The "correctly" part has to do with the PKI mess.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From jra at baylink.com  Fri Feb 10 14:30:35 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 10 Feb 2012 15:30:35 -0500 (EST)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <8D6F5DEF-21AF-43C0-B6AC-6E718D527646@cs.columbia.edu>
Message-ID: <9602735.2051.1328905835691.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Steven Bellovin" <smb at cs.columbia.edu>

> What's the line -- "I know I'm paranoid, but am I paranoid enough?"

"Just because people say you're paranoid, that doesn't mean that there
*aren't* people out to get you."

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


From bill at herrin.us  Fri Feb 10 15:15:19 2012
From: bill at herrin.us (William Herrin)
Date: Fri, 10 Feb 2012 16:15:19 -0500
Subject: PGP, S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't
 encourage phishing)
In-Reply-To: <20120210180106.GB80127@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
Message-ID: <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:01 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 10, 2012 at 06:46:43PM +0100, Jeroen Massar wrote:
>> The problem still lies in the issue that most people, even on this very
>> list, do not use PGP or S/MIME. (and that there are two standards does
>> not help much there either ;)
>
> The problem space is still certificate management.

The problem space is that most folks won't catch the difference
between an email and link from ripe.net, ripe.org and ripe.ca. The
game is lost long before a purely technical version of validating the
message source becomes an issue.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From eesslinger at fpu-tn.com  Fri Feb 10 15:19:24 2012
From: eesslinger at fpu-tn.com (Eric J Esslinger)
Date: Fri, 10 Feb 2012 15:19:24 -0600
Subject: couple of questions regarding 'lifeline' and large scale nat...
Message-ID: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>

We're toying with the idea of a low bitrate 'lifeline' internet on our cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit rates are you providing.
Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead. Understand, we're only talking about basic internet, something like a 256k/96k (or similar) connect, not something that would be used by a serious user. (One thing we are looking at is some older dial up users we still have, most of which could go onto cable just fine but don't want to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand customers for this. We're not a large ISP/cable company by any means.

__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Eric J Esslinger.vcf
Type: text/x-vcard
Size: 498 bytes
Desc: Eric J Esslinger.vcf
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/bc4a8cdc/attachment.vcf>

From bicknell at ufp.org  Fri Feb 10 15:37:55 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 13:37:55 -0800
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
Message-ID: <20120210213755.GA88812@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 04:15:19PM -0500, William Herrin wrote:
> The problem space is that most folks won't catch the difference
> between an email and link from ripe.net, ripe.org and ripe.ca. The
> game is lost long before a purely technical version of validating the
> message source becomes an issue.

You're reply is along the lines of what several other folks have
told me privately, and I think they all miss the mark of where I
am going with my suggestion.

Hypothetically, I get an e-mail from ripe.ca, which uses some trick
(perhaps as simple as HTML text and link that go to different places)
to visually show me ripe.net and actually sends me to ripe.org.

Let's also assume I have a ripe.net account and have been to that
web site before.

The software can do a pile of things that make life better for the user:

1) When I reach ripe.org (from the phish above), my browser can say:

   "This is an SSL web site asking for a login and password, and yet,
    you've never been here before.  Maybe you would prefer to register,
    or leave if you came here incorrectly."

   That's all client side UI, and would make even novice users stop
   and think about what happened.

2) Let's say the e-mail was signed, by ripe.ca, the original sender.
   When my e-mail client passes the URL to my browser, it can also pass
   the details of the ripe.ca key.  My browser can then say "You got
   an e-mail from Key ABC, but went to a web site run by XYZ, are you
   sure this is what you want to do?"  Of course if everything matches,
   it can be silent.

Specifically I am NOT suggesting to ever trust a root-CA, or the
details in a certificate.  Indeed, browsers could ship with no
certificates what so ever in my scheme.  The key is comparing
multiple sources of information.  Most folks might not know the
difference between ripe.ca and ripe.net.  The existing CA scheme
may allow both of them to get the common name "R?seaux IP Europ?ens",
confusing even the technical who look close.  But it's trivial for
the software to say Cert in E-mail != Cert in Web, or even that
they don't have a common branch in the tree (in a large org they
may have the same parent, for instance).

As I've also said, a good UI feature would be the ability to add a
description to a cert locally.  Once I'm sure my banks web site is legit
I should be able to add "Leo's Bank" in the cert store locally.  Now
when my web browser or e-mail client use that cert to validate a message
they can display "Leo's Bank" next to it.  I can easily look for that
and know I went back to the same place.  I click on a link in my e-mail
and see no description, I know something went wrong.

Does my scheme stop all phishing.  Heck no.  If we wait for a perfect
solution we'll never have any solution.  Look at NANOG.  Bandy Rush is
here somewhere.  It's why many years ago I set my mailer to PGP all
e-mail to NANOG.  See an e-mail from me not signed, don't trust it.
Does that stop all impersonation on NANOG.  Heck no, but if we all did
it, and subscribed to the web of trust, it would all but stop it.

Users hate encryption and ignore the warnings not because they don't
want to be secure, or are idiots.  They do it because the darn software
is broken, confusing, and has the worst UI's ever invented.  If the
industry fixes it, encryption will be much more widespread.  Small
steps, like banks allowing users to upload an cert to their account
profile, and then communicate via two-way authenticated e-mail would go
a long way to traning the user community how this should work.  End user
ISP's (cable, DSL) issuing e-mail certs automatically and installing
them as part of their install package would be a quantum leap forward.

It's not hard, people just don't do it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/742945ee/attachment.bin>

From bicknell at ufp.org  Fri Feb 10 15:43:41 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 13:43:41 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <20120210214341.GB88812@ussenterprise.ufp.org>

In a message written on Fri, Feb 10, 2012 at 03:19:24PM -0600, Eric J Esslinger wrote:
> First question, if you happen to be doing something like this, what bit rates are you providing.

Comcast has a program with some of the best marketing around it right
now, their Internet Essentials service: http://www.internetessentials.com/

$9.95/month, 1.5Mbps down, 384kbps up.

> Second question, though 'real' internet customers all get real IP's, what would you think of doing something like this with 'large scale' nat instead.

Carriers do not want to run NAT's.  You can go read the archives of the
CGN (Carrier Grade NAT) discussions where folks are looking at moving
the NAT into the service provider due to IPv4 exhaustion.

UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
passthrough), combined with the problems of some applications that
make thousands of TCP connections in a short order eating up ports
makes it a nightmare to manage and debug.  Of course, if they are
doing illegal things you'd better keep some detailed records of who did
what when a LEO comes knocking.

The key to a low cost service is making it as low cost as possible,
moving the NAT inside the carrier will had a huge amount of headache and
support costs, not what you want.

A possibly relevant question with IPv4 exhaustion coming is could you
make this service IPv6 only so you don't have to find IPv4 addresses for
it.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/40887ce0/attachment.bin>

From cidr-report at potaroo.net  Fri Feb 10 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 10 Feb 2012 22:00:00 GMT
Subject: BGP Update Report
Message-ID: <201202102200.q1AM003Z055387@wattle.apnic.net>

BGP Update Report
Interval: 02-Feb-12 -to- 09-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            53549  3.4%      29.9 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS28683           32704  2.1%     536.1 -- BENINTELECOM
 3 - AS9829            26878  1.7%      39.6 -- BSNL-NIB National Internet Backbone
 4 - AS12479           26390  1.7%     303.3 -- UNI2-AS France Telecom Espana SA
 5 - AS45271           23588  1.5%     168.5 -- ICLNET-AS-AP 5th Floor, Windsor Building, Off: CST Road
 6 - AS32528           22752  1.4%    7584.0 -- ABBOTT Abbot Labs
 7 - AS8452            21248  1.3%      52.7 -- TE-AS TE-AS
 8 - AS23154           20456  1.3%    6818.7 -- SANMINA-SCI Sanmina-SCI Corporation
 9 - AS5800            19469  1.2%      64.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
10 - AS7552            17101  1.1%      19.6 -- VIETEL-AS-AP Vietel Corporation
11 - AS24560           16978  1.1%      39.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
12 - AS20632           15343  1.0%    1180.2 -- PETERSTAR-AS PeterStar
13 - AS2118            15208  1.0%      17.4 -- RELCOM-AS OOO "NPO Relcom"
14 - AS17974           14308  0.9%      15.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
15 - AS6503            12775  0.8%       7.6 -- Axtel, S.A.B. de C.V.
16 - AS6066            12372  0.8%    6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
17 - AS5976            11800  0.8%     119.2 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - AS6713            11470  0.7%      25.9 -- IAM-AS
19 - AS29126           11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
20 - AS12975           10309  0.7%      45.4 -- PALTEL-AS PALTEL Autonomous System


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126           11373  0.7%   11373.0 -- DATIQ-AS Datiq B.V.
 2 - AS32528           22752  1.4%    7584.0 -- ABBOTT Abbot Labs
 3 - AS23154           20456  1.3%    6818.7 -- SANMINA-SCI Sanmina-SCI Corporation
 4 - AS6066            12372  0.8%    6186.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 5 - AS5868             1882  0.1%    1882.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 6 - AS8163             1257  0.1%    1257.0 -- METROTEL REDES S.A.
 7 - AS20632           15343  1.0%    1180.2 -- PETERSTAR-AS PeterStar
 8 - AS53362             882  0.1%     882.0 -- MIXIT-AS - Mixit, Inc.
 9 - AS21271             810  0.1%     810.0 -- SOTELMABGP
10 - AS27704             595  0.0%     595.0 -- Tiendas Comercial Mexicana, S.A. de C.V.
11 - AS17408            3497  0.2%     582.8 -- ABOVE-AS-AP AboveNet Communications Taiwan
12 - AS51896             567  0.0%     567.0 -- HRINGDU-AS Hringdu ehf
13 - AS1997             1643  0.1%     547.7 -- IBMDES-AS - IBM Dallas Engineering & Scientific
14 - AS28683           32704  2.1%     536.1 -- BENINTELECOM
15 - AS36980             512  0.0%     512.0 -- JOHNHOLT-ASN
16 - AS39843            1415  0.1%     471.7 -- RATECOM-AS ZAO "Ratecom"
17 - AS48068             448  0.0%     448.0 -- VISONIC Visonic Ltd
18 - AS56886             440  0.0%     440.0 -- REDSTAR-AS OOO "Red Star"
19 - AS676               437  0.0%     437.0 -- United Nations Development Programme
20 - AS37296             432  0.0%     432.0 -- AFCOMSAT


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 148.164.14.0/24   20430  1.2%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 2 - 84.204.132.0/24   15228  0.9%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 217.170.24.0/21   11373  0.7%   AS29126 -- DATIQ-AS Datiq B.V.
 4 - 130.36.34.0/24    11372  0.7%   AS32528 -- ABBOTT Abbot Labs
 5 - 130.36.35.0/24    11372  0.7%   AS32528 -- ABBOTT Abbot Labs
 6 - 122.161.0.0/16    10381  0.6%   AS24560 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
 7 - 62.36.252.0/22     8257  0.5%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 202.92.235.0/24    8179  0.5%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 9 - 190.67.172.0/22    6746  0.4%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
10 - 62.36.249.0/24     6209  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
11 - 204.29.239.0/24    6186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
12 - 150.225.0.0/16     6186  0.4%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
13 - 62.36.241.0/24     5685  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
14 - 62.36.210.0/24     5463  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 194.63.9.0/24      5322  0.3%   AS1273  -- CW Cable and Wireless Worldwide plc
16 - 41.43.219.0/24     4202  0.2%   AS8452  -- TE-AS TE-AS
17 - 41.43.222.0/24     4150  0.2%   AS8452  -- TE-AS TE-AS
18 - 205.73.118.0/24    4059  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - 205.73.116.0/23    3969  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
20 - 41.43.233.0/24     3643  0.2%   AS8452  -- TE-AS TE-AS

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb 10 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 10 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202102200.q1AM00W4055381@wattle.apnic.net>

This report has been generated at Fri Feb 10 21:12:37 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        03-02-12    397625      230154
        04-02-12    398129      229956
        05-02-12    397792      230223
        06-02-12    397996      230469
        07-02-12    398139      230795
        08-02-12    398862      230787
        09-02-12    399071      230735
        10-02-12    398957      231557


AS Summary
         40190  Number of ASes in routing system
         16851  Number of ASes announcing only one prefix
          3442  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      109981184  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 10Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     399616   231551   168065    42.1%   All ASes

AS6389      3442      204     3238    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3432     1743     1689    49.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS18566     2093      413     1680    80.3%   COVAD - Covad Communications
                                               Co.
AS4766      2475     1002     1473    59.5%   KIXS-AS-KR Korea Telecom
AS22773     1510      118     1392    92.2%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS2118      1385       14     1371    99.0%   RELCOM-AS OOO "NPO Relcom"
AS4323      1611      387     1224    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1659      497     1162    70.0%   NET Servicos de Comunicao S.A.
AS4755      1531      402     1129    73.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1871      791     1080    57.7%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS7552      1393      358     1035    74.3%   VIETEL-AS-AP Vietel
                                               Corporation
AS10620     1751      739     1012    57.8%   Telmex Colombia S.A.
AS19262     1386      397      989    71.4%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7303      1263      371      892    70.6%   Telecom Argentina S.A.
AS26615      897       33      864    96.3%   Tim Celular S.A.
AS8402      1645      824      821    49.9%   CORBINA-AS OJSC "Vimpelcom"
AS4808      1149      342      807    70.2%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8151      1477      675      802    54.3%   Uninet S.A. de C.V.
AS18101      952      156      796    83.6%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1014      329      685    67.6%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS9498       885      204      681    76.9%   BBIL-AP BHARTI Airtel Ltd.
AS9394       882      207      675    76.5%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS7545      1643      979      664    40.4%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS3356      1096      455      641    58.5%   LEVEL3 Level 3 Communications
AS30036     1384      761      623    45.0%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17974     1728     1119      609    35.2%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS17676      681       75      606    89.0%   GIGAINFRA Softbank BB Corp.
AS15557     1095      510      585    53.4%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS4804       660       95      565    85.6%   MPX-AS Microplex PTY LTD
AS3549       986      430      556    56.4%   GBLX Global Crossing Ltd.

Total      44976    14630    30346    67.5%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        37.114.8.0/21        AS20608 T-SYSTEMS-ITALIA-AS T-Systems Italia Autonomous System
        37.114.192.0/18      AS51074 MABNA Gostaresh Ertebatate Mabna Co. Ltd.
        37.115.0.0/16        AS15895 KSNET-AS Kyivstar GSM
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        98.159.96.0/20       AS46975 
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        176.108.32.0/20      AS31042 SERBIA-BROADBAND-AS Serbia BroadBand-Srpske Kablovske mreze d.o.o.
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel Limited.
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.80.128.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.80.130.0/23      AS9260  MULTINET-PK NSP,ISP,HFC,DSL,DIALUP,Data Network Connectivity solutions,
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - KNOLOGY,  Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From mansaxel at besserwisser.org  Fri Feb 10 16:24:39 2012
From: mansaxel at besserwisser.org (=?iso-8859-1?Q?M=E5ns?= Nilsson)
Date: Fri, 10 Feb 2012 23:24:39 +0100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjiivbph.wl%randy@psg.com>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
Message-ID: <20120210222435.GF27669@besserwisser.org>

On Fri, Feb 10, 2012 at 09:29:30AM -0800, Randy Bush wrote:
> > So because of phishing, nobody should send messages with URLs in them?
> 
> more and more these days, i have taken to not clicking the update messages, 
> but going to the web site manyually to get it.

Web site? With the RIPE db one communicates using PGP email for data
in and port 43 queries for data out. The web site is for signing up to
RIPE meetings. Yes, RIPE NCC, I think that you put a lot of resources into
new fancy guish junk, and tend to forget how things should be done, and
some things -- the horror! -- are only possible to accomplish using the
web site and some forgotten password. To me, that is much more annoying
than the side projects that people are griping over.

</rant>
 
> waaaay to much phishing, and it is getting subtle and good.

Indeed. 

-- 
M?ns


From rsk at gsp.org  Fri Feb 10 17:46:30 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Fri, 10 Feb 2012 18:46:30 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210173701.GA79917@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com>
 <20120210173701.GA79917@ussenterprise.ufp.org>
Message-ID: <20120210234630.GA23186@gsp.org>

On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
> Remind me again why we live in this sad word Randy (correcly) described?

Because banks and many other institutions have prioritized all-singing,
all-dancing, bloated, horribly-badly-marked-up HTML email with
"stationary" and logos and pictures and web bugs far, FAR ahead of
security, privacy, accessability, portability and other -ilities that
I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
accounts that will get hosed or *their* money that will get lost.
Things like that only happen to the little people.

See also this related note:

	http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html

---rsk


From brandon at rd.bbc.co.uk  Fri Feb 10 18:09:37 2012
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Sat, 11 Feb 2012 00:09:37 GMT
Subject: Dear RIPE: Please don't encourage phishing
Message-ID: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>

> So it's necessary to throw the baby out with the bathwater, and tell them
> never to click on a link...

That baby was ugly anyway

brandon


From jeff-kell at utc.edu  Fri Feb 10 18:12:37 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 10 Feb 2012 19:12:37 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120210234630.GA23186@gsp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <20120210234630.GA23186@gsp.org>
Message-ID: <4F35B275.5000605@utc.edu>

There used to be the old programming benchmark of how large a "program"
(in lines, as well as compiled bytes) it took to say "Hello, world."

The 21st century benchmark might now well be the size of a "Hello,
world" e-mail.

Or a web page with a similar statement.

Jeff

On 2/10/2012 6:46 PM, Rich Kulawiec wrote:
> On Fri, Feb 10, 2012 at 09:37:01AM -0800, Leo Bicknell wrote:
>> Remind me again why we live in this sad word Randy (correcly) described?
> Because banks and many other institutions have prioritized all-singing,
> all-dancing, bloated, horribly-badly-marked-up HTML email with
> "stationary" and logos and pictures and web bugs far, FAR ahead of
> security, privacy, accessability, portability and other -ilities that
> I'm too lazy to enumerate just now.  Besides: it's not like it's *their*
> accounts that will get hosed or *their* money that will get lost.
> Things like that only happen to the little people.
>
> See also this related note:
>
> 	http://www.mail-archive.com/infowarrior%40attrition.org/msg08436.html
>
> ---rsk
>



From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 10 18:19:46 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 09:19:46 +0900
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <20120210214341.GB88812@ussenterprise.ufp.org>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
Message-ID: <4F35B422.1020403@necom830.hpcl.titech.ac.jp>

Leo Bicknell wrote:

> UPNP, NAT-PMP, the ability to enter static bypasses (DMZ's, NAT
> passthrough), combined with the problems of some applications that
> make thousands of TCP connections in a short order eating up ports
> makes it a nightmare to manage and debug.

The applications can simply be debugged to use socket option
of REUSEPORT.

I pointed it out so along with static port mapping at the last
meeting in "Track: IPv4 runout, Doing More with Less".

> Of course, if they are
> doing illegal things you'd better keep some detailed records of who did
> what when a LEO comes knocking.

Are you saying we MUST record all the IP addresses and
port numbers of all peers of your customers to prevent
illegal things?

If so, we have to do so, even if you are not using NAT,
I'm afraid.

If not and we only have to have information on which
port is used by which customer, static port mapping
is just fine.

Anyway, developers of virus software will be quite
cooperative to use REUSEPORT, to hide symptoms that
the virus software is installed.

> The key to a low cost service is making it as low cost as possible,
> moving the NAT inside the carrier will had a huge amount of headache and
> support costs, not what you want.

Use NAT with static port mapping (and same port numbers are used
in and out), there is no headache and support cost caused by NAT.

> A possibly relevant question with IPv4 exhaustion coming is could you
> make this service IPv6 only so you don't have to find IPv4 addresses for
> it.

IPv6 means considerably more amount of headache and
support costs than using NAT cleverly and simply.

						Masataka Ohta


From lstewart at superb.net  Fri Feb 10 18:24:11 2012
From: lstewart at superb.net (Landon Stewart)
Date: Fri, 10 Feb 2012 16:24:11 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
Message-ID: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>

On 10 February 2012 16:09, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

From randy at psg.com  Fri Feb 10 18:45:34 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 10 Feb 2012 16:45:34 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <m27gzu9p01.wl%randy@psg.com>

> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.

idn has made this unsafe

randy


From bicknell at ufp.org  Fri Feb 10 19:00:36 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 10 Feb 2012 17:00:36 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
 <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
Message-ID: <20120211010036.GA95294@ussenterprise.ufp.org>

In a message written on Sat, Feb 11, 2012 at 09:19:46AM +0900, Masataka Ohta wrote:
> The applications can simply be debugged to use socket option
> of REUSEPORT.

"Simple" is subjective.  Keep in mind many users will have a home
gateway which also does NAT.  And indeed double NAT in the home (router
doing NAT, third party device doing NAT) is depressingly common.  That
means some of the troubleshooting will be via a triple-NAT if the
carrier is performing the conversion.

> Are you saying we MUST record all the IP addresses and
> port numbers of all peers of your customers to prevent
> illegal things?

If the carrier NAT's, maybe.

Today port information need not be stored, because an IP is assigned
to a customer.  Law enforcement can come request who was using an
IP, and be given the customer information.  It's what everyone has
come to expect.

It's also not just what is legally required, but what is administratively
friendly.  Will the law say you have to track ports with carrier
grade NAT, probably not.  Will law enforcement spend a lot more
time with your staff trying to track down bad people costing you
time and money if you don't, probably.

Large operations tend to find that having a cost effective and staff
time effective way to deal with law enforcement is very important.

> IPv6 means considerably more amount of headache and
> support costs than using NAT cleverly and simply.

When IPv4 addresses are selling for $100 an address that equation
changes quickly.  That day may be only a few months or years off.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/d2b38012/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 10 19:16:36 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 10:16:36 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m27gzu9p01.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
Message-ID: <4F35C174.1090605@necom830.hpcl.titech.ac.jp>

Randy Bush wrote:

>> My $0.02 on this issue is if the message is rich text I hover over the link
>> and see where it actually sends me.
> 
> idn has made this unsafe

I pointed it out at IETF Munich in 1997 that with an example of:

	MICROSOFT.COM

where 'C' of MICROSOFT is actually a Cyrillic character.

But, people insisted working on useless IDN.

						Masataka Ohta


From choprboy at dakotacom.net  Fri Feb 10 19:25:48 2012
From: choprboy at dakotacom.net (Adrian)
Date: Fri, 10 Feb 2012 18:25:48 -0700
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <201202101825.48610.choprboy@dakotacom.net>

On Friday 10 February 2012 17:24, Landon Stewart wrote:
> My $0.02 on this issue is if the message is rich text I hover over the link
> and see where it actually sends me.  If I don't know what that link is then
> I don't click it.


Oh really? How about trying this.... Go to Google and search "is my url safe":
http://www.google.com/search?q=is+my+url+safe

Now hover over that second link reportedly to faq.ssl.com and look at what 
your browser reports:
http://faq.ssl.com/article.aspx?id=10068

Now look at the page code or copy/paste the URL somewhere else... Where does 
that link really go?
....
http://www.google.com/url?q=http://faq.ssl.com/article.aspx%3Fid%3D10068&sa=U&ei=JcI1T_DRKJDXiAKauoSvCg&ved=0CBgQFjAB&usg=AFQjCNHSmrhtgWQczEe1j0LhdMdUW5x4LA

So much for looking at what mouse-over shows....


Adrian



From joe at nethead.com  Fri Feb 10 19:36:44 2012
From: joe at nethead.com (Joe Hamelin)
Date: Fri, 10 Feb 2012 17:36:44 -0800
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <CAO0-hXaeAXKqddyGDhwK662HfWGaknR6BovxJcQehtNb_sq09Q@mail.gmail.com>

On Fri, Feb 10, 2012 at 1:19 PM, Eric J Esslinger <eesslinger at fpu-tn.com>wrote:

> We're toying with the idea of a low bitrate 'lifeline' internet on our
> cable system, maybe even bundled with a certain level of cable service.
>
> First question, if you happen to be doing something like this, what bit
> rates are you providing.
>

Well, a lifeline telephone is effectively 64kb/s, up and down.  Makes me
remember when I had my first ISDN line and was happy to get beyond dial-up
rates.


> Second question, though 'real' internet customers all get real IP's, what
> would you think of doing something like this with 'large scale' nat
> instead. Understand, we're only talking about basic internet, something
> like a 256k/96k (or similar) connect, not something that would be used by a
> serious user. (One thing we are looking at is some older dial up users we
> still have, most of which could go onto cable just fine but don't want to
> pay the price).
>

Force SMTP to something sane, block all the 139, etc. MS ports.  Basic web,
telnet, and ssh.  Set it up like a coffee house.  Use a proxy and make them
register.  It's not like they are chatting 911, ya know.  If they have NAT
issues, then they need a real account.  If they can get to google,
wikimedia, or what ever a high school student needs to research papers,
then they have what they need for a life-line.  Let chat protocols through,
that's low bandwidth.  I'm guessing that this is done as a favor to the
customer that won't/can't pay for a real account.  But let them know it's
not a real account.  This is just to give them a taste of real IP and not a
solution to all their problems.  Shove them a NATted DHCP address and if
they can't figure that out then refer them to the local wizkid or a better
plan with support.  Let them know up front that this is a basic service and
don't expect phone support.  If you're a cable company then they can call
and say the cable is out.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From Valdis.Kletnieks at vt.edu  Fri Feb 10 20:41:41 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 10 Feb 2012 21:41:41 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Fri, 10 Feb 2012 16:24:11 PST."
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <136898.1328928101@turing-police.cc.vt.edu>

On Fri, 10 Feb 2012 16:24:11 PST, Landon Stewart said:
> I don't click it.  Not sure how long it's going to take, probably a
> generation, for people to use some sense before mindlessly clicking on
> stuff.

Only if you find a way to keep more idiots from being born. :)

I don't think anybody wants to go there.  At least not on this list.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120210/7fb5c008/attachment.bin>

From Vinny_Abello at Dell.com  Fri Feb 10 22:47:42 2012
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Sat, 11 Feb 2012 04:47:42 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
Message-ID: <FD9B2CB2B33E394FAE3B74669547605712B0059E@DFWX10HMPTC01.AMER.DELL.COM>

Unfortunately that's not under control of those businesses. This plain text email you sent comes across with clickable mailto and http links in your signature in most modern email clients despite you having sent it in plain text. "Helpful" email program defaults won't force people to copy and paste the URL. They just create the hyperlink for people based on the pattern in the plain text message. It seems anything beginning with www or http(s):// will be converted to a clickable link out of convenience to the user. It's always that endless struggle of security vs. convenience...

-Vinny

-----Original Message-----
From: Landon Stewart [mailto:lstewart at superb.net] 
Sent: Friday, February 10, 2012 7:24 PM
To: Brandon Butterworth
Cc: nanog at nanog.org
Subject: Re: Dear RIPE: Please don't encourage phishing

On 10 February 2012 16:09, Brandon Butterworth <brandon at rd.bbc.co.uk> wrote:

> > So it's necessary to throw the baby out with the bathwater, and tell them
> > never to click on a link...
>
> That baby was ugly anyway
>
>
HAHAHA.

My $0.02 on this issue is if the message is rich text I hover over the link
and see where it actually sends me.  If I don't know what that link is then
I don't click it.  Not sure how long it's going to take, probably a
generation, for people to use some sense before mindlessly clicking on
stuff.

Banks and businesses that keep sensitive information in a protected area on
the web for you should start sending messages in PLAIN TEXT so you have to
copy/paste the link if you don't already have it book marked or don't want
to type it.  Sure it's not all flashy and there's no nice pictures and junk
but if you get an email from your bank that's not in plain text and
contains hyperlinks then you'll know it's fake before you even read it.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net


From carlos at race.com  Sat Feb 11 00:54:29 2012
From: carlos at race.com (Carlos Alcantar)
Date: Sat, 11 Feb 2012 06:54:29 +0000
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
Message-ID: <CB5B4FED.5DB2F%carlos@race.com>

You might also want to think about it's not to far off that the gov starts
supplementing those cost of these users, with all the changes being made
in USF.  Possible why comcast has started taking on these users to get a
good head count.  Does anyone know with these low end comcast package does
the user still need to pay the $5 modem rental fee?

Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Eric J Esslinger <eesslinger at fpu-tn.com>
Date: Fri, 10 Feb 2012 15:19:24 -0600
To: "nanog at nanog.org" <nanog at nanog.org>
Subject: couple of questions regarding 'lifeline' and large scale nat...

We're toying with the idea of a low bitrate 'lifeline' internet on our
cable system, maybe even bundled with a certain level of cable service.

First question, if you happen to be doing something like this, what bit
rates are you providing.
Second question, though 'real' internet customers all get real IP's, what
would you think of doing something like this with 'large scale' nat
instead. Understand, we're only talking about basic internet, something
like a 256k/96k (or similar) connect, not something that would be used by
a serious user. (One thing we are looking at is some older dial up users
we still have, most of which could go onto cable just fine but don't want
to pay the price).

Also when I say large scale, I doubt I'd have more than a few thousand
customers for this. We're not a large ISP/cable company by any means.

__________________________
Eric Esslinger
Information Services Manager - Fayetteville Public Utilities
http://www.fpu-tn.com/
(931)433-1522 ext 165

This message may contain confidential and/or proprietary information and
is intended for the person/entity to whom it was originally addressed. Any
use by others is strictly prohibited.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5571 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/c7d34b28/attachment-0001.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 02:19:57 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 11 Feb 2012 17:19:57 +0900
Subject: couple of questions regarding 'lifeline' and large scale nat...
In-Reply-To: <20120211010036.GA95294@ussenterprise.ufp.org>
References: <D2D37F15EBBD524693E9F3CB32D02080430CA6AE5A@exchange.corp.fpu-tn.com>
 <20120210214341.GB88812@ussenterprise.ufp.org>
 <4F35B422.1020403@necom830.hpcl.titech.ac.jp>
 <20120211010036.GA95294@ussenterprise.ufp.org>
Message-ID: <4F3624AD.9080805@necom830.hpcl.titech.ac.jp>

Leo Bicknell wrote:

>> The applications can simply be debugged to use socket option
>> of REUSEPORT.
> 
> "Simple" is subjective. 

To "the problems of some applications that make thousands of
TCP connections in a short order eating up ports makes it a
nightmare to manage and debug", I gave you an objectively
simple answer.

> Keep in mind many users will have a home
> gateway which also does NAT.  And indeed double NAT in the home (router
> doing NAT, third party device doing NAT) is depressingly common.

Double NAT does not make things worse, as long as "static
bypasses" exist, which is your assumption.

OTOH, the double NAT, some of which may or may not IPv6 capable,
makes IPv6 deployment hard, if not impossible.

> That
> means some of the troubleshooting will be via a triple-NAT if the
> carrier is performing the conversion.

The carrier should have a trouble shooting equipment within
its private network, which means trouble shooting over
the double NAT with IPv4 is much easier than with IPv6.

>> Are you saying we MUST record all the IP addresses and
>> port numbers of all peers of your customers to prevent
>> illegal things?
> 
> If the carrier NAT's, maybe.

> Today port information need not be stored, because an IP is assigned
> to a customer.

Wrong.

With your requirement to record IP address of peers, a carrier
must record port numbers of peers of its customer, if some
carriers of the peers use NAT.

Note that there already are carriers who use NAT.

Note also that, recording peers' IPv4 address needs 4Bs,
recording peers' IPv4 addresses and port numbers needs 6Bs
and recording peers' IPv6 addresses needs 16Bs.

> Law enforcement can come request who was using an
> IP, and be given the customer information.  It's what everyone has
> come to expect.

That's completely different from recording information of peers
of your customer.

> Large operations tend to find that having a cost effective and staff
> time effective way to deal with law enforcement is very important.

True. And, see the double NAT example you mentioned.

>> IPv6 means considerably more amount of headache and
>> support costs than using NAT cleverly and simply.
> 
> When IPv4 addresses are selling for $100 an address that equation
> changes quickly.  That day may be only a few months or years off.

Sorry, are you seriously saying that paying $100 once for a
customer is so much expense for a carrier?

Even if so, the carrier should deploy NAT, because $100 is
paid only once for hundreds of customers.

Moreover, wide deployment of NAT will further reduce prices
of IPv4 addresses.


						Masataka Ohta


From sh.vahabzadeh at gmail.com  Sat Feb 11 04:09:16 2012
From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh)
Date: Sat, 11 Feb 2012 13:39:16 +0330
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
Message-ID: <0C2F9F90-97C9-4425-A5F0-E69ED3B78298@gmail.com>

It is not accessible to with XMPP, yahoo google none of them is not accessible from Iran.
I have not try obfsproxy but as a ordinary connection we do not have https :)

--
Regards,
Shahab Vahabzadeh, Network Engineer and System Administrator

PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90

On Feb 10, 2012, at 11:37 PM, Marshall Eubanks <marshall.eubanks at gmail.com> wrote:

> And in response
> 
> http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/
> 
> (quoting) :
> 
> ?Basically, say you want to look like an XMPP chat instead of SSL,? he
> writes to me, referring to a protocol for instant messaging as the
> decoy for the encrypted SSL communications. ?Obfsproxy should start
> up, you choose XMPP, and obfsproxy should emulate XMPP to the point
> where even a sophisticated [deep packet inspection] device cannot find
> anything suspicious.?
> 
> Regards
> Marshall
> 
> On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
> <sh.vahabzadeh at gmail.com> wrote:
>> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>> 
>> --
>> Regards,
>> Shahab Vahabzadeh, Network Engineer and System Administrator
>> 
>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81  C2EE 76A2 46C2 5367 BF90
>> 
>> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>> 
>>> Haven't seen this come through on NANOG yet:
>>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>> 
>>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>>> stopped?
>>> 
>> 


From neil at tonal.clara.co.uk  Sat Feb 11 10:04:02 2012
From: neil at tonal.clara.co.uk (Neil Harris)
Date: Sat, 11 Feb 2012 16:04:02 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
Message-ID: <4F369172.501@tonal.clara.co.uk>

On 11/02/12 01:16, Masataka Ohta wrote:
> Randy Bush wrote:
>
>>> My $0.02 on this issue is if the message is rich text I hover over the link
>>> and see where it actually sends me.
>> idn has made this unsafe
> I pointed it out at IETF Munich in 1997 that with an example of:
>
> 	MICROSOFT.COM
>
> where 'C' of MICROSOFT is actually a Cyrillic character.
>
> But, people insisted working on useless IDN.
>
> 						Masataka Ohta
>
>


Techniques to deal with this sort of spoofing already exist: see

http://www.mozilla.org/projects/security/tld-idn-policy-list.html

for one quite effective approach.

-- Neil




From randy at psg.com  Sat Feb 11 11:09:25 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 11 Feb 2012 09:09:25 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F369172.501@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
Message-ID: <m2sjihpa9m.wl%randy@psg.com>

>>>> My $0.02 on this issue is if the message is rich text I hover over the link
>>>> and see where it actually sends me.
>>> idn has made this unsafe
> Techniques to deal with this sort of spoofing already exist: see
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> for one quite effective approach.

and grandma is gonna use this?  with internet exploder or safari?

let's try to remember that there are normal human beings on the net
these years (bummer that, eh?), and this list is kind of about serving
them.

randy


From tknchris at gmail.com  Sat Feb 11 11:13:14 2012
From: tknchris at gmail.com (chris)
Date: Sat, 11 Feb 2012 12:13:14 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2sjihpa9m.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
Message-ID: <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>

The internet was way cooler before that

chris
On Feb 11, 2012 12:09 PM, "Randy Bush" <randy at psg.com> wrote:

> >>>> My $0.02 on this issue is if the message is rich text I hover over
> the link
> >>>> and see where it actually sends me.
> >>> idn has made this unsafe
> > Techniques to deal with this sort of spoofing already exist: see
> > http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> > for one quite effective approach.
>
> and grandma is gonna use this?  with internet exploder or safari?
>
> let's try to remember that there are normal human beings on the net
> these years (bummer that, eh?), and this list is kind of about serving
> them.
>
> randy
>
>

From javier at kjsl.org  Sat Feb 11 11:18:15 2012
From: javier at kjsl.org (Javier Henderson)
Date: Sat, 11 Feb 2012 12:18:15 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <CAKnNFz8vf4ue_pvisWHmOkQRWH-pp15ncL08YYBRtUAbowz=OA@mail.gmail.com>
Message-ID: <710F66C0-9A26-4350-AA18-76FD161DB976@kjsl.org>


On Feb 11, 2012, at 12:13 PM, chris wrote:

> The internet was way cooler before that

Yes, and a lot of us could run open relays on our SMTP servers to help each other out, and a full usenet feed fit on a plain ol' 9600 baud link.

But no way I could have at home the kind of bandwidth I can get today for a very reasonable price, and so on.

-jav



From Valdis.Kletnieks at vt.edu  Sat Feb 11 12:28:57 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 11 Feb 2012 13:28:57 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sat, 11 Feb 2012 09:09:25 PST."
 <m2sjihpa9m.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
Message-ID: <170508.1328984937@turing-police.cc.vt.edu>

On Sat, 11 Feb 2012 09:09:25 PST, Randy Bush said:
> >>>> My $0.02 on this issue is if the message is rich text I hover over the link
> >>>> and see where it actually sends me.
> >>> idn has made this unsafe
> > Techniques to deal with this sort of spoofing already exist: see
> > http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> > for one quite effective approach.

Nice.  Basically, unless the TLD registrar has a public policy that basically says
"We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
all get displayed as xn--gobbledygook.

(The actual policy for the .UA registrar is more subtle. They *do* in fact
allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
users.  However, they require at least one character that's visually unique to
Cyrillic in the domain name.  They also don't allow mixed Cyrillic/Latin
scripts in one domain name).  Or so http://www.hostmaster.ua/idn/
tells me after Google Translate gets done with it. ;)

> and grandma is gonna use this?  with internet exploder or safari?

If the manufacturers of IE and Safari can't come up with a similar policy,
then the people at Mozilla can use "We protect you from malicious names"
as a marketing diffferentiation feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/851e32f4/attachment.bin>

From kmedcalf at dessus.com  Sat Feb 11 15:37:31 2012
From: kmedcalf at dessus.com (Keith Medcalf)
Date: Sat, 11 Feb 2012 14:37:31 -0700
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <FD9B2CB2B33E394FAE3B74669547605712B0059E@DFWX10HMPTC01.AMER.DELL.COM>
Message-ID: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>

> Unfortunately that's not under control of those businesses. This plain text
> email you sent comes across with clickable mailto and http links in your
> signature in most modern email clients despite you having sent it in plain
> text. "Helpful" email program defaults won't force people to copy and paste
> the URL. They just create the hyperlink for people based on the pattern in
> the plain text message. It seems anything beginning with www or http(s)://
> will be converted to a clickable link out of convenience to the user. It's
> always that endless struggle of security vs. convenience...

At least it is what is says, and the effect is precisely the same as if one copied and pasted the link into the browser.

What is truly evil is non text/plain email.  Anyone who permits or assists in the rendering of non-plaintext email deserves whatever befalls them -- and they should not be permitted zero-liability for their stupidity and ignorance.

They end-user is of course entitled to cross-claim against the manufacturer of the defective system or device which rendered the message in a deceptive way (such as Dell and Microsoft in particular).

---
()? ascii ribbon campaign against html e-mail
/\? www.asciiribbon.org





From richard.barnes at gmail.com  Sat Feb 11 15:50:10 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Sat, 11 Feb 2012 13:50:10 -0800
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
Message-ID: <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>

FWIW: A colleague in Iran was able to connect to a server in the US
using HTTPS on a non-standard port (9999).  It appears that the
Iranian government is not blocking TLS/HTTPS per se, but just port
443.  So in principle, if there were just some HTTPS proxies using
non-standard ports, then people would be able to get out.  At least
until (1) the addresses of the proxies become known to the regime, or
(2) they start blocking cross-border TLS altogether.

--Richard



On Fri, Feb 10, 2012 at 12:07 PM, Marshall Eubanks
<marshall.eubanks at gmail.com> wrote:
> And in response
>
> http://www.forbes.com/sites/andygreenberg/2012/02/10/as-iran-cracks-down-online-tor-tests-undetectable-encrypted-connections/
>
> (quoting) :
>
> ?Basically, say you want to look like an XMPP chat instead of SSL,? he
> writes to me, referring to a protocol for instant messaging as the
> decoy for the encrypted SSL communications. ?Obfsproxy should start
> up, you choose XMPP, and obfsproxy should emulate XMPP to the point
> where even a sophisticated [deep packet inspection] device cannot find
> anything suspicious.?
>
> Regards
> Marshall
>
> On Fri, Feb 10, 2012 at 2:03 PM, Shahab Vahabzadeh
> <sh.vahabzadeh at gmail.com> wrote:
>> Yes I am from Iran and outgoing TCP/443 has been stoped ;)
>>
>> --
>> Regards,
>> Shahab Vahabzadeh, Network Engineer and System Administrator
>>
>> PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 ?C2EE 76A2 46C2 5367 BF90
>>
>> On Feb 10, 2012, at 9:56 PM, Ryan Malayter <malayter at gmail.com> wrote:
>>
>>> Haven't seen this come through on NANOG yet:
>>> http://arstechnica.com/tech-policy/news/2012/02/iran-reportedly-blocking-encrypted-internet-traffic.ars
>>>
>>> Can anyone with the ability confirm that TCP/443 traffic from Iran has
>>> stopped?
>>>
>>
>


From alan at clegg.com  Sat Feb 11 16:56:52 2012
From: alan at clegg.com (Alan Clegg)
Date: Sat, 11 Feb 2012 17:56:52 -0500
Subject: Iran blocking essentially all encyrpted protocols
In-Reply-To: <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>
References: <b94086e9-fc46-4c7c-9034-b24123b46934@ir9g2000pbc.googlegroups.com>
 <D4CC1941-285F-46E6-BC5B-E426A6BB7657@gmail.com>
 <CAJNg7VJBtM_bNOto0gsZzxMNjbUNSXFOhqACxoZAaVb+-asYCQ@mail.gmail.com>
 <CACB24Ms1afYu-CTXYFw0nQ-yMF2uWvHsKqx9f21gDk5-YY+hiA@mail.gmail.com>
Message-ID: <4F36F234.8010106@clegg.com>

On 2/11/2012 4:50 PM, Richard Barnes wrote:
> FWIW: A colleague in Iran was able to connect to a server in the US
> using HTTPS on a non-standard port (9999).  It appears that the
> Iranian government is not blocking TLS/HTTPS per se, but just port
> 443.  So in principle, if there were just some HTTPS proxies using
> non-standard ports, then people would be able to get out.  At least
> until (1) the addresses of the proxies become known to the regime, or
> (2) they start blocking cross-border TLS altogether.

Or applications (and providers) knew how to use SRV records...

AlanC
-- 
alan at clegg.com | 1.919.355.8851

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/900bae32/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 18:09:22 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 09:09:22 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F369172.501@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
Message-ID: <4F370332.4050709@necom830.hpcl.titech.ac.jp>

Neil Harris wrote:

> Techniques to deal with this sort of spoofing already exist: see
> 
> http://www.mozilla.org/projects/security/tld-idn-policy-list.html

It does not make sense that .COM allows Cyrillic characters:

http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html

i script of a domain name is Cyrillic.

Domain names do not have such property as script.

Is the following domain name:

	CCC.COM

Latin or Cyrillic?

> for one quite effective approach.

The only reasonable thing to do is to disable so called
IDN.

					Masataka Ohta

PS

Isn't it obvious from the page you referred that IDN is
not internationalization but an uncoordinated
collection of poor localizations?


From mysidia at gmail.com  Sat Feb 11 18:10:03 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 11 Feb 2012 18:10:03 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
Message-ID: <CAAAwwbV-MXyvaXbnvEgdTHTtBf9hsk3SzLBLN46a8z9ed4PSbw@mail.gmail.com>

On Fri, Feb 10, 2012 at 10:56 AM, Steven Bellovin <smb at cs.columbia.edu> wrote:

You know, clickable objects in automated business communications are a
standard practice,
the larger the organization sending the message,  the more complicated
and annoying their standard e-mail template full of HTML eyecandy, the
more clickable links   to improve accessibility,  and  banks among the
worst offenders.
Those encourage phishing,   because  HTML just provides way too many
methods of  faking a URL,  or making a 'button'  or 'link'  go to
somewhere else besides what is suggested by the e-mail text.

All an e-mail user needs to do is click on one unknown link,  to  be
quietly diverted to a fake website,  that will then ask the user to
"change" a password;   it makes no difference whether the e-mail
itself is  about passwords or  a security issue or not.
Convincing the user to "log in" can be done while they are visiting
the fake website.



There are plenty of phishers that rely on convincing users to hit the
'reply' button and divulge sensitive info,  with no  clickable items
in the message  at all.

But this particular item from RIPE here appears to be a plain text message...
text/plain

The message from RIPE is darn benign, and does not really encourage
phishing moreso.
When was the last time you saw a phishing attempt in a  text/plain
e-mail showing the name of  a HTTPS location
on  the real organization's web site ?

If sending out a web address "encourages phishers",  then what are
they supposed to provide to make  sure maintainer users  can easily
and quickly change their password?

RIPEs not encouraging phishing by sending such a message.   MUA
developers who  included   text/html     MIME type support and support
creating clickable objects in a HTML message  have encouraged
convincing phishing  very much so.


What RIPE did there is a perfectly example of what should be done.
Send plain text e-mail with the URL location to review,  no  HTML
doodads.

They have no control of your e-mail client  that for some reason
perhaps turns a plaintext URL into something you can click.

> I received the enclosed note, apparently from RIPE (and the headers check out).
> Why are you sending messages with clickable objects that I'm supposed to use to
> change my password?
>


--
-JH


From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 19:25:53 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 10:25:53 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <170508.1328984937@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
Message-ID: <4F371521.7090809@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> (The actual policy for the .UA registrar is more subtle. They *do* in fact
> allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
> users.  However, they require at least one character that's visually unique to
> Cyrillic in the domain name.

Unique within what?

Is a Cyrillic character, which looks like Latin E with diaeresis,
a unique Cyrillic character?

Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma,
a unique Cyrillic character?

Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE",
a unique Greek character?

> They also don't allow mixed Cyrillic/Latin
> scripts in one domain name).

Is a Russian word containing no unique (unique to ASCII)
Cyrillic characters encoded as Latin character using ASCII,
even though a Russian word containing unique (whatever unique
means) Cyrillic character encoded as Cyrillic characters?

It is obvious that such confused scheme encourage phishing
a lot.

> If the manufacturers of IE and Safari can't come up with a similar policy,
> then the people at Mozilla can use "We protect you from malicious names"
> as a marketing diffferentiation feature.

The only protection is to disable IDN.

					Masataka Ohta


From johnl at iecc.com  Sat Feb 11 19:31:18 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 01:31:18 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <170508.1328984937@turing-police.cc.vt.edu>
Message-ID: <20120212013118.28066.qmail@joyce.lan>

>Nice.  Basically, unless the TLD registrar has a public policy that basically says
>"We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
>all get displayed as xn--gobbledygook.

More or less.  ICANN has been wrestling with the lookalike character
issue in domain names for about a decade.  I think it's fair to say
that everyone agrees that all solutions are less than totally
satisfactory.

R's,
John


From neil at tonal.clara.co.uk  Sat Feb 11 19:34:17 2012
From: neil at tonal.clara.co.uk (Neil Harris)
Date: Sun, 12 Feb 2012 01:34:17 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F370332.4050709@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
Message-ID: <4F371719.9030207@tonal.clara.co.uk>

On 12/02/12 00:09, Masataka Ohta wrote:
> Neil Harris wrote:
>
>> Techniques to deal with this sort of spoofing already exist: see
>>
>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
> It does not make sense that .COM allows Cyrillic characters:
>
> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>
> i script of a domain name is Cyrillic.
>
> Domain names do not have such property as script.
>
> Is the following domain name:
>
> 	CCC.COM
>
> Latin or Cyrillic?
>
>> for one quite effective approach.
> The only reasonable thing to do is to disable so called
> IDN.
>
> 					Masataka Ohta
>
> PS
>
> Isn't it obvious from the page you referred that IDN is
> not internationalization but an uncoordinated
> collection of poor localizations?
>

I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
safer, given that it already exists.

Lots of people have thought about this quite carefully. See RFC 4290 for
a technical discussion of the thinking behind this policy, and RFC 5992
for a policy mechanism designed to resolve the problem you raised in
your example above.

You will notice that the .com domain does not appear on the Mozilla IDN
whitelist.

-- N.





From sven at cb3rob.net  Sat Feb 11 21:34:58 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 03:34:58 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>

yes, domain names that cannot be typed in with any keyboard/charset on any 
computer out there, excellent idea, devide and conquerer, i wonder who 
came up with that idiotic plan again, probably the ITU or one of their 
infiltrants in icann.

how about, we simply don't code any software or adjust any platforms to 
support it, if nobody uses it, no problem :P

(or just deliberately break it as its nothing more than a "devide and 
conquerer" attempt of the UN anyway ;)

On Sun, 12 Feb 2012, Neil Harris wrote:

> On 12/02/12 00:09, Masataka Ohta wrote:
>> Neil Harris wrote:
>>
>>> Techniques to deal with this sort of spoofing already exist: see
>>>
>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>> It does not make sense that .COM allows Cyrillic characters:
>>
>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>
>> i script of a domain name is Cyrillic.
>>
>> Domain names do not have such property as script.
>>
>> Is the following domain name:
>>
>> 	CCC.COM
>>
>> Latin or Cyrillic?
>>
>>> for one quite effective approach.
>> The only reasonable thing to do is to disable so called
>> IDN.
>>
>> 					Masataka Ohta
>>
>> PS
>>
>> Isn't it obvious from the page you referred that IDN is
>> not internationalization but an uncoordinated
>> collection of poor localizations?
>>
>
> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.
>
> Lots of people have thought about this quite carefully. See RFC 4290 for
> a technical discussion of the thinking behind this policy, and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.
>
> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.
>
> -- N.
>
>
>
>


From sven at cb3rob.net  Sat Feb 11 21:47:24 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 03:47:24 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>

as if it wasn't annoying enough already that some n00bs are using URI's 
with characters you can't type in (and in most cases don't even display 
correctly), icann has a better idea! hostnames you can't type in!

all those struggeling regimes that want to keep local control over our 
internets are gonna be so proud of them :P

(and that despite the fact that it's perfectly well possible to write -any 
language out there- in the first 7 bits of ascii)

yay, a step back in time, everyone back to their cave and write on the 
wall with a piece of stone in characters nobody can read!

so far for progress...

we used to develop stuff so that people could communicate with one 
another, whatever went wrong, when did it move to "preventing people from 
communicating with one another"...

i don't have keyboards with a million or so keys on it, do you?

and no, i don't know the alt-codes for weird russian or japanese crap.

if we wanted local shit only, we could just have stuck with tv and radio 
and telephones and fax machines.

so; we're not implementing any of that, we'll deliberately make any 
software we produce go nuts on it and cause errors all over the place, and 
we strongly urge any nerd out there to do exactly the same.


On Sun, 12 Feb 2012, Neil Harris wrote:

> On 12/02/12 00:09, Masataka Ohta wrote:
>> Neil Harris wrote:
>>
>>> Techniques to deal with this sort of spoofing already exist: see
>>>
>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>> It does not make sense that .COM allows Cyrillic characters:
>>
>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>
>> i script of a domain name is Cyrillic.
>>
>> Domain names do not have such property as script.
>>
>> Is the following domain name:
>>
>> 	CCC.COM
>>
>> Latin or Cyrillic?
>>
>>> for one quite effective approach.
>> The only reasonable thing to do is to disable so called
>> IDN.
>>
>> 					Masataka Ohta
>>
>> PS
>>
>> Isn't it obvious from the page you referred that IDN is
>> not internationalization but an uncoordinated
>> collection of poor localizations?
>>
>
> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.
>
> Lots of people have thought about this quite carefully. See RFC 4290 for
> a technical discussion of the thinking behind this policy, and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.
>
> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.
>
> -- N.
>
>
>
>


From Valdis.Kletnieks at vt.edu  Sat Feb 11 22:39:48 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 11 Feb 2012 23:39:48 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 03:47:24 GMT."
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
Message-ID: <191698.1329021588@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 03:47:24 GMT, Sven Olaf Kamphuis said:

> (and that despite the fact that it's perfectly well possible to write -any
> language out there- in the first 7 bits of ascii)

And it's *equally* possible to write "any language out there" using a
7-bit encoding of the Cyrillic character set.

Let me know how you'd enjoy doing that.

Oh, that would suck because Cyrillic isn't very similar to your native
character set?  Welcome to the way the vast majority of the world feels.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120211/5ec17531/attachment-0001.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 23:07:26 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 14:07:26 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F371719.9030207@tonal.clara.co.uk>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
Message-ID: <4F37490E.2000604@necom830.hpcl.titech.ac.jp>

Neil Harris wrote:

> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
> safer, given that it already exists.

It's like trying to make DES safer.

> Lots of people have thought about this quite carefully.

Not at all. They (including some Japanese) just wished IDN
work ignoring technical reality.

> See RFC 4290 for
> a technical discussion of the thinking behind this policy,

Technically speaking, there are several sets of frequently
used different but similar Japanese characters most people
do not distinguish so vigorously.

For example, "Sai" of "Saitoh", the tenth most frequent
Japanese family name, is represented by 4 similar but
different characters, which is distinguished by people
named "Saitoh" but not distinguished by most others,
which means phishing is unavoidable.

That is, RFC4290 covering such Japanese characters is
not technical from the beginning.

> and RFC 5992
> for a policy mechanism designed to resolve the problem you raised in
> your example above.

It is nothing more than a political statement, because
there is no reasonable way to use tables in Appendix A.

> You will notice that the .com domain does not appear on the Mozilla IDN
> whitelist.

Which means IDN can not be "Internationalized" at all and
selling IDN is nothing more than a fraud.

					Masataka Ohta


From Valdis.Kletnieks at vt.edu  Sat Feb 11 23:13:27 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 12 Feb 2012 00:13:27 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 10:25:53 +0900."
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
Message-ID: <192978.1329023607@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
> Valdis.Kletnieks at vt.edu wrote:
>
> > (The actual policy for the .UA registrar is more subtle. They *do* in fact
> > allow "U+0441 Cyrillic Small Letter ES" which is visually a C to us Latin-glyph
> > users.  However, they require at least one character that's visually unique to
> > Cyrillic in the domain name.
>
> Unique within what?
>
> Is a Cyrillic character, which looks like Latin E with diaeresis,
> a unique Cyrillic character?
>
> Is "CYRILLIC CAPITAL LETTER GHE", which looks like Greek Gamma,
> a unique Cyrillic character?
>
> Is Greek Gamma, which looks like "CYRILLIC CAPITAL LETTER GHE",
> a unique Greek character?

Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma
or Latin-E-with-diaresis, in domain names.  So you can't find a domain
bankname-containing-ghe.ua and spoof it with bankname-containing-gamma.ua.

I suppose you *could* find a 'greek-bankame-containing-gamma-and-only-chars-spoofable-in-cyrillic.gr'
and create a 'bankname-containing-ghe-and-cyrillic.ua'.  But quite frankly,
turning off IDN doesn't fix that problem - greekbank.gr is spoofable
by greekbank.ua and greekbank.com.  We *already* have companies
that will register 'foobar.com', 'foobar.net', 'foobar.org' and every other variant
they can to prevent squatters in the other TLDs.

> > They also don't allow mixed Cyrillic/Latin
> > scripts in one domain name).
>
> Is a Russian word containing no unique (unique to ASCII)
> Cyrillic characters encoded as Latin character using ASCII,
> even though a Russian word containing unique (whatever unique
> means) Cyrillic character encoded as Cyrillic characters?

No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'.
And due to the requirement that a cyrillic name have a special char
in it, you can's spoof an all-latin-chars.ua name.

> The only protection is to disable IDN.

You also have to ban the use of numbers in domain names, because you
need to prevent people being tricked by micros0ft.com and m1crosoft.com.

Good luck on that.

Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I
looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using,
the two are pixel-identical).

I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that.

It's interesting how some people are insisting that the IDN code has to be
*perfect* and make it *totally* impossible to create a phishable spoof of
a domain - but aren't willing to take the extra step of banning the characters
in the Latin Ascii charset that are spoofable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120212/bf03e128/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 11 23:25:05 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 14:25:05 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <191698.1329021588@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120338130.10731@a84-22-97-10.cb3rob.net>
 <191698.1329021588@turing-police.cc.vt.edu>
Message-ID: <4F374D31.7070508@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> (and that despite the fact that it's perfectly well possible to write -any
>> language out there- in the first 7 bits of ascii)

Yes, any language including FORTRAN.

> And it's *equally* possible to write "any language out there" using a
> 7-bit encoding of the Cyrillic character set.

Yes, any language including FORTRAN, because KOI-7, a
7-bit encoding of the Cyrillic character set, includes
all the uppercase Latin characters.

> Oh, that would suck because Cyrillic isn't very similar to your native
> character set?  Welcome to the way the vast majority of the world feels.

See how the vast majority of the world feels.

http://en.wikipedia.org/wiki/ISO/IEC_646
Since the portion of ISO/IEC 646 shared by all countries
(the "invariant set") specified only those letters used
in the ISO basic Latin alphabet,

						Masataka Ohta


From mysidia at gmail.com  Sat Feb 11 23:45:08 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sat, 11 Feb 2012 23:45:08 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <CAAAwwbV955qaaW7WisHf09GuxYVsw5dj8qXeHS16VXvpfVg-AA@mail.gmail.com>

On Sat, Feb 11, 2012 at 11:13 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Sun, 12 Feb 2012 10:25:53 +0900, Masataka Ohta said:
>> Valdis.Kletnieks at vt.edu wrote:
> It's interesting how some people are insisting that the IDN code has to be
> *perfect* and make it *totally* impossible to create a phishable spoof of
> a domain - but aren't willing to take the extra step of banning the characters
> in the Latin Ascii charset that are spoofable.
[snip]

There aren't really any characters in the latin ASCII charset that are
so spoofable.
0 and O,   |, I, l,  and 1  do come close,  depending on the font
chosen.     This is easily avoidable, because there are so few
spoofable characters,  you can easily just avoid using a spoofable one
in your domain name,   or register all variants.  These are minor
compared to the issues you get expanding the possible URL  character
sets to all unicode, through IDN support.

The extended character sets available under IDN provide a large number
of spoofable characters from various different charsets that are
indistinguishable.


For phishing to not be a serious risk, IDN implementations have to
have some kind of security policy.

A start would be: don't display IDN characters,   unless   they are
within a character set the user is expected to be familiar with.   For
example,  for a web browser that ships in North America,  only the
locally relevant IDN character sets should be enabled  by default.

If you should want to see IDN characters from Cyrillic character sets,
 or  Chinese Ideographs,
there should be a requirement you very deliberately install support
for specific character set you need.


Or install a localized browser that has the specific IDN charsets
allowed by policy.
There should also be a browser-enforced policy that different charsets
cannot be mixed in the same domain name.

Then any increase in phishing risk is limited to regions / language
localized  browsers
where the character set with spoofable characters makes sense  and is
in common use.


Ideally there  should be a table of every pair of characters that
"look somewhat similar to each other"   in every character set,   and
every registrar  ensuring  appearance uniqueness for every  new domain
registration.


--
-JH


From joelja at bogus.com  Sun Feb 12 00:57:36 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Sat, 11 Feb 2012 22:57:36 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
Message-ID: <4F3762E0.7050909@bogus.com>

On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
> yes, domain names that cannot be typed in with any keyboard/charset on
> any computer out there, excellent idea, devide and conquerer, i wonder
> who came up with that idiotic plan again, probably the ITU or one of
> their infiltrants in icann.

If it's worth shoveling blame indiscriminately it's worth informing
yourself a little about the timeline and the actors involved.

http://en.wikipedia.org/wiki/Internationalized_domain_name

> how about, we simply don't code any software or adjust any platforms to
> support it, if nobody uses it, no problem :P
> 
> (or just deliberately break it as its nothing more than a "devide and
> conquerer" attempt of the UN anyway ;)
> 
> On Sun, 12 Feb 2012, Neil Harris wrote:
> 
>> On 12/02/12 00:09, Masataka Ohta wrote:
>>> Neil Harris wrote:
>>>
>>>> Techniques to deal with this sort of spoofing already exist: see
>>>>
>>>> http://www.mozilla.org/projects/security/tld-idn-policy-list.html
>>> It does not make sense that .COM allows Cyrillic characters:
>>>
>>> http://www.iana.org/domains/idn-tables/tables/com_cyrl_1.0.html
>>>
>>> i script of a domain name is Cyrillic.
>>>
>>> Domain names do not have such property as script.
>>>
>>> Is the following domain name:
>>>
>>>     CCC.COM
>>>
>>> Latin or Cyrillic?
>>>
>>>> for one quite effective approach.
>>> The only reasonable thing to do is to disable so called
>>> IDN.
>>>
>>>                     Masataka Ohta
>>>
>>> PS
>>>
>>> Isn't it obvious from the page you referred that IDN is
>>> not internationalization but an uncoordinated
>>> collection of poor localizations?
>>>
>>
>> I'm not a flag-waver for IDN, so much as a proponent of ways to make IDN
>> safer, given that it already exists.
>>
>> Lots of people have thought about this quite carefully. See RFC 4290 for
>> a technical discussion of the thinking behind this policy, and RFC 5992
>> for a policy mechanism designed to resolve the problem you raised in
>> your example above.
>>
>> You will notice that the .com domain does not appear on the Mozilla IDN
>> whitelist.
>>
>> -- N.
>>
>>
>>
>>
> 



From drc at virtualized.org  Sun Feb 12 01:16:16 2012
From: drc at virtualized.org (David Conrad)
Date: Sat, 11 Feb 2012 23:16:16 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3762E0.7050909@bogus.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk>
 <4F370332.4050709@necom830.hpcl.titech.ac.jp>
 <4F371719.9030207@tonal.clara.co.uk>
 <Pine.LNX.4.64.1202120332570.10731@a84-22-97-10.cb3rob.net>
 <4F3762E0.7050909@bogus.com>
Message-ID: <D032D1F2-9696-4FE6-9E48-95A9B6925392@virtualized.org>

On Feb 11, 2012, at 10:57 PM, Joel jaeggli wrote:
> On 2/11/12 19:34 , Sven Olaf Kamphuis wrote:
>> yes, domain names that cannot be typed in with any keyboard/charset on
>> any computer out there, excellent idea, devide and conquerer, i wonder
>> who came up with that idiotic plan again, probably the ITU or one of
>> their infiltrants in icann.
> 
> If it's worth shoveling blame indiscriminately it's worth informing
> yourself a little about the timeline and the actors involved.
> 
> http://en.wikipedia.org/wiki/Internationalized_domain_name

You mean he's serious?  I thought he was just being an ironic troll...

Regards,
-drc




From mohta at necom830.hpcl.titech.ac.jp  Sun Feb 12 01:59:36 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sun, 12 Feb 2012 16:59:36 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <4F377168.9040903@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

> Doesn't actually matter, because the .ua registry isn't allowing Greek Gamma
> or Latin-E-with-diaresis, in domain names.

Such local conventions have nothing to do with internationalization.

> But quite frankly,
> turning off IDN doesn't fix that problem - greekbank.gr is spoofable
> by greekbank.ua and greekbank.com.

The problem is greekbank.gr is spoofable as greekbank.gr.

>> Is a Russian word containing no unique (unique to ASCII)
>> Cyrillic characters encoded as Latin character using ASCII,
>> even though a Russian word containing unique (whatever unique
>> means) Cyrillic character encoded as Cyrillic characters?
> 
> No, it means you get to pick 'all-latin-chars.ua' or 'all-cyrillic-chars.ua'.
> And due to the requirement that a cyrillic name have a special char
> in it, you can's spoof an all-latin-chars.ua name.

That "a cyrillic name have a special char in it" makes it
impossible to have a Cyrillic representation of an Ukrainian
word containing no special chars and is impractical.

>> The only protection is to disable IDN.
>
> You also have to ban the use of numbers in domain names, because you
> need to prevent people being tricked by micros0ft.com and m1crosoft.com.

No, the simple solution against such a simple problem is to
use proper font, because all the people know that '0' and 'o'
are different characters and treat them differently.

						Masataka Ohta


From vinny at abellohome.net  Sun Feb 12 03:44:13 2012
From: vinny at abellohome.net (Vinny Abello)
Date: Sun, 12 Feb 2012 04:44:13 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <4F3789ED.2030708@abellohome.net>

On 2/11/2012 4:37 PM, Keith Medcalf wrote:
>> Unfortunately that's not under control of those businesses. This
>> plain text email you sent comes across with clickable mailto and
>> http links in your signature in most modern email clients despite
>> you having sent it in plain text. "Helpful" email program
>> defaults won't force people to copy and paste the URL. They just
>> create the hyperlink for people based on the pattern in the plain
>> text message. It seems anything beginning with www or http(s):// 
>> will be converted to a clickable link out of convenience to the
>> user. It's always that endless struggle of security vs.
>> convenience...
> 
> At least it is what is says, and the effect is precisely the same
> as if one copied and pasted the link into the browser.
> 
> What is truly evil is non text/plain email.  Anyone who permits or
> assists in the rendering of non-plaintext email deserves whatever
> befalls them -- and they should not be permitted zero-liability for
> their stupidity and ignorance.
> 
> They end-user is of course entitled to cross-claim against the
> manufacturer of the defective system or device which rendered the
> message in a deceptive way (such as Dell and Microsoft in
> particular).

The average person won't know that "it is what it says" if it's
possible for it not to be... which I think is what you're driving at
with eliminating that as a possibility. And the effect is the same,
but the time to do it is different. I wouldn't want to have to use web
sites with no hyperlinks and I was expected to just copy and paste
every URL I wanted to follow into the address bar.

However, the vast majority of the Internet population (and human
beings in general) like aesthetically pleasing things and therefore
don't want to upgrade to mutt and lynx to be safe on the Internet.
HTML based email looks much better despite embedded hidden <evil>
tags. All recent email clients I've come across give you anti-phishing
warnings in one way or another if the URL does not match the actual
link. I honestly can't remember the last time I've seen a phishing
email because they are so easy to detect before they even get to your
inbox. Sure, you could also keep the HTML and disable the links (which
I've seen done), but then you inconvenience people. Things take too
long as it is now anyway despite the constant advancements we see
constantly. We need to speed technology up more and make them easier
AND safer. Technology needs to be unobtrusive to the end user and get
out of their way.

I personally don't believe the mantra of stripping away technology to
solve problems rather than applying technology and advancing standards
is the answer just because technology makes something dangerous for
the average consumer. Despite all the car fatalities on a yearly basis
and the constant safety advancements we have in the auto industry, I
have never heard people say we should get rid of cars and go back to
horses. Of course scam emails are much more prevalent than car
fatalities by far, but they're also less serious.

Most of the younger generation I know doesn't even use email. They
have it as a formality because things require it and exchange
everything via Facebook or video chat or IM... which simply means this
concern over the trickery of immoral scammers on the average
unsuspecting person will just shift mediums as has throughout history.
It's already prevalent on these mediums now.

Not sure what the jab at Dell was specifically other than the email
address I posted from originally. As far as I have seen, Dell doesn't
make email clients. That's like someone holding Sony/Samsung/LG liable
because their TV showed them a TV program they didn't want to see.

Anyway, just my $0.02 wrapped in rambling from a tired mind. Sorry if
some of this didn't make sense as a result. :)

-Vinny

P.S. I prefer plain-text email. ;)


From lists at internetpolicyagency.com  Sun Feb 12 09:30:40 2012
From: lists at internetpolicyagency.com (Roland Perry)
Date: Sun, 12 Feb 2012 15:30:40 +0000
Subject: PGP,
 S/MIME + SSL cross-reference (Was: Dear RIPE: Please don't encourage
 phishing)
In-Reply-To: <20120210213755.GA88812@ussenterprise.ufp.org>
References: <F08F9451-BE4A-4E04-8FA6-382ED92CF832@cs.columbia.edu>
 <CACB24MuxBvWwKATdV6FgKbSHAF=DzU6COYVmO5jXvjf+ue-gLg@mail.gmail.com>
 <m2sjiivbph.wl%randy@psg.com> <20120210173701.GA79917@ussenterprise.ufp.org>
 <4F355803.4040402@unfix.org> <20120210180106.GB80127@ussenterprise.ufp.org>
 <CAP-guGWh4+4kg1Jr1HLpF9voWYdrt9zyx9cRVXyZTL2i83etvw@mail.gmail.com>
 <20120210213755.GA88812@ussenterprise.ufp.org>
Message-ID: <Vw+8ueQgs9NPFAOQ@perry.co.uk>

In article <20120210213755.GA88812 at ussenterprise.ufp.org>, Leo Bicknell 
<bicknell at ufp.org> writes
>Hypothetically, I get an e-mail from ripe.ca

Or from ripen.cc which is one of their actual domains (used briefly as a 
url shortener).
-- 
Roland Perry


From johnl at iecc.com  Sun Feb 12 10:52:01 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 16:52:01 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <20120212165201.19594.qmail@joyce.lan>

>What is truly evil is non text/plain email.

Have we fallen through a time warp into 1996?

R's,
John
-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From cdel at firsthand.net  Sun Feb 12 11:23:49 2012
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Sun, 12 Feb 2012 17:23:49 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212013118.28066.qmail@joyce.lan>
References: <20120212013118.28066.qmail@joyce.lan>
Message-ID: <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>

The DNS "industry" is putting us a long way from when RFC 2826 was written. 

Christian
 
On 12 Feb 2012, at 01:31, John Levine wrote:

>> Nice.  Basically, unless the TLD registrar has a public policy that basically says
>> "We don't allow names with cyrillic C to collide with MICROSOFT", their hostnames
>> all get displayed as xn--gobbledygook.
> 
> More or less.  ICANN has been wrestling with the lookalike character
> issue in domain names for about a decade.  I think it's fair to say
> that everyone agrees that all solutions are less than totally
> satisfactory.
> 
> R's,
> John
> 



From johnl at iecc.com  Sun Feb 12 11:40:12 2012
From: johnl at iecc.com (John R. Levine)
Date: 12 Feb 2012 12:40:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
References: <20120212013118.28066.qmail@joyce.lan>
 <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
Message-ID: <alpine.BSF.2.00.1202121238280.21410@joyce.lan>

> The DNS "industry" is putting us a long way from when RFC 2826 was written.

That's true, but you can't just blow off the majority of people in the 
world who use languages that you can't write in the ASCII character set.

It's a hard problem.  I wouldn't say that ICANN's approach has been 
optimal, but I also wouldn't say there's an obvious solution they've 
missed.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From johnl at iecc.com  Sun Feb 12 12:06:25 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 18:06:25 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
Message-ID: <20120212180625.22375.qmail@joyce.lan>

>>What is truly evil is non text/plain email.
>
>Have we fallen through a time warp into 1996?

Evidently yes.  Look, it's a known-not-to-work SMTP callback:

><kmedcalf at dessus.com>:
>Connected to 69.172.205.65 but sender was rejected.
>Remote host said: 578 johnl at iecc.com address rejected with reverse-check

-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From rsk at gsp.org  Sun Feb 12 12:19:10 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Sun, 12 Feb 2012 13:19:10 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3789ED.2030708@abellohome.net>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net>
Message-ID: <20120212181910.GA16374@gsp.org>

On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
> All recent email clients I've come across give you anti-phishing
> warnings in one way or another if the URL does not match the actual link. 

Which is great, but doesn't help you if the URL and the link are:

	http://firstnationalbank.example.com

because a significant number of users will only see "firstnationalbank"
and ".com".

That's why I recommend that banks et.al. don't put *any* URLs in their
messages.  If they make this an explicit policy and pound it into the
heads of their customers that ANY message containing a URL is not from
them, and that they should always use their bookmarks to get to the
bank's site, then they're training their customers to be phish-resistant.

---rsk


From sven at cb3rob.net  Sun Feb 12 13:15:28 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 19:15:28 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <Pine.LNX.4.64.1202121913310.10731@a84-22-97-10.cb3rob.net>

>
> That's why I recommend that banks et.al. don't put *any* URLs in their
> messages.  If they make this an explicit policy and pound it into the
> heads of their customers that ANY message containing a URL is not from
> them, and that they should always use their bookmarks to get to the
> bank's site, then they're training their customers to be phish-resistant.

they do, and the next thing you know, someone in marketing sends out an 
email with an url -anyway-.

considering the fact that banks don't seem to like to be contacted by 
emails nor get replies (noreply at ...) i'd strongly suggest them not to use 
crappy obsolete SMTP at all but rather present the users with their 
messages they don't want to distribute by paper mail -after- logging into 
their online banking system, where they can use all the html, links, flash 
*kuch* etc they want.

>
> ---rsk
>


From sven at cb3rob.net  Sun Feb 12 13:22:06 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sun, 12 Feb 2012 19:22:06 +0000 (UTC)
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <Pine.LNX.4.64.1202121919390.10731@a84-22-97-10.cb3rob.net>

btw, i'm quite sure that -banks- of all things have the resources to just 
take the transaction part for consumers -off their pcs- and simply send 
them a dedicated device with an ethernet port to do the transactions on.

the same way they do in shops.

no more bothering with "omg what if they click a link, get phished and end 
up in the transaction interface", as there simply won't be a web based 
transaction interface.

guess the "its not allowed to cost anything" mentality of banks towards 
the internet is mostly gone (About time too ;) so they could consider 
other options besides "using the hardware that's allready there and owned 
by the customer (and full of virusses and spyware ;)"

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Sun, 12 Feb 2012, Rich Kulawiec wrote:

> On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
>> All recent email clients I've come across give you anti-phishing
>> warnings in one way or another if the URL does not match the actual link.
>
> Which is great, but doesn't help you if the URL and the link are:
>
> 	http://firstnationalbank.example.com
>
> because a significant number of users will only see "firstnationalbank"
> and ".com".
>
> That's why I recommend that banks et.al. don't put *any* URLs in their
> messages.  If they make this an explicit policy and pound it into the
> heads of their customers that ANY message containing a URL is not from
> them, and that they should always use their bookmarks to get to the
> bank's site, then they're training their customers to be phish-resistant.
>
> ---rsk
>


From jeff-kell at utc.edu  Sun Feb 12 13:27:56 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 12 Feb 2012 14:27:56 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <alpine.BSF.2.00.1202121238280.21410@joyce.lan>
References: <20120212013118.28066.qmail@joyce.lan>
 <146B95B9-51B5-4E2B-96AF-BEB7FB13FEC1@firsthand.net>
 <alpine.BSF.2.00.1202121238280.21410@joyce.lan>
Message-ID: <4F3812BC.4030604@utc.edu>

Heck, even Klingon made it to the private UTF-8 registry,
http://en.wikipedia.org/wiki/Klingon_writing_systems

:)

Jeff



From johnl at iecc.com  Sun Feb 12 13:47:56 2012
From: johnl at iecc.com (John Levine)
Date: 12 Feb 2012 19:47:56 -0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <Pine.LNX.4.64.1202121919390.10731@a84-22-97-10.cb3rob.net>
Message-ID: <20120212194756.26077.qmail@joyce.lan>

In article <Pine.LNX.4.64.1202121919390.10731 at a84-22-97-10.cb3rob.net> you write:
>btw, i'm quite sure that -banks- of all things have the resources to just 
>take the transaction part for consumers -off their pcs- and simply send 
>them a dedicated device with an ethernet port to do the transactions on.

More likely USB, but yes, a doozit with a small screen to display the
amount and recipient of a transaction and a verification code you type
in, and sufficient crypto to set up a secure channel back to the bank
would fix a lot of phishing.

I don't understand bank security at all.  HSBC recently sent me a
Digipass 270 with a 12 button keyboard and a one-line display that is
apparently able to do signatures, but all they use it for is a PIN.
That's helpful against password theft, but not MITM.

R's,
John


From vinny at abellohome.net  Sun Feb 12 13:49:12 2012
From: vinny at abellohome.net (Vinny Abello)
Date: Sun, 12 Feb 2012 14:49:12 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120212181910.GA16374@gsp.org>
References: <7bc08d666d6dc041a4fb5ab830a0fe02@mail.dessus.com>
 <4F3789ED.2030708@abellohome.net> <20120212181910.GA16374@gsp.org>
Message-ID: <4F3817B8.8050902@abellohome.net>

On 2/12/2012 1:19 PM, Rich Kulawiec wrote:
> On Sun, Feb 12, 2012 at 04:44:13AM -0500, Vinny Abello wrote:
>> All recent email clients I've come across give you anti-phishing 
>> warnings in one way or another if the URL does not match the
>> actual link.
> 
> Which is great, but doesn't help you if the URL and the link are:
> 
> http://firstnationalbank.example.com
> 
> because a significant number of users will only see
> "firstnationalbank" and ".com".
> 
> That's why I recommend that banks et.al. don't put *any* URLs in
> their messages.  If they make this an explicit policy and pound it
> into the heads of their customers that ANY message containing a URL
> is not from them, and that they should always use their bookmarks
> to get to the bank's site, then they're training their customers to
> be phish-resistant.

Yes, very true. I unfortunately see average people fall for these
types of things all the time. Ultimately, the issue is getting the end
user educated. However, I've also seen users get a message drilled
into their heads for 10 years that an email admin will never ask for
their passwords, yet they eagerly give them away to some random
scammer that says they need their password or their account will be
shut off, signed by "the email team"... and suddenly their email
account is spewing spam from random IP addresses all over the net.
<sigh> The weakest link is ultimately the person behind the device.
We're attempting to make technology fix stupid, which is often harder
for the people designing the technology. They would never think
sticking their hand down a garbage disposal is a good idea, but there
are people out there that do this. :( Likewise, a person wouldn't
click on a link if it's blatantly obvious the link doesn't point to
the real web site, right? :) Obviously no. To be very effective,
security design needs to assume the biggest threat to the security of
anything is the person on the good side of the fence who will open the
gate.

Lately, I get calls on a weekly basis from people trying to steal my
credit card from me. If I have time I like to have fun with them,
eating up their time so they have less of it to scam people who don't
know any better. (Look on Youtube for people doing this. It's
hilarious). These scammers have been around for at least 5 years or
longer and nobody has yet fixed this problem, which is also
astounding. As a result, customers who don't recognize the scam get
their credit card whacked with random charges because they didn't
think anything was wrong with giving away their credit card info and
social security number to a random stranger who calls them and claims
to be able to lower their interest rate. So at the same time making
people aware the real emails will not contain links, banks should be
doing a better job telling people not to give away their credit card
info to anyone in a situation similar to this. It should be better
handled by all banks and companies in genereal as a global security
education process. I don't believe it should be limited just to email
or Internet related usage of the bank or company's resources.

I'm probably not giving people enough credit, but social engineering
is likely the most effective hacking technique that exists because it
targets the weakest link and often works. That's currently the easiest
thing to target because security has improved so much over the years
on the technological end. I'm not sure about others, but the most
prevalent security threats I see today are vastly different than the
ones from ten to fifteen years prior.

-Vinny


From Valdis.Kletnieks at vt.edu  Sun Feb 12 13:55:48 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 12 Feb 2012 14:55:48 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 16:59:36 +0900."
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
Message-ID: <223001.1329076548@turing-police.cc.vt.edu>

On Sun, 12 Feb 2012 16:59:36 +0900, Masataka Ohta said:
> The problem is greekbank.gr is spoofable as greekbank.gr.

That would be the .gr registry's problem then.  They could take the same
solution as the .ua registry -force lowercase and allow all-latin or all-greek
names.

Oh, what do you know... they *do* do something similar.
https://grweb.ics.forth.gr/tomcat_docs/AP592_012_2011_.pdf
See page 5 and 6, in particular:

8. Any [.gr] Domain Names that are homographs of a [.gr] Domain Name
already assigned shall be automatically reserved for the Holder of the
above assigned [.gr] Domain Name and shall be activated following the
Holder's submission of an activation declaration to the Registry.

So how do you spoof greekbank.gr with greekbank.gr under those rules?

> No, the simple solution against such a simple problem is to
> use proper font, because all the people know that '0' and 'o'
> are different characters and treat them differently.

Well then, if all that's required is a "proper font",  what is the problem with
your Saitoh families? You said they were "represented by 4 similar but
different characters, which is distinguished by people named "Saitoh" but not
distinguished by most others,"  Why can't *they* use a "proper font" that makes
the difference between the 4 characters recognizable?  After all, *they*
know the 4 characters are different and can treat them differently, right?

(And no, it's *not* "different for kanji" - it's the exact same problem and you
know it.  In both cases, (I/l and your Sai issue), the problem is similar
glyphs.  Don't bother replying to suggest a fix for the lower-l/upper-I issue
unless the *same* fix applies to your Sai issue).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120212/cea7a669/attachment.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sun Feb 12 20:39:35 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 13 Feb 2012 11:39:35 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <223001.1329076548@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
Message-ID: <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

>> The problem is greekbank.gr is spoofable as greekbank.gr.
> 
> That would be the .gr registry's problem then.

As it is the problem of IDN, same problem exist everywhere.

> They could take the same
> solution as the .ua registry -force lowercase and allow all-latin or all-greek
> names.

DNS does not allow .ua registry force lowercase for ASCII.

> So how do you spoof greekbank.gr with greekbank.gr under those rules?

I merely used your example.

> Well then, if all that's required is a "proper font",  what is the problem with
> your Saitoh families?

All that's required is a "proper font" for ASCII.

Beyond ASCII, you almost automatically loss.

For example, in ISO8859-1 context, uppercase of 'y' with
diaeresis is not 'Y' with diaeresis, because there is no
'Y' with diaeresis in ISO8859-1, which is bad enough.

So, I can understand your attempt to insist on lowercase,
but it does not work because DNS does not allow it.

						Masataka Ohta


From smb at cs.columbia.edu  Sun Feb 12 21:22:18 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Sun, 12 Feb 2012 22:22:18 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <192978.1329023607@turing-police.cc.vt.edu>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
Message-ID: <16B9F1F7-DB0B-42DC-B5BC-14FCF9FA32CB@cs.columbia.edu>

> 
> 
> Oh, and 'i' and 'l' need to be banned as well, because a san-serif uppercase I
> looks a lot like a san-serif lowercase l. (In fact, in the font I'm currently using,
> the two are pixel-identical).
> 
> I don't see anybody calling for the banning of 'i' and 'l' in domain names due to that.

The very first phishing message I ever saw was from paypa1.com.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From mysidia at gmail.com  Sun Feb 12 21:52:16 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 12 Feb 2012 21:52:16 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
Message-ID: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>

2012/2/12 Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>:
> Valdis.Kletnieks at vt.edu wrote:
[snip]
> So, I can understand your attempt to insist on lowercase,
> but it does not work because DNS does not allow it.
[snip]

Not exactly...  DNS is case-insensitive when you are talking about
7-bit ASCII;  the set of alphabetic characters that can appear in a
DNS label;  with no punycode.

IDN means that non-ASCII characters are represented using punycode.

As soon as you have a browser parsing  punycode stuff,  any string
containing unicode characters has a unique punycode encoding / RFC
3491 / RFC 3492.


The symbols represented in the punycode encodings are not case sensitive.


Uppercase A-Z  vs Lowercase a-z in the generalized variable-length
integers   are not distinct,
the punycode representation itself cannot really be case sensitive,
but the codepoint represented by the encoding,  the result of decoding
the punycode  is case-preserving.

--
-JH


From nanog-poster at axu.tm  Sun Feb 12 22:50:51 2012
From: nanog-poster at axu.tm (Aleksi Suhonen)
Date: Mon, 13 Feb 2012 06:50:51 +0200
Subject: IPv6 explicit BGP group configs
Message-ID: <4F3896AB.6040203@axu.tm>

Hello,

keith tokash wrote:
> I'm prepping an environment for v6 and I'm wondering what, if
>  any, benefit there is to splitting v4 and v6 into separate groups.
> We're running Junipers and things are fairly neat and ordered;

I haven't really looked very hard, since I subscribe to the stated 
reasons for keeping v4 and v6 sessions apart. (migration, max-pfx, ...)

BUT

To my knowledge, JunOS doesn't even support using a single TCP session 
to exchange routes of all address families. If someone knows how to do 
this - if even for just IPv4 and IPv6 unicast - let me know ... ;-)

-- 
         Aleksi Suhonen / Axu TM Oy
         World Wide Web: www.axu.tm


From owen at delong.com  Sun Feb 12 23:01:52 2012
From: owen at delong.com (Owen DeLong)
Date: Sun, 12 Feb 2012 21:01:52 -0800
Subject: IPv6 explicit BGP group configs
In-Reply-To: <4F3896AB.6040203@axu.tm>
References: <4F3896AB.6040203@axu.tm>
Message-ID: <8FAFB9AF-D464-4E10-AD1B-C5C5397D46AA@delong.com>

It has limitations, but, it's documented pretty well in the excellent Day One/Day Two Juniper books for IPv6 written by Chris Grundemann. 

However, as others have said, I strongly subscribe to the school of "don't do that, it leads to unnecessary pain and provides little benefit.

Owen

On Feb 12, 2012, at 8:50 PM, Aleksi Suhonen wrote:

> Hello,
> 
> keith tokash wrote:
>> I'm prepping an environment for v6 and I'm wondering what, if
>> any, benefit there is to splitting v4 and v6 into separate groups.
>> We're running Junipers and things are fairly neat and ordered;
> 
> I haven't really looked very hard, since I subscribe to the stated reasons for keeping v4 and v6 sessions apart. (migration, max-pfx, ...)
> 
> BUT
> 
> To my knowledge, JunOS doesn't even support using a single TCP session to exchange routes of all address families. If someone knows how to do this - if even for just IPv4 and IPv6 unicast - let me know ... ;-)
> 
> -- 
>        Aleksi Suhonen / Axu TM Oy
>        World Wide Web: www.axu.tm



From randy at psg.com  Sun Feb 12 23:36:54 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 21:36:54 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
Message-ID: <m2lio7mgzt.wl%randy@psg.com>

> DNS is case-insensitive when you are talking about 7-bit ASCII

< pedantry >

dns itself is purely eight bit transparent.  one can even have a dot as
a non-separator.  p.r.c could be a tld.  it's strictly length/value.

of course, everyone and their dog has placed restrictions on it for this
use or that.

randy


From mysidia at gmail.com  Sun Feb 12 23:47:11 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 12 Feb 2012 23:47:11 -0600
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2lio7mgzt.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
Message-ID: <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>

On Sun, Feb 12, 2012 at 11:36 PM, Randy Bush <randy at psg.com> wrote:
>> DNS is case-insensitive when you are talking about 7-bit ASCII
> < pedantry >
> dns itself is purely eight bit transparent. ?one can even have a dot as
> a non-separator. ?p.r.c could be a tld. ?it's strictly length/value.

That's true, but  there is no standard character representation for
octet values  128 - 255.
If you use them in a DNS record,  they are just binary values that
don't refer to a specific printable symbol.

Only octets in the range from  65 to 90 (uppercase) and  977 to 122
(lowercase)
have a case equivalent for DNS resolution.

And IDN  uses 7-bit ASCII  DNS records.

--
-JH


From randy at psg.com  Sun Feb 12 23:51:21 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 21:51:21 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
Message-ID: <m2ipjbmgbq.wl%randy@psg.com>

>> dns itself is purely eight bit transparent. ?one can even have a dot as
>> a non-separator. ?p.r.c could be a tld. ?it's strictly length/value.
> That's true, but  there is no standard character representation for
> octet values  128 - 255.

utf-8 is the one used in the ietf community.

> Only octets in the range from 65 to 90 (uppercase) and 977 to 122
> (lowercase) have a case equivalent for DNS resolution.

dns resolution is eight bit clear.

randy


From bmanning at vacation.karoshi.com  Sun Feb 12 23:55:00 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Mon, 13 Feb 2012 05:55:00 +0000
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <m2lio7mgzt.wl%randy@psg.com>
References: <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
Message-ID: <20120213055500.GA5555@vacation.karoshi.com.>

On Sun, Feb 12, 2012 at 09:36:54PM -0800, Randy Bush wrote:
> > DNS is case-insensitive when you are talking about 7-bit ASCII
> 
> < pedantry >
> 
> dns itself is purely eight bit transparent.  one can even have a dot as
> a non-separator.  p.r.c could be a tld.  it's strictly length/value.
> 
> of course, everyone and their dog has placed restrictions on it for this
> use or that.
> 
> randy

	ah, the good'ol days.   ^g.net as an early attempt for the visually impaired
	lasted for a couple months.   about the same time you received your IPv4 /33


/bill


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 13 00:11:30 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 13 Feb 2012 15:11:30 +0900
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
Message-ID: <4F38A992.7030000@necom830.hpcl.titech.ac.jp>

Jimmy Hess wrote:

> As soon as you have a browser parsing  punycode stuff,  any string
> containing unicode characters has a unique punycode encoding / RFC
> 3491 / RFC 3492.

Labels (not "any string") which happens to be pure ASCII
are still case insensitive, which is DNS.

Note that, according to Valdis;

: (The actual policy for the .UA registrar is more subtle.
: They *do* in fact allow "U+0441 Cyrillic Small Letter ES"
: which is visually a C to us Latin-glyph users.  However,
: they require at least one character that's visually unique
: to Cyrillic in the domain name.  They also don't allow
; mixed Cyrillic/Latin scripts in one domain name).

a label (not "domain name") of a Ukrainian word all the
characters of which have shapes identical to some ASCII
characters can only be represented using ASCII characters
only.

						Masataka Ohta


From marka at isc.org  Mon Feb 13 00:21:02 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 13 Feb 2012 17:21:02 +1100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Sun, 12 Feb 2012 21:51:21 -0800."
 <m2ipjbmgbq.wl%randy@psg.com>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com> <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
Message-ID: <20120213062102.D60461D37336@drugs.dv.isc.org>


In message <m2ipjbmgbq.wl%randy at psg.com>, Randy Bush writes:
> >> dns itself is purely eight bit transparent. =A0one can even have a dot as
> >> a non-separator. =A0p.r.c could be a tld. =A0it's strictly length/value.
> > That's true, but  there is no standard character representation for
> > octet values  128 - 255.
> 
> utf-8 is the one used in the ietf community.

I challenge you to find a RFC that say it is UTF-8.  

> > Only octets in the range from 65 to 90 (uppercase) and 977 to 122
> > (lowercase) have a case equivalent for DNS resolution.
> 
> dns resolution is eight bit clear.

It may be 8 bit clear but only 0-127 have defined meaning.

128-255 may be UTF-8 but they could equally be ISO-LATIN-*.

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


From randy at psg.com  Mon Feb 13 00:29:09 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 22:29:09 -0800
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120213062102.D60461D37336@drugs.dv.isc.org>
References: <201202110009.AAA24255@sunf10.rd.bbc.co.uk>
 <CABgOHgshJ4W1H4qcXastk5sUqLazc4nVjBDrnKe6sxo4R1aKrg@mail.gmail.com>
 <m27gzu9p01.wl%randy@psg.com>
 <4F35C174.1090605@necom830.hpcl.titech.ac.jp>
 <4F369172.501@tonal.clara.co.uk> <m2sjihpa9m.wl%randy@psg.com>
 <170508.1328984937@turing-police.cc.vt.edu>
 <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
Message-ID: <m2ehtzmekq.wl%randy@psg.com>

>> dns resolution is eight bit clear.
> It may be 8 bit clear but only 0-127 have defined meaning.
> 128-255 may be UTF-8 but they could equally be ISO-LATIN-*.

nothing means anything


From alibaba123123 at gmail.com  Mon Feb 13 00:48:37 2012
From: alibaba123123 at gmail.com (ali baba)
Date: Mon, 13 Feb 2012 14:48:37 +0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
Message-ID: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>

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

From randy at psg.com  Mon Feb 13 00:50:57 2012
From: randy at psg.com (Randy Bush)
Date: Sun, 12 Feb 2012 22:50:57 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <m2bop3mdke.wl%randy@psg.com>

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

would be very unusual.  export it from your router.

randy


From peterehiwe at gmail.com  Mon Feb 13 00:51:07 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Mon, 13 Feb 2012 07:51:07 +0100
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <CADECfTV4oqLfT9XvOXgg+uZAjzQKePfr8foPeNA4i5rGmEJwdg@mail.gmail.com>

Why cant you do the netflow from your end?

On Mon, Feb 13, 2012 at 7:48 AM, ali baba <alibaba123123 at gmail.com> wrote:

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



-- 
Warm Regards

Peter(CCIE 23782).

From sethm at rollernet.us  Mon Feb 13 01:37:41 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Sun, 12 Feb 2012 23:37:41 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <4F38BDC5.90408@rollernet.us>

On 2/12/12 10:48 PM, ali baba wrote:
> 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?
> 

None that I've ever head of. Export netflow from your router. It'll be
the same data.

~Seth



From gbonser at seven.com  Mon Feb 13 04:30:48 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 13 Feb 2012 10:30:48 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>

nfdump + NfSen

Do it yourself.


> -----Original Message-----
> From: ali baba [mailto:alibaba123123 at gmail.com]
> Sent: Sunday, February 12, 2012 10:49 PM
> To: nanog at 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


From rmaunier at neotelecoms.com  Mon Feb 13 04:53:03 2012
From: rmaunier at neotelecoms.com (Raphael MAUNIER)
Date: Mon, 13 Feb 2012 10:53:03 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
Message-ID: <CB5EA962.79E04%rmaunier@neotelecoms.com>

+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" <gbonser at seven.com> wrote:

>nfdump + NfSen
>
>Do it yourself.
>
>
>> -----Original Message-----
>> From: ali baba [mailto:alibaba123123 at gmail.com]
>> Sent: Sunday, February 12, 2012 10:49 PM
>> To: nanog at 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
>



From matt at mt.au.com  Mon Feb 13 05:02:41 2012
From: matt at mt.au.com (Matt Taylor)
Date: Mon, 13 Feb 2012 22:02:41 +1100
Subject: IP Transit with netflow report?
In-Reply-To: <CB5EA962.79E04%rmaunier@neotelecoms.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
Message-ID: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>

Scrutinizer!
 

On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com> 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" <gbonser at seven.com> wrote:
> 
>> nfdump + NfSen
>> 
>> Do it yourself.
>> 
>> 
>>> -----Original Message-----
>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>> Sent: Sunday, February 12, 2012 10:49 PM
>>> To: nanog at 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
>> 
> 
> 


From alibaba123123 at gmail.com  Mon Feb 13 19:22:26 2012
From: alibaba123123 at gmail.com (ali baba)
Date: Tue, 14 Feb 2012 09:22:26 +0800
Subject: IP Transit with netflow report?
In-Reply-To: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
Message-ID: <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>

Ya, thks for the suggestion... been using Arbor and like the flexibility of
doing different reports on the fly. But, it is costing too much and newer
box only allow 5 routers?!! Having some hard time trying to get the
resources to do it in-house, as you guys know, mgmt loves to say forget it
and press the provider to give us..

Is there anyone out there providing such a thing as netflow-as-a-service?


On Monday, February 13, 2012, Matt Taylor <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com>
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" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at 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
>>>
>>
>>
>
>

From egermann at limanews.com  Mon Feb 13 19:40:47 2012
From: egermann at limanews.com (Eric Germann)
Date: Mon, 13 Feb 2012 17:40:47 -0800
Subject: IP Transit with netflow report?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
Message-ID: <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>

+1

Use it, love it.  Opened eyes on how much "social media traffic" (amongst other things) goes on on a daily basis.

EKG


-----Original Message-----
From: George Bonser [mailto:gbonser at seven.com] 
Sent: Monday, February 13, 2012 5:31 AM
To: ali baba; nanog at nanog.org
Subject: RE: IP Transit with netflow report?

nfdump + NfSen

Do it yourself.


> -----Original Message-----
> From: ali baba [mailto:alibaba123123 at gmail.com]
> Sent: Sunday, February 12, 2012 10:49 PM
> To: nanog at 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



From jloiacon at csc.com  Mon Feb 13 20:20:15 2012
From: jloiacon at csc.com (Joe Loiacono)
Date: Mon, 13 Feb 2012 21:20:15 -0500
Subject: IP Transit with netflow report?
In-Reply-To: <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
 <CAMdJjY1ge9XA7RkBCw8jXgAg9Aoft=06jGv9=G70ZDu-1kut2w@mail.gmail.com>
Message-ID: <OF30F229C1.4DB6946C-ON852579A4.000C0BC1-852579A4.000CD725@csc.com>

Consider also FlowViewer w/ flow-tools. You can set up long-term graphs of
any filtered traffic you like (e.g., by AS, by IP range, by service (ie
port), or any combination, etc.) Keeps stats like peak, average, etc. (just
like MRTG, only for the filtered set of your choice.) Has an email alert
capability when usage crosses a max or min threshold.

Quick, easy install.

http://ensight.eos.nasa.gov/FlowViewer

Joe




From:	ali baba <alibaba123123 at gmail.com>
To:	Matt Taylor <matt at mt.au.com>
Cc:	"nanog at nanog.org" <nanog at nanog.org>
Date:	02/13/2012 08:22 PM
Subject:	Re: IP Transit with netflow report?



Ya, thks for the suggestion... been using Arbor and like the flexibility of
doing different reports on the fly. But, it is costing too much and newer
box only allow 5 routers?!! Having some hard time trying to get the
resources to do it in-house, as you guys know, mgmt loves to say forget it
and press the provider to give us..

Is there anyone out there providing such a thing as netflow-as-a-service?


On Monday, February 13, 2012, Matt Taylor <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com>
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" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at 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
>>>
>>
>>
>
>




From jra at baylink.com  Mon Feb 13 21:21:08 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 13 Feb 2012 22:21:08 -0500 (EST)
Subject: Sonicwall 3500/netflow
Message-ID: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>

This will be my first time in Sonicwall territory.  I'm assuming this thing
will (effectively) *be* my edge router; does it support netflow, as has been
being discussed in the recent thread?

I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 for
backup/load bal; I don't think this will be a BGP application.  :-)

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


From gbonser at seven.com  Tue Feb 14 01:17:02 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 14 Feb 2012 07:17:02 +0000
Subject: IP Transit with netflow report?
In-Reply-To: <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>
References: <CAMdJjY0CNZj2SY9Rh64AcXbSUL=_b2md2X37NLy-k3xFJ1R50g@mail.gmail.com>
 <CAMdJjY3dPkqYJvnKjn+q+Tq++5zbYub5k6inXg+xps6vFWs2tw@mail.gmail.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CC7198@RWC-MBX1.corp.seven.com>
 <730AF3879A3A3844B3FB5A881A3DFBC801015058078D@VA3DIAXVS091.RED001.local>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CCABD6@RWC-MBX1.corp.seven.com>

> From: Eric Germann 
> Sent: Monday, February 13, 2012 5:41 PM
> To: George Bonser
> Cc: nanog at nanog.org
> Subject: RE: IP Transit with netflow report?
> 
> +1
> 
> Use it, love it.  Opened eyes on how much "social media traffic"
> (amongst other things) goes on on a daily basis.
> 
> EKG

And it works with sflow devices, too.  As a special added treat, the latest nfdump package in Debian sid comes with the sflow tools (yay! No more recompiling the package from source!) and it should be migrating to your favorite Debian derivative soon-ish (Ubuntu?).




From jay at miscreant.org  Tue Feb 14 04:58:41 2012
From: jay at miscreant.org (Jay Mitchell)
Date: Tue, 14 Feb 2012 21:58:41 +1100
Subject: Sonicwall 3500/netflow
In-Reply-To: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
Message-ID: <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>

According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.

http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications

--jay


On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:

> This will be my first time in Sonicwall territory.  I'm assuming this thing
> will (effectively) *be* my edge router; does it support netflow, as has been
> being discussed in the recent thread?
> 
> I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 for
> backup/load bal; I don't think this will be a BGP application.  :-)
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 


From blake at pfankuch.me  Tue Feb 14 08:40:40 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Tue, 14 Feb 2012 14:40:40 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>

JRA,
	If you have questions contact me off list.  I would shoot for a little higher device to support that bandwidth if you are going to be enabling Services at all.  Also if you use services, make sure they are enabled only on 1 zone as to not double scan traffic.  Also I would skip the DPI-SSL services for now, as they are extremely throughput intensive.  The company I work for manages a few hundred Sonicwalls, some of them in a pretty complex setup.  SonicWall netflow is a little unique, they have a GUI feature called APPFlow which makes it pretty easy to trim down to watch exactly what you need (once you get the hang of it).  Some of the additional free features make the SonicWall very nice.  The SSLVPN portal is very handy for remote troubleshooting.  You can bind it to a VLAN interface with private addresses for management purposes as well as remote access.  

Careful though, they can either be a beast, or a joy to manage depending on how you set it up.

If you want to do entirely CLI management on the SonicWall, be prepared for a headache.  Everything is case sensitive, and not the cleanest.  If you build quick templates in your favorite text editor, it can be very simple to manage this way.  

SonicWall is pushing 5.8.1.4 firmwares to all of the partners as far as I know (maybe to everyone) if you call in with an issue.  Check the caveats though, we have a few conflicts related to VPN stuff as well as dynamic routing a few places.

Blake

-----Original Message-----
From: Jay Mitchell [mailto:jay at miscreant.org] 
Sent: Tuesday, February 14, 2012 3:59 AM
To: Jay Ashworth
Cc: NANOG
Subject: Re: Sonicwall 3500/netflow

According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.

http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications

--jay


On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:

> This will be my first time in Sonicwall territory.  I'm assuming this 
> thing will (effectively) *be* my edge router; does it support netflow, 
> as has been being discussed in the recent thread?
> 
> I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 
> for backup/load bal; I don't think this will be a BGP application.  
> :-)
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 



From brandon.kim at brandontek.com  Tue Feb 14 09:49:00 2012
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Tue, 14 Feb 2012 10:49:00 -0500
Subject: Sonicwall 3500/netflow
In-Reply-To: <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
Message-ID: <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>


I've been using 5.8 with no problems thus far. As for the CLI, yes it is CLUNKY.

But they are completely revamping it, it will be very similar to Cisco in the near future...




> From: blake at pfankuch.me
> To: jay at miscreant.org; jra at baylink.com
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 14:40:40 +0000
> CC: nanog at nanog.org
> 
> JRA,
> 	If you have questions contact me off list.  I would shoot for a little higher device to support that bandwidth if you are going to be enabling Services at all.  Also if you use services, make sure they are enabled only on 1 zone as to not double scan traffic.  Also I would skip the DPI-SSL services for now, as they are extremely throughput intensive.  The company I work for manages a few hundred Sonicwalls, some of them in a pretty complex setup..  SonicWall netflow is a little unique, they have a GUI feature called APPFlow which makes it pretty easy to trim down to watch exactly what you need (once you get the hang of it).  Some of the additional free features make the SonicWall very nice.  The SSLVPN portal is very handy for remote troubleshooting.  You can bind it to a VLAN interface with private addresses for management purposes as well as remote access.  
> 
> Careful though, they can either be a beast, or a joy to manage depending on how you set it up.
> 
> If you want to do entirely CLI management on the SonicWall, be prepared for a headache.  Everything is case sensitive, and not the cleanest.  If you build quick templates in your favorite text editor, it can be very simple to manage this way.  
> 
> SonicWall is pushing 5.8.1.4 firmwares to all of the partners as far as I know (maybe to everyone) if you call in with an issue.  Check the caveats though, we have a few conflicts related to VPN stuff as well as dynamic routing a few places.
> 
> Blake
> 
> -----Original Message-----
> From: Jay Mitchell [mailto:jay at miscreant.org] 
> Sent: Tuesday, February 14, 2012 3:59 AM
> To: Jay Ashworth
> Cc: NANOG
> Subject: Re: Sonicwall 3500/netflow
> 
> According to the spec sheet it does, haven't had the opportunity to play with one to comment any further though.
> 
> http://www.sonicwall.com/us/products/NSA_3500.html#tab=specifications
> 
> --jay
> 
> 
> On 14/02/2012, at 2:21 PM, Jay Ashworth <jra at baylink.com> wrote:
> 
> > This will be my first time in Sonicwall territory.  I'm assuming this 
> > thing will (effectively) *be* my edge router; does it support netflow, 
> > as has been being discussed in the recent thread?
> > 
> > I'm likely going to have 100M from L3, with FiOS/150 and Roadrunner/50 
> > for backup/load bal; I don't think this will be a BGP application.  
> > :-)
> > 
> > Cheers,
> > -- jra
> > -- 
> > Jay R. Ashworth                  Baylink                       jra at baylink.com
> > Designer                     The Things I Think                       RFC 2100
> > Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> > St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> > 
> 
> 
 		 	   		  

From leigh.porter at ukbroadband.com  Tue Feb 14 09:53:43 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Tue, 14 Feb 2012 15:53:43 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, 
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>
Message-ID: <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Brandon Kim [mailto:brandon.kim at brandontek.com]
> Sent: 14 February 2012 15:51
> To: blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> Cc: nanog group
> Subject: RE: Sonicwall 3500/netflow
> 
> 
> I've been using 5.8 with no problems thus far. As for the CLI, yes it
> is CLUNKY.
> 
> But they are completely revamping it, it will be very similar to Cisco
> in the near future...

Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?


--
Leigh Porter




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


From brandon.kim at brandontek.com  Tue Feb 14 10:13:39 2012
From: brandon.kim at brandontek.com (Brandon Kim)
Date: Tue, 14 Feb 2012 11:13:39 -0500
Subject: Sonicwall 3500/netflow
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, ,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>, ,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>,
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>,
 <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
Message-ID: <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>


Never messed around with Juniper....




> From: leigh.porter at ukbroadband.com
> To: brandon.kim at brandontek.com; blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> CC: nanog at nanog.org
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 15:53:43 +0000
> 
> 
> 
> > -----Original Message-----
> > From: Brandon Kim [mailto:brandon.kim at brandontek.com]
> > Sent: 14 February 2012 15:51
> > To: blake at pfankuch.me; jay at miscreant.org; jra at baylink.com
> > Cc: nanog group
> > Subject: RE: Sonicwall 3500/netflow
> > 
> > 
> > I've been using 5.8 with no problems thus far. As for the CLI, yes it
> > is CLUNKY.
> > 
> > But they are completely revamping it, it will be very similar to Cisco
> > in the near future...
> 
> Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?
> 
> 
> --
> Leigh Porter
> 
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
 		 	   		  

From lstewart at superb.net  Tue Feb 14 15:03:33 2012
From: lstewart at superb.net (Landon Stewart)
Date: Tue, 14 Feb 2012 13:03:33 -0800
Subject: Does anyone know anything about intelishift.com?
Message-ID: <CABgOHgvHRCvX9vksyZovrBoEyLb-Grv8f7EAEioyyxqNDHGH6A@mail.gmail.com>

Does anyone know if intelishift.com has a reputation that is good or bad?
 I have never heard of them before but need to know some more about them.
 If you have anything to share please let me know off-list.  We are seeing
some unscrupulous behaviour from them regarding marketing and spam.

---
Landon Stewart <lstewart at superb.net <mailto"LStewart at Superb.Net>>
Manager of Systems and Engineering
Superb Internet Corp - 888-354-6128 x 4199
Web hosting and more "Ahead of the Rest": www.superb.net

From jmilko at bandwidth.com  Tue Feb 14 15:32:44 2012
From: jmilko at bandwidth.com (James Milko)
Date: Tue, 14 Feb 2012 16:32:44 -0500
Subject: Clued contact at Brighthouse
Message-ID: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>

Brighthouse seems to be announcing one of our prefixes.  Does anyone have a
contact for them that doesn't end up in residential support?

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth

From jmilko at bandwidth.com  Tue Feb 14 16:32:22 2012
From: jmilko at bandwidth.com (James Milko)
Date: Tue, 14 Feb 2012 17:32:22 -0500
Subject: Clued contact at Brighthouse
In-Reply-To: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>
References: <CAMiL-88tSmxvADx9kAkUzWzFmxyHREs++j_KLApyEuNjZPwFvA@mail.gmail.com>
Message-ID: <CAMiL-8-aGg=fsQ-OtKocfz+u5G2ekokOVs-Z4UPxK4jAXmwojA@mail.gmail.com>

Thanks to everyone who contacted us off list.  We got in touch with the
correct people over at Brighthouse and are working on it now.

Thanks,
James Milko
Senior Network Engineer
www.inetwork.com
4001 Weston Parkway
Cary, NC 27513

inetwork is a division of Bandwidth


On Tue, Feb 14, 2012 at 4:32 PM, James Milko <jmilko at bandwidth.com> wrote:

> Brighthouse seems to be announcing one of our prefixes.  Does anyone have
> a contact for them that doesn't end up in residential support?
>
> Thanks,
> James Milko
> Senior Network Engineer
> www.inetwork.com
> 4001 Weston Parkway
> Cary, NC 27513
>
> inetwork is a division of Bandwidth
>

From blake at pfankuch.me  Tue Feb 14 16:39:07 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Tue, 14 Feb 2012 22:39:07 +0000
Subject: Sonicwall 3500/netflow
In-Reply-To: <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>
References: <30376579.2476.1329189668728.JavaMail.root@benjamin.baylink.com>, ,
 <325D1DEE-D12B-4204-BBE4-B9B0A11D665A@miscreant.org>, ,
 <CC75EEBF17C7374EA8309102B7B10C84860B1FFB@SHSBS.shenrons-house.local>,
 <BLU158-W51472FFDC4763D01968E7FDC7C0@phx.gbl>,
 <D181DDABABE57E4DB72FEE00331478644A71DF@EALPO1.ukbroadband.com>
 <BLU158-W40B5CECC4C1F25E8B5CC44DC7C0@phx.gbl>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84860B2429@SHSBS.shenrons-house.local>

I would be happy if it was Juniper or Cisco ish.  Right now it's just total crap :)

From: brandon.j.kim at live.com [mailto:brandon.j.kim at live.com] On Behalf Of Brandon Kim
Sent: Tuesday, February 14, 2012 9:14 AM
To: leigh.porter at ukbroadband.com; Blake Pfankuch; jay at miscreant.org; jra at baylink.com
Cc: nanog group
Subject: RE: Sonicwall 3500/netflow

Never messed around with Juniper....



> From: leigh.porter at ukbroadband.com<mailto:leigh.porter at ukbroadband.com>
> To: brandon.kim at brandontek.com<mailto:brandon.kim at brandontek.com>; blake at pfankuch.me<mailto:blake at pfankuch.me>; jay at miscreant.org<mailto:jay at miscreant.org>; jra at baylink.com<mailto:jra at baylink.com>
> CC: nanog at nanog.org<mailto:nanog at nanog.org>
> Subject: RE: Sonicwall 3500/netflow
> Date: Tue, 14 Feb 2012 15:53:43 +0000
>
>
>
> > -----Original Message-----
> > From: Brandon Kim [mailto:brandon.kim at brandontek.com]<mailto:[mailto:brandon.kim at brandontek.com]>
> > Sent: 14 February 2012 15:51
> > To: blake at pfankuch.me<mailto:blake at pfankuch.me>; jay at miscreant.org<mailto:jay at miscreant.org>; jra at baylink.com<mailto:jra at baylink.com>
> > Cc: nanog group
> > Subject: RE: Sonicwall 3500/netflow
> >
> >
> > I've been using 5.8 with no problems thus far. As for the CLI, yes it
> > is CLUNKY.
> >
> > But they are completely revamping it, it will be very similar to Cisco
> > in the near future...
>
> Why do people like to base their CLIs on the really rather awful Cisco style interface rather than something with some more structure like Juniper?
>
>
> --
> Leigh Porter
>
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

From bortzmeyer at nic.fr  Wed Feb 15 03:44:38 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Wed, 15 Feb 2012 10:44:38 +0100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120213062102.D60461D37336@drugs.dv.isc.org>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
Message-ID: <20120215094438.GA30846@nic.fr>

On Mon, Feb 13, 2012 at 05:21:02PM +1100,
 Mark Andrews <marka at isc.org> 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.



From Valdis.Kletnieks at vt.edu  Wed Feb 15 04:13:54 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 15 Feb 2012 05:13:54 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Wed, 15 Feb 2012 10:44:38 +0100."
 <20120215094438.GA30846@nic.fr>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr>
Message-ID: <22591.1329300834@turing-police.cc.vt.edu>

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. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/7af051c3/attachment.bin>

From rs at seastrom.com  Wed Feb 15 05:46:40 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Wed, 15 Feb 2012 06:46:40 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <22591.1329300834@turing-police.cc.vt.edu> (Valdis Kletnieks's
 message of "Wed, 15 Feb 2012 05:13:54 -0500")
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com>
 <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr>
 <22591.1329300834@turing-police.cc.vt.edu>
Message-ID: <86mx8kqpy7.fsf@seastrom.com>


Valdis.Kletnieks at 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" <grin>

-r



From marka at isc.org  Wed Feb 15 07:32:19 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 00:32:19 +1100
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: Your message of "Wed, 15 Feb 2012 06:46:40 CDT."
 <86mx8kqpy7.fsf@seastrom.com>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr> <22591.1329300834@turing-police.cc.vt.edu>
 <86mx8kqpy7.fsf@seastrom.com>
Message-ID: <20120215133219.DED4E1D6273B@drugs.dv.isc.org>


In message <86mx8kqpy7.fsf at seastrom.com>, "Robert E. Seastrom" writes:
> 
> Valdis.Kletnieks at 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" <grin>

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: marka at isc.org


From brunner at nic-naa.net  Wed Feb 15 11:00:25 2012
From: brunner at nic-naa.net (Eric Brunner-Williams)
Date: Wed, 15 Feb 2012 12:00:25 -0500
Subject: Dear RIPE: Please don't encourage phishing
In-Reply-To: <20120215133219.DED4E1D6273B@drugs.dv.isc.org>
References: <4F371521.7090809@necom830.hpcl.titech.ac.jp>
 <192978.1329023607@turing-police.cc.vt.edu>
 <4F377168.9040903@necom830.hpcl.titech.ac.jp>
 <223001.1329076548@turing-police.cc.vt.edu>
 <4F3877E7.2010904@necom830.hpcl.titech.ac.jp>
 <CAAAwwbUEaw7mviPrh2Tp4o_yaMWispg4_ZB_o9KAjgpyuvY0HA@mail.gmail.com>
 <m2lio7mgzt.wl%randy@psg.com>
 <CAAAwwbW_tCpq9ejiXPkZjUi3f-d5Jfe9wzEriwFQeZ_YHaRpmg@mail.gmail.com>
 <m2ipjbmgbq.wl%randy@psg.com> <20120213062102.D60461D37336@drugs.dv.isc.org>
 <20120215094438.GA30846@nic.fr> <22591.1329300834@turing-police.cc.vt.edu>
 <86mx8kqpy7.fsf@seastrom.com> <20120215133219.DED4E1D6273B@drugs.dv.isc.org>
Message-ID: <4F3BE4A9.2030306@nic-naa.net>

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


From rps at maine.edu  Wed Feb 15 12:51:37 2012
From: rps at maine.edu (Ray Soucy)
Date: Wed, 15 Feb 2012 13:51:37 -0500
Subject: IP Transit with netflow report?
In-Reply-To: <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
References: <CB5EA962.79E04%rmaunier@neotelecoms.com>
 <FDBCF4BE-A520-44CF-BA83-5569C1FE8BD9@mt.au.com>
Message-ID: <CALFTrnM1dgt8LoAvXqbkSUtKn+OHHpJ3gjf0SSgH6aA390tmKA@mail.gmail.com>

+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 <matt at mt.au.com> wrote:
> Scrutinizer!
>
>
> On 13/02/2012, at 9:53 PM, Raphael MAUNIER <rmaunier at neotelecoms.com> 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" <gbonser at seven.com> wrote:
>>
>>> nfdump + NfSen
>>>
>>> Do it yourself.
>>>
>>>
>>>> -----Original Message-----
>>>> From: ali baba [mailto:alibaba123123 at gmail.com]
>>>> Sent: Sunday, February 12, 2012 10:49 PM
>>>> To: nanog at 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/


From jtk at cymru.com  Wed Feb 15 14:47:15 2012
From: jtk at cymru.com (John Kristoff)
Date: Wed, 15 Feb 2012 14:47:15 -0600
Subject: Common operational misconceptions
Message-ID: <20120215144715.18e65a55@w520.localdomain>

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


From bhmccie at gmail.com  Wed Feb 15 14:57:58 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 15 Feb 2012 14:57:58 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C1C56.6040802@gmail.com>

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


From chipps at chipps.com  Wed Feb 15 15:10:44 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Wed, 15 Feb 2012 15:10:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <008501ccec26$47e8c010$d7ba4030$@chipps.com>

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

Kenneth M. Chipps Ph.D.

-----Original Message-----
From: John Kristoff [mailto:jtk at cymru.com] 
Sent: Wednesday, February 15, 2012 2:47 PM
To: nanog at 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





From mark at pcinw.net  Wed Feb 15 15:26:28 2012
From: mark at pcinw.net (Mark Grigsby)
Date: Wed, 15 Feb 2012 13:26:28 -0800
Subject: Common operational misconceptions
In-Reply-To: <008501ccec26$47e8c010$d7ba4030$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <008501ccec26$47e8c010$d7ba4030$@chipps.com>
Message-ID: <CAKwRnJMZAxpS3r1HYLB0RYNbVfJqH6U95MaSi2L=K2g+9vktqQ@mail.gmail.com>

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

> Keep the discussion on the list. I would like to know as well.
>
> Kenneth M. Chipps Ph.D.
>
> -----Original Message-----
> From: John Kristoff [mailto:jtk at cymru.com]
> Sent: Wednesday, February 15, 2012 2:47 PM
> To: nanog at 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

From dwhite at olp.net  Wed Feb 15 15:52:01 2012
From: dwhite at olp.net (Dan White)
Date: Wed, 15 Feb 2012 15:52:01 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215215200.GG3353@dan.olp.net>

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


From tias at netnod.se  Wed Feb 15 15:59:37 2012
From: tias at netnod.se (Mathias Wolkert)
Date: Wed, 15 Feb 2012 22:59:37 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se>

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

/Tias

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

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


From bicknell at ufp.org  Wed Feb 15 16:06:53 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Wed, 15 Feb 2012 14:06:53 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215220653.GA59477@ussenterprise.ufp.org>


Auto-neg, as someone already mentioned.

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

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

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/e227d507/attachment.bin>

From bhmccie at gmail.com  Wed Feb 15 16:09:22 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 15 Feb 2012 16:09:22 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215215200.GG3353@dan.olp.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215215200.GG3353@dan.olp.net>
Message-ID: <4F3C2D12.7010001@gmail.com>

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


From dougb at dougbarton.us  Wed Feb 15 16:14:31 2012
From: dougb at dougbarton.us (Doug Barton)
Date: Wed, 15 Feb 2012 14:14:31 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215220653.GA59477@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215220653.GA59477@ussenterprise.ufp.org>
Message-ID: <4F3C2E47.80903@dougbarton.us>

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/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120215/8cc9fa88/attachment.bin>

From johnl at iecc.com  Wed Feb 15 16:19:42 2012
From: johnl at iecc.com (John Levine)
Date: 15 Feb 2012 22:19:42 -0000
Subject: Models of DNS traffic and caches
Message-ID: <20120215221942.828.qmail@joyce.lan>

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, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From cra at WPI.EDU  Wed Feb 15 16:36:15 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 15 Feb 2012 17:36:15 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215223615.GN5968@angus.ind.WPI.EDU>

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


From gbakos at alpinista.org  Wed Feb 15 16:36:32 2012
From: gbakos at alpinista.org (George Bakos)
Date: Wed, 15 Feb 2012 22:36:32 +0000
Subject: Anonymous planning a root-servers party
Message-ID: <20120215223632.7545efa0@alpinista.org>

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. Sshhhhh! Don't anybody mention anycast - it's a secret.


From shortdudey123 at gmail.com  Wed Feb 15 16:40:47 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 15 Feb 2012 16:40:47 -0600
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215223632.7545efa0@alpinista.org>
References: <20120215223632.7545efa0@alpinista.org>
Message-ID: <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>

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 <gbakos at alpinista.org> 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. Sshhhhh! Don't anybody mention anycast - it's a secret.
>
>

From jared at puck.nether.net  Wed Feb 15 16:42:11 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Wed, 15 Feb 2012 17:42:11 -0500
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215223632.7545efa0@alpinista.org>
References: <20120215223632.7545efa0@alpinista.org>
Message-ID: <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>


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



From cabo at tzi.org  Wed Feb 15 16:49:25 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Wed, 15 Feb 2012 23:49:25 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120215223615.GN5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
Message-ID: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>

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



From tkapela at gmail.com  Wed Feb 15 16:51:44 2012
From: tkapela at gmail.com (Anton Kapela)
Date: Wed, 15 Feb 2012 16:51:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120215223615.GN5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
Message-ID: <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>

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

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

Clarify?

-tk


From eric at eparsonage.com  Wed Feb 15 16:51:45 2012
From: eric at eparsonage.com (Eric Parsonage)
Date: Thu, 16 Feb 2012 09:21:45 +1030
Subject: Anonymous planning a root-servers party
In-Reply-To: <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
Message-ID: <D9FA5D45-E125-4BE4-9222-FFEDC207F1BB@eparsonage.com>

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



From rsk at gsp.org  Wed Feb 15 16:52:44 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Wed, 15 Feb 2012 17:52:44 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120215225244.GA25272@gsp.org>

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


From mike.lyon at gmail.com  Wed Feb 15 16:53:34 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Wed, 15 Feb 2012 14:53:34 -0800
Subject: Common operational misconceptions
In-Reply-To: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
Message-ID: <CAFFgAjDwNmtOKs1y35dQSZ-w41Hh4U0onQ2r-KL1TpyVksnRUg@mail.gmail.com>

With security in mind:

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

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

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


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

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

From cra at WPI.EDU  Wed Feb 15 17:02:58 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Wed, 15 Feb 2012 18:02:58 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
Message-ID: <20120215230258.GQ5968@angus.ind.WPI.EDU>

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

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


From marka at isc.org  Wed Feb 15 17:13:57 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 10:13:57 +1100
Subject: Anonymous planning a root-servers party
In-Reply-To: Your message of "Wed, 15 Feb 2012 17:42:11 CDT."
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
Message-ID: <20120215231357.1A77B1D65435@drugs.dv.isc.org>


In message <5F40C962-FF7E-4197-BBA5-5E891104B17C at 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. Sshhhhh! 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 AAAA
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: marka at isc.org


From jeff-kell at utc.edu  Wed Feb 15 17:18:21 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Wed, 15 Feb 2012 18:18:21 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215230258.GQ5968@angus.ind.WPI.EDU>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <CAJWBqEtLH60sXTRQ=ppP9-XVV56OeJ1hMtKancCyW_hQ1=9teA@mail.gmail.com>
 <20120215230258.GQ5968@angus.ind.WPI.EDU>
Message-ID: <4F3C3D3D.1070204@utc.edu>

(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




From algold at lncc.br  Wed Feb 15 17:23:13 2012
From: algold at lncc.br (Alexandre Grojsgold)
Date: Wed, 15 Feb 2012 21:23:13 -0200
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C3E61.6050401@lncc.br>


Telco provided VPN makes communication between your sites secure.

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


-- Alg


From ask at develooper.com  Wed Feb 15 17:30:11 2012
From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=)
Date: Wed, 15 Feb 2012 15:30:11 -0800
Subject: SSL Certificates
In-Reply-To: <CA+kZPgYB4KBgbqEh9uS5+R=CcjH_s0uy9j-rnKL92sNes4ktaQ@mail.gmail.com>
References: <CA+kZPgYB4KBgbqEh9uS5+R=CcjH_s0uy9j-rnKL92sNes4ktaQ@mail.gmail.com>
Message-ID: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>


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/

From meirea at charterschoolit.com  Wed Feb 15 18:00:51 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 00:00:51 +0000
Subject: Wireless Recommendations
In-Reply-To: <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>,
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>

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 [jof at thejof.com]
Sent: Tuesday, February 07, 2012 2:50 PM
To: Arzhel Younsi
Cc: Mario Eirea; nanog at nanog.org
Subject: Re: Wireless Recommendations

On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi <xionox at gmail.com> 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


From jsw at inconcepts.biz  Wed Feb 15 18:10:04 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Wed, 15 Feb 2012 19:10:04 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAPWAtbJ=e1JD1-=_5SQEzuJ1eh8gTEiSGfv987ecT61-s5RgMA@mail.gmail.com>

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

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

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

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

MTU, Path MTU Detection, and MSS

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

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


From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 18:13:34 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 09:13:34 +0900
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215231357.1A77B1D65435@drugs.dv.isc.org>
References: <20120215223632.7545efa0@alpinista.org>
 <5F40C962-FF7E-4197-BBA5-5E891104B17C@puck.nether.net>
 <20120215231357.1A77B1D65435@drugs.dv.isc.org>
Message-ID: <4F3C4A2E.4020603@necom830.hpcl.titech.ac.jp>

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


From ler762 at gmail.com  Wed Feb 15 18:17:57 2012
From: ler762 at gmail.com (Lee)
Date: Wed, 15 Feb 2012 19:17:57 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>

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

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

Lee


On 2/15/12, John Kristoff <jtk at 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
>
>


From johnl at iecc.com  Wed Feb 15 18:17:00 2012
From: johnl at iecc.com (John Levine)
Date: 16 Feb 2012 00:17:00 -0000
Subject: SSL Certificates
In-Reply-To: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
Message-ID: <20120216001700.52490.qmail@joyce.lan>

>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



From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 18:19:26 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 09:19:26 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>

PKI is cryptographically secure.

IDN is internationalized.

IPv6 reduces router load by not allowing fragmentation.

IPv6 is operational.

						Masataka Ohta


From steve.bertrand at gmail.com  Wed Feb 15 18:23:21 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 19:23:21 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C4C79.5080208@gmail.com>

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



From steve.bertrand at gmail.com  Wed Feb 15 18:31:50 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 19:31:50 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C4C79.5080208@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4C79.5080208@gmail.com>
Message-ID: <4F3C4E76.6050201@gmail.com>

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.


From michael at rancid.berkeley.edu  Wed Feb 15 18:46:44 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Wed, 15 Feb 2012 16:46:44 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C51F4.2020305@rancid.berkeley.edu>

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



From george.herbert at gmail.com  Wed Feb 15 18:49:53 2012
From: george.herbert at gmail.com (George Herbert)
Date: Wed, 15 Feb 2012 16:49:53 -0800
Subject: SSL Certificates
In-Reply-To: <20120216001700.52490.qmail@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
Message-ID: <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>

On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> 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.herbert at gmail.com


From nathan at atlasnetworks.us  Wed Feb 15 18:55:49 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 16 Feb 2012 00:55:49 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>

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

Nathan


From dlc at lampinc.com  Wed Feb 15 19:13:34 2012
From: dlc at lampinc.com (Dale Carstensen)
Date: Wed, 15 Feb 2012 18:13:34 -0700
Subject: Common operational misconceptions 
In-Reply-To: <20120215144715.18e65a55@w520.localdomain> 
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <20120216011051.1B73938D601@lampinc.com>

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.




From jbates at brightok.net  Wed Feb 15 19:20:38 2012
From: jbates at brightok.net (Jack Bates)
Date: Wed, 15 Feb 2012 19:20:38 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C2D12.7010001@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215215200.GG3353@dan.olp.net> <4F3C2D12.7010001@gmail.com>
Message-ID: <4F3C59E6.2040504@brightok.net>

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


From marka at isc.org  Wed Feb 15 19:32:31 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 12:32:31 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Wed, 15 Feb 2012 14:14:31 -0800."
 <4F3C2E47.80903@dougbarton.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215220653.GA59477@ussenterprise.ufp.org> <4F3C2E47.80903@dougbarton.us>
Message-ID: <20120216013231.A0B801D66455@drugs.dv.isc.org>


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

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

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


From meirea at charterschoolit.com  Wed Feb 15 20:07:36 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 02:07:36 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>

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

-Mario Eirea

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


From shortdudey123 at gmail.com  Wed Feb 15 20:12:44 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Wed, 15 Feb 2012 20:12:44 -0600
Subject: Common operational misconceptions
In-Reply-To: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
Message-ID: <CAPiURgVe82WXB8Vo8pko8okvHVxCk3-BUcNMbiK6TJcp6k1sww@mail.gmail.com>

I whole-heartedly agree with that last one.

-Grant

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

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

From steve.bertrand at gmail.com  Wed Feb 15 20:16:35 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 21:16:35 -0500
Subject: Common operational misconceptions
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
Message-ID: <4F3C6703.4050607@gmail.com>

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


From steve.bertrand at gmail.com  Wed Feb 15 20:25:53 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 21:25:53 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
Message-ID: <4F3C6931.1030908@gmail.com>

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


From phil at cluestick.net  Wed Feb 15 20:27:17 2012
From: phil at cluestick.net (Phil Dyer)
Date: Wed, 15 Feb 2012 21:27:17 -0500
Subject: Common operational misconceptions
In-Reply-To: <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215223615.GN5968@angus.ind.WPI.EDU>
 <FC93A3C8-7DC0-4325-BD72-5BEFF5ED37A6@tzi.org>
Message-ID: <CAB+BaiMELqqzaP1+AwSDt8dT7SETfy-4QW=KsYwAsSruuNr3Lw@mail.gmail.com>

On Wed, Feb 15, 2012 at 5:49 PM, Carsten Bormann <cabo at tzi.org> wrote:
> On Feb 15, 2012, at 23:36, Chuck Anderson wrote:
>
>> security
>
> That must be the top of the list:

as a segue to....

> NATs provide security


From dhc2 at dcrocker.net  Wed Feb 15 20:37:42 2012
From: dhc2 at dcrocker.net (Dave CROCKER)
Date: Wed, 15 Feb 2012 18:37:42 -0800
Subject: Anonymous planning a root-servers party
In-Reply-To: <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
References: <20120215223632.7545efa0@alpinista.org>
 <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
Message-ID: <4F3C6BF6.6080609@dcrocker.net>



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


From marka at isc.org  Wed Feb 15 21:12:07 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 14:12:07 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Wed, 15 Feb 2012 21:16:35 CDT."
 <4F3C6703.4050607@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
Message-ID: <20120216031208.132481D76BD5@drugs.dv.isc.org>


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

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

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

		dig edns-v6-ok.isc.org txt

Similarly for IPv4.

		dig edns-v4-ok.isc.org txt

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


From mohta at necom830.hpcl.titech.ac.jp  Wed Feb 15 21:24:05 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 12:24:05 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>

Mark Andrews wrote:

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

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

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

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

					Masataka Ohta


From w3yni1 at gmail.com  Wed Feb 15 21:26:11 2012
From: w3yni1 at gmail.com (Charles Mills)
Date: Wed, 15 Feb 2012 22:26:11 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
Message-ID: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>

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

Chuck

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

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

From faisal at snappydsl.net  Wed Feb 15 21:50:53 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Wed, 15 Feb 2012 22:50:53 -0500
Subject: Wireless Recommendations
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>,
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3C7D1D.7070203@snappydsl.net>

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: Support at 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 [jof at thejof.com]
> Sent: Tuesday, February 07, 2012 2:50 PM
> To: Arzhel Younsi
> Cc: Mario Eirea; nanog at nanog.org
> Subject: Re: Wireless Recommendations
>
> On Tue, Feb 7, 2012 at 11:19 AM, Arzhel Younsi<xionox at gmail.com>  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
>
>



From jof at thejof.com  Wed Feb 15 21:54:29 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 15 Feb 2012 19:54:29 -0800
Subject: Wireless Recommendations
In-Reply-To: <4F3C7D1D.7070203@snappydsl.net>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>
Message-ID: <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>

On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> 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


From jbaino at gmail.com  Wed Feb 15 22:13:54 2012
From: jbaino at gmail.com (Jeremy)
Date: Wed, 15 Feb 2012 23:13:54 -0500
Subject: 802.11 MAC Point Coordination Function
Message-ID: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>

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

From meirea at charterschoolit.com  Wed Feb 15 22:14:28 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Thu, 16 Feb 2012 04:14:28 +0000
Subject: Wireless Recommendations
In-Reply-To: <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>,
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>

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 [jof at thejof.com]
Sent: Wednesday, February 15, 2012 10:54 PM
To: Faisal at snappydsl.net
Cc: nanog at nanog.org
Subject: Re: Wireless Recommendations

On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> 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



From marka at isc.org  Wed Feb 15 22:27:39 2012
From: marka at isc.org (Mark Andrews)
Date: Thu, 16 Feb 2012 15:27:39 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 12:24:05 +0900."
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
Message-ID: <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>


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

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

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

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

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

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


From joelja at bogus.com  Wed Feb 15 22:41:10 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 15 Feb 2012 20:41:10 -0800
Subject: Wireless Recommendations
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>,
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3C88E6.3000208@bogus.com>

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 [jof at thejof.com]
> Sent: Wednesday, February 15, 2012 10:54 PM
> To: Faisal at snappydsl.net
> Cc: nanog at nanog.org
> Subject: Re: Wireless Recommendations
> 
> On Wed, Feb 15, 2012 at 7:50 PM, Faisal Imtiaz <faisal at snappydsl.net> 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
> 
> 
> 



From steve.bertrand at gmail.com  Wed Feb 15 22:43:32 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Wed, 15 Feb 2012 23:43:32 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <4F3C8974.9010308@gmail.com>

On 2012.02.15 22:12, Mark Andrews wrote:
> In message<4F3C6703.4050607 at 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


From antti.ristimaki at gmx.com  Wed Feb 15 22:47:07 2012
From: antti.ristimaki at gmx.com (=?ISO-8859-1?Q?Antti_Ristim=E4ki?=)
Date: Thu, 16 Feb 2012 06:47:07 +0200
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F3C8A4B.1090309@gmx.com>

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



From chipps at chipps.com  Wed Feb 15 23:04:01 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Wed, 15 Feb 2012 23:04:01 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C8A4B.1090309@gmx.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
Message-ID: <00e501ccec68$65aa8650$30ff92f0$@chipps.com>

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

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

-----Original Message-----
From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com] 
Sent: Wednesday, February 15, 2012 10:47 PM
To: John Kristoff
Cc: nanog at 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
>






From bmanning at vacation.karoshi.com  Wed Feb 15 23:16:18 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 16 Feb 2012 05:16:18 +0000
Subject: and now for something completely different
Message-ID: <20120216051618.GA2590@vacation.karoshi.com.>


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.


From joelja at bogus.com  Wed Feb 15 23:57:35 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 15 Feb 2012 21:57:35 -0800
Subject: Common operational misconceptions
In-Reply-To: <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
Message-ID: <4F3C9ACF.2050108@bogus.com>

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

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

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com] 
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog at 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
>>
> 
> 
> 
> 
> 
> 



From chipps at chipps.com  Thu Feb 16 00:00:04 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Thu, 16 Feb 2012 00:00:04 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3C9ACF.2050108@bogus.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
Message-ID: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>

"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 at bogus.com] 
Sent: Wednesday, February 15, 2012 11:58 PM
To: Kenneth M. Chipps Ph.D.
Cc: nanog at nanog.org
Subject: Re: Common operational misconceptions

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

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

ISIS is used in organizations other than ISPs.

> -----Original Message-----
> From: Antti Ristim?ki [mailto:antti.ristimaki at gmx.com]
> Sent: Wednesday, February 15, 2012 10:47 PM
> To: John Kristoff
> Cc: nanog at 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
>>
> 
> 
> 
> 
> 
> 





From mohta at necom830.hpcl.titech.ac.jp  Thu Feb 16 00:11:32 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Thu, 16 Feb 2012 15:11:32 +0900
Subject: Common operational misconceptions
In-Reply-To: <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <20120216042740.5EA131D7F6FE@drugs.dv.isc.org>
Message-ID: <4F3C9E14.2060001@necom830.hpcl.titech.ac.jp>

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


From aftab.siddiqui at gmail.com  Thu Feb 16 00:20:37 2012
From: aftab.siddiqui at gmail.com (Aftab Siddiqui)
Date: Thu, 16 Feb 2012 11:20:37 +0500
Subject: Common operational misconceptions
In-Reply-To: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
 <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
 <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
Message-ID: <CAK5YLgdv-uONoQhERb6g0V+EzevveXEEunCbiP2VecgP1n4_hg@mail.gmail.com>

Some recent questions from interview and lab sessions I took.

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

Regards,

Aftab A. Siddiqui


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

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

From bmanning at vacation.karoshi.com  Thu Feb 16 00:34:21 2012
From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com)
Date: Thu, 16 Feb 2012 06:34:21 +0000
Subject: SSL Certificates
In-Reply-To: <20120216001700.52490.qmail@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
Message-ID: <20120216063421.GA2785@vacation.karoshi.com.>

On Thu, Feb 16, 2012 at 12:17:00AM -0000, 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


From jof at thejof.com  Thu Feb 16 00:42:13 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Wed, 15 Feb 2012 22:42:13 -0800
Subject: Wireless Recommendations
In-Reply-To: <4F3C88E6.3000208@bogus.com>
References: <043e01ccdf90$38c96870$aa5c3950$@impactbusiness.com>
 <4F281AC7.2050706@bogus.com>
 <4E0D68AD-773A-472D-B80F-0D7B628BBF39@charterschoolit.com>
 <CAHgar0aExC8Do6ZXftMcfkLBsOyy8O-vgaGT-+eKiJK=Ms5hmA@mail.gmail.com>
 <CAHsqw9sNPd0ThSBEpf-ud7HhP64rE5JP3dhT39be7Pzw8gMjyA@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C041D7E@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C7D1D.7070203@snappydsl.net>
 <CAHsqw9vQTw7nZPzrvgtVqqRcc=aOgwsu1cNZLDRV6vP8HyPR=Q@mail.gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C042796@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3C88E6.3000208@bogus.com>
Message-ID: <CAHsqw9vRJwvqStdu8hMMRmZ3e4kcy_H7txShCZ_AXHBUFj4Dxg@mail.gmail.com>

On Wed, Feb 15, 2012 at 8:41 PM, Joel jaeggli <joelja at bogus.com> 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


From mysidia at gmail.com  Thu Feb 16 00:57:25 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Thu, 16 Feb 2012 00:57:25 -0600
Subject: SSL Certificates
In-Reply-To: <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
Message-ID: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>

On Wed, Feb 15, 2012 at 6:49 PM, George Herbert
<george.herbert at gmail.com> wrote:
> On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> 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


From owen at delong.com  Thu Feb 16 01:34:02 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 15 Feb 2012 23:34:02 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <8A3EC4D2-EFAB-41FD-A1C3-E21C1B2EBD52@delong.com>


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



From owen at delong.com  Thu Feb 16 01:45:48 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 15 Feb 2012 23:45:48 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3C6703.4050607@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
Message-ID: <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>


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



From prt at prt.org  Thu Feb 16 02:21:05 2012
From: prt at prt.org (Paul Thornton)
Date: Thu, 16 Feb 2012 08:21:05 +0000
Subject: Common operational misconceptions
In-Reply-To: <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <D2E0BA90-D48E-42FA-9312-9E659694837F@delong.com>
Message-ID: <4F3CBC71.3010401@prt.org>

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

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

-- 
Paul


From leigh.porter at ukbroadband.com  Thu Feb 16 02:32:07 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Thu, 16 Feb 2012 08:32:07 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <804FACA5-E586-4108-AED3-C1E9B2549120@ukbroadband.com>


On 15 Feb 2012, at 20:50, "John Kristoff" <jtk at cymru.com> wrote:

> Hi friends,
> 
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
> 
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers.  Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.

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

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

--
Leigh


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


From jof at thejof.com  Thu Feb 16 02:57:59 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Thu, 16 Feb 2012 00:57:59 -0800
Subject: 802.11 MAC Point Coordination Function
In-Reply-To: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>
References: <CAJCOWetn9o5cfm2LWS5z9-pb1SvPTmVm8GqstLt9fNZvzW2yaA@mail.gmail.com>
Message-ID: <CAHsqw9u5nsmXOJ4ZoZ-sGMh8hTHOK5tCayuJF3-E9-coHWoERw@mail.gmail.com>

On Wed, Feb 15, 2012 at 8:13 PM, Jeremy <jbaino at gmail.com> wrote:
> 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!

I know of no such feature in "classic" Aironet APs. Everything I've
run across only does classic 802.11-style DCF along with all the
stations.
You might check out the Aironet 1550, which supports forming dynamic
mesh-like topologies, though I can't speak to it as I've never laid
hands on the hardware or software.

Other vendors and hackers are implementing alternative media-access
control and coordination functions, though.
You might check out Ubiquiti's AirMax-speaking hardware or
ieee80211_tdma in FreeBSD for software MAC-capable drivers.

Cheers,
jof


From tim at pelican.org  Thu Feb 16 03:58:53 2012
From: tim at pelican.org (Tim Franklin)
Date: Thu, 16 Feb 2012 09:58:53 -0000 (GMT)
Subject: Common operational misconceptions
In-Reply-To: <804FACA5-E586-4108-AED3-C1E9B2549120@ukbroadband.com>
Message-ID: <dca78cc7-d063-4c96-b990-a5cfea77c128@mail.pelican.org>

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

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

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

Regards,
Tim.


From chris at ctcampbell.com  Thu Feb 16 04:26:26 2012
From: chris at ctcampbell.com (Chris Campbell)
Date: Thu, 16 Feb 2012 10:26:26 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120215225244.GA25272@gsp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215225244.GA25272@gsp.org>
Message-ID: <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>

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
> 



From sthaug at nethelp.no  Thu Feb 16 06:01:43 2012
From: sthaug at nethelp.no (sthaug at nethelp.no)
Date: Thu, 16 Feb 2012 13:01:43 +0100 (CET)
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <20120216.130143.74691634.sthaug@nethelp.no>

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

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

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

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

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

Steinar Haug, Nethelp consulting, sthaug at nethelp.no


From mwlucas at blackhelicopters.org  Thu Feb 16 06:03:24 2012
From: mwlucas at blackhelicopters.org (Michael W. Lucas)
Date: Thu, 16 Feb 2012 07:03:24 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3C8A4B.1090309@gmx.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
Message-ID: <20120216120324.GA49227@bewilderbeast.blackhelicopters.org>


"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 at BlackHelicopters.org, Twitter @mwlauthor


From lykinsbd at gmail.com  Thu Feb 16 06:11:42 2012
From: lykinsbd at gmail.com (Brett Lykins)
Date: Thu, 16 Feb 2012 07:11:42 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <-4603831956774401251@unknownmsgid>

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


From jared at puck.nether.net  Thu Feb 16 06:31:46 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 16 Feb 2012 07:31:46 -0500
Subject: Common operational misconceptions
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
Message-ID: <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>


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

From davidianwalker at gmail.com  Thu Feb 16 07:01:50 2012
From: davidianwalker at gmail.com (David Walker)
Date: Thu, 16 Feb 2012 23:31:50 +1030
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CABE=bROXb90M3Ft7zO8DVW4zxugyEu8pMmd_+oadJHY6WnyKvA@mail.gmail.com>

Teach the TCP/IP model ...

On 16/02/2012, John Kristoff <jtk at 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
>
>


From hank at efes.iucc.ac.il  Thu Feb 16 07:03:55 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 16 Feb 2012 15:03:55 +0200
Subject: Hi speed trading - hi speed monitoring
Message-ID: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>

Nanosecond Trading Could Make Markets Go Haywire
http://www.wired.com/wiredscience/2012/02/high-speed-trading/

"Below the 950-millisecond level, where computerized trading occurs so 
quickly that human traders can't even react, no fewer than 18,520 crashes 
and spikes occurred."

Anyone who has managed a network knows that when you look at your 
MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  Start 
looking at 1sec intervals and you will see spikes that hit 100% of capacity 
- even on networks running at 25% average utilization.

I guess trading and networking do have many unseen similarities.

-Hank



From owen at delong.com  Thu Feb 16 07:03:45 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 05:03:45 -0800
Subject: Common operational misconceptions
In-Reply-To: <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
Message-ID: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>


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



From jtk at cymru.com  Thu Feb 16 07:12:27 2012
From: jtk at cymru.com (John Kristoff)
Date: Thu, 16 Feb 2012 07:12:27 -0600
Subject: Common operational misconceptions
In-Reply-To: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
Message-ID: <20120216071227.7bf8a61e@w520.localdomain>

On Wed, 15 Feb 2012 22:26:11 -0500
Charles Mills <w3yni1 at 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


From rps at maine.edu  Thu Feb 16 07:17:03 2012
From: rps at maine.edu (Ray Soucy)
Date: Thu, 16 Feb 2012 08:17:03 -0500
Subject: Common operational misconceptions
In-Reply-To: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
Message-ID: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>

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


From jeff-kell at utc.edu  Thu Feb 16 07:27:14 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 16 Feb 2012 08:27:14 -0500
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D0432.6070201@utc.edu>

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


From jared at puck.nether.net  Thu Feb 16 07:25:22 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 16 Feb 2012 08:25:22 -0500
Subject: Common operational misconceptions
In-Reply-To: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
Message-ID: <46062C99-75D7-4B1D-AE78-A1ECF20785F7@puck.nether.net>

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

Jared Mauch

On Feb 16, 2012, at 8:03 AM, Owen DeLong <owen at 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.


From johnl at iecc.com  Thu Feb 16 07:33:55 2012
From: johnl at iecc.com (John R. Levine)
Date: 16 Feb 2012 08:33:55 -0500
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202160820001.4595@joyce.lan>

> 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

These certs cost $9.00.  You're not going to get much of an insurance 
policy at that price.

R's,
John


From rodrick.brown at gmail.com  Thu Feb 16 07:35:28 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Thu, 16 Feb 2012 08:35:28 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <87B432B3-94F6-411A-A8CD-B931B6DC74D9@gmail.com>

On Feb 16, 2012, at 8:03 AM, Hank Nussbacher <hank at efes.iucc.ac.il> wrote:

> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so quickly that human traders can't even react, no fewer than 18,520 crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  Start looking at 1sec intervals and you will see spikes that hit 100% of capacity - even on networks running at 25% average utilization

I've had great success using appliances from network monitoring vendor  Corvil - http://www.corvil.com/ and TS-A's TipOff - www.ts-a.com/TipOff/tipoff.html 

Both can decode most market data feeds formats and drill down to provide a slew of details when trying to debug jitter and latency on networks where sub-millisecond thresholds are essential for analysis.

Disclaimer: I'm no way affiliated with any of these companies or products.

> 
> I guess trading and networking do have many unseen similarities.
> 
> -Hank
> 
> 


From regnauld at nsrc.org  Thu Feb 16 07:36:59 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 14:36:59 +0100
Subject: Common operational misconceptions
In-Reply-To: <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <742C02BD-93F9-4EC4-96FE-ADC2BFAE5E30@charterschoolit.com>
Message-ID: <20120216133659.GA65401@macbook.bluepipe.net>

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



From regnauld at nsrc.org  Thu Feb 16 07:44:37 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 14:44:37 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216031208.132481D76BD5@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
Message-ID: <20120216134437.GB65401@macbook.bluepipe.net>

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.



From jethro.binks at strath.ac.uk  Thu Feb 16 07:49:47 2012
From: jethro.binks at strath.ac.uk (Jethro R Binks)
Date: Thu, 16 Feb 2012 13:49:47 +0000 (GMT)
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <alpine.BSF.2.00.1202161348160.68442@qrswnz.pp.fgengu.np.hx>

On Thu, 16 Feb 2012, Hank Nussbacher wrote:

> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so 
> quickly that human traders can't even react, no fewer than 18,520 
> crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your 
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  
> Start looking at 1sec intervals and you will see spikes that hit 100% of 
> capacity - even on networks running at 25% average utilization.
> 
> I guess trading and networking do have many unseen similarities.

Tieing the two together, this post shows how a lot of 'conventional' 
network thinking needs to be turned on its head when it comes to networks 
for trading floors:

http://www.fragmentationneeded.net/2011/12/pricing-and-trading-networks-down-is-up.html

Jethro.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK

The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.


From marka at isc.org  Thu Feb 16 07:51:26 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 00:51:26 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 13:01:43 BST."
 <20120216.130143.74691634.sthaug@nethelp.no>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
Message-ID: <20120216135126.40A051D8B63A@drugs.dv.isc.org>


In message <20120216.130143.74691634.sthaug at nethelp.no>, sthaug at 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 at nethelp.no
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From jeff-kell at utc.edu  Thu Feb 16 07:57:04 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Thu, 16 Feb 2012 08:57:04 -0500
Subject: Common operational misconceptions
In-Reply-To: <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <20120215225244.GA25272@gsp.org>
 <5BE69C32-0E92-4C7E-B4D2-DAC646D91A0C@ctcampbell.com>
Message-ID: <4F3D0B30.1090504@utc.edu>

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



From cra at WPI.EDU  Thu Feb 16 08:01:59 2012
From: cra at WPI.EDU (Chuck Anderson)
Date: Thu, 16 Feb 2012 09:01:59 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3D0432.6070201@utc.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D0432.6070201@utc.edu>
Message-ID: <20120216140159.GT17691@angus.ind.WPI.EDU>

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.


From jeroen at unfix.org  Thu Feb 16 08:01:41 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 16 Feb 2012 15:01:41 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216135126.40A051D8B63A@drugs.dv.isc.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
 <20120216135126.40A051D8B63A@drugs.dv.isc.org>
Message-ID: <4F3D0C45.9020100@unfix.org>

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


From shuque at upenn.edu  Thu Feb 16 08:08:18 2012
From: shuque at upenn.edu (Shumon Huque)
Date: Thu, 16 Feb 2012 09:08:18 -0500
Subject: Common operational misconceptions
In-Reply-To: <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com>
 <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com>
 <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
Message-ID: <20120216140818.GA15528@isc.upenn.edu>

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 at bogus.com] 
> Sent: Wednesday, February 15, 2012 11:58 PM
> To: Kenneth M. Chipps Ph.D.
> Cc: nanog at 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.


From marka at isc.org  Thu Feb 16 08:28:36 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 01:28:36 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 14:44:37 BST."
 <20120216134437.GB65401@macbook.bluepipe.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
Message-ID: <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>


In message <20120216134437.GB65401 at 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 at isc.org


From marka at isc.org  Thu Feb 16 08:50:22 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 01:50:22 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 15:01:41 BST."
 <4F3D0C45.9020100@unfix.org>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216.130143.74691634.sthaug@nethelp.no>
 <20120216135126.40A051D8B63A@drugs.dv.isc.org> <4F3D0C45.9020100@unfix.org>
Message-ID: <20120216145022.E327B1D8C0AF@drugs.dv.isc.org>


In message <4F3D0C45.9020100 at 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 at isc.org


From hank at efes.iucc.ac.il  Thu Feb 16 09:07:48 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Thu, 16 Feb 2012 17:07:48 +0200
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <alpine.BSF.2.00.1202161348160.68442@qrswnz.pp.fgengu.np.hx
 >
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
 <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <5.1.0.14.2.20120216170730.03667380@efes.iucc.ac.il>

At 13:49 16/02/2012 +0000, Jethro R Binks wrote:
>On Thu, 16 Feb 2012, Hank Nussbacher wrote:
>
> > Nanosecond Trading Could Make Markets Go Haywire
> > http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> >
> > "Below the 950-millisecond level, where computerized trading occurs so
> > quickly that human traders can't even react, no fewer than 18,520
> > crashes and spikes occurred."
> >
> > Anyone who has managed a network knows that when you look at your
> > MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.
> > Start looking at 1sec intervals and you will see spikes that hit 100% of
> > capacity - even on networks running at 25% average utilization.
> >
> > I guess trading and networking do have many unseen similarities.
>
>Tieing the two together, this post shows how a lot of 'conventional'
>network thinking needs to be turned on its head when it comes to networks
>for trading floors:
>
>http://www.fragmentationneeded.net/2011/12/pricing-and-trading-networks-down-is-up.html

Great article!

Thanks for sharing,
Hank


>Jethro.
>
>.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .
>Jethro R Binks, Network Manager,
>Information Services Directorate, University Of Strathclyde, Glasgow, UK
>
>The University of Strathclyde is a charitable body, registered in
>Scotland, number SC015263.



From ttauber at 1-4-5.net  Thu Feb 16 09:51:19 2012
From: ttauber at 1-4-5.net (Tony Tauber)
Date: Thu, 16 Feb 2012 10:51:19 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <4F3C76D5.9040603@necom830.hpcl.titech.ac.jp>
 <CAOF0KO92Bg3tzFa5PcF4ATka=-AqM8=9QegP6b+4-_3gHdRJaA@mail.gmail.com>
Message-ID: <CAGQUKcerrYz9=b_u5xrbpRzhVfh6bYXCwrzV0zxOAq9FbTV4HQ@mail.gmail.com>

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

From morrowc.lists at gmail.com  Thu Feb 16 10:13:07 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 16 Feb 2012 11:13:07 -0500
Subject: SSL Certificates
In-Reply-To: <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
Message-ID: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>

On Thu, Feb 16, 2012 at 8:33 AM, John R. Levine <johnl at iecc.com> wrote:
>> 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
>
>
> These certs cost $9.00. ?You're not going to get much of an insurance policy
> at that price.

again, startssl.com - free. why pay? it's (as you say) not actually
buying you anything except random bits anyway... if you can get them
for free, why would you not do that?


From bicknell at ufp.org  Thu Feb 16 10:21:08 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 16 Feb 2012 08:21:08 -0800
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <20120216162108.GA11808@ussenterprise.ufp.org>

In a message written on Thu, Feb 16, 2012 at 12:57:25AM -0600, Jimmy Hess wrote:
> 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.

One thing I'm not clear about is, are there any protocol or
implementation limitations that require only one CA?

I would think I could take my private key and get multiple CA's to
sign it, then present all of those signatures to the client.  Should
one CA be revoked, my certificate would still be signed by one or
more others.

Does this work?  Does anyone do it?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/1cc02fef/attachment.bin>

From johnl at iecc.com  Thu Feb 16 10:21:12 2012
From: johnl at iecc.com (John R. Levine)
Date: 16 Feb 2012 11:21:12 -0500
Subject: SSL Certificates
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202161117300.13754@joyce.lan>

>> These certs cost $9.00. ?You're not going to get much of an insurance policy
>> at that price.
>
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?

The free ones are supposed to be used only for personal sites.

Also, the fact that they tell me to go away and use a different browser 
when I try to sign up using Chrome does not fill me with warm feelings.

Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From jeroen at unfix.org  Thu Feb 16 10:21:33 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 16 Feb 2012 17:21:33 +0100
Subject: SSL Certificates
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <4F3D2D0D.3040005@unfix.org>

On 2012-02-16 17:13 , Christopher Morrow wrote:
> On Thu, Feb 16, 2012 at 8:33 AM, John R. Levine <johnl at iecc.com> wrote:
>>> 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
>>
>>
>> These certs cost $9.00.  You're not going to get much of an insurance policy
>> at that price.
> 
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?

Because they do not have a wildcard one for 'free', which is useful when
one wants to serve eg example.com but als www.example.com from the same
location along with other variants of the hostname. Except for that, it
is a rather great offer. Though one can of course just serve the
example.com one and force people after they accept to the main site.

I tend to stick CAcert ones on hosts and tell people to either just
accept that single cert and store it for future checks or just install
the CAcert root cert, that covers a lot of hosts in one go, given of
course that one trusts what CAcert is doing, but that goes for anything.

The method that Firefox is using with the unchained certificates "save
this unverified cert and as long as it is the same it is great" is in
that respect similar to SSH hostkeys, one can verify those offline and
just keep on using them as as long as that cert is the same you are
likely talking to the same host (ssl etc still don't cover compromised
hosts).

In the end, they are just bits, and this whole verification thing at the
verification of owner adds nothing except for an ease-of-use factor for
the non-techy folks on the Internet.

Greets,
 Jeroen


From johnl at iecc.com  Thu Feb 16 10:29:03 2012
From: johnl at iecc.com (John Levine)
Date: 16 Feb 2012 16:29:03 -0000
Subject: SSL Certificates
In-Reply-To: <20120216162108.GA11808@ussenterprise.ufp.org>
Message-ID: <20120216162903.14199.qmail@joyce.lan>

In article <20120216162108.GA11808 at ussenterprise.ufp.org> you write:
>-=-=-=-=-=-
>
>In a message written on Thu, Feb 16, 2012 at 12:57:25AM -0600, Jimmy Hess wrote:
>> 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.
>
>One thing I'm not clear about is, are there any protocol or
>implementation limitations that require only one CA?

I've had the same cert signed by multiple CAs, although rarely at the
same time.  Never tried to present both versions in the same session,
though.

R's,
John


From regnauld at nsrc.org  Thu Feb 16 10:53:08 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Thu, 16 Feb 2012 17:53:08 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
Message-ID: <20120216165308.GE65401@macbook.bluepipe.net>

	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


From jbates at brightok.net  Thu Feb 16 11:08:22 2012
From: jbates at brightok.net (Jack Bates)
Date: Thu, 16 Feb 2012 11:08:22 -0600
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D3806.4000008@brightok.net>

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


From jm-nanog at vj8.net  Thu Feb 16 11:54:39 2012
From: jm-nanog at vj8.net (James Triplett)
Date: Thu, 16 Feb 2012 12:54:39 -0500
Subject: SSL Certificates startssl.com
In-Reply-To: <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
 <alpine.BSF.2.00.1202160820001.4595@joyce.lan>
 <CAL9jLaZtNv_RqW9zLmu8Cp=6-0CS76zgbSUwxLUB+z2m6-_j=w@mail.gmail.com>
Message-ID: <20120216175439.GA14119@datamat.net>

On (16/02/12 11:13), Christopher Morrow wrote:
> again, startssl.com - free. why pay? it's (as you say) not actually
> buying you anything except random bits anyway... if you can get them
> for free, why would you not do that?
> 

They may not charge money, but it's not really free.  You have to
provide them so much personal information, it feels like an
invitation to identity theft.  At the least what they collect would
be valuable information to sell to marketeers.

They demand a valid residential address for the free personal-use certificate;
a business address will not do (and they check).  Our mixed-use building did
not qualify.

Next option is one of their cheap business certificates, but then you must
send scanned images of:
	1. The cover of your passport
	2. The first pages of the passport
	3. The picture of you with your personal detail of your passport
		 and
	1. Both sides of your drivers license or identity card or
	2. Photo ID document issued by a local, state or federal authority.

In order to save a couple bucks, I'm gonna scan all this and send it off
to somewhere in Israel???  Geotrust or Comodo don't put you through this.  
For $10, I'll keep my info, thanks.









From michael at rancid.berkeley.edu  Thu Feb 16 13:10:45 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Thu, 16 Feb 2012 11:10:45 -0800
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
Message-ID: <4F3D54B5.4000109@rancid.berkeley.edu>

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


From cjp at 0x1.net  Thu Feb 16 13:25:32 2012
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Thu, 16 Feb 2012 14:25:32 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <20120216192532.GA57917@byzantium.local>

On Thu, Feb 16, 2012 at 03:03:55PM +0200, Hank Nussbacher wrote:
> Anyone who has managed a network knows that when you look at your
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.
> Start looking at 1sec intervals and you will see spikes that hit
> 100% of capacity - even on networks running at 25% average
> utilization.

As sampling rate approaches zero, so will the "spikyness" of the
graph--ultimately an interface is either sending a frame (100%) or it's
not (0%).

-cjp


From owen at delong.com  Thu Feb 16 13:25:18 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 11:25:18 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120216140818.GA15528@isc.upenn.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C8A4B.1090309@gmx.com> <00e501ccec68$65aa8650$30ff92f0$@chipps.com>
 <4F3C9ACF.2050108@bogus.com> <00f201ccec70$3a4c8f50$aee5adf0$@chipps.com>
 <20120216140818.GA15528@isc.upenn.edu>
Message-ID: <DC1DF01C-46A1-4FF0-B420-D8AB131CE363@delong.com>

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 at bogus.com] 
>> Sent: Wednesday, February 15, 2012 11:58 PM
>> To: Kenneth M. Chipps Ph.D.
>> Cc: nanog at 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.



From dholmes at mwdh2o.com  Thu Feb 16 13:41:17 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Thu, 16 Feb 2012 11:41:17 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <922ACC42D498884AA02B3565688AF9953403542EB5@USEXMBS01.mwd.h2o>

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 at cymru.com]
Sent: Wednesday, February 15, 2012 12:47 PM
To: nanog at 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.


From marka at isc.org  Thu Feb 16 14:22:42 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 07:22:42 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Thu, 16 Feb 2012 17:53:08 BST."
 <20120216165308.GE65401@macbook.bluepipe.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
 <20120216165308.GE65401@macbook.bluepipe.net>
Message-ID: <20120216202242.C18381D8C58B@drugs.dv.isc.org>


In message <20120216165308.GE65401 at 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 at isc.org


From andreas at livejournalinc.com  Thu Feb 16 14:27:08 2012
From: andreas at livejournalinc.com (Andreas Echavez)
Date: Thu, 16 Feb 2012 13:27:08 -0700
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>

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

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

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

Thanks!
Andreas


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

From web at typo.org  Thu Feb 16 14:35:15 2012
From: web at typo.org (Wayne E Bouchard)
Date: Thu, 16 Feb 2012 13:35:15 -0700
Subject: Common operational misconceptions
In-Reply-To: <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
Message-ID: <20120216203515.GA5775@wakko.typo.org>

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

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


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


From george.herbert at gmail.com  Thu Feb 16 14:41:11 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 12:41:11 -0800
Subject: SSL Certificates
In-Reply-To: <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
References: <569AB73B-41C1-4B63-BE2D-3F67C27B990B@develooper.com>
 <20120216001700.52490.qmail@joyce.lan>
 <CAK__KzufZm8=shcztXGbNa-Jqw9dBkhEE=61haEHuJH9h8WW-Q@mail.gmail.com>
 <CAAAwwbWmiAgX5RB-1wTmJZNmkWU7wkHA6HA-THGZ3bYfRGsW6A@mail.gmail.com>
Message-ID: <CAK__Kzth_d3UxDyaGRNpHPkexCQMwU9j8wpnySZXs_Yr9MdXTQ@mail.gmail.com>

On Wed, Feb 15, 2012 at 10:57 PM, Jimmy Hess <mysidia at gmail.com> wrote:
> On Wed, Feb 15, 2012 at 6:49 PM, George Herbert
> <george.herbert at gmail.com> wrote:
>> On Wed, Feb 15, 2012 at 4:17 PM, John Levine <johnl at iecc.com> 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.

Please recall that this HAS happened to another CA in the last year.


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

I think that's highly ass-backwards.

If it's been compromised and the compromise is not yet "fully known" -
revoked by the CA or distrusted by browsers - we exist in a nether
region where the customers connecting to "your" servers can be
transparently Man-in-the-Middle attacked.  If someone doing MiiM to
your customers would be a significant problem, then it's incumbent
upon you to not put your head in the sand when there's a
higher-than-normal risk that one CA may have A Problem.

The situation is in fact *worse* than "completely worthless".  In that
situation it has an active negative value.

This is complicated by the fact that you don't even need to be a
customer of that CA for that to be a risk.  If browsers trust that CA,
and that CA's keys are loose, then anyone with those can impersonate
anyone else on the net transparently.  But the fix for that revokes
the root cert and all the signed certs for that CA.  Immediately, if
the browser vendors response to the prior incident carries through to
a new one.  Buying new certs or continuing to use certs that have a
noticable risk of immediate revocation seems ... unwise.


Again - I don't know if it's been compromised.  The vendor is not
being forthcoming at that level of detail yet.  They are evidently
still trying to figure out how bad the penetration was.  That is not a
good sign, but does not automatically mean the worst by any means.


-- 
-george william herbert
george.herbert at gmail.com


From jchambers at ucla.edu  Thu Feb 16 14:59:01 2012
From: jchambers at ucla.edu (Jason Chambers)
Date: Thu, 16 Feb 2012 12:59:01 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <4F3D6E15.7080006@ucla.edu>

On 2/16/12 5:03 AM, Hank Nussbacher wrote:
> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so
> quickly that human traders can't even react, no fewer than 18,520
> crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well. 
> Start looking at 1sec intervals and you will see spikes that hit 100% of
> capacity - even on networks running at 25% average utilization.
> 
> I guess trading and networking do have many unseen similarities.
> 

Some complementary information I read a few weeks ago:

http://www.homelandsecuritynewswire.com/critical-cyber-vulnerabilities-found-financial-system

http://www.cpacket.com/latency

http://www.cpacket.com/download/Introduction%20to%20Network%20Latency%20Engineering.pdf



Regards,

--Jason



From streiner at cluebyfour.org  Thu Feb 16 15:02:29 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 16 Feb 2012 16:02:29 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <20120216203515.GA5775@wakko.typo.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
 <20120216203515.GA5775@wakko.typo.org>
Message-ID: <Pine.LNX.4.64.1202161558540.11697@whammy.cluebyfour.org>

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

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

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

jms


From randy at psg.com  Thu Feb 16 15:08:46 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 16 Feb 2012 13:08:46 -0800
Subject: time sink 42
Message-ID: <m2aa4ih4f5.wl%randy@psg.com>

ok, this is horribly pragmatic, but it's real.  yesterday i was in the
westin playing rack and stack for five hours.  an horrifyingly large
amount of my time was spent trying to peel apart labels made on my
portable brother label tape maker, yes peeling the backing from a little
label so remote hands could easily confirm a server they were going to
attack.

is there a trick?  is there a (not expensive) different labeling machine
or technique i should use?

randy


From blakjak at blakjak.net  Thu Feb 16 15:12:15 2012
From: blakjak at blakjak.net (Mark Foster)
Date: Fri, 17 Feb 2012 10:12:15 +1300
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <4F3D712F.50304@blakjak.net>

On 17/02/12 10:08, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>
Many label makers (including Brother) use tapes that have a split up the
middle of the back layer, so you can peel it off half-at-a-time and not
fight with finding edges, etc.

Otherwise I suppose it's just a case of finding the knack.  My label
maker is of the cheaper variety and the tape i've been getting for it
doesn't have the back-split, so I get to fight with it on the occasion
that the knack doesn't seem to work...

Mark.


From george.herbert at gmail.com  Thu Feb 16 15:14:11 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 13:14:11 -0800
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <CAK__KzvaTau-Lrq2Kpyxw6LWfAdjL-mhqHdbg+QrZtL43XadhQ@mail.gmail.com>

Brothers' are fine; buy the tapes that have the split-down-the-middle
backing on them.

It reduces the unpeeling problem from
more-time-than-the-label-took-to-type-in to about 2 seconds.  You just
grab the edges at an end and bend it, so the backing bulges outwards,
and off it starts to come.


-george

On Thu, Feb 16, 2012 at 1:08 PM, Randy Bush <randy at psg.com> wrote:
> ok, this is horribly pragmatic, but it's real. ?yesterday i was in the
> westin playing rack and stack for five hours. ?an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick? ?is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>



-- 
-george william herbert
george.herbert at gmail.com


From bicknell at ufp.org  Thu Feb 16 15:15:47 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 16 Feb 2012 13:15:47 -0800
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <20120216211547.GA23755@ussenterprise.ufp.org>

In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.

The Brother I have that takes "M" tape has the problem you describe,
it's nearly impossible to get the backing to separate from the label.

I have another Brother that takes "TZ" tape, the backing of the tape of
slit down the middle lengthwise.  Gently curling the tape by squeezing
it causes the middle to pop open, easy to grab.

You can guess which one sits on the shelf, and which one gets used a
lot.

The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
anymore but there are several similar curent models.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/ca930803/attachment.bin>

From mike.lyon at gmail.com  Thu Feb 16 15:18:42 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 16 Feb 2012 13:18:42 -0800
Subject: time sink 42
In-Reply-To: <20120216211547.GA23755@ussenterprise.ufp.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
Message-ID: <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>

If they are Dell servers, you could always name each host in their BIOS so
it shows up on the display of the host.

-Mike


On Thu, Feb 16, 2012 at 1:15 PM, Leo Bicknell <bicknell at ufp.org> wrote:

> In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush
> wrote:
> > ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> > westin playing rack and stack for five hours.  an horrifyingly large
> > amount of my time was spent trying to peel apart labels made on my
> > portable brother label tape maker, yes peeling the backing from a little
> > label so remote hands could easily confirm a server they were going to
> > attack.
>
> The Brother I have that takes "M" tape has the problem you describe,
> it's nearly impossible to get the backing to separate from the label.
>
> I have another Brother that takes "TZ" tape, the backing of the tape of
> slit down the middle lengthwise.  Gently curling the tape by squeezing
> it causes the middle to pop open, easy to grab.
>
> You can guess which one sits on the shelf, and which one gets used a
> lot.
>
> The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
> anymore but there are several similar curent models.
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>



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

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

From keegan.holley at sungard.com  Thu Feb 16 15:18:44 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 16 Feb 2012 16:18:44 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <CABO8Q6TuX4fuqxh06Jp6t6u5uge66Fd42GOq0KfLJCqN4ThcKw@mail.gmail.com>

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

2012/2/15 John Kristoff <jtk at cymru.com>

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

From erik.soosalu at calyxinc.com  Thu Feb 16 15:20:06 2012
From: erik.soosalu at calyxinc.com (Erik Soosalu)
Date: Thu, 16 Feb 2012 16:20:06 -0500
Subject: time sink 42
In-Reply-To: <20120216211547.GA23755@ussenterprise.ufp.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
Message-ID: <0B224A2FE01CC54C860290D42474BF60052D5413@exchange.nff.local>

The other trick is to pre-print your labels.

We use a Brother PT-9500PC to print our labels.  It is a dedicated PC
printer, but it always half-cuts a little tab at the end of the label so
you bend the label at the cut and it is simple to pull off.


Thanks,
Erik 
-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Thursday, February 16, 2012 4:16 PM
To: North American Network Operators' Group
Subject: Re: time sink 42

In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy
Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a
little
> label so remote hands could easily confirm a server they were going to
> attack.

The Brother I have that takes "M" tape has the problem you describe,
it's nearly impossible to get the backing to separate from the label.

I have another Brother that takes "TZ" tape, the backing of the tape of
slit down the middle lengthwise.  Gently curling the tape by squeezing
it causes the middle to pop open, easy to grab.

You can guess which one sits on the shelf, and which one gets used a
lot.

The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
anymore but there are several similar curent models.

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


From mooregr at greenms.com  Thu Feb 16 15:20:48 2012
From: mooregr at greenms.com (Greg D. Moore)
Date: Thu, 16 Feb 2012 16:20:48 -0500
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <mailman.16.1329427258.46016.nanog@nanog.org>

At 04:08 PM 2/16/2012, Randy Bush wrote:
>ok, this is horribly pragmatic, but it's real.  yesterday i was in the
>westin playing rack and stack for five hours.  an horrifyingly large
>amount of my time was spent trying to peel apart labels made on my
>portable brother label tape maker, yes peeling the backing from a little
>label so remote hands could easily confirm a server they were going to
>attack.
>
>is there a trick?  is there a (not expensive) different labeling machine
>or technique i should use?

If you can't find the split back I've used a black uniball pen. Stick 
tape between pen and metal clip.  Rotate pen about 90 degrees so 
there's a bend in the tape.  But thumb against the metal, holding the 
tape in place.  Pull pen along the length of the tape.  (think about 
the old trick with scissors and making wrapping ribbon for presents 
turn into a curlycue.

That tends to create enough of a tension between the front of the 
tape and the back and it'll be peeled apart.



>randy

Greg D. 
Moore 
http://greenmountainsoftware.wordpress.com/
CEO QuiCR: Quick, Crowdsourced Responses. http://www.quicr.net





From morrowc.lists at gmail.com  Thu Feb 16 15:21:21 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 16 Feb 2012 16:21:21 -0500
Subject: time sink 42
In-Reply-To: <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
Message-ID: <CAL9jLabMo_fEmu2Yr7dA05LPxA6ECtj7TOrO6eZgXG6o=+F9DQ@mail.gmail.com>

On Thu, Feb 16, 2012 at 4:18 PM, Mike Lyon <mike.lyon at gmail.com> wrote:
> If they are Dell servers, you could always name each host in their BIOS so
> it shows up on the display of the host.

provided the dell actually had that display, and provided the server
didn't toss a PS ...

http://www.amazon.com/RHINO-101-WITH-SELF-LAM/dp/B001O84KYE

sort of looks neat, wonder if the tape is the split-type.

> -Mike
>
>
> On Thu, Feb 16, 2012 at 1:15 PM, Leo Bicknell <bicknell at ufp.org> wrote:
>
>> In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush
>> wrote:
>> > ok, this is horribly pragmatic, but it's real. ?yesterday i was in the
>> > westin playing rack and stack for five hours. ?an horrifyingly large
>> > amount of my time was spent trying to peel apart labels made on my
>> > portable brother label tape maker, yes peeling the backing from a little
>> > label so remote hands could easily confirm a server they were going to
>> > attack.
>>
>> The Brother I have that takes "M" tape has the problem you describe,
>> it's nearly impossible to get the backing to separate from the label.
>>
>> I have another Brother that takes "TZ" tape, the backing of the tape of
>> slit down the middle lengthwise. ?Gently curling the tape by squeezing
>> it causes the middle to pop open, easy to grab.
>>
>> You can guess which one sits on the shelf, and which one gets used a
>> lot.
>>
>> The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
>> anymore but there are several similar curent models.
>>
>> --
>> ? ? ? Leo Bicknell - bicknell at ufp.org - CCIE 3440
>> ? ? ? ?PGP keys at http://www.ufp.org/~bicknell/
>>
>
>
>
> --
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon


From daniel at fx.net.nz  Thu Feb 16 15:23:30 2012
From: daniel at fx.net.nz (Daniel Griggs)
Date: Fri, 17 Feb 2012 10:23:30 +1300
Subject: Common operational misconceptions
In-Reply-To: <20120216165308.GE65401@macbook.bluepipe.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com>
 <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
 <20120216165308.GE65401@macbook.bluepipe.net>
Message-ID: <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg@mail.gmail.com>

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

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

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

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

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

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




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

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


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

From keegan.holley at sungard.com  Thu Feb 16 15:25:15 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Thu, 16 Feb 2012 16:25:15 -0500
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>

If you're building a datacenter probably not.  Other than giving the remote
hands some identifier and making them label the servers themselves.  If
you're at a conference you could get away with using masking tape and a
sharpie.  If you think it was time consuming applying the labels wait until
you need to remove one.


2012/2/16 Randy Bush <randy at psg.com>

> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>
>
>

From jlewis at lewis.org  Thu Feb 16 15:27:26 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Thu, 16 Feb 2012 16:27:26 -0500 (EST)
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <Pine.LNX.4.61.1202161624360.2201@soloth.lewis.org>

On Thu, 16 Feb 2012, Randy Bush wrote:

> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?

Nobody's been a smart ass yet and suggested a roll of duct tape and a 
sharpie?

All the labelers I've used have had the split down the middle tape, so 
just bend the label horizontally onto itself, and the backing separates.

Which reminds me, I have a new fiber transit connection I just turned up 
which needs labeling...and someone seems to have run off with my brother.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From jfbeam at gmail.com  Thu Feb 16 15:30:31 2012
From: jfbeam at gmail.com (Ricky Beam)
Date: Thu, 16 Feb 2012 16:30:31 -0500
Subject: time sink 42
In-Reply-To: <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
Message-ID: <op.v9sjc5y8tfhldh@rbeam.xactional.com>

On Thu, 16 Feb 2012 16:18:42 -0500, Mike Lyon <mike.lyon at gmail.com> wrote:
> If they are Dell servers, you could always name each host in their BIOS  
> so it shows up on the display of the host.

I did that with a batch of sun v20z's... when they got to the colo, no one  
knew which was which until they're powered and the service processor is  
fully booted. (a process that takes several minutes) By then, they've been  
racked in the wrong racks and in the wrong order. :-(  Of course, I've  
done that to myself as well... pull a stack of machines and forget what  
order they were in :-)

--Ricky


From Joel.Snyder at Opus1.COM  Thu Feb 16 15:32:07 2012
From: Joel.Snyder at Opus1.COM (Joel M Snyder)
Date: Thu, 16 Feb 2012 14:32:07 -0700
Subject: time sink 42
In-Reply-To: <mailman.3982.1329427419.46019.nanog@nanog.org>
References: <mailman.3982.1329427419.46019.nanog@nanog.org>
Message-ID: <4F3D75D7.3010903@opus1.com>

On 2/16/12 2:23 PM, nanog-request at nanog.org wrote:
> time sink 42

Others have already noted the difference between TZ and M tapes; the TZ 
tapes are also supposed to be 'better' in that they are laminated, while 
the M tapes are not and may decay more quickly.

However, the problem I have is that the "better" label maker (the one 
that takes TZ tapes) is not nearly as easy to use as the "cheaper" one, 
the M-compatible P-touch.  I knew that I didn't want a bunch of useless 
features, so I bought the cheapest TZ-compatible P-touch I could find, 
the 1290, but it is about twice as hard to get anything done with it as 
the bottom-of-the-line $19.95 P-Touch that takes M tapes.

Anyone got a solution for *that* particular problem?  Should I get a 
better TZ-compatible labeler?

jms

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
jms at Opus1.COM                http://www.opus1.com/jms


From streiner at cluebyfour.org  Thu Feb 16 15:32:42 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 16 Feb 2012 16:32:42 -0500 (EST)
Subject: time sink 42
In-Reply-To: <20120216211547.GA23755@ussenterprise.ufp.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.64.1202161629150.11697@whammy.cluebyfour.org>

On Thu, 16 Feb 2012, Leo Bicknell wrote:

> The Brother I have that takes "M" tape has the problem you describe,
> it's nearly impossible to get the backing to separate from the label.
>
> I have another Brother that takes "TZ" tape, the backing of the tape of
> slit down the middle lengthwise.  Gently curling the tape by squeezing
> it causes the middle to pop open, easy to grab.

+1 for the TZ tape.  It is made of a heavier material than the M tape, and 
has better adhesive that will better on equipment that has any sort of 
textured finish, such as many types of cabinets, patch panels, and fiber 
termination bays.  Labels that are made with M tape will start to peel off 
of just about anything that doesn't have a smooth finish shortly after 
being applied.

jms


From cmadams at hiwaay.net  Thu Feb 16 15:33:38 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 16 Feb 2012 15:33:38 -0600
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <20120216213338.GA9953@hiwaay.net>

Once upon a time, Randy Bush <randy at psg.com> said:
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?

Like others, I use a Brother P-Touch with TZ tapes with a split down the
middle.  However, the last couple of tapes had splits that weren't cut
quite right, and they wouldn't peel easily.

What I usually do in that case (or with non-split tape) is to curl the
end of the tape across the blade of my pocket knife.  The tape and the
backing curl differently, so this makes it easy to then get the blade of
the knife between the tape and the backing and separate them.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From msa at latt.net  Thu Feb 16 15:35:05 2012
From: msa at latt.net (Majdi S. Abbas)
Date: Thu, 16 Feb 2012 14:35:05 -0700
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <20120216213505.GB18506@puck.nether.net>

On Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.

	Randy,

	Personally, I got tired of buying batteries, and expensive label
tapes, and tend to stick with Avery labels from the office supply store
(or Brady labels for cabling), and preprinting.  Either can be run
through a typewriter, and the Avery labels tend to run through a standard
office printer just fine.

	Then I just have to peel a standard label off of wax paper, which
is much easier than dealing with plastic tape that appears to be fused
to its backing at the factory.

	The split back variety is a little better, but even then it can be
hard to get your fingernails under the other side.  We haven't really
improved much on labeling technology in decades.

	--msa


From ttauber at 1-4-5.net  Thu Feb 16 15:40:45 2012
From: ttauber at 1-4-5.net (Tony Tauber)
Date: Thu, 16 Feb 2012 16:40:45 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120216203515.GA5775@wakko.typo.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAD8GWssw53E6RqLS7x5YxJzG_+1BAHxarWQCBT6tVADCLvXiHA@mail.gmail.com>
 <20120216203515.GA5775@wakko.typo.org>
Message-ID: <CAGQUKccmtia-_7P8en4gozDHXhMCZAwTUzsQ0rsU+=GwNHHdVQ@mail.gmail.com>

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

Tony

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

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

From Justin.Dixon at BBandT.com  Thu Feb 16 15:45:49 2012
From: Justin.Dixon at BBandT.com (Dixon, Justin)
Date: Thu, 16 Feb 2012 21:45:49 +0000
Subject: time sink 42
In-Reply-To: <20120216213505.GB18506@puck.nether.net>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216213505.GB18506@puck.nether.net>
Message-ID: <52A4B7C174F4334C9C6D5BEE83775FD102925A@WIL-EXMBX11.bbtnet.com>

> -----Original Message-----
> From: Majdi S. Abbas [mailto:msa at latt.net]
> Sent: Thursday, February 16, 2012 16:35
> To: Randy Bush
> Cc: North American Network Operators' Group
> Subject: Re: time sink 42
> 
> On Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush wrote:
> > ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> > westin playing rack and stack for five hours.  an horrifyingly large
> > amount of my time was spent trying to peel apart labels made on my
> > portable brother label tape maker, yes peeling the backing from a little
> > label so remote hands could easily confirm a server they were going to
> > attack.
> 
> 	Randy,
> 
> 	Personally, I got tired of buying batteries, and expensive label
> tapes, and tend to stick with Avery labels from the office supply store
> (or Brady labels for cabling), and preprinting.  Either can be run
> through a typewriter, and the Avery labels tend to run through a standard
> office printer just fine.
> 
> 	Then I just have to peel a standard label off of wax paper, which
> is much easier than dealing with plastic tape that appears to be fused
> to its backing at the factory.
> 
> 	The split back variety is a little better, but even then it can be
> hard to get your fingernails under the other side.  We haven't really
> improved much on labeling technology in decades.
> 
> 	--msa

No mention of good (*detailed*) documentation based on model/serial number and facility rack ID/rack position in case the label were to inadvertently be removed/fall off/etc.?

Only issue with that approach is that if the colo facility moves your hardware at some point you need to ensure that they let you know that so you can update your documentation to coincide with (hopefully) their documentation of where your equipment is located.

Justin


From bicknell at ufp.org  Thu Feb 16 15:47:26 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 16 Feb 2012 13:47:26 -0800
Subject: time sink 42
In-Reply-To: <4F3D75D7.3010903@opus1.com>
References: <mailman.3982.1329427419.46019.nanog@nanog.org>
 <4F3D75D7.3010903@opus1.com>
Message-ID: <20120216214726.GA24970@ussenterprise.ufp.org>

In a message written on Thu, Feb 16, 2012 at 02:32:07PM -0700, Joel M Snyder wrote:
> features, so I bought the cheapest TZ-compatible P-touch I could find, 
> the 1290, but it is about twice as hard to get anything done with it as 
> the bottom-of-the-line $19.95 P-Touch that takes M tapes.
> 
> Anyone got a solution for *that* particular problem?  Should I get a 
> better TZ-compatible labeler?

Brother seems to have about 20 different models out at any time,
and replaces about 2 of them once a year.  Chances are you can find
one you like.  My kingdom for a model that didn't hide an apostrophy
on a sub-menu.

The "step up" solution is something like Brady.  Significantly more
expensive label makers, somewhat more expensive supplies.  However
I generally think they are superior in UI, durability, label
selection, and so on.  Many also have a serial port (I think USB
on a few of the new ones) so you can "print" (basically an ASCII
stream) to them which can make large volume labling really easy
from your PC.  If you're spending more than a half hour a day with your
label maker invest in a mid-range Brady.

The "step down" is a pen.  For labeling cables sheets of the "self
laminating" labels (a white tab with a clear tail) are easy to write on
and laminate as you install them.  No batteries, super small for a ton
of labels, easy to use.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/eee808e3/attachment.bin>

From sparctacus at gmail.com  Thu Feb 16 15:51:15 2012
From: sparctacus at gmail.com (Bryan Irvine)
Date: Thu, 16 Feb 2012 13:51:15 -0800
Subject: time sink 42
In-Reply-To: <op.v9sjc5y8tfhldh@rbeam.xactional.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
Message-ID: <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>

On Thu, Feb 16, 2012 at 1:30 PM, Ricky Beam <jfbeam at gmail.com> wrote:
> On Thu, 16 Feb 2012 16:18:42 -0500, Mike Lyon <mike.lyon at gmail.com> wrote:
>>
>> If they are Dell servers, you could always name each host in their BIOS so
>> it shows up on the display of the host.
>
>
> I did that with a batch of sun v20z's... when they got to the colo, no one
> knew which was which until they're powered and the service processor is
> fully booted. (a process that takes several minutes) By then, they've been
> racked in the wrong racks and in the wrong order. :-( ?Of course, I've done
> that to myself as well... pull a stack of machines and forget what order
> they were in :-)

And watch for the removable faceplates.  We've been bitten before
after a server move by rebooting a server that had the correct label
but the wrong faceplate.  Now we label the faceplate as well as
underneath of it too.  :-)

-B


From jra at baylink.com  Thu Feb 16 15:53:20 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 16 Feb 2012 16:53:20 -0500 (EST)
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <31408939.3145.1329429200455.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Randy Bush" <randy at psg.com>

> ok, this is horribly pragmatic, but it's real. yesterday i was in the
> westin playing rack and stack for five hours. an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to attack.
> 
> is there a trick? is there a (not expensive) different labeling
> machine or technique i should use?

1) You should make sure you're buying the newer crack-n-peel labels, on 
which the backing is scored along the center.

2) If you have the older stuff, bend a corner sharply from the plastic
side (front) towards the paper side (backing).  The plastic label has more
spring in it, and will spring back away from the paper -- which will stay
bent -- and you'll have some separation that you can peel from.

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


From mark at viviotech.net  Thu Feb 16 16:01:08 2012
From: mark at viviotech.net (Mark Keymer)
Date: Thu, 16 Feb 2012 14:01:08 -0800
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <4F3D7CA4.9020204@viviotech.net>

Hi Randy,

I know where you are coming from. I have going throw many types. 
Currently we use the Bothers P-Touch with the TZe Tape with the specific 
"Cable/Wire Labels" tape. It works ok and the labels last much longer 
then the previous masking tape with sharpe method.

Overall I pay more money then I would like for the machine and the Tape. 
But it seems to work well and that does mean something.

One of my techs have been look at the  "TekGun - Cable Labeling System" 
for cables. It does look kind of cool. Anyone here have experience with 
that TekGun and what are your thoughts on it?

Mark Keymer
CFO/COO
Vivio Technologies


On 2/16/2012 1:08 PM, Randy Bush wrote:
> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
>
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?
>
> randy
>


From Valdis.Kletnieks at vt.edu  Thu Feb 16 16:00:43 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 16 Feb 2012 17:00:43 -0500
Subject: time sink 42
In-Reply-To: Your message of "Thu, 16 Feb 2012 21:45:49 GMT."
 <52A4B7C174F4334C9C6D5BEE83775FD102925A@WIL-EXMBX11.bbtnet.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216213505.GB18506@puck.nether.net>
 <52A4B7C174F4334C9C6D5BEE83775FD102925A@WIL-EXMBX11.bbtnet.com>
Message-ID: <120409.1329429643@turing-police.cc.vt.edu>

On Thu, 16 Feb 2012 21:45:49 GMT, "Dixon, Justin" said:

> Only issue with that approach is that if the colo facility moves your
> hardware at some point you need to ensure that they let you know that so you
> can update your documentation to coincide with (hopefully) their documentation
> of where your equipment is located.

Cloud computing - when you pay a premium for them not to let you know
when they do that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/9d4e74f2/attachment.bin>

From hvb at dsms.com  Thu Feb 16 16:01:57 2012
From: hvb at dsms.com (harold barker)
Date: Thu, 16 Feb 2012 14:01:57 -0800
Subject: time sink 42
In-Reply-To: <4F3D75D7.3010903@opus1.com>
References: <mailman.3982.1329427419.46019.nanog@nanog.org>
 <4F3D75D7.3010903@opus1.com>
Message-ID: <DC49906A-EB3F-42CD-BE9D-875A79B3C071@dsms.com>



Solution: 
http://www.bradyid.com




From kauer at biplane.com.au  Thu Feb 16 16:04:49 2012
From: kauer at biplane.com.au (Karl Auer)
Date: Fri, 17 Feb 2012 09:04:49 +1100
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <1329429889.17490.397.camel@karl>

On Thu, 2012-02-16 at 13:08 -0800, Randy Bush wrote:
> an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker
> [...]
> is there a trick?

Some tapes have a split backing; bend the tape along the long axis and
you can peel off both halves very easily.

If you can't find such tape for your model of label maker, you will need
fingernails and either a very good sense of touch or good eyesight.

Fold one of the corners of the label, just a tiny corner, back towards
the backing paper, then forward. The backing paper will come off that
tiny corner. Use the aforementioned fingernails to get under the label
at that point. It's usually easier to grip the label than the backing
paper, because the label is a little sticky underneath.

Some people say you should fold forward then back. Some people use a
penknife instead of a fingernail.

Another technique, that I've never been able to master: Hold the label,
backing towards you, about a centimetre from the cut end, place the cut
end at right angles against and across the underside of your right
forefinger, pressing very lightly, and drag your finger down. Done
right, the backing peels off and curls down your finger.

Both techniques rely on the label being slightly stiffer than the
backing paper, and thus bending less.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/48dcbfa8/attachment.bin>

From jra at baylink.com  Thu Feb 16 16:06:17 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 16 Feb 2012 17:06:17 -0500 (EST)
Subject: Which P-Touch should I have?
In-Reply-To: <4F3D75D7.3010903@opus1.com>
Message-ID: <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Joel M Snyder" <Joel.Snyder at Opus1.COM>

> Anyone got a solution for *that* particular problem? Should I get a
> better TZ-compatible labeler?

If you're labelling a batch of stuff all at once, you should definitely
get one that runs from your PC; I have a PT-2430PC, and their software is
actually pretty damn skippy, as long as you're running Windows.  It won't 
run in WINE at all, cause it wants to install its own USB driver.  I'll be
trying it in VBox next.

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


From sven at cb3rob.net  Thu Feb 16 16:08:52 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 16 Feb 2012 22:08:52 +0000 (UTC)
Subject: time sink 42
In-Reply-To: <4F3D712F.50304@blakjak.net>
References: <m2aa4ih4f5.wl%randy@psg.com> <4F3D712F.50304@blakjak.net>
Message-ID: <Pine.LNX.4.64.1202162155430.14470@a84-22-97-10.cb3rob.net>

we just use paper labels and markers, much faster & easier.

it's not just the "peeling the back of it", its also the "entering the 
stuff on the tiny keyboard"

and unlike labelprinter stickers, they hold in higher 
temperatures with low humidity and lots of airflow
after a few years ;)

we've found that with most labelwriters, the only thing keeping the labels 
on the hardware after several years in a datacenter environment is the 
vacume between the label and the metal, the glue kinda "disappears" in air 
like that :P

as for servers: well.. the ones with a led display are nice... (hint 
ibm/cisco... crappy dells have them, why don't yours ;)

(would be nice to also see led displays on cisco switches in the future, 
but keep in mind: NOT displaying hostnames/ip addresses!!! has to be a 
seperate config entry!)

(especially since they can be automatically updated during pxe reinstalls 
with the new service-id number ;)

anyway, ditch the labelwriters alltogether, just get sheets with paper 
stickers and write the stuff on them with markers, faster, more efficient, 
lasts longer.

the labelwriter crap just "falls off" after a while, then gets blown away, 
potentially ending up in a ventilator etc.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Mark Foster wrote:

> On 17/02/12 10:08, Randy Bush wrote:
>> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
>> westin playing rack and stack for five hours.  an horrifyingly large
>> amount of my time was spent trying to peel apart labels made on my
>> portable brother label tape maker, yes peeling the backing from a little
>> label so remote hands could easily confirm a server they were going to
>> attack.
>>
>> is there a trick?  is there a (not expensive) different labeling machine
>> or technique i should use?
>>
>> randy
>>
> Many label makers (including Brother) use tapes that have a split up the
> middle of the back layer, so you can peel it off half-at-a-time and not
> fight with finding edges, etc.
>
> Otherwise I suppose it's just a case of finding the knack.  My label
> maker is of the cheaper variety and the tape i've been getting for it
> doesn't have the back-split, so I get to fight with it on the occasion
> that the knack doesn't seem to work...
>
> Mark.
>


From sethm at rollernet.us  Thu Feb 16 16:11:20 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Thu, 16 Feb 2012 14:11:20 -0800
Subject: time sink 42
In-Reply-To: <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>
Message-ID: <4F3D7F08.7040303@rollernet.us>

On 2/16/12 1:25 PM, Keegan Holley wrote:
> If you're building a datacenter probably not.  Other than giving the remote
> hands some identifier and making them label the servers themselves.  If
> you're at a conference you could get away with using masking tape and a
> sharpie.  If you think it was time consuming applying the labels wait until
> you need to remove one.
> 


The flat end of a spudger makes quick work of removing labels for me.

~Seth



From streiner at cluebyfour.org  Thu Feb 16 16:10:56 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 16 Feb 2012 17:10:56 -0500 (EST)
Subject: time sink 42
In-Reply-To: <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
 <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202161708241.11697@whammy.cluebyfour.org>

On Thu, 16 Feb 2012, Bryan Irvine wrote:

> And watch for the removable faceplates.  We've been bitten before
> after a server move by rebooting a server that had the correct label
> but the wrong faceplate.  Now we label the faceplate as well as
> underneath of it too.  :-)

We do the same with cabinets.  Both the doors and the inner frame of the 
cabinet get labeled, since doors can often be removed during rack-and-stack
work.  In the event of a mismatch, the label on the inner frame is generally
the winner :)

jms


From sven at cb3rob.net  Thu Feb 16 16:11:00 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 16 Feb 2012 22:11:00 +0000 (UTC)
Subject: time sink 42
In-Reply-To: <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202162209090.14470@a84-22-97-10.cb3rob.net>

you actually can do that from linux, integrate it into your 
installer/imaging code and you're set ;)

just that dell seems to be the only one who has given this some thought ;)

but hey, you can just buy usb "photoframe" keychains, put the service-id 
number in a jpeg image, store it on there, and keep one in a usb port 
on each server ;)

they're dirt cheap.


On Thu, 16 Feb 2012, Mike Lyon wrote:

> If they are Dell servers, you could always name each host in their BIOS so
> it shows up on the display of the host.
>
> -Mike
>
>
> On Thu, Feb 16, 2012 at 1:15 PM, Leo Bicknell <bicknell at ufp.org> wrote:
>
>> In a message written on Thu, Feb 16, 2012 at 01:08:46PM -0800, Randy Bush
>> wrote:
>>> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
>>> westin playing rack and stack for five hours.  an horrifyingly large
>>> amount of my time was spent trying to peel apart labels made on my
>>> portable brother label tape maker, yes peeling the backing from a little
>>> label so remote hands could easily confirm a server they were going to
>>> attack.
>>
>> The Brother I have that takes "M" tape has the problem you describe,
>> it's nearly impossible to get the backing to separate from the label.
>>
>> I have another Brother that takes "TZ" tape, the backing of the tape of
>> slit down the middle lengthwise.  Gently curling the tape by squeezing
>> it causes the middle to pop open, easy to grab.
>>
>> You can guess which one sits on the shelf, and which one gets used a
>> lot.
>>
>> The TZ tape unit I use is a P-Touch 1100QL, I don't think it's made
>> anymore but there are several similar curent models.
>>
>> --
>>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>>        PGP keys at http://www.ufp.org/~bicknell/
>>
>
>
>
> -- 
> Mike Lyon
> 408-621-4826
> mike.lyon at gmail.com
>
> http://www.linkedin.com/in/mlyon
>


From jra at baylink.com  Thu Feb 16 16:17:11 2012
From: jra at baylink.com (Jay Ashworth)
Date: Thu, 16 Feb 2012 17:17:11 -0500 (EST)
Subject: time sink 42
In-Reply-To: <1329429889.17490.397.camel@karl>
Message-ID: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Karl Auer" <kauer at biplane.com.au>

> If you can't find such tape for your model of label maker, you will need
> fingernails and either a very good sense of touch or good eyesight.
> 
> Fold one of the corners of the label, just a tiny corner, back towards
> the backing paper, then forward. The backing paper will come off that
> tiny corner. Use the aforementioned fingernails to get under the label
> at that point. It's usually easier to grip the label than the backing
> paper, because the label is a little sticky underneath.
> 
> Some people say you should fold forward then back. Some people use a
> penknife instead of a fingernail.

It matters which way you bend, because of the relative stiffness of the
paper and the plastic; you have to bend *towards* the paper, which will stay
folded, away from the plastic.

And I have effectively no fingernails, and that method works well enough for
me.

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


From cmadams at hiwaay.net  Thu Feb 16 16:21:42 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Thu, 16 Feb 2012 16:21:42 -0600
Subject: time sink 42
In-Reply-To: <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
 <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
Message-ID: <20120216222142.GE9953@hiwaay.net>

Once upon a time, Bryan Irvine <sparctacus at gmail.com> said:
> And watch for the removable faceplates.  We've been bitten before
> after a server move by rebooting a server that had the correct label
> but the wrong faceplate.  Now we label the faceplate as well as
> underneath of it too.  :-)

Not just faceplates; we got a couple of racks of used Dell servers and
were rolling through testing them when we discovered a couple where the
Dell tag on the lid didn't match the firmware.  The tag on the back did;
at some point, somebody had switched lids on the cases!
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From nick at foobar.org  Thu Feb 16 16:27:55 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 16 Feb 2012 22:27:55 +0000
Subject: time sink 42
In-Reply-To: <CAK__KzvaTau-Lrq2Kpyxw6LWfAdjL-mhqHdbg+QrZtL43XadhQ@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <CAK__KzvaTau-Lrq2Kpyxw6LWfAdjL-mhqHdbg+QrZtL43XadhQ@mail.gmail.com>
Message-ID: <4F3D82EB.7000505@foobar.org>

On 16/02/2012 21:14, George Herbert wrote:
> Brothers' are fine; buy the tapes that have the split-down-the-middle
> backing on them.
> 
> It reduces the unpeeling problem from
> more-time-than-the-label-took-to-type-in to about 2 seconds.  You just
> grab the edges at an end and bend it, so the backing bulges outwards,
> and off it starts to come.

Well, that's the theory anyway.  The reality is that the split doesn't
quite split, and because the tape is so small, you need a child's fingers
to open it out.  If you're doing all the labelling after a long day's work,
you might have worked up a sweat, in which case your hands will be covered
with salt - and we all know how well labels stick after being pawed at with
a salty fingernail.

Nick


From sven at cb3rob.net  Thu Feb 16 16:27:43 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 16 Feb 2012 22:27:43 +0000 (UTC)
Subject: time sink 42
In-Reply-To: <20120216222142.GE9953@hiwaay.net>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
 <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
 <20120216222142.GE9953@hiwaay.net>
Message-ID: <Pine.LNX.4.64.1202162223310.14470@a84-22-97-10.cb3rob.net>

manufacturers printing the mac address of eth0 and the bmc on the back of 
the case somewhere at the factory would be appreciated too.

preferably with a barcode as well.

the mac addresses is usually nowhere to be found on servers.

the things should just ship with the bmc set to dhcp, a barcode readable 
label with the mac addresses, serial console enabled at 9600n81 with 
portsharing with the bmc SOL, and pxe and wol enabled --

who do these manufacturers think they're selling to anyway, people that 
buy just one unit and have all day to install it or what?

Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Thu, 16 Feb 2012, Chris Adams wrote:

> Once upon a time, Bryan Irvine <sparctacus at gmail.com> said:
>> And watch for the removable faceplates.  We've been bitten before
>> after a server move by rebooting a server that had the correct label
>> but the wrong faceplate.  Now we label the faceplate as well as
>> underneath of it too.  :-)
>
> Not just faceplates; we got a couple of racks of used Dell servers and
> were rolling through testing them when we discovered a couple where the
> Dell tag on the lid didn't match the firmware.  The tag on the back did;
> at some point, somebody had switched lids on the cases!
> -- 
> Chris Adams <cmadams at hiwaay.net>
> Systems and Network Administrator - HiWAAY Internet Services
> I don't speak for anybody but myself - that's enough trouble.
>


From sven at cb3rob.net  Thu Feb 16 16:30:53 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Thu, 16 Feb 2012 22:30:53 +0000 (UTC)
Subject: time sink 42
In-Reply-To: <20120216222142.GE9953@hiwaay.net>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
 <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
 <20120216222142.GE9953@hiwaay.net>
Message-ID: <Pine.LNX.4.64.1202162230260.14470@a84-22-97-10.cb3rob.net>


> Once upon a time, Bryan Irvine <sparctacus at gmail.com> said:
>> And watch for the removable faceplates.

you mean you actually leave those things on there? :P
*grin*


From marka at isc.org  Thu Feb 16 16:40:16 2012
From: marka at isc.org (Mark Andrews)
Date: Fri, 17 Feb 2012 09:40:16 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Fri, 17 Feb 2012 10:23:30 +1300."
 <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <4F3C6703.4050607@gmail.com> <20120216031208.132481D76BD5@drugs.dv.isc.org>
 <20120216134437.GB65401@macbook.bluepipe.net>
 <20120216142836.CEF371D8BA2D@drugs.dv.isc.org>
 <20120216165308.GE65401@macbook.bluepipe.net>
 <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg@mail.gmail.com>
Message-ID: <20120216224016.ACA8A1D8D60E@drugs.dv.isc.org>


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

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

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

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

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

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

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

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

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

%


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


From michael at rancid.berkeley.edu  Thu Feb 16 16:41:56 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Thu, 16 Feb 2012 14:41:56 -0800
Subject: Common operational misconceptions
In-Reply-To: <8A3EC4D2-EFAB-41FD-A1C3-E21C1B2EBD52@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <8A3EC4D2-EFAB-41FD-A1C3-E21C1B2EBD52@delong.com>
Message-ID: <4F3D8634.9090708@rancid.berkeley.edu>

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

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

Concepts/words that often get confused:

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

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

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

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

michael


From george.herbert at gmail.com  Thu Feb 16 16:42:02 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 14:42:02 -0800
Subject: time sink 42
In-Reply-To: <4F3D82EB.7000505@foobar.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <CAK__KzvaTau-Lrq2Kpyxw6LWfAdjL-mhqHdbg+QrZtL43XadhQ@mail.gmail.com>
 <4F3D82EB.7000505@foobar.org>
Message-ID: <CAK__KztnZzSAn96oVaCY8NbyNGCQOEQg8W=ZrKztT-1aBbTz9g@mail.gmail.com>

On Thu, Feb 16, 2012 at 2:27 PM, Nick Hilliard <nick at foobar.org> wrote:
> On 16/02/2012 21:14, George Herbert wrote:
>> Brothers' are fine; buy the tapes that have the split-down-the-middle
>> backing on them.
>>
>> It reduces the unpeeling problem from
>> more-time-than-the-label-took-to-type-in to about 2 seconds. ?You just
>> grab the edges at an end and bend it, so the backing bulges outwards,
>> and off it starts to come.
>
> Well, that's the theory anyway. ?The reality is that the split doesn't
> quite split, and because the tape is so small, you need a child's fingers
> to open it out. ?If you're doing all the labelling after a long day's work,
> you might have worked up a sweat, in which case your hands will be covered
> with salt - and we all know how well labels stick after being pawed at with
> a salty fingernail.

I've done several dozens of reels worth of the split-back (TZ type, I
guess) tape, as well as about an equal amount of the old non-split
tape, in datacenters and network centers going back into the early
1990s.  The worst split tape was at least partly splitting and much
better than the non-split stuff.

Once I had it figured out I could pop it open and start unpeeling
blind, without looking at it.  Even at the end of the day with grime
and dust and salt on my fingernails.

Your mileage may vary, but in my experience it just about always just works.


-- 
-george william herbert
george.herbert at gmail.com


From michael at rancid.berkeley.edu  Thu Feb 16 17:09:08 2012
From: michael at rancid.berkeley.edu (Michael Sinatra)
Date: Thu, 16 Feb 2012 15:09:08 -0800
Subject: time sink 42
In-Reply-To: <20120216222142.GE9953@hiwaay.net>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <20120216211547.GA23755@ussenterprise.ufp.org>
 <CAFFgAjDmTMnwFDa8SrYQk+hYPMBVY4qZR-UguobjjrmroDjvXg@mail.gmail.com>
 <op.v9sjc5y8tfhldh@rbeam.xactional.com>
 <CAG367gZJf5Ef6JOAwCaoOYDC32d=YsbxBiWhwxhu-NMQ5qvPfQ@mail.gmail.com>
 <20120216222142.GE9953@hiwaay.net>
Message-ID: <4F3D8C94.5000102@rancid.berkeley.edu>

On 02/16/12 14:21, Chris Adams wrote:
> Once upon a time, Bryan Irvine<sparctacus at gmail.com>  said:
>> And watch for the removable faceplates.  We've been bitten before
>> after a server move by rebooting a server that had the correct label
>> but the wrong faceplate.  Now we label the faceplate as well as
>> underneath of it too.  :-)
>
> Not just faceplates; we got a couple of racks of used Dell servers and
> were rolling through testing them when we discovered a couple where the
> Dell tag on the lid didn't match the firmware.  The tag on the back did;
> at some point, somebody had switched lids on the cases!

There's where labelers can come in really handy.  A "friend" once told 
me this story:

He and a colleague were working at the PAIX late one night re-routing a 
bunch of fiber jumpers from a switch to new interfaces on some optical 
gear.  The labels on all of the cables were supposed to have the 
switch's model number and interface number and then the optical gear's 
model number and interface.  The colleague went about generating all of 
the labels while my friend cleaned, ran, and installed the jumpers. 
Then they both set about affixing labels to both ends of the jumpers. 
The colleague suddenly stopped and said "we're going to have to re-do 
all of these labels!  Look--I got the model number of the switch wrong."

Indeed, the colleague had added 100 to the model number of the switch, 
and had done so on all of the 2-3 dozen labels.  Not catastrophic, but 
it was late (about 3am) and my friend and the colleague still had a lot 
of work to do.  It was cramped, noisy, and cold where they were working.

"Nonsense," said my friend.  "Give me the labeler."

"What are you going to do?"

"I am going to upgrade the switch."

He set about relabeling the switch's faceplates so that all of the model 
numbers matched the (incorrect) model number on the cable labels. 
Problem solved and only 2-3 labels used, not 2-3 dozen.

Ever hear of a Cisco 6600?  Now you have.

Strangely, my friend and that colleague have never been invited back to 
perform similar "upgrades" for that customer.

michael


From scott at sberkman.net  Thu Feb 16 17:24:18 2012
From: scott at sberkman.net (Scott Berkman)
Date: Thu, 16 Feb 2012 18:24:18 -0500
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <00b301cced02$1b712860$52537920$@sberkman.net>

For the regular Brother labels, my trick is to fold down the corner a
little, that usually makes it easier to peel.  You can also cut the
"whitespace" off the end and that sometimes helps.

Sorry if this was a double post, but I don't think I saw either of these
suggestions in the thread already.  If so make that a +1.

-Scott

-----Original Message-----
From: Randy Bush [mailto:randy at psg.com] 
Sent: Thursday, February 16, 2012 4:09 PM
To: North American Network Operators' Group
Subject: time sink 42

ok, this is horribly pragmatic, but it's real.  yesterday i was in the
westin playing rack and stack for five hours.  an horrifyingly large amount
of my time was spent trying to peel apart labels made on my portable brother
label tape maker, yes peeling the backing from a little label so remote
hands could easily confirm a server they were going to attack.

is there a trick?  is there a (not expensive) different labeling machine or
technique i should use?

randy




From drais at icantclick.org  Thu Feb 16 17:32:40 2012
From: drais at icantclick.org (david raistrick)
Date: Thu, 16 Feb 2012 18:32:40 -0500 (EST)
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <alpine.BSF.2.00.1202161831130.58956@murf.icantclick.org>

On Thu, 16 Feb 2012, Randy Bush wrote:

> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?

the rhino pro labelers and labels have a split on the backer so they peel 
easy.  oh, and they dont come off with heat exposure (some of them are 
even ok after a few years outdoors in florida) like the brother junk does.

I think my megadeluxewithacase model cost about $100 from provantage...

:)



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From owen at delong.com  Thu Feb 16 17:32:13 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 15:32:13 -0800
Subject: Which P-Touch should I have?
In-Reply-To: <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
References: <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
Message-ID: <C63E35C0-8744-420A-B818-AD783A78B0CD@delong.com>

Personally, I prefer the Brady IDExpert.

It's pricier, but, it has much greater flexibility and will produce, among other things, very nice self-laminating labels you can wrap around wires.

Owen

On Feb 16, 2012, at 2:06 PM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Joel M Snyder" <Joel.Snyder at Opus1.COM>
> 
>> Anyone got a solution for *that* particular problem? Should I get a
>> better TZ-compatible labeler?
> 
> If you're labelling a batch of stuff all at once, you should definitely
> get one that runs from your PC; I have a PT-2430PC, and their software is
> actually pretty damn skippy, as long as you're running Windows.  It won't 
> run in WINE at all, cause it wants to install its own USB driver.  I'll be
> trying it in VBox next.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274



From george.herbert at gmail.com  Thu Feb 16 17:38:38 2012
From: george.herbert at gmail.com (George Herbert)
Date: Thu, 16 Feb 2012 15:38:38 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <4F3D6E15.7080006@ucla.edu>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
 <4F3D6E15.7080006@ucla.edu>
Message-ID: <CAK__KztBZJC4Nvfm=yuC=u-R0qL9NAmwW-iTU=1rrrNLyKq_tg@mail.gmail.com>

On Thu, Feb 16, 2012 at 12:59 PM, Jason Chambers <jchambers at ucla.edu> wrote:
> On 2/16/12 5:03 AM, Hank Nussbacher wrote:
>> Nanosecond Trading Could Make Markets Go Haywire
>> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
>>
>> "Below the 950-millisecond level, where computerized trading occurs so
>> quickly that human traders can't even react, no fewer than 18,520
>> crashes and spikes occurred."
>>
>> Anyone who has managed a network knows that when you look at your
>> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.
>> Start looking at 1sec intervals and you will see spikes that hit 100% of
>> capacity - even on networks running at 25% average utilization.
>>
>> I guess trading and networking do have many unseen similarities.
>>
>
> Some complementary information I read a few weeks ago:
>
> http://www.homelandsecuritynewswire.com/critical-cyber-vulnerabilities-found-financial-system
>
> http://www.cpacket.com/latency
>
> http://www.cpacket.com/download/Introduction%20to%20Network%20Latency%20Engineering.pdf
>
> Regards,
>
> --Jason

This all is very familiar to anyone who's looked at ethernet (or other
networks) for real-time control purposes, such as flight control of
aircraft or rockets or for autos or other ground vehicles.

Though the finance people are pushing it a lot more than the rocket
and aircraft control people I know...  I guess markets crash faster
than rockets!


-- 
-george william herbert
george.herbert at gmail.com


From owen at delong.com  Thu Feb 16 17:38:46 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 15:38:46 -0800
Subject: time sink 42
In-Reply-To: <alpine.BSF.2.00.1202161831130.58956@murf.icantclick.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <alpine.BSF.2.00.1202161831130.58956@murf.icantclick.org>
Message-ID: <CC44A858-C082-48A4-BF7E-9E45F99DD372@delong.com>

For standard linear tape labels, making a sharp s-curve bend in the label near one end will often cause the backing to readily separate from the label at that end.

Brother used to include a nifty little tool for doing just that stuck in the bottom of many of their P-Touch labelers. Don't know if they still do or not.

This trick also works on the linear tape labels on the Brady I mentioned in response to JRA's question as well.
For the self-laminating cable labels, the labels don't stretch all the way to the edge of the backing, so, simple bending of the backing and attacking with fingernail works pretty quick and easy.

Owen

On Feb 16, 2012, at 3:32 PM, david raistrick wrote:

> On Thu, 16 Feb 2012, Randy Bush wrote:
> 
>> is there a trick?  is there a (not expensive) different labeling machine
>> or technique i should use?
> 
> the rhino pro labelers and labels have a split on the backer so they peel easy.  oh, and they dont come off with heat exposure (some of them are even ok after a few years outdoors in florida) like the brother junk does.
> 
> I think my megadeluxewithacase model cost about $100 from provantage...
> 
> :)
> 
> 
> 
> --
> david raistrick        http://www.netmeister.org/news/learn2quote.html
> drais at icantclick.org             http://www.expita.com/nomime.html
> 



From jgreco at ns.sol.net  Thu Feb 16 18:06:55 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Thu, 16 Feb 2012 18:06:55 -0600 (CST)
Subject: time sink 42
In-Reply-To: <m2aa4ih4f5.wl%randy@psg.com>
Message-ID: <201202170006.q1H06tFK046467@aurora.sol.net>

> ok, this is horribly pragmatic, but it's real.  yesterday i was in the
> westin playing rack and stack for five hours.  an horrifyingly large
> amount of my time was spent trying to peel apart labels made on my
> portable brother label tape maker, yes peeling the backing from a little
> label so remote hands could easily confirm a server they were going to
> attack.
> 
> is there a trick?  is there a (not expensive) different labeling machine
> or technique i should use?

I hate all the newer Brother labelmakers I've seen - pretty much for this
very reason.  I've never found a good method for quickly and reliably
removing the backings for them.

We have a bunch of older Brother PT-20's that use the TC-20 tape.  This
is a generally awesome but a little limited labelmaker.  It's a bit big,
but it does offer a nicer keyboard than most current devices.  The three
maybe-gotchas all involve the tape being a multipart tape:  you have a
sticky backing on which the lettering is printed, which is then covered
with a very resilient plastic laminate covering, all pressed together/
assembled inside the tape cartridge as part of the printing process.

1) Sometimes, when removing the labels, the plastic laminate cover will
   delaminate from the sticky tape - leaving a peeling-it-off nightmare.
   In all fairness, the types of surface that this happens on typically
   cause Brother TZ-style labels to shred too.  I have never fully
   identified the types of surfaces involved, but some plastics seem to
   be the biggest trouble.

2) Occasionally, with age, we've seen short sections (~.5cm) delaminate
   and leave a little "loop" or "bubble" in the middle of a label. 
   Usually in hot/humid environments.

3) Due to the lamination technique, the label is very springy and cannot
   be used for cable markings.

Other than these occasional issues, we have been exceedingly pleased with
the PT-20's for many years, perhaps as many as 20 years now.  They're
great for marking all sorts of things, from file folders to electronic
gear.

I would avoid the newer Brother units I've seen in favor of some of the
other units people have mentioned, but for inexpensive basic server
marking, I still really like the PT-20's.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From kauer at biplane.com.au  Thu Feb 16 18:14:41 2012
From: kauer at biplane.com.au (Karl Auer)
Date: Fri, 17 Feb 2012 11:14:41 +1100
Subject: time sink 42
In-Reply-To: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>
References: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>
Message-ID: <1329437681.17490.414.camel@karl>

On Thu, 2012-02-16 at 17:17 -0500, Jay Ashworth wrote:
> > Fold one of the corners of the label, just a tiny corner, back towards
> > the backing paper, then forward.

> It matters which way you bend, because of the relative stiffness of
> the paper and the plastic; you have to bend *towards* the paper, which
> will stay folded, away from the plastic.

What?!? Forward instead of backward? KILL THE UNBELIEVER! KILL! KILL!

The alternative approach, to which ALL right-thinking persons subscribe,
is to avoid, as much as possible, folding the label. Because, indeed and
as you say, it will remain folded. If the label does have to be bent, it
should be left bent down, not up. Bending it towards the backing may
work on it's own, subjecting the backing paper to the more acute
deformation, and the label may even thereafter return to the flat
position uncreased, leaving the backing paper separated. The more
destructive bend upwards may also leave a corner of the label bent up
and away from the surface the label will be on.

The Covenant of the Holy Order of Downfolders meets weekly behind the
fourth server rack from the left, lower basement. Batteries not
supplied. Bring your own torch, pitchfork, etc.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/356c6455/attachment.bin>

From nathan at atlasnetworks.us  Thu Feb 16 18:17:54 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 17 Feb 2012 00:17:54 +0000
Subject: time sink 42
In-Reply-To: <201202170006.q1H06tFK046467@aurora.sol.net>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <201202170006.q1H06tFK046467@aurora.sol.net>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B7E20@ex-mb-2.corp.atlasnetworks.us>

> I hate all the newer Brother labelmakers I've seen - pretty much for
> this
> very reason.  I've never found a good method for quickly and reliably
> removing the backings for them.

The one thing I absolutely cannot stand about all the low-end brothers is the amount of waste they generate.  When printing single labels, they spit out a useless 3/4 inch tab that you have to hit the 'cut' lever for.  This tab is the tape that was wasted pushing out the last label.  I would estimate this consumes about 20% of the tape on these printers - perhaps less if you chain print or have longer labels.  The PT-1830 and PT-1880 are good examples of this insanity.


From jjones at danrj.com  Thu Feb 16 18:28:46 2012
From: jjones at danrj.com (Jerry Jones)
Date: Thu, 16 Feb 2012 18:28:46 -0600
Subject: time sink 42
In-Reply-To: <1329437681.17490.414.camel@karl>
References: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>
 <1329437681.17490.414.camel@karl>
Message-ID: <9E4C2B84-0110-411E-9866-37BE21145A66@danrj.com>

I have been scoring paper back VERY lightly near one end with razor knife, then peeling off.


On Feb 16, 2012, at 6:14 PM, Karl Auer wrote:

On Thu, 2012-02-16 at 17:17 -0500, Jay Ashworth wrote:
>> Fold one of the corners of the label, just a tiny corner, back towards
>> the backing paper, then forward.

> It matters which way you bend, because of the relative stiffness of
> the paper and the plastic; you have to bend *towards* the paper, which
> will stay folded, away from the plastic.

What?!? Forward instead of backward? KILL THE UNBELIEVER! KILL! KILL!

The alternative approach, to which ALL right-thinking persons subscribe,
is to avoid, as much as possible, folding the label. Because, indeed and
as you say, it will remain folded. If the label does have to be bent, it
should be left bent down, not up. Bending it towards the backing may
work on it's own, subjecting the backing paper to the more acute
deformation, and the label may even thereafter return to the flat
position uncreased, leaving the backing paper separated. The more
destructive bend upwards may also leave a corner of the label bent up
and away from the surface the label will be on.

The Covenant of the Holy Order of Downfolders meets weekly behind the
fourth server rack from the left, lower basement. Batteries not
supplied. Bring your own torch, pitchfork, etc.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687



From steve.bertrand at gmail.com  Thu Feb 16 18:41:42 2012
From: steve.bertrand at gmail.com (Steve Bertrand)
Date: Thu, 16 Feb 2012 19:41:42 -0500
Subject: Canadian ops working under a U.S. TN visa
Message-ID: <4F3DA246.7090109@gmail.com>

I am in the last-moment phase of moving from Canada to the U.S. for a 
one-year contract. Tomorrow I will be crossing at the Peace Bridge at 
Niagara to apply for my TN visa.

Could anyone here who may have gone through this process contact me 
off-list to answer a few simple questions?

Thank you,

Steve


From bill at herrin.us  Thu Feb 16 18:45:29 2012
From: bill at herrin.us (William Herrin)
Date: Thu, 16 Feb 2012 19:45:29 -0500
Subject: Which P-Touch should I have?
In-Reply-To: <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>

On Thu, Feb 16, 2012 at 5:06 PM, Jay Ashworth <jra at baylink.com> wrote:
>> From: "Joel M Snyder" <Joel.Snyder at Opus1.COM>
>> Anyone got a solution for *that* particular problem? Should I get a
>> better TZ-compatible labeler?
>
> If you're labelling a batch of stuff all at once, you should definitely
> get one that runs from your PC; I have a PT-2430PC, and their software is
> actually pretty damn skippy, as long as you're running Windows. ?It won't
> run in WINE at all, cause it wants to install its own USB driver. ?I'll be
> trying it in VBox next.

The PT-2100 was the best of both worlds. Regular labeler AND a USB
port to drive it from a PC.  Current model is PT-2730 I think.

http://www.brother-usa.com/Ptouch/Ptouch_DualOperation/


On Thu, Feb 16, 2012 at 6:32 PM, Owen DeLong <owen at delong.com> wrote:
> Personally, I prefer the Brady IDExpert.
>
> It's pricier, but, it has much greater flexibility and will
> produce, among other things, very nice self-laminating
> labels you can wrap around wires.

For cable labeling I've had good results with 3M Scotch Super88 color
electrical tape. Pick unique color bands for each cable. Band it
identically at both ends. You don't have to squint to see how it's
labeled. And the label isn't invalidated merely because you unplugged
it from one place and plugged it in somewhere else.

For longer distances, label the patch panel.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From sven at cb3rob.net  Thu Feb 16 18:52:41 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 00:52:41 +0000 (UTC)
Subject: time sink 42
In-Reply-To: <9E4C2B84-0110-411E-9866-37BE21145A66@danrj.com>
References: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>
 <1329437681.17490.414.camel@karl>
 <9E4C2B84-0110-411E-9866-37BE21145A66@danrj.com>
Message-ID: <Pine.LNX.4.64.1202170051350.14470@a84-22-97-10.cb3rob.net>


On Thu, 16 Feb 2012, Jerry Jones wrote:

> I have been scoring paper back VERY lightly near one end with razor knife, then peeling off.

sounds like something that increases the time it takes to make and put one 
single label on by 500%


From joelja at bogus.com  Thu Feb 16 18:53:20 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Thu, 16 Feb 2012 16:53:20 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <4F3DA500.3030702@bogus.com>

On 2/16/12 05:03 , Hank Nussbacher wrote:
> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
> 
> "Below the 950-millisecond level, where computerized trading occurs so
> quickly that human traders can't even react, no fewer than 18,520
> crashes and spikes occurred."
> 
> Anyone who has managed a network knows that when you look at your
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well. 
> Start looking at 1sec intervals and you will see spikes that hit 100% of
> capacity - even on networks running at 25% average utilization.

given a serialized interface the network is 100% utilized everytime a
packet is sent, if you're measuring at the microsecond level it's far
more germain what the queue depth is rather than whether a packet is
currently on the wire or not. A 5 minute 1 minute or 1 second average is
a pretty good measure of how much of the time it wasn't being utilitized
during the same interval.

The fm4000 based Aristas have hardware hooks to stream the latency data
in the form of queue thresholds at you via LANZ, that can take your
visibility down to 800 or so usec snapshot of the queue. The broadcom
devices doesn't have a comparable functionality.

> I guess trading and networking do have many unseen similarities.

I'd be careful about analogizing them to much. high speeding trading
strategies to a very large extent depend on the high speed parties being
about to make more granular decisions faster that other participants can
complete transactions, forwarding engines are mostly looking to get rid
of packets as expeditiously as possible.

> -Hank
> 
> 



From paul at paulgraydon.co.uk  Thu Feb 16 19:08:31 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Thu, 16 Feb 2012 15:08:31 -1000
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
References: <5.1.0.14.2.20120216150028.00c2df78@efes.iucc.ac.il>
Message-ID: <4F3DA88F.1040700@paulgraydon.co.uk>

On 2/16/2012 3:03 AM, Hank Nussbacher wrote:
> Nanosecond Trading Could Make Markets Go Haywire
> http://www.wired.com/wiredscience/2012/02/high-speed-trading/
>
> "Below the 950-millisecond level, where computerized trading occurs so 
> quickly that human traders can't even react, no fewer than 18,520 
> crashes and spikes occurred."
>
> Anyone who has managed a network knows that when you look at your 
> MRTG/Cacti graphs at 5min, 10min ,15min intervals - all looks well.  
> Start looking at 1sec intervals and you will see spikes that hit 100% 
> of capacity - even on networks running at 25% average utilization.
>
> I guess trading and networking do have many unseen similarities.
>
> -Hank
>
Anecdotally, I had an interview years ago for a small-ish futures 
trading company based in London.  The interviewer had to pause the 
interview part way through whilst he investigated a 10ms latency spike 
that the traders were noticing on a short point-to-point fiber link to 
the London Stock Exchange.  He commented that the traders were far 
better at 'feeling' when an connection was showing even a trace of lag 
compared to normal than anything he'd set up by way of monitoring (not 
sure how good his monitoring was, though.)

Paul



From mohta at necom830.hpcl.titech.ac.jp  Thu Feb 16 19:11:22 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 10:11:22 +0900
Subject: Common operational misconceptions
In-Reply-To: <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
Message-ID: <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>

Andreas Echavez wrote:

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

That PMTUD works is a misconception.

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

That's another misconception.

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

					Masataka Ohta


From josh.hoppes at gmail.com  Thu Feb 16 19:16:36 2012
From: josh.hoppes at gmail.com (Josh Hoppes)
Date: Thu, 16 Feb 2012 19:16:36 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
Message-ID: <CAMcDho=b8uWv2OGBg7qRwKGjwbEhe1_2VCLqaW+s-8wijUo=rw@mail.gmail.com>

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

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


From joe at nethead.com  Thu Feb 16 19:18:21 2012
From: joe at nethead.com (Joe Hamelin)
Date: Thu, 16 Feb 2012 17:18:21 -0800
Subject: Which P-Touch should I have?
In-Reply-To: <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
Message-ID: <CAO0-hXb3aaBDLv3ojNVVaxky1vo1wdtXySxTOEACPdHA4pGKBw@mail.gmail.com>

> Anyone got a solution for *that* particular problem? Should I get a
> better TZ-compatible labeler?

Brother PT-1400 P-Touch Handheld Labeler ($90ish) is nice in that it will
do three lines and also do "flags" (double print) to tag wires with.
 Batteries last a good while, and fits in the hand nicely.  Good for field
work and fairly rugged.  Main downside is lack of a qwerty keypad.  If you
don't have to label a whole data center and just need to pump out a dozen
or two a day, it does the job well and won't kill the budget.  Fits nice in
the tool bag too.

http://www.amazon.com/Brother-PT-1400-P-Touch-Handheld-Labeler/dp/B00011KHPG/ref=sr_1_22?ie=UTF8&qid=1329441056&sr=8-22


--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From mohta at necom830.hpcl.titech.ac.jp  Thu Feb 16 19:37:08 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 10:37:08 +0900
Subject: Common operational misconceptions
In-Reply-To: <CAMcDho=b8uWv2OGBg7qRwKGjwbEhe1_2VCLqaW+s-8wijUo=rw@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <CAMcDho=b8uWv2OGBg7qRwKGjwbEhe1_2VCLqaW+s-8wijUo=rw@mail.gmail.com>
Message-ID: <4F3DAF44.2040408@necom830.hpcl.titech.ac.jp>

Josh Hoppes wrote:

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

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

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

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

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

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

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

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

						Masataka Ohta


From Valdis.Kletnieks at vt.edu  Thu Feb 16 19:40:24 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 16 Feb 2012 20:40:24 -0500
Subject: Canadian ops working under a U.S. TN visa
In-Reply-To: Your message of "Thu, 16 Feb 2012 19:41:42 EST."
 <4F3DA246.7090109@gmail.com>
References: <4F3DA246.7090109@gmail.com>
Message-ID: <130307.1329442824@turing-police.cc.vt.edu>

On Thu, 16 Feb 2012 19:41:42 EST, Steve Bertrand said:
> I am in the last-moment phase of moving from Canada to the U.S. for a
> one-year contract. Tomorrow I will be crossing at the Peace Bridge at
> Niagara to apply for my TN visa.

And here I thought it was just West Virginia and Alabama that required their
own separate visas for furriners. ;)

(Sorry, couldn't resist. ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/71356506/attachment-0001.bin>

From Valdis.Kletnieks at vt.edu  Thu Feb 16 19:43:31 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 16 Feb 2012 20:43:31 -0500
Subject: Common operational misconceptions
In-Reply-To: Your message of "Fri, 17 Feb 2012 10:11:22 +0900."
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
Message-ID: <130462.1329443011@turing-police.cc.vt.edu>

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

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

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

Let me know how that works out for you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/947739c5/attachment.bin>

From johnl at iecc.com  Thu Feb 16 19:58:05 2012
From: johnl at iecc.com (John Levine)
Date: 17 Feb 2012 01:58:05 -0000
Subject: Canadian ops working under a U.S. TN visa
In-Reply-To: <130307.1329442824@turing-police.cc.vt.edu>
Message-ID: <20120217015805.33587.qmail@joyce.lan>

>> I am in the last-moment phase of moving from Canada to the U.S. for a
>> one-year contract. Tomorrow I will be crossing at the Peace Bridge at
>> Niagara to apply for my TN visa.
>
>And here I thought it was just West Virginia and Alabama that required their
>own separate visas for furriners. ;)

Watch out or I'll tell you about the time I was busted at the Rainbow Bridge for
undeclared photo albums.

R's,
John


From aledm at qix.co.uk  Thu Feb 16 19:58:38 2012
From: aledm at qix.co.uk (Aled Morris)
Date: Fri, 17 Feb 2012 01:58:38 +0000
Subject: time sink 42
In-Reply-To: <Pine.LNX.4.64.1202170051350.14470@a84-22-97-10.cb3rob.net>
References: <26514555.3163.1329430631662.JavaMail.root@benjamin.baylink.com>
 <1329437681.17490.414.camel@karl>
 <9E4C2B84-0110-411E-9866-37BE21145A66@danrj.com>
 <Pine.LNX.4.64.1202170051350.14470@a84-22-97-10.cb3rob.net>
Message-ID: <CAO1bj=aw9MQKHGPL0QFGisnc0w78L30vNh2J0kBSa06J6oDp=w@mail.gmail.com>

On 17 February 2012 00:52, Sven Olaf Kamphuis <sven at cb3rob.net> wrote:

>
> On Thu, 16 Feb 2012, Jerry Jones wrote:
>
>  I have been scoring paper back VERY lightly near one end with razor
>> knife, then peeling off.
>>
>
> sounds like something that increases the time it takes to make and put one
> single label on by 500%
>
>
Not to mention the band-aid you'll need too.

Aled

From MGauvin at dryden.ca  Thu Feb 16 20:00:19 2012
From: MGauvin at dryden.ca (Mark Gauvin)
Date: Thu, 16 Feb 2012 20:00:19 -0600
Subject: Canadian ops working under a U.S. TN visa
In-Reply-To: <20120217015805.33587.qmail@joyce.lan>
References: <20120217015805.33587.qmail@joyce.lan>
Message-ID: <B389B120-520D-41C0-9157-CF6C0B440362@dryden.ca>

Had 4 HD,s held for a week

Sent from my iPhone

On 2012-02-16, at 7:59 PM, "John Levine" <johnl at iecc.com> wrote:

>>> I am in the last-moment phase of moving from Canada to the U.S.  
>>> for a
>>> one-year contract. Tomorrow I will be crossing at the Peace Bridge  
>>> at
>>> Niagara to apply for my TN visa.
>>
>> And here I thought it was just West Virginia and Alabama that  
>> required their
>> own separate visas for furriners. ;)
>
> Watch out or I'll tell you about the time I was busted at the  
> Rainbow Bridge for
> undeclared photo albums.
>
> R's,
> John
>


From mohta at necom830.hpcl.titech.ac.jp  Thu Feb 16 20:07:59 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 11:07:59 +0900
Subject: Common operational misconceptions
In-Reply-To: <130462.1329443011@turing-police.cc.vt.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <130462.1329443011@turing-police.cc.vt.edu>
Message-ID: <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

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

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

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

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

					Masataka Ohta


From rms2176 at columbia.edu  Thu Feb 16 20:35:03 2012
From: rms2176 at columbia.edu (Ridwan Sami)
Date: Thu, 16 Feb 2012 21:35:03 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
Message-ID: <20120216213503.dv4tk6ot8g0k0c8w@cubmail.cc.columbia.edu>

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

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

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

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

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

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

Authentication by client IP address alone is sufficient.

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

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

+1 for "NAT is security".

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


From owen at delong.com  Thu Feb 16 22:41:59 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 20:41:59 -0800
Subject: Which P-Touch should I have?
In-Reply-To: <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
Message-ID: <875B29FA-0705-4276-B3F1-5A942552DC50@delong.com>

> 
> For cable labeling I've had good results with 3M Scotch Super88 color
> electrical tape. Pick unique color bands for each cable. Band it
> identically at both ends. You don't have to squint to see how it's
> labeled. And the label isn't invalidated merely because you unplugged
> it from one place and plugged it in somewhere else.
> 

I usually use labels printed on all sides in about a 14 point font that have a unique number followed by a - and a length. So, for example, 10294-4.5 is a 4.5' long cable number 10294.

You might need to squint a bit to read it, but, 14 points is usually pretty legible and being printed 4 times on the label (3 of which remain visible on the average cat5/cat6 cable) means you usually don't have to futz with twirling the cable to find the label.

I usually have the labels installed ~2" from the plug at each end.

In a crowded deployment, I think the color bands would be like trying to read resistor color codes in a box of ~1,000 mixed resistors. You're going to end up squinting anyway.  With my tactic, you have the additional advantage that you get a defined search radius within which the other end can be located.

Using serial-number labels instead of equipment-specific labels means that mine aren't invalidated either.

Owen



From owen at delong.com  Thu Feb 16 22:48:04 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 20:48:04 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
Message-ID: <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>


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

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

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

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

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

Owen



From Valdis.Kletnieks at vt.edu  Thu Feb 16 22:58:44 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Thu, 16 Feb 2012 23:58:44 -0500
Subject: Common operational misconceptions
In-Reply-To: Your message of "Fri, 17 Feb 2012 11:07:59 +0900."
 <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <130462.1329443011@turing-police.cc.vt.edu>
 <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>
Message-ID: <138266.1329454724@turing-police.cc.vt.edu>

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

No, you said specifcially that it can be restored by end system*S*
plural.  Yes, I can get one box listening.  Now tell me how to get
the second and third boxes listening on the same port.  If you can't
do that, then in fact, it is *not* possible to restore *full* end-to-end
connectivity.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120216/cc5d43ce/attachment.bin>

From mansaxel at besserwisser.org  Thu Feb 16 23:10:00 2012
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Fri, 17 Feb 2012 06:10:00 +0100
Subject: time sink 42
In-Reply-To: <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>
Message-ID: <20120217050959.GA12546@besserwisser.org>

Subject: Re: time sink 42 Date: Thu, Feb 16, 2012 at 04:25:15PM -0500 Quoting Keegan Holley (keegan.holley at sungard.com):
> If you're building a datacenter probably not.  Other than giving the remote
> hands some identifier and making them label the servers themselves.  If
> you're at a conference you could get away with using masking tape and a
> sharpie.  

The Sharpie(tm) gets my full approval. 

The masking tape not. 

For conferences, Permacel 724 is the ultimate tape, as seen on major rock tours. 
	http://www.goodbuyguys.com/catalog/index.php/cPath/22_52_83

For more permanent marking, without going to label printing (for
which I think Brady is the best) I like tesa brand cloth tape from
Beiersdorf. 4541 is my favourite model.
	http://www.tesatape.com/industry/products/tesa_4541.html

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
hubub, hubub, HUBUB, hubub, hubub, hubub, HUBUB, hubub, hubub, hubub.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/5c2e28f0/attachment-0001.bin>

From chipps at chipps.com  Thu Feb 16 23:20:37 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Thu, 16 Feb 2012 23:20:37 -0600
Subject: Which P-Touch should I have?
In-Reply-To: <875B29FA-0705-4276-B3F1-5A942552DC50@delong.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
 <875B29FA-0705-4276-B3F1-5A942552DC50@delong.com>
Message-ID: <023b01cced33$e20e8860$a62b9920$@chipps.com>

I don't suppose anyone follows the TIA-606-B Administration Standard for the
Telecommunications Infrastructure of Commercial Buildings when labeling
things like cables.

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Thursday, February 16, 2012 10:42 PM
To: William Herrin
Cc: NANOG
Subject: Re: Which P-Touch should I have?

> 
> For cable labeling I've had good results with 3M Scotch Super88 color 
> electrical tape. Pick unique color bands for each cable. Band it 
> identically at both ends. You don't have to squint to see how it's 
> labeled. And the label isn't invalidated merely because you unplugged 
> it from one place and plugged it in somewhere else.
> 

I usually use labels printed on all sides in about a 14 point font that have
a unique number followed by a - and a length. So, for example, 10294-4.5 is
a 4.5' long cable number 10294.

You might need to squint a bit to read it, but, 14 points is usually pretty
legible and being printed 4 times on the label (3 of which remain visible on
the average cat5/cat6 cable) means you usually don't have to futz with
twirling the cable to find the label.

I usually have the labels installed ~2" from the plug at each end.

In a crowded deployment, I think the color bands would be like trying to
read resistor color codes in a box of ~1,000 mixed resistors. You're going
to end up squinting anyway.  With my tactic, you have the additional
advantage that you get a defined search radius within which the other end
can be located.

Using serial-number labels instead of equipment-specific labels means that
mine aren't invalidated either.

Owen






From dougb at dougbarton.us  Thu Feb 16 23:27:26 2012
From: dougb at dougbarton.us (Doug Barton)
Date: Thu, 16 Feb 2012 21:27:26 -0800
Subject: time sink 42
In-Reply-To: <20120217050959.GA12546@besserwisser.org>
References: <m2aa4ih4f5.wl%randy@psg.com>
 <CABO8Q6TtVERJz+dg12EAX_rKRJNdZO0t-07L0wT_8x+Y0vFGKA@mail.gmail.com>
 <20120217050959.GA12546@besserwisser.org>
Message-ID: <4F3DE53E.2050502@dougbarton.us>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/16/2012 21:10, M?ns Nilsson wrote:
> The Sharpie(tm) gets my full approval.
> 
> The masking tape not.
> 
> For conferences, Permacel 724 is the ultimate tape

For less fancy/lower budget alternatives the blue "painter's masking
tape" is a better choice.


- -- 

	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/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)

iQEcBAEBCAAGBQJPPeU+AAoJEFzGhvEaGryEly4IAKEmNpmDqAzFKPpVm7VpnT4r
5yGGNpBfBXOD960KXJ3ZrkA1/CvDx6u6VF3GrtzBaWMD34BqJsO6372xD1YEeoUD
1XWF+Ju3huEIMBKSttBNjEJopbW5yy1a6l0+Csv++8J5jb+8NqQV+YSnwp+5kcb9
r6gHykCZFo75raMl++UYdOtCE15ygABkZby++ch2xQcWJez/BVhFuApATENgsrmp
Yz2JuHDr+OA8eyyXUQOlWwMfoVqJeBm2Tt4AIky8HiuktLjOKnynoJ0PpnmJ3Oym
r6doLUnomw4fbQZszLRjxP+AvnjHcP6/7GTHlXlhD9yMHbhbw9XgnmvT/3U1zLo=
=qwAs
-----END PGP SIGNATURE-----


From joe at nethead.com  Thu Feb 16 23:33:35 2012
From: joe at nethead.com (Joe Hamelin)
Date: Thu, 16 Feb 2012 21:33:35 -0800
Subject: Which P-Touch should I have?
In-Reply-To: <023b01cced33$e20e8860$a62b9920$@chipps.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
 <875B29FA-0705-4276-B3F1-5A942552DC50@delong.com>
 <023b01cced33$e20e8860$a62b9920$@chipps.com>
Message-ID: <CAO0-hXYauVvLv9qvCK9mDqm86JnqNa8y4CCoPFvJNbpLmgy4Yg@mail.gmail.com>

Give me a link to the labeling section and I'll let you know if I've seen
it in the wild.  I'm out in the field now (got sick of the desk) and see a
lot of commercial/retail plants.

I doubt that it's going on in retail, except maybe Lowe's Hardware.  They
do love MM fiber and just did a nation-wide network upgrade to gigabit
everywhere in the stores.  But then again, the label specs were kinda hit
and miss.

Sadly I've seen no IPv6 in any retail shops.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474


On Thu, Feb 16, 2012 at 9:20 PM, Kenneth M. Chipps Ph.D.
<chipps at chipps.com>wrote:

> I don't suppose anyone follows the TIA-606-B Administration Standard for
> the
> Telecommunications Infrastructure of Commercial Buildings when labeling
> things like cables.
>
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com]
> Sent: Thursday, February 16, 2012 10:42 PM
> To: William Herrin
> Cc: NANOG
> Subject: Re: Which P-Touch should I have?
>
> >
> > For cable labeling I've had good results with 3M Scotch Super88 color
> > electrical tape. Pick unique color bands for each cable. Band it
> > identically at both ends. You don't have to squint to see how it's
> > labeled. And the label isn't invalidated merely because you unplugged
> > it from one place and plugged it in somewhere else.
> >
>
> I usually use labels printed on all sides in about a 14 point font that
> have
> a unique number followed by a - and a length. So, for example, 10294-4.5 is
> a 4.5' long cable number 10294.
>
> You might need to squint a bit to read it, but, 14 points is usually pretty
> legible and being printed 4 times on the label (3 of which remain visible
> on
> the average cat5/cat6 cable) means you usually don't have to futz with
> twirling the cable to find the label.
>
> I usually have the labels installed ~2" from the plug at each end.
>
> In a crowded deployment, I think the color bands would be like trying to
> read resistor color codes in a box of ~1,000 mixed resistors. You're going
> to end up squinting anyway.  With my tactic, you have the additional
> advantage that you get a defined search radius within which the other end
> can be located.
>
> Using serial-number labels instead of equipment-specific labels means that
> mine aren't invalidated either.
>
> Owen
>
>
>
>
>
>

From gbonser at seven.com  Thu Feb 16 23:42:36 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 05:42:36 +0000
Subject: Common operational misconceptions
In-Reply-To: <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>

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

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

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






From surfer at mauigateway.com  Thu Feb 16 23:55:54 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 16 Feb 2012 21:55:54 -0800
Subject: OT: Re: Canadian ops working under a U.S. TN visa
Message-ID: <20120216215554.54D22E6B@m0005309.ppops.net>



--- johnl at iecc.com wrote:
Watch out or I'll tell you about the time I was busted at the Rainbow Bridge for
undeclared photo albums.
----------------------------


Rainbow Bridge as in 1970s Maui?  Got photos?

https://en.wikipedia.org/wiki/Rainbow_Bridge_(film)


Like others, I couldn't resist...  :-)
scott



A modest audience of a few hundred island hippies, surfers, and students turned
up following announcements that Hendrix would play a free concert for a film. 


From johnl at iecc.com  Fri Feb 17 00:20:59 2012
From: johnl at iecc.com (John Levine)
Date: 17 Feb 2012 06:20:59 -0000
Subject: OT: Re: Canadian ops working under a U.S. TN visa
In-Reply-To: <20120216215554.54D22E6B@m0005309.ppops.net>
Message-ID: <20120217062059.43374.qmail@joyce.lan>

In article <20120216215554.54D22E6B at m0005309.ppops.net> you write:
>Watch out or I'll tell you about the time I was busted at the Rainbow Bridge for
>undeclared photo albums.

Actually I lied, it was the Whirlpool bridge, an underappreciated
engineering marvel.  Trains on the upper level, cars on the lower
level, originally built by Roebling as a suspension bridge in 1855,
the first successful rail suspension bridge in the world.  In 1896-7
they built the current steel arch bridge underneath the existing
decks, then took down the towers and cables, keeping the bridge open
the whole time.  The ironwork is quite elaborate, too bad there's no
longer pedestrian access to look at it.

The Rainbow Bridge, about a mile upstream, has a better view but is
much less interesting.


R's,
John


From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 17 00:24:42 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 15:24:42 +0900
Subject: Common operational misconceptions
In-Reply-To: <138266.1329454724@turing-police.cc.vt.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <130462.1329443011@turing-police.cc.vt.edu>
 <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>
 <138266.1329454724@turing-police.cc.vt.edu>
Message-ID: <4F3DF2AA.4040308@necom830.hpcl.titech.ac.jp>

Valdis.Kletnieks at vt.edu wrote:

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

Yes, end to end connectivity is restored.

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

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

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

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

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

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

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

						Masataka Ohta


From cabo at tzi.org  Fri Feb 17 00:30:30 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Fri, 17 Feb 2012 07:30:30 +0100
Subject: Common operational misconceptions
In-Reply-To: <4F3D3806.4000008@brightok.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
Message-ID: <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>

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

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

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

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

Gr??e, Carsten



From cabo at tzi.org  Fri Feb 17 00:39:00 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Fri, 17 Feb 2012 07:39:00 +0100
Subject: Common operational misconceptions
In-Reply-To: <4F3D8634.9090708@rancid.berkeley.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <8A3EC4D2-EFAB-41FD-A1C3-E21C1B2EBD52@delong.com>
 <4F3D8634.9090708@rancid.berkeley.edu>
Message-ID: <EF4FB8BE-151A-407C-BD68-4D56FC739B8B@tzi.org>

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

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

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

Gr??e, Carsten



From owen at delong.com  Fri Feb 17 00:41:43 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 16 Feb 2012 22:41:43 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3DF2AA.4040308@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <130462.1329443011@turing-police.cc.vt.edu>
 <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>
 <138266.1329454724@turing-police.cc.vt.edu>
 <4F3DF2AA.4040308@necom830.hpcl.titech.ac.jp>
Message-ID: <F889C600-7AEE-47A3-8C63-012B3DA90968@delong.com>

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

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

Owen

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

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



From paul at paulgraydon.co.uk  Fri Feb 17 00:50:11 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Thu, 16 Feb 2012 20:50:11 -1000
Subject: Common operational misconceptions
In-Reply-To: <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
Message-ID: <4F3DF8A3.8040708@paulgraydon.co.uk>

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

Paul


From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 17 00:54:33 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 15:54:33 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
Message-ID: <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

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

It depends on how you define "work well".

As the RFC says:

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

it can not react against PMTU changes very well.

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

						Masataka Ohta


From mohta at necom830.hpcl.titech.ac.jp  Fri Feb 17 01:03:32 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Fri, 17 Feb 2012 16:03:32 +0900
Subject: Common operational misconceptions
In-Reply-To: <F889C600-7AEE-47A3-8C63-012B3DA90968@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <130462.1329443011@turing-police.cc.vt.edu>
 <4F3DB67F.2050700@necom830.hpcl.titech.ac.jp>
 <138266.1329454724@turing-police.cc.vt.edu>
 <4F3DF2AA.4040308@necom830.hpcl.titech.ac.jp>
 <F889C600-7AEE-47A3-8C63-012B3DA90968@delong.com>
Message-ID: <4F3DFBC4.9020003@necom830.hpcl.titech.ac.jp>

Owen DeLong wrote:

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

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

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

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

   Abstract

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

							Masataka Ohta



From cabo at tzi.org  Fri Feb 17 01:05:02 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Fri, 17 Feb 2012 08:05:02 +0100
Subject: Common operational misconceptions
In-Reply-To: <4F3DF8A3.8040708@paulgraydon.co.uk>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
Message-ID: <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>

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

> what OSI means

Yet another common misconception popping up:

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

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

Gr??e, Carsten



From jsw at inconcepts.biz  Fri Feb 17 01:29:36 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Fri, 17 Feb 2012 02:29:36 -0500
Subject: common time-management mistake: rack & stack
Message-ID: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>

Randy's P-Touch thread brings up an issue I think is worth some
discussion.  I have noticed that a lot of very well-paid, sometimes
well-qualified, networking folks spend some of their time on "rack &
stack" tasks, which I feel is a very unwise use of time and talent.

Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
Flying a sharp router jockey around to far-flung POPs to install gear
is just as foolish.

Not only does the router jockey cost a lot more to employ than a CCNA,
but if your senior-level talent is wasting time in airports and IBXes,
that is time they can't be doing things CCNAs can't.

I was once advising a client on a transit purchasing decision, and a
fairly-large, now-defunct tier-2 ISP was being considered.  We needed
a few questions about their IPv6 plans answered before we were
comfortable.  The CTO of that org was the only guy who was able to
answer these questions.  After waiting four days for him to return our
message, he reached out to us from an airplane phone, telling us that
he had been busy racking new routers in several east-coast cities (his
office was not east-coast) and that's why he hadn't got back to us
yet.

As you might imagine, the client quickly realized that they didn't
want to deal with a vendor whose CTO spent his time doing rack & stack
instead of engineering his network or engaging with customers.  If he
had simply said he was on vacation, we would never have known how
poorly the senior people at that ISP managed their time.

With apologies to Randy, let the CCNAs fight with label makers.
-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From mansaxel at besserwisser.org  Fri Feb 17 02:16:56 2012
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Fri, 17 Feb 2012 09:16:56 +0100
Subject: Which P-Touch should I have?
In-Reply-To: <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
Message-ID: <20120217081656.GB12546@besserwisser.org>

Subject: Re: Which P-Touch should I have? Date: Thu, Feb 16, 2012 at 07:45:29PM -0500 Quoting William Herrin (bill at herrin.us):
 
> For cable labeling I've had good results with 3M Scotch Super88 color
> electrical tape. Pick unique color bands for each cable. Band it
> identically at both ends. You don't have to squint to see how it's
> labeled. And the label isn't invalidated merely because you unplugged
> it from one place and plugged it in somewhere else.

At previous employer, we ordered two identical rolls of Brady (IIRC)
numbered labels. Every cable got numbered in both ends  and the number,
being unique at the site, could be used for documentation as well as
finding both ends in looms etc.

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
LBJ, LBJ, how many JOKES did you tell today??!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/ca5e8f6c/attachment.bin>

From brandon at rd.bbc.co.uk  Fri Feb 17 02:17:16 2012
From: brandon at rd.bbc.co.uk (Brandon Butterworth)
Date: Fri, 17 Feb 2012 08:17:16 GMT
Subject: common time-management mistake: rack & stack
Message-ID: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>

> I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack &
> stack" tasks, which I feel is a very unwise use of time and talent.

It's not a waste, it's therapeutic, breaks the monotony of a desk
job, you get a bit of exercise. Doing something mindless can help
clear your thoughts, engineering yoga.

> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.

That'd be a good idea, it's too easy to become remote from reality.
obviously you need the right balance - s/big//

brandon


From nathan at atlasnetworks.us  Fri Feb 17 02:34:36 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 17 Feb 2012 08:34:36 +0000
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B867B@ex-mb-2.corp.atlasnetworks.us>

> With apologies to Randy, let the CCNAs fight with label makers.

No, your CTO shouldn't  be racking and stacking routers all the time.  The fundamental concept of an organizational hierarchy dictates that.  But a CTO who has lost touch with the challenges inherent in racking and stacking a router can't effectively support his team.  See the TV series 'undercover boss' for a (possibly trite and clich?d) example of this.

"Your position never gives you the right to command. It only imposes on you the duty of so living your life that others can receive your orders without being humiliated."
--Dag Hammarskjold


From bortzmeyer at nic.fr  Fri Feb 17 02:42:36 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 17 Feb 2012 09:42:36 +0100
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120215223632.7545efa0@alpinista.org>
References: <20120215223632.7545efa0@alpinista.org>
Message-ID: <20120217084236.GA30791@nic.fr>

On Wed, Feb 15, 2012 at 10:36:32PM +0000,
 George Bakos <gbakos at alpinista.org> wrote 
 a message of 13 lines which said:

> As I hadn't seen it discussed here, I'll have to assume that many
> NANOGers haven't seen the latest rant from Anonymous:

There's nothing proving that it comes from the Anonymous (the name is
itself quite fuzzy, anyone can say "I am the Anonymous"). It may be a
student playing, it may be a security vendor trying to raise more
security awareness, etc.

A post on pastebin means nothing.


From bortzmeyer at nic.fr  Fri Feb 17 02:43:53 2012
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Fri, 17 Feb 2012 09:43:53 +0100
Subject: Anonymous planning a root-servers party
In-Reply-To: <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
References: <20120215223632.7545efa0@alpinista.org>
 <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
Message-ID: <20120217084353.GB30791@nic.fr>

On Wed, Feb 15, 2012 at 04:40:47PM -0600,
 Grant Ridder <shortdudey123 at gmail.com> wrote 
 a message of 23 lines which said:

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

No need to remember, Wikipedia does it for you 
<http://en.wikipedia.org/wiki/Distributed_denial_of_service_attacks_on_root_nameservers>.


From jsw at inconcepts.biz  Fri Feb 17 02:58:55 2012
From: jsw at inconcepts.biz (Jeff Wheeler)
Date: Fri, 17 Feb 2012 03:58:55 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B7B867B@ex-mb-2.corp.atlasnetworks.us>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <8C26A4FDAE599041A13EB499117D3C286B7B867B@ex-mb-2.corp.atlasnetworks.us>
Message-ID: <CAPWAtbK9_+tmP8Sg68Bsm92T_xi2FTnpV-hTS7UQ7DP6Ye+yzw@mail.gmail.com>

On Fri, Feb 17, 2012 at 3:34 AM, Nathan Eisenberg
<nathan at atlasnetworks.us> wrote:
> No, your CTO shouldn't ?be racking and stacking routers all the time. ?The fundamental concept of an organizational hierarchy dictates that. ?But a CTO who has lost touch with the challenges inherent in racking and stacking a router can't effectively support his team. ?See the TV series 'undercover boss' for a (possibly trite and clich?d) example of this.

I'm not suggesting it's a crime for the CTO to put his eyes and hands
on a POP local to his office once in a while, or pay a visit to his
gear in a city where he happens to be in to conduct business that
requires the presence of the CTO, not a CCNA.

On Fri, Feb 17, 2012 at 3:17 AM, Brandon Butterworth
<brandon at rd.bbc.co.uk> wrote:
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.

This, however, is exactly the kind of thinking that produces bad
managers.  Yes, it can be boring sitting at a desk all day.  If that
is your job, don't ignore it so you can play site tech while to-do's
pile up in your absence.  If your are a senior decision-maker, don't
set a bad example for everyone else in your org by blowing off your
senior-level duties to fly around the globe doing something that you
have CCNAs for.

The "my desk-job is boring so I spent the day racking gear" message is
fine if you are not blowing off real work to push boxes through the
co-lo.  If that's your hobby, fine, but rack & stack is not part of
the CTO, network engineer, or whatever, job.  It's a hobby and you
shouldn't ignore your actual duties to go do it.  It's no better than
spending the workday at the movie theater or playing world of warcraft
at the office.

On Fri, Feb 17, 2012 at 3:14 AM, Justin Twiss
<Justin.Twiss at bekkers.com.au> wrote:
> Unfortuantely, some of us work for companies with limited numbers of staff so in effect, the CTO does whatever work is necessary to get the job done and keep the client happy, whether that be rack & stack, decommission, BGP peering or even disaster mitigation...

If you don't have any junior-level employees to do the junior-level
work, yes, this is certainly true.  But as soon as that "CTO," who is
also wearing a bunch of other hats, finds himself with a long to-do
list, the first thing he ought to do is delegate tasks like rack &
stack to inexpensive workers so he can use his most valuable
strengths.


Obviously we are throwing around the term "CTO" at this point in
reference to pretty small businesses, but the basic concept here is,
don't let mundane tasks get in the way of work you are specially
qualified to do.  Definitely don't go out of your way to do mundane
tasks so you can play IBX tourist on your company's dime!

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator? /? Innovative Network Concepts


From don at bowenvale.co.nz  Fri Feb 17 03:01:14 2012
From: don at bowenvale.co.nz (Don Gould)
Date: Fri, 17 Feb 2012 22:01:14 +1300
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
Message-ID: <4F3E175A.7080909@bowenvale.co.nz>

+1

I picked up ram from a supplier today.  Could have used a courier, but 
getting out of the office is vital.

A CTO who's lost touch because they haven't been to a remote site in 
half a decade is a business risk, more so than the CTO being away from 
their desk.

If there is business risk from having the CTO out of touch for a week or 
even a month then there's a bigger problem.

D

On 17/02/2012 9:17 p.m., Brandon Butterworth wrote:
>> I have noticed that a lot of very well-paid, sometimes
>> well-qualified, networking folks spend some of their time on "rack&
>> stack" tasks, which I feel is a very unwise use of time and talent.
>
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.
>
>> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
>
> That'd be a good idea, it's too easy to become remote from reality.
> obviously you need the right balance - s/big//
>
> brandon
>

-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699



From mansaxel at besserwisser.org  Fri Feb 17 07:06:36 2012
From: mansaxel at besserwisser.org (=?utf-8?B?TcOlbnM=?= Nilsson)
Date: Fri, 17 Feb 2012 14:06:36 +0100
Subject: Which P-Touch should I have?
In-Reply-To: <023b01cced33$e20e8860$a62b9920$@chipps.com>
References: <4F3D75D7.3010903@opus1.com>
 <21961071.3155.1329429977888.JavaMail.root@benjamin.baylink.com>
 <CAP-guGUjM_X9Hz3fk46MoCdmf0CHMe_7Gz2cpgYgTekS8rABgg@mail.gmail.com>
 <875B29FA-0705-4276-B3F1-5A942552DC50@delong.com>
 <023b01cced33$e20e8860$a62b9920$@chipps.com>
Message-ID: <20120217130636.GF12546@besserwisser.org>

Subject: RE: Which P-Touch should I have? Date: Thu, Feb 16, 2012 at 11:20:37PM -0600 Quoting Kenneth M. Chipps Ph.D. (chipps at chipps.com):
> I don't suppose anyone follows the TIA-606-B Administration Standard for the
> Telecommunications Infrastructure of Commercial Buildings when labeling
> things like cables.

The swedish equivalents are way to tree-centric, meaning it is hard to
assign codes to stuff like fiber path between rooms that do not pass
the One Interconnect In The Basement.

We did a 600x600mm grid in the entire building (fitting the footprint of
an ETSI frame, or two 300mm deep cabinets as well as being one european
floor tile.) and then every cable documentation refered grid number and
HE. (German for RU) So a cable could be referenced with AA92:12 - AB36:14,
but the only label on the cable was a serial number.

-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
YOU!!  Give me the CUTEST, PINKEST, most charming little VICTORIAN
DOLLHOUSE you can find!!  An make it SNAPPY!!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/fed7364e/attachment.bin>

From jared at puck.nether.net  Fri Feb 17 07:35:54 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 17 Feb 2012 08:35:54 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
Message-ID: <BFB092CA-AA55-41D6-9FA2-D95CA5286055@puck.nether.net>


On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote:

>> I have noticed that a lot of very well-paid, sometimes
>> well-qualified, networking folks spend some of their time on "rack &
>> stack" tasks, which I feel is a very unwise use of time and talent.
> 
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.

	+1 I find this myself, it's useful to do this, as it is to sit in with the operations team and other groups (even finance) to understand what other groups need/require.  I've often found that someone is working around a problem they didn't know you could solve (easily), or is doing a large amount of manual labor when there is an API, etc.

	Perspective is good.  I also do other work that certainly isn't a complete use of my talents that benefits others (e.g.: chaperone a field-trip at school).  These are not without merits, but I do know I have my faults in perhaps reading (and responding) to NANOG too much when I should be engaged in more worthwhile tasks.

>> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
> 
> That'd be a good idea, it's too easy to become remote from reality.
> obviously you need the right balance - s/big//

	- Jared

From ralph.brandt at pateam.com  Fri Feb 17 07:54:18 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Fri, 17 Feb 2012 08:54:18 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <BFB092CA-AA55-41D6-9FA2-D95CA5286055@puck.nether.net>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
 <BFB092CA-AA55-41D6-9FA2-D95CA5286055@puck.nether.net>
Message-ID: <51C66083768C2949A7EB14910C78B0170184EFED@embgsr24.pateam.com>

I think it was Miagi in Karate Kid that stressed balance.  The CTO who
is NEVER out of his cage is dangerous, likewise the one that is never
available is also.  It is keeping in touch with what is happening at all
levels that makes him valuable.  If there is one thing that American
Management misses, it is that.  The GROWING companies almost always have
management that is active, visible and accessible - top to bottom.  The
ones that are dying are not.  The same goes for union leaders who are
really pseudo-management.  The senior technicians are no different than
management, they need broad focus but they must also be able to take the
magnifying glass and look at the current situation.  A network engineer
who cannot do both is not living up to his job description.


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


-----Original Message-----
From: Jared Mauch [mailto:jared at puck.nether.net] 
Sent: Friday, February 17, 2012 8:36 AM
To: Brandon Butterworth
Cc: nanog at nanog.org
Subject: Re: common time-management mistake: rack & stack


On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote:

>> I have noticed that a lot of very well-paid, sometimes
>> well-qualified, networking folks spend some of their time on "rack &
>> stack" tasks, which I feel is a very unwise use of time and talent.
> 
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.

	+1 I find this myself, it's useful to do this, as it is to sit
in with the operations team and other groups (even finance) to
understand what other groups need/require.  I've often found that
someone is working around a problem they didn't know you could solve
(easily), or is doing a large amount of manual labor when there is an
API, etc.

	Perspective is good.  I also do other work that certainly isn't
a complete use of my talents that benefits others (e.g.: chaperone a
field-trip at school).  These are not without merits, but I do know I
have my faults in perhaps reading (and responding) to NANOG too much
when I should be engaged in more worthwhile tasks.

>> Imagine if the CFO of a bank spent a big chunk of his time filling up
ATMs.
> 
> That'd be a good idea, it's too easy to become remote from reality.
> obviously you need the right balance - s/big//

	- Jared


From nick at foobar.org  Fri Feb 17 08:00:45 2012
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 17 Feb 2012 14:00:45 +0000
Subject: Spam from Telx
In-Reply-To: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
Message-ID: <4F3E5D8D.60403@foobar.org>

So, anyone else get spammed by Telx after posting to nanog?

This is massively unprofessional.

Nick

-------- Original Message --------
Subject: RE: telx
Date: Fri, 17 Feb 2012 13:47:25 +0000
From: George Fitzpatrick <gfitzpatrick at telx.com>
To: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi xxxxxxxxxxxx,

We have some exciting things happening here at Telx that can help your
network connectivity.
Can we chat for 5 minutes?

Thanks,
George
917.371.7257




From sven at cb3rob.net  Fri Feb 17 08:04:50 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 14:04:50 +0000 (UTC)
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202171359510.14470@a84-22-97-10.cb3rob.net>

>
> I was once advising a client on a transit purchasing decision, and a
> fairly-large, now-defunct tier-2 ISP was being considered.  We needed
> a few questions about their IPv6 plans answered before we were
> comfortable.  The CTO of that org was the only guy who was able to
> answer these questions.  After waiting four days for him to return our
> message, he reached out to us from an airplane phone, telling us that
> he had been busy racking new routers in several east-coast cities (his
> office was not east-coast) and that's why he hadn't got back to us
> yet.
>
> As you might imagine, the client quickly realized that they didn't
> want to deal with a vendor whose CTO spent his time doing rack & stack
> instead of engineering his network or engaging with customers.  If he
> had simply said he was on vacation, we would never have known how
> poorly the senior people at that ISP managed their time.

on the contrary, we'd PREFER if CEO's and CTO's of our trading partners 
know what their company is doing and how their core network actually 
works. (Rather than just giving one of those stupid flyers with a world 
map and some lines representing their network to potential customers ;)

no "startrek questions pls". :P.

(and rack & stack with "routers" is something else than rack & stack with 
serverfarms, as for servers, you can just as well have an installation 
company or the vendor do it for you ("clearance" issues set aside ;).. 
with routers its a bit more touchy which wire goes where exactly, and 
furthermore, they have to be individually configured during install, so 
its better to just be there, CTO or not CTO :P

you might be confusing the CTO for the sales manager :P


From jthomas at axcelx.com  Fri Feb 17 08:09:09 2012
From: jthomas at axcelx.com (James Thomas)
Date: Fri, 17 Feb 2012 09:09:09 -0500
Subject: Spam from Telx
In-Reply-To: <4F3E5D8D.60403@foobar.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
Message-ID: <004901cced7d$b77f7420$267e5c60$@com>

He has spammed by responding to posts that people have made in the past, he
is still trolling I guess.

James

-----Original Message-----
From: Nick Hilliard [mailto:nick at foobar.org] 
Sent: Friday, February 17, 2012 9:01 AM
To: nanog at nanog.org
Subject: Spam from Telx

So, anyone else get spammed by Telx after posting to nanog?

This is massively unprofessional.

Nick

-------- Original Message --------
Subject: RE: telx
Date: Fri, 17 Feb 2012 13:47:25 +0000
From: George Fitzpatrick <gfitzpatrick at telx.com>
To: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Hi xxxxxxxxxxxx,

We have some exciting things happening here at Telx that can help your
network connectivity.
Can we chat for 5 minutes?

Thanks,
George
917.371.7257





From sven at cb3rob.net  Fri Feb 17 08:10:02 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 14:10:02 +0000 (UTC)
Subject: Anonymous planning a root-servers party
In-Reply-To: <20120217084353.GB30791@nic.fr>
References: <20120215223632.7545efa0@alpinista.org>
 <CAPiURgUGbx0mV65vUXqSC+YdUjnAPpGAZ=kC1Z_bCZH5nx1-JQ@mail.gmail.com>
 <20120217084353.GB30791@nic.fr>
Message-ID: <Pine.LNX.4.64.1202171406410.14470@a84-22-97-10.cb3rob.net>

the zionist usa regime does a far better job at taking icann out of the 
loop as a resolvable root than anonymous will ever able to do :P

(time to change the root.hints to a competing root ;)

the internet treats censorship as damage and routes around it, remember 
that one :P

so can special agent retard of ICE put all those domains back nao pls :P

you know the ones that say "seized" (must be american english for "we 
don't care about the souvereignity of other countries and confiscate 
assets of their citizens nontheless ;)

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Stephane Bortzmeyer wrote:

> On Wed, Feb 15, 2012 at 04:40:47PM -0600,
> Grant Ridder <shortdudey123 at gmail.com> wrote
> a message of 23 lines which said:
>
>> 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.
>
> No need to remember, Wikipedia does it for you
> <http://en.wikipedia.org/wiki/Distributed_denial_of_service_attacks_on_root_nameservers>.
>


From ahebert at pubnix.net  Fri Feb 17 08:11:32 2012
From: ahebert at pubnix.net (Alain Hebert)
Date: Fri, 17 Feb 2012 09:11:32 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <4F3E6014.2000000@pubnix.net>

     Hi,

     Or sometimes you don't let a hazardous task like handling a Carrier 
Class Router to your CCNA in case they injure themself.

     Or worst...  drop it =D

     ( From an actual experience )

-----
Alain Hebert                                ahebert at pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443


On 02/17/12 02:29, Jeff Wheeler wrote:
> Randy's P-Touch thread brings up an issue I think is worth some
> discussion.  I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack&
> stack" tasks, which I feel is a very unwise use of time and talent.
>
> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
> Flying a sharp router jockey around to far-flung POPs to install gear
> is just as foolish.
>
> Not only does the router jockey cost a lot more to employ than a CCNA,
> but if your senior-level talent is wasting time in airports and IBXes,
> that is time they can't be doing things CCNAs can't.
>
> I was once advising a client on a transit purchasing decision, and a
> fairly-large, now-defunct tier-2 ISP was being considered.  We needed
> a few questions about their IPv6 plans answered before we were
> comfortable.  The CTO of that org was the only guy who was able to
> answer these questions.  After waiting four days for him to return our
> message, he reached out to us from an airplane phone, telling us that
> he had been busy racking new routers in several east-coast cities (his
> office was not east-coast) and that's why he hadn't got back to us
> yet.
>
> As you might imagine, the client quickly realized that they didn't
> want to deal with a vendor whose CTO spent his time doing rack&  stack
> instead of engineering his network or engaging with customers.  If he
> had simply said he was on vacation, we would never have known how
> poorly the senior people at that ISP managed their time.
>
> With apologies to Randy, let the CCNAs fight with label makers.


From streiner at cluebyfour.org  Fri Feb 17 08:13:22 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 09:13:22 -0500 (EST)
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
Message-ID: <Pine.LNX.4.64.1202170900230.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Brandon Butterworth wrote:

> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.

Definite +1 here.  I got my start in this profession 15-ish years ago at a 
mid-sized regional ISP.  The company was small enough, in terms of its work
force, that that I interviewed with the CEO for what was largely an IT 
position.  As a result, many people in the organization wore lots of 
different hats.  It wasn't to the point of having accountants pull cable 
or IT guys doing the books, but I did spend a lot of time doing 
rack-and-stack work.  I didn't (and still don't) mind rack-and-stack, 
pulling cable, etc.  As others have said, it's a good, therapeutic 
diversion from staring at a screen and attending meetings ;)

Another good reason for getting out into the field.  When you're the 
person who defines technical deployment standards for an organization, it 
gives you an opportunity to verify that work is being done to those 
standards.

> That'd be a good idea, it's too easy to become remote from reality.
> obviously you need the right balance - s/big//

I'm sure if the ISP I got my start with 15-ish years ago was much bigger, I
would not have interviewed with the CEO, but at that time, it was the right
fit for that organization.

jms


From rps at maine.edu  Fri Feb 17 08:13:54 2012
From: rps at maine.edu (Ray Soucy)
Date: Fri, 17 Feb 2012 09:13:54 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
Message-ID: <CALFTrnOupefAKzTtuHpYN_o_h7StisqrYDW1TBWrYD=oM3xiOQ@mail.gmail.com>

Hrm.

On Fri, Feb 17, 2012 at 3:17 AM, Brandon Butterworth
<brandon at rd.bbc.co.uk> wrote:
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.

This.

One of the reasons I love my job so much is that I don't need to be
stuck at a keyboard all the time.

I usually "volunteer" to help rack and stack new hardware that I
haven't had a chance to touch yet.  "For humans, touch can connect you
to an object in a very personal way, make it seem more real."

: )

-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From streiner at cluebyfour.org  Fri Feb 17 08:15:48 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 09:15:48 -0500 (EST)
Subject: Spam from Telx
In-Reply-To: <4F3E5D8D.60403@foobar.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
Message-ID: <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Nick Hilliard wrote:

> So, anyone else get spammed by Telx after posting to nanog?
>
> This is massively unprofessional.

Yep - just got one a few minutes ago.  I was just getting ready to spin up 
my trolling-for-business-by-scraping-addresses-from-nanog-is-bad-mojo 
response.

jms

> We have some exciting things happening here at Telx that can help your
> network connectivity.
> Can we chat for 5 minutes?
>
> Thanks,
> George
> 917.371.7257
>
>
>
>


From sven at cb3rob.net  Fri Feb 17 08:18:01 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 14:18:01 +0000 (UTC)
Subject: common time-management mistake: rack & stack
In-Reply-To: <4F3E6014.2000000@pubnix.net>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <4F3E6014.2000000@pubnix.net>
Message-ID: <Pine.LNX.4.64.1202171415420.14470@a84-22-97-10.cb3rob.net>

actually most west european countries have laws against having your 
employees lift up stuff heavier than 20 kilos :P

you generally don't have insurance on your network-dude to handle such 
things *grin* if it drops on his foot, you're screwed. (or worse, on his 
hand ;)

looking at the latest models we found units weighing 110 kilos *grin*
i'm not lifting -that- up.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Alain Hebert wrote:

>    Hi,
>
>    Or sometimes you don't let a hazardous task like handling a Carrier Class 
> Router to your CCNA in case they injure themself.
>
>    Or worst...  drop it =D
>
>    ( From an actual experience )
>
> -----
> Alain Hebert                                ahebert at pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.net    Fax: 514-990-9443
>
>
> On 02/17/12 02:29, Jeff Wheeler wrote:
>> Randy's P-Touch thread brings up an issue I think is worth some
>> discussion.  I have noticed that a lot of very well-paid, sometimes
>> well-qualified, networking folks spend some of their time on "rack&
>> stack" tasks, which I feel is a very unwise use of time and talent.
>> 
>> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
>> Flying a sharp router jockey around to far-flung POPs to install gear
>> is just as foolish.
>> 
>> Not only does the router jockey cost a lot more to employ than a CCNA,
>> but if your senior-level talent is wasting time in airports and IBXes,
>> that is time they can't be doing things CCNAs can't.
>> 
>> I was once advising a client on a transit purchasing decision, and a
>> fairly-large, now-defunct tier-2 ISP was being considered.  We needed
>> a few questions about their IPv6 plans answered before we were
>> comfortable.  The CTO of that org was the only guy who was able to
>> answer these questions.  After waiting four days for him to return our
>> message, he reached out to us from an airplane phone, telling us that
>> he had been busy racking new routers in several east-coast cities (his
>> office was not east-coast) and that's why he hadn't got back to us
>> yet.
>> 
>> As you might imagine, the client quickly realized that they didn't
>> want to deal with a vendor whose CTO spent his time doing rack&  stack
>> instead of engineering his network or engaging with customers.  If he
>> had simply said he was on vacation, we would never have known how
>> poorly the senior people at that ISP managed their time.
>> 
>> With apologies to Randy, let the CCNAs fight with label makers.
>


From sven at cb3rob.net  Fri Feb 17 08:22:08 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 14:22:08 +0000 (UTC)
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
Message-ID: <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>

\o/ i got one too, i'll put a bunch of sales droids on this "George" from 
telx right away to make him an offer in return *grin*

(this is how you treat ppl trying to sell you something in an aggressive 
manner, you just have your people try to sell -them- something in return 
;)

On Fri, 17 Feb 2012, Justin M. Streiner wrote:

> On Fri, 17 Feb 2012, Nick Hilliard wrote:
>
>> So, anyone else get spammed by Telx after posting to nanog?
>> 
>> This is massively unprofessional.
>
> Yep - just got one a few minutes ago.  I was just getting ready to spin up my 
> trolling-for-business-by-scraping-addresses-from-nanog-is-bad-mojo response.
>
> jms
>
>> We have some exciting things happening here at Telx that can help your
>> network connectivity.
>> Can we chat for 5 minutes?
>> 
>> Thanks,
>> George
>> 917.371.7257
>> 
>> 
>> 
>> 
>


From shortdudey123 at gmail.com  Fri Feb 17 08:24:49 2012
From: shortdudey123 at gmail.com (Grant Ridder)
Date: Fri, 17 Feb 2012 08:24:49 -0600
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
Message-ID: <CAPiURgW=pdym-a4DPMtaqKGka7udDw6RNTrb=tv53+p0AGjzew@mail.gmail.com>

Ya, i got a message 2 days ago from them.  It was very vague.  Only
2 sentences.

-Grant

On Fri, Feb 17, 2012 at 8:15 AM, Justin M. Streiner <streiner at cluebyfour.org
> wrote:

> On Fri, 17 Feb 2012, Nick Hilliard wrote:
>
>  So, anyone else get spammed by Telx after posting to nanog?
>>
>> This is massively unprofessional.
>>
>
> Yep - just got one a few minutes ago.  I was just getting ready to spin up
> my trolling-for-business-by-**scraping-addresses-from-nanog-**is-bad-mojo
> response.
>
> jms
>
>
>  We have some exciting things happening here at Telx that can help your
>> network connectivity.
>> Can we chat for 5 minutes?
>>
>> Thanks,
>> George
>> 917.371.7257
>>
>>
>>
>>
>>
>

From bicknell at ufp.org  Fri Feb 17 08:29:27 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 06:29:27 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3DF8A3.8040708@paulgraydon.co.uk>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
Message-ID: <20120217142927.GA70102@ussenterprise.ufp.org>

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

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

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

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

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/6c823e0e/attachment.bin>

From bhmccie at gmail.com  Fri Feb 17 08:29:42 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 08:29:42 -0600
Subject: Common operational misconceptions
In-Reply-To: <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
Message-ID: <4F3E6456.9090507@gmail.com>

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From streiner at cluebyfour.org  Fri Feb 17 08:33:56 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 09:33:56 -0500 (EST)
Subject: common time-management mistake: rack & stack
In-Reply-To: <Pine.LNX.4.64.1202171415420.14470@a84-22-97-10.cb3rob.net>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <4F3E6014.2000000@pubnix.net>
 <Pine.LNX.4.64.1202171415420.14470@a84-22-97-10.cb3rob.net>
Message-ID: <Pine.LNX.4.64.1202170924090.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:

> actually most west european countries have laws against having your employees 
> lift up stuff heavier than 20 kilos :P

IT job postings in the US often include physical qualifiers such as "must 
be able to lift weights of up to 50 pounds (~22.7 kilos)" and "must be 
able to use hand tools".  The lecture about using safe lifting practices 
usually waits until after you accept the job and go through your 
new-employee orientation :)

jms


From bicknell at ufp.org  Fri Feb 17 08:46:13 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 06:46:13 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <20120217144613.GB70102@ussenterprise.ufp.org>

In a message written on Fri, Feb 17, 2012 at 02:29:36AM -0500, Jeff Wheeler wrote:
> Randy's P-Touch thread brings up an issue I think is worth some
> discussion.  I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack &
> stack" tasks, which I feel is a very unwise use of time and talent.

At the risk of offending many folks on NANOG, our industry is more
like a trade than a profession.  In many cases we would do better
to treat our people (in terms of how they are managed) like skilled
trades, electricians, plumbers, metal fitters, rather than pretend
they are white collar professionals.

Low level employees should be apprenticed by higher level employees.
Many of our skills are learned on the job; just like other trades
someone with only book knowledge is darn near useless.  Not only
do those above need to teach, but they need to supervise, and
exercise standards and quality control.

To your point, if you look at skilled trades the simpler the task the
more likely it will fall to the "new guy".  Rack and stack is probably
one of simplest jobs in our industry.  A two man team, one senior, one
junior, showing up at a colo may see the junior guy doing the physical
work, while the senior guy works out any issues with the colo provider
brings up the interconnection to them, etc.

But key to an apprenticeship is that the senior guy does some of
the low level work some of the time, and _shows_ the junior guy how
to do it right.  The senior guy might rack or stack a couple of
boxes each colo they visit, and relate concepts like how the screw
hole spacing works in the rack rails, how to plan cable management,
proper labeling, and so on.

It really accomplishes much of what everyone else is talking about,
while still being productive.  The "old hat" gets the downtime and
catharsis of doing a simple, yet productive task.  The new guy gets to
learn how to do the job properly.  The employer knows the work has 
been done right, as it was overseen by the old hat, and that they will
have someone to replace him when the old hat retires.

Maybe if we did more apprecenship style learning folks would still know
how to wrap cables with wax string.  It's simple, fast, and works well.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/7ea87b52/attachment-0001.bin>

From ralph.brandt at pateam.com  Fri Feb 17 08:51:23 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Fri, 17 Feb 2012 09:51:23 -0500
Subject: Common operational misconceptions
In-Reply-To: <20120217142927.GA70102@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
Message-ID: <51C66083768C2949A7EB14910C78B0170184EFF8@embgsr24.pateam.com>

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

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


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

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

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

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

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

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

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


From bhmccie at gmail.com  Fri Feb 17 08:52:23 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 08:52:23 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120217142927.GA70102@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
Message-ID: <4F3E69A7.2060008@gmail.com>

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

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From streiner at cluebyfour.org  Fri Feb 17 08:54:22 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 09:54:22 -0500 (EST)
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
Message-ID: <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:

> \o/ i got one too, i'll put a bunch of sales droids on this "George" from 
> telx right away to make him an offer in return *grin*

I did respond directly to him, and got a somewhat indignant response back, 
stating that he had no idea what I was talking about and that my contact 
information had come from an "opt in email broker".  It's going to be one 
of those days....

jms


From w3yni1 at gmail.com  Fri Feb 17 08:57:03 2012
From: w3yni1 at gmail.com (Charles Mills)
Date: Fri, 17 Feb 2012 09:57:03 -0500
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
Message-ID: <CAOF0KO9eE1+kv+VwdiZQJ2WU6yHbwV_WF+5ey4OhexqPDxG+JA@mail.gmail.com>

I didn't even respond.  I think many of these
high-pressure-aggressive-types always have an answer like that conveniently
vague enough as to give them an "out".

On Fri, Feb 17, 2012 at 9:54 AM, Justin M. Streiner <streiner at cluebyfour.org
> wrote:

> On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:
>
>  \o/ i got one too, i'll put a bunch of sales droids on this "George" from
>> telx right away to make him an offer in return *grin*
>>
>
> I did respond directly to him, and got a somewhat indignant response back,
> stating that he had no idea what I was talking about and that my contact
> information had come from an "opt in email broker".  It's going to be one
> of those days....
>
> jms
>
>

From meirea at charterschoolit.com  Fri Feb 17 08:57:37 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Fri, 17 Feb 2012 14:57:37 +0000
Subject: Common operational misconceptions
In-Reply-To: <20120217142927.GA70102@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>,
 <20120217142927.GA70102@ussenterprise.ufp.org>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C053D2E@CSIT-SRV-MBX-01.charterschoolit.local>

+1

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

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

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

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

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

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


From ralph.brandt at pateam.com  Fri Feb 17 09:01:34 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Fri, 17 Feb 2012 10:01:34 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E69A7.2060008@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184EFFA@embgsr24.pateam.com>

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

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

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

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

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

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


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

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

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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



From streiner at cluebyfour.org  Fri Feb 17 09:02:01 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 10:02:01 -0500 (EST)
Subject: Spam from Telx
In-Reply-To: <CAOF0KO9eE1+kv+VwdiZQJ2WU6yHbwV_WF+5ey4OhexqPDxG+JA@mail.gmail.com>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <CAOF0KO9eE1+kv+VwdiZQJ2WU6yHbwV_WF+5ey4OhexqPDxG+JA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202170958300.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Charles Mills wrote:

> I didn't even respond.  I think many of these
> high-pressure-aggressive-types always have an answer like that conveniently
> vague enough as to give them an "out".

I did mention to him that such tactics were likely to create a large group 
of people who will never do business with Telx.  It's equivalent to having 
someone call you out of the blue to sell you a car, whether you're in the 
market to buy or not.

jms


From ops.lists at gmail.com  Fri Feb 17 09:04:43 2012
From: ops.lists at gmail.com (Suresh Ramasubramanian)
Date: Fri, 17 Feb 2012 20:34:43 +0530
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
Message-ID: <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>

In other words he bought a list of leads.

On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner
<streiner at cluebyfour.org> wrote:
> I did respond directly to him, and got a somewhat indignant response back,
> stating that he had no idea what I was talking about and that my contact
> information had come from an "opt in email broker". ?It's going to be one of
> those days....



-- 
Suresh Ramasubramanian (ops.lists at gmail.com)


From streiner at cluebyfour.org  Fri Feb 17 09:09:16 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 10:09:16 -0500 (EST)
Subject: Spam from Telx
In-Reply-To: <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202171008120.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote:

> In other words he bought a list of leads.

Possibly, albeit a poorly screened list of leads.

jms

> On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner
> <streiner at cluebyfour.org> wrote:
>> I did respond directly to him, and got a somewhat indignant response back,
>> stating that he had no idea what I was talking about and that my contact
>> information had come from an "opt in email broker". ?It's going to be one of
>> those days....
>
>
>
> -- 
> Suresh Ramasubramanian (ops.lists at gmail.com)
>

From sven at cb3rob.net  Fri Feb 17 09:09:17 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 15:09:17 +0000 (UTC)
Subject: Spam from Telx
In-Reply-To: <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202171507260.30949@a84-22-97-10.cb3rob.net>

needless to say their own website is slow as poo through a coffee filter 
:P

reminds me of the isdn days :P

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote:

> In other words he bought a list of leads.
>
> On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner
> <streiner at cluebyfour.org> wrote:
>> I did respond directly to him, and got a somewhat indignant response back,
>> stating that he had no idea what I was talking about and that my contact
>> information had come from an "opt in email broker". ?It's going to be one of
>> those days....
>
>
>
> -- 
> Suresh Ramasubramanian (ops.lists at gmail.com)
>

From sven at cb3rob.net  Fri Feb 17 09:11:24 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 15:11:24 +0000 (UTC)
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202171507260.30949@a84-22-97-10.cb3rob.net>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>
 <Pine.LNX.4.64.1202171507260.30949@a84-22-97-10.cb3rob.net>
Message-ID: <Pine.LNX.4.64.1202171510460.11363@a84-22-97-10.cb3rob.net>

we have something exitig happening at telx! we are now connected to the 
"backbone" through a 128kbit/s adsl line!

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:

> needless to say their own website is slow as poo through a coffee filter :P
>
> reminds me of the isdn days :P
>
> -- 
> Greetings,
>
> Sven Olaf Kamphuis,
> CB3ROB Ltd. & Co. KG
> =========================================================================
> Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
>         D-13359                   Registration:    HRA 42834 B
>         BERLIN                    Phone:           +31/(0)87-8747479
>         Germany                   GSM:             +49/(0)152-26410799
> RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
> =========================================================================
> <penpen> C3P0, der elektrische Westerwelle
> http://www.facebook.com/cb3rob
> =========================================================================
>
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
>
>
> On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote:
>
>> In other words he bought a list of leads.
>> 
>> On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner
>> <streiner at cluebyfour.org> wrote:
>>> I did respond directly to him, and got a somewhat indignant response back,
>>> stating that he had no idea what I was talking about and that my contact
>>> information had come from an "opt in email broker". ??It's going to be one 
>>> of
>>> those days....
>> 
>> 
>> 
>> -- 
>> Suresh Ramasubramanian (ops.lists at gmail.com)
>

From meirea at charterschoolit.com  Fri Feb 17 09:12:57 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Fri, 17 Feb 2012 15:12:57 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3E69A7.2060008@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,<4F3E69A7.2060008@gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>

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

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

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

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

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

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

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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



From jbates at brightok.net  Fri Feb 17 09:14:00 2012
From: jbates at brightok.net (Jack Bates)
Date: Fri, 17 Feb 2012 09:14:00 -0600
Subject: Common operational misconceptions
In-Reply-To: <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
Message-ID: <4F3E6EB8.5070803@brightok.net>

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

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

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

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


Jack


From leigh.porter at ukbroadband.com  Fri Feb 17 09:19:47 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 17 Feb 2012 15:19:47 +0000
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202171008120.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <CAArzuovVfW=Z_+Yf-yyu_6R4CrqL9v=5foA-f9kJRSumfX3pEQ@mail.gmail.com>,
 <Pine.LNX.4.64.1202171008120.18711@whammy.cluebyfour.org>
Message-ID: <DCF7A062-EFAA-47B7-96F7-523686EBC3C9@ukbroadband.com>

No he didnt. The one he sent to me actually included part of the thread he picked me up from.

I told him the most exciting thing he could do is to not spam me again.

Poor guy, did nobody tell him?

-- 
Leigh Porter


On 17 Feb 2012, at 15:11, "Justin M. Streiner" <streiner at cluebyfour.org> wrote:

> On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote:
> 
>> In other words he bought a list of leads.
> 
> Possibly, albeit a poorly screened list of leads.
> 
> jms
> 
>> On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner
>> <streiner at cluebyfour.org> wrote:
>>> I did respond directly to him, and got a somewhat indignant response back,
>>> stating that he had no idea what I was talking about and that my contact
>>> information had come from an "opt in email broker".  It's going to be one of
>>> those days....
>> 
>> 
>> 
>> -- 
>> Suresh Ramasubramanian (ops.lists at gmail.com)
>> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

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


From sclark at netwolves.com  Fri Feb 17 09:18:57 2012
From: sclark at netwolves.com (Steve Clark)
Date: Fri, 17 Feb 2012 10:18:57 -0500
Subject: Common operational misconceptions
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3E6FE1.7030607@netwolves.com>

I agree with this 100%.

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

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


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

From marka at isc.org  Fri Feb 17 09:20:12 2012
From: marka at isc.org (Mark Andrews)
Date: Sat, 18 Feb 2012 02:20:12 +1100
Subject: Spam from Telx
In-Reply-To: Your message of "Fri, 17 Feb 2012 09:54:22 CDT."
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
Message-ID: <20120217152012.67A9F1D93DA8@drugs.dv.isc.org>


In message <Pine.LNX.4.64.1202170951390.18711 at whammy.cluebyfour.org>, "Justin M
. Streiner" writes:
> On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:
> 
> > \o/ i got one too, i'll put a bunch of sales droids on this "George" from 
> > telx right away to make him an offer in return *grin*
> 
> I did respond directly to him, and got a somewhat indignant response back, 
> stating that he had no idea what I was talking about and that my contact 
> information had come from an "opt in email broker".  It's going to be one 
> of those days....
> 
> jms
> 

It's a little hard to says that with a straight face when it has a copy
of the message posted to nanog attached.
It's even more "amusing" when your company is already listed in the pdf.

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


From thegameiam at yahoo.com  Fri Feb 17 09:20:37 2012
From: thegameiam at yahoo.com (David Barak)
Date: Fri, 17 Feb 2012 07:20:37 -0800 (PST)
Subject: Common operational misconceptions
In-Reply-To: <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
Message-ID: <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>

>From: Owen DeLong owen at delong.com

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

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

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

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

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

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

From streiner at cluebyfour.org  Fri Feb 17 09:28:23 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 10:28:23 -0500 (EST)
Subject: Spam from Telx
In-Reply-To: <20120217152012.67A9F1D93DA8@drugs.dv.isc.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <20120217152012.67A9F1D93DA8@drugs.dv.isc.org>
Message-ID: <Pine.LNX.4.64.1202171026561.18711@whammy.cluebyfour.org>

On Sat, 18 Feb 2012, Mark Andrews wrote:

>> I did respond directly to him, and got a somewhat indignant response back,
>> stating that he had no idea what I was talking about and that my contact
>> information had come from an "opt in email broker".  It's going to be one
>> of those days....
>
> It's a little hard to says that with a straight face when it has a copy
> of the message posted to nanog attached.
> It's even more "amusing" when your company is already listed in the pdf.

The message I got was a bit more sanitized.  Guess I was lucky ;)

jms


From jra at baylink.com  Fri Feb 17 09:28:22 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 10:28:22 -0500 (EST)
Subject: Which way to fold the label (was: Re: time sink 42)
In-Reply-To: <1329437681.17490.414.camel@karl>
Message-ID: <3634669.3367.1329492502370.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Karl Auer" <kauer at biplane.com.au>

> On Thu, 2012-02-16 at 17:17 -0500, Jay Ashworth wrote:
> > > Fold one of the corners of the label, just a tiny corner, back towards
> > > the backing paper, then forward.
> 
> > It matters which way you bend, because of the relative stiffness of
> > the paper and the plastic; you have to bend *towards* the paper,
> > which will stay folded, away from the plastic.
> 
> What?!? Forward instead of backward? KILL THE UNBELIEVER! KILL! KILL!

Way to misquote me, Karl.  :-)

> The alternative approach, to which ALL right-thinking persons subscribe,
> is to avoid, as much as possible, folding the label. Because, indeed and
> as you say, it will remain folded. If the label does have to be bent, it
> should be left bent down, not up. Bending it towards the backing may
> work on it's own, subjecting the backing paper to the more acute
> deformation, and the label may even thereafter return to the flat
> position uncreased, leaving the backing paper separated. The more
> destructive bend upwards may also leave a corner of the label bent up
> and away from the surface the label will be on.

It isn't necessary to bend it so sharply that the crease will stay in the 
plastic, no.

And no, I didn't say the "label would stay folded".  I said the "backing 
would stay folded".

GET IT RIGHT!!!!!1111!!!!ONE!!!!ELEVENTYONE!

> The Covenant of the Holy Order of Downfolders meets weekly behind the
> fourth server rack from the left, lower basement. Batteries not
> supplied. Bring your own torch, pitchfork, etc.

Magic?  

Or More Magic?

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


From jra at baylink.com  Fri Feb 17 09:30:33 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 10:30:33 -0500 (EST)
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <4F3DA88F.1040700@paulgraydon.co.uk>
Message-ID: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Paul Graydon" <paul at paulgraydon.co.uk>

> Anecdotally, I had an interview years ago for a small-ish futures
> trading company based in London. The interviewer had to pause the
> interview part way through whilst he investigated a 10ms latency spike
> that the traders were noticing on a short point-to-point fiber link to
> the London Stock Exchange. He commented that the traders were far
> better at 'feeling' when an connection was showing even a trace of lag
> compared to normal than anything he'd set up by way of monitoring (not
> sure how good his monitoring was, though.)

This was my experience in a callcenter as well; network type problem reports
always came in from the floor managers before Nagios came forth with an 
opinion.

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


From jra at baylink.com  Fri Feb 17 09:33:12 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 10:33:12 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <20120216213503.dv4tk6ot8g0k0c8w@cubmail.cc.columbia.edu>
Message-ID: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>

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

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

Yeah, no.

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

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


From jared at puck.nether.net  Fri Feb 17 09:36:17 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 17 Feb 2012 10:36:17 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E6456.9090507@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org> <4F3E6456.9090507@gmail.com>
Message-ID: <35D94D0B-73ED-4C79-B01C-E221DBF0AFEA@puck.nether.net>


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

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


I was thinking of making a checklist out of it.

- Jared

From w3yni1 at gmail.com  Fri Feb 17 09:39:36 2012
From: w3yni1 at gmail.com (Charles Mills)
Date: Fri, 17 Feb 2012 10:39:36 -0500
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202171026561.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
 <20120217152012.67A9F1D93DA8@drugs.dv.isc.org>
 <Pine.LNX.4.64.1202171026561.18711@whammy.cluebyfour.org>
Message-ID: <CAOF0KO-hUnFMw0h7p8cOSY3VvJUchsXj-LJzhWT_wNUJxYTcZw@mail.gmail.com>

I've been getting voicemails from someone, leaving a first name only saying
they have question that only I can answer.  Dangling bait like that is a
big red flag so they don't get a callback.

On Fri, Feb 17, 2012 at 10:28 AM, Justin M. Streiner <
streiner at cluebyfour.org> wrote:

> On Sat, 18 Feb 2012, Mark Andrews wrote:
>
>  I did respond directly to him, and got a somewhat indignant response back,
>>> stating that he had no idea what I was talking about and that my contact
>>> information had come from an "opt in email broker".  It's going to be one
>>> of those days....
>>>
>>
>> It's a little hard to says that with a straight face when it has a copy
>> of the message posted to nanog attached.
>> It's even more "amusing" when your company is already listed in the pdf.
>>
>
> The message I got was a bit more sanitized.  Guess I was lucky ;)
>
> jms
>
>

From wade at e-novations.ca  Fri Feb 17 09:40:54 2012
From: wade at e-novations.ca (Kierstead, Wade)
Date: Fri, 17 Feb 2012 15:40:54 +0000
Subject: One solution -- time sink 42
Message-ID: <922FCBA4BB44C64D84464CC3645025B4330EE975@Tiger01.city.fredericton.nb.ca>


Here's a little trick that works really well for those types of labels.  Have you watched professional wrappers at Christmas time curling ribbon with a  pair of scissors?  It works for removing the backing from the labels as well.  Hold the backing of the label against the side of a pair of scissors / knife / even a key with some sharper points on it, and drag it across the edge.  This will make the ends separate a little bit, allowing you to take hold and easily separate the pieces.

Check out this site that shows it being done with scissors if you've never seen it 
http://www.wikihow.com/Curl-Ribbon 

Make sure it's the backing side being scraped across the scissors, not the printed side.

Wade


-----Original Message-----
From: Randy Bush [mailto:randy at psg.com]
Sent: Thursday, February 16, 2012 4:09 PM
To: North American Network Operators' Group
Subject: time sink 42

ok, this is horribly pragmatic, but it's real.  yesterday i was in the westin playing rack and stack for five hours.  an horrifyingly large amount of my time was spent trying to peel apart labels made on my portable brother label tape maker, yes peeling the backing from a little label so remote hands could easily confirm a server they were going to attack.

is there a trick?  is there a (not expensive) different labeling machine or technique i should use?

randy





________________________________

This electronic mail, including any attachments, is confidential and is for the sole use of the intended recipient and may be privileged.  Any unauthorized distribution, copying, disclosure or review is prohibited.  Neither communication over the Internet nor disclosure to anyone other than the intended recipient constitutes waiver of privilege.  If you are not the intended recipient, please immediately notify the sender and then delete this communication and any attachments from your computer system and records without saving or forwarding it. Thank you.




From sven at cb3rob.net  Fri Feb 17 09:44:10 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 15:44:10 +0000 (UTC)
Subject: Common operational misconceptions
In-Reply-To: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
References: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
Message-ID: <Pine.LNX.4.64.1202171539510.6626@a84-22-97-10.cb3rob.net>

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

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


From bhmccie at gmail.com  Fri Feb 17 09:46:13 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 09:46:13 -0600
Subject: Common operational misconceptions
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184EFFA@embgsr24.pateam.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <51C66083768C2949A7EB14910C78B0170184EFFA@embgsr24.pateam.com>
Message-ID: <4F3E7645.2000708@gmail.com>

Well said. An American tragedy.

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From jbates at brightok.net  Fri Feb 17 09:48:21 2012
From: jbates at brightok.net (Jack Bates)
Date: Fri, 17 Feb 2012 09:48:21 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3E6FE1.7030607@netwolves.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com>
Message-ID: <4F3E76C5.8010902@brightok.net>



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

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

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


Jack


From cmadams at hiwaay.net  Fri Feb 17 09:49:56 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Fri, 17 Feb 2012 09:49:56 -0600
Subject: Spam from Telx
In-Reply-To: <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
 <Pine.LNX.4.64.1202170914070.18711@whammy.cluebyfour.org>
 <Pine.LNX.4.64.1202171420430.25485@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202170951390.18711@whammy.cluebyfour.org>
Message-ID: <20120217154956.GC21219@hiwaay.net>

Once upon a time, Justin M. Streiner <streiner at cluebyfour.org> said:
> On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:
> >\o/ i got one too, i'll put a bunch of sales droids on this "George" from 
> >telx right away to make him an offer in return *grin*
> 
> I did respond directly to him, and got a somewhat indignant response back, 
> stating that he had no idea what I was talking about and that my contact 
> information had come from an "opt in email broker".  It's going to be one 
> of those days....

My personalized message from George was directly in reply to my post in
the "time sink 42" thread.  He's subscribed to the list and just going
down the message list hitting "reply".
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From bhmccie at gmail.com  Fri Feb 17 09:51:18 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 09:51:18 -0600
Subject: Common operational misconceptions
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <4F3E7776.1010405@gmail.com>

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From bhmccie at gmail.com  Fri Feb 17 09:51:47 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 09:51:47 -0600
Subject: Common operational misconceptions
In-Reply-To: <35D94D0B-73ED-4C79-B01C-E221DBF0AFEA@puck.nether.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org> <4F3E6456.9090507@gmail.com>
 <35D94D0B-73ED-4C79-B01C-E221DBF0AFEA@puck.nether.net>
Message-ID: <4F3E7793.2010700@gmail.com>

If you do, please share it. Thank you.

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From w3yni1 at gmail.com  Fri Feb 17 09:56:11 2012
From: w3yni1 at gmail.com (Charles Mills)
Date: Fri, 17 Feb 2012 10:56:11 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E7793.2010700@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
 <4F3E6456.9090507@gmail.com>
 <35D94D0B-73ED-4C79-B01C-E221DBF0AFEA@puck.nether.net>
 <4F3E7793.2010700@gmail.com>
Message-ID: <CAOF0KO-jQC5q2V8xOGkT5Swr9JQWQ7hv=2AzyN5Y56F+T9AgTw@mail.gmail.com>

Original poster who started thread said he would.

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

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

From jtk at cymru.com  Fri Feb 17 10:04:40 2012
From: jtk at cymru.com (John Kristoff)
Date: Fri, 17 Feb 2012 10:04:40 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3E6456.9090507@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org>
 <4F3E6456.9090507@gmail.com>
Message-ID: <20120217100440.606522cb@w520.localdomain>

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

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

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

John


From jbates at brightok.net  Fri Feb 17 10:09:38 2012
From: jbates at brightok.net (Jack Bates)
Date: Fri, 17 Feb 2012 10:09:38 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120217100440.606522cb@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <4D800C5E-9D54-4B15-AD8B-09823F572279@tzi.org> <4F3E6456.9090507@gmail.com>
 <20120217100440.606522cb@w520.localdomain>
Message-ID: <4F3E7BC2.9040108@brightok.net>

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

Greatest misconception of all.


Jack



From gbonser at seven.com  Fri Feb 17 10:10:37 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 16:10:37 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>

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

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

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



From meirea at charterschoolit.com  Fri Feb 17 10:13:06 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Fri, 17 Feb 2012 16:13:06 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3E7776.1010405@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,<4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>,
 <4F3E7776.1010405@gmail.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>

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

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

Mario Eirea

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

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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

From khelms at ispalliance.net  Fri Feb 17 10:23:59 2012
From: khelms at ispalliance.net (Scott Helms)
Date: Fri, 17 Feb 2012 11:23:59 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E6FE1.7030607@netwolves.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com>
Message-ID: <4F3E7F1F.3060504@ispalliance.net>

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

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

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



From gbonser at seven.com  Fri Feb 17 10:28:30 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 16:28:30 +0000
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0399@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: Jeff Wheeler 
> Sent: Thursday, February 16, 2012 11:30 PM
> To: NANOG
> Subject: common time-management mistake: rack & stack
> 
> Randy's P-Touch thread brings up an issue I think is worth some
> discussion.  I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack &
> stack" tasks, which I feel is a very unwise use of time and talent.
> 
> Imagine if the CFO of a bank spent a big chunk of his time filling up
> ATMs.
> Flying a sharp router jockey around to far-flung POPs to install gear
> is just as foolish.
> 
> Not only does the router jockey cost a lot more to employ than a CCNA,
> but if your senior-level talent is wasting time in airports and IBXes,
> that is time they can't be doing things CCNAs can't.
> 


I see this as a double-edged sword.   You don't want your "C" staff out in the field actually installing gear as a general course of operations as that is a great waste of their time/talent unless the "C" role is more "honorary" than anything else.  That said, you might want a senior technical person on site overseeing the installation, checking the configuration, interfacing with vendor staff, testing things, etc.  And it is good to have this senior staff member present when things go sideways as is often the case with new installations and often these issues are physical and are best solved with someone senior on site who can make decisions on the spot or carry more weight with the provider to get things done quickly. This should be someone that was involved in discussions with the vendor's rep. during the planning phase.  If you get too reliant on sending only the cage monkeys (a term I use with fondness) then what happens when problems turn up greatly depend on your corporate culture.  Do they simply stop, report the problem and wait for direction?  Is there anyone on site that has the trust of the organization to make decisions on the fly and cut through the organizational red tape? Can they authorize a configuration change to work around something unforeseen?  Having someone senior enough on site to make these decisions and carries some weight with the vendor can greatly reduce the time it takes to get a data center up and running.  Granted, he doesn't need to be there when the initial cables are being laid out but should be there once equipment starts being installed in racks and configured.  Having that experience and authority on site at the time of installation can be quite valuable.



From eugen at leitl.org  Fri Feb 17 10:36:54 2012
From: eugen at leitl.org (Eugen Leitl)
Date: Fri, 17 Feb 2012 17:36:54 +0100
Subject: Common operational misconceptions
In-Reply-To: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
References: <20120216213503.dv4tk6ot8g0k0c8w@cubmail.cc.columbia.edu>
 <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120217163654.GN7343@leitl.org>

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

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


From mike.lyon at gmail.com  Fri Feb 17 10:46:02 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Fri, 17 Feb 2012 08:46:02 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3E76C5.8010902@brightok.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net> <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com> <4F3E76C5.8010902@brightok.net>
Message-ID: <5012176673874185868@unknownmsgid>

Sent from my iPhone

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

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


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


From jkrembs at fairpoint.com  Fri Feb 17 10:55:51 2012
From: jkrembs at fairpoint.com (Krembs, Jesse)
Date: Fri, 17 Feb 2012 11:55:51 -0500
Subject: One solution -- time sink 42
In-Reply-To: <922FCBA4BB44C64D84464CC3645025B4330EE975@Tiger01.city.fredericton.nb.ca>
References: <922FCBA4BB44C64D84464CC3645025B4330EE975@Tiger01.city.fredericton.nb.ca>
Message-ID: <B395B9E849BE8942A0CD18754D3C94C0123EE6A8@0NH1EVSP01.fairpoint.com>

My crappy PT-80 has this little slot in the top built for doing just
this..it works pseudo-magically!

Jesse Krembs - Data Network Architecture & Planning
FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403
| jkrembs at fairpoint.com
www.FairPoint.com| 802.951.1519 office | 802.735.4886 cell


-----Original Message-----
From: Kierstead, Wade [mailto:wade at e-novations.ca] 
Sent: Friday, February 17, 2012 10:41 AM
To: 'Randy Bush'; 'North American Network Operators' Group'
Subject: One solution -- time sink 42


Here's a little trick that works really well for those types of labels.
Have you watched professional wrappers at Christmas time curling ribbon
with a  pair of scissors?  It works for removing the backing from the
labels as well.  Hold the backing of the label against the side of a
pair of scissors / knife / even a key with some sharper points on it,
and drag it across the edge.  This will make the ends separate a little
bit, allowing you to take hold and easily separate the pieces.

Check out this site that shows it being done with scissors if you've
never seen it 
http://www.wikihow.com/Curl-Ribbon 

Make sure it's the backing side being scraped across the scissors, not
the printed side.

Wade


-----Original Message-----
From: Randy Bush [mailto:randy at psg.com]
Sent: Thursday, February 16, 2012 4:09 PM
To: North American Network Operators' Group
Subject: time sink 42

ok, this is horribly pragmatic, but it's real.  yesterday i was in the
westin playing rack and stack for five hours.  an horrifyingly large
amount of my time was spent trying to peel apart labels made on my
portable brother label tape maker, yes peeling the backing from a little
label so remote hands could easily confirm a server they were going to
attack.

is there a trick?  is there a (not expensive) different labeling machine
or technique i should use?

randy





________________________________



This electronic mail, including any attachments, is confidential and is
for the sole use of the intended recipient and may be privileged.  Any
unauthorized distribution, copying, disclosure or review is prohibited.
Neither communication over the Internet nor disclosure to anyone other
than the intended recipient constitutes waiver of privilege.  If you are
not the intended recipient, please immediately notify the sender and
then delete this communication and any attachments from your computer
system and records without saving or forwarding it. Thank you.






_______________________________________________________________________


This e-mail message and its attachments are for the sole use of the intended recipients.  They may contain confidential information, legally privileged information or other information subject to legal restrictions.  If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.


From gary.buhrmaster at gmail.com  Fri Feb 17 11:00:16 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 17 Feb 2012 09:00:16 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3E69A7.2060008@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
Message-ID: <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>

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

"Necessity is the mother of invention"

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

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

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

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

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

Gary


From mikea at mikea.ath.cx  Fri Feb 17 11:00:50 2012
From: mikea at mikea.ath.cx (Mike Andrews)
Date: Fri, 17 Feb 2012 11:00:50 -0600
Subject: Common operational misconceptions
In-Reply-To: <5012176673874185868@unknownmsgid>
References: <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com> <4F3E76C5.8010902@brightok.net>
 <5012176673874185868@unknownmsgid>
Message-ID: <20120217170050.GA10646@mikea.ath.cx>

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

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

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


From marcelplug at gmail.com  Fri Feb 17 11:01:07 2012
From: marcelplug at gmail.com (Marcel Plug)
Date: Fri, 17 Feb 2012 12:01:07 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E7776.1010405@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
Message-ID: <CACfXSnAs1zhcg7P7eHDWf35-ag47zUvD=qoOsg-_TBGAuTi4ug@mail.gmail.com>

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

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

-Marcel

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

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


From joelja at bogus.com  Fri Feb 17 11:06:25 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 17 Feb 2012 09:06:25 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <Pine.LNX.4.64.1202171415420.14470@a84-22-97-10.cb3rob.net>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <4F3E6014.2000000@pubnix.net>
 <Pine.LNX.4.64.1202171415420.14470@a84-22-97-10.cb3rob.net>
Message-ID: <4F3E8911.9070505@bogus.com>

On 2/17/12 06:18 , Sven Olaf Kamphuis wrote:
> actually most west european countries have laws against having your
> employees lift up stuff heavier than 20 kilos :P
> 
> you generally don't have insurance on your network-dude to handle such
> things *grin* if it drops on his foot, you're screwed. (or worse, on his
> hand ;)
> 
> looking at the latest models we found units weighing 110 kilos *grin*
> i'm not lifting -that- up.
> 

http://www.serverlift.com/solutions/products/sl500x-server-lift/


From gbonser at seven.com  Fri Feb 17 11:15:58 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 17:15:58 +0000
Subject: common time-management mistake: rack & stack
In-Reply-To: <20120217144613.GB70102@ussenterprise.ufp.org>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <20120217144613.GB70102@ussenterprise.ufp.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD050F@RWC-MBX1.corp.seven.com>



> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> Sent: Friday, February 17, 2012 6:46 AM
> To: NANOG
> Subject: Re: common time-management mistake: rack & stack

> Low level employees should be apprenticed by higher level employees.
> Many of our skills are learned on the job; just like other trades
> someone with only book knowledge is darn near useless.  Not only do
> those above need to teach, but they need to supervise, and exercise
> standards and quality control.

+1  I believe that can not be stressed enough. There is also another aspect to it in that about 15% of the population of people are "abstract" thinkers and 85% are "concrete" thinkers.  The abstract thinkers are the ones who can come up with a vision in their head of how something should work as a system and then set out and build it.  Or when they are faced with a problem, can in their head envision the work around and then apply that vision on site to do things such as rewire a portion of the network in a methodical fashion with no/little downtime.  Those people are relatively rare and working with your line staff gives one an opportunity to assess the various talent sets of the people in the organization.  The abstract thinkers are the ones good at being able to design a network from scratch and the concrete thinkers are the ones who will be great maintaining that network and keeping everything documented and done according to policy.  You need both and it just so happens that you need more of one sort in just about the same proportion that you find them in the general population.  The key is to identify which people have which talents and place them where their natural abilities more closely mesh with their job requirements.  If you can do that, you can have a very powerful team.  If you place people into positions simply based on the number of years in the organization or because of holes punched in the cert ticket, you might end up with people in positions that they don't really like or aren't particularly good at doing.  The first step in building such an organization, though, is working closely with your people and attempting to identify whose natural abilities like in which direction.  Sometimes it is more about talent than training, more about nature than nurture.

> To your point, if you look at skilled trades the simpler the task the
> more likely it will fall to the "new guy".  Rack and stack is probably
> one of simplest jobs in our industry.  A two man team, one senior, one
> junior, showing up at a colo may see the junior guy doing the physical
> work, while the senior guy works out any issues with the colo provider
> brings up the interconnection to them, etc.

But at the same time, if you have a guy who might not be so sharp at troubleshooting a very complex network but is sharp as a tack when it comes to documenting things and keeping paperwork organized, that is a vital skill in the overall effort, too.  That person should be given responsibility for maintaining more of the documentation, organizing things so they are easy for other employees to find, etc. and their pay should still continue to increase as they gain wider scope across more of the organization over time.  The point is that it often takes many different sorts of skills and attempting to match people's natural talents to the requirements of the organization benefits both parties provided the individual involved doesn't see their position as a dead end.  A good person of the sort mentioned above can literally save hours of time for people doing other tasks such as troubleshooting a problem.  There is a certain synergy involved and some organizations recognize that, and some don't.  Some are better in an architectural role, some are naturally better in a sustaining role, others are better at an organizational support role and (darned) few are good at all of those tasks.  Sometimes we don't have the luxury of such specialization of roles, but some organizations do, particularly if they are in a phase of reorganization and downsizing.  One thing to look at might not only be "how good is this person in their current role" but also "would this person absolutely kick butt in a different role".

> But key to an apprenticeship is that the senior guy does some of the
> low level work some of the time, and _shows_ the junior guy how to do
> it right.  The senior guy might rack or stack a couple of boxes each
> colo they visit, and relate concepts like how the screw hole spacing
> works in the rack rails, how to plan cable management, proper labeling,
> and so on.

Actually, just having the senior person assist with some tasks such as moving/installing heavy/unwieldy gear does more than just show them how to do it right, it is actually quite an important almost sort of bonding experience between employees.  It says "I'm not allergic to work and not above doing the same job you are doing when it needs to get done, we are all important pieces of the big picture."  It can give an employee a sense that they are respected and appreciated for the job they do, even if it is fairly low on the corporate org chart.  It is still vital to the success of the overall business or they wouldn't be there to begin with.  Doing things like this telegraphs that in a tangible way without having to spew a lot of corporate propaganda.

 
> It really accomplishes much of what everyone else is talking about,
> while still being productive.  The "old hat" gets the downtime and
> catharsis of doing a simple, yet productive task.  The new guy gets to
> learn how to do the job properly.  The employer knows the work has been
> done right, as it was overseen by the old hat, and that they will have
> someone to replace him when the old hat retires.

The "old hat" still gets job satisfaction from seeing a vision come to physical life and operate as planned.  Why deprive them of that?  It can re-energize one's love of a particular carrier field and remind them why they are in that field to begin with.

> Maybe if we did more apprecenship style learning folks would still know
> how to wrap cables with wax string.  It's simple, fast, and works well.

Leo, in many trades, telecommunications being one of them, the military was one source of new people with some skills and with some hands-on experience.  As that scales back these days, it gets harder to find such people.  We don't have trade schools and we don't have apprenticeship programs like companies used to have so I agree.  People coming out of a community college or a certification program know enough to be extremely dangerous (sort of like a lieutenant with a screwdriver, the most dangerous person in the world aside from a corporal with a clipboard) and need to be mentored as they gain perspective in real world situations.  I completely agree that we should be looking more at our employees in the longer term as a nurturing process and identifying where their natural interests and abilities can benefit both sides of the equation.  Having that interaction with the senior staff is vital.  And that senior staff member should not only be explaining WHAT he is doing, but WHY he is doing it that way.
 


From randy at psg.com  Fri Feb 17 11:17:03 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 17 Feb 2012 09:17:03 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
References: <201202170817.IAA09390@sunf10.rd.bbc.co.uk>
Message-ID: <m2aa4h752o.wl%randy@psg.com>

would have been good to know to whom you were replying, not in To: or in
pre-quote text.

>> I have noticed that a lot of very well-paid, sometimes
>> well-qualified, networking folks spend some of their time on "rack &
>> stack" tasks, which I feel is a very unwise use of time and talent.
> 
> It's not a waste, it's therapeutic, breaks the monotony of a desk
> job, you get a bit of exercise. Doing something mindless can help
> clear your thoughts, engineering yoga.
> 
>> Imagine if the CFO of a bank spent a big chunk of his time filling up
>> ATMs.
> 
> That'd be a good idea, it's too easy to become remote from reality.
> obviously you need the right balance - s/big//

i configure routers, admin servers, and occasionally rack and stack in
my own research racks [0].  aside from giving me a base in reality
instead of all research papers and power point (a major benefit), it's
like housework or doing the dishes, shut up and do your part.

it's also damned useful to maintain layer zero skills.  once upon a
time, when i was playing at vp eng, a london routing hub was supposed to
be turned up.  the equipment sat in co-lo receiving for weeks, and no
respose from the london techs (i am sure they had ccnas, whetever the
hell that is).  so i grabbed my toolkit and got on a plane and walked
into redbus and started turning it all up.  the local techs appeared
pretty damed quickly and started doing their jobs.  of course, a few
weeks later they were told to get jobs elsewhere.

maintain your skills, you may need them again some day.

randy

---

[0] - deep thanks to (in alpha order) cisco, equinix, google, juniper,
      nsf, and others for contributions.


From sven at cb3rob.net  Fri Feb 17 11:16:31 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 17:16:31 +0000 (UTC)
Subject: Common operational misconceptions
In-Reply-To: <20120217163654.GN7343@leitl.org>
References: <20120216213503.dv4tk6ot8g0k0c8w@cubmail.cc.columbia.edu>
 <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
 <20120217163654.GN7343@leitl.org>
Message-ID: <Pine.LNX.4.64.1202171715220.803@a84-22-97-10.cb3rob.net>

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

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

On Fri, 17 Feb 2012, Eugen Leitl wrote:

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


From josmon at rigozsaurus.com  Fri Feb 17 11:25:45 2012
From: josmon at rigozsaurus.com (John Osmon)
Date: Fri, 17 Feb 2012 10:25:45 -0700
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
References: <4F3DA88F.1040700@paulgraydon.co.uk>
 <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120217172545.GA18459@jeeves.rigozsaurus.com>

On Fri, Feb 17, 2012 at 10:30:33AM -0500, Jay Ashworth wrote:
> ----- Original Message -----
> > From: "Paul Graydon" <paul at paulgraydon.co.uk>
> 
> > Anecdotally, I had an interview years ago for a small-ish futures
> > trading company based in London. The interviewer had to pause the
> > interview part way through whilst he investigated a 10ms latency spike
> > that the traders were noticing on a short point-to-point fiber link to
> > the London Stock Exchange. He commented that the traders were far
> > better at 'feeling' when an connection was showing even a trace of lag
> > compared to normal than anything he'd set up by way of monitoring (not
> > sure how good his monitoring was, though.)
> 
> This was my experience in a callcenter as well; network type problem reports
> always came in from the floor managers before Nagios came forth with an 
> opinion.

When I used to run an ISP network, our NOC always talked about "that
porn guy" who would call the *exact* *momment* the NNTP server had any
type of stutter...

I guess there's always a canary for the coal mine -- eh?


From nanog at thedaileyplanet.com  Fri Feb 17 11:26:12 2012
From: nanog at thedaileyplanet.com (Chad Dailey)
Date: Fri, 17 Feb 2012 11:26:12 -0600
Subject: common time-management mistake: rack & stack
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD050F@RWC-MBX1.corp.seven.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <20120217144613.GB70102@ussenterprise.ufp.org>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD050F@RWC-MBX1.corp.seven.com>
Message-ID: <CAFEuDREP58rXeV2aELQNSj3CZ4Tp1UEeUT7O9_Uha7PtxkZk+A@mail.gmail.com>

On Fri, Feb 17, 2012 at 11:15 AM, George Bonser <gbonser at seven.com> wrote:

>
>
> > -----Original Message-----
> > From: Leo Bicknell [mailto:bicknell at ufp.org]
> > Sent: Friday, February 17, 2012 6:46 AM
> > To: NANOG
> > Subject: Re: common time-management mistake: rack & stack
>
> > Low level employees should be apprenticed by higher level employees.
> > Many of our skills are learned on the job; just like other trades
> > someone with only book knowledge is darn near useless.  Not only do
> > those above need to teach, but they need to supervise, and exercise
> > standards and quality control.
>
> +1  I believe that can not be stressed enough. There is also another
> aspect to it in that about 15% of the population of people are "abstract"
> thinkers and 85% are "concrete" thinkers.  The abstract thinkers are the
> ones who can come up with a vision in their head of how something should
> work as a system and then set out and build it.  Or when they are faced
> with a problem, can in their head envision the work around and then apply
> that vision on site to do things such as rewire a portion of the network in
> a methodical fashion with no/little downtime.  Those people are relatively
> rare and working with your line staff gives one an opportunity to assess
> the various talent sets of the people in the organization.  The abstract
> thinkers are the ones good at being able to design a network from scratch
> and the concrete thinkers are the ones who will be great maintaining that
> network and keeping everything documented and done according to policy.
>  You need both and it just so happens that you need more of one sort in
> just about the same proportion that you find them in the general
> population.  The key is to identify which people have which talents and
> place them where their natural abilities more closely mesh with their job
> requirements.  If you can do that, you can have a very powerful team.  If
> you place people into positions simply based on the number of years in the
> organization or because of holes punched in the cert ticket, you might end
> up with people in positions that they don't really like or aren't
> particularly good at doing.  The first step in building such an
> organization, though, is working closely with your people and attempting to
> identify whose natural abilities like in which direction.  Sometimes it is
> more about talent than training, more about nature than nurture.
>
> > To your point, if you look at skilled trades the simpler the task the
> > more likely it will fall to the "new guy".  Rack and stack is probably
> > one of simplest jobs in our industry.  A two man team, one senior, one
> > junior, showing up at a colo may see the junior guy doing the physical
> > work, while the senior guy works out any issues with the colo provider
> > brings up the interconnection to them, etc.
>
> But at the same time, if you have a guy who might not be so sharp at
> troubleshooting a very complex network but is sharp as a tack when it comes
> to documenting things and keeping paperwork organized, that is a vital
> skill in the overall effort, too.  That person should be given
> responsibility for maintaining more of the documentation, organizing things
> so they are easy for other employees to find, etc. and their pay should
> still continue to increase as they gain wider scope across more of the
> organization over time.  The point is that it often takes many different
> sorts of skills and attempting to match people's natural talents to the
> requirements of the organization benefits both parties provided the
> individual involved doesn't see their position as a dead end.  A good
> person of the sort mentioned above can literally save hours of time for
> people doing other tasks such as troubleshooting a problem.  There is a
> certain synergy involved and some organizations recognize that, and some
> don't.  Some are better in an architectural role, some are naturally better
> in a sustaining role, others are better at an organizational support role
> and (darned) few are good at all of those tasks.  Sometimes we don't have
> the luxury of such specialization of roles, but some organizations do,
> particularly if they are in a phase of reorganization and downsizing.  One
> thing to look at might not only be "how good is this person in their
> current role" but also "would this person absolutely kick butt in a
> different role".
>
> > But key to an apprenticeship is that the senior guy does some of the
> > low level work some of the time, and _shows_ the junior guy how to do
> > it right.  The senior guy might rack or stack a couple of boxes each
> > colo they visit, and relate concepts like how the screw hole spacing
> > works in the rack rails, how to plan cable management, proper labeling,
> > and so on.
>
> Actually, just having the senior person assist with some tasks such as
> moving/installing heavy/unwieldy gear does more than just show them how to
> do it right, it is actually quite an important almost sort of bonding
> experience between employees.  It says "I'm not allergic to work and not
> above doing the same job you are doing when it needs to get done, we are
> all important pieces of the big picture."  It can give an employee a sense
> that they are respected and appreciated for the job they do, even if it is
> fairly low on the corporate org chart.  It is still vital to the success of
> the overall business or they wouldn't be there to begin with.  Doing things
> like this telegraphs that in a tangible way without having to spew a lot of
> corporate propaganda.
>
>
> > It really accomplishes much of what everyone else is talking about,
> > while still being productive.  The "old hat" gets the downtime and
> > catharsis of doing a simple, yet productive task.  The new guy gets to
> > learn how to do the job properly.  The employer knows the work has been
> > done right, as it was overseen by the old hat, and that they will have
> > someone to replace him when the old hat retires.
>
> The "old hat" still gets job satisfaction from seeing a vision come to
> physical life and operate as planned.  Why deprive them of that?  It can
> re-energize one's love of a particular carrier field and remind them why
> they are in that field to begin with.
>
> > Maybe if we did more apprecenship style learning folks would still know
> > how to wrap cables with wax string.  It's simple, fast, and works well.
>
> Leo, in many trades, telecommunications being one of them, the military
> was one source of new people with some skills and with some hands-on
> experience.  As that scales back these days, it gets harder to find such
> people.  We don't have trade schools and we don't have apprenticeship
> programs like companies used to have so I agree.  People coming out of a
> community college or a certification program know enough to be extremely
> dangerous (sort of like a lieutenant with a screwdriver, the most dangerous
> person in the world aside from a corporal with a clipboard) and need to be
> mentored as they gain perspective in real world situations.  I completely
> agree that we should be looking more at our employees in the longer term as
> a nurturing process and identifying where their natural interests and
> abilities can benefit both sides of the equation.  Having that interaction
> with the senior staff is vital.  And that senior staff member should not
> only be explaining WHAT he is doing, but WHY he is doing it that way.
>
>
>
Knowledge transfer should also include the very important WHY NOT to do
something a certain way.  This part is often left out.  Considering that
most bit-twiddler tasks can be performed a multitude of ways, both sides of
the argument should be presented.  Perhaps this is obvious to all on the
list, but it's certainly not to junior staff.

From gbonser at seven.com  Fri Feb 17 11:31:19 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 17:31:19 +0000
Subject: Common operational misconceptions
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C053D2E@CSIT-SRV-MBX-01.charterschoolit.local>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>,
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <C95B38A68C80744C8B371447DB6EE98C053D2E@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD05E1@RWC-MBX1.corp.seven.com>

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

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

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

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



From lists at quux.de  Fri Feb 17 11:35:27 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 18:35:27 +0100
Subject: Common operational misconceptions
In-Reply-To: <CAKwRnJMZAxpS3r1HYLB0RYNbVfJqH6U95MaSi2L=K2g+9vktqQ@mail.gmail.com>
 (Mark Grigsby's message of "Wed, 15 Feb 2012 13:26:28 -0800")
References: <20120215144715.18e65a55@w520.localdomain>
 <008501ccec26$47e8c010$d7ba4030$@chipps.com>
 <CAKwRnJMZAxpS3r1HYLB0RYNbVfJqH6U95MaSi2L=K2g+9vktqQ@mail.gmail.com>
Message-ID: <87sji9bbxc.fsf@pc8.berlin.quux.de>

Mark Grigsby <mark at pcinw.net> writes:

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

Once upon a time: 

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

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


From josmon at rigozsaurus.com  Fri Feb 17 11:33:56 2012
From: josmon at rigozsaurus.com (John Osmon)
Date: Fri, 17 Feb 2012 10:33:56 -0700
Subject: Common operational misconceptions
In-Reply-To: <4F3E6FE1.7030607@netwolves.com>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com>
Message-ID: <20120217173356.GB18459@jeeves.rigozsaurus.com>

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

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

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



From lists at quux.de  Fri Feb 17 11:37:53 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 18:37:53 +0100
Subject: Common operational misconceptions
In-Reply-To: <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se> (Mathias
 Wolkert's message of "Wed, 15 Feb 2012 22:59:37 +0100")
References: <20120215144715.18e65a55@w520.localdomain>
 <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se>
Message-ID: <87obsxbbta.fsf@pc8.berlin.quux.de>

Mathias Wolkert <tias at netnod.se> writes:

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

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

SCNR

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


From gbonser at seven.com  Fri Feb 17 11:36:28 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 17:36:28 +0000
Subject: Common operational misconceptions
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184EFFA@embgsr24.pateam.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <51C66083768C2949A7EB14910C78B0170184EFFA@embgsr24.pateam.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0641@RWC-MBX1.corp.seven.com>

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

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




From lists at quux.de  Fri Feb 17 11:43:50 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 18:43:50 +0100
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 (Jeff Wheeler's message of "Fri, 17 Feb 2012 02:29:36 -0500")
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <87k43lbbjd.fsf@pc8.berlin.quux.de>

Jeff Wheeler <jsw at inconcepts.biz> writes:

> With apologies to Randy, let the CCNAs fight with label makers.

Yeah. And you need do be at last CCNP to switch a module in a router. 

Had this request last year. I first thought that some troubleshooting /
configuration was involved but it was just replacing a module.

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


From nathan at atlasnetworks.us  Fri Feb 17 11:26:08 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 17 Feb 2012 17:26:08 +0000
Subject: Spam from Telx
In-Reply-To: <4F3E5D8D.60403@foobar.org>
References: <3CC3117A8EF6FF439254141C02BF6E141801F457@mbx027-e1-nj-2.exch027.domain.local>
 <4F3E5D8D.60403@foobar.org>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B8CEE@ex-mb-2.corp.atlasnetworks.us>

> So, anyone else get spammed by Telx after posting to nanog?
> 
> This is massively unprofessional.
> 
> Nick
 
Yep.  I shot a complaint to customerservice at telx.com.  Assuming Mr. Fitzpatrick does not control that portion of the company, it may be of value for other recipients of his spam to do the same.

Nathan Eisenberg


From sven at cb3rob.net  Fri Feb 17 11:41:52 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 17:41:52 +0000 (UTC)
Subject: Common operational misconceptions
In-Reply-To: <87obsxbbta.fsf@pc8.berlin.quux.de>
References: <20120215144715.18e65a55@w520.localdomain>
 <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se>
 <87obsxbbta.fsf@pc8.berlin.quux.de>
Message-ID: <Pine.LNX.4.64.1202171740420.803@a84-22-97-10.cb3rob.net>


On Fri, 17 Feb 2012, Jens Link wrote:

> Mathias Wolkert <tias at netnod.se> writes:
>
>> Autoneg. The old timers that don't trust it after a few decades of
>> decent code. Or those that lock one side and expect the other to adjust
>> to that.

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

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

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


From jjones at danrj.com  Fri Feb 17 11:47:02 2012
From: jjones at danrj.com (Jerry Jones)
Date: Fri, 17 Feb 2012 11:47:02 -0600
Subject: Common operational misconceptions
In-Reply-To: <20120217173356.GB18459@jeeves.rigozsaurus.com>
References: <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com>
 <20120217173356.GB18459@jeeves.rigozsaurus.com>
Message-ID: <589C6F34-B602-4343-912C-FD127A18D72B@danrj.com>


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

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

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

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

Quote I have hear over the years


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

From gbonser at seven.com  Fri Feb 17 11:51:27 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 17:51:27 +0000
Subject: Common operational misconceptions
In-Reply-To: <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD06F1@RWC-MBX1.corp.seven.com>

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

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

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



From gary.buhrmaster at gmail.com  Fri Feb 17 11:54:13 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 17 Feb 2012 09:54:13 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <CAMfXtQxgqhawTT8-fNrURXCZsXL7RTukmfc1a2MrWab1dm-HVg@mail.gmail.com>

On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler <jsw at inconcepts.biz> wrote:
...
> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
> Flying a sharp router jockey around to far-flung POPs to install gear
> is just as foolish.

There is a theory of management that says a good manager
needs to know nothing about the staff or the jobs he is managing,
because his job is about returning profit to the shareholder,
and not about what the company does.  AFAIK, these
theories are made in the academic halls of the business
schools, which churn out MBAs, and, self-selected group
that they are, believe in (more) managers, and (more)
powerpoint business plans, and (more) theory.

I happen to come from a different background, and believe
that it has value to understand what the people who are
working for you actually do.  That does not mean the CEO
should spend all day delivering the mail (or flipping burgers),
but she had better have done it a few times, and it is a good
idea to do it from time to time to see what has changed.
It keeps the manager grounded with the reality.

(I have been told that the reason that the commanders
in the Army are reluctant to send their people to battle
is that they have experienced it, and know it is hell.
And the reason the people will go to hell for their
commander is that the commander has the moral
authority of having done it, experienced it, know
that they are asking a lot, but it is for the common
good.  People will follow a leader who has been there,
done that, and not so much when it is just an academic
business plan on a powerpoint slide.)


From jeff-kell at utc.edu  Fri Feb 17 11:55:01 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 17 Feb 2012 12:55:01 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
Message-ID: <4F3E9475.1050106@utc.edu>

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

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

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

Jeff


From owen at delong.com  Fri Feb 17 11:55:04 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 09:55:04 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <292C237E-219A-4F7C-9BC0-14F47B878C2B@delong.com>


On Feb 16, 2012, at 11:29 PM, Jeff Wheeler wrote:

> Randy's P-Touch thread brings up an issue I think is worth some
> discussion.  I have noticed that a lot of very well-paid, sometimes
> well-qualified, networking folks spend some of their time on "rack &
> stack" tasks, which I feel is a very unwise use of time and talent.
> 
> Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs.
> Flying a sharp router jockey around to far-flung POPs to install gear
> is just as foolish.
> 
> Not only does the router jockey cost a lot more to employ than a CCNA,
> but if your senior-level talent is wasting time in airports and IBXes,
> that is time they can't be doing things CCNAs can't.
> 
> I was once advising a client on a transit purchasing decision, and a
> fairly-large, now-defunct tier-2 ISP was being considered.  We needed
> a few questions about their IPv6 plans answered before we were
> comfortable.  The CTO of that org was the only guy who was able to
> answer these questions.  After waiting four days for him to return our
> message, he reached out to us from an airplane phone, telling us that
> he had been busy racking new routers in several east-coast cities (his
> office was not east-coast) and that's why he hadn't got back to us
> yet.
> 
> As you might imagine, the client quickly realized that they didn't
> want to deal with a vendor whose CTO spent his time doing rack & stack
> instead of engineering his network or engaging with customers.  If he
> had simply said he was on vacation, we would never have known how
> poorly the senior people at that ISP managed their time.
> 
> With apologies to Randy, let the CCNAs fight with label makers.
> -- 
> Jeff S Wheeler <jsw at inconcepts.biz>
> Sr Network Operator  /  Innovative Network Concepts

With all due respect, Jeff, I think you are missing several factors that come into the human equation beyond merely the most efficient use of a particular person's time.

I would go stark-raving bonkers trapped in a cubicle doing only things that CCNAs can't if I didn't get the occasional break to go out and play with real hardware in the field. Most of the well-paid well-qualified networking folks I know are the same way. 

I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate.

On the surface, it might seem an inefficient use of financial/human resources, but, I think that there is value to time in the field that doesn't necessarily show up directly on the balance sheet.

Admittedly, in my current position, I'm no longer in an operational role for the most part, but, I'm even more out in the field and spending more time in airports.

Owen



From rodrick.brown at gmail.com  Fri Feb 17 12:01:36 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Fri, 17 Feb 2012 13:01:36 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
Message-ID: <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>

On Feb 17, 2012, at 10:30 AM, Jay Ashworth <jra at baylink.com> wrote:

> ----- Original Message -----
>> From: "Paul Graydon" <paul at paulgraydon.co.uk>
> 
>> Anecdotally, I had an interview years ago for a small-ish futures
>> trading company based in London. The interviewer had to pause the
>> interview part way through whilst he investigated a 10ms latency spike
>> that the traders were noticing on a short point-to-point fiber link to
>> the London Stock Exchange. He commented that the traders were far
>> better at 'feeling' when an connection was showing even a trace of lag
>> compared to normal than anything he'd set up by way of monitoring (not
>> sure how good his monitoring was, though.)
> 
> This was my experience in a callcenter as well; network type problem reports
> always came in from the floor managers before Nagios came forth with an 
> opinion.

This has nothing to do with a gut feeling or instinct. Trading companies today monitor P&L near realtime and traders will begin to experience low fill rates or worse be rejected by trading counter parties when prices are too far off or out of the money. The longer a system takes to responds to market quotes the lower fills rates they begin to notice and higher execution costs. Trades today in the equity markets must be within the national best bid, best offer price range or companies can be fined by the SEC which is why latency an jitter can be problematic in financial networks. 
 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 


From jared at puck.nether.net  Fri Feb 17 12:04:41 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Fri, 17 Feb 2012 13:04:41 -0500
Subject: Common operational misconceptions
In-Reply-To: <Pine.LNX.4.64.1202171740420.803@a84-22-97-10.cb3rob.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <21EB6874-EC26-4BFF-805B-434D6C83F0D4@netnod.se>
 <87obsxbbta.fsf@pc8.berlin.quux.de>
 <Pine.LNX.4.64.1202171740420.803@a84-22-97-10.cb3rob.net>
Message-ID: <27E70DD9-FED2-4AA3-8E5C-83680B1D3633@puck.nether.net>

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

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

Jared Mauch

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

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


From gbonser at seven.com  Fri Feb 17 12:06:52 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 18:06:52 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3E9475.1050106@utc.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
 <4F3E9475.1050106@utc.edu>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>

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

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

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



From jra at baylink.com  Fri Feb 17 12:12:09 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:12:09 -0500 (EST)
Subject: Anonymous planning a root-servers party
In-Reply-To: <Pine.LNX.4.64.1202171406410.14470@a84-22-97-10.cb3rob.net>
Message-ID: <7503967.3409.1329502329909.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Sven Olaf Kamphuis" <sven at cb3rob.net>

> the internet treats censorship as damage and routes around it,
> remember that one :P

Not only do we remember it, I believe John's on this list.

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


From tony at swalter.com  Fri Feb 17 12:15:09 2012
From: tony at swalter.com (Tony Patti)
Date: Fri, 17 Feb 2012 13:15:09 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <CAMfXtQxgqhawTT8-fNrURXCZsXL7RTukmfc1a2MrWab1dm-HVg@mail.gmail.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <CAMfXtQxgqhawTT8-fNrURXCZsXL7RTukmfc1a2MrWab1dm-HVg@mail.gmail.com>
Message-ID: <035101cceda0$157d3860$4077a920$@com>



> From: Gary Buhrmaster [mailto:gary.buhrmaster at gmail.com] 
> Sent: Friday, February 17, 2012 12:54 PM
> To: Jeff Wheeler
> Cc: NANOG
> Subject: Re: common time-management mistake: rack & stack
> On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler <jsw at inconcepts.biz> wrote:
> ...
> > Imagine if the CFO of a bank spent a big chunk of his time filling up
ATMs.
> > Flying a sharp router jockey around to far-flung POPs to install gear 
> > is just as foolish.
> 
> There is a theory of management that says a good manager needs to know
nothing about the staff or the jobs he is managing, because his job is about
returning profit to the shareholder, 
> and not about what the company does.  AFAIK, these theories are made in
the academic halls of the business schools, 
> which churn out MBAs, and, self-selected group that they are, believe in
(more) managers, and (more) powerpoint business plans, and (more) theory.
>
> I happen to come from a different background, and believe that it has
value to understand what the people who are working for you actually do.  
> That does not mean the CEO should spend all day delivering the mail (or
flipping burgers), but she had better have done it a few times, 
> and it is a good idea to do it from time to time to see what has changed.
> It keeps the manager grounded with the reality.
>  (I have been told that the reason that the commanders in the Army are
reluctant to send their people to battle is that they have experienced it,
and know it is hell.
> And the reason the people will go to hell for their commander is that the
commander has the moral authority of having done it, experienced it, 
> know that they are asking a lot, but it is for the common good.  People
will follow a leader who has been there, done that, 
> and not so much when it is just an academic business plan on a powerpoint
slide.)

+1 for Gary's comment.

That is the large difference between LEADING and MANAGING.

In the context of the military scenario above, Grace Hopper comes to mind
because of her nanoseconds etc
"In her retirement speech, instead of dwelling on the past, she talked about
moving toward the future, stressing the importance of leadership."
http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm
I was lucky enough to have heard her speak once at an ACM event.

Tony Patti
CIO
S. Walter Packaging Corp.




From jra at baylink.com  Fri Feb 17 12:16:05 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:16:05 -0500 (EST)
Subject: common time-management mistake: rack & stack
In-Reply-To: <20120217144613.GB70102@ussenterprise.ufp.org>
Message-ID: <8922420.3411.1329502565104.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Leo Bicknell" <bicknell at ufp.org>

> Maybe if we did more apprecenship style learning folks would still
> know how to wrap cables with wax string. It's simple, fast, and works well.

Cue the obligatory cabling porn thread.

Cheers,
-- jr 'and aren't all the old Bell guys dead now?' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From bicknell at ufp.org  Fri Feb 17 12:25:11 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 10:25:11 -0800
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>
References: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
 <4F3E9475.1050106@utc.edu>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>
Message-ID: <20120217182511.GA95638@ussenterprise.ufp.org>

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

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

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/f0a23244/attachment.bin>

From jra at baylink.com  Fri Feb 17 12:26:51 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:26:51 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <20120217170050.GA10646@mikea.ath.cx>
Message-ID: <10579285.3413.1329503211140.JavaMail.root@benjamin.baylink.com>

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

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

"The problem's leaving here fine!"

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


From ralph.brandt at pateam.com  Fri Feb 17 12:28:04 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Fri, 17 Feb 2012 13:28:04 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E7F1F.3060504@ispalliance.net>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E6FE1.7030607@netwolves.com> <4F3E7F1F.3060504@ispalliance.net>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F01D@embgsr24.pateam.com>

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



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

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

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

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

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




From lists at quux.de  Fri Feb 17 12:35:13 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 19:35:13 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120217182511.GA95638@ussenterprise.ufp.org> (Leo Bicknell's
 message of "Fri, 17 Feb 2012 10:25:11 -0800")
References: <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
 <4F3E9475.1050106@utc.edu>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>
 <20120217182511.GA95638@ussenterprise.ufp.org>
Message-ID: <8739a9b95q.fsf@pc8.berlin.quux.de>

Leo Bicknell <bicknell at ufp.org> writes:

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

Hmm.....

http://gearomat.com/

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


From paul at paulgraydon.co.uk  Fri Feb 17 12:32:34 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Fri, 17 Feb 2012 08:32:34 -1000
Subject: Common operational misconceptions
In-Reply-To: <20120217142927.GA70102@ussenterprise.ufp.org>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
Message-ID: <4F3E9D42.3060708@paulgraydon.co.uk>

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

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

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

Paul


From jra at baylink.com  Fri Feb 17 12:35:15 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:35:15 -0500 (EST)
Subject: WW: Colo Vending Machine
Message-ID: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>

Please post your top 3 favorite components/parts you'd like to see in a
vending machine at your colo; please be as specific as possible; don't 
let vendor specificity scare you off.

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


From Valdis.Kletnieks at vt.edu  Fri Feb 17 12:36:35 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 17 Feb 2012 13:36:35 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: Your message of "Fri, 17 Feb 2012 13:01:36 EST."
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
Message-ID: <37473.1329503795@turing-police.cc.vt.edu>

On Fri, 17 Feb 2012 13:01:36 EST, Rodrick Brown said:
> Trades today in the equity markets must be within the national best bid, best
> offer price range or companies can be fined by the SEC which is why latency
> an jitter can be problematic in financial networks.

Am I the only one who thinks that if network jitter can make you fall outside
the acceptable price window, maybe, just maybe,  the market is just too damned
volatile for its own good?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/dcb08887/attachment.bin>

From jof at thejof.com  Fri Feb 17 12:40:01 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Fri, 17 Feb 2012 10:40:01 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>

On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth <jra at baylink.com> wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

This is a riot! I'd love to have something like this at facilities I'm in.
Some useful stuff that comes to mind:
 - Rack screws of various common sizes and threadings
 - SFPs, GBICs, etc.
 - Rollover cable / DE-9->8P8P adapter
 - Screwdrivers
 - Cross-over Ethernet, patch cables
 - zip ties, velcro tape, etc.
 - Label tape

Cheers,
jof


From tperrine at scea.com  Fri Feb 17 12:40:17 2012
From: tperrine at scea.com (Tom Perrine)
Date: Fri, 17 Feb 2012 10:40:17 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F3E9F11.70807@scea.com>

On 2/17/12 10:35 AM, Jay Ashworth wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.

Clue in a Can - I prefer the 8 oz size, but sometimes it would be nice to get the 12 oz bottle.

--tep




From owen at delong.com  Fri Feb 17 12:35:53 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 10:35:53 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3E69A7.2060008@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
Message-ID: <B79A92E9-C1EE-4ED6-AC2E-E704B98E446F@delong.com>


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

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

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

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

Owen



From streiner at cluebyfour.org  Fri Feb 17 12:41:25 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 13:41:25 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <Pine.LNX.4.64.1202171338430.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Jay Ashworth wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

1. 1GB+ USB sticks
2. Cat5E patch cords in various lengths
3. Rack screws/cage nuts that are appropriate for the types of cabinets in 
that facility

jms


From eric-list at truenet.com  Fri Feb 17 12:43:35 2012
From: eric-list at truenet.com (Eric Tykwinski)
Date: Fri, 17 Feb 2012 13:43:35 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
Message-ID: <022801cceda4$11377b90$33a672b0$@truenet.com>

+1 for GBICs, SFPs 

I don't know if it's just me, but I have the worst luck with them.

-----Original Message-----
From: Jonathan Lassoff [mailto:jof at thejof.com] 
Sent: Friday, February 17, 2012 1:40 PM
To: Jay Ashworth
Cc: NANOG
Subject: Re: WW: Colo Vending Machine

On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth <jra at baylink.com> wrote:
> Please post your top 3 favorite components/parts you'd like to see in 
> a vending machine at your colo; please be as specific as possible; 
> don't let vendor specificity scare you off.

This is a riot! I'd love to have something like this at facilities I'm in.
Some useful stuff that comes to mind:
 - Rack screws of various common sizes and threadings
 - SFPs, GBICs, etc.
 - Rollover cable / DE-9->8P8P adapter
 - Screwdrivers
 - Cross-over Ethernet, patch cables
 - zip ties, velcro tape, etc.
 - Label tape

Cheers,
jof





From chipps at chipps.com  Fri Feb 17 12:43:24 2012
From: chipps at chipps.com (Kenneth M. Chipps Ph.D.)
Date: Fri, 17 Feb 2012 12:43:24 -0600
Subject: Common operational misconceptions
In-Reply-To: <4F3E9D42.3060708@paulgraydon.co.uk>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
Message-ID: <031901cceda4$081057d0$18310770$@chipps.com>

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

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

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

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

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

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

Paul





From mikea at mikea.ath.cx  Fri Feb 17 12:44:01 2012
From: mikea at mikea.ath.cx (Mike Andrews)
Date: Fri, 17 Feb 2012 12:44:01 -0600
Subject: common time-management mistake: rack & stack
In-Reply-To: <035101cceda0$157d3860$4077a920$@com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <CAMfXtQxgqhawTT8-fNrURXCZsXL7RTukmfc1a2MrWab1dm-HVg@mail.gmail.com>
 <035101cceda0$157d3860$4077a920$@com>
Message-ID: <20120217184401.GC10646@mikea.ath.cx>

On Fri, Feb 17, 2012 at 01:15:09PM -0500, Tony Patti wrote:

> In the context of the military scenario above, Grace Hopper comes to mind
> because of her nanoseconds etc
> "In her retirement speech, instead of dwelling on the past, she talked about
> moving toward the future, stressing the importance of leadership."
> http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm
> I was lucky enough to have heard her speak once at an ACM event.

I still have my nanosecond. Did she hand them out to the crowd there?

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


From jra at baylink.com  Fri Feb 17 12:44:57 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:44:57 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <24634832.3435.1329504297384.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

And I'll start: 

1) Cat 5e molded, hooded patch cables, 7 ft, in blue, green and red
2) Power cords: C19 to L6-15, C19 to C20, C13 to C20 (latter 2 for 208V PDUs)
    (If you don't have your own C13 to L6-15 cords, you're in the wrong biz)
3) Multimode patch cables, LC-duplex, 15ft

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


From sven at cb3rob.net  Fri Feb 17 12:46:13 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 18:46:13 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <Pine.LNX.4.64.1202171841010.32438@a84-22-97-10.cb3rob.net>

rackmount screws, nuts, bolts, rubber rings for both M6 and whatever other 
stuff ppl use (that smaller size is common too ;)

preferably in both black and silver color.

19" trays
19" electricity socket bars

IEC power cables.
ethernet patch cables 3 meter

screwdriver sets

and whatever other stuff people generally forget and then decide to steal 
out of our racks so we have to drive to the home depot kinda thing again.
(don't ask ;)

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Jay Ashworth wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>


From jra at baylink.com  Fri Feb 17 12:46:56 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:46:56 -0500 (EST)
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <37473.1329503795@turing-police.cc.vt.edu>
Message-ID: <2788368.3441.1329504416406.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Valdis Kletnieks" <Valdis.Kletnieks at vt.edu>

> On Fri, 17 Feb 2012 13:01:36 EST, Rodrick Brown said:
> > Trades today in the equity markets must be within the national best
> > bid, best
> > offer price range or companies can be fined by the SEC which is why
> > latency
> > an jitter can be problematic in financial networks.
> 
> Am I the only one who thinks that if network jitter can make you fall
> outside
> the acceptable price window, maybe, just maybe, the market is just too
> damned
> volatile for its own good?

You are not the only one.

Cheers,
-- jr 'hold any purchased stock for a minimum of 7 days' a
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From trelane at trelane.net  Fri Feb 17 12:47:42 2012
From: trelane at trelane.net (Andrew D Kirch)
Date: Fri, 17 Feb 2012 13:47:42 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F3EA0CE.9000701@trelane.net>

On 2/17/2012 1:35 PM, Jay Ashworth wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
console cables (cisco juniper adtran)
1' extension cords (for the few devices that I have requiring DC power 
packs)
label tape
rack screws
zip ties
AC cords
grounding ribbon
replacement bits for phillips, and torx


From jra at baylink.com  Fri Feb 17 12:48:37 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 13:48:37 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <24634832.3435.1329504297384.JavaMail.root@benjamin.baylink.com>
Message-ID: <26821809.3449.1329504517746.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> 2) Power cords: C19 to L6-15, C19 to C20, C13 to C20 (latter 2 for
> 208V PDUs)

Oh: "in black and red"

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


From sparctacus at gmail.com  Fri Feb 17 12:49:32 2012
From: sparctacus at gmail.com (Bryan Irvine)
Date: Fri, 17 Feb 2012 10:49:32 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
Message-ID: <CAG367gbbQT00SiaMpANxq6SM44KpCQv6MHh5uUgOjgrNkLkJcA@mail.gmail.com>

On Fri, Feb 17, 2012 at 10:40 AM, Jonathan Lassoff <jof at thejof.com> wrote:
> On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth <jra at baylink.com> wrote:
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>
> This is a riot! I'd love to have something like this at facilities I'm in.
> Some useful stuff that comes to mind:
> ?- Rack screws of various common sizes and threadings
> ?- SFPs, GBICs, etc.
> ?- Rollover cable / DE-9->8P8P adapter
> ?- Screwdrivers
> ?- Cross-over Ethernet, patch cables
> ?- zip ties, velcro tape, etc.
> ?- Label tape

HAHA!  Great list.  Add to this

Cable Tester
Thumb Drive
RJ45s
RJ45 crimper
Box knife
LED flashlights
Blank CDs/DVDs


From leigh.porter at ukbroadband.com  Fri Feb 17 12:52:28 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 17 Feb 2012 18:52:28 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>


On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.

Pizza, condoms and headache tablets.

-- 
Leigh



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


From owen at delong.com  Fri Feb 17 12:45:26 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 10:45:26 -0800
Subject: Common operational misconceptions
In-Reply-To: <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
Message-ID: <4C692CFB-BD67-4E73-B332-3F3F7A2F2C64@delong.com>


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

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

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

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

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

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

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

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

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

Owen



From owen at delong.com  Fri Feb 17 12:49:13 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 10:49:13 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3E7776.1010405@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
Message-ID: <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>

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

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

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

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



From erik.soosalu at calyxinc.com  Fri Feb 17 12:50:55 2012
From: erik.soosalu at calyxinc.com (Erik Soosalu)
Date: Fri, 17 Feb 2012 13:50:55 -0500
Subject: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <0B224A2FE01CC54C860290D42474BF60052D54BB@exchange.nff.local>

1) Patch cables every 1' length from 3-10'
2) Velcro wrap
3) Tools (screwdrivers, etc)

And since the racks usually come with the cage nuts, maybe the colo should just provide them.


Thanks,
Erik 

-----Original Message-----
From: Jay Ashworth [mailto:jra at baylink.com] 
Sent: Friday, February 17, 2012 1:35 PM
To: NANOG
Subject: WW: Colo Vending Machine

Please post your top 3 favorite components/parts you'd like to see in a
vending machine at your colo; please be as specific as possible; don't 
let vendor specificity scare you off.

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



From bicknell at ufp.org  Fri Feb 17 12:54:08 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 10:54:08 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <37473.1329503795@turing-police.cc.vt.edu>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
 <37473.1329503795@turing-police.cc.vt.edu>
Message-ID: <20120217185408.GA96943@ussenterprise.ufp.org>

In a message written on Fri, Feb 17, 2012 at 01:36:35PM -0500, Valdis.Kletnieks at vt.edu wrote:
> Am I the only one who thinks that if network jitter can make you fall outside
> the acceptable price window, maybe, just maybe,  the market is just too damned
> volatile for its own good?

I've had an interesting discussion with some financial heads about
a simple idea.

What if the exchange, on every inbound trade, inserted a random
delay, say between 0 and 60 seconds, before processing it?

Almost all of this computer based, let's be closer to the exchange stuff
becomes junk, immediately.  Anyone "long" (where long is probably more
than 10 minutes, with a 60 second jitter) in a security wouldn't notice.

I mean, if the general public has to get 15 minute delayed quotes so
they don't manipulate the market, shouldn't the big guys? :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/d477e78e/attachment.bin>

From paul at paulgraydon.co.uk  Fri Feb 17 12:55:11 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Fri, 17 Feb 2012 08:55:11 -1000
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <37473.1329503795@turing-police.cc.vt.edu>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
 <37473.1329503795@turing-police.cc.vt.edu>
Message-ID: <4F3EA28F.908@paulgraydon.co.uk>

On 02/17/2012 08:36 AM, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 17 Feb 2012 13:01:36 EST, Rodrick Brown said:
>> Trades today in the equity markets must be within the national best bid, best
>> offer price range or companies can be fined by the SEC which is why latency
>> an jitter can be problematic in financial networks.
> Am I the only one who thinks that if network jitter can make you fall outside
> the acceptable price window, maybe, just maybe,  the market is just too damned
> volatile for its own good?
https://www.google.com/finance?client=ob&q=NASDAQ:AAPL 
<https://www.google.com/finance?client=ob&q=NASDAQ:AAPL>

See what happened on Wednesday with Apple's stock.  With no good cause 
it looks like various parties started to try and short it.  You can see 
the initial result from 12pm->1pm, the 'quick buck' 1pm-1:30pm rise, 
then the start of some more shorting at which point you can see the 
pattern emerge where the automatic trading algorithms started doing 
their thing.  Definitely too volatile.

Paul

From bicknell at ufp.org  Fri Feb 17 12:55:58 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 10:55:58 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120217185558.GB96943@ussenterprise.ufp.org>

In a message written on Fri, Feb 17, 2012 at 01:35:15PM -0500, Jay Ashworth wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.

USB->Serial adapters.  Preferably selected so they are driverless on
both OSX and Windows. :)

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/402f76b8/attachment.bin>

From cscora at apnic.net  Fri Feb 17 12:55:41 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 18 Feb 2012 04:55:41 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202171855.q1HItfa5020900@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 18 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              398152
    Prefixes after maximum aggregation:                          169962
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     192387
Total ASes present in the Internet Routing Table:                 40142
    Prefixes per ASN:                                              9.92
Origin-only ASes present in the Internet Routing Table:           32774
Origin ASes announcing only one prefix:                           15521
Transit ASes present in the Internet Routing Table:                5396
Transit-only ASes present in the Internet Routing Table:            143
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               324
    Unregistered ASNs in the Routing Table:                         127
Number of 32-bit ASNs allocated by the RIRs:                       2284
Number of 32-bit ASNs visible in the Routing Table:                1972
Prefixes from 32-bit ASNs in the Routing Table:                    4748
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            225
Number of addresses announced to Internet:                   2516085584
    Equivalent to 149 /8s, 248 /16s and 107 /24s
    Percentage of available address space announced:               67.9
    Percentage of allocated address space announced:               67.9
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      169239

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    98012
    Total APNIC prefixes after maximum aggregation:               31831
    APNIC Deaggregation factor:                                    3.08
Prefixes being announced from the APNIC address blocks:           94322
    Unique aggregates announced from the APNIC address blocks:    39128
APNIC Region origin ASes present in the Internet Routing Table:    4661
    APNIC Prefixes per ASN:                                       20.24
APNIC Region origin ASes announcing only one prefix:               1240
APNIC Region transit ASes present in the Internet Routing Table:    738
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         24
Number of APNIC region 32-bit ASNs visible in the Routing Table:    149
Number of APNIC addresses announced to Internet:              636127072
    Equivalent to 37 /8s, 234 /16s and 135 /24s
    Percentage of available APNIC address space announced:         80.7

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148390
    Total ARIN prefixes after maximum aggregation:                75337
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           120289
    Unique aggregates announced from the ARIN address blocks:     49478
ARIN Region origin ASes present in the Internet Routing Table:    14911
    ARIN Prefixes per ASN:                                         8.07
ARIN Region origin ASes announcing only one prefix:                5685
ARIN Region transit ASes present in the Internet Routing Table:    1565
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               805086400
    Equivalent to 47 /8s, 252 /16s and 164 /24s
    Percentage of available ARIN address space announced:          64.0

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     99249
    Total RIPE prefixes after maximum aggregation:                52504
    RIPE Deaggregation factor:                                     1.89
Prefixes being announced from the RIPE address blocks:            90947
    Unique aggregates announced from the RIPE address blocks:     55992
RIPE Region origin ASes present in the Internet Routing Table:    16316
    RIPE Prefixes per ASN:                                         5.57
RIPE Region origin ASes announcing only one prefix:                7989
RIPE Region transit ASes present in the Internet Routing Table:    2603
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1356
Number of RIPE addresses announced to Internet:               501182472
    Equivalent to 29 /8s, 223 /16s and 112 /24s
    Percentage of available RIPE address space announced:          80.7

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38624
    Total LACNIC prefixes after maximum aggregation:               8109
    LACNIC Deaggregation factor:                                   4.76
Prefixes being announced from the LACNIC address blocks:          38253
    Unique aggregates announced from the LACNIC address blocks:   19501
LACNIC Region origin ASes present in the Internet Routing Table:   1574
    LACNIC Prefixes per ASN:                                      24.30
LACNIC Region origin ASes announcing only one prefix:               443
LACNIC Region transit ASes present in the Internet Routing Table:   291
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        24
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   448
Number of LACNIC addresses announced to Internet:              96604808
    Equivalent to 5 /8s, 194 /16s and 18 /24s
    Percentage of available LACNIC address space announced:        64.0

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8956
    Total AfriNIC prefixes after maximum aggregation:              2096
    AfriNIC Deaggregation factor:                                  4.27
Prefixes being announced from the AfriNIC address blocks:          6976
    Unique aggregates announced from the AfriNIC address blocks:   2176
AfriNIC Region origin ASes present in the Internet Routing Table:   514
    AfriNIC Prefixes per ASN:                                     13.57
AfriNIC Region origin ASes announcing only one prefix:              164
AfriNIC Region transit ASes present in the Internet Routing Table:  118
Average AfriNIC Region AS path length visible:                      4.4
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             30956544
    Equivalent to 1 /8s, 216 /16s and 92 /24s
    Percentage of available AfriNIC address space announced:       46.1

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2485      11107         989   Korea Telecom (KIX)
17974     1729        501          36   PT TELEKOMUNIKASI INDONESIA
 7545     1643        303          86   TPG Internet Pty Ltd
 4755     1550        385         160   TATA Communications formerly 
 7552     1267       1064           7   Vietel Corporation
 9829     1181        997          29   BSNL National Internet Backbo
 4808     1149       2114         318   CNCGROUP IP network: China169
 9583     1124         84         482   Sify Limited
24560     1019        385         167   Bharti Airtel Ltd., Telemedia
18101      950        130         156   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3440       3807         201   bellsouth.net, inc. 
 7029     3389       1014         159   Windstream Communications Inc
18566     2091        382         177   Covad Communications 
 1785     1871        680         126   PaeTec Communications, Inc.
20115     1627       1550         630   Charter Communications 
 4323     1608       1062         384   Time Warner Telecom
22773     1527       2910         110   Cox Communications, Inc.
30036     1400        248         750   Mediacom Communications Corp 
19262     1388       4703         397   Verizon Global Networks 
 7018     1307       6996         848   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1768        480          15   Corbina telecom
 2118     1399         97          13   EUnet/RELCOM Autonomous Syste
15557     1098       2184          60   LDCOM NETWORKS
34984      653        188         173   BILISIM TELEKOM
 6830      644       1927         413   UPC Distribution Services
20940      615        198         472   Akamai Technologies European 
12479      605        643          54   Uni2 Autonomous System
 8551      576        360          81   Bezeq International
31148      538         37           9   FreeNet ISP
 3320      533       8450         399   Deutsche Telekom AG

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1744        323         172   TVCABLE BOGOTA 
28573     1671       1085          65   NET Servicos de Comunicao S.A
 8151     1475       3007         345   UniNet S.A. de C.V. 
 7303     1263        758         182   Telecom Argentina Stet-France
26615      860        672          33   Tim Brasil S.A.
27947      661         67         108   Telconet S.A
11172      631         91          73   Servicios Alestra S.A de C.V 
22047      581        322          17   VTR PUNTO NET S.A. 
 6503      552        418          66   AVANTEL, S.A. 
 3816      551        237          91   Empresa Nacional de Telecomun

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1232        958          13   TEDATA
24863      830        156          44   LINKdotNET AS number
 6713      489        649          18   Itissalat Al-MAGHRIB
 3741      278        939         229   The Internet Solution 
33776      237         13          14   Starcomms Nigeria Limited
15706      222         32           6   Sudatel Internet Exchange Aut
29571      214         17          12   Ci Telecom Autonomous system 
12258      197         28          62   Vodacom Internet Company 
24835      194         80           8   RAYA Telecom - Egypt
16637      163        664          82   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3440       3807         201   bellsouth.net, inc. 
 7029     3389       1014         159   Windstream Communications Inc
 4766     2485      11107         989   Korea Telecom (KIX)
18566     2091        382         177   Covad Communications 
 1785     1871        680         126   PaeTec Communications, Inc.
 8402     1768        480          15   Corbina telecom
10620     1744        323         172   TVCABLE BOGOTA 
17974     1729        501          36   PT TELEKOMUNIKASI INDONESIA
28573     1671       1085          65   NET Servicos de Comunicao S.A
 7545     1643        303          86   TPG Internet Pty Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3389        3230      Windstream Communications Inc
18566      2091        1914      Covad Communications 
 8402      1768        1753      Corbina telecom
 1785      1871        1745      PaeTec Communications, Inc.
17974      1729        1693      PT TELEKOMUNIKASI INDONESIA
28573      1671        1606      NET Servicos de Comunicao S.A
10620      1744        1572      TVCABLE BOGOTA 
 7545      1643        1557      TPG Internet Pty Ltd
 4766      2485        1496      Korea Telecom (KIX)
22773      1527        1417      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
23.27.0.0/16         18779     Guru.com 
27.112.114.0/24      23884     Proimage Engineering and Comm

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:27      /11:80      /12:231     
/13:458     /14:814     /15:1471    /16:12149   /17:6211    /18:10346   
/19:20464   /20:28291   /21:29265   /22:39904   /23:37028   /24:207711  
/25:1186    /26:1449    /27:779     /28:168     /29:57      /30:14      
/31:0       /32:18      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3045          3389      Windstream Communications Inc
 6389     2110          3440      bellsouth.net, inc. 
18566     2040          2091      Covad Communications 
 8402     1747          1768      Corbina telecom
10620     1641          1744      TVCABLE BOGOTA 
30036     1354          1400      Mediacom Communications Corp 
11492     1118          1155      Cable One 
 1785     1064          1871      PaeTec Communications, Inc.
15557     1045          1098      LDCOM NETWORKS
 8452     1042          1232      TEDATA

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:505       2:740       4:14        5:1         6:3         8:384    
  12:1960     13:1        14:597      15:11       16:3        17:7      
  20:8        23:135      24:1730     27:1186     31:945      32:65     
  33:2        34:2        36:9        37:186      38:781      40:115    
  41:3149     42:96       43:1        44:3        46:1298     47:3      
  49:331      50:501      52:13       54:2        55:10       56:3      
  57:38       58:966      59:494      60:344      61:1195     62:949    
  63:2005     64:4148     65:2284     66:4452     67:2034     68:1174   
  69:3163     70:934      71:412      72:1795     74:2658     75:463    
  76:320      77:979      78:948      79:486      80:1212     81:879    
  82:604      83:523      84:587      85:1153     86:749      87:914    
  88:338      89:1556     90:282      91:4472     92:530      93:1349   
  94:1378     95:1116     96:418      97:311      98:812      99:38     
 100:4       101:144     103:805     106:65      107:155     108:168    
 109:1489    110:700     111:851     112:437     113:527     114:602    
 115:765     116:862     117:710     118:903     119:1254    120:361    
 121:685     122:1624    123:1082    124:1333    125:1325    128:538    
 129:190     130:216     131:588     132:166     133:21      134:234    
 135:62      136:215     137:182     138:288     139:145     140:490    
 141:263     142:394     143:403     144:509     145:69      146:483    
 147:237     148:732     149:282     150:172     151:198     152:447    
 153:170     154:7       155:408     156:212     157:367     158:160    
 159:512     160:321     161:245     162:341     163:187     164:531    
 165:395     166:558     167:458     168:762     169:147     170:838    
 171:114     172:4       173:1722    174:592     175:421     176:516    
 177:503     178:1255    180:1180    181:67      182:726     183:280    
 184:430     185:1       186:2013    187:846     188:1070    189:1172   
 190:5504    192:5979    193:5532    194:4341    195:3402    196:1289   
 197:164     198:3622    199:4393    200:5704    201:1742    202:8419   
 203:8619    204:4369    205:2440    206:2744    207:2781    208:4076   
 209:3557    210:2760    211:1481    212:2011    213:1838    214:857    
 215:91      216:5029    217:1488    218:551     219:337     220:1225   
 221:561     222:324     223:313    

End of report


From streiner at cluebyfour.org  Fri Feb 17 12:56:15 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 13:56:15 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <Pine.LNX.4.64.1202171352070.18711@whammy.cluebyfour.org>

On Fri, 17 Feb 2012, Jay Ashworth wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

To my original list, I'll also add cage nut extractors.  When available, 
they are a godsend.  I usually keep one in my backpack-of-tools when I go 
out to do rack-and-sta--- er... occupational yoga :)

jms


From tony at swalter.com  Fri Feb 17 12:56:22 2012
From: tony at swalter.com (Tony Patti)
Date: Fri, 17 Feb 2012 13:56:22 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <20120217184401.GC10646@mikea.ath.cx>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <CAMfXtQxgqhawTT8-fNrURXCZsXL7RTukmfc1a2MrWab1dm-HVg@mail.gmail.com>
 <035101cceda0$157d3860$4077a920$@com> <20120217184401.GC10646@mikea.ath.cx>
Message-ID: <038901cceda5$d768d420$863a7c60$@com>

> From: Mike Andrews [mailto:mikea at mikea.ath.cx] 
> Sent: Friday, February 17, 2012 1:44 PM
> To: 'NANOG'
> Subject: Re: common time-management mistake: rack & stack
> 
> On Fri, Feb 17, 2012 at 01:15:09PM -0500, Tony Patti wrote:
> 
> > In the context of the military scenario above, Grace Hopper comes to 
> > mind because of her nanoseconds etc "In her retirement speech, instead 
> > of dwelling on the past, she talked about moving toward the future, 
> > stressing the importance of leadership."
> > http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm
> > I was lucky enough to have heard her speak once at an ACM event.
> 
> I still have my nanosecond. Did she hand them out to the crowd there?

Yes, of course!

I remember that she said they were borrowed from a phone closet in the
Pentagon...

Of course, she is also famous for "It's easier to ask for forgiveness than
it is to get permission"
Notable Quotation from her Wikipedia page at
http://en.wikipedia.org/wiki/Grace_Hopper 

Tony Patti
CIO
S. Walter Packaging Corp.



From sven at cb3rob.net  Fri Feb 17 12:56:27 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 18:56:27 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202171841010.32438@a84-22-97-10.cb3rob.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <Pine.LNX.4.64.1202171841010.32438@a84-22-97-10.cb3rob.net>
Message-ID: <Pine.LNX.4.64.1202171848190.32438@a84-22-97-10.cb3rob.net>

rj45 crimp connectors for both 8p8c flatcable and cat5e (they are 
different!)

"cisco" type db9-rj45 adapters, prewired (when you buy them bulk they 
usually come unwired ;)

tierips

empty cds/dvds

usb cd/dvd writers (see rs232 ;)

usb floppy drives (yes, they're still around ;)

3.5" HD floppies (yes, they're still around ;)

usb -> rs232 adapters (in case the shitty modern laptop you just bought 
upon arriving in that country didn't come with the most important 
interface of all ;)

ECC RAM DIMMS of various sizes and speeds and pinnings

SCA and SAS and SATA HDDs and SSD's

CF cards, USB sticks, DIGITAL CAMERAS!

replacement ventilators for most equipment maybe.. but that one can be a 
bit tricky ;)

so pretty much all the stuff you normally cannot buy in computer stores 
and still need if you just go to location x and need to set things up 
without preparation.


-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote:

> rackmount screws, nuts, bolts, rubber rings for both M6 and whatever other 
> stuff ppl use (that smaller size is common too ;)
>
> preferably in both black and silver color.
>
> 19" trays
> 19" electricity socket bars
>
> IEC power cables.
> ethernet patch cables 3 meter
>
> screwdriver sets
>
> and whatever other stuff people generally forget and then decide to steal out 
> of our racks so we have to drive to the home depot kinda thing again.
> (don't ask ;)
>
> -- 
> Greetings,
>
> Sven Olaf Kamphuis,
> CB3ROB Ltd. & Co. KG
> =========================================================================
> Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
>         D-13359                   Registration:    HRA 42834 B
>         BERLIN                    Phone:           +31/(0)87-8747479
>         Germany                   GSM:             +49/(0)152-26410799
> RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
> =========================================================================
> <penpen> C3P0, der elektrische Westerwelle
> http://www.facebook.com/cb3rob
> =========================================================================
>
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
>
>
> On Fri, 17 Feb 2012, Jay Ashworth wrote:
>
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>> 
>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth                  Baylink 
>> jra at baylink.com
>> Designer                     The Things I Think                       RFC 
>> 2100
>> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover 
>> DII
>> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 
>> 1274
>> 
>


From ken.gilmour at gmail.com  Fri Feb 17 12:57:39 2012
From: ken.gilmour at gmail.com (Ken Gilmour)
Date: Fri, 17 Feb 2012 19:57:39 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAMhuimgf_cXdWaDpqduME8uKPsJH0FxNvmBfxtwXXP=L_QbDsg@mail.gmail.com>

Phase testers
Velcro
Flashlight (depending on how well lit the dc is)

--
Sent from my Android tablet. Please excuse my brevity
On Feb 17, 2012 6:35 PM, "Jay Ashworth" <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think                       RFC
> 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647
> 1274
>
>

From jof at thejof.com  Fri Feb 17 12:58:54 2012
From: jof at thejof.com (Jonathan Lassoff)
Date: Fri, 17 Feb 2012 10:58:54 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217185558.GB96943@ussenterprise.ufp.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
Message-ID: <CAHsqw9tFz_BHT_SjAZ8ibyWOfKnXWcmb7tWz9r9tKn9icX3-YQ@mail.gmail.com>

On Fri, Feb 17, 2012 at 10:55 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 17, 2012 at 01:35:15PM -0500, Jay Ashworth wrote:
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>
> USB->Serial adapters. ?Preferably selected so they are driverless on
> both OSX and Windows. :)

Does such a device exist? I've yet to run across one.

Personally, I would recommend those based on FTDI chips or Prolific
PL2303 -- both have support for Linux, Windows, and OSX.

--j


From sven at cb3rob.net  Fri Feb 17 12:58:12 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 18:58:12 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
Message-ID: <Pine.LNX.4.64.1202171857530.32438@a84-22-97-10.cb3rob.net>

noise/ear protectors!


On Fri, 17 Feb 2012, Leigh Porter wrote:

>
> On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
>
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>
> Pizza, condoms and headache tablets.
>
> -- 
> Leigh
>
>
>
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
>


From sparctacus at gmail.com  Fri Feb 17 12:59:51 2012
From: sparctacus at gmail.com (Bryan Irvine)
Date: Fri, 17 Feb 2012 10:59:51 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217185558.GB96943@ussenterprise.ufp.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
Message-ID: <CAG367gYi6yk3Fbx6v7ESxZT5H7cUA6bSfB8V=qS4NHiYEmJctg@mail.gmail.com>

On Fri, Feb 17, 2012 at 10:55 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 17, 2012 at 01:35:15PM -0500, Jay Ashworth wrote:
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>
> USB->Serial adapters. ?Preferably selected so they are driverless on
> both OSX and Windows. :)

The trick is to look for one that works on OpenBSD.  If it works
there, it will work on Windows, Mac, and Linux.  YMMV. :-)


From owen at delong.com  Fri Feb 17 12:59:10 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 10:59:10 -0800
Subject: Common operational misconceptions
In-Reply-To: <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>,
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
Message-ID: <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>


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

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

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

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

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

Owen

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

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



From tperrine at scea.com  Fri Feb 17 13:01:38 2012
From: tperrine at scea.com (Tom Perrine)
Date: Fri, 17 Feb 2012 11:01:38 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
Message-ID: <4F3EA412.4010205@scea.com>

On 2/17/12 10:52 AM, Leigh Porter wrote:
> 
> On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
> 
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't 
>> let vendor specificity scare you off.
> 
> Pizza, condoms and headache tablets.
> 

Stone Brewery Arrogant Bastard beer - "A bitter brew for your bitter life", "You are not worthy"



From sven at cb3rob.net  Fri Feb 17 13:01:39 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 19:01:39 +0000 (UTC)
Subject: Colo Vending Machine
In-Reply-To: <0B224A2FE01CC54C860290D42474BF60052D54BB@exchange.nff.local>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <0B224A2FE01CC54C860290D42474BF60052D54BB@exchange.nff.local>
Message-ID: <Pine.LNX.4.64.1202171858540.32438@a84-22-97-10.cb3rob.net>


On Fri, 17 Feb 2012, Erik Soosalu wrote:

> 1) Patch cables every 1' length from 3-10'
> 2) Velcro wrap
> 3) Tools (screwdrivers, etc)
>
> And since the racks usually come with the cage nuts, maybe the colo should just provide them.

they do? nonono, you have to buy those seperately :P

racks don't even come with "doors" and "side walls" etc by default *grin*

you have to buy them seperately anyway if you want to make sure your 
company uses all the same ones, so you don't have to take them out again 
and replace them because some fukkin idiot put the wrong size into the 
hole as it "came with something else"

> >
> Thanks,
> Erik
>
> -----Original Message-----
> From: Jay Ashworth [mailto:jra at baylink.com]
> Sent: Friday, February 17, 2012 1:35 PM
> To: NANOG
> Subject: WW: Colo Vending Machine
>
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>
>
>


From gbonser at seven.com  Fri Feb 17 13:03:44 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 19:03:44 +0000
Subject: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>

Diagonal cutters
Screwdriver with interchangeable Phillips/straight blade
Small flashlight (with the data center provider's logo even!)
Headlamp
Small mirror (inspection mirror)
Rack screws
Zip ties
Velcro ties
Sharpie markers
Pens 
Notebook of shirt pocket size with pages that can be easily torn out for leaving notes.
Post-It
Assortment of electrical tape in various colors.
SFPs (optical and RJ-45, short and long range)
USB stick (sans viruses)
Patch cords 1, 3, 5 meter. Copper, multi-mode, single-mode fiber
USB to DB9 dongle (with driver on USB stick or one the computer can discover on the Internet)
Standard charger of sort used for most smart phones these days or the proper USB cable (micro USB)

The vending machine should use a card like an ATM/gift card, not accept cash.  You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space.  If something is needed, one can purchase it with the card.  If there is no money on the card, a person can add cash to the card via a web portal somewhere.   Scenario:  remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.




From Valdis.Kletnieks at vt.edu  Fri Feb 17 13:04:45 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Fri, 17 Feb 2012 14:04:45 -0500
Subject: Common operational misconceptions
In-Reply-To: Your message of "Fri, 17 Feb 2012 10:49:13 PST."
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
Message-ID: <39313.1329505485@turing-police.cc.vt.edu>

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

IBM S/360 definitely preferred hex.  And EBCDIC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/7e04a136/attachment.bin>

From erik.soosalu at calyxinc.com  Fri Feb 17 13:06:37 2012
From: erik.soosalu at calyxinc.com (Erik Soosalu)
Date: Fri, 17 Feb 2012 14:06:37 -0500
Subject: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202171858540.32438@a84-22-97-10.cb3rob.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <0B224A2FE01CC54C860290D42474BF60052D54BB@exchange.nff.local>
 <Pine.LNX.4.64.1202171858540.32438@a84-22-97-10.cb3rob.net>
Message-ID: <0B224A2FE01CC54C860290D42474BF60052D54C2@exchange.nff.local>

I know I'm being a freaking idealist.

My tool bag carries all my required sets of screws and cage nuts.  Works
great until the first level guy decides to borrow something and not put
it back.

Thanks,
Erik 
-----Original Message-----
From: Sven Olaf Kamphuis [mailto:sven at cb3rob.net] 
Sent: Friday, February 17, 2012 2:02 PM
To: Erik Soosalu
Cc: NANOG
Subject: RE: Colo Vending Machine


On Fri, 17 Feb 2012, Erik Soosalu wrote:

> 1) Patch cables every 1' length from 3-10'
> 2) Velcro wrap
> 3) Tools (screwdrivers, etc)
>
> And since the racks usually come with the cage nuts, maybe the colo
should just provide them.

they do? nonono, you have to buy those seperately :P

racks don't even come with "doors" and "side walls" etc by default
*grin*

you have to buy them seperately anyway if you want to make sure your 
company uses all the same ones, so you don't have to take them out again

and replace them because some fukkin idiot put the wrong size into the 
hole as it "came with something else"

> >
> Thanks,
> Erik
>
> -----Original Message-----
> From: Jay Ashworth [mailto:jra at baylink.com]
> Sent: Friday, February 17, 2012 1:35 PM
> To: NANOG
> Subject: WW: Colo Vending Machine
>
> Please post your top 3 favorite components/parts you'd like to see in
a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink
jra at baylink.com
> Designer                     The Things I Think
RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
647 1274
>
>
>



From bblackford at gmail.com  Fri Feb 17 13:06:50 2012
From: bblackford at gmail.com (Bill Blackford)
Date: Fri, 17 Feb 2012 11:06:50 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAMv18OMe0TW1iNdv6C0XkEO6FCL5jmDbU0EsQFEevHSbhih=bw@mail.gmail.com>

1. patch cables. MMF and SMF, LC and SC and LC/SC to include LC and SC
couplers so one can mix-and-match
2. Velcro wraps.
3. cage nuts/bolts

-b



On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth <jra at baylink.com> wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com
> Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100
> Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII
> St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274
>



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.....


From nathan at atlasnetworks.us  Fri Feb 17 13:06:29 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Fri, 17 Feb 2012 19:06:29 +0000
Subject: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286B7B90A1@ex-mb-2.corp.atlasnetworks.us>

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think
> RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
> 647 1274
> 

USB A/B/Mini/Micro/Nano/Pico/etc/etc/etc cables
Spare parts (common sizes of RAM/Disks/Fans)
New servers (probably don't fit in a vending machine, but in that dark place where you need a new box *TONIGHT*, this could be a godsend)
Generically sized hoodie or sweatshirt.  Datacenters can get really cold if you're in there longer than expected.
Advil/Ibuprofen/Generic OTC Pain Reliever
Cisco Console Cables

Outside of a vending machine, I've also seen a few facilities that have normal vending machines (including instant coffee dispensers).  This has, on more than one occasion, kept me standing long enough to get the jorb done.

Nathan Eisenberg

From sven at cb3rob.net  Fri Feb 17 13:07:25 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 19:07:25 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EA412.4010205@scea.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
 <4F3EA412.4010205@scea.com>
Message-ID: <Pine.LNX.4.64.1202171904350.32438@a84-22-97-10.cb3rob.net>

if a pop doesn't come with a hotel with a bar in front of the door, 
or at least around the corner, and preferably free beer, coffee, etc in 
the cantina as well, we're not a customer of theirs haha.

headace tables are good..

but then again, with noise protectors you would not get the headace in the 
first place :P

and a buttwarmer to sit on the floor (or maybe even a chair!)


On Fri, 17 Feb 2012, Tom Perrine wrote:

> On 2/17/12 10:52 AM, Leigh Porter wrote:
>>
>> On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
>>
>>> Please post your top 3 favorite components/parts you'd like to see in a
>>> vending machine at your colo; please be as specific as possible; don't
>>> let vendor specificity scare you off.
>>
>> Pizza, condoms and headache tablets.
>>
>
> Stone Brewery Arrogant Bastard beer - "A bitter brew for your bitter life", "You are not worthy"
>
>


From sven at cb3rob.net  Fri Feb 17 13:09:02 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 19:09:02 +0000 (UTC)
Subject: Colo Vending Machine
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
Message-ID: <Pine.LNX.4.64.1202171908450.32438@a84-22-97-10.cb3rob.net>

or you just use your datacenter access rfid pass to pay and they put it on 
the bill later on.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, George Bonser wrote:

> Diagonal cutters
> Screwdriver with interchangeable Phillips/straight blade
> Small flashlight (with the data center provider's logo even!)
> Headlamp
> Small mirror (inspection mirror)
> Rack screws
> Zip ties
> Velcro ties
> Sharpie markers
> Pens
> Notebook of shirt pocket size with pages that can be easily torn out for leaving notes.
> Post-It
> Assortment of electrical tape in various colors.
> SFPs (optical and RJ-45, short and long range)
> USB stick (sans viruses)
> Patch cords 1, 3, 5 meter. Copper, multi-mode, single-mode fiber
> USB to DB9 dongle (with driver on USB stick or one the computer can discover on the Internet)
> Standard charger of sort used for most smart phones these days or the proper USB cable (micro USB)
>
> The vending machine should use a card like an ATM/gift card, not accept cash.  You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space.  If something is needed, one can purchase it with the card.  If there is no money on the card, a person can add cash to the card via a web portal somewhere.   Scenario:  remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.
>
>
>
>


From matthew at corp.crocker.com  Fri Feb 17 13:10:01 2012
From: matthew at corp.crocker.com (Matthew S. Crocker)
Date: Fri, 17 Feb 2012 14:10:01 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <dcc840de-e8d1-4d40-8cbd-786df3754194@zimbra1.crocker.com>


Serial cables, DB9 -> USB converts and all of the various vendor adapters to make it work.

WTSHTF I'm always digging through my gear looking for the right serial adapter.

Duct tape, paper clips and chewing gum.  If it was good enough for McGyver it is good enough for me.


----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>
> To: "NANOG" <nanog at nanog.org>
> Sent: Friday, February 17, 2012 1:35:15 PM
> Subject: WW: Colo Vending Machine
> 
> Please post your top 3 favorite components/parts you'd like to see in
> a
> vending machine at your colo; please be as specific as possible;
> don't
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
>                       jra at baylink.com
> Designer                     The Things I Think
>                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
> 647 1274
> 
> 
> 


From mike.lyon at gmail.com  Fri Feb 17 13:10:28 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Fri, 17 Feb 2012 11:10:28 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EA412.4010205@scea.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
 <4F3EA412.4010205@scea.com>
Message-ID: <CAFFgAjCbD959ScZe2C21fo3Q1a5JYkdEtOcu+RJ=YrUMAxMYBg@mail.gmail.com>

1. BNC tees
2. FDDI cables
3. AUI to BNC adapters.



On Fri, Feb 17, 2012 at 11:01 AM, Tom Perrine <tperrine at scea.com> wrote:

> On 2/17/12 10:52 AM, Leigh Porter wrote:
> >
> > On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
> >
> >> Please post your top 3 favorite components/parts you'd like to see in a
> >> vending machine at your colo; please be as specific as possible; don't
> >> let vendor specificity scare you off.
> >
> > Pizza, condoms and headache tablets.
> >
>
> Stone Brewery Arrogant Bastard beer - "A bitter brew for your bitter
> life", "You are not worthy"
>
>
>


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

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

From lists at quux.de  Fri Feb 17 13:13:05 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 20:13:05 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217185558.GB96943@ussenterprise.ufp.org> (Leo Bicknell's
 message of "Fri, 17 Feb 2012 10:55:58 -0800")
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
Message-ID: <87y5s19su6.fsf@pc8.berlin.quux.de>

Leo Bicknell <bicknell at ufp.org> writes:

> USB->Serial adapters.  Preferably selected so they are driverless on
> both OSX and Windows. :)
               ^^^^^^^

Wahahahaha.... There is no such thing. 

I've seen people reinstalling their Windows after trying to use another
USB->Serial adapter. I also have seen people running a Linux VM so they
can use a USB->Serial adapter they borrowed from me.

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


From sven at cb3rob.net  Fri Feb 17 13:13:18 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 19:13:18 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <87y5s19su6.fsf@pc8.berlin.quux.de>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
 <87y5s19su6.fsf@pc8.berlin.quux.de>
Message-ID: <Pine.LNX.4.64.1202171912180.32438@a84-22-97-10.cb3rob.net>

there is, you can have a pci-bridge or isa-bridge on usb... and then have 
a normal rs232 card in it *grin*

so far for wintendo :P

(yes it does understand the concept of having a usb-connected pci 
interface :P

On Fri, 17 Feb 2012, Jens Link wrote:

> Leo Bicknell <bicknell at ufp.org> writes:
>
>> USB->Serial adapters.  Preferably selected so they are driverless on
>> both OSX and Windows. :)
>               ^^^^^^^
>
> Wahahahaha.... There is no such thing.
>
> I've seen people reinstalling their Windows after trying to use another
> USB->Serial adapter. I also have seen people running a Linux VM so they
> can use a USB->Serial adapter they borrowed from me.
>
> Jens
> -- 
> -------------------------------------------------------------------------
> | Foelderichstr. 40   | 13595 Berlin, Germany    | +49-151-18721264     |
> | http://blog.quux.de | jabber: jenslink at guug.de | -------------------  |
> -------------------------------------------------------------------------
>


From bonomi at mail.r-bonomi.com  Fri Feb 17 13:18:53 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 17 Feb 2012 13:18:53 -0600 (CST)
Subject: Common operational misconceptions
In-Reply-To: <39313.1329505485@turing-police.cc.vt.edu>
Message-ID: <201202171918.q1HJIrJw065001@mail.r-bonomi.com>

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

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




From bhmccie at gmail.com  Fri Feb 17 13:16:58 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 13:16:58 -0600
Subject: Common operational misconceptions
In-Reply-To: <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
Message-ID: <4F3EA7AA.2010902@gmail.com>

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

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

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From bhmccie at gmail.com  Fri Feb 17 13:17:57 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 13:17:57 -0600
Subject: Common operational misconceptions
In-Reply-To: <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>,
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>,
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
Message-ID: <4F3EA7E5.3070406@gmail.com>

Well put and great example Owen.

-Hammer-

"I was a normal American nerd"
-Jack Herer



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



From surfer at mauigateway.com  Fri Feb 17 13:18:21 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 17 Feb 2012 11:18:21 -0800
Subject: Common operational misconceptions
Message-ID: <20120217111821.55081A16@resin11.mta.everyone.net>




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

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


grrr....
scott



From lists at quux.de  Fri Feb 17 13:21:20 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 20:21:20 +0100
Subject: Common operational misconceptions
In-Reply-To: <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com> (Owen DeLong's
 message of "Fri, 17 Feb 2012 10:59:10 -0800")
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
Message-ID: <87obsx9sgf.fsf@pc8.berlin.quux.de>

Owen DeLong <owen at delong.com> writes:

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

Ack.

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

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

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


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

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

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


From tperrine at scea.com  Fri Feb 17 13:19:29 2012
From: tperrine at scea.com (Tom Perrine)
Date: Fri, 17 Feb 2012 11:19:29 -0800
Subject: Common operational misconceptions
In-Reply-To: <39313.1329505485@turing-police.cc.vt.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
 <39313.1329505485@turing-police.cc.vt.edu>
Message-ID: <4F3EA841.4080205@scea.com>

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

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

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

- --tep

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

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


From lists at quux.de  Fri Feb 17 13:24:26 2012
From: lists at quux.de (Jens Link)
Date: Fri, 17 Feb 2012 20:24:26 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202171848190.32438@a84-22-97-10.cb3rob.net> (Sven
 Olaf Kamphuis's message of "Fri,
 17 Feb 2012 18:56:27 +0000 (UTC)")
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <Pine.LNX.4.64.1202171841010.32438@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202171848190.32438@a84-22-97-10.cb3rob.net>
Message-ID: <87k43l9sb9.fsf@pc8.berlin.quux.de>

Sven Olaf Kamphuis <sven at cb3rob.net> writes:

> 3.5" HD floppies (yes, they're still around ;)

Really? I thought Deutsche Bahn was last company using
them: "Unfortunately we can't display reservation information."

Okay, knowing Deutsche Bahn the disks might not be 3,5". ;-)


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


From sven at cb3rob.net  Fri Feb 17 13:24:50 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Fri, 17 Feb 2012 19:24:50 +0000 (UTC)
Subject: Common operational misconceptions
In-Reply-To: <4F3EA7AA.2010902@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net> <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>, 
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com> <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
 <4F3EA7AA.2010902@gmail.com>
Message-ID: <Pine.LNX.4.64.1202171919480.32438@a84-22-97-10.cb3rob.net>

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

steve jobs knew how to operate a computer?

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

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

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

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

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

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


From gbonser at seven.com  Fri Feb 17 13:26:44 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 19:26:44 +0000
Subject: Common operational misconceptions
In-Reply-To: <87obsx9sgf.fsf@pc8.berlin.quux.de>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
 <87obsx9sgf.fsf@pc8.berlin.quux.de>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0AA4@RWC-MBX1.corp.seven.com>

> > 3.	Troubleshooting skills are limited to knowing the number of the
> vendor's help desk.
> 
> There are no problems! Can't be. And if there are they hire external
> experts. BTDT. Those are well paid jobs.

I see that a lot and there is often an organizational reason for it.  If a tech says "I have a ticket open with the vendor" and provides the ticket and status updates on a regular basis, he's covered as far as the people higher up in the organization are concerned.  If the C(X)O wants to know what's going on, the manager can shift the focus to the vendor and say we are waiting for a fix from them.

A tech trying to troubleshoot it and fix it themselves is going to be hounded every five minutes for status updates and won't be able to get any work done because every five minutes (I kid you not, I have worked where that is a requirement) he has to pull his head out of what he is doing and answer a bunch of questions from the PHBs.  And you always get "how long is it going to be" and you want to say "10 minutes longer than it would have been if you hadn't interrupted me" but you bite your tongue.



From gary.buhrmaster at gmail.com  Fri Feb 17 13:29:20 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 17 Feb 2012 19:29:20 +0000
Subject: Common operational misconceptions
In-Reply-To: <201202171918.q1HJIrJw065001@mail.r-bonomi.com>
References: <39313.1329505485@turing-police.cc.vt.edu>
 <201202171918.q1HJIrJw065001@mail.r-bonomi.com>
Message-ID: <CAMfXtQxRaXCS=1ZPrBS+zUtWhiUwO21HY44xkcZjKxX1zyz5FQ@mail.gmail.com>

On Fri, Feb 17, 2012 at 19:18, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
....
> And the ?_real_ number crunchers used ones-complement arithmetic.

Not to mention 0 had a sign (and 0 did not compare
as equal to -0).


From gbonser at seven.com  Fri Feb 17 13:35:03 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 17 Feb 2012 19:35:03 +0000
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0AA4@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
 <87obsx9sgf.fsf@pc8.berlin.quux.de>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0AA4@RWC-MBX1.corp.seven.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0ACB@RWC-MBX1.corp.seven.com>

> A tech trying to troubleshoot it and fix it themselves is going to be
> hounded every five minutes for status updates and won't be able to get
> any work done because every five minutes (I kid you not, I have worked
> where that is a requirement) he has to pull his head out of what he is
> doing and answer a bunch of questions from the PHBs.  And you always
> get "how long is it going to be" and you want to say "10 minutes longer
> than it would have been if you hadn't interrupted me" but you bite your
> tongue.
> 

Though the flip side of that is that if someone has been neck deep in a problem for hours, you should force them to take a break, go get a drink of water, step outside for fresh air or a smoke if they do, or just talk to a colleague for a moment and review the problem.  In my case, the stepping away for a few minutes has sometimes allowed the answer to the problem to suddenly snap into focus or in the process of describing it to someone else the forming of the thoughts to describe it often allows a new aspect of the problem to become visible that you hadn't noticed before.




From rps at maine.edu  Fri Feb 17 13:42:05 2012
From: rps at maine.edu (Ray Soucy)
Date: Fri, 17 Feb 2012 14:42:05 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3E69A7.2060008@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
Message-ID: <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>

As someone who was born in 1984 I respectfully disagree. ;-)




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



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From surfer at mauigateway.com  Fri Feb 17 13:42:42 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Fri, 17 Feb 2012 11:42:42 -0800
Subject: common time-management mistake: rack & stack
Message-ID: <20120217114242.55081631@resin11.mta.everyone.net>



--- gary.buhrmaster at gmail.com wrote:
There is a theory of management that says a good manager
needs to know nothing about the staff or the jobs he is managing,
---------------------------------------------

<neck hair == raised>  :-)

>From empirical data, this is not a good thing for companies.  They
constantly make bad choices because they not only don't understand the 
concepts, but can't even grasp the consequences of their decision.

For example, I had four GigEs each to several upstreams.  I pointed the BGP 
session to the loopback at the provider's router, so the traffic would load 
share across the four GigEs.  I was told my one of those managers who "needs 
to know nothing about the staff or the jobs he is managing" that was not 
redundant and that I had to do one BGP session per GigE, so four BGP sessions 
to each upstream.  After some heated discussions with the manager about why 
that was not a good design decision, I warmed up my resume and started looking 
for a new job.

scott


From randy at psg.com  Fri Feb 17 13:44:05 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 17 Feb 2012 11:44:05 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3EA841.4080205@scea.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
 <39313.1329505485@turing-police.cc.vt.edu>
 <4F3EA841.4080205@scea.com>
Message-ID: <m2r4xt5jp6.wl%randy@psg.com>

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

704 - was i think 36-bit but the mind fades
704x/709x - 36 bit
1401 - variable word length with BCD+zone-bit encoding per char

randy


From owen at delong.com  Fri Feb 17 13:42:31 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 11:42:31 -0800
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0ACB@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
 <87obsx9sgf.fsf@pc8.berlin.quux.de>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0AA4@RWC-MBX1.corp.seven.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0ACB@RWC-MBX1.corp.seven.com>
Message-ID: <AAC95D83-5F5D-4683-8F49-E52C94F5851D@delong.com>

I have found that the best solution to persistent hounding goes about like this:

"Sir, I'm doing everything I can to resolve the problem as quickly as possible. However, I can focus on giving you status updates every 5 minutes, or, I can focus on resolving the problem. I cannot do both. which would you prefer?"

As to the internal vs. external question, most organizations I've worked for have just wanted the problem solved. They didn't so much care whether I was taking a lot of time to solve it or the vendor was taking a lot of time to respond to me, they wanted the problem fixed and I was the one they could fire.

As such, it was in my interest to usually learn most of the systems better than the tech support folk at the other end of the phone.

YMMV

Owen

On Feb 17, 2012, at 11:35 AM, George Bonser wrote:

>> A tech trying to troubleshoot it and fix it themselves is going to be
>> hounded every five minutes for status updates and won't be able to get
>> any work done because every five minutes (I kid you not, I have worked
>> where that is a requirement) he has to pull his head out of what he is
>> doing and answer a bunch of questions from the PHBs.  And you always
>> get "how long is it going to be" and you want to say "10 minutes longer
>> than it would have been if you hadn't interrupted me" but you bite your
>> tongue.
>> 
> 
> Though the flip side of that is that if someone has been neck deep in a problem for hours, you should force them to take a break, go get a drink of water, step outside for fresh air or a smoke if they do, or just talk to a colleague for a moment and review the problem.  In my case, the stepping away for a few minutes has sometimes allowed the answer to the problem to suddenly snap into focus or in the process of describing it to someone else the forming of the thoughts to describe it often allows a new aspect of the problem to become visible that you hadn't noticed before.
> 
> 



From todd at borked.ca  Fri Feb 17 13:46:24 2012
From: todd at borked.ca (Todd Snyder)
Date: Fri, 17 Feb 2012 14:46:24 -0500
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
Message-ID: <CAPQUSnNcTjD_O94qQKpAvYZdKP6UJdaYaLTUzD7tbi0nugL2xA@mail.gmail.com>

as a 33 year old, I'm looking forward to hitting 35 so I can finally
understand what you guys are talking about!  Will I get some sort of glow
or achievement?

think I'll get a raise when I can add 'troubleshooting' to my resume? :)

On Fri, Feb 17, 2012 at 2:42 PM, Ray Soucy <rps at maine.edu> wrote:

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

From ralph.brandt at pateam.com  Fri Feb 17 13:47:58 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Fri, 17 Feb 2012 14:47:58 -0500
Subject: Common operational misconceptions
In-Reply-To: <CACfXSnAs1zhcg7P7eHDWf35-ag47zUvD=qoOsg-_TBGAuTi4ug@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <CACfXSnAs1zhcg7P7eHDWf35-ag47zUvD=qoOsg-_TBGAuTi4ug@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F021@embgsr24.pateam.com>

I just pulled the humorous point about Mary the accountant out, pasted its link into an email and sent it to our staff with the suggestion they read it. I was going to past it here but decided to let someone who wants to read it go to the site, they may learn something by accident if they do.

I have been unable to get our group to read anything else, maybe they will read this very well written document.  It really is a "comm oriented" Cliff Notes of Kepner Trego Problem Analysis.  I would love them to read the text book, but will settle for anything.


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


-----Original Message-----
From: Marcel Plug [mailto:marcelplug at gmail.com] 
Sent: Friday, February 17, 2012 12:01 PM
To: -Hammer-
Cc: nanog at nanog.org
Subject: Re: Common operational misconceptions

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

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

-Marcel

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

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



From kiriki at streamguys.com  Fri Feb 17 13:47:33 2012
From: kiriki at streamguys.com (Kiriki Delany)
Date: Fri, 17 Feb 2012 11:47:33 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <20120217185408.GA96943@ussenterprise.ufp.org>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
 <37473.1329503795@turing-police.cc.vt.edu>
 <20120217185408.GA96943@ussenterprise.ufp.org>
Message-ID: <078201ccedad$111efb70$335cf250$@com>

Why not just simultaneously settle all trades at the same time? Once every
minute, or every 5 minutes, or per day? 

There are many solutions to the problem. I'm sure those that can take
advantage of the latency don't want the solution. 


Kiriki Delany

-----Original Message-----
From: Leo Bicknell [mailto:bicknell at ufp.org] 
Sent: Friday, February 17, 2012 10:54 AM
To: NANOG
Subject: Re: Hi speed trading - hi speed monitoring

In a message written on Fri, Feb 17, 2012 at 01:36:35PM -0500,
Valdis.Kletnieks at vt.edu wrote:
> Am I the only one who thinks that if network jitter can make you fall 
> outside the acceptable price window, maybe, just maybe,  the market is 
> just too damned volatile for its own good?

I've had an interesting discussion with some financial heads about a simple
idea.

What if the exchange, on every inbound trade, inserted a random delay, say
between 0 and 60 seconds, before processing it?

Almost all of this computer based, let's be closer to the exchange stuff
becomes junk, immediately.  Anyone "long" (where long is probably more than
10 minutes, with a 60 second jitter) in a security wouldn't notice.

I mean, if the general public has to get 15 minute delayed quotes so they
don't manipulate the market, shouldn't the big guys? :)

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



From lowen at pari.edu  Fri Feb 17 13:45:26 2012
From: lowen at pari.edu (Lamar Owen)
Date: Fri, 17 Feb 2012 14:45:26 -0500
Subject: Common operational misconceptions
In-Reply-To: <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <201202171445.27437.lowen@pari.edu>

On Friday, February 17, 2012 01:30:30 AM Carsten Bormann wrote:
> Ah, one of the greatest misconceptions still around in 2012:

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

Misconception: Layers are not recursive. 

Thanks to tunneling/MPLS/other encapsulation techniques, they are.


From garrett at skjelstad.org  Fri Feb 17 13:58:10 2012
From: garrett at skjelstad.org (Garrett Skjelstad)
Date: Fri, 17 Feb 2012 11:58:10 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
Message-ID: <4A58EA87-1BAC-4AAA-BBD1-7DBBCFD45F54@skjelstad.org>

You must have a pre-dotcom bubble datacenter...

Sent from my iPhone

On Feb 17, 2012, at 10:52, Leigh Porter <leigh.porter at ukbroadband.com> wrote:

> 
> On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
> 
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't 
>> let vendor specificity scare you off.
> 
> Pizza, condoms and headache tablets.
> 
> -- 
> Leigh
> 
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> 


From jason at thebaughers.com  Fri Feb 17 14:00:46 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Fri, 17 Feb 2012 14:00:46 -0600
Subject: Colo Vending Machine
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
Message-ID: <4F3EB1EE.4000902@thebaughers.com>

Better double the size of the colo to accommodate the rows upon rows of 
vending machines filled with all the stuff you would have brought with 
you if you'd planned ahead.




From leigh.porter at ukbroadband.com  Fri Feb 17 14:05:20 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 17 Feb 2012 20:05:20 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>

Did anybody say beer yet?

-- 
Leigh


On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

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


From alter3d at alter3d.ca  Fri Feb 17 14:06:43 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Fri, 17 Feb 2012 15:06:43 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
Message-ID: <4F3EB353.10708@alter3d.ca>

On 12-02-17 03:05 PM, Leigh Porter wrote:
> Did anybody say beer yet?
>

Don't forget the 30lb sledgehammer for those times when, ah, "percussive 
maintenance" is the only possible solution.  ;)

(Might be a bit hard to fit into a vending machine though... maybe the 
colo staff could just rent one out...)

- Pete



From cvuljanic at gmail.com  Fri Feb 17 14:10:50 2012
From: cvuljanic at gmail.com (Craig)
Date: Fri, 17 Feb 2012 15:10:50 -0500
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <078201ccedad$111efb70$335cf250$@com>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
 <37473.1329503795@turing-police.cc.vt.edu>
 <20120217185408.GA96943@ussenterprise.ufp.org>
 <078201ccedad$111efb70$335cf250$@com>
Message-ID: <CAJ=P5aZsjAj=jqZgXAtYYc_WW8pmkJStmPmPTqo9bQKWbWao+A@mail.gmail.com>

Some longer term players, will use delayed data as they are trading longer
term, and dont care too much so if the orders were delayed a bit more,
these players most likely wouldn't care/notice.

But also you have to consider, there are a large degree of shorter term
players, who are in/out of the market and play both sides, these do have
real-time data feeds, and do care about latency. Some shops go as far as to
only use a certain length patch cables from their trading PC to the switch
port they are connected to. Also consider when news releases are announced,
the markets often do move quite fast, and a LOT of money can be made/lost
in seconds, so delaying the orders, could and would affect the outcome of
the trades.

Also consider that a vast majority of the trades are automated by
computers, and some want their servers setup as close to the exchange as
possible, in fact the CME group released that they will offer/lease data
center space:

"One such project is a 428,000-square-foot data center in the western
suburbs of Chicago opened by the CME Group, which owns the Chicago
Mercantile Exchange<http://topics.nytimes.com/top/reference/timestopics/organizations/c/chicago_mercantile_exchange/index.html?inline=nyt-org>.
It houses the exchange?s Globex electronic futures and options trading
platform and space for traders to install computers next to the exchange?s
machines, a practice known as co-location ? at a cost of about $25,000 a
month per rack of computers."

http://www.nytimes.com/2011/01/02/business/02speed.html?pagewanted=all

http://www.datacenterknowledge.com/archives/2010/08/23/cme-group-opens-chicago-trading-hub/







On Fri, Feb 17, 2012 at 2:47 PM, Kiriki Delany <kiriki at streamguys.com>wrote:

> Why not just simultaneously settle all trades at the same time? Once every
> minute, or every 5 minutes, or per day?
>
> There are many solutions to the problem. I'm sure those that can take
> advantage of the latency don't want the solution.
>
>
> Kiriki Delany
>
> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> Sent: Friday, February 17, 2012 10:54 AM
> To: NANOG
> Subject: Re: Hi speed trading - hi speed monitoring
>
> In a message written on Fri, Feb 17, 2012 at 01:36:35PM -0500,
> Valdis.Kletnieks at vt.edu wrote:
> > Am I the only one who thinks that if network jitter can make you fall
> > outside the acceptable price window, maybe, just maybe,  the market is
> > just too damned volatile for its own good?
>
> I've had an interesting discussion with some financial heads about a simple
> idea.
>
> What if the exchange, on every inbound trade, inserted a random delay, say
> between 0 and 60 seconds, before processing it?
>
> Almost all of this computer based, let's be closer to the exchange stuff
> becomes junk, immediately.  Anyone "long" (where long is probably more than
> 10 minutes, with a 60 second jitter) in a security wouldn't notice.
>
> I mean, if the general public has to get 15 minute delayed quotes so they
> don't manipulate the market, shouldn't the big guys? :)
>
> --
>       Leo Bicknell - bicknell at ufp.org - CCIE 3440
>        PGP keys at http://www.ufp.org/~bicknell/
>
>
>

From joelja at bogus.com  Fri Feb 17 14:11:24 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Fri, 17 Feb 2012 12:11:24 -0800
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <078201ccedad$111efb70$335cf250$@com>
References: <14641915.3369.1329492633531.JavaMail.root@benjamin.baylink.com>
 <1AE1F810-452C-45A9-83C9-2110ECF155D6@gmail.com>
 <37473.1329503795@turing-police.cc.vt.edu>
 <20120217185408.GA96943@ussenterprise.ufp.org>
 <078201ccedad$111efb70$335cf250$@com>
Message-ID: <4F3EB46C.3070206@bogus.com>

On 2/17/12 11:47 , Kiriki Delany wrote:
> Why not just simultaneously settle all trades at the same time? Once every
> minute, or every 5 minutes, or per day? 
> 
> There are many solutions to the problem. I'm sure those that can take
> advantage of the latency don't want the solution. 

Ask yourself where the incentives are that drive the observed behavior.

> 
> Kiriki Delany
> 
> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org] 
> Sent: Friday, February 17, 2012 10:54 AM
> To: NANOG
> Subject: Re: Hi speed trading - hi speed monitoring
> 
> In a message written on Fri, Feb 17, 2012 at 01:36:35PM -0500,
> Valdis.Kletnieks at vt.edu wrote:
>> Am I the only one who thinks that if network jitter can make you fall 
>> outside the acceptable price window, maybe, just maybe,  the market is 
>> just too damned volatile for its own good?
> 
> I've had an interesting discussion with some financial heads about a simple
> idea.
> 
> What if the exchange, on every inbound trade, inserted a random delay, say
> between 0 and 60 seconds, before processing it?
> 
> Almost all of this computer based, let's be closer to the exchange stuff
> becomes junk, immediately.  Anyone "long" (where long is probably more than
> 10 minutes, with a 60 second jitter) in a security wouldn't notice.
> 
> I mean, if the general public has to get 15 minute delayed quotes so they
> don't manipulate the market, shouldn't the big guys? :)
> 



From bruns at 2mbit.com  Fri Feb 17 14:12:23 2012
From: bruns at 2mbit.com (Brielle Bruns)
Date: Fri, 17 Feb 2012 13:12:23 -0700
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217185558.GB96943@ussenterprise.ufp.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
Message-ID: <4F3EB4A7.9060705@2mbit.com>

On 2/17/12 11:55 AM, Leo Bicknell wrote:
> USB->Serial adapters.  Preferably selected so they are driverless on
> both OSX and Windows.:)

If you preinstall the Prolific PL-2303 (either commercial or open source 
driver version, at least on Mac) or MOSChip, you'll have drivers for 99% 
of the USB to serial adapters out there.

I still long for the day when someone makes a true 16550 based USB to 
serial adapter...   Some of the stuff I need to reprogram at the shop at 
times does not like the cheapie chips that are most common  - I've 
bricked an APC network manager card at least once for that specific 
reason...


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org


From meirea at charterschoolit.com  Fri Feb 17 14:13:16 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Fri, 17 Feb 2012 20:13:16 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>,
 <CFCBD44E-2743-4117-A192-6159D7B04D91@ukbroadband.com>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C054ECD@CSIT-SRV-MBX-01.charterschoolit.local>

Don't forget the lube.

Mario Eirea
________________________________________
From: Leigh Porter [leigh.porter at ukbroadband.com]
Sent: Friday, February 17, 2012 1:52 PM
To: Jay Ashworth
Cc: NANOG
Subject: Re: WW: Colo Vending Machine

On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

Pizza, condoms and headache tablets.

--
Leigh



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



From jeff-kell at utc.edu  Fri Feb 17 14:13:33 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 17 Feb 2012 15:13:33 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
Message-ID: <4F3EB4ED.208@utc.edu>

Direct phone number of a 2nd level TAC that speaks English and doesn't
read from a transcript :)

Lots of good mentions, I might add two...

(1) Snap-on multitool plier (or linesman equivalent), combination
plier/diags/various screwdrivers, etc.
(2) Universal power brick

On the last one above, I arrived at GFIRST last year, opened up laptop
to check for WiFi, and Ooops!  no power brick.  After debating Dell and
FedEx and other disgusting options, there was a BestBuy vending machine
at the Gaylord that included... you guessed it...

So in addition to the parts/supplies you may need onsite, there's always
the issue of what you forgot to stuff in the jump bag before you hit the
road...

Jeff


From randy at psg.com  Fri Feb 17 14:16:24 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 17 Feb 2012 12:16:24 -0800
Subject: Colo Vending Machine
In-Reply-To: <4F3EB1EE.4000902@thebaughers.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <4F3EB1EE.4000902@thebaughers.com>
Message-ID: <m2ipj55i7b.wl%randy@psg.com>

i just want to pay a compliment to the fibercloud colo in the seattle
westin.  there are crash carts, a tool-chest, rack screws, other screws,
garbage cans, ...  and, if you are polite, they'll loan you usbs, blank
cds, ...  and, as remote hands, they are smarter than i.  oops, maybe
that's not a compliment.

randy


From jra at baylink.com  Fri Feb 17 14:19:22 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 15:19:22 -0500 (EST)
Subject: Hi speed trading - hi speed monitoring
In-Reply-To: <CAJ=P5aZsjAj=jqZgXAtYYc_WW8pmkJStmPmPTqo9bQKWbWao+A@mail.gmail.com>
Message-ID: <6254931.3489.1329509962173.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Craig" <cvuljanic at gmail.com>

> But also you have to consider, there are a large degree of shorter term
> players, who are in/out of the market and play both sides, these do have
> real-time data feeds, and do care about latency. Some shops go as far as to
> only use a certain length patch cables from their trading PC to the switch
> port they are connected to. Also consider when news releases are announced,
> the markets often do move quite fast, and a LOT of money can be made/lost
> in seconds, so delaying the orders, could and would affect the outcome of
> the trades.

Sure.  We're simply asserting that those people serve no useful social
function, and we don't *care* whether their needs are served or not.

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


From leigh.porter at ukbroadband.com  Fri Feb 17 14:24:33 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 17 Feb 2012 20:24:33 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EB353.10708@alter3d.ca>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>,
 <4F3EB353.10708@alter3d.ca>
Message-ID: <324F8B04-F4B6-489F-B1DE-6B48AFE110C3@ukbroadband.com>


On 17 Feb 2012, at 20:10, "Peter Kristolaitis" <alter3d at alter3d.ca> wrote:

> On 12-02-17 03:05 PM, Leigh Porter wrote:
>> Did anybody say beer yet?
>> 
> 
> Don't forget the 30lb sledgehammer for those times when, ah, "percussive maintenance" is the only possible solution.  ;)
> 
> (Might be a bit hard to fit into a vending machine though... maybe the colo staff could just rent one out...)
> 
> - Pete
> 

Ahh yes, I recently used a universal adjuster to assist with some installation issues..

Another handy item would be little packets of pixie dust for when things just don't work,,

--
Leigh


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


From leigh.porter at ukbroadband.com  Fri Feb 17 14:27:37 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 17 Feb 2012 20:27:37 +0000
Subject: Colo Vending Machine
In-Reply-To: <m2ipj55i7b.wl%randy@psg.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <4F3EB1EE.4000902@thebaughers.com>,<m2ipj55i7b.wl%randy@psg.com>
Message-ID: <59D9D590-FE3E-4A9B-B854-2039DC4A910A@ukbroadband.com>


On 17 Feb 2012, at 20:18, "Randy Bush" <randy at psg.com> wrote:

> i just want to pay a compliment to the fibercloud colo in the seattle
> westin.  there are crash carts, a tool-chest, rack screws, other screws,
> garbage cans, ...  and, if you are polite, they'll loan you usbs, blank
> cds, ...  and, as remote hands, they are smarter than i.  oops, maybe
> that's not a compliment.
> 
> randy

There used to me a guy called Mike at telecity NY (25 Broadway) who was just fantastic. With mike and the radio shack next door there was not much that could not be fixed.

Mike, wherever you are now, kudos!

--
Leigh


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


From gary.buhrmaster at gmail.com  Fri Feb 17 14:25:55 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Fri, 17 Feb 2012 20:25:55 +0000
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <CAMfXtQzmprWaO7z2RYmjYbJhQ1P+0wLNwqmChqBsV25ds9yVTA@mail.gmail.com>
 <4F3E9475.1050106@utc.edu>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0778@RWC-MBX1.corp.seven.com>
Message-ID: <CAMfXtQyb9aAMZYvdf_-Y7u+kRG_6gfS5pvakeP72YFm7UooXFw@mail.gmail.com>

On Fri, Feb 17, 2012 at 18:06, George Bonser <gbonser at seven.com> wrote:
....
> Fry's wanted $55 for a 1 meter LC-LC multi-mode patch cord yesterday at the store on Arques in Sunnyvale.

Admittedly high, but in the same store, one set of rows to the
left (as you were looking at the fibres) they sell 12-24 rack
screws for something like $10/bag of 12.  Now *that* is
markup.


From bhmccie at gmail.com  Fri Feb 17 14:26:15 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 14:26:15 -0600
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
Message-ID: <4F3EB7E7.1040004@gmail.com>

Still buzzing over that cheap auto insurance eh? :) Wait till people 
stop carding you.....

-Hammer-

"I was a normal American nerd"
-Jack Herer



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


From rps at maine.edu  Fri Feb 17 14:40:37 2012
From: rps at maine.edu (Ray Soucy)
Date: Fri, 17 Feb 2012 15:40:37 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F3EB7E7.1040004@gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
 <4F3EB7E7.1040004@gmail.com>
Message-ID: <CALFTrnP=GUpGQZ1PuS97PjfMX23ezzY6mGBjFyRF9F58_MDXnA@mail.gmail.com>

Maybe ;-)

I don't think it's an age thing, though.

The number of people who have a real interest in technology, and how
things work "under the hood" hasn't changed much.  I know people 10
years younger than me who can keep up with the best of us, and people
10 years older who are complete failures at technology.  People like
us have always been a fairly small number.

What has changed, though, is that there are a lot more young people
who think they have technology skills; perhaps as a side effect of
growing up in a world where the Internet has always been there.
Naturally, we have a lot of people filling IT spots that aren't
qualified and lack the basic knowledge of how complex systems are
built.   To troubleshoot effectively, you need to be able to break
down systems into their components and isolate the problem; and a lot
of people just don't have the background to be able to do that because
they never cared to do so.  It's just a paycheck to them.

Those of us in my age group were lucky enough to be around for the
transition from dial-up BBS, to dial-up Internet, to broadband.  As a
networking geek I don't think I could ask for a better year to be
born, really.  It's always been exciting.

These days I'm playing with DWDM and a state wide R&E network in a
state that established dark fiber as a public utility; doesn't get
much better than that.

I'd say the future is pretty bright. ;-)




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



-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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


From bonomi at mail.r-bonomi.com  Fri Feb 17 14:45:58 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Fri, 17 Feb 2012 14:45:58 -0600 (CST)
Subject: WW: Colo Vending Machine
In-Reply-To: <324F8B04-F4B6-489F-B1DE-6B48AFE110C3@ukbroadband.com>
Message-ID: <201202172045.q1HKjwLO066156@mail.r-bonomi.com>


Leigh Porter <leigh.porter at ukbroadband.com> wrote;
> On 17 Feb 2012, at 20:10, "Peter Kristolaitis" <alter3d at alter3d.ca> wrote:
> > On 12-02-17 03:05 PM, Leigh Porter wrote:
> >> Did anybody say beer yet?

I think it's safe to say that the Datacenter operators generally want customer
visits to be as un-beer-able as they can make it.

> > Don't forget the 30lb sledgehammer for those times when, ah, "percussive 
> > maintenance" is the only possible solution.  ;)
> > 
> > (Might be a bit hard to fit into a vending machine though... maybe the 
> > colo staff could just rent one out...)
> > 
> > - Pete
> > 
>
> Ahh yes, I recently used a universal adjuster to assist with some installation issues..
>
> Another handy item would be little packets of pixie dust for when things just 
> don't work,,

Speaking of _that_, add to the list the traditional item(s)z for debugging SCSI
problems.




From bhmccie at gmail.com  Fri Feb 17 14:48:58 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Fri, 17 Feb 2012 14:48:58 -0600
Subject: Common operational misconceptions
In-Reply-To: <CALFTrnP=GUpGQZ1PuS97PjfMX23ezzY6mGBjFyRF9F58_MDXnA@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <CALFTrnMV4j_eSefgMqj-jNV9k0YDunT-bwQCsnO6+-RNX9esnw@mail.gmail.com>
 <4F3EB7E7.1040004@gmail.com>
 <CALFTrnP=GUpGQZ1PuS97PjfMX23ezzY6mGBjFyRF9F58_MDXnA@mail.gmail.com>
Message-ID: <4F3EBD3A.1070607@gmail.com>

I couldn't argue with any of that. Again, there are exceptions on either 
side.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 2:40 PM, Ray Soucy wrote:
> Maybe ;-)
>
> I don't think it's an age thing, though.
>
> The number of people who have a real interest in technology, and how
> things work "under the hood" hasn't changed much.  I know people 10
> years younger than me who can keep up with the best of us, and people
> 10 years older who are complete failures at technology.  People like
> us have always been a fairly small number.
>
> What has changed, though, is that there are a lot more young people
> who think they have technology skills; perhaps as a side effect of
> growing up in a world where the Internet has always been there.
> Naturally, we have a lot of people filling IT spots that aren't
> qualified and lack the basic knowledge of how complex systems are
> built.   To troubleshoot effectively, you need to be able to break
> down systems into their components and isolate the problem; and a lot
> of people just don't have the background to be able to do that because
> they never cared to do so.  It's just a paycheck to them.
>
> Those of us in my age group were lucky enough to be around for the
> transition from dial-up BBS, to dial-up Internet, to broadband.  As a
> networking geek I don't think I could ask for a better year to be
> born, really.  It's always been exciting.
>
> These days I'm playing with DWDM and a state wide R&E network in a
> state that established dark fiber as a public utility; doesn't get
> much better than that.
>
> I'd say the future is pretty bright. ;-)
>
>
>
>
> On Fri, Feb 17, 2012 at 3:26 PM, -Hammer-<bhmccie at gmail.com>  wrote:
>> Still buzzing over that cheap auto insurance eh? :) Wait till people stop
>> carding you.....
>>
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 1:42 PM, Ray Soucy wrote:
>>> As someone who was born in 1984 I respectfully disagree. ;-)
>>>
>>>
>>>
>>>
>>> On Fri, Feb 17, 2012 at 9:52 AM, -Hammer-<bhmccie at gmail.com>    wrote:
>>>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>>>
>>>> Yes, I'm going to get flamed. Yes, there are exceptions in both
>>>> directions.
>>>>
>>>>
>>>> -Hammer-
>>>>
>>>> "I was a normal American nerd"
>>>> -Jack Herer
>>>>
>>>>
>>>>
>>>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
>>>>> Graydon wrote:
>>>>>> At the same time, it's shocking how many network people I come across
>>>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>>>> only in theory.  Just having a grasp of that makes all the world of
>>>>>> difference when it comes to troubleshooting.  Start at layer 1 and work
>>>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>>>> physically connected? Are the link lights flashing? Can traffic route
>>>>>> to
>>>>>> it, etc. etc.
>>>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>>>> comment.  I would venture over 90% of the engineers I work with
>>>>> have no idea how to troubleshoot properly.  Thinking back to my own
>>>>> education, I don't recall anyone in highschool or college attempting
>>>>> to teach troubleshooting skills.  Most classes teach you how to
>>>>> build things, not deal with them when they are broken.
>>>>>
>>>>> The basic skills are probably obvious to someone who might design
>>>>> course material if they sat down and thought about how to teach
>>>>> troubleshooting.  However, there is one area that may not be obvious.
>>>>> There's also a group management problem.  Many times troubleshooting
>>>>> is done with multiple folks on the phone (say, customer, ISP and
>>>>> vendor).  Not only do you have to know how to troubleshoot, but how
>>>>> to get everyone on the same page so every possible cause isn't
>>>>> tested 3 times.
>>>>>
>>>>> I think all college level courses should include a "break/fix"
>>>>> exercise/module after learning how to build something, and much of that
>>>>> should be done in a group enviornment.
>>>>>
>>>
>
>


From johnl at iecc.com  Fri Feb 17 14:58:39 2012
From: johnl at iecc.com (John Levine)
Date: 17 Feb 2012 20:58:39 -0000
Subject: Spam from Telx
In-Reply-To: <4F3E5D8D.60403@foobar.org>
Message-ID: <20120217205839.74976.qmail@joyce.lan>

In article <4F3E5D8D.60403 at foobar.org> you write:
>So, anyone else get spammed by Telx after posting to nanog?

Yes.

-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From eric at usf.edu  Fri Feb 17 15:06:33 2012
From: eric at usf.edu (Eric Stewart)
Date: Fri, 17 Feb 2012 16:06:33 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EB353.10708@alter3d.ca>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
 <4F3EB353.10708@alter3d.ca>
Message-ID: <4F3EC159.5090402@usf.edu>

On 2/17/2012 3:06 PM, Peter Kristolaitis wrote:
> Don't forget the 30lb sledgehammer for those times when, ah, 
> "percussive maintenance" is the only possible solution.  ;)

My previous job had me managing our presence in a data center.  For 
several months, in the row of racks across the hot aisle from ours, 
there was another customer of the data center who had apparently decided 
to only plug in one of the two power supplies for some drive array they 
had ... which resulted in a nice, steady beep.  While not excessively 
loud, you could still make it out from several rows away.  For those 
months, within five minutes of being in the data center, I wanted to 
perform percussive maintenance ... first on that equipment, then on the 
idiot who let it go for more than day beeping like that.

-- 
Eric Stewart - Network Administrator - eric at usf.edu
University of South Florida, Information Technology



From mark at noc.mainstreet.net  Fri Feb 17 15:13:11 2012
From: mark at noc.mainstreet.net (Mark Kent)
Date: Fri, 17 Feb 2012 13:13:11 -0800 (PST)
Subject: NANOG Digest... digest or closer to IM?
Message-ID: <201202172113.q1HLDB4T082808@mainstreet.net>

I got 29 NANOG Digest messages in the past 24 hours.

Where are those people who have time to complain about the noise on
this list?  Did they all leave?   Is anyone else willing to take up
the cause?

-mark


From johnl at iecc.com  Fri Feb 17 15:21:37 2012
From: johnl at iecc.com (John Levine)
Date: 17 Feb 2012 21:21:37 -0000
Subject: NANOG Digest... digest or closer to IM?
In-Reply-To: <201202172113.q1HLDB4T082808@mainstreet.net>
Message-ID: <20120217212137.75768.qmail@joyce.lan>

>I got 29 NANOG Digest messages in the past 24 hours.
>
>Where are those people who have time to complain about the noise on
>this list?  Did they all leave?   Is anyone else willing to take up
>the cause?

Maybe we've finally all learned how to make our mail programs sort the
mail.

R's,
John


From george at montco.net  Fri Feb 17 15:44:35 2012
From: george at montco.net (George Carey)
Date: Fri, 17 Feb 2012 16:44:35 -0500
Subject: Colo Vending Machine
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
Message-ID: <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>


> 
> The vending machine should use a card like an ATM/gift card, not accept cash.  You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space.  If something is needed, one can purchase it with the card.  If there is no money on the card, a person can add cash to the card via a web portal somewhere.   Scenario:  remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.
> 
> 

Actually pricing should be 8 bits, 16 bits, or maybe 32 bits for the really important stuff.

George

From james.cutler at consultant.com  Fri Feb 17 14:45:32 2012
From: james.cutler at consultant.com (Cutler James R)
Date: Fri, 17 Feb 2012 15:45:32 -0500
Subject: Common operational misconceptions
In-Reply-To: <B79A92E9-C1EE-4ED6-AC2E-E704B98E446F@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <B79A92E9-C1EE-4ED6-AC2E-E704B98E446F@delong.com>
Message-ID: <12E803A3-E4E0-4B64-B1B3-69EC459DA03D@consultant.com>

On Feb 17, 2012, at 1:35 PM, Owen DeLong wrote:
> On Feb 17, 2012, at 6:52 AM, -Hammer- wrote:
> 
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>> 
> Is this a statement or something to be added to the list of misconceptions that are commonplace out there?
> 
> Not trying to be flip... Honestly asking the question. I can see it going either way, frankly. ;-)
> 
> Owen



Clearly, it is a misconception.  

The effect of aging on trouble-shooting skills is simply the opportunity for gaining experience.

(Personal anecdotes omitted here.  You are welcome.)


James R. Cutler
james.cutler at consultant.com






From jesler at sourcefire.com  Fri Feb 17 15:57:00 2012
From: jesler at sourcefire.com (Joel Esler)
Date: Fri, 17 Feb 2012 16:57:00 -0500
Subject: NANOG Digest... digest or closer to IM?
In-Reply-To: <201202172113.q1HLDB4T082808@mainstreet.net>
References: <201202172113.q1HLDB4T082808@mainstreet.net>
Message-ID: <D34601ED-5F87-4105-A058-E5224B6DFB4A@sourcefire.com>

I think you just volunteered.  

--
Joel Esler

On Feb 17, 2012, at 4:13 PM, Mark Kent <mark at noc.mainstreet.net> wrote:

> I got 29 NANOG Digest messages in the past 24 hours.
> 
> Where are those people who have time to complain about the noise on
> this list?  Did they all leave?   Is anyone else willing to take up
> the cause?
> 
> -mark
> 


From cidr-report at potaroo.net  Fri Feb 17 16:00:01 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 17 Feb 2012 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201202172200.q1HM01Le042551@wattle.apnic.net>

BGP Update Report
Interval: 09-Feb-12 -to- 16-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            83278  3.8%      38.5 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS9829            39627  1.8%      42.3 -- BSNL-NIB National Internet Backbone
 3 - AS12479           27469  1.2%     143.8 -- UNI2-AS France Telecom Espana SA
 4 - AS7029            23227  1.1%       8.1 -- WINDSTREAM - Windstream Communications Inc
 5 - AS32528           23027  1.0%    4605.4 -- ABBOTT Abbot Labs
 6 - AS18566           20515  0.9%      10.1 -- COVAD - Covad Communications Co.
 7 - AS23154           20477  0.9%    5119.2 -- SANMINA-SCI Sanmina-SCI Corporation
 8 - AS5800            20237  0.9%      71.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 9 - AS20632           20074  0.9%    2867.7 -- PETERSTAR-AS PeterStar
10 - AS2118            18881  0.9%      25.5 -- RELCOM-AS OOO "NPO Relcom"
11 - AS7552            16504  0.8%      12.4 -- VIETEL-AS-AP Vietel Corporation
12 - AS1785            16340  0.7%      11.1 -- AS-PAETEC-NET - PaeTec Communications, Inc.
13 - AS17974           15974  0.7%      10.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
14 - AS31148           14804  0.7%      22.2 -- FREENET-AS FreeNet ISP
15 - AS7011            14325  0.7%      12.7 -- FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc.
16 - AS3816            13684  0.6%      60.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP
17 - AS5976            13460  0.6%     137.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - AS9498            12924  0.6%      40.6 -- BBIL-AP BHARTI Airtel Ltd.
19 - AS24560           12866  0.6%      19.2 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services
20 - AS6713            12595  0.6%      27.8 -- IAM-AS


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126           10943  0.5%   10943.0 -- DATIQ-AS Datiq B.V.
 2 - AS6066            11963  0.5%    5981.5 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 3 - AS23154           20477  0.9%    5119.2 -- SANMINA-SCI Sanmina-SCI Corporation
 4 - AS32528           23027  1.0%    4605.4 -- ABBOTT Abbot Labs
 5 - AS13277            7914  0.4%    3957.0 -- HP-MS HP-MS Autonomous System
 6 - AS17408            3353  0.1%    3353.0 -- ABOVE-AS-AP AboveNet Communications Taiwan
 7 - AS1997             2997  0.1%    2997.0 -- IBMDES-AS - IBM Dallas Engineering & Scientific
 8 - AS20632           20074  0.9%    2867.7 -- PETERSTAR-AS PeterStar
 9 - AS16536            1805  0.1%    1805.0 -- HPES - Hewlett-Packard Company
10 - AS8163             1267  0.1%    1267.0 -- METROTEL REDES S.A.
11 - AS57228            1157  0.1%    1157.0 -- IMTECH-ICT-UK-AS Imtech ICT Limited
12 - AS35411            4219  0.2%    1054.8 -- SIBINET-AS Sibinet, Ltd. Autonomous System
13 - AS24666            3868  0.2%     967.0 -- AXA-AS AXA Luxembourg S.A
14 - AS5868              938  0.0%     938.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
15 - AS53362             926  0.0%     926.0 -- MIXIT-AS - Mixit, Inc.
16 - AS17412             906  0.0%     906.0 -- WOOSHWIRELESSNZ Woosh Wireless
17 - AS12163            3370  0.1%     842.5 -- BNSI - Broadband Network Services, Inc.
18 - AS25379             748  0.0%     748.0 -- PROF-TEL-COMM-AS Prof-Tel-Comm Ltd.
19 - AS49466             692  0.0%     692.0 -- DECLIC-TELECOM Declic Telecom SAS
20 - AS21271             601  0.0%     601.0 -- SOTELMABGP


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 148.164.14.0/24   20441  0.9%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 2 - 84.204.132.0/24   20043  0.8%   AS20632 -- PETERSTAR-AS PeterStar
 3 - 130.36.34.0/24    11503  0.5%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11503  0.5%   AS32528 -- ABBOTT Abbot Labs
 5 - 202.92.235.0/24   11081  0.5%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 6 - 217.170.24.0/21   10943  0.5%   AS29126 -- DATIQ-AS Datiq B.V.
 7 - 62.36.252.0/22     8519  0.4%   AS12479 -- UNI2-AS France Telecom Espana SA
 8 - 190.67.172.0/22    7016  0.3%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
 9 - 62.36.249.0/24     6425  0.3%   AS12479 -- UNI2-AS France Telecom Espana SA
10 - 150.225.0.0/16     5984  0.2%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
11 - 204.29.239.0/24    5979  0.2%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
12 - 62.36.241.0/24     5841  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 62.36.210.0/24     5593  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
14 - 190.67.168.0/22    5077  0.2%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP
15 - 194.63.9.0/24      4739  0.2%   AS1273  -- CW Cable and Wireless Worldwide plc
16 - 109.197.120.0/21   4188  0.2%   AS35411 -- SIBINET-AS Sibinet, Ltd. Autonomous System
17 - 205.73.118.0/24    4069  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - 205.73.116.0/23    3973  0.2%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
19 - 194.209.13.0/24    3957  0.2%   AS13277 -- HP-MS HP-MS Autonomous System
20 - 194.209.211.0/24   3957  0.2%   AS13277 -- HP-MS HP-MS Autonomous System

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb 17 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 17 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202172200.q1HM006P042543@wattle.apnic.net>

This report has been generated at Fri Feb 17 21:12:44 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        10-02-12    398957      231485
        11-02-12    399566      231603
        12-02-12    399566      231622
        13-02-12    399583      231893
        14-02-12    400024      232174
        15-02-12    400553      232435
        16-02-12    400822      232740
        17-02-12    400903      232934


AS Summary
         40244  Number of ASes in routing system
         16844  Number of ASes announcing only one prefix
          3440  Largest number of prefixes announced by an AS
                AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
      109997568  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 17Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     401035   232916   168119    41.9%   All ASes

AS6389      3440      204     3236    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3430     1726     1704    49.7%   WINDSTREAM - Windstream
                                               Communications Inc
AS18566     2091      413     1678    80.2%   COVAD - Covad Communications
                                               Co.
AS4766      2489     1012     1477    59.3%   KIXS-AS-KR Korea Telecom
AS22773     1527      119     1408    92.2%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS2118      1399       14     1385    99.0%   RELCOM-AS OOO "NPO Relcom"
AS4323      1609      386     1223    76.0%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1671      460     1211    72.5%   NET Servicos de Comunicao S.A.
AS4755      1546      406     1140    73.7%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1872      793     1079    57.6%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1389      399      990    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS7552      1271      308      963    75.8%   VIETEL-AS-AP Vietel
                                               Corporation
AS10620     1738      779      959    55.2%   Telmex Colombia S.A.
AS7303      1264      372      892    70.6%   Telecom Argentina S.A.
AS26615      862       33      829    96.2%   Tim Celular S.A.
AS8151      1475      665      810    54.9%   Uninet S.A. de C.V.
AS4808      1149      345      804    70.0%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS8402      1700      904      796    46.8%   CORBINA-AS OJSC "Vimpelcom"
AS18101      951      160      791    83.2%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS24560     1019      326      693    68.0%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS9498       885      204      681    76.9%   BBIL-AP BHARTI Airtel Ltd.
AS9394       883      208      675    76.4%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS3356      1098      456      642    58.5%   LEVEL3 Level 3 Communications
AS30036     1400      760      640    45.7%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS17676      681       75      606    89.0%   GIGAINFRA Softbank BB Corp.
AS15557     1098      513      585    53.3%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS17974     1729     1158      571    33.0%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS4804       658       95      563    85.6%   MPX-AS Microplex PTY LTD
AS3549       988      432      556    56.3%   GBLX Global Crossing Ltd.
AS4780       793      238      555    70.0%   SEEDNET Digital United Inc.

Total      44105    13963    30142    68.3%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        37.128.136.0/21      AS12835 INFOTN-AS Trentino Network srl
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        91.235.232.0/24      AS12617 SOLIDO-NET Solido Hosting A/S
        98.159.96.0/20       AS46975 
        103.6.52.0/22        AS45731 ARDH-AS-ID ARDH GLOBAL INDONESIA, PT
        108.175.32.0/24      AS2906  NETFL-HUB-ASN - Netflix Inc
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.33.14.0/23       AS34984 TELLCOM-AS Tellcom Iletisim Hizmetleri
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.9.55.0/24        AS2764  AAPT AAPT Limited
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel Limited.
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.180.240.0/20     AS12083 KNOLOGY-NET - KNOLOGY,  Inc.
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From kauer at biplane.com.au  Fri Feb 17 16:21:08 2012
From: kauer at biplane.com.au (Karl Auer)
Date: Sat, 18 Feb 2012 09:21:08 +1100
Subject: Which way to fold the label (was: Re: time sink 42)
In-Reply-To: <3634669.3367.1329492502370.JavaMail.root@benjamin.baylink.com>
References: <3634669.3367.1329492502370.JavaMail.root@benjamin.baylink.com>
Message-ID: <1329517268.17490.510.camel@karl>

On Fri, 2012-02-17 at 10:28 -0500, Jay Ashworth wrote:
> > What?!? Forward instead of backward? KILL THE UNBELIEVER! KILL! KILL!
> 
> Way to misquote me, Karl.  :-)

Ayup! :-)

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120218/addc9154/attachment.bin>

From rodrick.brown at gmail.com  Fri Feb 17 16:22:03 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Fri, 17 Feb 2012 17:22:03 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>

On Feb 17, 2012, at 1:35 PM, Jay Ashworth <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.
> 

atom based 10" laptop with serial interface and cable. $15 day charge would rock! 

4 Port 10/100/1000 hub. $20? 

USB sticks  2/4/8GB

Cage nuts various common sizes. 

Vending machine should double as wireless AP with open Internet access $5 should give you AP code and min 8 hour access time. 

Sent from my iPhone.

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


From jason at thebaughers.com  Fri Feb 17 16:55:43 2012
From: jason at thebaughers.com (Jason Baugher)
Date: Fri, 17 Feb 2012 16:55:43 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
Message-ID: <4F3EDAEF.1020909@thebaughers.com>

Do you guys ride your bike to the colo and show up in shorts and a 
t-shirt? Who goes to the colo without things like their laptop?


On 2/17/2012 4:22 PM, Rodrick Brown wrote:
> On Feb 17, 2012, at 1:35 PM, Jay Ashworth<jra at baylink.com>  wrote:
>
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>>
> atom based 10" laptop with serial interface and cable. $15 day charge would rock!
>
> 4 Port 10/100/1000 hub. $20?
>
> USB sticks  2/4/8GB
>
> Cage nuts various common sizes.
>
> Vending machine should double as wireless AP with open Internet access $5 should give you AP code and min 8 hour access time.
>
> Sent from my iPhone.
>
>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth                  Baylink                       jra at baylink.com
>> Designer                     The Things I Think                       RFC 2100
>> Ashworth&  Associates     http://baylink.pitas.com         2000 Land Rover DII
>> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>>
>



From rodrick.brown at gmail.com  Fri Feb 17 17:02:06 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Fri, 17 Feb 2012 18:02:06 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EDAEF.1020909@thebaughers.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
Message-ID: <F42CBCCB-C2E5-4423-8CB5-81CECCE466C9@gmail.com>

On Feb 17, 2012, at 5:55 PM, Jason Baugher <jason at thebaughers.com> wrote:

> Do you guys ride your bike to the colo and show up in shorts and a t-shirt? Who goes to the colo without things like their laptop?
> 

Think of it as one less thing to carry to carry to the colo :-)


> 
> On 2/17/2012 4:22 PM, Rodrick Brown wrote:
>> On Feb 17, 2012, at 1:35 PM, Jay Ashworth<jra at baylink.com>  wrote:
>> 
>>> Please post your top 3 favorite components/parts you'd like to see in a
>>> vending machine at your colo; please be as specific as possible; don't
>>> let vendor specificity scare you off.
>>> 
>> atom based 10" laptop with serial interface and cable. $15 day charge would rock!
>> 
>> 4 Port 10/100/1000 hub. $20?
>> 
>> USB sticks  2/4/8GB
>> 
>> Cage nuts various common sizes.
>> 
>> Vending machine should double as wireless AP with open Internet access $5 should give you AP code and min 8 hour access time.
>> 
>> Sent from my iPhone.
>> 
>>> Cheers,
>>> -- jra
>>> -- 
>>> Jay R. Ashworth                  Baylink                       jra at baylink.com
>>> Designer                     The Things I Think                       RFC 2100
>>> Ashworth&  Associates     http://baylink.pitas.com         2000 Land Rover DII
>>> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>>> 
>> 
> 
> 


From nanog at maunier.org  Fri Feb 17 17:15:44 2012
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Sat, 18 Feb 2012 00:15:44 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>

2012/2/17 Jay Ashworth <jra at baylink.com>

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
>
>
1 - As previously said : LC/SC couplers + patchcords
2 - fibre/connectors cleaning kit
3 - SC/LC optical attenuators
4 - Laser pen that can send visible red beam in blink/continuous mode
5 - as said previously too : USB-RS232 adaptator
6 - plastic cable clamps (don't know the exact english term for that but I
mean this -->
http://www.hellopro.fr/images/produit-2/9/3/8/serre-cables-261839.jpg)
7 - compressed air can to clean dust
8 - CAT5 tester

A good this to be able to borrow from the noc (because a bit problematic to
put then in a vending machine) :

- an Optical Power Meter
- a live fiber detection device (to be able to detect presence of light and
the direction of the light in a fibre without disconnecting it) we use
these at work and they're awesome :
http://www.exfo.com/en/Products/Field-Network-Testing/Optical/Signal-Detection/LFD-300BTG-300B-FiberFinder/
- a plunger (not sure about the english translation for this one too :-) )


-- 
Pierre-Yves Maunier

From aledm at qix.co.uk  Fri Feb 17 17:18:25 2012
From: aledm at qix.co.uk (Aled Morris)
Date: Fri, 17 Feb 2012 23:18:25 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <022801cceda4$11377b90$33a672b0$@truenet.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
 <022801cceda4$11377b90$33a672b0$@truenet.com>
Message-ID: <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>

On 17 February 2012 18:43, Eric Tykwinski <eric-list at truenet.com> wrote:

> +1 for GBICs, SFPs
>
>
You'll need to be carrying a lot of loose change then :-)

My ideal vending machine would dispense Cat5e by the foot, the more you
pull the more you pay, RJ45 plugs in pairs, and a crimp tool on a long
chain (like the way you buy chain in a hardware store)

Aled

From drais at icantclick.org  Fri Feb 17 17:23:14 2012
From: drais at icantclick.org (david raistrick)
Date: Fri, 17 Feb 2012 18:23:14 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>

On Sat, 18 Feb 2012, Pierre-Yves Maunier wrote:

> 6 - plastic cable clamps (don't know the exact english term for that but I
> mean this -->
> http://www.hellopro.fr/images/produit-2/9/3/8/serre-cables-261839.jpg)

also known as "zip tie" or "plastic cable tie" more generically


--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From aledm at qix.co.uk  Fri Feb 17 17:32:26 2012
From: aledm at qix.co.uk (Aled Morris)
Date: Fri, 17 Feb 2012 23:32:26 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
 <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>
Message-ID: <CAO1bj=ZeTGtUHEL5aDb48pLXd+Z+ijer8pYHhewmtY5rf_ypWg@mail.gmail.com>

On 17 February 2012 23:23, david raistrick <drais at icantclick.org> wrote:

> On Sat, 18 Feb 2012, Pierre-Yves Maunier wrote:
>
>  6 - plastic cable clamps (don't know the exact english term for that but I
>> mean this -->
>> http://www.hellopro.fr/images/**produit-2/9/3/8/serre-cables-**261839.jpg<http://www.hellopro.fr/images/produit-2/9/3/8/serre-cables-261839.jpg>
>> )
>>
>
> also known as "zip tie" or "plastic cable tie" more generically
>
>
Though wax string is nicer.

http://www.repsole.com/ProductGroup.asp?PGID=254

Aled

From gbakos at alpinista.org  Fri Feb 17 17:35:34 2012
From: gbakos at alpinista.org (George Bakos)
Date: Fri, 17 Feb 2012 23:35:34 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120217233534.4476ba15@alpinista.org>

Key features required:

Running an OS that can be patched/updated by someone other than the
machine vendor

Deployment in a screened subnet, not trusted by the rest of the
administrative net

(^^I've run into NT4.0 on a vending machine in a physical DMZ!)

RFC 2324 implementation

g

On Fri, 17 Feb 2012 13:35:15 -0500 (EST)
Jay Ashworth <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
> 


-- 


From jeff-kell at utc.edu  Fri Feb 17 17:43:08 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Fri, 17 Feb 2012 18:43:08 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <CAO1bj=ZeTGtUHEL5aDb48pLXd+Z+ijer8pYHhewmtY5rf_ypWg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
 <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>
 <CAO1bj=ZeTGtUHEL5aDb48pLXd+Z+ijer8pYHhewmtY5rf_ypWg@mail.gmail.com>
Message-ID: <4F3EE60C.1010308@utc.edu>

On 2/17/2012 6:32 PM, Aled Morris wrote:
> Though wax string is nicer.
> http://www.repsole.com/ProductGroup.asp?PGID=254

Or in less static environments, velcro ties, e.g.,
http://www.cabletiesandmore.com/velcro.php

Jeff



From randy at psg.com  Fri Feb 17 18:07:45 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 17 Feb 2012 16:07:45 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EDAEF.1020909@thebaughers.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
Message-ID: <m2zkch3sxa.wl%randy@psg.com>

> Do you guys ride your bike to the colo and show up in shorts and a 
> t-shirt? Who goes to the colo without things like their laptop?

fools who are willing to type passphrases on others' laptops?

randy


From jra at baylink.com  Fri Feb 17 18:09:03 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 19:09:03 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
Message-ID: <21184089.3557.1329523743081.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Aled Morris" <aledm at qix.co.uk>

> On 17 February 2012 18:43, Eric Tykwinski <eric-list at truenet.com>
> wrote:
> 
> > +1 for GBICs, SFPs

> You'll need to be carrying a lot of loose change then :-)

In fact, vending machines with builtin card readers and radio credit card
validation are stock items these days.

> My ideal vending machine would dispense Cat5e by the foot, the more you
> pull the more you pay, RJ45 plugs in pairs, and a crimp tool on a long
> chain (like the way you buy chain in a hardware store)

"in pairs" is nice; chained crimper -- or more likely "we'll authorize your
card for $60; if you give us back the crimper, we'll only settle for $5".

Not sure how much trouble "cable by the foot" would be, but I like it.

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


From jra at baylink.com  Fri Feb 17 18:11:07 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 17 Feb 2012 19:11:07 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217233534.4476ba15@alpinista.org>
Message-ID: <1188066.3559.1329523867208.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "George Bakos" <gbakos at alpinista.org>

> Key features required:
> 
> Running an OS that can be patched/updated by someone other than the
> machine vendor

I assume you mean the machine proper.  Hopefully that will be a stock unit;
I don't really want to get into building vending machines.  :-)

> Deployment in a screened subnet, not trusted by the rest of the
> administrative net

Direct CDPD (or whatever we're calling that these days.

> RFC 2324 implementation

Definitely.

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


From don at bowenvale.co.nz  Fri Feb 17 18:18:18 2012
From: don at bowenvale.co.nz (Don Gould)
Date: Sat, 18 Feb 2012 13:18:18 +1300
Subject: Simple Cable Marking Standards
Message-ID: <4F3EEE4A.5030100@bowenvale.co.nz>

I would like to make a wiki page with links to useful resources.

This issue cased me problems last week.

I don't know what the conventions are.

I don't know what the best tools are.

I don't know what others are doing.

I don't have good examples.

I am interested specifically in 'very small, edge' examples.

I'm also interested in FLOSS documentation tools for recording set ups, 
pref web based that will translate well to Android.



D


-- 
Don Gould
31 Acheson Ave
Mairehau
Christchurch, New Zealand
Ph: + 64 3 348 7235
Mobile: + 64 21 114 0699



From sven at cb3rob.net  Fri Feb 17 18:17:58 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sat, 18 Feb 2012 00:17:58 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EB4A7.9060705@2mbit.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org> <4F3EB4A7.9060705@2mbit.com>
Message-ID: <Pine.LNX.4.64.1202180015510.32438@a84-22-97-10.cb3rob.net>

>
> I still long for the day when someone makes a true 16550 based USB to serial 
> adapter...   Some of the stuff I need to reprogram at the shop at times does 
> not like the cheapie chips that are most common  - I've bricked an APC 
> network manager card at least once for that specific reason...

says more about the apc network manager card...

if it can't handle rs232 properly... well...
(or, from what i understand from this, doesn't have checksums on its 
firmware files or doesn't check them ;)


From sven at cb3rob.net  Fri Feb 17 18:29:32 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sat, 18 Feb 2012 00:29:32 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202180027420.32438@a84-22-97-10.cb3rob.net>

> 7 - compressed air can to clean dust

dust?!?!? sounds like time to find a whole new colo and move 
everything out of there haha.

i've -never- encountered one with dust in it.

that stuff usually gets sucked out before it gets the idea to land on 
anything should it even get in in the first place


From sven at cb3rob.net  Fri Feb 17 18:31:30 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sat, 18 Feb 2012 00:31:30 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
 <022801cceda4$11377b90$33a672b0$@truenet.com>
 <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202180030070.32438@a84-22-97-10.cb3rob.net>

>
> My ideal vending machine would dispense Cat5e by the foot, the more you
> pull the more you pay, RJ45 plugs in pairs, and a crimp tool on a long
> chain (like the way you buy chain in a hardware store)
>
> Aled
>

except for that -usually- when you -need- the crimp tool, you only know at 
which position to put the connectors after you have laid it in place, and 
then need the crimptool -there-, not at the vending machine.

(usually between racks, for everything else, there is pre-fab patchcables)


From sven at cb3rob.net  Fri Feb 17 18:33:38 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sat, 18 Feb 2012 00:33:38 +0000 (UTC)
Subject: WW: Colo Vending Machine
In-Reply-To: <20120217233534.4476ba15@alpinista.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217233534.4476ba15@alpinista.org>
Message-ID: <Pine.LNX.4.64.1202180032320.32438@a84-22-97-10.cb3rob.net>

rfid scanner for billing through the datacenter bill with your access 
card. (which is linked to your customer id anyway ;)

On Fri, 17 Feb 2012, George Bakos wrote:

> Key features required:
>
> Running an OS that can be patched/updated by someone other than the
> machine vendor
>
> Deployment in a screened subnet, not trusted by the rest of the
> administrative net
>
> (^^I've run into NT4.0 on a vending machine in a physical DMZ!)
>
> RFC 2324 implementation
>
> g
>
> On Fri, 17 Feb 2012 13:35:15 -0500 (EST)
> Jay Ashworth <jra at baylink.com> wrote:
>
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>>
>> Cheers,
>> -- jra
>> --
>> Jay R. Ashworth                  Baylink                       jra at baylink.com
>> Designer                     The Things I Think                       RFC 2100
>> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
>> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>>
>
>
> -- 
>


From gbonser at seven.com  Fri Feb 17 18:36:48 2012
From: gbonser at seven.com (George Bonser)
Date: Sat, 18 Feb 2012 00:36:48 +0000
Subject: Simple Cable Marking Standards
In-Reply-To: <4F3EEE4A.5030100@bowenvale.co.nz>
References: <4F3EEE4A.5030100@bowenvale.co.nz>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD1FDE@RWC-MBX1.corp.seven.com>

> From: Don Gould 
> Sent: Friday, February 17, 2012 4:18 PM
> To: North American Network Operators' Group
> Subject: Simple Cable Marking Standards
> 
> I would like to make a wiki page with links to useful resources.
> 
> This issue cased me problems last week.
> 
> I don't know what the conventions are.
> 
> I don't know what the best tools are.
> 
> I don't know what others are doing.
> 
> I don't have good examples.
> 
> I am interested specifically in 'very small, edge' examples.
> 
> I'm also interested in FLOSS documentation tools for recording set ups,
> pref web based that will translate well to Android.

One thing I will do if I have some spare time at the colo is wander the aisles and see what other folks have done in certain situations.  Many people put some nice work on display, so, admire it and learn from it.  Some of it "looks" really nice but can be a pain to work with, too so you have to consider how it would be to have to pull a blade from that switch that looks really nice at first until you consider having to actually replace anything in that network.




From streiner at cluebyfour.org  Fri Feb 17 18:37:58 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 19:37:58 -0500 (EST)
Subject: Simple Cable Marking Standards
In-Reply-To: <4F3EEE4A.5030100@bowenvale.co.nz>
References: <4F3EEE4A.5030100@bowenvale.co.nz>
Message-ID: <Pine.LNX.4.64.1202171926570.23972@whammy.cluebyfour.org>

On Sat, 18 Feb 2012, Don Gould wrote:

> I would like to make a wiki page with links to useful resources.
> This issue cased me problems last week.
> I don't know what the conventions are.

The conventions often work back to whatever is appropriate in your 
environment.  Some people use TIA/EIA 606-A as a starting point and work 
out from there.  Other shops are much less formal.  Still others do no 
labeling whatsoever.

My employer's standard for copper data and voice wiring was already pretty 
well formed by the time I started.  There really wasn't anything in place 
for fiber, so I developed a standard for naming racks, fiber bays within a 
rack, and connectors within a bay.  Cross-connect information (source 
rack/bay/connector(s), destination rack/bay/connector(s), anong with 
useful items like jumper type/length and any free-form notes, end-to-end 
test results, etc will eventually be stored in a database, using a path 
ID (analogous to a telco circuit ID) that is labeled on each jumper in 
the path and the interface descriptions of the end devices.  It's one of 
those projects I've been wanting to get back to, but workload and 
diminishing DB/development kung-fu have conspired against me so far :(

The long-term goal is to get that all of that accessible from a web app 
that can be access in the field by a tech with a laptop or a mobile 
device.

jms


From streiner at cluebyfour.org  Fri Feb 17 18:40:02 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Fri, 17 Feb 2012 19:40:02 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202180027420.32438@a84-22-97-10.cb3rob.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
 <Pine.LNX.4.64.1202180027420.32438@a84-22-97-10.cb3rob.net>
Message-ID: <Pine.LNX.4.64.1202171938130.23972@whammy.cluebyfour.org>

On Sat, 18 Feb 2012, Sven Olaf Kamphuis wrote:

>>  7 - compressed air can to clean dust
>
> dust?!?!? sounds like time to find a whole new colo and move everything out 
> of there haha.

I also hope that duster can would not be used by someone who is attempting 
to clean fiber end-faces.  Incredibly bad idea.  See a recent thread on 
cisco-nsp.

jms


From dale.shaw+nanog at gmail.com  Fri Feb 17 18:43:27 2012
From: dale.shaw+nanog at gmail.com (Dale Shaw)
Date: Sat, 18 Feb 2012 11:43:27 +1100
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAG_V2876krm_gqAfXgZq-NW-UmZAJyb2kjOE+M=b4CUxnWEW-g@mail.gmail.com>

Hi,

On Feb 18, 2012 5:35 AM, "Jay Ashworth" <jra at baylink.com> wrote:
>
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.

Similar topic with mostly useful ideas here:

http://lists.ausnog.net/pipermail/ausnog/2011-November/011590.html

Cheers,
Dale

From george.herbert at gmail.com  Fri Feb 17 18:51:00 2012
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 17 Feb 2012 16:51:00 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <21184089.3557.1329523743081.JavaMail.root@benjamin.baylink.com>
References: <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
 <21184089.3557.1329523743081.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAK__KzvMvaupPKBCmcp_cDm15oEdjm67=affQvo+hSdmxp2D2Q@mail.gmail.com>

On Fri, Feb 17, 2012 at 4:09 PM, Jay Ashworth <jra at baylink.com> wrote:
> ----- Original Message -----
>> From: "Aled Morris" <aledm at qix.co.uk>
>
>> On 17 February 2012 18:43, Eric Tykwinski <eric-list at truenet.com>
>> wrote:
>>
>> > +1 for GBICs, SFPs
>
>> You'll need to be carrying a lot of loose change then :-)
>
> In fact, vending machines with builtin card readers and radio credit card
> validation are stock items these days.

I was informed just a bit ago that one of the Equinix datacenters in
the SF Bay Area that I haven't been in to yet in fact has an old coke
machine that someone set up with a credit card reader and, among other
things, it apparently dispenses GBICs.

This could be someone playing a game of radio from the conversation
here, but he's not on NANOG (or so he says).


-- 
-george william herbert
george.herbert at gmail.com


From owen at delong.com  Fri Feb 17 18:53:17 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 16:53:17 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <324F8B04-F4B6-489F-B1DE-6B48AFE110C3@ukbroadband.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>,
 <4F3EB353.10708@alter3d.ca>
 <324F8B04-F4B6-489F-B1DE-6B48AFE110C3@ukbroadband.com>
Message-ID: <5583A5B0-A3A2-486A-B945-22C9A382B49F@delong.com>


On Feb 17, 2012, at 12:24 PM, Leigh Porter wrote:

> 
> On 17 Feb 2012, at 20:10, "Peter Kristolaitis" <alter3d at alter3d.ca> wrote:
> 
>> On 12-02-17 03:05 PM, Leigh Porter wrote:
>>> Did anybody say beer yet?
>>> 
>> 
>> Don't forget the 30lb sledgehammer for those times when, ah, "percussive maintenance" is the only possible solution.  ;)
>> 
>> (Might be a bit hard to fit into a vending machine though... maybe the colo staff could just rent one out...)
>> 
>> - Pete
>> 
> 
> Ahh yes, I recently used a universal adjuster to assist with some installation issues..
> 
> Another handy item would be little packets of pixie dust for when things just don't work,,

I thought pixie dust was for increasing drive capacity. ;-)

http://news.cnet.com/2100-1001-257943.html

Owen



From george.herbert at gmail.com  Fri Feb 17 19:00:17 2012
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 17 Feb 2012 17:00:17 -0800
Subject: Colo Vending Machine
In-Reply-To: <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
Message-ID: <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>

On Fri, Feb 17, 2012 at 1:44 PM, George Carey <george at montco.net> wrote:
>
>>
>> The vending machine should use a card like an ATM/gift card, not accept cash. ?You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space. ?If something is needed, one can purchase it with the card. ?If there is no money on the card, a person can add cash to the card via a web portal somewhere. ? Scenario: ?remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.
>>
>>
>
> Actually pricing should be 8 bits, 16 bits, or maybe 32 bits for the really important stuff.

Will IANA accept netblock transfers as an exchange medium for
datacenter goodies vending machine payments? ...  ;-)


-- 
-george william herbert
george.herbert at gmail.com


From george.herbert at gmail.com  Fri Feb 17 19:02:06 2012
From: george.herbert at gmail.com (George Herbert)
Date: Fri, 17 Feb 2012 17:02:06 -0800
Subject: Colo Vending Machine
In-Reply-To: <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
Message-ID: <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>

On Fri, Feb 17, 2012 at 5:00 PM, George Herbert
<george.herbert at gmail.com> wrote:
> On Fri, Feb 17, 2012 at 1:44 PM, George Carey <george at montco.net> wrote:
>>
>>>
>>> The vending machine should use a card like an ATM/gift card, not accept cash. ?You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space. ?If something is needed, one can purchase it with the card. ?If there is no money on the card, a person can add cash to the card via a web portal somewhere. ? Scenario: ?remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.
>>>
>>>
>>
>> Actually pricing should be 8 bits, 16 bits, or maybe 32 bits for the really important stuff.
>
> Will IANA accept netblock transfers as an exchange medium for
> datacenter goodies vending machine payments? ... ?;-)

Joking while busy discouraged.  s/IANA/ARIN/d'oh


-- 
-george william herbert
george.herbert at gmail.com


From bicknell at ufp.org  Fri Feb 17 19:07:29 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 17 Feb 2012 17:07:29 -0800
Subject: X.509 Certs For Personal Use
Message-ID: <20120218010729.GA10033@ussenterprise.ufp.org>


On the heals of some of the most productive conversation I've seen on
NANOG in ages, let me try another topic!

I suspect most people on NANOG are in the same boat that I'm in, we
operate some small number of domains for ourselves, friends, family, and
projects we like.  I suspect many of us are also security conscious and
would like to use encryption as often as possible.

Unfortunately to communicate with random folks on the Internet you need
an "SSL Certificate" signed by a "Trusted Root".  Ok, we can argue about
that, but that's what I'm going to assume for my question.  That could
be a cert for a web server, a mail server, a jabber server, or even a
personal e-mail certificate.

What I've found is a few classes of service:

- Totally free, but the Root CA is not well distributed (or other
  issues).

- Free for "one" (perhaps one web, one e-mail) on a well distributed CA,
  major upcharge for more.

- Services for businesses designed for maintaining multiple domains and
  certs starting at $high and ending at $crazy.

I am _not_ looking for a free only alternative, but I am looking for a
fee structure and price that makes _personal_ use economically workable.
I'd love to support community based efforts, but the reality is random
folks will be accessing my web site, sending me e-mail, etc, so I want
certs that are signed by root certs that ship with OSX/Windows/Linux,
they should "just validate".  I also do not require "EV" certificates,
although being able to get one for an upcharge might be nice.

Are there any providers that target someone with my desires?  What
providers do NANOG folks use for their _personal_ needs?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/5b9f0371/attachment.bin>

From gary.buhrmaster at gmail.com  Fri Feb 17 19:13:47 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Sat, 18 Feb 2012 01:13:47 +0000
Subject: Colo Vending Machine
In-Reply-To: <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
Message-ID: <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>

On Sat, Feb 18, 2012 at 01:02, George Herbert <george.herbert at gmail.com> wrote:
....
>> Will IANA accept netblock transfers as an exchange medium for
>> datacenter goodies vending machine payments? ... ?;-)
>
> Joking while busy discouraged. ?s/IANA/ARIN/d'oh

I suspect ARIN would follow its policy to recognize
any transfer and update its records as long as the
needs assessment was successfully completed,
but any compensation between the seller and
buyer of the resource is not part of the ARIN process.

(This is a (bad?) joke reference to a currently
ongoing discussion on the ARIN PPML list).


From nanog at maunier.org  Fri Feb 17 19:15:14 2012
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Sat, 18 Feb 2012 02:15:14 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202171938130.23972@whammy.cluebyfour.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
 <Pine.LNX.4.64.1202180027420.32438@a84-22-97-10.cb3rob.net>
 <Pine.LNX.4.64.1202171938130.23972@whammy.cluebyfour.org>
Message-ID: <CAEGdXrNW7PeynuPQwmpMTBx5cMTBc=3Q7=m6GzqxA6hmtLLbLQ@mail.gmail.com>

2012/2/18 Justin M. Streiner <streiner at cluebyfour.org>

> On Sat, 18 Feb 2012, Sven Olaf Kamphuis wrote:
>
>   7 - compressed air can to clean dust
>>>
>>
>> dust?!?!? sounds like time to find a whole new colo and move everything
>> out of there haha.
>>
>
> I also hope that duster can would not be used by someone who is attempting
> to clean fiber end-faces.  Incredibly bad idea.  See a recent thread on
> cisco-nsp.
>
> jms
>
>
That's why I wrote first about the fibre/connector cleaning kit.
The air can is for removing any dust that could be in the rack, air filter
of equipments etc.
All datacenters are differents some are very clean, others are very creepy
(but anyway I think those won't have any air can available :-) )


-- 
Pierre-Yves Maunier

From rms2176 at columbia.edu  Fri Feb 17 19:36:45 2012
From: rms2176 at columbia.edu (R. Sami)
Date: Fri, 17 Feb 2012 20:36:45 -0500
Subject: Common operational misconceptions
In-Reply-To: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
References: <2758121.3371.1329492792776.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120217203645.530mqb977808g8w0@cubmail.cc.columbia.edu>

When I bring up Linux ISOs to the believers of this misconception,  
they generally argue that Linux ISOs can be obtained without  
BitTorrent as well so blocking BT is okay. But I believe it is up to  
the user to decide which protocol to use to obtain the data and if the  
user wants to use BT but the network prevents this, the network is at  
fault.

Other valid uses of BitTorrent include content intentionally  
distributed via BT for free by Hollywood studios, television  
broadcasters, and artists of Creative Commons works. There's also  
Blizzard patches and other game patches. Some companies like Twitter  
apparently use BitTorrent internally (https://github.com/lg/murder).

Quoting Jay Ashworth <jra at baylink.com>:

> ----- Original Message -----
>> From: "Ridwan Sami" <rms2176 at columbia.edu>
>
>> There is no legitimate reason for a user to use BitTorrent (someone
>> will probably disagree with this).
>
> Yeah, no.
>
> You've clearly never tried to download a Linux installer DVD.
>
> Cheers,
> -- jr 'among dozens of other legitimate uses' a


From owen at delong.com  Fri Feb 17 19:39:34 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 17:39:34 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EDAEF.1020909@thebaughers.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
Message-ID: <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>

I have, on occasion been away from my laptop and gotten the call to go to the colo and deal with XYZ hardware problem and the colo was either: A in the opposite or orthogonal direction from  my house and significantly closer or B the colo was between my present location.

In such cases, I will occasionally stop by the colo without going home to retrieve the laptop. 90% of the time it works out OK. 10% of the time I end up leaving the colo, going home, retrieving the laptop and returning to the colo. Obviously, if there was a loaner laptop available for a $15 rental in the colo as described, it would probably be worth $15 to me and/or my organization to avoid the delay and bother of the round-trip between colo and home.

Owen

On Feb 17, 2012, at 2:55 PM, Jason Baugher wrote:

> Do you guys ride your bike to the colo and show up in shorts and a t-shirt? Who goes to the colo without things like their laptop?
> 
> 
> On 2/17/2012 4:22 PM, Rodrick Brown wrote:
>> On Feb 17, 2012, at 1:35 PM, Jay Ashworth<jra at baylink.com>  wrote:
>> 
>>> Please post your top 3 favorite components/parts you'd like to see in a
>>> vending machine at your colo; please be as specific as possible; don't
>>> let vendor specificity scare you off.
>>> 
>> atom based 10" laptop with serial interface and cable. $15 day charge would rock!
>> 
>> 4 Port 10/100/1000 hub. $20?
>> 
>> USB sticks  2/4/8GB
>> 
>> Cage nuts various common sizes.
>> 
>> Vending machine should double as wireless AP with open Internet access $5 should give you AP code and min 8 hour access time.
>> 
>> Sent from my iPhone.
>> 
>>> Cheers,
>>> -- jra
>>> -- 
>>> Jay R. Ashworth                  Baylink                       jra at baylink.com
>>> Designer                     The Things I Think                       RFC 2100
>>> Ashworth&  Associates     http://baylink.pitas.com         2000 Land Rover DII
>>> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274
>>> 
>> 
> 



From owen at delong.com  Fri Feb 17 19:42:40 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 17:42:40 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
 <alpine.BSF.2.00.1202171822280.58956@murf.icantclick.org>
Message-ID: <FE0C8B5E-120A-4C2B-A56A-674B83640F28@delong.com>


On Feb 17, 2012, at 3:23 PM, david raistrick wrote:

> On Sat, 18 Feb 2012, Pierre-Yves Maunier wrote:
> 
>> 6 - plastic cable clamps (don't know the exact english term for that but I
>> mean this -->
>> http://www.hellopro.fr/images/produit-2/9/3/8/serre-cables-261839.jpg)
> 
> also known as "zip tie" or "plastic cable tie" more generically

I'd much rather see Velcro cable ties like this:

http://www.amazon.com/Velcro-Hook-Loop-Fastening-Cable/dp/B004AFUJZC/ref=pd_cp_e_3

Owen



From owen at delong.com  Fri Feb 17 19:40:53 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 17:40:53 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAHsqw9vcgnROJi2x00orKFmW-CBaaA_hLXgAZHW4ngrDTk20SQ@mail.gmail.com>
 <022801cceda4$11377b90$33a672b0$@truenet.com>
 <CAO1bj=aONbM4wSbwGhq3Se90MhFwbwCxREfAk5joqSeqyUK9cA@mail.gmail.com>
Message-ID: <08D36930-8646-4769-A606-1E715DC036E4@delong.com>


On Feb 17, 2012, at 3:18 PM, Aled Morris wrote:

> On 17 February 2012 18:43, Eric Tykwinski <eric-list at truenet.com> wrote:
> 
>> +1 for GBICs, SFPs
>> 
>> 
> You'll need to be carrying a lot of loose change then :-)
> 
> My ideal vending machine would dispense Cat5e by the foot, the more you
> pull the more you pay, RJ45 plugs in pairs, and a crimp tool on a long
> chain (like the way you buy chain in a hardware store)
> 
> Aled

I think this would be more like the BestBuy vending machines that sell iPods, etc. and take credit cards.

Owen



From owen at delong.com  Fri Feb 17 19:52:01 2012
From: owen at delong.com (Owen DeLong)
Date: Fri, 17 Feb 2012 17:52:01 -0800
Subject: Common operational misconceptions
In-Reply-To: <39313.1329505485@turing-police.cc.vt.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org> <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
 <39313.1329505485@turing-police.cc.vt.edu>
Message-ID: <60BF48B5-DEFE-4F6C-ACD7-3C9C2797CB90@delong.com>


On Feb 17, 2012, at 11:04 AM, Valdis.Kletnieks at vt.edu wrote:

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

Strictly an artifact of it's EBCDIC nature, as a matter of fact...

The BCD in EBCDIC stands for Binary Coded Decimal which inherently
requires Hex.

In fact, if you compare punched cards to EBCDIC, you'll find some remarkable
similarities...

For example C1 (12 1) is A (Hollerith A is a 12 punch plus a 1 punch).

Owen



From bruns at 2mbit.com  Fri Feb 17 20:48:56 2012
From: bruns at 2mbit.com (Brielle Bruns)
Date: Fri, 17 Feb 2012 19:48:56 -0700
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.64.1202180015510.32438@a84-22-97-10.cb3rob.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org> <4F3EB4A7.9060705@2mbit.com>
 <Pine.LNX.4.64.1202180015510.32438@a84-22-97-10.cb3rob.net>
Message-ID: <4F3F1198.2050309@2mbit.com>

On 2/17/12 5:17 PM, Sven Olaf Kamphuis wrote:
>>
>> I still long for the day when someone makes a true 16550 based USB to
>> serial adapter... Some of the stuff I need to reprogram at the shop at
>> times does not like the cheapie chips that are most common - I've
>> bricked an APC network manager card at least once for that specific
>> reason...
>
> says more about the apc network manager card...
>
> if it can't handle rs232 properly... well...
> (or, from what i understand from this, doesn't have checksums on its
> firmware files or doesn't check them ;)


:P

I totally agree that the APC network cards are...  for lack of a better 
term, a steaming pile.  Unfortunately, when you have quite a few older 
UPSs and PDUs with old cards like the AP9606 that are still in service...

I work pretty heavily these days in repair, refurbishment, and upgrading 
of legacy equipment from various fields - changes of career can be fun 
and rewarding, and in this case, a bit more relaxing from not being on 
call 24/7.

When the vendor is long gone, replacement parts are scarce, and 
everything is serial based, you learn pretty quick that quirks and 
timing issues can wreck and trash a controller.  Usually equals the 
junking of whole pieces of machinery or expensive replacement parts.

So, while some people have messaged me off list giving me grief for 
suggesting it, I have my reasons for desiring such a 'strange beast'.

In the meantime, I've got a passive ISA backplane, a collection of 286, 
386, and higher proc boards, and misc ISA serial boards (why oh why did 
some vendors use RS-485 on some controllers???).


<rant>
On an unrelated side note and not directed at you...  I read messages on 
this list at times, and I have to wonder if some people here forget 
where they came from when they first started out in the field or 
building their own company.

Sometimes, its not possible to just replace or upgrade things in active 
service just because they are older, or because they are quirky.  Yeah, 
its easy to say, "switch vendors!", but in reality, we all know that is 
far from the truth.

I guess its easy lose sight of the fact that there's alot of companies 
and groups that don't have the luxury of million dollar budgets...  or 
even tens of thousands in budget...  Or run what they do as a hobby or 
charity.
</rant>


-- 
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org    /     http://www.ahbl.org


From johnl at iecc.com  Fri Feb 17 21:32:10 2012
From: johnl at iecc.com (John Levine)
Date: 18 Feb 2012 03:32:10 -0000
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218010729.GA10033@ussenterprise.ufp.org>
Message-ID: <20120218033210.88103.qmail@joyce.lan>

I use these guys: http://www.cheapssls.com/

They sell Geotrust and Comodo certs for under $10/yr.  The hassle
level is quite low.  First you order a cert providing the usual
billing info, then you go to their web site, pick the order you just
paid for, go to a screen where you paste in your signing request, and
pick which e-mail address to send the confirmation message to.  Click
a URL in the confirmation message and the signed cert shows up in a
few minutes.  The certs are chained, but I've had no acceptance
problems once I realized I had to to add an extra Apache config line
to serve the intermediate cert.

If you get a Comodo cert for example.com, it'll also work for
www.example.com.  Other than that, they seem to be equivalent.

If you just want something for testing, http://freessl.com/ will
provide a real 30 day Geotrust cert for free, with similarly low
hassle.  At the end of the 30 days, you can renew the cert into a paid
one at cheapssls or any other Geotrust reseller.

I realize there are places that will provide totally free certs, but
their hassle level is far greater.  For $24 I can get a Comodo cert
that will make my SSL complaints go away for three years, which seems
like a bargain to me.

R's,
John


From andyjohnson at ij.net  Fri Feb 17 22:03:06 2012
From: andyjohnson at ij.net (Andy Johnson)
Date: Fri, 17 Feb 2012 23:03:06 -0500
Subject: Simple Cable Marking Standards
References: <4F3EEE4A.5030100@bowenvale.co.nz>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD1FDE@RWC-MBX1.corp.seven.com>
Message-ID: <02c301ccedf2$39469fa0$0241a8c0@oicu812>

>> Some of it "looks" really nice but can be a pain to work with, too so you 
>> have to consider how it would be to have to pull a blade from that switch 
>> that looks really nice at first until you consider having to actually 
>> replace anything in that network.

This advice is huge, and often only learned after both being the guy to wire 
up two fully populated chassis (240ish rj45's) in a rack, and then come to 
the realization that you can't remove blades without unplugging all the 
cables of the four blades surrounding it. That isn't the worst of it, the 
realization that any future blade replacements on either chassis will cost 
you that same pain is what really hurts.




From mysidia at gmail.com  Fri Feb 17 23:09:05 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Fri, 17 Feb 2012 23:09:05 -0600
Subject: Common operational misconceptions
In-Reply-To: <60BF48B5-DEFE-4F6C-ACD7-3C9C2797CB90@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <EE93FFCD-7B3E-44EF-A772-40C9CF323A72@delong.com>
 <39313.1329505485@turing-police.cc.vt.edu>
 <60BF48B5-DEFE-4F6C-ACD7-3C9C2797CB90@delong.com>
Message-ID: <CAAAwwbVjU9D61C+fC+jXWV--u6Y6tMaqhqgkabz0SR9WcJvxeQ@mail.gmail.com>

On Wed, Feb 15, 2012 at 4:52 PM, Rich Kulawiec <rsk at gsp.org> wrote:
> ICMP is evil.
To that I would add under...
Security misconceptions
   0. Security is just common sense.
        a.  More draconian/more complicated policies/practices
automatically result in a good
             secure, usable environment.
              i.  For secure results, require users to set a
25-character complex password with 1-day
                  expire.
             ii.  For best results, get a checklist containing every
possible "security measure" that
                  can be implemented, and implement them in no particular order.
            iii.  For best results, ask a committee of accomplished
bureaucrats....

        b.  For best results,  leave all settings at their default values.
               i.  A security focused analysis is not required to
design a secure system/network.
               ii. If each device is secure, the overall system is
automatically secure.

        c. Just install Product $X,  Product $Y.   Everything will be fine.
        d. If that doesn't work, and we still get a security breach,
adding Product $Z will
           definitely make it secure forever,  without log checking
and security reviews.
        e. A simple automated scan can detect all possible security issues.

   1. Script kiddies don't want access to my router, because they
can't run malware
        i. Routers always encrypt passwords in memory; the *s
displayed when you look at the password field in the webui prove it;
no worries throwing out old equipment.
       ii. It's okay to re-use the admin password for a POP3 account,
no security risk there.

   2. If your organization partitions its internal network from the
internet with a firewall....
          a.  The network will be invincible to attack.  or
                 i. Private addressing ensures a LAN secure against
outside attack.
                ii. SSL certificates don't matter, just click Continue.

          b.  Sources of possible abuse/intrusion will always be on
the outside. [or]
                i.  The perimeter firewall makes the LAN safe against
packet sniffers
                ii. Use of Ethernet  switches instead of hubs make the
LAN completely safe against packet sniffers.
                iii. Managing local LAN devices (such as routers)
using telnet or plain HTTP
                    is safe and secure  (because of i or ii).

                iv. Plain e-mail is an  excellent file transfer
protocol -- it's also a secure way to
                   transfer large files into or out of a
Firewall-secured LAN,  since e-mail is private.

               v. External USB drives are a safe, secure, convenient
way to bring data into
                   or out of the partitioned network.    Antivirus
will thwart any attempt to
                   transfer malicious files of any type.

               vi. FTP is a safe way to bring data into or out of a
secure network, and the data
                  is safe against interception because a password is
required to connect.

          c.  The one perimeter firewall will protect the network
against internal attacks,
               and even outsiders gaining access to open wifi.
                i.  WEP or open access with MAC address filtering is
pretty secure.
               ii. MAC address filtering on the core router will make
sure unauthorized devices
                  plugged in cannot possibly gain access to the LAN.
              iii. MAC address filtering on the DHCP server will make
sure unauthorized devices
                  plugged in cannot possibly gain access to the LAN.

          d.  No need to worry about having a DMZ or separate network,
 for hosting internet services behind a firewall.
                i.  If traffic is only allowed to port 80, shell
access cannot be obtained by exploit,
                    even if the PHP scripts have bugs, because port 23
is required for shell access.
               ii.  If traffic from the internet is alllowed to pass
to one host through a firewall,
                   any possible security risk  is limited to
exclusively that one host.









> Firewalls will solve our security issues.
> Antivirus will solve our security issues.
...

$MAGIC_PRODUCT will solve our security issues.
For many different values of $MAGIC_PRODUCT
--
-JH


From techie at w6yx.stanford.edu  Sat Feb 18 01:19:21 2012
From: techie at w6yx.stanford.edu (Bob Vaughan)
Date: Fri, 17 Feb 2012 23:19:21 -0800 (PST)
Subject: Common operational misconceptions
Message-ID: <201202180719.q1I7JLIr062630@w6yx.stanford.edu>


"Ethernet/Token Ring/Cisco Console/whatever uses an RJ45 connector"

 RJ45 defines a keyed 8P8C type connector, wired in a specific
 manner, for a specific 2 wire telco service. Incompatible with the
 above on several levels.  "RJxx" == specific connector/wiring pattern 
 for specific telco applications. Non-telco uses need not apply.

 One of these days I'm going to start carrying around some actual RJ45
 type cables to hand out to those who ask.


"DB9"

 DB defines a D series subminiature connector with a size "B" (nominal 25 pin) 
 shell. DE defines a size "E" (nominal 9 pin) shell. DA15, DB25, DC37, DD50,
 DE9, etc..  Also DB13W3 (old Sun monitors), etc. If in doubt, refer to 
 ITT/Cannon catalogs. (my oldest is from 1971).


-- 
               -- Welcome My Son, Welcome To The Machine --
Bob Vaughan  | techie@{w6yx|tantivy}.stanford.edu 	| techie at tantivy.net
AF6RR	     | P.O. Box 19792, Stanford, Ca 94309	| 1-650-469-3850
-- I am Me, I am only Me, And no one else is Me, What could be simpler? --


From dgdalton99 at yahoo.com  Sat Feb 18 01:25:43 2012
From: dgdalton99 at yahoo.com (dgdalton99 at yahoo.com)
Date: Sat, 18 Feb 2012 07:25:43 +0000
Subject: NANOG Digest, Vol 49, Issue 84
In-Reply-To: <mailman.4129.1329505836.46019.nanog@nanog.org>
References: <mailman.4129.1329505836.46019.nanog@nanog.org>
Message-ID: <275347532-1329549955-cardhu_decombobulator_blackberry.rim.net-1336953307-@b5.c4.bise6.blackberry>

2r7rtqAer2*2sQa#*
Sent via BlackBerry by AT&T

-----Original Message-----
From: nanog-request at nanog.org
Date: Fri, 17 Feb 2012 13:10:36 
To: <nanog at nanog.org>
Reply-To: nanog at nanog.org
Subject: NANOG Digest, Vol 49, Issue 84

Send NANOG mailing list submissions to
	nanog at nanog.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://mailman.nanog.org/mailman/listinfo/nanog
or, via email, send a message with subject or body 'help' to
	nanog-request at nanog.org

You can reach the person managing the list at
	nanog-owner at nanog.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of NANOG digest..."


Today's Topics:

   1. RE: Colo Vending Machine (George Bonser)
   2. Re: Common operational misconceptions (Valdis.Kletnieks at vt.edu)
   3. RE: Colo Vending Machine (Erik Soosalu)
   4. Re: WW: Colo Vending Machine (Bill Blackford)
   5. RE: Colo Vending Machine (Nathan Eisenberg)
   6. Re: WW: Colo Vending Machine (Sven Olaf Kamphuis)
   7. RE: Colo Vending Machine (Sven Olaf Kamphuis)
   8. Re: WW: Colo Vending Machine (Matthew S. Crocker)
   9. Re: WW: Colo Vending Machine (Mike Lyon)


----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Feb 2012 19:03:44 +0000
From: George Bonser <gbonser at seven.com>
To: Jay Ashworth <jra at baylink.com>, NANOG <nanog at nanog.org>
Subject: RE: Colo Vending Machine
Message-ID:
	<596B74B410EE6B4CA8A30C3AF1A155EA09CD0995 at RWC-MBX1.corp.seven.com>
Content-Type: text/plain; charset="utf-8"

Diagonal cutters
Screwdriver with interchangeable Phillips/straight blade
Small flashlight (with the data center provider's logo even!)
Headlamp
Small mirror (inspection mirror)
Rack screws
Zip ties
Velcro ties
Sharpie markers
Pens 
Notebook of shirt pocket size with pages that can be easily torn out for leaving notes.
Post-It
Assortment of electrical tape in various colors.
SFPs (optical and RJ-45, short and long range)
USB stick (sans viruses)
Patch cords 1, 3, 5 meter. Copper, multi-mode, single-mode fiber
USB to DB9 dongle (with driver on USB stick or one the computer can discover on the Internet)
Standard charger of sort used for most smart phones these days or the proper USB cable (micro USB)

The vending machine should use a card like an ATM/gift card, not accept cash.  You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space.  If something is needed, one can purchase it with the card.  If there is no money on the card, a person can add cash to the card via a web portal somewhere.   Scenario:  remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.




------------------------------

Message: 2
Date: Fri, 17 Feb 2012 14:04:45 -0500
From: Valdis.Kletnieks at vt.edu
To: Owen DeLong <owen at delong.com>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Common operational misconceptions
Message-ID: <39313.1329505485 at turing-police.cc.vt.edu>
Content-Type: text/plain; charset="us-ascii"

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

IBM S/360 definitely preferred hex.  And EBCDIC.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120217/7e04a136/attachment-0001.bin>

------------------------------

Message: 3
Date: Fri, 17 Feb 2012 14:06:37 -0500
From: "Erik Soosalu" <erik.soosalu at calyxinc.com>
To: "NANOG" <nanog at nanog.org>
Subject: RE: Colo Vending Machine
Message-ID:
	<0B224A2FE01CC54C860290D42474BF60052D54C2 at exchange.nff.local>
Content-Type: text/plain;	charset="us-ascii"

I know I'm being a freaking idealist.

My tool bag carries all my required sets of screws and cage nuts.  Works
great until the first level guy decides to borrow something and not put
it back.

Thanks,
Erik 
-----Original Message-----
From: Sven Olaf Kamphuis [mailto:sven at cb3rob.net] 
Sent: Friday, February 17, 2012 2:02 PM
To: Erik Soosalu
Cc: NANOG
Subject: RE: Colo Vending Machine


On Fri, 17 Feb 2012, Erik Soosalu wrote:

> 1) Patch cables every 1' length from 3-10'
> 2) Velcro wrap
> 3) Tools (screwdrivers, etc)
>
> And since the racks usually come with the cage nuts, maybe the colo
should just provide them.

they do? nonono, you have to buy those seperately :P

racks don't even come with "doors" and "side walls" etc by default
*grin*

you have to buy them seperately anyway if you want to make sure your 
company uses all the same ones, so you don't have to take them out again

and replace them because some fukkin idiot put the wrong size into the 
hole as it "came with something else"

> >
> Thanks,
> Erik
>
> -----Original Message-----
> From: Jay Ashworth [mailto:jra at baylink.com]
> Sent: Friday, February 17, 2012 1:35 PM
> To: NANOG
> Subject: WW: Colo Vending Machine
>
> Please post your top 3 favorite components/parts you'd like to see in
a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink
jra at baylink.com
> Designer                     The Things I Think
RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
647 1274
>
>
>




------------------------------

Message: 4
Date: Fri, 17 Feb 2012 11:06:50 -0800
From: Bill Blackford <bblackford at gmail.com>
To: Jay Ashworth <jra at baylink.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: WW: Colo Vending Machine
Message-ID:
	<CAMv18OMe0TW1iNdv6C0XkEO6FCL5jmDbU0EsQFEevHSbhih=bw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

1. patch cables. MMF and SMF, LC and SC and LC/SC to include LC and SC
couplers so one can mix-and-match
2. Velcro wraps.
3. cage nuts/bolts

-b



On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth <jra at baylink.com> wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com
> Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100
> Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII
> St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274
>



-- 
Bill Blackford
Network Engineer

Logged into reality and abusing my sudo privileges.....



------------------------------

Message: 5
Date: Fri, 17 Feb 2012 19:06:29 +0000
From: Nathan Eisenberg <nathan at atlasnetworks.us>
To: Jay Ashworth <jra at baylink.com>, NANOG <nanog at nanog.org>
Subject: RE: Colo Vending Machine
Message-ID:
	<8C26A4FDAE599041A13EB499117D3C286B7B90A1 at ex-mb-2.corp.atlasnetworks.us>
	
Content-Type: text/plain; charset="utf-8"

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
> jra at baylink.com
> Designer                     The Things I Think
> RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
> 647 1274
> 

USB A/B/Mini/Micro/Nano/Pico/etc/etc/etc cables
Spare parts (common sizes of RAM/Disks/Fans)
New servers (probably don't fit in a vending machine, but in that dark place where you need a new box *TONIGHT*, this could be a godsend)
Generically sized hoodie or sweatshirt.  Datacenters can get really cold if you're in there longer than expected.
Advil/Ibuprofen/Generic OTC Pain Reliever
Cisco Console Cables

Outside of a vending machine, I've also seen a few facilities that have normal vending machines (including instant coffee dispensers).  This has, on more than one occasion, kept me standing long enough to get the jorb done.

Nathan Eisenberg

------------------------------

Message: 6
Date: Fri, 17 Feb 2012 19:07:25 +0000 (UTC)
From: Sven Olaf Kamphuis <sven at cb3rob.net>
To: Tom Perrine <tperrine at scea.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: WW: Colo Vending Machine
Message-ID:
	<Pine.LNX.4.64.1202171904350.32438 at a84-22-97-10.cb3rob.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

if a pop doesn't come with a hotel with a bar in front of the door, 
or at least around the corner, and preferably free beer, coffee, etc in 
the cantina as well, we're not a customer of theirs haha.

headace tables are good..

but then again, with noise protectors you would not get the headace in the 
first place :P

and a buttwarmer to sit on the floor (or maybe even a chair!)


On Fri, 17 Feb 2012, Tom Perrine wrote:

> On 2/17/12 10:52 AM, Leigh Porter wrote:
>>
>> On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
>>
>>> Please post your top 3 favorite components/parts you'd like to see in a
>>> vending machine at your colo; please be as specific as possible; don't
>>> let vendor specificity scare you off.
>>
>> Pizza, condoms and headache tablets.
>>
>
> Stone Brewery Arrogant Bastard beer - "A bitter brew for your bitter life", "You are not worthy"
>
>



------------------------------

Message: 7
Date: Fri, 17 Feb 2012 19:09:02 +0000 (UTC)
From: Sven Olaf Kamphuis <sven at cb3rob.net>
To: George Bonser <gbonser at seven.com>
Cc: NANOG <nanog at nanog.org>
Subject: RE: Colo Vending Machine
Message-ID:
	<Pine.LNX.4.64.1202171908450.32438 at a84-22-97-10.cb3rob.net>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

or you just use your datacenter access rfid pass to pay and they put it on 
the bill later on.

-- 
Greetings,

Sven Olaf Kamphuis,
CB3ROB Ltd. & Co. KG
=========================================================================
Address: Koloniestrasse 34         VAT Tax ID:      DE267268209
          D-13359                   Registration:    HRA 42834 B
          BERLIN                    Phone:           +31/(0)87-8747479
          Germany                   GSM:             +49/(0)152-26410799
RIPE:    CBSK1-RIPE                e-Mail:          sven at cb3rob.net
=========================================================================
<penpen> C3P0, der elektrische Westerwelle
http://www.facebook.com/cb3rob
=========================================================================

Confidential: Please be advised that the information contained in this
email message, including all attached documents or files, is privileged
and confidential and is intended only for the use of the individual or
individuals addressed. Any other use, dissemination, distribution or
copying of this communication is strictly prohibited.


On Fri, 17 Feb 2012, George Bonser wrote:

> Diagonal cutters
> Screwdriver with interchangeable Phillips/straight blade
> Small flashlight (with the data center provider's logo even!)
> Headlamp
> Small mirror (inspection mirror)
> Rack screws
> Zip ties
> Velcro ties
> Sharpie markers
> Pens
> Notebook of shirt pocket size with pages that can be easily torn out for leaving notes.
> Post-It
> Assortment of electrical tape in various colors.
> SFPs (optical and RJ-45, short and long range)
> USB stick (sans viruses)
> Patch cords 1, 3, 5 meter. Copper, multi-mode, single-mode fiber
> USB to DB9 dongle (with driver on USB stick or one the computer can discover on the Internet)
> Standard charger of sort used for most smart phones these days or the proper USB cable (micro USB)
>
> The vending machine should use a card like an ATM/gift card, not accept cash.  You should be able to "charge" the card with some cash via a web portal and keep the card in the facility in your space.  If something is needed, one can purchase it with the card.  If there is no money on the card, a person can add cash to the card via a web portal somewhere.   Scenario:  remote hands guy arrives on site, needs an SFP, card doesn't have enough money on it, calls me, I can add the cash to the card, he can purchase the SFP and leave the card in the space for the next time it is needed.
>
>
>
>



------------------------------

Message: 8
Date: Fri, 17 Feb 2012 14:10:01 -0500 (EST)
From: "Matthew S. Crocker" <matthew at corp.crocker.com>
To: Jay Ashworth <jra at baylink.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: WW: Colo Vending Machine
Message-ID: <dcc840de-e8d1-4d40-8cbd-786df3754194 at zimbra1.crocker.com>
Content-Type: text/plain; charset=utf-8


Serial cables, DB9 -> USB converts and all of the various vendor adapters to make it work.

WTSHTF I'm always digging through my gear looking for the right serial adapter.

Duct tape, paper clips and chewing gum.  If it was good enough for McGyver it is good enough for me.


----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>
> To: "NANOG" <nanog at nanog.org>
> Sent: Friday, February 17, 2012 1:35:15 PM
> Subject: WW: Colo Vending Machine
> 
> Please post your top 3 favorite components/parts you'd like to see in
> a
> vending machine at your colo; please be as specific as possible;
> don't
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> --
> Jay R. Ashworth                  Baylink
>                       jra at baylink.com
> Designer                     The Things I Think
>                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land
> Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727
> 647 1274
> 
> 
> 



------------------------------

Message: 9
Date: Fri, 17 Feb 2012 11:10:28 -0800
From: Mike Lyon <mike.lyon at gmail.com>
To: Tom Perrine <tperrine at scea.com>
Cc: NANOG <nanog at nanog.org>
Subject: Re: WW: Colo Vending Machine
Message-ID:
	<CAFFgAjCbD959ScZe2C21fo3Q1a5JYkdEtOcu+RJ=YrUMAxMYBg at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

1. BNC tees
2. FDDI cables
3. AUI to BNC adapters.



On Fri, Feb 17, 2012 at 11:01 AM, Tom Perrine <tperrine at scea.com> wrote:

> On 2/17/12 10:52 AM, Leigh Porter wrote:
> >
> > On 17 Feb 2012, at 18:37, "Jay Ashworth" <jra at baylink.com> wrote:
> >
> >> Please post your top 3 favorite components/parts you'd like to see in a
> >> vending machine at your colo; please be as specific as possible; don't
> >> let vendor specificity scare you off.
> >
> > Pizza, condoms and headache tablets.
> >
>
> Stone Brewery Arrogant Bastard beer - "A bitter brew for your bitter
> life", "You are not worthy"
>
>
>


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

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


End of NANOG Digest, Vol 49, Issue 84
*************************************

From mpalmer at hezmatt.org  Sat Feb 18 01:42:13 2012
From: mpalmer at hezmatt.org (Matthew Palmer)
Date: Sat, 18 Feb 2012 18:42:13 +1100
Subject: WW: Colo Vending Machine
In-Reply-To: <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
Message-ID: <20120218074213.GK4990@hezmatt.org>

On Fri, Feb 17, 2012 at 05:39:34PM -0800, Owen DeLong wrote:
> In such cases, I will occasionally stop by the colo without going home to
> retrieve the laptop.  90% of the time it works out OK.  10% of the time I
> end up leaving the colo, going home, retrieving the laptop and returning
> to the colo.  Obviously, if there was a loaner laptop available for a $15
> rental in the colo as described, it would probably be worth $15 to me
> and/or my organization to avoid the delay and bother of the round-trip
> between colo and home.

As previously advised, typing passwords/phrases into such devices is...  not
recommended.  At $ORK, we've got DC tech laptops in each suite for just such
occasions, preconfigured with everything you might need (bookmarks into all
internal systems and likely wiki pages, a "DC tech" jabber account, etc). 
Works well, and I'm sure they've paid for themselves many times over.

- Matt

-- 
<liw> hut.fi has or used to have two nfs servers not-responding and
still-trying... don't know if their dns server was not-found... 4o4 would be
then a good name for the web server... endless hours of fun
<aj> "did you get a response from 4o4?" "nah, it just 404ed"



From mike at steadfast.net  Sat Feb 18 01:54:02 2012
From: mike at steadfast.net (Mike Bailey)
Date: Sat, 18 Feb 2012 01:54:02 -0600
Subject: NANOG Digest, Vol 49, Issue 70
In-Reply-To: <mailman.4055.1329488009.46019.nanog@nanog.org>
References: <mailman.4055.1329488009.46019.nanog@nanog.org>
Message-ID: <4F3F591A.4020209@steadfast.net>

I have yet to receive one of these, but I rarely post to nanog. Could 
you post up the email headers for us to see? I'm curious to see if it 
actually originated from a telx mailserver, according to their TXT/SPF 
records they use messagelabs.com, mktomail.com, and intermedia.net.


On 02/17/2012 08:13 AM, nanog-request at nanog.org wrote:
> So, anyone else get spammed by Telx after posting to nanog?
>
> This is massively unprofessional.
>
> Nick
>
> -------- Original Message --------
> Subject: RE: telx
> Date: Fri, 17 Feb 2012 13:47:25 +0000
> From: George Fitzpatrick<gfitzpatrick at telx.com>
> To: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
> Hi xxxxxxxxxxxx,
>
> We have some exciting things happening here at Telx that can help your
> network connectivity.
> Can we chat for 5 minutes?
>
> Thanks,
> George
> 917.371.7257



From paul at paulgraydon.co.uk  Sat Feb 18 01:56:25 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Fri, 17 Feb 2012 21:56:25 -1000
Subject: Common operational misconceptions
In-Reply-To: <031901cceda4$081057d0$18310770$@chipps.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
Message-ID: <4F3F59A9.5060800@paulgraydon.co.uk>

Give me someone who can already think and analyse over someone who 
'knows' it all, any day.  You can be qualified to the hilt but 
absolutely useless in the real world (I've watched CCNP and higher 
struggling to figure out why they can't ping a 10.0.0.0/24 address at a 
customers remote site, not even realising it's a private range, let 
alone trying to trace the path of the ping,)  If you're capable of 
symptoms->synthesis->solution you're of much more use to me.  You can 
pick up technical knowledge on the job, or around the job.  It's 
extremely hard to mold someone's thinking patterns by the time they're 
adults.  When we interview we try to spend more time trying to gauge 
problem solving capabilities than anything else, after first quickly 
establishing their technical level.

Paul

On 2/17/2012 8:43 AM, Kenneth M. Chipps Ph.D. wrote:
> Exactly right. They have some much information floating around in their
> heads many of them cannot fit it together. But once they get on the job, all
> of those little synapses rapidly connect, and then the light comes on.
>
> Higher education is just like drivers education. You did not learn to drive
> in drivers education. You learned how to drive by driving. Higher education
> gives you the foundation on which to learn.
>
> -----Original Message-----
> From: Paul Graydon [mailto:paul at paulgraydon.co.uk]
> Sent: Friday, February 17, 2012 12:33 PM
> To: nanog at nanog.org
> Subject: Re: Common operational misconceptions
>
> On 02/17/2012 04:29 AM, Leo Bicknell wrote:
>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
> Graydon wrote:
>>> At the same time, it's shocking how many network people I come across
>>> with no real grasp of even what OSI means by each layer, even if it's
>>> only in theory.  Just having a grasp of that makes all the world of
>>> difference when it comes to troubleshooting.  Start at layer 1 and
>>> work upwards (unless you're able to make appropriate intuitive
>>> leaps.) Is it physically connected? Are the link lights flashing? Can
>>> traffic route to it, etc. etc.
>> I wouldn't call it a "misconception", but I want to echo Paul's
>> comment.  I would venture over 90% of the engineers I work with have
>> no idea how to troubleshoot properly.  Thinking back to my own
>> education, I don't recall anyone in highschool or college attempting
>> to teach troubleshooting skills.  Most classes teach you how to build
>> things, not deal with them when they are broken.
> The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
> troubleshooting.  Not sure if they still do, or if trainers even bother to
> mention it (mine did back when I did it several years ago)
>
>> The basic skills are probably obvious to someone who might design
>> course material if they sat down and thought about how to teach
>> troubleshooting.  However, there is one area that may not be obvious.
>> There's also a group management problem.  Many times troubleshooting
>> is done with multiple folks on the phone (say, customer, ISP and
>> vendor).  Not only do you have to know how to troubleshoot, but how to
>> get everyone on the same page so every possible cause isn't tested 3
>> times.
> Never trust what you can't prove yourself, that includes vendors and
> customers.  Every now and then I forget this and find hours later that I've
> wasted a whole bunch of time because I trusted when someone said something
> that it actually was the case.  It's really often better to test something a
> third time even if Vendor and Customer tell you something is a particular
> way.
>
>> I think all college level courses should include a "break/fix"
>> exercise/module after learning how to build something, and much of
>> that should be done in a group enviornment.
>>
> Definitely.  I've learnt more in my time from breaking things than I've ever
> learnt setting them up; however the education system is focused on breadth
> of knowledge, not depth.  Students are expected to be able to regurgitate
> ridiculous amounts of facts and figures, so that they pass standardised
> tests, not understand how to actually use them.
>
> Paul
>
>
>
>
>



From nanog at studio442.com.au  Sat Feb 18 02:12:01 2012
From: nanog at studio442.com.au (Julien Goodwin)
Date: Sat, 18 Feb 2012 19:12:01 +1100
Subject: WW: Colo Vending Machine
In-Reply-To: <20120218074213.GK4990@hezmatt.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
Message-ID: <4F3F5D51.7060202@studio442.com.au>

On 18/02/12 18:42, Matthew Palmer wrote:
> On Fri, Feb 17, 2012 at 05:39:34PM -0800, Owen DeLong wrote:
>> In such cases, I will occasionally stop by the colo without going home to
>> retrieve the laptop.  90% of the time it works out OK.  10% of the time I
>> end up leaving the colo, going home, retrieving the laptop and returning
>> to the colo.  Obviously, if there was a loaner laptop available for a $15
>> rental in the colo as described, it would probably be worth $15 to me
>> and/or my organization to avoid the delay and bother of the round-trip
>> between colo and home.
> 
> As previously advised, typing passwords/phrases into such devices is...  not
> recommended.  At $ORK, we've got DC tech laptops in each suite for just such
> occasions, preconfigured with everything you might need (bookmarks into all
> internal systems and likely wiki pages, a "DC tech" jabber account, etc). 
> Works well, and I'm sure they've paid for themselves many times over.

The old colo at $JOB[-1] used to have an old Wyse 50 kicking around
which I was happy enough to use (yes they can still be made to snarf
credentials, but it's less likely) once or twice when I forgot my
USB-Serial.


From leo at deepreflect.net  Sat Feb 18 02:29:43 2012
From: leo at deepreflect.net (Leonardo Rizzi)
Date: Sat, 18 Feb 2012 08:29:43 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <CAEGdXrMd3fD2hwS0LGuDyHA26fkuyrBXpcoENYvqDsgHf6jqgw@mail.gmail.com>
Message-ID: <assp.03950a43e6.4F3F6177.3000406@deepreflect.net>


C14 to "laptop usable" power cord
Iron Solder
key set for standard rack (IBM, APC, etc.)
International power adapter
Multipurpose all-in-one portable ethernet router/firewall/switch

On 02/17/2012 11:15 PM, Pierre-Yves Maunier wrote:
> 2012/2/17 Jay Ashworth<jra at baylink.com>
>
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't
>> let vendor specificity scare you off.
>>
>> Cheers,
>> -- jra
>>
>>
> 1 - As previously said : LC/SC couplers + patchcords
> 2 - fibre/connectors cleaning kit
> 3 - SC/LC optical attenuators
> 4 - Laser pen that can send visible red beam in blink/continuous mode
> 5 - as said previously too : USB-RS232 adaptator
> 6 - plastic cable clamps (don't know the exact english term for that but I
> mean this -->
> http://www.hellopro.fr/images/produit-2/9/3/8/serre-cables-261839.jpg)
> 7 - compressed air can to clean dust
> 8 - CAT5 tester
>
> A good this to be able to borrow from the noc (because a bit problematic to
> put then in a vending machine) :
>
> - an Optical Power Meter
> - a live fiber detection device (to be able to detect presence of light and
> the direction of the light in a fibre without disconnecting it) we use
> these at work and they're awesome :
> http://www.exfo.com/en/Products/Field-Network-Testing/Optical/Signal-Detection/LFD-300BTG-300B-FiberFinder/
> - a plunger (not sure about the english translation for this one too :-) )
>
>

-- 
Leonardo Rizzi
Web: www.deepreflect.net
Home: +39 02 45071118
Mobile: +39 339 8387915
Mobile UK: +44 7895 873667


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5145 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120218/b198b30c/attachment.bin>

From tvhawaii at shaka.com  Sat Feb 18 02:55:44 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Fri, 17 Feb 2012 22:55:44 -1000
Subject: Common operational misconceptions
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
 <4F3F59A9.5060800@paulgraydon.co.uk>
Message-ID: <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>

Paul Graydon wrote:
> Give me someone who can already think and analyse over someone who
> 'knows' it all, any day.  You can be qualified to the hilt but
> absolutely useless in the real world (I've watched CCNP and higher
> struggling to figure out why they can't ping a 10.0.0.0/24 address at a
> customers remote site, not even realising it's a private range, let
> alone trying to trace the path of the ping,)

Hard to believe, but you're obviously serious.  What are their job titles?  What were they hired to accomplish?
Also hard for me to understand that someone could study for CCNx and not get exposed to Private space and 1918...what am I 
missing?

--Michael 



From jeroen at mompl.net  Sat Feb 18 03:22:16 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Sat, 18 Feb 2012 01:22:16 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3C51F4.2020305@rancid.berkeley.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C51F4.2020305@rancid.berkeley.edu>
Message-ID: <4F3F6DC8.2030302@mompl.net>

Michael Sinatra wrote:
> The words "Internet" and "Web" can be used interchangeably

I prefer the term "intergophers" myself.

-- 
Earthquake Magnitude: 4.9
Date: Friday, February 17, 2012 14:28:20 UTC
Location: Komandorskiye Ostrova, Russia region
Latitude: 54.5969; Longitude: 168.8863
Depth: 34.70 km



From leigh.porter at ukbroadband.com  Sat Feb 18 03:35:49 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Sat, 18 Feb 2012 09:35:49 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>,
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
Message-ID: <FC6F66ED-1A09-43D6-A2E9-DADD8E531337@ukbroadband.com>


On 18 Feb 2012, at 01:46, "Owen DeLong" <owen at delong.com> wrote:

> I have, on occasion been away from my laptop and gotten the call to go to the colo and deal with XYZ hardware problem and the colo was either: A in the opposite or orthogonal direction from  my house and significantly closer or B the colo was between my present location.
> 
> In such cases, I will occasionally stop by the colo without going home to retrieve the laptop. 90% of the time it works out OK. 10% of the time I end up leaving the colo, going home, retrieving the laptop and returning to the colo. Obviously, if there was a loaner laptop available for a $15 rental in the colo as described, it would probably be worth $15 to me and/or my organization to avoid the delay and bother of the round-trip between colo and home.
> 
> Owen
> 


Yeah done that a few times.. Now all our colo sites have a kit with laptop (that boots win 7,  XP and Linux) serial USB things, USB ethernet things and that has a DVD/cd burner and a stock of blanks and a 3G dongle thing.

I.e. everything I have ever had to go home/office/nearest-shop for..

So now when our guys to go colo, they can usually take anything and have most  things they need there already.

Now we need to nail them down so people DON'T BRING THEM BACK TO THE OFFICE.

--
Leigh


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


From lists at 1337.mx  Sat Feb 18 04:16:50 2012
From: lists at 1337.mx (toor)
Date: Sat, 18 Feb 2012 18:16:50 +0800
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218033210.88103.qmail@joyce.lan>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
Message-ID: <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>

I use http://www.startssl.com/ for all my personal certifcates. I have
not had any issues with the validations (once you have an account you
can validate a domain by sending an email to a predefined list of
contact addresses) and the certificates are issued instantly.

On Sat, Feb 18, 2012 at 11:32 AM, John Levine <johnl at iecc.com> wrote:
> I use these guys: http://www.cheapssls.com/
>
> They sell Geotrust and Comodo certs for under $10/yr. ?The hassle
> level is quite low. ?First you order a cert providing the usual
> billing info, then you go to their web site, pick the order you just
> paid for, go to a screen where you paste in your signing request, and
> pick which e-mail address to send the confirmation message to. ?Click
> a URL in the confirmation message and the signed cert shows up in a
> few minutes. ?The certs are chained, but I've had no acceptance
> problems once I realized I had to to add an extra Apache config line
> to serve the intermediate cert.
>
> If you get a Comodo cert for example.com, it'll also work for
> www.example.com. ?Other than that, they seem to be equivalent.
>
> If you just want something for testing, http://freessl.com/ will
> provide a real 30 day Geotrust cert for free, with similarly low
> hassle. ?At the end of the 30 days, you can renew the cert into a paid
> one at cheapssls or any other Geotrust reseller.
>
> I realize there are places that will provide totally free certs, but
> their hassle level is far greater. ?For $24 I can get a Comodo cert
> that will make my SSL complaints go away for three years, which seems
> like a bargain to me.
>
> R's,
> John
>


From mohta at necom830.hpcl.titech.ac.jp  Sat Feb 18 05:31:52 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Sat, 18 Feb 2012 20:31:52 +0900
Subject: Common operational misconceptions
In-Reply-To: <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
Message-ID: <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>

David Barak wrote:

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

I'm afraid both of you don't try to understand why NAT was
harmful to destroy the end to end transparency nor the end
to end argument presented in the original paper by Saltezer
et. al:

       The function in question can completely and correctly be
       implemented only with the knowledge and help of the application
       standing at the end points of the communication system. Therefore,
       providing that questioned function as a feature of the
       communication system itself is not possible.

While plain NAT, which actively hide itself from end systems,
which means there can be no "knowledge and help of the
application" expected, is very harmful to the end to end
transparency, it is possible to entirely neutralize the
harmful effects, by let NAT boxes ask help end systems.

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

The reality is much better that NAT is not so harmful if NAT
clients and gateways are designed properly to be able to
reverse the harmful translations by NAT gateways.

I have running code to make the reverse translations, with
which protocols such as ftp with PORT commands are working.

					Masataka Ohta


From regnauld at nsrc.org  Sat Feb 18 07:27:05 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sat, 18 Feb 2012 14:27:05 +0100
Subject: X.509 Certs For Personal Use
In-Reply-To: <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
Message-ID: <20120218132705.GC81143@macbook.bluepipe.net>

toor (lists) writes:
> I use http://www.startssl.com/ for all my personal certifcates. I have
> not had any issues with the validations (once you have an account you
> can validate a domain by sending an email to a predefined list of
> contact addresses) and the certificates are issued instantly.

	"Your request is being held up for review by our personnel".
	
	Up to 6 hours. Must be their definition of instant :)

	Cheers,
	Phil


From nanog at maunier.org  Sat Feb 18 07:36:41 2012
From: nanog at maunier.org (Pierre-Yves Maunier)
Date: Sat, 18 Feb 2012 14:36:41 +0100
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EDAEF.1020909@thebaughers.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
Message-ID: <CAEGdXrOJFPauKKnRdCcnhzQsq94GN0Z6Xus=nR4zNYU+O8zzFQ@mail.gmail.com>

2012/2/17 Jason Baugher <jason at thebaughers.com>

> Do you guys ride your bike to the colo and show up in shorts and a
> t-shirt? Who goes to the colo without things like their laptop?
>
>
Nope but sometimes you can forget some things.
I usually try to take everything to cover my needs while on site but it can
happens you forget something if you're in hurry.

I always have this in my bag along with my laptop when I go on site :
http://goo.gl/O2deX
- a leatherman
- some LC/SC couplers
- 1GE-TX tri-rate (10/100/1000M) SFP, 1GE LX multirate SFP (up to STM16)
- LC and SC loop patch cord
- 2x7dB SC attenuators
- usb-rs232 adaptor + rs232-rj45 adaptor
- 2xCAT5 cable : 2 meters + 10 cm
- 1xRJ45 straight coupler

Some times I need something else like a laser pen of a power meter that I
can't always bring with me and that I can forget when I go on site. Or if
I've just used one of these in the office I can forget to put them back in
my bag and I would need it on site.

Having the possibility to have these on site is usefull even if you're not
the kind of guy going without anything or like with say in french : with
your dick and your knife.


-- 
Pierre-Yves Maunier

From jgreco at ns.sol.net  Sat Feb 18 08:39:39 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Sat, 18 Feb 2012 08:39:39 -0600 (CST)
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EDAEF.1020909@thebaughers.com>
Message-ID: <201202181439.q1IEdf1Y079184@aurora.sol.net>

> Do you guys ride your bike to the colo and show up in shorts and a 
> t-shirt? Who goes to the colo without things like their laptop?

Quite frankly, when the colo is 800 miles away and you've flown out
to do something important, only to be tripped up by a lack of some
stupid $something, and it's 11PM at night, you get a very different
(*very* different) outlook on it all.  Especially with the way it is
these days to fly, you don't want to be carrying odd stuff with you
if you can avoid it.  We'll ship gear via FedEx or UPS.  We rely on
existing on-site supplies to cover most unexpected stuff.

It is easy to justify keeping a well-stocked toolbox with a ton of
generally-useful tools, and also some specialty tools, for example.  

Our Ashburn toolbox contains, among other things:

Laminated maps of the area with distributors like Graybar located (now
probably useless, 8 years out of date, anyone familiar with NoVA will
understand, haha), Notebook and pen, pencil

Precision flat & Phillips screwdrivers, Mini Maglite, Sharpie RGB Markers,
Utility Knife (cutting boxes), Xacto Knife set, hex bit extensions, DB25 pin
inserter/extractor tools, scissors, surgeon's clamp, metal nibbler, wire
stripper, various general crimp tools, several pliers, several needlenose/
bent-nose, flush cutters, adjustable wrenches, Victorinox Swiss CyberTool,
Milwaukee Power Screwdriver #6546.  22" (not a typo) hex Phillips bit.

Outlet wiring tester, telephone line tester, RS232 snooper, AUI xcvr (don't
laugh, I actually used one within the last 5 years), wire wrap tool and
wire, pencils and sharpener, anti-static wrist strap, logic probe, tool
magnetizer, digital multimeter, soldering iron and supplies, electrical
tape, punchdown tool, heat shrink tubing kit, hex key sets, socket drive
sets, medium screwdrivers.

Tap & drill set, 20' tape measure, hammer, rubber mallet, big pliers, big
utility knife, torp level, various bit kits, large adj wrench, tongue and
groove pliers, big wire cutters/needle nose, spare charger and battery
for power screwdriver, small cordless drill, crimpers, first aid kit,
big MagLite, test lead kit, serial adapter kit.

Now I will concede that we've used a lot of this stuff only a few times
over the years, and some of it maybe even never, but the point is that
it really stinks to be on-site and in-need without an easy way to address
the need.  It's really amusing that there've been people who have made
it a habit to borrow tools out of our toolbox "because we have just
about anything."

Since you guys like pictures:

http://www.sol.net/tmp/nanog/toolbox1.jpg
http://www.sol.net/tmp/nanog/toolbox2.jpg
http://www.sol.net/tmp/nanog/toolbox3.jpg

We also keep some small roughtotes with:

Fiber supplies
Copper supplies
Power cords etc
Server parts
Telecom supplies

So, yes, sometimes I show up at the colo in shorts and a t-shirt.  Matter
of fact, most of the time I do.  It's more fun that way.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From john-nanog at johnpeach.com  Sat Feb 18 09:44:52 2012
From: john-nanog at johnpeach.com (John Peach)
Date: Sat, 18 Feb 2012 10:44:52 -0500
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218132705.GC81143@macbook.bluepipe.net>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
Message-ID: <20120218104452.62cc383e@milhouse>

On Sat, 18 Feb 2012 14:27:05 +0100
Phil Regnauld <regnauld at nsrc.org> wrote:

> toor (lists) writes:
> > I use http://www.startssl.com/ for all my personal certifcates. I have
> > not had any issues with the validations (once you have an account you
> > can validate a domain by sending an email to a predefined list of
> > contact addresses) and the certificates are issued instantly.
> 
> 	"Your request is being held up for review by our personnel".
> 	
> 	Up to 6 hours. Must be their definition of instant :)

It's nice to see that they actually do random reviews, rather than just
issuing everything requested. I use startssl and have not had anything
held for review.

> 
> 	Cheers,
> 	Phil
> 


-- 
John


From regnauld at nsrc.org  Sat Feb 18 10:37:37 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sat, 18 Feb 2012 17:37:37 +0100
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218104452.62cc383e@milhouse>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
 <20120218104452.62cc383e@milhouse>
Message-ID: <20120218163737.GD89362@macbook.bluepipe.net>

John Peach (john-nanog) writes:
> > 
> > 	"Your request is being held up for review by our personnel".
> > 	
> > 	Up to 6 hours. Must be their definition of instant :)
> 
> It's nice to see that they actually do random reviews, rather than just
> issuing everything requested. I use startssl and have not had anything
> held for review.

	And I did get my account and cert shortly after. So they are quick.

	On the other hand, I'm not sure I'd trust a cert where they
	happen to be the ones generating the key and the CSR themselves.
	Yes, it's free, but that doesn't mean I want to give up all forms
	of security :)

	Cheers,
	Phil


From johnl at iecc.com  Sat Feb 18 12:12:31 2012
From: johnl at iecc.com (John Levine)
Date: 18 Feb 2012 18:12:31 -0000
Subject: NANOG Digest, Vol 49, Issue 70
In-Reply-To: <4F3F591A.4020209@steadfast.net>
Message-ID: <20120218181231.20258.qmail@joyce.lan>

Here's a copy of one I recently got:

http://spample.iecc.com/sqz/22977784

It was sent from hub027-nj-8.exch027.serverdata.net [206.225.167.252]

-- 
Regards,
John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From sven at cb3rob.net  Sat Feb 18 12:27:12 2012
From: sven at cb3rob.net (Sven Olaf Kamphuis)
Date: Sat, 18 Feb 2012 18:27:12 +0000 (UTC)
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218010729.GA10033@ussenterprise.ufp.org>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
Message-ID: <Pine.LNX.4.64.1202181823170.32438@a84-22-97-10.cb3rob.net>

>
> Are there any providers that target someone with my desires?  What
> providers do NANOG folks use for their _personal_ needs?

none at all, we choose NOT to make ourselves dependant on external 
suppliers as far as posibble and this includes NOT having SSL which is 
lacky in encryption, as well as overal security (bufferoverflows and what 
not) anyway, as well as "external parties" having YOUR keys. (whomever 
came up with that idea must work for some other government or have been on 
crack ;)

in short: no go, just encrypt your layer 2/3 if you don't trust the 
"way there" with a mechanism of your own, not supplied by un screened 
third parties

(quite sure verybad notwork solution is full of cia spies, but we have 
none of ours in there, so screw them ;)


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


From paul at paulgraydon.co.uk  Sat Feb 18 12:55:20 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Sat, 18 Feb 2012 08:55:20 -1000
Subject: Common operational misconceptions
In-Reply-To: <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
 <4F3F59A9.5060800@paulgraydon.co.uk>
 <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>
Message-ID: <4F3FF418.2000009@paulgraydon.co.uk>

On 2/17/2012 10:55 PM, Michael Painter wrote:
> Paul Graydon wrote:
>> Give me someone who can already think and analyse over someone who
>> 'knows' it all, any day.  You can be qualified to the hilt but
>> absolutely useless in the real world (I've watched CCNP and higher
>> struggling to figure out why they can't ping a 10.0.0.0/24 address at a
>> customers remote site, not even realising it's a private range, let
>> alone trying to trace the path of the ping,)
>
> Hard to believe, but you're obviously serious.  What are their job 
> titles?  What were they hired to accomplish?
> Also hard for me to understand that someone could study for CCNx and 
> not get exposed to Private space and 1918...what am I missing?
>
Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for 
an ISP & Hosting company.  For the company the NOC team was the top tier 
of customer support (3rd line+), they looked after routers, switches, 
firewalls, servers, leased lines, and so on.
This individual was perfectly capable of regurgitating all the facts, 
figures and technical details you can imagine, probably pretty much the 
entire CCNP syllabus.  What they didn't seem that capable of was 
actually applying that to anything.  I'd bet good money that if I'd 
asked him at the time what the 1918 network ranges are he'd have been 
able to tell me.
This is exactly what we're teaching kids to do these days (makes me feel 
so old that I've already been saying this for several years and I'm only 
31) standardised tests aren't marked based on ability to apply 
knowledge, just the knowledge itself.  Hence my view, give me someone 
who knows how to think over someone who is qualified to the hilt.  These 
exam cram 'do a CCNP in a week' courses only serve to make it worse.

Paul


From astrodog at gmail.com  Sat Feb 18 12:55:42 2012
From: astrodog at gmail.com (Astrodog)
Date: Sat, 18 Feb 2012 12:55:42 -0600
Subject: Colo Vending Machine
In-Reply-To: <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
Message-ID: <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>

On Fri, Feb 17, 2012 at 7:13 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com> wrote:
> On Sat, Feb 18, 2012 at 01:02, George Herbert <george.herbert at gmail.com> wrote:
> ....
>>> Will IANA accept netblock transfers as an exchange medium for
>>> datacenter goodies vending machine payments? ... ?;-)
>>
>> Joking while busy discouraged. ?s/IANA/ARIN/d'oh
>
> I suspect ARIN would follow its policy to recognize
> any transfer and update its records as long as the
> needs assessment was successfully completed,
> but any compensation between the seller and
> buyer of the resource is not part of the ARIN process.
>
> (This is a (bad?) joke reference to a currently
> ongoing discussion on the ARIN PPML list).
>

Hah. So, this should work, provided both entities are on the STSL then.

--- Harrison


From morrowc.lists at gmail.com  Sat Feb 18 12:57:25 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 18 Feb 2012 13:57:25 -0500
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218104452.62cc383e@milhouse>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
 <20120218104452.62cc383e@milhouse>
Message-ID: <CAL9jLaaVSa+c+=aTb5kdj4huXLQ4_Rrj3tw=+gG0_o4-8=q0Eg@mail.gmail.com>

On Sat, Feb 18, 2012 at 10:44 AM, John Peach <john-nanog at johnpeach.com> wrote:
> On Sat, 18 Feb 2012 14:27:05 +0100
> Phil Regnauld <regnauld at nsrc.org> wrote:
>
>> toor (lists) writes:
>> > I use http://www.startssl.com/ for all my personal certifcates. I have
>> > not had any issues with the validations (once you have an account you
>> > can validate a domain by sending an email to a predefined list of
>> > contact addresses) and the certificates are issued instantly.
>>
>> ? ? ? "Your request is being held up for review by our personnel".
>>
>> ? ? ? Up to 6 hours. Must be their definition of instant :)
>
> It's nice to see that they actually do random reviews, rather than just
> issuing everything requested. I use startssl and have not had anything
> held for review.

I've had most of mine held, but almost always I get a response in side
of 20 mins. Really, what I care about here is:
  1) cert validates in almost all clients (mozilla/chrome/mail.app)
  2) controlled/secured by my key, not something made up on the server side
  3) not paying money for random bytes.

it works and eddy's pretty quick on requests.

-chris

>>
>> ? ? ? Cheers,
>> ? ? ? Phil
>>
>
>
> --
> John
>


From morrowc.lists at gmail.com  Sat Feb 18 12:58:52 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 18 Feb 2012 13:58:52 -0500
Subject: X.509 Certs For Personal Use
In-Reply-To: <20120218163737.GD89362@macbook.bluepipe.net>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
 <20120218104452.62cc383e@milhouse>
 <20120218163737.GD89362@macbook.bluepipe.net>
Message-ID: <CAL9jLabp=uWCogyrVhAE=-v6bpao1ykZ4_GfLzJE_F_r3ckoBA@mail.gmail.com>

On Sat, Feb 18, 2012 at 11:37 AM, Phil Regnauld <regnauld at nsrc.org> wrote:
> John Peach (john-nanog) writes:
>> >
>> > ? ? "Your request is being held up for review by our personnel".
>> >
>> > ? ? Up to 6 hours. Must be their definition of instant :)
>>
>> It's nice to see that they actually do random reviews, rather than just
>> issuing everything requested. I use startssl and have not had anything
>> held for review.
>
> ? ? ? ?And I did get my account and cert shortly after. So they are quick.
>
> ? ? ? ?On the other hand, I'm not sure I'd trust a cert where they
> ? ? ? ?happen to be the ones generating the key and the CSR themselves.
> ? ? ? ?Yes, it's free, but that doesn't mean I want to give up all forms
> ? ? ? ?of security :)

<http://goo.gl/thGxC> (sorry, the blog's url is stupid and long)

use your own key materials and gen your own csr ... silly simple.

>
> ? ? ? ?Cheers,
> ? ? ? ?Phil
>


From hrlinneweh at sbcglobal.net  Sat Feb 18 13:02:25 2012
From: hrlinneweh at sbcglobal.net (Henry Linneweh)
Date: Sat, 18 Feb 2012 11:02:25 -0800 (PST)
Subject: DNS Attacks
In-Reply-To: <CALjCmpma-gXUerPUfeAWtgZn4qtVkxJTaEFL3D9Gc0OTvS96oQ@mail.gmail.com>
References: <CALjCmpma-gXUerPUfeAWtgZn4qtVkxJTaEFL3D9Gc0OTvS96oQ@mail.gmail.com>
Message-ID: <1329591745.49831.YahooMailNeo@web180303.mail.gq1.yahoo.com>



http://thehackernews.com/2012/02/fbi-will-shutdown-internet-on-march-8.html


________________________________
From: toor <lists at 1337.mx>
To: nanog at nanog.org 
Sent: Tuesday, January 17, 2012 9:04 PM
Subject: DNS Attacks

Hi list,

I am wondering if anyone else has seen a large amount of DNS queries
coming from various IP ranges in China. I have been trying to find a
pattern in the attacks but so far I have come up blank. I am completly
guessing these are possibly DNS amplification attacks but I am not
sure. Usually what I see is this:

- Attacks most commonly between the hours of 4AM-4PM UTC
- DNS queries appear to be for real domains that the DNS servers in
question are authoritive for (I can't really see any pattern there,
there are about 150,000 zones on the servers in question)
- From a range of IP's there will be an attack for approximately 5-10
minutes before stopping and then a break of 30 minutes or so before
another attack from a different IP range
- Every IP range has been from China

I have limited the number of queries that can be done to mitigate this
but its messing up my pretty netflow graphs due to the spikes in
flows/packets being sent.

Does anyone have any ideas what the reasoning behind this could be? I
would also be interested to hear from anyone else experiencing this
too.

I can provide IP ranges from where I am seeing the issue but it does
vary a lot between the attacks with the only pattern every time being
the source address is located in China. I read a thread earlier,
http://seclists.org/nanog/2011/Nov/920, which sounds like the exact
thing I am seeing.

Thanks

From cdl at asgaard.org  Sat Feb 18 13:04:21 2012
From: cdl at asgaard.org (Christopher LILJENSTOLPE)
Date: Sat, 18 Feb 2012 11:04:21 -0800
Subject: X.509 Certs For Personal Use
In-Reply-To: <CAL9jLaaVSa+c+=aTb5kdj4huXLQ4_Rrj3tw=+gG0_o4-8=q0Eg@mail.gmail.com>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
 <20120218104452.62cc383e@milhouse>
 <CAL9jLaaVSa+c+=aTb5kdj4huXLQ4_Rrj3tw=+gG0_o4-8=q0Eg@mail.gmail.com>
Message-ID: <F6FA331C-27CC-48EF-877E-CAB9BC7C0D41@asgaard.org>

Greetings I'll +1 Chris's experience with startssl

On 18Feb2012, at 10.57, Christopher Morrow wrote:

> On Sat, Feb 18, 2012 at 10:44 AM, John Peach <john-nanog at johnpeach.com> wrote:
>> On Sat, 18 Feb 2012 14:27:05 +0100
>> Phil Regnauld <regnauld at nsrc.org> wrote:
>> 
>>> toor (lists) writes:
>>>> I use http://www.startssl.com/ for all my personal certifcates. I have
>>>> not had any issues with the validations (once you have an account you
>>>> can validate a domain by sending an email to a predefined list of
>>>> contact addresses) and the certificates are issued instantly.
>>> 
>>>       "Your request is being held up for review by our personnel".
>>> 
>>>       Up to 6 hours. Must be their definition of instant :)
>> 
>> It's nice to see that they actually do random reviews, rather than just
>> issuing everything requested. I use startssl and have not had anything
>> held for review.
> 
> I've had most of mine held, but almost always I get a response in side
> of 20 mins. Really, what I care about here is:
>  1) cert validates in almost all clients (mozilla/chrome/mail.app)
>  2) controlled/secured by my key, not something made up on the server side
>  3) not paying money for random bytes.
> 
> it works and eddy's pretty quick on requests.
> 
> -chris
> 
>>> 
>>>       Cheers,
>>>       Phil
>>> 
>> 
>> 
>> --
>> John
>> 
> 

--  
???
Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc
Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120218/4b5351d9/attachment.bin>

From gbonser at seven.com  Sat Feb 18 14:36:50 2012
From: gbonser at seven.com (George Bonser)
Date: Sat, 18 Feb 2012 20:36:50 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F3FF418.2000009@paulgraydon.co.uk>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
 <4F3F59A9.5060800@paulgraydon.co.uk>
 <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>
 <4F3FF418.2000009@paulgraydon.co.uk>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD3DCE@RWC-MBX1.corp.seven.com>

> Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for
> an ISP & Hosting company.  

There was a time a new hire with all the right holes punched in his ticket deleted an item in an access-list in a PIX that was running an older version of the software than he was familiar with.  The entire access-list disappeared and he was locked out, production stopped, like a train hitting a brick wall.  


> For the company the NOC team was the top
> tier of customer support (3rd line+), they looked after routers,
> switches, firewalls, servers, leased lines, and so on.
> This individual was perfectly capable of regurgitating all the facts,
> figures and technical details you can imagine, probably pretty much the
> entire CCNP syllabus.  What they didn't seem that capable of was
> actually applying that to anything.

You might be surprised at how common that is.  If you present them with ALL the diagrams and ALL of the configs on paper, they can figure it out.  In other words, if you recreate the same environment they had in their training class, they can do fine.  But what some can't seem to be able to do is visualize in their head how things are.  It is that layer of abstraction that separates them out.  They are fine for maintaining documentation or even for participating in a design review but you don't want them designing some new addition to the network or working on something "live".  My first clue often comes from the quality of diagrams they produce. If the diagrams are accurate as far as what connects to what but do not reflect the actual flow of the network, that's a telltale sign.  Sort of like an electronic schematic.  If they sort of have random components/stages at random locations in the drawing that doesn't really reflect the functional flow through the device, that is my clue that I am likely dealing with a concrete thinker and not an abstract thinker.  Ditto if they demand that the symbol representing a particular piece of gear actually be a picture of that piece of gear.  If they get lost when gear is represented by a square box then they are probably part of the normal 85% of people who find it more difficult (actually have to try) to translate a square box on a diagram to a router in the rack in their head vs the 15% who do that naturally without any effort.

The access-list guy mentioned above would be great for looking at the config and producing a new one with the correct access control, but you wouldn't want him to be the one to apply it in production on a live network.  So even in that guy's case, there is a place where their skills can be quite useful and there are other places where their chance of making a costly mistake increase.  It is a matter of matching the person's role to their skills.

> I'd bet good money that if I'd
> asked him at the time what the 1918 network ranges are he'd have been
> able to tell me.

You'll be surprised how many people "forget" that 172.28.0.0 is rfc1918 space.  They are so used to seeing 172.16 that they tend to forget 172.17-31. I've had to change null routes and access controls to include the entire /12.  They "know" that it is a /12 but seem to forget in practice when they see a second octet that isn't "16".


> This is exactly what we're teaching kids to do these days (makes me
> feel so old that I've already been saying this for several years and
> I'm only
> 31) standardised tests aren't marked based on ability to apply
> knowledge, just the knowledge itself. 

Yes.  We teach them facts but now how to FIND facts.  Part of teaching is in teaching how to teach yourself.  It started with me when I was a kid.  When I had a question, my father would always say "look it up and tell me" even if he knew the answer perfectly well.  He had invested in an encyclopedia and the annual updates and was determined that I would use it.  It taught me how to research to find my own answers and it taught me to learn it well enough to explain it to someone else because Pop would always throw in a couple of questions for me after I explained it to him just to see if I actually "got" the underlying concept.  Besides, often in the course of researching one thing, I happened across a completely unrelated thing that caught my interest in that volume of the book and learned something I hadn't even been looking for.  Forget the Internet, for people with kids at home, I would recommend a hard copy set of World Book with the Year Book and Science Year annual additions.  That one in particular because the style in which they are written, they are actually pretty fun to read and have a lot of illustrations. http://www.worldbook.com/browse-all-products/item/953-advanced-research-package-2012 (no affiliation at all with them, just a satisfied "customer").  Soon, going to the books when a question arose became natural.

It is one thing to produce a "teachable" child, something quite different to produce the ability to learn independently and allow their own natural curiosity to "pull" them to that knowledge.



From streiner at cluebyfour.org  Sat Feb 18 14:41:28 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 18 Feb 2012 15:41:28 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <4F3D54B5.4000109@rancid.berkeley.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D54B5.4000109@rancid.berkeley.edu>
Message-ID: <Pine.LNX.4.64.1202181534220.23972@whammy.cluebyfour.org>

On Thu, 16 Feb 2012, Michael Sinatra wrote:

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

I have a few cruddy old 1950s (or earlier) buildings on campus where I can 
find thicknet and (dead for many years) vampire taps, along with thinnet, 
many different vintages of voice and data cabling, and many different 
vintages of fiber, including lots of OM1 multimode.  Makes for some very 
interesting pictures and "what *is* that?" conversations.

jms


From tom at ninjabadger.net  Sat Feb 18 15:04:04 2012
From: tom at ninjabadger.net (Tom Hill)
Date: Sat, 18 Feb 2012 21:04:04 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F401244.4050106@ninjabadger.net>

On 17/02/12 18:35, Jay Ashworth wrote:
> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't
> let vendor specificity scare you off.
>
> Cheers,
> -- jra

I thought they already existed: http://gearomat.com/

That one's a FlexOptix idea, so the vending machine will indeed 'vend' 
optics and then also go on to code them for your chosen hardware.

I thought it was a neat idea when I spoke to Fearghas about it a year or 
so ago, though I've still not seen one around yet.

Tom




From tvhawaii at shaka.com  Sat Feb 18 15:15:31 2012
From: tvhawaii at shaka.com (Michael Painter)
Date: Sat, 18 Feb 2012 11:15:31 -1000
Subject: Common operational misconceptions
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
 <4F3F59A9.5060800@paulgraydon.co.uk>
 <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>
 <4F3FF418.2000009@paulgraydon.co.uk>
Message-ID: <0CFE0F59F0F34B10B07BCB0EC9E29DBD@owner59e1f1502>

Paul Graydon wrote:
>> Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for
> an ISP & Hosting company.  For the company the NOC team was the top tier
> of customer support (3rd line+), they looked after routers, switches,
> firewalls, servers, leased lines, and so on.
> This individual was perfectly capable of regurgitating all the facts,
> figures and technical details you can imagine, probably pretty much the
> entire CCNP syllabus.  What they didn't seem that capable of was
> actually applying that to anything.  I'd bet good money that if I'd
> asked him at the time what the 1918 network ranges are he'd have been
> able to tell me.
> This is exactly what we're teaching kids to do these days (makes me feel
> so old that I've already been saying this for several years and I'm only
> 31) standardised tests aren't marked based on ability to apply
> knowledge, just the knowledge itself.  Hence my view, give me someone
> who knows how to think over someone who is qualified to the hilt.  These
> exam cram 'do a CCNP in a week' courses only serve to make it worse.
>
> Paul

Ahh, I get you now...thanks.

Took me back to '64 and the battery of tests (all day!) I was given before getting hired by IBM for the 360 rollout.  I 
was amazed by the amount of questions of the "if gear a turns ccw, what does lever b do?" variety.
Later I was told that -all- the testing results were important, even the psychological ones, but what they really wanted 
to find was the best analytical *mind*.

Best,

--Michael 



From efbatey at gmail.com  Sat Feb 18 15:32:42 2012
From: efbatey at gmail.com (Everett Batey)
Date: Sat, 18 Feb 2012 13:32:42 -0800
Subject: facebook.com DNS not found 20120218 2125 UTC
Message-ID: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>

facebook.com DNS not found 20120218 2125 UTC
Is there any outage information for DNS for  facebook.com / www.facebook.com
 ?
  "Oops! Google Chrome could not find www.facebook.com"


On Fri, Feb 17, 2012 at 11:26 PM, <nanog-request at nanog.org> wrote:

> Send NANOG mailing list submissions to
>        nanog at nanog.org
>
>
-- 
 R/  Everett Batey / Skype: wa6cre-10 / efbatey at gmail.com
  or efbarc at cotdazr.org or wa6cre at rabbitradio.org or lioneverett at gmail.com
   Lions 4-A3 Calendar  / CrisisLinks http://bit.ly/cw95Um
    Please visit So Calif Linux Expo http://www.socallinuxexpo.org
     (805) 616-2471 / G-Talk/Twitter: efbatey

From john-nanog at johnpeach.com  Sat Feb 18 15:39:43 2012
From: john-nanog at johnpeach.com (John Peach)
Date: Sat, 18 Feb 2012 16:39:43 -0500
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
References: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
Message-ID: <20120218163943.5cb5159a@milhouse>

On Sat, 18 Feb 2012 13:32:42 -0800
Everett Batey <efbatey at gmail.com> wrote:

> facebook.com DNS not found 20120218 2125 UTC
> Is there any outage information for DNS for  facebook.com / www.facebook.com
>  ?
>   "Oops! Google Chrome could not find www.facebook.com"

Not here

dig +trace www.facebook.com

; <<>> DiG 9.7.3 <<>> +trace www.facebook.com
;; global options: +cmd
.                       157853  IN      NS      d.root-servers.net.
.                       157853  IN      NS      j.root-servers.net.
.                       157853  IN      NS      c.root-servers.net.
.                       157853  IN      NS      f.root-servers.net.
.                       157853  IN      NS      b.root-servers.net.
.                       157853  IN      NS      l.root-servers.net.
.                       157853  IN      NS      h.root-servers.net.
.                       157853  IN      NS      m.root-servers.net.
.                       157853  IN      NS      a.root-servers.net.
.                       157853  IN      NS      k.root-servers.net.
.                       157853  IN      NS      g.root-servers.net.
.                       157853  IN      NS      e.root-servers.net.
.                       157853  IN      NS      i.root-servers.net.
;; Received 228 bytes from 192.168.1.2#53(192.168.1.2) in 3 ms

com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
;; Received 494 bytes from 192.5.5.241#53(f.root-servers.net) in 99 ms

facebook.com.           172800  IN      NS      ns1.facebook.com.
facebook.com.           172800  IN      NS      ns2.facebook.com.
facebook.com.           172800  IN      NS      ns3.facebook.com.
facebook.com.           172800  IN      NS      ns4.facebook.com.
facebook.com.           172800  IN      NS      ns5.facebook.com.
;; Received 204 bytes from 192.33.14.30#53(b.gtld-servers.net) in 208 ms

www.facebook.com.       86400   IN      NS      glb1.facebook.com.
www.facebook.com.       86400   IN      NS      glb2.facebook.com.
;; Received 104 bytes from 66.220.151.20#53(ns3.facebook.com) in 91 ms

www.facebook.com.       120     IN      A       69.171.234.96
;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 20 ms


> 
> 
> On Fri, Feb 17, 2012 at 11:26 PM, <nanog-request at nanog.org> wrote:
> 
> > Send NANOG mailing list submissions to
> >        nanog at nanog.org
> >
> >


-- 
John


From Joel.Snyder at Opus1.COM  Sat Feb 18 15:41:39 2012
From: Joel.Snyder at Opus1.COM (Joel M Snyder)
Date: Sat, 18 Feb 2012 14:41:39 -0700
Subject: DNS Attacks
In-Reply-To: <mailman.4221.1329597418.46019.nanog@nanog.org>
References: <mailman.4221.1329597418.46019.nanog@nanog.org>
Message-ID: <4F401B13.3060202@opus1.com>


> http://thehackernews.com/2012/02/fbi-will-shutdown-internet-on-march-8.html

Quoting the FBI:

85.255.112.0 through 85.255.127.255
67.210.0.0 through 67.210.15.255
93.188.160.0 through 93.188.167.255
77.67.83.0 through 77.67.83.255
213.109.64.0 through 213.109.79.255
64.28.176.0 through 64.28.191.255

Solve said problem easily by destination NATing those IPs on 53/UDP/TCP 
to your own recursive servers, or dump them on Google at 8.8.8.8 if 
you're so inclined.  Extra bonus result: NAT logs will show who needs a 
pleasant email from customer service.

Or you could just let 'em[1] suffer, BoFH-style.

jms

[1] "'em" in this case is "your customer service reps" who will see a 
'higher than normal call volume' should the FBI's warning mean anything.

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
jms at Opus1.COM                http://www.opus1.com/jms


From israel.lugo at lugosys.com  Sat Feb 18 15:46:08 2012
From: israel.lugo at lugosys.com (Israel G. Lugo)
Date: Sat, 18 Feb 2012 21:46:08 +0000
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <20120218163943.5cb5159a@milhouse>
References: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
 <20120218163943.5cb5159a@milhouse>
Message-ID: <4F401C20.4010101@lugosys.com>

Likewise, working here.

$ dig +trace www.facebook.com

; <<>> DiG 9.7.0-P1 <<>> +trace www.facebook.com
;; global options: +cmd
.                       240259  IN      NS      b.root-servers.net.
.                       240259  IN      NS      g.root-servers.net.
.                       240259  IN      NS      i.root-servers.net.
.                       240259  IN      NS      c.root-servers.net.
.                       240259  IN      NS      f.root-servers.net.
.                       240259  IN      NS      d.root-servers.net.
.                       240259  IN      NS      l.root-servers.net.
.                       240259  IN      NS      m.root-servers.net.
.                       240259  IN      NS      j.root-servers.net.
.                       240259  IN      NS      e.root-servers.net.
.                       240259  IN      NS      a.root-servers.net.
.                       240259  IN      NS      h.root-servers.net.
.                       240259  IN      NS      k.root-servers.net.
;; Received 272 bytes from 192.168.100.1#53(192.168.100.1) in 1 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 494 bytes from 2001:7fd::1#53(k.root-servers.net) in 65 ms

facebook.com.           172800  IN      NS      ns1.facebook.com.
facebook.com.           172800  IN      NS      ns2.facebook.com.
facebook.com.           172800  IN      NS      ns3.facebook.com.
facebook.com.           172800  IN      NS      ns4.facebook.com.
facebook.com.           172800  IN      NS      ns5.facebook.com.
;; Received 204 bytes from 192.48.79.30#53(j.gtld-servers.net) in 361 ms

www.facebook.com.       86400   IN      NS      glb2.facebook.com.
www.facebook.com.       86400   IN      NS      glb1.facebook.com.
;; Received 104 bytes from 66.220.145.65#53(ns5.facebook.com) in 206 ms

www.facebook.com.       120     IN      A       69.63.190.22
;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 146 ms



On 02/18/2012 09:39 PM, John Peach wrote:
> On Sat, 18 Feb 2012 13:32:42 -0800
> Everett Batey <efbatey at gmail.com> wrote:
>
>> facebook.com DNS not found 20120218 2125 UTC
>> Is there any outage information for DNS for  facebook.com / www.facebook.com
>>  ?
>>   "Oops! Google Chrome could not find www.facebook.com"
> Not here
>
> dig +trace www.facebook.com
>
> ; <<>> DiG 9.7.3 <<>> +trace www.facebook.com
> ;; global options: +cmd
> .                       157853  IN      NS      d.root-servers.net.
> .                       157853  IN      NS      j.root-servers.net.
> .                       157853  IN      NS      c.root-servers.net.
> .                       157853  IN      NS      f.root-servers.net.
> .                       157853  IN      NS      b.root-servers.net.
> .                       157853  IN      NS      l.root-servers.net.
> .                       157853  IN      NS      h.root-servers.net.
> .                       157853  IN      NS      m.root-servers.net.
> .                       157853  IN      NS      a.root-servers.net.
> .                       157853  IN      NS      k.root-servers.net.
> .                       157853  IN      NS      g.root-servers.net.
> .                       157853  IN      NS      e.root-servers.net.
> .                       157853  IN      NS      i.root-servers.net.
> ;; Received 228 bytes from 192.168.1.2#53(192.168.1.2) in 3 ms
>
> com.                    172800  IN      NS      b.gtld-servers.net.
> com.                    172800  IN      NS      a.gtld-servers.net.
> com.                    172800  IN      NS      f.gtld-servers.net.
> com.                    172800  IN      NS      c.gtld-servers.net.
> com.                    172800  IN      NS      j.gtld-servers.net.
> com.                    172800  IN      NS      h.gtld-servers.net.
> com.                    172800  IN      NS      l.gtld-servers.net.
> com.                    172800  IN      NS      k.gtld-servers.net.
> com.                    172800  IN      NS      g.gtld-servers.net.
> com.                    172800  IN      NS      m.gtld-servers.net.
> com.                    172800  IN      NS      i.gtld-servers.net.
> com.                    172800  IN      NS      e.gtld-servers.net.
> com.                    172800  IN      NS      d.gtld-servers.net.
> ;; Received 494 bytes from 192.5.5.241#53(f.root-servers.net) in 99 ms
>
> facebook.com.           172800  IN      NS      ns1.facebook.com.
> facebook.com.           172800  IN      NS      ns2.facebook.com.
> facebook.com.           172800  IN      NS      ns3.facebook.com.
> facebook.com.           172800  IN      NS      ns4.facebook.com.
> facebook.com.           172800  IN      NS      ns5.facebook.com.
> ;; Received 204 bytes from 192.33.14.30#53(b.gtld-servers.net) in 208 ms
>
> www.facebook.com.       86400   IN      NS      glb1.facebook.com.
> www.facebook.com.       86400   IN      NS      glb2.facebook.com.
> ;; Received 104 bytes from 66.220.151.20#53(ns3.facebook.com) in 91 ms
>
> www.facebook.com.       120     IN      A       69.171.234.96
> ;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 20 ms
>
>
>>
>> On Fri, Feb 17, 2012 at 11:26 PM, <nanog-request at nanog.org> wrote:
>>
>>> Send NANOG mailing list submissions to
>>>        nanog at nanog.org
>>>
>>>
>


From bonomi at mail.r-bonomi.com  Sat Feb 18 16:29:17 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sat, 18 Feb 2012 16:29:17 -0600 (CST)
Subject: DNS Attacks
In-Reply-To: <4F401B13.3060202@opus1.com>
Message-ID: <201202182229.q1IMTHGS079581@mail.r-bonomi.com>


Joel M Snyder <Joel.Snyder at Opus1.COM> wrote;
>
> > http://thehackernews.com/2012/02/fbi-will-shutdown-internet-on-march-8.html
>
> Quoting the FBI:
>
> 85.255.112.0 through 85.255.127.255
> 67.210.0.0 through 67.210.15.255
> 93.188.160.0 through 93.188.167.255
> 77.67.83.0 through 77.67.83.255
> 213.109.64.0 through 213.109.79.255
> 64.28.176.0 through 64.28.191.255
>
> Solve said problem easily by destination NATing those IPs on 53/UDP/TCP 
> to your own recursive servers, or dump them on Google at 8.8.8.8 if 
> you're so inclined.  Extra bonus result: NAT logs will show who needs a 
> pleasant email from customer service.

Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
query -- returns the address of a dedicated machine on your network set up 
especially for this purpose.  This special-purpose machine returns a 
customized 'error message' for any/all 'standard' protocols -- one that
states that they are infected with the particular malware, that none of 
their attempts at intnernet access will work until they get that malware
removed, that they need to contact a 'computer repair' business ("See the
Yellow pages") to get the problem dealt with, -and- that assistance with 
such malware removal is -not- part your 'support' services.  Lastly, add
a statement that any calls to -your- support staff will cause the customer's
account a fee of $xx -- just for repeating the above.  Th special-purpose
machine logs all inbound connection attempts -- timestamp, source IP, and 
protocol -- for matching against customer accounts, providing a provable
audit trail to support the 'penalty' charge, when users -do- call 'support'.
Optionally, you refer them to a 'paid consulting' division of your operation,
which provides additional services on a time-and-materials basis.

This approach is -not- particularly 'customer-friendly' in the short term,
but it -will- have long-term benefits for the customer -- they _will_ have
learned something about the risks of not 'practicing safe hex', and their
machine(s) will (well, _probably_) be safer/more secure in the future.  Thus
reducing future problems for both the customer and the provider support desk.

> Or you could just let 'em[1] suffer, BoFH-style.
>
> [1] "'em" in this case is "your customer service reps" who will see a 
> 'higher than normal call volume' should the FBI's warning mean anything.




From regnauld at nsrc.org  Sat Feb 18 16:39:04 2012
From: regnauld at nsrc.org (Phil Regnauld)
Date: Sat, 18 Feb 2012 23:39:04 +0100
Subject: X.509 Certs For Personal Use
In-Reply-To: <CAL9jLabp=uWCogyrVhAE=-v6bpao1ykZ4_GfLzJE_F_r3ckoBA@mail.gmail.com>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
 <20120218033210.88103.qmail@joyce.lan>
 <CALjCmp=nDhWXoZh0MfhPuxUoxYxfPDrEZii2uEOysHQYm8AD_A@mail.gmail.com>
 <20120218132705.GC81143@macbook.bluepipe.net>
 <20120218104452.62cc383e@milhouse>
 <20120218163737.GD89362@macbook.bluepipe.net>
 <CAL9jLabp=uWCogyrVhAE=-v6bpao1ykZ4_GfLzJE_F_r3ckoBA@mail.gmail.com>
Message-ID: <EE2062E7-5F95-43EB-B758-9AEB4EDDBD1B@nsrc.org>



On 18/02/2012, at 19.58, Christopher Morrow <morrowc.lists at gmail.com> wrote:

> 
> <http://goo.gl/thGxC> (sorry, the blog's url is stupid and long)
> 
> use your own key materials and gen your own csr ... silly simple

Yep someone else pointed me to this off list. Very useful - thanks!

Cheers
Phil


From randy at psg.com  Sat Feb 18 17:27:24 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 18 Feb 2012 18:27:24 -0500
Subject: public scalable vpn?
Message-ID: <m2sji73eoz.wl%randy@psg.com>

academics in ontario are gonna need a scalable vpn service until they
find jobs elsewhere.

http://www.cautbulletin.ca/en_article.asp?SectionID=1386&SectionName=News&VolID=336&VolumeName=No%202&VolumeStartDate=2/10/2012&EditionID=36&EditionName=Vol%2059&EditionStartDate=1/19/2012&ArticleID=3400

i can only handle a dozen or so.  anyone running anything at scale?

randy


From gbonser at seven.com  Sat Feb 18 17:51:37 2012
From: gbonser at seven.com (George Bonser)
Date: Sat, 18 Feb 2012 23:51:37 +0000
Subject: public scalable vpn?
In-Reply-To: <m2sji73eoz.wl%randy@psg.com>
References: <m2sji73eoz.wl%randy@psg.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD4316@RWC-MBX1.corp.seven.com>

> academics in ontario are gonna need a scalable vpn service until they
> find jobs elsewhere.
> 
> http://www.cautbulletin.ca/en_article.asp?SectionID=1386&SectionName=Ne
> ws&VolID=336&VolumeName=No%202&VolumeStartDate=2/10/2012&EditionID=36&E
> ditionName=Vol%2059&EditionStartDate=1/19/2012&ArticleID=3400
> 
> i can only handle a dozen or so.  anyone running anything at scale?
> 
> randy

"The agreement reached last month with the licensing agency includes provisions defining e-mailing hyperlinks as equivalent to photocopying a document"

I certainly hope that is some politicized hype printed in that article and not real.  That is absolutely idiotic on the face of it.  When I have seen stuff like this printed in the past it has generally been over the top catastrophizing of an issue in order to inflame emotions.  I sure hope that's the case here.  Otherwise my impression of Canadians has sunk to a new low.  Why would it be in anyone's interest to sign such an agreement?




From gbonser at seven.com  Sat Feb 18 18:07:37 2012
From: gbonser at seven.com (George Bonser)
Date: Sun, 19 Feb 2012 00:07:37 +0000
Subject: public scalable vpn?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD4316@RWC-MBX1.corp.seven.com>
References: <m2sji73eoz.wl%randy@psg.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD4316@RWC-MBX1.corp.seven.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD4366@RWC-MBX1.corp.seven.com>

> I certainly hope that is some politicized hype printed in that article
> and not real.  

For example, if I have a copy of a copyrighted piece that I am not authorized to redistribute on a server and I send someone a hyperlink to it so they can download it, I can see that as different from sending them a hyperlink to the legitimate distribution outlet for the piece and I am concerned that the author of the article has been careful not to mention that distinction for the sole purpose of making it appear much more draconian than it really is.  On the other hand, giving a third party ANY access to my employees' correspondence for ANY purpose is reason to be seriously concerned as that could be abused in any number of ways.





From dmiller at tiggee.com  Sat Feb 18 19:09:54 2012
From: dmiller at tiggee.com (David Miller)
Date: Sat, 18 Feb 2012 20:09:54 -0500
Subject: public scalable vpn?
In-Reply-To: <m2sji73eoz.wl%randy@psg.com>
References: <m2sji73eoz.wl%randy@psg.com>
Message-ID: <4F404BE2.1070700@tiggee.com>

On 2/18/2012 6:27 PM, Randy Bush wrote:
> academics in ontario are gonna need a scalable vpn service until they
> find jobs elsewhere.
>
> http://www.cautbulletin.ca/en_article.asp?SectionID=1386&SectionName=News&VolID=336&VolumeName=No%202&VolumeStartDate=2/10/2012&EditionID=36&EditionName=Vol%2059&EditionStartDate=1/19/2012&ArticleID=3400
>
> i can only handle a dozen or so.  anyone running anything at scale?
>
> randy
>

https://www.torproject.org/

-DMM



From josmon at rigozsaurus.com  Sat Feb 18 21:22:55 2012
From: josmon at rigozsaurus.com (John Osmon)
Date: Sat, 18 Feb 2012 20:22:55 -0700
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3F5D51.7060202@studio442.com.au>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
Message-ID: <20120219032255.GA30213@jeeves.rigozsaurus.com>

On Sat, Feb 18, 2012 at 07:12:01PM +1100, Julien Goodwin wrote:
> The old colo at $JOB[-1] used to have an old Wyse 50 kicking around
> which I was happy enough to use (yes they can still be made to snarf
> credentials, but it's less likely) once or twice when I forgot my
> USB-Serial.

At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
trash bin and stuck it on a spare crash cart.

Then I fixed something while they were still looking for USB-Serial,
etc.

The smart one came over and learned how to set the serial port speed
from me...  I still talk to *him*.


From cmadams at hiwaay.net  Sat Feb 18 22:41:32 2012
From: cmadams at hiwaay.net (Chris Adams)
Date: Sat, 18 Feb 2012 22:41:32 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <20120219032255.GA30213@jeeves.rigozsaurus.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
Message-ID: <20120219044132.GA17040@hiwaay.net>

Once upon a time, John Osmon <josmon at rigozsaurus.com> said:
> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
> trash bin and stuck it on a spare crash cart.

We have a VT-510 in the data center and at least one VT-420 sitting in a
closet.  I have a VT-102 (well, a C.Itoh CIT-101 rebadged by Intergraph)
at home.

"Dumb" terminals are sometimes very smart.

-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.


From jeff-kell at utc.edu  Sat Feb 18 22:45:36 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sat, 18 Feb 2012 23:45:36 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <20120219044132.GA17040@hiwaay.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <20120219044132.GA17040@hiwaay.net>
Message-ID: <4F407E70.6080607@utc.edu>

On 2/18/2012 11:41 PM, Chris Adams wrote:
> "Dumb" terminals are sometimes very smart.

Well, yeah, unless you're ever in one of those spots where you need to
xmodem an IOS image...

(Makes you appreciate those newfangled ones that can mount USB drives ...)

Jeff


From sean at donelan.com  Sat Feb 18 23:35:27 2012
From: sean at donelan.com (Sean Donelan)
Date: Sun, 19 Feb 2012 00:35:27 -0500 (EST)
Subject: National Initiative for Cybersecurity Education (NICE)
In-Reply-To: <4F3FF418.2000009@paulgraydon.co.uk>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net>
 <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E9D42.3060708@paulgraydon.co.uk>
 <031901cceda4$081057d0$18310770$@chipps.com>
 <4F3F59A9.5060800@paulgraydon.co.uk>
 <79E53F63288F4F1BA39971DF40819B26@owner59e1f1502>
 <4F3FF418.2000009@paulgraydon.co.uk>
Message-ID: <alpine.GSO.2.00.1202182357370.26972@clifden.donelan.com>

On Sat, 18 Feb 2012, Paul Graydon wrote:
> Yes I'm serious, they were CCNP qualified, hired as a NOC engineer for an ISP 
> & Hosting company.  For the company the NOC team was the top tier of customer

The CCNP was a success from the point of view of the person.  It got the
person hired by an ISP & Hosting company to work in the top tier of 
customer support. Is it the fault of the CCNP that the hiring process at 
the ISP & Hosting company couldn't tell the difference?

If anyone has suggestions for improving the network and information 
security education in the US, please send your suggestions to the folks at 
the National Initiative for Cybersecurity Education (NICE).

  http://csrc.nist.gov/nice/

I've been trying to hire 5 federal civil servants (GS7 to GS13) to work on 
informations security architecture and program management at small and 
micro US government agencies.  Its amazing how hard it is to find people
that both understand the technology and can think beyond the manual.  I 
understand the attraction of using certificates as a screening mechanism 
by HR departments.  But that is why you have the job interview.

--
P.S. I have a functional APC Back-UPS XS1500 (4+ year old batteries) if
anyone in Northern Virginia wants to pick it up.  Otherwise I have to pay 
the battery recycling/disposal fee.


From morrowc.lists at gmail.com  Sat Feb 18 23:44:03 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sun, 19 Feb 2012 00:44:03 -0500
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <4F401C20.4010101@lugosys.com>
References: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
 <20120218163943.5cb5159a@milhouse> <4F401C20.4010101@lugosys.com>
Message-ID: <CAL9jLaZ06RLHfp=mqbbzcdXH=pQ5QDo+10EBjjxg8fUxUGJ_zQ@mail.gmail.com>

This sort of thing happens 'often' ('XXX is not available, wtf?')

should there be some set of troubleshooting steps followed, like a
list of thing you'd do in order to show you'd troubleshot the problem
and it wasn't "your problem"? Something along the lines of:

o whois output
o dig NS output
o dig +trace output
o 'downforeveryoneorjustme.com' says things are tango-uniform
o other...

reported such that others can either refute usefully or corroborate.

-chris

On Sat, Feb 18, 2012 at 4:46 PM, Israel G. Lugo <israel.lugo at lugosys.com> wrote:
> Likewise, working here.
>
> $ dig +trace www.facebook.com
>
> ; <<>> DiG 9.7.0-P1 <<>> +trace www.facebook.com
> ;; global options: +cmd
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?b.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?g.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?i.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?c.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?f.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?d.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?l.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?m.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?j.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?e.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?a.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?h.root-servers.net.
> . ? ? ? ? ? ? ? ? ? ? ? 240259 ?IN ? ? ?NS ? ? ?k.root-servers.net.
> ;; Received 272 bytes from 192.168.100.1#53(192.168.100.1) in 1 ms
>
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?a.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?b.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?c.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?d.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?e.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?f.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?g.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?h.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?i.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?j.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?k.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?l.gtld-servers.net.
> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?m.gtld-servers.net.
> ;; Received 494 bytes from 2001:7fd::1#53(k.root-servers.net) in 65 ms
>
> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns1.facebook.com.
> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns2.facebook.com.
> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns3.facebook.com.
> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns4.facebook.com.
> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns5.facebook.com.
> ;; Received 204 bytes from 192.48.79.30#53(j.gtld-servers.net) in 361 ms
>
> www.facebook.com. ? ? ? 86400 ? IN ? ? ?NS ? ? ?glb2.facebook.com.
> www.facebook.com. ? ? ? 86400 ? IN ? ? ?NS ? ? ?glb1.facebook.com.
> ;; Received 104 bytes from 66.220.145.65#53(ns5.facebook.com) in 206 ms
>
> www.facebook.com. ? ? ? 120 ? ? IN ? ? ?A ? ? ? 69.63.190.22
> ;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 146 ms
>
>
>
> On 02/18/2012 09:39 PM, John Peach wrote:
>> On Sat, 18 Feb 2012 13:32:42 -0800
>> Everett Batey <efbatey at gmail.com> wrote:
>>
>>> facebook.com DNS not found 20120218 2125 UTC
>>> Is there any outage information for DNS for ?facebook.com / www.facebook.com
>>> ??
>>> ? "Oops! Google Chrome could not find www.facebook.com"
>> Not here
>>
>> dig +trace www.facebook.com
>>
>> ; <<>> DiG 9.7.3 <<>> +trace www.facebook.com
>> ;; global options: +cmd
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?d.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?j.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?c.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?f.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?b.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?l.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?h.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?m.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?a.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?k.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?g.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?e.root-servers.net.
>> . ? ? ? ? ? ? ? ? ? ? ? 157853 ?IN ? ? ?NS ? ? ?i.root-servers.net.
>> ;; Received 228 bytes from 192.168.1.2#53(192.168.1.2) in 3 ms
>>
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?b.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?a.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?f.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?c.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?j.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?h.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?l.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?k.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?g.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?m.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?i.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?e.gtld-servers.net.
>> com. ? ? ? ? ? ? ? ? ? ?172800 ?IN ? ? ?NS ? ? ?d.gtld-servers.net.
>> ;; Received 494 bytes from 192.5.5.241#53(f.root-servers.net) in 99 ms
>>
>> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns1.facebook.com.
>> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns2.facebook.com.
>> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns3.facebook.com.
>> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns4.facebook.com.
>> facebook.com. ? ? ? ? ? 172800 ?IN ? ? ?NS ? ? ?ns5.facebook.com.
>> ;; Received 204 bytes from 192.33.14.30#53(b.gtld-servers.net) in 208 ms
>>
>> www.facebook.com. ? ? ? 86400 ? IN ? ? ?NS ? ? ?glb1.facebook.com.
>> www.facebook.com. ? ? ? 86400 ? IN ? ? ?NS ? ? ?glb2.facebook.com.
>> ;; Received 104 bytes from 66.220.151.20#53(ns3.facebook.com) in 91 ms
>>
>> www.facebook.com. ? ? ? 120 ? ? IN ? ? ?A ? ? ? 69.171.234.96
>> ;; Received 50 bytes from 69.171.255.10#53(glb2.facebook.com) in 20 ms
>>
>>
>>>
>>> On Fri, Feb 17, 2012 at 11:26 PM, <nanog-request at nanog.org> wrote:
>>>
>>>> Send NANOG mailing list submissions to
>>>> ? ? ? ?nanog at nanog.org
>>>>
>>>>
>>
>


From joe at nethead.com  Sun Feb 19 00:29:46 2012
From: joe at nethead.com (Joe Hamelin)
Date: Sat, 18 Feb 2012 22:29:46 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F407E70.6080607@utc.edu>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <20120219044132.GA17040@hiwaay.net> <4F407E70.6080607@utc.edu>
Message-ID: <CAO0-hXafjXhzOPv5nwYmQEA2ABNHmG4fJ3PmeMsnr0pzAc+cdg@mail.gmail.com>

Just give me a gumball machine with RJ45 ends and a crimper on a chain.

I'll find some wire that can be shorter.

--
Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474

From ken.gilmour at gmail.com  Sun Feb 19 04:59:37 2012
From: ken.gilmour at gmail.com (Ken Gilmour)
Date: Sun, 19 Feb 2012 11:59:37 +0100
Subject: DNS Attacks
In-Reply-To: <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
Message-ID: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>

On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com> wrote:
>
> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
> query -- returns the address of a dedicated machine on your network set up
> especially for this purpose.

What happens when the client sends a POST from a cached page on the end
user's machine? E.g. if they post login credentials. Of course, they'll get
the error page, but then you have confidential data in your logs and now
you have to protect highly confidential info, at least if you're in europe.

From patrick at ianai.net  Sun Feb 19 05:59:22 2012
From: patrick at ianai.net (Patrick W. Gilmore)
Date: Sun, 19 Feb 2012 11:59:22 +0000
Subject: DNS Attacks
In-Reply-To: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
Message-ID: <A4689BB2-7625-4967-B826-4B5110A5FD3B@ianai.net>

On Feb 19, 2012, at 10:59, Ken Gilmour <ken.gilmour at gmail.com> wrote:
> On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com> wrote:
>> 
>> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
>> query -- returns the address of a dedicated machine on your network set up
>> especially for this purpose.
> 
> What happens when the client sends a POST from a cached page on the end
> user's machine? E.g. if they post login credentials. Of course, they'll get
> the error page, but then you have confidential data in your logs and now
> you have to protect highly confidential info, at least if you're in europe.

It is possible to configure the web server not to log POSTed info.

-- 
TTFN,
patrick



From jeroen at unfix.org  Sun Feb 19 06:02:01 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Sun, 19 Feb 2012 13:02:01 +0100
Subject: DNS Attacks
In-Reply-To: <A4689BB2-7625-4967-B826-4B5110A5FD3B@ianai.net>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <A4689BB2-7625-4967-B826-4B5110A5FD3B@ianai.net>
Message-ID: <4F40E4B9.8080504@unfix.org>

On 2012-02-19 12:59 , Patrick W. Gilmore wrote:
> On Feb 19, 2012, at 10:59, Ken Gilmour <ken.gilmour at gmail.com> wrote:
>> On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com> wrote:
>>>
>>> Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
>>> query -- returns the address of a dedicated machine on your network set up
>>> especially for this purpose.
>>
>> What happens when the client sends a POST from a cached page on the end
>> user's machine? E.g. if they post login credentials. Of course, they'll get
>> the error page, but then you have confidential data in your logs and now
>> you have to protect highly confidential info, at least if you're in europe.
> 
> It is possible to configure the web server not to log POSTed info.

Per default most webservers (Apache, nginx, etc) won't log POST
variables, GET variables will be logged (as they are part of the query)
but those should not contain any PII.

Greets,
 Jeroen




From Valdis.Kletnieks at vt.edu  Sun Feb 19 08:23:40 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sun, 19 Feb 2012 09:23:40 -0500
Subject: DNS Attacks
In-Reply-To: Your message of "Sun, 19 Feb 2012 13:02:01 +0100."
 <4F40E4B9.8080504@unfix.org>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <A4689BB2-7625-4967-B826-4B5110A5FD3B@ianai.net>
 <4F40E4B9.8080504@unfix.org>
Message-ID: <77222.1329661420@turing-police.cc.vt.edu>

On Sun, 19 Feb 2012 13:02:01 +0100, Jeroen Massar said:

> Per default most webservers (Apache, nginx, etc) won't log POST
> variables, GET variables will be logged (as they are part of the query)
> but those should not contain any PII.

Right. They shouldn't.  But the security mailing lists have lots of
counter-examples from clue-challenged web developers.. Plan your logging
strategy accordingly (is there any safe answer here other than "disable
logging" or "log only timestamp and source IP"?)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120219/5a686cab/attachment.bin>

From tknchris at gmail.com  Sun Feb 19 08:38:33 2012
From: tknchris at gmail.com (chris)
Date: Sun, 19 Feb 2012 09:38:33 -0500
Subject: CLEC in NJ for Sprint/Centurytel
Message-ID: <CAKnNFz-EJQBByhs_n7ExVT3qojK4Kb3VwUR4ZwWEfswYtrh4ZA@mail.gmail.com>

Hello,

We use DSL as a backup for some of our client sites where there is no
better alternative. I am looking for a preferably facilities based CLEC in
NJ who can provide us with DSL in sprint/centurytel territories. If anyone
has any recommendations for companies which can do this, experiences, etc
it would be great.

Thanks,
chris

From bonomi at mail.r-bonomi.com  Sun Feb 19 10:14:45 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 19 Feb 2012 10:14:45 -0600 (CST)
Subject: DNS Attacks
In-Reply-To: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
Message-ID: <201202191614.q1JGEjsE088170@mail.r-bonomi.com>

> From ken.gilmour at gmail.com  Sun Feb 19 05:04:39 2012
> Date: Sun, 19 Feb 2012 11:59:37 +0100
> Subject: Re: DNS Attacks
> From: Ken Gilmour <ken.gilmour at gmail.com>
> To: Robert Bonomi <bonomi at mail.r-bonomi.com>
> Cc: nanog at nanog.org
>
> On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com> wrote:
> >
> > Even better, nat to a 'bogon' DNS server -- one that -- regardless of the
> > query -- returns the address of a dedicated machine on your network set up
> > especially for this purpose.
>
> What happens when the client sends a POST from a cached page on the end
> user's machine? E.g. if they post login credentials. Of course, they'll get
> the error page, but then you have confidential data in your logs and now
> you have to protect highly confidential info, at least if you're in europe.
>

*WHAT* 'confidential data' in which logs?   <grin>

The aforementioned dedicated machine isn't a real web-server, or a real
'any other' server -- it is solely a special-purpose application machine,
When you connect to it on say, port 80, it doesn't log anything from the 
port -- it just logs (1) the timestamp, and (2) the connecting IP address 
(and _nothing_ else); then it copies out a previously prepared static file,
and disconnects.

You build a separae app that reads that logfile, matches IP ddress/timestamp
to a customer account, and feeds a message into the 'customer records' system
that this customer -has- been notified of this problem, and when, in case 
they call for support.

If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe'
between the processes, so that the data never hits disk in the first place. ;)

I've got proof-of-concept code for a single program that handles HTTP (port
80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143), IMAP3
(port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far.   
I'm planing to add IRC, and various SSL-based protocols as well.




From smb at cs.columbia.edu  Sun Feb 19 10:47:29 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Sun, 19 Feb 2012 11:47:29 -0500
Subject: public scalable vpn?
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD4316@RWC-MBX1.corp.seven.com>
References: <m2sji73eoz.wl%randy@psg.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD4316@RWC-MBX1.corp.seven.com>
Message-ID: <C30791CE-CD66-4EF2-8208-FACC258192B6@cs.columbia.edu>


On Feb 18, 2012, at 6:51 PM, George Bonser wrote:

>> academics in ontario are gonna need a scalable vpn service until they
>> find jobs elsewhere.
>> 
>> http://www.cautbulletin.ca/en_article.asp?SectionID=1386&SectionName=Ne
>> ws&VolID=336&VolumeName=No%202&VolumeStartDate=2/10/2012&EditionID=36&E
>> ditionName=Vol%2059&EditionStartDate=1/19/2012&ArticleID=3400
>> 
>> i can only handle a dozen or so.  anyone running anything at scale?
>> 
>> randy
> 
> "The agreement reached last month with the licensing agency includes provisions defining e-mailing hyperlinks as equivalent to photocopying a document"
> 
> I certainly hope that is some politicized hype printed in that article and not real.  That is absolutely idiotic on the face of it.  When I have seen stuff like this printed in the past it has generally been over the top catastrophizing of an issue in order to inflame emotions.  I sure hope that's the case here.  Otherwise my impression of Canadians has sunk to a new low.  Why would it be in anyone's interest to sign such an agreement?

It seems to be real -- see http://communications.uwo.ca/western_news/stories/2012/February/copyright_deal_struck.html

I asked a Canadian friend of mine (who has serious privacy and security expertise) about it.  She said "Yes - we were discussing this vile decision in my Technopolicy law class...  I have no idea what they were thinking! Idiots."

		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From jcurran at istaff.org  Sun Feb 19 11:21:02 2012
From: jcurran at istaff.org (John Curran)
Date: Sun, 19 Feb 2012 12:21:02 -0500
Subject: Colo Vending Machine
In-Reply-To: <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
 <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
Message-ID: <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>

On Feb 18, 2012, at 1:55 PM, Astrodog wrote:
> On Fri, Feb 17, 2012 at 7:13 PM, Gary Buhrmaster
> <gary.buhrmaster at gmail.com> wrote:
>> On Sat, Feb 18, 2012 at 01:02, George Herbert <george.herbert at gmail.com> wrote:
>> ....
>>>> Will IANA accept netblock transfers as an exchange medium for
>>>> datacenter goodies vending machine payments? ...  ;-)
>>> 
>>> Joking while busy discouraged.  s/IANA/ARIN/d'oh
>> 
>> I suspect ARIN would follow its policy to recognize
>> any transfer and update its records as long as the
>> needs assessment was successfully completed,
>> but any compensation between the seller and
>> buyer of the resource is not part of the ARIN process.
>> 
>> (This is a (bad?) joke reference to a currently
>> ongoing discussion on the ARIN PPML list).
> 
> Hah. So, this should work, provided both entities are on the STSL then.

"Sure..."  ;-)

That means you'd want about $2K worth of gear because of the existing /24 
minimum, in addition to vending machine able to explain why it needs the 
address space.   

Have fun,
/John

p.s. A /16 might be about right for a pack of 100G SMF CFP modules...



From caldcv at gmail.com  Sun Feb 19 12:53:50 2012
From: caldcv at gmail.com (Chris)
Date: Sun, 19 Feb 2012 13:53:50 -0500
Subject: Dynadot DNS acting up?
Message-ID: <CAPF5agcjDxbYVkTa7j5aQZu_ML6e5cSW9FxqyJf14NWf+UWe8A@mail.gmail.com>

Anyone noticing issues with Dynadot (site is down) and Dynadot related
domain names where you are using their DNS servers?

-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton


From astrodog at gmail.com  Sun Feb 19 15:05:20 2012
From: astrodog at gmail.com (Astrodog)
Date: Sun, 19 Feb 2012 15:05:20 -0600
Subject: Colo Vending Machine
In-Reply-To: <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
 <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
 <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>
Message-ID: <CACxBGJNzOUMVoXUowUJFPoy2GKSK0yus9CFUpy8km8DZQgw5MA@mail.gmail.com>

On Sun, Feb 19, 2012 at 11:21 AM, John Curran <jcurran at istaff.org> wrote:
> On Feb 18, 2012, at 1:55 PM, Astrodog wrote:
>> On Fri, Feb 17, 2012 at 7:13 PM, Gary Buhrmaster
>> <gary.buhrmaster at gmail.com> wrote:
>>> On Sat, Feb 18, 2012 at 01:02, George Herbert <george.herbert at gmail.com> wrote:
>>> ....
>>>>> Will IANA accept netblock transfers as an exchange medium for
>>>>> datacenter goodies vending machine payments? ... ?;-)
>>>>
>>>> Joking while busy discouraged. ?s/IANA/ARIN/d'oh
>>>
>>> I suspect ARIN would follow its policy to recognize
>>> any transfer and update its records as long as the
>>> needs assessment was successfully completed,
>>> but any compensation between the seller and
>>> buyer of the resource is not part of the ARIN process.
>>>
>>> (This is a (bad?) joke reference to a currently
>>> ongoing discussion on the ARIN PPML list).
>>
>> Hah. So, this should work, provided both entities are on the STSL then.
>
> "Sure..." ?;-)
>
> That means you'd want about $2K worth of gear because of the existing /24
> minimum, in addition to vending machine able to explain why it needs the
> address space.
>
> Have fun,
> /John
>
> p.s. A /16 might be about right for a pack of 100G SMF CFP modules...
>

This gives me an idea. The vending machine could also sell hosting.
Sometimes, the box just won't come back to life and you need somewhere
to stuff the data. *grin*

(Actually, based on a few of my DC visits, there are times where I'd
have gladly shelled out $2k for a small baggie of screws.)

--- Harrison


From owen at delong.com  Sun Feb 19 18:24:49 2012
From: owen at delong.com (Owen DeLong)
Date: Sun, 19 Feb 2012 16:24:49 -0800
Subject: Common operational misconceptions
In-Reply-To: <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
Message-ID: <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>


On Feb 18, 2012, at 3:31 AM, Masataka Ohta wrote:

> David Barak wrote:
> 
>>> From: Owen DeLong owen at delong.com
>> 
>>> Sigh... NAT is a horrible hack that served us all too well in
> >> address conservation. Beyond that, it is merely a source of pain.
>> 
>> I understand why you say that - NAT did yeoman's work in address
> > conservation. However, it also enabled (yes, really) lots of
> > topologies and approaches which are *not* designed upon the
> > end-to-end model. Some of these approaches have found their way
> > into business proceses.
> 
> I'm afraid both of you don't try to understand why NAT was
> harmful to destroy the end to end transparency nor the end
> to end argument presented in the original paper by Saltezer
> et. al:
> 
>      The function in question can completely and correctly be
>      implemented only with the knowledge and help of the application
>      standing at the end points of the communication system. Therefore,
>      providing that questioned function as a feature of the
>      communication system itself is not possible.
> 
> While plain NAT, which actively hide itself from end systems,
> which means there can be no "knowledge and help of the
> application" expected, is very harmful to the end to end
> transparency, it is possible to entirely neutralize the
> harmful effects, by let NAT boxes ask help end systems.
> 
>> An argument you and others have made many times boils down
> > to "but if we never had NAT, think how much better it
> > would be!"
> 
> The reality is much better that NAT is not so harmful if NAT
> clients and gateways are designed properly to be able to
> reverse the harmful translations by NAT gateways.
> 
> I have running code to make the reverse translations, with
> which protocols such as ftp with PORT commands are working.
> 
> 					Masataka Ohta


No, I think you do not understand...

I have a NAT gateway with a single public address.

I have 15 FTP servers and 22 web servers behind it.

I want people to be able to go to ftp://<hostname> and/or http://<hostname> for each of them.

Please explain to me how your code solves this problem?

Yeah, thought so.

Owen



From jeff-kell at utc.edu  Sun Feb 19 19:01:49 2012
From: jeff-kell at utc.edu (Jeff Kell)
Date: Sun, 19 Feb 2012 20:01:49 -0500
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
References: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
Message-ID: <4F419B7D.5040004@utc.edu>

On 2/18/2012 4:32 PM, Everett Batey wrote:
> facebook.com DNS not found 20120218 2125 UTC
> Is there any outage information for DNS for  facebook.com / www.facebook.com
>  ?
>   "Oops! Google Chrome could not find www.facebook.com"

I have had two reports of "can't get to facebook" from campus today, not
exactly from 3rd-tier helpdesk techs mind you, but a reasonably
reputable source.  "Traceroute stops at 127.0.0.1" (yeah, I know).

Works fine from campus for me, and they say the machine does "nslookup"
a Facebook CDN provider IP (69.171.234.96).  They can go anywhere else,
no problem.  Verified they have our DHCP server and internal recursive
DNS servers so it's not an issue at that level.

I'm "ONLY" bringing this up as my spidey-sense is wondering if there is
some facebook-captive malware or browser plugin floating about? 

Ring any bells?

If nothing else comes in I'm going to write it off as a Sunday evening
hallucination and check it again tomorrow :)

Jeff


From jgreco at ns.sol.net  Sun Feb 19 19:07:32 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Sun, 19 Feb 2012 19:07:32 -0600 (CST)
Subject: Common operational misconceptions
In-Reply-To: <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
Message-ID: <201202200107.q1K17W5l000294@aurora.sol.net>

> > I have running code to make the reverse translations, with
> > which protocols such as ftp with PORT commands are working.
> 
> No, I think you do not understand...
> 
> I have a NAT gateway with a single public address.
> 
> I have 15 FTP servers and 22 web servers behind it.
> 
> I want people to be able to go to ftp://<hostname> and/or =
> http://<hostname> for each of them.

Owen,

Your suggestion here would set many "security experts" heads on fire.

Whatever will they do when NAT doesn't make such things virtually
impossible?

:-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From mysidia at gmail.com  Sun Feb 19 19:09:49 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 19 Feb 2012 19:09:49 -0600
Subject: Common operational misconceptions
In-Reply-To: <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
Message-ID: <CAAAwwbUnK20ETo90K4=W_LBVuheF5fJmSoqnFhsNs7PGpmpVPQ@mail.gmail.com>

On Sun, Feb 19, 2012 at 6:24 PM, Owen DeLong <owen at delong.com> wrote:
> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp://<hostname> and/or http://<hostname> for each of them.

For HTTP;  You put a device on that one IP that will accept each TCP
connection,  await the SNI or Host  header from the client,   and then
make/forward  the connection to a proper server for that hostname.
The public IP address belongs to the FTP/HTTP  "service"  instead of
belonging to a server.


For FTP,  send to a desired FTP server based on the login username or
otherwise make a SRV record for the  _ftp  service for each hostname,
 and   set aside a TCP port for each FTP service's control connection.

The   ftp://user@<hostname>   approach  or the
ftp://user@<basehostname>/<hostname>/  is  probably more convenient
than ftp://<hostname>:<1234>, since many clients do not support SRV
records.

The problem is with the FTP protocol not supporting virtual hosting,
though;  this missing FTP feature is not a NAT problem per se.

The VHOST problem was solved with HTTP a long time ago.
It's just that FTP is a lot less popular / fell into some disuse,  so
the deficiency  (lack of virtual hosting support)   was  never
corrected -- and the protocol hasn't had a single update in a long
time.

So you'll have to have a workaround to do 15 FTP servers with one
global IP,  because your circumstance is so unusual,  that's just
life.

--
-JH


From callahanwarlick at gmail.com  Sun Feb 19 19:20:05 2012
From: callahanwarlick at gmail.com (Callahan Warlick)
Date: Sun, 19 Feb 2012 17:20:05 -0800
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <4F419B7D.5040004@utc.edu>
References: <CAFBwhDYnu2+Mj1AKHBFV7U7MY-ox6FA9n45iO_xGAY-wr_UDGA@mail.gmail.com>
 <4F419B7D.5040004@utc.edu>
Message-ID: <CA+6MkbO5XeJ=EnQHDpowa3ifgZ+3e9noLA6cGtVssQZqLf-SaQ@mail.gmail.com>

Please feel free to unicast me if you ever see any reproducible issues.

-Callahan

On Sun, Feb 19, 2012 at 5:01 PM, Jeff Kell <jeff-kell at utc.edu> wrote:
> On 2/18/2012 4:32 PM, Everett Batey wrote:
>> facebook.com DNS not found 20120218 2125 UTC
>> Is there any outage information for DNS for ?facebook.com / www.facebook.com
>> ??
>> ? "Oops! Google Chrome could not find www.facebook.com"
>
> I have had two reports of "can't get to facebook" from campus today, not
> exactly from 3rd-tier helpdesk techs mind you, but a reasonably
> reputable source. ?"Traceroute stops at 127.0.0.1" (yeah, I know).
>
> Works fine from campus for me, and they say the machine does "nslookup"
> a Facebook CDN provider IP (69.171.234.96). ?They can go anywhere else,
> no problem. ?Verified they have our DHCP server and internal recursive
> DNS servers so it's not an issue at that level.
>
> I'm "ONLY" bringing this up as my spidey-sense is wondering if there is
> some facebook-captive malware or browser plugin floating about?
>
> Ring any bells?
>
> If nothing else comes in I'm going to write it off as a Sunday evening
> hallucination and check it again tomorrow :)
>
> Jeff
>


From marka at isc.org  Sun Feb 19 19:21:44 2012
From: marka at isc.org (Mark Andrews)
Date: Mon, 20 Feb 2012 12:21:44 +1100
Subject: Common operational misconceptions
In-Reply-To: Your message of "Sun, 19 Feb 2012 19:07:32 MDT."
 <201202200107.q1K17W5l000294@aurora.sol.net>
References: <201202200107.q1K17W5l000294@aurora.sol.net>
Message-ID: <20120220012144.D239C1D9D0AE@drugs.dv.isc.org>


In message <201202200107.q1K17W5l000294 at aurora.sol.net>, Joe Greco writes:
> > > I have running code to make the reverse translations, with
> > > which protocols such as ftp with PORT commands are working.
> > 
> > No, I think you do not understand...
> > 
> > I have a NAT gateway with a single public address.
> > 
> > I have 15 FTP servers and 22 web servers behind it.
> > 
> > I want people to be able to go to ftp://<hostname> and/or =
> > http://<hostname> for each of them.
> 
> Owen,
> 
> Your suggestion here would set many "security experts" heads on fire.
> 
> Whatever will they do when NAT doesn't make such things virtually
> impossible?
> 
> :-)

Time to write "How to use SRV with FTP".  CGN is going to push
the extension of a whole lot of protocols.

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


From alvarezp at alvarezp.ods.org  Sun Feb 19 19:33:54 2012
From: alvarezp at alvarezp.ods.org (Octavio Alvarez)
Date: Sun, 19 Feb 2012 17:33:54 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <op.v9yemqf34oyyg1@localhost.localdomain>

On Wed, 15 Feb 2012 12:47:15 -0800, John Kristoff <jtk at cymru.com> 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.

The idea that "the more access-points, the better our WiFi".

Oh, and the use of RJ45 for the unconfigured 8P8C, but this is not that
annoying.

Cheers.


From kauer at biplane.com.au  Sun Feb 19 20:06:40 2012
From: kauer at biplane.com.au (Karl Auer)
Date: Mon, 20 Feb 2012 13:06:40 +1100
Subject: Common operational misconceptions
In-Reply-To: <CAAAwwbUnK20ETo90K4=W_LBVuheF5fJmSoqnFhsNs7PGpmpVPQ@mail.gmail.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
 <CAAAwwbUnK20ETo90K4=W_LBVuheF5fJmSoqnFhsNs7PGpmpVPQ@mail.gmail.com>
Message-ID: <1329703600.4021.44.camel@karl>

On Sun, 2012-02-19 at 19:09 -0600, Jimmy Hess wrote:
> For HTTP;  You put a device on that one IP that will accept each TCP
> connection,  await the SNI or Host  header from the client,   and then
> make/forward  the connection to a proper server for that hostname.

So you need an extra device to work around NAT. Or you have to build
extra smarts into existing devices to work around NAT. There is a
pattern here...
 
> For FTP,  send to a desired FTP server based on the login username or
> otherwise make a SRV record for the  _ftp  service for each hostname,
>  and   set aside a TCP port for each FTP service's control connection.

So NAT does indeed prevent the scenario Owen outlined.

It does not make sense to make that the application's fault. If you have
to build NAT-awareness (even indirectly, as in SRV-awareness) into every
application, then you've lost the game and it might be time to realise
that NAT is the problem, not all the applications.

> The problem is with the FTP protocol not supporting virtual hosting,
> though;  this missing FTP feature is not a NAT problem per se.

I'm not sure I agree with that, see above. And while virtual hosting may
be a Good Thing for various other reasons, it seems to me that if it is
required with NAT and is not required without NAT, then it is most
certainly "the fault of NAT" that it is required.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)
http://www.biplane.com.au/kauer

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/c477b67d/attachment-0001.bin>

From mohta at necom830.hpcl.titech.ac.jp  Sun Feb 19 20:17:32 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 20 Feb 2012 11:17:32 +0900
Subject: Common operational misconceptions
In-Reply-To: <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
Message-ID: <4F41AD3C.9070302@necom830.hpcl.titech.ac.jp>

Owen DeLong wrote:

>> I have running code to make the reverse translations, with
>> which protocols such as ftp with PORT commands are working.

> No, I think you do not understand...

How can't I understand several minor issues with the running code.

> I have 15 FTP servers and 22 web servers behind it.
> I want people to be able to go to ftp://<hostname>  and/or http://<hostname>  for each of them.
> Please explain to me how your code solves this problem?

See

   draft-ohta-urlsrv-00.txt

   DNS SRV RRs of a domain implicitly specify servers and port numbers
   corresponding to the domain.

   By combining URLs and SRV RRs, no port numbers have to be specified
   explicitly in URLs, even if non-default port numbers are used, which
   makes URLs more concise for port based virtual and real hosting,
   where port based real hosting means that multiple servers sharing an
   IP address are distinguished by port numbers to give service for
   different URLs, which is the case for port forwarded servers behind
   NAT and servers with realm specific IP.

> Yeah, thought so.

The draft has been available since September 29, 2011.

					Masataka Ohta


From aj at jonesy.com.au  Sun Feb 19 22:09:34 2012
From: aj at jonesy.com.au (Andrew Jones)
Date: Mon, 20 Feb 2012 15:09:34 +1100
Subject: Common operational misconceptions
In-Reply-To: <4F41AD3C.9070302@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
 <4F41AD3C.9070302@necom830.hpcl.titech.ac.jp>
Message-ID: <9720a2f39b708b8ca9bd979fe918c6f8@localhost>

On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
<mohta at necom830.hpcl.titech.ac.jp> wrote:
>    draft-ohta-urlsrv-00.txt
> 
>    DNS SRV RRs of a domain implicitly specify servers and port numbers
>    corresponding to the domain.
> 
>    By combining URLs and SRV RRs, no port numbers have to be specified
>    explicitly in URLs, even if non-default port numbers are used, which
>    makes URLs more concise for port based virtual and real hosting,
>    where port based real hosting means that multiple servers sharing an
>    IP address are distinguished by port numbers to give service for
>    different URLs, which is the case for port forwarded servers behind
>    NAT and servers with realm specific IP.
> 

It seems to me that this will create all sorts of headaches for firewall
ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
example, the devices would need to inspect traffic on all ports and perform
DPI. This is not as much of a problem on the firewall protecting the
servers (you know what ports to inspect), but will require a lot more
processing power on the client-side NAT firewall.

Jonesy


From mysidia at gmail.com  Sun Feb 19 22:40:57 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 19 Feb 2012 22:40:57 -0600
Subject: Common operational misconceptions
In-Reply-To: <9720a2f39b708b8ca9bd979fe918c6f8@localhost>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
 <4F41AD3C.9070302@necom830.hpcl.titech.ac.jp>
 <9720a2f39b708b8ca9bd979fe918c6f8@localhost>
Message-ID: <CAAAwwbWipsNPNiikqwAXYyOqLdy=HuOR137rVy+oeb6TZ9iUyA@mail.gmail.com>

On Sun, Feb 19, 2012 at 10:09 PM, Andrew Jones <aj at jonesy.com.au> wrote:
> On Mon, 20 Feb 2012 11:17:32 +0900, Masataka Ohta
> It seems to me that this will create all sorts of headaches for firewall
> ALGs. Rather than just passing port 21/tcp traffic to the FTP ALG for
> example, the devices would need to inspect traffic on all ports and perform
[snip]

That doesn't work when the FTP control connection is encrypted using SSL.
Layer 4  Firewall devices should not be expecting to intercept FTP
traffic and make decisions based on the application layer contents of
the traffic.

I would suggest a requirement that FTP clients utilizing SRV records
to access FTP on an alternate port MUST utilize Firewall-Friendly FTP
as described by RFC1579.

Each FTP server can then be assigned its own port range, or the FTP
server can be configured to notify the Firewall device which ports to
forward using UpNP or a NAT traversal protocol such as STUN, and the
Firewall device can be configured  to forward the appropriate range of
ports  to the correct server.

--
-JH


From mysidia at gmail.com  Sun Feb 19 23:38:26 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Sun, 19 Feb 2012 23:38:26 -0600
Subject: Colo Vending Machine
In-Reply-To: <CACxBGJNzOUMVoXUowUJFPoy2GKSK0yus9CFUpy8km8DZQgw5MA@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
 <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
 <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>
 <CACxBGJNzOUMVoXUowUJFPoy2GKSK0yus9CFUpy8km8DZQgw5MA@mail.gmail.com>
Message-ID: <CAAAwwbVF+6Nbx4jKSe5yB8FuF+-9FmfDu8h265h+Qba91+9bUg@mail.gmail.com>

On Sun, Feb 19, 2012 at 3:05 PM, Astrodog <astrodog at gmail.com> wrote:
> This gives me an idea. The vending machine could also sell hosting.
> Sometimes, the box just won't come back to life and you need somewhere
> to stuff the data. *grin*

How about a vending machine, where you insert a hard drive, swipe your card,
and it either gets vaulted to S3 or an EC2 intance is spawned on the
cloud, and the data on the drive becomes the instance's boot media and
gets streamed to the instance storage over a 10-gigabit connection
from the vending machine,  until all the data's uploaded.

That solves the problem of end users getting their data to the hosting
provider quickly, with no need to stress out their low-speed WAN.

--
-JH


From me at anuragbhatia.com  Sun Feb 19 23:41:12 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Mon, 20 Feb 2012 11:11:12 +0530
Subject: Colo Vending Machine
In-Reply-To: <CAAAwwbVF+6Nbx4jKSe5yB8FuF+-9FmfDu8h265h+Qba91+9bUg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
 <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
 <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>
 <CACxBGJNzOUMVoXUowUJFPoy2GKSK0yus9CFUpy8km8DZQgw5MA@mail.gmail.com>
 <CAAAwwbVF+6Nbx4jKSe5yB8FuF+-9FmfDu8h265h+Qba91+9bUg@mail.gmail.com>
Message-ID: <CAJ0+aXY7Fh3ng36=UG2crSwmO9U7Uxp9pcpMs7zP_d1QdHXCNw@mail.gmail.com>

Nice idea of future! :)


Btw as side question - I heard transfer rates from S3 are capped badly.
Something like 5-10Mbps. Is that true? Anyone of you ever came across such
cap?

On Mon, Feb 20, 2012 at 11:08 AM, Jimmy Hess <mysidia at gmail.com> wrote:

> On Sun, Feb 19, 2012 at 3:05 PM, Astrodog <astrodog at gmail.com> wrote:
> > This gives me an idea. The vending machine could also sell hosting.
> > Sometimes, the box just won't come back to life and you need somewhere
> > to stuff the data. *grin*
>
> How about a vending machine, where you insert a hard drive, swipe your
> card,
> and it either gets vaulted to S3 or an EC2 intance is spawned on the
> cloud, and the data on the drive becomes the instance's boot media and
> gets streamed to the instance storage over a 10-gigabit connection
> from the vending machine,  until all the data's uploaded.
>
> That solves the problem of end users getting their data to the hosting
> provider quickly, with no need to stress out their low-speed WAN.
>
> --
> -JH
>
>


-- 

Anurag Bhatia
anuragbhatia.com
or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
network!

Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
Linkedin: http://linkedin.anuragbhatia.com

From mike.lyon at gmail.com  Sun Feb 19 23:48:35 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 19 Feb 2012 21:48:35 -0800
Subject: Colo Vending Machine
In-Reply-To: <CAJ0+aXY7Fh3ng36=UG2crSwmO9U7Uxp9pcpMs7zP_d1QdHXCNw@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0995@RWC-MBX1.corp.seven.com>
 <EC276B04-1CBB-4B46-8611-B60145F69C8D@montco.net>
 <CAK__Kzst2u3RPHTteDmAPseNNFi7-FyWYXoGR477a5zfCKUVuQ@mail.gmail.com>
 <CAK__KzsHZ_OLj=9ZC7nYJAyDNmf6ApMR3tJGdtHgEZBsYn-cAw@mail.gmail.com>
 <CAMfXtQzA4+CMisjvV3rdGmYvyOBbxU=9n-pdCB0L_pxri2GXPA@mail.gmail.com>
 <CACxBGJM0iuG7yQRUDUknqoBJw4E1e5wfEeSwP8cxP2Gb559-Aw@mail.gmail.com>
 <AA31A898-014D-4C0A-9A70-DFC97F167474@istaff.org>
 <CACxBGJNzOUMVoXUowUJFPoy2GKSK0yus9CFUpy8km8DZQgw5MA@mail.gmail.com>
 <CAAAwwbVF+6Nbx4jKSe5yB8FuF+-9FmfDu8h265h+Qba91+9bUg@mail.gmail.com>
 <CAJ0+aXY7Fh3ng36=UG2crSwmO9U7Uxp9pcpMs7zP_d1QdHXCNw@mail.gmail.com>
Message-ID: <-6500775018775654516@unknownmsgid>

My rsync appeared to be running at 20+ Mbps to S3 last night...

Sent from my iPhone

On Feb 19, 2012, at 21:41, Anurag Bhatia <me at anuragbhatia.com> wrote:

> Nice idea of future! :)
>
>
> Btw as side question - I heard transfer rates from S3 are capped badly.
> Something like 5-10Mbps. Is that true? Anyone of you ever came across such
> cap?
>
> On Mon, Feb 20, 2012 at 11:08 AM, Jimmy Hess <mysidia at gmail.com> wrote:
>
>> On Sun, Feb 19, 2012 at 3:05 PM, Astrodog <astrodog at gmail.com> wrote:
>>> This gives me an idea. The vending machine could also sell hosting.
>>> Sometimes, the box just won't come back to life and you need somewhere
>>> to stuff the data. *grin*
>>
>> How about a vending machine, where you insert a hard drive, swipe your
>> card,
>> and it either gets vaulted to S3 or an EC2 intance is spawned on the
>> cloud, and the data on the drive becomes the instance's boot media and
>> gets streamed to the instance storage over a 10-gigabit connection
>> from the vending machine,  until all the data's uploaded.
>>
>> That solves the problem of end users getting their data to the hosting
>> provider quickly, with no need to stress out their low-speed WAN.
>>
>> --
>> -JH
>>
>>
>
>
> --
>
> Anurag Bhatia
> anuragbhatia.com
> or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected
> network!
>
> Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia>
> Linkedin: http://linkedin.anuragbhatia.com


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 00:42:56 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Mon, 20 Feb 2012 15:42:56 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
Message-ID: <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

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

> It depends on the OS and the method being used.  If you set the
> option to "2" on Linux, it will do MTU probing constantly and
> react to MTU changes.

It actually does nothing.

Given the following statements in the RFC:

   An initial eff_pmtu of 1400 bytes might
   be a good compromise because it would be safe for nearly all tunnels
   over all common networking gear, and yet close to the optimal MTU for
   the majority of paths in the Internet today.

and

   Each Packetization Layer MUST determine when probing has converged,
   that is, when the probe size range is small enough that further
   probing is no longer worth its cost.  When probing has converged, a

the hosts are keep assuming PMTU of 1400B and if local MTU
is 1500B or less, no discovery is performed because "the
probe size range is small enough".

> Also, the MTU for a given path only "lives" for 5 minutes anyway
> (by default) and is "rediscovered" with Linux.   (value in
> /proc/sys/net/ipv4/route/mtu_expires) but other operating
>  systems may behave in other ways.

See above. Rediscovery with initial eff_pmtu of 1400B and
search_high of 1500B immediately terminates without any
probe packets sent.

					Masataka Ohta


From ken.gilmour at gmail.com  Mon Feb 20 01:45:42 2012
From: ken.gilmour at gmail.com (Ken Gilmour)
Date: Mon, 20 Feb 2012 08:45:42 +0100
Subject: DNS Attacks
In-Reply-To: <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
Message-ID: <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>

--
Sent from my smart phone. Please excuse my brevity
On Feb 19, 2012 4:10 p.m., "Robert Bonomi" <bonomi at mail.r-bonomi.com> wrote:
>
> > From ken.gilmour at gmail.com  Sun Feb 19 05:04:39 2012
> > Date: Sun, 19 Feb 2012 11:59:37 +0100
> > Subject: Re: DNS Attacks
> > From: Ken Gilmour <ken.gilmour at gmail.com>
> > To: Robert Bonomi <bonomi at mail.r-bonomi.com>
> > Cc: nanog at nanog.org
> >
> > On Feb 18, 2012 10:24 PM, "Robert Bonomi" <bonomi at mail.r-bonomi.com>
wrote:
> > >
> > > Even better, nat to a 'bogon' DNS server -- one that -- regardless of
the
> > > query -- returns the address of a dedicated machine on your network
set up
> > > especially for this purpose.
> >
> > What happens when the client sends a POST from a cached page on the end
> > user's machine? E.g. if they post login credentials. Of course, they'll
get
> > the error page, but then you have confidential data in your logs and now
> > you have to protect highly confidential info, at least if you're in
europe.
> >
>
> *WHAT* 'confidential data' in which logs?   <grin>
>
> The aforementioned dedicated machine isn't a real web-server, or a real
> 'any other' server -- it is solely a special-purpose application machine,
> When you connect to it on say, port 80, it doesn't log anything from the
> port -- it just logs (1) the timestamp, and (2) the connecting IP address
> (and _nothing_ else); then it copies out a previously prepared static
file,
> and disconnects.
>
> You build a separae app that reads that logfile, matches IP
ddress/timestamp
> to a customer account, and feeds a message into the 'customer records'
system
> that this customer -has- been notified of this problem, and when, in case
> they call for support.
>
> If one is 'really' paranoid, the 'logfile' can be implemented as a 'pipe'
> between the processes, so that the data never hits disk in the first
place. ;)
>
> I've got proof-of-concept code for a single program that handles HTTP
(port
> 80), SMTP (port 25 and port 587), POP3 (port 110), IMAP2 & 4 (port 143),
IMAP3
> (port 220), TELNET (port 23), FTP (port 21), and NNTP (port 119), so far.
> I'm planing to add IRC, and various SSL-based protocols as well.
>

So you're suggesting that the client sends a DNS request to one of the sink
holes, which is intercepted by an appliance via some sort of NAT and then
dropped? That's also illegal in Europe. You are denying users the right to
information.

Using a redirect to some sort of Web server (a weird sort of DNS poisoning)
will at least inform a user that they're infected. But then that opens
another can of worms. I am imagining some sort of Facebook style "free
notification system" free to what extent? It also trains users to accept
foreign security advice aka fake AV warnings.

From owen at delong.com  Mon Feb 20 04:04:21 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 20 Feb 2012 02:04:21 -0800
Subject: Common operational misconceptions
In-Reply-To: <20120220012144.D239C1D9D0AE@drugs.dv.isc.org>
References: <201202200107.q1K17W5l000294@aurora.sol.net>
 <20120220012144.D239C1D9D0AE@drugs.dv.isc.org>
Message-ID: <A75C4B53-E6DC-4E68-890C-A59FAEEC5383@delong.com>


On Feb 19, 2012, at 5:21 PM, Mark Andrews wrote:

> 
> In message <201202200107.q1K17W5l000294 at aurora.sol.net>, Joe Greco writes:
>>>> I have running code to make the reverse translations, with
>>>> which protocols such as ftp with PORT commands are working.
>>> 
>>> No, I think you do not understand...
>>> 
>>> I have a NAT gateway with a single public address.
>>> 
>>> I have 15 FTP servers and 22 web servers behind it.
>>> 
>>> I want people to be able to go to ftp://<hostname> and/or =
>>> http://<hostname> for each of them.
>> 
>> Owen,
>> 
>> Your suggestion here would set many "security experts" heads on fire.
>> 
>> Whatever will they do when NAT doesn't make such things virtually
>> impossible?
>> 
>> :-)
> 
> Time to write "How to use SRV with FTP".  CGN is going to push
> the extension of a whole lot of protocols.

That would be the worst case scenario, actually.

Owen



From Valdis.Kletnieks at vt.edu  Mon Feb 20 07:33:47 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 20 Feb 2012 08:33:47 -0500
Subject: Common operational misconceptions
In-Reply-To: Your message of "Sun, 19 Feb 2012 16:24:49 PST."
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <1329492037.18866.YahooMailNeo@web31805.mail.mud.yahoo.com>
 <4F3F8C28.3090002@necom830.hpcl.titech.ac.jp>
 <825545E3-D383-49FB-A15F-3565A3A504C5@delong.com>
Message-ID: <128556.1329744827@turing-police.cc.vt.edu>

On Sun, 19 Feb 2012 16:24:49 PST, Owen DeLong said:

> No, I think you do not understand...
>
> I have a NAT gateway with a single public address.
>
> I have 15 FTP servers and 22 web servers behind it.
>
> I want people to be able to go to ftp://<hostname> and/or =
> http://<hostname> for each of them.
>
> Please explain to me how your code solves this problem?

I suspect that Masataka thinks the fact you can say http://hostname1:81,
http://hostname2:82, and so on means it's Not A Problem.

Except of course if you're trying to deploy this to actual users on actual
networks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/af6d9c2e/attachment.bin>

From varkey at varkey.in  Mon Feb 20 08:19:09 2012
From: varkey at varkey.in (Vivek Thomas)
Date: Mon, 20 Feb 2012 14:19:09 +0000 (UTC)
Subject: Dynadot DNS acting up?
References: <CAPF5agcjDxbYVkTa7j5aQZu_ML6e5cSW9FxqyJf14NWf+UWe8A@mail.gmail.com>
Message-ID: <loom.20120220T151731-629@post.gmane.org>

Chris <caldcv <at> gmail.com> writes:

> 
> Anyone noticing issues with Dynadot (site is down) and Dynadot related
> domain names where you are using their DNS servers?
> 


Yep, I was using Dynadot DNS for one of my domains. It seems their DNS servers
weren't functioning properly. Anyway I switched to NameCheap Free DNS after that.



From Valdis.Kletnieks at vt.edu  Mon Feb 20 08:42:15 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 20 Feb 2012 09:42:15 -0500
Subject: Common operational misconceptions
In-Reply-To: Your message of "Mon, 20 Feb 2012 15:42:56 +0900."
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
Message-ID: <131354.1329748935@turing-police.cc.vt.edu>

On Mon, 20 Feb 2012 15:42:56 +0900, Masataka Ohta said:
> George Bonser wrote:
>
> >> It is seemingly working well means there is not much PMTU changes,
> >> which means we had better assumes some PMTU (1280B, for example) and
> >> use it without PMTUD.
>
> > It depends on the OS and the method being used.  If you set the
> > option to "2" on Linux, it will do MTU probing constantly and
> > react to MTU changes.
>
> It actually does nothing.

Did you find this by just reading RFCs, or by actual code inspection?

> the hosts are keep assuming PMTU of 1400B and if local MTU
> is 1500B or less, no discovery is performed because "the
> probe size range is small enough".

And if the local MTU is 9000?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/61ff15a0/attachment.bin>

From bicknell at ufp.org  Mon Feb 20 08:57:16 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 20 Feb 2012 06:57:16 -0800
Subject: X.509 Certs For Personal Use - Follow Up
In-Reply-To: <20120218010729.GA10033@ussenterprise.ufp.org>
References: <20120218010729.GA10033@ussenterprise.ufp.org>
Message-ID: <20120220145716.GA56111@ussenterprise.ufp.org>


I received a number of interesting replies, most off-list, so I thought
I would summarize and perhaps restart the discussion.

Many folks pushed the "run your own CA" idea.  While I get that works,
and even secures the communication, if you run a web site accessed by
random folks it will confuse some percentage of them.

StartCom (www.startssl.com) seems to be the only 100% free option, with
a few limitations.  You must own your own domain (for instance they
validate your e-mail based on the ones listed in whois), and the certs
have the Organization set to "Persona not validated".  This doesn't
prevent the certs from working fine and "locking the padlock", but if
someone looks at it may raise an eyebrow.  Still, it's free, you can
generate a personal cert for e-mail and certs for web, smtps, jabber,
etc.  Multiple certs are no problem.  For 100% free, it's the only
option anyone has mentioned.

From there, you can move up to "cheap" with a couple of options.  With
StartCom a $60 upcharge will verify a _person_.  From that you can
generate unlimited certs for the domains you own, a pricing model I
think is really nice.  They are good for 2 years, although the
verification is only good for 1 year.  So it's $60 every 2 years if
you're not doing any new cert issues in that time, or $60 every year if
you are; but the lack of a per-cert charge makes this a pretty good deal
if you run a bunch of domains.

In the per-cert realm, both CheapSSL.COM ($8.95/cert/year) and RapidSSL
($49/cert/3year) offer relatively cheap per-cert pricing for one and
three year certs, respectively.  Depending on needs these may be cheaper
or more expensive than StartCom.

I am personally trying out the StartCom free for S/MIME, HTTPS,
SMTPS, and IMAPS right now, and they are working quite nicely thus
far.  If the testing goes well with all clients I may upgrade to
their verified product.

One last interesting idea that's not quite ready for prime time.
There's an IETF working group called DANE which has code in Chrome:
https://datatracker.ietf.org/wg/dane/

The idea is pretty simple, DNSSEC sign your zones, and then publish your
own key material in DNS.  By doing this there is no need for a CA at all,
which eliminates not only cost but the trust and security issues with
the CA's.  Of course it moves the trust and security to DNS, but at
least two folks argued that DNS (management) has proved more secure than
CA's, and at least here were fewer players to audit and trust.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/90e51b7a/attachment.bin>

From jlewis at lewis.org  Mon Feb 20 09:34:58 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 20 Feb 2012 10:34:58 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <20120219032255.GA30213@jeeves.rigozsaurus.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
Message-ID: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>

On Sat, 18 Feb 2012, John Osmon wrote:

> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
> trash bin and stuck it on a spare crash cart.
>
> Then I fixed something while they were still looking for USB-Serial,
> etc.

Speaking of that sort of thing, I'd really LOVE if there were a device 
about the size of a netbook that could be hooked up to otherwise headless 
machines in colos that would give you keyboard, video & mouse.  i.e. a 
folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know 
there are folding rackmount versions of this (i.e. from Dell), but I want 
something far more portable.  Twice in the past month, I'd had to drive 
100+ miles to a remote colo and took a full size flat panel monitor and 
keyboard with me.  Has anyone actually built this yet?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From jra at baylink.com  Mon Feb 20 09:37:21 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 20 Feb 2012 10:37:21 -0500 (EST)
Subject: facebook.com DNS not found 20120218 2125 UTC
In-Reply-To: <CAL9jLaZ06RLHfp=mqbbzcdXH=pQ5QDo+10EBjjxg8fUxUGJ_zQ@mail.gmail.com>
Message-ID: <3007153.144.1329752241814.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Christopher Morrow" <morrowc.lists at gmail.com>

> This sort of thing happens 'often' ('XXX is not available, wtf?')
> 
> should there be some set of troubleshooting steps followed, like a
> list of thing you'd do in order to show you'd troubleshot the problem
> and it wasn't "your problem"? Something along the lines of:
> 
> o whois output
> o dig NS output
> o dig +trace output
> o 'downforeveryoneorjustme.com' says things are tango-uniform
> o other...
> 
> reported such that others can either refute usefully or corroborate.

That's our ruleset on Outages; I repost it every so often (optimally
monthly, though it's not automated yet...)

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


From oscar.vives at gmail.com  Mon Feb 20 09:38:00 2012
From: oscar.vives at gmail.com (Tei)
Date: Mon, 20 Feb 2012 16:38:00 +0100
Subject: DNS Attacks
In-Reply-To: <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
Message-ID: <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>

I am a mere user, so I all this stuff sounds to me like giberish.

The right solution is to capture the request to these DNS servers, and
send to a custom server with a static message  "warning.html". Nothing
fancy.   With a phone number to "get out of jail", so people can call
to "op-out" of this thing, so can browse the internet to search for a
solution.

This or do nothing.

http://www.guardian.co.uk/world/2012/jan/18/iran-death-sentence-porn-programmer
Interpol helps Iran capture a programmer for creating porn sites.

Now, if the Interpol want you to block a DNS server, or worse, to spy
on users conecting to a DNS server. Will you help?  doing nothing is
also a good option, methinks.  Start medling, redirecting dns trafic,
spyiing on the user... all these things are dirty and can't end well.

(note, of course, I am a user, so I have a user opinion. )



-- 
--
?in del ?ensaje.


From Matthew.Black at csulb.edu  Mon Feb 20 09:40:10 2012
From: Matthew.Black at csulb.edu (Matthew Black)
Date: Mon, 20 Feb 2012 15:40:10 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <ED78B1C68B84A14FA706D13A230D7B431941AFD0@ITS-MAIL01.campus.ad.csulb.edu>

Take a look at Raritan. We use their product to gain remote access to system consoles. No more driving 100s of miles. Ok, it would be 200 feet for us.


matthew black
information technology services bh-188
california state university, long beach

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Monday, February 20, 2012 7:35 AM
To: nanog at nanog.org
Subject: Re: WW: Colo Vending Machine

On Sat, 18 Feb 2012, John Osmon wrote:

> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the 
> trash bin and stuck it on a spare crash cart.
>
> Then I fixed something while they were still looking for USB-Serial, 
> etc.

Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video & mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive 
100+ miles to a remote colo and took a full size flat panel monitor and
keyboard with me.  Has anyone actually built this yet?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________





From blake at pfankuch.me  Mon Feb 20 10:41:40 2012
From: blake at pfankuch.me (Blake Pfankuch)
Date: Mon, 20 Feb 2012 16:41:40 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <CC75EEBF17C7374EA8309102B7B10C84860B7D7C@SHSBS.shenrons-house.local>

I too would be VERY interested in something like this.  There are many times when I am out on site with customers who don't have anything connected to it and you need to figure out what is up.  Even a VGA input USB keyboard/mouse and application to match it for an Android/iFail tablet would be AWESOME.  I'm sure our office would buy about 10 of them the first week they were out...  I have USB inputs on my tablet that work for USB headphones and USB keyboard so I would think it would just be driver and software fun....

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Monday, February 20, 2012 8:35 AM
To: nanog at nanog.org
Subject: Re: WW: Colo Vending Machine

On Sat, 18 Feb 2012, John Osmon wrote:

> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the 
> trash bin and stuck it on a spare crash cart.
>
> Then I fixed something while they were still looking for USB-Serial, 
> etc.

Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video & mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive 
100+ miles to a remote colo and took a full size flat panel monitor and
keyboard with me.  Has anyone actually built this yet?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________



From gbonser at seven.com  Mon Feb 20 10:47:42 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 20 Feb 2012 16:47:42 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>

> George Bonser wrote:
> 
> >> It is seemingly working well means there is not much PMTU changes,
> >> which means we had better assumes some PMTU (1280B, for example) and
> >> use it without PMTUD.
> 
> > It depends on the OS and the method being used.  If you set the
> option
> > to "2" on Linux, it will do MTU probing constantly and react to MTU
> > changes.
> 
> It actually does nothing.


Must be magic then, because it works for me.  I've got a few dozen servers with MTU 7500 that aren't having a bit of trouble talking to anyone.




From mpetach at netflight.com  Mon Feb 20 10:54:29 2012
From: mpetach at netflight.com (Matthew Petach)
Date: Mon, 20 Feb 2012 08:54:29 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>

On Mon, Feb 20, 2012 at 7:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
> Speaking of that sort of thing, I'd really LOVE if there were a device about
> the size of a netbook that could be hooked up to otherwise headless machines
> in colos that would give you keyboard, video & mouse. ?i.e. a folding
> netbook shaped VGA monitor with USB keyboard and touchpad. ?I know there are
> folding rackmount versions of this (i.e. from Dell), but I want something
> far more portable. ?Twice in the past month, I'd had to drive 100+ miles to
> a remote colo and took a full size flat panel monitor and keyboard with me.
> ?Has anyone actually built this yet?

Seeing as how most laptops have a VGA connector
and a keyboard/mouse connector on them, albeit
wired in the wrong direction (VGA connector feeds
video out from the video card, keyboard port takes
in input from external keyboard), the wiring and hard
parts are already mostly done; I'd *love* to have a
vendor release a laptop line that has a toggle switch
on it that a) only engages when the laptop is off, and
b) flips the logic--keyboard port gets connected to the
output of the laptop keyboard, and sends data out
rather than receives data, while the VGA port is
disconnected from the video card, and is instead
connected to the LCD panel of the laptop.  If an
enterprise vendor added support for a toggle like
that, I'm sure there would be dozens of companies
that would order them in a heartbeat, to be able to
do away with the constant need for crash carts
rolling around the datacenter aisles.  Heck, even
I'd order one--I could finally get rid of the old monitors
I keep around the house for debugging random
server problems in the rack upstairs.  :/

Matt


From Valdis.Kletnieks at vt.edu  Mon Feb 20 11:00:20 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 20 Feb 2012 12:00:20 -0500
Subject: DNS Attacks
In-Reply-To: Your message of "Mon, 20 Feb 2012 16:38:00 +0100."
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
Message-ID: <5236.1329757220@turing-police.cc.vt.edu>

On Mon, 20 Feb 2012 16:38:00 +0100, Tei said:
> The right solution is to capture the request to these DNS servers, and
> send to a custom server with a static message  "warning.html".

Not all DNS lookups are for websites.  The lookup could be for NTP, or SMTP,
or ssh, or a World of Warcraft server, or....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/bcf0b4f1/attachment.bin>

From jgreco at ns.sol.net  Mon Feb 20 11:01:27 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Mon, 20 Feb 2012 11:01:27 -0600 (CST)
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <201202201701.q1KH1RpB012750@aurora.sol.net>

> Speaking of that sort of thing, I'd really LOVE if there were a device 
> about the size of a netbook that could be hooked up to otherwise headless 
> machines in colos that would give you keyboard, video & mouse.  i.e. a 
> folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know 
> there are folding rackmount versions of this (i.e. from Dell), but I want 
> something far more portable.  Twice in the past month, I'd had to drive 
> 100+ miles to a remote colo and took a full size flat panel monitor and 
> keyboard with me.  Has anyone actually built this yet?

Not that I know of.  We used to be able to buy Proview PL456S / Mag
Innovision LT456S's 14" LCD's, which are fairly portable and small,
and combined with a small form factor keyboard, that's not a horrible
compromise.  You just jam one in a little spare space in the top of a
rack.  But you can't *get* them anymore.  Monitor sizes have exploded 
in the last half a decade.  Bah.

But from our own experience, the need for a keyboard and display has
decreased dramatically in recent years.  Most server grade gear these
days can be had with IPMI/iLO/whatever, and the use of ESXi makes it
uncommon for us to actually need physical KVM, which means that a small
laptop is an ever-more-flexible tool.  I'm a little curious to know if
this sort of arrangement is still relatively uncommon.

I must admit that our planning and preparedness is designed around a
multi-level strategy to avoid having to go on-site to a site nearly a
thousand miles away, so we've probably instrumented things a bit more
heavily than many networks, but when the cost difference between IPMI-
capable gear and standard gear is a handful of dollars, I guess I am
a bit mystified that anyone would want to "drive 100+ miles to a
remote colo" twice a month for a task that it sounds like KVMoIP or
IPMI might be able to tackle.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From pelzi at pelzi.net  Mon Feb 20 11:32:57 2012
From: pelzi at pelzi.net (Jussi Peltola)
Date: Mon, 20 Feb 2012 19:32:57 +0200
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <20120220173256.GJ22186@pokute.pelzi.net>

On Mon, Feb 20, 2012 at 10:34:58AM -0500, Jon Lewis wrote:
> Speaking of that sort of thing, I'd really LOVE if there were a
> device about the size of a netbook that could be hooked up to
> otherwise headless machines in colos that would give you keyboard,
> video & mouse.  i.e. a folding netbook shaped VGA monitor with USB
> keyboard and touchpad.  I know there are folding rackmount versions
> of this (i.e. from Dell), but I want something far more portable.
> Twice in the past month, I'd had to drive 100+ miles to a remote
> colo and took a full size flat panel monitor and keyboard with me.
> Has anyone actually built this yet?
 
http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html

Get a usb ethernet adapter to plug it in if you don't want to use the
only one in your laptop.

Ethernet is a great convenience for this purpose. It is much nicer to
use a long cable to get away from the heat and cramped aisle so you can
stretch your legs while typing.

The spider duo even allows RS232 access with reverse telnet and ssh.

IMO having a portable IP KVM at every site is a very good investment.
Just ask remote hands to connect it. Then you can diagnose at home and
drive only when it is necessary. In customer sites the customer will
usually be very happy to be the remote hands, so they will get faster
repairs for less cost.


From joelja at bogus.com  Mon Feb 20 11:51:59 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 20 Feb 2012 09:51:59 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
Message-ID: <4F42883F.5050301@bogus.com>

On 2/20/12 08:54 , Matthew Petach wrote:
> On Mon, Feb 20, 2012 at 7:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
>> Speaking of that sort of thing, I'd really LOVE if there were a device about
>> the size of a netbook that could be hooked up to otherwise headless machines
>> in colos that would give you keyboard, video & mouse.  i.e. a folding
>> netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are
>> folding rackmount versions of this (i.e. from Dell), but I want something
>> far more portable.  Twice in the past month, I'd had to drive 100+ miles to
>> a remote colo and took a full size flat panel monitor and keyboard with me.
>>  Has anyone actually built this yet?

http://www.startech.com/Server-Management/KVM-Switches/Portable-USB-PS-2-KVM-Console-Adapter-for-Notebook-PCs~NOTECONS01

> I'm sure there would be dozens of companies
> that would order them in a heartbeat, to be able to
> do away with the constant need for crash carts
> rolling around the datacenter aisles.  Heck, even
> I'd order one--I could finally get rid of the old monitors
> I keep around the house for debugging random
> server problems in the rack upstairs.  :/

Dozens is a rather small market when a production run is a couple
hundred thousand units...

Things with legacy ports on them are on the way out. given an ipmi
manager that doesn't suck there should be no reason to connect to the
machine at all, to console in. the rats nest is a lot more tractable
when there is ethernet and power and nothing else.



From bicknell at ufp.org  Mon Feb 20 11:55:07 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Mon, 20 Feb 2012 09:55:07 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F42883F.5050301@bogus.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <4F42883F.5050301@bogus.com>
Message-ID: <20120220175507.GA66123@ussenterprise.ufp.org>

In a message written on Mon, Feb 20, 2012 at 09:51:59AM -0800, Joel jaeggli wrote:
> Things with legacy ports on them are on the way out. given an ipmi
> manager that doesn't suck there should be no reason to connect to the
> machine at all, to console in. the rats nest is a lot more tractable
> when there is ethernet and power and nothing else.

This reminded me of another gizmo I'd like to have...

How about a Bluetooth to Serial adapter?  Routers don't (yet) have
iLO, but I have this fantasy about being able to walk into a colo
with a handfull of small adapters that I simply plug on to consoles
and then sit down with my laptop and can access all the serial ports
without having to run cables.

Talk about eliminating the rat's nest....

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120220/d085bbd8/attachment.bin>

From morrowc.lists at gmail.com  Mon Feb 20 11:55:21 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 20 Feb 2012 12:55:21 -0500
Subject: DNS Attacks
In-Reply-To: <5236.1329757220@turing-police.cc.vt.edu>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
 <5236.1329757220@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaYiRk2orA=y1vyj_GuQcaHiPwbpo+oF74wWJwJRs52JPw@mail.gmail.com>

On Mon, Feb 20, 2012 at 12:00 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Mon, 20 Feb 2012 16:38:00 +0100, Tei said:
>> The right solution is to capture the request to these DNS servers, and
>> send to a custom server with a static message ?"warning.html".
>
> Not all DNS lookups are for websites. ?The lookup could be for NTP, or SMTP,
> or ssh, or a World of Warcraft server, or....

thank you.


From morrowc.lists at gmail.com  Mon Feb 20 11:57:46 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 20 Feb 2012 12:57:46 -0500
Subject: DNS Attacks
In-Reply-To: <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
Message-ID: <CAL9jLaaYJUDoeWqUCrzXLGn0PXecrrCSHvij0JeLJhAYkDgJFA@mail.gmail.com>

On Mon, Feb 20, 2012 at 10:38 AM, Tei <oscar.vives at gmail.com> wrote:
> I am a mere user, so I all this stuff sounds to me like giberish.
>
> The right solution is to capture the request to these DNS servers, and
> send to a custom server with a static message ?"warning.html". Nothing
> fancy. ? With a phone number to "get out of jail", so people can call
> to "op-out" of this thing, so can browse the internet to search for a
> solution.


in this case, the fbi/dns-changer case, the information is pretty
straightforward for theisp folk... 'client machine makes dns queries
not to the isp dns server (or one of several free dns services), but
to a known bad set of netblocks'

the easy fix is to just stand up (forever, ha!) dns servers on the ip
blocks inside the ISP's network, done and done... they can then start
notifying the customers via mail/email/carrier-pidgeon that they are
infected, along with instructions about how to get un-infected.

-chris


From joelja at bogus.com  Mon Feb 20 12:22:02 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 20 Feb 2012 10:22:02 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <20120220175507.GA66123@ussenterprise.ufp.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <4F42883F.5050301@bogus.com> <20120220175507.GA66123@ussenterprise.ufp.org>
Message-ID: <4F428F4A.9000205@bogus.com>

On 2/20/12 09:55 , Leo Bicknell wrote:
> In a message written on Mon, Feb 20, 2012 at 09:51:59AM -0800, Joel jaeggli wrote:
>> Things with legacy ports on them are on the way out. given an ipmi
>> manager that doesn't suck there should be no reason to connect to the
>> machine at all, to console in. the rats nest is a lot more tractable
>> when there is ethernet and power and nothing else.
> 
> This reminded me of another gizmo I'd like to have...
> 
> How about a Bluetooth to Serial adapter?  Routers don't (yet) have
> iLO, but I have this fantasy about being able to walk into a colo
> with a handfull of small adapters that I simply plug on to consoles
> and then sit down with my laptop and can access all the serial ports
> without having to run cables.

such a thing exists, I wouldn't consider it part of permanent oob solution.

http://www.amazon.com/SIIG-ID-SB0011-S1-RS-232-Bluetooth-Converter/dp/B001AZTABE

http://www.quatech.com/catalog/bluetooth_serial.php

> Talk about eliminating the rat's nest....
> 



From Joel.Snyder at Opus1.COM  Mon Feb 20 12:40:00 2012
From: Joel.Snyder at Opus1.COM (Joel M Snyder)
Date: Mon, 20 Feb 2012 11:40:00 -0700
Subject: Bluetooth-to-Serial (was: Re: Colo Vending Machine)
Message-ID: <4F429380.2040109@opus1.com>

+1 on the suggestion for a SpiderDuo as portable KVM+your own laptop. 
Solves the problem and leverages the hardware you already have.  Works 
great!

Anyway: Bluetooth-to-Serial has been around for years; I did a review of 
several of them a while ago, even connecting with a Nokia phone (this 
was before iPhone/iPad existed) in a little Interop video piece in 
Network World.

The IOGear BT-to-Serial is the most common nowadays; it is inexpensive 
and works pretty well and it is specifically designed for this kind of 
console environment.  It draws 9V, so you can make a 9V 
battery-to-device adapter for about $2 with parts you get at Digikey if 
you want total portability.

There are also more 'industrial' versions which are designed for 
longer-term use.  My favorite is the BluePortXP, which has an integrated 
rechargeable battery, a nice little antenna, and can be externally 
powered if needed.  That's pricey, closer to $200 as I remember, but it 
is designed for longer-term use in a single location.  There are others 
along this line, a quick Google search will find them, mostly in the 
industrial PC-type businesses.

The one I actually use almost every day is called a BlueConsole.  These, 
unfortunately, are not available anymore.  A Cisco engineer in Florida 
(I think) made them as a "Garagatronics" project years ago.  It is a 
lovely piece of work, available with either a DB9 OR a RJ45 male on it, 
a 9V battery connector on the other end, and also powered from the 
serial port if available.  You can dangle the RJ45 one from a Cisco 
router literally forever without a battery and it will BT-to-serial for 
20 or 30 feet.  If you can find one, buy it as it's the perfect 
compromise between the BluePort and the IOGear.

jms
-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
jms at Opus1.COM                http://www.opus1.com/jms


From jlewis at lewis.org  Mon Feb 20 13:19:15 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 20 Feb 2012 14:19:15 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <201202201701.q1KH1RpB012750@aurora.sol.net>
References: <201202201701.q1KH1RpB012750@aurora.sol.net>
Message-ID: <Pine.LNX.4.61.1202201416320.2201@soloth.lewis.org>

On Mon, 20 Feb 2012, Joe Greco wrote:

> I must admit that our planning and preparedness is designed around a
> multi-level strategy to avoid having to go on-site to a site nearly a
> thousand miles away, so we've probably instrumented things a bit more
> heavily than many networks, but when the cost difference between IPMI-
> capable gear and standard gear is a handful of dollars, I guess I am
> a bit mystified that anyone would want to "drive 100+ miles to a
> remote colo" twice a month for a task that it sounds like KVMoIP or
> IPMI might be able to tackle.

Technically, only one of the trips was to play doctor on the remote 
server...the second was to upgrade/replace other gear in the POP, but I 
figured as long as I'm there, it'd really suck to be there and not have a 
head for the server if I need it...so it went with me.  On the second 
trip, the monitor (this time a 20" because the 17" I'd taken last time had 
died in the interval between the trips...or maybe as a result of its car 
trip) never left the car.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From lowen at pari.edu  Mon Feb 20 13:18:51 2012
From: lowen at pari.edu (Lamar Owen)
Date: Mon, 20 Feb 2012 14:18:51 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <24634832.3435.1329504297384.JavaMail.root@benjamin.baylink.com>
References: <24634832.3435.1329504297384.JavaMail.root@benjamin.baylink.com>
Message-ID: <201202201418.51664.lowen@pari.edu>

On Friday, February 17, 2012 01:44:57 PM Jay Ashworth wrote:
> 2) Power cords: C19 to L6-15, C19 to C20, C13 to C20 (latter 2 for 208V PDUs)
>     (If you don't have your own C13 to L6-15 cords, you're in the wrong biz)

An interesting thread.....

I'd say if you had, instead of a C13 on one end, a C15 so that it would be a tad more universal (Cisco 7507 and 12012 power supplies, for instance, are C16 and not C14 inlets), since the C15 will mate to a C14 but a C13 won't mate to a C16.  As I'm still running some old kit (have a 7507 still in production in an internal role, and just removed a 12012) I have run into that.

And I'll have to be one of those who has no equipment needing an L6-15; plenty of L5-20's, L5-30's, L6-20's, L6-30's, and a few L21-30's but no 15 amp locking NEMA receptacles to be found.  Is an L6-15R standard on some PDU's or something, while others are C14 and C20 (such as EMC's PDU's)?


From jra at baylink.com  Mon Feb 20 13:57:19 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 20 Feb 2012 14:57:19 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <7348703.158.1329767839008.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jon Lewis" <jlewis at lewis.org>

> Speaking of that sort of thing, I'd really LOVE if there were a device
> about the size of a netbook that could be hooked up to otherwise headless
> machines in colos that would give you keyboard, video & mouse. i.e. a
> folding netbook shaped VGA monitor with USB keyboard and touchpad. I know
> there are folding rackmount versions of this (i.e. from Dell), but I want
> something far more portable. Twice in the past month, I'd had to drive
> 100+ miles to a remote colo and took a full size flat panel monitor and
> keyboard with me. Has anyone actually built this yet?

Not quite... but there is at least one vendor who manufactures a single-head
genlock VNC server; it plugs into your VGA, KB and Mouse connectors, and has
an Ethernet connector on the other side.

This might actually be more useful, I think.

Wish I could give you a vendor name.  Startech makes them with builtin KVM
switches, but I'm not sure if they have the single port model.

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


From jra at baylink.com  Mon Feb 20 14:05:16 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 20 Feb 2012 15:05:16 -0500 (EST)
Subject: Single-port Network "KVM"
Message-ID: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>

Here's one example; cheapest I've seen:

http://www.kvm-switches-online.com/0su51068.html

There are others.  This one appears to be web/java based rather than VNC,
though that probably isn't a killer for most people.

I thought I'd seen a little dongle-y model; I'll look around a bit more.

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


From jra at baylink.com  Mon Feb 20 14:08:39 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 20 Feb 2012 15:08:39 -0500 (EST)
Subject: Single-port Network "KVM"
In-Reply-To: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
Message-ID: <29102431.164.1329768519273.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jay Ashworth" <jra at baylink.com>

> There are others. This one appears to be web/java based rather than VNC,
> though that probably isn't a killer for most people.
> 
> I thought I'd seen a little dongle-y model; I'll look around a bit
> more.

Didn't read far enough; Jussi Peltola posted this downthread:

http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html

That's the item I wanted, and it's only $200.  And Lantronix' support
department is arguably the best hardware vendor support organization I 
have *ever* worked with.

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


From pelzi at pelzi.net  Mon Feb 20 14:14:20 2012
From: pelzi at pelzi.net (Jussi Peltola)
Date: Mon, 20 Feb 2012 22:14:20 +0200
Subject: Single-port Network "KVM"
In-Reply-To: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
References: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120220201420.GK22186@pokute.pelzi.net>

On Mon, Feb 20, 2012 at 03:05:16PM -0500, Jay Ashworth wrote:
> Here's one example; cheapest I've seen:
> 
> http://www.kvm-switches-online.com/0su51068.html
> 
> There are others.  This one appears to be web/java based rather than VNC,
> though that probably isn't a killer for most people.
> 
> I thought I'd seen a little dongle-y model; I'll look around a bit more.
> 
 
Again:

http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html

only $199. Disclaimer: I'm only a satisfied customer. The SpiderDuo
seems to be more or less the same thing as the supermicro IPMI cards,
and works well, even though it has the typical hack-ish embedded linux
appliance feel to it (i.e. I'd not dare to connect it to the internet at
large)

The reverse telnet serial does seem to work without mucking the data,
which I find very important. Come to think of it, I'm not sure if you
can send a BREAK. I'll need to check the next time I'm using it.


From joelja at bogus.com  Mon Feb 20 15:00:56 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Mon, 20 Feb 2012 13:00:56 -0800
Subject: DNS Attacks
In-Reply-To: <CAL9jLaaYJUDoeWqUCrzXLGn0PXecrrCSHvij0JeLJhAYkDgJFA@mail.gmail.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
 <CAL9jLaaYJUDoeWqUCrzXLGn0PXecrrCSHvij0JeLJhAYkDgJFA@mail.gmail.com>
Message-ID: <4F42B488.2090903@bogus.com>

On 2/20/12 09:57 , Christopher Morrow wrote:
> On Mon, Feb 20, 2012 at 10:38 AM, Tei <oscar.vives at gmail.com> wrote:
>> I am a mere user, so I all this stuff sounds to me like giberish.
>>
>> The right solution is to capture the request to these DNS servers, and
>> send to a custom server with a static message  "warning.html". Nothing
>> fancy.   With a phone number to "get out of jail", so people can call
>> to "op-out" of this thing, so can browse the internet to search for a
>> solution.
> 
> 
> in this case, the fbi/dns-changer case, the information is pretty
> straightforward for theisp folk... 'client machine makes dns queries
> not to the isp dns server (or one of several free dns services), but
> to a known bad set of netblocks'
> 
> the easy fix is to just stand up (forever, ha!) dns servers on the ip
> blocks inside the ISP's network, done and done... 

given the size and distribution of the ip blocks in question I doubt
very much that they will go unused forever...

from a previous message in this thread.

  Quoting the FBI:
  85.255.112.0 through 85.255.127.255
  67.210.0.0 through 67.210.15.255
  93.188.160.0 through 93.188.167.255
  77.67.83.0 through 77.67.83.255
  213.109.64.0 through 213.109.79.255
  64.28.176.0 through 64.28.191.255

which map quite nice to various rir prefix assigments. it's almost like
someone cribbed the whois inetnum field when they loaded their scattergun...

inetnum:         85.255.112.0 - 85.255.127.255

while I have no doubt that some of those prefixes my be run by rather
than simply host to bad actors, if they're returned to rirs, they will
be assigned again, so a static filter policy will return to bite us
again like it always does.

> they can then start
> notifying the customers via mail/email/carrier-pidgeon that they are
> infected, along with instructions about how to get un-infected.
> 
> -chris
> 
> 



From sethm at rollernet.us  Mon Feb 20 15:05:38 2012
From: sethm at rollernet.us (Seth Mattinen)
Date: Mon, 20 Feb 2012 13:05:38 -0800
Subject: Single-port Network "KVM"
In-Reply-To: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
References: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F42B5A2.4050502@rollernet.us>

On 2/20/12 12:05 PM, Jay Ashworth wrote:
> Here's one example; cheapest I've seen:
> 
> http://www.kvm-switches-online.com/0su51068.html
> 
> There are others.  This one appears to be web/java based rather than VNC,
> though that probably isn't a killer for most people.
> 
> I thought I'd seen a little dongle-y model; I'll look around a bit more.
> 


A past thread also mentioned OpenGear:

http://opengear.com/product-IP-KVM.html

I'd been eying this one, but the $199 Lantronix seems like a price point
too good to pass up.

~Seth


From meirea at charterschoolit.com  Mon Feb 20 15:14:48 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Mon, 20 Feb 2012 21:14:48 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>,
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
Message-ID: <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>

Ive wished this for years. Seems like it could be easy to achieve in theory. 

-Mario Eirea

On Feb 20, 2012, at 11:55 AM, "Matthew Petach" <mpetach at netflight.com> wrote:

> On Mon, Feb 20, 2012 at 7:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
>> Speaking of that sort of thing, I'd really LOVE if there were a device about
>> the size of a netbook that could be hooked up to otherwise headless machines
>> in colos that would give you keyboard, video & mouse.  i.e. a folding
>> netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are
>> folding rackmount versions of this (i.e. from Dell), but I want something
>> far more portable.  Twice in the past month, I'd had to drive 100+ miles to
>> a remote colo and took a full size flat panel monitor and keyboard with me.
>>  Has anyone actually built this yet?
> 
> Seeing as how most laptops have a VGA connector
> and a keyboard/mouse connector on them, albeit
> wired in the wrong direction (VGA connector feeds
> video out from the video card, keyboard port takes
> in input from external keyboard), the wiring and hard
> parts are already mostly done; I'd *love* to have a
> vendor release a laptop line that has a toggle switch
> on it that a) only engages when the laptop is off, and
> b) flips the logic--keyboard port gets connected to the
> output of the laptop keyboard, and sends data out
> rather than receives data, while the VGA port is
> disconnected from the video card, and is instead
> connected to the LCD panel of the laptop.  If an
> enterprise vendor added support for a toggle like
> that, I'm sure there would be dozens of companies
> that would order them in a heartbeat, to be able to
> do away with the constant need for crash carts
> rolling around the datacenter aisles.  Heck, even
> I'd order one--I could finally get rid of the old monitors
> I keep around the house for debugging random
> server problems in the rack upstairs.  :/
> 
> Matt
> 


From pelzi at pelzi.net  Mon Feb 20 15:23:30 2012
From: pelzi at pelzi.net (Jussi Peltola)
Date: Mon, 20 Feb 2012 23:23:30 +0200
Subject: Laptop with reverse VGA
In-Reply-To: <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
Message-ID: <20120220212330.GL22186@pokute.pelzi.net>

It practically requires more hardware than a separate IP KVM. Finding
RS-232 in a laptop is already nearly impossible, so I doubt this will
happen.

The keyboard/mouse part *might* be possible in some cases where these
devices have a usb interface somewhere in the middle. Still, you'd need
cables that break USB standards or a separate connector.

The display would require a scaler/processor/ADC/TMDS receiver, which are
found in every standalone LCD. This stuff consumes multiple watts (it
becomes hot enough to cook itself in a few years after all) so it will
not appear in a laptop any time soon.

An IP KVM or a USB KVM is the way to go. Then you are not bound to one
very weird laptop and have to hunt for a new one every few years to
upgrade. And you can copy-paste stuff, and lots of other benefits.

On Mon, Feb 20, 2012 at 09:14:48PM +0000, Mario Eirea wrote:
> Ive wished this for years. Seems like it could be easy to achieve in theory. 
> 
> -Mario Eirea
> 
> On Feb 20, 2012, at 11:55 AM, "Matthew Petach" <mpetach at netflight.com> wrote:
> 
> > On Mon, Feb 20, 2012 at 7:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
> >> Speaking of that sort of thing, I'd really LOVE if there were a device about
> >> the size of a netbook that could be hooked up to otherwise headless machines
> >> in colos that would give you keyboard, video & mouse.  i.e. a folding
> >> netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are
> >> folding rackmount versions of this (i.e. from Dell), but I want something
> >> far more portable.  Twice in the past month, I'd had to drive 100+ miles to
> >> a remote colo and took a full size flat panel monitor and keyboard with me.
> >>  Has anyone actually built this yet?
> > 
> > Seeing as how most laptops have a VGA connector
> > and a keyboard/mouse connector on them, albeit
> > wired in the wrong direction (VGA connector feeds
> > video out from the video card, keyboard port takes
> > in input from external keyboard), the wiring and hard
> > parts are already mostly done; I'd *love* to have a
> > vendor release a laptop line that has a toggle switch
> > on it that a) only engages when the laptop is off, and
> > b) flips the logic--keyboard port gets connected to the
> > output of the laptop keyboard, and sends data out
> > rather than receives data, while the VGA port is
> > disconnected from the video card, and is instead
> > connected to the LCD panel of the laptop.  If an
> > enterprise vendor added support for a toggle like
> > that, I'm sure there would be dozens of companies
> > that would order them in a heartbeat, to be able to
> > do away with the constant need for crash carts
> > rolling around the datacenter aisles.  Heck, even
> > I'd order one--I could finally get rid of the old monitors
> > I keep around the house for debugging random
> > server problems in the rack upstairs.  :/
> > 
> > Matt
> > 
> 


From jra at baylink.com  Mon Feb 20 15:29:20 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 20 Feb 2012 16:29:20 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <20120220175507.GA66123@ussenterprise.ufp.org>
Message-ID: <9200930.179.1329773360600.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Leo Bicknell" <bicknell at ufp.org>

> This reminded me of another gizmo I'd like to have...
> 
> How about a Bluetooth to Serial adapter? Routers don't (yet) have
> iLO, but I have this fantasy about being able to walk into a colo
> with a handfull of small adapters that I simply plug on to consoles
> and then sit down with my laptop and can access all the serial ports
> without having to run cables.

C-O-N-N-E-C-T-I-C-U-T.

This is another device that's been around for some time:

http://www.ebay.com/itm/230748054309

That one's from Quatech (for the archives), but I know some other mfgs
make them too.

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


From faisal at snappydsl.net  Mon Feb 20 15:47:20 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Mon, 20 Feb 2012 16:47:20 -0500
Subject: Laptop with reverse VGA
In-Reply-To: <20120220212330.GL22186@pokute.pelzi.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
 <20120220212330.GL22186@pokute.pelzi.net>
Message-ID: <4F42BF68.6010700@snappydsl.net>

Interesting thought.....

You know you can easily put together something like such...

Some ideas for you:--

Screens:  (these are mostly designed to be 2nd Screens on laptops).

http://www.amazon.com/s/?ie=UTF8&keywords=lt1421&tag=googhydr-20&index=aps&hvadid=13474581570&ref=pd_sl_8j9d6nstmk_b 
<http://www.amazon.com/s/?ie=UTF8&keywords=lt1421&tag=googhydr-20&index=aps&hvadid=13474581570&ref=pd_sl_8j9d6nstmk_b>

More Screens:  Mostly designed for industrial / POS applications.

http://www.ebay.com/sch/i.html?_nkw=lilliput+vga+lcd&_sacat=0&_stpos=33155&_sop=16&gbr=1&_odkw=10.1%22+vga+lcd&_osacat=0&_trksid=p3286.c0.m270.l1313 
<http://www.ebay.com/sch/i.html?_nkw=lilliput+vga+lcd&_sacat=0&_stpos=33155&_sop=16&gbr=1&_odkw=10.1%22+vga+lcd&_osacat=0&_trksid=p3286.c0.m270.l1313>

http://store.earthlcd.com/LCD-Products

For Keyboards:
http://www.tigerdirect.com/applications/SearchTools/search.asp?keywords=small+keyboard

-----------------------
Or if you can order one of these..... Exactly what you are looking for !!!
http://store.earthlcd.com/LCD-Products/Portable-Monitors



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: Support at Snappydsl.net

On Mon, Feb 20, 2012 at 7:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
>>>> Speaking of that sort of thing, I'd really LOVE if there were a device about
>>>> the size of a netbook that could be hooked up to otherwise headless machines
>>>> in colos that would give you keyboard, video&  mouse.  i.e. a folding
>>>> netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are
>>>> folding rackmount versions of this (i.e. from Dell), but I want something
>>>> far more portable.  Twice in the past month, I'd had to drive 100+ miles to
>>>> a remote colo and took a full size flat panel monitor and keyboard with me.
>>>>   Has anyone actually built this yet?



From jlewis at lewis.org  Mon Feb 20 16:05:15 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Mon, 20 Feb 2012 17:05:15 -0500 (EST)
Subject: Laptop with reverse VGA
In-Reply-To: <4F42BF68.6010700@snappydsl.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
 <20120220212330.GL22186@pokute.pelzi.net> <4F42BF68.6010700@snappydsl.net>
Message-ID: <Pine.LNX.4.61.1202201702181.2201@soloth.lewis.org>

On Mon, 20 Feb 2012, Faisal Imtiaz wrote:

> Or if you can order one of these..... Exactly what you are looking for !!!
> http://store.earthlcd.com/LCD-Products/Portable-Monitors

That does look like pretty much exactly what I wanted...but a palm sized 
IP KVM for less than half the price seems much more sensible and useful. 
I'm already pushing for us to buy a few...and might even just buy a 
personal one.  It just goes to show, sometimes you don't know what you're 
looking for until you find it.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From dave at temk.in  Mon Feb 20 16:43:35 2012
From: dave at temk.in (Dave Temkin)
Date: Mon, 20 Feb 2012 14:43:35 -0800
Subject: [NANOG-announce] NANOG 55 - Vancouver:  Call For Presentations
Message-ID: <4F42CC97.3000200@temk.in>

     NANOG Community,

     After an awesome meeting in San Diego, we're already starting to get ready for NANOG 55 in Vancouver.  
If you have a topic you'd like to speak about, we'd love to consider it.  Please watch 
http://www.nanog.org/meetings/nanog55/callforpresentations.html for more information.

     Please keep these important dates in mind:


     Presentation Abstracts and Draft Slides Due:       02-Apr-2012
     Final Slides Due:                                                  09-Apr-2012
     Draft Program Published:                                    27-Apr-2012
     Final Agenda Published:                                      15-May-2012

     Please submit your materials to http://pc.nanog.org

     Looking forward to seeing everyone in San Diego.

     -Dave Temkin

     (Chair, NANOG Program Committee)

_______________________________________________
NANOG-announce mailing list
NANOG-announce at nanog.org
https://mailman.nanog.org/mailman/listinfo/nanog-announce


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 16:53:24 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 07:53:24 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
Message-ID: <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

> Must be magic then, because it works for me.

Yes, but magicians always use tricks.

> I've got a few dozen servers with MTU 7500 that aren't
> having a bit of trouble talking to anyone.

Your trick is that your routers at the border between MTUs
7500 and 1500 (or maybe, 1400 or so) generate ICMP packet
too big packets to your servers and no intermediate
entities filter them, isn't it?

						Masataka Ohta


From scott at sberkman.net  Mon Feb 20 17:05:31 2012
From: scott at sberkman.net (Scott Berkman)
Date: Mon, 20 Feb 2012 18:05:31 -0500
Subject: Laptop with reverse VGA
In-Reply-To: <Pine.LNX.4.61.1202201702181.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
 <20120220212330.GL22186@pokute.pelzi.net> <4F42BF68.6010700@snappydsl.net>
 <Pine.LNX.4.61.1202201702181.2201@soloth.lewis.org>
Message-ID: <007601ccf024$25847b70$708d7250$@sberkman.net>

There are also these, work with anything with a USB port:

http://www.blackbox.com/Store/Detail.aspx/USB-Laptop-Console-Crash-Cart-Adap
ter/KVT100A

You could mate this with a cheap used Netbook too.

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org] 
Sent: Monday, February 20, 2012 5:05 PM
To: Faisal Imtiaz
Cc: nanog at nanog.org
Subject: Re: Laptop with reverse VGA

On Mon, 20 Feb 2012, Faisal Imtiaz wrote:

> Or if you can order one of these..... Exactly what you are looking for !!!
> http://store.earthlcd.com/LCD-Products/Portable-Monitors

That does look like pretty much exactly what I wanted...but a palm sized IP
KVM for less than half the price seems much more sensible and useful. 
I'm already pushing for us to buy a few...and might even just buy a personal
one.  It just goes to show, sometimes you don't know what you're looking for
until you find it.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________




From gbonser at seven.com  Mon Feb 20 17:27:31 2012
From: gbonser at seven.com (George Bonser)
Date: Mon, 20 Feb 2012 23:27:31 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>

> 
> Your trick is that your routers at the border between MTUs
> 7500 and 1500 (or maybe, 1400 or so) generate ICMP packet too big
> packets to your servers and no intermediate entities filter them, isn't
> it?
> 
> 						Masataka Ohta

I am saying that MTU probing works just fine, even with a link in between that has a shorter MTU and doesn't pass ICMP.  I actually have one of those. 

It actively probes with packets of varying sizes and learns what the path MTU is.  It does not rely on ICMP.  Again, it actively probes with varying sizes of packets until it believes it has "converged".  There are two modes with linux.  1: where it only probes if there is a problem and 2: where it probes all the time.



   The initial value for search_high SHOULD be the largest possible
   packet that might be supported by the flow.  This may be limited by
   the local interface MTU, by an explicit protocol mechanism such as
   the TCP MSS option, or by an intrinsic limit such as the size of a
   protocol length field.  In addition, the initial value for
   search_high MAY be limited by a configuration option to prevent
   probing above some maximum size.  Search_high is likely to be the
   same as the initial Path MTU as computed by the classical Path MTU
   Discovery algorithm.

   It is RECOMMENDED that search_low be initially set to an MTU size
   that is likely to work over a very wide range of environments.  Given
   today's technologies, a value of 1024 bytes is probably safe enough.
   The initial value for search_low SHOULD be configurable.

...

   The probe may have a size anywhere in the "probe size range"
   described above.  However, a number of factors affect the selection
   of an appropriate size.  A simple strategy might be to do a binary
   search halving the probe size range with each probe.  However, for
   some protocols, such as TCP, failed probes are more expensive than
   successful ones, since data in a failed probe will need to be
   retransmitted.  For such protocols, a strategy that raises the probe
   size in smaller increments might have lower overhead.  For many
   protocols, both at and above the Packetization Layer, the benefit of
   increasing MTU sizes may follow a step function such that it is not
   advantageous to probe within certain regions at all.

   As an optimization, it may be appropriate to probe at certain common
   or expected MTU sizes, for example, 1500 bytes for standard Ethernet,
   or 1500 bytes minus header sizes for tunnel protocols.

   Some protocols may use other mechanisms to choose the probe sizes.
   For example, protocols that have certain natural data block sizes
   might simply assemble messages from a number of blocks until the
   total size is smaller than search_high, and if possible larger than
   search_low.

   Each Packetization Layer MUST determine when probing has converged,
   that is, when the probe size range is small enough that further
   probing is no longer worth its cost.  When probing has converged, a
   timer SHOULD be set.  When the timer expires, search_high should be
   reset to its initial value (described above) so that probing can
   resume.  Thus, if the path changes, increasing the Path MTU, then the
   flow will eventually take advantage of it.  The value for this timer
   MUST NOT be less than 5 minutes and is recommended to be 10 minutes,
   per RFC 1981.

The timer for Linux is 5 minute by default but you can change it.




From khuon at neebu.net  Mon Feb 20 17:39:26 2012
From: khuon at neebu.net (Jake Khuon)
Date: Mon, 20 Feb 2012 15:39:26 -0800
Subject: Laptop with reverse VGA
In-Reply-To: <20120220212330.GL22186@pokute.pelzi.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
 <20120220212330.GL22186@pokute.pelzi.net>
Message-ID: <1329781166.24342.6.camel@Decaf.NEEBU.Net>

On Mon, 2012-02-20 at 23:23 +0200, Jussi Peltola wrote:

> The display would require a scaler/processor/ADC/TMDS receiver, which are
> found in every standalone LCD. This stuff consumes multiple watts (it
> becomes hot enough to cook itself in a few years after all) so it will
> not appear in a laptop any time soon.

I think the form-factour is already there.  I have a Motorola Atrix
smartphone.  It's available with a laptop-dock unit.  This is
essentially a USB hub and display.  The display is connected by
outputting from the phone's HDMI port.  The rest of the input/output
device (keyboard and trackpad) are seen as USB connected devices and
interfaced via the phone's USB port (Atrix supports USB host mode).

Essentially, this laptop dock is what people are talking about except
for a generic host instead of for a phone. We would want to expose the
HDMI input generically and probably with an additional VGA input.  Of
course there are also VGA-HDMI converters.  Anyone wanna ring up
Motorola to see if they're interesting in adapting the Atrix laptop-dock
technology?

-- 
/*=================[ Jake Khuon <khuon at NEEBU.Net> ]=================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | -------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| NETWORKS |
 +==================================================================*/



From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 18:16:53 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 09:16:53 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
Message-ID: <4F42E275.50608@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

> I am saying that MTU probing works just fine, even with a
> link in between that has a shorter MTU and doesn't pass
> ICMP.

And I have been saying your statement is unfounded.

> I actually have one of those.

I can't see any.

> It actively probes with packets of varying sizes and learns
> what the path MTU is.

First, it sets eff_pmtu to 1400B. OK?

> It does not rely on ICMP.  Again, it actively probes with
> varying sizes of packets until it believes it has
> "converged".

>     The initial value for search_high SHOULD be the largest possible
>     packet that might be supported by the flow.  This may be limited by
>     the local interface MTU, by an explicit protocol mechanism such as
>     the TCP MSS option,

OK, so, even with local MTU of 7500B and without ICMP PTB, if
local MTU of your peer is 1500B, TCP MSS makes search_high
1500B.

As eff_pmtu of 1400B is close enough to search_high, you are
done.

Eff_pmtu of 1400B will be used forever with no probe packets
sent.

> The timer for Linux is 5 minute by default but you can change it.

Timer timeouts do not affect TCP MSS.

						Masataka Ohta

PS

Your lengthy quotation means you don't see the point.


From meirea at charterschoolit.com  Mon Feb 20 18:26:15 2012
From: meirea at charterschoolit.com (Mario Eirea)
Date: Tue, 21 Feb 2012 00:26:15 +0000
Subject: Laptop with reverse VGA
In-Reply-To: <007601ccf024$25847b70$708d7250$@sberkman.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
 <AFE88D5F-321E-4F7A-B197-B4A773220746@charterschoolit.com>
 <20120220212330.GL22186@pokute.pelzi.net> <4F42BF68.6010700@snappydsl.net>
 <Pine.LNX.4.61.1202201702181.2201@soloth.lewis.org>,
 <007601ccf024$25847b70$708d7250$@sberkman.net>
Message-ID: <C95B38A68C80744C8B371447DB6EE98C05B7BB@CSIT-SRV-MBX-01.charterschoolit.local>

This is perfect! In my situation, I have to deal with many single server at multiple locations instead of the opposite. This sure beats walking around with an LCD panel and keyboard...

-Mario Eirea
________________________________________
From: Scott Berkman [scott at sberkman.net]
Sent: Monday, February 20, 2012 6:05 PM
To: 'Jon Lewis'; 'Faisal Imtiaz'
Cc: nanog at nanog.org
Subject: RE: Laptop with reverse VGA

There are also these, work with anything with a USB port:

http://www.blackbox.com/Store/Detail.aspx/USB-Laptop-Console-Crash-Cart-Adap
ter/KVT100A

You could mate this with a cheap used Netbook too.

-----Original Message-----
From: Jon Lewis [mailto:jlewis at lewis.org]
Sent: Monday, February 20, 2012 5:05 PM
To: Faisal Imtiaz
Cc: nanog at nanog.org
Subject: Re: Laptop with reverse VGA

On Mon, 20 Feb 2012, Faisal Imtiaz wrote:

> Or if you can order one of these..... Exactly what you are looking for !!!
> http://store.earthlcd.com/LCD-Products/Portable-Monitors

That does look like pretty much exactly what I wanted...but a palm sized IP
KVM for less than half the price seems much more sensible and useful.
I'm already pushing for us to buy a few...and might even just buy a personal
one.  It just goes to show, sometimes you don't know what you're looking for
until you find it.

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________





From bonomi at mail.r-bonomi.com  Mon Feb 20 19:11:11 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Mon, 20 Feb 2012 19:11:11 -0600 (CST)
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <201202210111.q1L1BBLa001435@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Mon Feb 20 09:40:44 2012
> Date: Mon, 20 Feb 2012 10:34:58 -0500 (EST)
> From: Jon Lewis <jlewis at lewis.org>
> To: nanog at nanog.org
> Subject: Re: WW: Colo Vending Machine
>
> On Sat, 18 Feb 2012, John Osmon wrote:
>
> > At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
> > trash bin and stuck it on a spare crash cart.
> >
> > Then I fixed something while they were still looking for USB-Serial,
> > etc.
>
> Speaking of that sort of thing, I'd really LOVE if there were a device 
> about the size of a netbook that could be hooked up to otherwise headless 
> machines in colos that would give you keyboard, video & mouse.  i.e. a 
> folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know 
> there are folding rackmount versions of this (i.e. from Dell), but I want 
> something far more portable.  Twice in the past month, I'd had to drive 
> 100+ miles to a remote colo and took a full size flat panel monitor and 
> keyboard with me.  Has anyone actually built this yet?

You might want to look at "Lilliput Computer" offerings  
<http://www.lilliputweb.net>

Add an "Adesso Flexible compact keyboard"
<http://www.google.com/products/catalog?hl=en&cid=6658121900308964173>

And you're in the 'in a briefcase, or a backpack' range, and nearly in
the 'in a coat pocket' range.  

Not _exactly_ what you asked for -- it's two pieces, not one -- but close.


From smb at cs.columbia.edu  Mon Feb 20 19:40:33 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Mon, 20 Feb 2012 20:40:33 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F42E275.50608@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
Message-ID: <C404202E-DFED-4BC5-A411-2943698282CD@cs.columbia.edu>

> 
> 
>> The timer for Linux is 5 minute by default but you can change it.
> 
> Timer timeouts do not affect TCP MSS.
> 

RFC 2923:
      TCP should notice that the connection is timing out.  After
      several timeouts, TCP should attempt to send smaller packets,
      perhaps turning off the DF flag for each packet.  If this
      succeeds, it should continue to turn off PMTUD for the connection
      for some reasonable period of time, after which it should probe
      again to try to determine if the path has changed.

It's Informational, not standards track, but the problem -- and the fix
-- have been known for a very long time.


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From mysidia at gmail.com  Mon Feb 20 20:07:20 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Mon, 20 Feb 2012 20:07:20 -0600
Subject: Common operational misconceptions
In-Reply-To: <201202180719.q1I7JLIr062630@w6yx.stanford.edu>
References: <201202180719.q1I7JLIr062630@w6yx.stanford.edu>
Message-ID: <CAAAwwbWLXN+-ZUGKuLGORhe5_0GVU=T9nVYGXq4w6qLKnmRYCg@mail.gmail.com>

On Sat, Feb 18, 2012 at 1:19 AM, Bob Vaughan <techie at w6yx.stanford.edu> wrote:
> "Ethernet/Token Ring/Cisco Console/whatever uses an RJ45 connector"
> ?RJ45 defines a keyed 8P8C type connector, wired in a specific
> ?manner, for a specific 2 wire telco service. Incompatible with the
> ?above on several levels. ?"RJxx" == specific connector/wiring pattern
> ?for specific telco applications. Non-telco uses need not apply.

RJ45 is really an example of what was originally a misconception
became so widespread, so universal, that reality has actually shifted
so the misconception became reality.   When was the last time you ever
heard anyone say "8P8C connector?"

Joe public caught on to "RJ45",  so now that word means something
different in common usage than what it was specified to be.     When
was the last time you heard someone say 8P8C connector in reference to
Ethernet?

Nowadays it is technically ambiguous to say "RJ45";  are you talking about
[a] The original standard, Registered Jack 45,  which was a specific
connector together with a specific pinout   (which is not Ethernet
over UTP)?     Usage of the connector is exceedingly rare,  and will
hardly ever be referred to.

Or
[b] "Ethernet" connector; The generic 8P8C connector (which has a
certain resemblance to RJ 45) is specified for use with TIA/EIA 568
compliant cable termination ?


Now instead of [a]  being  correct and [b] being always the
misconception.....     [b] is "correct" in common usage.

And you have to decide based on context of the conversation which
defintion of RJ45 is intended,  but  [b] will almost always be the
correct definition.

--
-JH


From gbonser at seven.com  Mon Feb 20 20:11:03 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 21 Feb 2012 02:11:03 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F42E275.50608@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD73D1@RWC-MBX1.corp.seven.com>

> -----Original Message-----
> From: Masataka Ohta

> First, it sets eff_pmtu to 1400B. OK? 

Where did you get 1400 from?  Are you talking specifically with the linux implementation?  

"As eff_pmtu of 1400B is close enough to search_high, you are done."

I suppose that depends on a specific implementation of "close enough" is.  I haven't looked at the specific code linux uses to implement this and "close enough" is fairly subjective and can be interpreted in different ways by different people.  But even 1400 on, say, a 1420 MSS ICMP black hole is one heck of a lot better than running no PMTUD at all and running at something under 600 bytes.


> PS
> 
> Your lengthy quotation means you don't see the point.

I am wondering where you got this magic 1400 value from.  It should basically zero in on a number pretty close to the real path MSS in a few iterations.  Maybe that one specific implementation stops at the first successful value, but that isn't the way the recommendation is written.

Did I say it was "perfect"?  No, but the notion that PMTUD is "broken" or "doesn't work" isn't exactly true.  With the old mechanism, such a connection would simply hang or force people to turn off PMTUD completely.  The new mechanism actually seems to perform rather well in the face of an ICMP black hole.




From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 20:42:56 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 11:42:56 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD73D1@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD73D1@RWC-MBX1.corp.seven.com>
Message-ID: <4F4304B0.6020500@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

>> First, it sets eff_pmtu to 1400B. OK?
> 
> Where did you get 1400 from?

Read the RFC. PERIOD.

						Masataka Ohta


From gbonser at seven.com  Mon Feb 20 21:08:53 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 21 Feb 2012 03:08:53 +0000
Subject: Common operational misconceptions
In-Reply-To: <4F4304B0.6020500@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD73D1@RWC-MBX1.corp.seven.com>
 <4F4304B0.6020500@necom830.hpcl.titech.ac.jp>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CD7431@RWC-MBX1.corp.seven.com>

I, in fact, HAVE read the RFC.  

   The initial value for search_high SHOULD be the largest possible
   packet that might be supported by the flow.  This may be limited by
   the local interface MTU, by an explicit protocol mechanism such as
   the TCP MSS option, or by an intrinsic limit such as the size of a
   protocol length field.

So the initial probe would be the reported MSS of the remote system in this case 1460 which would fail.  I believe you might be getting confused by this paragraph:

   The general strategy is for the Packetization Layer to find an
   appropriate Path MTU by probing the path with progressively larger
   packets.  If a probe packet is successfully delivered, then the
   effective Path MTU is raised to the probe size.

And believing that as soon as a value is found that passes, the process stops.  That isn't the case.

   PLPMTUD uses a searching technique to find the Path MTU.  Each
   conclusive probe narrows the MTU search range, either by raising the
   lower limit on a successful probe or lowering the upper limit on a
   failed probe, converging toward the true Path MTU.  For most
   transport layers, the search should be stopped once the range is
   narrow enough that the benefit of a larger effective Path MTU is
   smaller than the search overhead of finding it.

The issue here is that the judgement of "once the range is narrow enough that the benefit of a larger effective Path MTU is smaller than the search overhead of finding it" and one might well argue that someone decided that the difference between 1400 and 1420 MSS (20 bytes) isn't worth the extra overhead of finding it those 20 bytes.  But in the case of a 7500 MTU and a 4500 MTU black hole link in between, it certainly does NOT go to 1400 and stay there.



> -----Original Message-----
> From: Masataka Ohta [mailto:mohta at necom830.hpcl.titech.ac.jp]
> Sent: Monday, February 20, 2012 6:43 PM
> To: George Bonser
> Cc: nanog at nanog.org
> Subject: Re: Common operational misconceptions
> 
> George Bonser wrote:
> 
> >> First, it sets eff_pmtu to 1400B. OK?
> >
> > Where did you get 1400 from?
> 
> Read the RFC. PERIOD.
> 
> 						Masataka Ohta


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 21:27:26 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 12:27:26 +0900
Subject: Common operational misconceptions
In-Reply-To: <C404202E-DFED-4BC5-A411-2943698282CD@cs.columbia.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <C404202E-DFED-4BC5-A411-2943698282CD@cs.columbia.edu>
Message-ID: <4F430F1E.7080208@necom830.hpcl.titech.ac.jp>

Steven Bellovin wrote:

>> Timer timeouts do not affect TCP MSS.

> RFC 2923:
>        TCP should notice that the connection is timing out.  After
>        several timeouts, TCP should attempt to send smaller packets,
>        perhaps turning off the DF flag for each packet.  If this
>        succeeds, it should continue to turn off PMTUD for the connection
>        for some reasonable period of time, after which it should probe
>        again to try to determine if the path has changed.

So?

> It's Informational, not standards track, but the problem
> -- and the fix -- have been known for a very long time.

I'm not sure what, do you think, is the problem, because the
paragraph of RFC2923 you quote has nothing to do with TCP
MSS.

The relevant section of the RFC (relevant to MSS) should be:

   The MSS should be determined based on the MTUs of the interfaces on
   the system, as outlined in [RFC1122] and [RFC1191].

which means MSS is constant.

Note also that the next paragraph (next to the paragraph you
quote) of the RFC eventually says to use PMTU of 1280B for
IPv6 if there are black holes. It is not a very good thing
to do especially for IP over IP tunnels, because 1280B
packets are always fragmented if they are carried over a
tunnel with MTU of 1280B.

As implosion cause by multicast PMTUD of IPv6 requires ICMP
PTB black holed, you can expect a lot of black holes.

					Masataka Ohta


From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 21:37:07 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 12:37:07 +0900
Subject: Common operational misconceptions
In-Reply-To: <596B74B410EE6B4CA8A30C3AF1A155EA09CD7431@RWC-MBX1.corp.seven.com>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD73D1@RWC-MBX1.corp.seven.com>
 <4F4304B0.6020500@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7431@RWC-MBX1.corp.seven.com>
Message-ID: <4F431163.9000104@necom830.hpcl.titech.ac.jp>

George Bonser wrote:

> I, in fact, HAVE read the RFC.

You don't, at all.

>     The initial value for search_high SHOULD be the largest possible
>     packet that might be supported by the flow.  This may be limited by
>     the local interface MTU, by an explicit protocol mechanism such as
>     the TCP MSS option, or by an intrinsic limit such as the size of a
>     protocol length field.

It is a section on "search_high", while your question in your
previous mail was on "eff_pmtu":

>> First, it sets eff_pmtu to 1400B. OK?
> Where did you get 1400 from?

Note that rest of your mail also contains a lot of
misunderstandings on the RFC. But, as you don't read
the RFC, collecting them is a waste of time.

Read the RFC thoroughly again and again, 10 times a day
for 30 days. Then, I may reply your further questions if
asked off list.

PERIOD.

					Masataka Ohta


From smb at cs.columbia.edu  Mon Feb 20 21:44:36 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Mon, 20 Feb 2012 22:44:36 -0500
Subject: Common operational misconceptions
In-Reply-To: <4F430F1E.7080208@necom830.hpcl.titech.ac.jp>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <C404202E-DFED-4BC5-A411-2943698282CD@cs.columbia.edu>
 <4F430F1E.7080208@necom830.hpcl.titech.ac.jp>
Message-ID: <2879F20F-A96E-433D-BB24-6C61AE46FE71@cs.columbia.edu>


On Feb 20, 2012, at 10:27 PM, Masataka Ohta wrote:

> Steven Bellovin wrote:
> 
>>> Timer timeouts do not affect TCP MSS.
> 
>> RFC 2923:
>>       TCP should notice that the connection is timing out.  After
>>       several timeouts, TCP should attempt to send smaller packets,
>>       perhaps turning off the DF flag for each packet.  If this
>>       succeeds, it should continue to turn off PMTUD for the connection
>>       for some reasonable period of time, after which it should probe
>>       again to try to determine if the path has changed.
> 
> So?
> 
>> It's Informational, not standards track, but the problem
>> -- and the fix -- have been known for a very long time.
> 
> I'm not sure what, do you think, is the problem, because the
> paragraph of RFC2923 you quote has nothing to do with TCP
> MSS.

Sure it does.  That's in 2.1; the start of it discusses PMTUD
failing for various reasons including firewalls.  
> 
> The relevant section of the RFC (relevant to MSS) should be:
> 
>   The MSS should be determined based on the MTUs of the interfaces on
>   the system, as outlined in [RFC1122] and [RFC1191].
> 
> which means MSS is constant.

The text I quoted says, in so many words, "send smaller packets".
I don't know how it's possible to be more explicit than that.
> 
> Note also that the next paragraph (next to the paragraph you
> quote) of the RFC eventually says to use PMTU of 1280B for
> IPv6 if there are black holes. It is not a very good thing
> to do especially for IP over IP tunnels, because 1280B
> packets are always fragmented if they are carried over a
> tunnel with MTU of 1280B.

Please cite in context.  The text I quoted says that one option
is to try turning off DF; the next paragraph notes that you can't
do that on v6.  It also doesn't say to to use PMTU of 1280, it
says that that's a good fallback, and notes that v6 support requires
that.  Although it doesn't say so, I'll note that IP in IP makes the
outer IP effectively a link layer for the inner IP; as such, it has
to preserve all of the relevant properties including a link MTU of
1280.  If that doesn't work -- though it most likely will, since
the most common hardware MTU is from the ancient 1500 byte Ethernet
size -- the outer IP endpoint has to deal with it appropriately,
such as by intentional fragmentation. just as is done for IP over
ATM with its 53-byte cell size (RFC 2225).
> 
> As implosion cause by multicast PMTUD of IPv6 requires ICMP
> PTB black holed, you can expect a lot of black holes.
> 
> 					Masataka Ohta
> 


		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From mohta at necom830.hpcl.titech.ac.jp  Mon Feb 20 22:01:59 2012
From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta)
Date: Tue, 21 Feb 2012 13:01:59 +0900
Subject: Common operational misconceptions
In-Reply-To: <2879F20F-A96E-433D-BB24-6C61AE46FE71@cs.columbia.edu>
References: <20120215144715.18e65a55@w520.localdomain>
 <CAJ0NkqhMpcrucK7twUYAX7FMzkF4ZoJX3cV5gLA36o5O-yBUJw@mail.gmail.com>
 <4F3DA93A.3060904@necom830.hpcl.titech.ac.jp>
 <BE94FC87-74BF-4791-95D4-2336C3298F79@delong.com>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CCF9BA@RWC-MBX1.corp.seven.com>
 <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD0318@RWC-MBX1.corp.seven.com>
 <4F41EB70.3080401@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD6CC2@RWC-MBX1.corp.seven.com>
 <4F42CEE4.3030800@necom830.hpcl.titech.ac.jp>
 <596B74B410EE6B4CA8A30C3AF1A155EA09CD7264@RWC-MBX1.corp.seven.com>
 <4F42E275.50608@necom830.hpcl.titech.ac.jp>
 <C404202E-DFED-4BC5-A411-2943698282CD@cs.columbia.edu>
 <4F430F1E.7080208@necom830.hpcl.titech.ac.jp>
 <2879F20F-A96E-433D-BB24-6C61AE46FE71@cs.columbia.edu>
Message-ID: <4F431737.6000508@necom830.hpcl.titech.ac.jp>

Steven Bellovin wrote:

>> I'm not sure what, do you think, is the problem, because the
>> paragraph of RFC2923 you quote has nothing to do with TCP
>> MSS.
> 
> Sure it does.  That's in 2.1; the start of it discusses PMTUD
> failing for various reasons including firewalls.

Firewalls?

Though I have never assumed existence of firewalls, if you are
saying IPv6 will be even less operational because of firewalls,
I have no counter argument.

> The text I quoted says, in so many words, "send smaller packets".
> I don't know how it's possible to be more explicit than that.

No disagreement.

I have been keep saying that IPv6 can't depend on PMTUD and
must send packets of 1280B or less.

It's George Bonser, not me, who said there were other ways.

> Please cite in context.  The text I quoted says that one option
> is to try turning off DF; the next paragraph notes that you can't
> do that on v6.

I thought the context is whether IPv6 is operational or not.

Or, is it whether PMTUDv4 operational or not?

Or, is your problem completely different from the above two?

Your clarification is helpful

					Masataka Ohta




From rsm at fast-serv.com  Mon Feb 20 22:10:54 2012
From: rsm at fast-serv.com (Randy McAnally)
Date: Mon, 20 Feb 2012 23:10:54 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
Message-ID: <34791872-6752-4623-9814-7D786491F4BF@fast-serv.com>

Cage nuts.

Sent from my IPhone (pardon the typo's)

On Feb 17, 2012, at 1:35 PM, Jay Ashworth <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth                  Baylink                       jra at baylink.com
> Designer                     The Things I Think                       RFC 2100
> Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
> St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From chaim.rieger at gmail.com  Tue Feb 21 00:16:28 2012
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Mon, 20 Feb 2012 22:16:28 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <34791872-6752-4623-9814-7D786491F4BF@fast-serv.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <34791872-6752-4623-9814-7D786491F4BF@fast-serv.com>
Message-ID: <f60d0e4a-7f6f-494c-bea6-81b740295297@email.android.com>

Apple stickers 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Randy McAnally <rsm at fast-serv.com> wrote:

Cage nuts.

Sent from my IPhone (pardon the typo's)

On Feb 17, 2012, at 1:35 PM, Jay Ashworth <jra at baylink.com> wrote:

> Please post your top 3 favorite components/parts you'd like to see in a
> vending machine at your colo; please be as specific as possible; don't 
> let vendor specificity scare you off.
> 
> Cheers,
> -- jra
> -- 
> Jay R. Ashworth Baylink jra at baylink.com
> Designer The Things I Think RFC 2100
> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
> St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274


From tim.connolly at farecompare.com  Tue Feb 21 00:23:56 2012
From: tim.connolly at farecompare.com (Tim Connolly (FC))
Date: Tue, 21 Feb 2012 00:23:56 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <f60d0e4a-7f6f-494c-bea6-81b740295297@email.android.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <34791872-6752-4623-9814-7D786491F4BF@fast-serv.com>
 <f60d0e4a-7f6f-494c-bea6-81b740295297@email.android.com>
Message-ID: <AF54746A-A9B8-4AD4-88A3-B30659C538E3@farecompare.com>

1. A blow-up mattress and pillow set.
2. A magic wand
3. A highly caffeinated Noc-Tech


> On Feb 17, 2012, at 1:35 PM, Jay Ashworth <jra at baylink.com> wrote:
> 
>> Please post your top 3 favorite components/parts you'd like to see in a
>> vending machine at your colo; please be as specific as possible; don't 
>> let vendor specificity scare you off.
>> 
>> Cheers,
>> -- jra
>> -- 
>> Jay R. Ashworth Baylink jra at baylink.com
>> Designer The Things I Think RFC 2100
>> Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
>> St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
> 



Tim Connolly
Director of IT


-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3719 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120221/d2268596/attachment-0001.gif>
-------------- next part --------------


Web: www.farecompare.com



From davidj at mckendrick.ca  Tue Feb 21 01:54:04 2012
From: davidj at mckendrick.ca (David)
Date: Mon, 20 Feb 2012 23:54:04 -0800
Subject: Single-port Network "KVM"
In-Reply-To: <4F42B5A2.4050502@rollernet.us>
References: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
 <4F42B5A2.4050502@rollernet.us>
Message-ID: <4F434D9C.1010102@mckendrick.ca>

Spider kvms come well recommended and it's what I see being used around
the datacenter often.
Prefer them vs. the bulkier ones I've used in the past.

web/java is supported, as is VNC -- the latter of which makes them very
usable.
On 02/20/2012 01:05 PM, Seth Mattinen wrote:
> On 2/20/12 12:05 PM, Jay Ashworth wrote:
>> Here's one example; cheapest I've seen:
>>
>> http://www.kvm-switches-online.com/0su51068.html
>>
>> There are others.  This one appears to be web/java based rather than VNC,
>> though that probably isn't a killer for most people.
>>
>> I thought I'd seen a little dongle-y model; I'll look around a bit more.
>>
>
> A past thread also mentioned OpenGear:
>
> http://opengear.com/product-IP-KVM.html
>
> I'd been eying this one, but the $199 Lantronix seems like a price point
> too good to pass up.
>
> ~Seth
>


-- 
David
Follow me @davidandgoliath



From owen at delong.com  Tue Feb 21 03:50:15 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Feb 2012 01:50:15 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <8D4C50BE-08C0-4F26-B640-E89AC20E1BB2@delong.com>


On Feb 20, 2012, at 7:34 AM, Jon Lewis wrote:

> On Sat, 18 Feb 2012, John Osmon wrote:
> 
>> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
>> trash bin and stuck it on a spare crash cart.
>> 
>> Then I fixed something while they were still looking for USB-Serial,
>> etc.
> 
> Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video & mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive 100+ miles to a remote colo and took a full size flat panel monitor and keyboard with me.  Has anyone actually built this yet?
> 

Actually, everything necessary to do that is present in the new Macbook Pros with Thunderbolt.

It would just take a dongle with the VGA input and the USB outputs and some minor changes to "Target Display Mode" Software.

Owen



From owen at delong.com  Tue Feb 21 03:51:12 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Feb 2012 01:51:12 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <ED78B1C68B84A14FA706D13A230D7B431941AFD0@ITS-MAIL01.campus.ad.csulb.edu>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <ED78B1C68B84A14FA706D13A230D7B431941AFD0@ITS-MAIL01.campus.ad.csulb.edu>
Message-ID: <E027C725-BC39-45D7-BA99-D25AABBC7FD1@delong.com>

+1 for Raritan... I was very happy with their KVM switches at my last job.

Owen

On Feb 20, 2012, at 7:40 AM, Matthew Black wrote:

> Take a look at Raritan. We use their product to gain remote access to system consoles. No more driving 100s of miles. Ok, it would be 200 feet for us.
> 
> 
> matthew black
> information technology services bh-188
> california state university, long beach
> 
> -----Original Message-----
> From: Jon Lewis [mailto:jlewis at lewis.org] 
> Sent: Monday, February 20, 2012 7:35 AM
> To: nanog at nanog.org
> Subject: Re: WW: Colo Vending Machine
> 
> On Sat, 18 Feb 2012, John Osmon wrote:
> 
>> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the 
>> trash bin and stuck it on a spare crash cart.
>> 
>> Then I fixed something while they were still looking for USB-Serial, 
>> etc.
> 
> Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video & mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive 
> 100+ miles to a remote colo and took a full size flat panel monitor and
> keyboard with me.  Has anyone actually built this yet?
> 
> ----------------------------------------------------------------------
>  Jon Lewis, MCP :)           |  I route
>  Senior Network Engineer     |  therefore you are
>  Atlantic Net                |
> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
> 
> 
> 



From lowen at pari.edu  Tue Feb 21 06:24:17 2012
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 21 Feb 2012 07:24:17 -0500
Subject: Common operational misconceptions
In-Reply-To: <CAAAwwbWLXN+-ZUGKuLGORhe5_0GVU=T9nVYGXq4w6qLKnmRYCg@mail.gmail.com>
References: <201202180719.q1I7JLIr062630@w6yx.stanford.edu>
Message-ID: <201202210724.17554.lowen@pari.edu>

On Monday, February 20, 2012 09:07:20 PM Jimmy Hess wrote:
> RJ45 is really an example of what was originally a misconception
> became so widespread, so universal, that reality has actually shifted
> so the misconception became reality.   When was the last time you ever
> heard anyone say "8P8C connector?"

And then there's the 10C variant used on some serial port interfaces (like those from Equinox)..... 

'8 pin modular plug' is reasonable, though, and is what I'll typically say, with the modifier 'for stranded' or 'for solid' conductors, as it does make a difference.  I haven't said 'RJ45 plug' in years.

Yeah, it's a bummer that the keyed RJ45 plug got genericized to the unkeyed variant; at least the unkeyed plug used for TIA568A/B will work in a true RJ45 jack.....  


From bonomi at mail.r-bonomi.com  Tue Feb 21 06:46:44 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Tue, 21 Feb 2012 06:46:44 -0600 (CST)
Subject: Common operational misconceptions
In-Reply-To: <201202210724.17554.lowen@pari.edu>
Message-ID: <201202211246.q1LCkiOG008405@mail.r-bonomi.com>


Lamar Owen <lowen at pari.edu> wrote:
>
> On Monday, February 20, 2012 09:07:20 PM Jimmy Hess wrote:
> > RJ45 is really an example of what was originally a misconception
> > became so widespread, so universal, that reality has actually shifted
> > so the misconception became reality.   When was the last time you ever
> > heard anyone say "8P8C connector?"
>
> And then there's the 10C variant used on some serial port interfaces (like 
> those from Equinox)..... 

At least "RJ45-X" is still unambiguus.  <wry grin>



From doctorchd at gmail.com  Tue Feb 21 07:04:03 2012
From: doctorchd at gmail.com (Dmitry Cherkasov)
Date: Tue, 21 Feb 2012 15:04:03 +0200
Subject: Single-port Network "KVM"
In-Reply-To: <29102431.164.1329768519273.JavaMail.root@benjamin.baylink.com>
References: <30245088.162.1329768316593.JavaMail.root@benjamin.baylink.com>
 <29102431.164.1329768519273.JavaMail.root@benjamin.baylink.com>
Message-ID: <CAP5kh1CQa1kTGONtFjs9viK07oA0CH_2yTFzvc-mZkejhCis+A@mail.gmail.com>

Not exactly what was asked originally but consider using Dell
PowerEdge servers with Enterprise iDRAC component. You get nice IP-KVM
+ power switch. This adds around $300 to the overall server price.
BTW, looks like this iDRAC is implemented on the base of Avocent gear
which is one of the best in IP-KVMs.
I'm completely satisfied using iDRACs in a number of servers.

Just my $0.05.


Dmitry Cherkasov



2012/2/20 Jay Ashworth <jra at baylink.com>:
> ----- Original Message -----
>> From: "Jay Ashworth" <jra at baylink.com>
>
>> There are others. This one appears to be web/java based rather than VNC,
>> though that probably isn't a killer for most people.
>>
>> I thought I'd seen a little dongle-y model; I'll look around a bit
>> more.
>
> Didn't read far enough; Jussi Peltola posted this downthread:
>
> http://www.lantronix.com/it-management/kvm-over-ip/securelinx-spiderduo.html
>
> That's the item I wanted, and it's only $200. ?And Lantronix' support
> department is arguably the best hardware vendor support organization I
> have *ever* worked with.
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth ? ? ? ? ? ? ? ? ?Baylink ? ? ? ? ? ? ? ? ? ? ? jra at baylink.com
> Designer ? ? ? ? ? ? ? ? ? ? The Things I Think ? ? ? ? ? ? ? ? ? ? ? RFC 2100
> Ashworth & Associates ? ? http://baylink.pitas.com ? ? ? ? 2000 Land Rover DII
> St Petersburg FL USA ? ? ?http://photo.imageinc.us ? ? ? ? ? ? +1 727 647 1274
>


From bhmccie at gmail.com  Tue Feb 21 07:57:02 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Tue, 21 Feb 2012 07:57:02 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <E027C725-BC39-45D7-BA99-D25AABBC7FD1@delong.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <ED78B1C68B84A14FA706D13A230D7B431941AFD0@ITS-MAIL01.campus.ad.csulb.edu>
 <E027C725-BC39-45D7-BA99-D25AABBC7FD1@delong.com>
Message-ID: <4F43A2AE.10906@gmail.com>

Can someone give me a link or part number on the Raritan site? I see LCD 
consoles but they are the generic slide out versions. Looking for the 
netbook concept referenced below....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/21/2012 3:51 AM, Owen DeLong wrote:
> +1 for Raritan... I was very happy with their KVM switches at my last job.
>
> Owen
>
> On Feb 20, 2012, at 7:40 AM, Matthew Black wrote:
>
>> Take a look at Raritan. We use their product to gain remote access to system consoles. No more driving 100s of miles. Ok, it would be 200 feet for us.
>>
>>
>> matthew black
>> information technology services bh-188
>> california state university, long beach
>>
>> -----Original Message-----
>> From: Jon Lewis [mailto:jlewis at lewis.org]
>> Sent: Monday, February 20, 2012 7:35 AM
>> To: nanog at nanog.org
>> Subject: Re: WW: Colo Vending Machine
>>
>> On Sat, 18 Feb 2012, John Osmon wrote:
>>
>>> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
>>> trash bin and stuck it on a spare crash cart.
>>>
>>> Then I fixed something while they were still looking for USB-Serial,
>>> etc.
>> Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video&  mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive
>> 100+ miles to a remote colo and took a full size flat panel monitor and
>> keyboard with me.  Has anyone actually built this yet?
>>
>> ----------------------------------------------------------------------
>>   Jon Lewis, MCP :)           |  I route
>>   Senior Network Engineer     |  therefore you are
>>   Atlantic Net                |
>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>>
>>
>>
>
>


From nanog at vanwesten.net  Tue Feb 21 08:32:04 2012
From: nanog at vanwesten.net (nanog)
Date: Tue, 21 Feb 2012 15:32:04 +0100
Subject: Common operational misconceptions
In-Reply-To: <20120215144715.18e65a55@w520.localdomain>
References: <20120215144715.18e65a55@w520.localdomain>
Message-ID: <4F43AAE4.8070104@vanwesten.net>

Op 15-2-2012 21:47, John Kristoff schreef:
> 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
>
Haven't seen this one yet:

"TCP/IP is based on the osi model."

Erik van Westen.


From josmon at rigozsaurus.com  Tue Feb 21 08:42:24 2012
From: josmon at rigozsaurus.com (John Osmon)
Date: Tue, 21 Feb 2012 07:42:24 -0700
Subject: WW: Colo Vending Machine
In-Reply-To: <f60d0e4a-7f6f-494c-bea6-81b740295297@email.android.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <34791872-6752-4623-9814-7D786491F4BF@fast-serv.com>
 <f60d0e4a-7f6f-494c-bea6-81b740295297@email.android.com>
Message-ID: <20120221144224.GA16981@jeeves.rigozsaurus.com>

On Mon, Feb 20, 2012 at 10:16:28PM -0800, Chaim Rieger wrote:
> Apple stickers 

I've got half a sheet of NeXT stickers left.  Is that a reasonable
substitute?


From jra at baylink.com  Tue Feb 21 08:48:21 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 21 Feb 2012 09:48:21 -0500 (EST)
Subject: Laptop with reverse VGA
In-Reply-To: <1329781166.24342.6.camel@Decaf.NEEBU.Net>
Message-ID: <21481184.381.1329835701027.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jake Khuon" <khuon at neebu.net>

> I think the form-factour is already there. I have a Motorola Atrix
> smartphone. It's available with a laptop-dock unit. This is
> essentially a USB hub and display. The display is connected by
> outputting from the phone's HDMI port. The rest of the input/output
> device (keyboard and trackpad) are seen as USB connected devices and
> interfaced via the phone's USB port (Atrix supports USB host mode).
> 
> Essentially, this laptop dock is what people are talking about except
> for a generic host instead of for a phone. We would want to expose the
> HDMI input generically and probably with an additional VGA input. Of
> course there are also VGA-HDMI converters. Anyone wanna ring up
> Motorola to see if they're interesting in adapting the Atrix
> laptop-dock technology? 

As someone who's done video for 20 years, I can tell you, Jake: 

It ain't that easy.

The interface on the Atrix is purpose-built, and it's almost certainly
just a DVI/HDMI digital interface to a panel that expects that.

What's necessary for a standalone KVM of the sort we're talking about
is what the video people call a "genlock" circuit -- most machines that
need this at all have analog VGA out, and you have to have a chip that
can lock up to it, and extract the video from that analog signal cleanly.

This is, to quote the Jargon file, decidedly non-trivial to do well.

That's the reason why a single port unit, not on sale, is generally around
$400.  If it was DVI/HDMI *only*, it could be substantially cheaper, but
I've never seen one that was.

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


From jra at baylink.com  Tue Feb 21 08:56:21 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 21 Feb 2012 09:56:21 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <CAAAwwbWLXN+-ZUGKuLGORhe5_0GVU=T9nVYGXq4w6qLKnmRYCg@mail.gmail.com>
Message-ID: <15342324.393.1329836181561.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Jimmy Hess" <mysidia at gmail.com>

> RJ45 is really an example of what was originally a misconception
> became so widespread, so universal, that reality has actually shifted
> so the misconception became reality. When was the last time you ever
> heard anyone say "8P8C connector?"
> 
> Joe public caught on to "RJ45", so now that word means something
> different in common usage than what it was specified to be. When
> was the last time you heard someone say 8P8C connector in reference to
> Ethernet?

WADR: horseshit.

I, in fact, just wrote a cabling RFQ yesterday for a new building, and
*I* write "8P8C male modular connector".  So, in short: if you *actually
need to be saying it*, you actually need to be saying it correctly, because
you're talking to people who know the difference.

They won't say anything, mind you, and you'll get what you want; they'll
just think you're a clueless dilettante.

Cheers,
-- jr 'yes, I'm a prescriptivist[1]' a

[1] The *point* of language is communication; this is impossible if
words "mean what people want them to mean, no more, no less".
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


From owen at delong.com  Tue Feb 21 09:59:59 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Feb 2012 07:59:59 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F43A2AE.10906@gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <ED78B1C68B84A14FA706D13A230D7B431941AFD0@ITS-MAIL01.campus.ad.csulb.edu>
 <E027C725-BC39-45D7-BA99-D25AABBC7FD1@delong.com> <4F43A2AE.10906@gmail.com>
Message-ID: <4B224621-7940-4584-B956-DCCB86F1C5C9@delong.com>

http://www.raritan.com/products/kvm-over-ip/

Owen

On Feb 21, 2012, at 5:57 AM, -Hammer- wrote:

> Can someone give me a link or part number on the Raritan site? I see LCD consoles but they are the generic slide out versions. Looking for the netbook concept referenced below....
> 
> -Hammer-
> 
> "I was a normal American nerd"
> -Jack Herer
> 
> 
> 
> On 2/21/2012 3:51 AM, Owen DeLong wrote:
>> +1 for Raritan... I was very happy with their KVM switches at my last job.
>> 
>> Owen
>> 
>> On Feb 20, 2012, at 7:40 AM, Matthew Black wrote:
>> 
>>> Take a look at Raritan. We use their product to gain remote access to system consoles. No more driving 100s of miles. Ok, it would be 200 feet for us.
>>> 
>>> 
>>> matthew black
>>> information technology services bh-188
>>> california state university, long beach
>>> 
>>> -----Original Message-----
>>> From: Jon Lewis [mailto:jlewis at lewis.org]
>>> Sent: Monday, February 20, 2012 7:35 AM
>>> To: nanog at nanog.org
>>> Subject: Re: WW: Colo Vending Machine
>>> 
>>> On Sat, 18 Feb 2012, John Osmon wrote:
>>> 
>>>> At my $JOB[-1] they laughed at me when I pulled a Wyse out of the
>>>> trash bin and stuck it on a spare crash cart.
>>>> 
>>>> Then I fixed something while they were still looking for USB-Serial,
>>>> etc.
>>> Speaking of that sort of thing, I'd really LOVE if there were a device about the size of a netbook that could be hooked up to otherwise headless machines in colos that would give you keyboard, video&  mouse.  i.e. a folding netbook shaped VGA monitor with USB keyboard and touchpad.  I know there are folding rackmount versions of this (i.e. from Dell), but I want something far more portable.  Twice in the past month, I'd had to drive
>>> 100+ miles to a remote colo and took a full size flat panel monitor and
>>> keyboard with me.  Has anyone actually built this yet?
>>> 
>>> ----------------------------------------------------------------------
>>>  Jon Lewis, MCP :)           |  I route
>>>  Senior Network Engineer     |  therefore you are
>>>  Atlantic Net                |
>>> _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
>>> 
>>> 
>>> 
>> 
>> 



From ekim.ittag at gmail.com  Tue Feb 21 10:31:27 2012
From: ekim.ittag at gmail.com (Mike Gatti)
Date: Tue, 21 Feb 2012 08:31:27 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <CAG367gYi6yk3Fbx6v7ESxZT5H7cUA6bSfB8V=qS4NHiYEmJctg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <20120217185558.GB96943@ussenterprise.ufp.org>
 <CAG367gYi6yk3Fbx6v7ESxZT5H7cUA6bSfB8V=qS4NHiYEmJctg@mail.gmail.com>
Message-ID: <A1F2C57F-9382-4B27-9FC9-39E8871989B4@gmail.com>

The Trendnet TU-S9 (works on 32 and 64bit), it uses the prolific chip and it's pretty cheap, making it fit for a vending machine. 
Trendnet could actually use the Franks Hot Sauce commercial on TV to advertise, 
the one that the old lady says "I put that s$@t on everything". 

P.S.: I don't work for trendnet :)

--
Michael Gatti  
main. 949.371.5474
(UTC -8)



On Feb 17, 2012, at 10:59 AM, Bryan Irvine wrote:

> On Fri, Feb 17, 2012 at 10:55 AM, Leo Bicknell <bicknell at ufp.org> wrote:
>> In a message written on Fri, Feb 17, 2012 at 01:35:15PM -0500, Jay Ashworth wrote:
>>> Please post your top 3 favorite components/parts you'd like to see in a
>>> vending machine at your colo; please be as specific as possible; don't
>>> let vendor specificity scare you off.
>> 
>> USB->Serial adapters.  Preferably selected so they are driverless on
>> both OSX and Windows. :)
> 
> The trick is to look for one that works on OpenBSD.  If it works
> there, it will work on Windows, Mac, and Linux.  YMMV. :-)
> 



From ekim.ittag at gmail.com  Tue Feb 21 10:39:59 2012
From: ekim.ittag at gmail.com (Mike Gatti)
Date: Tue, 21 Feb 2012 08:39:59 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F3EB353.10708@alter3d.ca>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
 <4F3EB353.10708@alter3d.ca>
Message-ID: <F23D8063-3356-48A2-8481-4928082D613D@gmail.com>

The 30lb sledge hammer should be in the parking lot in a enclosure with a front glass that reads "Break in case of extreme frustration" right next to the dumpster for recycling hardware. 
You could make a living just with that business, replacing the front glass. 

--
Michael Gatti  
main. 949.371.5474
(UTC -8)



On Feb 17, 2012, at 12:06 PM, Peter Kristolaitis wrote:

> On 12-02-17 03:05 PM, Leigh Porter wrote:
>> Did anybody say beer yet?
>> 
> 
> Don't forget the 30lb sledgehammer for those times when, ah, "percussive maintenance" is the only possible solution.  ;)
> 
> (Might be a bit hard to fit into a vending machine though... maybe the colo staff could just rent one out...)
> 
> - Pete
> 
> 



From ido at oasis-tech.net  Tue Feb 21 10:46:10 2012
From: ido at oasis-tech.net (Ido Szargel)
Date: Tue, 21 Feb 2012 18:46:10 +0200
Subject: IX in France
In-Reply-To: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
Message-ID: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>

Hi All,

 

We are currently looking to connect to one of the IX's available in Paris,

It seems that there are 2 "major" players - FranceIX and Equinix FR, can
anyone share their opinions about those?

 

Thanks,

Ido

 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6073 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120221/20f13710/attachment.bin>

From jared at puck.nether.net  Tue Feb 21 10:53:53 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 21 Feb 2012 11:53:53 -0500
Subject: IX in France
In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
Message-ID: <3701294F-E15E-4D46-AF68-13E746753850@puck.nether.net>


On Feb 21, 2012, at 11:46 AM, Ido Szargel wrote:

> Hi All,
> 
> We are currently looking to connect to one of the IX's available in Paris,
> 
> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
> anyone share their opinions about those?

At my former employer we connected to PARIX and don't recall any issues there.

www.parix.net (seems to be down right now).

- Jared






From rmaunier at neotelecoms.com  Tue Feb 21 11:04:08 2012
From: rmaunier at neotelecoms.com (Raphael MAUNIER)
Date: Tue, 21 Feb 2012 17:04:08 +0000
Subject: IX in France
In-Reply-To: <3701294F-E15E-4D46-AF68-13E746753850@puck.nether.net>
Message-ID: <CB698B3A.7C989%rmaunier@neotelecoms.com>

Hello,

In Paris you have Equinix Paris, Sfinx and FranceIX. I'm the co founder of
Franceix with 2 other folks, so I know well the subject :)
Franceix is a neutral IXP, and based on an association model ( exactly the
same model as Amsix ).

Today FranceIX is the biggest one in Paris and is located in all carrier
hotel in Paris ( except Equinix )  and also in Marseille.
There is some gateway with other IXP : Sfinx, Lyonix and Lucix (
Luxembourg ).

Both EquinixFR and Franceix have a partner program and you can connect to
both using a third partner ( or of course directly ).

You can have more information here : https://www.franceix.net/ or send an
email to info at franceix.net

Regards,
--
Rapha?l Maunier
NEO TELECOMS
CTO / Directeur Ing?nierie
AS8218





On 2/21/12 5:53 PM, "Jared Mauch" <jared at puck.nether.net> wrote:

>
>On Feb 21, 2012, at 11:46 AM, Ido Szargel wrote:
>
>> Hi All,
>> 
>> We are currently looking to connect to one of the IX's available in
>>Paris,
>> 
>> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
>> anyone share their opinions about those?
>
>At my former employer we connected to PARIX and don't recall any issues
>there.
>
>www.parix.net (seems to be down right now).
>
>- Jared
>
>
>
>
>



From neil at tonal.clara.co.uk  Tue Feb 21 11:19:10 2012
From: neil at tonal.clara.co.uk (Neil Harris)
Date: Tue, 21 Feb 2012 17:19:10 +0000
Subject: Laptop with reverse VGA
In-Reply-To: <21481184.381.1329835701027.JavaMail.root@benjamin.baylink.com>
References: <21481184.381.1329835701027.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F43D20E.3040703@tonal.clara.co.uk>

On 21/02/12 14:48, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Jake Khuon"<khuon at neebu.net>
>> I think the form-factour is already there. I have a Motorola Atrix
>> smartphone. It's available with a laptop-dock unit. This is
>> essentially a USB hub and display. The display is connected by
>> outputting from the phone's HDMI port. The rest of the input/output
>> device (keyboard and trackpad) are seen as USB connected devices and
>> interfaced via the phone's USB port (Atrix supports USB host mode).
>>
>> Essentially, this laptop dock is what people are talking about except
>> for a generic host instead of for a phone. We would want to expose the
>> HDMI input generically and probably with an additional VGA input. Of
>> course there are also VGA-HDMI converters. Anyone wanna ring up
>> Motorola to see if they're interesting in adapting the Atrix
>> laptop-dock technology?
> As someone who's done video for 20 years, I can tell you, Jake:
>
> It ain't that easy.
>
> The interface on the Atrix is purpose-built, and it's almost certainly
> just a DVI/HDMI digital interface to a panel that expects that.
>
> What's necessary for a standalone KVM of the sort we're talking about
> is what the video people call a "genlock" circuit -- most machines that
> need this at all have analog VGA out, and you have to have a chip that
> can lock up to it, and extract the video from that analog signal cleanly.
>
> This is, to quote the Jargon file, decidedly non-trivial to do well.
>
> That's the reason why a single port unit, not on sale, is generally around
> $400.  If it was DVI/HDMI *only*, it could be substantially cheaper, but
> I've never seen one that was.
>
> Cheers,
> - jra

High prices are more likely to do with the small market for such 
devices, than to do with the cost of the underlying technology.

It isn't so much genlock, as accurate pixel clock recovery, that's the 
hard thing.

It is indeed hard to do well, but fortunately the chipmakers have done 
all that for you.  It's a common enough need (think flat panel monitors) 
that there are inexpensive single-chip solutions for it that not only do 
the A/D conversion, but handle the pixel clock recovery for you as well: 
see, for example, the Analog Devices AD9884A or ADV7441A.

Data sheets at 
http://www.analog.com/en/audiovideo-products/analoghdmidvi-interfaces/ad9884a/products/product.html 
and 
http://www.analog.com/en/analog-to-digital-converters/video-decoders/adv7441a/products/product.html 
respectively.

-- Neil



From jra at baylink.com  Tue Feb 21 11:45:02 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 21 Feb 2012 12:45:02 -0500 (EST)
Subject: Laptop with reverse VGA
In-Reply-To: <4F43D20E.3040703@tonal.clara.co.uk>
Message-ID: <12654917.483.1329846302426.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Neil Harris" <neil at tonal.clara.co.uk>

> High prices are more likely to do with the small market for such
> devices, than to do with the cost of the underlying technology.

Sure.  Not being on the consumer part of the S-curve will kill you.

> It isn't so much genlock, as accurate pixel clock recovery, that's the
> hard thing.

That's the fundamental component of genlock, I think, isn't it?

> It is indeed hard to do well, but fortunately the chipmakers have done
> all that for you. It's a common enough need (think flat panel monitors)
> that there are inexpensive single-chip solutions for it that not only
> do the A/D conversion, but handle the pixel clock recovery for you as
> well: see, for example, the Analog Devices AD9884A or ADV7441A.

Yeah; I knew (or was pretty sure) that it was down to the chip level at
this point, but as you say, for driving the price down, there's nothing
like the single-chip solution, and this is apparently just far enough
off the edge of the popularity curve that it's not in any single-chip 
solutions (that I know of, and board-level hardware isn't really my game).

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


From pelzi at pelzi.net  Tue Feb 21 15:08:51 2012
From: pelzi at pelzi.net (Jussi Peltola)
Date: Tue, 21 Feb 2012 23:08:51 +0200
Subject: Laptop with reverse VGA
In-Reply-To: <12654917.483.1329846302426.JavaMail.root@benjamin.baylink.com>
References: <4F43D20E.3040703@tonal.clara.co.uk>
 <12654917.483.1329846302426.JavaMail.root@benjamin.baylink.com>
Message-ID: <20120221210851.GN22186@pokute.pelzi.net>

On Tue, Feb 21, 2012 at 12:45:02PM -0500, Jay Ashworth wrote:
> Yeah; I knew (or was pretty sure) that it was down to the chip level at
> this point, but as you say, for driving the price down, there's nothing
> like the single-chip solution, and this is apparently just far enough
> off the edge of the popularity curve that it's not in any single-chip 
> solutions (that I know of, and board-level hardware isn't really my game).
 
Practically all desktop LCDs do have a single chip that eats VGA and
outputs LVDS. All you would need is a suitable ROM with modelines for it
to work with a laptop screen. But these parts run hot and come in
gigantic TQFP packages (when compared to the form factor of ICs in
laptops.)

Making a replacement card that fits in a laptop instead of the
motherboard is quite possible. Sadly, I have neither the time nor the
motivation since I already have a SpiderDuo :)


From laurent at guerby.net  Tue Feb 21 15:25:04 2012
From: laurent at guerby.net (Laurent GUERBY)
Date: Tue, 21 Feb 2012 22:25:04 +0100
Subject: IX in France
In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
Message-ID: <1329859504.3397.532.camel@pc2>

On Tue, 2012-02-21 at 18:46 +0200, Ido Szargel wrote:
> Hi All,
> 
>  
> 
> We are currently looking to connect to one of the IX's available in Paris,
> 
> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
> anyone share their opinions about those?

Hi,

We're connected to both (and to a smaller third one named FR-IX), it's
not that expensive and adds redundancy to join many peers.

Sincerely,

Laurent



From morrowc.lists at gmail.com  Tue Feb 21 16:05:39 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Tue, 21 Feb 2012 17:05:39 -0500
Subject: DNS Attacks
In-Reply-To: <4F42B488.2090903@bogus.com>
References: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <201202191614.q1JGEjsE088170@mail.r-bonomi.com>
 <CAMhuimj6QLwtqiJYesxoH13PCoLK+Sb1ohRvH27HCDfmOjZJkw@mail.gmail.com>
 <CACg3zYFe3dtUP08dE-GaQ89peHpmMTW0rfsA1rB3Hb6HnOP5bA@mail.gmail.com>
 <CAL9jLaaYJUDoeWqUCrzXLGn0PXecrrCSHvij0JeLJhAYkDgJFA@mail.gmail.com>
 <4F42B488.2090903@bogus.com>
Message-ID: <CAL9jLaaLHn3BP19XCU-uKbZ_-1TT7N5EXkSGaQ54XYQPVC2+Jw@mail.gmail.com>

On Mon, Feb 20, 2012 at 4:00 PM, Joel jaeggli <joelja at bogus.com> wrote:

> be assigned again, so a static filter policy will return to bite us
> again like it always does.

sure, so you are saying there's a timelimit on how long the supposed
ISP can run this infrastructure... and that they have until then to
lower their loss rate(s) when customers are cutoff and call their
support center because: "The Intertubes are down!".

sounds accurate to me... of course, they've already been getting
notifications of infected folks, so hopefully they have a jump on the
problem already? :)

it's wishful thinking monday!
-chris


From mysidia at gmail.com  Tue Feb 21 16:29:04 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 21 Feb 2012 16:29:04 -0600
Subject: DNS Attacks
In-Reply-To: <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
Message-ID: <CAAAwwbUW5B6qJjHejGpDPOtixjSGQEHGCZj=5njJ+AsiGFEU7A@mail.gmail.com>

On Sun, Feb 19, 2012 at 4:59 AM, Ken Gilmour <ken.gilmour at gmail.com> wrote:
> What happens when the client sends a POST from a cached page on the end
> user's machine? E.g. if they post login credentials. Of course, they'll get
> the error page, but then you have confidential data in your logs and now
> you have to protect highly confidential info, at least if you're in europe.

Either you don't log the data on the webserver,  or you notify the
user that the POST form data has now been posted, and display the link
to the public web page where their posted data now appears, on the
error page.

Once your user has shared "confidential" information unsolicited with
an unknown third party, and the general public,   the information's
confidentiality was spoiled by the act of posting, regardless of the
content of the information

-- 
-JH


From jwininger at ifncom.net  Tue Feb 21 16:58:19 2012
From: jwininger at ifncom.net (James Wininger)
Date: Tue, 21 Feb 2012 17:58:19 -0500
Subject: Customer Notification System.
Message-ID: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>

We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
us). We have a need for a customer notification system. We have simply
out grown the ability to send emails to our customers manually. We need
to have a better way of notifying our customers of maintenance etc.

 

We would need to send notifications out to say about 400 customers.
Ideally the system would send an attached PDF. It would be great if this
system were SQL based etc.

 

Does anyone know of a system that is out there that does this? We have
looked at a few applications (windows based) but integration with
billing etc seems to be a caveat. I have thought of possibly using a
mailing list type approach, but that gets us back to (almost) where we
are today. Any pointers would be greatly appreciated. 

 

--

Jim Wininger

jwininger at ifncom.net

 


From davidj at mckendrick.ca  Tue Feb 21 17:00:13 2012
From: davidj at mckendrick.ca (David)
Date: Tue, 21 Feb 2012 15:00:13 -0800
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <4F4421FD.1020206@mckendrick.ca>

PHPList?

On 02/21/2012 02:58 PM, James Wininger wrote:
> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
>
>  
>
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.
>
>  
>
> Does anyone know of a system that is out there that does this? We have
> looked at a few applications (windows based) but integration with
> billing etc seems to be a caveat. I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. Any pointers would be greatly appreciated. 
>
>  
>
> --
>
> Jim Wininger
>
> jwininger at ifncom.net
>
>  
>


-- 
David
Follow me @davidandgoliath



From bstengel at kinber.org  Tue Feb 21 17:03:40 2012
From: bstengel at kinber.org (Brian Stengel)
Date: Tue, 21 Feb 2012 18:03:40 -0500
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <CABLLS=MAcNvbum4TRvO15kDK+tQvg8Og3wwrQhwAd8qQO69F1g@mail.gmail.com>

http://www.varolii.com/

On Tue, Feb 21, 2012 at 5:58 PM, James Wininger <jwininger at ifncom.net>wrote:

> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
>
>
>
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.
>
>
>
> Does anyone know of a system that is out there that does this? We have
> looked at a few applications (windows based) but integration with
> billing etc seems to be a caveat. I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. Any pointers would be greatly appreciated.
>
>
>
> --
>
> Jim Wininger
>
> jwininger at ifncom.net
>
>
>
>


-- 
Brian Stengel
KINBER Director of Operations
bstengel at kinber.org
412.254.3481
Skype: brian_stengel

KINBER - Keystone Initiative for Network Based Education and Research -
www.kinber.org
PennREN - Pennsylvania's Research and Education Network

From dwhite at olp.net  Tue Feb 21 17:05:17 2012
From: dwhite at olp.net (Dan White)
Date: Tue, 21 Feb 2012 17:05:17 -0600
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <20120221230517.GL4588@dan.olp.net>

We use Mailchimp to relay emails to our customers. They have the ability to
maintain lists of customer addresses, and I believe they have an API for
maintaining the list.

On 02/21/12?17:58?-0500, James Wininger wrote:
>We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
>us). We have a need for a customer notification system. We have simply
>out grown the ability to send emails to our customers manually. We need
>to have a better way of notifying our customers of maintenance etc.
>
>
>
>We would need to send notifications out to say about 400 customers.
>Ideally the system would send an attached PDF. It would be great if this
>system were SQL based etc.
>
>
>
>Does anyone know of a system that is out there that does this? We have
>looked at a few applications (windows based) but integration with
>billing etc seems to be a caveat. I have thought of possibly using a
>mailing list type approach, but that gets us back to (almost) where we
>are today. Any pointers would be greatly appreciated.
>
>
>
>--
>
>Jim Wininger
>
>jwininger at ifncom.net
>
>
>
>

-- 
Dan White


From tompipes at corp.skybeam.com  Tue Feb 21 17:07:22 2012
From: tompipes at corp.skybeam.com (Tom Pipes)
Date: Tue, 21 Feb 2012 17:07:22 -0600
Subject: Customer Notification System.
In-Reply-To: <1127e0dfbaac47b397aa78457801df15@mail1.jabbroadband.local>
References: <1127e0dfbaac47b397aa78457801df15@mail1.jabbroadband.local>
Message-ID: <CAM+5HniCKYRCN9bkvWpG_M4T1F46dNvDyiOAptWb200cB5tccg@mail.gmail.com>

Not sure if you have a customer database/spreadsheet and what OS platform
you use, but this product has served us well in the past:

http://www.massmailsoftware.com/bulkmail/

Tom Pipes
tom.pipes at t6mail.com


On Tue, Feb 21, 2012 at 4:58 PM, James Wininger <jwininger at ifncom.net>wrote:

> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
>
>
>
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.
>
>
>
> Does anyone know of a system that is out there that does this? We have
> looked at a few applications (windows based) but integration with
> billing etc seems to be a caveat. I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. Any pointers would be greatly appreciated.
>
>
>
> --
>
> Jim Wininger
>
> jwininger at ifncom.net
>
>
>
>

From Valdis.Kletnieks at vt.edu  Tue Feb 21 17:15:04 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 21 Feb 2012 18:15:04 -0500
Subject: DNS Attacks
In-Reply-To: Your message of "Tue, 21 Feb 2012 16:29:04 CST."
 <CAAAwwbUW5B6qJjHejGpDPOtixjSGQEHGCZj=5njJ+AsiGFEU7A@mail.gmail.com>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <CAAAwwbUW5B6qJjHejGpDPOtixjSGQEHGCZj=5njJ+AsiGFEU7A@mail.gmail.com>
Message-ID: <23411.1329866104@turing-police.cc.vt.edu>

On Tue, 21 Feb 2012 16:29:04 CST, Jimmy Hess said:
> Once your user has shared "confidential" information unsolicited with
> an unknown third party, and the general public,   the information's
> confidentiality was spoiled by the act of posting, regardless of the
> content of the information

I see lawyers booking their vacations in Tahiti now.....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120221/f8164e4a/attachment.bin>

From alex at aleach.com  Tue Feb 21 17:23:27 2012
From: alex at aleach.com (Alex Leach)
Date: Tue, 21 Feb 2012 17:23:27 -0600
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <CAKnPn=730NNCf8VpbT3iuZgHFtKUfjitbWHK637n8Hq2pPAUcQ@mail.gmail.com>

Billing software that caters to smaller web hosts and ISPs like WHMCS
can send out mass mailings, and you can drill down which customers
should receive the email based on the services they have with you.



On Tue, Feb 21, 2012 at 4:58 PM, James Wininger <jwininger at ifncom.net> wrote:
> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
>
>
>
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.
>
>
>
> Does anyone know of a system that is out there that does this? We have
> looked at a few applications (windows based) but integration with
> billing etc seems to be a caveat. I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. Any pointers would be greatly appreciated.
>
>
>
> --
>
> Jim Wininger
>
> jwininger at ifncom.net
>
>
>


From lanning at lanning.cc  Tue Feb 21 18:07:10 2012
From: lanning at lanning.cc (Robert Hajime Lanning)
Date: Tue, 21 Feb 2012 16:07:10 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <F23D8063-3356-48A2-8481-4928082D613D@gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
 <4F3EB353.10708@alter3d.ca> <F23D8063-3356-48A2-8481-4928082D613D@gmail.com>
Message-ID: <4F4431AE.5040205@lanning.cc>

PC LOAD LETTER?!?!?!?!?

On 02/21/12 08:39, Mike Gatti wrote:
> The 30lb sledge hammer should be in the parking lot in a
> enclosure with a front glass that reads "Break in case of
> extreme frustration" right next to the dumpster for
> recycling hardware.
>
> You could make a living just with that business,
> replacing the front glass.
> 

-- 
Mr. Flibble
King of the Potato People


From mysidia at gmail.com  Tue Feb 21 20:06:10 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Tue, 21 Feb 2012 20:06:10 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAEmG1=p43Zr9ZADS-KB7zkEC6gY-xZ+SWnOh8WwioEJr40RUgg@mail.gmail.com>
Message-ID: <CAAAwwbWnEaAnfGKrvmOEU+Sz7RPTgDy712A9vOZic5rbrxoGAw@mail.gmail.com>

On Mon, Feb 20, 2012 at 10:54 AM, Matthew Petach <mpetach at netflight.com> wrote:

> Seeing as how most laptops have a VGA connector
> and a keyboard/mouse connector on them, albeit
> wired in the wrong direction (VGA connector feeds

I see that Epiphan makes a   $400 KVM2USB dongle.

http://www.epiphan.com/pdf/products_brochures/KVM2USB_brochure.pdf

--
-JH


From hrlinneweh at sbcglobal.net  Tue Feb 21 20:17:22 2012
From: hrlinneweh at sbcglobal.net (Henry Linneweh)
Date: Tue, 21 Feb 2012 18:17:22 -0800 (PST)
Subject: DNS Attacks
In-Reply-To: <23411.1329866104@turing-police.cc.vt.edu>
References: <4F401B13.3060202@opus1.com>
 <201202182229.q1IMTHGS079581@mail.r-bonomi.com>
 <CAMhuimisRngM_0si_fdWRhcxA-YOMASyzi4XHm-zOE-_uM0+2Q@mail.gmail.com>
 <CAAAwwbUW5B6qJjHejGpDPOtixjSGQEHGCZj=5njJ+AsiGFEU7A@mail.gmail.com>
 <23411.1329866104@turing-police.cc.vt.edu>
Message-ID: <1329877042.68802.YahooMailNeo@web180309.mail.gq1.yahoo.com>



Here is a repeat
http://www.theregister.co.uk/2012/02/16/ghost_domains_dns_vuln/

-henry
________________________________
From: "Valdis.Kletnieks at vt.edu" <Valdis.Kletnieks at vt.edu>
To: Jimmy Hess <mysidia at gmail.com> 
Cc: nanog at nanog.org 
Sent: Tuesday, February 21, 2012 3:15 PM
Subject: Re: DNS Attacks

On Tue, 21 Feb 2012 16:29:04 CST, Jimmy Hess said:
> Once your user has shared "confidential" information unsolicited with
> an unknown third party, and the general public,???the information's
> confidentiality was spoiled by the act of posting, regardless of the
> content of the information

I see lawyers booking their vacations in Tahiti now.....

From graham at apolix.co.za  Tue Feb 21 21:19:18 2012
From: graham at apolix.co.za (Graham Beneke)
Date: Wed, 22 Feb 2012 05:19:18 +0200
Subject: Customer Notification System.
In-Reply-To: <4F4421FD.1020206@mckendrick.ca>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F4421FD.1020206@mckendrick.ca>
Message-ID: <4F445EB6.3040100@apolix.co.za>

On 22/02/2012 01:00, David wrote:
> PHPList?

We've been using PHPlist for a while but have also been searching for 
something that can do a 'network noticeboard' type of thing.

Haven't really come up with anything useful yet.

-- 
Graham Beneke


From asr at latency.net  Tue Feb 21 21:39:13 2012
From: asr at latency.net (Adam Rothschild)
Date: Tue, 21 Feb 2012 22:39:13 -0500
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <CAPZUUwVJQKkBcJAJXmaq3c=h_Uvkq5UpmJV0+w=ME6n0+G8BRg@mail.gmail.com>

On Tue, Feb 21, 2012 at 5:58 PM, James Wininger <jwininger at ifncom.net> wrote:
> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.

Seconding the earlier recommendation, mailchimp is a great tool.  Good
interface aside, there is strong operational benefit to being able to
issue notices completely "out of band".

> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF [...]

If you're going to do this, please be sure to send a copy of the
notice inline as plain text too.  Your customers on smartphones, using
assistive technology, or automatically piping vendor notices into
calendaring/ticketing systems will thank you.  :-)

HTH,
-a


From paul4004 at gmail.com  Tue Feb 21 22:22:11 2012
From: paul4004 at gmail.com (PC)
Date: Tue, 21 Feb 2012 21:22:11 -0700
Subject: WW: Colo Vending Machine
In-Reply-To: <4F4431AE.5040205@lanning.cc>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4644DDFD-287D-4885-8800-0C18486F0B7A@ukbroadband.com>
 <4F3EB353.10708@alter3d.ca>
 <F23D8063-3356-48A2-8481-4928082D613D@gmail.com>
 <4F4431AE.5040205@lanning.cc>
Message-ID: <CAJAdsD=990SSmoZsKmgAkYAKan9N8oDL5c=7pCNU--ZEnf9=dQ@mail.gmail.com>

Back in college we had a fund raiser as a club where we laid out a bunch of
computer parts and a sledgehammer.  We charged by the swing.  It was Office
Space style fun.

It's profitability far exceeded our expectations.



On Tue, Feb 21, 2012 at 5:07 PM, Robert Hajime Lanning
<lanning at lanning.cc>wrote:

> PC LOAD LETTER?!?!?!?!?
>
> On 02/21/12 08:39, Mike Gatti wrote:
> > The 30lb sledge hammer should be in the parking lot in a
> > enclosure with a front glass that reads "Break in case of
> > extreme frustration" right next to the dumpster for
> > recycling hardware.
> >
> > You could make a living just with that business,
> > replacing the front glass.
> >
>
> --
> Mr. Flibble
> King of the Potato People
>
>

From jra at baylink.com  Tue Feb 21 22:24:05 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 21 Feb 2012 23:24:05 -0500 (EST)
Subject: WW: Colo Vending Machine
In-Reply-To: <4F4431AE.5040205@lanning.cc>
Message-ID: <25397165.620.1329884645026.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Robert Hajime Lanning" <lanning at lanning.cc>
> On 02/21/12 08:39, Mike Gatti wrote:
> > The 30lb sledge hammer should be in the parking lot in a
> > enclosure with a front glass that reads "Break in case of
> > extreme frustration" right next to the dumpster for
> > recycling hardware.
> >
> > You could make a living just with that business,
> > replacing the front glass.
>
> PC LOAD LETTER?!?!?!?!?

I prefer OUT OF CHEESE myself.

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


From jra at baylink.com  Tue Feb 21 22:26:04 2012
From: jra at baylink.com (Jay Ashworth)
Date: Tue, 21 Feb 2012 23:26:04 -0500 (EST)
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <425710.622.1329884764548.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "James Wininger" <jwininger at ifncom.net>

> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
> 
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if
> this system were SQL based etc.

I will reply much more strongly than the other poster did:

*USE ASCII*.

If you sent me a scheduled maintenance window notice as a PDF attached to
an empty email, I'd drop you for a competitor.

But then, I'm a $CUSSWORD about such things.

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


From owen at delong.com  Wed Feb 22 00:15:42 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 21 Feb 2012 22:15:42 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <25397165.620.1329884645026.JavaMail.root@benjamin.baylink.com>
References: <25397165.620.1329884645026.JavaMail.root@benjamin.baylink.com>
Message-ID: <FE142D0A-CF83-42D4-A4BE-D070FC9E987B@delong.com>


On Feb 21, 2012, at 8:24 PM, Jay Ashworth wrote:

> ----- Original Message -----
>> From: "Robert Hajime Lanning" <lanning at lanning.cc>
>> On 02/21/12 08:39, Mike Gatti wrote:
>>> The 30lb sledge hammer should be in the parking lot in a
>>> enclosure with a front glass that reads "Break in case of
>>> extreme frustration" right next to the dumpster for
>>> recycling hardware.
>>> 
>>> You could make a living just with that business,
>>> replacing the front glass.
>> 
>> PC LOAD LETTER?!?!?!?!?
> 
> I prefer OUT OF CHEESE myself.

Allright... Which one of you jokers stole my red stapler?

Owen



From o.calvano at gmail.com  Wed Feb 22 01:53:04 2012
From: o.calvano at gmail.com (Olivier CALVANO)
Date: Wed, 22 Feb 2012 08:53:04 +0100
Subject: IX in France
In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
Message-ID: <CAJajPeff+1eTTiVw4MTbyzrPOkqAVNke9tY7kcMG06pCB=jOJw@mail.gmail.com>

Hi

For me the best choice is FranceIX.

We are connected to Sfinx, FranceIX and Equinix, but 70% of our
peering traffic are sent on FranceIX.

Panap and Parix is dead

Best Regards
Olivier


Le 21 f?vrier 2012 17:46, Ido Szargel <ido at oasis-tech.net> a ?crit :
> Hi All,
>
>
>
> We are currently looking to connect to one of the IX's available in Paris,
>
> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
> anyone share their opinions about those?
>
>
>
> Thanks,
>
> Ido
>
>
>


From tim at pelican.org  Wed Feb 22 04:02:01 2012
From: tim at pelican.org (Tim Franklin)
Date: Wed, 22 Feb 2012 10:02:01 -0000 (GMT)
Subject: WW: Colo Vending Machine
In-Reply-To: <4F4431AE.5040205@lanning.cc>
Message-ID: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>

> PC LOAD LETTER?!?!?!?!?

PC LOAD LETTER is not the issue.

One country that insists on using different paper sizes to everyone else, but also happens to set a lot of hardware and software defaults is the issue :(


From rsk at gsp.org  Wed Feb 22 05:01:24 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Wed, 22 Feb 2012 06:01:24 -0500
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <20120222110124.GA24779@gsp.org>

On Tue, Feb 21, 2012 at 05:58:19PM -0500, James Wininger wrote:
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.

(a) Use ASCII.  Using PDF for this is insane.

(b) You're dealing with only 400 customers, yet you want the overhead
and complexity of a SQL-capable database?  Do you also engage a fleet
of bulldozers when you want to plant a flower in the back yard?

> I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. 

Precisely what is wrong with a "mailing list type approach", using
Mailman (which is the best available and what runs this list)?  It handles
COI (mandatory for responsible and ethical operation of all mailing lists),
it runs on all varieties of 'nix, it plays nice with MTAs, it deals with
most bounces in a sane fashion, etc.

---rsk


From leigh.porter at ukbroadband.com  Wed Feb 22 05:26:33 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 22 Feb 2012 11:26:33 +0000
Subject: Customer Notification System.
In-Reply-To: <20120222110124.GA24779@gsp.org>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <20120222110124.GA24779@gsp.org>
Message-ID: <D181DDABABE57E4DB72FEE00331478644B5B92@EALPO1.ukbroadband.com>



> -----Original Message-----
> From: Rich Kulawiec [mailto:rsk at gsp.org]
> Sent: 22 February 2012 11:04
> To: nanog at nanog.org
> Subject: Re: Customer Notification System.
> 
> On Tue, Feb 21, 2012 at 05:58:19PM -0500, James Wininger wrote:
> > We would need to send notifications out to say about 400 customers.
> > Ideally the system would send an attached PDF. It would be great if
> > this system were SQL based etc.
> 
> (a) Use ASCII.  Using PDF for this is insane.
> 
> (b) You're dealing with only 400 customers, yet you want the overhead
> and complexity of a SQL-capable database?  Do you also engage a fleet
> of bulldozers when you want to plant a flower in the back yard?
> 
> > I have thought of possibly using a
> > mailing list type approach, but that gets us back to (almost) where
> we
> > are today.
> 
> Precisely what is wrong with a "mailing list type approach", using
> Mailman (which is the best available and what runs this list)?  It
> handles COI (mandatory for responsible and ethical operation of all
> mailing lists), it runs on all varieties of 'nix, it plays nice with
> MTAs, it deals with most bounces in a sane fashion, etc.

Yeah please don't use PDF. There is nothing more annoying than getting an email about something important that had a PDF attachment to tell you about the important things. Lowest common denominator!

I used to use mailman for this, but we had a CRM system as well which was database driven. So I write a script to grab the right email addresses from the database every night and populate mailman. 

--
Leigh




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


From CAsensio at nexica.com  Wed Feb 22 05:53:04 2012
From: CAsensio at nexica.com (Carlos Asensio)
Date: Wed, 22 Feb 2012 12:53:04 +0100
Subject: Cisco CAT6500 IOS Simulator
Message-ID: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>

Hi there,

Anyone know a way of simulate a Cisco CAT6500 IOS?

We're trying to deploy a lab of our production environment.

Thanks in advance,
Carlos.

From mysidia at gmail.com  Wed Feb 22 08:03:32 2012
From: mysidia at gmail.com (Jimmy Hess)
Date: Wed, 22 Feb 2012 08:03:32 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
References: <4F4431AE.5040205@lanning.cc>
 <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
Message-ID: <CAAAwwbXXKVnvppB2ONwL0YDxJkV_h4_1haAw9Q2aPDAR-mtCAQ@mail.gmail.com>

On Wed, Feb 22, 2012 at 4:02 AM, Tim Franklin <tim at pelican.org> wrote:
>> PC LOAD LETTER?!?!?!?!?
> PC LOAD LETTER is not the issue.
> One country that insists on using different paper sizes to everyone else, but also happens to set a lot of hardware and software defaults is the issue :(

LC LOAD A4
then.


--
-JH


From jack at bonyari.com  Wed Feb 22 09:02:35 2012
From: jack at bonyari.com (Jack Morgan)
Date: Wed, 22 Feb 2012 07:02:35 -0800
Subject: FCoE Deployment
Message-ID: <4F45038B.7090005@bonyari.com>

Does anyone know of any company or organization deploying FCoE[1] in a
production environment? I'm curious how widely adopted this technology is.


[1] http://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
    http://fcoe.com/


Thanks,

-- 
Jack Morgan



From tore.anderson at redpill-linpro.com  Wed Feb 22 09:14:17 2012
From: tore.anderson at redpill-linpro.com (Tore Anderson)
Date: Wed, 22 Feb 2012 16:14:17 +0100
Subject: FCoE Deployment
In-Reply-To: <4F45038B.7090005@bonyari.com>
References: <4F45038B.7090005@bonyari.com>
Message-ID: <4F450649.5050302@redpill-linpro.com>

* Jack Morgan

> Does anyone know of any company or organization deploying FCoE[1] in
> a production environment? I'm curious how widely adopted this
> technology is.

FCoE was until very recently the only way to do centralized block
storage to the Cisco UCS server blades, so I'd imagine it's quite widely
adopted. That said, we don't run FCoE outside of the UCS ?black box? -
its uplinks to the SAN are just regular FC.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com


From nanog at rsle.net  Wed Feb 22 09:34:32 2012
From: nanog at rsle.net (R. Scott Evans)
Date: Wed, 22 Feb 2012 10:34:32 -0500
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <c7309109466e4b15b7e9528ad9a9a412@rsle.net>

What, no programmers in your NOC to roll your own?

---
#!/usr/bin/perl

use DBI;

# define variables ($sendmail, $from, $database... etc)

$dbh = DBI->connect("DBI:mysql:$database:$server", $user, $pass);
$mysearch = $dbh->prepare("SELECT customer,cid,email FROM $table WHERE
$find);
$mysearch->execute;

while (($customer,$cid,$email) = $mysearch->fetchrow_array) {
	open(MAIL, "| $sendmail -t");
	print MAIL "From: $from\n";
	print MAIL "To: $email\n";
	print MAIL "Subject: $subject\n\n";
	print MAIL "$customer,\nYour circuit $cid is going down bla bla bla.";
	close(MAIL);
}
$dbh->disconnect;
---

** NOTE - this is off the top of my head, ie.. not tested.  That said,
it's more or less a simplified version of what we do. 

-Scott

On Tue, 21 Feb 2012 17:58:19 -0500, "James Wininger"
<jwininger at ifncom.net> wrote:
> We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> us). We have a need for a customer notification system. We have simply
> out grown the ability to send emails to our customers manually. We need
> to have a better way of notifying our customers of maintenance etc.
> 
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF. It would be great if this
> system were SQL based etc.
> 
> Does anyone know of a system that is out there that does this? We have
> looked at a few applications (windows based) but integration with
> billing etc seems to be a caveat. I have thought of possibly using a
> mailing list type approach, but that gets us back to (almost) where we
> are today. Any pointers would be greatly appreciated. 
> 
> --
> Jim Wininger
> jwininger at ifncom.net


From CAsensio at nexica.com  Wed Feb 22 09:36:47 2012
From: CAsensio at nexica.com (Carlos Asensio)
Date: Wed, 22 Feb 2012 16:36:47 +0100
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
Message-ID: <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>

Hi John,

Thanks for your answer but, as far as I know, with GNS3 we can't run a CAT6500 IOS.

Any alternative?

Cheers,
Carlos.


-----Mensaje original-----
De: John Kreno [mailto:john.kreno at gmail.com] 
Enviado el: mi?rcoles, 22 de febrero de 2012 15:25
Para: Carlos Asensio
Asunto: Re: Cisco CAT6500 IOS Simulator

Try GNS 3


On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio <CAsensio at nexica.com> wrote:
> Hi there,
>
> Anyone know a way of simulate a Cisco CAT6500 IOS?
>
> We're trying to deploy a lab of our production environment.
>
> Thanks in advance,
> Carlos.



-- 
John Kreno

"Those who would sacrifice essential liberties for a little temporary
safety deserve neither liberty nor safety." - Ben Franklin


From nick at foobar.org  Wed Feb 22 09:41:08 2012
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 22 Feb 2012 15:41:08 +0000
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
Message-ID: <4F450C94.8050905@foobar.org>

On 22/02/2012 15:36, Carlos Asensio wrote:
> Any alternative?

Ebay.

Nick


From CAsensio at nexica.com  Wed Feb 22 09:46:27 2012
From: CAsensio at nexica.com (Carlos Asensio)
Date: Wed, 22 Feb 2012 16:46:27 +0100
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <4F450C94.8050905@foobar.org>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
 <4F450C94.8050905@foobar.org>
Message-ID: <FCF4EA853883E348957567CD9E90E97301D3D26101@vnxbcnex01.bcn.nexica.com>

Hi Nick,

Thanks for your answer. We'll take it into proper consideration.

Any other alternatives?

Cheers,
Carlos.

-----Mensaje original-----
De: Nick Hilliard [mailto:nick at foobar.org] 
Enviado el: mi?rcoles, 22 de febrero de 2012 16:41
Para: nanog at nanog.org
Asunto: Re: Cisco CAT6500 IOS Simulator

On 22/02/2012 15:36, Carlos Asensio wrote:
> Any alternative?

Ebay.

Nick



From hank at efes.iucc.ac.il  Wed Feb 22 09:48:23 2012
From: hank at efes.iucc.ac.il (Hank Nussbacher)
Date: Wed, 22 Feb 2012 17:48:23 +0200 (IST)
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
Message-ID: <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>

On Wed, 22 Feb 2012, Carlos Asensio wrote:

Not supported:
http://www.gns3.net/hardware-emulated/

-Hank

> Hi John,
>
> Thanks for your answer but, as far as I know, with GNS3 we can't run a CAT6500 IOS.
>
> Any alternative?
>
> Cheers,
> Carlos.
>
>
> -----Mensaje original-----
> De: John Kreno [mailto:john.kreno at gmail.com]
> Enviado el: mi?rcoles, 22 de febrero de 2012 15:25
> Para: Carlos Asensio
> Asunto: Re: Cisco CAT6500 IOS Simulator
>
> Try GNS 3
>
>
> On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio <CAsensio at nexica.com> wrote:
>> Hi there,
>>
>> Anyone know a way of simulate a Cisco CAT6500 IOS?
>>
>> We're trying to deploy a lab of our production environment.
>>
>> Thanks in advance,
>> Carlos.
>
>
>
>

From owen at delong.com  Wed Feb 22 09:50:10 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 22 Feb 2012 07:50:10 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
References: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
Message-ID: <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>


On Feb 22, 2012, at 2:02 AM, Tim Franklin wrote:

>> PC LOAD LETTER?!?!?!?!?
> 
> PC LOAD LETTER is not the issue.
> 
> One country that insists on using different paper sizes to everyone else, but also happens to set a lot of hardware and software defaults is the issue :(

While there is some truth to this, in reality, if everyone else would just use 8.5" x 11", then, the US would no longer be different. :p

Owen



From bhmccie at gmail.com  Wed Feb 22 09:55:44 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Wed, 22 Feb 2012 09:55:44 -0600
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
 <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>
Message-ID: <4F451000.2020107@gmail.com>

NO.

There is no method. Go to Ebay and buy one. Sorry. Or if you are a big 
enough customer you can ask Cisco to mock up your solution in one of 
their labs.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/22/2012 9:48 AM, Hank Nussbacher wrote:
> On Wed, 22 Feb 2012, Carlos Asensio wrote:
>
> Not supported:
> http://www.gns3.net/hardware-emulated/
>
> -Hank
>
>> Hi John,
>>
>> Thanks for your answer but, as far as I know, with GNS3 we can't run 
>> a CAT6500 IOS.
>>
>> Any alternative?
>>
>> Cheers,
>> Carlos.
>>
>>
>> -----Mensaje original-----
>> De: John Kreno [mailto:john.kreno at gmail.com]
>> Enviado el: mi?rcoles, 22 de febrero de 2012 15:25
>> Para: Carlos Asensio
>> Asunto: Re: Cisco CAT6500 IOS Simulator
>>
>> Try GNS 3
>>
>>
>> On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio <CAsensio at nexica.com> 
>> wrote:
>>> Hi there,
>>>
>>> Anyone know a way of simulate a Cisco CAT6500 IOS?
>>>
>>> We're trying to deploy a lab of our production environment.
>>>
>>> Thanks in advance,
>>> Carlos.
>>
>>
>>
>>


From drohan at gmail.com  Wed Feb 22 10:00:13 2012
From: drohan at gmail.com (Daniel Rohan)
Date: Wed, 22 Feb 2012 19:00:13 +0300
Subject: Customer Notification System.
In-Reply-To: <c7309109466e4b15b7e9528ad9a9a412@rsle.net>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <c7309109466e4b15b7e9528ad9a9a412@rsle.net>
Message-ID: <CAJXc8RKk7-puwUYyc6=beQDuHo+=2-orFLLsqNByTbEJCQbztA@mail.gmail.com>

On Feb 22, 2012 6:35 PM, "R. Scott Evans" <nanog at rsle.net> wrote:

> ** NOTE - this is off the top of my head, ie.. not tested.  That said,
> it's more or less a simplified version of what we do.
>

whoa. best humble brag I've seen in a few weeks, Scott. And that's saying a
lot considering this is NANOG.
 On Feb 22, 2012 6:35 PM, "R. Scott Evans" <nanog at rsle.net> wrote:

> What, no programmers in your NOC to roll your own?
>
> ---
> #!/usr/bin/perl
>
> use DBI;
>
> # define variables ($sendmail, $from, $database... etc)
>
> $dbh = DBI->connect("DBI:mysql:$database:$server", $user, $pass);
> $mysearch = $dbh->prepare("SELECT customer,cid,email FROM $table WHERE
> $find);
> $mysearch->execute;
>
> while (($customer,$cid,$email) = $mysearch->fetchrow_array) {
>        open(MAIL, "| $sendmail -t");
>        print MAIL "From: $from\n";
>        print MAIL "To: $email\n";
>        print MAIL "Subject: $subject\n\n";
>        print MAIL "$customer,\nYour circuit $cid is going down bla bla
> bla.";
>        close(MAIL);
> }
> $dbh->disconnect;
> ---
>
> ** NOTE - this is off the top of my head, ie.. not tested.  That said,
> it's more or less a simplified version of what we do.
>
> -Scott
>
> On Tue, 21 Feb 2012 17:58:19 -0500, "James Wininger"
> <jwininger at ifncom.net> wrote:
> > We are a smaller ISP in Indiana. We are growing quite rapidly (yeah for
> > us). We have a need for a customer notification system. We have simply
> > out grown the ability to send emails to our customers manually. We need
> > to have a better way of notifying our customers of maintenance etc.
> >
> > We would need to send notifications out to say about 400 customers.
> > Ideally the system would send an attached PDF. It would be great if this
> > system were SQL based etc.
> >
> > Does anyone know of a system that is out there that does this? We have
> > looked at a few applications (windows based) but integration with
> > billing etc seems to be a caveat. I have thought of possibly using a
> > mailing list type approach, but that gets us back to (almost) where we
> > are today. Any pointers would be greatly appreciated.
> >
> > --
> > Jim Wininger
> > jwininger at ifncom.net
>
>

From chaim.rieger at gmail.com  Wed Feb 22 10:03:38 2012
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Wed, 22 Feb 2012 08:03:38 -0800
Subject: FCoE Deployment
In-Reply-To: <4F45038B.7090005@bonyari.com>
References: <4F45038B.7090005@bonyari.com>
Message-ID: <4F4511DA.7080701@gmail.com>

On 2/22/2012 7:02 AM, Jack Morgan wrote:
> Does anyone know of any company or organization deploying FCoE[1] in a
> production environment? I'm curious how widely adopted this technology is.
>
>
> [1] http://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
>      http://fcoe.com/
>
>
> Thanks,
>
I do
what would you like to know


From nick at foobar.org  Wed Feb 22 10:06:40 2012
From: nick at foobar.org (Nick Hilliard)
Date: Wed, 22 Feb 2012 16:06:40 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
References: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
 <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
Message-ID: <4F451290.2020408@foobar.org>

On 22/02/2012 15:50, Owen DeLong wrote:
> While there is some truth to this, in reality, if everyone else would
> just use 8.5" x 11", then, the US would no longer be different. :p

There are still two other countries in the world which only use imperial
measurements: Burma and Liberia.  I can see you're proud to be part of this
illustrious club.

Nick


From joelja at bogus.com  Wed Feb 22 10:09:47 2012
From: joelja at bogus.com (Joel jaeggli)
Date: Wed, 22 Feb 2012 08:09:47 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
References: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
 <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
Message-ID: <4F45134B.7010808@bogus.com>

On 2/22/12 07:50 , Owen DeLong wrote:
> 
> On Feb 22, 2012, at 2:02 AM, Tim Franklin wrote:
> 
>>> PC LOAD LETTER?!?!?!?!?
>>
>> PC LOAD LETTER is not the issue.
>>
>> One country that insists on using different paper sizes to everyone else, but also happens to set a lot of hardware and software defaults is the issue :(
> 
> While there is some truth to this, in reality, if everyone else would just use 8.5" x 11", then, the US would no longer be different. :p

If we just stop printing things the problem goes away.

> Owen
> 
> 
> 



From gary.buhrmaster at gmail.com  Wed Feb 22 10:34:06 2012
From: gary.buhrmaster at gmail.com (Gary Buhrmaster)
Date: Wed, 22 Feb 2012 08:34:06 -0800
Subject: WW: Colo Vending Machine
In-Reply-To: <4F45134B.7010808@bogus.com>
References: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
 <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
 <4F45134B.7010808@bogus.com>
Message-ID: <CAMfXtQxN=_PNfu_uZYGcH6PwM0MqB=M5bTufu2jGneUNEAWk4w@mail.gmail.com>

On Wed, Feb 22, 2012 at 08:09, Joel jaeggli <joelja at bogus.com> wrote:
...
> If we just stop printing things the problem goes away.

I think Xerox promised me a paperless office
(starting in the 1980s?).  I am still waiting.


From jcdill.lists at gmail.com  Wed Feb 22 10:34:49 2012
From: jcdill.lists at gmail.com (JC Dill)
Date: Wed, 22 Feb 2012 08:34:49 -0800
Subject: Customer Notification System.
In-Reply-To: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
Message-ID: <4F451929.8030407@gmail.com>

On 21/02/12 2:58 PM, James Wininger wrote:
>
> We would need to send notifications out to say about 400 customers.
> Ideally the system would send an attached PDF.

Why are you sending an attachment?

I hate it when businesses think that they will somehow improve my 
reading experience by bloating up the email, sending attachments, etc.  
What about if I'm reading email on my phone?  In what way does providing 
the information in a PDF benefit ME?

99.999% of the time there is absolutely no benefit in the attachment.  
But by pushing customers to open attachments to get the content we are 
encouraging them to be complacent about opening all attachments, and 
that's a great way to end up getting infected with malware.

Make sure you have a Very Good Reason for sending content in an 
attachment.  If your plan is to always send the info as a PDF odds are 
high that you don't have a good reason for doing it this way.

jc



From acv at miniguru.ca  Wed Feb 22 10:46:30 2012
From: acv at miniguru.ca (acv)
Date: Wed, 22 Feb 2012 11:46:30 -0500
Subject: Customer Notification System.
In-Reply-To: <4F451929.8030407@gmail.com>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F451929.8030407@gmail.com>
Message-ID: <20120222164630.GO3596@miniguru.ca>

On Wed, Feb 22, 2012 at 08:34:49AM -0800, JC Dill wrote:
> 
> 99.999% of the time there is absolutely no benefit in the attachment.  
> But by pushing customers to open attachments to get the content we are 
> encouraging them to be complacent about opening all attachments, and 
> that's a great way to end up getting infected with malware.

I agree whole heartedly. If the Marketing/Sales folks are stuck up on branding,
I'd explore sending a MIME multipart/alternative with branded HTML and a
plain text version with no degradation of actual content. And keep the whole
thing under 25-30KB total. Creating them is pretty easy with perl MIME::Lite.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120222/85f18a0e/attachment.bin>

From o.calvano at gmail.com  Wed Feb 22 10:43:15 2012
From: o.calvano at gmail.com (Olivier CALVANO)
Date: Wed, 22 Feb 2012 17:43:15 +0100
Subject: [BIZ] Colocate at New York
Message-ID: <CAJajPeexnmM5WdmDHVwTPjQbFknPasVV+Y-_uYMvOv2=zBfeYA@mail.gmail.com>

Hi

we want see a colocate at New York:

* Equinix or telehouse
* 1/4 or 1/2 rack (only private rack with 1/4 or 1/2 door)
* 1 Kva Dual Feeds
* 1 Cross Connect Fiber
*  no internet.

If you know a good supplier ;=)

Thanks
Olivier


From stephen at sprunk.org  Wed Feb 22 10:50:04 2012
From: stephen at sprunk.org (Stephen Sprunk)
Date: Wed, 22 Feb 2012 10:50:04 -0600
Subject: WW: Colo Vending Machine
In-Reply-To: <CAMfXtQxN=_PNfu_uZYGcH6PwM0MqB=M5bTufu2jGneUNEAWk4w@mail.gmail.com>
References: <e592699c-15ff-4c8a-ae74-7269bf565ecf@mail.pelican.org>
 <C14A5C97-5089-4CF0-9634-7997E8E6A204@delong.com>
 <4F45134B.7010808@bogus.com>
 <CAMfXtQxN=_PNfu_uZYGcH6PwM0MqB=M5bTufu2jGneUNEAWk4w@mail.gmail.com>
Message-ID: <4F451CBC.3090207@sprunk.org>

On 22-Feb-12 10:34, Gary Buhrmaster wrote:
> On Wed, Feb 22, 2012 at 08:09, Joel jaeggli <joelja at bogus.com> wrote:
>> If we just stop printing things the problem goes away.
> I think Xerox promised me a paperless office (starting in the 1980s?).  I am still waiting.

That's an odd thing to expect from a company that made its name in
photocopiers, printers and fax machines, i.e. machines that enabled
using /more/ paper in the office rather than less.

However, my office /is /almost entirely paperless today; everything is
done via email/web except where paper is required by the legal system. 
Nearly all of what I do print is signed, scanned to PDF and shredded
within minutes.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2312 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120222/78a9df0f/attachment.bin>

From aegal at cisco.com  Wed Feb 22 11:13:48 2012
From: aegal at cisco.com (Abdulkadir Egal)
Date: Wed, 22 Feb 2012 09:13:48 -0800
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <FCF4EA853883E348957567CD9E90E97301D3D26101@vnxbcnex01.bcn.nexica.com>
Message-ID: <CB6A624C.27667%aegal@cisco.com>

Hi Carlos

Let me know offline what hardware you need.

Regards

Abdul





On 2/22/12 7:46 AM, "Carlos Asensio" <CAsensio at nexica.com> wrote:

> Hi Nick,
> 
> Thanks for your answer. We'll take it into proper consideration.
> 
> Any other alternatives?
> 
> Cheers,
> Carlos.
> 
> -----Mensaje original-----
> De: Nick Hilliard [mailto:nick at foobar.org]
> Enviado el: mi?rcoles, 22 de febrero de 2012 16:41
> Para: nanog at nanog.org
> Asunto: Re: Cisco CAT6500 IOS Simulator
> 
> On 22/02/2012 15:36, Carlos Asensio wrote:
>> Any alternative?
> 
> Ebay.
> 
> Nick
> 
> 



From dgolding at ragingwire.com  Wed Feb 22 14:37:57 2012
From: dgolding at ragingwire.com (Dan Golding)
Date: Wed, 22 Feb 2012 12:37:57 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <20120217144613.GB70102@ussenterprise.ufp.org>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <20120217144613.GB70102@ussenterprise.ufp.org>
Message-ID: <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>


> -----Original Message-----
> From: Leo Bicknell [mailto:bicknell at ufp.org]
> 
> At the risk of offending many folks on NANOG, our industry is more
like
> a trade than a profession.  In many cases we would do better to treat
> our people (in terms of how they are managed) like skilled trades,
> electricians, plumbers, metal fitters, rather than pretend they are
> white collar professionals.
> 
> Low level employees should be apprenticed by higher level employees.
> Many of our skills are learned on the job; just like other trades
> someone with only book knowledge is darn near useless.  Not only do
> those above need to teach, but they need to supervise, and exercise
> standards and quality control.


I disagree. The best model is - gasp - engineering, a profession which
many in "networking" claim to be a part of, but few actually are. In the
engineering world (not CS, not development - think ME and EE), there is
a strongly defined relationship between junior and senior engineers, and
real mentorship. The problem with "networking" is that TOO MANY skills
are learned on the job (poorly), rather than folks coming in with solid
fundamentals. I blame our higher education system for being ineffectual
in this regard. Most of the "book learning" that you refer to is not
true theory - it's a mix of vendor prescriptions and
overgeneralizations. In "networking", you don't learn real theory until
you're very senior - you learn practice, first. 

The true problem is that most "networking" professionals came out of a
CS background or are self-taught. They might be clueful and they might
be highly adept, but they lack the structure of an engineering
educations and formal mentorship. They also lack real licensing, which
is a separate problem. 


> 
> To your point, if you look at skilled trades the simpler the task the
> more likely it will fall to the "new guy".  Rack and stack is probably
> one of simplest jobs in our industry.  A two man team, one senior, one
> junior, showing up at a colo may see the junior guy doing the physical
> work, while the senior guy works out any issues with the colo provider
> brings up the interconnection to them, etc.
> 

Rack and stack is not a network engineer task, anymore than running a
208/3 phase circuit is an electrical engineer's task. Instead, rack and
stack is a task for a skilled telecom tradesman. I have nothing against
network engineers getting out of the office to do this, but the quality
of their work will never be up to a real telecom guy. Look at the
cabling. You can always tell which has been done by a "network engineer"
and which has been done by a real tradesman. Guess which one is better?

Dan





From p.lynch at netappliant.com  Wed Feb 22 15:10:56 2012
From: p.lynch at netappliant.com (Pierce Lynch)
Date: Wed, 22 Feb 2012 21:10:56 +0000
Subject: FCoE Deployment
In-Reply-To: <4F450649.5050302@redpill-linpro.com>
References: <4F45038B.7090005@bonyari.com>
 <4F450649.5050302@redpill-linpro.com>
Message-ID: <A4428DD467A70E48B98693F1E20B198C14A89B9D@V-ENT02.eu.netappliant.com>

> FCoE was until very recently the only way to do centralized block storage 
> to the Cisco UCS server blades, so I'd imagine it's quite widely adopted.
> That said, we don't run FCoE outside of the UCS <black box> - its uplinks
> to the SAN are just regular FC.

Agreed, very much the only implementation I have come across FCoE installations for is Cisco UCS chassis. Personally, it's not something that I have seen regularly adopted as of yet outside proprietary hardware configurations such as UCS deployments.

Certainly also keen to understand as to any other use cases and deployments others have implemented using full-blown FCoE.

Kind regards,

Pierce Lynch



From jeroen at mompl.net  Wed Feb 22 15:13:47 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 22 Feb 2012 13:13:47 -0800
Subject: Most energy efficient (home) setup
Message-ID: <4F455A8B.80809@mompl.net>

After reading a number of threads where people list their huge and 
wasteful, but undoubtedly fun (and sometimes necessary?), home setups 
complete with dedicated rooms and aircos I felt inclined to ask who has 
attempted to make a really energy efficient setup?

This may be an interesting read, it uses a plugcomputer:
http://www.theregister.co.uk/2010/11/11/diy_zero_energy_home_server/page2.html

Admittedly I don't have a need for a full blown home lab since I am not 
a network engineer, I'm more of a sysadmin/network admin/programmer kind 
of person... So I can make do with a somewhat minimal set up. But I *do* 
have tunneled IPv6 from home ;-)

In my current apartment in addition to an el cheapo DSL modem that 
probably wastes about 10 watts and a "sometimes on" PC workstation I 
used to have an always on thinkpad (early 2000s model) as my main 
desktop system and an always on G4 system (pegasos2 in case you care) 
acting as a mail/web/ssh server. The thinkpad was a refurbished model 
and it was quite stable, up to 500 days of uptime during its last years. 
But the hardware slowly disintegrated and when the gfx card died I 
retired it.

Right now my always on server is a VIA artigo 1100 pico-itx system 
(replacing the G4 system) and my "router/firewall/modem" is still the el 
cheapo DSL modem (which runs busybox by the way). I have an upgraded 
workstation that's "sometimes on", it has a mini itx form factor (AMD 
phenom2 CPU). I use debian on all systems.

I haven't measured it but I think if the set up would use 30 watts 
continuously (only taking the always on systems into account) it'd be a 
lot. Of course it'll spike when I fire up the workstation.

It's not extremely energy efficient but compared to some setups I read 
about it is. The next step would be to migrate to a plugcomputer or 
something similar (http://plugcomputer.org/).

Any suggestions and ideas appreciated of course. :-)

Thanks,
Jeroen

-- 
Earthquake Magnitude: 3.0
Date: Wednesday, February 22, 2012 13:57:33 UTC
Location: Island of Hawaii, Hawaii
Latitude: 19.4252; Longitude: -155.3207
Depth: 3.90 km


From jgreco at ns.sol.net  Wed Feb 22 15:48:42 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 22 Feb 2012 15:48:42 -0600 (CST)
Subject: Most energy efficient (home) setup
In-Reply-To: <4F455A8B.80809@mompl.net>
Message-ID: <201202222148.q1MLmgKF051917@aurora.sol.net>

> Right now my always on server is a VIA artigo 1100 pico-itx system 
> (replacing the G4 system) and my "router/firewall/modem" is still the el 
> cheapo DSL modem (which runs busybox by the way). I have an upgraded 
> workstation that's "sometimes on", it has a mini itx form factor (AMD 
> phenom2 CPU). I use debian on all systems.
> 
> I haven't measured it but I think if the set up would use 30 watts 
> continuously (only taking the always on systems into account) it'd be a 
> lot. Of course it'll spike when I fire up the workstation.
> 
> It's not extremely energy efficient but compared to some setups I read 
> about it is. The next step would be to migrate to a plugcomputer or 
> something similar (http://plugcomputer.org/).
> 
> Any suggestions and ideas appreciated of course. :-)

You want truly energy efficient but not too resource limited like the 
Pogoplug and stuff like that?  Look to Apple's Mac mini.

The current Mac mini "Server" model sports an i7 2.0GHz quad-core CPU
and up to 16GB RAM (see OWC for that, IIRC).  Two drives, up to 750GB
each, or SSD's if you prefer.

12 frickin' watts when idle.  Or thereabouts.  Think about 40 watts
when running full tilt, maybe a bit more.

In the more-realistically-server-grade department, we've built some
really nice Supermicro based E3-1230's, 16-32GB, 6x GigE, RAID, six- 
to eight 2.5" SSD's and Seagate Momentus XT hybrid drives, idle around
60 watts and peak around 100.  We've virtualized loads of older boxes 
onto some of those with good-to-great success.  Two of those can replace 
what took a rackful of machines a decade ago.

Quite frankly, I think most of the "little server" stuff is a bit
questionable.  We picked up a ProLiant Microserver N36L a while back
for NAS use, but quite frankly I'm un-blown-away by its 35 watt baseline
performance, when for 45 watts I can get an E3-1230 with 16GB of RAM,
run ESXi, and run stuff alongside a NAS VM.  (The 60 watt figure is for
a more loaded-up-with-stuff box)

Which brings me to the point:  for energy efficient home use, you might
want to consider a slightly larger/more expensive machine and 
virtualization.  It doesn't have to be an ESXi host.  It seems like you
can run two or three other servers on a Mac mini Server with stuff like
VMware Fusion without stressing things too much, and that might put you
in the 20-30 watt range for a flexible setup.  You also don't have to
buy a MMS; the lower end Mac mini's are also plenty powerful, can be
upgraded similarly, but lack OS X Server and the quad core CPU.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From stb at lassitu.de  Wed Feb 22 16:02:05 2012
From: stb at lassitu.de (Stefan Bethke)
Date: Wed, 22 Feb 2012 23:02:05 +0100
Subject: Most energy efficient (home) setup
In-Reply-To: <201202222148.q1MLmgKF051917@aurora.sol.net>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>
Message-ID: <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>

Am 22.02.2012 um 22:48 schrieb Joe Greco:

> You also don't have to
> buy a MMS; the lower end Mac mini's are also plenty powerful, can be
> upgraded similarly, but lack OS X Server and the quad core CPU.

With 10.7, Server is now a $50 add-on download from the Mac App Store, no special hardware required.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811





From marcelplug at gmail.com  Wed Feb 22 16:07:00 2012
From: marcelplug at gmail.com (Marcel Plug)
Date: Wed, 22 Feb 2012 17:07:00 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <4F455A8B.80809@mompl.net>
References: <4F455A8B.80809@mompl.net>
Message-ID: <CACfXSnAC6qf3=Gq5WQJaRMCusidM=NH=DJJs0N+A_tzE8GksJA@mail.gmail.com>

I've run a SheevaPlug at home for a few years now.  I don't do
anything fancy with it, but it does what I need it to do.  Mostly that
is file server, web server, jump-box for network testing.  Also
testing different linux software for this and that...  (Quagga runs
nicely, but won't hold a full BGP table :)

There are no moving parts in my home computer/networking gear, unless
my laptop is running.  That was the goal for me.  I recently grabbed a
couple of TPLink WR703N devices to mess around with as well, but I
haven't had a chance to dig into that much.

The internet tells me that the Sheeva uses about 5 Watts of power.
Along with my wireless router and DSL modem I might be under 10 Watts,
but I really don't know how much power a wireless modem uses.

Oh and I also have native IPv6 on my DSL.  I like to brag about that
whenever I can.

Marcel

On Wed, Feb 22, 2012 at 4:13 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
> After reading a number of threads where people list their huge and wasteful,
> but undoubtedly fun (and sometimes necessary?), home setups complete with
> dedicated rooms and aircos I felt inclined to ask who has attempted to make
> a really energy efficient setup?
>
> This may be an interesting read, it uses a plugcomputer:
> http://www.theregister.co.uk/2010/11/11/diy_zero_energy_home_server/page2.html
>
> Admittedly I don't have a need for a full blown home lab since I am not a
> network engineer, I'm more of a sysadmin/network admin/programmer kind of
> person... So I can make do with a somewhat minimal set up. But I *do* have
> tunneled IPv6 from home ;-)
>
> In my current apartment in addition to an el cheapo DSL modem that probably
> wastes about 10 watts and a "sometimes on" PC workstation I used to have an
> always on thinkpad (early 2000s model) as my main desktop system and an
> always on G4 system (pegasos2 in case you care) acting as a mail/web/ssh
> server. The thinkpad was a refurbished model and it was quite stable, up to
> 500 days of uptime during its last years. But the hardware slowly
> disintegrated and when the gfx card died I retired it.
>
> Right now my always on server is a VIA artigo 1100 pico-itx system
> (replacing the G4 system) and my "router/firewall/modem" is still the el
> cheapo DSL modem (which runs busybox by the way). I have an upgraded
> workstation that's "sometimes on", it has a mini itx form factor (AMD
> phenom2 CPU). I use debian on all systems.
>
> I haven't measured it but I think if the set up would use 30 watts
> continuously (only taking the always on systems into account) it'd be a lot.
> Of course it'll spike when I fire up the workstation.
>
> It's not extremely energy efficient but compared to some setups I read about
> it is. The next step would be to migrate to a plugcomputer or something
> similar (http://plugcomputer.org/).
>
> Any suggestions and ideas appreciated of course. :-)
>
> Thanks,
> Jeroen
>
> --
> Earthquake Magnitude: 3.0
> Date: Wednesday, February 22, 2012 13:57:33 UTC
> Location: Island of Hawaii, Hawaii
> Latitude: 19.4252; Longitude: -155.3207
> Depth: 3.90 km
>


From leigh.porter at ukbroadband.com  Wed Feb 22 16:09:48 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 22 Feb 2012 22:09:48 +0000
Subject: Most energy efficient (home) setup
In-Reply-To: <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>,
 <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>
Message-ID: <F864B4AC-45E5-4AC6-AF04-DB8E5120DC70@ukbroadband.com>


On 22 Feb 2012, at 22:04, "Stefan Bethke" <stb at lassitu.de> wrote:

> Am 22.02.2012 um 22:48 schrieb Joe Greco:
> 
>> You also don't have to
>> buy a MMS; the lower end Mac mini's are also plenty powerful, can be
>> upgraded similarly, but lack OS X Server and the quad core CPU.
> 
> With 10.7, Server is now a $50 add-on download from the Mac App Store, no special hardware required.
> 

You dudes need to get with the times and put all this stuff in the cloud.

Ok so I joke a little.. But I did move a load of stuff from a couple of home servers to some VMs and it works fine. Less to mess around with and prob cheaper too. 

The only thing I keep at home now is storage.

--
Leigh Porter


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


From jgreco at ns.sol.net  Wed Feb 22 16:08:52 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 22 Feb 2012 16:08:52 -0600 (CST)
Subject: Most energy efficient (home) setup
In-Reply-To: <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>
Message-ID: <201202222208.q1MM8qS5052370@aurora.sol.net>

> Am 22.02.2012 um 22:48 schrieb Joe Greco:
> > You also don't have to
> > buy a MMS; the lower end Mac mini's are also plenty powerful, can be
> > upgraded similarly, but lack OS X Server and the quad core CPU.
> 
> With 10.7, Server is now a $50 add-on download from the Mac App Store, no special hardware required.

I also haven't found it to be particularly *good* at anything; I'm not
an OS X guy, and maybe that's part of the problem, but I found Snow
Leopard Server a lot more comprehensible in a "this seems really un-Apple-
like but at least it makes some sort of sense" way.

OS X Lion Server feels like someone just bolted on random bits of server
management stuff.  If you've ever managed a server with a poorly
integrated control panel, it reminds me a little of that.

I believe that there are plenty of people who ditch OS X entirely and do
other things with them.  I wish ESXi would run on them.  I could see
*uses* for that.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From cabo at tzi.org  Wed Feb 22 16:19:55 2012
From: cabo at tzi.org (Carsten Bormann)
Date: Wed, 22 Feb 2012 23:19:55 +0100
Subject: common time-management mistake: rack & stack
In-Reply-To: <292C237E-219A-4F7C-9BC0-14F47B878C2B@delong.com>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <292C237E-219A-4F7C-9BC0-14F47B878C2B@delong.com>
Message-ID: <9D2AC5BE-9AA3-491B-BF27-DF61591243DA@tzi.org>

On Feb 17, 2012, at 18:55, Owen DeLong wrote:

> I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate.

In software, this problem is a rather well known "Antipattern":

	http://c2.com/cgi/wiki?ArchitectsDontCode

(This is an "Antipattern", i.e. it actually means "Architects *MUST* write code".
But the problems from doing this getting in the way are also discussed there, so Jeff gets some support, too.)

Gr??e, Carsten

PS.: Donald E. Knuth said:
"The designer of a new kind of system must participate fully in the implementation."
So, the more cookie-cutter your systems become, the less important is the requirement to do this over and over.
But having it done once, and recently enough, still is a qualification factor for an architect.

PPS.: I'm less sure about the battlefield analogies :-)



From jeroen at mompl.net  Wed Feb 22 16:38:19 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 22 Feb 2012 14:38:19 -0800
Subject: Most energy efficient (home) setup
In-Reply-To: <F864B4AC-45E5-4AC6-AF04-DB8E5120DC70@ukbroadband.com>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>,
 <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>
 <F864B4AC-45E5-4AC6-AF04-DB8E5120DC70@ukbroadband.com>
Message-ID: <4F456E5B.20502@mompl.net>

Leigh Porter wrote:
> You dudes need to get with the times and put all this stuff in the cloud.
> Ok so I joke a little.. 

The "cloud" seems to be a more modern implementation of the mainframe 
"paradigm" (and now I feel soiled having used 2 such words in one 
sentence). It has its uses, though it's interesting to see how things go 
full circle. I predict a move away from "the cloud" in about a decade, 
give or take.

> The only thing I keep at home now is storage.

I do have a few virtual private servers (and use them) and have set up a 
few VPS serving servers myself. However it's fun to tinker with hardware 
and if I'd migrate as much as possible to VPS systems it'd take a big 
chunk of the fun out of it.

As a side note, the main reasons for me to have a more energy efficient 
setup is not to "go green" (there are better ways for that) but because 
it is a fun challenge, I dislike paying bigger bills, and I hate the 
clutter and the noise a big setup brings.

Greetings,
Jeroen

-- 
Earthquake Magnitude: 3.2
Date: Wednesday, February 22, 2012 22:00:06 UTC
Location: Central Alaska
Latitude: 62.0453; Longitude: -152.4945
Depth: 10.90 km


From jeroen at mompl.net  Wed Feb 22 16:43:43 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 22 Feb 2012 14:43:43 -0800
Subject: Most energy efficient (home) setup
In-Reply-To: <CACfXSnAC6qf3=Gq5WQJaRMCusidM=NH=DJJs0N+A_tzE8GksJA@mail.gmail.com>
References: <4F455A8B.80809@mompl.net>
 <CACfXSnAC6qf3=Gq5WQJaRMCusidM=NH=DJJs0N+A_tzE8GksJA@mail.gmail.com>
Message-ID: <4F456F9F.6020702@mompl.net>

Marcel Plug wrote:
> I've run a SheevaPlug at home for a few years now.  I don't do
> anything fancy with it, but it does what I need it to do.  Mostly that

I wonder how reliable the storage is in these things. Is it comparable 
to modern SSDs?

> Oh and I also have native IPv6 on my DSL.  I like to brag about that
> whenever I can.

So your ISP delivers IPv6 to your home? I wish mine did...

-- 
Earthquake Magnitude: 3.2
Date: Wednesday, February 22, 2012 22:00:06 UTC
Location: Central Alaska
Latitude: 62.0453; Longitude: -152.4945
Depth: 10.90 km


From leigh.porter at ukbroadband.com  Wed Feb 22 16:48:44 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Wed, 22 Feb 2012 22:48:44 +0000
Subject: Most energy efficient (home) setup
In-Reply-To: <4F456E5B.20502@mompl.net>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>,
 <0D3B245D-345F-4697-B17B-4844A9ADD984@lassitu.de>
 <F864B4AC-45E5-4AC6-AF04-DB8E5120DC70@ukbroadband.com>,
 <4F456E5B.20502@mompl.net>
Message-ID: <84D965B8-EB55-44DB-A67A-94599E2F5436@ukbroadband.com>


On 22 Feb 2012, at 22:40, "Jeroen van Aart" <jeroen at mompl.net> wrote:

> Leigh Porter wrote:
>> You dudes need to get with the times and put all this stuff in the cloud.
>> Ok so I joke a little.. 
> 
> The "cloud" seems to be a more modern implementation of the mainframe "paradigm" (and now I feel soiled having used 2 such words in one sentence). It has its uses, though it's interesting to see how things go full circle. I predict a move away from "the cloud" in about a decade, give or take.

Or sooner when people realise that anything not locked away on an box at home is being routinely nosed at for thought crime and illegal quotations or something or other..



> I do have a few virtual private servers (and use them) and have set up a few VPS serving servers myself. However it's fun to tinker with hardware and if I'd migrate as much as possible to VPS systems it'd take a big chunk of the fun out of it.

Yeah it does, I wish I had time for the fun of it! 

--
Leigh


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


From jgreco at ns.sol.net  Wed Feb 22 17:00:06 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 22 Feb 2012 17:00:06 -0600 (CST)
Subject: Most energy efficient (home) setup
In-Reply-To: <F864B4AC-45E5-4AC6-AF04-DB8E5120DC70@ukbroadband.com>
Message-ID: <201202222300.q1MN06ki052833@aurora.sol.net>

> On 22 Feb 2012, at 22:04, "Stefan Bethke" <stb at lassitu.de> wrote:
> > Am 22.02.2012 um 22:48 schrieb Joe Greco:
> >=20
> >> You also don't have to
> >> buy a MMS; the lower end Mac mini's are also plenty powerful, can be
> >> upgraded similarly, but lack OS X Server and the quad core CPU.
> >=20
> > With 10.7, Server is now a $50 add-on download from the Mac App Store, n=
> o special hardware required.
> >=20
> 
> You dudes need to get with the times and put all this stuff in the cloud.

We are.  I'm just putting it in *our* cloud, not some random other
company's.

> Ok so I joke a little.. But I did move a load of stuff from a couple of ho=
> me servers to some VMs and it works fine. Less to mess around with and pro=
> b cheaper too.=20
> 
> The only thing I keep at home now is storage.

If you're keeping the storage, run some VM's alongside.  

Quite frankly, it's a little horrifying how quickly people have embraced
not owning their own resources.  On one hand, sure, it's great not to have
to worry about some aspects of it all, but on the other hand...

The web sites that we entrust our data to can, and do, vanish:

MySpace.  GeoCities.  Friendster.  Google Videos.  Which of those did
you predict would eventually fail?

The companies we pay to provide us with services screw up:

T-Mobile (Microsoft?) Sidekick.  Lala.  Megaupload.  RIM/Blackberry.

Arbitrary changes in terms of service:

Facebook.  Dropbox.  Google.

You know where I never have to worry about any of that?  On gear we own
and control.

"Cloud" is a crock of hooey buzzword.  There's no "cloud."  For the
average end user, it is the realization that we've farmed out tasks to 
unknowable servers across the Internet.  For the technical user, it's
setting up instances of servers in some large hosting company's big
data centers.  The "cloud" people refer to today is nothing more than
the continued evolution of virtualized hosting.

There's nothing magic about it.  You're trusting your data, your 
processes, or (most likely) both, to arbitrary other companies whose
responsibilities are to their shareholders and whose motives are
profits.  You have no control over the actual management, must trust
that they'll let you know if their security has been breached, and
you may never find out if someone's gone snooping.

It isn't somehow magic and new because someone calls it "cloud."
All this "cloud" stuff?  It runs on actual hardware, not up in the sky.
And as long as it runs on actual hardware, it'll run faster and better
and more responsively on equipment that's less-loaded, better-specced,
and much-closer.

Sun had it right all those years ago: "The network is the computer."
But it doesn't have to be Amazon's network, or Google's network.
We *are* the North American Network Operators' Group.  The people
here are more than just a little clued about this stuff.

I'm fine with running Netflix out of the cloud.  I can tolerate their
occasional outages and problems.  I'm fine with running other
unimportant stuff out of the cloud.  But it looks like it is going to 
be a long time before I have any real interest in running anything of
value out of someone else's "cloud."

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From david at davidswafford.com  Wed Feb 22 17:06:48 2012
From: david at davidswafford.com (David)
Date: Wed, 22 Feb 2012 18:06:48 -0500
Subject: FCoE Deployment
In-Reply-To: <4F45038B.7090005@bonyari.com>
References: <4F45038B.7090005@bonyari.com>
Message-ID: <AE14FD9B-05EA-43D0-A92B-4DD18326DD29@davidswafford.com>

yep, we're doing FCoE in an EMC Symettric, ESX, Nexus environment.  All of our FCoE is over 10gb CNAs.  We are having good results, though we hit an odd bug on QLogics cards initially on pur HP DL 580s (affected twinax only -- if you dropped on uplink , ie testing failover, throughput dropped to crap for disk i/o., that issue only cleared after a power cycle of the server.  Qlogic never fixed the issue so we RMAd nearly 30k in 10gb CNA cards and swapped everythibg to fiber.  So beware of that.  I can get more detail on the affected cards,etc tomorrow if interested.  Our entire production VMware environment is off that setup.

David

Sent from an email server.

On Feb 22, 2012, at 10:02 AM, Jack Morgan <jack at bonyari.com> wrote:

> Does anyone know of any company or organization deploying FCoE[1] in a
> production environment? I'm curious how widely adopted this technology is.
> 
> 
> [1] http://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
>    http://fcoe.com/
> 
> 
> Thanks,
> 
> -- 
> Jack Morgan
> 
> 


From david at davidswafford.com  Wed Feb 22 17:10:32 2012
From: david at davidswafford.com (David)
Date: Wed, 22 Feb 2012 18:10:32 -0500
Subject: FCoE Deployment
In-Reply-To: <A4428DD467A70E48B98693F1E20B198C14A89B9D@V-ENT02.eu.netappliant.com>
References: <4F45038B.7090005@bonyari.com>
 <4F450649.5050302@redpill-linpro.com>
 <A4428DD467A70E48B98693F1E20B198C14A89B9D@V-ENT02.eu.netappliant.com>
Message-ID: <D05CBAF3-3614-45CF-A776-33A9FF4A16B4@davidswafford.com>

our reason btw was to cut down on cabling/switch costs, it starts to add up when you consider how many blades get eated by 1gb copper.  going to DL580s amd a few hp chassis.  A chassis used to eat nearly 64 copper 1gb and 32 fiber channel connections.  on FCoE/CNAs, we're literally talking 4 x 10gb cables (16 blades).  

David

Sent from an email server.

On Feb 22, 2012, at 4:10 PM, Pierce Lynch <p.lynch at netappliant.com> wrote:

>> FCoE was until very recently the only way to do centralized block storage 
>> to the Cisco UCS server blades, so I'd imagine it's quite widely adopted.
>> That said, we don't run FCoE outside of the UCS <black box> - its uplinks
>> to the SAN are just regular FC.
> 
> Agreed, very much the only implementation I have come across FCoE installations for is Cisco UCS chassis. Personally, it's not something that I have seen regularly adopted as of yet outside proprietary hardware configurations such as UCS deployments.
> 
> Certainly also keen to understand as to any other use cases and deployments others have implemented using full-blown FCoE.
> 
> Kind regards,
> 
> Pierce Lynch
> 
> 


From jeroen at mompl.net  Wed Feb 22 17:26:18 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 22 Feb 2012 15:26:18 -0800
Subject: Most energy efficient (home) setup
In-Reply-To: <201202222300.q1MN06ki052833@aurora.sol.net>
References: <201202222300.q1MN06ki052833@aurora.sol.net>
Message-ID: <4F45799A.1070600@mompl.net>

Joe Greco wrote:
> Quite frankly, it's a little horrifying how quickly people have embraced
> not owning their own resources.  On one hand, sure, it's great not to have
> to worry about some aspects of it all, but on the other hand...

> The web sites that we entrust our data to can, and do, vanish:

> You know where I never have to worry about any of that?  On gear we own
> and control.
> 
> "Cloud" is a crock of hooey buzzword.  There's no "cloud."  For the
> average end user, it is the realization that we've farmed out tasks to 

> Sun had it right all those years ago: "The network is the computer."
> But it doesn't have to be Amazon's network, or Google's network.
> We *are* the North American Network Operators' Group.  The people
> here are more than just a little clued about this stuff.

I wholeheartedly agree.
I couldn't have said it better :-)

-- 
Earthquake Magnitude: 3.2
Date: Wednesday, February 22, 2012 22:00:06 UTC
Location: Central Alaska
Latitude: 62.0453; Longitude: -152.4945
Depth: 10.90 km


From kamtha at ak-labs.net  Wed Feb 22 18:15:50 2012
From: kamtha at ak-labs.net (Carlos Kamtha)
Date: Wed, 22 Feb 2012 19:15:50 -0500
Subject: colosolutions abuse contact?
Message-ID: <20120223001550.GI75951@ak-labs.net>

Hi, 

I'm hoping to get a hold of an abuse contact at colosolutions.com.   

Any help is greatly appreciated. 

If so, please contact me offlist. 

Cheers, 
Carlos. 


From marcelplug at gmail.com  Wed Feb 22 19:34:08 2012
From: marcelplug at gmail.com (Marcel Plug)
Date: Wed, 22 Feb 2012 20:34:08 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <4F456F9F.6020702@mompl.net>
References: <4F455A8B.80809@mompl.net>
 <CACfXSnAC6qf3=Gq5WQJaRMCusidM=NH=DJJs0N+A_tzE8GksJA@mail.gmail.com>
 <4F456F9F.6020702@mompl.net>
Message-ID: <CACfXSnDyt9h6Yh3xftgPza-FKLFj=O8bBtJLAwOJPz2ud69+aA@mail.gmail.com>

On Wed, Feb 22, 2012 at 5:43 PM, Jeroen van Aart <jeroen at mompl.net> wrote:
>
> I wonder how reliable the storage is in these things. Is it comparable to
> modern SSDs?

No issues so far.  As I said though, I don't push it too hard.  I
don't have any specs or stats off hand, so I can't get any more
detailed.

I use a SD card for extra storage, also seems to be working just fine.

>
>
>> Oh and I also have native IPv6 on my DSL. ?I like to brag about that
>> whenever I can.
>
>
> So your ISP delivers IPv6 to your home? I wish mine did...
>
I'm pretty happy with them, I just wish my DLink would stop requiring reboots...

>
>

Marcel


From jeroen at mompl.net  Wed Feb 22 20:15:42 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Wed, 22 Feb 2012 18:15:42 -0800
Subject: Most energy efficient (home) setup
In-Reply-To: <CACfXSnDyt9h6Yh3xftgPza-FKLFj=O8bBtJLAwOJPz2ud69+aA@mail.gmail.com>
References: <4F455A8B.80809@mompl.net>	<CACfXSnAC6qf3=Gq5WQJaRMCusidM=NH=DJJs0N+A_tzE8GksJA@mail.gmail.com>	<4F456F9F.6020702@mompl.net>
 <CACfXSnDyt9h6Yh3xftgPza-FKLFj=O8bBtJLAwOJPz2ud69+aA@mail.gmail.com>
Message-ID: <4F45A14E.3090700@mompl.net>

Marcel Plug wrote:
> No issues so far.  As I said though, I don't push it too hard.  I
> don't have any specs or stats off hand, so I can't get any more
> detailed.

What's the speed like?

> I'm pretty happy with them, I just wish my DLink would stop requiring reboots...

I assume you connected it to a (battery backed) UPS? If not doing so may 
help with that. Small fluctuations in power may cause just enough bitrot 
  (http://www.catb.org/jargon/html/B/bit-rot.html) for it to behave 
funky but not all out fail.

Greetings,
Jeroen

-- 
Earthquake Magnitude: 3.2
Date: Wednesday, February 22, 2012 22:00:06 UTC
Location: Central Alaska
Latitude: 62.0453; Longitude: -152.4945
Depth: 10.90 km


From jwininger at ifncom.net  Wed Feb 22 20:43:31 2012
From: jwininger at ifncom.net (James Wininger)
Date: Wed, 22 Feb 2012 21:43:31 -0500
Subject: Customer Notification System.
In-Reply-To: <20120222110124.GA24779@gsp.org>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <20120222110124.GA24779@gsp.org>
Message-ID: <ECB21E5E-A687-4C1F-9B0C-97378CE9F442@ifncom.net>


Well there isn't anything wrong with the mail list approach, but it is more complicated than sending email to a list of customers. We have several types of services (transport, ss7, managed Noc svc etc). Having the db backend would give us flexibility for future notifications based on type of service etc.

-- 
Jim Wininger

On Feb 22, 2012, at 6:02 AM, "Rich Kulawiec" <rsk at gsp.org> wrote:

> On Tue, Feb 21, 2012 at 05:58:19PM -0500, James Wininger wrote:
>> We would need to send notifications out to say about 400 customers.
>> Ideally the system would send an attached PDF. It would be great if this
>> system were SQL based etc.
> 
> (a) Use ASCII.  Using PDF for this is insane.
> 
> (b) You're dealing with only 400 customers, yet you want the overhead
> and complexity of a SQL-capable database?  Do you also engage a fleet
> of bulldozers when you want to plant a flower in the back yard?
> 
>> I have thought of possibly using a
>> mailing list type approach, but that gets us back to (almost) where we
>> are today. 
> 
> Precisely what is wrong with a "mailing list type approach", using
> Mailman (which is the best available and what runs this list)?  It handles
> COI (mandatory for responsible and ethical operation of all mailing lists),
> it runs on all varieties of 'nix, it plays nice with MTAs, it deals with
> most bounces in a sane fashion, etc.
> 
> ---rsk
> 


From DStaal at usa.net  Wed Feb 22 20:41:42 2012
From: DStaal at usa.net (Daniel Staal)
Date: Wed, 22 Feb 2012 21:41:42 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <201202222148.q1MLmgKF051917@aurora.sol.net>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>
Message-ID: <FB0871DCC664C25FB8E1B9C4@mac-pro.magehandbook.com>

--As of February 22, 2012 3:48:42 PM -0600, Joe Greco is alleged to have 
said:

>> Right now my always on server is a VIA artigo 1100 pico-itx system
>> (replacing the G4 system) and my "router/firewall/modem" is still the el
>> cheapo DSL modem (which runs busybox by the way). I have an upgraded
>> workstation that's "sometimes on", it has a mini itx form factor (AMD
>> phenom2 CPU). I use debian on all systems.
>>
>> I haven't measured it but I think if the set up would use 30 watts
>> continuously (only taking the always on systems into account) it'd be a
>> lot. Of course it'll spike when I fire up the workstation.
>>
>> It's not extremely energy efficient but compared to some setups I read
>> about it is. The next step would be to migrate to a plugcomputer or
>> something similar (http://plugcomputer.org/).
>>
>> Any suggestions and ideas appreciated of course. :-)
>
> You want truly energy efficient but not too resource limited like the
> Pogoplug and stuff like that?  Look to Apple's Mac mini.
>
> The current Mac mini "Server" model sports an i7 2.0GHz quad-core CPU
> and up to 16GB RAM (see OWC for that, IIRC).  Two drives, up to 750GB
> each, or SSD's if you prefer.

--As for the rest, it is mine.

There is an intermediate step as well; something along the lines of an ALIX 
or Fit-PC (or Netgate) board.  These are boards designed for 
embedded/network applications, mostly.  (Although the Fit-PC looks to be 
more of a thin client desktop.)  Depending on the use, one can run a decent 
home server on one, or even a lightweight *nix desktop.

Most of these don't actually specify what they use, power-wise; they just 
list what power supply is included.  Fit-PC advertises that it runs at .5 
watts for standby, 8 watts fully loaded.  Many of the others are probably 
similar, depending on how powerful they actually are, and how you configure 
them.

Daniel T. Staal

---------------------------------------------------------------
This email copyright the author.  Unless otherwise noted, you
are expressly allowed to retransmit, quote, or otherwise use
the contents for non-commercial purposes.  This copyright will
expire 5 years after the author's death, or in 30 years,
whichever is longer, unless such a period is in excess of
local copyright law.
---------------------------------------------------------------


From jwininger at ifncom.net  Wed Feb 22 20:46:47 2012
From: jwininger at ifncom.net (James Wininger)
Date: Wed, 22 Feb 2012 21:46:47 -0500
Subject: Customer Notification System.
In-Reply-To: <4F451929.8030407@gmail.com>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F451929.8030407@gmail.com>
Message-ID: <0BED6E4A-3731-4904-BE4D-83579FB6A3EB@ifncom.net>

Well we would not be sending the notification in an attachment, but there are times when it would be nice to send a list of circuit ids (exported from billing system as PDF) or some other exported doc to the notification.


-- 
Jim Wininger
Indiana Fiber Network
Desk - 317-777-7114
Cell - 317-432-7609
Office - 317-280-4636

CONFIDENTIALITY NOTICE: The information contained in this electronic mail transmission (including any attachment) is intended for the exclusive use of the named recipient and may contain information that is privileged or otherwise confidential. It is not intended for transmission to, or receipt by, anyone other than the named recipient (or person authorized to deliver it to the named recipient). It should not be copied or forwarded to any unauthorized person. If you have received this electronic mail transmission in error, please delete it from your system including any attachment without copying or forwarding it, and notify the sender of the error by return e-mail.

On Feb 22, 2012, at 11:34 AM, "JC Dill" <jcdill.lists at gmail.com> wrote:

> On 21/02/12 2:58 PM, James Wininger wrote:
>> 
>> We would need to send notifications out to say about 400 customers.
>> Ideally the system would send an attached PDF.
> 
> Why are you sending an attachment?
> 
> I hate it when businesses think that they will somehow improve my reading experience by bloating up the email, sending attachments, etc.  What about if I'm reading email on my phone?  In what way does providing the information in a PDF benefit ME?
> 
> 99.999% of the time there is absolutely no benefit in the attachment.  But by pushing customers to open attachments to get the content we are encouraging them to be complacent about opening all attachments, and that's a great way to end up getting infected with malware.
> 
> Make sure you have a Very Good Reason for sending content in an attachment.  If your plan is to always send the info as a PDF odds are high that you don't have a good reason for doing it this way.
> 
> jc
> 


From jwininger at ifncom.net  Wed Feb 22 21:06:55 2012
From: jwininger at ifncom.net (James Wininger)
Date: Wed, 22 Feb 2012 22:06:55 -0500
Subject: WW: Colo Vending Machine
In-Reply-To: <201202181439.q1IEdf1Y079184@aurora.sol.net>
References: <201202181439.q1IEdf1Y079184@aurora.sol.net>
Message-ID: <95E1758B-12EB-4993-9C2B-9DB79892F1E5@ifncom.net>

http://www.sol.net/tmp/nanog/toolbox2.jpg

Ahhhh sweet memories....the 3COM/USR screwdriver. Nice to see someone still has one.


-- 
Jim Wininger


On Feb 18, 2012, at 9:41 AM, "Joe Greco" <jgreco at ns.sol.net> wrote:

>> Do you guys ride your bike to the colo and show up in shorts and a 
>> t-shirt? Who goes to the colo without things like their laptop?
> 
> Quite frankly, when the colo is 800 miles away and you've flown out
> to do something important, only to be tripped up by a lack of some
> stupid $something, and it's 11PM at night, you get a very different
> (*very* different) outlook on it all.  Especially with the way it is
> these days to fly, you don't want to be carrying odd stuff with you
> if you can avoid it.  We'll ship gear via FedEx or UPS.  We rely on
> existing on-site supplies to cover most unexpected stuff.
> 
> It is easy to justify keeping a well-stocked toolbox with a ton of
> generally-useful tools, and also some specialty tools, for example.  
> 
> Our Ashburn toolbox contains, among other things:
> 
> Laminated maps of the area with distributors like Graybar located (now
> probably useless, 8 years out of date, anyone familiar with NoVA will
> understand, haha), Notebook and pen, pencil
> 
> Precision flat & Phillips screwdrivers, Mini Maglite, Sharpie RGB Markers,
> Utility Knife (cutting boxes), Xacto Knife set, hex bit extensions, DB25 pin
> inserter/extractor tools, scissors, surgeon's clamp, metal nibbler, wire
> stripper, various general crimp tools, several pliers, several needlenose/
> bent-nose, flush cutters, adjustable wrenches, Victorinox Swiss CyberTool,
> Milwaukee Power Screwdriver #6546.  22" (not a typo) hex Phillips bit.
> 
> Outlet wiring tester, telephone line tester, RS232 snooper, AUI xcvr (don't
> laugh, I actually used one within the last 5 years), wire wrap tool and
> wire, pencils and sharpener, anti-static wrist strap, logic probe, tool
> magnetizer, digital multimeter, soldering iron and supplies, electrical
> tape, punchdown tool, heat shrink tubing kit, hex key sets, socket drive
> sets, medium screwdrivers.
> 
> Tap & drill set, 20' tape measure, hammer, rubber mallet, big pliers, big
> utility knife, torp level, various bit kits, large adj wrench, tongue and
> groove pliers, big wire cutters/needle nose, spare charger and battery
> for power screwdriver, small cordless drill, crimpers, first aid kit,
> big MagLite, test lead kit, serial adapter kit.
> 
> Now I will concede that we've used a lot of this stuff only a few times
> over the years, and some of it maybe even never, but the point is that
> it really stinks to be on-site and in-need without an easy way to address
> the need.  It's really amusing that there've been people who have made
> it a habit to borrow tools out of our toolbox "because we have just
> about anything."
> 
> Since you guys like pictures:
> 
> http://www.sol.net/tmp/nanog/toolbox1.jpg
> http://www.sol.net/tmp/nanog/toolbox2.jpg
> http://www.sol.net/tmp/nanog/toolbox3.jpg
> 
> We also keep some small roughtotes with:
> 
> Fiber supplies
> Copper supplies
> Power cords etc
> Server parts
> Telecom supplies
> 
> So, yes, sometimes I show up at the colo in shorts and a t-shirt.  Matter
> of fact, most of the time I do.  It's more fun that way.
> 
> ... JG
> -- 
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "We call it the 'one bite at the apple' rule. Give me one chance [and] then I
> won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
> With 24 million small businesses in the US alone, that's way too many apples.
> 


From gh at nynex.net  Wed Feb 22 21:54:22 2012
From: gh at nynex.net (george hill)
Date: Thu, 23 Feb 2012 03:54:22 +0000
Subject: Most energy efficient (home) setup
In-Reply-To: <201202222148.q1MLmgKF051917@aurora.sol.net>
References: <201202222148.q1MLmgKF051917@aurora.sol.net>
Message-ID: <4F45B86E.20201@nynex.net>

On 02/22/12 21:13, Jeroen van Aart wrote:
> I felt inclined to ask who has attempted to make a really energy
> efficient setup?

My current always-on home server is:
 - 3U rackmount box, Supermicro H8SGL, 450 watt '80-plus platinum' PSU
 - 8-core Opteron 6128 _underclocked_ to 800Mhz
 - 16 GB of ECC DDR2
 - 8x 2TB SATA 'green' drives from assorted manufacturers
 - all fans replaced with near-silent Noctua models
 - 2 additional gigE ports (4 total)

I run a few VMs on it to compartmentalize things a bit; the host and
most VMs run gentoo-amd64-hardened, virtualized with Qemu-KVM.  Host OS
routes/firewalls.  One VM is boot and NFS-root server for a couple
diskless workstations around the house.  Another VM runs ntpd, local
DNS, HTTP forward proxy, shell, dev tools, etc.  Another boots FreeBSD
and runs only Postrgres.  The box is also my home music & movie system,
runs motion-detection software to record video from a security camera,
and logs weather and other sensor data.

The server burns 170 to 190 watts in normal use, up to about 280 peak
(movie or music playing + diskless workstations running + compiling
stuff + video recording + backing up laptop).  This is certainly not low
absolute energy consumption compared to some of the other things
mentioned in this thread, but it also does a lot more, so it might be
more efficient, depending on situation.  Consider also that the diskless
workstations only use around 35 W each (including monitor), and these
are the primary personal computers in my home.

In 2011 measured annual energy consumption for the server was 1635
kW*hour, 186 W average.  I estimate the diskless workstations use
another 270 kW*hour or so annually.

 -gh/nynex



From randy at psg.com  Wed Feb 22 23:41:47 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 23 Feb 2012 11:11:47 +0530
Subject: do not filter your customers
Message-ID: <m2hayi85t0.wl%randy@psg.com>

don't filter your customers.  when they leak the world to you, it will
get you a lot of free press and your marketing department will love you.

just ask telstra.

randy


From cnielsen at microsoft.com  Thu Feb 23 00:33:16 2012
From: cnielsen at microsoft.com (Christian Nielsen)
Date: Thu, 23 Feb 2012 06:33:16 +0000
Subject: do not filter your customers
In-Reply-To: <m2hayi85t0.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
Message-ID: <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>

Who once said, there is no such thing as bad press?

http://www.smh.com.au/technology/technology-news/dodo-takes-blame-for-internet-outage-affecting-millions-20120223-1tpqq.html

http://www.itnews.com.au/News/291364,telstra-router-causes-major-internet-outage.aspx

"Dodo has revealed a "minor hardware issue" was behind a Telstra outage that impacted multiple service providers and internet services nationwide"

Does anyone have any additional details?

Christian

-----Original Message-----
From: Randy Bush [mailto:randy at psg.com] 
Sent: Wednesday, February 22, 2012 9:42 PM
To: North American Network Operators' Group
Subject: do not filter your customers

don't filter your customers.  when they leak the world to you, it will get you a lot of free press and your marketing department will love you.

just ask telstra.

randy





From randy at psg.com  Thu Feb 23 00:44:10 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 23 Feb 2012 12:14:10 +0530
Subject: do not filter your customers
In-Reply-To: <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
Message-ID: <m21upm82x1.wl%randy@psg.com>

> "Dodo has revealed a "minor hardware issue" was behind a Telstra
> outage that impacted multiple service providers and internet services
> nationwide"

bs, trying to blame it on a vendor.

a customer leaked a full table to smellstra, and they had not filtered.
hence the $subject.

and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.

randy


From morrowc.lists at gmail.com  Thu Feb 23 00:45:36 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 23 Feb 2012 01:45:36 -0500
Subject: do not filter your customers
In-Reply-To: <m21upm82x1.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
Message-ID: <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>

On Thu, Feb 23, 2012 at 1:44 AM, Randy Bush <randy at psg.com> wrote:
\
> and things when further downhill from there, when telstra also did not
> filter what they announced to their peers, and the peers went over
> prefix limits and dropped bgp.

Oh! so protections worked!

>:)


From randy at psg.com  Thu Feb 23 00:57:18 2012
From: randy at psg.com (Randy Bush)
Date: Thu, 23 Feb 2012 12:27:18 +0530
Subject: do not filter your customers
In-Reply-To: <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>
Message-ID: <m2zkca6nqp.wl%randy@psg.com>

>> and things when further downhill from there, when telstra also did not
>> filter what they announced to their peers, and the peers went over
>> prefix limits and dropped bgp.
> Oh! so protections worked!

imiho, prefix count is too big a hammer.

it would have been better if optus had irr-based filters in place on
peerings with telstra.  then they would not have dropped the sessions
and their customers could still reach telstra customers.

of course, if telstra did not publish accurately in an irr instance,
not much optus could do.

randy


From peterehiwe at gmail.com  Thu Feb 23 01:49:17 2012
From: peterehiwe at gmail.com (Peter Ehiwe)
Date: Thu, 23 Feb 2012 08:49:17 +0100
Subject: do not filter your customers
In-Reply-To: <m2zkca6nqp.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>
 <m2zkca6nqp.wl%randy@psg.com>
Message-ID: <CADECfTWiZ69bzOA0ZW0ZwZHVV1fkANyO1VgUBH=vd4hziH0ybA@mail.gmail.com>

IOS-XR

On 2/23/12, Randy Bush <randy at psg.com> wrote:
>>> and things when further downhill from there, when telstra also did not
>>> filter what they announced to their peers, and the peers went over
>>> prefix limits and dropped bgp.
>> Oh! so protections worked!
>
> imiho, prefix count is too big a hammer.
>
> it would have been better if optus had irr-based filters in place on
> peerings with telstra.  then they would not have dropped the sessions
> and their customers could still reach telstra customers.
>
> of course, if telstra did not publish accurately in an irr instance,
> not much optus could do.
>
> randy
>
>


-- 
Warm Regards

Peter(CCIE 23782).


From jay at miscreant.org  Thu Feb 23 01:54:34 2012
From: jay at miscreant.org (Jay Mitchell)
Date: Thu, 23 Feb 2012 18:54:34 +1100
Subject: do not filter your customers
In-Reply-To: <m2hayi85t0.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
Message-ID: <9F2FE4E0-25F0-461C-B97B-1418A059A280@miscreant.org>

I'm laughing now, but it wasn't funny a couple of hours ago. Seems a lot of the .au govt needs to learn some carrier diversity...

On 23/02/2012, at 4:41 PM, Randy Bush <randy at psg.com> wrote:

> don't filter your customers.  when they leak the world to you, it will
> get you a lot of free press and your marketing department will love you.
> 
> just ask telstra.
> 
> randy
> 


From me at anuragbhatia.com  Thu Feb 23 02:00:27 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 23 Feb 2012 13:30:27 +0530
Subject: do not filter your customers
In-Reply-To: <m2zkca6nqp.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>
 <m2zkca6nqp.wl%randy@psg.com>
Message-ID: <CAJ0+aXavWOcxxSsqqPGGkjLnqkhcOuMfwaMLUiY=9xQOGQQwMg@mail.gmail.com>

Haha!  Funny

(Sent from my mobile device)

Anurag Bhatia
http://anuragbhatia.com
On Feb 23, 2012 12:27 PM, "Randy Bush" <randy at psg.com> wrote:

> >> and things when further downhill from there, when telstra also did not
> >> filter what they announced to their peers, and the peers went over
> >> prefix limits and dropped bgp.
> > Oh! so protections worked!
>
> imiho, prefix count is too big a hammer.
>
> it would have been better if optus had irr-based filters in place on
> peerings with telstra.  then they would not have dropped the sessions
> and their customers could still reach telstra customers.
>
> of course, if telstra did not publish accurately in an irr instance,
> not much optus could do.
>
> randy
>
>

From me at anuragbhatia.com  Thu Feb 23 02:05:21 2012
From: me at anuragbhatia.com (Anurag Bhatia)
Date: Thu, 23 Feb 2012 13:35:21 +0530
Subject: Question regarding anycasting in CDN setup
In-Reply-To: <20120208200730.GA12862@gweep.net>
References: <CAJ0+aXZiB3XbUqOtV0y+X4VJSQCuYc-ffvPgQ5J=TucXWhfrVA@mail.gmail.com>
 <CAAAas8E7oytFJuFWtxWt_BEugh8yBGSpLY2edYP03jVAHwsk2w@mail.gmail.com>
 <CAJ0+aXaQEbKDawh2JTE+EeogCkDLX1BheTxPN5JZy1TtsBHjrw@mail.gmail.com>
 <CAJ0+aXbEoCsbhM9bmn9zEwxMf153AJg_cEXD+zKaMurg4WGe3Q@mail.gmail.com>
 <20120208200730.GA12862@gweep.net>
Message-ID: <CAJ0+aXYwcY5OtJ3tGO+D3XEC7ZiPAQH5DRHqW7EtmTaoRd2kvg@mail.gmail.com>

Great explanation .

Thanks everyone

(Sent from my mobile device)

Anurag Bhatia
http://anuragbhatia.com
On Feb 9, 2012 1:37 AM, "Joe Provo" <nanog-post at rsuc.gweep.net> wrote:

> On Thu, Feb 09, 2012 at 01:28:07AM +0530, Anurag Bhatia wrote:
> [snip]
> > I have never did such setup, but I assume it works as you say. I wonder
> how
> > it finds a US based system from IP quickly (since it's DNS server)?
>
>
> Drop "ip geolocation" or "internet geolocation" into Your Favorite
> Search Engine. Short answer is some folks just refer to databases
> published/generated by others, some folks use DNS guesses, and some
> folks measure packet arrival. And most often, there is a combination
> of methods used.
>
> --
>         RSUC / GweepNet / Spunk / FnB / Usenix / SAGE / NewNOG
>
>

From CAsensio at nexica.com  Thu Feb 23 03:00:04 2012
From: CAsensio at nexica.com (Carlos Asensio)
Date: Thu, 23 Feb 2012 10:00:04 +0100
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <4F451000.2020107@gmail.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
 <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>
 <4F451000.2020107@gmail.com>
Message-ID: <FCF4EA853883E348957567CD9E90E97301DA90747E@vnxbcnex01.bcn.nexica.com>

Hi Hammer,

Thanks for your answer. That was pretty much what I was thinking.

Thanks to all the offers I've received off-line :).

Best regards,
Carlos.

-----Mensaje original-----
De: -Hammer- [mailto:bhmccie at gmail.com] 
Enviado el: mi?rcoles, 22 de febrero de 2012 16:56
Para: nanog at nanog.org
Asunto: Re: Cisco CAT6500 IOS Simulator

NO.

There is no method. Go to Ebay and buy one. Sorry. Or if you are a big 
enough customer you can ask Cisco to mock up your solution in one of 
their labs.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/22/2012 9:48 AM, Hank Nussbacher wrote:
> On Wed, 22 Feb 2012, Carlos Asensio wrote:
>
> Not supported:
> http://www.gns3.net/hardware-emulated/
>
> -Hank
>
>> Hi John,
>>
>> Thanks for your answer but, as far as I know, with GNS3 we can't run 
>> a CAT6500 IOS.
>>
>> Any alternative?
>>
>> Cheers,
>> Carlos.
>>
>>
>> -----Mensaje original-----
>> De: John Kreno [mailto:john.kreno at gmail.com]
>> Enviado el: mi?rcoles, 22 de febrero de 2012 15:25
>> Para: Carlos Asensio
>> Asunto: Re: Cisco CAT6500 IOS Simulator
>>
>> Try GNS 3
>>
>>
>> On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio <CAsensio at nexica.com> 
>> wrote:
>>> Hi there,
>>>
>>> Anyone know a way of simulate a Cisco CAT6500 IOS?
>>>
>>> We're trying to deploy a lab of our production environment.
>>>
>>> Thanks in advance,
>>> Carlos.
>>
>>
>>
>>



From cdel at firsthand.net  Thu Feb 23 04:22:15 2012
From: cdel at firsthand.net (Christian de Larrinaga)
Date: Thu, 23 Feb 2012 10:22:15 +0000
Subject: do not filter your customers
In-Reply-To: <9F2FE4E0-25F0-461C-B97B-1418A059A280@miscreant.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <9F2FE4E0-25F0-461C-B97B-1418A059A280@miscreant.org>
Message-ID: <91F873E6-C198-48DE-8E0A-75B2060F6DC7@firsthand.net>

not just the .au govt
C
On 23 Feb 2012, at 07:54, Jay Mitchell wrote:

> I'm laughing now, but it wasn't funny a couple of hours ago. Seems a lot of the .au govt needs to learn some carrier diversity...
> 
> On 23/02/2012, at 4:41 PM, Randy Bush <randy at psg.com> wrote:
> 
>> don't filter your customers.  when they leak the world to you, it will
>> get you a lot of free press and your marketing department will love you.
>> 
>> just ask telstra.
>> 
>> randy
>> 
> 



From rsk at gsp.org  Thu Feb 23 05:45:56 2012
From: rsk at gsp.org (Rich Kulawiec)
Date: Thu, 23 Feb 2012 06:45:56 -0500
Subject: Customer Notification System.
In-Reply-To: <4F451929.8030407@gmail.com>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F451929.8030407@gmail.com>
Message-ID: <20120223114556.GA27878@gsp.org>

On Wed, Feb 22, 2012 at 08:34:49AM -0800, JC Dill wrote:
> 99.999% of the time there is absolutely no benefit in the
> attachment.  But by pushing customers to open attachments to get the
> content we are encouraging them to be complacent about opening all
> attachments, and that's a great way to end up getting infected with
> malware.

Spurious attachments also (like HTML markup, another email worst practice
used only by (a) people who don't know any better and (b) spammers) chew
up bandwidth, which is sadly becoming an increasingly expensive commodity
for everyone using mobile devices.  They eat space in mail spools. They
require more resources to be scanned (whether for malware, dubious URLs,
exploits, or anything else).

---rsk


From lowen at pari.edu  Thu Feb 23 07:39:46 2012
From: lowen at pari.edu (Lamar Owen)
Date: Thu, 23 Feb 2012 08:39:46 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <4F455A8B.80809@mompl.net>
References: <4F455A8B.80809@mompl.net>
Message-ID: <201202230839.46959.lowen@pari.edu>

On Wednesday, February 22, 2012 04:13:47 PM Jeroen van Aart wrote:
> Any suggestions and ideas appreciated of course. :-)

www.aleutia.com

DC-powered everything, including a 12VDC LCD monitor.  We're getting one of their D2 Pro dual core Atoms (they have other options for more money) for a solar powered telescope controller, and the specs look good. 

There is a whole market segment out there for the 'Mini ITX' crowd with DC power, low power budgets, and reasonable processors.  Solid State drives have immensely.


From bhmccie at gmail.com  Thu Feb 23 08:13:53 2012
From: bhmccie at gmail.com (-Hammer-)
Date: Thu, 23 Feb 2012 08:13:53 -0600
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <FCF4EA853883E348957567CD9E90E97301DA90747E@vnxbcnex01.bcn.nexica.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
 <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>
 <4F451000.2020107@gmail.com>
 <FCF4EA853883E348957567CD9E90E97301DA90747E@vnxbcnex01.bcn.nexica.com>
Message-ID: <4F4649A1.8060703@gmail.com>

I'm sure that virtualizing the sup would be possible. But having to come 
up with all the line cards would be a nightmare. I'd love for someone 
Internal to tell me I'm wrong but until we can get a 3560 or a 3750X on 
Dynamips I wouldn't push for a 6500 or a Nexus.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/23/2012 3:00 AM, Carlos Asensio wrote:
> Hi Hammer,
>
> Thanks for your answer. That was pretty much what I was thinking.
>
> Thanks to all the offers I've received off-line :).
>
> Best regards,
> Carlos.
>
> -----Mensaje original-----
> De: -Hammer- [mailto:bhmccie at gmail.com]
> Enviado el: mi?rcoles, 22 de febrero de 2012 16:56
> Para: nanog at nanog.org
> Asunto: Re: Cisco CAT6500 IOS Simulator
>
> NO.
>
> There is no method. Go to Ebay and buy one. Sorry. Or if you are a big
> enough customer you can ask Cisco to mock up your solution in one of
> their labs.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/22/2012 9:48 AM, Hank Nussbacher wrote:
>> On Wed, 22 Feb 2012, Carlos Asensio wrote:
>>
>> Not supported:
>> http://www.gns3.net/hardware-emulated/
>>
>> -Hank
>>
>>> Hi John,
>>>
>>> Thanks for your answer but, as far as I know, with GNS3 we can't run
>>> a CAT6500 IOS.
>>>
>>> Any alternative?
>>>
>>> Cheers,
>>> Carlos.
>>>
>>>
>>> -----Mensaje original-----
>>> De: John Kreno [mailto:john.kreno at gmail.com]
>>> Enviado el: mi?rcoles, 22 de febrero de 2012 15:25
>>> Para: Carlos Asensio
>>> Asunto: Re: Cisco CAT6500 IOS Simulator
>>>
>>> Try GNS 3
>>>
>>>
>>> On Wed, Feb 22, 2012 at 6:53 AM, Carlos Asensio<CAsensio at nexica.com>
>>> wrote:
>>>> Hi there,
>>>>
>>>> Anyone know a way of simulate a Cisco CAT6500 IOS?
>>>>
>>>> We're trying to deploy a lab of our production environment.
>>>>
>>>> Thanks in advance,
>>>> Carlos.
>>>
>>>
>>>
>


From bicknell at ufp.org  Thu Feb 23 09:29:35 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Feb 2012 07:29:35 -0800
Subject: Most energy efficient (home) setup
In-Reply-To: <4F455A8B.80809@mompl.net>
References: <4F455A8B.80809@mompl.net>
Message-ID: <20120223152935.GA8659@ussenterprise.ufp.org>

In a message written on Wed, Feb 22, 2012 at 01:13:47PM -0800, Jeroen van Aart wrote:
> After reading a number of threads where people list their huge and 
> wasteful, but undoubtedly fun (and sometimes necessary?), home setups 
> complete with dedicated rooms and aircos I felt inclined to ask who has 
> attempted to make a really energy efficient setup?

I've spent a fair amount of time working on energy effiency at home.
While I've had a rack at my house in the distant past, the cooling
and power bill have always made me work at down sizing.  Also, as
time went by I became more obsessed with quite fans, or in particular
fanless designs.  I hate working in a room with fan noise.

As others have pointed out, there are options these days.  Finding
a competent home router isn't hard, there are plenty of consumer,
fanless devices that can be flashed with OpenWRT or DDWRT.  I've
also used a fanless ALIX PC running a unix OS, works great.  Apple
products like the Mini and Time Capsule are great off the shelf
options for low power and fanless.  Plenty of folks make low power
home theater or car PC's as well.

The area where I think work needs to be done is home file servers.
Most of the low power computer options assume you also want a
super-small case and a disk or two.  Many Atom motherboards only
have a pair of SATA ports, a rare couple have four ports.  There
seems to be this crazy assumption that if you need 5 disks you need
mondo processor, and it's just not true.  I need 5 disks for space,
but if the box can pump it out at 100Mbps I'm more than happy for
home use.  It idles 99.99% of the time.

I'd love a low powered motherboard with 6-8 SATA, and a case with
perhaps 6 hot swap bays but designed for a low powered, fanless
motherboard.  IX Systems's FreeNAS Mini is the closest I've seen,
but it tops out at 4 drives.

But what's really missing is storage management.  RAID5 (and similar)
require all drives to be online all the time.  I'd love an intelligent
file system that could spin down drives when not in use, and even for
many workloads spin up only a portion of the drives.  It's easy to
imagine a system with a small SSD and a pair of disks.  Reads spin one
disk.  Writes go to that disk and the SSD until there are enough, which
spins up the second drive and writes them out as a proper mirror.  In a
home file server drive motors, time you have 4-6 drives, eat most of the
power.  CPU's speed step down nicely, drives don't.

The cloud is great for many things, but only if you have a local copy.
I don't mind serving a web site I push from home out of the cloud, if my
cloud provider dies I get another and push the same data.  It seems like
keeping that local copy safe, secure, and fed with electricty and
cooling takes way more energy (people and electricty) than it should.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120223/d846a0ba/attachment.bin>

From morrowc.lists at gmail.com  Thu Feb 23 09:49:53 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Thu, 23 Feb 2012 10:49:53 -0500
Subject: do not filter your customers
In-Reply-To: <m2zkca6nqp.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <CAL9jLaZs2D-sSJsUtZ_=CkFPF3Ku1WFqePUTiLAHyzCm5u0QWg@mail.gmail.com>
 <m2zkca6nqp.wl%randy@psg.com>
Message-ID: <CAL9jLabgJSBkF9Lw_bYt86wFh0ZS5VwQ8s25jizyWFzm1bddhQ@mail.gmail.com>

On Thu, Feb 23, 2012 at 1:57 AM, Randy Bush <randy at psg.com> wrote:
>>> and things when further downhill from there, when telstra also did not
>>> filter what they announced to their peers, and the peers went over
>>> prefix limits and dropped bgp.
>> Oh! so protections worked!
>
> imiho, prefix count is too big a hammer.

sure. aspath-filter! :)

> it would have been better if optus had irr-based filters in place on
> peerings with telstra. ?then they would not have dropped the sessions
> and their customers could still reach telstra customers.

really, both parties need/should-have filters, right?
both parties should have their 'irr data' up-to-date...
both parties should also filter outbound prefixes (so they don't leak
internals, or ...etc)

telstra seems to have ~8880 or so prefixes registered in IRRs (via
radb whois lookup)
optus has ~1217 or so prefixes registered in IRRs (again via the same
lookup to radb)

> of course, if telstra did not publish accurately in an irr instance,
> not much optus could do.

it's not clear how accurate the data is :( I do see one example that's
not telstra (and which I don't see through telstra from one host I
tested from)
  203.59.57.0/24

a REACH customer, supposedly, registered by REACH on the behalf of the
customer... the whole /16 there is allocated to the same entity not
REACH though, so that's a tad confusing.

-chris


From awentzell at gmail.com  Thu Feb 23 09:55:52 2012
From: awentzell at gmail.com (Andrew Wentzell)
Date: Thu, 23 Feb 2012 10:55:52 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <20120223152935.GA8659@ussenterprise.ufp.org>
References: <4F455A8B.80809@mompl.net>
 <20120223152935.GA8659@ussenterprise.ufp.org>
Message-ID: <CADBpUxUKvdU7fWpb2T2DdCDFhVQFAxyRKh9iWs5BSL-afbNFag@mail.gmail.com>

On Thu, Feb 23, 2012 at 10:29 AM, Leo Bicknell <bicknell at ufp.org> wrote:
> I'd love a low powered motherboard with 6-8 SATA, and a case with
> perhaps 6 hot swap bays but designed for a low powered, fanless
> motherboard. ?IX Systems's FreeNAS Mini is the closest I've seen,
> but it tops out at 4 drives.

Look at Supermicro's X7SPA-H. It's an Atom board with the ICH9R
chipset, and 6 on-board SATA ports.

That one has been out for a while, so there may be something newer
available now too.


From jmaimon at ttec.com  Thu Feb 23 10:06:14 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Thu, 23 Feb 2012 11:06:14 -0500
Subject: automatic bgp route refresh
Message-ID: <4F4663F6.9000909@ttec.com>

Hey All,

I would greatly appreciate it if somebody would point me to cisco 
release notes for the change I see in 15.1 where BGP neighbor route-map 
configurations happen in real time, without needing any clearing, soft 
or otherwise.

Seems like some have also noticed this behavior recently on some other 
trains.

Much obliged.

Best,

Joe




From virendra.rode at gmail.com  Thu Feb 23 11:39:19 2012
From: virendra.rode at gmail.com (virendra rode)
Date: Thu, 23 Feb 2012 09:39:19 -0800
Subject: IX in France
In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
Message-ID: <4F4679C7.8050102@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Brings up another question to mind, how many of you have peered using
partial route transit versus having direct peering relationship at the
exchange?

I've personally ran into companies during peering meetings wanting to
sell you their peering relationship (access to their routes that they've
earned through their relationship) as opposed to you wanting to
establish direct peering relationship.

This way you don't bare port fees, no colocation cost, cost of IX
membership, etc.

I understand this is not true peering relationship, however its an
interesting way to obtain exchange point routes and I understand this is
nothing new.

Just interested in learning about your experiences.


regards,
/virendra

On 02/21/2012 08:46 AM, Ido Szargel wrote:
> Hi All,
> 
>  
> 
> We are currently looking to connect to one of the IX's available in Paris,
> 
> It seems that there are 2 "major" players - FranceIX and Equinix FR, can
> anyone share their opinions about those?
> 
>  
> 
> Thanks,
> 
> Ido
> 
>  
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GeccACgkQ3HuimOHfh+GcBAD8CBJ6Of8ciFMr4ufim8+u7Hpg
cWLXuuqNkgIeQa+jr1gA/27Bqck+d/LEXeoPNJQExUjXMoQC7sNXoPOIHlfrrKF0
=7jTr
-----END PGP SIGNATURE-----


From caldcv at gmail.com  Thu Feb 23 11:44:55 2012
From: caldcv at gmail.com (Chris)
Date: Thu, 23 Feb 2012 12:44:55 -0500
Subject: colosolutions abuse contact?
In-Reply-To: <20120223001550.GI75951@ak-labs.net>
References: <20120223001550.GI75951@ak-labs.net>
Message-ID: <CAPF5agcMEswtu1MYBZO8_S9AYg4Peo+4qGTw0wjym04cH1h_Ag@mail.gmail.com>

If all else fails, contact the uplink. Unfortunately it gets more
response and casually mention "I tried finding a contact but was
unable so I contacted you"



On 2/22/12, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> Hi,
>
> I'm hoping to get a hold of an abuse contact at colosolutions.com.
>
> Any help is greatly appreciated.
>
> If so, please contact me offlist.
>
> Cheers,
> Carlos.
>
>


-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton


From jared at puck.nether.net  Thu Feb 23 12:00:51 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Thu, 23 Feb 2012 13:00:51 -0500
Subject: IX in France
In-Reply-To: <4F4679C7.8050102@gmail.com>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
 <4F4679C7.8050102@gmail.com>
Message-ID: <AB08CDF9-CA46-4D63-ADD9-5EEDBA6599A2@puck.nether.net>


On Feb 23, 2012, at 12:39 PM, virendra rode wrote:

> I understand this is not true peering relationship, however its an
> interesting way to obtain exchange point routes and I understand this is
> nothing new.

<mini-rant>

I've found people who use the term 'peering' to mean something different than what I personally interpret it to mean.

eg: "We have peering with 4 carriers at our colocation facility where you can place gear"

Translation: We have blended IP transit from 4 carriers, or you can directly connect to them as needed.

I understand why they call it this, because "I configured peering with Level3/Cogent" on my router, etc.  The difference is in the policy.  What you're speaking of is someone selling transit, which is perfectly fine over various IXes, you generally are prohibited from 'selling next-hop', i.e.: you have to bear the cost on the IX port of the forwarding.

</mini-rant>

Buying transit isn't as dirty as people think it is, sometimes its the right business decision.  If you connect to an IX for $4000/mo at gig-e, you might as well buy transit at $4/meg on that same port IMHO.  You're unlikely to be using the port at 100% anyways at the IX, so your cost-per-meg there needs to properly reflect your 95% or whatnot.

- Jared

From nick at foobar.org  Thu Feb 23 12:18:25 2012
From: nick at foobar.org (Nick Hilliard)
Date: Thu, 23 Feb 2012 18:18:25 +0000
Subject: IX in France
In-Reply-To: <AB08CDF9-CA46-4D63-ADD9-5EEDBA6599A2@puck.nether.net>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
 <4F4679C7.8050102@gmail.com>
 <AB08CDF9-CA46-4D63-ADD9-5EEDBA6599A2@puck.nether.net>
Message-ID: <4F4682F1.3030001@foobar.org>

On 23/02/2012 18:00, Jared Mauch wrote:
> Buying transit isn't as dirty as people think it is, sometimes its the
> right business decision.  If you connect to an IX for $4000/mo at gig-e,

Anyone prepared to pay $4000/m for a gig IX connection is making the wrong
business decision.

Nick



From virendra.rode at gmail.com  Thu Feb 23 12:28:43 2012
From: virendra.rode at gmail.com (virendra rode)
Date: Thu, 23 Feb 2012 10:28:43 -0800
Subject: IX in France
In-Reply-To: <AB08CDF9-CA46-4D63-ADD9-5EEDBA6599A2@puck.nether.net>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
 <4F4679C7.8050102@gmail.com>
 <AB08CDF9-CA46-4D63-ADD9-5EEDBA6599A2@puck.nether.net>
Message-ID: <4F46855B.2000104@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/23/2012 10:00 AM, Jared Mauch wrote:
> 
> On Feb 23, 2012, at 12:39 PM, virendra rode wrote:
> 
>> I understand this is not true peering relationship, however its an
>> interesting way to obtain exchange point routes and I understand this is
>> nothing new.
> 
> <mini-rant>
- ----------------------
> 
> I've found people who use the term 'peering' to mean something different than what I personally interpret it to mean.
> 
> eg: "We have peering with 4 carriers at our colocation facility where you can place gear"
> 
> Translation: We have blended IP transit from 4 carriers, or you can directly connect to them as needed.
> 
> I understand why they call it this, because "I configured peering with Level3/Cogent" on my router, etc.  The difference is in the policy.  What you're speaking of is someone selling transit, which is perfectly fine over various IXes, you generally are prohibited from 'selling next-hop', i.e.: you have to bear the cost on the IX port of the forwarding.
> 
> </mini-rant>
- ---------------------------
Correct, I meant to say private peering as opposed to settlement-free.


> 
> Buying transit isn't as dirty as people think it is, sometimes its the right business decision.  If you connect to an IX for $4000/mo at gig-e, you might as well buy transit at $4/meg on that same port IMHO.  You're unlikely to be using the port at 100% anyways at the IX, so your cost-per-meg there needs to properly reflect your 95% or whatnot.
> 
> - Jared
- ----------------------
I understand, I'm trying to factor in cost of peering (transport,
equipment, cross-connect, colocation, equipment cost) of buying transit
vs private peering.


regards,
/virendra

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GhVsACgkQ3HuimOHfh+HqFgD+L2WYr2Tt1ZRY+Z2AAVDpX00N
bwNSXKLbnzjy8Ol5b2QA/AiL3NbesEoZy901tBW7TAdAzPOUK8W9a4rnhRakDk8B
=acfM
-----END PGP SIGNATURE-----


From jcdill.lists at gmail.com  Thu Feb 23 12:44:06 2012
From: jcdill.lists at gmail.com (JC Dill)
Date: Thu, 23 Feb 2012 10:44:06 -0800
Subject: Customer Notification System.
In-Reply-To: <0BED6E4A-3731-4904-BE4D-83579FB6A3EB@ifncom.net>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F451929.8030407@gmail.com>
 <0BED6E4A-3731-4904-BE4D-83579FB6A3EB@ifncom.net>
Message-ID: <4F4688F6.9000608@gmail.com>

On 22/02/12 6:46 PM, James Wininger wrote:
> Well we would not be sending the notification in an attachment, but there are times when it would be nice to send a list of circuit ids (exported from billing system as PDF) or some other exported doc to the notification.

Nice for WHO?  There is absolutely no need to export something as simple 
as a list of circuit IDs as a pdf.  Use plain text.  Ditto for the rest 
of your exported DOCs.

When there are exceptions, when you need to include an image (sparingly, 
not because marketing thought it was a good idea to bling up all your 
emails), or a table, send in HTML with plain text.  Don't make the 
recipient start up another program to open an attachment.

jc



From lowen at pari.edu  Thu Feb 23 12:59:18 2012
From: lowen at pari.edu (Lamar Owen)
Date: Thu, 23 Feb 2012 13:59:18 -0500
Subject: common time-management mistake: rack & stack
In-Reply-To: <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
Message-ID: <201202231359.18977.lowen@pari.edu>

On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote:
> I disagree. The best model is - gasp - engineering, a profession which
> many in "networking" claim to be a part of, but few actually are. In the
> engineering world (not CS, not development - think ME and EE), there is
> a strongly defined relationship between junior and senior engineers, and
> real mentorship. 

My degree is in EE, and I spent over a decade in the field as a 'broadcast engineer' Now, a 'broadcast engineer' is not a PE, and is not currently licensed as such, although many of the best consulting broadcast engineers do take the extra step and expense to get the PE license; technically, in many states, you're not even supposed to use the word 'engineer' in your title without having a PE license.

By way of background, my specialty was phased array directional AM broadcast systems in the 5-50KW range, doing 'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements, transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and such.   

I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.).  So I say this with some experience. 

Mentoring in broadcast is still practiced by associations like the Society of Broadcast Engineers and others.  These days, much of this sort of thing is online with websites like www.thebdr.net and mailing lists like those hosted by broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community.

Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still stay in touch, and one who died twenty years ago, a few years after I got started in the field.  RIP W4QA.  He taught me more in half an hour about phased arrays and the way they worked in practice than ten hours of class time could have.  Likewise, I know some old hands here, even if I've not physically met them, whose opinions I trust, even if I don't agree with them. 

> The problem with "networking" is that TOO MANY skills
> are learned on the job (poorly), rather than folks coming in with solid
> fundamentals. 

This is not limited to networking. 

The parallels between broadcast engineering and IT/networking are a little too close for comfort, since there are more potential mentors with weak teaching skills and bad misconceptions that were valid 'back in the day' than there are who will teach practical, working, correct ways of doing things 'today' and why they are done the way they are done (which can involve some history, one of my favorite things). 

A mentor who will teach how to think about why you are doing what you are doing is priceless.  A mentor who will honestly go over the pros and cons of his or her favorite technique and admit that is isn't the single 'correct' way to do something, and a mentor who will teach you how to think sideways, especially when things are broken, are beyond priceless.  I especially like it when a mentor has told me 'now, this isn't necessarily the way I'd do it, and I'm not really fond of it, but you *can* do this to get this result if you need to do so...just don't ask me to fix it later.'

And the recent thread on common misconceptions has been priceless, in my book.  Especially due to some of the respectful disagreements.

> I blame our higher education system for being ineffectual
> in this regard. Most of the "book learning" that you refer to is not
> true theory - it's a mix of vendor prescriptions and
> overgeneralizations. In "networking", you don't learn real theory until
> you're very senior - you learn practice, first. 

Vendor-specific certifications don't help much, either, really, in the 'why' department.

> They also lack real licensing, which
> is a separate problem. 

Now you've stirred the pot!  In the broadcast field, SBE offers some good things in the line of vendor-neutral certification; in the networking field there are some vendor-neutral avenues, such as BiCSI for general stuff and SANS for security stuff.

Having said that, and going back to the broadcast example, not too long ago you had to have an FCC 'First Phone' to even be qualified to read a transmitter's meters, and every broadcast licensee (holding the station's operating license, that is) had to employ 'operators' holding an active First Phone to keep an eye on the transmitter during all operating hours, with the First Phone of every operator posted at the site, and even the DJ's had to have a Third Class Permit to run the audio board, and periodic FCC inspections were frequent.  So that's the extreme situation in terms of licensing, just for reference....




From christophe at clucas.fr  Thu Feb 23 13:04:45 2012
From: christophe at clucas.fr (Christophe Lucas)
Date: Thu, 23 Feb 2012 20:04:45 +0100
Subject: IX in France
In-Reply-To: <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
References: <DFB728D80D51BC489529E01B6D924D8FDC29@DB3PRD0402MB119.eurprd04.prod.outlook.com>
 <7A848D4888ADA94B8A46A17296740133B38D4AE3E2@DEXTER.oasis-tech.local>
Message-ID: <4f2383dcd7b41f4849097d35cb8059e1@www.clucas.fr>

Le 21.02.2012 17:46, Ido Szargel a ?crit?:
> Hi All,
>
>
>
> We are currently looking to connect to one of the IX's available in 
> Paris,
>
> It seems that there are 2 "major" players - FranceIX and Equinix FR, 
> can
> anyone share their opinions about those?
>
>
>
> Thanks,
>
> Ido

Hi,

My former employer is connected to France-IX. I have spent time in 
peering managment and the service/connectivity is good.

My two cents.

Best regards,
-- 
Christophe Lucas
christophe at clucas.fr


From Vinny_Abello at Dell.com  Thu Feb 23 13:28:52 2012
From: Vinny_Abello at Dell.com (Vinny_Abello at Dell.com)
Date: Thu, 23 Feb 2012 19:28:52 +0000
Subject: Customer Notification System.
In-Reply-To: <4F4688F6.9000608@gmail.com>
References: <01245B4ABF809743A84B2F16C6598FEADD38D9@hydrogen>
 <4F451929.8030407@gmail.com>
 <0BED6E4A-3731-4904-BE4D-83579FB6A3EB@ifncom.net>
 <4F4688F6.9000608@gmail.com>
Message-ID: <FD9B2CB2B33E394FAE3B74669547605712B095DF@DFWX10HMPTC01.AMER.DELL.COM>

Paraphrasing someone else........ I would encourage my competitors to send notifications to their customers in PDF format.

:)

-Vinny

-----Original Message-----
From: JC Dill [mailto:jcdill.lists at gmail.com] 
Sent: Thursday, February 23, 2012 1:44 PM
To: NANOG list
Subject: Re: Customer Notification System.

On 22/02/12 6:46 PM, James Wininger wrote:
> Well we would not be sending the notification in an attachment, but there are times when it would be nice to send a list of circuit ids (exported from billing system as PDF) or some other exported doc to the notification.

Nice for WHO?  There is absolutely no need to export something as simple 
as a list of circuit IDs as a pdf.  Use plain text.  Ditto for the rest 
of your exported DOCs.

When there are exceptions, when you need to include an image (sparingly, 
not because marketing thought it was a good idea to bling up all your 
emails), or a table, send in HTML with plain text.  Don't make the 
recipient start up another program to open an attachment.

jc




From bicknell at ufp.org  Thu Feb 23 13:35:39 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Thu, 23 Feb 2012 11:35:39 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <20120217144613.GB70102@ussenterprise.ufp.org>
 <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>
Message-ID: <20120223193539.GA19426@ussenterprise.ufp.org>

In a message written on Wed, Feb 22, 2012 at 12:37:57PM -0800, Dan Golding wrote:
> I disagree. The best model is - gasp - engineering, a profession which
> many in "networking" claim to be a part of, but few actually are. In the
> engineering world (not CS, not development - think ME and EE), there is
> a strongly defined relationship between junior and senior engineers, and
> real mentorship. The problem with "networking" is that TOO MANY skills

Actually, the differences are deeper than you suggest, and it's why
the model you suggest won't work for networking, yet.  I think
there's a chance they may in the future, although it's not a given.

There are several aspects to licensing, but one of the most important
is that the applicant knows basic rules of the profession.  In most
cases these rules are codified into law, and can be tested in a
straitforwad way.  An EE doesn't go around saying "run your circits
at 80% unless you have a 100% duty breaker" because it's a good
idea, or they like it, or their vendor told them do.  They do that
because it's part of the National Electric Code which everyone
(including non-licensed folks) is _required by law_ to follow.

Networking does not have "codes".  There's nothing to test against.
If we wanted to apply a licensed engineer model to the networking
field the first thing that would need to be developed is a set of
comprehensive codes.  Anyone who's experienced PCI (as an example
of an IT attempt at something similar to a code) and also worked
with a more established one (NEC, NFPA, etc) knows that IT isn't
even in the same ballpark yet.  I won't go into the reasons here,
I think there are many and we could discuss that for hours.

But I actually think your analogy is more misplaced because the
names do not line up.  The networking equivilant of an EE or ME is
the "Network Architect".  EE's and ME's are designers in their
professions.  They write up blueprints and plans.  This is also
what network architects do.  Think a CCDA operating as a sales
engineer.  They draw up a design but never implement it.

Network Engineers are the trades people.  We come up with really
dumb names like Network Enginneer 1, 2, 3 and 4.  In a real trade
these would be apprentice, journyman, master, supervisor.  They
take the plans and turn it into something.  In a real trade
(electrican, plumber, hvac, etc) the supervisor interacts with the
apprentice, journeyman and master, who are all working on the same
team.  The subtasks are divided according to skill.

In IT, the Network Engineer 4 thinks he only needs to talk to the
Network Engineer 3.  Everyone else is "below him".  How many companies
have Network Engineer 1's that aren't allowed to even log into many
of their network devices, or call the engineer level 3's and 4's
on the phone?  This is absurd.  Some companies even put them in
different call centers sioled away from each other so they don't
even know who call!  This is where I think we need more mentorship
and teamwork.  When a team of electricans shows up the apprentice
does a lot of the meanial work, but is also allowed to do some of
the higher level work, under strict supervision.

I think, in a sense, we agree more than disagree.  There are established
models for engineering disciplins and IT would probably do better in
many ways if it were to fall in line.  Licensed folks working in
architecture and design.  Codes to standardize and provide quality
control and safety.  Apprenticed skilled trades to implement.  What
we're arguing over here is some minor semantics of how that structure
works in IT.

HOWEVER, I am not sure it completely works.  Here's why; some
colleges have C.S. in the Arts and Sciences college, and treat how
to program more like how to write a novel than how to build a bridge.
Others have it in the Engineering college, and treat it more like
building a bridge than writing an novel.  What seems to work is a
blend in the real world, treating most IT tasks like classical
engineering doesn't work out well, nor does treating it like writing
a book.  IT isn't governed by the same hard (physical) rules as
traditional engineering, but you also can't be freely creative and
expect to come up with something that works.

I personally would like to see the industry work on the "code"
problem, which would be necessary pre-work for licensing.  I'd also
like to see trade style mentoring.  I think those can proceed in
parallel.  I'm just personally prepared for the eventuality that
IT might never fit into as ridgid a framework as EE or ME.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120223/1efc1bbd/attachment.bin>

From dholmes at mwdh2o.com  Thu Feb 23 13:54:47 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Thu, 23 Feb 2012 11:54:47 -0800
Subject: common time-management mistake: rack & stack
In-Reply-To: <201202231359.18977.lowen@pari.edu>
References: <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>
 <201202231359.18977.lowen@pari.edu>
Message-ID: <922ACC42D498884AA02B3565688AF9953405312D4B@USEXMBS01.mwd.h2o>

The problem with using engineering as a model is that computer science networking theory is based upon mathematical logic and formal mathematics (for instance Finite State Machines, Turing Machines), and operates on what are essentially robotic automatons running in real time. Engineering as I have experienced it, operates according to construction time frames using CSI specifications, preliminary design reviews, and various iterations of final design reviews involving engineering drawings and CSI-format specification documents where a 6 year start-to-finish time frame is not unusual. The number of PEs who can operate in real time is but a fraction of all PEs, and those who can plan a project with a 1 week time frame, and implement the project at 3 am in the morning is a yet smaller fraction. ( and don't even think about the number of PEs who can get a 3 am call and must fix a broken network ASAP).

Not everyone has the ability to grasp mathematical logic, even though they have been able to get an engineering degree.

Engineers have no peers in the ability to build bridges, skyscrapers, and other large construction projects, but this ability does not transfer to computer science, and computer networking.

-----Original Message-----
From: Lamar Owen [mailto:lowen at pari.edu]
Sent: Thursday, February 23, 2012 10:59 AM
To: nanog at nanog.org
Subject: Re: common time-management mistake: rack & stack

On Wednesday, February 22, 2012 03:37:57 PM Dan Golding wrote:
> I disagree. The best model is - gasp - engineering, a profession which
> many in "networking" claim to be a part of, but few actually are. In the
> engineering world (not CS, not development - think ME and EE), there is
> a strongly defined relationship between junior and senior engineers, and
> real mentorship.

My degree is in EE, and I spent over a decade in the field as a 'broadcast engineer' Now, a 'broadcast engineer' is not a PE, and is not currently licensed as such, although many of the best consulting broadcast engineers do take the extra step and expense to get the PE license; technically, in many states, you're not even supposed to use the word 'engineer' in your title without having a PE license.

By way of background, my specialty was phased array directional AM broadcast systems in the 5-50KW range, doing 'technician' things like phasor rocking, transmitter retubing and retuning, monitor point and radial measurements, transmitter installation, and tower climbing, in addition to more mathematical and engineering sorts of things like initial coverage and protection studies for pattern/power changes, measured radial ground conductivity/dielectric constant curve fitting/prediction contour overlap studies and models, as well as keeping up with FCC regulations and such.

I left broadcasting full-time in 2003 for an IT position, as a stress-reducer (and it worked.).  So I say this with some experience.

Mentoring in broadcast is still practiced by associations like the Society of Broadcast Engineers and others.  These days, much of this sort of thing is online with websites like www.thebdr.net and mailing lists like those hosted by broadcast.net; in this regard the network ops community isn't too dissimilar from the broadcast community.

Now, while in the broadcast role I had the distinct honor of having three fantastic personal mentors, two of whom still stay in touch, and one who died twenty years ago, a few years after I got started in the field.  RIP W4QA.  He taught me more in half an hour about phased arrays and the way they worked in practice than ten hours of class time could have.  Likewise, I know some old hands here, even if I've not physically met them, whose opinions I trust, even if I don't agree with them.

> The problem with "networking" is that TOO MANY skills
> are learned on the job (poorly), rather than folks coming in with solid
> fundamentals.

This is not limited to networking.

The parallels between broadcast engineering and IT/networking are a little too close for comfort, since there are more potential mentors with weak teaching skills and bad misconceptions that were valid 'back in the day' than there are who will teach practical, working, correct ways of doing things 'today' and why they are done the way they are done (which can involve some history, one of my favorite things).

A mentor who will teach how to think about why you are doing what you are doing is priceless.  A mentor who will honestly go over the pros and cons of his or her favorite technique and admit that is isn't the single 'correct' way to do something, and a mentor who will teach you how to think sideways, especially when things are broken, are beyond priceless.  I especially like it when a mentor has told me 'now, this isn't necessarily the way I'd do it, and I'm not really fond of it, but you *can* do this to get this result if you need to do so...just don't ask me to fix it later.'

And the recent thread on common misconceptions has been priceless, in my book.  Especially due to some of the respectful disagreements.

> I blame our higher education system for being ineffectual
> in this regard. Most of the "book learning" that you refer to is not
> true theory - it's a mix of vendor prescriptions and
> overgeneralizations. In "networking", you don't learn real theory until
> you're very senior - you learn practice, first.

Vendor-specific certifications don't help much, either, really, in the 'why' department.

> They also lack real licensing, which
> is a separate problem.

Now you've stirred the pot!  In the broadcast field, SBE offers some good things in the line of vendor-neutral certification; in the networking field there are some vendor-neutral avenues, such as BiCSI for general stuff and SANS for security stuff.

Having said that, and going back to the broadcast example, not too long ago you had to have an FCC 'First Phone' to even be qualified to read a transmitter's meters, and every broadcast licensee (holding the station's operating license, that is) had to employ 'operators' holding an active First Phone to keep an eye on the transmitter during all operating hours, with the First Phone of every operator posted at the site, and even the DJ's had to have a Third Class Permit to run the audio board, and periodic FCC inspections were frequent.  So that's the extreme situation in terms of licensing, just for reference....




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.


From isabeldias1 at yahoo.com  Thu Feb 23 14:00:59 2012
From: isabeldias1 at yahoo.com (isabel dias)
Date: Thu, 23 Feb 2012 12:00:59 -0800 (PST)
Subject: common time-management mistake: rack & stack
In-Reply-To: <20120223193539.GA19426@ussenterprise.ufp.org>
References: <CAPWAtbLe+PCM8+JRKo5op5v_HTr8q3JBu9qmymKyCOw66nHhUw@mail.gmail.com>
 <20120217144613.GB70102@ussenterprise.ufp.org>
 <1C7B96053DD7814496A0D1E71661B6830288270A@SMF-ENTXM-001.sac.ragingwire.net>
 <20120223193539.GA19426@ussenterprise.ufp.org>
Message-ID: <1330027259.84483.YahooMailNeo@web121605.mail.ne1.yahoo.com>

1- what do you mean by "Licensed folks working in architecture and design"?
?
2- You wrote "IT isn't governed by the same hard (physical) rules as
traditional engineering, but you also can't be freely creative and
expect to come up with something that works." bolox!
As far as I'm aware you are not showing any creative work that requires the copywrite/authoring work. Unfortunatly the great majority of us are "users" of the system.?There are different levels of users, some more cleaver than others.
?
The one that looks for data sets in databases in in IT and so is into "scripting" and CShell.
?
The sponsor is the issue.He was tasked to do so!?have you ever been employed or have been offered employment by someone that has a lower weight than you have?
the frameworks seem to be known more and more and still................some face unemployment whereas others are and will always be your sponsors- think about the director of your local post office? :-)
?
Have you ever thought the reason why you are doing what you are doing instead of signing a PO?
?
Who's business is this ? do you know why you are required to have at least three A levels? and at least two MSc/MA? Or even maybe a PhD? Where exactly are you based?
?
?
?
?
?
?
?
?
?


________________________________
From: Leo Bicknell <bicknell at ufp.org>
To: Dan Golding <dgolding at ragingwire.com> 
Cc: NANOG <nanog at nanog.org> 
Sent: Thursday, February 23, 2012 7:35 PM
Subject: Re: common time-management mistake: rack & stack

In a message written on Wed, Feb 22, 2012 at 12:37:57PM -0800, Dan Golding wrote:
> I disagree. The best model is - gasp - engineering, a profession which
> many in "networking" claim to be a part of, but few actually are. In the
> engineering world (not CS, not development - think ME and EE), there is
> a strongly defined relationship between junior and senior engineers, and
> real mentorship. The problem with "networking" is that TOO MANY skills

Actually, the differences are deeper than you suggest, and it's why
the model you suggest won't work for networking, yet.? I think
there's a chance they may in the future, although it's not a given.

There are several aspects to licensing, but one of the most important
is that the applicant knows basic rules of the profession.? In most
cases these rules are codified into law, and can be tested in a
straitforwad way.? An EE doesn't go around saying "run your circits
at 80% unless you have a 100% duty breaker" because it's a good
idea, or they like it, or their vendor told them do.? They do that
because it's part of the National Electric Code which everyone
(including non-licensed folks) is _required by law_ to follow.

Networking does not have "codes".? There's nothing to test against.
If we wanted to apply a licensed engineer model to the networking
field the first thing that would need to be developed is a set of
comprehensive codes.? Anyone who's experienced PCI (as an example
of an IT attempt at something similar to a code) and also worked
with a more established one (NEC, NFPA, etc) knows that IT isn't
even in the same ballpark yet.? I won't go into the reasons here,
I think there are many and we could discuss that for hours.

But I actually think your analogy is more misplaced because the
names do not line up.? The networking equivilant of an EE or ME is
the "Network Architect".? EE's and ME's are designers in their
professions.? They write up blueprints and plans.? This is also
what network architects do.? Think a CCDA operating as a sales
engineer.? They draw up a design but never implement it.

Network Engineers are the trades people.? We come up with really
dumb names like Network Enginneer 1, 2, 3 and 4.? In a real trade
these would be apprentice, journyman, master, supervisor.? They
take the plans and turn it into something.? In a real trade
(electrican, plumber, hvac, etc) the supervisor interacts with the
apprentice, journeyman and master, who are all working on the same
team.? The subtasks are divided according to skill.

In IT, the Network Engineer 4 thinks he only needs to talk to the
Network Engineer 3.? Everyone else is "below him".? How many companies
have Network Engineer 1's that aren't allowed to even log into many
of their network devices, or call the engineer level 3's and 4's
on the phone?? This is absurd.? Some companies even put them in
different call centers sioled away from each other so they don't
even know who call!? This is where I think we need more mentorship
and teamwork.? When a team of electricans shows up the apprentice
does a lot of the meanial work, but is also allowed to do some of
the higher level work, under strict supervision.

I think, in a sense, we agree more than disagree.? There are established
models for engineering disciplins and IT would probably do better in
many ways if it were to fall in line.? Licensed folks working in
architecture and design.? Codes to standardize and provide quality
control and safety.? Apprenticed skilled trades to implement.? What
we're arguing over here is some minor semantics of how that structure
works in IT.

HOWEVER, I am not sure it completely works.? Here's why; some
colleges have C.S. in the Arts and Sciences college, and treat how
to program more like how to write a novel than how to build a bridge.
Others have it in the Engineering college, and treat it more like
building a bridge than writing an novel.? What seems to work is a
blend in the real world, treating most IT tasks like classical
engineering doesn't work out well, nor does treating it like writing
a book.? IT isn't governed by the same hard (physical) rules as
traditional engineering, but you also can't be freely creative and
expect to come up with something that works.

I personally would like to see the industry work on the "code"
problem, which would be necessary pre-work for licensing.? I'd also
like to see trade style mentoring.? I think those can proceed in
parallel.? I'm just personally prepared for the eventuality that
IT might never fit into as ridgid a framework as EE or ME.

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

From myeaddress at gmail.com  Thu Feb 23 14:11:36 2012
From: myeaddress at gmail.com (Maverick)
Date: Thu, 23 Feb 2012 15:11:36 -0500
Subject: Network Traffic Collection
Message-ID: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>

Hello,

I am trying to collect traffic traffic from pcap file and store it in
a database but really confused how to organize it. Should I organize
it on connection basis/ flow basis or IP basis.

It might be an effort to write a customized traffic analysis tool like
wireshark with only required functionality. I would really appreciate
if someone can give me direction on write way of organizing the data
because right now I only see individual packets and no way of putting
them in some order.

Best,
Ali


From jeroen at unfix.org  Thu Feb 23 14:14:19 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 23 Feb 2012 21:14:19 +0100
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
Message-ID: <4F469E1B.1040100@unfix.org>

On 2012-02-23 21:11 , Maverick wrote:
> Hello,
> 
> I am trying to collect traffic traffic from pcap file and store it in
> a database but really confused how to organize it. Should I organize
> it on connection basis/ flow basis or IP basis.
> 
> It might be an effort to write a customized traffic analysis tool like
> wireshark with only required functionality. I would really appreciate
> if someone can give me direction on write way of organizing the data
> because right now I only see individual packets and no way of putting
> them in some order.

Does this all not completely depend on what you actually want to do with
it? You might want to start there instead of the other way around.

Greets,
 Jeroen



From myeaddress at gmail.com  Thu Feb 23 14:19:24 2012
From: myeaddress at gmail.com (Maverick)
Date: Thu, 23 Feb 2012 15:19:24 -0500
Subject: Network Traffic Collection
In-Reply-To: <4F469E1B.1040100@unfix.org>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
Message-ID: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>

I want to be able to see information like how much traffic an ip send
over a period of time, what machines it talked to etc from this
perspective it should be IP based but I would really like to know how
other people do it.

Best,
Ali

On Thu, Feb 23, 2012 at 3:14 PM, Jeroen Massar <jeroen at unfix.org> wrote:
> On 2012-02-23 21:11 , Maverick wrote:
>> Hello,
>>
>> I am trying to collect traffic traffic from pcap file and store it in
>> a database but really confused how to organize it. Should I organize
>> it on connection basis/ flow basis or IP basis.
>>
>> It might be an effort to write a customized traffic analysis tool like
>> wireshark with only required functionality. I would really appreciate
>> if someone can give me direction on write way of organizing the data
>> because right now I only see individual packets and no way of putting
>> them in some order.
>
> Does this all not completely depend on what you actually want to do with
> it? You might want to start there instead of the other way around.
>
> Greets,
> ?Jeroen
>


From MatlockK at exempla.org  Thu Feb 23 14:20:23 2012
From: MatlockK at exempla.org (Matlock, Kenneth L)
Date: Thu, 23 Feb 2012 13:20:23 -0700
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
Message-ID: <4288131ED5E3024C9CD4782CECCAD2C710B04C6D@LMC-MAIL2.exempla.org>

Netflow + netflow collector.

Ken Matlock
Network Analyst
Systems and Technology Service Center
Sisters of Charity of Leavenworth Health System 
12600 W. Colfax, Suite A-500
Lakewood, CO 80215
 
303-467-4671
matlockk at exempla.org
 
-----Original Message-----
From: Maverick [mailto:myeaddress at gmail.com] 
Sent: Thursday, February 23, 2012 1:19 PM
To: Jeroen Massar
Cc: nanog at nanog.org
Subject: Re: Network Traffic Collection

I want to be able to see information like how much traffic an ip send over a period of time, what machines it talked to etc from this perspective it should be IP based but I would really like to know how other people do it.

Best,
Ali

On Thu, Feb 23, 2012 at 3:14 PM, Jeroen Massar <jeroen at unfix.org> wrote:
> On 2012-02-23 21:11 , Maverick wrote:
>> Hello,
>>
>> I am trying to collect traffic traffic from pcap file and store it in 
>> a database but really confused how to organize it. Should I organize 
>> it on connection basis/ flow basis or IP basis.
>>
>> It might be an effort to write a customized traffic analysis tool 
>> like wireshark with only required functionality. I would really 
>> appreciate if someone can give me direction on write way of 
>> organizing the data because right now I only see individual packets 
>> and no way of putting them in some order.
>
> Does this all not completely depend on what you actually want to do 
> with it? You might want to start there instead of the other way around.
>
> Greets,
> ?Jeroen
>

*** Exempla Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** Exempla Confidentiality Notice ***



From sraja97 at gmail.com  Thu Feb 23 14:29:51 2012
From: sraja97 at gmail.com (Suresh Rajagopalan)
Date: Thu, 23 Feb 2012 12:29:51 -0800
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
Message-ID: <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>

On Thu, Feb 23, 2012 at 12:19 PM, Maverick <myeaddress at gmail.com> wrote:
> I want to be able to see information like how much traffic an ip send
> over a period of time, what machines it talked to etc from this
> perspective it should be IP based but I would really like to know how
> other people do it.
>


Run argus on a span port.

-Suresh


From mike.lyon at gmail.com  Thu Feb 23 14:34:58 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 23 Feb 2012 10:34:58 -1000
Subject: Network Traffic Collection
In-Reply-To: <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>
Message-ID: <-7963108524144646278@unknownmsgid>

Random thought, anyone ever used Splunk for this kind of thing?

-mike

Sent from my iPhone

On Feb 23, 2012, at 10:30, Suresh Rajagopalan <sraja97 at gmail.com> wrote:

> On Thu, Feb 23, 2012 at 12:19 PM, Maverick <myeaddress at gmail.com> wrote:
>> I want to be able to see information like how much traffic an ip send
>> over a period of time, what machines it talked to etc from this
>> perspective it should be IP based but I would really like to know how
>> other people do it.
>>
>
>
> Run argus on a span port.
>
> -Suresh
>


From virendra.rode at gmail.com  Thu Feb 23 14:47:49 2012
From: virendra.rode at gmail.com (virendra rode)
Date: Thu, 23 Feb 2012 12:47:49 -0800
Subject: do not filter your customers
In-Reply-To: <m2hayi85t0.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
Message-ID: <4F46A5F5.1090008@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Speaking of leaking the world, I remember one of our transit peer during
their nightly maintenance decided they needed people to talk to, so they
decided to share some love by passing ~ 350k routes causing a meltdown.

As lesson learned, we included a combination of prefix-list &
maximum-prefix filters as part of our config script.

When the hard limit hits a certain percentage, we get alerted that the
neighbor is approaching the limit.


regards,
/virendra

On 02/22/2012 09:41 PM, Randy Bush wrote:
> don't filter your customers.  when they leak the world to you, it will
> get you a lot of free press and your marketing department will love you.
> 
> just ask telstra.
> 
> randy
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9GpfUACgkQ3HuimOHfh+HwZgD/dlgPaTsxCs0cyRFVBsDI2J5i
/dLwyQrUADOySuKlgn0A/iuF+gojyqIbLwstPin0Je06KDytE8AYsNuwLXCmAWI5
=qrOK
-----END PGP SIGNATURE-----


From jason at lixfeld.ca  Thu Feb 23 14:51:15 2012
From: jason at lixfeld.ca (Jason Lixfeld)
Date: Thu, 23 Feb 2012 15:51:15 -0500
Subject: Network Traffic Collection
In-Reply-To: <-7963108524144646278@unknownmsgid>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>
 <-7963108524144646278@unknownmsgid>
Message-ID: <CF5E67C0-FF66-475F-83DD-AFDC1467052D@lixfeld.ca>

Splunk is an amazing tool and did an awesome thing and introduced a free license in 4.3.

I'm using it at two sites now and I'm loving it!

On 2012-02-23, at 3:34 PM, Mike Lyon wrote:

> Random thought, anyone ever used Splunk for this kind of thing?
> 
> -mike
> 
> Sent from my iPhone
> 
> On Feb 23, 2012, at 10:30, Suresh Rajagopalan <sraja97 at gmail.com> wrote:
> 
>> On Thu, Feb 23, 2012 at 12:19 PM, Maverick <myeaddress at gmail.com> wrote:
>>> I want to be able to see information like how much traffic an ip send
>>> over a period of time, what machines it talked to etc from this
>>> perspective it should be IP based but I would really like to know how
>>> other people do it.
>>> 
>> 
>> 
>> Run argus on a span port.
>> 
>> -Suresh
>> 
> 



From jeroen at unfix.org  Thu Feb 23 14:52:23 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Thu, 23 Feb 2012 21:52:23 +0100
Subject: Network Traffic Collection
In-Reply-To: <-7963108524144646278@unknownmsgid>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>
 <-7963108524144646278@unknownmsgid>
Message-ID: <4F46A707.3080301@unfix.org>

On 2012-02-23 21:34 , Mike Lyon wrote:
> Random thought, anyone ever used Splunk for this kind of thing?

Various folks have, the problem of course comes down to processing
power, thus you'll need to throw a lot of hardware against it to be able
to process traffic in a decent network.

Check http://www.raffy.ch/ and http://pixlcloud.com/ etc for more
details about this.

Greets,
 Jeroen


From mike.lyon at gmail.com  Thu Feb 23 15:18:43 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Thu, 23 Feb 2012 11:18:43 -1000
Subject: Network Traffic Collection
In-Reply-To: <4F46A707.3080301@unfix.org>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <CAOvcAgAPAyAp1QU-0xw6mzpPE3OYkLShec-macpgT26GEE8oJQ@mail.gmail.com>
 <-7963108524144646278@unknownmsgid> <4F46A707.3080301@unfix.org>
Message-ID: <1074378242116011525@unknownmsgid>

Run it with hadoop in EC2?

Sent from my iPhone

On Feb 23, 2012, at 10:52, Jeroen Massar <jeroen at unfix.org> wrote:

> On 2012-02-23 21:34 , Mike Lyon wrote:
>> Random thought, anyone ever used Splunk for this kind of thing?
>
> Various folks have, the problem of course comes down to processing
> power, thus you'll need to throw a lot of hardware against it to be able
> to process traffic in a decent network.
>
> Check http://www.raffy.ch/ and http://pixlcloud.com/ etc for more
> details about this.
>
> Greets,
> Jeroen


From jgreco at ns.sol.net  Thu Feb 23 15:53:06 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Thu, 23 Feb 2012 15:53:06 -0600 (CST)
Subject: Most energy efficient (home) setup
In-Reply-To: <20120223152935.GA8659@ussenterprise.ufp.org>
Message-ID: <201202232153.q1NLr6F7071434@aurora.sol.net>

> I've spent a fair amount of time working on energy effiency at home.
> While I've had a rack at my house in the distant past, the cooling
> and power bill have always made me work at down sizing.  Also, as
> time went by I became more obsessed with quite fans, or in particular
> fanless designs.  I hate working in a room with fan noise.

So, good group to ask, probably...  anyone have suggestions for a low-
noise, low-power GigE switch in the 24-port range ... managed, with SFP?
That doesn't require constant rebooting?

I'm sure I'll get laughed at for saying we like the Dell 5324.  It's a
competent switch that we've had good luck with for half a decade.  The
RPS is noisy as heck, though, and overall consumption is something like
maybe 80 watts per switch (incl RPS).

> The area where I think work needs to be done is home file servers.
> Most of the low power computer options assume you also want a
> super-small case and a disk or two.  Many Atom motherboards only
> have a pair of SATA ports, a rare couple have four ports.  There
> seems to be this crazy assumption that if you need 5 disks you need
> mondo processor, and it's just not true.  I need 5 disks for space,
> but if the box can pump it out at 100Mbps I'm more than happy for
> home use.  It idles 99.99% of the time.
> 
> I'd love a low powered motherboard with 6-8 SATA, and a case with
> perhaps 6 hot swap bays but designed for a low powered, fanless
> motherboard.  IX Systems's FreeNAS Mini is the closest I've seen,
> but it tops out at 4 drives.
> 
> But what's really missing is storage management.  RAID5 (and similar)
> require all drives to be online all the time.  I'd love an intelligent
> file system that could spin down drives when not in use, and even for
> many workloads spin up only a portion of the drives.  It's easy to
> imagine a system with a small SSD and a pair of disks.  Reads spin one
> disk.  Writes go to that disk and the SSD until there are enough, which
> spins up the second drive and writes them out as a proper mirror.  In a
> home file server drive motors, time you have 4-6 drives, eat most of the
> power.  CPU's speed step down nicely, drives don't.

FreeNAS can cope with ATA idle spindowns.  You don't need to have all the
drives spun up all the time.  But it's a lot more dumb than it maybe could
be.  What do you consider a reasonable power budget to be?

> The cloud is great for many things, but only if you have a local copy.
> I don't mind serving a web site I push from home out of the cloud, if my
> cloud provider dies I get another and push the same data.  It seems like
> keeping that local copy safe, secure, and fed with electricty and
> cooling takes way more energy (people and electricty) than it should.

Quite frankly, and I'm going to get some flak for saying this I bet, I am
very disappointed at how poorly the Internet community and related vendors
have been at making useful software, hardware, and services that mere 
mortals can use that do not also marry them to some significant gotchas 
(or their own proprietary platforms and/or services). Part of the reason 
that people wish to outsource their problems is because it hasn't been
made easy to handle them yourself.

Look at e-mail service as just one example.  What the average user wants
is to be able to get and send e-mail.  Think of how much effort it is to
set up an e-mail system, with spam filtering, a web frontend, and all the
other little things.  I've been building e-mail services on the Internet
for more than a quarter of a century, and as far as I can tell, it has
not gotten easier - it's gotten worse.  Most people just concede defeat
without even trying at this point, point their domains at Gmail, and let
someone else handle it.

What about services like Flickr?  We've completely failed at providing
strategies for users to retain their pictures locally without putting
them at risk.  By that, I mean that Microsoft (for example) has made it 
nice and easy for users to pull their digital photos off their cameras, 
but has failed to impress upon users that their computers are not 
redundant or reliable, and then when a hard drive fails, years worth
of pictures vanish in a moment.  So that frustrates users, who then go
to services like Flickr, upload their content there, and their data lies
on a server somewhere, awaiting the day the business implodes, or gets
T-Mo Sidekick'ed, or whatever.

This frustrates me, seeing as how we've had so much time in which this
stuff could have been made significantly more usable and useful...

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From streiner at cluebyfour.org  Thu Feb 23 15:59:55 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Thu, 23 Feb 2012 16:59:55 -0500 (EST)
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202231655440.22135@whammy.cluebyfour.org>

On Thu, 23 Feb 2012, Maverick wrote:

> I want to be able to see information like how much traffic an ip send
> over a period of time, what machines it talked to etc from this
> perspective it should be IP based but I would really like to know how
> other people do it.

Truth is that most people probably don't do it, beyond temporary, ad-hoc 
deployments, to solve a specific problem at a specific point in time. 
Traffic capture and analysis doesn't scale too well into multi-Gb/s 
service provider environments.

Netflow tools are an option if 'reasonably accurate' is good enough for 
your needs.

jms


From james at smithwaysecurity.com  Thu Feb 23 16:17:38 2012
From: james at smithwaysecurity.com (James Smith)
Date: Thu, 23 Feb 2012 18:17:38 -0400
Subject: Botnet Traffic
Message-ID: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>

Hello,

Can anyone on this list provide botnet network traffic for analysis, or Ip?s which have been infected.
-- 
Sincerely;


James Smith
CEO, CEH, Security Analyst
Email: james at smithwaysecurity.com
Phone: 1877-760-1953
Website: www.SmithwaySecurity.com


CONFIDENTIALITY NOTICE: This communication with its contents may contain confidential and/or legally privileged information. It is solely for the use of the intended recipient(s). Unauthorized interception, review, use or disclosure is prohibited and may violate applicable laws including the Electronic Communications Privacy Act. If you are not the intended recipient, please contact the sender and destroy all copies of the communication.

- This communication is confidential to the parties it was intended to serve -

From lowen at pari.edu  Thu Feb 23 16:21:03 2012
From: lowen at pari.edu (Lamar Owen)
Date: Thu, 23 Feb 2012 17:21:03 -0500
Subject: Most energy efficient (home) setup
In-Reply-To: <201202232153.q1NLr6F7071434@aurora.sol.net>
References: <201202232153.q1NLr6F7071434@aurora.sol.net>
Message-ID: <201202231721.03510.lowen@pari.edu>

On Thursday, February 23, 2012 04:53:06 PM Joe Greco wrote:
> So, good group to ask, probably...  anyone have suggestions for a low-
> noise, low-power GigE switch in the 24-port range ... managed, with SFP?
> That doesn't require constant rebooting?

I can't comment to the rebooting, but a couple of years ago I looked at the Allied-Telesis AT-9000-28SP, which is a smack steeply priced (~$1,500) but has flexible optics and is managed.  And at ~35 watts is the lowest powered managed gigabit switch I was able to find for our solar powered telescopes.  The grant that was going to fund that fell through, so I'm still running the 90W+ Catalyst 2900XL with two 1000Base-X modules and 24 10/100 ports instead, but the AT unit looked pretty good as a pretty much direct replacement with extra bandwidth.


From djahandarie at gmail.com  Thu Feb 23 16:26:48 2012
From: djahandarie at gmail.com (Darius Jahandarie)
Date: Thu, 23 Feb 2012 17:26:48 -0500
Subject: Botnet Traffic
In-Reply-To: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>
References: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>
Message-ID: <CAFANWtUbiXTGubZq63EaX9MwrREWV0T0pKoisTfi6=axAv_z2w@mail.gmail.com>

On Thu, Feb 23, 2012 at 17:17, James Smith <james at smithwaysecurity.com> wrote:
> Can anyone on this list provide botnet network traffic for analysis, or Ip?s which have been infected.

Have you considered contacting Team Cymru or Shadowserver? As far as I
know, they are the two major groups who collect this sort of
information on a non-local scale. I believe Team Cymru at least has
someone who follows NANOG..

The largest issue here is going to be trust -- it is highly unlikely
your just going to get huge dumps of useful information, especially if
your intentions are for-profit.


Best of luck.

-- 
Darius Jahandarie


From jtk at cymru.com  Thu Feb 23 16:42:47 2012
From: jtk at cymru.com (John Kristoff)
Date: Thu, 23 Feb 2012 16:42:47 -0600
Subject: Botnet Traffic
In-Reply-To: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>
References: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>
Message-ID: <20120223164247.7691f094@w520.localdomain>

On Thu, 23 Feb 2012 18:17:38 -0400
"James Smith" <james at smithwaysecurity.com> wrote:

> Can anyone on this list provide botnet network traffic for analysis,
> or Ip?s which have been infected.

Hi James,

Normally few people are going to be unwilling to provide such a thing,
at least for live or recently active botnets to the general public.  In
essence, few people like to spread that sort of dirty laundry around to
anyone who comes asking in a public forum.

However, there is some public data available in various locations.  For
instance, the Dragon Research Group (DRG) provides some public data it
sees on the well known HTTP, VNC and SSH ports.  The SSH report is
primarily compiled from random SSH brute force spreading worms.

  <http://dragonresearchgroup.org/insight/>

Note, I'm one of the DRG volunteers.

You can browse around the SANS ISC reports and get an idea of what they
see from various hosts and networks too.

  <http://isc.sans.edu/reports.html>

I'm not involved with that organization.

Lenny Zeltser has a page detailing where you might get some sample
malware to research:

  <http://zeltser.com/combating-malicious-software/malware-sample-sources.html>

There are likely many other sources of info if you dig around,
but you may be better off asking in another forum where security,
rather than networking is the major theme.  Feel free to contact me off
list and I'll see if I can help introduce you to the appropriate venues.

John


From james at smithwaysecurity.com  Thu Feb 23 16:46:42 2012
From: james at smithwaysecurity.com (James Smith)
Date: Thu, 23 Feb 2012 18:46:42 -0400
Subject: Botnet Traffic
In-Reply-To: <CAFANWtUbiXTGubZq63EaX9MwrREWV0T0pKoisTfi6=axAv_z2w@mail.gmail.com>
References: <BAB325A54D484A6B8BFE3221C466AA5A@smithwaIntell>
 <CAFANWtUbiXTGubZq63EaX9MwrREWV0T0pKoisTfi6=axAv_z2w@mail.gmail.com>
Message-ID: <CCA1314539764D13AA5062E1DB9D4B32@smithwaIntell>

Thank you, this will be helpful.

-----Original Message----- 
From: Darius Jahandarie
Sent: Thursday, February 23, 2012 6:26 PM
To: James Smith
Cc: nanog at nanog.org
Subject: Re: Botnet Traffic

On Thu, Feb 23, 2012 at 17:17, James Smith <james at smithwaysecurity.com> 
wrote:
> Can anyone on this list provide botnet network traffic for analysis, or Ip?s 
> which have been infected.

Have you considered contacting Team Cymru or Shadowserver? As far as I
know, they are the two major groups who collect this sort of
information on a non-local scale. I believe Team Cymru at least has
someone who follows NANOG..

The largest issue here is going to be trust -- it is highly unlikely
your just going to get huge dumps of useful information, especially if
your intentions are for-profit.


Best of luck.

-- 
Darius Jahandarie 



From surfer at mauigateway.com  Thu Feb 23 16:51:35 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Thu, 23 Feb 2012 14:51:35 -0800
Subject: Network Traffic Collection
Message-ID: <20120223145135.A87E958D@resin11.mta.everyone.net>



----------- myeaddress at gmail.com wrote: ----------
From: Maverick <myeaddress at gmail.com>

>> It might be an effort to write a customized traffic analysis tool like
>> wireshark with only required functionality. I would really appreciate


I want to be able to see information like how much traffic an ip send
over a period of time, what machines it talked to etc from this
perspective it should be IP based but I would really like to know how
other people do it.
-------------------------------------------------


Wouldn't Wireshark provide this for you?  In particular, the "Conversations" 
tool under the "Statistics" drop down menu?  It adds data to the tool in 
real time.  If you want a graphical output the I/O graphs also under the
"Statistics" menu can graph all, or slices of the data in the main 
Wireshark output.

scott


From enuckols at colosolutions.com  Thu Feb 23 17:06:30 2012
From: enuckols at colosolutions.com (Ed S. Nuckols)
Date: Thu, 23 Feb 2012 18:06:30 -0500
Subject: colosolutions abuse contact?
In-Reply-To: <CAPF5agcMEswtu1MYBZO8_S9AYg4Peo+4qGTw0wjym04cH1h_Ag@mail.gmail.com>
References: <20120223001550.GI75951@ak-labs.net>
 <CAPF5agcMEswtu1MYBZO8_S9AYg4Peo+4qGTw0wjym04cH1h_Ag@mail.gmail.com>
Message-ID: <353A64F3EF481B4B94CD76A8E666BFDCD33F04850B@florl006.corp.colosolutions.com>

I apologize for the late reply, we were  having an email issue causing mail to be queued instead of delivered.  This appears to be irc (efnet channel drama related), but it has been tended to regardless.  For reference, my arin POC (which is attached to our IP space) also has my direct office number on it, and typically abuse@/support@  are checked rather often.  We are also listed at http://www.nls.net/noc/, which seems a rather handy tool (although I have no idea how up to date its kept). 

Thanks much,

Ed Nuckols
Colo Solutions


-----Original Message-----
From: Chris [mailto:caldcv at gmail.com] 
Sent: Thursday, February 23, 2012 12:45 PM
To: NANOG list
Subject: Re: colosolutions abuse contact?

If all else fails, contact the uplink. Unfortunately it gets more
response and casually mention "I tried finding a contact but was
unable so I contacted you"



On 2/22/12, Carlos Kamtha <kamtha at ak-labs.net> wrote:
> Hi,
>
> I'm hoping to get a hold of an abuse contact at colosolutions.com.
>
> Any help is greatly appreciated.
>
> If so, please contact me offlist.
>
> Cheers,
> Carlos.
>
>


-- 
--C

"The dumber people think you are, the more surprised they're going to
be when you kill them." - Sir William Clayton



From carlos at race.com  Thu Feb 23 17:30:52 2012
From: carlos at race.com (Carlos Alcantar)
Date: Thu, 23 Feb 2012 23:30:52 +0000
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
Message-ID: <CB6C0BA3.61613%carlos@race.com>

Netflow / Sflow with one of the fallowing software packages

http://www.plixer.com/products/netflow-sflow/scrutinizer-netflow-sflow.php
http://www.solarwinds.com/NetFlow

http://www.arbornetworks.com/
Or the hand full of other open source options out there.



Carlos Alcantar
Race Communications / Race Team Member
101 Haskins Way, So. San Francisco, CA. 94080
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com





-----Original Message-----
From: Maverick <myeaddress at gmail.com>
Date: Thu, 23 Feb 2012 15:19:24 -0500
To: Jeroen Massar <jeroen at unfix.org>
Cc: "nanog at nanog.org" <nanog at nanog.org>
Subject: Re: Network Traffic Collection

I want to be able to see information like how much traffic an ip send
over a period of time, what machines it talked to etc from this
perspective it should be IP based but I would really like to know how
other people do it.

Best,
Ali

On Thu, Feb 23, 2012 at 3:14 PM, Jeroen Massar <jeroen at unfix.org> wrote:
> On 2012-02-23 21:11 , Maverick wrote:
>> Hello,
>>
>> I am trying to collect traffic traffic from pcap file and store it in
>> a database but really confused how to organize it. Should I organize
>> it on connection basis/ flow basis or IP basis.
>>
>> It might be an effort to write a customized traffic analysis tool like
>> wireshark with only required functionality. I would really appreciate
>> if someone can give me direction on write way of organizing the data
>> because right now I only see individual packets and no way of putting
>> them in some order.
>
> Does this all not completely depend on what you actually want to do with
> it? You might want to start there instead of the other way around.
>
> Greets,
>  Jeroen
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5571 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120223/aea022a7/attachment-0001.bin>

From peter.phaal at gmail.com  Thu Feb 23 17:41:20 2012
From: peter.phaal at gmail.com (Peter Phaal)
Date: Thu, 23 Feb 2012 15:41:20 -0800
Subject: Network Traffic Collection
In-Reply-To: <Pine.LNX.4.64.1202231655440.22135@whammy.cluebyfour.org>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <Pine.LNX.4.64.1202231655440.22135@whammy.cluebyfour.org>
Message-ID: <CAB8g2zz9HbtMW8M_E2xtQPtndN=hcUrgr6Oh1dmv-zJU2gK8OQ@mail.gmail.com>

On Thu, Feb 23, 2012 at 1:59 PM, Justin M. Streiner
<streiner at cluebyfour.org> wrote:
> On Thu, 23 Feb 2012, Maverick wrote:
>
>> I want to be able to see information like how much traffic an ip send
>> over a period of time, what machines it talked to etc from this
>> perspective it should be IP based but I would really like to know how
>> other people do it.
>
>
> Truth is that most people probably don't do it, beyond temporary, ad-hoc
> deployments, to solve a specific problem at a specific point in time.
> Traffic capture and analysis doesn't scale too well into multi-Gb/s service
> provider environments.
>
> Netflow tools are an option if 'reasonably accurate' is good enough for your
> needs.
>
> jms
>

For high speed switched Ethernet environments, consider using sFlow.

You can treat sFlow as remote packet capture and use Wireshark/tcpdump
for troubleshooting network traffic:

http://blog.sflow.com/2011/11/wireshark.html

Or use sFlow reporting tools to find IP sources, protocols etc.:

http://sflow.org/products/collectors.php

Which tool to choose depends on your requirements.


From rcarpen at network1.net  Thu Feb 23 17:48:21 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Thu, 23 Feb 2012 18:48:21 -0500 (EST)
Subject: Most energy efficient (home) setup
In-Reply-To: <201202231721.03510.lowen@pari.edu>
Message-ID: <732b5685-3da1-459d-b4b6-5bc2f8305dd1@zimbra.network1.net>


I like the Juniper EX2200C switches. They are only 12-port, but have 2 SFPs. They are very low power, and have no fans.

However, I am still waiting (it has been several months) for them to send me the correct rack mount brackets (which are a separate purchase).


-Randy

--
| Randy Carpenter
| Vice President - IT Services
| Red Hat Certified Engineer
| First Network Group, Inc.
| (800)578-6381, Opt. 1
----

----- Original Message -----
> On Thursday, February 23, 2012 04:53:06 PM Joe Greco wrote:
> > So, good group to ask, probably...  anyone have suggestions for a
> > low-
> > noise, low-power GigE switch in the 24-port range ... managed, with
> > SFP?
> > That doesn't require constant rebooting?
> 
> I can't comment to the rebooting, but a couple of years ago I looked
> at the Allied-Telesis AT-9000-28SP, which is a smack steeply priced
> (~$1,500) but has flexible optics and is managed.  And at ~35 watts
> is the lowest powered managed gigabit switch I was able to find for
> our solar powered telescopes.  The grant that was going to fund that
> fell through, so I'm still running the 90W+ Catalyst 2900XL with two
> 1000Base-X modules and 24 10/100 ports instead, but the AT unit
> looked pretty good as a pretty much direct replacement with extra
> bandwidth.
> 
> 
> 


From owen at delong.com  Thu Feb 23 18:38:48 2012
From: owen at delong.com (Owen DeLong)
Date: Thu, 23 Feb 2012 16:38:48 -0800
Subject: Network Traffic Collection
In-Reply-To: <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
Message-ID: <2CD8A0A1-5A40-4308-B125-784190442920@delong.com>

PCAP is not well suited to what you describe. Most people use Sflow/Cflow/...
instead.

Owen

On Feb 23, 2012, at 12:19 PM, Maverick wrote:

> I want to be able to see information like how much traffic an ip send
> over a period of time, what machines it talked to etc from this
> perspective it should be IP based but I would really like to know how
> other people do it.
> 
> Best,
> Ali
> 
> On Thu, Feb 23, 2012 at 3:14 PM, Jeroen Massar <jeroen at unfix.org> wrote:
>> On 2012-02-23 21:11 , Maverick wrote:
>>> Hello,
>>> 
>>> I am trying to collect traffic traffic from pcap file and store it in
>>> a database but really confused how to organize it. Should I organize
>>> it on connection basis/ flow basis or IP basis.
>>> 
>>> It might be an effort to write a customized traffic analysis tool like
>>> wireshark with only required functionality. I would really appreciate
>>> if someone can give me direction on write way of organizing the data
>>> because right now I only see individual packets and no way of putting
>>> them in some order.
>> 
>> Does this all not completely depend on what you actually want to do with
>> it? You might want to start there instead of the other way around.
>> 
>> Greets,
>>  Jeroen
>> 



From danny at tcb.net  Thu Feb 23 20:00:31 2012
From: danny at tcb.net (Danny McPherson)
Date: Thu, 23 Feb 2012 21:00:31 -0500
Subject: do not filter your customers
In-Reply-To: <m21upm82x1.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
Message-ID: <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>


On Feb 23, 2012, at 1:44 AM, Randy Bush wrote:

> a customer leaked a full table to smellstra, and they had not filtered.
> hence the $subject.

Ahh, this is I think the customer "leak" problem I'm trying to illustrate 
that an RPKI/BGPSEC-enabled world alone (as currently prescribed) 
does NOT protect against.  

If it can happen by accident, it can certainly serve as smoke screen or
enable an actual targeted attack quite nicely by those so compelled.

> and things when further downhill from there, when telstra also did not
> filter what they announced to their peers, and the peers went over
> prefix limits and dropped bgp.

Prefix limits are rather binary and indiscriminate, indeed.

-danny


From randy at psg.com  Thu Feb 23 21:42:19 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 24 Feb 2012 09:12:19 +0530
Subject: do not filter your customers
In-Reply-To: <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
Message-ID: <m262ew6go4.wl%randy@psg.com>

>> a customer leaked a full table to smellstra, and they had not filtered.
>> hence the $subject.
> 
> Ahh, this is I think the customer "leak" problem I'm trying to illustrate 
> that an RPKI/BGPSEC-enabled world alone (as currently prescribed) 
> does NOT protect against.  

the problem is that you have yet to rigorously define it and how to
unambiguously and rigorously detect it.  lack of that will prevent
anyone from helping you prevent it.

randy


From bep at whack.org  Fri Feb 24 00:41:24 2012
From: bep at whack.org (Bruce Pinsky)
Date: Thu, 23 Feb 2012 22:41:24 -0800
Subject: Cisco CAT6500 IOS Simulator
In-Reply-To: <4F4649A1.8060703@gmail.com>
References: <FCF4EA853883E348957567CD9E90E97301D3D2607D@vnxbcnex01.bcn.nexica.com>
 <CALt-y3+kCP-1h7y-x3wJHEsTpObahzRjtKy43eaYMgTS=r5tzA@mail.gmail.com>
 <FCF4EA853883E348957567CD9E90E97301D3D260FF@vnxbcnex01.bcn.nexica.com>
 <alpine.LRH.2.00.1202221748070.25726@efes.iucc.ac.il>
 <4F451000.2020107@gmail.com>
 <FCF4EA853883E348957567CD9E90E97301DA90747E@vnxbcnex01.bcn.nexica.com>
 <4F4649A1.8060703@gmail.com>
Message-ID: <4F473114.7030407@whack.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -Hammer- wrote:
> I'm sure that virtualizing the sup would be possible. But having to come up
> with all the line cards would be a nightmare. I'd love for someone Internal
> to tell me I'm wrong but until we can get a 3560 or a 3750X on Dynamips I
> wouldn't push for a 6500 or a Nexus.
> 

What functionality of the 6500 are you looking for?  If you want hardware
specifics like QoS queues and such, that is unlikely.  If you are looking
for platform independent things like spanning tree, port channels, layer 3
functionality, etc, there may be a solution forthcoming from Cisco.

- -- 
=========
bep

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

iEYEARECAAYFAk9HMRMACgkQE1XcgMgrtybX4ACg0d8MPXQ4Y+HqlRp78wWNQR82
ZIQAoJ4oWXfGcELZIxVYOoGl4Sk+FcYB
=oiUG
-----END PGP SIGNATURE-----


From rdobbins at arbor.net  Fri Feb 24 00:57:03 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Fri, 24 Feb 2012 06:57:03 +0000
Subject: do not filter your customers
In-Reply-To: <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
Message-ID: <158E9EB8-70B7-45CB-B9F8-77E94038E887@arbor.net>


On Feb 24, 2012, at 9:00 AM, Danny McPherson wrote:

> Prefix limits are rather binary and indiscriminate, indeed.

AS-PATH filters and max-length filters, OTOH, are not.

Also, it's important that network operators understand that flap-dampening has been iatrogenic for many years, now.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From randy at psg.com  Fri Feb 24 01:02:19 2012
From: randy at psg.com (Randy Bush)
Date: Fri, 24 Feb 2012 12:32:19 +0530
Subject: do not filter your customers
In-Reply-To: <158E9EB8-70B7-45CB-B9F8-77E94038E887@arbor.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <158E9EB8-70B7-45CB-B9F8-77E94038E887@arbor.net>
Message-ID: <m2ehtk90jo.wl%randy@psg.com>

> Also, it's important that network operators understand that
> flap-dampening has been iatrogenic for many years, now.

wellllll, ... 

https://datatracker.ietf.org/doc/draft-ymbk-rfd-usable/

randy


From david at davidswafford.com  Fri Feb 24 05:28:50 2012
From: david at davidswafford.com (David Swafford)
Date: Fri, 24 Feb 2012 06:28:50 -0500
Subject: FCoE Deployment
In-Reply-To: <34FB1D1922F27F439B677D238AF0A4AC0F9137@X-MB10.xds.umail.utah.edu>
References: <4F45038B.7090005@bonyari.com>
 <AE14FD9B-05EA-43D0-A92B-4DD18326DD29@davidswafford.com>
 <34FB1D1922F27F439B677D238AF0A4AC0F9137@X-MB10.xds.umail.utah.edu>
Message-ID: <CAA8=vb4gCkLQwjdcEZdMSvEF3Z2J-8TUbZysobbPKvLVvE6T7w@mail.gmail.com>

Hey everyone,


I've not forgotten about this.  I plan on writing up the detail on our FCoE
experiences on Monday and will post it here.  Have a few things going on
today and this weekend that are going to prevent me from keeping focused on
this.

David.

On Thu, Feb 23, 2012 at 12:50 PM, Tom Ammon <tom.ammon at utah.edu> wrote:

> David,
>
> I'm  very interested in hearing more details on this, if you want to
> share...
>
> Tom
>
> -----Original Message-----
> From: David [mailto:david at davidswafford.com]
> Sent: Wednesday, February 22, 2012 4:07 PM
> To: Jack Morgan
> Cc: nanog at nanog.org
> Subject: Re: FCoE Deployment
>
> yep, we're doing FCoE in an EMC Symettric, ESX, Nexus environment.  All of
> our FCoE is over 10gb CNAs.  We are having good results, though we hit an
> odd bug on QLogics cards initially on pur HP DL 580s (affected twinax only
> -- if you dropped on uplink , ie testing failover, throughput dropped to
> crap for disk i/o., that issue only cleared after a power cycle of the
> server.  Qlogic never fixed the issue so we RMAd nearly 30k in 10gb CNA
> cards and swapped everythibg to fiber.  So beware of that.  I can get more
> detail on the affected cards,etc tomorrow if interested.  Our entire
> production VMware environment is off that setup.
>
> David
>
> Sent from an email server.
>
> On Feb 22, 2012, at 10:02 AM, Jack Morgan <jack at bonyari.com> wrote:
>
> > Does anyone know of any company or organization deploying FCoE[1] in a
> > production environment? I'm curious how widely adopted this technology
> is.
> >
> >
> > [1] http://en.wikipedia.org/wiki/Fibre_Channel_over_Ethernet
> >    http://fcoe.com/
> >
> >
> > Thanks,
> >
> > --
> > Jack Morgan
> >
> >
>
>

From danny at tcb.net  Fri Feb 24 06:46:40 2012
From: danny at tcb.net (Danny McPherson)
Date: Fri, 24 Feb 2012 07:46:40 -0500
Subject: do not filter your customers
In-Reply-To: <m262ew6go4.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
Message-ID: <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>


On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:

> the problem is that you have yet to rigorously define it and how to
> unambiguously and rigorously detect it.  lack of that will prevent
> anyone from helping you prevent it.

You referred to this incident as a "leak" in your message:

"a customer leaked a full table"

I was simply agreeing with you -- i.e., looked like a "leak", smelled 
like a "leak" - let's call it a leak.

I'm optimistic that all the good folks focusing on this in their day
jobs, and expressly funded and resourced to do so, will eventually
recognize what I'm calling "leaks" is part of the routing security 
problem.

-danny


From Thomas.Weible at flexoptix.net  Fri Feb 24 08:00:37 2012
From: Thomas.Weible at flexoptix.net (Thomas Weible - FLEXOPTIX)
Date: Fri, 24 Feb 2012 14:00:37 +0000
Subject: AW: WW: Colo Vending Machine
In-Reply-To: <4F401244.4050106@ninjabadger.net>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <4F401244.4050106@ninjabadger.net>
Message-ID: <3C73F7533E17CE4BA3558C3026772EC83DFE2DD9@postman.intranet.flexoptix.net>

> I thought they already existed: http://gearomat.com/

Yeah, that's correct. You can see the first version of the series production  at CeBIT Hannover this year (Hall 6 Booth K45) - the show will take place between 6th - 10th of march. We also have some free tickets for the show. If you plan to be there, let us know and drop me a line.

> That one's a FlexOptix idea, so the vending machine will indeed 'vend'
> optics and then also go on to code them for your chosen hardware.
> 
> I thought it was a neat idea when I spoke to Fearghas about it a year or so
> ago, though I've still not seen one around yet.

It took a while to move from the first prototype to a ruggedized, flexible and in series produceable version. 

  Thomas




From jra at baylink.com  Fri Feb 24 09:46:54 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 24 Feb 2012 10:46:54 -0500 (EST)
Subject: [Outages-discussion] Recent outage in Australia affecting Telstra
In-Reply-To: <20120224130833.GA7024@greenie.muc.de>
Message-ID: <1201724.391.1330098414072.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Gert Doering" <gert at greenie.muc.de>

> > One of Telstra's downstream customers, a smaller ISP called Dodo,
> > accidentally announced the global table to Telstra (or perhaps a very
> > large portion of it.) Enough of it to cause major disruption.
> 
> This is good. There is a chance that Telstra will learn from it, and
> do proper customer-facing filters now.
> 
> OTOH, there also is a chance that Telstra lawyers will just sue the
> customer, and not change anything...

Perhaps.  I am not familiar with Australian jurisprudence, but the US there
is the doctrine of Last Clear Chance[1]... and the work necessary on Telstra's
part to avoid this problem is a) well known, b) arguably considered best
practice for a company in their field, and c) not disproportionately 
onorous for them to have undertaken...

so even if they sue, it's not at all a clear cut case for them to "win".

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


From jra at baylink.com  Fri Feb 24 10:50:17 2012
From: jra at baylink.com (Jay Ashworth)
Date: Fri, 24 Feb 2012 11:50:17 -0500 (EST)
Subject: Hostway email from John Martis
Message-ID: <30606072.428.1330102217417.JavaMail.root@benjamin.baylink.com>

If anyone at Hostway is listening -- though I don't really owe you this,
since you couldn't even be bothered to call me back in October when I was
shopping -- you might want to:

a) fix the content restrictions on the half dozen or more people on the
mailing list to which johnmartis at hostway redirects, and

b) make sure you have no such filters at all on postmaster@, in accordance
with the relevant RFCs.

And no, there was no restrictable content in my reply.

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


From smb at cs.columbia.edu  Fri Feb 24 12:10:23 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 24 Feb 2012 13:10:23 -0500
Subject: do not filter your customers
In-Reply-To: <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
Message-ID: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>


On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote:

> 
> On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
> 
>> the problem is that you have yet to rigorously define it and how to
>> unambiguously and rigorously detect it.  lack of that will prevent
>> anyone from helping you prevent it.
> 
> You referred to this incident as a "leak" in your message:
> 
> "a customer leaked a full table"
> 
> I was simply agreeing with you -- i.e., looked like a "leak", smelled 
> like a "leak" - let's call it a leak.
> 
> I'm optimistic that all the good folks focusing on this in their day
> jobs, and expressly funded and resourced to do so, will eventually
> recognize what I'm calling "leaks" is part of the routing security 
> problem.
> 
Sure; I don't disagree, and I don't think that Randy does.  But just
because we can't solve the whole problem, does that mean we shouldn't
solve any of it?

As Randy said, we can't even try for a strong technical solution
until we have a definition that's better than "I know it when I see it".



		--Steve Bellovin, https://www.cs.columbia.edu/~smb







From goemon at anime.net  Fri Feb 24 12:13:27 2012
From: goemon at anime.net (goemon at anime.net)
Date: Fri, 24 Feb 2012 10:13:27 -0800 (PST)
Subject: do not filter your customers
In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
Message-ID: <Pine.LNX.4.64.1202241012120.1799@sasami.anime.net>

On Fri, 24 Feb 2012, Steven Bellovin wrote:
> Sure; I don't disagree, and I don't think that Randy does.  But just
> because we can't solve the whole problem, does that mean we shouldn't
> solve any of it?

that is often the way things are argued in engineering circles.

the solution is imperfect therefore it is useless.

this philosophy is reflected in the shoddy state of networks today.

-Dan


From jmaimon at ttec.com  Fri Feb 24 12:35:14 2012
From: jmaimon at ttec.com (Joe Maimon)
Date: Fri, 24 Feb 2012 13:35:14 -0500
Subject: do not filter your customers
In-Reply-To: <Pine.LNX.4.64.1202241012120.1799@sasami.anime.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <Pine.LNX.4.64.1202241012120.1799@sasami.anime.net>
Message-ID: <4F47D862.6040507@ttec.com>



goemon at anime.net wrote:
> On Fri, 24 Feb 2012, Steven Bellovin wrote:
>> Sure; I don't disagree, and I don't think that Randy does. But just
>> because we can't solve the whole problem, does that mean we shouldn't
>> solve any of it?
>
> that is often the way things are argued in engineering circles.
>
> the solution is imperfect therefore it is useless.
>
> this philosophy is reflected in the shoddy state of networks today.
>
> -Dan

Due to which side winning the debate?

Joe


From cscora at apnic.net  Fri Feb 24 12:55:14 2012
From: cscora at apnic.net (Routing Analysis Role Account)
Date: Sat, 25 Feb 2012 04:55:14 +1000 (EST)
Subject: Weekly Routing Table Report
Message-ID: <201202241855.q1OItEqo005237@thyme.rand.apnic.net>

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG,
TRNOG, CaribNOG and the RIPE Routing Working Group.

Daily listings are sent to bgp-stats at lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith <pfsinoz at gmail.com>.

Routing Table Report   04:00 +10GMT Sat 25 Feb, 2012

Report Website:     http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary
----------------

BGP routing table entries examined:                              398370
    Prefixes after maximum aggregation:                          170083
    Deaggregation factor:                                          2.34
    Unique aggregates announced to Internet:                     193498
Total ASes present in the Internet Routing Table:                 40222
    Prefixes per ASN:                                              9.90
Origin-only ASes present in the Internet Routing Table:           32798
Origin ASes announcing only one prefix:                           15535
Transit ASes present in the Internet Routing Table:                5416
Transit-only ASes present in the Internet Routing Table:            144
Average AS path length visible in the Internet Routing Table:       4.4
    Max AS path length visible:                                      33
    Max AS path prepend of ASN (48687)                               24
Prefixes from unregistered ASNs in the Routing Table:               321
    Unregistered ASNs in the Routing Table:                         131
Number of 32-bit ASNs allocated by the RIRs:                       2294
Number of 32-bit ASNs visible in the Routing Table:                2008
Prefixes from 32-bit ASNs in the Routing Table:                    4823
Special use prefixes present in the Routing Table:                    2
Prefixes being announced from unallocated address space:            303
Number of addresses announced to Internet:                   2521478992
    Equivalent to 150 /8s, 74 /16s and 183 /24s
    Percentage of available address space announced:               68.0
    Percentage of allocated address space announced:               68.0
    Percentage of available address space allocated:              100.0
    Percentage of address space in use by end-sites:               92.0
Total number of prefixes smaller than registry allocations:      169400

APNIC Region Analysis Summary
-----------------------------

Prefixes being announced by APNIC Region ASes:                    97749
    Total APNIC prefixes after maximum aggregation:               31742
    APNIC Deaggregation factor:                                    3.08
Prefixes being announced from the APNIC address blocks:           94211
    Unique aggregates announced from the APNIC address blocks:    39264
APNIC Region origin ASes present in the Internet Routing Table:    4664
    APNIC Prefixes per ASN:                                       20.20
APNIC Region origin ASes announcing only one prefix:               1235
APNIC Region transit ASes present in the Internet Routing Table:    738
Average APNIC Region AS path length visible:                        4.5
    Max APNIC Region AS path length visible:                         18
Number of APNIC region 32-bit ASNs visible in the Routing Table:    151
Number of APNIC addresses announced to Internet:              639946592
    Equivalent to 38 /8s, 36 /16s and 207 /24s
    Percentage of available APNIC address space announced:         81.2

APNIC AS Blocks        4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
                       58368-59391, 131072-132095, 132096-133119
APNIC Address Blocks     1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
                        49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
                       106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
                       116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
                       123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8,
                       182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8,
                       219/8, 220/8, 221/8, 222/8, 223/8,

ARIN Region Analysis Summary
----------------------------

Prefixes being announced by ARIN Region ASes:                    148408
    Total ARIN prefixes after maximum aggregation:                75382
    ARIN Deaggregation factor:                                     1.97
Prefixes being announced from the ARIN address blocks:           120229
    Unique aggregates announced from the ARIN address blocks:     49575
ARIN Region origin ASes present in the Internet Routing Table:    14921
    ARIN Prefixes per ASN:                                         8.06
ARIN Region origin ASes announcing only one prefix:                5683
ARIN Region transit ASes present in the Internet Routing Table:    1575
Average ARIN Region AS path length visible:                         4.0
    Max ARIN Region AS path length visible:                          22
Number of ARIN region 32-bit ASNs visible in the Routing Table:      15
Number of ARIN addresses announced to Internet:               805439424
    Equivalent to 48 /8s, 2 /16s and 7 /24s
    Percentage of available ARIN address space announced:          64.0

ARIN AS Blocks         1-1876, 1902-2042, 2044-2046, 2048-2106
(pre-ERX allocations)  2138-2584, 2615-2772, 2823-2829, 2880-3153
                       3354-4607, 4865-5119, 5632-6655, 6912-7466
                       7723-8191, 10240-12287, 13312-15359, 16384-17407
                       18432-20479, 21504-23551, 25600-26591,
                       26624-27647, 29696-30719, 31744-33791
                       35840-36863, 39936-40959, 46080-47103
                       53248-55295, 393216-394239
ARIN Address Blocks      3/8,   4/8,   6/8,   7/8,   8/8,   9/8,  11/8,
                        12/8,  13/8,  15/8,  16/8,  17/8,  18/8,  19/8,
                        20/8,  21/8,  22/8,  23/8,  24/8,  26/8,  28/8,
                        29/8,  30/8,  32/8,  33/8,  34/8,  35/8,  38/8,
                        40/8,  44/8,  45/8,  47/8,  48/8,  50/8,  52/8,
                        53/8,  54/8,  55/8,  56/8,  57/8,  63/8,  64/8,
                        65/8,  66/8,  67/8,  68/8,  69/8,  70/8,  71/8,
                        72/8,  73/8,  74/8,  75/8,  76/8,  96/8,  97/8,
                        98/8,  99/8, 100/8, 104/8, 107/8, 108/8, 173/8,
                       174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8,
                       208/8, 209/8, 214/8, 215/8, 216/8,

RIPE Region Analysis Summary
----------------------------

Prefixes being announced by RIPE Region ASes:                     99486
    Total RIPE prefixes after maximum aggregation:                52692
    RIPE Deaggregation factor:                                     1.89
Prefixes being announced from the RIPE address blocks:            91151
    Unique aggregates announced from the RIPE address blocks:     56714
RIPE Region origin ASes present in the Internet Routing Table:    16336
    RIPE Prefixes per ASN:                                         5.58
RIPE Region origin ASes announcing only one prefix:                8012
RIPE Region transit ASes present in the Internet Routing Table:    2613
Average RIPE Region AS path length visible:                         4.7
    Max RIPE Region AS path length visible:                          33
Number of RIPE region 32-bit ASNs visible in the Routing Table:    1380
Number of RIPE addresses announced to Internet:               500978952
    Equivalent to 29 /8s, 220 /16s and 85 /24s
    Percentage of available RIPE address space announced:          80.7

RIPE AS Blocks         1877-1901, 2043, 2047, 2107-2136, 2585-2614
(pre-ERX allocations)  2773-2822, 2830-2879, 3154-3353, 5377-5631
                       6656-6911, 8192-9215, 12288-13311, 15360-16383
                       20480-21503, 24576-25599, 28672-29695
                       30720-31743, 33792-35839, 38912-39935
                       40960-45055, 47104-52223, 56320-58367
                       196608-198655
RIPE Address Blocks      2/8,   5/8,  25/8,  31/8,  37/8,  46/8,  51/8,
                        62/8,  77/8,  78/8,  79/8,  80/8,  81/8,  82/8,
                        83/8,  84/8,  85/8,  86/8,  87/8,  88/8,  89/8,
                        90/8,  91/8,  92/8,  93/8,  94/8,  95/8, 109/8,
                       176/8, 178/8, 185/8, 193/8, 194/8, 195/8, 212/8,
                       213/8, 217/8,

LACNIC Region Analysis Summary
------------------------------

Prefixes being announced by LACNIC Region ASes:                   38762
    Total LACNIC prefixes after maximum aggregation:               8083
    LACNIC Deaggregation factor:                                   4.80
Prefixes being announced from the LACNIC address blocks:          38441
    Unique aggregates announced from the LACNIC address blocks:   19555
LACNIC Region origin ASes present in the Internet Routing Table:   1576
    LACNIC Prefixes per ASN:                                      24.39
LACNIC Region origin ASes announcing only one prefix:               442
LACNIC Region transit ASes present in the Internet Routing Table:   289
Average LACNIC Region AS path length visible:                       4.4
    Max LACNIC Region AS path length visible:                        17
Number of LACNIC region 32-bit ASNs visible in the Routing Table:   458
Number of LACNIC addresses announced to Internet:              97295240
    Equivalent to 5 /8s, 204 /16s and 155 /24s
    Percentage of available LACNIC address space announced:        64.4

LACNIC AS Blocks       26592-26623, 27648-28671, 52224-53247,
                       262144-263167 plus ERX transfers
LACNIC Address Blocks  177/8, 179/8, 181/8, 186/8, 187/8, 189/8, 190/8,
                       200/8, 201/8,

AfriNIC Region Analysis Summary
-------------------------------

Prefixes being announced by AfriNIC Region ASes:                   8970
    Total AfriNIC prefixes after maximum aggregation:              2091
    AfriNIC Deaggregation factor:                                  4.29
Prefixes being announced from the AfriNIC address blocks:          6985
    Unique aggregates announced from the AfriNIC address blocks:   2124
AfriNIC Region origin ASes present in the Internet Routing Table:   517
    AfriNIC Prefixes per ASN:                                     13.51
AfriNIC Region origin ASes announcing only one prefix:              163
AfriNIC Region transit ASes present in the Internet Routing Table:  116
Average AfriNIC Region AS path length visible:                      4.4
    Max AfriNIC Region AS path length visible:                       25
Number of AfriNIC region 32-bit ASNs visible in the Routing Table:    4
Number of AfriNIC addresses announced to Internet:             31523072
    Equivalent to 1 /8s, 225 /16s and 1 /24s
    Percentage of available AfriNIC address space announced:       47.0

AfriNIC AS Blocks      36864-37887, 327680-328703 & ERX transfers
AfriNIC Address Blocks  41/8, 102/8, 105/8, 197/8,

APNIC Region per AS prefix count summary
----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 4766     2485      11107         991   Korea Telecom (KIX)
17974     1725        503          36   PT TELEKOMUNIKASI INDONESIA
 7545     1642        303          86   TPG Internet Pty Ltd
 4755     1557        385         157   TATA Communications formerly 
 7552     1282       1064           7   Vietel Corporation
 4808     1148       2112         319   CNCGROUP IP network: China169
 9583     1126         84         483   Sify Limited
 9829     1106        996          29   BSNL National Internet Backbo
24560     1011        385         167   Bharti Airtel Ltd., Telemedia
18101      949        130         155   Reliance Infocom Ltd Internet

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC

ARIN Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3433       3807         199   bellsouth.net, inc. 
 7029     3416       1014         159   Windstream Communications Inc
18566     2091        382         177   Covad Communications 
 1785     1873        680         126   PaeTec Communications, Inc.
20115     1629       1551         630   Charter Communications 
 4323     1607       1043         381   Time Warner Telecom
22773     1536       2910         110   Cox Communications, Inc.
30036     1415        254         745   Mediacom Communications Corp 
19262     1388       4703         398   Verizon Global Networks 
 7018     1311       6980         851   AT&T WorldNet Services

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN

RIPE Region per AS prefix count summary
---------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8402     1753        480          15   Corbina telecom
 2118     1398         97          13   EUnet/RELCOM Autonomous Syste
15557     1099       2184          60   LDCOM NETWORKS
34984      656        188         173   BILISIM TELEKOM
 6830      644       1927         413   UPC Distribution Services
20940      627        203         480   Akamai Technologies European 
12479      608        644          55   Uni2 Autonomous System
 8551      565        360          81   Bezeq International
31148      541         37           9   FreeNet ISP
 3320      533       8450         399   Deutsche Telekom AG

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE

LACNIC Region per AS prefix count summary
-----------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
10620     1751        324         171   TVCABLE BOGOTA 
28573     1685       1088          62   NET Servicos de Comunicao S.A
 8151     1483       3011         349   UniNet S.A. de C.V. 
 7303     1326        822         186   Telecom Argentina Stet-France
26615      881        668          32   Tim Brasil S.A.
27947      662         67         108   Telconet S.A
11172      632         91          72   Servicios Alestra S.A de C.V 
22047      581        322          17   VTR PUNTO NET S.A. 
 6503      576        418          66   AVANTEL, S.A. 
 3816      554        237          91   Empresa Nacional de Telecomun

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC

AfriNIC Region per AS prefix count summary
------------------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 8452     1254        958          13   TEDATA
24863      834        274          37   LINKdotNET AS number
 6713      489        649          18   Itissalat Al-MAGHRIB
 3741      277        923         228   The Internet Solution 
15706      227         32           6   Sudatel Internet Exchange Aut
29571      214         17          12   Ci Telecom Autonomous system 
12258      197         28          62   Vodacom Internet Company 
24835      194         80           8   RAYA Telecom - Egypt
33776      182         12          20   Starcomms Nigeria Limited
16637      157        647          81   MTN Network Solutions

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC

Global Per AS prefix count summary
----------------------------------

  ASN   No of nets  /20 equiv  MaxAgg  Description
 6389     3433       3807         199   bellsouth.net, inc. 
 7029     3416       1014         159   Windstream Communications Inc
 4766     2485      11107         991   Korea Telecom (KIX)
18566     2091        382         177   Covad Communications 
 1785     1873        680         126   PaeTec Communications, Inc.
 8402     1753        480          15   Corbina telecom
10620     1751        324         171   TVCABLE BOGOTA 
17974     1725        503          36   PT TELEKOMUNIKASI INDONESIA
28573     1685       1088          62   NET Servicos de Comunicao S.A
 7545     1642        303          86   TPG Internet Pty Ltd

Complete listing at http://thyme.rand.apnic.net/current/data-ASnet

Global Per AS Maximum Aggr summary
----------------------------------

  ASN   No of nets  Net Savings Description
 7029      3416        3257      Windstream Communications Inc
18566      2091        1914      Covad Communications 
 1785      1873        1747      PaeTec Communications, Inc.
 8402      1753        1738      Corbina telecom
17974      1725        1689      PT TELEKOMUNIKASI INDONESIA
28573      1685        1623      NET Servicos de Comunicao S.A
10620      1751        1580      TVCABLE BOGOTA 
 7545      1642        1556      TPG Internet Pty Ltd
 4766      2485        1494      Korea Telecom (KIX)
22773      1536        1426      Cox Communications, Inc.

Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet

List of Unregistered Origin ASNs (Global)
-----------------------------------------

Bad AS  Designation  Network              Transit AS  Description
15132   UNALLOCATED  12.9.150.0/24         7018       AT&T WorldNet Servic
32567   UNALLOCATED  12.14.170.0/24        4323       Time Warner Telecom
32567   UNALLOCATED  12.25.107.0/24        4323       Time Warner Telecom
25639   UNALLOCATED  12.41.169.0/24        7018       AT&T WorldNet Servic
13317   UNALLOCATED  12.44.10.0/24         7018       AT&T WorldNet Servic
23502   UNALLOCATED  12.44.44.0/24         7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.103.0/24        7018       AT&T WorldNet Servic
17300   UNALLOCATED  12.45.110.0/24         701       UUNET Technologies, 
16476   UNALLOCATED  12.46.27.0/24         7018       AT&T WorldNet Servic
32873   UNALLOCATED  12.46.100.0/23       10912       InterNAP Network Ser

Complete listing at http://thyme.rand.apnic.net/current/data-badAS

Prefixes from private and non-routed address space (Global)
-----------------------------------------------------------

Prefix             Origin AS  Description
128.0.0.0/21         12654     RIPE NCC RIS Project
128.0.24.0/24        12654     RIPE NCC RIS Project

Complete listing at http://thyme.rand.apnic.net/current/data-dsua

Advertised Unallocated Addresses
--------------------------------

Network            Origin AS  Description
14.192.0.0/22        45464     Room 201, TGU Bldg
14.192.4.0/22        45464     Room 201, TGU Bldg
14.192.8.0/22        45464     Room 201, TGU Bldg
14.192.12.0/22       45464     Room 201, TGU Bldg
14.192.16.0/22       45464     Room 201, TGU Bldg
14.192.20.0/22       45464     Room 201, TGU Bldg
14.192.24.0/22       45464     Room 201, TGU Bldg
14.192.28.0/22       45464     Room 201, TGU Bldg
23.27.0.0/16         18779     Guru.com 
27.112.114.0/24      23884     Proimage Engineering and Comm

Complete listing at http://thyme.rand.apnic.net/current/data-add-IANA

Number of prefixes announced per prefix length (Global)
-------------------------------------------------------

 /1:0        /2:0        /3:0        /4:0        /5:0        /6:0       
 /7:0        /8:19       /9:12      /10:28      /11:81      /12:232     
/13:459     /14:812     /15:1473    /16:12149   /17:6216    /18:10375   
/19:20480   /20:28362   /21:29291   /22:39795   /23:37056   /24:207890  
/25:1174    /26:1425    /27:782     /28:170     /29:56      /30:14      
/31:0       /32:19      

Advertised prefixes smaller than registry allocations
-----------------------------------------------------

  ASN   No of nets  Total ann.   Description
 7029     3070          3416      Windstream Communications Inc
 6389     2107          3433      bellsouth.net, inc. 
18566     2040          2091      Covad Communications 
 8402     1732          1753      Corbina telecom
10620     1648          1751      TVCABLE BOGOTA 
30036     1365          1415      Mediacom Communications Corp 
11492     1122          1159      Cable One 
 1785     1064          1873      PaeTec Communications, Inc.
 8452     1062          1254      TEDATA
15557     1046          1099      LDCOM NETWORKS

Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos

Number of /24s announced per /8 block (Global)
----------------------------------------------

   1:503       2:712       4:14        6:3         8:387      12:1962   
  13:1        14:595      15:11       16:3        17:7        20:8      
  23:134      24:1736     27:1195     31:944      32:65       33:2      
  34:2        36:9        37:198      38:781      40:116      41:3117   
  42:112      43:1        44:3        46:1324     47:3        49:319    
  50:509      52:13       54:2        55:7        56:3        57:38     
  58:965      59:494      60:344      61:1189     62:966      63:2010   
  64:4122     65:2285     66:4460     67:2020     68:1167     69:3163   
  70:909      71:406      72:1791     74:2648     75:470      76:320    
  77:970      78:958      79:509      80:1224     81:878      82:629    
  83:528      84:585      85:1155     86:728      87:912      88:334    
  89:1564     90:282      91:4501     92:510      93:1351     94:1386   
  95:1118     96:421      97:311      98:831      99:38      100:4      
 101:154     103:830     106:66      107:161     108:176     109:1542   
 110:708     111:853     112:435     113:528     114:601     115:779    
 116:870     117:710     118:906     119:1258    120:364     121:690    
 122:1617    123:1078    124:1329    125:1316    128:536     129:190    
 130:217     131:590     132:162     133:21      134:234     135:62     
 136:214     137:183     138:268     139:145     140:468     141:261    
 142:394     143:420     144:515     145:69      146:486     147:240    
 148:734     149:300     150:163     151:198     152:448     153:171    
 154:7       155:395     156:212     157:370     158:163     159:517    
 160:319     161:245     162:342     163:181     164:523     165:393    
 166:559     167:459     168:737     169:148     170:838     171:118    
 172:4       173:1721    174:598     175:422     176:507     177:507    
 178:1282    180:1184    181:68      182:736     183:281     184:432    
 185:1       186:2039    187:856     188:1084    189:1186    190:5463   
 192:5970    193:5539    194:4344    195:3394    196:1288    197:167    
 198:3622    199:4415    200:5710    201:1737    202:8401    203:8633   
 204:4362    205:2441    206:2741    207:2795    208:4067    209:3551   
 210:2752    211:1476    212:2015    213:1843    214:837     215:101    
 216:5030    217:1501    218:547     219:337     220:1224    221:562    
 222:324     223:312    

End of report


From cjp at 0x1.net  Fri Feb 24 13:01:23 2012
From: cjp at 0x1.net (Christopher Pilkington)
Date: Fri, 24 Feb 2012 14:01:23 -0500
Subject: HP A6600 experiences
Message-ID: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>

If anyone has any experiences they'd be willing to share, or even lab reports, on HP A6600, it would be helpful.  I believe this is the same product as H3C SR6600.

We're being asked to "look at" A6604 facing our IPv4/IPv6 transit.  I'd like to get some opinions before I go through effort of getting one in the lab.

-cjp

From richard.barnes at gmail.com  Fri Feb 24 13:08:32 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 24 Feb 2012 14:08:32 -0500
Subject: HP contact?
Message-ID: <CACB24MuevWT1zih+DYtrZHSRVZjBhac1YefERdG0TsTRR2bi7g@mail.gmail.com>

Anyone have a clueful contact at HP?  One of their proprietary DHCP
features is squatting on an IANA-registered code point.

Thanks,
--Richard


From danny at tcb.net  Fri Feb 24 13:26:14 2012
From: danny at tcb.net (Danny McPherson)
Date: Fri, 24 Feb 2012 14:26:14 -0500
Subject: do not filter your customers
In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
Message-ID: <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>


On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:

> But just because we can't solve the whole problem, does that
> mean we shouldn't solve any of it?

Nope, we most certainly should decompose the problem into 
addressable elements, that's core to engineering and operations.

However, simply because the currently envisaged solution 
doesn't solve this problem doesn't mean we shouldn't 
acknowledge it exists.

The IETF's BGP security threats document [1]  "describes a threat 
model for BGP path security", which constrains itself to the 
carefully worded SIDR WG charter, which addresses route origin 
authorization and AS_PATH "semantics" -- i.e., this "leak" 
problem is expressly out of scope of a threats document
discussing BGP path security - eh? 

How the heck we can talk about BGP path security and not 
consider this incident a threat is beyond me, particularly when it 
happens by accident all the time.  How we can justify putting all 
that BGPSEC and RPKI machinery in place and not address this 
"leak" issue somewhere in the mix is, err.., telling.

Alas, I suspect we can all agree that experiments are good and 
the market will ultimately decide.

-danny

[1] draft-ietf-sidr-bgpsec-threats-02


From morrowc.lists at gmail.com  Fri Feb 24 13:29:57 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 14:29:57 -0500
Subject: do not filter your customers
In-Reply-To: <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
Message-ID: <CAL9jLaYbnWuK76zswo0LfU2Z9GxLvhG2FwDoQ0dH9xgxiV=4HQ@mail.gmail.com>

On Fri, Feb 24, 2012 at 2:26 PM, Danny McPherson <danny at tcb.net> wrote:

> happens by accident all the time. ?How we can justify putting all
> that BGPSEC and RPKI machinery in place and not address this
> "leak" issue somewhere in the mix is, err.., telling.

I think if we asked telstra why they didn't filter their customer some
answer like:
 1) we did, we goofed, oops!
 2) we don't it's too hard
 3) filters? what?

I suspect in the case of 1 it's a software problem that needs more
belts/suspenders
I suspect in the case of 2 it's a problem that could be shown to be
simpler with some resource-certification in place
I suspect 3 is not likely... (or I hope so).

So, even without defining what a leak is, providing a tool to better
create/verify filtering would be a boon.


From Sherif_Hashem at hms.harvard.edu  Fri Feb 24 13:37:00 2012
From: Sherif_Hashem at hms.harvard.edu (Hashem, Sherif Rakhaa)
Date: Fri, 24 Feb 2012 14:37:00 -0500
Subject: Comcast / RCN Issues in Boston
Message-ID: <3C43EC49B7AF084BA385F946485B1F4C54456D8F9B@ITCCRMAIL02.MED.HARVARD.EDU>

Are there any ongoing issues with Comcast and/or RCN in the Boston Metro Area?

Thanks,
Sherif Hashem

Harvard Medical School | Network Operations
25 Shattuck Street | Gordon Hall Suite 500 | Boston, MA, 02115
d: (617)432-7534  | c: (617)999-7818 | f: (617)432-6804


From danny at tcb.net  Fri Feb 24 13:40:39 2012
From: danny at tcb.net (Danny McPherson)
Date: Fri, 24 Feb 2012 14:40:39 -0500
Subject: do not filter your customers
In-Reply-To: <CAL9jLaYbnWuK76zswo0LfU2Z9GxLvhG2FwDoQ0dH9xgxiV=4HQ@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <CAL9jLaYbnWuK76zswo0LfU2Z9GxLvhG2FwDoQ0dH9xgxiV=4HQ@mail.gmail.com>
Message-ID: <3DCB02DA-0961-4744-89D1-6BBFAB99294E@tcb.net>


On Feb 24, 2012, at 2:29 PM, Christopher Morrow wrote:
> 
> I think if we asked telstra why they didn't filter their customer some
> answer like:
> 1) we did, we goofed, oops!
> 2) we don't it's too hard
> 3) filters? what?
> 
> I suspect in the case of 1 it's a software problem that needs more
> belts/suspenders
> I suspect in the case of 2 it's a problem that could be shown to be
> simpler with some resource-certification in place
> I suspect 3 is not likely... (or I hope so).
> 
> So, even without defining what a leak is, providing a tool to better
> create/verify filtering would be a boon.



Yes, I agree!

What I'd hate to see is:

4) We fully deployed BGPSEC, and RPKI, and upgraded our 
infrastructure, and retooled provisioning, operations and processes 
to support it all fully, and required our customers and peers to use it, 
and even then this still happened - WTF was the point?

This "leak" thing is a key vulnerability that simply can't be brushed 
aside - that's the crux of my frustration with the current effort.

-danny



From richard.barnes at gmail.com  Fri Feb 24 13:49:38 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Fri, 24 Feb 2012 14:49:38 -0500
Subject: do not filter your customers
In-Reply-To: <3DCB02DA-0961-4744-89D1-6BBFAB99294E@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <CAL9jLaYbnWuK76zswo0LfU2Z9GxLvhG2FwDoQ0dH9xgxiV=4HQ@mail.gmail.com>
 <3DCB02DA-0961-4744-89D1-6BBFAB99294E@tcb.net>
Message-ID: <CACB24MtU1EUZt3iTQVvi_93ppochhj-7Q7sNaskFD+=Z-7rjew@mail.gmail.com>

>> I think if we asked telstra why they didn't filter their customer some
>> answer like:
>> 1) we did, we goofed, oops!
>> 2) we don't it's too hard
>> 3) filters? what?
>>
>> I suspect in the case of 1 it's a software problem that needs more
>> belts/suspenders
>> I suspect in the case of 2 it's a problem that could be shown to be
>> simpler with some resource-certification in place
>> I suspect 3 is not likely... (or I hope so).
>>
>> So, even without defining what a leak is, providing a tool to better
>> create/verify filtering would be a boon.
>
>
>
> Yes, I agree!
>
> What I'd hate to see is:
>
> 4) We fully deployed BGPSEC, and RPKI, and upgraded our
> infrastructure, and retooled provisioning, operations and processes
> to support it all fully, and required our customers and peers to use it,
> and even then this still happened - WTF was the point?

I think this is the point:
<https://twitter.com/#!/atoonk/status/165245731429564416>


> This "leak" thing is a key vulnerability that simply can't be brushed
> aside - that's the crux of my frustration with the current effort.

You seem to think that there's some extension/modification to BGPSEC
that would fix route leaks in addition to the ASPATH issues that
BGPSEC addresses right now.  Have you written this up anywhere?  I
would be interested to read it.

--Richard


From danny at tcb.net  Fri Feb 24 13:58:57 2012
From: danny at tcb.net (Danny McPherson)
Date: Fri, 24 Feb 2012 14:58:57 -0500
Subject: do not filter your customers
In-Reply-To: <CACB24MtU1EUZt3iTQVvi_93ppochhj-7Q7sNaskFD+=Z-7rjew@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <CAL9jLaYbnWuK76zswo0LfU2Z9GxLvhG2FwDoQ0dH9xgxiV=4HQ@mail.gmail.com>
 <3DCB02DA-0961-4744-89D1-6BBFAB99294E@tcb.net>
 <CACB24MtU1EUZt3iTQVvi_93ppochhj-7Q7sNaskFD+=Z-7rjew@mail.gmail.com>
Message-ID: <6A2FB177-CDF4-4FA2-A63A-317CFFE3BA42@tcb.net>


On Feb 24, 2012, at 2:49 PM, Richard Barnes wrote:

> You seem to think that there's some extension/modification to BGPSEC
> that would fix route leaks in addition to the ASPATH issues that
> BGPSEC addresses right now.  Have you written this up anywhere?  I
> would be interested to read it.

I don't, actually -- as I haven't presupposed that "BGPSEC" is the 
answer to all things routing security related, nor have I excluded it.

I didn't realize it was unacceptable to acknowledge a problem exists 
without having solved already.  I might have that backwards though.

-danny



From shane at castlepoint.net  Fri Feb 24 14:04:20 2012
From: shane at castlepoint.net (Shane Amante)
Date: Fri, 24 Feb 2012 13:04:20 -0700
Subject: do not filter your customers
In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
Message-ID: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>

Steve,

On Feb 24, 2012, at 11:10 AM, Steven Bellovin wrote:
> On Feb 24, 2012, at 7:46 40AM, Danny McPherson wrote:
>> On Feb 23, 2012, at 10:42 PM, Randy Bush wrote:
>>> the problem is that you have yet to rigorously define it and how to
>>> unambiguously and rigorously detect it.  lack of that will prevent
>>> anyone from helping you prevent it.
>> 
>> You referred to this incident as a "leak" in your message:
>> 
>> "a customer leaked a full table"
>> 
>> I was simply agreeing with you -- i.e., looked like a "leak", smelled 
>> like a "leak" - let's call it a leak.
>> 
>> I'm optimistic that all the good folks focusing on this in their day
>> jobs, and expressly funded and resourced to do so, will eventually
>> recognize what I'm calling "leaks" is part of the routing security 
>> problem.
>> 
> Sure; I don't disagree, and I don't think that Randy does.  But just
> because we can't solve the whole problem, does that mean we shouldn't
> solve any of it?

Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't understand why people keep ignoring this.

As has been discussed in the SIDR WG, BGPSEC will _increase_ state in BGP, (more DRAM needed in PE's and RR's, crypto processors to verify sigs, more UPDATE traffic for beaconing).  And, at the end of the day, ISP's are going to go to their customers and say to them:
- BGP convergence may be slower than in the past, because we're shipping sigs around in BGP now
- we can prevent a malicious attack from a random third-party (in the right part of the topology);
- *but* I can't protect you from a 20+ year old problem of a transit customer accidentally -or- maliciously stealing/dropping your traffic if they leak routes from one provider to another provider?


> As Randy said, we can't even try for a strong technical solution
> until we have a definition that's better than "I know it when I see it".

The first step is admitting that we have a problem, then discussing it collectively to try to determine a way to prevent said problem from happening.

-shane

From morrowc.lists at gmail.com  Fri Feb 24 14:54:35 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 15:54:35 -0500
Subject: do not filter your customers
In-Reply-To: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
Message-ID: <CAL9jLab+5QHfpWm0gkJJzECwa-498UPzJzNGTzB8c4-if9cdkw@mail.gmail.com>

On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante <shane at castlepoint.net> wrote:

> Solving for route leaks is /the/ "killer app" for BGPSEC. ?I can't understand why people keep ignoring this.

I don't think anyone's ignoring the problem... I think lots of people
have said an equivalent of:
1) "How do I know that this path: A - B - C - D
  is a 'leak'?"

Followed by:
2) "Tell me how to answer this programatically given the data we have
today in the routing system" (bgp data on the wire, IRR data, RIR
data)

so far ... both of the above questions haven't been answered (well 1
was answered with: "I will know it when i see it" which isn't helpful
at all in finding a solution)

-chris


From Joel.Snyder at Opus1.COM  Fri Feb 24 14:56:01 2012
From: Joel.Snyder at Opus1.COM (Joel M Snyder)
Date: Fri, 24 Feb 2012 13:56:01 -0700
Subject: Cool IPs: 1.234.35.245 brute force SSHing
Message-ID: <4F47F961.6050709@opus1.com>

Normally I wouldn't say anything to anyone about anything so mundane as 
brute-force SSH attacks, but this one caught my eye just because of the 
IP address:

	1.234.35.245

I wanna get a connection in Korea so I can have 1.234.56.78.


jms

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
jms at Opus1.COM                http://www.opus1.com/jms


From bicknell at ufp.org  Fri Feb 24 14:59:50 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 24 Feb 2012 12:59:50 -0800
Subject: do not filter your customers
In-Reply-To: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
Message-ID: <20120224205950.GA87433@ussenterprise.ufp.org>

In a message written on Fri, Feb 24, 2012 at 01:04:20PM -0700, Shane Amante wrote:
> Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't understand why people keep ignoring this.

Not all "leaks" are bad.

I remember when there was that undersea landside in Asia that took
out a bunch of undersea cables.  Various providers quickly did
mutual transit and other arrangements to route around the problem,
getting a number of things back up quite quickly.  These did not
match IRR records though, and likely would not have matached BGPSEC
information, at least not initially.

There are plenty of cases where someone "leaks" more specifics with
NO_EXPORT to only one of their BGP peers for the purposes of TE.

The challenge of securing BGP isn't crypto, and it isn't enough
ram/cpu/whatever to process it.  The challenge is getting a crypto
scheme that operators can use to easily represent the real world.
It turns out the real world is quite messy though, often full of
temporary hacks, unusual relationships and other issues.

I'm sure it will be solved, one day.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120224/1cfe65e8/attachment.bin>

From morrowc.lists at gmail.com  Fri Feb 24 15:07:28 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 16:07:28 -0500
Subject: do not filter your customers
In-Reply-To: <20120224205950.GA87433@ussenterprise.ufp.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <20120224205950.GA87433@ussenterprise.ufp.org>
Message-ID: <CAL9jLaYYkhv1v-kJQ4VPf=e0oxdWVzJ79VydWc9oWxnfdXp9Bw@mail.gmail.com>

On Fri, Feb 24, 2012 at 3:59 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 24, 2012 at 01:04:20PM -0700, Shane Amante wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC. ?I can't understand why people keep ignoring this.
>
> Not all "leaks" are bad.
>
> I remember when there was that undersea landside in Asia that took
> out a bunch of undersea cables. ?Various providers quickly did
> mutual transit and other arrangements to route around the problem,
> getting a number of things back up quite quickly. ?These did not
> match IRR records though, and likely would not have matached BGPSEC
> information, at least not initially.

well.... for bgpsec so if the paths were signed, and origins signed,
why would they NOT pass BGPSEC muster?

I can see that if the IRR data didn't match up sanely
prefix-lists/filters would need some cajoling, but that likely
happened anyway in this case.

-chris


From vincent.ferran-lacome at bnpparibas.com  Fri Feb 24 15:11:59 2012
From: vincent.ferran-lacome at bnpparibas.com (vincent.ferran-lacome at bnpparibas.com)
Date: Fri, 24 Feb 2012 22:11:59 +0100
Subject: AUTO : Vincent FERRAN-LACOME est absent(e). (retour 06/03/2012)
Message-ID: <OFCBFC0E72.B0F0F985-ONC12579AE.0074744C-C12579AE.0074744C@bnpparibas.com>



Je suis absent(e) du bureau jusqu'au 06/03/2012

Je suis absent pour le moment.
En cas de n?cessit?, merci de transmettre vos messages ? l'?quipe CSIRT:
csirt at bnpparibas.com
+33 1 40 14 26 95 (office hours UTC +1/+2)

--
I am currently out of office.
If necessary, please forward your messages to the CSIRT team:
csirt at bnpparibas.com
+33 1 40 14 26 95 (office hours UTC +1/+2)


Remarque?: ceci est une r?ponse automatique ? votre message  "NANOG Digest,
Vol 49, Issue 126" envoy? le 24/2/12 21:54:42.

C'est la seule notification que vous recevrez pendant l'absence de cette
personne.


This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential. 
If you receive this message in error,or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose, 
dissemination or disclosure, either whole or partial, is prohibited. Since the internet 
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS 
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified. 
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message") 
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de 
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas 
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie. 
N'imprimez ce message que si necessaire, pensez a l'environnement.

From bicknell at ufp.org  Fri Feb 24 15:29:11 2012
From: bicknell at ufp.org (Leo Bicknell)
Date: Fri, 24 Feb 2012 13:29:11 -0800
Subject: do not filter your customers
In-Reply-To: <CAL9jLaYYkhv1v-kJQ4VPf=e0oxdWVzJ79VydWc9oWxnfdXp9Bw@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <20120224205950.GA87433@ussenterprise.ufp.org>
 <CAL9jLaYYkhv1v-kJQ4VPf=e0oxdWVzJ79VydWc9oWxnfdXp9Bw@mail.gmail.com>
Message-ID: <20120224212911.GA88380@ussenterprise.ufp.org>

In a message written on Fri, Feb 24, 2012 at 04:07:28PM -0500, Christopher Morrow wrote:
> well.... for bgpsec so if the paths were signed, and origins signed,
> why would they NOT pass BGPSEC muster?

I honestly have trouble keeping the BGP security work straight.
There is work to secure the sessions, work to authenticate route
origin, work to authenticate the AS-Path, the peer relationships,
and so on.

I believe BGPSEC authenticates the AS-Path, and thus turning up a
new peer requires them to each sign each others "path object".

During the time period between when the route propogates and the
signature propogates these routes appear to be a leak.  I don't
believe the signature data is moved via BGP.  Worse, in this case,
imagine if one of the parties was "cut off" from the signature
distribution system.  They would need to bring up their (non-validating)
routes to reach the signature distribution system before their
routes would be accepted!

In fact, this happens today with those who strict IRR filter.  Try
getting a block from ARIN, and then service from a provider who
only uses IRR filters.  The answer is to go to some other already
up and working network to submit your IRR data to the IRR server,
before your network can come up and be accepted!

On a new turn up for an end-user, not a big deal.  When you look at the
problems that might occur in the face of natural or man made disasters
though, like the cable cut, it could result in outages that could have
been fixed in minutes with a non-validing system taking hours to fix in
a validating one.

That may be an acceptable trade off to get security; but it depends on
exactly what the trade off ends up being.  To date, I personally have
found "insecure" BGP, even with the occasional leaks, to be a better
overall solution.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120224/f46b3dcf/attachment.bin>

From cidr-report at potaroo.net  Fri Feb 24 16:00:01 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 24 Feb 2012 22:00:01 GMT
Subject: BGP Update Report
Message-ID: <201202242200.q1OM01ck025021@wattle.apnic.net>

BGP Update Report
Interval: 16-Feb-12 -to- 23-Feb-12 (7 days)
Observation Point: BGP Peering with AS131072

TOP 20 Unstable Origin AS
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS8402            86391  2.5%      43.1 -- CORBINA-AS OJSC "Vimpelcom"
 2 - AS9829            35953  1.1%      30.4 -- BSNL-NIB National Internet Backbone
 3 - AS12479           29505  0.9%      48.4 -- UNI2-AS France Telecom Espana SA
 4 - AS7029            25688  0.8%       7.2 -- WINDSTREAM - Windstream Communications Inc
 5 - AS32528           23683  0.7%    2368.3 -- ABBOTT Abbot Labs
 6 - AS11014           21552  0.6%     215.5 -- CPS
 7 - AS5800            21107  0.6%      73.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
 8 - AS2118            20463  0.6%      14.6 -- RELCOM-AS OOO "NPO Relcom"
 9 - AS20632           20097  0.6%     467.4 -- PETERSTAR-AS PeterStar
10 - AS17974           17654  0.5%      10.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia
11 - AS28573           17644  0.5%      10.4 -- NET Servicos de Comunicao S.A.
12 - AS7552            17220  0.5%      12.0 -- VIETEL-AS-AP Vietel Corporation
13 - AS9498            16401  0.5%      18.2 -- BBIL-AP BHARTI Airtel Ltd.
14 - AS8151            15735  0.5%      10.5 -- Uninet S.A. de C.V.
15 - AS6389            15060  0.4%       4.4 -- BELLSOUTH-NET-BLK - BellSouth.net Inc.
16 - AS4780            14637  0.4%      18.2 -- SEEDNET Digital United Inc.
17 - AS9583            13263  0.4%      10.0 -- SIFY-AS-IN Sify Limited
18 - AS6066            12854  0.4%    6427.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
19 - AS52251           12849  0.4%     166.9 -- NORTECH
20 - AS13277           12786  0.4%    6393.0 -- HP-MS HP-MS Autonomous System


TOP 20 Unstable Origin AS (Updates per announced prefix)
Rank ASN                Upds     %  Upds/Pfx    AS-Name
 1 - AS29126            7801  0.2%    7801.0 -- DATIQ-AS Datiq B.V.
 2 - AS6066            12854  0.4%    6427.0 -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 3 - AS13277           12786  0.4%    6393.0 -- HP-MS HP-MS Autonomous System
 4 - AS30133            2768  0.1%    2768.0 -- ISC-F-AS - Internet Systems Consortium, Inc.
 5 - AS23154           11977  0.3%    2395.4 -- SANMINA-SCI Sanmina-SCI Corporation
 6 - AS32528           23683  0.7%    2368.3 -- ABBOTT Abbot Labs
 7 - AS32669            1483  0.0%    1483.0 -- WACOMT2004 - WACOM TECHNOLOGY
 8 - AS53362             944  0.0%     944.0 -- MIXIT-AS - Mixit, Inc.
 9 - AS44774            1588  0.1%     794.0 -- ZOLOTOY-KLYUCHIK-AS OOO CTO KKM Zolotoy Klyuchik
10 - AS2                 784  0.0%     406.0 -- AUSTRALIAN-SYNCHROTRON-AS-AP Australian Synchrotron
11 - AS55665             697  0.0%     697.0 -- STMI-AS-ID PT Sampoerna Telemedia Indonesia
12 - AS3                 689  0.0%    1756.0 -- MILICHSOFT-NET-AS Milichsoft Rafal Miliszewski
13 - AS16715            1158  0.0%     579.0 -- ARISTOTLE-ASN - Aristotle Internet Access
14 - AS11943             945  0.0%     472.5 -- GLOBE - Globe Wireless
15 - AS20632           20097  0.6%     467.4 -- PETERSTAR-AS PeterStar
16 - AS9430            12146  0.3%     433.8 -- STPI-NOIDA Software Technology Parks of India,Block-IV
17 - AS36980             404  0.0%     404.0 -- JOHNHOLT-ASN
18 - AS49239             385  0.0%     385.0 -- FIL-AS IP Fil Elena Leonidovna
19 - AS21452            1884  0.1%     376.8 -- skannet-ibadan
20 - AS57228             376  0.0%     376.0 -- IMTECH-ICT-UK-AS Imtech ICT Limited


TOP 20 Unstable Prefixes
Rank Prefix             Upds     % Origin AS -- AS Name
 1 - 84.204.132.0/24   19732  0.6%   AS20632 -- PETERSTAR-AS PeterStar
 2 - 148.164.14.0/24   11951  0.3%   AS23154 -- SANMINA-SCI Sanmina-SCI Corporation
 3 - 130.36.34.0/24    11815  0.3%   AS32528 -- ABBOTT Abbot Labs
 4 - 130.36.35.0/24    11815  0.3%   AS32528 -- ABBOTT Abbot Labs
 5 - 202.92.235.0/24   11425  0.3%   AS9498  -- BBIL-AP BHARTI Airtel Ltd.
 6 - 62.36.252.0/22     8420  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
 7 - 217.170.24.0/21    7801  0.2%   AS29126 -- DATIQ-AS Datiq B.V.
 8 - 204.29.239.0/24    6427  0.2%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
 9 - 150.225.0.0/16     6427  0.2%   AS6066  -- VERIZON-BUSINESS-MAE-AS6066 - Verizon Business Network Services Inc.
10 - 194.209.13.0/24    6393  0.2%   AS13277 -- HP-MS HP-MS Autonomous System
11 - 194.209.211.0/24   6393  0.2%   AS13277 -- HP-MS HP-MS Autonomous System
12 - 62.36.249.0/24     6365  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
13 - 62.36.241.0/24     5836  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
14 - 62.36.210.0/24     5605  0.2%   AS12479 -- UNI2-AS France Telecom Espana SA
15 - 194.63.9.0/24      4707  0.1%   AS1273  -- CW Cable and Wireless Worldwide plc
16 - 205.73.118.0/24    4447  0.1%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
17 - 205.73.116.0/23    4342  0.1%   AS5976  -- DNIC-ASBLK-05800-06055 - DoD Network Information Center
18 - 111.125.126.0/24   4115  0.1%   AS17639 -- COMCLARK-AS ComClark Network & Technology Corp.
19 - 12.5.58.0/23       4021  0.1%   AS12163 -- BNSI - Broadband Network Services, Inc.
20 - 190.67.172.0/22    3859  0.1%   AS3816  -- COLOMBIA TELECOMUNICACIONES S.A. ESP

Details at http://bgpupdates.potaroo.net
------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From cidr-report at potaroo.net  Fri Feb 24 16:00:00 2012
From: cidr-report at potaroo.net (cidr-report at potaroo.net)
Date: Fri, 24 Feb 2012 22:00:00 GMT
Subject: The Cidr Report
Message-ID: <201202242200.q1OM00Gp025015@wattle.apnic.net>

This report has been generated at Fri Feb 24 21:12:17 2012 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.

Check http://www.cidr-report.org for a current version of this report.

Recent Table History
        Date      Prefixes    CIDR Agg
        17-02-12    400903      232885
        18-02-12    400942      231397
        19-02-12    400700      231459
        20-02-12    400828      231569
        21-02-12    400514      231895
        22-02-12    401059      231955
        23-02-12    401447      231743
        24-02-12    400967      232887


AS Summary
         40323  Number of ASes in routing system
         16892  Number of ASes announcing only one prefix
          3457  Largest number of prefixes announced by an AS
                AS7029 : WINDSTREAM - Windstream Communications Inc
      110149152  Largest address span announced by an AS (/32s)
                AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street


Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as 
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').

 --- 24Feb12 ---
ASnum    NetsNow NetsAggr  NetGain   % Gain   Description

Table     401393   232884   168509    42.0%   All ASes

AS6389      3433      202     3231    94.1%   BELLSOUTH-NET-BLK -
                                               BellSouth.net Inc.
AS7029      3457     1723     1734    50.2%   WINDSTREAM - Windstream
                                               Communications Inc
AS4766      2489     1014     1475    59.3%   KIXS-AS-KR Korea Telecom
AS22773     1536      119     1417    92.3%   ASN-CXA-ALL-CCI-22773-RDC -
                                               Cox Communications Inc.
AS2118      1398       14     1384    99.0%   RELCOM-AS OOO "NPO Relcom"
AS18566     2091      724     1367    65.4%   COVAD - Covad Communications
                                               Co.
AS4323      1608      383     1225    76.2%   TWTC - tw telecom holdings,
                                               inc.
AS28573     1685      463     1222    72.5%   NET Servicos de Comunicao S.A.
AS4755      1557      406     1151    73.9%   TATACOMM-AS TATA
                                               Communications formerly VSNL
                                               is Leading ISP
AS1785      1876      797     1079    57.5%   AS-PAETEC-NET - PaeTec
                                               Communications, Inc.
AS19262     1388      398      990    71.3%   VZGNI-TRANSIT - Verizon Online
                                               LLC
AS10620     1751      766      985    56.3%   Telmex Colombia S.A.
AS7552      1282      323      959    74.8%   VIETEL-AS-AP Vietel
                                               Corporation
AS7303      1328      405      923    69.5%   Telecom Argentina S.A.
AS26615      881       32      849    96.4%   Tim Celular S.A.
AS8151      1485      671      814    54.8%   Uninet S.A. de C.V.
AS4808      1148      346      802    69.9%   CHINA169-BJ CNCGROUP IP
                                               network China169 Beijing
                                               Province Network
AS18101      950      158      792    83.4%   RELIANCE-COMMUNICATIONS-IN
                                               Reliance Communications
                                               Ltd.DAKC MUMBAI
AS17974     1725     1039      686    39.8%   TELKOMNET-AS2-AP PT
                                               Telekomunikasi Indonesia
AS9498       893      210      683    76.5%   BBIL-AP BHARTI Airtel Ltd.
AS24560     1011      334      677    67.0%   AIRTELBROADBAND-AS-AP Bharti
                                               Airtel Ltd., Telemedia
                                               Services
AS7545      1643      967      676    41.1%   TPG-INTERNET-AP TPG Internet
                                               Pty Ltd
AS9394       878      211      667    76.0%   CRNET CHINA RAILWAY
                                               Internet(CRNET)
AS30036     1415      758      657    46.4%   MEDIACOM-ENTERPRISE-BUSINESS -
                                               Mediacom Communications Corp
AS3356      1101      457      644    58.5%   LEVEL3 Level 3 Communications
AS17676      686       75      611    89.1%   GIGAINFRA Softbank BB Corp.
AS15557     1099      514      585    53.2%   LDCOMNET Societe Francaise du
                                               Radiotelephone S.A
AS3549       988      431      557    56.4%   GBLX Global Crossing Ltd.
AS4780       792      242      550    69.4%   SEEDNET Digital United Inc.
AS22047      581       33      548    94.3%   VTR BANDA ANCHA S.A.

Total      44155    14215    29940    67.8%   Top 30 total


Possible Bogus Routes

        10.86.64.32/30       AS65530 -Private Use AS-
        10.86.64.36/30       AS65530 -Private Use AS-
        10.86.65.32/30       AS65530 -Private Use AS-
        10.86.65.36/30       AS65530 -Private Use AS-
        10.255.255.0/30      AS65530 -Private Use AS-
        10.255.255.4/30      AS65530 -Private Use AS-
        10.255.255.8/30      AS65530 -Private Use AS-
        14.192.0.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.4.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.8.0/22        AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.12.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.16.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.20.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.24.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        14.192.28.0/22       AS45464 NEXTWEB-AS-AP Room 201, TGU Bldg
        27.112.114.0/24      AS23884 PROENNET-AS Proimage Engineering and Communication Co.,Ltd.
        37.131.240.0/21      AS15743 IPH net.de AG
        41.222.79.0/24       AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited
        62.61.220.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        62.61.221.0/24       AS24974 TACHYON-EU Tachyon Europe BV
        64.21.192.0/20       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.212.0/22       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        64.21.216.0/21       AS11610 INETNEBR-1 - Internet Nebraska Corporation
        66.129.0.0/19        AS3901  ARRAKIS - Higher Technology Services
        66.180.239.0/24      AS35888 VIGNETTE - VIGNETTE CORPORATION
        66.207.32.0/20       AS23011 
        66.245.176.0/20      AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC
        66.251.128.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.133.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.134.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.136.0/21      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.140.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.141.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.142.0/24      AS33227 BLUEBRIDGE-NETWORKS - Blue Bridge Networks
        66.251.143.0/24      AS3356  LEVEL3 Level 3 Communications
        69.46.224.0/20       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.233.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        69.46.236.0/24       AS32592 HUNT-BROTHERS-OF-LOUISIANA-LLC - Hunt Brothers
        71.19.134.0/23       AS3313  INET-AS BT Italia S.p.A.
        72.44.16.0/20        AS15054 HAMELTRONICS - Hameltronics, LLC
        98.159.96.0/20       AS46975 
        103.6.120.0/22       AS56049 EASYLINK-NET-HK Flat/RM 1 BLK2 16/F
        110.34.44.0/22       AS12653 COMTONET KB Impuls Hellas S.A.
        116.206.72.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.85.0/24      AS6461  MFNX MFN - Metromedia Fiber Network
        116.206.103.0/24     AS6461  MFNX MFN - Metromedia Fiber Network
        117.120.56.0/21      AS4755  TATACOMM-AS TATA Communications formerly VSNL is Leading ISP
        121.46.0.0/16        AS4134  CHINANET-BACKBONE No.31,Jin-rong Street
        142.54.0.0/19        AS23498 CDSI - Cogeco Data Services Inc.
        172.45.1.0/24        AS3356  LEVEL3 Level 3 Communications
        172.45.2.0/24        AS29571 CITelecom-AS
        172.45.3.0/24        AS29571 CITelecom-AS
        172.102.0.0/22       AS4812  CHINANET-SH-AP China Telecom (Group)
        190.104.32.0/21      AS27882 Telef?nica Celular de Bolivia S.A.
        193.0.22.0/23        AS3333  RIPE-NCC-AS RIPE Network Coordination Centre
        200.6.93.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.94.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.6.95.0/24        AS6400  Compa??a Dominicana de Tel?fonos, C. por A. - CODETEL
        200.23.84.0/24       AS8151  Uninet S.A. de C.V.
        200.24.73.0/24       AS26061 Equant Colombia
        200.33.40.0/24       AS11172 Alestra, S. de R.L. de C.V.
        200.34.0.0/20        AS6342  Instituto Tecnol?gico y de Estudios Superiores de Monterrey
        200.53.0.0/19        AS13878 Diveo do Brasil Telecomunicacoes Ltda
        202.1.224.0/24       AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000
        202.8.106.0/24       AS9530  SHINSEGAE-AS SHINSEGAE I&C Co., Ltd.
        202.20.108.0/23      AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama
        202.58.113.0/24      AS19161 
        202.61.75.0/24       AS9927  PHILCOMNET-PH A Multihomed ISP Company
        202.83.120.0/21      AS37972 
        202.83.124.0/24      AS37972 
        202.83.125.0/24      AS37972 
        202.83.126.0/24      AS37972 
        202.86.32.0/20       AS18255 BRISBANE-AP Brisbane City Council
        202.94.1.0/24        AS4808  CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
        202.133.70.0/24      AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited
        202.140.128.0/19     AS9583  SIFY-AS-IN Sify Limited
        202.160.152.0/22     AS10113 EFTEL-AS-AP Eftel Limited.
        202.174.125.0/24     AS9498  BBIL-AP BHARTI Airtel Ltd.
        202.176.1.0/24       AS9942  COMINDICO-AP SOUL Converged Communications Australia
        202.179.134.0/24     AS23966 LDN-AS-PK LINKdotNET Telecom Limited
        203.23.1.0/24        AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.24.38.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.30.127.0/24      AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/23       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.86.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.87.0/24       AS18111 NETSPEED-AS-AP Netspeed Internet Communications
        203.32.188.0/24      AS1221  ASN-TELSTRA Telstra Pty Ltd
        203.142.219.0/24     AS45149 
        205.150.0.0/15       AS701   UUNET - MCI Communications Services, Inc. d/b/a Verizon Business
        205.175.214.0/24     AS5583  ORANGE-BUSINESS-SERVICES-BENELUX France Telecom S.A.
        206.123.129.0/24     AS10790 INREACH-AS - InReach Internet
        206.197.184.0/24     AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company
        207.174.131.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.132.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.152.0/23     AS26116 INDRA - Indra's Net Inc
        207.174.154.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.155.0/24     AS26116 INDRA - Indra's Net Inc
        207.174.200.0/24     AS22658 EARTHNET - Earthnet, Inc.
        207.174.248.0/21     AS6653  PRIVATEI - privateI, LLC
        207.231.96.0/19      AS11194 NUNETPA - NuNet Inc.
        208.83.53.0/24       AS40569 YGOMI-AS - Ygomi LLC
        208.91.56.0/21       AS22241 IC2NET - IC2NET
        208.91.56.0/24       AS22241 IC2NET - IC2NET
        208.91.57.0/24       AS22241 IC2NET - IC2NET
        208.91.58.0/24       AS22241 IC2NET - IC2NET
        208.91.59.0/24       AS22241 IC2NET - IC2NET
        208.91.60.0/24       AS22241 IC2NET - IC2NET
        208.91.61.0/24       AS22241 IC2NET - IC2NET
        208.91.62.0/24       AS22241 IC2NET - IC2NET
        208.91.63.0/24       AS22241 IC2NET - IC2NET
        209.133.224.0/19     AS4323  TWTC - tw telecom holdings, inc.
        209.148.64.0/19      AS13773 TELNETCOMM - Telnet Communications
        209.177.64.0/20      AS6461  MFNX MFN - Metromedia Fiber Network
        209.213.0.0/20       AS33005 ELTOPIA - Eltopia.com, LLC
        209.222.240.0/22     AS19747 
        210.56.150.0/23      AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED
        216.12.160.0/20      AS26627 AS-PILOSOFT - Pilosoft, Inc.
        216.21.160.0/20      AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport
        216.194.160.0/20     AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport


Please see http://www.cidr-report.org for the full report

------------------------------------
Copies of this report are mailed to:
  nanog at nanog.org
  eof-list at ripe.net
  apops at apops.net
  routing-wg at ripe.net
  afnog at afnog.org


From morrowc.lists at gmail.com  Fri Feb 24 16:04:40 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 17:04:40 -0500
Subject: do not filter your customers
In-Reply-To: <20120224212911.GA88380@ussenterprise.ufp.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <20120224205950.GA87433@ussenterprise.ufp.org>
 <CAL9jLaYYkhv1v-kJQ4VPf=e0oxdWVzJ79VydWc9oWxnfdXp9Bw@mail.gmail.com>
 <20120224212911.GA88380@ussenterprise.ufp.org>
Message-ID: <CAL9jLaa4oA-VrPKiGGh_gPGrSJ=iaFTb+T_AiV0p0x13TyTqEw@mail.gmail.com>

On Fri, Feb 24, 2012 at 4:29 PM, Leo Bicknell <bicknell at ufp.org> wrote:
> In a message written on Fri, Feb 24, 2012 at 04:07:28PM -0500, Christopher Morrow wrote:
>> well.... for bgpsec so if the paths were signed, and origins signed,
>> why would they NOT pass BGPSEC muster?
>
> I honestly have trouble keeping the BGP security work straight.

yes

> There is work to secure the sessions, work to authenticate route
> origin, work to authenticate the AS-Path, the peer relationships,
> and so on.
>
> I believe BGPSEC authenticates the AS-Path, and thus turning up a
> new peer requires them to each sign each others "path object".

well currently it doesn't do anything (really) but the PLAN is that
you'd be able to look at the origin, view some transitive
community/attribute and say: "That validates with the roa data" - some
cert-check/hash-check/etc.

then later on you'd be able to say for each AS in the ASPATH:
  "Yes, the route is signed by AS1, the signature validates. Yes the
route is signed by AS2, the signature validates (wash/rinse/repeat for
the whole path)"

> During the time period between when the route propogates and the
> signature propogates these routes appear to be a leak. ?I don't

signatures follow inside the announcement as currently draft-spec'd.

> believe the signature data is moved via BGP. ?Worse, in this case,
> imagine if one of the parties was "cut off" from the signature
> distribution system. ?They would need to bring up their (non-validating)
> routes to reach the signature distribution system before their
> routes would be accepted!

the sig data for an NLRI follows along inside the announcement.
the cache of data is probably updated inside of a day... there's
likely some skew, but provided the origins don't change and no one has
to emergency release new key materials, I think it's not important for
this discussion.

you simply start hearing routes with same origin as previously on
different paths. "new customers" essentially pop up en-mass. This
isn't a problem as long as the customers are the same origin-as as
before... it'd mean some rejiggering of prefix-lists (as I said
before) but ... you'd be doing that anyway.

> In fact, this happens today with those who strict IRR filter. ?Try
> getting a block from ARIN, and then service from a provider who
> only uses IRR filters. ?The answer is to go to some other already
> up and working network to submit your IRR data to the IRR server,
> before your network can come up and be accepted!

right, there's some lag between publication and acceptance/update. I
think in the case of (for example L(3) the lag is ~6hrs in the worst
case.

> On a new turn up for an end-user, not a big deal. ?When you look at the
> problems that might occur in the face of natural or man made disasters
> though, like the cable cut, it could result in outages that could have
> been fixed in minutes with a non-validing system taking hours to fix in
> a validating one.

I don't think that's really the case, but walking through the
processes/requirements seems like a sane thing to do.

> That may be an acceptable trade off to get security; but it depends on
> exactly what the trade off ends up being. ?To date, I personally have
> found "insecure" BGP, even with the occasional leaks, to be a better
> overall solution.

how's that chinese leak of F-root doing for you? :)

-chris


From smb at cs.columbia.edu  Fri Feb 24 16:04:43 2012
From: smb at cs.columbia.edu (Steven Bellovin)
Date: Fri, 24 Feb 2012 17:04:43 -0500
Subject: do not filter your customers
In-Reply-To: <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
Message-ID: <8166C61D-518A-43F9-8D0C-A27C13905379@cs.columbia.edu>


On Feb 24, 2012, at 2:26 14PM, Danny McPherson wrote:

> 
> On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:
> 
>> But just because we can't solve the whole problem, does that
>> mean we shouldn't solve any of it?
> 
> Nope, we most certainly should decompose the problem into 
> addressable elements, that's core to engineering and operations.
> 
> However, simply because the currently envisaged solution 
> doesn't solve this problem doesn't mean we shouldn't 
> acknowledge it exists.
> 
> The IETF's BGP security threats document [1]  "describes a threat 
> model for BGP path security", which constrains itself to the 
> carefully worded SIDR WG charter, which addresses route origin 
> authorization and AS_PATH "semantics" -- i.e., this "leak" 
> problem is expressly out of scope of a threats document
> discussing BGP path security - eh? 
> 
> How the heck we can talk about BGP path security and not 
> consider this incident a threat is beyond me, particularly when it 
> happens by accident all the time.  How we can justify putting all 
> that BGPSEC and RPKI machinery in place and not address this 
> "leak" issue somewhere in the mix is, err.., telling.


I repeat -- we're in violent agreement that route leaks are
a serious problem.  No one involved in BGPSEC -- not me, not Randy,
not anyone -- disagrees.  Give us an actionable definition and
we'll try to build a defense.  Right now, we have nothing better
than what Justice Potter Stewart once said in an opinion: "I shall 
not today attempt further to define the kinds of material I 
understand to be embraced within that shorthand description 
["hard-core pornography"]; and perhaps I could never succeed 
in intelligibly doing so. But I know it when I see it..."

Again -- *please* give us a definition.

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

P.S. It was routing problems, including leaks between RIP and either
EIGRP or OSPF (it's been >20 years; I just don't remember), that got
me involved in Internet security in the first place.  I really do
understand the issue.



From gbonser at seven.com  Fri Feb 24 16:06:31 2012
From: gbonser at seven.com (George Bonser)
Date: Fri, 24 Feb 2012 22:06:31 +0000
Subject: do not filter your customers
In-Reply-To: <20120224205950.GA87433@ussenterprise.ufp.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <20120224205950.GA87433@ussenterprise.ufp.org>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CE6AC6@RWC-MBX1.corp.seven.com>

> -----Original Message-----
> From: Leo Bicknell 
> Sent: Friday, February 24, 2012 1:00 PM

> There are plenty of cases where someone "leaks" more specifics with
> NO_EXPORT to only one of their BGP peers for the purposes of TE.
> 
> The challenge of securing BGP isn't crypto, and it isn't enough
> ram/cpu/whatever to process it.  The challenge is getting a crypto
> scheme that operators can use to easily represent the real world.
> It turns out the real world is quite messy though, often full of
> temporary hacks, unusual relationships and other issues.
> 
> I'm sure it will be solved, one day.

I can think of a way to do it but it would require some trust and it would require that people actually *used* it.  What one would do is feed the routes they are proposing to send to a BGP peer to a RIR front-end.  The receiving peer would "sign off" on the proposal and the routes would be then entered into the RIR.  That is the step that is currently missing.  Anyone can enter practically anything into an RIR and the receiving side never gets to "sanity check" the information before it actually gets written to the database.  Once you have this base of information, route filtration generated from the database becomes more reliable.

In fact, a network might have several "canned" profiles of different route packages registered in the front end. A "transit" package, a "customer routes" package and maybe some specialized packages for peering at various private/public exchange points.  If you pick up a new peer at a transit point, you select the package for that point, it proposes that to the peer, peer approves it, and they can both generate their route filters from that information.

It could even highlight some glaring errors automatically to spot what might be a typo or even attempted nefarious activity.  The receiver of a proposed change might be alerted to the fact that the new route(s) being offered are inconsistent with the database information (routes already being sourced by an AS that the proposed sender is not peering with) which could be overridden by the receiver (or just ignored) but having something show up in some way that highlights a possible inconsistency might generate a closer look at that proposal and head off problems later.

But the fundamental problem is that the current system is "open loop".



From gih at apnic.net  Fri Feb 24 16:08:54 2012
From: gih at apnic.net (Geoff Huston)
Date: Sat, 25 Feb 2012 09:08:54 +1100
Subject: do not filter your customers
In-Reply-To: <CAL9jLab+5QHfpWm0gkJJzECwa-498UPzJzNGTzB8c4-if9cdkw@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <CAL9jLab+5QHfpWm0gkJJzECwa-498UPzJzNGTzB8c4-if9cdkw@mail.gmail.com>
Message-ID: <2EE7FD57-2CF6-40A2-B384-9457947593AA@apnic.net>


On 25/02/2012, at 7:54 AM, Christopher Morrow wrote:

> On Fri, Feb 24, 2012 at 3:04 PM, Shane Amante <shane at castlepoint.net> wrote:
> 
>> Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't understand why people keep ignoring this.
> 
> I don't think anyone's ignoring the problem... I think lots of people
> have said an equivalent of:
> 1) "How do I know that this path: A - B - C - D
>  is a 'leak'?"
> 

If you are receiving  a path of the form (A B C D), and the origination of the prefix at D is good, then the only way you can figure out this is a leak as compare to the intentional operation of BGP is not by looking at the operation of protocol per se, but by looking at the routing policy intentions of A, B, C and D and working out if what you are seeing is intentional within the scope of the routing policies of these entities. RPSL is one such approach of describing such policy in a manner that one could perform some basic computation over the data.

It exposes a broader issue here about the difference between routing intent and protocol correctness. From the perspective of protocol correctness, regardless of whether the information was intended to be propagated, a protocol correctness tool should be able to tell you that the information has been faithfully propagated, but cannot tell you whether such propagation was intentional or not.


> Followed by:
> 2) "Tell me how to answer this programatically given the data we have
> today in the routing system" (bgp data on the wire, IRR data, RIR
> data)
> 

I wish.

> so far ... both of the above questions haven't been answered (well 1
> was answered with: "I will know it when i see it" which isn't helpful
> at all in finding a solution)


Some longstanding problems are longstanding because we have not quite managed to apply the appropriate analytical approach to the problem. Others are longstanding problems because they are damn difficult and this makes me wonder if we really understand the nature of the space we are working in. For example, if you think about routing not as a topology and reachability tool, but an distributed algorithm to solve a set of simultaneous equations (policies) would that provide a different insight as to the way in which routing policies and routing protocols interact? 

Geoff







From leigh.porter at ukbroadband.com  Fri Feb 24 16:45:26 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Fri, 24 Feb 2012 22:45:26 +0000
Subject: HP A6600 experiences
In-Reply-To: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
References: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
Message-ID: <D181DDABABE57E4DB72FEE00331478644B9A53@EALPO1.ukbroadband.com>


I thought the A6604 was EOL?

http://h17007.www1.hp.com/docs/products/eos/Select_HP_A6600_Routers_and_Modules_ES_Announcement.pdf


--
Leigh


> -----Original Message-----
> From: Christopher Pilkington [mailto:cjp at 0x1.net]
> Sent: 24 February 2012 19:05
> To: NANOG mailing list
> Subject: HP A6600 experiences
> 
> If anyone has any experiences they'd be willing to share, or even lab
> reports, on HP A6600, it would be helpful.  I believe this is the same
> product as H3C SR6600.
> 
> We're being asked to "look at" A6604 facing our IPv4/IPv6 transit.  I'd
> like to get some opinions before I go through effort of getting one in
> the lab.
> 
> -cjp
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud
> service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________

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


From nick at foobar.org  Fri Feb 24 17:16:06 2012
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 24 Feb 2012 23:16:06 +0000
Subject: do not filter your customers
In-Reply-To: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
Message-ID: <4F481A36.8090701@foobar.org>

On 24/02/2012 20:04, Shane Amante wrote:
> Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't
> understand why people keep ignoring this.

I'd be interested to hear your opinions on exactly how rpki in its current
implementation would have prevented the optus/telstra problem.  Could you
elaborate?

Here's a quote from draft-ietf-sidr-origin-ops:

>    As the BGP origin AS of an update is not signed, origin validation is
>    open to malicious spoofing.  Therefore, RPKI-based origin validation
>    is designed to deal only with inadvertent mis-advertisement.
> 
>    Origin validation does not address the problem of AS-Path validation.
>    Therefore paths are open to manipulation, either malicious or
>    accidental.

An optus/telstra style problem might have been mitigated by an rpki based
full path validation mechanism, but we don't have path validation.  Right
now, we only have a draft of a list of must-have features -
draft-ietf-sidr-bgpsec-reqs.  This is only the first step towards designing
a functional protocol, not to mind having running code.

Nick


From nick at foobar.org  Fri Feb 24 17:20:19 2012
From: nick at foobar.org (Nick Hilliard)
Date: Fri, 24 Feb 2012 23:20:19 +0000
Subject: do not filter your customers
In-Reply-To: <20120224205950.GA87433@ussenterprise.ufp.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <20120224205950.GA87433@ussenterprise.ufp.org>
Message-ID: <4F481B33.9000600@foobar.org>

On 24/02/2012 20:59, Leo Bicknell wrote:
> It turns out the real world is quite messy though, often full of
> temporary hacks, unusual relationships and other issues.

... and, if you create a top-down control mechanism to be superimposed upon
the current fully distributed control mechanism, you will soon find that
politicians and regulators will take a very keen interest in BGP once they
realise that they can turn off specific prefixes from a single point.

Whatever about temporary hacks and unusual relationships, the entropy
introduced by layers 9 through 12 is almost always insufferable.

Nick



From randy at psg.com  Fri Feb 24 18:38:45 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 25 Feb 2012 06:08:45 +0530
Subject: do not filter your customers
In-Reply-To: <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
Message-ID: <m2hayf7nmy.wl%randy@psg.com>

>> I'm optimistic that all the good folks focusing on this in their day
>> jobs, and expressly funded and resourced to do so, will eventually
>> recognize what I'm calling "leaks" is part of the routing security 
>> problem.
>> 
> Sure; I don't disagree, and I don't think that Randy does.  But just
> because we can't solve the whole problem, does that mean we shouldn't
> solve any of it?

is it a *security* problem?  it is a violation of business intent.  and
one we would like to solve.  but it is not clear to me that 'leaks' are
really a security issue.

randy


From randy at psg.com  Fri Feb 24 18:49:15 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 25 Feb 2012 06:19:15 +0530
Subject: do not filter your customers
In-Reply-To: <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
Message-ID: <m2aa47ohys.wl%randy@psg.com>

> Solving for route leaks is /the/ "killer app" for BGPSEC.

as would be solving world hunger, war, bad cooking, especially bad
cooking.

route leaks, as much as i understand them
  o are indeed bad ops issues
  o are not security per se
  o are a violation of business relationshiops
  o and 20 years of fighting them have not given us any significant
    increase in understanding, formal definition, or prevention.

i would love to see progress on the route leak problem.  i do not
confuddle it with security.

randy


From young at jsyoung.net  Fri Feb 24 19:24:57 2012
From: young at jsyoung.net (Jeffrey S. Young)
Date: Sat, 25 Feb 2012 12:24:57 +1100
Subject: do not filter your customers
In-Reply-To: <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
Message-ID: <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>

1.  Make your customers register routes, then filter them.
     (may be time for big providers to put routing tools into 
     open source for the good of the community - make it 
     less hard?)

2.  Implement the "1-hop" hack to protect your BGP peering.

98% of problem solved on the Internet today

3.  Implement a "# of routes-type" filter to make your peers 
     (and transit customers) phone you if they really do want 
     to add 500,000 routes to your session ( or the wrong set
     of YouTube routes...).

99.9% of problem solved.

4.  Implement BGP-Sec

99.91% of "this" problem solved.

Because #1 is 'just too hard' and because #4 is just too sexy 
as an academic pursuit we all suffer the consequences.  It's
a shame that tier one peering agreements didn't evolve with
a 'filter your customers' clause (aka do the right thing) as well
as a 'like for like' (similar investments) clause in them.

I'm not downplaying the BGP-SEC work, I think it's valid and
may one day save us from some smart bunny who wants to
make a name for himself by bringing the Internet to a halt.  I
don't believe that's what we're battling here.  We're battling the
operational cost of doing the right thing with the toolset we have
versus waiting for a utopian solution (foolproof and free) that may 
never come.

jy

ps. my personal view.

On 25/02/2012, at 6:26 AM, Danny McPherson <danny at tcb.net> wrote:

> 
> On Feb 24, 2012, at 1:10 PM, Steven Bellovin wrote:
> 
>> But just because we can't solve the whole problem, does that
>> mean we shouldn't solve any of it?
> 
> Nope, we most certainly should decompose the problem into 
> addressable elements, that's core to engineering and operations.
> 
> However, simply because the currently envisaged solution 
> doesn't solve this problem doesn't mean we shouldn't 
> acknowledge it exists.
> 
> The IETF's BGP security threats document [1]  "describes a threat 
> model for BGP path security", which constrains itself to the 
> carefully worded SIDR WG charter, which addresses route origin 
> authorization and AS_PATH "semantics" -- i.e., this "leak" 
> problem is expressly out of scope of a threats document
> discussing BGP path security - eh? 
> 
> How the heck we can talk about BGP path security and not 
> consider this incident a threat is beyond me, particularly when it 
> happens by accident all the time.  How we can justify putting all 
> that BGPSEC and RPKI machinery in place and not address this 
> "leak" issue somewhere in the mix is, err.., telling.
> 
> Alas, I suspect we can all agree that experiments are good and 
> the market will ultimately decide.
> 
> -danny
> 
> [1] draft-ietf-sidr-bgpsec-threats-02
> 


From rdobbins at arbor.net  Fri Feb 24 19:45:59 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 25 Feb 2012 01:45:59 +0000
Subject: do not filter your customers
In-Reply-To: <m2aa47ohys.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <m2aa47ohys.wl%randy@psg.com>
Message-ID: <BFE89AB0-8C64-4324-A58A-DC319FB287B0@arbor.net>


On Feb 25, 2012, at 7:49 AM, Randy Bush wrote:

> i would love to see progress on the route leak problem.  i do not confuddle it with security.

Availability is a key aspect of security - the most important one, in many cases/contexts.  The availability of the control plane itself (i.e., being stable/resilient enough to continue doing its job even under various forms of duress) as well as the availability of the information about paths it propagates in order to allow the routing of transit traffic both fall squarely within the rubric of security, IMHO.

The disruption of transit traffic routing often caused by route leaks, as in this particular case, has a negative impact of the overall availability of affected networks/endpoints/applications/services/data.  However, route leaks are only one potential cause of such hits to availability - and while there are several BCPs which can and should be adopted in order to protect against control-plane disruption, they in many cases honored more in the breach than in the observance due to complexity, opex (as is the case with many - some would say most - security-related BCPs), and so forth.

The single best thing which could be done to improve the stability/resiliency of the control-plane on IP networks in general would be to change the nature of the control-plane (not just BGP, but the IGPs, as well) from in-band to out-of-band, IMHO.  I know this will probably never happen, but wanted to be sure that the point was made in relation to this specific topic for the sake of completeness, if nothing else.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From morrowc.lists at gmail.com  Fri Feb 24 19:59:18 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 20:59:18 -0500
Subject: do not filter your customers
In-Reply-To: <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
Message-ID: <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>

On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young at jsyoung.net> wrote:
> 1. ?Make your customers register routes, then filter them.
> ? ? (may be time for big providers to put routing tools into
> ? ? open source for the good of the community - make it
> ? ? less hard?)

not a big provider, but ras at e-gerbil did release irr-tools no?

> 2. ?Implement the "1-hop" hack to protect your BGP peering.
>
> 98% of problem solved on the Internet today
>

which problem? GTSH only protects your actual bgp session, not the
content of the session(s) or the content across the larger network.

> 3. ?Implement a "# of routes-type" filter to make your peers
> ? ? (and transit customers) phone you if they really do want
> ? ? to add 500,000 routes to your session ( or the wrong set
> ? ? of YouTube routes...).

max-prefix already exists... sometimes it works, sometimes it's a
burden. It doesnt' tell you anything about the content of the session
though (the YT routes example doesn't actually work that way)

> 99.9% of problem solved.

? not sure about that number

> 4. ?Implement BGP-Sec
>
> 99.91% of "this" problem solved.
>
> Because #1 is 'just too hard' and because #4 is just too sexy
> as an academic pursuit we all suffer the consequences. ?It's

there are folks working on the #4 problem, not academics even. It's
not been particularly sexy though :(

> a shame that tier one peering agreements didn't evolve with
> a 'filter your customers' clause (aka do the right thing) as well
> as a 'like for like' (similar investments) clause in them.

I'm missing something here... it's not clear to me that 'tier1'
providers matter a whole lot in the discussion. Many of them have
spoken up saying: "Figuring out the downstream matrix in order to put
a prefix-list on my SFP peer is not trivial, and probably not workable
on gear today." (shane I think has even said this here...)

> I'm not downplaying the BGP-SEC work, I think it's valid and
> may one day save us from some smart bunny who wants to
> make a name for himself by bringing the Internet to a halt. ?I
> don't believe that's what we're battling here. ?We're battling the
> operational cost of doing the right thing with the toolset we have

right, so today you have to do a lot of math/work to figure out if
your customer's prefixes are hers, and if they should be permitted
into your RIB. Tomorrow you COULD get a better end result with less
work and more assurance given a populated resource certification
system.

Extending some into the land of BGPSEC you COULD also know that the
route you hear originated from the correct ASN and later you'd be able
to tell that path the route travel was the same as the ASPATH in the
route...

-chris


From cjp at 0x1.net  Fri Feb 24 20:08:27 2012
From: cjp at 0x1.net (Christopher J. Pilkington)
Date: Fri, 24 Feb 2012 21:08:27 -0500
Subject: HP A6600 experiences
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644B9A53@EALPO1.ukbroadband.com>
References: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
 <D181DDABABE57E4DB72FEE00331478644B9A53@EALPO1.ukbroadband.com>
Message-ID: <7042837978518625470@unknownmsgid>

On Feb 24, 2012, at 17:43, Leigh Porter <leigh.porter at ukbroadband.com> wrote:

> I thought the A6604 was EOL?
>
> http://h17007.www1.hp.com/docs/products/eos/Select_HP_A6600_Routers_and_Modules_ES_Announcement.pdf

Yes, and the recommended replacement is... the A6604. (Read whole EOL
announcement.)

>

-cjp


From rdobbins at arbor.net  Fri Feb 24 20:12:46 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 25 Feb 2012 02:12:46 +0000
Subject: do not filter your customers
In-Reply-To: <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
Message-ID: <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>


On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:

> max-prefix already exists... sometimes it works, sometimes it's a burden.

Some sort of throttle - i.e., allow only X number of routing updates within Y number of [seconds?  milliseconds? BGP packets?] would be more useful, IMHO.  If the configured rate is exceeded, maintain the session but stop accepting further updates until either manually reset or the rate of updates falls back within acceptable parameters.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From nanog at studio442.com.au  Fri Feb 24 20:23:19 2012
From: nanog at studio442.com.au (Julien Goodwin)
Date: Sat, 25 Feb 2012 13:23:19 +1100
Subject: do not filter your customers
In-Reply-To: <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
Message-ID: <4F484617.3090804@studio442.com.au>

On 25/02/12 13:12, Dobbins, Roland wrote:
> 
> On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
> 
>> max-prefix already exists... sometimes it works, sometimes it's a burden.
> 
> Some sort of throttle - i.e., allow only X number of routing updates within Y number of [seconds?  milliseconds? BGP packets?] would be more useful, IMHO.  If the configured rate is exceeded, maintain the session but stop accepting further updates until either manually reset or the rate of updates falls back within acceptable parameters.


JunOS does have "out-delay", but that's not quite a solution although it
does help stem some prefix flapping issues.


From morrowc.lists at gmail.com  Fri Feb 24 20:39:37 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Fri, 24 Feb 2012 21:39:37 -0500
Subject: do not filter your customers
In-Reply-To: <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
Message-ID: <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>

On Fri, Feb 24, 2012 at 9:12 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
> On Feb 25, 2012, at 8:59 AM, Christopher Morrow wrote:
>
>> max-prefix already exists... sometimes it works, sometimes it's a burden.
>
> Some sort of throttle - i.e., allow only X number of routing updates within Y number of [seconds? ?milliseconds? BGP packets?] would be more useful, IMHO. ?If the configured rate is exceeded, maintain the session but stop accepting further updates until either manually reset or the rate of updates falls back within acceptable parameters.

it seems to me that most of the options discussed for this are .. bad,
in one dimension or another :(

typical max-prefix today will dump a session, if you exceed the number
of prefixes on the session... good? maybe? bad? maybe? did the peer
fire up a full table to you? or did you just not pay attention to the
log messages saying: "Hey, joe's going to need an update shortly..."

X prefixes/packets in Y seconds/milliseconds doesn't keep the peer
from blowing up your RIB, it does slow down convergence :(

If you have 200 peers on an edge device, dropping the whole device's
routing capabilities because of one AS7007/AS1221/AS9121 .. isn't cool
to your network nor the other customers on that device :( max-prefix
as it exists today at least caps the damage at one customer.

The knobs available are sort of harsh all the way around though today :(

-chris


From rdobbins at arbor.net  Fri Feb 24 21:52:56 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 25 Feb 2012 03:52:56 +0000
Subject: do not filter your customers
In-Reply-To: <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>	<0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>	<9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
Message-ID: <4FF16005-0D5E-4E4A-A492-8C8AECCE52B4@arbor.net>


On Feb 25, 2012, at 9:39 AM, Christopher Morrow wrote:

> it seems to me that most of the options discussed for this are .. bad, in one dimension or another :(

Concur.

> X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from blowing up your RIB,

How so?  If the configured parameters are exceeded, stop accepting/inserting updates until this is no longer the case.  Exceptions would be made for peering session establishment, it would take effect after that.

> it does slow down convergence :(

Yes, but is this always necessarily a Bad Thing?  For example, this particular circumstance (and many like it, c.f. AS7007 incident, et. al.)  it could be argued that in this particular case, [incorrect?  undesirable?  premature? pessimal?] convergence led to a poor result, could it not?

> If you have 200 peers on an edge device, dropping the whole device's routing capabilities because of one AS7007/AS1221/AS9121 .. isn't cool
> to your network nor the other customers on that device :(

Apologies for being unclear; I wasn't suggesting dropping or removing anything, but rather refusing to further accept/insert updates from a given peer until the update rate from said peer slowed to within configured parameters.

> max-prefix as it exists today at least caps the damage at one customer.

But it doesn't, really, does it?  The effects cascade in an anisotropic manner throughout a potentially large transit cone.

> The knobs available are sort of harsh all the way around though today :(

Concur again, sigh.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From young at jsyoung.net  Fri Feb 24 21:53:21 2012
From: young at jsyoung.net (Jeff Young)
Date: Sat, 25 Feb 2012 14:53:21 +1100
Subject: do not filter your customers
In-Reply-To: <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
Message-ID: <95C55BC0-C3FF-44AE-A3E2-0611E191E107@jsyoung.net>


On 25/02/2012, at 12:59 PM, Christopher Morrow wrote:

> On Fri, Feb 24, 2012 at 8:24 PM, Jeffrey S. Young <young at jsyoung.net> wrote:
>> 1.  Make your customers register routes, then filter them.
>>     (may be time for big providers to put routing tools into
>>     open source for the good of the community - make it
>>     less hard?)
> 
> not a big provider, but ras at e-gerbil did release irr-tools no?

And other providers out there have extensive tool sets from which
we could all benefit.  I'll let them chime in if they choose.

> 
>> 2.  Implement the "1-hop" hack to protect your BGP peering.
>> 
>> 98% of problem solved on the Internet today
>> 
> 
> which problem? GTSH only protects your actual bgp session, not the
> content of the session(s) or the content across the larger network.
> 

The security problem, but it was a hedge on my part.

>> 3.  Implement a "# of routes-type" filter to make your peers
>>     (and transit customers) phone you if they really do want
>>     to add 500,000 routes to your session ( or the wrong set
>>     of YouTube routes...).
> 
> max-prefix already exists... sometimes it works, sometimes it's a
> burden. It doesnt' tell you anything about the content of the session
> though (the YT routes example doesn't actually work that way)

Depends on how many /24's the Pakistan(?) Telecom guy let into the 
network to block the YT content...  but you're right, the example would 
have been better in support of #1.  
(had PT been forced to register routes before sending them and his 
upstream been filtering based on those routes we'd have never heard 
about it.)

> 
>> 99.9% of problem solved.
> 
> ? not sure about that number
> 

>> 4.  Implement BGP-Sec
>> 
>> 99.91% of "this" problem solved.
>> 
>> Because #1 is 'just too hard' and because #4 is just too sexy
>> as an academic pursuit we all suffer the consequences.  It's
> 
> there are folks working on the #4 problem, not academics even. It's
> not been particularly sexy though :(
> 

Point was that the problem is mostly operational.  We have tools
to deal with the problem but the operational costs are high.  For 
fifteen (below) years we've treated this (route leak) as "not my problem"
because it's too costly.   Every 6-12 months it comes back to bite
us.  If the cost of an outage every 6 months+ is low compared to
solving the problem, the community will endure the outage. If we 
want it to stop today we can make it stop but stopping it has a cost.

?...a glitch at a small ISP... triggered a major outage in Internet access 
across the country. The problem started when MAI Network Services
...passed bad router information from one of its customers onto Sprint.?
-- news.com, April 25, 1997

jy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 235 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120225/cc480566/attachment.bin>

From shane at castlepoint.net  Sat Feb 25 00:07:04 2012
From: shane at castlepoint.net (Shane Amante)
Date: Fri, 24 Feb 2012 23:07:04 -0700
Subject: do not filter your customers
In-Reply-To: <4F481A36.8090701@foobar.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <4F481A36.8090701@foobar.org>
Message-ID: <714598E8-DB44-48FB-A706-08BF46E3B37A@castlepoint.net>

Nick,

On Feb 24, 2012, at 4:16 PM, Nick Hilliard wrote:
> On 24/02/2012 20:04, Shane Amante wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC.  I can't
>> understand why people keep ignoring this.
> 
> I'd be interested to hear your opinions on exactly how rpki in its current
> implementation would have prevented the optus/telstra problem.  Could you
> elaborate?

I apologize if I mislead you, but I did not claim that the RPKI, in its current ROA implementation, *would* have prevented this specific route leak related to Optus/Telstra.  OTOH, I would completely agree with Geoff's comment that the policy language of RPSL has the ability to express routing _policy_, a.k.a. "intent", recursively across multiple ASN's ... (please note that I'm specifically talking about the technical capability of the policy language of RPSL, not the actual _data_ contained in the IRR).

Or, to put it a different way, the reachability information carried in BGP is the end-result/output of policy.  One needs to understand the *input*, a.k.a.: the policy/intent, if they are to validate the output, namely the reachability information carried in BGP.  Unfortunately, denying this reality is not going to make it "go away".


> Here's a quote from draft-ietf-sidr-origin-ops:
> 
>>   As the BGP origin AS of an update is not signed, origin validation is
>>   open to malicious spoofing.  Therefore, RPKI-based origin validation
>>   is designed to deal only with inadvertent mis-advertisement.
>> 
>>   Origin validation does not address the problem of AS-Path validation.
>>   Therefore paths are open to manipulation, either malicious or
>>   accidental.
> 
> An optus/telstra style problem might have been mitigated by an rpki based
> full path validation mechanism, but we don't have path validation.  Right
> now, we only have a draft of a list of must-have features -
> draft-ietf-sidr-bgpsec-reqs.  This is only the first step towards designing
> a functional protocol, not to mind having running code.

As one example, those "must-have features" have not, yet[1], accounted for the various "kinky" things we all do to manipulate the AS_PATH in the wild, for lots of very important business reasons, namely: ASN consolidation through knobs like "local-as alias" in JUNOS-land and "local-as no-prepend replace-as" in IOS-land, which have existed in shipping code for several years and are in active, widespread use and will continue to remain so[2].  Furthermore, given the current design proposal on the table of a BGPSEC transmitter forward-signing the "Target AS", as learned from a receiver in the BGP OPEN message, this could make it impossible to do ASN consolidation in the future, (unless I'm misunderstanding something).

-shane

[1] I have asked at the the last SIDR WG meeting in Taipei specifically for this to be accounted for, but I don't see this in the current rev of the draft you cite. Perhaps others should chime in on the SIDR WG mailing list if they are aware of the use of ASN-consolidation knobs and consider them a critical factor to consider during the design process, particularly so they are looked at during the earliest stages of the design.
[2] I haven't heard of any vendors stating that they are intending to EOL or not support those features any more, but it would be amusing to see the reaction they would get if they tried.  :-)

From brent at brentrjones.com  Sat Feb 25 00:15:54 2012
From: brent at brentrjones.com (Brent Jones)
Date: Fri, 24 Feb 2012 22:15:54 -0800
Subject: HP A6600 experiences
In-Reply-To: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
References: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
Message-ID: <CAOC=LuUWnVDqxAXKinTSBq3qwsyOsXmvXueWhR=g4ucuTX2bOA@mail.gmail.com>

On Fri, Feb 24, 2012 at 11:01 AM, Christopher Pilkington <cjp at 0x1.net>wrote:

> If anyone has any experiences they'd be willing to share, or even lab
> reports, on HP A6600, it would be helpful.  I believe this is the same
> product as H3C SR6600.
>
> We're being asked to "look at" A6604 facing our IPv4/IPv6 transit.  I'd
> like to get some opinions before I go through effort of getting one in the
> lab.
>
> -cjp
>

If HP's modular chassis are anything like their fixed configuration, I
would stay away from them.
We abandoned all HP networking equipment due to gross bugs and firmware
incompatibility.
We tried to deploy 10Gb with HP, but they had shipping hardware, with no
firmware to support the modules. Now they recommend us switching all our
Procurve line with H3C.

Needless to say, we will not buy HP/H3C equipment ever again, lesson
learned.

Juniper, Force10, Arista, and Cisco (surprisingly) make much better gear
these days at much more competitive pricing.

-- 
Brent Jones
brent at brentrjones.com

From shane at castlepoint.net  Sat Feb 25 00:28:15 2012
From: shane at castlepoint.net (Shane Amante)
Date: Fri, 24 Feb 2012 23:28:15 -0700
Subject: do not filter your customers
In-Reply-To: <m2aa47ohys.wl%randy@psg.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <m2aa47ohys.wl%randy@psg.com>
Message-ID: <6424C3E0-E806-4789-A2A8-85CE4EAB2A0E@castlepoint.net>


On Feb 24, 2012, at 5:49 PM, Randy Bush wrote:
>> Solving for route leaks is /the/ "killer app" for BGPSEC.
> 
> as would be solving world hunger, war, bad cooking, especially bad
> cooking.
> 
> route leaks, as much as i understand them
>  o are indeed bad ops issues
>  o are not security per se
>  o are a violation of business relationshiops
>  o and 20 years of fighting them have not given us any significant
>    increase in understanding, formal definition, or prevention.
> 
> i would love to see progress on the route leak problem.  i do not
> confuddle it with security.


So, it is not OK for traffic to be /intentionally/ diverted through a malevolent AS, but it is OK for traffic to be /unintentionally/ diverted through a (possibly) malevolent AS?  Who's to judge the security exposure[1] of the latter is not identical (or, worse) than the former?

-shane

[1] dropped traffic, traffic analysis, etc. 

From morrowc.lists at gmail.com  Sat Feb 25 01:15:20 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 25 Feb 2012 02:15:20 -0500
Subject: do not filter your customers
In-Reply-To: <4FF16005-0D5E-4E4A-A492-8C8AECCE52B4@arbor.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <4FF16005-0D5E-4E4A-A492-8C8AECCE52B4@arbor.net>
Message-ID: <CAL9jLaab2EqWcPupzRaH_Duuf3Tki6UMHbDupJzpoyiz9TipmA@mail.gmail.com>

On Fri, Feb 24, 2012 at 10:52 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:
>
>> X prefixes/packets in Y seconds/milliseconds doesn't keep the peer from blowing up your RIB,
>
> How so? ?If the configured parameters are exceeded, stop accepting/inserting updates until this is no longer the case. ?Exceptions would be made for peering session establishment, it would take effect after that.
>

if the rate is 1/ms ... I can fill the rib in 2million ms ... ~30mins?
Rate alone isn't the problem :( size matters.

>> it does slow down convergence :(
>
> Yes, but is this always necessarily a Bad Thing? ?For example, this particular circumstance (and many like it, c.f. AS7007 incident, et. al.) ?it could be argued that in this particular case, [incorrect? ?undesirable? ?premature? pessimal?] convergence led to a poor result, could it not?
>

it's not clear, to me at least, that slowing convergence is good. it
seems to me that folk do all manner of 'interesting' things in order
to limit convergence time. People aren't trying to actively make
convergence take longer, that I've seen at least.

>> If you have 200 peers on an edge device, dropping the whole device's routing capabilities because of one AS7007/AS1221/AS9121 .. isn't cool
>> to your network nor the other customers on that device :(
>
> Apologies for being unclear; I wasn't suggesting dropping or removing anything, but rather refusing to further accept/insert updates from a given peer until the update rate from said peer slowed to within configured parameters.
>

yup, I think I jumped a bit around, my penalizing every other customer
was a reference to not having any limiting system in place.

>> max-prefix as it exists today at least caps the damage at one customer.
>
> But it doesn't, really, does it? ?The effects cascade in an anisotropic manner throughout a potentially large transit cone.
>

dropping a single customer sucks, dropping an entire edge device is
far far worse.

>> The knobs available are sort of harsh all the way around though today :(
>
> Concur again, sigh.

hurray! sort of.

thanks!
-chris


From rdobbins at arbor.net  Sat Feb 25 01:26:58 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sat, 25 Feb 2012 07:26:58 +0000
Subject: do not filter your customers
In-Reply-To: <CAL9jLaab2EqWcPupzRaH_Duuf3Tki6UMHbDupJzpoyiz9TipmA@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>	<0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>	<9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <4FF16005-0D5E-4E4A-A492-8C8AECCE52B4@arbor.net>
 <CAL9jLaab2EqWcPupzRaH_Duuf3Tki6UMHbDupJzpoyiz9TipmA@mail.gmail.com>
Message-ID: <51CB099D-2922-42A2-BAEE-0D0A1DB7B348@arbor.net>


On Feb 25, 2012, at 2:15 PM, Christopher Morrow wrote:

> if the rate is 1/ms ... I can fill the rib in 2million ms ... ~30mins?  Rate alone isn't the problem :( size matters.

Sure; the idea is that some sort of throttling, coupled with overall size limitations, might be useful.

> People aren't trying to actively make convergence take longer, that I've seen at least.

Yes, and in most cases, the goal is to speed up convergence.  I'm positing that in these particular circumstances, fast convergence is not necessarily desirable, and that 'these particular circumstances' generally involve large numbers of updates which are not associated with turning up a new peering session being received over a short period of time.

What about routing update transmission throttling, instead?  Does that make any more sense, in terms of being liberal with what we accept and conservative in what (or how much, how quickly) we send?

> dropping a single customer sucks, dropping an entire edge device is far far worse.

I agree; I don't mean to imply that anything should be dropped.  Again, apologies for being unclear.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From mukom.tamon at gmail.com  Sat Feb 25 01:27:13 2012
From: mukom.tamon at gmail.com (Mukom Akong T.)
Date: Sat, 25 Feb 2012 11:27:13 +0400
Subject: Network Traffic Collection
In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C710B04C6D@LMC-MAIL2.exempla.org>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C710B04C6D@LMC-MAIL2.exempla.org>
Message-ID: <CAHDzDLD-6c2AHd7VwATULcxGpWNPqAMYhm7jpyurDdNETyeOww@mail.gmail.com>

On Fri, Feb 24, 2012 at 12:20 AM, Matlock, Kenneth L
<MatlockK at exempla.org> wrote:
> Netflow + netflow collector.

+1 This guide should give you a good start.

http://techowto.files.wordpress.com/2008/09/ntop-guide.pdf

Regards

-- 
Mukom Akong Tamon
______________

"If we can't BREATH, we'll die. Yet, we don't LIVE in order to breath.
Ditto we SHOULDN'T WORK just to MAKE MONEY. Doing so puts us on a one
way street to IRRELEVANCE."


[In Search of Excellence & Perfection] - http://perfexcellence.org
[Moments of TechXcellence] - http://techexcellence.net
[ICT Business Integration] -?http://ibiztech.wordpress.com
[About Me] - http://about.me/perfexcellence


From randy at psg.com  Sat Feb 25 03:05:44 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 25 Feb 2012 14:35:44 +0530
Subject: do not filter your customers
In-Reply-To: <6424C3E0-E806-4789-A2A8-85CE4EAB2A0E@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <m2aa47ohys.wl%randy@psg.com>
 <6424C3E0-E806-4789-A2A8-85CE4EAB2A0E@castlepoint.net>
Message-ID: <m2mx87mgev.wl%randy@psg.com>

> So, it is not OK for traffic to be /intentionally/ diverted through a
> malevolent AS

traffic?  i do not hold the fantasy that traffic is highly correlated to
the control plane.  see http://archive.psg.com/optometry.pdf if you need
a disproof of the fantasy.

> but it is OK for traffic to be /unintentionally/ diverted through a
> (possibly) malevolent AS?

intent?  how the hell do i know intent?  i can barely read my own mind
let alone telstra's.

and i very much doubt telstra thought they were _attacking_ optus.

randy


From randy at psg.com  Sat Feb 25 03:52:35 2012
From: randy at psg.com (Randy Bush)
Date: Sat, 25 Feb 2012 15:22:35 +0530
Subject: do not filter your customers
In-Reply-To: <6424C3E0-E806-4789-A2A8-85CE4EAB2A0E@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <m2aa47ohys.wl%randy@psg.com>
 <6424C3E0-E806-4789-A2A8-85CE4EAB2A0E@castlepoint.net>
Message-ID: <m2k43bme8s.wl%randy@psg.com>

> as would be solving world hunger, war, bad cooking, especially bad
> cooking.
> 
> route leaks, as much as i understand them
>  o are indeed bad ops issues
>  o are not security per se
>  o are a violation of business relationshiops
>  o and 20 years of fighting them have not given us any significant
>    increase in understanding, formal definition, or prevention.

let me try to express how i see the problem.  to do this rigorously, i
would need to form the transitive closure of the business policies of
every inter-provider link on the internet.

why i say it is per-link and not just inter-as (which would be hard
enough) is that i know a *lot* of examples where two ass have different
business policies on different links.  [ i'll exchange se asian routes
with you in hong kong, but only sell you transit in tokyo.  we have two
links in frankfurt, one local peering and one international transit. ]

it is not just one-hop because telstra was 'supposed to' pass some
customers' customers' routes to optus.

i find this daunting.  but i would *really* like to be able to
rigorously solve it.  please please please explain to me how it is
simpler than this.

randy


From myeaddress at gmail.com  Sat Feb 25 08:14:13 2012
From: myeaddress at gmail.com (Maverick)
Date: Sat, 25 Feb 2012 09:14:13 -0500
Subject: Network Traffic Collection
In-Reply-To: <CAHDzDLD-6c2AHd7VwATULcxGpWNPqAMYhm7jpyurDdNETyeOww@mail.gmail.com>
References: <CA+vWMo6JBwnS+u5wjw4e5XM5mJO6Sut6o8HYsbtabAq8wbLdtg@mail.gmail.com>
 <4F469E1B.1040100@unfix.org>
 <CA+vWMo5DUC9+s_W2Z99tA=+7ROD2kDvNG-a2R0ZET_ZPX25+Zg@mail.gmail.com>
 <4288131ED5E3024C9CD4782CECCAD2C710B04C6D@LMC-MAIL2.exempla.org>
 <CAHDzDLD-6c2AHd7VwATULcxGpWNPqAMYhm7jpyurDdNETyeOww@mail.gmail.com>
Message-ID: <CA+vWMo5nVPY-DY9vC=oJbG1N6KukV-ZTKAm8TbrhH3dD4tHCsw@mail.gmail.com>

Thanks Mukom for the wonderful guide, this is really helpful. I have
few questions about ntop though.

How can I get access to the log files generated by ntop and do my own
parsing rather than looking for webbased results that are generated.
Are there any programs available that do parsing of ntops log files.
When I run ntop on pcap I don't get the throughput graphs as rrd
doesn't work on pcap is there any work around for that.

Thanks,
Ali

On Sat, Feb 25, 2012 at 2:27 AM, Mukom Akong T. <mukom.tamon at gmail.com> wrote:
> On Fri, Feb 24, 2012 at 12:20 AM, Matlock, Kenneth L
> <MatlockK at exempla.org> wrote:
>> Netflow + netflow collector.
>
> +1 This guide should give you a good start.
>
> http://techowto.files.wordpress.com/2008/09/ntop-guide.pdf
>
> Regards
>
> --
> Mukom Akong Tamon
> ______________
>
> "If we can't BREATH, we'll die. Yet, we don't LIVE in order to breath.
> Ditto we SHOULDN'T WORK just to MAKE MONEY. Doing so puts us on a one
> way street to IRRELEVANCE."
>
>
> [In Search of Excellence & Perfection] - http://perfexcellence.org
> [Moments of TechXcellence] - http://techexcellence.net
> [ICT Business Integration] -?http://ibiztech.wordpress.com
> [About Me] - http://about.me/perfexcellence


From Valdis.Kletnieks at vt.edu  Sat Feb 25 11:20:10 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 25 Feb 2012 12:20:10 -0500
Subject: do not filter your customers
In-Reply-To: Your message of "Fri, 24 Feb 2012 21:39:37 EST."
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
Message-ID: <33004.1330190410@turing-police.cc.vt.edu>

On Fri, 24 Feb 2012 21:39:37 EST, Christopher Morrow said:

> The knobs available are sort of harsh all the way around though today :(

So what would be a good knob if it was available?  I've seen about forty-leven
people say the current knobs suck, but no real proposals of "what would really
rock is if we could...."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120225/2f43c2db/attachment.bin>

From tom at ninjabadger.net  Sat Feb 25 12:04:20 2012
From: tom at ninjabadger.net (Tom Hill)
Date: Sat, 25 Feb 2012 18:04:20 +0000
Subject: do not filter your customers
In-Reply-To: <33004.1330190410@turing-police.cc.vt.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <33004.1330190410@turing-police.cc.vt.edu>
Message-ID: <4F4922A4.2030507@ninjabadger.net>

On 25/02/12 17:20, Valdis.Kletnieks at vt.edu wrote:
> On Fri, 24 Feb 2012 21:39:37 EST, Christopher Morrow said:
>
>> The knobs available are sort of harsh all the way around though today :(
>
> So what would be a good knob if it was available?  I've seen about forty-leven
> people say the current knobs suck, but no real proposals of "what would really
> rock is if we could...."

I've suggested before that a configured increase limit, in percentage 
might be *slightly* more intelligent than the current hard limit 
settings (i.e. max-prefixes).

Typically you're going to get, what, 100 routes? Maybe less, maybe more. 
If that rises by 100%, drop the session. Weird customer? 200%.

Tom


From faisal at snappydsl.net  Sat Feb 25 14:02:41 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Sat, 25 Feb 2012 15:02:41 -0500
Subject: Looking For Tinet NOC Contact
In-Reply-To: <4F4922A4.2030507@ninjabadger.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <33004.1330190410@turing-police.cc.vt.edu> <4F4922A4.2030507@ninjabadger.net>
Message-ID: <4F493E61.2010309@snappydsl.net>

Hello,

If anyone from TINET (AS 3257) is on this list, can you please contact us ?
We have one of their customers announcing one of our blocks and I need 
to get them to stop doing that.:)

Thanks you in advance.

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: Support at Snappydsl.net





From nick at foobar.org  Sat Feb 25 16:15:48 2012
From: nick at foobar.org (Nick Hilliard)
Date: Sat, 25 Feb 2012 22:15:48 +0000
Subject: do not filter your customers
In-Reply-To: <714598E8-DB44-48FB-A706-08BF46E3B37A@castlepoint.net>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <4F481A36.8090701@foobar.org>
 <714598E8-DB44-48FB-A706-08BF46E3B37A@castlepoint.net>
Message-ID: <4F495D94.8010703@foobar.org>

On 25/02/2012 06:07, Shane Amante wrote:
>  OTOH, I would completely agree with
> Geoff's comment that the policy language of RPSL has the ability to
> express routing _policy_, a.k.a. "intent", recursively across multiple
> ASN's ... (please note that I'm specifically talking about the technical
> capability of the policy language of RPSL, not the actual _data_
> contained in the IRR).

routing policy concerns the interaction of two classes of object (prefixes
and asns) as handled between asns.  Problem is, while you can describe AS
interaction between ASNs and some prefix stuff between ASNs, rpsl doesn't
really have proper support to link the two - i.e. tying prefixes to
specific paths and all that jazz.  Then again, neither do most routers.  It
hardly matters - without a secure means of path validation, the path is
purely advisory and you can only barely trust the peer asn in the path.

So RPSL isn't really a solution for describing how prefixes ought to be
handled to inter-asn connectivity, and even if it were and routers could
handle as->prefix mapping properly, our routers couldn't handle it for
large-scale interconnection links due to configuration management
limitations.  Put simply, managing enormous lists of prefixes and piles of
ASN paths (in regex form) causes router RPs to asplode.   So from the point
of view of prefix distribution control, some sort of live query system is
required.

To this end, rpki with as path validation (if we actually had an
implementation which checked all the boxes in the draft list of
requirements) might work.  My point was that at the moment, it's vapour and
it's not clear at this point that it will ever change into something more
solid, particularly given the challenging feature list that we want it to
cope with, and given the constraints of what people already do with their
policy routing.

And even if it does ever work, it immediately opens up an exquisitely ugly
can of worms at layers 9 and above.  Call me conservative, but I have not
been convinced that RPKI solves more problems than it creates.

Your other concerns about as path validation implementation are indeed
difficult to address.

Nick


From grupo.ipv6 at gmail.com  Sat Feb 25 16:36:44 2012
From: grupo.ipv6 at gmail.com (Grupo IPv6)
Date: Sat, 25 Feb 2012 20:36:44 -0200
Subject: IPv6 net tools
Message-ID: <CANuE+sBOc18DpNPofYa8cUH7j_Xg-LfXpntfDe9u5UitY+jp8A@mail.gmail.com>

We are a group of students in telecommunications engineering from Uruguay.
We are studying some network tools for our final project and we would like
to know if someone could tell us which of this tools have IPv6 support:

?         Bprobe

?         Cprobe

?         Pathload

?         Pathrate

?         Pathchar

?         Clink

?         Nettimer

?         Spruce

      Thanks for your help!!


Gianina

From dongting.yu at cl.cam.ac.uk  Sat Feb 25 16:39:15 2012
From: dongting.yu at cl.cam.ac.uk (Dongting Yu)
Date: Sat, 25 Feb 2012 22:39:15 +0000
Subject: do not filter your customers
In-Reply-To: <4F495D94.8010703@foobar.org>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <4F481A36.8090701@foobar.org>
 <714598E8-DB44-48FB-A706-08BF46E3B37A@castlepoint.net>
 <4F495D94.8010703@foobar.org>
Message-ID: <CAHUKT2BMAU48MOpp9b71JeSN0How4+7wmEHYFFdxbeDEQWc07A@mail.gmail.com>

Let me chime in and attempt to explain why a couple of solutions I've
seen so far in this thread won't work:

- rate-limiting/throttling updates: BGP by protocol does not repeat
updates; if an update is sent then the sender assumes that the
receiver has received it and will remember it until a change or a
withdrawal. If you rate limit announcements, either you hold things
off in a buffer, which would need a very large buffer, or you drop
updates, which would lead to inconsistent views on the two sides of
the session. What if a legitimate update was among the large burst?

- max-prefix: it is currently used to prevent large bursts of updates
but it won't stop Youtube incident, which was more targeted. Perhaps
the YT incident falls into a different category from 'route leaks' but
without a clear definition of the latter we simply cannot say. Also,
max-prefix causes problems in slowly-increasing peers or peers with
new large customers and people not bothered to adjust the max-prefix
value accordingly.

- max-prefix in the form of a percentage: some peers actually are very
stable in the number of prefixes they announce, and some are not. Both
are probably valid depending on your business model/requirements. A x%
may be too lax for one company but too little for another. Figuring
the right number (or even a ballpark) is probably a lot harder than a
simple max-prefix value. I have seen ASes that announce hundreds to
tens of thousands of prefixes on a periodic basis. Percentages also
don't work so well for ASes with single-digit or low-double-digit
number of of prefixes.


Dongting


From bonomi at mail.r-bonomi.com  Sat Feb 25 17:26:23 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sat, 25 Feb 2012 17:26:23 -0600 (CST)
Subject: IPv6 net tools
In-Reply-To: <CANuE+sBOc18DpNPofYa8cUH7j_Xg-LfXpntfDe9u5UitY+jp8A@mail.gmail.com>
Message-ID: <201202252326.q1PNQNEK066203@mail.r-bonomi.com>

> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org  Sat Feb 25 16:37:44 2012
> Date: Sat, 25 Feb 2012 20:36:44 -0200
> Subject: IPv6 net tools
> From: Grupo IPv6 <grupo.ipv6 at gmail.com>
> To: nanog at nanog.org
>
> We are a group of students in telecommunications engineering from Uruguay.
> We are studying some network tools for our final project and we would like
> to know if someone could tell us which of this tools have IPv6 support:
>

The going rate for consulting services, by subscribers of this mailing-list,
is probably well over US$100/hr, with a multi-day minimum.

Rates for "do my homework form me" tasks tend to be *significantly* higher.

Using such obscure and little-known tools like 'google', or 'bing', it 
should be no challenge to find the publishers of the various software you
ask about, -and- the 'specifications' thereof.  If not stated in the afore-
said specifications, _directly_ asking the people who made the software, will
get you an 'authoritative' answer.




From morrowc.lists at gmail.com  Sat Feb 25 18:55:16 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Sat, 25 Feb 2012 19:55:16 -0500
Subject: do not filter your customers
In-Reply-To: <33004.1330190410@turing-police.cc.vt.edu>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>
 <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>
 <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <33004.1330190410@turing-police.cc.vt.edu>
Message-ID: <CAL9jLaa=g6X_1RqEH_NyixbSx-iopEk1gyUeFd1OeNMz0nv2ww@mail.gmail.com>

On Sat, Feb 25, 2012 at 12:20 PM,  <Valdis.Kletnieks at vt.edu> wrote:
> On Fri, 24 Feb 2012 21:39:37 EST, Christopher Morrow said:
>
>> The knobs available are sort of harsh all the way around though today :(
>
> So what would be a good knob if it was available? ?I've seen about forty-leven
> people say the current knobs suck, but no real proposals of "what would really
> rock is if we could...."

I'm not sure... here's a few ideas though to toss on the fire of thought:

1) break the process up inside the router, provide another set of
places to blcok and tackle the problem.

2) better metric the problem for operations staff

3) automate the problem 'better' (inside a set of sane boundaries)

I think in 1 I want to be able to be assured that inbound data to a
bgp peer will not cause problems for all other peers on the same
device. Keep the parsing, memory and cpu management separate from the
main routing management inside the router, provide controls on these
points configurable at a per-peer level.

That way you could limit things like:
  - each peer able to take a maximum amount of RAM, start discarding
routes over that limit, alarm at a configurable percentage of the
limit.
  - each peer could consume only a set percentage of CPU resources,
better would be the ability to pin bgp peer usage to a particular CPU
(or set of CPUs) and other route processing on another
CPU/set-of-CPUs.
  - interfaces between the bgp speaker, receiver, ingest and databases
could all be standardized, simple and auditable as well. If the peer
sent a malformed update only that peering session would die, if the
parsing of the update caused a meltdown again only the single peer
would be affected. The interface between the code speaking to the peer
and the RIB could be more robust and more resilient to errors.

for 2, I think having more data available about avg rate of increase,
max rate of increase, average burst size and predicted time to overrun
would be helpful. Most of this one could gather with some smart SNMP
tricks I suspect... on the other hand, just reacting to the syslog
messages in a timely fashion works :)

for 3, automate the reaction to syslog/snmp messages, increasing the
thresholds if there hasn't been an increase in the last X hours and
the limit is not above Y percent of a full table already. (and send a
note to the NOC ticket system for historical preservation).

These too have flaws... I'm not sure there's a good answer to this though :(

-chris


From notcommonmistakes at gmail.com  Sat Feb 25 19:02:31 2012
From: notcommonmistakes at gmail.com (not common)
Date: Sat, 25 Feb 2012 20:02:31 -0500
Subject: Small ISP Need to Know
Message-ID: <CAKF9zbAU+cf-Z_OzdRfiru9RRAnQPy0k4fuiJFHrxxitdD30Hw@mail.gmail.com>

Hello,

I work for an ISP (35K customers) and do System Admin work for operations
and development (DNS, Radius and such).

I want learn more on our IP side (Routing, BGP, MPLS, Core Network).

I am trying to learn the Net Ops world piece by piece, and this is where I
ask:

Where is a good place (or places) to start learning ISP operations "Need To
Know"?

Thanks for your time

From streiner at cluebyfour.org  Sat Feb 25 19:15:11 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Sat, 25 Feb 2012 20:15:11 -0500 (EST)
Subject: Small ISP Need to Know
In-Reply-To: <CAKF9zbAU+cf-Z_OzdRfiru9RRAnQPy0k4fuiJFHrxxitdD30Hw@mail.gmail.com>
References: <CAKF9zbAU+cf-Z_OzdRfiru9RRAnQPy0k4fuiJFHrxxitdD30Hw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1202252009030.31859@whammy.cluebyfour.org>

On Sat, 25 Feb 2012, not common wrote:

> I want learn more on our IP side (Routing, BGP, MPLS, Core Network).
>
> I am trying to learn the Net Ops world piece by piece, and this is where I
> ask:
>
> Where is a good place (or places) to start learning ISP operations "Need To
> Know"?

This subject has been discussed here several times in the past few months. 
Check the archives of this list for references to lots of starting points.

One such thread may be found here:
http://mailman.nanog.org/pipermail/nanog/2011-November/042168.html

jms


From faisal at snappydsl.net  Sat Feb 25 19:48:07 2012
From: faisal at snappydsl.net (Faisal Imtiaz)
Date: Sat, 25 Feb 2012 20:48:07 -0500
Subject: Small ISP Need to Know
In-Reply-To: <CAKF9zbAU+cf-Z_OzdRfiru9RRAnQPy0k4fuiJFHrxxitdD30Hw@mail.gmail.com>
References: <CAKF9zbAU+cf-Z_OzdRfiru9RRAnQPy0k4fuiJFHrxxitdD30Hw@mail.gmail.com>
Message-ID: <82223340-D803-4410-95C4-69071CC16D30@snappydsl.net>

Do a google search for "cisco isp essentials"....

Some good starting point...

Sent from my iPhone

On Feb 25, 2012, at 8:02 PM, not common <notcommonmistakes at gmail.com> wrote:

> Hello,
> 
> I work for an ISP (35K customers) and do System Admin work for operations
> and development (DNS, Radius and such).
> 
> I want learn more on our IP side (Routing, BGP, MPLS, Core Network).
> 
> I am trying to learn the Net Ops world piece by piece, and this is where I
> ask:
> 
> Where is a good place (or places) to start learning ISP operations "Need To
> Know"?
> 
> Thanks for your time
> 


From rdobbins at arbor.net  Sat Feb 25 23:43:58 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 26 Feb 2012 05:43:58 +0000
Subject: do not filter your customers
In-Reply-To: <CAHUKT2BMAU48MOpp9b71JeSN0How4+7wmEHYFFdxbeDEQWc07A@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com> <0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com> <9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <38BE694A-53C0-4306-B129-5B3BF101291B@castlepoint.net>
 <4F481A36.8090701@foobar.org>
 <714598E8-DB44-48FB-A706-08BF46E3B37A@castlepoint.net>
 <4F495D94.8010703@foobar.org>
 <CAHUKT2BMAU48MOpp9b71JeSN0How4+7wmEHYFFdxbeDEQWc07A@mail.gmail.com>
Message-ID: <4FE812A3-EFD6-4C43-A762-2F9D17372FA7@arbor.net>


On Feb 26, 2012, at 5:39 AM, Dongting Yu wrote:

>  you drop updates, which would lead to inconsistent views on the two sides of the session.

Views are inconsistent by design - there is no state synchronization.  All a sender knows is that he sent the updates, not what (if anything) was done with them by the receiver.

> What if a legitimate update was among the large burst?

Presumably, soft-reset would be initiated after the throttling.

But per previous email, if any sort of throttling is to be done at all, it's probably best that it is done by the sender.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From rdobbins at arbor.net  Sat Feb 25 23:45:57 2012
From: rdobbins at arbor.net (Dobbins, Roland)
Date: Sun, 26 Feb 2012 05:45:57 +0000
Subject: do not filter your customers
In-Reply-To: <CAL9jLaa=g6X_1RqEH_NyixbSx-iopEk1gyUeFd1OeNMz0nv2ww@mail.gmail.com>
References: <m2hayi85t0.wl%randy@psg.com>
 <DAA24513C63D0448A9C49E2EADAC8EB78AEBBAFD@TK5EX14MBXC139.redmond.corp.microsoft.com>
 <m21upm82x1.wl%randy@psg.com>	<0BE25545-3192-464A-A5FE-612D7FBBEE79@tcb.net>
 <m262ew6go4.wl%randy@psg.com>	<9EC6688B-9D77-4512-8718-D872D0CEB0CB@tcb.net>
 <5B04B8F4-0F66-4EE2-BC3A-16B5583DE173@cs.columbia.edu>
 <1E4FA693-C09B-41F1-9A19-733853007327@tcb.net>
 <59D29BDB-5903-4C4B-ABA6-83A71FA97F51@jsyoung.net>
 <CAL9jLaYRj4M_v=4YRHCtanW+g7HECX2AkhARdtPJJ+FLdH5=-w@mail.gmail.com>
 <4800AAF1-743B-4B43-97CD-AD9B0017CBB5@arbor.net>
 <CAL9jLaZ45P-Cd0cFZAhufMEgAVa6XoQ3dUBOWk=-n3jTVBY1Rw@mail.gmail.com>
 <33004.1330190410@turing-police.cc.vt.edu>
 <CAL9jLaa=g6X_1RqEH_NyixbSx-iopEk1gyUeFd1OeNMz0nv2ww@mail.gmail.com>
Message-ID: <7A9AD093-1169-4B27-B707-961F4272AB0D@arbor.net>


On Feb 26, 2012, at 7:55 AM, Christopher Morrow wrote:

> I'm not sure... here's a few ideas though to toss on the fire of thought:

Concur with this general approach, which is a longer-term effort - but it would be nice if there was some discrete, limited-scope knob which could conceivably be added as a point-feature request, thereby having some chance of actually making it into shipping code at some point before the next millennium, and which won't cause more harm than good.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>

	  Luck is the residue of opportunity and design.

		       -- John Milton



From paulooi at takizo.com  Sun Feb 26 03:27:07 2012
From: paulooi at takizo.com (takizo)
Date: Sun, 26 Feb 2012 17:27:07 +0800
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <4F47F961.6050709@opus1.com>
References: <4F47F961.6050709@opus1.com>
Message-ID: <8E4E3C41-7769-43A4-A161-53A2F0088FA0@takizo.com>

That is awesome :) 1.234.x.x 


On Feb 25, 2012, at 4:56 AM, Joel M Snyder wrote:

> Normally I wouldn't say anything to anyone about anything so mundane as brute-force SSH attacks, but this one caught my eye just because of the IP address:
> 
> 	1.234.35.245
> 
> I wanna get a connection in Korea so I can have 1.234.56.78.
> 
> 
> jms
> 
> -- 
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One       Phone: +1 520 324 0494
> jms at Opus1.COM                http://www.opus1.com/jms
> 



From richard.barnes at gmail.com  Sun Feb 26 03:46:09 2012
From: richard.barnes at gmail.com (Richard Barnes)
Date: Sun, 26 Feb 2012 15:16:09 +0530
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <4F47F961.6050709@opus1.com>
References: <4F47F961.6050709@opus1.com>
Message-ID: <CACB24Mv6hNMHG_wU7L5=gETnCkV1GfdBw9Ok5KOxqv0OriCZGw@mail.gmail.com>

While you're in Korea, you could talk to Samsung as well about
123.32.0.0/12 (including 123.45.67.89).  Closer to home, you could
also talk to AT&T about 12.0.0.0/8 (12.34.56.78).
--Richard

On Sat, Feb 25, 2012 at 2:26 AM, Joel M Snyder <Joel.Snyder at opus1.com> wrote:
> Normally I wouldn't say anything to anyone about anything so mundane as
> brute-force SSH attacks, but this one caught my eye just because of the IP
> address:
>
> ? ? ? ?1.234.35.245
>
> I wanna get a connection in Korea so I can have 1.234.56.78.
>
>
> jms
>
> --
> Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Senior Partner, Opus One ? ? ? Phone: +1 520 324 0494
> jms at Opus1.COM ? ? ? ? ? ? ? ?http://www.opus1.com/jms
>


From mike at mikejones.in  Sun Feb 26 05:12:38 2012
From: mike at mikejones.in (Mike Jones)
Date: Sun, 26 Feb 2012 11:12:38 +0000
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <CACB24Mv6hNMHG_wU7L5=gETnCkV1GfdBw9Ok5KOxqv0OriCZGw@mail.gmail.com>
References: <4F47F961.6050709@opus1.com>
 <CACB24Mv6hNMHG_wU7L5=gETnCkV1GfdBw9Ok5KOxqv0OriCZGw@mail.gmail.com>
Message-ID: <CAAAas8HaEyn-Hud9X5PVdcT3BtO7YO+TeGaK-QmiA1v7WKUt0Q@mail.gmail.com>

On 26 February 2012 09:46, Richard Barnes <richard.barnes at gmail.com> wrote:
> While you're in Korea, you could talk to Samsung as well about
> 123.32.0.0/12 (including 123.45.67.89). ?Closer to home, you could
> also talk to AT&T about 12.0.0.0/8 (12.34.56.78).
> --Richard

Or if you don't mind a "little" unsolicited traffic you could always
ask APNIC if you could have 1.2.3.0/24 which is unlikely to ever get
assigned by the normal process (currently assigned to the debogon
project but i don't think they are actively doing anything with it
just waiting for it to become usable some day)

Also had a look and it appears that along with 8.8.8.0/24 google also
got assigned 4.3.2.0/24 by Level3, but they aren't currently using it.
I wonder which company has the "best" collection of IP assignments...

- Mike


From caldcv at gmail.com  Sun Feb 26 10:41:44 2012
From: caldcv at gmail.com (Chris)
Date: Sun, 26 Feb 2012 11:41:44 -0500
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <CAAAas8HaEyn-Hud9X5PVdcT3BtO7YO+TeGaK-QmiA1v7WKUt0Q@mail.gmail.com>
References: <4F47F961.6050709@opus1.com>
 <CACB24Mv6hNMHG_wU7L5=gETnCkV1GfdBw9Ok5KOxqv0OriCZGw@mail.gmail.com>
 <CAAAas8HaEyn-Hud9X5PVdcT3BtO7YO+TeGaK-QmiA1v7WKUt0Q@mail.gmail.com>
Message-ID: <CAPF5agd76+PNQYvtFgNcf8xEAWJp7KAi1fSE2AAoxZM5LYaFSA@mail.gmail.com>

Ughhh been getting cPanel SSH brute force alerts all weekend because of him

-C


From jra at baylink.com  Sun Feb 26 13:42:50 2012
From: jra at baylink.com (Jay Ashworth)
Date: Sun, 26 Feb 2012 14:42:50 -0500 (EST)
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <CACB24Mv6hNMHG_wU7L5=gETnCkV1GfdBw9Ok5KOxqv0OriCZGw@mail.gmail.com>
Message-ID: <31975655.512.1330285370739.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Richard Barnes" <richard.barnes at gmail.com>

> 123.32.0.0/12 (including 123.45.67.89). Closer to home, you could
> also talk to AT&T about 12.0.0.0/8 (12.34.56.78).

Somewhat surprisingly, AT&T doesn't seem to be *doing* anything special with
12.34.56.78.

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


From bonomi at mail.r-bonomi.com  Sun Feb 26 16:29:13 2012
From: bonomi at mail.r-bonomi.com (Robert Bonomi)
Date: Sun, 26 Feb 2012 16:29:13 -0600 (CST)
Subject: Cool IPs: 1.234.35.245 brute force SSHing
In-Reply-To: <31975655.512.1330285370739.JavaMail.root@benjamin.baylink.com>
Message-ID: <201202262229.q1QMTDJP076951@mail.r-bonomi.com>


Jay Ashworth <jra at baylink.com> wrote:
> "Richard Barnes" <richard.barnes at gmail.com> wrote:`
> > 123.32.0.0/12 (including 123.45.67.89). Closer to home, you could
> > also talk to AT&T about 12.0.0.0/8 (12.34.56.78).
>
> Somewhat surprisingly, AT&T doesn't seem to be *doing* anything special with
> 12.34.56.78.

Level3 also has a 'unique' possibility they don't seem to be doing anything
with.  8.16.24.32/32 could be
inside 8.16.24/24
inside 8.16/16
inside 8/8




From rcarpen at network1.net  Sun Feb 26 16:56:41 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Sun, 26 Feb 2012 17:56:41 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
Message-ID: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>



Does anyone have any recommendation for a reliable cloud host?

We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.

We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.

Basic requirements:

1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)
2. Actual support (with a phone number I can call)
3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)

thanks,
-Randy


From mike.lyon at gmail.com  Sun Feb 26 17:04:13 2012
From: mike.lyon at gmail.com (Mike Lyon)
Date: Sun, 26 Feb 2012 13:04:13 -1000
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <4072438532644084451@unknownmsgid>

Godaddy? Servint.com? Amazon EC2?

-mike

Sent from my iPhone

On Feb 26, 2012, at 12:57, Randy Carpenter <rcarpen at network1.net> wrote:

>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.
>
> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.
>
> Basic requirements:
>
> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)
> 2. Actual support (with a phone number I can call)
> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)
>
> thanks,
> -Randy
>


From toasty at dragondata.com  Sun Feb 26 17:26:31 2012
From: toasty at dragondata.com (Kevin Day)
Date: Sun, 26 Feb 2012 17:26:31 -0600
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>


On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.
> 
> Basic requirements:
> 
> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)

This is actually a much harder problem to solve than it sounds, and gets progressively harder depending on what you mean by "failover".

At the very least, having two physical hosts capable of running your VM requires that your VM be stored on some kind of SAN (usually iSCSI based) storage system. Otherwise, two hosts have no way of accessing your VM's data if one were to die. This makes things an order of magnitude or higher more expensive.

But then all you've really done is moved your single point of failure to the SAN. Small SANs aren't economical, so you end up having tons of customers on one SAN. If it dies tons of VMs are suddenly down. So you now need a redundant SAN capable of live-mirroring everyone's data. These aren't cheap either, and add a lot of complexity to things. (How to handle failover if it died mid-write, who has the most recent data after a total blackout, etc)

And this is really just saying "If hardware fails, i want my VM to reboot on another host." If what you're defining high availability to mean "even if a physical host fails, i don't want a second of downtime, my VM can't reboot" you want something like VMware's ESXi High Availability modules where your VM is actually running on two hosts at once, running in lock-step with each other so if one fails the other takes over transparently. Licenses for this are ridiculously expensive, and requires some reasonably complex networking and storage systems.

And I still haven't touched on having to make sure both physical hosts capable of running your VM are on totally independent switches/power/etc, the SAN has multiple interfaces so it's not all going through one switch, etc.

I also haven't run into anyone deploying a high-availability/redundant system where they haven't accidentally ended up with a split-brain scenario (network isolation causes the backup node to think it's live, when the primary is still running). Carefully synchronizing things to prevent this is hard and fragile.

I'm not saying you can't have this feature, but it's not typical in "reasonably priced" cloud services, and nearly unheard-of to be something automatically used. Just moving your virtual machine from using local storage to ISCSI backed storage drastically increases disk latency and caps the whole physical host's disk speed to 1gbps (not much deployment for 10GE adapters on the low-priced VM provider yet). Any provider who automatically provisions a virtual machine this way will get complaints that their servers are slow, which is true compared to someone selling VMs that use local storage. The "running your VM on two hosts at once" system has such a performance penalty, and costs so much in licensing, you really need to NEED it for it not to be a ridiculous waste of resources.

Amazon comes sorta close to this, in that their storage is mostly-totally separate from the hosts running your code. But they have had failures knock out access to your storage, so it's still not where I think you're saying you want to be.

The moral of the story is that just because it's "in the cloud", it doesn't gain higher reliability unless you're specifically taking steps to ensure it. Most people solve this by taking things that are already distributable (like DNS) and setting up multiple DNS servers in different places - that's where all this "cloud stuff" really shines.


(please no stories about how you were able to make a redundant virtual machine run using 5 year old servers in your basement, i'm talking about something that's supportable on a provider scale, and isn't adding more single-points-of-failure)

-- Kevin



From ben at bencarleton.com  Sun Feb 26 17:27:04 2012
From: ben at bencarleton.com (Ben Carleton)
Date: Sun, 26 Feb 2012 18:27:04 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <4072438532644084451@unknownmsgid>
References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
 <4072438532644084451@unknownmsgid>
Message-ID: <4F4ABFC8.3050801@bencarleton.com>

On 2/26/2012 6:04 PM, Mike Lyon wrote:
> Godaddy? Servint.com? Amazon EC2?
>
> -mike
>
> Sent from my iPhone
>
> On Feb 26, 2012, at 12:57, Randy Carpenter <rcarpen at network1.net> wrote:
>
>>
>> Does anyone have any recommendation for a reliable cloud host?
>>
>> We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.
>>
>> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.
>>
>> Basic requirements:
>>
>> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)
>> 2. Actual support (with a phone number I can call)
>> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)
>>
>> thanks,
>> -Randy
>>

With that some of those cloud providers are charging per-instance,
automatic hot standby is really not a given, but that could just be me :)

We use Amazon and are happy with them. With them, you would have to set
up your own failover operation but it's absolutely doable. They give you
all the tools you need (load balancing, EBS, etc) but it's up to you to
make it happen. We use their load-balancing feature with HTTP but it
looks like you could do it with any service (DNS, etc). As a result,
when they had their last huge outage (a whole datacenter), we lost some
of our instances but our customer-facing services remained available.

Their support options are pretty good but you have to shell out for a
package to get them on the phone. Pricing for that is tied to how much
of their resources you are using.

-- Ben


From netengr at gmail.com  Sun Feb 26 17:34:31 2012
From: netengr at gmail.com (Netengr)
Date: Mon, 27 Feb 2012 07:34:31 +0800
Subject: HP A6600 experiences
In-Reply-To: <D181DDABABE57E4DB72FEE00331478644B9A53@EALPO1.ukbroadband.com>
References: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
 <D181DDABABE57E4DB72FEE00331478644B9A53@EALPO1.ukbroadband.com>
Message-ID: <52431928-677A-42B4-8CCB-8EF61B2F8834@gmail.com>

HP 6604, 6608 both models has FIP modules FIP 100 and FIP 200 only these modules are now replaced with FIP 110 and FIP 210 those comes with double the power of earlier models. So A6604still available with FIP 210

Regards
Ubaid


On 25-Feb-2012, at 6:45, Leigh Porter <leigh.porter at ukbroadband.com> wrote:

> 
> I thought the A6604 was EOL?
> 
> http://h17007.www1.hp.com/docs/products/eos/Select_HP_A6600_Routers_and_Modules_ES_Announcement.pdf
> 
> 
> --
> Leigh
> 
> 
>> -----Original Message-----
>> From: Christopher Pilkington [mailto:cjp at 0x1.net]
>> Sent: 24 February 2012 19:05
>> To: NANOG mailing list
>> Subject: HP A6600 experiences
>> 
>> If anyone has any experiences they'd be willing to share, or even lab
>> reports, on HP A6600, it would be helpful.  I believe this is the same
>> product as H3C SR6600.
>> 
>> We're being asked to "look at" A6604 facing our IPv4/IPv6 transit.  I'd
>> like to get some opinions before I go through effort of getting one in
>> the lab.
>> 
>> -cjp
>> 
>> ______________________________________________________________________
>> This email has been scanned by the Symantec Email Security.cloud
>> service.
>> For more information please visit http://www.symanteccloud.com
>> ______________________________________________________________________
> 
> ______________________________________________________________________
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> 


From netengr at gmail.com  Sun Feb 26 17:39:31 2012
From: netengr at gmail.com (Netengr)
Date: Mon, 27 Feb 2012 07:39:31 +0800
Subject: HP A6600 experiences
In-Reply-To: <CAOC=LuUWnVDqxAXKinTSBq3qwsyOsXmvXueWhR=g4ucuTX2bOA@mail.gmail.com>
References: <2DD6885A-13DA-4D72-B96F-0AD077BAF091@0x1.net>
 <CAOC=LuUWnVDqxAXKinTSBq3qwsyOsXmvXueWhR=g4ucuTX2bOA@mail.gmail.com>
Message-ID: <7B606535-D51B-44A0-BF7A-B476AB3760CA@gmail.com>

Hi Brent,

Was your experience is with procure range or H3C? So far I found no issues with H3C it's multicore 10G platform comes with Comware which is the same OS across H3C routers and switches.

Chris, if you need more power there is another higher model 8800 platform 

Regards
Ubaid


On 25-Feb-2012, at 14:15, Brent Jones <brent at brentrjones.com> wrote:

> On Fri, Feb 24, 2012 at 11:01 AM, Christopher Pilkington <cjp at 0x1.net>wrote:
> 
>> If anyone has any experiences they'd be willing to share, or even lab
>> reports, on HP A6600, it would be helpful.  I believe this is the same
>> product as H3C SR6600.
>> 
>> We're being asked to "look at" A6604 facing our IPv4/IPv6 transit.  I'd
>> like to get some opinions before I go through effort of getting one in the
>> lab.
>> 
>> -cjp
>> 
> 
> If HP's modular chassis are anything like their fixed configuration, I
> would stay away from them.
> We abandoned all HP networking equipment due to gross bugs and firmware
> incompatibility.
> We tried to deploy 10Gb with HP, but they had shipping hardware, with no
> firmware to support the modules. Now they recommend us switching all our
> Procurve line with H3C.
> 
> Needless to say, we will not buy HP/H3C equipment ever again, lesson
> learned.
> 
> Juniper, Force10, Arista, and Cisco (surprisingly) make much better gear
> these days at much more competitive pricing.
> 
> -- 
> Brent Jones
> brent at brentrjones.com


From nanog at deman.com  Sun Feb 26 17:52:27 2012
From: nanog at deman.com (Michael DeMan)
Date: Sun, 26 Feb 2012 15:52:27 -0800
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <31877C63-383C-4A07-9838-6BE0394AB146@deman.com>

We have found it effective at least for things like DNS and MX-backup to simply swap some VPS and/or physical colo with another ISP outside our geographic area.  Both protocols are designed for that kind of redundancy.  Definitely has limitations, but is also probably the cheapest solution.

- Mike

On Feb 26, 2012, at 2:56 PM, Randy Carpenter wrote:

> 
> 
> Does anyone have any recommendation for a reliable cloud host?
> 
> We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.
> 
> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.
> 
> Basic requirements:
> 
> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)
> 2. Actual support (with a phone number I can call)
> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)
> 
> thanks,
> -Randy
> 



From rcarpen at network1.net  Sun Feb 26 18:02:20 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Sun, 26 Feb 2012 19:02:20 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
Message-ID: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>



----- Original Message -----
> 
> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> > We have been using Rackspace Cloud Servers. We just realized that
> > they have absolutely no redundancy or failover after experiencing
> > a outage that lasted more than 6 hours yesterday. I am appalled
> > that they would offer something called "cloud" without having any
> > failover at all.
> > 
> > Basic requirements:
> > 
> > 1. Full redundancy with instant failover to other hypervisor hosts
> > upon hardware failure (I thought this was a given!)
> 
> This is actually a much harder problem to solve than it sounds, and
> gets progressively harder depending on what you mean by "failover".
> 
> At the very least, having two physical hosts capable of running your
> VM requires that your VM be stored on some kind of SAN (usually
> iSCSI based) storage system. Otherwise, two hosts have no way of
> accessing your VM's data if one were to die. This makes things an
> order of magnitude or higher more expensive.

This does not have to be true at all.  Even having a fully fault-tolerant SAN in addition to spare servers should not cost much more than having separate RAID arrays inside each of the server, when you are talking about 1,000s of server (which Rackspace certainly has)

> But then all you've really done is moved your single point of failure
> to the SAN. Small SANs aren't economical, so you end up having tons
> of customers on one SAN. If it dies tons of VMs are suddenly down.
> So you now need a redundant SAN capable of live-mirroring everyone's
> data. These aren't cheap either, and add a lot of complexity to
> things. (How to handle failover if it died mid-write, who has the
> most recent data after a total blackout, etc)

NetApp. HA heads. Done. Add a DR site with replication, and you can survive a site failure, and be back up and running in less than an hour. I would think that the big datacenter guys already have this type of thing set up.

> And this is really just saying "If hardware fails, i want my VM to
> reboot on another host." If what you're defining high availability
> to mean "even if a physical host fails, i don't want a second of
> downtime, my VM can't reboot" you want something like VMware's ESXi
> High Availability modules where your VM is actually running on two
> hosts at once, running in lock-step with each other so if one fails
> the other takes over transparently. Licenses for this are
> ridiculously expensive, and requires some reasonably complex
> networking and storage systems.

I don't need that kind of HA, and understand that it is not going to be available. 15 minutes of downtime is fine. 6 hours is completely unacceptable, and it false advertising to say you have a "Cloud" service, and then have the realization that you could have *indefinite* downtime.

> And I still haven't touched on having to make sure both physical
> hosts capable of running your VM are on totally independent
> switches/power/etc, the SAN has multiple interfaces so it's not all
> going through one switch, etc.

That is all just basic datacenter design. I have that level of redundancy with my extremely small datacenter. I only have 2 hypervisor hosts running around 12 VMs.

> I also haven't run into anyone deploying a
> high-availability/redundant system where they haven't accidentally
> ended up with a split-brain scenario (network isolation causes the
> backup node to think it's live, when the primary is still running).
> Carefully synchronizing things to prevent this is hard and fragile.

I've never had it. Not if you properly set up failover (look at STONITH)

> I'm not saying you can't have this feature, but it's not typical in
> "reasonably priced" cloud services, and nearly unheard-of to be
> something automatically used. Just moving your virtual machine from
> using local storage to ISCSI backed storage drastically increases
> disk latency and caps the whole physical host's disk speed to 1gbps

No it doesn't. Haven't you heard of multipath? Using 4 1Gb/s paths gives me about the same I/O as a local RAID array, with the added feature of failover if a link drops. 4 1Gb/s ports is ridiculously cheap. And, 10Gb is not nearly as expensive as it used to be.

> (not much deployment for 10GE adapters on the low-priced VM provider
> yet). Any provider who automatically provisions a virtual machine
> this way will get complaints that their servers are slow, which is
> true compared to someone selling VMs that use local storage. The
> "running your VM on two hosts at once" system has such a performance
> penalty, and costs so much in licensing, you really need to NEED it
> for it not to be a ridiculous waste of resources.

I don't follow what you mean by "running the VM on two hosts." I just want my single virtual to be booted up on a spare hypervisor if there is a hypervisor failure. No license costs for that, and should not have any performance implications at all.

> Amazon comes sorta close to this, in that their storage is
> mostly-totally separate from the hosts running your code. But they
> have had failures knock out access to your storage, so it's still
> not where I think you're saying you want to be.
> 
> The moral of the story is that just because it's "in the cloud", it
> doesn't gain higher reliability unless you're specifically taking
> steps to ensure it. Most people solve this by taking things that are
> already distributable (like DNS) and setting up multiple DNS servers
> in different places - that's where all this "cloud stuff" really
> shines.

The funky problem with DNS specifically, is that all the servers need to be up, or someone will get bad answers. Not having a preference system, like MX records has hurt in this regard. Anycast fixes this to a certain degree. Anycast is another challenge for these hosting providers.
 
> (please no stories about how you were able to make a redundant
> virtual machine run using 5 year old servers in your basement, i'm
> talking about something that's supportable on a provider scale, and
> isn't adding more single-points-of-failure)

I have actually done this :-)

But, I also have a fully redundant system at our main office using very few components. We also have a DR site, connected with fiber. The challenge we have is if we run into routing issues upstream that are beyond our control. Hence the need to have a few things also hosted externally geographically and routing-wise.


From drais at icantclick.org  Sun Feb 26 18:19:02 2012
From: drais at icantclick.org (david raistrick)
Date: Sun, 26 Feb 2012 19:19:02 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
References: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
Message-ID: <alpine.BSF.2.00.1202261918580.42771@murf.icantclick.org>

On Sun, 26 Feb 2012, Randy Carpenter wrote:

> I don't need that kind of HA, and understand that it is not going to be 
> available. 15 minutes of downtime is fine. 6 hours is completely 
> unacceptable, and it false advertising to say you have a "Cloud" 
> service, and then have the realization that you could have *indefinite* 
> downtime.


Um.  You and I apparently work in different clouds.

In my world, the SLAs I have agreed to state, roughly, that uptime is not 
guaranteed, nor is data recoverability.  They suggest that that sort of 
thing is -my- problem to engineer and architect around.

I don't use Rackspace's cloud solution - but I haven't seen anything to 
suggest that they advertise their service any differently.

The "cloud" provides flexibility and rapid deployment at the expense of 
hands-on control and reliability (and SLAs).

Perhaps you forgot to read the SLA?  Or you can show us where someone 
defines "Cloud" as "highly available" and "without indefinite downtime" ?



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From jlewis at lewis.org  Sun Feb 26 18:29:40 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Sun, 26 Feb 2012 19:29:40 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
References: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
Message-ID: <Pine.LNX.4.61.1202261913450.2201@soloth.lewis.org>

On Sun, 26 Feb 2012, Randy Carpenter wrote:

> This does not have to be true at all.  Even having a fully 
> fault-tolerant SAN in addition to spare servers should not cost much 
> more than having separate RAID arrays inside each of the server, when 
> you are talking about 1,000s of server (which Rackspace certainly has)

When is your cloud offering going to be available to the public?

> I don't need that kind of HA, and understand that it is not going to be 
> available. 15 minutes of downtime is fine. 6 hours is completely 
> unacceptable, and it false advertising to say you have a "Cloud" 
> service, and then have the realization that you could have *indefinite* 
> downtime.

I think you're assuming "cloud" means things that the provider does not. 
To me, "cloud" just means VPS that I can create/destroy quickly whenever I 
feel like it, without any interaction from the provider's people.  i.e. a 
few mouse clicks or an API call can "provision a 10gb CentOS VM with 256mb 
RAM".  It's up and running before I could locate a CentOS install CD, and 
if I don't like it, a few clicks or an API call deletes it, reprovisions 
it, exchanges it for a Ubuntu server, etc.  Cloud doesn't mean if the node 
my VM(s) are on dies or crashes, my VMs boot up on an alternate node. 
That would certainly be a nice feature, but that's just a form of 
redundancy in a cloud...not a defining attribute of cloud.

> The funky problem with DNS specifically, is that all the servers need to 
> be up, or someone will get bad answers. Not having a preference system,

DNS "handles" down servers.  How would one of your DNS servers being down 
give someone bad answers?  It won't give any answers, and another server 
will be queried.  Or do you mean if storage "goes away", but your DNS 
server is still running, it'll either give nxdomain or stale 
data...depending on whether it had the data in memory or storage went away 
and updates began failing because of it?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From jlewis at lewis.org  Sun Feb 26 18:34:23 2012
From: jlewis at lewis.org (Jon Lewis)
Date: Sun, 26 Feb 2012 19:34:23 -0500 (EST)
Subject: Common operational misconceptions
In-Reply-To: <87obsx9sgf.fsf@pc8.berlin.quux.de>
References: <20120215144715.18e65a55@w520.localdomain>
 <4F3C4B8E.2010900@necom830.hpcl.titech.ac.jp>
 <8C26A4FDAE599041A13EB499117D3C286B7B6C94@ex-mb-2.corp.atlasnetworks.us>
 <F97E3FA7-1FD5-488D-BE81-4C26AA34EEDC@puck.nether.net>
 <86BF63E7-DCC5-400A-BC08-436F19280134@delong.com>
 <CALFTrnNzgs1V1i35sZPbU_jEg61Kmh=N7=aQCQxk4Rkhoy--GQ@mail.gmail.com>
 <4F3D3806.4000008@brightok.net> <5AD4C80D-425E-4CD0-B661-CF4F359A3D00@tzi.org>
 <4F3DF8A3.8040708@paulgraydon.co.uk>
 <20120217142927.GA70102@ussenterprise.ufp.org>
 <4F3E69A7.2060008@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C053D5A@CSIT-SRV-MBX-01.charterschoolit.local>
 <4F3E7776.1010405@gmail.com>
 <C95B38A68C80744C8B371447DB6EE98C05409D@CSIT-SRV-MBX-01.charterschoolit.local>
 <60D4E71A-E275-413B-8DCD-932BE124461B@delong.com>
 <87obsx9sgf.fsf@pc8.berlin.quux.de>
Message-ID: <Pine.LNX.4.61.1202261931580.2201@soloth.lewis.org>

Blocking incoming spam is worth spending $ on for software, 3rd party 
filtering services, or dedicated spam filtering hardare.  Blocking 
outgoing spam?  Huh?

----------------------------------------------------------------------
  Jon Lewis, MCP :)           |  I route
  Senior Network Engineer     |  therefore you are
  Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


From apishdadi at gmail.com  Sun Feb 26 19:27:28 2012
From: apishdadi at gmail.com (A. Pishdadi)
Date: Sun, 26 Feb 2012 19:27:28 -0600
Subject: Programmers with network engineering skills
Message-ID: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>

Hello All,

i have been looking for quite some time now a descent coder (c,php) who has
a descent amount of system admin / netadmin experience. Doesn't necessarily
need to be an expert at network engineering but being acclimated in
understanding the basic fundamentals of networking. Understanding basic
routing concepts, how to diagnose using tcpdump / pcap, understanding
subnetting and how bgp works (not necessarily setting up bgp). I've posted
job listings on the likes of dice and monster and have not found any good
canidates, most of them ASP / Java guys.

If anyone can point me to a site they might recommend for job postings or
know of any consulting firms that might provide these services that would
be greatly appreciated.

From tony at swalter.com  Sun Feb 26 20:39:41 2012
From: tony at swalter.com (Tony Patti)
Date: Sun, 26 Feb 2012 21:39:41 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <alpine.BSF.2.00.1202261918580.42771@murf.icantclick.org>
References: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <alpine.BSF.2.00.1202261918580.42771@murf.icantclick.org>
Message-ID: <026201ccf4f9$0e7e3d10$2b7ab730$@com>

> -----Original Message-----
> From: david raistrick [mailto:drais at icantclick.org] 
> Sent: Sunday, February 26, 2012 7:19 PM
> To: Randy Carpenter
> Cc: Nanog
> Subject: Re: Reliable Cloud host ?
> 
> On Sun, 26 Feb 2012, Randy Carpenter wrote:
> 
> > I don't need that kind of HA, and understand that it is not going to 
> > be available. 15 minutes of downtime is fine. 6 hours is completely 
> > unacceptable, and it false advertising to say you have a "Cloud"
> > service, and then have the realization that you could have 
> > *indefinite* downtime.
> 
> Um.  You and I apparently work in different clouds.

Since it is the weekend, I can't resist writing down a little equation:

Marketing(cloud) <> Technology(cloud)

For some values  of "cloud" perhaps?

p.s. tongue firmly in cheek

- Tony




From eyeronic.design at gmail.com  Mon Feb 27 00:34:12 2012
From: eyeronic.design at gmail.com (Mike Hale)
Date: Sun, 26 Feb 2012 22:34:12 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>

Isn't this what the entire DevOps movement is kinda trying to push?

I see quite a few of these gigs pop up on Craigslist.  If you've
already invested some time in the search, perhaps it'd be better to
hire someone good with C/PHP and train them in the art of networking.

If you're located in a major city, I'm sure you can find a community
college that has a networking certificate program you can send your
developer to, along with an in-house training program.

Just a thought.  Best of luck.  :)

On Sun, Feb 26, 2012 at 5:27 PM, A. Pishdadi <apishdadi at gmail.com> wrote:
> Hello All,
>
> i have been looking for quite some time now a descent coder (c,php) who has
> a descent amount of system admin / netadmin experience. Doesn't necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've posted
> job listings on the likes of dice and monster and have not found any good
> canidates, most of them ASP / Java guys.
>
> If anyone can point me to a site they might recommend for job postings or
> know of any consulting firms that might provide these services that would
> be greatly appreciated.



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0


From morrowc.lists at gmail.com  Mon Feb 27 00:39:50 2012
From: morrowc.lists at gmail.com (Christopher Morrow)
Date: Mon, 27 Feb 2012 01:39:50 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
Message-ID: <CAL9jLaZpOw_BTTPR-6gc_QecUZCSUTzohLEOXvaXqmRpci8yJg@mail.gmail.com>

On Mon, Feb 27, 2012 at 1:34 AM, Mike Hale <eyeronic.design at gmail.com> wrote:
> Isn't this what the entire DevOps movement is kinda trying to push?
>

as to devops... this was funny:

<http://velocityconf.com/velocity2011/public/schedule/detail/20406>

-chris


From mlspirat42 at gmail.com  Mon Feb 27 00:56:10 2012
From: mlspirat42 at gmail.com (Benjamin)
Date: Mon, 27 Feb 2012 15:56:10 +0900
Subject: Programmers with network engineering skills
In-Reply-To: <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
Message-ID: <4F4B290A.7040503@gmail.com>

On 27/02/2012 15:34, Mike Hale wrote:
> Isn't this what the entire DevOps movement is kinda trying to push?
>
>
Wow, thanks, I ignored about the DevOps, that's exactly how I would 
define myself. Is there a particular website where DevOps are supposed 
to post their resume or find job offers?




From leigh.porter at ukbroadband.com  Mon Feb 27 03:40:17 2012
From: leigh.porter at ukbroadband.com (Leigh Porter)
Date: Mon, 27 Feb 2012 09:40:17 +0000
Subject: Reliable Cloud host ?
In-Reply-To: <026201ccf4f9$0e7e3d10$2b7ab730$@com>
References: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <alpine.BSF.2.00.1202261918580.42771@murf.icantclick.org>
 <026201ccf4f9$0e7e3d10$2b7ab730$@com>
Message-ID: <D181DDABABE57E4DB72FEE00331478644BBA89@EALPO1.ukbroadband.com>


> -----Original Message-----
> From: Tony Patti [mailto:tony at swalter.com]
> Sent: 27 February 2012 02:42
> To: 'david raistrick'; 'Randy Carpenter'
> Cc: 'Nanog'
> Subject: RE: Reliable Cloud host ?
> 
> > -----Original Message-----
> > From: david raistrick [mailto:drais at icantclick.org]
> > Sent: Sunday, February 26, 2012 7:19 PM
> > To: Randy Carpenter
> > Cc: Nanog
> > Subject: Re: Reliable Cloud host ?
> >
> > On Sun, 26 Feb 2012, Randy Carpenter wrote:
> >
> > > I don't need that kind of HA, and understand that it is not going
> to
> > > be available. 15 minutes of downtime is fine. 6 hours is completely
> > > unacceptable, and it false advertising to say you have a "Cloud"
> > > service, and then have the realization that you could have
> > > *indefinite* downtime.
> >
> > Um.  You and I apparently work in different clouds.
> 
> Since it is the weekend, I can't resist writing down a little equation:
> 
> Marketing(cloud) <> Technology(cloud)
> 
> For some values  of "cloud" perhaps?

Well indeed that is a valid point. All cloud to me means is that there is some abstracted instance of x and that it does not always relate to a particular physical device, indeed, it may well be spread around a few physical devices. 

I don't think there is any implied magic redundancy automatic failover move your instance to another bit of metal if something breaks in there unless that's specifically stated.

caveat emptor

--
Leigh


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


From askoorb+nanog at gmail.com  Mon Feb 27 06:24:43 2012
From: askoorb+nanog at gmail.com (Alex Brooks)
Date: Mon, 27 Feb 2012 12:24:43 +0000
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
 <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <CALKLF08NUXKgCi5k5EDxg7QH7S5bX+uRUFEGGV=ysS46JG15jQ@mail.gmail.com>

Hello,

On Sun, Feb 26, 2012 at 10:56 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.
>
> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.
>
> Basic requirements:
>
> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)
> 2. Actual support (with a phone number I can call)
> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)
>

Well, as everyone has been saying, unfortunately with "infrastructure"
clouds, you have to engineer your set up to their standards to have
failover.

For example, Amazon (as mentioned in the thread) give a 99.95% uptime
SLA *if* you set up failover yourself accros more than one
"Avaliability Zone" within a region.  Details are at
http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html
and http://blog.rightscale.com/2008/03/26/setting-up-a-fault-tolerant-site-using-amazons-availability-zones/
(though clearer, this one is a bit of an advert).  As mentioned, with
Amazon, you can use support if you pay for it, it's not included as
standard.

If you fancy some help though, people like RightScale sounds like
exactly what you are after to make management much simpler for you
http://www.rightscale.com/products/why-rightscale.php, but pricing for
services like that can be a little high for small setups, though they
do have a free edition that may be suitable.

You can get the same kind of 99.95% SLA from other providers if you
follow their deployment guidelines regarding their type of "zones".
Microsoft will do it for not too much
)http://www.windowsazure.com/en-us/support/sla/) include online and
telephone support in the price and are in the process of making Red
Hat Linux available.

But let's not forget simply buying the software as a service is also
an option, where fail-over becomes Someone Else's Problem.  For DNS,
EasyDNS (https://web.easydns.com/DNS_hosting.php) are rather good and
not too expensive, and you can get a 100% up-time guarantee if you
want.  A review of them regarding availability is at
http://www.theregister.co.uk/2012/01/31/why_i_use_easydns/

Do let us know who you end up picking and how it goes.

Alex


From andy at meniscus.org  Mon Feb 27 06:36:45 2012
From: andy at meniscus.org (Andy Grosser)
Date: Mon, 27 Feb 2012 07:36:45 -0500
Subject: Comcast / RCN Issues in Boston
In-Reply-To: <3C43EC49B7AF084BA385F946485B1F4C54456D8F9B@ITCCRMAIL02.MED.HARVARD.EDU>
References: <3C43EC49B7AF084BA385F946485B1F4C54456D8F9B@ITCCRMAIL02.MED.HARVARD.EDU>
Message-ID: <CAExboLyKnOT2zVZyy+N-26OrKR3ivQXDVnTM-n1-TZ5t0vfdKw@mail.gmail.com>

There was an issue during much of the day on Friday 2/24 due to a code
error on a Harvard Internet2 router at NOX.  It was bounced around 4:35 pm
and everything has been fine since.

Andy


On Fri, Feb 24, 2012 at 2:37 PM, Hashem, Sherif Rakhaa <
Sherif_Hashem at hms.harvard.edu> wrote:

> Are there any ongoing issues with Comcast and/or RCN in the Boston Metro
> Area?
>
> Thanks,
> Sherif Hashem
>
> Harvard Medical School | Network Operations
> 25 Shattuck Street | Gordon Hall Suite 500 | Boston, MA, 02115
> d: (617)432-7534  | c: (617)999-7818 | f: (617)432-6804
>
>


-- 
Andy Grosser
andy (at) meniscus [dot] org
---

From perldork at webwizarddesign.com  Mon Feb 27 08:31:57 2012
From: perldork at webwizarddesign.com (Max)
Date: Mon, 27 Feb 2012 09:31:57 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
 <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <CACPTa4J8FJ6vbY-01c5-UHfLrE9qy7sXg1QDtECjCVun+QacVw@mail.gmail.com>

Linode.com is not cloud based but they offer IP failover between VPS
instances at no additonal charge - their pricing is excellent, I have
had no down time issues with them in 3+ years with 3 different
customers using them and they have nice OOB and programmatic API
access for controlling VPs instances as well.

Max

On 2/26/12, Randy Carpenter <rcarpen at network1.net> wrote:
>
>
> Does anyone have any recommendation for a reliable cloud host?
>
> We require 1 or 2 very small virtual hosts to host some remote services to
> serve as backup to our main datacenter. One of these services is a DNS
> server, so it is important that it is up all the time.
>
> We have been using Rackspace Cloud Servers. We just realized that they have
> absolutely no redundancy or failover after experiencing a outage that lasted
> more than 6 hours yesterday. I am appalled that they would offer something
> called "cloud" without having any failover at all.
>
> Basic requirements:
>
> 1. Full redundancy with instant failover to other hypervisor hosts upon
> hardware failure (I thought this was a given!)
> 2. Actual support (with a phone number I can call)
> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny
> 256MB RAM Server with <1GB/mo of data transfers)
>
> thanks,
> -Randy
>
>


From jared at puck.nether.net  Mon Feb 27 08:39:25 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 27 Feb 2012 09:39:25 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <D7DF15F1-8609-4650-A3B0-0472AF02158D@puck.nether.net>


On Feb 26, 2012, at 5:56 PM, Randy Carpenter wrote:

> We require 1 or 2 very small virtual hosts to host some remote services to serve as backup to our main datacenter. One of these services is a DNS server, so it is important that it is up all the time.
> 
> We have been using Rackspace Cloud Servers. We just realized that they have absolutely no redundancy or failover after experiencing a outage that lasted more than 6 hours yesterday. I am appalled that they would offer something called "cloud" without having any failover at all.

Pardon the weird question:

Is the DNS service authoritative or recursive?  If auth, you can solve this a few ways, either by giving the DNS name people point to multiple AAAA (and A) records pointing at a diverse set of instances.  DNS is designed to work around a host being down.  Same goes for MX and several other services.  While it may make the service slightly slower, it's certainly not the end of the world.

Taking a mesh of services from Rackspace, EC2, The Planet, or any other number of hosting providers will allow you to roll-your-own.

The other solution is to go to a professional DNS service provider, e.g.: Dyn, Verisign, EveryDNS or NeuStar.

While you can run your own infrastructure, the barrier for operating it properly is getting a bit higher each year in doing it "right".  I was recently shown an attack graph of a ~200Gb/s attack against a DNS server.  *ouch*.

Sometimes being professional is knowing when to say "I can't do this justice myself, perhaps it's better/easier/cheaper to pay someone to do it right".

- Jared

(Disclosure: I work for one of the above named companies, but not in a capacity related to anything in this email).

From david at davidswafford.com  Mon Feb 27 09:22:24 2012
From: david at davidswafford.com (David Swafford)
Date: Mon, 27 Feb 2012 10:22:24 -0500
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
Message-ID: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>

Hi Everyone!

I had several requests for more feedback on our FCoE experience, based on
my comments from a thread last week, so I'm writing here with a bit more
background on our project in hopes that it saves some pain for others :-).

I'm with a sizable health insurance provider in the mid-west, and we've
typically focused on technology vs. headcount as an overal strategy.  Based
on that, we upgrade much more often than some of our peers in the industry
because techology is still cheaper than long-term staffing costs.

Last fall, we were faced with an issue of both power and rack capacity
constraints in our primary datacenter, which is just three years old now.
As various ideas were on the table, which included taking out a section of
IT cubes to expand the DC, the most appealing idea was to consolidate our
server and network infrastructure into what was coined our "High Density
Row".

We transitioned from Cat6500s as access to a Nexus 5K deployment, using 5Ks
as both distribution and access for the new HD row.  We didn't like how
oversubscription is handled on 2K FEXs when it comes to 10G links, so for
the situation here all 5Ks made the most sense.  Our capacity needs
couldn't justify 7Ks and while they would have been cool to have, we didn't
want to blow money just because.

Our SAN is an EMC Symmetrix with Cisco MDS switches in between it and the
hosts (Fiber Channel).  In the new row, we deployed all hosts with CNAs
(converged net adapters), which combine both FCoE storage and network in a
single 10Gb connection.  Since FCoE was new to all of us, we use a phased
approach that the Nexus offered where we brough straight fiber channel
connections into our distibution layer 5Ks and used the Nexus' FCoE proxy
functionality to convert between true FC to FCoE.

>From the host perpsective, it was only aware of FCoE connectivity to the
Nexus.  VSANs had to be created on the Nexus to map back to the FC VSANs on
the MDS side, Virtual Fiber Channel (VFC) interfaces were created on the
Nexus side, and a few other settings had to be configured.

Overall though, the config wasn't huge, but the biggest hurdle for was that
as the network guys, we had to learn the storage side to be able to
properly set this up.  So new terms like WWN (world wide name), floggy
database, VSAN (a VLAN for storage), etc.  Also, on the Nexus side, you
have to enable the feature of FCOE, as Nexus OS is very modulular and
leaves most options disabled during the initial setup.

The painful part, which is probably what might be of most interest here, is
that we hit a very strange and catrastrophic issue specific to QLogic's
8242 Copper-based (twinax) CNA adapter.  As part of the burn-in testing, we
were working with our server team to simulate the loss of a
link/card/switch (all hosts were dual-connected with dual-CNAs to separate
5Ks).  We were using the Cisco branded twinax cabling and QLogic's 8242
card (brand new HP DL580s in this case, new card, new 5K, new cabling).
When a single link was dropped/diconnected PHYSICALLY (a shut/no shut is
not the same here), the host's throughput on BOTH storage and network went
to crap.

Our baseline was showing nearly 400MB/s on storage (raw disk IO) tests
prior to a link drop and  1-8 MB/s after!  This siutation would not recover
until you fully rebooted/power cycled the server.  We had the same results
accross every HP DL 580 tested, which was 5-6 of them I belive.  We
replaced CNAs, cables, and even moved ports across 5Ks.  It didn't matter
which cable, 5K, port, of card we used, all reacted the same!  The hosts
were all Windows 2008 Datacenter, simliar hardware, Nexus 5K on current
code, twinax cabling.

This situation led to a sev 2 w/ Cisco, the equivalant w/ HP, EMC, and
QLogic.  We used both the straight QLogic 8242 and the HP OEM'd version and
the results were identical.  QLogic acknowledged the issue but could not
resolve it due not being able to grab a hardware level trace of the
connection (required some type of test equipment that they couldn't provide
and we didn't have).

As part of our trail/error testing, we had our re-seller ship us the fiber
versions of the same QLogic cards, becuase we eventually got down to a gut
instinct of this being a copper/electrical anomoly.  That instict was
dead-on.  Switching to the fiber versions, with fiber SFPs on the 5K side
resolved the situation entirely.  We are now able to drop a link with NO
noticable degradation, back and forth, and eveyrthing is consistent again.

We originally went the twinax route because it was signifiantly cheaper
than the fiber, but in retrospect, as a whole, the danger posed was not
worth it.  You might ask, well... why would you intentially drop the
cable?  Think about a situation of doing a code upgrade on the 5K, since
it's not a dual-sup box, you physcailly go through a reboot to upgrade it.
That reboot right htere would have hosed our entire environment (keep in
mind, the HD row's intent was to replace a signifiant portion of our
production environment).  You could also have a HW failure on a 5K.  It
kind of defeats the point of all this redundancy if your throuhput goes to
hell when loosing a single path.  As our storage guys best put it "i'd
rather loose a path than have bad performance through it....based on how
things alert, I'd know right away if a path were down, but not if it were
severaly degraded."

Btw, we've been rock solid on the fiber-connected CNAs ever since.  We're
still using copper on our connections to HP blade chassis though, which go
to FLEX Fabric cards, as we couldn't produce the problem on those.  For
those wondering, we did rebuild several of the DL580s from scratch (all of
this was a new deployment, thankfully!), we also went through many
iterations of driver updates/changes/etc.

Lots of head-banging and teamwork eventually got us squared away!  This
situation is a good example of why network guys NEED to have a great
relationship with both server and storage guys (we're all really close
where I'm at).  Had there been tension/etc between the teams, this would
have been signifiantky harder to resolve.

Hope this helps, sorry for the long winded email :-), but I think those
interested will find it beneficial.


David.

From jasongurtz at npumail.com  Mon Feb 27 09:25:34 2012
From: jasongurtz at npumail.com (Jason Gurtz)
Date: Mon, 27 Feb 2012 10:25:34 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <CALKLF08NUXKgCi5k5EDxg7QH7S5bX+uRUFEGGV=ysS46JG15jQ@mail.gmail.com>
References: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
 <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
 <CALKLF08NUXKgCi5k5EDxg7QH7S5bX+uRUFEGGV=ysS46JG15jQ@mail.gmail.com>
Message-ID: <A92EAF652EC423438D55C14C60771C870467E567@exchgsrv.nputilities.local>

> [...]  For DNS,
> EasyDNS (https://web.easydns.com/DNS_hosting.php) are rather good and
> not too expensive, and you can get a 100% up-time guarantee if you
> want.  A review of them regarding availability is at
> http://www.theregister.co.uk/2012/01/31/why_i_use_easydns/

I have been a very satisfied EasyDNS customer for about a decade and
concur with the article. Nothing is perfect, but the rapid response and
support I've received have always been top-notch.

> Do let us know who you end up picking and how it goes.

Indeed. "Cloud" outside of references to mists and objects in the sky is a
completely meaningless term for operators. In fact, it has made it harder
to differentiate between services (which I'm sure is the point).

As an operator (knowing how things can be subject to accelerated roll-out
when $business feels they are missing out), I wonder if a lot of these
"cloud" service bumps-in-the-road aren't just a symptom of not being fully
baked in.

~JasonG


From bill at herrin.us  Mon Feb 27 09:28:37 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 10:28:37 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
Message-ID: <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>

On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
>> > 1. Full redundancy with instant failover to other hypervisor hosts
>> > upon hardware failure (I thought this was a given!)
>>
>> This is actually a much harder problem to solve than it sounds, and
>> gets progressively harder depending on what you mean by "failover".
>>
>> At the very least, having two physical hosts capable of running your
>> VM requires that your VM be stored on some kind of SAN (usually
>> iSCSI based) storage system. Otherwise, two hosts have no way of
>> accessing your VM's data if one were to die. This makes things an
>> order of magnitude or higher more expensive.
>
> This does not have to be true at all. ?Even having a fully fault-tolerant
> SAN in addition to spare servers should not cost much more than
> having separate RAID arrays inside each of the server, when you
> are talking about 1,000s of server (which Rackspace certainly has)

Randy,

You're kidding, right?

SAN storage costs the better part of an order of magnitude more than
server storage, which itself is several times more expensive than
workstation storage. That's before you duplicate the SAN and set up
the replication process so that cabinet and room level failures don't
take you out.

DR sites then create a ferocious (read: expensive) bandwidth
challenge. Data can't flush from the primary SAN's write cache until
the DR SAN acknowledges receipt. If you don't have enough bandwidth to
keep up under the heaviest daily loads, the cache quickly fills and
the writes block.


I maintain 50ish VMs with about 30 different providers at the moment.
Not one of them attempts to do anything like what you describe.


> NetApp. HA heads. Done. Add a DR site with replication,
>and you can survive a site failure, and be back up and
>running in less than an hour. I would think that the big
>datacenter guys already have this type of thing set up.

That's expensive and VMs are sold primarily on price. You want high
reliability, you start with the dedicated colo server. Customers who
want DR in a VM environment buy two VMs and build data replication at
the app layer.


On Mon, Feb 27, 2012 at 9:31 AM, Max <perldork at webwizarddesign.com> wrote:
> Linode.com is not cloud based but they offer IP failover between VPS
> instances at no additonal charge - their pricing is excellent, I have
> had no down time issues with them in 3+ years with 3 different
> customers using them and they have nice OOB and programmatic API
> access for controlling VPs instances as well.

Hi Max,

I have had superb results from Linode and highly recommend them.
However, they're facilitating application level failover not keeping
your VM magically alive. And:

http://library.linode.com/linux-ha/ip-failover-heartbeat-pacemaker-ubuntu-10.04

"Both Linodes must reside in the same datacenter for IP failover"

So they don't support a full DR capability even if you're smart at the
app level.


On Mon, Feb 27, 2012 at 9:39 AM, Jared Mauch <jared at puck.nether.net> wrote:
> Is the DNS service authoritative or recursive?  If auth, you can
> solve this a few ways, either by giving the DNS name people
> point to multiple AAAA (and A) records pointing at a diverse
> set of instances.  DNS is designed to work around a host
> being down.  Same goes for MX and several other services.
>  While it may make the service slightly slower, it's certainly
> not the end of the world.

Hi Jared,

How DNS is designed to work and how it actually works is not the same.
Look up "DNS Pinning" for example. For most kinds of DR you need IP
level failover where the IP address is rerouted to the available site.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From completearch at gmail.com  Mon Feb 27 10:04:35 2012
From: completearch at gmail.com (Frank Ho)
Date: Tue, 28 Feb 2012 00:04:35 +0800
Subject: Provider WAAS service for multiple MPLS VPN customers, possible?
In-Reply-To: <CAJoqs+70DdgK3xHU58eN0p_Y1VETpB4Rdfri=yLLvCKwMbP=jg@mail.gmail.com>
References: <CAJoqs+70DdgK3xHU58eN0p_Y1VETpB4Rdfri=yLLvCKwMbP=jg@mail.gmail.com>
Message-ID: <CAJoqs+4EqqatCg4F6uRw1+vxWWnw-t0GusuZrxQBW8qPzFRqPg@mail.gmail.com>

Hi there,
     Just want to know if anybody out there has tried to put a pair of
Cisco WAAS cards on two PEs to optimize the traffic of multiple VRFs
between them ? Is that actually possible ? If it's possible, how does
the WAAS module card forward the optimized traffic back to the correct
VRF? Any hints or sample configurations are most?appreciated.


Frank.


From marshall.eubanks at gmail.com  Mon Feb 27 10:11:18 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Mon, 27 Feb 2012 11:11:18 -0500
Subject: BBC reports Kenya fiber break
Message-ID: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>

Is anyone seeing this ?

http://www.bbc.co.uk/news/world-africa-17179544

"East Africa's high-speed internet access has been severely disrupted
after a ship dropped its anchor onto fibre-optic cables off Kenya's
coast."

Regards
Marshall


From dmiller at tiggee.com  Mon Feb 27 10:37:08 2012
From: dmiller at tiggee.com (David Miller)
Date: Mon, 27 Feb 2012 11:37:08 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <A92EAF652EC423438D55C14C60771C870467E567@exchgsrv.nputilities.local>
References: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
 <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
 <CALKLF08NUXKgCi5k5EDxg7QH7S5bX+uRUFEGGV=ysS46JG15jQ@mail.gmail.com>
 <A92EAF652EC423438D55C14C60771C870467E567@exchgsrv.nputilities.local>
Message-ID: <4F4BB134.2020609@tiggee.com>

On 2/27/2012 10:25 AM, Jason Gurtz wrote:
>> [...]  For DNS,
>> EasyDNS (https://web.easydns.com/DNS_hosting.php) are rather good and
>> not too expensive, and you can get a 100% up-time guarantee if you
>> want.  A review of them regarding availability is at
>> http://www.theregister.co.uk/2012/01/31/why_i_use_easydns/
> I have been a very satisfied EasyDNS customer for about a decade and
> concur with the article. Nothing is perfect, but the rapid response and
> support I've received have always been top-notch.

I have been a satisfied DNS Made Easy customer for many years.

Note: I am also an employee of DNS Made Easy.  I was a customer for
years before I became an employee.


>
>> Do let us know who you end up picking and how it goes.
> Indeed. "Cloud" outside of references to mists and objects in the sky is a
> completely meaningless term for operators. In fact, it has made it harder
> to differentiate between services (which I'm sure is the point).
>
> As an operator (knowing how things can be subject to accelerated roll-out
> when $business feels they are missing out), I wonder if a lot of these
> "cloud" service bumps-in-the-road aren't just a symptom of not being fully
> baked in.

It depends on what you mean by "bumps-in-the-road"...

If you mean issues experienced by customers of cloud service providers,
then the most common issues are a symptom of not implementing redundancy
(anticipating failure) in their usage of the platform.  There are a
whole lot of folks who believe that they can buy an instance from Vendor
=~ /.*cloud.*/ and all of their DR worries will magically be "taken care
of" by the platform.  That isn't the case.

Amazon is usually pretty good at providing RFOs after issues.  All of
their RFOs (that I have seen) include pointers to all of the Amazon
redundancy configuration documents that customers who did experience an
issue regarding the RFO did not follow (which caused them to experience
an outage due to a platform issue).

DR in using cloud services is the same as DR has always been - look at
all potential failures and then implement redundancy where the
cost/benefit works out in favor of the redundancy.  Document, test,
rinse, lather, repeat.

Rightscale and other services like it provide tools to help.

-DMM



From graham at apolix.co.za  Mon Feb 27 10:46:25 2012
From: graham at apolix.co.za (Graham Beneke)
Date: Mon, 27 Feb 2012 18:46:25 +0200
Subject: BBC reports Kenya fiber break
In-Reply-To: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
Message-ID: <4F4BB361.4020101@apolix.co.za>

On 27/02/2012 18:11, Marshall Eubanks wrote:
> Is anyone seeing this ?
>
> http://www.bbc.co.uk/news/world-africa-17179544

Along with:
http://mybroadband.co.za/news/telecoms/44263-triple-whammy-hits-eassy.html

The east is struggling with outages.

-- 
Graham Beneke


From jared at puck.nether.net  Mon Feb 27 11:09:21 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 27 Feb 2012 12:09:21 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
Message-ID: <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>


On Feb 27, 2012, at 10:28 AM, William Herrin wrote:

> On Mon, Feb 27, 2012 at 9:39 AM, Jared Mauch <jared at puck.nether.net> wrote:
>> Is the DNS service authoritative or recursive?  If auth, you can
>> solve this a few ways, either by giving the DNS name people
>> point to multiple AAAA (and A) records pointing at a diverse
>> set of instances.  DNS is designed to work around a host
>> being down.  Same goes for MX and several other services.
>> While it may make the service slightly slower, it's certainly
>> not the end of the world.
> 
> Hi Jared,
> 
> How DNS is designed to work and how it actually works is not the same.
> Look up "DNS Pinning" for example. For most kinds of DR you need IP
> level failover where the IP address is rerouted to the available site.

If you want a system with 0 loss and 0 delay, start building your private network.

I'm never claimed your response would be perfect, but it will certainly work well enough to avoid major problems.  Or you can pay someone to do it for you.  I'm not sure what a DNS hosted solution costs, and I'm geeky and run my own DNS on beta/RC quality software as well ;).

What I do know is that my domain hasn't disappeared from the net wholesale as the name servers are "diverse-enough".

Is DNS performance important?  Sure.  Should everyone set their TTL to 30?  No.  Reaching a high percentage of the internet doesn't require such a high SLA.  Note, I didn't say reaching the top sites.  While super-old, http://www.zooknic.com/Domains/counts.html says > 111m named sites in a few gTLDs.  I'm sure there are better stats, but most of them don't need the same dns infrastructure that a google, bing, Facebook, etc require.

If your DNS fits on a VM in someone else's "cloud", you likely won't notice the difference.  A few extra NS records will likely do the right thing and go unnoticed.

- Jared

From rcarpen at network1.net  Mon Feb 27 11:36:00 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Mon, 27 Feb 2012 12:36:00 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <D7DF15F1-8609-4650-A3B0-0472AF02158D@puck.nether.net>
Message-ID: <4aa21105-a3e4-4ca1-a9d2-16902c2f8402@zimbra.network1.net>


> Pardon the weird question:
> 
> Is the DNS service authoritative or recursive?  If auth, you can
> solve this a few ways, either by giving the DNS name people point to
> multiple AAAA (and A) records pointing at a diverse set of
> instances.

Authoritative. But, also not the only thing that we are running that needs some geographic and route diversity.

> DNS is designed to work around a host being down.  Same
> goes for MX and several other services.  While it may make the
> service slightly slower, it's certainly not the end of the world.

Oh, how I wish this were true in practice. If I had a dollar for every time we had serious issues because one of a few authoritative DNS servers was not responding... OK, I wouldn't be rich, but this happens all the time. Caching servers out on the net get a "non-answer" because the server they chose to ask was down, and it caches that. They shouldn't do that, but they do, and there's nothing that can be done about it.

-Randy


From oliver at g.garraux.net  Mon Feb 27 11:47:31 2012
From: oliver at g.garraux.net (Oliver Garraux)
Date: Mon, 27 Feb 2012 12:47:31 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: <4F4BB361.4020101@apolix.co.za>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BB361.4020101@apolix.co.za>
Message-ID: <CAD_uLpNAkL-dgQVQkBd5LYHtrnqL80G-M=rGW8XpXdii-Jfd=Q@mail.gmail.com>

On Mon, Feb 27, 2012 at 11:46 AM, Graham Beneke <graham at apolix.co.za> wrote:
> On 27/02/2012 18:11, Marshall Eubanks wrote:
>>
>> Is anyone seeing this ?
>>
>> http://www.bbc.co.uk/news/world-africa-17179544
>
>
> Along with:
> http://mybroadband.co.za/news/telecoms/44263-triple-whammy-hits-eassy.html
>
> The east is struggling with outages.
>
> --
> Graham Beneke
>

Most of the ISP's in Malawi have been having issues since the 17th due
to a severed cable in the Red Sea.

Oliver


From virendra.rode at gmail.com  Mon Feb 27 12:20:10 2012
From: virendra.rode at gmail.com (virendra rode)
Date: Mon, 27 Feb 2012 10:20:10 -0800
Subject: BBC reports Kenya fiber break
In-Reply-To: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
Message-ID: <4F4BC95A.30307@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/27/2012 08:11 AM, Marshall Eubanks wrote:
> Is anyone seeing this ?
> 
> http://www.bbc.co.uk/news/world-africa-17179544
> 
> "East Africa's high-speed internet access has been severely disrupted
> after a ship dropped its anchor onto fibre-optic cables off Kenya's
> coast."
> 
> Regards
> Marshall
> 
- --------------------------
I don't have a direct feedback into this disruption but from what I
gather they were able to (manually) re-route traffic (alternative
submarine cable and /or satellite systems) whether its slow that's a
different story but having performance degradation, as opposed to
complete service outage is still workable, IMO. Hopefully diversity will
help minimize localized damages as the global economy (communications,
education, business, entertainment, banking & commerce) continues to be
dependent on undersea cables.

Typically the GPS navigation suite has undersea cables well documented.
I for one am interested to know how this was overlooked or maybe human
error?


regards,
/virendra


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk9LyVkACgkQ3HuimOHfh+FZggD/a+LIEBXANdItl2NGbaTCRQsh
+5/l0RvFRL3EMws8IsAA/jlV2gFGzCB1SM8pFAmKnK6sgS38tnxDFDj/4KqIUFky
=40jD
-----END PGP SIGNATURE-----


From esavage at digitalrage.org  Mon Feb 27 12:42:07 2012
From: esavage at digitalrage.org (Elijah Savage)
Date: Mon, 27 Feb 2012 13:42:07 -0500 (EST)
Subject: Provider WAAS service for multiple MPLS VPN customers, possible?
In-Reply-To: <CAJoqs+4EqqatCg4F6uRw1+vxWWnw-t0GusuZrxQBW8qPzFRqPg@mail.gmail.com>
Message-ID: <24077701.952.1330368127451.JavaMail.root@ubuntu.digitalrage.org>

I have never done it between MPLS like what you are referring to, but for the best optimization you will need edge WAE units on each end of the connection.

----- Original Message -----
From: "Frank Ho" <completearch at gmail.com>
To: nanog at nanog.org
Sent: Monday, February 27, 2012 11:04:35 AM
Subject: Re: Provider WAAS service for multiple MPLS VPN customers, possible?

Hi there,
     Just want to know if anybody out there has tried to put a pair of
Cisco WAAS cards on two PEs to optimize the traffic of multiple VRFs
between them ? Is that actually possible ? If it's possible, how does
the WAAS module card forward the optimized traffic back to the correct
VRF? Any hints or sample configurations are most?appreciated.


Frank.



From bill at herrin.us  Mon Feb 27 13:02:04 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 14:02:04 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
Message-ID: <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>

On Mon, Feb 27, 2012 at 12:09 PM, Jared Mauch <jared at puck.nether.net> wrote:
> On Feb 27, 2012, at 10:28 AM, William Herrin wrote:
>> How DNS is designed to work and how it actually works is not the same.
>> Look up "DNS Pinning" for example. For most kinds of DR you need IP
>> level failover where the IP address is rerouted to the available site.
>
> I'm never claimed your response would be perfect, but it will certainly work
> well enough to avoid major problems.

No, actually, it won't. In practice, most end user applications
disregard the DNS TTL.

In some cases this is because of carelessness: The application does a
gethostbyname once when it starts, grabs the first IP address in the
list and retains it indefinitely. The gethostbyname function doesn't
even pass the TTL to the application. Ntpd is/used to be one of the
notable offenders, continuing to poll the dead address for years after
the server moved.

In other cases disregarding the TTL was a deliberate design decision.
Web browser DNS Pinning is an example of this. All modern web browsers
implement a form of DNS Pinning where they refuse to try an alternate
IP address for a web server on subsequent TCP connections after making
the first successful contact. This plugs a javascript security leak
where a client side application could be made to scan the interior of
its user's firewall by switching the DNS back and forth between local
and remote addresses. In some cases this stuck-address behavior can
persist until the browser is completely closed and reopened, possibly
when the PC is rebooted weeks later.

The net result is that when you switch the IP address of your server,
a percentage of your users (declining over time) will be unable to
access it for hours, days, weeks or even years regardless of the DNS
TTL setting.

This isn't theoretical, by the way. I had to renumber a major web site
once. 1 hour TTL at the beginning of the process. Three month overlap
in which both addresses were online and the DNS pointed to the new
one. At the end of the three months a fraction of a percent of the
*real user traffic* was _still_ coming in the obsolete address. Using
the correct name in the Host: header, so the user wasn't deliberately
picking the IP address.

If you want DR that *works*, reroute the IP address.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From george.herbert at gmail.com  Mon Feb 27 13:19:27 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 27 Feb 2012 11:19:27 -0800
Subject: Reliable Cloud host ?
In-Reply-To: <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
Message-ID: <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>

On Mon, Feb 27, 2012 at 7:28 AM, William Herrin <bill at herrin.us> wrote:
> On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter <rcarpen at network1.net> wrote:
>>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
>>> > 1. Full redundancy with instant failover to other hypervisor hosts
>>> > upon hardware failure (I thought this was a given!)
>>>
>>> This is actually a much harder problem to solve than it sounds, and
>>> gets progressively harder depending on what you mean by "failover".
>>>
>>> At the very least, having two physical hosts capable of running your
>>> VM requires that your VM be stored on some kind of SAN (usually
>>> iSCSI based) storage system. Otherwise, two hosts have no way of
>>> accessing your VM's data if one were to die. This makes things an
>>> order of magnitude or higher more expensive.
>>
>> This does not have to be true at all. ?Even having a fully fault-tolerant
>> SAN in addition to spare servers should not cost much more than
>> having separate RAID arrays inside each of the server, when you
>> are talking about 1,000s of server (which Rackspace certainly has)
>
> Randy,
>
> You're kidding, right?
>
> SAN storage costs the better part of an order of magnitude more than
> server storage, which itself is several times more expensive than
> workstation storage. That's before you duplicate the SAN and set up
> the replication process so that cabinet and room level failures don't
> take you out.

This is clearly becoming a not-NANOG-ish thread, however...

Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
prefer) fails the smell test on a local enterprise-grade
virtualization cluster, much less a shared cloud service.

Some people have done tricks with distributing the data using one of
the research-ish shared filesystems, rather than separate shared
storage.  That can be made to work if the host OS model and its
available shared filesystems work for you.  Doesn't work for Vmware
Vcenter / Vmotion-ish stuff as far as I know.

There are plenty of people doing non-enterprise-grade virtualization.
There's no mandate that you have the ability to migrate a virtual to
another node in realtime or restart it immediately on another node if
the first node dies suddenly.  But anyone saying "we have a cloud" and
not providing that type of service, is in marketing not engineering.
>From a systems architecture point of view, you can't do that.


-- 
-george william herbert
george.herbert at gmail.com


From fredan-nanog at fredan.se  Mon Feb 27 13:36:57 2012
From: fredan-nanog at fredan.se (fredrik danerklint)
Date: Mon, 27 Feb 2012 20:36:57 +0100
Subject: do not filter your customers - part2
Message-ID: <4F4BDB59.7010801@fredan.se>

If we are gonna start to get somewhere with this issue, how about to 
make sure the routing/prefix databases is correct first?

Please see:
https://www.fredan.se/temp/prefixes.tar

In that file you will find 'not_allowed_to_announce6' which contains
about 2307 prefixes of ipv6 which is not in any routing/prefix databases 
OR the prefix that was submitted to it was wrong (probably the syntax of 
that prefix).

Which bring us to the next question.

Why on earth is it possible to submit a faulty prefix into a database 
today? Why is there (basically) no verification at all?
Please take a look at 'databases_to_prefixes.sh' see what's going on
(ok, some of the databases is probably for internal use only and we
need to filter that - but it is so much more that needs to be filtered).

Also in that file you will find 'prefixes4' and 'prefixes6' which 
contains all the prefixes after all the checking has been made (One 
prefix per line). These two files could be really useful for everybody 
in this community if someone (like the RIR:s) made those available to 
all of us, so we don't have to download all the databases, just the 
prefixes....

(And I know that AS52011 is announce to two prefixes which is not in the 
databases. Thank you very much).

-- 
//fredan


From Valdis.Kletnieks at vt.edu  Mon Feb 27 13:53:53 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Mon, 27 Feb 2012 14:53:53 -0500
Subject: Reliable Cloud host ?
In-Reply-To: Your message of "Mon, 27 Feb 2012 14:02:04 EST."
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
Message-ID: <42252.1330372433@turing-police.cc.vt.edu>

On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:

> The net result is that when you switch the IP address of your server,
> a percentage of your users (declining over time) will be unable to
> access it for hours, days, weeks or even years regardless of the DNS
> TTL setting.

Amen brother.

So just for grins, after seeing William's I set up a listener on an address
that had an NTP server on it many moons ago. As in the machine was shut down
around 2002/06/30 22:49 and we didn't re-assign the IP address ever since
*because* it kept getting hit with NTP packets..  Yes, a decade ago.

In the first 15 minutes, 234 different IP's have tried to NTP to that address.

And the winner for "most confused host", which in addition to trying to NTP also did this:

14:23:24.518136 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:23:57.395525 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:24:28.536351 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:24:53.382719 IP 74.254.73.90.500 > 128.173.14.71.123: isakmp:
14:25:01.391268 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:25:32.522313 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:26:05.399885 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:26:36.529713 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:27:09.405922 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:27:40.528381 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:28:13.393794 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:28:20.971269 IP 74.254.73.90.69 > 128.173.14.71.123:  48 tftp-#6914
14:28:37.907704 IP 74.254.73.90.161 > 128.173.14.71.123:  [id?P/x/27]
14:28:44.525585 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:29:17.399784 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:29:48.531804 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:30:21.398360 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:30:52.530148 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:31:25.403931 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:31:56.536594 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:32:29.404457 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)
14:33:00.534956 IP 74.254.73.90.68 > 128.173.14.71.123: BOOTP/DHCP, unknown (0xdb), length 48
14:33:33.402336 IP 74.254.73.90.53 > 128.173.14.71.123: 56064 [b2&3=0x6ee] [3494a] [0q] [307au] (48)

Somewhere in BellSouth territory, a machine desperately needs to be whacked upside the head.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120227/dd5b3f78/attachment.bin>

From ralph.brandt at pateam.com  Mon Feb 27 14:02:13 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Mon, 27 Feb 2012 15:02:13 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>

Generalists are hard to come by these days. They are people who learn
less and less about more and more till they know nothing about
everything. People today are specializing in the left and right halves
of the bytes....  They learn more and more about less and less till they
know everything about nothing.  And BTW, they are worthless unless you
have five of them working on a problem because none of them know enough
to fix it.  Worse, you can replace the word five with fifty and it may
be still true. 

I know of three of these, all gainfully employed at this time and could
each find at least a couple jobs if they wanted.  I am one, my son is
two and a guy we worked with is the third. 

At one time (40 years ago) the mantra in IS was train for expertise, now
it is hire for it.  Somewhere there has to be a happy medium.  I suggest
this, find a good coder, not a mediocre who writes shit code but a good
one who can think and learn and when you talk about branching out with
his skill set he or she lights up.  His first thing on site is take the
A+ networking course.  

No, I do not sell the courses.  But I have seen this kind of approach
work when nothing else was.




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

-----Original Message-----
From: A. Pishdadi [mailto:apishdadi at gmail.com] 
Sent: Sunday, February 26, 2012 8:27 PM
To: NANOG
Subject: Programmers with network engineering skills

Hello All,

i have been looking for quite some time now a descent coder (c,php) who
has
a descent amount of system admin / netadmin experience. Doesn't
necessarily
need to be an expert at network engineering but being acclimated in
understanding the basic fundamentals of networking. Understanding basic
routing concepts, how to diagnose using tcpdump / pcap, understanding
subnetting and how bgp works (not necessarily setting up bgp). I've
posted
job listings on the likes of dice and monster and have not found any
good
canidates, most of them ASP / Java guys.

If anyone can point me to a site they might recommend for job postings
or
know of any consulting firms that might provide these services that
would
be greatly appreciated.


From owen at delong.com  Mon Feb 27 14:22:19 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Feb 2012 12:22:19 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
Message-ID: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>

I think you're more likely to find a network engineer with (possibly limited)
programming skills.

That's certainly where I would categorize myself.

Owen

On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote:

> Generalists are hard to come by these days. They are people who learn
> less and less about more and more till they know nothing about
> everything. People today are specializing in the left and right halves
> of the bytes....  They learn more and more about less and less till they
> know everything about nothing.  And BTW, they are worthless unless you
> have five of them working on a problem because none of them know enough
> to fix it.  Worse, you can replace the word five with fifty and it may
> be still true. 
> 
> I know of three of these, all gainfully employed at this time and could
> each find at least a couple jobs if they wanted.  I am one, my son is
> two and a guy we worked with is the third. 
> 
> At one time (40 years ago) the mantra in IS was train for expertise, now
> it is hire for it.  Somewhere there has to be a happy medium.  I suggest
> this, find a good coder, not a mediocre who writes shit code but a good
> one who can think and learn and when you talk about branching out with
> his skill set he or she lights up.  His first thing on site is take the
> A+ networking course.  
> 
> No, I do not sell the courses.  But I have seen this kind of approach
> work when nothing else was.
> 
> 
> 
> 
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services
> Telephone +1 717.506.0802
> FAX +1 717.506.4358
> Email Ralph.Brandt at pateam.com
> 5095 Ritter Rd
> Mechanicsburg PA 17055
> 
> -----Original Message-----
> From: A. Pishdadi [mailto:apishdadi at gmail.com] 
> Sent: Sunday, February 26, 2012 8:27 PM
> To: NANOG
> Subject: Programmers with network engineering skills
> 
> Hello All,
> 
> i have been looking for quite some time now a descent coder (c,php) who
> has
> a descent amount of system admin / netadmin experience. Doesn't
> necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've
> posted
> job listings on the likes of dice and monster and have not found any
> good
> canidates, most of them ASP / Java guys.
> 
> If anyone can point me to a site they might recommend for job postings
> or
> know of any consulting firms that might provide these services that
> would
> be greatly appreciated.



From drais at icantclick.org  Mon Feb 27 14:31:55 2012
From: drais at icantclick.org (david raistrick)
Date: Mon, 27 Feb 2012 15:31:55 -0500 (EST)
Subject: Programmers with network engineering skills
In-Reply-To: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
Message-ID: <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>

On Mon, 27 Feb 2012, Owen DeLong wrote:

> I think you're more likely to find a network engineer with (possibly limited)
> programming skills.

While I'll agree about the more likely, if I needed a coder who had a firm 
grasp of networking I'd rather teach a good coder networking, than try to 
teach the art and magic of good development to a network guy.

I think it really comes down to which you need: a hardcore network 
engineer/architect who can hack up code, or a hardcore developer who has 
or can obtain enough of a grasp of networking fundementals and specifics 
to build you the software you need him to develop.

The ones who already know both ends extremely well are going to be -very- hard to find, but 
finding one who can learn enough of the other to accomplish what you need 
shouldn't be hard at all.

oh wait, that's an echo I hear isn't it.


...d (who is not exactly the former though I've played one for TV, and not 
at all the later)

--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From drais at icantclick.org  Mon Feb 27 14:43:18 2012
From: drais at icantclick.org (david raistrick)
Date: Mon, 27 Feb 2012 15:43:18 -0500 (EST)
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>

On Mon, 27 Feb 2012, William Herrin wrote:

> In some cases this is because of carelessness: The application does a
> gethostbyname once when it starts, grabs the first IP address in the
> list and retains it indefinitely. The gethostbyname function doesn't
> even pass the TTL to the application. Ntpd is/used to be one of the
> notable offenders, continuing to poll the dead address for years after
> the server moved.

While yes it often is carelessness - it's been reported by hardcore 
development sorts that I trust that there is no standardized API to obtain 
the TTL...  What needs to get fixed is get[hostbyname,addrinfo,etc] so 
programmers have better tools.



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html


From drais at icantclick.org  Mon Feb 27 14:42:07 2012
From: drais at icantclick.org (david raistrick)
Date: Mon, 27 Feb 2012 15:42:07 -0500 (EST)
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202271536580.425@murf.icantclick.org>

On Mon, 27 Feb 2012, William Herrin wrote:

> In some cases this is because of carelessness: The application does a
> gethostbyname once when it starts, grabs the first IP address in the
> list and retains it indefinitely. The gethostbyname function doesn't
> even pass the TTL to the application. Ntpd is/used to be one of the
> notable offenders, continuing to poll the dead address for years after
> the server moved.

While yes it often is carelessness - it's been reported by hardcore 
development sorts that I trust that there is no standardized API to obtain 
the TTL...  What needs to get fixed is get[hostbyname,addrinfo,etc] so 
programmers have better tools.



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html


From paul at paulgraydon.co.uk  Mon Feb 27 15:05:55 2012
From: paul at paulgraydon.co.uk (Paul Graydon)
Date: Mon, 27 Feb 2012 21:05:55 +0000
Subject: Reliable Cloud host ?
In-Reply-To: <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>
Message-ID: <20120227210555.GA3319@paulgraydon.co.uk>

On Mon, Feb 27, 2012 at 11:19:27AM -0800, George Herbert wrote:
> On Mon, Feb 27, 2012 at 7:28 AM, William Herrin <bill at herrin.us> wrote:
> > On Sun, Feb 26, 2012 at 7:02 PM, Randy Carpenter <rcarpen at network1.net> wrote:
> >>> On Feb 26, 2012, at 4:56 PM, Randy Carpenter wrote:
> >>> > 1. Full redundancy with instant failover to other hypervisor hosts
> >>> > upon hardware failure (I thought this was a given!)
> >>>
> >>> This is actually a much harder problem to solve than it sounds, and
> >>> gets progressively harder depending on what you mean by "failover".
> >>>
> >>> At the very least, having two physical hosts capable of running your
> >>> VM requires that your VM be stored on some kind of SAN (usually
> >>> iSCSI based) storage system. Otherwise, two hosts have no way of
> >>> accessing your VM's data if one were to die. This makes things an
> >>> order of magnitude or higher more expensive.
> >>
> >> This does not have to be true at all. ?Even having a fully fault-tolerant
> >> SAN in addition to spare servers should not cost much more than
> >> having separate RAID arrays inside each of the server, when you
> >> are talking about 1,000s of server (which Rackspace certainly has)
> >
> > Randy,
> >
> > You're kidding, right?
> >
> > SAN storage costs the better part of an order of magnitude more than
> > server storage, which itself is several times more expensive than
> > workstation storage. That's before you duplicate the SAN and set up
> > the replication process so that cabinet and room level failures don't
> > take you out.
> 
> This is clearly becoming a not-NANOG-ish thread, however...
> 
> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
> prefer) fails the smell test on a local enterprise-grade
> virtualization cluster, much less a shared cloud service.
> 
> Some people have done tricks with distributing the data using one of
> the research-ish shared filesystems, rather than separate shared
> storage.  That can be made to work if the host OS model and its
> available shared filesystems work for you.  Doesn't work for Vmware
> Vcenter / Vmotion-ish stuff as far as I know.
> 
> There are plenty of people doing non-enterprise-grade virtualization.
> There's no mandate that you have the ability to migrate a virtual to
> another node in realtime or restart it immediately on another node if
> the first node dies suddenly.  But anyone saying "we have a cloud" and
> not providing that type of service, is in marketing not engineering.
> From a systems architecture point of view, you can't do that.

Cloud is utterly meaningless drivel.
Your idea of cloud is different from mine, which is different from my co-workers, bosses, people in marketing etc. etc.
It's a vague useless term that could mean everything from a bog standard mail server through to full on 'deploy your app' things like Heroku.  It would be more accurate to focus on IaaS, PaaS, SaaS et al

For what little it's probably worth mentioning, Amazon provides a shared storage platform in the form of EBS, Elastic Block Storage, which you can choose to use as your root device on your server if you so wish
(wouldn't advise you do, latency is unpredictable), or you can have it mounted wherever is relevant for your data (the most common route). That's their non-physical server dependent storage provision.
If you pay extra it'll replicate, or even replicate between availability zones.  You can also choose to have Amazon monitor and ensure sufficient numbers of your server are running through autoscale.

Paul


From ralph.brandt at pateam.com  Mon Feb 27 15:40:40 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Mon, 27 Feb 2012 16:40:40 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F283@embgsr24.pateam.com>

Generalists are hard to come by these days. They are people who learn
less and less about more and more till they know nothing about
everything. People today are specializing in the left and right halves
of the bytes....  They learn more and more about less and less till they
know everything about nothing.  And BTW, they are worthless unless you
have five of them working on a problem because none of them know enough
to fix it.  Worse, you can replace the word five with fifty and it may
be still true. 

I know of three of these, all gainfully employed at this time and could
each find at least a couple jobs if they wanted.  I am one, my son is
two and a guy we worked with is the third. 

At one time (40 years ago) the mantra in IS was train for expertise, now
it is hire for it.  Somewhere there has to be a happy medium.  I suggest
this, find a good coder, not a mediocre who writes bad code but a good
one who can think and learn and when you talk about branching out with
his skill set he or she lights up.  His first thing on site is take the
A+ networking course.  

No, I do not sell the courses.  But I have seen this kind of approach
work when nothing else was.




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

-----Original Message-----
From: A. Pishdadi [mailto:apishdadi at gmail.com] 
Sent: Sunday, February 26, 2012 8:27 PM
To: NANOG
Subject: Programmers with network engineering skills

Hello All,

i have been looking for quite some time now a descent coder (c,php) who
has
a descent amount of system admin / netadmin experience. Doesn't
necessarily
need to be an expert at network engineering but being acclimated in
understanding the basic fundamentals of networking. Understanding basic
routing concepts, how to diagnose using tcpdump / pcap, understanding
subnetting and how bgp works (not necessarily setting up bgp). I've
posted
job listings on the likes of dice and monster and have not found any
good
canidates, most of them ASP / Java guys.

If anyone can point me to a site they might recommend for job postings
or
know of any consulting firms that might provide these services that
would
be greatly appreciated.


From owen at delong.com  Mon Feb 27 16:14:00 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Feb 2012 14:14:00 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
Message-ID: <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>


On Feb 27, 2012, at 12:31 PM, david raistrick wrote:

> On Mon, 27 Feb 2012, Owen DeLong wrote:
> 
>> I think you're more likely to find a network engineer with (possibly limited)
>> programming skills.
> 
> While I'll agree about the more likely, if I needed a coder who had a firm grasp of networking I'd rather teach a good coder networking, than try to teach the art and magic of good development to a network guy.
> 

Well, I won't call myself a hard-core coder, but, I think I have a reasonable grasp on the art and magic of good development. What I mostly lack is speed and efficiency in the language of choice for whatever project. I can write good code, it just takes me longer than it would take a hard-core coder.

OTOH, having done both, I would say that I think you are not necessarily correct about which direction of teaching is harder. Yes, if you start with a network engineer that knows nothing about writing code or doesn't understand the principles of good coding, you're probably right. However, starting with a network engineer that can write decent code slowly, I think you will get a better result in most cases than if you try to teach network engineering to a hard-core coder that has only a minimal understanding of networking.

> I think it really comes down to which you need: a hardcore network engineer/architect who can hack up code, or a hardcore developer who has or can obtain enough of a grasp of networking fundementals and specifics to build you the software you need him to develop.
> 

I'm guessing that someone who needed a hard-core developer that could grasp fundamentals would have grabbed an existing coder and handed him a copy of Comer.

The fact that this person posted to NANOG instead implies to me that he needs someone that has a better grasp than just the fundamentals.

Of course I am speculating about that and I could be wrong.

> The ones who already know both ends extremely well are going to be -very- hard to find, but finding one who can learn enough of the other to accomplish what you need shouldn't be hard at all.
> 

Depends on what you need. However, I think it's faster to go from limited coding skills with a good basis in the fundamentals to usable development than to go from limited networking skills to a firm grasp on how networks behave in the real world. To the best of my knowledge, nothing but experience will teach you the latter. Even with 20+ years experience networks do still occasionally manage to surprise me.

> ...d (who is not exactly the former though I've played one for TV, and not at all the later)

I am admittedly lost given the three choices as to which constitutes former or latter at this point.

1.	Strong coder with limited networking
2.	Strong networker with limited coding
3.	Strong in both

Owen
Who is a strong network engineer
Who has been a professional software engineer (though many years ago and my skills are rusty
	and out of date)



From jra at baylink.com  Mon Feb 27 16:23:06 2012
From: jra at baylink.com (Jay Ashworth)
Date: Mon, 27 Feb 2012 17:23:06 -0500 (EST)
Subject: Programmers with network engineering skills
In-Reply-To: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
Message-ID: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com>

----- Original Message -----
> From: "Owen DeLong" <owen at delong.com>

> I think you're more likely to find a network engineer with (possibly
> limited) programming skills.
> 
> That's certainly where I would categorize myself.

And you're the first I've seen suggest, or even imply, that going that
direction instead might be more fruitful; seemed to me that the skills
necessary to make a decent network engineer would support learning 
programming better than the other way round -- though in fact I personally
did it the other way.

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


From dougb at dougbarton.us  Mon Feb 27 16:31:13 2012
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 27 Feb 2012 14:31:13 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com>
References: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F4C0431.1010308@dougbarton.us>

On 2/27/2012 2:23 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Owen DeLong" <owen at delong.com>
> 
>> I think you're more likely to find a network engineer with (possibly
>> limited) programming skills.
>>
>> That's certainly where I would categorize myself.
> 
> And you're the first I've seen suggest, or even imply, that going that
> direction instead might be more fruitful; seemed to me that the skills
> necessary to make a decent network engineer would support learning 
> programming better than the other way round -- though in fact I personally
> did it the other way.

I think it depends on what level of "coding" you're talking about. If
you want someone that can whip up a few scripts to easily manage routine
tasks, then sure, network guy -> "coder" is usually a safe and easy path.

OTOH, if you're talking professional application developer working on a
project with more than one moving part, and/or more than one person on
the team, you really need someone who thinks like a developer, and can
be trained to understand network concepts.

.... and yes, the latter is the path that I've taken, so I have a
built-in bias.


Doug

-- 

	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/



From m.hallgren at free.fr  Mon Feb 27 16:33:27 2012
From: m.hallgren at free.fr (Michael Hallgren)
Date: Mon, 27 Feb 2012 23:33:27 +0100
Subject: Programmers with network engineering skills
In-Reply-To: <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
Message-ID: <1330382007.7324.6.camel@home>

Le lundi 27 f?vrier 2012 ? 14:14 -0800, Owen DeLong a ?crit :
> On Feb 27, 2012, at 12:31 PM, david raistrick wrote:
> 
> > On Mon, 27 Feb 2012, Owen DeLong wrote:
> > 
> >> I think you're more likely to find a network engineer with (possibly limited)
> >> programming skills.
> > 
> > While I'll agree about the more likely, if I needed a coder who had a firm grasp of networking I'd rather teach a good coder networking, than try to teach the art and magic of good development to a network guy.
> > 
> 
> Well, I won't call myself a hard-core coder, but, I think I have a reasonable grasp on the art and magic of good development. What I mostly lack is speed and efficiency in the language of choice for whatever project. I can write good code, it just takes me longer than it would take a hard-core coder.
> 
> OTOH, having done both, I would say that I think you are not necessarily correct about which direction of teaching is harder. Yes, if you start with a network engineer that knows nothing about writing code or doesn't understand the principles of good coding, you're probably right. However, starting with a network engineer that can write decent code slowly, I think you will get a better result in most cases than if you try to teach network engineering to a hard-core coder that has only a minimal understanding of networking.
> 
> > I think it really comes down to which you need: a hardcore network engineer/architect who can hack up code, or a hardcore developer who has or can obtain enough of a grasp of networking fundementals and specifics to build you the software you need him to develop.
> > 
> 
> I'm guessing that someone who needed a hard-core developer that could grasp fundamentals would have grabbed an existing coder and handed him a copy of Comer.
> 
> The fact that this person posted to NANOG instead implies to me that he needs someone that has a better grasp than just the fundamentals.
> 
> Of course I am speculating about that and I could be wrong.
> 
> > The ones who already know both ends extremely well are going to be -very- hard to find, but finding one who can learn enough of the other to accomplish what you need shouldn't be hard at all.
> > 
> 
> Depends on what you need. However, I think it's faster to go from limited coding skills with a good basis in the fundamentals to usable development than to go from limited networking skills to a firm grasp on how networks behave in the real world. To the best of my knowledge, nothing but experience will teach you the latter. Even with 20+ years experience networks do still occasionally manage to surprise me.
> 
> > ...d (who is not exactly the former though I've played one for TV, and not at all the later)
> 
> I am admittedly lost given the three choices as to which constitutes former or latter at this point.
> 
> 1.	Strong coder with limited networking
> 2.	Strong networker with limited coding
> 3.	Strong in both

It's all about KISS, to appreciate sound abstraction, in other words.

Cheers,
mh

> 
> Owen
> Who is a strong network engineer
> Who has been a professional software engineer (though many years ago and my skills are rusty
> 	and out of date)
> 
> 




From igevioya at gmail.com  Mon Feb 27 16:35:43 2012
From: igevioya at gmail.com (daniel.onwude)
Date: Mon, 27 Feb 2012 23:35:43 +0100
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
In-Reply-To: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
References: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
Message-ID: <9BECD6EB-9300-4B48-8F2C-2447321AF2D1@gmail.com>

Thanks,

Working on a similar design and now know what to avoid :)

Rgds
dan
On Feb 27, 2012, at 4:22 PM, David Swafford wrote:

> Hi Everyone!
> 
> I had several requests for more feedback on our FCoE experience, based on
> my comments from a thread last week, so I'm writing here with a bit more
> background on our project in hopes that it saves some pain for others :-).
> 
> I'm with a sizable health insurance provider in the mid-west, and we've
> typically focused on technology vs. headcount as an overal strategy.  Based
> on that, we upgrade much more often than some of our peers in the industry
> because techology is still cheaper than long-term staffing costs.
> 
> Last fall, we were faced with an issue of both power and rack capacity
> constraints in our primary datacenter, which is just three years old now.
> As various ideas were on the table, which included taking out a section of
> IT cubes to expand the DC, the most appealing idea was to consolidate our
> server and network infrastructure into what was coined our "High Density
> Row".
> 
> We transitioned from Cat6500s as access to a Nexus 5K deployment, using 5Ks
> as both distribution and access for the new HD row.  We didn't like how
> oversubscription is handled on 2K FEXs when it comes to 10G links, so for
> the situation here all 5Ks made the most sense.  Our capacity needs
> couldn't justify 7Ks and while they would have been cool to have, we didn't
> want to blow money just because.
> 
> Our SAN is an EMC Symmetrix with Cisco MDS switches in between it and the
> hosts (Fiber Channel).  In the new row, we deployed all hosts with CNAs
> (converged net adapters), which combine both FCoE storage and network in a
> single 10Gb connection.  Since FCoE was new to all of us, we use a phased
> approach that the Nexus offered where we brough straight fiber channel
> connections into our distibution layer 5Ks and used the Nexus' FCoE proxy
> functionality to convert between true FC to FCoE.
> 
> From the host perpsective, it was only aware of FCoE connectivity to the
> Nexus.  VSANs had to be created on the Nexus to map back to the FC VSANs on
> the MDS side, Virtual Fiber Channel (VFC) interfaces were created on the
> Nexus side, and a few other settings had to be configured.
> 
> Overall though, the config wasn't huge, but the biggest hurdle for was that
> as the network guys, we had to learn the storage side to be able to
> properly set this up.  So new terms like WWN (world wide name), floggy
> database, VSAN (a VLAN for storage), etc.  Also, on the Nexus side, you
> have to enable the feature of FCOE, as Nexus OS is very modulular and
> leaves most options disabled during the initial setup.
> 
> The painful part, which is probably what might be of most interest here, is
> that we hit a very strange and catrastrophic issue specific to QLogic's
> 8242 Copper-based (twinax) CNA adapter.  As part of the burn-in testing, we
> were working with our server team to simulate the loss of a
> link/card/switch (all hosts were dual-connected with dual-CNAs to separate
> 5Ks).  We were using the Cisco branded twinax cabling and QLogic's 8242
> card (brand new HP DL580s in this case, new card, new 5K, new cabling).
> When a single link was dropped/diconnected PHYSICALLY (a shut/no shut is
> not the same here), the host's throughput on BOTH storage and network went
> to crap.
> 
> Our baseline was showing nearly 400MB/s on storage (raw disk IO) tests
> prior to a link drop and  1-8 MB/s after!  This siutation would not recover
> until you fully rebooted/power cycled the server.  We had the same results
> accross every HP DL 580 tested, which was 5-6 of them I belive.  We
> replaced CNAs, cables, and even moved ports across 5Ks.  It didn't matter
> which cable, 5K, port, of card we used, all reacted the same!  The hosts
> were all Windows 2008 Datacenter, simliar hardware, Nexus 5K on current
> code, twinax cabling.
> 
> This situation led to a sev 2 w/ Cisco, the equivalant w/ HP, EMC, and
> QLogic.  We used both the straight QLogic 8242 and the HP OEM'd version and
> the results were identical.  QLogic acknowledged the issue but could not
> resolve it due not being able to grab a hardware level trace of the
> connection (required some type of test equipment that they couldn't provide
> and we didn't have).
> 
> As part of our trail/error testing, we had our re-seller ship us the fiber
> versions of the same QLogic cards, becuase we eventually got down to a gut
> instinct of this being a copper/electrical anomoly.  That instict was
> dead-on.  Switching to the fiber versions, with fiber SFPs on the 5K side
> resolved the situation entirely.  We are now able to drop a link with NO
> noticable degradation, back and forth, and eveyrthing is consistent again.
> 
> We originally went the twinax route because it was signifiantly cheaper
> than the fiber, but in retrospect, as a whole, the danger posed was not
> worth it.  You might ask, well... why would you intentially drop the
> cable?  Think about a situation of doing a code upgrade on the 5K, since
> it's not a dual-sup box, you physcailly go through a reboot to upgrade it.
> That reboot right htere would have hosed our entire environment (keep in
> mind, the HD row's intent was to replace a signifiant portion of our
> production environment).  You could also have a HW failure on a 5K.  It
> kind of defeats the point of all this redundancy if your throuhput goes to
> hell when loosing a single path.  As our storage guys best put it "i'd
> rather loose a path than have bad performance through it....based on how
> things alert, I'd know right away if a path were down, but not if it were
> severaly degraded."
> 
> Btw, we've been rock solid on the fiber-connected CNAs ever since.  We're
> still using copper on our connections to HP blade chassis though, which go
> to FLEX Fabric cards, as we couldn't produce the problem on those.  For
> those wondering, we did rebuild several of the DL580s from scratch (all of
> this was a new deployment, thankfully!), we also went through many
> iterations of driver updates/changes/etc.
> 
> Lots of head-banging and teamwork eventually got us squared away!  This
> situation is a good example of why network guys NEED to have a great
> relationship with both server and storage guys (we're all really close
> where I'm at).  Had there been tension/etc between the teams, this would
> have been signifiantky harder to resolve.
> 
> Hope this helps, sorry for the long winded email :-), but I think those
> interested will find it beneficial.
> 
> 
> David.



From dougb at dougbarton.us  Mon Feb 27 16:37:12 2012
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 27 Feb 2012 14:37:12 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <4F4C0431.1010308@dougbarton.us>
References: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com>
 <4F4C0431.1010308@dougbarton.us>
Message-ID: <4F4C0598.5060708@dougbarton.us>

On 2/27/2012 2:31 PM, Doug Barton wrote:
> then sure, network guy -> "coder" is usually a safe and easy path.

Sorry, looking at this again it reads a lot more derogatory on paper
than I meant it to. There is a lot of value in being able to automate
repetitive tasks ... my point was simply that doing that is a different
development model than working on a larger scale project; where scope,
structure, etc. come into play.


Doug (who either needs more caffeine, or less ...)

-- 

	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/



From rodrick.brown at gmail.com  Mon Feb 27 17:12:48 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Mon, 27 Feb 2012 18:12:48 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <F9CFD32E-E4F4-4AF4-A479-06256109D894@gmail.com>

On Feb 26, 2012, at 8:27 PM, "A. Pishdadi" <apishdadi at gmail.com> wrote:

> Hello All,
> 
> i have been looking for quite some time now a descent coder (c,php) who has
> a descent amount of system admin / netadmin experience. Doesn't necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've posted
> job listings on the likes of dice and monster and have not found any good
> canidates, most of them ASP / Java guys.
> 
> If anyone can point me to a site they might recommend for job postings or
> know of any consulting firms that might provide these services that would
> be greatly appreciated.

Good Luck guys like these are being scooped up by large financial firms and hedgefunds and they don't come cheap  ~$250k easy! 

From bill at herrin.us  Mon Feb 27 17:45:58 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 18:45:58 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>
Message-ID: <CAP-guGWWe7+HqOPDoKBXbMA57yPmZaf0SkPo58VObC49qtDCuA@mail.gmail.com>

On Mon, Feb 27, 2012 at 2:19 PM, George Herbert
<george.herbert at gmail.com> wrote:
> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
> prefer) fails the smell test on a local enterprise-grade
> virtualization cluster, much less a shared cloud service.

Hi George,

Why would you imagine that a $30/month virtual private server is built
on an enterprise-grade virtualization cluster? You know what it costs
to builds fibre channel SANs and blade servers and DR. In what
universe does $30/mo per customer recover that cost during the useful
life of the equipment?

A VPS is 2012's version of 2002's web server + CGI and a unix shell.
Quite useful but don't expect magic from it.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Mon Feb 27 17:50:27 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 18:50:27 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
Message-ID: <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>

On Mon, Feb 27, 2012 at 3:43 PM, david raistrick <drais at icantclick.org> wrote:
> On Mon, 27 Feb 2012, William Herrin wrote:
>> In some cases this is because of carelessness: The application does a
>> gethostbyname once when it starts, grabs the first IP address in the
>> list and retains it indefinitely. The gethostbyname function doesn't
>> even pass the TTL to the application. Ntpd is/used to be one of the
>> notable offenders, continuing to poll the dead address for years after
>> the server moved.
>
> While yes it often is carelessness - it's been reported by hardcore
> development sorts that I trust that there is no standardized API to obtain
> the TTL... ?What needs to get fixed is get[hostbyname,addrinfo,etc] so
> programmers have better tools.

Meh. What should be fixed is that connect() should receive a name
instead of an IP address. Having an application deal directly with the
IP address should be the exception rather than the rule. Then, deal
with the TTL issues once in the standard libraries instead of
repeatedly in every single application.

In theory, that'd even make the app code protocol agnostic so that it
doesn't have to be rewritten yet again for IPv12.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From owen at delong.com  Mon Feb 27 18:07:26 2012
From: owen at delong.com (Owen DeLong)
Date: Mon, 27 Feb 2012 16:07:26 -0800
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
Message-ID: <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>


On Feb 27, 2012, at 3:50 PM, William Herrin wrote:

> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick <drais at icantclick.org> wrote:
>> On Mon, 27 Feb 2012, William Herrin wrote:
>>> In some cases this is because of carelessness: The application does a
>>> gethostbyname once when it starts, grabs the first IP address in the
>>> list and retains it indefinitely. The gethostbyname function doesn't
>>> even pass the TTL to the application. Ntpd is/used to be one of the
>>> notable offenders, continuing to poll the dead address for years after
>>> the server moved.
>> 
>> While yes it often is carelessness - it's been reported by hardcore
>> development sorts that I trust that there is no standardized API to obtain
>> the TTL...  What needs to get fixed is get[hostbyname,addrinfo,etc] so
>> programmers have better tools.
> 
> Meh. What should be fixed is that connect() should receive a name
> instead of an IP address. Having an application deal directly with the
> IP address should be the exception rather than the rule. Then, deal
> with the TTL issues once in the standard libraries instead of
> repeatedly in every single application.
> 
> In theory, that'd even make the app code protocol agnostic so that it
> doesn't have to be rewritten yet again for IPv12.
> 

While I agree with the principle of what you are trying to say, I would argue
that it should be dealt with in getnameinfo() / getaddrinfo() and not connect().

It is perfectly reasonable for connect() to deal with an address structure.

If people are not using getnameinfo()/getaddrinfo() from the standard libraries,
then, I don't see any reason to believe that they would use connect() from the
standard libraries if it incorporated their functionality.

Owen



From chris at nmedia.net  Mon Feb 27 18:50:15 2012
From: chris at nmedia.net (Chris Cappuccio)
Date: Mon, 27 Feb 2012 16:50:15 -0800
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
In-Reply-To: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
References: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
Message-ID: <20120228005014.GA20175@ref.nmedia.net>

David Swafford [david at davidswafford.com] wrote:
> 
> Lots of head-banging and teamwork eventually got us squared away!  This
> situation is a good example of why network guys NEED to have a great
> relationship with both server and storage guys (we're all really close
> where I'm at).  Had there been tension/etc between the teams, this would
> have been signifiantky harder to resolve.

I don't know how this points to the NEED to have a great relationship with your vendor. Your vendors all failed to figure anything out. Obviously you need smart guys on staff to work-around problems...


From bill at herrin.us  Mon Feb 27 18:53:07 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 19:53:07 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
Message-ID: <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>

On Mon, Feb 27, 2012 at 3:22 PM, Owen DeLong <owen at delong.com> wrote:
> On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote:
>> Generalists are hard to come by these days.
>
> I think you're more likely to find a network engineer with (possibly limited)
> programming skills.

I wish. For the past three months I've been trying to find a network
engineer with a deep TCP/IP protocol understanding, network security
expertise, some Linux experience, minor programming skill with sockets
and a TS/SCI clearance.

The clearance is killing me. The two generalists didn't have a
clearance and the cleared applicants are programmers or admins but
never both.


On Mon, Feb 27, 2012 at 6:12 PM, Rodrick Brown <rodrick.brown at gmail.com> wrote:
> Good Luck guys like these are being scooped up by large financial
> firms and hedgefunds and they don't come cheap  ~$250k easy!

Not all of them. I've been approached a few times but there is
something sleazy about helping a bunch of tycoons do millisecond
timing attacks against the market. The money doesn't magically appear.
Every dollar they squeeze out that way is stolen from some grandmother
who has held the stock for 20 years.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bill at herrin.us  Mon Feb 27 18:59:28 2012
From: bill at herrin.us (William Herrin)
Date: Mon, 27 Feb 2012 19:59:28 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
Message-ID: <CAP-guGW3W2zqnS7EznZfOwPjo2dX+TNNVcjjarRO_5x2LvOpWw@mail.gmail.com>

On Mon, Feb 27, 2012 at 7:07 PM, Owen DeLong <owen at delong.com> wrote:
> On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
>> Meh. What should be fixed is that connect() should receive a name
>> instead of an IP address. Having an application deal directly with the
>> IP address should be the exception rather than the rule. Then, deal
>> with the TTL issues once in the standard libraries instead of
>> repeatedly in every single application.
>>
>> In theory, that'd even make the app code protocol agnostic so that it
>> doesn't have to be rewritten yet again for IPv12.
>
> While I agree with the principle of what you are trying to say, I would argue
> that it should be dealt with in getnameinfo() / getaddrinfo() and not connect().
>
> It is perfectly reasonable for connect() to deal with an address structure.

Yes, well, that's why we're still using a layer 4 protocol (TCP) that
can't dynamically rebind to the protocol level below (IP). God help us
when folks start overriding the ethernet MAC address to force machines
to keep the same IPv6 address that's been hardcoded somewhere or is
otherwise too much trouble to change.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From george.herbert at gmail.com  Mon Feb 27 19:03:28 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 27 Feb 2012 17:03:28 -0800
Subject: Reliable Cloud host ?
In-Reply-To: <CAP-guGWWe7+HqOPDoKBXbMA57yPmZaf0SkPo58VObC49qtDCuA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <CAK__KzuH0+K8z4n5kyDU+A-vy5ksSY-EY2=T11Nc75tjtFmOcQ@mail.gmail.com>
 <CAP-guGWWe7+HqOPDoKBXbMA57yPmZaf0SkPo58VObC49qtDCuA@mail.gmail.com>
Message-ID: <CAK__Kzv+YT+u0e9O7LN+2hsSarsiWGBBEVqRJVzUysLU65xsEw@mail.gmail.com>

On Mon, Feb 27, 2012 at 3:45 PM, William Herrin <bill at herrin.us> wrote:
> On Mon, Feb 27, 2012 at 2:19 PM, George Herbert
> <george.herbert at gmail.com> wrote:
>> Failing to have central shared storage (iSCSI, NAS, SAN, whatever you
>> prefer) fails the smell test on a local enterprise-grade
>> virtualization cluster, much less a shared cloud service.
>
> Hi George,
>
> Why would you imagine that a $30/month virtual private server is built
> on an enterprise-grade virtualization cluster? You know what it costs
> to builds fibre channel SANs and blade servers and DR. In what
> universe does $30/mo per customer recover that cost during the useful
> life of the equipment?

As I stated, one can either do it with SANs or with alternate storage.
 Amazon hit those price points with a custom distributed filesystem
that's more akin to the research distributed filesystems than anything
else.  It's using node storage, but not single-node locked; if the
physical dies it should not lose the data.

Amazon wrote that filesystem, but one could approach the problem with
an OTS research / labs distributed FS using blade or 1U internal disks
and duplicate what they did.

In the "enterprise" space, there's a lot more variety and flexibility
too.  I bought a 100 TB (raw) NAS / storage unit for well under $30k
not that long ago.  Even accounting for RAID6 and duplicate units on
the network (network RAID1 across two units doing RAID6 internally),
that would cover something like 250 "standard" AWS instances, or about
$100/unit for the storage.  At typical useful amortization (24 to 48
months) that's about $2 to $4/month/server.

That's not an EMC, a Hitachi, a BlueArc, a NetApp, a Compellant, even
a Nexsan.  But one can walk up the curve relatively smoothly from that
low end point to the bestest brightest highest-tier stuff depending on
one's customers' needs.

> A VPS is 2012's version of 2002's web server + CGI and a unix shell.
> Quite useful but don't expect magic from it.

There are plenty of services that know what they should do and do it
reasonably well.  AWS, above.

There are also a lot of services that (without naming names) are
floating out there in sketchy-land.

One should both know better and expect better.  It's possible to
design reliable services - with geographical redundancy and the like
between service providers, in case one corks - out of unreliable
services.  One should do some of that anyways, with clouds.  But the
quality of the underlying service varies a lot.  If you're paying AWS
prices for non-replicated storage, think carefully about what you're
doing.  If you're paying half of what AWS costs, and duplicating
locations to handle outages, then you're probably ok.  If you're
paying more and getting better service, ok.


-- 
-george william herbert
george.herbert at gmail.com


From rodrick.brown at gmail.com  Mon Feb 27 19:04:04 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Mon, 27 Feb 2012 20:04:04 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
Message-ID: <9AB28C80-99A4-4C98-A6CB-C0E73B7CEF68@gmail.com>


On Feb 27, 2012, at 7:53 PM, William Herrin <bill at herrin.us> wrote:

> On Mon, Feb 27, 2012 at 3:22 PM, Owen DeLong <owen at delong.com> wrote:
>> On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote:
>>> Generalists are hard to come by these days.
>> 
>> I think you're more likely to find a network engineer with (possibly limited)
>> programming skills.
> 
> I wish. For the past three months I've been trying to find a network
> engineer with a deep TCP/IP protocol understanding, network security
> expertise, some Linux experience, minor programming skill with sockets
> and a TS/SCI clearance.
> 
> The clearance is killing me. The two generalists didn't have a
> clearance and the cleared applicants are programmers or admins but
> never both.
> 
> 
> On Mon, Feb 27, 2012 at 6:12 PM, Rodrick Brown <rodrick.brown at gmail.com> wrote:
>> Good Luck guys like these are being scooped up by large financial
>> firms and hedgefunds and they don't come cheap  ~$250k easy!
> 
> Not all of them. I've been approached a few times but there is
> something sleazy about helping a bunch of tycoons do millisecond
> timing attacks against the market. The money doesn't magically appear.
> Every dollar they squeeze out that way is stolen from some grandmother
> who has held the stock for 20 years.
> 

Try explaining the number of ex-Bell Lab R&D folks working on trading desks these days. A major financial firm I worked for in the past directly targeted candidates from the telecom industry. In recent news a russian programmer who allegedly stole Goldman Sachs proprietary code was making $400k/year and he's probably still on the market looking for work :-) 

> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004


From jason at i6ix.com  Mon Feb 27 19:07:14 2012
From: jason at i6ix.com (Jason Bertoch)
Date: Mon, 27 Feb 2012 20:07:14 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
Message-ID: <4F4C28C2.9000706@i6ix.com>

On 2/27/2012 7:53 PM, William Herrin wrote:
>> I think you're more likely to find a network engineer with (possibly limited)
>> >  programming skills.
> I wish. For the past three months I've been trying to find a network
> engineer with a deep TCP/IP protocol understanding, network security
> expertise, some Linux experience, minor programming skill with sockets
> and a TS/SCI clearance.

Is clearance the problem, or the ability to obtain clearance due to 
something in their background?  If your work requires it, you should 
have some recourse for applicants to obtain the required clearance, no?

/Jason


From george.herbert at gmail.com  Mon Feb 27 19:12:13 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 27 Feb 2012 17:12:13 -0800
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGW3W2zqnS7EznZfOwPjo2dX+TNNVcjjarRO_5x2LvOpWw@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <CAP-guGW3W2zqnS7EznZfOwPjo2dX+TNNVcjjarRO_5x2LvOpWw@mail.gmail.com>
Message-ID: <CAK__KzsbDvnKEHvT-=y3SCaLEfQGX_BaohXHYBxq5TvOfRN1_Q@mail.gmail.com>

On Mon, Feb 27, 2012 at 4:59 PM, William Herrin <bill at herrin.us> wrote:
> ....
> Yes, well, that's why we're still using a layer 4 protocol (TCP) that
> can't dynamically rebind to the protocol level below (IP).

This is somewhat irritating, but on the scale of 0 (all is well) to 10
(you want me to do WHAT with DHCPv6???)  this is about a 2.

The application can re-connect from the TCP layer if something wiggy
happens to the layer below.  This is an application layer solution, is
well established, and works fine.  One just has to notice something's
amiss and retry connection rather than abort the application.

> God help us
> when folks start overriding the ethernet MAC address to force machines
> to keep the same IPv6 address that's been hardcoded somewhere or is
> otherwise too much trouble to change.

It could be worse.  Back in the day I worked for a company that did
one of the earlier two-on-motherboard ethernet chip servers.  The Boot
PROM (from another vendor) had no clue about multiple ethernet
interfaces.  It came up with both interfaces set to the same NVRAM-set
MAC.  We wanted to fix it in firmware but kept having issues with
that.

I had to get an init script to rotate the MAC for the second interface
up one, and ensure that it was in the OS and run before the interfaces
got plumbed, get it bundled into the OS distribution, and ensure that
factory MACs were only set to even numbers to start with.

One of these steps ultimately failed rather spectacularly.



-- 
-george william herbert
george.herbert at gmail.com


From george.herbert at gmail.com  Mon Feb 27 19:15:10 2012
From: george.herbert at gmail.com (George Herbert)
Date: Mon, 27 Feb 2012 17:15:10 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <4F4C28C2.9000706@i6ix.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
 <4F4C28C2.9000706@i6ix.com>
Message-ID: <CAK__KzvRe+6G3t74sjD7n=nOCLjjyXKRvEM3QA+O8ZRwWqxEhw@mail.gmail.com>

On Mon, Feb 27, 2012 at 5:07 PM, Jason Bertoch <jason at i6ix.com> wrote:
> On 2/27/2012 7:53 PM, William Herrin wrote:
>>>
>>> I think you're more likely to find a network engineer with (possibly
>>> limited)
>>> > ?programming skills.
>>
>> I wish. For the past three months I've been trying to find a network
>> engineer with a deep TCP/IP protocol understanding, network security
>> expertise, some Linux experience, minor programming skill with sockets
>> and a TS/SCI clearance.
>
>
> Is clearance the problem, or the ability to obtain clearance due to
> something in their background? ?If your work requires it, you should have
> some recourse for applicants to obtain the required clearance, no?

My understanding is that while primary and subcontractor companies can
put people in the sponsoring organization's clearance granting queue,
it takes so long to get someone through the queue that for high-level
positions they essentially make having the clearance already a
prerequisite.


-- 
-george william herbert
george.herbert at gmail.com


From jnewell at equinix.com  Mon Feb 27 19:24:54 2012
From: jnewell at equinix.com (Jared Newell)
Date: Mon, 27 Feb 2012 17:24:54 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <4F4C0431.1010308@dougbarton.us>
References: <6088002.1109.1330381386271.JavaMail.root@benjamin.baylink.com>
 <4F4C0431.1010308@dougbarton.us>
Message-ID: <22089644C8B3E843B2CA338CFEA9E4DF010ABF0FB1@sv2exmb01.us.win.equinix.com>

Doug,

I think the difference is that network engineers typically find themselves wanting to learn some form of programming to automate routine tasks while doing their job as a network engineer.  They've actually managed to be interested in programming while pursuing a career in networking out of necessity.

On the other hand, I think it's very rare for a hard-core programmer/developer to want to learn more about networking because it typically doesn't come up in their job when coding a professional application / large product with many moving parts and "more than one person on the team".

I'm sure it can happen either way and has (as many people have posted going either direction in this thread), but there needs to be some desire to learn for the individual.  I think you'll find a network engineer desiring to improve their programming skills much easier than a developer that wants to learn improve their networking skills beyond plugging a router into their home network.

-Jared


-----Original Message-----
From: Doug Barton [mailto:dougb at dougbarton.us] 
Sent: Monday, February 27, 2012 2:31 PM
To: Jay Ashworth
Cc: NANOG
Subject: Re: Programmers with network engineering skills

On 2/27/2012 2:23 PM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Owen DeLong" <owen at delong.com>
> 
>> I think you're more likely to find a network engineer with (possibly
>> limited) programming skills.
>>
>> That's certainly where I would categorize myself.
> 
> And you're the first I've seen suggest, or even imply, that going that 
> direction instead might be more fruitful; seemed to me that the skills 
> necessary to make a decent network engineer would support learning 
> programming better than the other way round -- though in fact I 
> personally did it the other way.

I think it depends on what level of "coding" you're talking about. If you want someone that can whip up a few scripts to easily manage routine tasks, then sure, network guy -> "coder" is usually a safe and easy path.

OTOH, if you're talking professional application developer working on a project with more than one moving part, and/or more than one person on the team, you really need someone who thinks like a developer, and can be trained to understand network concepts.

.... and yes, the latter is the path that I've taken, so I have a built-in bias.


Doug

-- 

	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/




From surfer at mauigateway.com  Mon Feb 27 19:34:33 2012
From: surfer at mauigateway.com (Scott Weeks)
Date: Mon, 27 Feb 2012 17:34:33 -0800
Subject: Programmers with network engineering skills
Message-ID: <20120227173433.A885A8BA@m0005309.ppops.net>



--- george.herbert at gmail.com wrote:
From: George Herbert <george.herbert at gmail.com>

My understanding is that while primary and subcontractor companies can
put people in the sponsoring organization's clearance granting queue,
it takes so long to get someone through the queue that for high-level
positions they essentially make having the clearance already a
prerequisite.
--------------------------------------


For TS maybe, but the Secret wasn't so bad.  Also, it depends on how old 
you are.  The younger you are the less they have to check.

scott


From guxiaojian at gmail.com  Mon Feb 27 19:38:48 2012
From: guxiaojian at gmail.com (Jian Gu)
Date: Mon, 27 Feb 2012 17:38:48 -0800
Subject: Provider WAAS service for multiple MPLS VPN customers, possible?
In-Reply-To: <CAJoqs+4EqqatCg4F6uRw1+vxWWnw-t0GusuZrxQBW8qPzFRqPg@mail.gmail.com>
References: <CAJoqs+70DdgK3xHU58eN0p_Y1VETpB4Rdfri=yLLvCKwMbP=jg@mail.gmail.com>
 <CAJoqs+4EqqatCg4F6uRw1+vxWWnw-t0GusuZrxQBW8qPzFRqPg@mail.gmail.com>
Message-ID: <CAAxc0wUo+tmC+hrDPS-Vs9Oc_4uLDC7By3GAwJeK+s-TNLs16g@mail.gmail.com>

Theoretically if both WAEs are placed inline on MPLS uplink, then it
should work -- unless WAAS code can only recognize IP/Ethernet but not
IP/MPLS/Ethernet traffic. I don't think WAAS is VRF aware and can
maintain a multi-VRF routing table.

On Mon, Feb 27, 2012 at 8:04 AM, Frank Ho <completearch at gmail.com> wrote:
> Hi there,
> ? ? Just want to know if anybody out there has tried to put a pair of
> Cisco WAAS cards on two PEs to optimize the traffic of multiple VRFs
> between them ? Is that actually possible ? If it's possible, how does
> the WAAS module card forward the optimized traffic back to the correct
> VRF? Any hints or sample configurations are most?appreciated.
>
>
> Frank.
>


From dholmes at mwdh2o.com  Mon Feb 27 19:46:26 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Mon, 27 Feb 2012 17:46:26 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
Message-ID: <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>

What about the case of the strong coder who decides that networking is more interesting as a life's work, moves into networking, will not consider employment where coding is even a remote possibility, and will successfully land another networking job elsewhere if management even brings up the subject of coding? I think this describes the great majority of networking professionals.

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com]
Sent: Monday, February 27, 2012 2:14 PM
To: david raistrick
Cc: NANOG
Subject: Re: Programmers with network engineering skills


On Feb 27, 2012, at 12:31 PM, david raistrick wrote:

> On Mon, 27 Feb 2012, Owen DeLong wrote:
>
>> I think you're more likely to find a network engineer with (possibly limited)
>> programming skills.
>
> While I'll agree about the more likely, if I needed a coder who had a firm grasp of networking I'd rather teach a good coder networking, than try to teach the art and magic of good development to a network guy.
>

Well, I won't call myself a hard-core coder, but, I think I have a reasonable grasp on the art and magic of good development. What I mostly lack is speed and efficiency in the language of choice for whatever project. I can write good code, it just takes me longer than it would take a hard-core coder.

OTOH, having done both, I would say that I think you are not necessarily correct about which direction of teaching is harder. Yes, if you start with a network engineer that knows nothing about writing code or doesn't understand the principles of good coding, you're probably right. However, starting with a network engineer that can write decent code slowly, I think you will get a better result in most cases than if you try to teach network engineering to a hard-core coder that has only a minimal understanding of networking.

> I think it really comes down to which you need: a hardcore network engineer/architect who can hack up code, or a hardcore developer who has or can obtain enough of a grasp of networking fundementals and specifics to build you the software you need him to develop.
>

I'm guessing that someone who needed a hard-core developer that could grasp fundamentals would have grabbed an existing coder and handed him a copy of Comer.

The fact that this person posted to NANOG instead implies to me that he needs someone that has a better grasp than just the fundamentals.

Of course I am speculating about that and I could be wrong.

> The ones who already know both ends extremely well are going to be -very- hard to find, but finding one who can learn enough of the other to accomplish what you need shouldn't be hard at all.
>

Depends on what you need. However, I think it's faster to go from limited coding skills with a good basis in the fundamentals to usable development than to go from limited networking skills to a firm grasp on how networks behave in the real world. To the best of my knowledge, nothing but experience will teach you the latter. Even with 20+ years experience networks do still occasionally manage to surprise me.

> ...d (who is not exactly the former though I've played one for TV, and not at all the later)

I am admittedly lost given the three choices as to which constitutes former or latter at this point.

1.      Strong coder with limited networking
2.      Strong networker with limited coding
3.      Strong in both

Owen
Who is a strong network engineer
Who has been a professional software engineer (though many years ago and my skills are rusty
        and out of date)



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.


From marka at isc.org  Mon Feb 27 19:47:43 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 28 Feb 2012 12:47:43 +1100
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: Your message of "Mon, 27 Feb 2012 18:50:27 CDT."
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
Message-ID: <20120228014743.AF0B01DDD2A1@drugs.dv.isc.org>


In message <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA at mail.gmail.com>,
 William Herrin writes:
> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick <drais at icantclick.org> wro=
> te:
> > On Mon, 27 Feb 2012, William Herrin wrote:
> >> In some cases this is because of carelessness: The application does a
> >> gethostbyname once when it starts, grabs the first IP address in the
> >> list and retains it indefinitely. The gethostbyname function doesn't
> >> even pass the TTL to the application. Ntpd is/used to be one of the
> >> notable offenders, continuing to poll the dead address for years after
> >> the server moved.
> >
> > While yes it often is carelessness - it's been reported by hardcore
> > development sorts that I trust that there is no standardized API to obtai=
> n
> > the TTL... =A0What needs to get fixed is get[hostbyname,addrinfo,etc] so
> > programmers have better tools.
> 
> Meh. What should be fixed is that connect() should receive a name
> instead of an IP address. Having an application deal directly with the
> IP address should be the exception rather than the rule. Then, deal
> with the TTL issues once in the standard libraries instead of
> repeatedly in every single application.

No.  connect() should stay the way it is.  Most developers cut and paste
the connection code.  It's just that the code they cut and paste is very
old and is often IPv4 only.

> In theory, that'd even make the app code protocol agnostic so that it
> doesn't have to be rewritten yet again for IPv12.

getaddrinfo() man page has IP version agnostic code examples.  It
is however simplistic code which doesn't behave well when a address
is unreachable.  For examples of how to behave better for TCP see:

https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp
 
Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From randy at psg.com  Mon Feb 27 20:23:02 2012
From: randy at psg.com (Randy Bush)
Date: Tue, 28 Feb 2012 07:53:02 +0530
Subject: Programmers with network engineering skills
In-Reply-To: <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
Message-ID: <m24nubu261.wl%randy@psg.com>

programming is not being able to write a hundred lines of unreadable
perl.

a real programmer can be productive in networking tools in a matter of a
month or two.  i have seen it multiple times.

a networker can become a useful real progammer in a year or three.

randy


From mike at mtcc.com  Mon Feb 27 20:30:57 2012
From: mike at mtcc.com (Michael Thomas)
Date: Mon, 27 Feb 2012 18:30:57 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <m24nubu261.wl%randy@psg.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
 <m24nubu261.wl%randy@psg.com>
Message-ID: <4F4C3C61.8010908@mtcc.com>

On 02/27/2012 06:23 PM, Randy Bush wrote:
> programming is not being able to write a hundred lines of unreadable
> perl.
>
> a real programmer can be productive in networking tools in a matter of a
> month or two.  i have seen it multiple times.
>
> a networker can become a useful real progammer in a year or three.
>

I agree. Programmers aren't born understanding some fields and not
others. In my case, I didn't have a clue about networking coming out
of school but picked it up because I thought it was neat, and there
was something intoxicating about the smell of the printed out RFC's.

Mike, weird i know


From dholmes at mwdh2o.com  Mon Feb 27 20:46:07 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Mon, 27 Feb 2012 18:46:07 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <m24nubu261.wl%randy@psg.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
 <m24nubu261.wl%randy@psg.com>
Message-ID: <922ACC42D498884AA02B3565688AF995340531311D@USEXMBS01.mwd.h2o>

But my point is that each person who is capable to do so generally chooses their life's work, after working in and trying out several capacities, and this is extremely common in IT environments where a person could have cycled through programming, system admin, dba, networking, security, etc. For me, I prefer networking, and even a substantial raise would not get me to design and write computer programs again. Life is short, networking professionals generally are in high demand, and are in networking because they like it. Yes Perl scripting may become a temporary, necessary evil at some point, but if the subject of coding comes up, many will move on.

-----Original Message-----
From: Randy Bush [mailto:randy at psg.com]
Sent: Monday, February 27, 2012 6:23 PM
To: Holmes,David A
Cc: North American Network Operators' Group
Subject: Re: Programmers with network engineering skills

programming is not being able to write a hundred lines of unreadable
perl.

a real programmer can be productive in networking tools in a matter of a
month or two.  i have seen it multiple times.

a networker can become a useful real progammer in a year or three.

randy

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.


From jason at ackley.net  Mon Feb 27 20:50:25 2012
From: jason at ackley.net (Jason Ackley)
Date: Mon, 27 Feb 2012 20:50:25 -0600
Subject: Reliable Cloud host ?
In-Reply-To: <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
References: <1ec39a38-acf5-486c-ae33-cb4f17cc1ee4@zimbra.network1.net>
 <1fd3e972-a2e2-4ecc-b2d1-03fe47a828ff@zimbra.network1.net>
Message-ID: <CAA=cXfo-gTQEzR5AV90KXpKYaHxh9Wp3yZKEAakniqr0e0hUbw@mail.gmail.com>

On Sun, Feb 26, 2012 at 4:56 PM, Randy Carpenter <rcarpen at network1.net> wrote:

> We have been using Rackspace Cloud Servers. We just realized that
> they have absolutely no redundancy or failover after experiencing a
> outage that lasted more than 6 hours yesterday. I am appalled that
> they would offer something called "cloud" without having any failover at all.

 Disclaimer: I work for Rackspace in a network architect capacity. We
have plenty of redundancy where it is needed.  We have all sorts of
solutions, for all sorts of intersections of problems, budgets and
customers. Sometimes finding the 'correct' solution is not as easy as
it could or should be. The menu is simply getting crowded :)

I don't know the specifics of your issue, but if you contact me
privately I can look into the specifics. You can also use my work
email address if you don't think I am legit (email me at this address
to get it). I do find that that impact is quite extreme, and certainly
an exception and something that there are many folks probably still
working on root causes and lessons learned. We take this stuff
seriously.


> 1. Full redundancy with instant failover to other hypervisor hosts upon hardware failure (I thought this was a given!)

As others have mentioned, you will not be able to find some of these
features for 1.5c/hr.   They quickly spiral out of control for
large-scale deployments. Every penny matters at 1.5c/hr .

I would ask that you look in your product portfolio and see if you
have anything at that price that you can answer a support phone call
for :) . This is not meant to be antagonistic, just to have a clear
mindset understanding of the $$ we are talking about and how careful
you have to be.

What these cloud price points allow you to do tho is to turn it from
one type of a problem to another type of problem that you can have
more control over.  As others have mentioned, spreading out with many
different providers is one example.

They (cloud, VMs, VPS, whatever you want to call them) are cheap,
disposable computing resources - don't treat them as anything else! As
with anything, you get what you pay for, and I am sure we have all had
'that customer' that claims $1,000,000 in losses for every hour of
impact, and they have a single whitebox server deployed.


> 2. Actual support (with a phone number I can call)

This is where the providers will typically start to differentiate
themselves from each other. As a company, we pride ourselves on
support. Full support has a price.  I don't want to turn this into a
sale-ish email tho.


> 3. reasonable pricing (No, $800/month is not reasonable when I need a tiny 256MB RAM Server with <1GB/mo of data transfers)

1.5c / hr is what our basic linux image starts at IIRC. Again, I am
not in sales, so I don't really keep track of how that compares to
some of the other folks out there, I would guess it is about the going
rate.

I have used Linode.com as well as EC2 as well and they both have some
great feature sets and offers. Both also have areas that could use
improvements.

I do agree that there is general misconceptions of what 'cloud' means.
That is simply a byproduct of the amount of folks involved in such
trends, and yes, the marketing folks getting involved as well. This is
unavoidable in the world today.

If you have any other questions or concerns that I can help with,
please let me know...


cheers,
--
jason


From d at unwiredcouch.com  Mon Feb 27 21:09:17 2012
From: d at unwiredcouch.com (Daniel Schauenberg)
Date: Mon, 27 Feb 2012 22:09:17 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <m24nubu261.wl%randy@psg.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
 <m24nubu261.wl%randy@psg.com>
Message-ID: <6C01638B-9F05-487A-952B-6FCB1601114C@unwiredcouch.com>

> a real programmer can be productive in networking tools in a matter of a
> month or two.  i have seen it multiple times.
> 
> a networker can become a useful real progammer in a year or three.

Thank you! I always wonder when someone distinguishes between a networker and a programmer as if they came from completely different worlds. I find these fields to be highly related. They are algorithmic at the core and you need a good understanding of architecture and design to successfully make the concepts work. If you have ever tried to find a bug in a badly structured network, you should be able to understand that implementing all of your application's use cases in one module is not a good idea. After implementing a good serialization scheme for your class data, network protocols are not that strange anymore (I know I'm exaggerating on simple examples here, but I hope the idea comes across).

My point is, if someone has a good understanding of applying architectural patterns to a problem and isolating error causes while debugging, it shouldn't matter if he wrote mostly software the last years or if she administered a large scale network. A good sysadmin can learn to write software and a good programmer can learn to love the datacenter.

From dholmes at mwdh2o.com  Mon Feb 27 21:26:18 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Mon, 27 Feb 2012 19:26:18 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <6C01638B-9F05-487A-952B-6FCB1601114C@unwiredcouch.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <922ACC42D498884AA02B3565688AF9953405313118@USEXMBS01.mwd.h2o>
 <m24nubu261.wl%randy@psg.com>
 <6C01638B-9F05-487A-952B-6FCB1601114C@unwiredcouch.com>
Message-ID: <922ACC42D498884AA02B3565688AF9953405313122@USEXMBS01.mwd.h2o>

Yes, a theoretical understanding of algorithms is a common element in programming and networking. But the thread seems to assume that highly capable programmers/network engineers are mere serfs, unable to forge their own destiny, at the beck and call of whomever they work for, instead of independent beings who are doing what they are doing because they like it and choose to continue doing so, even at the expense of foregoing substantial financial gain.

-----Original Message-----
From: Daniel Schauenberg [mailto:d at unwiredcouch.com]
Sent: Monday, February 27, 2012 7:09 PM
To: Randy Bush
Cc: Holmes,David A; North American Network Operators' Group
Subject: Re: Programmers with network engineering skills

> a real programmer can be productive in networking tools in a matter of a
> month or two.  i have seen it multiple times.
>
> a networker can become a useful real progammer in a year or three.

Thank you! I always wonder when someone distinguishes between a networker and a programmer as if they came from completely different worlds. I find these fields to be highly related. They are algorithmic at the core and you need a good understanding of architecture and design to successfully make the concepts work. If you have ever tried to find a bug in a badly structured network, you should be able to understand that implementing all of your application's use cases in one module is not a good idea. After implementing a good serialization scheme for your class data, network protocols are not that strange anymore (I know I'm exaggerating on simple examples here, but I hope the idea comes across).

My point is, if someone has a good understanding of applying architectural patterns to a problem and isolating error causes while debugging, it shouldn't matter if he wrote mostly software the last years or if she administered a large scale network. A good sysadmin can learn to write software and a good programmer can learn to love the datacenter.

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.


From matt.addison at lists.evilgeni.us  Mon Feb 27 22:57:30 2012
From: matt.addison at lists.evilgeni.us (Matt Addison)
Date: Mon, 27 Feb 2012 23:57:30 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
Message-ID: <6252359949770844391@unknownmsgid>

On Feb 27, 2012, at 19:10, Owen DeLong <owen at delong.com> wrote:

>
> On Feb 27, 2012, at 3:50 PM, William Herrin wrote:
>
>> On Mon, Feb 27, 2012 at 3:43 PM, david raistrick <drais at icantclick.org> wrote:
>>> On Mon, 27 Feb 2012, William Herrin wrote:
>>>> In some cases this is because of carelessness: The application does a
>>>> gethostbyname once when it starts, grabs the first IP address in the
>>>> list and retains it indefinitely. The gethostbyname function doesn't
>>>> even pass the TTL to the application. Ntpd is/used to be one of the
>>>> notable offenders, continuing to poll the dead address for years after
>>>> the server moved.
>>>
>>> While yes it often is carelessness - it's been reported by hardcore
>>> development sorts that I trust that there is no standardized API to obtain
>>> the TTL...  What needs to get fixed is get[hostbyname,addrinfo,etc] so
>>> programmers have better tools.
>>
>> Meh. What should be fixed is that connect() should receive a name
>> instead of an IP address. Having an application deal directly with the
>> IP address should be the exception rather than the rule. Then, deal
>> with the TTL issues once in the standard libraries instead of
>> repeatedly in every single application.
>>
>> In theory, that'd even make the app code protocol agnostic so that it
>> doesn't have to be rewritten yet again for IPv12.
>
> While I agree with the principle of what you are trying to say, I would argue
> that it should be dealt with in getnameinfo() / getaddrinfo() and not connect().
>
> It is perfectly reasonable for connect() to deal with an address structure.
>
> If people are not using getnameinfo()/getaddrinfo() from the standard libraries,
> then, I don't see any reason to believe that they would use connect() from the
> standard libraries if it incorporated their functionality.

gai/gni do not return TTL values on any platforms I'm aware of, the
only way to get TTL currently is to use a non standard resolver (e.g.
lwres). The issue is application developers not calling gai every time
they connect (due to aforementioned security concerns, at least in the
browser realm), instead opting to hold onto the original resolved
address for unreasonable amounts of time. Modifying gai to provide TTL
has been proposed in the past (dnsop '04) but afaik was shot down to
prevent inconsistencies in the API. Maybe when happy eyeballs
stabilizes someone will propose an API for inclusion in the standard
library that implements HE style connections. Looks like there was
already some talk on v6ops headed this way, but as always there's
resistance to standardizing it.

~Matt


From marka at isc.org  Mon Feb 27 23:45:26 2012
From: marka at isc.org (Mark Andrews)
Date: Tue, 28 Feb 2012 16:45:26 +1100
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: Your message of "Mon, 27 Feb 2012 23:57:30 CDT."
 <6252359949770844391@unknownmsgid>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
Message-ID: <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>


	getaddrinfo was designed to be extensible as was struct
	addrinfo.  Part of the problem with TTL is not data sources
	used by getaddrinfo have TTL information.  Additionally for
	many uses you want to reconnect to the same server rather
	than the same name.  Note there is nothing to prevent a
	getaddrinfo implementation maintaining its own cache though
	if I was implementing such a cache I would have a flag to
	to force a refresh.

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


From noonslists at gmail.com  Tue Feb 28 00:21:33 2012
From: noonslists at gmail.com (Noon Silk)
Date: Tue, 28 Feb 2012 17:21:33 +1100
Subject: Programmers with network engineering skills
In-Reply-To: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <CADt_azYrMv_O-C2zjK5s72dMBs2m51eU3dKen2=VmpUh--kizw@mail.gmail.com>

On Mon, Feb 27, 2012 at 12:27 PM, A. Pishdadi <apishdadi at gmail.com> wrote:
> Hello All,
>
> i have been looking for quite some time now a descent coder (c,php) who has

Just a practical comment here; part of your problem may be offering c
and php together. I don't want to start a war, but I know that at the
very least all the c programmers I know would considered php to be ...
"horribly offensive". So, maybe seperating out these two roles (c and
php programming) will help you.

It is definitely true (speaking as a programmer, C# for several years)
that seeing +PHP would instantly turn me off. Further, I'm sure that
almost anyone who is still programming in c these days would have the
level of networking knowledge you care about (and can train on top
of).


> a descent amount of system admin / netadmin experience. Doesn't necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've posted
> job listings on the likes of dice and monster and have not found any good
> canidates, most of them ASP / Java guys.
>
> If anyone can point me to a site they might recommend for job postings or
> know of any consulting firms that might provide these services that would
> be greatly appreciated.

-- 
Noon Silk

Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/

"Every morning when I wake up, I experience an exquisite joy ? the joy
of being this signature."


From gbonser at seven.com  Tue Feb 28 02:14:35 2012
From: gbonser at seven.com (George Bonser)
Date: Tue, 28 Feb 2012 08:14:35 +0000
Subject: Programmers with network engineering skills
In-Reply-To: <CADt_azYrMv_O-C2zjK5s72dMBs2m51eU3dKen2=VmpUh--kizw@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <CADt_azYrMv_O-C2zjK5s72dMBs2m51eU3dKen2=VmpUh--kizw@mail.gmail.com>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CE9BBD@RWC-MBX1.corp.seven.com>

> Noon Silk said:
>
> Just a practical comment here; part of your problem may be offering c
> and php together. I don't want to start a war, but I know that at the
> very least all the c programmers I know would considered php to be ...
> "horribly offensive". So, maybe seperating out these two roles (c and
> php programming) will help you.
> 
> It is definitely true (speaking as a programmer, C# for several years)
> that seeing +PHP would instantly turn me off. Further, I'm sure that
> almost anyone who is still programming in c these days would have the
> level of networking knowledge you care about (and can train on top of).

PHP tends to mesh well with things like perl programmers. It is basically a scripting language.  Anyone using D ?




From owen at delong.com  Tue Feb 28 03:32:17 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Feb 2012 01:32:17 -0800
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
 <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
Message-ID: <8935C8F3-4E5E-4963-BBAD-02C1608B1BB0@delong.com>


On Feb 27, 2012, at 9:45 PM, Mark Andrews wrote:

> 
> 	getaddrinfo was designed to be extensible as was struct
> 	addrinfo.  Part of the problem with TTL is not data sources
> 	used by getaddrinfo have TTL information.  Additionally for
> 	many uses you want to reconnect to the same server rather
> 	than the same name.  Note there is nothing to prevent a
> 	getaddrinfo implementation maintaining its own cache though
> 	if I was implementing such a cache I would have a flag to
> 	to force a refresh.
> 

Sorry if I wasn't clear... My point to Bill was that we should be using calls that don't have TTL information
(GAI/GNI in their default forms). That we don't need to abuse connect() to achieve that. That if people use GAI/GNI(), then, any brokenness is system-wide brokenness in the system's resolver library and should be addressed there.

Owen



From david at davidswafford.com  Tue Feb 28 04:55:01 2012
From: david at davidswafford.com (David Swafford)
Date: Tue, 28 Feb 2012 05:55:01 -0500
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
In-Reply-To: <20120228005014.GA20175@ref.nmedia.net>
References: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
 <20120228005014.GA20175@ref.nmedia.net>
Message-ID: <CAA8=vb6LJe4GZq3qyd4NDOEkZ-Mi=QGpX5w=zNzvNYxm6HBOQQ@mail.gmail.com>

Hey Chris,

Yeah, our vendors epically failed here!  I was getting at having a good
releationship with fellow server/storage team mates.

David.



On Mon, Feb 27, 2012 at 7:50 PM, Chris Cappuccio <chris at nmedia.net> wrote:

> David Swafford [david at davidswafford.com] wrote:
> >
> > Lots of head-banging and teamwork eventually got us squared away!  This
> > situation is a good example of why network guys NEED to have a great
> > relationship with both server and storage guys (we're all really close
> > where I'm at).  Had there been tension/etc between the teams, this would
> > have been signifiantky harder to resolve.
>
> I don't know how this points to the NEED to have a great relationship with
> your vendor. Your vendors all failed to figure anything out. Obviously you
> need smart guys on staff to work-around problems...
>

From bill at herrin.us  Tue Feb 28 07:11:54 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Feb 2012 08:11:54 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
 <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
Message-ID: <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg@mail.gmail.com>

On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews <marka at isc.org> wrote:
> ? ? ? ?getaddrinfo was designed to be extensible as was struct
> ? ? ? ?addrinfo. ?Part of the problem with TTL is not [all] data sources
> ? ? ? ?used by getaddrinfo have TTL information.

Hi Mark,

By the time getaddrinfo replaced gethostbyname, NIS and similar
systems were on their way out. It was reasonably well understood that
many if not most of the calls would return information gained from the
DNS. Depending on how you look at it, choosing not to propagate TTL
knowledge was either a belligerent choice to continue disrespecting
the DNS Time To Live or it was fatalistic acceptance that the DNS TTL
isn't and would not become functional at the application level.

Still works fine deeper in the query system, timing out which server
holds the records though.


>       ?Additionally for
> ? ? ? ?many uses you want to reconnect to the same server rather
> ? ? ? ?than the same name.

The SRV record was designed to solve that whole class of problems
without damaging the operation of the TTL. No one uses it.


It's all really very unfortunate. The recipe for SOHO multihoming, the
end of routing table bloat and IP roaming without pivoting off a home
base all boils down to two technologies: (1) a layer 4 protocol that
can dynamically rebind to the layer 3 IP address the same way IP uses
ARP to rebind to a changing ethernet MAC and (2) a DNS TTL that
actually works so that the DNS supports finding a connection's current
IP address.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From ralph.brandt at pateam.com  Tue Feb 28 07:18:43 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Tue, 28 Feb 2012 08:18:43 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F293@embgsr24.pateam.com>

Owen, I can only say it is my opinion, based on some years of experience
and working with people who have come from both sides.  I have seen more
people successfully move from programming to networking than the
reverse.


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


-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Monday, February 27, 2012 5:14 PM
To: david raistrick
Cc: Brandt, Ralph; NANOG
Subject: Re: Programmers with network engineering skills


On Feb 27, 2012, at 12:31 PM, david raistrick wrote:

> On Mon, 27 Feb 2012, Owen DeLong wrote:
> 
>> I think you're more likely to find a network engineer with (possibly
limited)
>> programming skills.
> 
> While I'll agree about the more likely, if I needed a coder who had a
firm grasp of networking I'd rather teach a good coder networking, than
try to teach the art and magic of good development to a network guy.
> 

Well, I won't call myself a hard-core coder, but, I think I have a
reasonable grasp on the art and magic of good development. What I mostly
lack is speed and efficiency in the language of choice for whatever
project. I can write good code, it just takes me longer than it would
take a hard-core coder.

OTOH, having done both, I would say that I think you are not necessarily
correct about which direction of teaching is harder. Yes, if you start
with a network engineer that knows nothing about writing code or doesn't
understand the principles of good coding, you're probably right.
However, starting with a network engineer that can write decent code
slowly, I think you will get a better result in most cases than if you
try to teach network engineering to a hard-core coder that has only a
minimal understanding of networking.

> I think it really comes down to which you need: a hardcore network
engineer/architect who can hack up code, or a hardcore developer who has
or can obtain enough of a grasp of networking fundementals and specifics
to build you the software you need him to develop.
> 

I'm guessing that someone who needed a hard-core developer that could
grasp fundamentals would have grabbed an existing coder and handed him a
copy of Comer.

The fact that this person posted to NANOG instead implies to me that he
needs someone that has a better grasp than just the fundamentals.

Of course I am speculating about that and I could be wrong.

> The ones who already know both ends extremely well are going to be
-very- hard to find, but finding one who can learn enough of the other
to accomplish what you need shouldn't be hard at all.
> 

Depends on what you need. However, I think it's faster to go from
limited coding skills with a good basis in the fundamentals to usable
development than to go from limited networking skills to a firm grasp on
how networks behave in the real world. To the best of my knowledge,
nothing but experience will teach you the latter. Even with 20+ years
experience networks do still occasionally manage to surprise me.

> ...d (who is not exactly the former though I've played one for TV, and
not at all the later)

I am admittedly lost given the three choices as to which constitutes
former or latter at this point.

1.	Strong coder with limited networking
2.	Strong networker with limited coding
3.	Strong in both

Owen
Who is a strong network engineer
Who has been a professional software engineer (though many years ago and
my skills are rusty
	and out of date)



From jeroen at unfix.org  Tue Feb 28 07:20:05 2012
From: jeroen at unfix.org (Jeroen Massar)
Date: Tue, 28 Feb 2012 14:20:05 +0100
Subject: Call for updates: Native IPv6 access providers
Message-ID: <4F4CD485.2020002@unfix.org>

Hi Folks,

I would like to get more organizations on the Native IPv6 list:

http://www.sixxs.net/faq/connectivity/?faq=native

Thus, if you have updates and also new entries, do not hesitate to
forward them to info at sixxs.net.

Please provide the list of countries that you are offering the service,
the name of the organization/company, the website, the IPv6 prefixes
involved, the type of link/technology and any kind of notes that may
pertain to your offering.

Of course, if you are in the planning phase and know that around date
XYZ you are going to offer the service too this can be put in the Notes
column too...

Yes, this list does not include Datacenter offerings, as when you have a
simple Ethernet/routed network it you should have been able to offer
IPv6 ages ago...

Thanks for the input!

Greets,
 Jeroen


From ralph.brandt at pateam.com  Tue Feb 28 07:23:52 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Tue, 28 Feb 2012 08:23:52 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <F9CFD32E-E4F4-4AF4-A479-06256109D894@gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <F9CFD32E-E4F4-4AF4-A479-06256109D894@gmail.com>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F294@embgsr24.pateam.com>

Rodrick, give me the name of one of those firms.  :)


Ralph Brandt


-----Original Message-----
From: Rodrick Brown [mailto:rodrick.brown at gmail.com] 
Sent: Monday, February 27, 2012 6:13 PM
To: A. Pishdadi
Cc: NANOG
Subject: Re: Programmers with network engineering skills

On Feb 26, 2012, at 8:27 PM, "A. Pishdadi" <apishdadi at gmail.com> wrote:

> Hello All,
> 
> i have been looking for quite some time now a descent coder (c,php)
who has
> a descent amount of system admin / netadmin experience. Doesn't
necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding
basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've
posted
> job listings on the likes of dice and monster and have not found any
good
> canidates, most of them ASP / Java guys.
> 
> If anyone can point me to a site they might recommend for job postings
or
> know of any consulting firms that might provide these services that
would
> be greatly appreciated.

Good Luck guys like these are being scooped up by large financial firms
and hedgefunds and they don't come cheap  ~$250k easy! 


From rodrick.brown at gmail.com  Tue Feb 28 07:41:16 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Tue, 28 Feb 2012 08:41:16 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184F294@embgsr24.pateam.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <F9CFD32E-E4F4-4AF4-A479-06256109D894@gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F294@embgsr24.pateam.com>
Message-ID: <96AE83C1-8415-4DFA-91A8-0413E809A5FD@gmail.com>

The smaller more elite hedge funds  are - Getco LLC, Knight Capital, SAC Capital Advisors, Jump Trading, Wolverine Trading, Chicago Trading, Citadel, Sun Trading

A list of larger firms are here - http://www.nasdaqtrader.com/Trader.aspx?id=topliquidity

The core skill sets most look for is core Linux, C/C++, multicast, multithreading, IPC, and low level kernel drivers. FPGA and CUDA is also becoming more relevant.

Sent from my iPhone

On Feb 28, 2012, at 8:23 AM, "Brandt, Ralph" <ralph.brandt at pateam.com> wrote:

> Rodrick, give me the name of one of those firms.  :)
> 
> 
> Ralph Brandt
> 
> 
> -----Original Message-----
> From: Rodrick Brown [mailto:rodrick.brown at gmail.com] 
> Sent: Monday, February 27, 2012 6:13 PM
> To: A. Pishdadi
> Cc: NANOG
> Subject: Re: Programmers with network engineering skills
> 
> On Feb 26, 2012, at 8:27 PM, "A. Pishdadi" <apishdadi at gmail.com> wrote:
> 
>> Hello All,
>> 
>> i have been looking for quite some time now a descent coder (c,php)
> who has
>> a descent amount of system admin / netadmin experience. Doesn't
> necessarily
>> need to be an expert at network engineering but being acclimated in
>> understanding the basic fundamentals of networking. Understanding
> basic
>> routing concepts, how to diagnose using tcpdump / pcap, understanding
>> subnetting and how bgp works (not necessarily setting up bgp). I've
> posted
>> job listings on the likes of dice and monster and have not found any
> good
>> canidates, most of them ASP / Java guys.
>> 
>> If anyone can point me to a site they might recommend for job postings
> or
>> know of any consulting firms that might provide these services that
> would
>> be greatly appreciated.
> 
> Good Luck guys like these are being scooped up by large financial firms
> and hedgefunds and they don't come cheap  ~$250k easy! 


From jared at puck.nether.net  Tue Feb 28 08:02:00 2012
From: jared at puck.nether.net (Jared Mauch)
Date: Tue, 28 Feb 2012 09:02:00 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <42252.1330372433@turing-police.cc.vt.edu>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
Message-ID: <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>


On Feb 27, 2012, at 2:53 PM, Valdis.Kletnieks at vt.edu wrote:

> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
> 
>> The net result is that when you switch the IP address of your server,
>> a percentage of your users (declining over time) will be unable to
>> access it for hours, days, weeks or even years regardless of the DNS
>> TTL setting.
> 
> Amen brother.
> 
> So just for grins, after seeing William's I set up a listener on an address
> that had an NTP server on it many moons ago. As in the machine was shut down
> around 2002/06/30 22:49 and we didn't re-assign the IP address ever since
> *because* it kept getting hit with NTP packets..  Yes, a decade ago.
> 
> In the first 15 minutes, 234 different IP's have tried to NTP to that address.

I hereby reject the principle that one can not renumber a host/name and move it.

Certainly some people will see breakage.  This is because their software is defective, sometimes in a critical way, other times in a way that is non-obvious.

But I reject the idea that you can't move a service, or have one MX, DNS, etc.. host be down and have it be fatal without something else being SERIOUSLY broken.  If you are right, nobody could ever renumber anything ever, nor take a service down ever in the most absolute terms.

I've been involved in large scale DNS server renumbering/moving/whatnot.  It's harder these days than it was in the past, but its feasible.  I know those resolver addresses that have been retired still get queries from *very* broken hosts.  Just because they're getting queries, doesn't mean they are expecting an answer, or will properly handle it.

Sometimes you have to break the service worse for people to repair it.  Look at the DCWG.org site and try to get an idea if you're infected.  At some point those will go away.  Doesn't mean those people aren't broken/infected and REQUIRE remediation.

- Jared

From mitch at illuminati.org  Tue Feb 28 08:03:33 2012
From: mitch at illuminati.org (John Mitchell)
Date: Tue, 28 Feb 2012 14:03:33 +0000
Subject: Programmers with network engineering skills
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
Message-ID: <4F4CDEB5.8050802@illuminati.org>

<rant>

I would wholeheartedly agree with this, but I believe its worse than 
just that. I used to categorize myself as a full developer, now I'm 
slightly ashamed to be tainted with that brush since there's so many 
people using the term who don't know the first thing about programming.

It used to be that when you were taught programming, you were taught 
concepts (when to use a for loop, while loop, Boolean algebra), then 
you built on the foundations by learning advanced concepts  (data 
structures, how to program concurrently using semaphores etc etc), you 
would then pick some optional classes to make up for some non 
programming specific knowledge (networking, linux admin, etc etc).

I now have a lot of friends who work in academia and they are worried 
by a decline (as am I when trying to hire new talent). Currently the 
teaching process is one of learning to program like a monkey, monkey 
see monkey do. People are no longer taught to think for themselves, but 
instead taught to program in a specific language (PHP, Java, rarely C 
or C++ any more, C#, or VB) and that is all they know. I don't believe 
this is a failing with the lecturers but with the fundamental change in 
attitudes to programming.

One of the tests I give all interviewees is write a very short program 
in a language they have never ever used before ( personally I recommend 
http://en.wikipedia.org/wiki/Brainfuck ) since this gives people a 
chance to show they can program rather than being able to tell me "I 
know PHP" or "I know C", suprisingly very few newer programmers can 
make it through, or even try it, because the concept of thinking for 
themselves is so last year.

</rant>

On 27 February 2012 20:02:13, Brandt, Ralph wrote:
> Generalists are hard to come by these days. They are people who learn
> less and less about more and more till they know nothing about
> everything. People today are specializing in the left and right halves
> of the bytes....  They learn more and more about less and less till they
> know everything about nothing.  And BTW, they are worthless unless you
> have five of them working on a problem because none of them know enough
> to fix it.  Worse, you can replace the word five with fifty and it may
> be still true. 
>
> I know of three of these, all gainfully employed at this time and could
> each find at least a couple jobs if they wanted.  I am one, my son is
> two and a guy we worked with is the third. 
>
> At one time (40 years ago) the mantra in IS was train for expertise, now
> it is hire for it.  Somewhere there has to be a happy medium.  I suggest
> this, find a good coder, not a mediocre who writes shit code but a good
> one who can think and learn and when you talk about branching out with
> his skill set he or she lights up.  His first thing on site is take the
> A+ networking course.  
>
> No, I do not sell the courses.  But I have seen this kind of approach
> work when nothing else was.
>
>
>
>
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services
> Telephone +1 717.506.0802
> FAX +1 717.506.4358
> Email Ralph.Brandt at pateam.com
> 5095 Ritter Rd
> Mechanicsburg PA 17055
>
> -----Original Message-----
> From: A. Pishdadi [mailto:apishdadi at gmail.com] 
> Sent: Sunday, February 26, 2012 8:27 PM
> To: NANOG
> Subject: Programmers with network engineering skills
>
> Hello All,
>
> i have been looking for quite some time now a descent coder (c,php) who
> has
> a descent amount of system admin / netadmin experience. Doesn't
> necessarily
> need to be an expert at network engineering but being acclimated in
> understanding the basic fundamentals of networking. Understanding basic
> routing concepts, how to diagnose using tcpdump / pcap, understanding
> subnetting and how bgp works (not necessarily setting up bgp). I've
> posted
> job listings on the likes of dice and monster and have not found any
> good
> canidates, most of them ASP / Java guys.
>
> If anyone can point me to a site they might recommend for job postings
> or
> know of any consulting firms that might provide these services that
> would
> be greatly appreciated.


From rps at maine.edu  Tue Feb 28 08:05:06 2012
From: rps at maine.edu (Ray Soucy)
Date: Tue, 28 Feb 2012 09:05:06 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CADt_azYrMv_O-C2zjK5s72dMBs2m51eU3dKen2=VmpUh--kizw@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <CADt_azYrMv_O-C2zjK5s72dMBs2m51eU3dKen2=VmpUh--kizw@mail.gmail.com>
Message-ID: <CALFTrnPg+UuDHm5Qzr9sa1PpqKEV1qOmuD4+uceu=51PNuFP1w@mail.gmail.com>

The right tool for the right job.

PHP (and the LAMP stack) can result in very quick development of systems
that will run on any vanilla Linux server.  In my experience, that has
turned out to be a huge benefit.

If you have a developer who knows C well, then they will more than likely
be able to use PHP properly.  I use both C and PHP myself, and have no
conflict.  I think they compliment each other nicely.  C for performance,
PHP for web applications or quick scrips.

C# and any .NET language on the other hand . . . now /that/ I question.




; )




On Tue, Feb 28, 2012 at 1:21 AM, Noon Silk <noonslists at gmail.com> wrote:

> On Mon, Feb 27, 2012 at 12:27 PM, A. Pishdadi <apishdadi at gmail.com> wrote:
> > Hello All,
> >
> > i have been looking for quite some time now a descent coder (c,php) who
> has
>
> Just a practical comment here; part of your problem may be offering c
> and php together. I don't want to start a war, but I know that at the
> very least all the c programmers I know would considered php to be ...
> "horribly offensive". So, maybe seperating out these two roles (c and
> php programming) will help you.
>
> It is definitely true (speaking as a programmer, C# for several years)
> that seeing +PHP would instantly turn me off. Further, I'm sure that
> almost anyone who is still programming in c these days would have the
> level of networking knowledge you care about (and can train on top
> of).
>
>
> > a descent amount of system admin / netadmin experience. Doesn't
> necessarily
> > need to be an expert at network engineering but being acclimated in
> > understanding the basic fundamentals of networking. Understanding basic
> > routing concepts, how to diagnose using tcpdump / pcap, understanding
> > subnetting and how bgp works (not necessarily setting up bgp). I've
> posted
> > job listings on the likes of dice and monster and have not found any good
> > canidates, most of them ASP / Java guys.
> >
> > If anyone can point me to a site they might recommend for job postings or
> > know of any consulting firms that might provide these services that would
> > be greatly appreciated.
>
> --
> Noon Silk
>
> Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/
>
> "Every morning when I wake up, I experience an exquisite joy ? the joy
> of being this signature."
>
>


-- 
Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

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

From mikea at mikea.ath.cx  Tue Feb 28 09:23:15 2012
From: mikea at mikea.ath.cx (Mike Andrews)
Date: Tue, 28 Feb 2012 09:23:15 -0600
Subject: BBC reports Kenya fiber break
In-Reply-To: <4F4BC95A.30307@gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com>
Message-ID: <20120228152315.GC43304@mikea.ath.cx>

On Mon, Feb 27, 2012 at 10:20:10AM -0800, virendra rode wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 02/27/2012 08:11 AM, Marshall Eubanks wrote:
> > Is anyone seeing this ?
> > 
> > http://www.bbc.co.uk/news/world-africa-17179544
> > 
> > "East Africa's high-speed internet access has been severely disrupted
> > after a ship dropped its anchor onto fibre-optic cables off Kenya's
> > coast."

The ship was reported to have dropped anchor while in a restricted or
prohibited area. These areas are _EXTREMELY_ well marked on charts. I can't
see it being anything other than human or mechanical error: not checking if
the ship is in a no-anchorage area, or the anchor chain wildcat brake _and_
the anchor chain blocking device fail simultaneously, or watch officer
totally mistakes the ship's location and orders the anchor to be let go.

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


From jamie at photon.com  Tue Feb 28 10:27:52 2012
From: jamie at photon.com (Jamie Bowden)
Date: Tue, 28 Feb 2012 16:27:52 +0000
Subject: Programmers with network engineering skills
In-Reply-To: <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
Message-ID: <5941B69EF8C7764DAE18F85A6A5A6AD018EED3@east-mail.photon.com>


William Herrin [mailto:bill at herrin.us]
> On Mon, Feb 27, 2012 at 3:22 PM, Owen DeLong <owen at delong.com> wrote:
> > On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote:
> >> Generalists are hard to come by these days.
> >
> > I think you're more likely to find a network engineer with (possibly
> limited)
> > programming skills.
> 
> I wish. For the past three months I've been trying to find a network
> engineer with a deep TCP/IP protocol understanding, network security
> expertise, some Linux experience, minor programming skill with sockets
> and a TS/SCI clearance.
> 
> The clearance is killing me. The two generalists didn't have a
> clearance and the cleared applicants are programmers or admins but
> never both.

Hey now...the time from zero to TS/SCI has gone from over half a decade to a mere quarter decade.  You can totally pay these guys to sit around doing drudge work while their skills atrophy in the interim.  Of course, if you need a poly on top, add some more time and stir continually while applying heat.

Jamie


From keegan.holley at sungard.com  Tue Feb 28 10:43:47 2012
From: keegan.holley at sungard.com (Keegan Holley)
Date: Tue, 28 Feb 2012 11:43:47 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
Message-ID: <CABO8Q6Q9f2+oViNEreFAZSmCzMjWPB7hRmT3Q9XHK7nPPzWL6g@mail.gmail.com>

+1 on both.  Senior network guys learn programming/scripting as a way to
automate configuration and deal with large amounts of data.  It's an
enhancement for us and most network people are willing to expand their
programming skills given the time.  On the other hand there are way too
many jobs where programmers can just be programmers for many of them to be
interested in expanding their networking skills even if they have prior
experience.  If they become interested in the "hardware" world they usually
go toward systems administrator and OS's.  Some of them are big enough
geeks to want to learn both or all three, but those are few and far
between.  It's very likely that such programmers frequent this list so
hopefully I won't get flamed for posting this.  EIther way it's just
semantics, but it is generally easier to find a network guy that wants to
learn how to program or get better at it than to find a programmer who is
dying to learn about networking.  Not sure if I agree with the opinion
about generalists.  There are alot of people who view technology as both a
job and a hobby and become experts in what pays their bills and then slowly
learn something about everything via osmosis.  There are alot of people
that never saw a book or trade rag they didn't like.


2012/2/27 Owen DeLong <owen at delong.com>

> I think you're more likely to find a network engineer with (possibly
> limited)
> programming skills.
>
> That's certainly where I would categorize myself.
>
> Owen
>
> On Feb 27, 2012, at 12:02 PM, Brandt, Ralph wrote:
>
> > Generalists are hard to come by these days. They are people who learn
> > less and less about more and more till they know nothing about
> > everything. People today are specializing in the left and right halves
> > of the bytes....  They learn more and more about less and less till they
> > know everything about nothing.  And BTW, they are worthless unless you
> > have five of them working on a problem because none of them know enough
> > to fix it.  Worse, you can replace the word five with fifty and it may
> > be still true.
> >
> > I know of three of these, all gainfully employed at this time and could
> > each find at least a couple jobs if they wanted.  I am one, my son is
> > two and a guy we worked with is the third.
> >
> > At one time (40 years ago) the mantra in IS was train for expertise, now
> > it is hire for it.  Somewhere there has to be a happy medium.  I suggest
> > this, find a good coder, not a mediocre who writes shit code but a good
> > one who can think and learn and when you talk about branching out with
> > his skill set he or she lights up.  His first thing on site is take the
> > A+ networking course.
> >
> > No, I do not sell the courses.  But I have seen this kind of approach
> > work when nothing else was.
> >
> >
> >
> >
> > Ralph Brandt
> > Communications Engineer
> > HP Enterprise Services
> > Telephone +1 717.506.0802
> > FAX +1 717.506.4358
> > Email Ralph.Brandt at pateam.com
> > 5095 Ritter Rd
> > Mechanicsburg PA 17055
> >
> > -----Original Message-----
> > From: A. Pishdadi [mailto:apishdadi at gmail.com]
> > Sent: Sunday, February 26, 2012 8:27 PM
> > To: NANOG
> > Subject: Programmers with network engineering skills
> >
> > Hello All,
> >
> > i have been looking for quite some time now a descent coder (c,php) who
> > has
> > a descent amount of system admin / netadmin experience. Doesn't
> > necessarily
> > need to be an expert at network engineering but being acclimated in
> > understanding the basic fundamentals of networking. Understanding basic
> > routing concepts, how to diagnose using tcpdump / pcap, understanding
> > subnetting and how bgp works (not necessarily setting up bgp). I've
> > posted
> > job listings on the likes of dice and monster and have not found any
> > good
> > canidates, most of them ASP / Java guys.
> >
> > If anyone can point me to a site they might recommend for job postings
> > or
> > know of any consulting firms that might provide these services that
> > would
> > be greatly appreciated.
>
>
>
>

From bill at herrin.us  Tue Feb 28 12:22:14 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Feb 2012 13:22:14 -0500
Subject: Reliable Cloud host ?
In-Reply-To: <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
Message-ID: <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>

On Tue, Feb 28, 2012 at 9:02 AM, Jared Mauch <jared at puck.nether.net> wrote:
> On Feb 27, 2012, at 2:53 PM, Valdis.Kletnieks at vt.edu wrote:
>> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
>>
>>> The net result is that when you switch the IP address of your server,
>>> a percentage of your users (declining over time) will be unable to
>>> access it for hours, days, weeks or even years regardless of the DNS
>>> TTL setting.
>>
>> Amen brother.
>>
>> So just for grins, after seeing William's I set up a listener on an address
>> that had an NTP server on it many moons ago. As in the machine was shut down
>> around 2002/06/30 22:49 and we didn't re-assign the IP address ever since
>> *because* it kept getting hit with NTP packets.. ?Yes, a decade ago.
>>
>> In the first 15 minutes, 234 different IP's have tried to NTP to that address.
>
> I hereby reject the principle that one can not renumber a
> host/name and move it.
> I reject the idea that you can't move a service, or have one
> MX, DNS, etc.. host be down and have it be fatal without
> something else being SERIOUSLY broken. ?If you are right,
> nobody could ever renumber anything ever, nor take a
> service down ever in the most absolute terms.

Something else IS seriously broken. Several something elses actually:

1. DNS TTL at the application boundary, due in part to...

2. Pushing the name to layer 3 address mapping process up from layer 4
to layer 7 where each application has to (incorrectly) reinvent the
process, and...

3. A layer 4 protocol which overloads the layer 3 address as an
inseverable component of its transport identifier.

Even stuff like SMTP which took care to respect the DNS TTL in its own
standards gets busted at the back end: too many antispam process
components rely on the source IP address, crushing large scale servers
that suddenly appear, transmitting large amounts of email from a fresh
IP address.


Shockingly enough we have a strongly functional network despite this
brokenness. But, it's broken all the same and renumbering is majorly
impaired as a consequence.


Renumbering in light of these issues isn't impossible. An overlap
period is required in which both old and new addresses are operable.
The duration of that overlap period is not defined by the the protocol
itself. Rather, it varies with the tolerable level or residual
brokenness, literally how many nines of users should be operating on
the new address before the old address can go away.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From Valdis.Kletnieks at vt.edu  Tue Feb 28 12:43:50 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Tue, 28 Feb 2012 13:43:50 -0500
Subject: Reliable Cloud host ?
In-Reply-To: Your message of "Tue, 28 Feb 2012 09:02:00 EST."
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
Message-ID: <13821.1330454630@turing-police.cc.vt.edu>

On Tue, 28 Feb 2012 09:02:00 EST, Jared Mauch said:

> Sometimes you have to break the service worse for people to repair it.

I broke it a decade ago, I think I can pretty much give up on expecting people to
repair it. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120228/aaeed03d/attachment-0001.bin>

From owen at delong.com  Tue Feb 28 12:45:07 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Feb 2012 10:45:07 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <51C66083768C2949A7EB14910C78B0170184F293@embgsr24.pateam.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <alpine.BSF.2.00.1202271527490.425@murf.icantclick.org>
 <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
 <51C66083768C2949A7EB14910C78B0170184F293@embgsr24.pateam.com>
Message-ID: <5E922400-B3C2-4001-9C63-EF0F43DC87F2@delong.com>

While what you say is true (heck, I'm one of them), my point is that a great many
network engineers have relatively strong programming backgrounds and if you
could convince one of them to go back to writing code (sufficiently interesting
project and/or right $$) you'd probably have better luck than finding a programmer
that has networking skills.

Owen

On Feb 28, 2012, at 5:18 AM, Brandt, Ralph wrote:

> Owen, I can only say it is my opinion, based on some years of experience
> and working with people who have come from both sides.  I have seen more
> people successfully move from programming to networking than the
> reverse.
> 
> 
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services
> Telephone +1 717.506.0802
> FAX +1 717.506.4358
> Email Ralph.Brandt at pateam.com
> 5095 Ritter Rd
> Mechanicsburg PA 17055
> 
> 
> -----Original Message-----
> From: Owen DeLong [mailto:owen at delong.com] 
> Sent: Monday, February 27, 2012 5:14 PM
> To: david raistrick
> Cc: Brandt, Ralph; NANOG
> Subject: Re: Programmers with network engineering skills
> 
> 
> On Feb 27, 2012, at 12:31 PM, david raistrick wrote:
> 
>> On Mon, 27 Feb 2012, Owen DeLong wrote:
>> 
>>> I think you're more likely to find a network engineer with (possibly
> limited)
>>> programming skills.
>> 
>> While I'll agree about the more likely, if I needed a coder who had a
> firm grasp of networking I'd rather teach a good coder networking, than
> try to teach the art and magic of good development to a network guy.
>> 
> 
> Well, I won't call myself a hard-core coder, but, I think I have a
> reasonable grasp on the art and magic of good development. What I mostly
> lack is speed and efficiency in the language of choice for whatever
> project. I can write good code, it just takes me longer than it would
> take a hard-core coder.
> 
> OTOH, having done both, I would say that I think you are not necessarily
> correct about which direction of teaching is harder. Yes, if you start
> with a network engineer that knows nothing about writing code or doesn't
> understand the principles of good coding, you're probably right.
> However, starting with a network engineer that can write decent code
> slowly, I think you will get a better result in most cases than if you
> try to teach network engineering to a hard-core coder that has only a
> minimal understanding of networking.
> 
>> I think it really comes down to which you need: a hardcore network
> engineer/architect who can hack up code, or a hardcore developer who has
> or can obtain enough of a grasp of networking fundementals and specifics
> to build you the software you need him to develop.
>> 
> 
> I'm guessing that someone who needed a hard-core developer that could
> grasp fundamentals would have grabbed an existing coder and handed him a
> copy of Comer.
> 
> The fact that this person posted to NANOG instead implies to me that he
> needs someone that has a better grasp than just the fundamentals.
> 
> Of course I am speculating about that and I could be wrong.
> 
>> The ones who already know both ends extremely well are going to be
> -very- hard to find, but finding one who can learn enough of the other
> to accomplish what you need shouldn't be hard at all.
>> 
> 
> Depends on what you need. However, I think it's faster to go from
> limited coding skills with a good basis in the fundamentals to usable
> development than to go from limited networking skills to a firm grasp on
> how networks behave in the real world. To the best of my knowledge,
> nothing but experience will teach you the latter. Even with 20+ years
> experience networks do still occasionally manage to surprise me.
> 
>> ...d (who is not exactly the former though I've played one for TV, and
> not at all the later)
> 
> I am admittedly lost given the three choices as to which constitutes
> former or latter at this point.
> 
> 1.	Strong coder with limited networking
> 2.	Strong networker with limited coding
> 3.	Strong in both
> 
> Owen
> Who is a strong network engineer
> Who has been a professional software engineer (though many years ago and
> my skills are rusty
> 	and out of date)



From owen at delong.com  Tue Feb 28 12:51:14 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Feb 2012 10:51:14 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <4F4CDEB5.8050802@illuminati.org>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <4F4CDEB5.8050802@illuminati.org>
Message-ID: <BD92786C-5276-4DB2-A81C-473FB54D0E60@delong.com>

This problem is not limited to programming.

Education in general has moved from teaching conceptual knowledge
re-inforced by practical examples and exercises to teaching methodological
and/or procedural knowledge without any effort to convey concepts.

It's much like the difference between teaching a man to buy a fish using
cash vs. teaching a man more generalized economic skills and money
management.

In the former case, you get a man who can eat fish as long as he still
has some cash. In the latter case, you get a man who can keep cash
coming in and use it to obtain a varied diet and other things he may
want.

Today, the indoctrination mills (hard to call them education centers
at this point) churn out people who are good at repeating the same
process and solving the same problems over and over.

Unfortunately, when faced with a problem that doesn't look like something
from their text book, they either become completely lost or they take
the hammer approach (when the only tool you have is a hammer, every
problem looks like a nail).

I'm not sure how to solve this. Teaching methodologically is much much
faster than teaching conceptually and the endemic lack of patience makes it
hard to get people to sit still long enough to learn conceptually.

Owen

On Feb 28, 2012, at 6:03 AM, John Mitchell wrote:

> <rant>
> 
> I would wholeheartedly agree with this, but I believe its worse than 
> just that. I used to categorize myself as a full developer, now I'm 
> slightly ashamed to be tainted with that brush since there's so many 
> people using the term who don't know the first thing about programming.
> 
> It used to be that when you were taught programming, you were taught 
> concepts (when to use a for loop, while loop, Boolean algebra), then 
> you built on the foundations by learning advanced concepts  (data 
> structures, how to program concurrently using semaphores etc etc), you 
> would then pick some optional classes to make up for some non 
> programming specific knowledge (networking, linux admin, etc etc).
> 
> I now have a lot of friends who work in academia and they are worried 
> by a decline (as am I when trying to hire new talent). Currently the 
> teaching process is one of learning to program like a monkey, monkey 
> see monkey do. People are no longer taught to think for themselves, but 
> instead taught to program in a specific language (PHP, Java, rarely C 
> or C++ any more, C#, or VB) and that is all they know. I don't believe 
> this is a failing with the lecturers but with the fundamental change in 
> attitudes to programming.
> 
> One of the tests I give all interviewees is write a very short program 
> in a language they have never ever used before ( personally I recommend 
> http://en.wikipedia.org/wiki/Brainfuck ) since this gives people a 
> chance to show they can program rather than being able to tell me "I 
> know PHP" or "I know C", suprisingly very few newer programmers can 
> make it through, or even try it, because the concept of thinking for 
> themselves is so last year.
> 
> </rant>
> 
> On 27 February 2012 20:02:13, Brandt, Ralph wrote:
>> Generalists are hard to come by these days. They are people who learn
>> less and less about more and more till they know nothing about
>> everything. People today are specializing in the left and right halves
>> of the bytes....  They learn more and more about less and less till they
>> know everything about nothing.  And BTW, they are worthless unless you
>> have five of them working on a problem because none of them know enough
>> to fix it.  Worse, you can replace the word five with fifty and it may
>> be still true. 
>> 
>> I know of three of these, all gainfully employed at this time and could
>> each find at least a couple jobs if they wanted.  I am one, my son is
>> two and a guy we worked with is the third. 
>> 
>> At one time (40 years ago) the mantra in IS was train for expertise, now
>> it is hire for it.  Somewhere there has to be a happy medium.  I suggest
>> this, find a good coder, not a mediocre who writes shit code but a good
>> one who can think and learn and when you talk about branching out with
>> his skill set he or she lights up.  His first thing on site is take the
>> A+ networking course.  
>> 
>> No, I do not sell the courses.  But I have seen this kind of approach
>> work when nothing else was.
>> 
>> 
>> 
>> 
>> Ralph Brandt
>> Communications Engineer
>> HP Enterprise Services
>> Telephone +1 717.506.0802
>> FAX +1 717.506.4358
>> Email Ralph.Brandt at pateam.com
>> 5095 Ritter Rd
>> Mechanicsburg PA 17055
>> 
>> -----Original Message-----
>> From: A. Pishdadi [mailto:apishdadi at gmail.com] 
>> Sent: Sunday, February 26, 2012 8:27 PM
>> To: NANOG
>> Subject: Programmers with network engineering skills
>> 
>> Hello All,
>> 
>> i have been looking for quite some time now a descent coder (c,php) who
>> has
>> a descent amount of system admin / netadmin experience. Doesn't
>> necessarily
>> need to be an expert at network engineering but being acclimated in
>> understanding the basic fundamentals of networking. Understanding basic
>> routing concepts, how to diagnose using tcpdump / pcap, understanding
>> subnetting and how bgp works (not necessarily setting up bgp). I've
>> posted
>> job listings on the likes of dice and monster and have not found any
>> good
>> canidates, most of them ASP / Java guys.
>> 
>> If anyone can point me to a site they might recommend for job postings
>> or
>> know of any consulting firms that might provide these services that
>> would
>> be greatly appreciated.



From lowen at pari.edu  Tue Feb 28 13:21:17 2012
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 28 Feb 2012 14:21:17 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <201202281421.17808.lowen@pari.edu>

On Monday, February 27, 2012 07:53:07 PM William Herrin wrote:
> .../SCI clearance.
> 
> The clearance is killing me. The two generalists didn't have a
> clearance and the cleared applicants are programmers or admins but
> never both.

I just about spewed my chai tea seeing 'SCI' and 'generalist' in the same post... isn't that mutually exclusive?


From jeroen at mompl.net  Tue Feb 28 13:30:51 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Tue, 28 Feb 2012 11:30:51 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <CAN3um4x-MetQ6JmTX5dMdo6d9uzsDFpPkWQUVqo9cxXPf4ggGw@mail.gmail.com>
Message-ID: <4F4D2B6B.2020901@mompl.net>

Mike Hale wrote:
> If you're located in a major city, I'm sure you can find a community
> college that has a networking certificate program you can send your
> developer to, along with an in-house training program.

Oh come on!!!1
Investing in your employee by sending them out to courses, for crying 
out loud, that's way too practical and effective to even consider.

And to add insult to injury you suggest a low cost alternative such as a 
community college. If an employer was going to do such an outrageous 
thing as sending an employee to a course at least let it be an 
overpriced corporate course. Gees.

</sarcasm>

-- 
Earthquake Magnitude: 3.0
Date: Tuesday, February 28, 2012 19:17:34 UTC
Location: Northern California
Latitude: 40.2860; Longitude: -124.3183
Depth: 19.90 km


From alter3d at alter3d.ca  Tue Feb 28 13:32:15 2012
From: alter3d at alter3d.ca (Peter Kristolaitis)
Date: Tue, 28 Feb 2012 14:32:15 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <BD92786C-5276-4DB2-A81C-473FB54D0E60@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <4F4CDEB5.8050802@illuminati.org>
 <BD92786C-5276-4DB2-A81C-473FB54D0E60@delong.com>
Message-ID: <4F4D2BBF.1090405@alter3d.ca>

Education in theoretical concepts is definitely a problem in general, 
but I've found it's particularly noticeable in the technology field 
which has become increasingly commercialized (or commoditized);  where 
once a "sysadmin" was a long-running process, grown from a person with 
the mindset of "how does this work?" and "let's build cool stuff!", 
eventually culminating in someone who knew operating systems, 
networking, and programming inside out (see: "UNIX greybeard" types), 
nowadays people haul off to a 5 day course in "Advanced System 
Administration(TM)", write a certificate exam or 15, and call themselves 
a "sysadmin".

There still are people with the "greybeard" mentality -- all of the very 
best sysadmins I know are of this type, and many know real programming 
(that is, data structures, algorithms, etc) better than the 
mass-produced developers our there -- but unfortunately, they're 
relatively rare, and usually very hard to recruit.   You have to have a 
very interesting project first and foremost -- salary is important, but 
building new, cool stuff is usually the #1 factor for top-notch 
generalists.

- Pete


On 12-02-28 01:51 PM, Owen DeLong wrote:
> This problem is not limited to programming.
>
> Education in general has moved from teaching conceptual knowledge
> re-inforced by practical examples and exercises to teaching methodological
> and/or procedural knowledge without any effort to convey concepts.
>
> It's much like the difference between teaching a man to buy a fish using
> cash vs. teaching a man more generalized economic skills and money
> management.
>
> In the former case, you get a man who can eat fish as long as he still
> has some cash. In the latter case, you get a man who can keep cash
> coming in and use it to obtain a varied diet and other things he may
> want.
>
> Today, the indoctrination mills (hard to call them education centers
> at this point) churn out people who are good at repeating the same
> process and solving the same problems over and over.
>
> Unfortunately, when faced with a problem that doesn't look like something
> from their text book, they either become completely lost or they take
> the hammer approach (when the only tool you have is a hammer, every
> problem looks like a nail).
>
> I'm not sure how to solve this. Teaching methodologically is much much
> faster than teaching conceptually and the endemic lack of patience makes it
> hard to get people to sit still long enough to learn conceptually.
>
> Owen
>
> On Feb 28, 2012, at 6:03 AM, John Mitchell wrote:
>
>> <rant>
>>
>> I would wholeheartedly agree with this, but I believe its worse than
>> just that. I used to categorize myself as a full developer, now I'm
>> slightly ashamed to be tainted with that brush since there's so many
>> people using the term who don't know the first thing about programming.
>>
>> It used to be that when you were taught programming, you were taught
>> concepts (when to use a for loop, while loop, Boolean algebra), then
>> you built on the foundations by learning advanced concepts  (data
>> structures, how to program concurrently using semaphores etc etc), you
>> would then pick some optional classes to make up for some non
>> programming specific knowledge (networking, linux admin, etc etc).
>>
>> I now have a lot of friends who work in academia and they are worried
>> by a decline (as am I when trying to hire new talent). Currently the
>> teaching process is one of learning to program like a monkey, monkey
>> see monkey do. People are no longer taught to think for themselves, but
>> instead taught to program in a specific language (PHP, Java, rarely C
>> or C++ any more, C#, or VB) and that is all they know. I don't believe
>> this is a failing with the lecturers but with the fundamental change in
>> attitudes to programming.
>>
>> One of the tests I give all interviewees is write a very short program
>> in a language they have never ever used before ( personally I recommend
>> http://en.wikipedia.org/wiki/Brainfuck ) since this gives people a
>> chance to show they can program rather than being able to tell me "I
>> know PHP" or "I know C", suprisingly very few newer programmers can
>> make it through, or even try it, because the concept of thinking for
>> themselves is so last year.
>>
>> </rant>
>>
>> On 27 February 2012 20:02:13, Brandt, Ralph wrote:
>>> Generalists are hard to come by these days. They are people who learn
>>> less and less about more and more till they know nothing about
>>> everything. People today are specializing in the left and right halves
>>> of the bytes....  They learn more and more about less and less till they
>>> know everything about nothing.  And BTW, they are worthless unless you
>>> have five of them working on a problem because none of them know enough
>>> to fix it.  Worse, you can replace the word five with fifty and it may
>>> be still true.
>>>
>>> I know of three of these, all gainfully employed at this time and could
>>> each find at least a couple jobs if they wanted.  I am one, my son is
>>> two and a guy we worked with is the third.
>>>
>>> At one time (40 years ago) the mantra in IS was train for expertise, now
>>> it is hire for it.  Somewhere there has to be a happy medium.  I suggest
>>> this, find a good coder, not a mediocre who writes shit code but a good
>>> one who can think and learn and when you talk about branching out with
>>> his skill set he or she lights up.  His first thing on site is take the
>>> A+ networking course.
>>>
>>> No, I do not sell the courses.  But I have seen this kind of approach
>>> work when nothing else was.
>>>
>>>
>>>
>>>
>>> Ralph Brandt
>>> Communications Engineer
>>> HP Enterprise Services
>>> Telephone +1 717.506.0802
>>> FAX +1 717.506.4358
>>> Email Ralph.Brandt at pateam.com
>>> 5095 Ritter Rd
>>> Mechanicsburg PA 17055
>>>
>>> -----Original Message-----
>>> From: A. Pishdadi [mailto:apishdadi at gmail.com]
>>> Sent: Sunday, February 26, 2012 8:27 PM
>>> To: NANOG
>>> Subject: Programmers with network engineering skills
>>>
>>> Hello All,
>>>
>>> i have been looking for quite some time now a descent coder (c,php) who
>>> has
>>> a descent amount of system admin / netadmin experience. Doesn't
>>> necessarily
>>> need to be an expert at network engineering but being acclimated in
>>> understanding the basic fundamentals of networking. Understanding basic
>>> routing concepts, how to diagnose using tcpdump / pcap, understanding
>>> subnetting and how bgp works (not necessarily setting up bgp). I've
>>> posted
>>> job listings on the likes of dice and monster and have not found any
>>> good
>>> canidates, most of them ASP / Java guys.
>>>
>>> If anyone can point me to a site they might recommend for job postings
>>> or
>>> know of any consulting firms that might provide these services that
>>> would
>>> be greatly appreciated.
>



From lowen at pari.edu  Tue Feb 28 13:35:49 2012
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 28 Feb 2012 14:35:49 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <11B1B530-B75C-4B60-B2A5-2F7B6365D333@delong.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <201202281435.49785.lowen@pari.edu>

On Monday, February 27, 2012 05:14:00 PM Owen DeLong wrote:
> Who is a strong network engineer
> Who has been a professional software engineer (though many years ago and my skills are rusty
> 	and out of date)

Owen, you nailed it here.  Even the ACM recognizes that a 'Software Engineer' and a 'Computer Scientist' are different animals (ACM recognizes five 'computer related' degree paths with unique skill maps: Computer Engineering, Computer Science, Software Engineering, Information Services, and Information Technology; see https://www.acm.org/education/curricula-recommendations for more details).

A true 'network engineer' will have a different mindset and different focus than a 'Computer Scientist' who has all the theoretical math skills that a Computer Scientist needs (a reply to one of my recent posts mentioned that math, and was somewhat derogatory about engineers and timeliness, but I digress). 

Coding and development can bridge across the differences; but it is very useful to understand some of the very basic differences in mindset, and apply that to the position being sought.  

It boils down to whether the OP wants strong engineering skills with the accompanying mindset, or strong CS skills with the accompanying mindset.  Given the other clearance issues, I would be more inclined to say that the OP would want a 'Software Engineer' with some network engineering skills rather than a CS grad with some network guy skills.  It's a different animal, and software engineering teaches change control and configuration management at a different depth than the typical CS track will do (and that sort of thing would be required in such a cleared environment).  On the flip side, that same 'Software Engineer' isn't nearly as steeped in CS fundamentals of algorithms and the associated math.


From owen at delong.com  Tue Feb 28 13:46:28 2012
From: owen at delong.com (Owen DeLong)
Date: Tue, 28 Feb 2012 11:46:28 -0800
Subject: Reliable Cloud host ?
In-Reply-To: <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
 <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>
Message-ID: <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com>


On Feb 28, 2012, at 10:22 AM, William Herrin wrote:

> On Tue, Feb 28, 2012 at 9:02 AM, Jared Mauch <jared at puck.nether.net> wrote:
>> On Feb 27, 2012, at 2:53 PM, Valdis.Kletnieks at vt.edu wrote:
>>> On Mon, 27 Feb 2012 14:02:04 EST, William Herrin said:
>>> 
>>>> The net result is that when you switch the IP address of your server,
>>>> a percentage of your users (declining over time) will be unable to
>>>> access it for hours, days, weeks or even years regardless of the DNS
>>>> TTL setting.
>>> 
>>> Amen brother.
>>> 
>>> So just for grins, after seeing William's I set up a listener on an address
>>> that had an NTP server on it many moons ago. As in the machine was shut down
>>> around 2002/06/30 22:49 and we didn't re-assign the IP address ever since
>>> *because* it kept getting hit with NTP packets..  Yes, a decade ago.
>>> 
>>> In the first 15 minutes, 234 different IP's have tried to NTP to that address.
>> 
>> I hereby reject the principle that one can not renumber a
>> host/name and move it.
>> I reject the idea that you can't move a service, or have one
>> MX, DNS, etc.. host be down and have it be fatal without
>> something else being SERIOUSLY broken.  If you are right,
>> nobody could ever renumber anything ever, nor take a
>> service down ever in the most absolute terms.
> 
> Something else IS seriously broken. Several something elses actually:
> 
> 1. DNS TTL at the application boundary, due in part to...

DNS TTL shouldn't make it to the application boundary...
> 
> 2. Pushing the name to layer 3 address mapping process up from layer 4
> to layer 7 where each application has to (incorrectly) reinvent the
> process, and...

But they don't have to... They can simply use getaddrinfo()/getnameinfo()
and let the OS libraries do it. The fact that some applications choose to
use their own resolvers instead of system libraries is what is broken.

> 3. A layer 4 protocol which overloads the layer 3 address as an
> inseverable component of its transport identifier.
> 
> Even stuff like SMTP which took care to respect the DNS TTL in its own
> standards gets busted at the back end: too many antispam process
> components rely on the source IP address, crushing large scale servers
> that suddenly appear, transmitting large amounts of email from a fresh
> IP address.

I think this is orthogonal to DNS TTL issues.

> Shockingly enough we have a strongly functional network despite this
> brokenness. But, it's broken all the same and renumbering is majorly
> impaired as a consequence.
> 

In my experience, the biggest hurdle to renumbering has nothing to do with DNS,
DNS TTLs, respect or failure to respect them, etc.

In my experience the biggest renumbering challenges come from the number of configuration
files which contain your IP addresses yet are not under your control.
	VPNs (the configuration at the far side of the VPN)
	Firewalls (vendors, clients, etc. that have put your IP addresses into exceptions)
	Router configurations (vendors, clients, etc. that have special routing policy to reach you)
	etc.

These are the things that make renumbering hard. The DNS stuff is usually fairly trivial to work around with a little time and planning.

> 
> Renumbering in light of these issues isn't impossible. An overlap
> period is required in which both old and new addresses are operable.

That's desirable even if you have a 5 second TTL and everyone did honor it.

> The duration of that overlap period is not defined by the the protocol
> itself. Rather, it varies with the tolerable level or residual
> brokenness, literally how many nines of users should be operating on
> the new address before the old address can go away.

There is some truth to that. The combination of applications having their
own (broken) resolver libraries and operating systems that provide even
more broken resolvers (thanks, Redmond) has made this a bigger challenge
than it should be. The ideal solution is to go back to using the OS resolver
libraries and fix them.

Best of luck actually achieving that.

Owen



From lowen at pari.edu  Tue Feb 28 13:51:00 2012
From: lowen at pari.edu (Lamar Owen)
Date: Tue, 28 Feb 2012 14:51:00 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <4F4CDEB5.8050802@illuminati.org>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
Message-ID: <201202281451.00623.lowen@pari.edu>

On Tuesday, February 28, 2012 09:03:33 AM John Mitchell wrote:
> One of the tests I give all interviewees is write a very short program 
> in a language they have never ever used before 

I typically recommend either Intercal, or one of various assembler languages that are out of date (well, not really out of date, but out of date for mainstream computing.  My old TRS-80 Z80 assembler skills come in handy when playing around with certain DVD drives' firmware, since a Z80 variant is used in many such drives).  Make 'em do something in 6502 that absolutely has to use page zero stuff, or in Z80 where a block instruction would be the best way to accomplish a task.  Or maybe handcoded ia64, or MIPS, the 6502's godgrandchildren....

Object shmobject, let me see the bytes!

And if they choose to try it in Intercal, they have to use at least two COME FROM statements.  In a 'Hello World' type program (of course, 'Hello World' in Intercal is, well, interesting, and reads like an obfuscated perl contest entry.  The point being, if you can make something useful happen in Intercal, you can probably do something useful in a sane language.

The skills I'm looking for are simple: be able to think sideways, and on your feet, with unfamiliar tools if necessary.  That is, be a quick study who doesn't cringe at any language, tool, toolkit, or technique that might need to be used.





From drais at icantclick.org  Tue Feb 28 14:50:51 2012
From: drais at icantclick.org (david raistrick)
Date: Tue, 28 Feb 2012 15:50:51 -0500 (EST)
Subject: Reliable Cloud host ?
In-Reply-To: <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
 <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>
 <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com>
Message-ID: <alpine.BSF.2.00.1202281542530.425@murf.icantclick.org>

On Tue, 28 Feb 2012, Owen DeLong wrote:

> But they don't have to... They can simply use getaddrinfo()/getnameinfo()
> and let the OS libraries do it. The fact that some applications choose to
> use their own resolvers instead of system libraries is what is broken.

Not always true - firewall software, for example, generally requires IP 
addresses in their rules (ipfw, pfsense, iptables, at least a few years 
ago) and for validly sane reasons (even some of our best kernel guys were 
not crazy enough to change that for ipfw).


Proxy software that supports high connection rates and connection churn 
generally prefer to cache the IP address internally because OS resolvers 
and the caches they read from just can't keep up [except in specificly 
well designed systems - which proxy developers can't expect blow joe to 
know how to do].  A stress test tool I'm working with just had to be 
modified for exactly that reason (and because adding more caches in front 
of AWS semiauthorative caches (due to split horizon) wouldn't solve 
anything.  a short TTL is a short TTL is a short TTL....).

Some of those proxy developers claim that within the chrootwhatchamajiggy 
that their socket handling code runs they don't have access to the 
resolvers - so they have to store them at startup (see haproxy).



--
david raistrick        http://www.netmeister.org/news/learn2quote.html
drais at icantclick.org             http://www.expita.com/nomime.html



From george.herbert at gmail.com  Tue Feb 28 14:59:39 2012
From: george.herbert at gmail.com (George Herbert)
Date: Tue, 28 Feb 2012 12:59:39 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <201202281421.17808.lowen@pari.edu>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
 <201202281421.17808.lowen@pari.edu>
Message-ID: <CAK__KzvfMaA+=p6BjoM8rkCp9WqXJdHXdFsKhJmkgE-syWQ=jg@mail.gmail.com>

On Tue, Feb 28, 2012 at 11:21 AM, Lamar Owen <lowen at pari.edu> wrote:
> On Monday, February 27, 2012 07:53:07 PM William Herrin wrote:
>> .../SCI clearance.
>>
>> The clearance is killing me. The two generalists didn't have a
>> clearance and the cleared applicants are programmers or admins but
>> never both.
>
> I just about spewed my chai tea seeing 'SCI' and 'generalist' in the same post... isn't that mutually exclusive?

There's a difference between the TS/SCI clearance - and SCI
compartmentalization security model for secure projects or information
- and whether you need a generalist programmer / network programmer to
solve the problem within the compartment or a specialist.

One can have very generalist problems within a very narrowly defined
security compartment.

One of my main hobbies, if done as a day job, would require TS/SCI
clearance plus an additional level; it requires about 8 or 9 major
scientific and engineering disciplines to master.


-- 
-george william herbert
george.herbert at gmail.com


From jeroen at mompl.net  Tue Feb 28 15:04:57 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Tue, 28 Feb 2012 13:04:57 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <4F4CDEB5.8050802@illuminati.org>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <4F4CDEB5.8050802@illuminati.org>
Message-ID: <4F4D4179.9050505@mompl.net>

John Mitchell wrote:
> <rant>
> 
> I would wholeheartedly agree with this, but I believe its worse than 

> teaching process is one of learning to program like a monkey, monkey 
> see monkey do. People are no longer taught to think for themselves, but 
> instead taught to program in a specific language (PHP, Java, rarely C 
> or C++ any more, C#, or VB) and that is all they know. I don't believe 
> this is a failing with the lecturers but with the fundamental change in 
> attitudes to programming.

The story of Mel comes to mind (one of my favourite):

http://www.catb.org/jargon/html/story-of-mel.html
http://www.catb.org/jargon/html/R/Real-Programmer.html

> http://en.wikipedia.org/wiki/Brainfuck ) since this gives people a 
> chance to show they can program rather than being able to tell me "I 
> know PHP" or "I know C", suprisingly very few newer programmers can 

I think someone being able to quickly understand brainfuck and write 
usable code in it may be smart, but I don't think it's necessarily a 
sure sign of a potentially productive employee that "fits well in the team".

Greetings,
Jeroen

-- 
Earthquake Magnitude: 3.5
Date: Tuesday, February 28, 2012 20:15:32 UTC
Location: Channel Islands region, California
Latitude: 33.9042; Longitude: -119.4195
Depth: 8.60 km


From marka at isc.org  Tue Feb 28 15:06:10 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 29 Feb 2012 08:06:10 +1100
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: Your message of "Tue, 28 Feb 2012 08:11:54 CDT."
 <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
 <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
 <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg@mail.gmail.com>
Message-ID: <20120228210610.C03B21DE58B4@drugs.dv.isc.org>


In message <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg at mail.gmail.com>,
 William Herrin writes:
> On Tue, Feb 28, 2012 at 12:45 AM, Mark Andrews <marka at isc.org> wrote:
> >        getaddrinfo was designed to be extensible as was struct
> >        addrinfo.  Part of the problem with TTL is not [all] dat=
> a sources
> >        used by getaddrinfo have TTL information.
> 
> Hi Mark,
> 
> By the time getaddrinfo replaced gethostbyname, NIS and similar
> systems were on their way out. It was reasonably well understood that
> many if not most of the calls would return information gained from the
> DNS. Depending on how you look at it, choosing not to propagate TTL
> knowledge was either a belligerent choice to continue disrespecting
> the DNS Time To Live or it was fatalistic acceptance that the DNS TTL
> isn't and would not become functional at the application level.

No.  Propogating TTL is still a issue especially when you do not always
have one.  You can't just wave the problem away.  As for DNS TTL addresses
are about the only thing which have multiple sources.  You also don't
have to use getaddrinfo.  It really is designed to be the first step in
connecting to a host.   If you need to reconnect you call it again.
 
> Still works fine deeper in the query system, timing out which server
> holds the records though.
> 
> 
> >        Additionally for
> >        many uses you want to reconnect to the same server rather
> >        than the same name.
> 
> The SRV record was designed to solve that whole class of problems
> without damaging the operation of the TTL. No one uses it.

You don't need to know the TTL to use SRV.
 
> It's all really very unfortunate. The recipe for SOHO multihoming, the
> end of routing table bloat and IP roaming without pivoting off a home
> base all boils down to two technologies: (1) a layer 4 protocol that
> can dynamically rebind to the layer 3 IP address the same way IP uses
> ARP to rebind to a changing ethernet MAC and (2) a DNS TTL that
> actually works so that the DNS supports finding a connection's current
> IP address.

DNS TTL works.  Applications that don't honour it arn't a indication that
it doesn't work.
 
> Regards,
> Bill Herrin
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org


From bill at herrin.us  Tue Feb 28 15:21:28 2012
From: bill at herrin.us (William Herrin)
Date: Tue, 28 Feb 2012 16:21:28 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <20120228210610.C03B21DE58B4@drugs.dv.isc.org>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
 <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
 <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg@mail.gmail.com>
 <20120228210610.C03B21DE58B4@drugs.dv.isc.org>
Message-ID: <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q@mail.gmail.com>

On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
> DNS TTL works. ?Applications that don't honour it arn't a indication that
> it doesn't work.

Mark,

If three people died and the building burned down then the sprinkler
system didn't work. It may have sprayed water, but it didn't *work*.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From ralph.brandt at pateam.com  Tue Feb 28 15:42:03 2012
From: ralph.brandt at pateam.com (Brandt, Ralph)
Date: Tue, 28 Feb 2012 16:42:03 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <4F4D4179.9050505@mompl.net>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <4F4CDEB5.8050802@illuminati.org> <4F4D4179.9050505@mompl.net>
Message-ID: <51C66083768C2949A7EB14910C78B0170184F2E0@embgsr24.pateam.com>

I would hope that the working with the team aspect would have been have been handled BEFORE you spend time on this.  Let HR do it, then check if they did it right because they screw it up at times. I have been overridden twice in hiring decisions over the years by my boss.  Both of them lived to regret that action.  Both were unsuitable because the person had character and personality flaws that made them unsuitable for any job except working more than 20 miles from Ted Kaminski.  




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


-----Original Message-----
From: Jeroen van Aart [mailto:jeroen at mompl.net] 
Sent: Tuesday, February 28, 2012 4:05 PM
To: NANOG list
Subject: Re: Programmers with network engineering skills

John Mitchell wrote:
> <rant>
> 
> I would wholeheartedly agree with this, but I believe its worse than 

> teaching process is one of learning to program like a monkey, monkey 
> see monkey do. People are no longer taught to think for themselves, but 
> instead taught to program in a specific language (PHP, Java, rarely C 
> or C++ any more, C#, or VB) and that is all they know. I don't believe 
> this is a failing with the lecturers but with the fundamental change in 
> attitudes to programming.

The story of Mel comes to mind (one of my favourite):

http://www.catb.org/jargon/html/story-of-mel.html
http://www.catb.org/jargon/html/R/Real-Programmer.html

> http://en.wikipedia.org/wiki/Brainfuck ) since this gives people a 
> chance to show they can program rather than being able to tell me "I 
> know PHP" or "I know C", suprisingly very few newer programmers can 

I think someone being able to quickly understand brainfuck and write 
usable code in it may be smart, but I don't think it's necessarily a 
sure sign of a potentially productive employee that "fits well in the team".

Greetings,
Jeroen

-- 
Earthquake Magnitude: 3.5
Date: Tuesday, February 28, 2012 20:15:32 UTC
Location: Channel Islands region, California
Latitude: 33.9042; Longitude: -119.4195
Depth: 8.60 km


From dnewman at networktest.com  Tue Feb 28 16:38:20 2012
From: dnewman at networktest.com (David Newman)
Date: Tue, 28 Feb 2012 14:38:20 -0800
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
In-Reply-To: <CAA8=vb6LJe4GZq3qyd4NDOEkZ-Mi=QGpX5w=zNzvNYxm6HBOQQ@mail.gmail.com>
References: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
 <20120228005014.GA20175@ref.nmedia.net>
 <CAA8=vb6LJe4GZq3qyd4NDOEkZ-Mi=QGpX5w=zNzvNYxm6HBOQQ@mail.gmail.com>
Message-ID: <4F4D575C.4000306@networktest.com>

On 2/28/12 2:55 AM, David Swafford wrote:

> Yeah, our vendors epically failed here!  

Were these QLogic 2400s or 2500s by any chance?

https://admin.fedoraproject.org/updates/F15/FEDORA-2012-1863

dn





From rcarpen at network1.net  Tue Feb 28 17:22:39 2012
From: rcarpen at network1.net (Randy Carpenter)
Date: Tue, 28 Feb 2012 18:22:39 -0500 (EST)
Subject: Time Warner Cable issues in Ohio ?
In-Reply-To: <2b4ee371-aeff-46cf-bcb7-800b3e02cfa7@zimbra.network1.net>
Message-ID: <2058610f-083b-4083-a275-08049ccb7c95@zimbra.network1.net>


We're seeing some strange issues with our fiber connection to TWC in Ohio. Intermittent packet loss to/from some IPs.

It gets as specific as from a certain IP outside our network, packets to a.b.c.10 are fine, but pings to a.b.c.50 (same subnet of same netblock) lose ~75% of the packets.

Likewise, from one of our IPs, connections are fine to a particular remote host, but not to another host on the same network.

Connections to/from some other IPs (and some whole networks) are totally fine.

It almost seems that some piece of gear somewhere is barfing on packets that have a particular set of bits in the source and/or destination address.

We have manually failed over to a backup connection, and are 100% fine now.

I just want to see if anyone has seen anything similar, or has any info. I am on hold now waiting for someone at TWC.

thanks,
-Randy


From jf at probe-networks.de  Tue Feb 28 17:38:01 2012
From: jf at probe-networks.de (Jonas Frey (Probe Networks))
Date: Wed, 29 Feb 2012 00:38:01 +0100
Subject: Time Warner Cable issues in Ohio ?
In-Reply-To: <2058610f-083b-4083-a275-08049ccb7c95@zimbra.network1.net>
References: <2058610f-083b-4083-a275-08049ccb7c95@zimbra.network1.net>
Message-ID: <1330472281.20248.316.camel@wks02>

Sounds very much like an issue with a link aggregation.
Seen this a couple of times with various carriers...apparently
monitoring lag's isnt a top priority nowadays.
Try to find out which hop is causing the problems (do multiple
traceroute's or use mtr on affected and unaffected servers) and drop TWC
a mail.


Am Dienstag, den 28.02.2012, 18:22 -0500 schrieb Randy Carpenter:
> We're seeing some strange issues with our fiber connection to TWC in Ohio. Intermittent packet loss to/from some IPs.
> 
> It gets as specific as from a certain IP outside our network, packets to a.b.c.10 are fine, but pings to a.b.c.50 (same subnet of same netblock) lose ~75% of the packets.
> 
> Likewise, from one of our IPs, connections are fine to a particular remote host, but not to another host on the same network.
> 
> Connections to/from some other IPs (and some whole networks) are totally fine.
> 
> It almost seems that some piece of gear somewhere is barfing on packets that have a particular set of bits in the source and/or destination address.
> 
> We have manually failed over to a backup connection, and are 100% fine now.
> 
> I just want to see if anyone has seen anything similar, or has any info. I am on hold now waiting for someone at TWC.
> 
> thanks,
> -Randy
> 



From mehmet at akcin.net  Tue Feb 28 17:44:19 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Tue, 28 Feb 2012 15:44:19 -0800
Subject: Alaska peering
Message-ID: <FA10E56D-913E-458E-A670-C7E03EF3EA7A@akcin.net>

Hi

I have read there was a discussion in 2010 regarding an IX in Alaska and whether it existed.

seems like the most logical point to get to Alaska is Seattle. Is that still the case? Is there any peering point in Alaska? 

please contact me offlist if you know some colo / Internet service provider there.

thanks.

mehmet

From pete at altadena.net  Tue Feb 28 17:58:10 2012
From: pete at altadena.net (Pete Carah)
Date: Tue, 28 Feb 2012 15:58:10 -0800
Subject: Time Warner Cable issues in Ohio ?
In-Reply-To: <2058610f-083b-4083-a275-08049ccb7c95@zimbra.network1.net>
References: <2058610f-083b-4083-a275-08049ccb7c95@zimbra.network1.net>
Message-ID: <8771CE5D-F214-4E20-BF82-35D6755C030E@altadena.net>



On Feb 28, 2012, at 15:22, Randy Carpenter <rcarpen at network1.net> wrote:

> 
> We're seeing some strange issues with our fiber connection to TWC in Ohio. Intermittent packet loss to/from some IPs.
> 
> It gets as specific as from a certain IP outside our network, packets to a.b.c.10 are fine, but pings to a.b.c.50 (same subnet of same netblock) lose ~75% of the packets.
> 
> Likewise, from one of our IPs, connections are fine to a particular remote host, but not to another host on the same network.
> 
> Connections to/from some other IPs (and some whole networks) are totally fine.
> 
> It almost seems that some piece of gear somewhere is barfing on packets that have a particular set of bits in the source and/or destination address.
> 
LACP somewhere with a partial link failure?

-- Pete



From dholmes at mwdh2o.com  Tue Feb 28 18:08:36 2012
From: dholmes at mwdh2o.com (Holmes,David A)
Date: Tue, 28 Feb 2012 16:08:36 -0800
Subject: Cisco ME3400
Message-ID: <922ACC42D498884AA02B3565688AF99534053132DB@USEXMBS01.mwd.h2o>

Anyone with advice on the ME3400 which some telcos use for Metro Ethernet Forum (MEF) services? Specifically looking for layer2 vs layer 3. At Layer 2 NNI/UNI vs dot1q qinq vs private VLANs. At Layer 3 multiple VRF CE/PE support. Specifically which connectivity options have been found to be most reliable and scalable.



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

From david at davidswafford.com  Tue Feb 28 19:19:16 2012
From: david at davidswafford.com (David Swafford)
Date: Tue, 28 Feb 2012 20:19:16 -0500
Subject: FCoE/CNA Deployment w/ Nexus 5K, HP 580s, QLogic
In-Reply-To: <4F4D575C.4000306@networktest.com>
References: <CAA8=vb6mJzCr3EpvY6n=2uCFdm5dxGNA5YdE_cj+XMJ-w-UpvQ@mail.gmail.com>
 <20120228005014.GA20175@ref.nmedia.net>
 <CAA8=vb6LJe4GZq3qyd4NDOEkZ-Mi=QGpX5w=zNzvNYxm6HBOQQ@mail.gmail.com>
 <4F4D575C.4000306@networktest.com>
Message-ID: <CAA8=vb6g8SUc8VktkWTdbgEc5194U4vt9ZRObuVn-6p1C=6JLw@mail.gmail.com>

The full SKU of the original cards was QLE8242-CU-CK (dual port copper).
 The replacements were the same, but SR instead of CU.  Here's a quick link
of detail on these cards --
http://www.qlogic.com/Resources/Documents/DataSheets/Adapters/Datasheet_8200_Series_Adapters.pdf
.

The copper cables/SFPs were Cisco's SFP-H10GB-CU5M and SFP-H10GB-CU3M,
which are listed on QLogic's list of approved cables:
http://www.qlogic.com/Resources/Documents/LineCards/Copper_Cables_Support_Matrix_Line_Card.pdf
.

I had a comment regarding the TCO of a Nexus 5548 w/ full SR SFPs vs.
copper  and yes, this is a significant cost increase, so be aware of that!
 Hopefully you're not paying retail for them :-), even w/ our discount it
was substantial.

David.



On Tue, Feb 28, 2012 at 5:38 PM, David Newman <dnewman at networktest.com>wrote:

> On 2/28/12 2:55 AM, David Swafford wrote:
>
> > Yeah, our vendors epically failed here!
>
> Were these QLogic 2400s or 2500s by any chance?
>
> https://admin.fedoraproject.org/updates/F15/FEDORA-2012-1863
>
> dn
>
>
>
>
>

From jeroen at mompl.net  Tue Feb 28 19:20:52 2012
From: jeroen at mompl.net (Jeroen van Aart)
Date: Tue, 28 Feb 2012 17:20:52 -0800
Subject: Programmers with network engineering skills
In-Reply-To: <5941B69EF8C7764DAE18F85A6A5A6AD018EED3@east-mail.photon.com>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
 <5941B69EF8C7764DAE18F85A6A5A6AD018EED3@east-mail.photon.com>
Message-ID: <4F4D7D74.7060407@mompl.net>

Jamie Bowden wrote:
> Hey now...the time from zero to TS/SCI has gone from over half a decade to a mere quarter decade.  You can totally pay these guys to sit around doing drudge work while their skills atrophy in the interim.  Of course, if you need a poly on top, add some more time and stir continually while applying heat.

I didn't know what TS/SCI exactly stood for. So I did some thorough 
research (read: wikipedia, so if I am wrong please correct me :-) and I 
found this:
http://en.wikipedia.org/wiki/List_of_U.S._security_clearance_terms#SCI_eligibility

"In general, employees do not publish the individual compartments for 
which they are cleared. While this information is not classified, 
specific compartment listings may reveal sensitive information when 
correlated with an individual's resume. Therefore, it is sufficient to 
declare that a candidate possesses a TS/SCI clearance with a polygraph."

That sparked my interest. Did I miss something? One can lie about TS/CSI 
clearance and be believed as long as one can fool a lie detector? How 
safe is that? That strikes me as a bit odd.

http://en.wikipedia.org/wiki/Polygraph#Validity
"Polygraphy has little credibility among scientists.[22][23] Despite 
claims of 90-95% validity by polygraph advocates, and 95-100% by 
businesses providing polygraph services,[non-primary source needed] 
critics maintain that rather than a "test", the method amounts to an 
inherently unstandardizable interrogation technique whose accuracy 
cannot be established"

-- 
Earthquake Magnitude: 4.7
Date: Tuesday, February 28, 2012 23:18:51 UTC
Location: Iran-Iraq border region
Latitude: 32.4895; Longitude: 47.1147
Depth: 10.20 km


From marka at isc.org  Tue Feb 28 19:46:56 2012
From: marka at isc.org (Mark Andrews)
Date: Wed, 29 Feb 2012 12:46:56 +1100
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: Your message of "Tue, 28 Feb 2012 16:21:28 CDT."
 <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <alpine.BSF.2.00.1202271543140.425@murf.icantclick.org>
 <CAP-guGVA4eHv0K=U=x2B-WPYDy2RQ7ZE1Di2AHc+dmA_huyGzA@mail.gmail.com>
 <51A4E832-3D01-4B9B-BBED-D05CFBF9425C@delong.com>
 <6252359949770844391@unknownmsgid>
 <20120228054527.2CF7B1DDE9D8@drugs.dv.isc.org>
 <CAP-guGV09HF7in+vZbKpGk0RR1Q4gpMMo5jQREUZVEj+ewzmkg@mail.gmail.com>
 <20120228210610.C03B21DE58B4@drugs.dv.isc.org>
 <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q@mail.gmail.com>
Message-ID: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>


In message <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q at mail.gmail.com>,
 William Herrin writes:
> On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
> > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
> at
> > it doesn't work.
> 
> Mark,
> 
> If three people died and the building burned down then the sprinkler
> system didn't work. It may have sprayed water, but it didn't *work*.

Not enough evidence to say if it worked or not.  Sprinkler systems
are designed to handle particular classes of fire, not every fire.

A 0 TTL means use this information for this transaction.  We don't
tear down TCP sessions on DNS TTL going to zero.

If one really want to deprecate addresses we need something a lot
more complicated than A and AAAA records in the DNS.  We need stuff
like "use this address for new transactions", "this address is going
away soon, don't use it unless no other works".  One also has to use
multiple addresses at the same time.

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


From os10rules at gmail.com  Tue Feb 28 20:03:04 2012
From: os10rules at gmail.com (Greg Ihnen)
Date: Tue, 28 Feb 2012 21:33:04 -0430
Subject: BBC reports Kenya fiber break
In-Reply-To: <20120228152315.GC43304@mikea.ath.cx>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
Message-ID: <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>


On Feb 28, 2012, at 10:53 AM, Mike Andrews wrote:

> On Mon, Feb 27, 2012 at 10:20:10AM -0800, virendra rode wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> On 02/27/2012 08:11 AM, Marshall Eubanks wrote:
>>> Is anyone seeing this ?
>>> 
>>> http://www.bbc.co.uk/news/world-africa-17179544
>>> 
>>> "East Africa's high-speed internet access has been severely disrupted
>>> after a ship dropped its anchor onto fibre-optic cables off Kenya's
>>> coast."
> 
> The ship was reported to have dropped anchor while in a restricted or
> prohibited area. These areas are _EXTREMELY_ well marked on charts. I can't
> see it being anything other than human or mechanical error: not checking if
> the ship is in a no-anchorage area, or the anchor chain wildcat brake _and_
> the anchor chain blocking device fail simultaneously, or watch officer
> totally mistakes the ship's location and orders the anchor to be let go.
> 
> -- 
> Mike Andrews, W5EGO
> mikea at mikea.ath.cx
> Tired old sysadmin 
> 

One more option:  engine or steering failure making dropping the hook an urgent necessity. What are the chances you'd hit a fiber-optic cable. ; - )

Greg

From gbonser at seven.com  Tue Feb 28 20:59:14 2012
From: gbonser at seven.com (George Bonser)
Date: Wed, 29 Feb 2012 02:59:14 +0000
Subject: Programmers with network engineering skills
In-Reply-To: <4F4D7D74.7060407@mompl.net>
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
 <5941B69EF8C7764DAE18F85A6A5A6AD018EED3@east-mail.photon.com>
 <4F4D7D74.7060407@mompl.net>
Message-ID: <596B74B410EE6B4CA8A30C3AF1A155EA09CEA689@RWC-MBX1.corp.seven.com>

> 
> That sparked my interest. Did I miss something? One can lie about
> TS/CSI clearance and be believed as long as one can fool a lie
> detector? How safe is that? That strikes me as a bit odd.
> 

Yeah, you missed something.  TS/SCI w/polygraph means that you underwent a Special Background Investigation *and* you passed a polygraph during an interview which is generally used to detect if you are being deceptive in your answers to questions, not so much to find "the truth".

And you can lie about the TS/SCI until it comes time to actually be cleared for work.  The "powers that be" will discover your lie before you ever emerge from the "leper colony" and your hopes of ever getting one at that point are headed down the drain.



From sikandar.raman at gmail.com  Tue Feb 28 21:44:50 2012
From: sikandar.raman at gmail.com (Ramanpreet Singh)
Date: Tue, 28 Feb 2012 19:44:50 -0800
Subject: Cisco ME3400
In-Reply-To: <922ACC42D498884AA02B3565688AF99534053132DB@USEXMBS01.mwd.h2o>
References: <922ACC42D498884AA02B3565688AF99534053132DB@USEXMBS01.mwd.h2o>
Message-ID: <CA+LM4FEiTDCZ5kccGQO=6yJ_obnYdAu0AYv-UOdcfXwqZtPAmA@mail.gmail.com>

Checkout me3600/me3800 ngn metro boxes which supports service level/efp
configuration. Also commonly known as cisco's evc infrastructute currently
supported on 7600 with es+ cards and asr 9k.

I dont think there is any other box from cost prespective which supports
most of the desired metro features as me3600/3800 does.
On Feb 28, 2012 4:08 PM, "Holmes,David A" <dholmes at mwdh2o.com> wrote:

> Anyone with advice on the ME3400 which some telcos use for Metro Ethernet
> Forum (MEF) services? Specifically looking for layer2 vs layer 3. At Layer
> 2 NNI/UNI vs dot1q qinq vs private VLANs. At Layer 3 multiple VRF CE/PE
> support. Specifically which connectivity options have been found to be most
> reliable and scalable.
>
>
>
>  ________________________________
> 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.
>

From babydr at baby-dragons.com  Tue Feb 28 23:33:06 2012
From: babydr at baby-dragons.com (Mr. James W. Laferriere)
Date: Tue, 28 Feb 2012 20:33:06 -0900 (AKST)
Subject: Alaska peering
In-Reply-To: <FA10E56D-913E-458E-A670-C7E03EF3EA7A@akcin.net>
References: <FA10E56D-913E-458E-A670-C7E03EF3EA7A@akcin.net>
Message-ID: <alpine.LNX.2.01.1202282032190.16495@filesrv1.baby-dragons.com>

 	Hello Mehmet ,

On Tue, 28 Feb 2012, Mehmet Akcin wrote:
> Hi
>
> I have read there was a discussion in 2010 regarding an IX in Alaska and whether it existed.
>
> seems like the most logical point to get to Alaska is Seattle. Is that still the case? Is there any peering point in Alaska?
>
> please contact me offlist if you know some colo / Internet service provider there.
>
> thanks.
>
> mehmet
 	Would you be so kind as to summerise any finding that you receive ?
 		Tia ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| babydr at baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+


From gary.buckmaster at digitalpacific.com.au  Wed Feb 29 00:01:21 2012
From: gary.buckmaster at digitalpacific.com.au (Gary Buckmaster)
Date: Wed, 29 Feb 2012 17:01:21 +1100
Subject: [Outages-discussion] Recent outage in Australia affecting Telstra
In-Reply-To: <1201724.391.1330098414072.JavaMail.root@benjamin.baylink.com>
References: <1201724.391.1330098414072.JavaMail.root@benjamin.baylink.com>
Message-ID: <4F4DBF31.7040909@digitalpacific.com.au>

On 2/25/2012 2:46 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Gert Doering" <gert at greenie.muc.de>
> 
>>> One of Telstra's downstream customers, a smaller ISP called Dodo,
>>> accidentally announced the global table to Telstra (or perhaps a very
>>> large portion of it.) Enough of it to cause major disruption.
>>
>> This is good. There is a chance that Telstra will learn from it, and
>> do proper customer-facing filters now.
>>
>> OTOH, there also is a chance that Telstra lawyers will just sue the
>> customer, and not change anything...
> 
> Perhaps.  I am not familiar with Australian jurisprudence, but the US there
> is the doctrine of Last Clear Chance[1]... and the work necessary on Telstra's
> part to avoid this problem is a) well known, b) arguably considered best
> practice for a company in their field, and c) not disproportionately 
> onorous for them to have undertaken...
> 
> so even if they sue, it's not at all a clear cut case for them to "win".
> 
> Cheers,
> -- jra 
> [1] https://en.wikipedia.org/wiki/Last_clear_chance

Being a relatively recent immigrant to Australia from the US, I can say
that, although I have no background in Australian legal shenanigans,
they aren't quite the litigious bastards we Americans tend to be.

Most of the commentary on AUSNOG tended towards "that was foolish,
hopefully they learn from that".  I suspect the chances of there being
any legal fallout from this are slim.


From skeeve at eintellego.net  Wed Feb 29 00:15:09 2012
From: skeeve at eintellego.net (Skeeve Stevens)
Date: Wed, 29 Feb 2012 06:15:09 +0000
Subject: [Outages-discussion] Recent outage in Australia affecting Telstra
In-Reply-To: <4F4DBF31.7040909@digitalpacific.com.au>
References: <1201724.391.1330098414072.JavaMail.root@benjamin.baylink.com>
 <4F4DBF31.7040909@digitalpacific.com.au>
Message-ID: <CAEUfUGPAoFLp0Gd6ctBYCOwnJPxyytbPiiP4b3pKb5O=3B7txg@mail.gmail.com>

I would probably suggest that there wouldn't be any.

*Skeeve Stevens, CEO*
eintellego Pty Ltd
skeeve at eintellego.net ; www.eintellego.net

Phone: 1300 753 383 ; Fax: (+612) 8572 9954

Cell +61 (0)414 753 383 ; skype://skeeve

facebook.com/eintellego

twitter.com/networkceoau ; www.linkedin.com/in/skeeve

PO Box 7726, Baulkham Hills, NSW 1755 Australia

The Experts Who The Experts Call
Juniper - Cisco ? Brocade - IBM



On Wed, Feb 29, 2012 at 06:01, Gary Buckmaster <
gary.buckmaster at digitalpacific.com.au> wrote:

> On 2/25/2012 2:46 AM, Jay Ashworth wrote:
> > ----- Original Message -----
> >> From: "Gert Doering" <gert at greenie.muc.de>
> >
> >>> One of Telstra's downstream customers, a smaller ISP called Dodo,
> >>> accidentally announced the global table to Telstra (or perhaps a very
> >>> large portion of it.) Enough of it to cause major disruption.
> >>
> >> This is good. There is a chance that Telstra will learn from it, and
> >> do proper customer-facing filters now.
> >>
> >> OTOH, there also is a chance that Telstra lawyers will just sue the
> >> customer, and not change anything...
> >
> > Perhaps.  I am not familiar with Australian jurisprudence, but the US
> there
> > is the doctrine of Last Clear Chance[1]... and the work necessary on
> Telstra's
> > part to avoid this problem is a) well known, b) arguably considered best
> > practice for a company in their field, and c) not disproportionately
> > onorous for them to have undertaken...
> >
> > so even if they sue, it's not at all a clear cut case for them to "win".
> >
> > Cheers,
> > -- jra
> > [1] https://en.wikipedia.org/wiki/Last_clear_chance
>
> Being a relatively recent immigrant to Australia from the US, I can say
> that, although I have no background in Australian legal shenanigans,
> they aren't quite the litigious bastards we Americans tend to be.
>
> Most of the commentary on AUSNOG tended towards "that was foolish,
> hopefully they learn from that".  I suspect the chances of there being
> any legal fallout from this are slim.
>
>

From joly at punkcast.com  Wed Feb 29 02:31:16 2012
From: joly at punkcast.com (Joly MacFie)
Date: Wed, 29 Feb 2012 03:31:16 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
Message-ID: <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>

A comment on the WSJ
story<http://online.wsj.com/article/SB10001424052970203833004577249434081658686.html>contains
a link to a great map.

http://www.submarinecablemap.com/

-- 
---------------------------------------------------------------
Joly MacFie  218 565 9365 Skype:punkcast
WWWhatsup NYC - http://wwwhatsup.com
 http://pinstand.com - http://punkcast.com
 VP (Admin) - ISOC-NY - http://isoc-ny.org
--------------------------------------------------------------
-

From jgreco at ns.sol.net  Wed Feb 29 06:57:17 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 29 Feb 2012 06:57:17 -0600 (CST)
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>
Message-ID: <201202291257.q1TCvHxJ072904@aurora.sol.net>

> In message <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q at mail.gmail.com>,
>  William Herrin writes:
> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
> > > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
> > at
> > > it doesn't work.
> > 
> > Mark,
> > 
> > If three people died and the building burned down then the sprinkler
> > system didn't work. It may have sprayed water, but it didn't *work*.
> 
> Not enough evidence to say if it worked or not.  Sprinkler systems
> are designed to handle particular classes of fire, not every fire.

It is also worth noting that many fire systems are not intended to
put out the fire, but to provide warning and then provide an extended
window for people to exit the affected building through use of sprinklers
and other measures to slow the spread of the fire.  As you suggest, most 
sprinkler systems are not actually designed to be able to completely 
extinguish fires - but that even applies to fires they are intended to be
able to "handle".  This is a common misunderstanding of the technology.

> A 0 TTL means use this information for this transaction.  We don't
> tear down TCP sessions on DNS TTL going to zero.
> 
> If one really want to deprecate addresses we need something a lot
> more complicated than A and AAAA records in the DNS.  We need stuff
> like "use this address for new transactions", "this address is going
> away soon, don't use it unless no other works".  One also has to use
> multiple addresses at the same time.

This has always been a weakness of the technology and documentation. 
The common usage scenario of static hosts and merely needing to be able 
to resolve a hostname to reach the traditional example of a "departmental 
server" or something like that is what most code and code examples are 
intended to tackle; very little of what developers are actually given (in 
real practical terms) even hints at needing to consider aspects such as 
TTL or periodically refreshing host->ip mappings, and most of the
documentation I've seen fails to discuss the implications of overloading
things like TTL for deliberate load-balancing or geo purposes.  Shocking
it's poorly understood by developers who just want their poor little 
program to connect over the Internet.

It's funny how these two technologies are both often misunderstood.  I
would not have thought of comparing DNS to fire suppression.  :-)

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From mikea at mikea.ath.cx  Wed Feb 29 07:04:43 2012
From: mikea at mikea.ath.cx (Mike Andrews)
Date: Wed, 29 Feb 2012 07:04:43 -0600
Subject: BBC reports Kenya fiber break
In-Reply-To: <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
Message-ID: <20120229130443.GA15832@mikea.ath.cx>

On Tue, Feb 28, 2012 at 09:33:04PM -0430, Greg Ihnen wrote:
> 
> On Feb 28, 2012, at 10:53 AM, Mike Andrews wrote:
> 
> > On Mon, Feb 27, 2012 at 10:20:10AM -0800, virendra rode wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA256
> >> 
> >> On 02/27/2012 08:11 AM, Marshall Eubanks wrote:
> >>> Is anyone seeing this ?
> >>> 
> >>> http://www.bbc.co.uk/news/world-africa-17179544
> >>> 
> >>> "East Africa's high-speed internet access has been severely disrupted
> >>> after a ship dropped its anchor onto fibre-optic cables off Kenya's
> >>> coast."
> > 
> > The ship was reported to have dropped anchor while in a restricted or
> > prohibited area. These areas are _EXTREMELY_ well marked on charts. I can't
> > see it being anything other than human or mechanical error: not checking if
> > the ship is in a no-anchorage area, or the anchor chain wildcat brake _and_
> > the anchor chain blocking device fail simultaneously, or watch officer
> > totally mistakes the ship's location and orders the anchor to be let go.
> > 
> > -- 
> > Mike Andrews, W5EGO
> > mikea at mikea.ath.cx
> > Tired old sysadmin 
> > 
> 
> One more option: engine or steering failure making dropping the hook an
> urgent necessity. What are the chances you'd hit a fiber-optic cable. ; -)

Good call. I'd not seen that one, but should have, and engineering
failures seem to be happening (or to be reported) rather more than they
used to. 

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


From rodrick.brown at gmail.com  Wed Feb 29 07:37:40 2012
From: rodrick.brown at gmail.com (Rodrick Brown)
Date: Wed, 29 Feb 2012 08:37:40 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
Message-ID: <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>

On Feb 29, 2012, at 3:31 AM, Joly MacFie <joly at punkcast.com> wrote:

> A comment on the WSJ
> story<http://online.wsj.com/article/SB10001424052970203833004577249434081658686.html>contains
> a link to a great map.
> 
> http://www.submarinecablemap.com/

There's about 1/2 a dozen or so known private and government research facilities on Antarctica and I'm surprised to see no fiber end points on that continent? This can't be true.

> 
> -- 
> ---------------------------------------------------------------
> Joly MacFie  218 565 9365 Skype:punkcast
> WWWhatsup NYC - http://wwwhatsup.com
> http://pinstand.com - http://punkcast.com
> VP (Admin) - ISOC-NY - http://isoc-ny.org
> --------------------------------------------------------------
> -


From jschauma at netmeister.org  Wed Feb 29 07:53:28 2012
From: jschauma at netmeister.org (Jan Schaumann)
Date: Wed, 29 Feb 2012 08:53:28 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
Message-ID: <20120229135328.GF24032@netmeister.org>

Joly MacFie <joly at punkcast.com> wrote:
> A comment on the WSJ
> story<http://online.wsj.com/article/SB10001424052970203833004577249434081658686.html>contains
> a link to a great map.
> 
> http://www.submarinecablemap.com/

I always liked this one, too:
http://is.gd/DXcddb

(Yes, flash. Still.)

-Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 478 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120229/866277b5/attachment.bin>

From Valdis.Kletnieks at vt.edu  Wed Feb 29 08:06:16 2012
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Wed, 29 Feb 2012 09:06:16 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: Your message of "Wed, 29 Feb 2012 08:37:40 EST."
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
Message-ID: <33165.1330524376@turing-police.cc.vt.edu>

On Wed, 29 Feb 2012 08:37:40 EST, Rodrick Brown said:
> There's about 1/2 a dozen or so known private and government research
> facilities on Antarctica and I'm surprised to see no fiber end points on that
> continent? This can't be true.

Cost-benefit.  A dozen sites, each with only 100-200 people, scattered across something
a tad bigger than Europe.  Even if you *land* a cable (which would be a technical
challenge, as there's few places you can land it without having to contend with an
ice shelf), the other 11 sites will *still* be so far away that dragging fiber to *there*
will be cost-impractical.  Especially the ones that are moving because they're actually
on glaciers or ice shelves.

But hey, if you think you can do it without going broke, go for it. ;)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20120229/16170de4/attachment.bin>

From bill at herrin.us  Wed Feb 29 08:18:47 2012
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Feb 2012 09:18:47 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <201202291257.q1TCvHxJ072904@aurora.sol.net>
References: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>
 <201202291257.q1TCvHxJ072904@aurora.sol.net>
Message-ID: <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>

On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco <jgreco at ns.sol.net> wrote:
>> In message <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q at mail.gmail.com>,
>> ?William Herrin writes:
>> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
>> > > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
>> > at
>> > > it doesn't work.
>> >
>> > Mark,
>> >
>> > If three people died and the building burned down then the sprinkler
>> > system didn't work. It may have sprayed water, but it didn't *work*.
>>
>> Not enough evidence to say if it worked or not. ?Sprinkler systems
>> are designed to handle particular classes of fire, not every fire.
>
> It is also worth noting that many fire systems are not intended to
> put out the fire, but to provide warning and then provide an extended
> window for people to exit the affected building through use of sprinklers
> and other measures to slow the spread of the fire.

Hi Joe,

The sprinkler system is designed to delay the fire long enough for
everyone to safely escape. As a secondary objective, it reduces the
fire damage that occurs while waiting for firefighters to arrive and
extinguish the fire. If "three people died" then the system failed.
Perhaps the design was inadequate. Perhaps some age-related issue
prevented the sprinkler heads from melting. Perhaps someone stacked
boxes to the ceiling and it blocked the water. Perhaps the water was
shut off and nobody knew it. Perhaps an initial explosion damaged the
sprinkler system so it could no longer work effectively. Whatever the
exact details, that sprinkler system failed.

Whoever you want to blame, DNS TTL dysfunction at the application
level is the same way. It's a failed system. With the TTL on an A
record set to 60 seconds, you can't change the address attached to the
A record and expect that 60 seconds later no one will continue to
connect to the old address. Nor 600 seconds later nor 6000 seconds
later. The "system" for renumbering a service of which the TTL setting
is a part consistently fails to reliably function in that manner.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From streiner at cluebyfour.org  Wed Feb 29 09:08:50 2012
From: streiner at cluebyfour.org (Justin M. Streiner)
Date: Wed, 29 Feb 2012 10:08:50 -0500 (EST)
Subject: BBC reports Kenya fiber break
In-Reply-To: <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
Message-ID: <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>

On Wed, 29 Feb 2012, Rodrick Brown wrote:

> There's about 1/2 a dozen or so known private and government research 
> facilities on Antarctica and I'm surprised to see no fiber end points on 
> that continent? This can't be true.

Constantly shifting ice shelves and glaciers make a terrestrial cable 
landing very difficult to implement on Antarctica.  Satellite connectivity
is likely the only feasible option.  There are very few places in
Antarctica that are reliably ice-free enough of the time to make a viable 
terrestrial landing station.  Getting connectivity from the landing 
station to other places on the continent is another matter altogether.

jms


From marshall.eubanks at gmail.com  Wed Feb 29 10:17:17 2012
From: marshall.eubanks at gmail.com (Marshall Eubanks)
Date: Wed, 29 Feb 2012 11:17:17 -0500
Subject: BBC reports Kenya fiber break
In-Reply-To: <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
 <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
Message-ID: <CAJNg7VKUeah+KsqF-Zd9sgC9HGh=D=urun3LyNHmsO-x5=0=Og@mail.gmail.com>

On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner
<streiner at cluebyfour.org> wrote:
> On Wed, 29 Feb 2012, Rodrick Brown wrote:
>
>> There's about 1/2 a dozen or so known private and government research
>> facilities on Antarctica and I'm surprised to see no fiber end points on
>> that continent? This can't be true.
>
>
> Constantly shifting ice shelves and glaciers make a terrestrial cable
> landing very difficult to implement on Antarctica. ?Satellite connectivity
> is likely the only feasible option. ?There are very few places in
> Antarctica that are reliably ice-free enough of the time to make a viable
> terrestrial landing station. ?Getting connectivity from the landing station
> to other places on the continent is another matter altogether.

Apparently at least one long fiber pull has been contemplated.

http://news.bbc.co.uk/2/hi/sci/tech/2207259.stm

(Note : the headline is incorrect - the Internet reached the South Pole in 1994,
via satellite, of course :
http://www.southpolestation.com/trivia/90s/ftp1.html )

As far as I can tell, this was never done, and the South Pole gets its
Internet mostly via
TDRSS.

http://www.usap.gov/technology/contentHandler.cfm?id=1971

Regards
Marshall

>
> jms
>


From internetplumber at gmail.com  Wed Feb 29 10:24:35 2012
From: internetplumber at gmail.com (Rob Evans)
Date: Wed, 29 Feb 2012 16:24:35 +0000
Subject: BBC reports Kenya fiber break
In-Reply-To: <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
 <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
Message-ID: <CACE4MRUQyduOQjOx7-HASrhO=izC+BQUko0nP8P-XLaaUttPHg@mail.gmail.com>

> Constantly shifting ice shelves and glaciers make a terrestrial cable
> landing very difficult to implement on Antarctica. ?Satellite connectivity
> is likely the only feasible option. ?There are very few places in
> Antarctica that are reliably ice-free enough of the time to make a viable
> terrestrial landing station. ?Getting connectivity from the landing station
> to other places on the continent is another matter altogether.

The British Antarctic Survey certainly use (used) satellite:

<http://www.antarctica.ac.uk/bas_research/techniques/tech7.php>

They gave a good presentation about it a couple of years ago:

<http://webmedia.company.ja.net/content/documents/shared/networkshop300310/blake_theuseofnetworksinthepolarregions.pdf>

Cheers,
Rob


From owen at delong.com  Wed Feb 29 12:01:12 2012
From: owen at delong.com (Owen DeLong)
Date: Wed, 29 Feb 2012 10:01:12 -0800
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
References: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>
 <201202291257.q1TCvHxJ072904@aurora.sol.net>
 <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
Message-ID: <41EEA4D9-E962-4B62-AA34-8ED5FF7430BE@delong.com>


On Feb 29, 2012, at 6:18 AM, William Herrin wrote:

> On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco <jgreco at ns.sol.net> wrote:
>>> In message <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q at mail.gmail.com>,
>>>  William Herrin writes:
>>>> On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
>>>>> DNS TTL works. =A0Applications that don't honour it arn't a indication th=
>>>> at
>>>>> it doesn't work.
>>>> 
>>>> Mark,
>>>> 
>>>> If three people died and the building burned down then the sprinkler
>>>> system didn't work. It may have sprayed water, but it didn't *work*.
>>> 
>>> Not enough evidence to say if it worked or not.  Sprinkler systems
>>> are designed to handle particular classes of fire, not every fire.
>> 
>> It is also worth noting that many fire systems are not intended to
>> put out the fire, but to provide warning and then provide an extended
>> window for people to exit the affected building through use of sprinklers
>> and other measures to slow the spread of the fire.
> 
> Hi Joe,
> 
> The sprinkler system is designed to delay the fire long enough for
> everyone to safely escape. As a secondary objective, it reduces the
> fire damage that occurs while waiting for firefighters to arrive and
> extinguish the fire. If "three people died" then the system failed.
> Perhaps the design was inadequate. Perhaps some age-related issue
> prevented the sprinkler heads from melting. Perhaps someone stacked
> boxes to the ceiling and it blocked the water. Perhaps the water was
> shut off and nobody knew it. Perhaps an initial explosion damaged the
> sprinkler system so it could no longer work effectively. Whatever the
> exact details, that sprinkler system failed.

Bill, you are blaming the sprinkler system for what could, in fact, be not
a failure of the sprinkler system, but, of the 3 humans.

If they were too intoxicated or stoned to react, for example, the sprinkler
system is not to blame. If they were overcome by smoke before the
sprinklers went off, that may be a failure of the smoke detectors, but, it
is not a failure of the sprinklers. If they were killed or rendered unconsious
and/or unresponsive in the preceding explosion you mentioned and did
not die in the subsequent fire, then, that is not a failure in the sprinkler
system.

> 
> Whoever you want to blame, DNS TTL dysfunction at the application
> level is the same way. It's a failed system. With the TTL on an A
> record set to 60 seconds, you can't change the address attached to the
> A record and expect that 60 seconds later no one will continue to
> connect to the old address. Nor 600 seconds later nor 6000 seconds
> later. The "system" for renumbering a service of which the TTL setting
> is a part consistently fails to reliably function in that manner.

Yes, the assumption by developers that gni/ghi is a fire-and-forget
mechanism and that the data received is static is a failure. It is not a
failure of DNS TTL. It is a failure of the application developers that
code that way. Further analysis of the underlying causes of that failure
to properly understand name resolution technology and the environment
in which it operates is left as an exercise for the reader.

The fact that people playing interesting games with DNS TTLs don't
necessarily understand or well document the situation to raise awareness
among application developers could also be argued to be a failure
on the part of those people.

It is not, in either case, a failure of the technology.

One should always call gni/gai in close temporal (and ideally close
in the code as well) proximity to calling connect(). Obviously one
should call these resolver functions prior to calling connect().

Most example code is designed for short-lived non-recovering flows,
so, it's designed along the lines of resolve->(iterate through results
calling connect() for each result untill connect() succeeds)->process->
close->exit.

Examples for persistent connections and/or connections that recover
or re-establish after a failure and/or browsers that stay running for a
long time and connect to the same system again significantly later
are few and far between. As a result, most code doing that ends up
being poorly written.

Further, DNS performance issues in the past have led developers of
such applications to "take matters into their own hands" to try and
improve the performance/behavior of their application in spite of
DNS. This is one of the things that led to many of the TTL ignorant
application-level DNS caches which you are complaining about.

Again, not a failure of DNS technology, but, of the operators of that
technology and the developers that tried to compensate for those
failures. They introduced a cure that is often worse than the disease.

Owen

> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004



From lanning at lanning.cc  Wed Feb 29 12:38:51 2012
From: lanning at lanning.cc (Robert Hajime Lanning)
Date: Wed, 29 Feb 2012 10:38:51 -0800
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <41EEA4D9-E962-4B62-AA34-8ED5FF7430BE@delong.com>
References: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>
 <201202291257.q1TCvHxJ072904@aurora.sol.net>
 <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
 <41EEA4D9-E962-4B62-AA34-8ED5FF7430BE@delong.com>
Message-ID: <4F4E70BB.9060101@lanning.cc>

On 02/29/12 10:01, Owen DeLong wrote:
> Further, DNS performance issues in the past have led developers of
> such applications to "take matters into their own hands" to try and
> improve the performance/behavior of their application in spite of
> DNS. This is one of the things that led to many of the TTL ignorant
> application-level DNS caches which you are complaining about.

I have found some carriers to run hacked nameservers.  Several years
ago I was moving a website and found that Cox was overriding the TTL
for all "www" names.  At least for their residential customers in
Oklahoma. The TTL value our test subject was getting was larger than
it had ever been set.

-- 
Mr. Flibble
King of the Potato People


From oscar.vives at gmail.com  Wed Feb 29 13:12:04 2012
From: oscar.vives at gmail.com (Tei)
Date: Wed, 29 Feb 2012 11:12:04 -0800
Subject: Reliable Cloud host ?
In-Reply-To: <alpine.BSF.2.00.1202281542530.425@murf.icantclick.org>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
 <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>
 <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com>
 <alpine.BSF.2.00.1202281542530.425@murf.icantclick.org>
Message-ID: <CACg3zYHSNeuLRWzKR7Ac-370KqTusc-FuQsSq=zFXTNQXc7C5A@mail.gmail.com>

related to the topic:
http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime

-- 
--
?in del ?ensaje.


From rs at seastrom.com  Wed Feb 29 13:12:51 2012
From: rs at seastrom.com (Robert E. Seastrom)
Date: Wed, 29 Feb 2012 14:12:51 -0500
Subject: Programmers with network engineering skills
In-Reply-To: <CAK__KzvRe+6G3t74sjD7n=nOCLjjyXKRvEM3QA+O8ZRwWqxEhw@mail.gmail.com> (George
 Herbert's message of "Mon, 27 Feb 2012 17:15:10 -0800")
References: <CAHGyo+-ewO5nZi6FECA_nBWSHvQ7h7-okTa51LiwRJJWYyAfRA@mail.gmail.com>
 <51C66083768C2949A7EB14910C78B0170184F278@embgsr24.pateam.com>
 <70AEFA48-0F1A-472D-8659-CD853854430E@delong.com>
 <CAP-guGV4hTVNfDuhA963GHNFW8L2FbmpmNqnAQJB7tXMZx1kuQ@mail.gmail.com>
 <4F4C28C2.9000706@i6ix.com>
 <CAK__KzvRe+6G3t74sjD7n=nOCLjjyXKRvEM3QA+O8ZRwWqxEhw@mail.gmail.com>
Message-ID: <868vjlh2rw.fsf@seastrom.com>


>> Is clearance the problem, or the ability to obtain clearance due to
>> something in their background? ?If your work requires it, you should have
>> some recourse for applicants to obtain the required clearance, no?
>
> My understanding is that while primary and subcontractor companies can
> put people in the sponsoring organization's clearance granting queue,
> it takes so long to get someone through the queue that for high-level
> positions they essentially make having the clearance already a
> prerequisite.

Things have gotten a lot better than they used to be.  My
understanding is that these days a DoD collateral TS is routinely
completed in < 6 months.

-r



From asusag at ifncom.net  Wed Feb 29 14:13:04 2012
From: asusag at ifncom.net (Andy Susag)
Date: Wed, 29 Feb 2012 15:13:04 -0500
Subject: Cisco ME3400
In-Reply-To: <CA+LM4FEiTDCZ5kccGQO=6yJ_obnYdAu0AYv-UOdcfXwqZtPAmA@mail.gmail.com>
References: <922ACC42D498884AA02B3565688AF99534053132DB@USEXMBS01.mwd.h2o>
 <CA+LM4FEiTDCZ5kccGQO=6yJ_obnYdAu0AYv-UOdcfXwqZtPAmA@mail.gmail.com>
Message-ID: <01245B4ABF809743A84B2F16C6598FEADD3FBD@hydrogen>

You'll need to use a metroipaccess image on the me3400 if you want more
than 2 NNI interfaces. We don't do any triple play or ETTH services so I
can't speak on that but as a layer 2 customer prem device for Carrier
Ethernet services it works well and it's hard to beat the price. Would
have been great if it was MPLS capable at its current price point
though! It's functional as a Layer 3 switch but I don't think it is very
robust as a router. If you are not married to Cisco, the Brocade CES is
worth looking in to. MPLS capable across all Ethernet ports. More
expensive though.

Andy S

-----Original Message-----
From: Ramanpreet Singh [mailto:sikandar.raman at gmail.com] 
Sent: Tuesday, February 28, 2012 22:45
To: Holmes,David A
Cc: North American Network Operators' Group
Subject: Re: Cisco ME3400

Checkout me3600/me3800 ngn metro boxes which supports service level/efp
configuration. Also commonly known as cisco's evc infrastructute
currently supported on 7600 with es+ cards and asr 9k.

I dont think there is any other box from cost prespective which supports
most of the desired metro features as me3600/3800 does.
On Feb 28, 2012 4:08 PM, "Holmes,David A" <dholmes at mwdh2o.com> wrote:

> Anyone with advice on the ME3400 which some telcos use for Metro 
> Ethernet Forum (MEF) services? Specifically looking for layer2 vs 
> layer 3. At Layer
> 2 NNI/UNI vs dot1q qinq vs private VLANs. At Layer 3 multiple VRF 
> CE/PE support. Specifically which connectivity options have been found

> to be most reliable and scalable.
>
>
>
>  ________________________________
> 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.
>


From jmkeller at houseofzen.org  Wed Feb 29 15:02:10 2012
From: jmkeller at houseofzen.org (James M Keller)
Date: Wed, 29 Feb 2012 16:02:10 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <4F4E70BB.9060101@lanning.cc>
References: <20120229014657.4D3DA1DEB044@drugs.dv.isc.org>
 <201202291257.q1TCvHxJ072904@aurora.sol.net>
 <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
 <41EEA4D9-E962-4B62-AA34-8ED5FF7430BE@delong.com>
 <4F4E70BB.9060101@lanning.cc>
Message-ID: <4F4E9252.7090800@houseofzen.org>

On 2/29/2012 1:38 PM, Robert Hajime Lanning wrote:
> On 02/29/12 10:01, Owen DeLong wrote:
>> Further, DNS performance issues in the past have led developers of
>> such applications to "take matters into their own hands" to try and
>> improve the performance/behavior of their application in spite of
>> DNS. This is one of the things that led to many of the TTL ignorant
>> application-level DNS caches which you are complaining about.
>
> I have found some carriers to run hacked nameservers.  Several years
> ago I was moving a website and found that Cox was overriding the TTL
> for all "www" names.  At least for their residential customers in
> Oklahoma. The TTL value our test subject was getting was larger than
> it had ever been set.
>

Back in the day, the uu.net cache servers where set for 24 hours (can't
remember if they claimed it was a performance issue or some other
justification).   Several other large ISPs of the day also did this, so
you typically got the "allow 24 hours for full propagation of DNS
changes ..." response when updating external DNS entries.   Nominal best
practice is to expect that and to run the service on old and new IPs for
at least 24 hours then start doing redirection (where possible by
protocol) or stop servicing the protocols on the old IP.


I'm sure other providers are doing the same to slow down fast flux
entries being used for spam site hosting today.

-- 
---
James M Keller



From jgreco at ns.sol.net  Wed Feb 29 15:02:47 2012
From: jgreco at ns.sol.net (Joe Greco)
Date: Wed, 29 Feb 2012 15:02:47 -0600 (CST)
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
Message-ID: <201202292102.q1TL2lpp077643@aurora.sol.net>

> On Wed, Feb 29, 2012 at 7:57 AM, Joe Greco <jgreco at ns.sol.net> wrote:
> >> In message <CAP-guGXK3WQGPLpmnVsnM0xnnU8==4zONK=UWTLkYWuduA6T9Q at mail.gmail.com>,
> >> ?William Herrin writes:
> >> > On Tue, Feb 28, 2012 at 4:06 PM, Mark Andrews <marka at isc.org> wrote:
> >> > > DNS TTL works. =A0Applications that don't honour it arn't a indication th=
> >> > at
> >> > > it doesn't work.
> >> >
> >> > Mark,
> >> >
> >> > If three people died and the building burned down then the sprinkler
> >> > system didn't work. It may have sprayed water, but it didn't *work*.
> >>
> >> Not enough evidence to say if it worked or not. ?Sprinkler systems
> >> are designed to handle particular classes of fire, not every fire.
> >
> > It is also worth noting that many fire systems are not intended to
> > put out the fire, but to provide warning and then provide an extended
> > window for people to exit the affected building through use of sprinklers
> > and other measures to slow the spread of the fire.
> 
> Hi Joe,
> 
> The sprinkler system is designed to delay the fire long enough for
> everyone to safely escape.

Hi Bill,

No, the sprinkler system is *intended* to delay the fire long enough
for everyone to safely escape, however, in order to accomplish this,
the designer chooses from some reasonable options to meet certain
goals that are commonly accepted to allow that.  For example, the
suppression design applied to a multistory dwelling where people
live, cook, and sleep is typically different from the single-story 
light office space.  Neither design will be effective against all
possible types of fire

> As a secondary objective, it reduces the
> fire damage that occurs while waiting for firefighters to arrive and
> extinguish the fire. If "three people died" then the system failed.

That's silly.  The system fails if the system *fails* or doesn't
behave as designed.  No system is capable of guaranteeing survival.

Just yesterday, here in Milwaukee, we had a child killed at a
railroad crossing.  The crossing was well-marked, with signals
and gates.  Visibility of approaching trains for close to a mile
in either direction.  The crew on the train saw him crossing,
blew their horn, laid on the emergency brakes.  CP Rail inspected
the gates and signals for any possible faults, but eyewitness
accounts were that the gates and signals were working, and the 
train made every effort to make itself known. 

The 11 year old kid had his hood up and earbuds in, and apparently
didn't see the signals or look up and down the track before crossing,
and for whatever reason, didn't hear the train horn blaring at him.

At a certain point, you just can't protect against every possible
bad thing that can happen.  I have a hard time seeing this as a
failure of the railroad's fully functional railroad crossing and
related safety mechanisms.  The system doesn't guarantee survival.

> Whoever you want to blame, DNS TTL dysfunction at the application
> level is the same way. It's a failed system. With the TTL on an A
> record set to 60 seconds, you can't change the address attached to the
> A record and expect that 60 seconds later no one will continue to
> connect to the old address. Nor 600 seconds later nor 6000 seconds
> later. The "system" for renumbering a service of which the TTL setting
> is a part consistently fails to reliably function in that manner.

It's a failure because people don't understand the intent of the system,
and it is pretty safe to argue that it is a multifaceted failure, due 
to failures by client implementations, server implementations, sample
code, attempts to use the system for things it wasn't meant for, etc. 
This is by no means limited to TTL; we've screwed up multiple addresses,
IPv6 handling, negative caching, um, do I need to go on...?

In the specific case of TTL, the problem is made much worse due to the
way most client code has hidden this data from developers, so that many
developers don't even have any idea that such a thing exists.

I'm not sure how to see that a design failure of the TTL mechanism.

I don't see developers ignoring DNS and hardcoding IP addresses into
code as a failure of the DNS system.

I see both as naive implementation errors.  The difference with TTL is
that the implementation errors are so widespread as to render any sane
implementation relatively useless.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.


From bill at herrin.us  Wed Feb 29 15:20:53 2012
From: bill at herrin.us (William Herrin)
Date: Wed, 29 Feb 2012 16:20:53 -0500
Subject: dns and software, was Re: Reliable Cloud host ?
In-Reply-To: <201202292102.q1TL2lpp077643@aurora.sol.net>
References: <CAP-guGVZfvMFjOah04W-18VpJiw5fYRXeKFr-pJJe0dW--xYNA@mail.gmail.com>
 <201202292102.q1TL2lpp077643@aurora.sol.net>
Message-ID: <CAP-guGUOjUKLa9eLfzqh3g-DV=86m=xJrf2zE4fTqu_cO9waBg@mail.gmail.com>

On Wed, Feb 29, 2012 at 4:02 PM, Joe Greco <jgreco at ns.sol.net> wrote:
> In the specific case of TTL, the problem is made much worse due to the
> way most client code has hidden this data from developers, so that many
> developers don't even have any idea that such a thing exists.
>
> I'm not sure how to see that a design failure of the TTL mechanism.

Hi Joe,

You shouldn't see that as a design failure of the TTL mechanism. It
isn't. It's a failure of the system of which DNS TTL is a component.
The TTL component itself was reasonably designed.

The failure is likened to installing a well designed sprinkler system
(the DNS with a TTL) and then shutting off the water valve
(gethostbyname/getaddrinfo).


> I don't see developers ignoring DNS and hardcoding IP addresses into
> code as a failure of the DNS system.

It isn't. It's a failure of the sockets API design which calls on
every application developer to (a) translate the name to a set of
addresses with a mechanism that discards the TTL knowledge and (b)
implement his own glue between name to address mapping and connect by
address.

It would be like telling an app developer: here's the ARP function and
the SEND function. When you Send to an IP address, make sure you
attach the right destination MAC. Of course the app developer gets it
wrong most of the time.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com? bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004


From bobbyjim at gmail.com  Wed Feb 29 15:24:12 2012
From: bobbyjim at gmail.com (Bobby Mac)
Date: Wed, 29 Feb 2012 15:24:12 -0600
Subject: Reliable Cloud host ?
In-Reply-To: <CACg3zYHSNeuLRWzKR7Ac-370KqTusc-FuQsSq=zFXTNQXc7C5A@mail.gmail.com>
References: <77160F42-2534-477D-A82B-C5097BCF3CE0@dragondata.com>
 <44403036-8fa4-4b76-a5da-5997692bb6a9@zimbra.network1.net>
 <CAP-guGV++cqRfNs9aC0zxRB0rLP4LgCAOTA+55ehELQP3QiFUA@mail.gmail.com>
 <76384BC9-336E-4048-976D-F1DF8091EED5@puck.nether.net>
 <CAP-guGVq=OPwZP7Fdyzv0_Ety4_5zDvBqXwSY1sUMpJGXDiGug@mail.gmail.com>
 <42252.1330372433@turing-police.cc.vt.edu>
 <E45FB3CC-DA59-46C7-8B1B-83AEAC2F5A66@puck.nether.net>
 <CAP-guGU11s-_2=WJVcVVo198nSi98Y5Kbv_OLEt_J=9Bj=ouNA@mail.gmail.com>
 <94C79C67-4111-44C0-9A0E-BC0552AA175D@delong.com>
 <alpine.BSF.2.00.1202281542530.425@murf.icantclick.org>
 <CACg3zYHSNeuLRWzKR7Ac-370KqTusc-FuQsSq=zFXTNQXc7C5A@mail.gmail.com>
Message-ID: <CAGREUyCgYBRr+7jr9uxFOt7iq0sH6S-3CxpC6dqJsL3=HP5uAg@mail.gmail.com>

HP has built an Openstack based cloud.  I got a beta account and things are
surprisingly stable.
hpcloud dot com

On Wed, Feb 29, 2012 at 1:12 PM, Tei <oscar.vives at gmail.com> wrote:

> related to the topic:
>
> http://slashdot.org/story/12/02/29/153226/microsofts-azure-cloud-suffers-major-downtime
>
> --
> --
> ?in del ?ensaje.
>
>

From dale.shaw+nanog at gmail.com  Wed Feb 29 18:29:25 2012
From: dale.shaw+nanog at gmail.com (Dale Shaw)
Date: Thu, 1 Mar 2012 11:29:25 +1100
Subject: WW: Colo Vending Machine
In-Reply-To: <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
Message-ID: <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>

Hi Jon,

On Tue, Feb 21, 2012 at 2:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
>
> Speaking of that sort of thing, I'd really LOVE if there were a device about
> the size of a netbook that could be hooked up to otherwise headless machines
> in colos that would give you keyboard, video & mouse. ?i.e. a folding
> netbook shaped VGA monitor with USB keyboard and touchpad. ?I know there are
> folding rackmount versions of this (i.e. from Dell), but I want something
> far more portable. ?Twice in the past month, I'd had to drive 100+ miles to
> a remote colo and took a full size flat panel monitor and keyboard with me.
> ?Has anyone actually built this yet?

What about something like this?

http://www.comsol.com.au/SL-PCC-01

cheers,
Dale


From nathan at atlasnetworks.us  Wed Feb 29 19:53:47 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 1 Mar 2012 01:53:47 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286EB939DC@EX-MB-1.corp.atlasnetworks.us>

> What about something like this?
> 
> http://www.comsol.com.au/SL-PCC-01
> 
> cheers,
> Dale
> 

Neat.  But, apparently comsol does not sell outside of the US.



From nathan at atlasnetworks.us  Wed Feb 29 19:55:42 2012
From: nathan at atlasnetworks.us (Nathan Eisenberg)
Date: Thu, 1 Mar 2012 01:55:42 +0000
Subject: WW: Colo Vending Machine
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286EB939DC@EX-MB-1.corp.atlasnetworks.us>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org> <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
 <8C26A4FDAE599041A13EB499117D3C286EB939DC@EX-MB-1.corp.atlasnetworks.us>
Message-ID: <8C26A4FDAE599041A13EB499117D3C286EB939FA@EX-MB-1.corp.atlasnetworks.us>

> Neat.  But, apparently comsol does not sell outside of the US.
> 
> 

I obviously need more coffee - I meant they do not sell *into* the US.  Apologies for the double-mail.



From dale.shaw+nanog at gmail.com  Wed Feb 29 19:56:51 2012
From: dale.shaw+nanog at gmail.com (Dale Shaw)
Date: Thu, 1 Mar 2012 12:56:51 +1100
Subject: WW: Colo Vending Machine
In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286EB939DC@EX-MB-1.corp.atlasnetworks.us>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
 <8C26A4FDAE599041A13EB499117D3C286EB939DC@EX-MB-1.corp.atlasnetworks.us>
Message-ID: <CAG_V287s5QJh6d-bmp2DoLACX11qK8CcHFTSjp8i_WyW0CssnQ@mail.gmail.com>

G'day Nathan,

On Thu, Mar 1, 2012 at 12:53 PM, Nathan Eisenberg
<nathan at atlasnetworks.us> wrote:
>
> Neat. ?But, apparently comsol does not sell outside of the US.

I didn't read the entire thread properly before posting my last
message (w/ link to Comsol site).

Someone else had already posted links to the same device on other
sites so I'm sure you could track one down with a bit of digging.

cheers,
Dale


From ted at io-tx.com  Wed Feb 29 21:50:29 2012
From: ted at io-tx.com (Ted Hatfield)
Date: Wed, 29 Feb 2012 21:50:29 -0600 (CST)
Subject: WW: Colo Vending Machine
In-Reply-To: <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
References: <7406565.3433.1329503715826.JavaMail.root@benjamin.baylink.com>
 <5F202126-FDB7-4C6C-A771-FDAFEEA414E5@gmail.com>
 <4F3EDAEF.1020909@thebaughers.com>
 <9C6F373F-FED6-4F3A-B2DF-F29C12E18B62@delong.com>
 <20120218074213.GK4990@hezmatt.org>
 <4F3F5D51.7060202@studio442.com.au>
 <20120219032255.GA30213@jeeves.rigozsaurus.com>
 <Pine.LNX.4.61.1202201028370.2201@soloth.lewis.org>
 <CAG_V284ctBPSc5P48AmJFb79FvijUQt565--WpLeCtqD7RBSow@mail.gmail.com>
Message-ID: <alpine.BSF.2.00.1202292149190.51337@io-tx.com>



On Thu, 1 Mar 2012, Dale Shaw wrote:

> Hi Jon,
>
> On Tue, Feb 21, 2012 at 2:34 AM, Jon Lewis <jlewis at lewis.org> wrote:
>>
>> Speaking of that sort of thing, I'd really LOVE if there were a device about
>> the size of a netbook that could be hooked up to otherwise headless machines
>> in colos that would give you keyboard, video & mouse. ?i.e. a folding
>> netbook shaped VGA monitor with USB keyboard and touchpad. ?I know there are
>> folding rackmount versions of this (i.e. from Dell), but I want something
>> far more portable. ?Twice in the past month, I'd had to drive 100+ miles to
>> a remote colo and took a full size flat panel monitor and keyboard with me.
>> ?Has anyone actually built this yet?
>
> What about something like this?
>
> http://www.comsol.com.au/SL-PCC-01
>
> cheers,
> Dale
>
>
>

Or something like this:

http://www.amazon.com/StarTech-Console-Portable-Adapter-NOTECONS01/dp/B002CLKFTQ/

Ted Hatfield

From mehmet at akcin.net  Wed Feb 29 23:21:19 2012
From: mehmet at akcin.net (Mehmet Akcin)
Date: Wed, 29 Feb 2012 21:21:19 -0800
Subject: BBC reports Kenya fiber break
In-Reply-To: <CAJNg7VKUeah+KsqF-Zd9sgC9HGh=D=urun3LyNHmsO-x5=0=Og@mail.gmail.com>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
 <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
 <CAJNg7VKUeah+KsqF-Zd9sgC9HGh=D=urun3LyNHmsO-x5=0=Og@mail.gmail.com>
Message-ID: <758C0573-EAEA-4FF8-8114-82DA31A3C709@akcin.net>


On Feb 29, 2012, at 8:17 AM, Marshall Eubanks wrote:

> On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner
> <streiner at cluebyfour.org> wrote:
>> On Wed, 29 Feb 2012, Rodrick Brown wrote:
>> 
>>> There's about 1/2 a dozen or so known private and government research
>>> facilities on Antarctica and I'm surprised to see no fiber end points on
>>> that continent? This can't be true.
>> 
>> 
>> Constantly shifting ice shelves and glaciers make a terrestrial cable
>> landing very difficult to implement on Antarctica.  Satellite connectivity
>> is likely the only feasible option.  There are very few places in
>> Antarctica that are reliably ice-free enough of the time to make a viable
>> terrestrial landing station.  Getting connectivity from the landing station
>> to other places on the continent is another matter altogether.
> 
> Apparently at least one long fiber pull has been contemplated.
> 
> http://news.bbc.co.uk/2/hi/sci/tech/2207259.stm
> 
> (Note : the headline is incorrect - the Internet reached the South Pole in 1994,
> via satellite, of course :
> http://www.southpolestation.com/trivia/90s/ftp1.html )
> 
> As far as I can tell, this was never done, and the South Pole gets its
> Internet mostly via
> TDRSS.
> 
> http://www.usap.gov/technology/contentHandler.cfm?id=1971

hmm antartica. that's very interesting place to deploy internet services ;)

> 
> Regards
> Marshall



From woody at pch.net  Wed Feb 29 23:45:16 2012
From: woody at pch.net (Bill Woodcock)
Date: Wed, 29 Feb 2012 21:45:16 -0800
Subject: BBC reports Kenya fiber break
In-Reply-To: <758C0573-EAEA-4FF8-8114-82DA31A3C709@akcin.net>
References: <CAJNg7VJEuKpxHZAUst9bpSwZGSVnx8+VyEEb-oGXjXiH9secrA@mail.gmail.com>
 <4F4BC95A.30307@gmail.com> <20120228152315.GC43304@mikea.ath.cx>
 <29AC3A99-40EC-469C-B72F-8032FC54D1CB@gmail.com>
 <CAM9VJk0taRwpZET=oOjvfYC9LnGVv7oED6w1Q3ZUWtgrU6ELUg@mail.gmail.com>
 <35A9ED71-EE80-444C-BAF4-1C403351FB56@gmail.com>
 <Pine.LNX.4.64.1202290938350.22197@whammy.cluebyfour.org>
 <CAJNg7VKUeah+KsqF-Zd9sgC9HGh=D=urun3LyNHmsO-x5=0=Og@mail.gmail.com>
 <758C0573-EAEA-4FF8-8114-82DA31A3C709@akcin.net>
Message-ID: <C970FF48-5F61-4180-BDFB-BC1E506382D0@pch.net>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

>> On Wed, Feb 29, 2012 at 10:08 AM, Justin M. Streiner
>> <streiner at cluebyfour.org> wrote:
>>> On Wed, 29 Feb 2012, Rodrick Brown wrote:
>>> 
>>>> There's about 1/2 a dozen or so known private and government research
>>>> facilities on Antarctica and I'm surprised to see no fiber end points on
>>>> that continent? This can't be true.
>>> 
>>> 
>>> Constantly shifting ice shelves and glaciers make a terrestrial cable
>>> landing very difficult to implement on Antarctica.  Satellite connectivity
>>> is likely the only feasible option.  There are very few places in
>>> Antarctica that are reliably ice-free enough of the time to make a viable
>>> terrestrial landing station.  Getting connectivity from the landing station
>>> to other places on the continent is another matter altogether.

There were INOC-DBA phones at several of the Antarctic stations, for quite a few years.  We could see connectivity to them go up and down as the satellites rose above the horizon and set again.

                                -Bill




-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJPTwztAAoJEG+kcEsoi3+HpgwP/2wjrnyjCoBrLgQYC/rsjVYe
uE8X9ZcnkAkBYI5Q3Aa3ZeVYNbUaX6OChgnsXlt+1v962Lja+V78QuthVDRCJ1Dp
Z5T+XtiIQB4u11lhN55mx8cPXbAKubGCduyCzjBBi+QqE5ayqqCocBHAItxYOMd7
RRS5ijNUKVMtGIWWWHAdMFAdGuy3zOIt/9oWkq9jJo30RJkEVR6pi7b/sGmM7rjX
XLVc1RPtCmtDkALohRyQOPrMJ2k7284fJ49t2P2Z/8yBbvJtGRmRBkTiUNis0wtx
Ndxed96TaNwwF3snE/zAxu6xCZnjR5trzC586b3ULS2sGSSo2W63AjOqzpMtb8HG
/hlK2GuaAe1vy9Qa+6XDwVJZqbkzPKzrNv7A3RjNvFkTapPGwk1FI7SBO46CUqHh
y2xED78JrIcoKTbC927eWrrArFGRe4ujx+w2D5enlZJT/vGonDScsE/ISAxITbCx
QHbtoAWIjVbraN1UZx+g9hvYOb3AT04zkTImQCj0Kj42COx729WvR7anrkwNNAJV
uqQyLK2wyS9ItyG3U54tECeGVeK0nn9Gyuhp9wdIKI4Qs+JHxXb2eHFqzbn9OZHB
O7PhbBTW3h+viNUkK2NnoiFbQP3E3ZzzNAKjTN9hWa15uGOKum5xUxSZFCD47BuD
J2CjI8dx5PhmLTbcZS4C
=M/np
-----END PGP SIGNATURE-----