- NANOG - lists.nanog.org

None
by None 12 Jul '07

12 Jul '07

m [65.199.113.8]) by bach.merit.edu (MOS 3.8.2-GA) with SMTP id ADV35111; Thu, 12 Jul 2007 14:42:17 -0400 (EDT) Received: from chiex01.int.tt.local ([172.17.250.113]) by chigtw01.tradingtechnologies.com (SMSSMTP 4.1.11.41) with SMTP id M200707121 3421723990 ; Thu, 12 Jul 2007 13:42:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: TCP congestion Date: Thu, 12 Jul 2007 13:42:05 -0500 Message-ID: <D4C8D8B144E6DE49AA3FC67557D58733061F4021@chiex01> In-Reply-To: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> Thread-Topic: TCP congestion Thread-Index: AcfEsRLuJSOqGHS0SfyYW+IzLHamswAAlz9w References: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> From: "Brian Knoll \(TTNET\)" <Brian.Knoll(a)tradingtechnologies.com> To: "Philip Lavine" <source_route(a)yahoo.com>, "nanog" <nanog(a)merit.edu> 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.46967698.00D0: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: 10 In order to solve this, you need to see a trace from both sides of the WAN. Which side is your trace from? Can you see the original ACK on both ends? =20 If the receiver is sending a DUP ACK, then the sender either never received the first ACK or it didn't receive it within the timeframe it expected. Brian -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Philip Lavine Sent: Thursday, July 12, 2007 1:07 PM To: nanog Subject: TCP congestion Can someone explain how a TCP conversation could degenerate into congestion avoidance on a long fat pipe if there is no packet/segment loss or out of order segments?=20 Here is the situation: WAN =3D 9 Mbps ATM connection between NY and LA (70 ms delay) LAN =3D Gig Ethernet Receiver: LA server =3D Win2k3 Sender: NY server =3D Linux 2.4 Data transmission typical =3D bursty but never more that 50% of CIR Segment sizes =3D 64k to 1460k but mostly less than 100k Typical Problem Scenario: Data transmission is humming along consistently at 2 Mbps, all of a sudden transmission rates drop to nothing then pickup again after 15-20 seconds. Prior to the drop off (based on packet capture) there is usually a DUP ACK/SACK coming from the receiver followed by the Retransmits and congestion avoidence. What is strange is there is nothing prior to the drop off that would be an impetus for congestion (no high BW utilization or packet loss). Also is there any known TCP issues between linux 2.4 kernel and windows 2003 SP1? Mainly are there issues regarding the handling of SACK, DUP ACK's and Fast Retransmits.=20 Of course we all know that this is not a application issue since developers make flawless socket code, but if it is network issue how is caused? Philip =20 ________________________________________________________________________ ____________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.=20 http://mobile.yahoo.com/go?refer=3D1GNXIC

1 0

None
by None 12 Jul '07

12 Jul '07

200.148]) by bach.merit.edu (MOS 3.8.2-GA) with SMTP id ADV33856; Thu, 12 Jul 2007 14:07:01 -0400 (EDT) Received: (qmail 28554 invoked by uid 60001); 12 Jul 2007 18:07:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type :Message-ID; b=APuO41mtUbbv7Tfogdu7M7Z+ddiGtGCzKxiCJpWXvwO7XmN2CAFEFw9HSb7LorrPXWZkNoKIp49h 8jzFCYl3gGq9gef8gW7q/ZLJlGT+MEg1L9rL2fbG6s2JrbB4PVse1gWDo6dimLY52iPHY0RZZe4tlc/D bqdScd/ltAG7MuA=; X-YMail-OSG: XhdJocUVM1mgMpKg.9cbhPFlvScQTvyLyESLUUlffJD4ymKreho8lQ9MTJLw9KYPZA- - Received: from [64.60.42.95] by web30805.mail.mud.yahoo.com via HTTP; Thu, 12 Ju l 2007 11:07:01 PDT X-Mailer: YahooMailRC/651.41 YahooMailWebService/0.7.41.16 Date: Thu, 12 Jul 2007 11:07:00 -0700 (PDT) From: Philip Lavine <source_route(a)yahoo.com> Subject: TCP congestion To: nanog <nanog(a)merit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Message-ID: <30366.27320.qm(a)web30805.mail.mud.yahoo.com> 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.0A090201.46966E45.006D: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: 8 Can someone explain how a TCP conversation could degenerate into congestion avoi dance on a long fat pipe if there is no packet/segment loss or out of order segm ents? Here is the situation: WAN = 9 Mbps ATM connection between NY and LA (70 ms delay) LAN = Gig Ethernet Receiver: LA server = Win2k3 Sender: NY server = Linux 2.4 Data transmission typical = bursty but never more that 50% of CIR Segment sizes = 64k to 1460k but mostly less than 100k Typical Problem Scenario: Data transmission is humming along consistently at 2 M bps, all of a sudden transmission rates drop to nothing then pickup again after 15-20 seconds. Prior to the drop off (based on packet capture) there is usually a DUP ACK/SACK coming from the receiver followed by the Retransmits and congesti on avoidence. What is strange is there is nothing prior to the drop off that wou ld be an impetus for congestion (no high BW utilization or packet loss). Also is there any known TCP issues between linux 2.4 kernel and windows 2003 SP1 ? Mainly are there issues regarding the handling of SACK, DUP ACK's and Fast Ret ransmits. Of course we all know that this is not a application issue since developers make flawless socket code, but if it is network issue how is caused? Philip ________________________________________________________________________________ ____ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC

1 0

RE: Level(3) faux paux
by David Hubbard 12 Jul '07

12 Jul '07

From: Valdis.Kletnieks(a)vt.edu > > Or maybe past experience has shown that the two have the same > *actual* failure rate, but asking for a Level3 help is more > likely to actually get you a clueful *and* helpful engineer. This has been my experience when we've had issues with any of the five companies we purchase from; Level 3 has consistently been able to put someone on the phone that actually knows how to resolve problems without even needing to call me back; most of the others we turn our link off because I know it's going to be several hours. David

1 0

None
by None 12 Jul '07

12 Jul '07

) by bach.merit.edu (MOS 3.8.2-GA) with ESMTP id ADV30699; Thu, 12 Jul 2007 11:53:05 -0400 (EDT) Received: from turing-police.cc.vt.edu (turing-police.cc.vt.edu [127.0.0.1]) by turing-police.cc.vt.edu (8.14.1/8.14.1) with ESMTP id l6CFr3ui002870; Thu, 12 Jul 2007 11:53:03 -0400 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: "Security Admin (NetSec)" <secadmin(a)netsecdesign.com> Cc: "nanog(a)merit.edu" <nanog(a)merit.edu> Subject: Re: Level(3) faux paux In-Reply-To: Your message of "Wed, 11 Jul 2007 22:56:32 PDT." <8D870AB38C30EC4C848A11A3F83D20D8060A3EF41A(a)exchange2007.mmicmanhom enet.local> From: Valdis.Kletnieks(a)vt.edu References: <8D870AB38C30EC4C848A11A3F83D20D8060A3EF41A(a)exchange2007.mmicmanhome net.local> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1184255583_3357P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 12 Jul 2007 11:53:03 -0400 Message-ID: <2869.1184255583(a)turing-police.cc.vt.edu> 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.0A090209.46964ED9.0113: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: 2 --==_Exmh_1184255583_3357P Content-Type: text/plain; charset=us-ascii On Wed, 11 Jul 2007 22:56:32 PDT, "Security Admin (NetSec)" said: > Am unsure whether or not this is a mis-statement, but based on NANOG posts, > Level(3) [AS3356] seems to show up mor=e often with issues than say Sprint > [AS1239]. How many places does AS3356 connect with other AS's, and how many places does AS1239 connec with other stuff? I'd expects an AS with 500 interchange points would have 25% more whoopsies than one with 400 interchanges even if they were otherwise equivalent. Another factor would be number of miles of fiber their net is run over - If backhoes per mile is a constant, a 3,000 mile link is more likely to be hit than one half as long, and so on. Or maybe Level3's network is more openly visible from outside, so it's easier to tell that they are the source of a problem than a net that's not easily debugged from outside the AS (leaving you wondering if it's them or somebody on the other side of them). Or maybe past experience has shown that the two have the same *actual* failure rate, but asking for a Level3 help is more likely to actually get you a clueful *and* helpful engineer. Plus, I don't think *any* provider gets mentioned enough on NANOG to be able to draw any realistic statistical inferences. The short-form highly inaccurate handwave is that you'd need *two* providers and at least 20-30 datapoints on *each* to draw conclusions - which would probably take you 2-3 years to collect, and at that point, changing management policies at both providers will render your results inaccurate (you'd be comparing 3-year old data to current). --==_Exmh_1184255583_3357P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Exmh version 2.5 07/13/2001 iD8DBQFGlk5fcC3lWbTT17ARAmk/AKCZXnSlaByL67fgcrcq9UwoxVFPwQCg8Oew rHXmKfeD0Mllu5T/6JqeqMw= =HeQA -----END PGP SIGNATURE----- --==_Exmh_1184255583_3357P--

1 0

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