- Test - lists.nanog.org

None
by None 12 Jul '07

12 Jul '07

enet.local> References: <8D870AB38C30EC4C848A11A3F83D20D8060A3EF41A(a)exchange2007.mmicmanhome net.local> X-Disclaimed: 54822 To: "nanog(a)merit.edu" <nanog(a)merit.edu> Subject: Re: Level(3) faux paux MIME-Version: 1.0 X-Mailer: Lotus Notes Build V80_M5_05202007 May 20, 2007 Message-ID: <OFC2D9836F.46E3A44F-ON85257316.00487CA5-85257316.004969A9(a)mail.kals ec.com> From: trainier(a)kalsec.com Date: Thu, 12 Jul 2007 09:18:12 -0400 X-MIMETrack: Serialize by Router on kalmail/Kalsec(Release 7.0.2FP1|January 10, 2007) at 07/12/2007 09:18:13 AM, Serialize complete at 07/12/2007 09:18:13 AM Content-Type: multipart/alternative; boundary="=_alternative 004969A585257316_=" Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu X-Loop: nanog X-Junkmail-Status: score=10/50, host=mozart.merit.edu X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.46962B88.0011:SCGAP167720,ss=1,fgs=0, ip=198.108.1.26, so=2006-09-22 03:48:54, dmn=5.3.14/2007-05-31 Status: RO X-Status: X-Keywords: X-UID: 7 This is a multipart message in MIME format. --=_alternative 004969A585257316_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable owner-nanog(a)merit.edu wrote on 07/12/2007 01:56:32 AM: > I have noticed that Level(3) misconfigs/outages seem to happen more=20 > frequently than with most other Tier 1?s. Am unsure whether or not=20 > this is a mis-statement, but based on NANOG posts, Level(3) [AS3356] > seems to show up more often with issues than say Sprint [AS1239]. As mentioned previously, there are a lot of variables that effect this=20 claim. =20 > Is their any one (or any coporation) that keeps track of outages=20 > such as these? Would think it might be a good thing to know for=20 > proper mulit-homing relationships to minimize the type of outage=20 > that Yahoo faced? A lot of businesses include this sort of data in their quarterly reports.=20 Some of your questions might be answered by reports like this one =3D>=20 http://www.level3.com/newsroom/pressreleases/2007/20070426.html Additionally, I'd do a Google search for terms like "System Availability"=20 and include some Tier 1 providers to see what kind of data comes back. Then just go from there. Tim Rainier =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=20 THIS E-MAIL is private correspondence and is intended only for the=20 identified recipients. We attempt to correctly address all e-mails, but if = for any reason you have received this message in error, please take notice = that you should not disclose or distribute this message to any other=20 person. You should immediately notify the sender and delete this message.=20 If the message contains or attaches CONFIDENTIAL information, you must=20 treat that information confidentially. For questions, please contact the=20 sender. --=_alternative 004969A585257316_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <tt>owner-nanog(a)merit.edu wrote on 07/12/2007 01:56:32 AM: > I have noticed that Level(3) misconfigs/outages seem to happen more > frequently than with most other Tier 1’s.  Am unsure whether or not > this is a mis-statement, but based on NANOG posts, Level(3) [AS3356]<b= r> > seems to show up more often with issues than say Sprint [AS1239].</fon= t></tt> <tt>As mentioned previously, there are a lot of variables that effect this claim.</tt> <tt>  > Is their any one (or any coporation) that keeps track of outages > such as these?  Would think it might be a good thing to know for > proper mulit-homing relationships to minimize the type of outage > that Yahoo faced…</tt> <tt>A lot of businesses include this sort of data in the= ir quarterly reports.  Some of your questions might be answered by= </tt> <tt>reports like this one =3D> </tt><a href=3D= http://www.level3.com/newsroom/pressreleases/2007/20070426.html><tt>http://www.level3.com/newsroom/pressreleases/2007/20070426.html</fo= nt></tt></a> <tt>Additionally, I'd do a Google search for terms like "System Availability" and include some Tier 1 providers to see</f= ont></tt> <tt>what kind of data comes back.  Then just go from there.</tt> <tt>Best regards,</tt> <tt>Tim Rainier</tt> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F THIS E-MAIL is private correspondence and is intended only for the identifi= ed recipients. We attempt to correctly address all e-mails, but if for any reason you have received this message in error, please take notice that you should not disclose or distribute this message to any other person. You should immediately notify the sender and delete this message. If the message contains or attaches CONFIDENTIAL information, you must treat that information confidentially. For questions, please contact the sender. --=_alternative 004969A585257316_=--

1 0

Re: Level(3) faux paux
by Chris L. Morrow 12 Jul '07

12 Jul '07

On Wed, 11 Jul 2007, Security Admin (NetSec) wrote: > I have noticed that Level(3) misconfigs/outages seem to happen more > frequently than with most other Tier 1's. Am unsure whether or not this maybe they have a larger change-rate? or more folks that notice problems and complain here? (note that I don't know but suspect everyone has a relatively close approximation of this figure at a certain place in the network-size-tiering) > show up more often with issues than say Sprint [AS1239]. Is their any (cause they don't let Ted on routers anymore...) > one (or any coporation) that keeps track of outages such as these? > Would think it might be a good thing to know for proper mulit-homing > relationships to minimize the type of outage that Yahoo faced... Because someone 3 as-hops away sucking down your prefix and traffic is your direct provider's problem how? -Chris

2 1

RE: Level(3) faux paux
by Neil J. McRae 12 Jul '07

12 Jul '07

Maybe level 3 have more vocal or higher profile customer base? Personally speaking I've found level 3 to have outstanding service and network availibility. Neil. -----Original Message----- From: Security Admin (NetSec) <secadmin(a)netsecdesign.com> Sent: 12 July 2007 06:56 To: nanog(a)merit.edu <nanog(a)merit.edu> Subject: Level(3) faux paux I have noticed that Level(3) misconfigs/outages seem to happen more frequently than with most other Tier 1s. Am unsure whether or not this is a mis-statement, but based on NANOG posts, Level(3) [AS3356] seems to show up more often with issues than say Sprint [AS1239]. Is their any one (or any coporation) that keeps track of outages such as these? Would think it might be a good thing to know for proper mulit-homing relationships to minimize the type of outage that Yahoo faced SecAdmin (aka Edward Ray)

1 0

reference page for IPv6 router
by Ruri Hiromi 10 Jul '07

10 Jul '07

Hello, We updated "Reference for IPv6 router settings" pages at team cymru. http://www.cymru.com/Bogons/v6top.html Any comments and suggestions are welcomed! Regards, ------------------------------- Ruri Hiromi ruri(a)bugest.net m owner-nanog(a)merit.edu Thu Jul 12 11:04:45 2007 -0400 Return-Path: <owner-nanog(a)merit.edu> Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by chopin.merit.edu (MOS 3.8.2-GA) with ESMTP id AFJ56547; Thu, 12 Jul 2007 11:04:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 998F04DF2E; Thu, 12 Jul 2007 11:01:08 -0400 (EDT) Delivered-To: nanog-outgoing(a)trapdoor.merit.edu Received: from localhost (localhost [127.0.0.1]) by trapdoor.merit.edu (Postfix) with ESMTP id 548924DF2A for <nanog-outgoing(a)trapdoor.merit.edu>; Thu, 12 Jul 2007 11:01:06 -0400 (EDT) X-Virus-Scanned: amavisd-new at merit.edu Received: from trapdoor.merit.edu ([127.0.0.1]) by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxzO1jXonCQa for <nanog-outgoing(a)trapdoor.merit.edu>; Thu, 12 Jul 2007 11:01:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C9C84DF47; Thu, 12 Jul 2007 11:00:57 -0400 (EDT) Delivered-To: nanog(a)trapdoor.merit.edu X-Virus-Scanned: amavisd-new at merit.edu Received: from trapdoor.merit.edu ([127.0.0.1]) by localhost (trapdoor.merit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSWy-o-lt-FV for <nanog(a)trapdoor.merit.edu>; Thu, 12 Jul 2007 11:00:45 -0400 (EDT) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 12 Jul 2007 16:02:03 +0100 Subject: FW: [address-policy-wg] IPv6 PI policy implemented From: JORDI PALET MARTINEZ <jordi.palet(a)consulintel.es> To: <nanog(a)nanog.org>, LACNIC Policy mailling list <politicas(a)lacnic.net> CC: "'Ernest Byaruhanga \\\\\\\\(AfriNIC\\\\\\\\)'" <ernest(a)afrinic.net> Message-ID: <C2BC00FB.1A7B30%jordi.palet(a)consulintel.es> Thread-Topic: [address-policy-wg] IPv6 PI policy implemented Thread-Index: AcfElZrS2ZbZEjCIEdyxQQAX8sYbNQ== In-Reply-To: <46962B72.8040703(a)afrinic.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet(a)consulintel.es X-HashCash: 1:20:070712:nanog@nanog.org::z5rK3vDGoK5VfKwH:0000000000000000000000 0000000000000000000000003Zmv X-Return-Path: jordi.palet(a)consulintel.es X-MDaemon-Deliver-To: nanog(a)nanog.org Reply-To: jordi.palet(a)consulintel.es Sender: owner-nanog(a)merit.edu Precedence: bulk Errors-To: owner-nanog(a)merit.edu FYI Regards, Jordi ------ Mensaje reenviado De: "Ernest Byaruhanga (AfriNIC)" <ernest(a)afrinic.net> Organizaci=F3n: AfriNIC - http://www.afrinic.net Responder a: <address-policy-wg-admin(a)ripe.net> Fecha: Thu, 12 Jul 2007 17:24:02 +0400 Para: <rpd(a)afrinic.net> CC: <afnog(a)afnog.org>, <announce(a)afrinic.net>, <afripv6-discuss(a)afrinic.net>, <ppml(a)arin.net>, <address-policy-wg(a)ripe.net>, <global-v6(a)apnic.net> Asunto: [address-policy-wg] IPv6 PI policy implemented Dear Colleagues, Please note that AfriNC has implemented the following policy: "IPv6 Provider Independent (PI) Assignment for End-Sites" http://www.afrinic.net/docs/policies/afpol-v6200701.htm We have consequently as of today started making /48 PI assignments from the following block: 2001:43f8::/29 You may need to adjust any filters in place accordingly. For more information, please see: http://www.afrinic.net/Registration/afsup-ipv6pi-assignments.htm Regards, Ernest AfriNIC ------ Fin del mensaje reenviado ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confiden tial. The information is intended to be for the use of the individual(s) named a bove. If you are not the intended recipient be aware that any disclosure, copyin g, distribution or use of the contents of this information, including attached f iles, is prohibited.

1 0

Yahoo outage summary
by Marcus H. Sachs 10 Jul '07

10 Jul '07

I put up a diary at the Storm Center (http://isc.sans.org/diary.html?storyid=3112) that summarizes what we know about the Yahoo outage on Friday. If anybody has any additional info they want to share or comments about the write-up please let me know. Marc -- Marc Sachs SANS ISC marc(a)sans.org

17 25

Level(3) filtering (was Yahoo outage summary)
by Kevin Epperson 10 Jul '07

10 Jul '07

There is some misinformation in previous posts that I would like to clarify on the Level 3 side of things. Every transit-like connection on AS3356 is prefix-filtered including all parties in this event. On AS3356 all prefix filters and import policies on BGP sessions are audited and checked in almost realtime for people or system errors (missing, mis-referenced, not referenced, otherwise broken config, etc.) The prefix filters themselves are generated using data from Level 3's own registry and known public route registries. As several folks have pointed out there are minimal checks for the validity of the source information. Further details on Level 3 filtering policies are available at: whois -h rr.level3.net AS3356 | grep remarks As an aside I see an increase in the number of downstreams asking for as-path filtering or *no* filtering usually with justifications of ISP X doesn't require us to register routes or just does as-path filtering. In my opinion that is bad news for everyone as documented in numerous BCPs, presentations and route-leaks. -Kevin Disclaimer - I do work for Level 3 but am expressing my opinions and not those of my employer.

3 2

RE: IP Allocations and moving AS numbers
by Azinger, Marla 09 Jul '07

09 Jul '07

Shane- Please redirect your email questions to ARIN ppml or discuss. That will be a better forum for you with these type of questions. I will also email you on the side. Cheers! Marla Azinger Frontier Communications AC Chair -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Shane Owens Sent: Monday, July 09, 2007 2:35 PM To: nanog(a)nanog.org Subject: IP Allocations and moving AS numbers All, I have been all but gone from IP management and BGP administration tasks for over 2 years while teaching myself telecom as a CLEC. I recently had a past business acquaintance contact me that is currently reselling bandwidth and using a 3rd parties network to do so. He currently has about 15 /24 address blocks through this 3rd party and wants to move to his own AS number and away from theirs. I know when I was last involved it seemed a pretty difficult process to do this through ARIN. Has the process changed at all recently? I am going to help them get the AS number and get the process started, but when asked if they could keep their existing IP address I explained that the existing 3rd party would need to write a letter stating that they are willing to transfer those IP's to your AS, ARIN would have to approve it and it may be a bit of a hassle. They are currently running 7 data centers nationally and are willing to migrate IP's, but would rather not if they can help it. Does this sound about right? I am going to go read the ARIN pages tonight to see if I can answer this myself, but don't have time during the workday to do a lot of research on this myself. Figure someone here probably knows already. Shane Owens DNA Communications shaneowens(a)dna-communications.com (w)815-562-4290 x-201 (c)815-793-3822

1 0

IP Allocations and moving AS numbers
by Shane Owens 09 Jul '07

09 Jul '07

All, I have been all but gone from IP management and BGP administration tasks for over 2 years while teaching myself telecom as a CLEC. I recently had a past business acquaintance contact me that is currently reselling bandwidth and using a 3rd parties network to do so. He currently has about 15 /24 address blocks through this 3rd party and wants to move to his own AS number and away from theirs. I know when I was last involved it seemed a pretty difficult process to do this through ARIN. Has the process changed at all recently? I am going to help them get the AS number and get the process started, but when asked if they could keep their existing IP address I explained that the existing 3rd party would need to write a letter stating that they are willing to transfer those IP's to your AS, ARIN would have to approve it and it may be a bit of a hassle. They are currently running 7 data centers nationally and are willing to migrate IP's, but would rather not if they can help it. Does this sound about right? I am going to go read the ARIN pages tonight to see if I can answer this myself, but don't have time during the workday to do a lot of research on this myself. Figure someone here probably knows already. Shane Owens DNA Communications shaneowens(a)dna-communications.com (w)815-562-4290 x-201 (c)815-793-3822

1 0

Re: Yahoo outage summary
by Jared Mauch 09 Jul '07

09 Jul '07

On Mon, Jul 09, 2007 at 01:23:46PM -0500, Borchers, Mark M. wrote: > Jared Mauch wrote: > > > The simple truth is that prefix lists ARE hard to manage. > > Medium-hard IMHO. Adding prefixes is relatively easy to implement. > Tracking and removing outdated information significantly more challenging. > > > Some people lack tools and automation to make it work or to manage their > networks. > > Best I can tell, even the largest transit providers handle prefix list > updates manually. Some have automated systems, but they're dependent on IRR data being correct. There are even tools to automate population of IRR data. > At this stage of history, a human interface is probably necessary in making > a reasonable > assessment about the legitimacy of an update request. I think here is one of the cruxes of the problem. If it requires a human, there's a few things that will happen: 1) prefix-list volume will be too much to be dealt with. I see some per-asn prefix lists that would be 255k routes and include all sorts of unreasonable junk like /32's 2) even taking a reasonable network, (in this case, i picked AS286) I see 4425 routes. Either you check these all manually (at least once), or come up with some way to model it. I currently see 250 routes in the table with as-path _286_ from my view. Either there's a lot of cruft there, or there's a lot of multihomed folks where i see a better path. Which is it? Do I have the time to crunch this myself? 3) What about those unique customer relationships? (this is made up) Like where ATT buys transit from Cogent for those few prefixes in New Zealand they care about? There's always some compelling business case to do something wonky. Does this mean that ATT needs to register their prefixes in the cogent IRR? How do you keep it 'quiet' that this is happening, instead of an object saying 'att priority customer route'? How do you validate these? Even the 'big guys' will make policy mistakes once in awhile. There needs to be some 'better-way' IMHO, but my ideas on this topic have not gotten far enough along for me to put code behind them. Perhaps I'll need to reprioritize those efforts. It seems to me like someone could do a cool system that churns through the route-views data, or if necessary just duplicate part of it by getting lots of bgp feeds and trying to parse the data. Too bad there's not a good way to do something like dampening on routes where depending on the age of the announcement and some 'trust' factor you can assign a series of local-preferences. I'd really like to see something like this exist. ie: "dampen" the "new" path (even if the prefix is a longer one) until some timer has ticked (unless some policy criteria are satisfied, such as same as-path, etc..). There's also the issue of how to implement this in the existing router(s), some of them with slower cpus. There's a lot of folks using older hardware to to bgp that just might melt if they had to evaluate some huge routing policy. - Jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

3 3

Vericenter Denver Outtage
by James Baldwin 09 Jul '07

09 Jul '07

Does anyone have further information on the Vericenter Denver outtage? Support is aware of the issue, however, they could not feed me a problem description at the time of ticket creation or an ETR? James Baldwin

1 1