From max.clark at gmail.com Sat May 1 11:07:08 2010 From: max.clark at gmail.com (Max Clark) Date: Sat, 1 May 2010 09:07:08 -0700 Subject: Internap Looking Glass / Route Server Message-ID: Hello, I'm looking for a public looking glass / route server connected to Internap - preferably in Los Angeles. Does such a thing exist? Thanks, Max From randy at psg.com Sat May 1 11:41:58 2010 From: randy at psg.com (Randy Bush) Date: Sat, 01 May 2010 18:41:58 +0200 Subject: Internap Looking Glass / Route Server In-Reply-To: References: Message-ID: > I'm looking for a public looking glass / route server connected to > Internap - preferably in Los Angeles. Does such a thing exist? similar subject, so excuse my piggybacking i am looking for looking glass softwhere which will run against junos, ios, and ios xr, so folk playing in the rpki origin validation testbed can see the effect of their certs/roas/... on the testbed routers. thanks. randy From scott at doc.net.au Sat May 1 13:37:32 2010 From: scott at doc.net.au (Scott Howard) Date: Sat, 1 May 2010 14:37:32 -0400 Subject: Internap Looking Glass / Route Server In-Reply-To: References: Message-ID: Internap do not have an external Looking Glass (not sure about Route Server, but I suspect it's the same). If you're a customer their helpdesk will run traceroutes/etc from a specific location if you ask, within reason of course... Scott. On Sat, May 1, 2010 at 12:07 PM, Max Clark wrote: > Hello, > > I'm looking for a public looking glass / route server connected to > Internap - preferably in Los Angeles. Does such a thing exist? > > Thanks, > Max > > From steve at ipv6canada.com Sat May 1 14:01:23 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Sat, 01 May 2010 15:01:23 -0400 Subject: Internap Looking Glass / Route Server In-Reply-To: References: Message-ID: <4BDC7A83.1060706@ipv6canada.com> On 2010.05.01 12:41, Randy Bush wrote: >> I'm looking for a public looking glass / route server connected to >> Internap - preferably in Los Angeles. Does such a thing exist? > > similar subject, so excuse my piggybacking > > i am looking for looking glass softwhere which will run against junos, > ios, and ios xr, so folk playing in the rpki origin validation testbed > can see the effect of their certs/roas/... on the testbed routers. ...and a request for off-list feedback but still borderline on topic... I'm interested in this too, specifically the RPKI aspect. I would have gone off-list with this, but I want to voice my interest. Randy, I'd be interested in asking some specifics... contact me off-list if you wouldn't mind. Steve From ml at kenweb.org Sat May 1 15:43:45 2010 From: ml at kenweb.org (ML) Date: Sat, 01 May 2010 16:43:45 -0400 Subject: Surcharge for providing Internet routes? Message-ID: <4BDC9281.50509@kenweb.org> Has anyone here heard of or do they themselves charge extra for providing a complete internet table to customers? Waive the surcharge for sufficiently large commits? From sethm at rollernet.us Sat May 1 15:59:27 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 01 May 2010 13:59:27 -0700 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: <4BDC962F.5010408@rollernet.us> On 5/1/2010 13:43, ML wrote: > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? > I've never heard of nor experienced that before. ~Seth From aaron at wholesaleinternet.net Sat May 1 16:00:23 2010 From: aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) Date: Sat, 1 May 2010 21:00:23 +0000 Subject: Surcharge for providing Internet routes? Message-ID: <1143170784-1272747624-cardhu_decombobulator_blackberry.rim.net-382493042-@bda075.bisx.prod.on.blackberry> Never heard of it. We don't do it. ------Original Message------ From: ML To: nanog at nanog.org Subject: Surcharge for providing Internet routes? Sent: May 1, 2010 3:43 PM Has anyone here heard of or do they themselves charge extra for providing a complete internet table to customers? Waive the surcharge for sufficiently large commits? Sent from my Verizon Wireless BlackBerry From steve at ipv6canada.com Sat May 1 16:42:11 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Sat, 01 May 2010 17:42:11 -0400 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: <4BDCA033.8030303@ipv6canada.com> On 2010.05.01 16:43, ML wrote: > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? ... I've never heard of it, but iow, I'd pay more if I could get my upstreams to provide the full table... Is there a market? I doubt it. Steve From patrick at ianai.net Sat May 1 16:46:22 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sat, 1 May 2010 17:46:22 -0400 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDCA033.8030303@ipv6canada.com> References: <4BDC9281.50509@kenweb.org> <4BDCA033.8030303@ipv6canada.com> Message-ID: <5E49E6D0-F093-4AFC-ABDC-D0E8EF2F0BD4@ianai.net> On May 1, 2010, at 5:42 PM, Steve Bertrand wrote: > On 2010.05.01 16:43, ML wrote: >> Has anyone here heard of or do they themselves charge extra for >> providing a complete internet table to customers? > > ... I've never heard of it, but iow, I'd pay more if I could get my > upstreams to provide the full table... > > Is there a market? I doubt it. Every "upstream" I've dealt with in the US & western Europe provides a full table if you ask. Kinda the point of being an "upstream". There are some countries where "Bee-Gee-Pee" is not understood, and they therefore do not speak it. If you buy transit from someone and they charge for setting up BGP and sending you a full table in the US, Canada, and most of Europe, I'd find another provider. That one probably isn't clueful enough to provide good service. In other parts of the planet, well, they probably still aren't clueful enough. :) But when the game is fixed, if it's the only game in town, you sometimes have to play anyway. -- TTFN, patrick From steve at ipv6canada.com Sat May 1 16:47:35 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Sat, 01 May 2010 17:47:35 -0400 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDCA033.8030303@ipv6canada.com> References: <4BDC9281.50509@kenweb.org> <4BDCA033.8030303@ipv6canada.com> Message-ID: <4BDCA177.3000107@ipv6canada.com> On 2010.05.01 17:42, Steve Bertrand wrote: > On 2010.05.01 16:43, ML wrote: >> Has anyone here heard of or do they themselves charge extra for >> providing a complete internet table to customers? > > ... I've never heard of it, but iow, I'd pay more if I could get my > upstreams to provide the full table... clarification... ...I'd pay a bit more if they would do BGP with me in the first place, let alone the size of the table I received... I think I was originally looking at the OP's question incorrectly... -sb From deleskie at gmail.com Sat May 1 17:14:16 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Sat, 1 May 2010 22:14:16 +0000 Subject: Surcharge for providing Internet routes? Message-ID: <1348015316-1272752053-cardhu_decombobulator_blackberry.rim.net-1339680108-@bda005.bisx.prod.on.blackberry> I've never heard of this either. -jim ------Original Message------ From: aaron at wholesaleinternet.net To: ML To: nanog at nanog.org ReplyTo: aaron at wholesaleinternet.net Subject: Re: Surcharge for providing Internet routes? Sent: May 1, 2010 6:00 PM Never heard of it. We don't do it. ------Original Message------ From: ML To: nanog at nanog.org Subject: Surcharge for providing Internet routes? Sent: May 1, 2010 3:43 PM Has anyone here heard of or do they themselves charge extra for providing a complete internet table to customers? Waive the surcharge for sufficiently large commits? Sent from my Verizon Wireless BlackBerry Sent from my BlackBerry device on the Rogers Wireless Network From johamby at blomand.net Sat May 1 17:36:41 2010 From: johamby at blomand.net (Joe Hamby) Date: Sat, 01 May 2010 17:36:41 -0500 Subject: Google Contact Message-ID: <20100501223602.7704D291B32@smtp1.av-mx.com> Is there anyone from Google on the list that can contact me off list to help with a "blocked" domain issue? Thanks in advance for any help. Joe Hamby From r.hyunseog at ieee.org Sat May 1 20:24:27 2010 From: r.hyunseog at ieee.org (Alex H. Ryu) Date: Sat, 01 May 2010 20:24:27 -0500 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: <4BDCD44B.9040904@ieee.org> Do you mean "Full routes" for BGP ? Sometimes there are extra charge for BGP, but never heard about full routes or not. How can they guarantee whether they provide Full routes or not ? If some routes are missing, are they going to provide the credit for it ? Full routes from BGP is always best-effort basis. So I don't think they can charge it based on whether it is full routes or not. They may charge for running BGP with you, but not for full routes or not. Alex ML wrote: > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? > > Waive the surcharge for sufficiently large commits? > > > > From matthew at corp.crocker.com Sat May 1 20:28:54 2010 From: matthew at corp.crocker.com (Matthew S. Crocker) Date: Sat, 1 May 2010 21:28:54 -0400 (EDT) Subject: Surcharge for providing Internet routes? In-Reply-To: <5E49E6D0-F093-4AFC-ABDC-D0E8EF2F0BD4@ianai.net> Message-ID: <1775725219.77174.1272763734547.JavaMail.root@zimbra1.crocker.com> We provide full tables to customers that ask, 99% of the time they don't know what they are asking for and don't really need it. full tables doesn't cost anything more but we only do it for our 100+meg customers. I don't for example do BGP with T1 level customers. -Matt ----- Original Message ----- > From: "Patrick W. Gilmore" > To: "NANOG list" > Sent: Saturday, May 1, 2010 5:46:22 PM > Subject: Re: Surcharge for providing Internet routes? > > On May 1, 2010, at 5:42 PM, Steve Bertrand wrote: > > On 2010.05.01 16:43, ML wrote: > >> Has anyone here heard of or do they themselves charge extra for > >> providing a complete internet table to customers? > > > > ... I've never heard of it, but iow, I'd pay more if I could get my > > upstreams to provide the full table... > > > > Is there a market? I doubt it. > > Every "upstream" I've dealt with in the US & western Europe provides a > full table if you ask. Kinda the point of being an "upstream". > > There are some countries where "Bee-Gee-Pee" is not understood, and > they therefore do not speak it. > > If you buy transit from someone and they charge for setting up BGP and > sending you a full table in the US, Canada, and most of Europe, I'd > find another provider. That one probably isn't clueful enough to > provide good service. > > In other parts of the planet, well, they probably still aren't clueful > enough. :) But when the game is fixed, if it's the only game in town, > you sometimes have to play anyway. > > -- > TTFN, > patrick -- Matthew S. Crocker President Crocker Communications, Inc. PO BOX 710 Greenfield, MA 01302-0710 http://www.crocker.com P: 413-746-2760 From nick at foobar.org Sun May 2 03:50:59 2010 From: nick at foobar.org (Nick Hilliard) Date: Sun, 2 May 2010 09:50:59 +0100 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDCA033.8030303@ipv6canada.com> References: <4BDC9281.50509@kenweb.org> <4BDCA033.8030303@ipv6canada.com> Message-ID: <2242A6CC-C263-4084-88AB-2B1C48AED040@foobar.org> On 1 May 2010, at 22:42, Steve Bertrand wrote: > On 2010.05.01 16:43, ML wrote: >> Has anyone here heard of or do they themselves charge extra for >> providing a complete internet table to customers? > > ... I've never heard of it, but iow, I'd pay more if I could get my > upstreams to provide the full table... I've seen the opposite-namely getting a substantial discount for moving from a default route feed to a dfz bgp feed. The rationale was that the default route ip connection was provisioned using hsrp on the provider side and came with a much stricter sla. Nick From randy at psg.com Sun May 2 05:14:40 2010 From: randy at psg.com (Randy Bush) Date: Sun, 02 May 2010 12:14:40 +0200 Subject: [ Internap ] Looking Glass / Route Server In-Reply-To: References: Message-ID: Mehmet Akcin recommended > http://wiki.version6.net/LG which looks good. but i am having some config problems o an update to makeaslist.pl is needed o i need docco for lg.conf is there a known mailing list? someone with a clue bat? randy From mpetach at netflight.com Sun May 2 22:27:56 2010 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 2 May 2010 20:27:56 -0700 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: On Sat, May 1, 2010 at 1:43 PM, ML wrote: > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? > > Waive the surcharge for sufficiently large commits? In Asia, there is a popular, but incorrectly named product offering that many ISPs sell called "domestic transit" which they sell for price $X; for "full routes" you often pay $2X-$3X. I grind my teeth every time I hear it, since "transit" doesn't mean "to select parts of the internet" in most people's eyes. It's really a paid peering offering, but no matter how much I try to correct people, the habit of calling it "domestic transit" still persists. :( Matt\ From aaron.glenn at gmail.com Sun May 2 23:16:48 2010 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Mon, 3 May 2010 04:16:48 +0000 Subject: International TE In-Reply-To: References: Message-ID: On Thu, Apr 29, 2010 at 6:41 PM, Arie Vayner wrote: > Thomas, > > Check this link: > http://onesc.net/communities/ here's a likely silly question: what's the thinking behind not purposefully and openly publishing available communities and their associated policy implications? difficulty? embarrassment? both? neither? From dorian at blackrose.org Sun May 2 23:27:42 2010 From: dorian at blackrose.org (Dorian Kim) Date: Mon, 3 May 2010 00:27:42 -0400 Subject: Surcharge for providing Internet routes? In-Reply-To: References: <4BDC9281.50509@kenweb.org> Message-ID: <20100503042741.GB85221@blackrose.org> On Sun, May 02, 2010 at 08:27:56PM -0700, Matthew Petach wrote: > In Asia, there is a popular, but incorrectly named product offering > that many ISPs sell called "domestic transit" which they sell > for price $X; for "full routes" you often pay $2X-$3X. I grind my > teeth every time I hear it, since "transit" doesn't mean "to select > parts of the internet" in most people's eyes. It's really a paid > peering offering, but no matter how much I try to correct people, > the habit of calling it "domestic transit" still persists. :( I don't think there is a universally agreed upon definition of what transit means other than it involves someone paying someone else. Just to clarify, there are both domestic transit and country specific paid peering products out there in Asia/Pacific region. I have no idea what the sales people call each in different countries, but domestic transit is not a misnomer as the ISP selling you this will be providing reacheability to their country specific customer base AND reacheability to their country specific peers. -dorian From owen at delong.com Mon May 3 00:49:21 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 2 May 2010 22:49:21 -0700 Subject: Surcharge for providing Internet routes? In-Reply-To: <20100503042741.GB85221@blackrose.org> References: <4BDC9281.50509@kenweb.org> <20100503042741.GB85221@blackrose.org> Message-ID: <0924A11F-ACAB-4A2A-B89B-AB9F1F8D805D@delong.com> On May 2, 2010, at 9:27 PM, Dorian Kim wrote: > On Sun, May 02, 2010 at 08:27:56PM -0700, Matthew Petach wrote: >> In Asia, there is a popular, but incorrectly named product offering >> that many ISPs sell called "domestic transit" which they sell >> for price $X; for "full routes" you often pay $2X-$3X. I grind my >> teeth every time I hear it, since "transit" doesn't mean "to select >> parts of the internet" in most people's eyes. It's really a paid >> peering offering, but no matter how much I try to correct people, >> the habit of calling it "domestic transit" still persists. :( > > I don't think there is a universally agreed upon definition of what > transit means other than it involves someone paying someone else. > Hurricane Electric routinely offers free transit on IPv6, and, we give free transit to many organizations on IPv4 as well. To us, transit means giving them routes that are not originated by our ASN or ASNs which are customers of our ASN. Owen From randy at psg.com Mon May 3 02:06:20 2010 From: randy at psg.com (Randy Bush) Date: Mon, 03 May 2010 09:06:20 +0200 Subject: Surcharge for providing Internet routes? In-Reply-To: <20100503042741.GB85221@blackrose.org> References: <4BDC9281.50509@kenweb.org> <20100503042741.GB85221@blackrose.org> Message-ID: > Just to clarify, there are both domestic transit and country specific > paid peering products out there in Asia/Pacific region. and europe. and ... randy From adrian.minta at gmail.com Mon May 3 04:50:02 2010 From: adrian.minta at gmail.com (Adrian M) Date: Mon, 3 May 2010 12:50:02 +0300 Subject: MikroTik strikes again ? Message-ID: MikroTik strikes again ? %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 received from xxxx: More than configured MAXAS-LIMIT aut-num: AS39625 as-name: ARANEO-AS descr: Omni-Araneo's AS number org: ORG-OSTW3-RIPE import: from AS12968 action pref=100; accept ANY export: to AS12968 announce AS39625 import: from AS39412 action pref=100; accept ANY export: to AS39412 announce AS39625 admin-c: TW1273-RIPE tech-c: TW1273-RIPE mnt-by: AS12968-MNT mnt-routes: AS12968-MNT source: RIPE # Filtered From bclark at spectraaccess.com Mon May 3 05:25:45 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 03 May 2010 06:25:45 -0400 Subject: MikroTik strikes again ? In-Reply-To: References: Message-ID: <4BDEA4A9.9020904@spectraaccess.com> Uhm....okay...but why does anyone prepend their ASN that much? Are you saying the Mikrotik did that on purpose? Adrian M wrote: > MikroTik strikes again ? > > %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > 39625 39625 39625 39625 received from xxxx: More than configured > MAXAS-LIMIT > > aut-num: AS39625 > as-name: ARANEO-AS > descr: Omni-Araneo's AS number > org: ORG-OSTW3-RIPE > import: from AS12968 action pref=100; accept ANY > export: to AS12968 announce AS39625 > import: from AS39412 action pref=100; accept ANY > export: to AS39412 announce AS39625 > admin-c: TW1273-RIPE > tech-c: TW1273-RIPE > mnt-by: AS12968-MNT > mnt-routes: AS12968-MNT > source: RIPE # Filtered > > From timoid at timoid.org Mon May 3 05:38:50 2010 From: timoid at timoid.org (Tim Warnock) Date: Mon, 3 May 2010 20:38:50 +1000 Subject: MikroTik strikes again ? In-Reply-To: <4BDEA4A9.9020904@spectraaccess.com> References: <4BDEA4A9.9020904@spectraaccess.com> Message-ID: <00df01caeaac$d4dc43c0$7e94cb40$@org> > Adrian M wrote: > > MikroTik strikes again ? > > > > %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625 > > 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 > > From: Bret Clark [mailto:bclark at spectraaccess.com] > Sent: Monday, 3 May 2010 8:26 PM > To: nanog at nanog.org > Subject: Re: MikroTik strikes again ? > > Uhm....okay...but why does anyone prepend their ASN that much? Are you > saying the Mikrotik did that on purpose? > MikroTik asks for an amount of prepends rather than what ASN to prepend with. There was a bug in an old version that would modulus the ASN with 256 and prepend that many times. In this case 39625 modulo 256 = 201 prepends. From christian at dnet.net.id Mon May 3 05:43:40 2010 From: christian at dnet.net.id (Christian) Date: Mon, 03 May 2010 17:43:40 +0700 Subject: MikroTik strikes again ? In-Reply-To: <4BDEA4A9.9020904@spectraaccess.com> References: <4BDEA4A9.9020904@spectraaccess.com> Message-ID: <4BDEA8DC.6080907@dnet.net.id> It's not really a bug, only a matter of habbit I guess :) I read this some time ago in nanog list: http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml regards, Christian Bret Clark wrote: > Uhm....okay...but why does anyone prepend their ASN that much? Are you > saying the Mikrotik did that on purpose? > > Adrian M wrote: >> MikroTik strikes again ? >> >> %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >> 39625 39625 39625 39625 received from xxxx: More than configured >> MAXAS-LIMIT >> >> aut-num: AS39625 >> as-name: ARANEO-AS >> descr: Omni-Araneo's AS number >> org: ORG-OSTW3-RIPE >> import: from AS12968 action pref=100; accept ANY >> export: to AS12968 announce AS39625 >> import: from AS39412 action pref=100; accept ANY >> export: to AS39412 announce AS39625 >> admin-c: TW1273-RIPE >> tech-c: TW1273-RIPE >> mnt-by: AS12968-MNT >> mnt-routes: AS12968-MNT >> source: RIPE # Filtered >> >> From bclark at spectraaccess.com Mon May 3 05:44:53 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Mon, 03 May 2010 06:44:53 -0400 Subject: MikroTik strikes again ? In-Reply-To: <00df01caeaac$d4dc43c0$7e94cb40$@org> References: <4BDEA4A9.9020904@spectraaccess.com> <00df01caeaac$d4dc43c0$7e94cb40$@org> Message-ID: <4BDEA925.1090906@spectraaccess.com> Tim Warnock wrote: >> Adrian M wrote: >> >>> MikroTik strikes again ? >>> >>> %BGP-6-ASPATH: Long AS path ... 39412 39625 39625 39625 39625 39625 >>> 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 39625 >>> >> From: Bret Clark [mailto:bclark at spectraaccess.com] >> Sent: Monday, 3 May 2010 8:26 PM >> To: nanog at nanog.org >> Subject: Re: MikroTik strikes again ? >> >> Uhm....okay...but why does anyone prepend their ASN that much? Are you >> saying the Mikrotik did that on purpose? >> >> > > MikroTik asks for an amount of prepends rather than what ASN to prepend > with. > > There was a bug in an old version that would modulus the ASN with 256 and > prepend that many times. > > In this case 39625 modulo 256 = 201 prepends. > > > > Yeah...guess I see why that would be a problem. From a.harrowell at gmail.com Mon May 3 05:48:42 2010 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Mon, 3 May 2010 11:48:42 +0100 Subject: MikroTik strikes again ? In-Reply-To: <4BDEA4A9.9020904@spectraaccess.com> References: <4BDEA4A9.9020904@spectraaccess.com> Message-ID: <201005031149.00695.a.harrowell@gmail.com> On Monday 03 May 2010 11:25:45 Bret Clark wrote: > Uhm....okay...but why does anyone prepend their ASN that much? Are you > saying the Mikrotik did that on purpose? > There was a well-known routing incident last year in which a difference between the Mikrotik and Cisco CLIs caused the propagation of extremely long AS-PATH attributes, which caused certain Cisco routers to crash. Basically, someone remembered their Cisco IOS syntax and typed "bgp-prepend 47868" into a Mikrotik; the correct syntax would have been "bgp-prepend x 47868" where x is an integer between 0 and 16 representing the desired number of prepends. The Mikrotik correctly tried to prepend 47868 47868 times, but had only one byte to store this value and therefore produced 255 prepends. Some Cisco machines, it turned out, had a bug that caused path lengths close to 255 to crash them. Fun and games ensued. The Renesys blog has much, much more: http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From joe.abley at icann.org Mon May 3 07:17:48 2010 From: joe.abley at icann.org (Joe Abley) Date: Mon, 3 May 2010 05:17:48 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: <046A19F5-7DC1-4585-9DB6-FC19BEB84BFC@icann.org> Root Zone DNSSEC Deployment Technical Status Update 2010-05-03 This is the fifth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. ** The final transition to the DURZ will take place on ** J-Root, on 2010-05-05 between 1700--1900 UTC. ** ** After that maintenance all root servers will be serving the ** DURZ, and will generate larger responses to DNS ** queries that request DNSSEC information. ** ** If you experience technical problems or need to contact ** technical project staff, please send e-mail to rootsign at icann.org ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred ** if possible. ** ** See below for more details. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. DEPLOYMENT STATUS The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. Twelve of the thirteen root servers have already made the transition to the DURZ. No harmful effects have been identified. The final root server to make the transition, J-Root, will start serving the DURZ in a maintenance window scheduled for 1700--1900 UTC on 2010-05-05. Initial observations relating to this transition will be presented and discussed at the DNS Working Group meeting at the RIPE meeting in Prague on 2010-05-06. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ To come: 2010-05-05: J starts to serve DURZ 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) A more detailed DURZ transition timetable with maintenance windows can be found in the document "DNSSEC Deployment for the Root Zone", the most recent draft of which can be found on the project web page at . From BECHA at ripe.net Mon May 3 08:18:11 2010 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 03 May 2010 15:18:11 +0200 Subject: IPv6 Ripeness Message-ID: <4BDECD13.3070407@ripe.net> [warning - statistics!] Dear colleagues, we have published an article on the RIPE Labs about the IPv6 Ripeness - a method of rating the v6 deployment of LIRs (Local Internet Registries) in RIPE NCC service region: http://labs.ripe.net/content/ipv6-ripeness In total: 8% of all (6.7K) LIRs have "4 stars", 27% have at least v6 space. Top results are for Slovenia: 25% "4 stars", and 67% v6 space! For now, we summarized the results per country. But, we have big plans for the future ... Please take a look, and tell us how useful you find it, and how can we make it better. Regards, Vesna Manojlovic RIPE NCC Trainer From will at harg.net Mon May 3 09:43:58 2010 From: will at harg.net (Will Hargrave) Date: Mon, 3 May 2010 16:43:58 +0200 Subject: Surcharge for providing Internet routes? In-Reply-To: References: <4BDC9281.50509@kenweb.org> Message-ID: <82F5B9D8-0FC4-4864-92D5-47DD228EF335@harg.net> On 3 May 2010, at 05:27, Matthew Petach wrote: > In Asia, there is a popular, but incorrectly named product offering > that many ISPs sell called "domestic transit" which they sell > for price $X; for "full routes" you often pay $2X-$3X. I grind my > teeth every time I hear it, since "transit" doesn't mean "to select > parts of the internet" in most people's eyes. It's really a paid > peering offering, but no matter how much I try to correct people, > the habit of calling it "domestic transit" still persists. :( This is relatively common in europe too - normally under the name 'partial transit'. paid peering: [provider AS] + [providers customers] partial transit: [provider AS] + [providers customers] + [providers peers] Pricing is typically 5-20% of the cost of full routes, and will provide in the region of 40-120k routes. From patrick at ianai.net Mon May 3 10:24:44 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 3 May 2010 11:24:44 -0400 Subject: Surcharge for providing Internet routes? In-Reply-To: <82F5B9D8-0FC4-4864-92D5-47DD228EF335@harg.net> References: <4BDC9281.50509@kenweb.org> <82F5B9D8-0FC4-4864-92D5-47DD228EF335@harg.net> Message-ID: <52875115-F110-4865-99C0-C1C7186E3BBD@ianai.net> On May 3, 2010, at 10:43 AM, Will Hargrave wrote: > On 3 May 2010, at 05:27, Matthew Petach wrote: >> In Asia, there is a popular, but incorrectly named product offering >> that many ISPs sell called "domestic transit" which they sell >> for price $X; for "full routes" you often pay $2X-$3X. I grind my >> teeth every time I hear it, since "transit" doesn't mean "to select >> parts of the internet" in most people's eyes. It's really a paid >> peering offering, but no matter how much I try to correct people, >> the habit of calling it "domestic transit" still persists. :( > > > This is relatively common in europe too - normally under the name 'partial transit'. At least they are naming it correctly. > paid peering: [provider AS] + [providers customers] > partial transit: [provider AS] + [providers customers] + [providers peers] > > Pricing is typically 5-20% of the cost of full routes, and will provide in the region of 40-120k routes. And pricing it correctly! Let's see, transit is at $1/Mbps, so I can get 120K prefixes for $0.05/Mbps? -- TTFN, patrick From bogstad at pobox.com Mon May 3 13:12:45 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 3 May 2010 14:12:45 -0400 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? Message-ID: Like many people, I can't justify the expense of "commercial" IP connectivity for my residence. As a result, I deal with dynamic IP addresses; dns issues; and limitations on the services that I can host at my residence. It just struck me that in the same way that IPv6 connectivity can be done via tunneling over IPv4 (Hurricane Electric, etc.), that static IPv4 addressability could be offered in a similar fashion. Some my question is: Does anyone offer (probably bandwidth restricted) IPv4 over IPv4 tunneling (with static IPs) commercially? I realize that making use of such a service MIGHT violate Terms of Service agreements, but that is going to vary from provider to provider and doesn't make offering such a service inherently wrong. Other possible reasons such services might be desired include wanting access to Internet services which are regionally restricted. (Again TOS violation possibilities MAY or MAY NOT apply.) In the (very?) long term, IPv4 over IPv6 tunneling could end up being one way that organizations can get IPv4 connectivity when the default changes from only-IPv4 to only-IPv6. (Yeah, I know that day may never come...) Thanks, Bill Bogstad From brandon.galbraith at gmail.com Mon May 3 13:17:26 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 3 May 2010 13:17:26 -0500 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: Message-ID: http://www.google.com/search?q=vpn+service Encryption would be a side benefit for your purpose. On Mon, May 3, 2010 at 1:12 PM, Bill Bogstad wrote: > Like many people, I can't justify the expense of "commercial" IP > connectivity for my residence. As a result, I deal with dynamic IP > addresses; dns issues; and limitations on the services that I can host > at my residence. It just struck me that in the same way that > IPv6 connectivity can be done via tunneling over IPv4 (Hurricane > Electric, etc.), that static IPv4 addressability could be offered in a > similar fashion. > > Some my question is: > > Does anyone offer (probably bandwidth restricted) IPv4 over IPv4 > tunneling (with static IPs) commercially? > > I realize that making use of such a service MIGHT violate Terms of > Service agreements, but that is going to vary from provider to > provider and doesn't make offering such a service inherently wrong. > Other possible reasons such services might be desired include wanting > access to Internet services which are regionally restricted. (Again > TOS violation possibilities MAY or MAY NOT apply.) > > In the (very?) long term, IPv4 over IPv6 tunneling could end up being > one way that organizations can get IPv4 connectivity when the default > changes from only-IPv4 to only-IPv6. (Yeah, I know that day may never > come...) > > Thanks, > Bill Bogstad > > -- Brandon Galbraith Voice: 630.492.0464 From greg at bestnet.kharkov.ua Mon May 3 13:27:00 2010 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Mon, 3 May 2010 21:27:00 +0300 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: Message-ID: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> On Mon, 3 May 2010 14:12:45 -0400 Bill Bogstad wrote: > Like many people, I can't justify the expense of "commercial" IP > connectivity for my residence. As a result, I deal with dynamic IP > addresses; dns issues; and limitations on the services that I can host > at my residence. It just struck me that in the same way that > IPv6 connectivity can be done via tunneling over IPv4 (Hurricane > Electric, etc.), that static IPv4 addressability could be offered in a > similar fashion. > > Some my question is: > > Does anyone offer (probably bandwidth restricted) IPv4 over IPv4 > tunneling (with static IPs) commercially? > > I realize that making use of such a service MIGHT violate Terms of > Service agreements, but that is going to vary from provider to > provider and doesn't make offering such a service inherently wrong. > Other possible reasons such services might be desired include wanting > access to Internet services which are regionally restricted. (Again > TOS violation possibilities MAY or MAY NOT apply.) > > In the (very?) long term, IPv4 over IPv6 tunneling could end up being > one way that organizations can get IPv4 connectivity when the default > changes from only-IPv4 to only-IPv6. (Yeah, I know that day may never > come...) Holly shit... Where do you live? In Ukraine we have almost no difference (well it is different from one company to another) between commercial and residental setups. At least it is so with smaller providers like one I have at home and one I work for (they are two different companies). So it seems very very strange to me you need to justify anything with your network operator. -- With best regards, Gregory Edigarov From cgrundemann at gmail.com Mon May 3 14:01:40 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 3 May 2010 13:01:40 -0600 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: Message-ID: On Mon, May 3, 2010 at 12:12, Bill Bogstad wrote: > Like many people, I can't justify the expense of "commercial" IP > connectivity for my residence. ?As a result, I deal with dynamic IP > addresses; dns issues; and limitations on the services that I can host > at my residence. Not sure where you live / what service is available to you but many "business" DSL, cable and fixed-wireless offerings are quite reasonably priced these days. I pay about $100/mo for 16m x 2m and a /28 from my local cable operator - which is likely less than residential service plus a vpn/tunnel service. It sure isn't a fiber metro-E connection but it does let me run my various servers out of the house. Perhaps something to look into. $0.02 ~Chris > > Thanks, > Bill Bogstad > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From nonobvious at gmail.com Mon May 3 16:15:07 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 3 May 2010 14:15:07 -0700 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> References: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> Message-ID: > On Mon, 3 May 2010 14:12:45 -0400 > Bill Bogstad wrote: >> Like many people, I can't justify the expense of "commercial" IP >> connectivity for my residence. ?As a result, I deal with dynamic IP .. On Mon, May 3, 2010 at 11:27 AM, Gregory Edigarov wrote: > Holly shit... Where do you live? In Ukraine we have almost no > difference (well it is different from one company to another) between > commercial and residental setups. At least it is so with smaller > providers like one I have at home and one I work for (they are two > different companies). > So it seems very very strange to me you need to justify anything with > your network operator. In most of the US, the standard residential ISP service gives you - some amount of bandwidth, usually asynchronous - dynamic IP address (with static available for a higher price) - some service quality and repair speed guarantees - many ISPs, especially cable modem, have annoying policies that say you can't run a server at home. But many don't. - some ISPs are starting to get the idea tha Most of the ISPs that provide that kind of service offer business service using the residential technology - higher price - better service quality and repair speed guarantees - static IP addresses, and you can run a server -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Mon May 3 16:34:23 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Mon, 3 May 2010 14:34:23 -0700 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: Back when I was on that side of the house, if you bought transit from 7018 and were managing your own routers, you got your choice of BGP or static, and BGP could have full routes, our-customer routes, default routes, and maybe some other variants. No charge for any of those options, but if you wanted full routes you'd need a hefty enough router, and if you thought you wanted full routes on your T1 line we'd offer you some hints about that not being a good idea. Other than that, full routes burned a bit of extra bandwidth, so if you had usage-based pricing that might have some minor effects. (If we were managing your routers, you usually weren't in the dual-homing business, or at least we'd be charging you more for a fatter router and managing the extra complexity of whatever you needed done locally, but all of that was just router management pricing, not network pricing.) -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nenolod at systeminplace.net Mon May 3 16:46:34 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 03 May 2010 16:46:34 -0500 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: Message-ID: <1272923194.4256.25.camel@petrie> On Mon, 2010-05-03 at 14:12 -0400, Bill Bogstad wrote: > Like many people, I can't justify the expense of "commercial" IP > connectivity for my residence. As a result, I deal with dynamic IP > addresses; dns issues; and limitations on the services that I can host > at my residence. It just struck me that in the same way that > IPv6 connectivity can be done via tunneling over IPv4 (Hurricane > Electric, etc.), that static IPv4 addressability could be offered in a > similar fashion. > > Some my question is: > > Does anyone offer (probably bandwidth restricted) IPv4 over IPv4 > tunneling (with static IPs) commercially? > > I realize that making use of such a service MIGHT violate Terms of > Service agreements, but that is going to vary from provider to > provider and doesn't make offering such a service inherently wrong. > Other possible reasons such services might be desired include wanting > access to Internet services which are regionally restricted. (Again > TOS violation possibilities MAY or MAY NOT apply.) > > In the (very?) long term, IPv4 over IPv6 tunneling could end up being > one way that organizations can get IPv4 connectivity when the default > changes from only-IPv4 to only-IPv6. (Yeah, I know that day may never > come...) > > Thanks, > Bill Bogstad > You could do this with a VPS. Make sure they run Xen or KVM or VMware though, so you have control over the routing table. William From smb at cs.columbia.edu Mon May 3 18:35:53 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Mon, 3 May 2010 19:35:53 -0400 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> Message-ID: <5225384E-1E2C-4B16-9F34-AA33FF24DA87@cs.columbia.edu> > > > - many ISPs, especially cable modem, have annoying policies that say > you can't run a server at home. But many don't. Right. Often, this is due to a combination of technology limitations -- with DSL, upstream and downstream bandwidths are tradeoffs; with cable modems, limited upstream bandwidth is inherent in the technology -- coupled with an obsolete model that assumes that consumers mostly download. Besides, if you can charge more for business service, why not...? --Steve Bellovin, http://www.cs.columbia.edu/~smb From bogstad at pobox.com Mon May 3 19:28:09 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Mon, 3 May 2010 20:28:09 -0400 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> References: <20100503212700.38248cd3@greg.bestnet.kharkov.ua> Message-ID: On Mon, May 3, 2010 at 2:27 PM, Gregory Edigarov wrote: > On Mon, 3 May 2010 14:12:45 -0400 > Holly shit... Where do you live? In Ukraine we have almost no > difference (well it is different from one company to another) between > commercial and residental setups. At least it is so with smaller > providers like one I have at home and one I work for (they are two > different companies). > So it seems very very strange to me you need to justify anything with > your network operator. North America. Specifically the Boston metro area of the USA. It's fairly common here to put all kinds of type of service restrictions on residential Internet connectivity. From what I've read on NANOG over the years, I thought this was common practice worldwide, but it sounds like that might not be the case in the Ukraine. Thanks, Bill Bogstad From srknth.s at gmail.com Mon May 3 21:47:55 2010 From: srknth.s at gmail.com (Srikanth Sundaresan) Date: Mon, 3 May 2010 22:47:55 -0400 Subject: Emulating ADSL bandwidth shaping Message-ID: I'm trying to model ADSL access link bandwidth shaping. With a link of 18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps, 8Mbps and 2Mbps access plans. I have a couple of questions: - do ISPs typically use token bucket filters with large bursts to shape traffic? - what kind of burst sizes and latencies/limits are typically used for the filter? Thanks in advance, Srikanth From patrick at zill.net Mon May 3 22:19:07 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 03 May 2010 23:19:07 -0400 Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: Message-ID: <4BDF922B.5080408@zill.net> Srikanth Sundaresan wrote: > I'm trying to model ADSL access link bandwidth shaping. With a link of > 18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps, > 8Mbps and 2Mbps access plans. I have a couple of questions: > > - do ISPs typically use token bucket filters with large bursts to shape traffic? > - what kind of burst sizes and latencies/limits are typically used for > the filter? > You will definitely have to account for latency. For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. Burst mode in my experience occurs only for about the first 15 seconds, then is throttled back (though not always; seems to depend on time of day). For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). Burst mode was generally not noticeable or available, that is, you got the same speed regardless of downloading a 1MB jpeg or a 640MB .iso file. IMHO, IME, ISTR, YMMV... --Patrick From aredridel at nbtsc.org Mon May 3 23:15:32 2010 From: aredridel at nbtsc.org (Aria Stewart) Date: Mon, 3 May 2010 22:15:32 -0600 Subject: Emulating ADSL bandwidth shaping In-Reply-To: <4BDF922B.5080408@zill.net> References: <4BDF922B.5080408@zill.net> Message-ID: On May 3, 2010, at 9:19 PM, Patrick Giagnocavo wrote: >> - do ISPs typically use token bucket filters with large bursts to shape traffic? >> - what kind of burst sizes and latencies/limits are typically used for >> the filter? >> > > You will definitely have to account for latency. > > For emulating cable traffic, latencies (in the USA) will be about > 60-80ms to typical sites. Burst mode in my experience occurs only for > about the first 15 seconds, then is throttled back (though not always; > seems to depend on time of day). > And queues of 1 second at line rate are not uncommon, so if you load the link, things lag. > For DSL, I seem to recall latency being about 90-110ms (note, I haven't > used DSL in many years). Burst mode was generally not noticeable or > available, that is, you got the same speed regardless of downloading a > 1MB jpeg or a 640MB .iso file. Now more typically 40ms. And yeah, no bursts over normal line rate. Most turn down line rate for other plans, not shape. From raymond at prolocation.net Tue May 4 03:54:39 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 4 May 2010 10:54:39 +0200 (CEST) Subject: Emulating ADSL bandwidth shaping In-Reply-To: <4BDF922B.5080408@zill.net> References: <4BDF922B.5080408@zill.net> Message-ID: Hi! >> - do ISPs typically use token bucket filters with large bursts to shape traffic? >> - what kind of burst sizes and latencies/limits are typically used for >> the filter? > You will definitely have to account for latency. > > For emulating cable traffic, latencies (in the USA) will be about > 60-80ms to typical sites. Burst mode in my experience occurs only for > about the first 15 seconds, then is throttled back (though not always; > seems to depend on time of day). > > For DSL, I seem to recall latency being about 90-110ms (note, I haven't > used DSL in many years). Burst mode was generally not noticeable or > available, that is, you got the same speed regardless of downloading a > 1MB jpeg or a 640MB .iso file. The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor 4... Bye, Raymond. From davehart at gmail.com Tue May 4 07:02:39 2010 From: davehart at gmail.com (Dave Hart) Date: Tue, 4 May 2010 12:02:39 +0000 Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: <4BDF922B.5080408@zill.net> Message-ID: On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting Patrick: >> For emulating cable traffic, latencies (in the USA) will be about >> 60-80ms to typical sites. [...] >> For DSL, I seem to recall latency being about 90-110ms (note, I haven't >> used DSL in many years). [...] > The latency i have here on my DSL is ~ 16-22 ms. So its much lower, factor > 4... Either you're looking only at the loop contribution, or you're in the SF bay area and nearly every "typical site" is available locally. Here in the relatively backwater Seattle suburbs, unless it's served by Microsoft or a content distribution network, there are substantial latencies to typical sites. To make it concrete I used Windows ICMP tracert against a few sites from both cable and DSL in the Seattle suburbs. First from a consumer-grade cable offering: http://pastebin.com/TGc6xsHk Then from a business-class telco DSL (complete with more than 1 static IP, someone tie me down lest my soul escape my body from sheer joy!): http://pastebin.com/DMrsiUQf Note I made no attempt to ensure I was tracing to the same numeric IP address from both, and the tests were simultaneous. Cheers, Dave Hart P.S. A special flip of the bird to those IWFs who filter all ICMP at the edge and break path MTU detection. From raymond at prolocation.net Tue May 4 07:04:17 2010 From: raymond at prolocation.net (Raymond Dijkxhoorn) Date: Tue, 4 May 2010 14:04:17 +0200 (CEST) Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: <4BDF922B.5080408@zill.net> Message-ID: Hi! > Either you're looking only at the loop contribution, or you're in the > SF bay area and nearly every "typical site" is available locally. > Here in the relatively backwater Seattle suburbs, unless it's served > by Microsoft or a content distribution network, there are substantial > latencies to typical sites. > > To make it concrete I used Windows ICMP tracert against a few sites > from both cable and DSL in the Seattle suburbs. First from a > consumer-grade cable offering: > > http://pastebin.com/TGc6xsHk > > Then from a business-class telco DSL (complete with more than 1 static > IP, someone tie me down lest my soul escape my body from sheer joy!): I am in the Netherlands, and its pretty common there to have low latency on DSL ;) Bye, Raymond. From tme at americafree.tv Tue May 4 07:27:21 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 4 May 2010 08:27:21 -0400 Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: <4BDF922B.5080408@zill.net> Message-ID: On May 4, 2010, at 8:02 AM, Dave Hart wrote: > On Tue, May 4, 2010 at 08:54 UTC, Raymond Dijkxhoorn wrote, quoting > Patrick: >>> For emulating cable traffic, latencies (in the USA) will be about >>> 60-80ms to typical sites. > [...] >>> For DSL, I seem to recall latency being about 90-110ms (note, I >>> haven't >>> used DSL in many years). > [...] >> The latency i have here on my DSL is ~ 16-22 ms. So its much lower, >> factor >> 4... > > Either you're looking only at the loop contribution, or you're in the > SF bay area and nearly every "typical site" is available locally. > Here in the relatively backwater Seattle suburbs, unless it's served > by Microsoft or a content distribution network, there are substantial > latencies to typical sites. > I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, Indian cricket blogs, you will typically have a high latency from the US. What does that tell you about your DSL or Cable system, except that it is somewhat removed from India ? Regards Marshall > To make it concrete I used Windows ICMP tracert against a few sites > from both cable and DSL in the Seattle suburbs. First from a > consumer-grade cable offering: > > http://pastebin.com/TGc6xsHk > > Then from a business-class telco DSL (complete with more than 1 static > IP, someone tie me down lest my soul escape my body from sheer joy!): > > http://pastebin.com/DMrsiUQf > > Note I made no attempt to ensure I was tracing to the same numeric IP > address from both, and the tests were simultaneous. > > Cheers, > Dave Hart > > P.S. A special flip of the bird to those IWFs who filter all ICMP at > the edge and break path MTU detection. > > From cboyd at gizmopartners.com Tue May 4 08:19:39 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 4 May 2010 08:19:39 -0500 Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: <4BDF922B.5080408@zill.net> Message-ID: <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> On May 4, 2010, at 7:27 AM, Marshall Eubanks wrote: > I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, > Indian cricket blogs, you will typically have a high latency from the US. What does that tell > you about your DSL or Cable system, except that it is somewhat removed from India ? Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency. I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time. So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM. --Chris From isabeldias1 at yahoo.com Tue May 4 08:41:48 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 4 May 2010 06:41:48 -0700 (PDT) Subject: Emulating ADSL bandwidth shaping In-Reply-To: <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> References: <4BDF922B.5080408@zill.net> <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> Message-ID: <137819.74004.qm@web52604.mail.re2.yahoo.com> same as in the HFC and QAM modulation values and so on and so forth ..... services that are requiring a connection-oriented service such as a gaming clan/cloud are highly affected when working in latency and jitter network based environments such as the ethernet based ones and SMDS ....... ----- Original Message ---- From: Chris Boyd To: NANOG Sent: Tue, May 4, 2010 2:19:39 PM Subject: Re: Emulating ADSL bandwidth shaping On May 4, 2010, at 7:27 AM, Marshall Eubanks wrote: > I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, > Indian cricket blogs, you will typically have a high latency from the US. What does that tell > you about your DSL or Cable system, except that it is somewhat removed from India ? Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency.? I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time. So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM. --Chris From isabeldias1 at yahoo.com Tue May 4 08:42:59 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Tue, 4 May 2010 06:42:59 -0700 (PDT) Subject: Emulating ADSL bandwidth shaping Message-ID: <121278.8302.qm@web52606.mail.re2.yahoo.com> Is cable better for gamming? ----- Original Message ---- From: isabel dias To: Chris Boyd ; NANOG Sent: Tue, May 4, 2010 2:41:48 PM Subject: Re: Emulating ADSL bandwidth shaping same as in the HFC and QAM modulation values and so on and so forth ..... services that are requiring a connection-oriented service such as a gaming clan/cloud are highly affected when working in latency and jitter network based environments such as the ethernet based ones and SMDS ....... ----- Original Message ---- From: Chris Boyd To: NANOG Sent: Tue, May 4, 2010 2:19:39 PM Subject: Re: Emulating ADSL bandwidth shaping On May 4, 2010, at 7:27 AM, Marshall Eubanks wrote: > I am not sure what the point is in mixing in speed of light latency. If your "typical sites" are, say, > Indian cricket blogs, you will typically have a high latency from the US. What does that tell > you about your DSL or Cable system, except that it is somewhat removed from India ? Most of the ADSL installations I've seen in SBC 13 state area had interleaving turned on, which significantly increases latency.? I suspect that's why many cable MSOs in the same territory have "cable is better for gaming" marketing campaigns running all the time. So the latency you see on an ADSL line is dependent on how the carrier set up the DSLAM. --Chris From Valdis.Kletnieks at vt.edu Tue May 4 09:16:45 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 04 May 2010 10:16:45 -0400 Subject: Emulating ADSL bandwidth shaping In-Reply-To: Your message of "Tue, 04 May 2010 06:42:59 PDT." <121278.8302.qm@web52606.mail.re2.yahoo.com> References: <121278.8302.qm@web52606.mail.re2.yahoo.com> Message-ID: <6372.1272982605@localhost> On Tue, 04 May 2010 06:42:59 PDT, isabel dias said: > Is cable better for gaming? Depends on the game and the gamer. Personally, it doesn't matter to me, as even if I was on my employer's 10GE uplink, I'd still lose to some snot-nosed brat with fast reflexes on a 56kb modem. So till they invent an uplink that has -1500ms latency, I'm screwed. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From swmike at swm.pp.se Tue May 4 09:44:06 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 4 May 2010 16:44:06 +0200 (CEST) Subject: Emulating ADSL bandwidth shaping In-Reply-To: <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> References: <4BDF922B.5080408@zill.net> <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> Message-ID: On Tue, 4 May 2010, Chris Boyd wrote: > Most of the ADSL installations I've seen in SBC 13 state area had > interleaving turned on, which significantly increases latency. I > suspect that's why many cable MSOs in the same territory have "cable is > better for gaming" marketing campaigns running all the time. > > So the latency you see on an ADSL line is dependent on how the carrier > set up the DSLAM. Interleaving is good because it reduces bit error rate on the line. Would be good though if the carrier let the customer change the properties of the line to optimize for different things, high snr target/no interleaving for low bw/low BER/low latency applications, low snr target/interleaving for file transfers. -- Mikael Abrahamsson email: swmike at swm.pp.se From cboyd at gizmopartners.com Tue May 4 09:54:59 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 4 May 2010 09:54:59 -0500 Subject: Emulating ADSL bandwidth shaping In-Reply-To: <121278.8302.qm@web52606.mail.re2.yahoo.com> References: <121278.8302.qm@web52606.mail.re2.yahoo.com> Message-ID: <707935F7-DBCC-4FB7-AF48-A95F9E7D3C8A@gizmopartners.com> On May 4, 2010, at 8:42 AM, isabel dias wrote: > Is cable better for gamming? All the LAN party places I know of use Metro Ethernet solutions. Gamers like low ping times to their servers, and are willing to spend $$ to get them. So if your target market includes people who play a lot of first person shooters, it may be worthwhile to consider offering a low latency setup for them. --Chris From drew.weaver at thenap.com Tue May 4 11:03:16 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Tue, 4 May 2010 12:03:16 -0400 Subject: Thailand Internet firewall? Message-ID: Hi, Is anyone aware whether or not Thailand has a centralized firewall on Internet access? We've had reports from several folks in Thailand that they are unable to get to some IP addresses in our network (this problem is reproducible on the traceroute.org Thailand sites as well). It seems to only be from Thailand, and only certain IPs on our network Does anyone know how to contact whoever is responsible for this firewall system to find out at the very least why this block is in place? thanks, -Drew From rdobbins at arbor.net Tue May 4 11:23:26 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 4 May 2010 16:23:26 +0000 Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: On May 4, 2010, at 11:03 PM, Drew Weaver wrote: > Is anyone aware whether or not Thailand has a centralized firewall on Internet access? Thai SPs are required by law to block sites deemed objectionable by the government of Thailand; common reasons given include lese majeste and/or other materials deemed injurious to 'national security'. Thailand's Ministry of Information & Computer Technology is the relevant governmental bureau - their Web site may be found here: As all this sort of thing is considered a sensitive subject in Thailand, it's doubtful you'll get a response, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From tb at tburke.us Tue May 4 11:40:11 2010 From: tb at tburke.us (Tim Burke) Date: Tue, 4 May 2010 12:40:11 -0400 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: , Message-ID: <53B4B0DD3700964E85B558B61CDC255EE7E35CF2D9@EXMBX01.njnx.lan> I'm using Comcast's business-class service. ~$110 per month for 22mbit down, 5mbit up and a /29. This would definitely be your best bet as opposed to trying to rig up a tunneled setup. You can also get their 12mbit down, 2mbit up service with a /29 for $79, iirc. ________________________________________ From: Chris Grundemann [cgrundemann at gmail.com] Sent: Monday, May 03, 2010 2:01 PM To: Bill Bogstad Cc: NANOG list Subject: Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? On Mon, May 3, 2010 at 12:12, Bill Bogstad wrote: > Like many people, I can't justify the expense of "commercial" IP > connectivity for my residence. As a result, I deal with dynamic IP > addresses; dns issues; and limitations on the services that I can host > at my residence. Not sure where you live / what service is available to you but many "business" DSL, cable and fixed-wireless offerings are quite reasonably priced these days. I pay about $100/mo for 16m x 2m and a /28 from my local cable operator - which is likely less than residential service plus a vpn/tunnel service. It sure isn't a fiber metro-E connection but it does let me run my various servers out of the house. Perhaps something to look into. $0.02 ~Chris > > Thanks, > Bill Bogstad > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From surfer at mauigateway.com Tue May 4 12:14:24 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 May 2010 10:14:24 -0700 Subject: Emulating ADSL bandwidth shaping Message-ID: <20100504101424.4C0F24C0@resin18.mta.everyone.net> --- cboyd at gizmopartners.com wrote: From: Chris Boyd On May 4, 2010, at 7:27 AM, Marshall Eubanks wrote: > I am not sure what the point is in mixing in speed of light > latency. If your "typical sites" are, say, Indian cricket > blogs, you will typically have a high latency from the US. > What does that tell you about your DSL or Cable system, > except that it is somewhat removed from India ? : Most of the ADSL installations I've seen in SBC 13 state area : had interleaving turned on, which significantly increases latency. : I suspect that's why many cable MSOs in the same territory have : "cable is better for gaming" marketing campaigns running all the time. : : So the latency you see on an ADSL line is dependent on how the : carrier set up the DSLAM. In the system I work on, which is in a state with many rural areas and an OSP that goes through a lot of very wet and very windy areas, has "Interleaved" turned on to correct errors. This adds ~25msec between the CPE and the nearest router. Sometimes folks ask for it to be changed to "Fast". We explain that errors may cause resyncs to happen and then make the change if the customer still wants it. That takes the latency from ~25msec to ~3-4msec. So use both when doing your modeling. I don't know how to model the error rate, though, as that would be dependent on the quality of the OSP you're modeling... scott ps. if you're so fast in gaming that a difference of 1/5 of a second makes a difference you're good... ;-) From owen at delong.com Tue May 4 12:37:21 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 4 May 2010 10:37:21 -0700 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: <53B4B0DD3700964E85B558B61CDC255EE7E35CF2D9@EXMBX01.njnx.lan> References: , <53B4B0DD3700964E85B558B61CDC255EE7E35CF2D9@EXMBX01.njnx.lan> Message-ID: LoL... I'm using that same service (without the /29 for $10/month) as transport for my tunneled setup. Owen On May 4, 2010, at 9:40 AM, Tim Burke wrote: > I'm using Comcast's business-class service. ~$110 per month for 22mbit down, 5mbit up and a /29. > > This would definitely be your best bet as opposed to trying to rig up a tunneled setup. You can also get their 12mbit down, 2mbit up service with a /29 for $79, iirc. > > ________________________________________ > From: Chris Grundemann [cgrundemann at gmail.com] > Sent: Monday, May 03, 2010 2:01 PM > To: Bill Bogstad > Cc: NANOG list > Subject: Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? > > On Mon, May 3, 2010 at 12:12, Bill Bogstad wrote: >> Like many people, I can't justify the expense of "commercial" IP >> connectivity for my residence. As a result, I deal with dynamic IP >> addresses; dns issues; and limitations on the services that I can host >> at my residence. > > > Not sure where you live / what service is available to you but many > "business" DSL, cable and fixed-wireless offerings are quite > reasonably priced these days. I pay about $100/mo for 16m x 2m and a > /28 from my local cable operator - which is likely less than > residential service plus a vpn/tunnel service. It sure isn't a fiber > metro-E connection but it does let me run my various servers out of > the house. Perhaps something to look into. > > $0.02 > ~Chris > >> >> Thanks, >> Bill Bogstad >> >> > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.coisoc.org From tb at tburke.us Tue May 4 14:25:55 2010 From: tb at tburke.us (Tim Burke) Date: Tue, 4 May 2010 15:25:55 -0400 Subject: any "bring your own bandwidth" IPv4 over IPv4 tunnel merchants? In-Reply-To: References: , <53B4B0DD3700964E85B558B61CDC255EE7E35CF2D9@EXMBX01.njnx.lan> Message-ID: <2451DEC9-0295-4743-BBC9-3DF3E4D5126C@tburke.us> I've had no problems with it. Seems to be much better than the residential service. The /29 was only $10? I must be getting jipped, I'm paying $20. Tim Burke 630.617.1300 Cell tb at tburke.us Email Sent from my iPhone On May 4, 2010, at 12:52 PM, "Owen DeLong" wrote: > LoL... I'm using that same service (without the /29 for $10/month) > as transport for my > tunneled setup. > > Owen > > On May 4, 2010, at 9:40 AM, Tim Burke wrote: > >> I'm using Comcast's business-class service. ~$110 per month for >> 22mbit down, 5mbit up and a /29. >> >> This would definitely be your best bet as opposed to trying to rig >> up a tunneled setup. You can also get their 12mbit down, 2mbit up >> service with a /29 for $79, iirc. >> >> ________________________________________ >> From: Chris Grundemann [cgrundemann at gmail.com] >> Sent: Monday, May 03, 2010 2:01 PM >> To: Bill Bogstad >> Cc: NANOG list >> Subject: Re: any "bring your own bandwidth" IPv4 over IPv4 tunnel >> merchants? >> >> On Mon, May 3, 2010 at 12:12, Bill Bogstad wrote: >>> Like many people, I can't justify the expense of "commercial" IP >>> connectivity for my residence. As a result, I deal with dynamic IP >>> addresses; dns issues; and limitations on the services that I can >>> host >>> at my residence. >> >> >> Not sure where you live / what service is available to you but many >> "business" DSL, cable and fixed-wireless offerings are quite >> reasonably priced these days. I pay about $100/mo for 16m x 2m and a >> /28 from my local cable operator - which is likely less than >> residential service plus a vpn/tunnel service. It sure isn't a fiber >> metro-E connection but it does let me run my various servers out of >> the house. Perhaps something to look into. >> >> $0.02 >> ~Chris >> >>> >>> Thanks, >>> Bill Bogstad >>> >>> >> >> >> -- >> @ChrisGrundemann >> weblog.chrisgrundemann.com >> www.burningwiththebush.com >> www.coisoc.org > From robert at grid.chu.edu.tw Sun May 2 07:16:52 2010 From: robert at grid.chu.edu.tw (Robert C. Hsu) Date: Sun, 2 May 2010 20:16:52 +0800 Subject: Call For Papers - UIC 2010 (Xi\'an, China, October 26-29, 2010) Message-ID: <201005021216.o42CGqO7029976@grid.chu.edu.tw> Our sincere apologies if you receive multiple copies of this announcement. ----------------------------------------------------------------------- --------- CALL FOR PAPERS The 7th International Conference on Ubiquitous Intelligence and Computing - Building Smart Worlds in Real and Cyber Spaces - UIC 2010 (http://www.nwpu.edu.cn/uic2010/) Xi'an, China, October 26-29, 2010 Technically Sponsored by IEEE CS TCSC Co-located with ATC 2010 (http://www.nwpu.edu.cn/atc2010/) ----------------------------------------------------------------------- --------- What's New: -------------- 1. Due to many requests, the submission deadline of UIC 2010 is extended to May 15. 2. Selected best papers of UIC 2010 will be published in the special issues of: * Personal and Ubiquitous Computing (Springer, SCI-E) * International Journal of Information Acquisition (World Scientific) * International Journal of Autonomous and Adaptive Communications Systems (Inderscience) 3. Six workshops have been accepted by UIC 2010. Workshop paper submission deadline is May 30. ----------------------------------------------------------------------- ---------- Ubiquitous sensors, devices, networks and information are paving the way towards a smart world in which computational intelligence is distributed throughout the physical environment to provide reliable and relevant services to people. This ubiquitous intelligence will change the computing landscape because it will enable new breeds of applications and systems to be developed and the realm of computing possibilities will be significantly extended. By enhancing everyday objects with intelligence, many tasks and processes could be simplified, the physical spaces where people interact like the workplaces and homes, could become more efficient, safer and more enjoyable. Ubiquitous computing, or pervasive computing, uses these many ??smart things or u-things?? to create smart environments, services and applications. A smart thing can be endowed with different levels of intelligence, and may be context-aware, active, interactive, reactive, proactive, assistive, adaptive, automated, sentient, perceptual, cognitive, autonomic and/or thinking. Research on ubiquitous intelligence is an emerging research field covering many disciplines. A series of grand challenges exist to move from the current level of computing services to the smart world of adaptive and intelligent services. Started in 2005, the series of UIC conferences has been held in Taipei, Nagasaki, Three Gorges (China), Hong Kong, Oslo and Brisbane. UIC 2010 will include a highly selective program of technical papers, accompanied by workshops, panel discussions and keynote speeches. Established as a premier venue in the area of ubiquitous intelligence and computing, UIC 2010 will offer a forum for researchers to exchange ideas and experiences in developing intelligent/smart objects, environments and systems. -------- TOPICS: -------- 1. Ubiquitous Intelligent/Smart Systems * Sensor, Ad Hoc, Mesh & P2P Networks * Social Networking and Computing * Knowledge Representation and Ontology * Wearable, Personal and Body Area Systems * Middleware and Intelligent Platforms * Intelligent Services and Architectures * Agents, Swarm and Context-aware Systems * Nature-inspired Intelligent Systems 2. Ubiquitous Intelligent/Smart Environments * Smart Room, Home, Office, Laboratory * Smart Shop, Hospital, Campus, City, etc. * Smart Vehicle, Road, Traffic & Transportation * Healthcare and Elder/Child Care Services * Pervasive/Ubiquitous Media and Services * Pervasive Learning, Games, Entertainment * Other Intelligent/Smart Applications 3. Ubiquitous Intelligent/Smart Objects * Electronic Labels, Cards, E-Tags and RFID * Embedded Chips, Sensors & Actuators * MEMS, NEMS, Micro & Biometric Devices * Smart Appliances and Wearable Devices * Material, Textile, Cloth, Furniture, etc. * Embedded Software and Agents * Interaction to Smart Objects/Devices * Smart Object OS and Programming 4. Personal/Social/Physical Aspects * Real/Cyber World Modeling and Semantics * User/Object Identity and Activity Recognition * Adaptive User Interfaces and Tools * Security, Privacy, Safety and Legal Issues * Emotional, Ethical and Psychological Factors * Implication & Impact of Ubiquitous Intelligence * Relations between Real and Cyber Worlds -------------------------------- WORKSHOPS AND AFFILIATED EVENTS: -------------------------------- The UIC 2010 Organizing Committee invites proposals for one-day workshops affiliated with the conference and addressing research areas related to the conference. The workshop proceedings will be published by IEEE CS Press. Submit workshop proposals to workshops chairs via email (robertchh at gmail.com and mieso08 at gmail.com) by 31 January 2010. Besides workshops, UIC 2010 will also include a special track, demo/exhibitions and a panel. Please visit the conference website for details. ---------------------- SUBMISSION GUIDELINES: ---------------------- Papers need to be prepared according to the LNCS format, and submitted in PDF format via the UIC 2010 submission site: http://www.nwpu.edu.cn/uic2010/Submission/ ---------------- IMPORTANT DATES: ---------------- Paper submission: May 15, 2010 (extended) Author notification: Jun. 30, 2010 Camera-ready due: Jul. 30, 2010 ------------------ PAPER PUBLICATION: ------------------ Accepted conference papers are planned to be published by Lecture Notes in Computer Science (LNCS, EI indexed). At least one author of each accepted paper is required to register and present their work at the conference, otherwise the paper will not be included in the proceedings. Distinguished Selected papers, after further extensions and revisions, will be published in special issues of prestigious journals including Personal and Ubiquitous Computing (Springer), International Journal of Information Acquisition (World Scientific), and International Journal of Autonomous and Adaptive Communications Systems (Inderscience). -------- AWARDS: -------- As in the past, UIC 2010 will present a Best Paper Award. A best demo or exhibition will also be selected. ----------- COMMITTEE: ----------- Honorary Chairs Yaoxue Zhang, Tsinghua University, China Stephen S. Yau, Arizona State University, USA Lionel M. Ni, Hong Kong Univ. of Sci. and Tech., HK General Chairs Daqing Zhang, Institute TELECOM SudParis, France Xingshe Zhou, Northwestern Polytechnical Univ., China Sajal Das, Univ. of Texas at Arlington, USA Program Chairs Zhiwen Yu, Northwestern Polytechnical Univ., China Ramiro Liscano, Univ. of Ontario Inst. of Tech., Canada Guanling Chen, University of Massachusetts, USA Program Vice Chairs Waltenegus Dargie, Tech. Univ. of Dresden, Germany Tatsuya Yamazaki, NICT, Japan Yu Chen, Tsinghua University, China Advisory Committee Chairs Norio Shiratori, Tohoku University, Japan Mohan Kumar, University of Texas at Arlington, USA Max Muehlhaeuser, Darmstadt Univ. of Tech., Germany Workshop Chairs Robert C. Hsu, Chung Hua Univ., Taiwan Mieso Denko, University of Guelph, Canada Publicity Chairs Bessam Abdulrazak, Univ. Sherbrooke, Canada Sung-Bae Cho, Yonsei University, Korea Wenbin Jiang, Huazhong Univ. of Sci. & Tech., China Artur Lugmayr, Tampere Univ. of Technology, Finland Hongbo Ni, Northwestern Polytechnical Univ., China Evi Syukur, University of New South Wales, Australia Panel Chairs Christian Becker, University of Mannheim, Germany Ren-Hung Huang, National Chung Cheng Univ., Taiwan Demo/Exhibition Chairs Gang Pan, Zhejiang University, China Xing Xie, Microsoft Research Asia, China Award Chairs Frode Eika Sandnes, Oslo University College, Norway Jiannong Cao, Hong Kong Polytechnic University, HK Special Track Chairs Zheng Yan, Nokia Research Center, Finland Yan Wang, Macquarie University, Australia International Liaison Chairs Marius Portmann, University of Queensland, Australia Yo-Ping Huang, National Taipei Univ. of Tech., Taiwan Bernady O. Apduhan, Kyushu Sangyo University, Japan Tao Mei, Chinese Academy of Sciences, China Jong Hyuk Park, Kyungnam University, Korea Judith Symonds, Auckland Univ. of Tech., New Zealand Industrial Liaison Chairs Wei Han, China Aeronautical Computing Institute, China Nagula Sangary, RIM, Canada Yan Zhang, Simula Lab, Norway Local Arrangement Chair Yuying Wang, Northwestern Polytechnical Univ., China Web Administration Chair Haipeng Wang, Northwestern Polytechnical Univ., China Steering Committee Jianhua Ma (chair), Hosei University, Japan Laurence T. Yang (chair), St. Francis Xavier Univ., Canada Hai Jin, Huazhong University of Sci. & Tech., China Theo Ungerer, University of Augsburg, Germany Jadwiga Indulska, University of Queensland, Australia Jeffrey J.P. Tsai, University of Illinois at Chicago, USA Advisory Committee and Program Committee See UIC 2010 website: http://www.nwpu.edu.cn/uic2010/ From swmike at swm.pp.se Tue May 4 14:58:29 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 4 May 2010 21:58:29 +0200 (CEST) Subject: Emulating ADSL bandwidth shaping In-Reply-To: <20100504101424.4C0F24C0@resin18.mta.everyone.net> References: <20100504101424.4C0F24C0@resin18.mta.everyone.net> Message-ID: On Tue, 4 May 2010, Scott Weeks wrote: > "Interleaved" turned on to correct errors. This adds ~25msec between > the CPE and the nearest router. Sometimes folks ask for it to be > changed to "Fast". We explain that errors may cause resyncs to happen > and then make the change if the customer still wants it. That takes the Basically "interleaved" is a way "smearing" bits over time, so FEC can do its job when there is a 1ms line hit that causes a lot of errors during that 1ms. Turning off interleaving (changing to "fast") usually means your "errored seconds" counter will increase over time because of lack of error correction, and your customer experiences packet loss intermittently. Never seen it cause resyncs, but that might happen, dunno. It is usually settable to 1,4,16 ms in each direction, so 25ms is not a "law of nature", it's just the default 16/4 ms downstream/upstream interleaving and then the added coding delay. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Tue May 4 15:02:50 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 4 May 2010 22:02:50 +0200 (CEST) Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: On Tue, 4 May 2010, Dobbins, Roland wrote: > Thai SPs are required by law to block sites deemed objectionable by the > government of Thailand; common reasons given include lese majeste and/or > other materials deemed injurious to 'national security'. +1. When I was in thailand the (my guess) URL inspection box was behaving badly and a substantial amount of TCP/80 connection attempts was failing. Using SSH tunneling to get out of Thailand made things behave much better becaus established tcp connections (even on 80) wasn't a problem, it was establishing new connections that was troublesome. > As all this sort of thing is considered a sensitive subject in Thailand, > it's doubtful you'll get a response, IMHO. +1 as well. There are two things you don't do in thailand, you don't ever say or do anything bad towards the king, and you don't do drugs. So since the filters are there to protect the king, it's a sensitive subject. -- Mikael Abrahamsson email: swmike at swm.pp.se From frnkblk at iname.com Tue May 4 15:26:29 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Tue, 4 May 2010 15:26:29 -0500 Subject: Emulating ADSL bandwidth shaping In-Reply-To: <4BDF922B.5080408@zill.net> References: <4BDF922B.5080408@zill.net> Message-ID: We're an ISP that has four access technologies. Both cable and DSL modem link times are affected by configured rate and sync rate, respectively. My home CM is at 15/1 Mbps and one-way latency is 4 to 5 msec. My home DSL modem is at 15/1 Mbps (with interleaving) and has a one-way latency of 15 to 16 msec. And FTTH at 15/1 Mbps is about 2 msec. In regards to burst mode, the cable modem file specifies how many bytes are given that top speed, not time. If the port is heavily utilized, "top" speed may not be attained during that burst session. Frank -----Original Message----- From: Patrick Giagnocavo [mailto:patrick at zill.net] Sent: Monday, May 03, 2010 10:19 PM To: Srikanth Sundaresan; NANOG Subject: Re: Emulating ADSL bandwidth shaping Srikanth Sundaresan wrote: > I'm trying to model ADSL access link bandwidth shaping. With a link of > 18Mbps, I'm using a token bucket filter (tc + netem) to model 10Mbps, > 8Mbps and 2Mbps access plans. I have a couple of questions: > > - do ISPs typically use token bucket filters with large bursts to shape traffic? > - what kind of burst sizes and latencies/limits are typically used for > the filter? > You will definitely have to account for latency. For emulating cable traffic, latencies (in the USA) will be about 60-80ms to typical sites. Burst mode in my experience occurs only for about the first 15 seconds, then is throttled back (though not always; seems to depend on time of day). For DSL, I seem to recall latency being about 90-110ms (note, I haven't used DSL in many years). Burst mode was generally not noticeable or available, that is, you got the same speed regardless of downloading a 1MB jpeg or a 640MB .iso file. IMHO, IME, ISTR, YMMV... --Patrick From surfer at mauigateway.com Tue May 4 16:00:00 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 4 May 2010 14:00:00 -0700 Subject: Emulating ADSL bandwidth shaping Message-ID: <20100504140000.4C0B9323@resin14.mta.everyone.net> --- swmike at swm.pp.se wrote: From: Mikael Abrahamsson On Tue, 4 May 2010, Scott Weeks wrote: > "Interleaved" turned on to correct errors. This adds ~25msec between > the CPE and the nearest router. Sometimes folks ask for it to be > changed to "Fast". We explain that errors may cause resyncs to happen > and then make the change if the customer still wants it. That takes the : Never seen it cause resyncs, but that might happen, dunno. It definitely causes the DSLAM port to resync sometimes. : It is usually settable to 1,4,16 ms in each direction, so : 25ms is not a "law of nature", it's just the default 16/4 ms : downstream/upstream interleaving and then the added coding delay. We have to set it high because of the OSP. It goes through jungles. Literally. ;-) Some areas get 25-30mph winds every day with 300-400 inches of rain a year. http://www.nature.org/wherewework/northamerica/states/hawaii/preserves/art2363.html http://farm5.static.flickr.com/4054/4303747828_ce95aea13d.jpg scott From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue May 4 16:27:00 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 5 May 2010 06:57:00 +0930 Subject: Emulating ADSL bandwidth shaping In-Reply-To: References: <4BDF922B.5080408@zill.net> <6C483617-D577-4DA7-BA15-FE00FFEB28B3@gizmopartners.com> Message-ID: <20100505065700.5f5974e6@opy.nosense.org> On Tue, 4 May 2010 16:44:06 +0200 (CEST) Mikael Abrahamsson wrote: > On Tue, 4 May 2010, Chris Boyd wrote: > > > Most of the ADSL installations I've seen in SBC 13 state area had > > interleaving turned on, which significantly increases latency. I > > suspect that's why many cable MSOs in the same territory have "cable is > > better for gaming" marketing campaigns running all the time. > > > > So the latency you see on an ADSL line is dependent on how the carrier > > set up the DSLAM. > > Interleaving is good because it reduces bit error rate on the line. Would > be good though if the carrier let the customer change the properties of > the line to optimize for different things, high snr target/no interleaving > for low bw/low BER/low latency applications, low snr target/interleaving > for file transfers. > It's common for ISPs in Australia who own their own DSLAMs to do this via 'line profiles'. I'm on the most aggressive one, and have line latency of around 9.5 to 10ms. Also what is interesting is that ADSL firmware in the modem can contribute significantly. I used to need to be on ADSL1 with interleaving to get any sort of reliable line sync. After a modem firmware upgrade, which I knew also involved an ADSL chipset firmware upgrade, I didn't get any more bandwidth, but was able to get stability (i.e. no loss of sync for weeks on end) without interleaving. Regards, Mark. From wavetossed at googlemail.com Tue May 4 18:01:25 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Wed, 5 May 2010 00:01:25 +0100 Subject: Surcharge for providing Internet routes? In-Reply-To: <20100503042741.GB85221@blackrose.org> References: <4BDC9281.50509@kenweb.org> <20100503042741.GB85221@blackrose.org> Message-ID: > I don't think there is a universally agreed upon definition of what > transit means other than it involves someone paying someone else. Uhh, "transit" is an English word which comes from the Latin word meaning "it goes across". Transit has nothing to do with payment at all. The only thing that everybody agrees on is that transit is carrying packets across your network to another network. Clearly, you could give away free transit if it helps you sell T-shirts, or data center racks or some such, so payment is just not relevant at all. The problem is that "full transit" is such a common thing, that many people just assume that "transit" means "full transit" and there, the misunderstandings begin, especially with people that haven't had experience with ISPs who make up their own rules instead of just copying the one down the road. > I have no idea what the sales people call each in different > countries, but domestic transit is not a misnomer as the ISP > selling you this will be providing reacheability to their > country specific customer base AND reacheability to their > country specific peers. Typically, sales people don't care about terminology and will happily call "free transit", "paid peering" if it helps them make a sale. But fundamentally, peering is about carrying packets from your neighbor's network to destinations on your own network in return for the same thing the other way around. Again, payment is not part of the definition of peering. Peering always involves two networks who are neighbors. Transit always involves three or more networks who are not neighbors and who have a third party network in between them. The packets all have to transit the third party network. Most everything else is either marketing, or the jostling and adjustment that happens when you discover that your business model isn't actually profitable because you didn't think through your pricing structures in enough detail, and some companies more clever than you have locked in contracts that you really should not have signed at that price point. --Michael Dillon From gbonser at seven.com Tue May 4 19:32:47 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 4 May 2010 17:32:47 -0700 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA4131@RWC-EX1.corp.seven.com> > -----Original Message----- > From: ML > Sent: Saturday, May 01, 2010 1:44 PM > To: nanog at nanog.org > Subject: Surcharge for providing Internet routes? > > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? > > Waive the surcharge for sufficiently large commits? > I had one provider once that wanted to charge me a surcharge simply for the privilege of running BGP. The had "bgp charge" on their list of things. Well, we were dual-homed to them and I asked how in the world they expected to fail traffic over if we *didn't* run bgb. They should be requiring I run bgp, not charging extra for it if they intend to meet their own SLA. Static routing to a dead link is a surefire SLA killer. The sales rep got a little red. As for a full table, no, I have not paid extra for it. From jmamodio at gmail.com Tue May 4 19:38:15 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Tue, 4 May 2010 19:38:15 -0500 Subject: Interesting combination of SPAM + Phishing + stupidity Message-ID: this is obviously no news and the attachment as you all probably know is a trojan executable. The interesting part and kind of a test to determine who is more stupid, the one sending the message or the one opening and executing the attachment, the message is supposedly sent by UPS but signed as DHL Customer Service, sort of "Welcome to Wells Fargo, your Bank of America support team", duhhh. Also, almost 3 months to notify you that a package was not delivered ? Are spammers getting smarter ? or users getting dumber ? Cheers >From - Tue May 04 17:34:08 2010 >Return-Path: >Delivery-Date: Tue, 04 May 2010 18:25:37 -0400 >From: "UPS Manager Sal Erwin" >To: >Subject: UPS Delivery Problem NR 97981. >Date: Wed, 5 May 2010 00:25:03 +0100 >MIME-Version: 1.0 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_0006_01CAEBD8.A43991A0" > >This is a multi-part message in MIME format. > >------=_NextPart_000_0006_01CAEBD8.A43991A0 >Content-Type: text/plain; > charset="Windows-1252" >Content-Transfer-Encoding: 7bit > >Hello! > >We failed to deliver the package you have sent on the 6th of February in time >because the recipient?s address is wrong. >Please print out the invoice copy attached and collect the package at our office. > >DHL Customer Services. > > >------=_NextPart_000_0006_01CAEBD8.A43991A0 >Content-Type: application/zip; > name="UPS_invoice_4978.zip" >Content-Transfer-Encoding: base64 >Content-Disposition: attachment; > filename="UPS_invoice_4978.zip" From mkarir at merit.edu Wed May 5 00:40:33 2010 From: mkarir at merit.edu (mkarir) Date: Wed, 5 May 2010 01:40:33 -0400 Subject: Tobit software Message-ID: <52322B50-152F-471E-B6A9-5B5665BD07EC@merit.edu> Hello, We are working on a research project that is trying to identify the root cause of some stray network traffic we are seeing. If you run any software from Tobit and are willing to spare some time to help us track down the root cause of this traffic we would really appreciate your help. Please contact me offlist so that we can coordinate. Thanks -manish Network Research & Development Merit Network Inc. From randy at psg.com Wed May 5 04:25:06 2010 From: randy at psg.com (Randy Bush) Date: Wed, 05 May 2010 11:25:06 +0200 Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: > Is anyone aware whether or not Thailand has a centralized firewall on > Internet access? think of it as more like a monopoly telco with ties to the government > We've had reports from several folks in Thailand that they are unable > to get to some IP addresses in our network (this problem is > reproducible on the traceroute.org Thailand sites as well). yes, sites are being blocked. > It seems to only be from Thailand, and only certain IPs on our network yes, it is by specific ip addresses > Does anyone know how to contact whoever is responsible for this > firewall system to find out at the very least why this block is in > place? read your newspaper randy From swmike at swm.pp.se Wed May 5 04:39:26 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 5 May 2010 11:39:26 +0200 (CEST) Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: On Wed, 5 May 2010, Randy Bush wrote: >> Does anyone know how to contact whoever is responsible for this >> firewall system to find out at the very least why this block is in >> place? > > read your newspaper It's not only now, they've been blocking badtalking the king for quite a while. I was also under the impression that it wasn't by IP but that they could block specific youtube videos etc. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Wed May 5 04:45:06 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 5 May 2010 09:45:06 +0000 Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: On May 5, 2010, at 4:39 PM, Mikael Abrahamsson wrote: > I was also under the impression that it wasn't by IP but that they could block specific youtube videos etc. They use a combination of IP blocking, DNS poisoning, and transparent HTTP proxy-based URL filtering. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From Valdis.Kletnieks at vt.edu Wed May 5 07:45:34 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 05 May 2010 08:45:34 -0400 Subject: Interesting combination of SPAM + Phishing + stupidity In-Reply-To: Your message of "Tue, 04 May 2010 19:38:15 CDT." References: Message-ID: <66072.1273063534@localhost> On Tue, 04 May 2010 19:38:15 CDT, Jorge Amodio said: > Are spammers getting smarter ? or users getting dumber ? http://uxmag.com/short-news/these-are-your-users-read-and-be-horrified Remember that statistically speaking, roughly half of all people are below average on the IQ bell curve. A stupefyingly high percentage of your users are either illiterate, innumerate, or both, or severely lacking in critical thinking skills. In addition, keep in mind that the spammers and other miscreants probably come from the ends of that same bell curve - some brilliant guys who think they can do better than the average office job, and some bozos who can't get an average office job. A few years ago, I was watching CNN, and they had a segment on Yellowstone Park installing new bear-proof trash containers. They basically had a complex latch that was too complicated for bears. Unfortunately, a lot of tourists would be stumped (or not bother) and dumped their garbage outside the dumpster, and the bears would come along and get into the garbage. The take-away line of the segment was from a ranger at the park: "There appears to be significant overlap in intelligence between the smartest bear and the dumbest tourist". From d3e3e3 at gmail.com Wed May 5 09:41:24 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 5 May 2010 10:41:24 -0400 Subject: DNS performance... Message-ID: Hi, There are a large number of DNS servers available. See for example http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software Does anyone know of good performance comparisons, especially for high end applications with lots of data/zones and/or high query/update rates? Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From richard.barnes at gmail.com Wed May 5 09:48:12 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 5 May 2010 16:48:12 +0200 Subject: DNS performance... In-Reply-To: References: Message-ID: OARC did a performance study of a few name servers in the context of root zone scaling, but it should be generalizable: On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake wrote: > Hi, > > There are a large number of DNS servers available. See for example > http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > > Does anyone know of good performance comparisons, especially for high > end applications with lots of data/zones and/or high query/update > rates? > > Thanks, > Donald > ============================= > ?Donald E. Eastlake 3rd ? +1-508-333-2270 (cell) > ?155 Beaver Street > ?Milford, MA 01757 USA > ?d3e3e3 at gmail.com > > From simon.perreault at viagenie.ca Wed May 5 09:48:59 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 05 May 2010 10:48:59 -0400 Subject: DNS performance... In-Reply-To: References: Message-ID: <4BE1855B.1090506@viagenie.ca> On 2010-05-05 10:41, Donald Eastlake wrote: > Does anyone know of good performance comparisons, especially for high > end applications with lots of data/zones and/or high query/update > rates? Recursive or authoritative? For recursive, there are pretty good graphs here: http://unbound.net/documentation/ripe56_unbound_02.pdf Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From nderitualex at gmail.com Wed May 5 09:48:19 2010 From: nderitualex at gmail.com (Alex Kamiru) Date: Wed, 05 May 2010 17:48:19 +0300 Subject: DNS performance... In-Reply-To: References: Message-ID: <1273070899.1860.5.camel@akamiru> Not sure of any comparison but I know BIND is widely used in the ISP space and they tend to have lots of zones as expected. -----Original Message----- From: Donald Eastlake To: nanog at nanog.org Subject: DNS performance... Date: Wed, 5 May 2010 10:41:24 -0400 Hi, There are a large number of DNS servers available. See for example http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software Does anyone know of good performance comparisons, especially for high end applications with lots of data/zones and/or high query/update rates? Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e3e3 at gmail.com From richard.barnes at gmail.com Wed May 5 09:52:15 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Wed, 5 May 2010 16:52:15 +0200 Subject: DNS performance... In-Reply-To: References: Message-ID: ... and here's the direct link to the full report: On Wed, May 5, 2010 at 4:48 PM, Richard Barnes wrote: > OARC did a performance study of a few name servers in the context of > root zone scaling, but it should be generalizable: > > > > > On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake wrote: >> Hi, >> >> There are a large number of DNS servers available. See for example >> http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software >> >> Does anyone know of good performance comparisons, especially for high >> end applications with lots of data/zones and/or high query/update >> rates? >> >> Thanks, >> Donald >> ============================= >> ?Donald E. Eastlake 3rd ? +1-508-333-2270 (cell) >> ?155 Beaver Street >> ?Milford, MA 01757 USA >> ?d3e3e3 at gmail.com >> >> > From d3e3e3 at gmail.com Wed May 5 10:03:11 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 5 May 2010 11:03:11 -0400 Subject: DNS performance... In-Reply-To: <4BE1855B.1090506@viagenie.ca> References: <4BE1855B.1090506@viagenie.ca> Message-ID: On Wed, May 5, 2010 at 10:48 AM, Simon Perreault wrote: > On 2010-05-05 10:41, Donald Eastlake wrote: >> >> Does anyone know of good performance comparisons, especially for high >> end applications with lots of data/zones and/or high query/update >> rates? > > Recursive or authoritative? I'm actually interested in both. Thanks for the pointer! Donald > For recursive, there are pretty good graphs here: > http://unbound.net/documentation/ripe56_unbound_02.pdf > > Simon > -- > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server ? ? ? ?--> http://numb.viagenie.ca > vCard 4.0 ? ? ? ? ? ? ? --> http://www.vcarddav.org From morrowc.lists at gmail.com Wed May 5 10:25:45 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 5 May 2010 11:25:45 -0400 Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: On Wed, May 5, 2010 at 5:39 AM, Mikael Abrahamsson wrote: > On Wed, 5 May 2010, Randy Bush wrote: > >>> Does anyone know how to contact whoever is responsible for this firewall >>> system to find out at the very least why this block is in place? >> >> read your newspaper > > It's not only now, they've been blocking badtalking the king for quite a > while. I was also under the impression that it wasn't by IP but that they > could block specific youtube videos etc. wccp boo on regimes that block internetz -chris From drc at virtualized.org Wed May 5 11:34:25 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 5 May 2010 09:34:25 -0700 Subject: Internationalized domain names in the root Message-ID: Perhaps a bit off-topic, but some folks might get support calls... http://?????-?????????.???/ (that's Arabic for .) Regards, -drc From mark at streamservice.nl Wed May 5 12:45:50 2010 From: mark at streamservice.nl (Mark Scholten) Date: Wed, 5 May 2010 19:45:50 +0200 Subject: DNS performance... In-Reply-To: References: Message-ID: <0eb401caec7a$cd237a20$676a6e60$@nl> > -----Original Message----- > From: Donald Eastlake [mailto:d3e3e3 at gmail.com] > Sent: Wednesday, May 05, 2010 4:41 PM > To: nanog at nanog.org > Subject: DNS performance... > > Hi, > > There are a large number of DNS servers available. See for example > http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > > Does anyone know of good performance comparisons, especially for high > end applications with lots of data/zones and/or high query/update > rates? > One of the links below should have information about this: - http://tin2.nixcartel.org/~devdas/presentation/dns-scalability.pdf - http://tin2.nixcartel.org/~devdas/presentation/dnsdb.pdf Please note this reports are not created by me. Regards, Mark > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3 at gmail.com From jmamodio at gmail.com Wed May 5 13:16:54 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 5 May 2010 13:16:54 -0500 Subject: Internationalized domain names in the root In-Reply-To: References: Message-ID: Great progress and interesting addition to the root, only issue is that after all the work with IDNs you land on a page written in english (web browser lang does not matter, name resolves to the same IP as the original URL). Hope they soon take advantage of the new name ... Cheers Jorge On Wed, May 5, 2010 at 11:34 AM, David Conrad wrote: > Perhaps a bit off-topic, but some folks might get support calls... > > http://?????-?????????.???/ > > (that's Arabic for .) > > Regards, > -drc From geoff at geoff.co.uk Wed May 5 13:27:37 2010 From: geoff at geoff.co.uk (Geoffrey Sisson) Date: Wed, 05 May 2010 11:27:37 -0700 Subject: DNS performance... In-Reply-To: References: Message-ID: <20100505182737.D9E015435F@smtp.geoff.co.uk> richard.barnes at gmail.com (Richard Barnes) wrote: > OARC did a performance study of a few name servers in the context of > root zone scaling, but it should be generalizable: > Note this study compares BIND and NSD only, and under a very specific set of conditions only, namely, serving a single large zone. Geoff (co-author of the study) > On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake wrote: > > Hi, > > > > There are a large number of DNS servers available. See for example > > http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > > > > Does anyone know of good performance comparisons, especially for high > > end applications with lots of data/zones and/or high query/update > > rates?> From nanog at nanog.org > From: nanog at nanog.org > Subject: Re: DNS performance... > Date: 5 May 10 14:48:12 GMT > > OARC did a performance study of a few name servers in the context of > root zone scaling, but it should be generalizable: > > > On Wed, May 5, 2010 at 4:41 PM, Donald Eastlake wrote: > > Hi, > > > > There are a large number of DNS servers available. See for example > > http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software > > > > Does anyone know of good performance comparisons, especially for high > > end applications with lots of data/zones and/or high query/update > > rates? From d3e3e3 at gmail.com Wed May 5 13:37:31 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Wed, 5 May 2010 14:37:31 -0400 Subject: DNS performance... In-Reply-To: <0eb401caec7a$cd237a20$676a6e60$@nl> References: <0eb401caec7a$cd237a20$676a6e60$@nl> Message-ID: On Wed, May 5, 2010 at 1:45 PM, Mark Scholten wrote: >> -----Original Message----- >> From: Donald Eastlake [mailto:d3e3e3 at gmail.com] >> Sent: Wednesday, May 05, 2010 4:41 PM >> ... >> >> Hi, >> >> There are a large number of DNS servers available. See for example >> http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software >> >> Does anyone know of good performance comparisons, especially for high >> end applications with lots of data/zones and/or high query/update >> rates? >> > One of the links below should have information about this: > - http://tin2.nixcartel.org/~devdas/presentation/dns-scalability.pdf > - http://tin2.nixcartel.org/~devdas/presentation/dnsdb.pdf Thanks for these pointers. For others who may be interested, the dns-scalability.pdf presentation appears to be a superset of the dnsdb.pdf presentation. Donald > Please note this reports are not created by me. > > Regards, Mark > >> Thanks, >> Donald >> ============================= >> ?Donald E. Eastlake 3rd ? +1-508-333-2270 (cell) >> ?155 Beaver Street >> ?Milford, MA 01757 USA >> ?d3e3e3 at gmail.com From joe.abley at icann.org Wed May 5 16:23:03 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 5 May 2010 14:23:03 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Root Zone DNSSEC Deployment Technical Status Update 2010-05-05 This is the sixth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. ** The final transition to a signed root zone took place today ** on J-Root, between 1700--1900 UTC. ** ** All root servers are now serving a signed root zone. ** ** All root servers will now generate larger responses to DNS ** queries that request DNSSEC information. ** ** If you experience technical problems or need to contact ** technical project staff, please send e-mail to rootsign at icann.org ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred ** if possible. ** ** See below for more details. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. DEPLOYMENT STATUS The incremental deployment of DNSSEC in the Root Zone is being carried out first by serving a Deliberately Unvalidatable Root Zone (DURZ), and subsequently by a conventionally signed root zone. Discussion of the approach can be found in the document "DNSSEC Deployment for the Root Zone", as well as in the technical presentations delivered at RIPE, NANOG, IETF and ICANN meetings. All of the thirteen root servers have now made the transition to the to the DURZ. No harmful effects have been identified. The final root server to make the transition, J-Root, started serving the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. Initial observations relating to this transition will be presented and discussed at the DNS Working Group meeting at RIPE 60 in Prague on 2010-05-06. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-07-01: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From tom at dyn.com Wed May 5 16:08:44 2010 From: tom at dyn.com (Tom Daly) Date: Wed, 5 May 2010 17:08:44 -0400 (EDT) Subject: [NANOG-announce] Update: NANOG 49 CFP In-Reply-To: <20100226155726.GA13442@1-4-5.net> Message-ID: <9437719.273351273093724776.JavaMail.root@mail.corp> Hello Fellow NANOG'ers, TLDR: The PC is still looking for great content for NANOG 49. Go upload abstracts and tutorials at https://pc.nanog.org. Just a quick note on behalf of the NANOG Program Committee that our next PC call will be next Tuesday, May 11th. Shortly after this meeting, we hope to post a draft agenda for NANOG 49, but we need your help - we still need a bit more content! For those of you that have submitted abstracts, now is a great time to upload your slides into the PC tool at https://pc.nanog.org, and for those who might want to give a talk to upload their abstracts and slides into the tool, again at https://pc.nanog.org. And while you're at it, take the time to go register for the conference at https://nanog.merit.edu/registration/, the Early Bird rate is still open. Thanks, and looking forward to seeing you all in San Francisco! Tom Daly, for the NANOG PC. -- Tom Daly CTO, Dynamic Network Services, Inc. http://dyn.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu May 6 05:44:50 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 6 May 2010 20:14:50 +0930 Subject: Thailand Internet firewall? In-Reply-To: References: Message-ID: <20100506201450.56bff197@opy.nosense.org> On Wed, 5 May 2010 09:45:06 +0000 "Dobbins, Roland" wrote: > > On May 5, 2010, at 4:39 PM, Mikael Abrahamsson wrote: > > > I was also under the impression that it wasn't by IP but that they could block specific youtube videos etc. > > They use a combination of IP blocking, DNS poisoning, and transparent HTTP proxy-based URL filtering. > I like to call them 'translucent proxies'. > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From gsomlo at gmail.com Thu May 6 13:12:44 2010 From: gsomlo at gmail.com (L. Gabriel Somlo) Date: Thu, 6 May 2010 14:12:44 -0400 Subject: DNS for RFC3180 GLOP reverse zone ? Message-ID: <20100506181242.GA23807@hedwig.net.cmu.edu> Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ? I get: 233.IN-ADDR.ARPA. 86400 IN NS FLAG.EP.NET. 233.IN-ADDR.ARPA. 86400 IN NS NIC.NEAR.NET. 233.IN-ADDR.ARPA. 86400 IN NS STRUL.STUPI.SE. 233.IN-ADDR.ARPA. 86400 IN NS NS.ISI.EDU. ;; Received 138 bytes from 192.228.79.201#53(b.root-servers.net) in 91 ms Of these, only FLAG.EP.NET actually seems to work; NIC.NEAR.NET no longer seems to exist STRUL.STUPI.SE returns SERVFAIL NS.ISI.EDU returns REFUSED I also tried to send email to hostmaster at ep.net to have a delegation updated, but got a bounce... I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported, or should I just give up :) Thanks, --Gabriel From gadams+nanog at avernus.com Thu May 6 13:45:36 2010 From: gadams+nanog at avernus.com (Geoff Adams) Date: Thu, 6 May 2010 14:45:36 -0400 Subject: Internationalized domain names in the root In-Reply-To: References: Message-ID: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> On 5 May 2010, at 2:16 PM, Jorge Amodio wrote: > On Wed, May 5, 2010 at 11:34 AM, David Conrad wrote: >> Perhaps a bit off-topic, but some folks might get support calls... >> >> http://?????-?????????.???/ >> >> (that's Arabic for .) > > Great progress and interesting addition to the root, only issue is > that after all the work with IDNs you land on a page written in > english (web browser lang does not matter, name resolves to the same > IP as the original URL). Hope they soon take advantage of the new name The page shows up in Arabic for me in all three of Safari (in which the URL bar also shows the Arabic name), Chrome and Firefox (in both of which the URL bar shows the encoded US-ASCII characters for the domain name). I tested using the Mac versions of these three browsers, and English is set as my preferred language. Arabic doesn't appear until much farther down on the list. The Safari experience looks nicer, but I suppose it leaves its users more susceptible to maliciously-constructed domain names that look similar to well-known ones. I wonder if they've addressed that issue in some way. I haven't been checking recently. - Geoff From jmamodio at gmail.com Thu May 6 13:59:03 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 6 May 2010 13:59:03 -0500 Subject: Internationalized domain names in the root In-Reply-To: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> References: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> Message-ID: Hi Geoff, yes, as I reported through other channels today the new IDN based URL started landing on the Arabic version of the page. Kudos for the folks in Egypt that are now taking advantage of the new ccTLD. I noticed testing with IE8, Chrome, FFox and Safari, that Safari is the only one that keeps showing the original URL in Arabic in the navigation toolbar, all the others switch to the ASCII encoded one. I guess there is more work/configuration to be done on the client side. Cheers Jorge On Thu, May 6, 2010 at 1:45 PM, Geoff Adams wrote: > On 5 May 2010, at 2:16 PM, Jorge Amodio wrote: >> On Wed, May 5, 2010 at 11:34 AM, David Conrad wrote: >>> Perhaps a bit off-topic, but some folks might get support calls... >>> >>> http://?????-?????????.???/ >>> >>> (that's Arabic for .) >> >> Great progress and interesting addition to the root, only issue is >> that after all the work with IDNs you land on a page written in >> english (web browser lang does not matter, name resolves to the same >> IP as the original URL). Hope they soon take advantage of the new name > > The page shows up in Arabic for me in all three of Safari (in which the URL bar also shows the Arabic name), Chrome and Firefox (in both of which the URL bar shows the encoded US-ASCII characters for the domain name). I tested using the Mac versions of these three browsers, and English is set as my preferred language. Arabic doesn't appear until much farther down on the list. > > The Safari experience looks nicer, but I suppose it leaves its users more susceptible to maliciously-constructed domain names that look similar to well-known ones. I wonder if they've addressed that issue in some way. I haven't been checking recently. > > - Geoff > From jcdill.lists at gmail.com Thu May 6 14:01:50 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 06 May 2010 12:01:50 -0700 Subject: Internationalized domain names in the root In-Reply-To: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> References: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> Message-ID: <4BE3121E.5060805@gmail.com> Geoff Adams wrote: > On 5 May 2010, at 2:16 PM, Jorge Amodio wrote: > >> On Wed, May 5, 2010 at 11:34 AM, David Conrad wrote: >> >>> Perhaps a bit off-topic, but some folks might get support calls... >>> >>> http://?????-?????????.???/ >>> >>> (that's Arabic for .) >>> >> Great progress and interesting addition to the root, only issue is >> that after all the work with IDNs you land on a page written in >> english (web browser lang does not matter, name resolves to the same >> IP as the original URL). Hope they soon take advantage of the new name >> > > The page shows up in Arabic for me in all three of Safari When I first checked this site yesterday, I saw a page in English[1]. The same page is in Arabic today, in the same browsers that displayed English when I checked yesterday. I assume the server admin waited until the domain went live before implementing language display selection based on the URL used to reach the site, and now it's working correctly. [1] Such as I see when I use this URL instead: http://www.mcit.gov.eg/ jc From tony at lava.net Thu May 6 14:18:48 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 6 May 2010 09:18:48 -1000 (HST) Subject: DNS for RFC3180 GLOP reverse zone ? In-Reply-To: <20100506181242.GA23807@hedwig.net.cmu.edu> References: <20100506181242.GA23807@hedwig.net.cmu.edu> Message-ID: On Thu, 6 May 2010, L. Gabriel Somlo wrote: > Does anyone know what's going on with DNS for 233.IN-ADDR.ARPA ? > Of these, only FLAG.EP.NET actually seems to work; > > NIC.NEAR.NET no longer seems to exist > > STRUL.STUPI.SE returns SERVFAIL > > NS.ISI.EDU returns REFUSED > > I also tried to send email to hostmaster at ep.net to have a delegation > updated, but got a bounce... > > I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported, > or should I just give up :) I think this has been broken for a while now. But if you ever figure out who can delegate the zones let me know :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From zaid at zaidali.com Thu May 6 15:27:00 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 06 May 2010 13:27:00 -0700 Subject: Internationalized domain names in the root In-Reply-To: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> Message-ID: I agree Safari experience looks much nicer and yes whole host of potential malice to arise. Firefox shows punycode http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ar/default.aspx Now if I understood arabic only and was travelling or happen to use Firefox which showed punycode how would I trust it? If it was directly translated to latin characters I could trust it with verification from someone I know who understands english. I would not trust puny code because an end user does not know what it means, I think there is potential for a lot of issues here. Zaid On 5/6/10 11:45 AM, "Geoff Adams" wrote: > On 5 May 2010, at 2:16 PM, Jorge Amodio wrote: >> On Wed, May 5, 2010 at 11:34 AM, David Conrad wrote: >>> Perhaps a bit off-topic, but some folks might get support calls... >>> >>> http://?????-?????????.???/ >>> >>> (that's Arabic for .) >> >> Great progress and interesting addition to the root, only issue is >> that after all the work with IDNs you land on a page written in >> english (web browser lang does not matter, name resolves to the same >> IP as the original URL). Hope they soon take advantage of the new name > > The page shows up in Arabic for me in all three of Safari (in which the URL > bar also shows the Arabic name), Chrome and Firefox (in both of which the URL > bar shows the encoded US-ASCII characters for the domain name). I tested using > the Mac versions of these three browsers, and English is set as my preferred > language. Arabic doesn't appear until much farther down on the list. > > The Safari experience looks nicer, but I suppose it leaves its users more > susceptible to maliciously-constructed domain names that look similar to > well-known ones. I wonder if they've addressed that issue in some way. I > haven't been checking recently. > > - Geoff From nonobvious at gmail.com Thu May 6 15:26:52 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 6 May 2010 13:26:52 -0700 Subject: Internationalized domain names in the root In-Reply-To: <4BE3121E.5060805@gmail.com> References: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> <4BE3121E.5060805@gmail.com> Message-ID: I'm getting three different behaviours from Firefox - I have the page open in a tab. The tab header is in Arabic script. (And the page itself renders fine in Arabic.) - When I go to that tab, the main Firefox window title shows boxes (i.e. "don't have the font for this.") - When I go to that tab, the Address Bar shows ugly punycode xn-format junk. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From nonobvious at gmail.com Thu May 6 15:26:52 2010 From: nonobvious at gmail.com (Bill Stewart) Date: Thu, 6 May 2010 13:26:52 -0700 Subject: Internationalized domain names in the root In-Reply-To: <4BE3121E.5060805@gmail.com> References: <689997AE-42C1-4759-8006-9F5BBE07E651@avernus.com> <4BE3121E.5060805@gmail.com> Message-ID: I'm getting three different behaviours from Firefox - I have the page open in a tab. The tab header is in Arabic script. (And the page itself renders fine in Arabic.) - When I go to that tab, the main Firefox window title shows boxes (i.e. "don't have the font for this.") - When I go to that tab, the Address Bar shows ugly punycode xn-format junk. -- ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it. From jabley at hopcount.ca Thu May 6 15:57:43 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 6 May 2010 22:57:43 +0200 Subject: Internationalized domain names in the root In-Reply-To: References: Message-ID: <058CF564-E1E6-4AAD-A01D-5634A0D98A68@hopcount.ca> On 2010-05-06, at 22:27, Zaid Ali wrote: > Now if I understood arabic only and was travelling or happen to use Firefox > which showed punycode how would I trust it? I agree, that seems like nonsense. The answer for non-Arabic-speakers who are concerned about whether an Arabic URL is a phishing site is presumably just not to follow any Arabic URLs. They're surely intended for people that don't have that problem. Joe From mysidia at gmail.com Thu May 6 22:14:34 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 6 May 2010 22:14:34 -0500 Subject: DNS for RFC3180 GLOP reverse zone ? In-Reply-To: <20100506181242.GA23807@hedwig.net.cmu.edu> References: <20100506181242.GA23807@hedwig.net.cmu.edu> Message-ID: On Thu, May 6, 2010 at 1:12 PM, L. Gabriel Somlo wrote: .. > I wonder if DNS for GLOP/RFC3180 is still expected to work/be supported, > or should I just give up :) > Thanks, I am not sure, but I believe as a best practice, RFC3180 is considered basically defunct at this point, it's obvious that at least the RDNS is neglected. The problem is that it relied on mapping bits from the AS number into the IP address bitspace. Now that AS numbers have been extended to 4 bytes in length, and RIRs are even about to stop differentiating between them when allocating AS numbers, or allowing anyone to request and be sure of getting a new 16-bit ASN. It seems that it will be impossible for the scheme to be followed in IPv4. A more sensible BCP at this point would be to designate the entire 223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535, since most ASNs are not using GLOP addressing. Mapping ASN bits onto multicast IP ranges is convenient but wasteful too, once you consider >2^16 ASNs. -- -J From pekkas at netcore.fi Fri May 7 00:29:08 2010 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 7 May 2010 08:29:08 +0300 (EEST) Subject: DNS for RFC3180 GLOP reverse zone ? In-Reply-To: References: <20100506181242.GA23807@hedwig.net.cmu.edu> Message-ID: On Thu, 6 May 2010, James Hess wrote: > Now that AS numbers have been extended to 4 bytes in length, and RIRs > are even about to stop differentiating between them when allocating > AS numbers, or allowing anyone to request and be sure of getting a new > 16-bit ASN. Then you may be interested to see this Last Call: http://www.ietf.org/mail-archive/web/mboned/current/msg01021.html (draft-ietf-mboned-ipv4-uni-based-mcast) > It seems that it will be impossible for the scheme to be followed in IPv4. > A more sensible BCP at this point would be to designate the entire > 223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535, > since most ASNs are not using GLOP addressing. Uhh. Take away the numbers from those who have already started using them? Are you serious? There were multiple attempts to the private etc. ASN parts of 233/8 to RIRs but these have failed (lack of interest?). The current situation (RFC5771) is that this has been designated as "AD-HOC Block III" and is assignable from IANA. The curious minds may also want to take a look at: http://tools.ietf.org/html/draft-ietf-mboned-addrarch-06 (Comments welcome, this has been waiting the completion of abovementioned draft.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From tme at americafree.tv Fri May 7 09:35:58 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 7 May 2010 10:35:58 -0400 Subject: DNS for RFC3180 GLOP reverse zone ? In-Reply-To: References: <20100506181242.GA23807@hedwig.net.cmu.edu> Message-ID: On May 6, 2010, at 11:14 PM, James Hess wrote: > On Thu, May 6, 2010 at 1:12 PM, L. Gabriel Somlo > wrote: .. >> I wonder if DNS for GLOP/RFC3180 is still expected to work/be >> supported, >> or should I just give up :) > Thanks, > > I am not sure, but I believe as a best practice, RFC3180 is > considered basically defunct at this point, it's obvious that at least > the RDNS is neglected. The problem is that it relied on mapping bits > from the AS number into the IP address bitspace. > > Now that AS numbers have been extended to 4 bytes in length, and RIRs > are even about to stop differentiating between them when allocating > AS numbers, or allowing anyone to request and be sure of getting a new > 16-bit ASN. > > It seems that it will be impossible for the scheme to be followed in > IPv4. > A more sensible BCP at this point would be to designate the entire > 223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535, > since most ASNs are not using GLOP addressing. > Look at RFC 5771 While it is no longer automatic, entities with 4 byte ASN can get multicast addresses from the AD-HOC Block III (the old extended GLOP space). Regards Marshall > Mapping ASN bits onto multicast IP ranges is convenient but wasteful > too, once you consider >2^16 ASNs. > > -- > -J > > From cscora at apnic.net Fri May 7 13:10:07 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 8 May 2010 04:10:07 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201005071810.o47IA8aO019914@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 08 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 320551 Prefixes after maximum aggregation: 147789 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 155617 Total ASes present in the Internet Routing Table: 33946 Prefixes per ASN: 9.44 Origin-only ASes present in the Internet Routing Table: 29466 Origin ASes announcing only one prefix: 14348 Transit ASes present in the Internet Routing Table: 4480 Transit-only ASes present in the Internet Routing Table: 104 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 28 Max AS path prepend of ASN (28009) 24 Prefixes from unregistered ASNs in the Routing Table: 335 Unregistered ASNs in the Routing Table: 119 Number of 32-bit ASNs allocated by the RIRs: 560 Prefixes from 32-bit ASNs in the Routing Table: 627 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 191 Number of addresses announced to Internet: 2206289024 Equivalent to 131 /8s, 129 /16s and 76 /24s Percentage of available address space announced: 59.5 Percentage of allocated address space announced: 65.5 Percentage of available address space allocated: 90.9 Percentage of address space in use by end-sites: 82.7 Total number of prefixes smaller than registry allocations: 153719 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76663 Total APNIC prefixes after maximum aggregation: 26693 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 73330 Unique aggregates announced from the APNIC address blocks: 32173 APNIC Region origin ASes present in the Internet Routing Table: 4023 APNIC Prefixes per ASN: 18.23 APNIC Region origin ASes announcing only one prefix: 1099 APNIC Region transit ASes present in the Internet Routing Table: 624 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 512199488 Equivalent to 30 /8s, 135 /16s and 139 /24s Percentage of available APNIC address space announced: 76.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/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: 133881 Total ARIN prefixes after maximum aggregation: 68854 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106747 Unique aggregates announced from the ARIN address blocks: 40648 ARIN Region origin ASes present in the Internet Routing Table: 13674 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5269 ARIN Region transit ASes present in the Internet Routing Table: 1356 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 726628384 Equivalent to 43 /8s, 79 /16s and 120 /24s Percentage of available ARIN address space announced: 61.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, 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, 54/8, 55/8, 56/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, 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: 73657 Total RIPE prefixes after maximum aggregation: 42784 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 66596 Unique aggregates announced from the RIPE address blocks: 43811 RIPE Region origin ASes present in the Internet Routing Table: 14438 RIPE Prefixes per ASN: 4.61 RIPE Region origin ASes announcing only one prefix: 7467 RIPE Region transit ASes present in the Internet Routing Table: 2160 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 425267232 Equivalent to 25 /8s, 89 /16s and 16 /24s Percentage of available RIPE address space announced: 79.2 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, 196608-197631 RIPE Address Blocks 2/8, 25/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, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28582 Total LACNIC prefixes after maximum aggregation: 6782 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 27004 Unique aggregates announced from the LACNIC address blocks: 13936 LACNIC Region origin ASes present in the Internet Routing Table: 1274 LACNIC Prefixes per ASN: 21.20 LACNIC Region origin ASes announcing only one prefix: 407 LACNIC Region transit ASes present in the Internet Routing Table: 219 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 28 Number of LACNIC addresses announced to Internet: 72850944 Equivalent to 4 /8s, 87 /16s and 158 /24s Percentage of available LACNIC address space announced: 72.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 6925 Total AfriNIC prefixes after maximum aggregation: 1807 AfriNIC Deaggregation factor: 3.83 Prefixes being announced from the AfriNIC address blocks: 5246 Unique aggregates announced from the AfriNIC address blocks: 1647 AfriNIC Region origin ASes present in the Internet Routing Table: 359 AfriNIC Prefixes per ASN: 14.61 AfriNIC Region origin ASes announcing only one prefix: 106 AfriNIC Region transit ASes present in the Internet Routing Table: 80 Average AfriNIC Region AS path length visible: 3.9 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC addresses announced to Internet: 16793344 Equivalent to 1 /8s, 0 /16s and 63 /24s Percentage of available AfriNIC address space announced: 50.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1847 8406 480 Korea Telecom (KIX) 17488 1314 140 123 Hathway IP Over Cable Interne 4755 1290 291 148 TATA Communications formerly 7545 1185 232 104 TPG Internet Pty Ltd 17974 1034 281 18 PT TELEKOMUNIKASI INDONESIA 9583 993 73 489 Sify Limited 4134 950 20455 399 CHINANET-BACKBONE 24560 891 304 166 Bharti Airtel Ltd., Telemedia 4808 844 1589 215 CNCGROUP IP network: China169 9829 794 679 41 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3931 3733 288 bellsouth.net, inc. 4323 3834 1116 406 Time Warner Telecom 1785 1784 699 131 PaeTec Communications, Inc. 7018 1551 5757 984 AT&T WorldNet Services 20115 1536 1505 655 Charter Communications 2386 1305 585 925 AT&T Data Communications Serv 6478 1219 250 152 AT&T Worldnet Services 3356 1207 10920 420 Level 3 Communications, LLC 22773 1153 2606 72 Cox Communications, Inc. 11492 1148 222 14 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 617 56 6 United Telecom of Georgia 3292 452 2027 393 TDC Tele Danmark 30890 438 100 205 Evolva Telecom 702 413 1869 329 UUNET - Commercial IP service 8551 403 356 37 Bezeq International 8866 395 117 18 Bulgarian Telecommunication C 3301 365 1413 321 TeliaNet Sweden 3320 365 7072 318 Deutsche Telekom AG 3215 346 3218 102 France Telecom Transpac 12479 330 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1550 2965 245 UniNet S.A. de C.V. 10620 1031 230 148 TVCABLE BOGOTA 28573 889 727 89 NET Servicos de Comunicao S.A 7303 724 375 101 Telecom Argentina Stet-France 6503 562 172 211 AVANTEL, S.A. 22047 547 310 15 VTR PUNTO NET S.A. 18881 544 268 11 Global Village Telecom 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 460 195 70 Empresa Nacional de Telecomun 14117 447 30 13 Telefonica del Sur S.A. Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 920 189 9 TEDATA 24863 712 147 42 LINKdotNET AS number 36992 626 273 172 Etisalat MISR 3741 273 852 232 The Internet Solution 33776 216 11 14 Starcomms Nigeria Limited 2018 215 230 111 Tertiary Education Network 24835 183 78 10 RAYA Telecom - Egypt 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3931 3733 288 bellsouth.net, inc. 4323 3834 1116 406 Time Warner Telecom 4766 1847 8406 480 Korea Telecom (KIX) 1785 1784 699 131 PaeTec Communications, Inc. 7018 1551 5757 984 AT&T WorldNet Services 8151 1550 2965 245 UniNet S.A. de C.V. 20115 1536 1505 655 Charter Communications 17488 1314 140 123 Hathway IP Over Cable Interne 2386 1305 585 925 AT&T Data Communications Serv 4755 1290 291 148 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3834 3428 Time Warner Telecom 1785 1784 1653 PaeTec Communications, Inc. 4766 1847 1367 Korea Telecom (KIX) 8151 1550 1305 UniNet S.A. de C.V. 17488 1314 1191 Hathway IP Over Cable Interne 4755 1290 1142 TATA Communications formerly 11492 1148 1134 Cable One 7545 1185 1081 TPG Internet Pty Ltd 22773 1153 1081 Cox Communications, Inc. 6478 1219 1067 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 1239 Sprint 26973 UNALLOCATED 12.39.154.0/23 1239 Sprint 26973 UNALLOCATED 12.39.155.0/24 1239 Sprint 26973 UNALLOCATED 12.39.159.0/24 1239 Sprint 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 46.0.0.0/16 12654 RIPE NCC RIS Project Complete listing at http://thyme.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:10 /10:25 /11:67 /12:191 /13:398 /14:688 /15:1265 /16:11053 /17:5274 /18:8964 /19:18279 /20:22518 /21:22662 /22:29424 /23:29006 /24:167759 /25:955 /26:1199 /27:630 /28:141 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2516 3931 bellsouth.net, inc. 4323 2333 3834 Time Warner Telecom 4766 1481 1847 Korea Telecom (KIX) 1785 1245 1784 PaeTec Communications, Inc. 17488 1063 1314 Hathway IP Over Cable Interne 11492 1056 1148 Cable One 18566 1040 1059 Covad Communications 10620 947 1031 TVCABLE BOGOTA 7018 930 1551 AT&T WorldNet Services 9583 845 993 Sify Limited Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 4:13 8:263 12:2006 13:10 15:23 16:3 17:8 20:21 24:1417 27:56 32:47 33:12 38:665 40:97 41:2159 44:3 46:1 47:25 52:6 55:6 56:2 57:24 58:722 59:517 60:431 61:1085 62:1043 63:1979 64:3839 65:2368 66:4179 67:1824 68:1089 69:2817 70:710 71:240 72:1832 73:2 74:2274 75:249 76:308 77:856 78:628 79:391 80:993 81:788 82:472 83:445 84:702 85:1046 86:457 87:697 88:325 89:1551 90:87 91:2736 92:480 93:1098 94:1400 95:589 96:246 97:309 98:566 99:28 109:467 110:330 111:501 112:255 113:287 114:395 115:586 116:1023 117:636 118:427 119:955 120:148 121:741 122:1434 123:884 124:1109 125:1298 128:210 129:208 130:197 131:561 132:246 133:17 134:194 135:45 136:225 137:171 138:254 139:92 140:485 141:136 142:354 143:383 144:473 145:52 146:427 147:167 148:595 149:316 150:153 151:169 152:262 153:167 154:2 155:329 156:184 157:324 158:107 159:368 160:315 161:204 162:270 163:171 164:411 165:532 166:497 167:396 168:801 169:161 170:700 171:50 172:1 173:721 174:664 175:92 178:74 180:455 182:48 183:253 184:39 186:378 187:320 188:1294 189:778 190:3639 192:5732 193:4690 194:3357 195:2764 196:1194 197:1 198:3574 199:3438 200:5347 201:1515 202:7980 203:8276 204:4050 205:2336 206:2535 207:3034 208:3922 209:3432 210:2506 211:1239 212:1730 213:1679 214:664 215:70 216:4566 217:1545 218:504 219:381 220:1107 221:400 222:313 End of report From cidr-report at potaroo.net Fri May 7 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 May 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201005072200.o47M03B4093734@wattle.apnic.net> BGP Update Report Interval: 29-Apr-10 -to- 06-May-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17488 61957 4.8% 53.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 2 - AS9498 25882 2.0% 41.4 -- BBIL-AP BHARTI Airtel Ltd. 3 - AS9829 22482 1.7% 24.0 -- BSNL-NIB National Internet Backbone 4 - AS9583 17345 1.3% 46.0 -- SIFY-AS-IN Sify Limited 5 - AS18207 15776 1.2% 52.8 -- IQARA-INDIA-AP Iqara Telecom India Pvt Ltd. 6 - AS35805 13424 1.0% 21.7 -- UTG-AS United Telecom AS 7 - AS30890 13274 1.0% 31.1 -- EVOLVA Evolva Telecom s.r.l. 8 - AS8386 12219 0.9% 152.7 -- KOCNET KOCNET-AS 9 - AS4538 10782 0.8% 399.3 -- ERX-CERNET-BKB China Education and Research Network Center 10 - AS29049 10767 0.8% 37.0 -- DELTA-TELECOM-AS Delta Telecom LTD. 11 - AS28477 10597 0.8% 10597.0 -- Universidad Autonoma del Esstado de Morelos 12 - AS36992 10094 0.8% 15.6 -- ETISALAT-MISR 13 - AS7633 8992 0.7% 62.0 -- SOFTNET-AS-AP Software Technology Parks of India - Bangalore 14 - AS14420 7871 0.6% 19.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 15 - AS9198 7660 0.6% 32.5 -- KAZTELECOM-AS JSC Kazakhtelecom 16 - AS8452 7497 0.6% 10.5 -- TEDATA TEDATA 17 - AS22047 7494 0.6% 57.6 -- VTR BANDA ANCHA S.A. 18 - AS5800 7444 0.6% 36.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS12479 7438 0.6% 275.5 -- UNI2-AS Uni2 - Lince telecomunicaciones 20 - AS8151 6857 0.5% 11.8 -- Uninet S.A. de C.V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS28477 10597 0.8% 10597.0 -- Universidad Autonoma del Esstado de Morelos 2 - AS47346 3376 0.3% 3376.0 -- ELECOM-NT-AS Elecom-NT LLC 3 - AS13004 2646 0.2% 2646.0 -- SOX Serbian Open Exchange 4 - AS26025 2229 0.2% 2229.0 -- COC - City of Calgary 5 - AS16569 2217 0.2% 2217.0 -- ASN-CITY-OF-CALGARY - City of Calgary 6 - AS48754 1547 0.1% 1547.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 7 - AS38680 1375 0.1% 1375.0 -- CMBHK-AS-KR CMB 8 - AS3397 839 0.1% 839.0 -- DAVINCI - Davinci Broadband Inc. 9 - AS28671 757 0.1% 757.0 -- Konecta Telecomunica??es Ltda 10 - AS11613 744 0.1% 744.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 11 - AS30341 1837 0.1% 612.3 -- SCTA-ASN - South Central Telephone Association 12 - AS44663 580 0.0% 580.0 -- INFOPROCESS-PL-AS Infoprocess Solutions 13 - AS18399 2152 0.2% 538.0 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 14 - AS4538 10782 0.8% 399.3 -- ERX-CERNET-BKB China Education and Research Network Center 15 - AS10445 2326 0.2% 387.7 -- HTG - Huntleigh Telcom 16 - AS28052 371 0.0% 371.0 -- Arte Radiotelevisivo Argentino 17 - AS38468 346 0.0% 346.0 -- YESBANK-IN ASN for YESBANK 18 - AS47593 345 0.0% 345.0 -- ATELECOM A-Telcom Ltd 19 - AS3505 684 0.1% 342.0 -- WINDSTREAM - Windstream Communications Inc 20 - AS36977 4971 0.4% 310.7 -- WARID-AS TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 58.207.96.0/19 10669 0.8% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 2 - 200.13.36.0/24 10597 0.8% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 93.191.104.0/21 3376 0.2% AS47346 -- ELECOM-NT-AS Elecom-NT LLC 4 - 202.92.235.0/24 3338 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 5 - 188.187.184.0/24 3241 0.2% AS41786 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 6 - 206.184.16.0/24 2921 0.2% AS174 -- COGENT Cogent/PSI 7 - 193.105.163.0/24 2646 0.2% AS13004 -- SOX Serbian Open Exchange 8 - 85.60.194.0/23 2486 0.2% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 9 - 143.138.107.0/24 2288 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 10 - 208.98.231.0/24 2229 0.2% AS26025 -- COC - City of Calgary 11 - 208.98.230.0/24 2217 0.2% AS16569 -- ASN-CITY-OF-CALGARY - City of Calgary 12 - 203.81.166.0/24 2068 0.1% AS18399 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 13 - 85.60.192.0/23 1570 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 14 - 91.212.23.0/24 1547 0.1% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 15 - 180.233.225.0/24 1375 0.1% AS38680 -- CMBHK-AS-KR CMB 16 - 90.150.0.0/24 1236 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 17 - 85.60.208.0/21 1112 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 18 - 205.91.160.0/20 1106 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - 85.60.208.0/22 1100 0.1% AS12479 -- UNI2-AS Uni2 - Lince telecomunicaciones 20 - 220.113.32.0/20 952 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 May 7 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 7 May 2010 22:00:01 GMT Subject: The Cidr Report Message-ID: <201005072200.o47M01Er093729@wattle.apnic.net> This report has been generated at Fri May 7 21:12:12 2010 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 30-04-10 322501 198664 01-05-10 322647 198609 02-05-10 322742 198643 03-05-10 322708 198607 04-05-10 322474 198576 05-05-10 322691 198520 06-05-10 322670 198937 07-05-10 322970 198880 AS Summary 34333 Number of ASes in routing system 14613 Number of ASes announcing only one prefix 4425 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97317792 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'). --- 07May10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 323126 198866 124260 38.5% All ASes AS6389 3931 293 3638 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4425 1509 2916 65.9% TWTC - tw telecom holdings, inc. AS4766 1847 494 1353 73.3% KIXS-AS-KR Korea Telecom AS4755 1290 203 1087 84.3% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1152 77 1075 93.3% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1314 300 1014 77.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7545 1189 236 953 80.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS18566 1059 159 900 85.0% COVAD - Covad Communications Co. AS8151 1553 666 887 57.1% Uninet S.A. de C.V. AS6478 1219 340 879 72.1% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1031 153 878 85.2% Telmex Colombia S.A. AS19262 1088 270 818 75.2% VZGNI-TRANSIT - Verizon Internet Services Inc. AS5668 833 202 631 75.8% AS-5668 - CenturyTel Internet Holdings, Inc. AS7303 731 107 624 85.4% Telecom Argentina S.A. AS1785 1784 1173 611 34.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS4808 844 256 588 69.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1553 987 566 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS8452 920 361 559 60.8% TEDATA TEDATA AS35805 617 64 553 89.6% UTG-AS United Telecom AS AS18101 668 121 547 81.9% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS24560 891 351 540 60.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 890 353 537 60.3% NET Servicos de Comunicao S.A. AS3356 1208 699 509 42.1% LEVEL3 Level 3 Communications AS4780 673 169 504 74.9% SEEDNET Digital United Inc. AS17676 569 78 491 86.3% GIGAINFRA Softbank BB Corp. AS9443 555 74 481 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17908 528 57 471 89.2% TCISL Tata Communications AS7011 1121 674 447 39.9% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 36638 10540 26098 71.2% Top 30 total Possible Bogus Routes 41.202.96.0/19 AS29571 CITelecom-AS 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 46.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 46.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.40.0/22 AS24399 ABN-PEERING-AS-AP Asia Broadcast Networks Peering AS 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.160.200.0/23 AS45122 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.52.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.15.170.0/24 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeroen at mompl.net Fri May 7 20:13:50 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 07 May 2010 18:13:50 -0700 Subject: Internationalized domain names in the root In-Reply-To: References: Message-ID: <4BE4BACE.5060900@mompl.net> David Conrad wrote: > Perhaps a bit off-topic, but some folks might get support calls... > > http://?????-?????????.???/ That actually looks quite handsome. :-) -- http://goldmark.org/jeff/stupid-disclaimers/ From beckman at angryox.com Sat May 8 00:53:28 2010 From: beckman at angryox.com (Peter Beckman) Date: Sat, 8 May 2010 01:53:28 -0400 Subject: Internationalized domain names in the root In-Reply-To: <4BE4BACE.5060900@mompl.net> References: <4BE4BACE.5060900@mompl.net> Message-ID: On Fri, 7 May 2010, Jeroen van Aart wrote: > David Conrad wrote: >> Perhaps a bit off-topic, but some folks might get support calls... >> >> http://?????-?????????.???/ > > That actually looks quite handsome. :-) And this is what it looks like to DNS: http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ Hurrah for Punycode. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From neil at tonal.clara.co.uk Sat May 8 07:29:10 2010 From: neil at tonal.clara.co.uk (Neil Harris) Date: Sat, 08 May 2010 13:29:10 +0100 Subject: Internationalized domain names in the root In-Reply-To: References: Message-ID: <4BE55916.4030408@tonal.clara.co.uk> On 06/05/10 21:27, Zaid Ali wrote: > I agree Safari experience looks much nicer and yes whole host of potential > malice to arise. Firefox shows punycode > > http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ar/default.aspx > > Now if I understood arabic only and was travelling or happen to use Firefox > which showed punycode how would I trust it? If it was directly translated to > latin characters I could trust it with verification from someone I know who > understands english. I would not trust puny code because an end user does > not know what it means, I think there is potential for a lot of issues here. > > Zaid > > This is indeed a security issue, and the behaviour in Firefox is currently that way by design. To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the Mozilla Foundation in order to inform the Foundation of their official IDN name allocation policy, so that the native-script URL display can then be switched on for their domain. See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and http://www.mozilla.org/projects/security/tld-idn-policy-list.html -- Neil From regnauld at nsrc.org Sat May 8 07:36:22 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Sat, 8 May 2010 14:36:22 +0200 Subject: Internationalized domain names in the root In-Reply-To: <4BE55916.4030408@tonal.clara.co.uk> References: <4BE55916.4030408@tonal.clara.co.uk> Message-ID: <20100508123622.GA2552@macbook.catpipe.net> Neil Harris (neil) writes: > > To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the > Mozilla Foundation in order to inform the Foundation of their > official IDN name allocation policy, so that the native-script URL > display can then be switched on for their domain. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and > http://www.mozilla.org/projects/security/tld-idn-policy-list.html Wow, talk about layer violation. Is there a central place where various TLDs' IDN policies will be maintained ? I see a scalability issue if TLDs have to communicate to every single application maintainer out there what their policy is. Cheers, Phil From johnl at iecc.com Sat May 8 10:48:40 2010 From: johnl at iecc.com (John Levine) Date: 8 May 2010 15:48:40 -0000 Subject: Internationalized domain names in the root In-Reply-To: <20100508123622.GA2552@macbook.catpipe.net> Message-ID: <20100508154840.36689.qmail@joyce.lan> >> To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the >> Mozilla Foundation in order to inform the Foundation of their >> official IDN name allocation policy, so that the native-script URL >> display can then be switched on for their domain. > > Wow, talk about layer violation. Yeah, security can be like that. Things which technically are treated the same are often semantically very different. > Is there a central place where various TLDs' IDN policies will > be maintained ? Yes, of course. See http://www.iana.org/domains/idn-tables/ It doesn't have the new IDN TLDs yet, but that's not surprising since ICANN didn't bother to tell the registries in advance that would be making the TLDs active. See http://www.circleid.com/posts/by_the_way_your_idn_is_live/ R's, John From LarrySheldon at cox.net Sat May 8 13:43:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sat, 08 May 2010 13:43:50 -0500 Subject: Internationalized domain names in the root In-Reply-To: <20100508123622.GA2552@macbook.catpipe.net> References: <4BE55916.4030408@tonal.clara.co.uk> <20100508123622.GA2552@macbook.catpipe.net> Message-ID: <4BE5B0E6.8010805@cox.net> On 5/8/2010 07:36, Phil Regnauld wrote: > Neil Harris (neil) writes: >> >> To fix it, the .eg / .xn--4gbrim TLD registrar needs to contact the >> Mozilla Foundation in order to inform the Foundation of their >> official IDN name allocation policy, so that the native-script URL >> display can then be switched on for their domain. >> >> See https://bugzilla.mozilla.org/show_bug.cgi?id=564213 and >> http://www.mozilla.org/projects/security/tld-idn-policy-list.html > > Wow, talk about layer violation. > > Is there a central place where various TLDs' IDN policies will > be maintained ? I see a scalability issue if TLDs have to communicate > to every single application maintainer out there what their policy is. Wait until the FCC, FTC, and IRS finish taking over the Internet. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jimb at jsbc.cc Sat May 8 14:20:32 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Sat, 08 May 2010 12:20:32 -0700 Subject: Internationalized domain names in the root In-Reply-To: References: <4BE4BACE.5060900@mompl.net> Message-ID: <4BE5B980.7060905@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/7/2010 22:53, Peter Beckman wrote: > On Fri, 7 May 2010, Jeroen van Aart wrote: > >> David Conrad wrote: >>> Perhaps a bit off-topic, but some folks might get support calls... >>> >>> http://?????-?????????.???/ >> >> That actually looks quite handsome. :-) > > And this is what it looks like to DNS: > > http://xn--4gbrim.xn----rmckbbajlc6dj7bxne2c.xn--wgbh1c/ > > Hurrah for Punycode. Yeah I was experimenting around with that yesterday. Imagine a zone file full of such domain names. Ack! "Did I accidentally hit x in the middle of that name in VIM? Better run it through the converter to make sure." Yay yet another level of complexity in DNS management. Some of the names look as ugly as the contents of DNSSEC RRs. :-) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvluX8ACgkQ2fXFxl4S7sTghwCg8sh1ZrKpa3d/GlYaGYhAZKN+ /HEAmgPrKZaaHynHRQuTAYfe4xQAWIh1 =cO/L -----END PGP SIGNATURE----- From jmamodio at gmail.com Sat May 8 21:14:53 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sat, 8 May 2010 21:14:53 -0500 Subject: Internationalized domain names in the root In-Reply-To: <4BE5B0E6.8010805@cox.net> References: <4BE55916.4030408@tonal.clara.co.uk> <20100508123622.GA2552@macbook.catpipe.net> <4BE5B0E6.8010805@cox.net> Message-ID: > Wait until the FCC, FTC, and IRS finish taking over the Internet. You forgot FBI, NSA and CIA, just to mention a few more three letter agencies ... k'mon gimme a break. Cheers From naveen at lastninja.net Sun May 9 06:23:45 2010 From: naveen at lastninja.net (Naveen Nathan) Date: Sun, 9 May 2010 04:23:45 -0700 Subject: Books for the NOC guys... In-Reply-To: <20100427031107.GG25706@skywalker.creative.net.au> References: <86wrwqukcm.fsf@seastrom.com> <20100403105237.GC31245@skywalker.creative.net.au> <20100427031107.GG25706@skywalker.creative.net.au> Message-ID: <20100509112344.GA3411@armakuni.lastninja.net> I was unable to register an acconut & edit the page. I would recommend including the O'reilly BGP book by Iljitsch van Beijnum. Under online stuff: The TCP/IP guide, which is surprisingly thorough: http://www.tcpipguide.com/ On Tue, Apr 27, 2010 at 11:11:07AM +0800, Adrian Chadd wrote: > On Mon, Apr 26, 2010, Joly MacFie wrote: > > I also grabbed the list http://isoc-ny.org/wiki/Networking > > > > Thanks to all who contributed. > > Please feel free to add a link to the above url in the nanog wiki. > > > > j > > > > > > On Sat, Apr 3, 2010 at 6:52 AM, Adrian Chadd wrote: > > > > > On Fri, Apr 02, 2010, Robert E. Seastrom wrote: > > > > > > > So, what are you having your up-and-coming NOC staff read? > > > > > > Since I thought this was worthwhile summarising, I've dumped > > > it on the mail topics page in the Wiki: > > > > > > http://nanog.cluepon.net/index.php/MailTopics > > > > > > I specifically left out the programming language related ranting. > > > > > > > > > Adrian > > > > > > > > > > > > -- > > --------------------------------------------------------------- > > Joly MacFie 218 565 9365 Skype:punkcast > > WWWhatsup NYC - http://wwwhatsup.com > > http://pinstand.com - http://punkcast.com > > Secretary - ISOC-NY - http://isoc-ny.org > > --------------------------------------------------------------- > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - > - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - > > -- Naveen Nathan To understand the human mind, understand self-deception. - Anon From smb at cs.columbia.edu Sun May 9 08:32:57 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 9 May 2010 09:32:57 -0400 Subject: BGP (in)security makes the AP wire Message-ID: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... --Steve Bellovin, http://www.cs.columbia.edu/~smb From ge at linuxbox.org Sun May 9 08:49:17 2010 From: ge at linuxbox.org (Gadi Evron) Date: Sun, 09 May 2010 16:49:17 +0300 Subject: Books for the NOC guys... In-Reply-To: <20100403105237.GC31245@skywalker.creative.net.au> References: <86wrwqukcm.fsf@seastrom.com> <20100403105237.GC31245@skywalker.creative.net.au> Message-ID: <4BE6BD5D.7070006@linuxbox.org> On 4/3/10 1:52 PM, Adrian Chadd wrote: > On Fri, Apr 02, 2010, Robert E. Seastrom wrote: > >> So, what are you having your up-and-coming NOC staff read? > > Since I thought this was worthwhile summarising, I've dumped > it on the mail topics page in the Wiki: > > http://nanog.cluepon.net/index.php/MailTopics > > I specifically left out the programming language related ranting. Can we create some instant web-poll to rank these books? I am sure many people would participate. There are several free services online, or I can volunteer a wordpress installation with the relevant plugin. Thanks, Gadi. From LarrySheldon at cox.net Sun May 9 10:54:46 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 May 2010 10:54:46 -0500 Subject: BGP (in)security makes the AP wire In-Reply-To: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> Message-ID: <4BE6DAC6.8080204@cox.net> On 5/9/2010 08:32, Steven Bellovin wrote: > http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html > > It's a pretty reasonable article, too, though I don't know that I > agree about the "simplicity of the routing system".... I worry about the implications in the article in the environment of recent news.... IRS (or FTC, or FCC) maintains a hosts.txt that everybody uses instead of BGP? I wonder how telephone calls are routed? (I know how they were in the 60's and 70's--I really don't know how the current system works. And when I drive someplace, I do indeed go by the signs I see, which are not erected by a central authority, as I move along. (I don't have a route from here to Fairbanks, Alaska, but my MCA shows one from here to Council Bluffs, Iowa, and from there there are several I might use, depending on what signs I see ("Warning, I29 N closed at Mondamin due to flooding") when I get there.) I'm sorry, but I am very afraid of "Central Authority". -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From eugen at leitl.org Sun May 9 11:30:47 2010 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 9 May 2010 18:30:47 +0200 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE6DAC6.8080204@cox.net> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> Message-ID: <20100509163047.GN1964@leitl.org> On Sun, May 09, 2010 at 10:54:46AM -0500, Larry Sheldon wrote: > And when I drive someplace, I do indeed go by the signs I see, which are > not erected by a central authority, as I move along. (I don't have a > route from here to Fairbanks, Alaska, but my MCA shows one from here to > Council Bluffs, Iowa, and from there there are several I might use, > depending on what signs I see ("Warning, I29 N closed at Mondamin due to > flooding") when I get there.) Speaking about that, is anyone currently seeing geographic (local-knowledge) routing and authorityless address (=position) allocation from coordinates (e.g. WGS 84 position fixes) in any realistic time frame as a major component on the Internet? Presumably, one could prototype something simple and cheap at L2 level with WGS 84->MAC (about ~m^2 resolution), custom switch firmware and GBIC for longish (1-70 km) distances, but without a mesh it won't work. > I'm sorry, but I am very afraid of "Central Authority". -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From joelja at bogus.com Sun May 9 11:38:18 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 09 May 2010 09:38:18 -0700 Subject: BGP (in)security makes the AP wire In-Reply-To: <20100509163047.GN1964@leitl.org> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> Message-ID: <4BE6E4FA.6000308@bogus.com> On 05/09/2010 09:30 AM, Eugen Leitl wrote: > On Sun, May 09, 2010 at 10:54:46AM -0500, Larry Sheldon wrote: > >> And when I drive someplace, I do indeed go by the signs I see, which are >> not erected by a central authority, as I move along. (I don't have a >> route from here to Fairbanks, Alaska, but my MCA shows one from here to >> Council Bluffs, Iowa, and from there there are several I might use, >> depending on what signs I see ("Warning, I29 N closed at Mondamin due to >> flooding") when I get there.) > > Speaking about that, is anyone currently seeing geographic (local-knowledge) > routing and authorityless address (=position) allocation from coordinates > (e.g. WGS 84 position fixes) in any realistic time frame as a major component > on the Internet? geographic location doesn't map to topology > Presumably, one could prototype something simple and cheap at L2 level > with WGS 84->MAC (about ~m^2 resolution), custom switch firmware and GBIC > for longish (1-70 km) distances, but without a mesh it won't work. > >> I'm sorry, but I am very afraid of "Central Authority". > From smb at cs.columbia.edu Sun May 9 11:47:53 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sun, 9 May 2010 12:47:53 -0400 Subject: BGP (in)security makes the AP wire In-Reply-To: <20100509163047.GN1964@leitl.org> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> Message-ID: <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> On May 9, 2010, at 12:30 47PM, Eugen Leitl wrote: > On Sun, May 09, 2010 at 10:54:46AM -0500, Larry Sheldon wrote: > >> And when I drive someplace, I do indeed go by the signs I see, which are >> not erected by a central authority, as I move along. (I don't have a >> route from here to Fairbanks, Alaska, but my MCA shows one from here to >> Council Bluffs, Iowa, and from there there are several I might use, >> depending on what signs I see ("Warning, I29 N closed at Mondamin due to >> flooding") when I get there.) > > Speaking about that, is anyone currently seeing geographic (local-knowledge) > routing and authorityless address (=position) allocation from coordinates > (e.g. WGS 84 position fixes) in any realistic time frame as a major component > on the Internet? > > Presumably, one could prototype something simple and cheap at L2 level > with WGS 84->MAC (about ~m^2 resolution), custom switch firmware and GBIC > for longish (1-70 km) distances, but without a mesh it won't work. It was discussed during the IPng days. My view at the time -- and my view today -- is that there's an inherent conflict between that and multiple competitive ISPs. Suppose there's an IP address corresponding to 40.75013351 west longitude, 73.99700928 north latitude (my building, according to Google maps). To which ISP should it be handed for delivery? Must all ISPs in a given area peer with each other? --Steve Bellovin, http://www.cs.columbia.edu/~smb From eugen at leitl.org Sun May 9 12:05:05 2010 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 9 May 2010 19:05:05 +0200 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE6E4FA.6000308@bogus.com> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <4BE6E4FA.6000308@bogus.com> Message-ID: <20100509170505.GO1964@leitl.org> On Sun, May 09, 2010 at 09:38:18AM -0700, Joel Jaeggli wrote: > geographic location doesn't map to topology In orbital line of sight (LoS) constellations and wireless meshes, yes. Arguably there's a cost function over fiber laid as well, e.g. long-distance fiber runs typically follow a geodesic. Of course over short distances relativistic ping isn't a necessarily good metric for distance. However, when deploying a geographically routed network with address assignment/refinement from mutual relativistic ping triangulation there would be incentive that topology follows geography. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From eugen at leitl.org Sun May 9 12:17:30 2010 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 9 May 2010 19:17:30 +0200 Subject: BGP (in)security makes the AP wire In-Reply-To: <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> Message-ID: <20100509171730.GP1964@leitl.org> On Sun, May 09, 2010 at 12:47:53PM -0400, Steven Bellovin wrote: > It was discussed during the IPng days. I realize the scheme is old, I myself reinvented it around 1990. I guess give that the idea hasn't gone very far since kind answers my own question. > My view at the time -- and my view today -- is that there's > an inherent conflict between that and multiple competitive ISPs. It'd be a standard. Surely people were thinking that before TCP/IP suite became dominant speaking a particular protocol was a competitive advantage against a competitor. > Suppose there's an IP address corresponding to 40.75013351 west > longitude, 73.99700928 north latitude (my building, according > to Google maps). To which ISP should it be handed for delivery? > Must all ISPs in a given area peer with each other? Let's say I buy a mesh radio which speaks the protocol. Who's the ISP? By putting it up on a pole or a roof I've become a transit point for traffic which potentially originated far away. I could use QoS to prioritize traffic by distance, so that far away traffic doesn't expire. In larger networks, you could tag packets with your ISP's tag, until it is being delivered to a "closest" point (of course geographic distance is not a single metric) of exchange. That way you could guarantee traffic doesn't exit your network unless it hasn't got any choice. Of course you could tunnel anything you want over a geographic link. Any LoS laser satellite constellation would presumably do that. -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE From LarrySheldon at cox.net Sun May 9 12:50:56 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 May 2010 12:50:56 -0500 Subject: BGP (in)security makes the AP wire In-Reply-To: <20100509171730.GP1964@leitl.org> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> <20100509171730.GP1964@leitl.org> Message-ID: <4BE6F600.1030500@cox.net> [The wonderful New And Improved Thunderbird deleted a response and the message I was responding to--I don't know how or why--seems to have to do with the arrival of new messages.] The message I was responding-to seemed to be a rant that the reason Area Code changes are (were) a hassle was due to the reluctance of the Evil Powers to permit overlays and portable numbers. I was saying that the Evil Powers thing is always a lot of fun, but the facts are that until fairly recent times, that is the way the technology worked. (As a point of interest--overlays have indeed been around since the 1960's.) When you dialed a number, a class 5 office received the digits dialed and decided what to do with the call. If the number dialed was one it served, it connected the call. If not it would (using engineering decisions encoded in the machine[1]) hand the call off to a higher class office, maybe all the way up to a class 1 which might hand it off to another class 1 and thence back down the hierarchy to the class 5 that served the number. There just was no way to keep track, second by second, to keep track of where a given number had wandered off to. No Evil Powers (not Bush, not Halliburton, not Cheney, not Tea Partiers, not ....). It was just the way things worked--and it was a pretty elegant design, all things considered. [1] Things that accounted for traffic patterns in a particular machine. For example, an office worked in had a class 5 machine in the 214 Area Code) which had an office that served 805-area numbers so they did go anywhere. It had high usage to 714 numbers so there were trunk right straight to the right class 5 office. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Sun May 9 12:54:32 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 09 May 2010 12:54:32 -0500 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE6F600.1030500@cox.net> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> <20100509171730.GP1964@leitl.org> <4BE6F600.1030500@cox.net> Message-ID: <4BE6F6D8.4010605@cox.net> On 5/9/2010 12:50, Larry Sheldon wrote: > [The wonderful New And Improved Thunderbird deleted a response and the > message I was responding to--I don't know how or why--seems to have to > do with the arrival of new messages.] > > The message I was responding-to seemed to be a rant that the reason Area > Code changes are (were) a hassle was due to the reluctance of the Evil > Powers to permit overlays and portable numbers. Well, egg-on-face time. Thunderbird has a loss-of-focus issue and the message I was working on was in a news group--not here. Sorry. I'll just grab my coat ..... From tglassey at earthlink.net Sun May 9 13:06:15 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 09 May 2010 11:06:15 -0700 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE6F6D8.4010605@cox.net> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE6DAC6.8080204@cox.net> <20100509163047.GN1964@leitl.org> <6417CF8C-CDAF-490E-930A-EE01FF65FCB1@cs.columbia.edu> <20100509171730.GP1964@leitl.org> <4BE6F600.1030500@cox.net> <4BE6F6D8.4010605@cox.net> Message-ID: <4BE6F997.6020001@earthlink.net> On 5/9/2010 10:54 AM, Larry Sheldon wrote: > On 5/9/2010 12:50, Larry Sheldon wrote: >> [The wonderful New And Improved Thunderbird deleted a response and the >> message I was responding to--I don't know how or why--seems to have to >> do with the arrival of new messages.] >> >> The message I was responding-to seemed to be a rant that the reason Area >> Code changes are (were) a hassle was due to the reluctance of the Evil >> Powers to permit overlays and portable numbers. > > Well, egg-on-face time. > > Thunderbird has a loss-of-focus issue and the message I was working on > was in a news group--not here. > > Sorry. > > I'll just grab my coat ..... as another victim of TBv3. Todd > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From john_brzozowski at cable.comcast.com Sun May 9 13:52:39 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Sun, 09 May 2010 14:52:39 -0400 Subject: IMPORTANT - Comcast IPv6 Trials Message-ID: Folks, Wanted to send a short note out about some email that you have seen recently regarding Comcast's IPv6 trials. When you visit http://trial.comcast.net please be sure that you visit the following link "Completed Introduction Survey?" at the bottom right hand side of the IPv6 trial page. This survey is very important, we need the information you supply to properly plan various aspects of our trials. Also, when entering in your information in the "Completed Introduction Survey?" please try to enter only the information requested. For example for your phone number please just enter your phone number and be sure to supply the one that is associated with your Comcast account. Also, when supplying your cable modem MAC address please only enter the MAC address of the cable modem. I also see there has been a fair amount of activity in the forum area of our trial portal. I will try to post some additional information there soon in response to some questions. Thanks again and please let me know if you have any questions. John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From andy at nosignal.org Sun May 9 15:51:33 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 9 May 2010 21:51:33 +0100 Subject: Surcharge for providing Internet routes? In-Reply-To: <4BDC9281.50509@kenweb.org> References: <4BDC9281.50509@kenweb.org> Message-ID: On 1 May 2010, at 21:43, ML wrote: > Has anyone here heard of or do they themselves charge extra for > providing a complete internet table to customers? > > Waive the surcharge for sufficiently large commits? Compared with some kind of reduced/waived fee for partial, or default only, or static routes ? I have seen some of my customers get charged a set up fee (NRC) for bgp (beyond the port fee). Normally an indication to me that we're going to have problems with this supplier.... And I have never seen this as an MRC, but I guess it could happen. Run a mile if so. Andy From franck at genius.com Sun May 9 22:39:30 2010 From: franck at genius.com (Franck Martin) Date: Sun, 9 May 2010 20:39:30 -0700 (PDT) Subject: Securing the BGP or controlling it? Message-ID: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> http://skunkpost.com/news.sp?newsId=2327 From scott at doc.net.au Sun May 9 23:17:00 2010 From: scott at doc.net.au (Scott Howard) Date: Sun, 9 May 2010 21:17:00 -0700 Subject: Securing the BGP or controlling it? In-Reply-To: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Made it to Slashdot too - http://tech.slashdot.org/story/10/05/10/0056228/The-Status-of-Routing-Reform-mdash-How-Fragile-is-the-Internet As usual I wouldn't recommend reading the comments unless you want your eyes to bleed... Scott. On Sun, May 9, 2010 at 8:39 PM, Franck Martin wrote: > http://skunkpost.com/news.sp?newsId=2327 > From randy at psg.com Mon May 10 01:37:29 2010 From: randy at psg.com (Randy Bush) Date: Mon, 10 May 2010 08:37:29 +0200 Subject: BGP (in)security makes the AP wire In-Reply-To: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> Message-ID: > http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html embarrassing but pretty much correct. a reporter did their homework. if i knew who it was, i would add them to my very small "willing to talk to" list. > It's a pretty reasonable article, too, though I don't know that I > agree about the "simplicity of the routing system".... "The fact that very good computer scientists are studying the internet as a behavioral phenomonon should scare the hell out of us." -- me, some years ago randy From randy at psg.com Mon May 10 01:40:58 2010 From: randy at psg.com (Randy Bush) Date: Mon, 10 May 2010 08:40:58 +0200 Subject: Securing the BGP or controlling it? In-Reply-To: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > http://skunkpost.com/news.sp?newsId=2327 same article as the one bellovin linked yesterday. but this version has author attribution. thanks. randy From tme at americafree.tv Mon May 10 01:43:51 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 10 May 2010 02:43:51 -0400 Subject: BGP (in)security makes the AP wire In-Reply-To: References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> Message-ID: <6DB20D6F-8B45-4A59-89D0-C3315363639F@americafree.tv> On May 10, 2010, at 2:37 AM, Randy Bush wrote: >> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html > > embarrassing but pretty much correct. a reporter did their homework. > if i knew who it was, i would add them to my very small "willing to > talk > to" list. Peter Svensson, AP Technology Writer http://twitter.com/petersvensson Regards Marshall > >> It's a pretty reasonable article, too, though I don't know that I >> agree about the "simplicity of the routing system".... > > "The fact that very good computer scientists are studying the internet > as a behavioral phenomonon should scare the hell out of us." > -- me, some years ago > > randy > > From LarrySheldon at cox.net Mon May 10 10:26:43 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 10 May 2010 10:26:43 -0500 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BE825B3.4040501@cox.net> On 5/9/2010 23:17, Scott Howard wrote: > Made it to Slashdot too - > http://tech.slashdot.org/story/10/05/10/0056228/The-Status-of-Routing-Reform-mdash-How-Fragile-is-the-Internet > > As usual I wouldn't recommend reading the comments unless you want your eyes > to bleed... I go back a step or two--I try very hard not to read AP. Which pretty much takes me out of reading anything but the comics in the "news"papers. And a lot of the comics have become so politicized that I don't read many of them any more. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From morrowc.lists at gmail.com Mon May 10 10:29:20 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 May 2010 11:29:20 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Mon, May 10, 2010 at 2:40 AM, Randy Bush wrote: >> http://skunkpost.com/news.sp?newsId=2327 > > same article as the one bellovin linked yesterday. ?but this version has > author attribution. ?thanks. a couple choice quotes: "Spokesmen at AT&T Inc. and Verizon Communications Inc., two of the largest, world-spanning carriers of Internet traffic, said they were unable to find anyone at their companies who could discuss the issue of routing reform." guess they didn't find rexford's successor @7018 or schiller @701? oh, well actually these folks don't do telephone networking so I guess it makes perfect sense :( "Pieter Poll, the chief technology officer at Qwest Communications International Inc., says that he would support some simple mechanisms to validate data routes, but he argues that fundamental reform isn't necessary. Hijackings are typically corrected quickly enough that they don't pose a major threat, he argues." qwest customers may want to take note here..."quickly enough" is how much of your business lost exactly? -chris :( From jbates at brightok.net Mon May 10 10:30:09 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 10 May 2010 10:30:09 -0500 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BE82681.3000100@brightok.net> Christopher Morrow wrote: > "Pieter Poll, the chief technology officer at Qwest Communications > International Inc., says that he would support some simple mechanisms > to validate data routes, but he argues that fundamental reform isn't > necessary. Hijackings are typically corrected quickly enough that they > don't pose a major threat, he argues." > > qwest customers may want to take note here..."quickly enough" is how > much of your business lost exactly? > They filter my routes. Not sure what he's talking about. Jack From morrowc.lists at gmail.com Mon May 10 10:37:31 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 10 May 2010 11:37:31 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE82681.3000100@brightok.net> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82681.3000100@brightok.net> Message-ID: On Mon, May 10, 2010 at 11:30 AM, Jack Bates wrote: > > They filter my routes. Not sure what he's talking about. just guessing but they probably don't filter 'peer' (SFP) routes, so if say 2914 accepted a route from their customer ConEdison that included a subnet of yours... boom goes your reachability :( From nick at foobar.org Mon May 10 10:52:12 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 May 2010 16:52:12 +0100 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4BE82BAC.2010509@foobar.org> On 10/05/2010 16:29, Christopher Morrow wrote: > qwest customers may want to take note here..."quickly enough" is how > much of your business lost exactly? this is a matter of risk analysis. No secure routing means we'll continue to see the occasional high profile outage which is dealt with very quickly. Secure routing is going to introduce significant complexities into the inter-domain routing system. Complexities lead to greater pilot error, and pilot error leads to outages. So while we may have fixed the 2 hour youtube externally derived problem which we get once every couple of years, it's probably going to come at the cost of having N hours worth of outages per year per ASN, because someone's mucked up their configuration, or has let their cert expire, or whatever. My gut instinct tells me that secure routing and the rpki venture well into the realm of negative returns. But I would be really interested to see some proper risk analysis in this area done by someone with clue. Nick From aaron.glenn at gmail.com Mon May 10 11:00:40 2010 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Mon, 10 May 2010 16:00:40 +0000 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE82BAC.2010509@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: On Mon, May 10, 2010 at 3:52 PM, Nick Hilliard wrote: > > My gut instinct tells me that secure routing and the rpki venture well into > the realm of negative returns. ?But I would be really interested to see > some proper risk analysis in this area done by someone with clue. my gut says things would do well to begin with simply making an effort at maintaining usable irr data and automagically generating sane filters. why don't people do that again? I hope I'm not naively misunderstanding a primary use of irr data in front of 10,000 of my closest friends... From JBonner at enventis.com Mon May 10 11:28:42 2010 From: JBonner at enventis.com (Jerry Bonner) Date: Mon, 10 May 2010 11:28:42 -0500 Subject: Dial Concentrators - TNT / APX8000 R.I.P. Message-ID: I'm told by our Alcatel rep that the APX 8000 is no longer supported and that we can no longer get hardware support because they "don't have any spare parts". I share a certain amount of love for this platform dating back to Ascend, but what am I to do now? Obviously no one is making large investments in their dial platform, but are there any other viable alternatives out there that are actually supported? ~jerry From franck at genius.com Mon May 10 11:47:57 2010 From: franck at genius.com (Franck Martin) Date: Mon, 10 May 2010 09:47:57 -0700 (PDT) Subject: Securing the BGP or controlling it? In-Reply-To: Message-ID: <8805496.719.1273510074525.JavaMail.franck@franck-martins-macbook-pro.local> APNIC allows you to put your BGP data in the whois, so like this you have a third party verification tool on who is peering with who. From nick at foobar.org Mon May 10 11:48:43 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 May 2010 17:48:43 +0100 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: <4BE838EB.3000000@foobar.org> On 10/05/2010 17:00, Aaron Glenn wrote: > my gut says things would do well to begin with simply making an effort > at maintaining usable irr data and automagically generating sane > filters. why don't people do that again? I hope I'm not naively > misunderstanding a primary use of irr data in front of 10,000 of my > closest friends... There are a lot of problems associated with using IRRDB filters for inbound prefix filtering. - some clients announce lots of prefixes. This can make inbound prefix filtering difficult in some situations. pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l 967 - there are some endemic data reliability problems with the IRRDBs, exacerbated by the fact that on most of the widely-used IRRDBs, there is no link between the RIR and the IRRDB, which means that anyone can register any address space. whois.ripe.net doesn't allow this, but lots of other IRRDBs do. - the ripe whois server software does not support server-side as-set expansion. This is a really serious problem if you're expanding large ASNs. - there is very little client software. At least irrtoolset compiles these days, but its front-end is very primitive. rpsltool provides some really nice templating functionality, but doesn't implement large sections of the rpsl standards. Nick From scott at sberkman.net Mon May 10 11:50:59 2010 From: scott at sberkman.net (Scott Berkman) Date: Mon, 10 May 2010 12:50:59 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: <017201caf060$f7e4bcd0$e7ae3670$@net> I think the only one under support may be the Cisco AS series (AS5800 only now?): http://www.cisco.com/en/US/products/hw/univgate/ps509/ The other platform I knew besides the TNT was the Nortel CVX but it is EOL also. -Scott -----Original Message----- From: Jerry Bonner [mailto:JBonner at enventis.com] Sent: Monday, May 10, 2010 12:29 PM To: nanog at nanog.org Subject: Dial Concentrators - TNT / APX8000 R.I.P. I'm told by our Alcatel rep that the APX 8000 is no longer supported and that we can no longer get hardware support because they "don't have any spare parts". I share a certain amount of love for this platform dating back to Ascend, but what am I to do now? Obviously no one is making large investments in their dial platform, but are there any other viable alternatives out there that are actually supported? ~jerry From tmagill at providecommerce.com Mon May 10 11:54:04 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Mon, 10 May 2010 09:54:04 -0700 Subject: Securing the BGP or controlling it? In-Reply-To: <8805496.719.1273510074525.JavaMail.franck@franck-martins-macbook-pro.local> References: <8805496.719.1273510074525.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: All of the major providers I have worked with have required proof of 'ownership' of address space or an LoA from the registered holder of that space before they would allow advertisements from me, which are then filtered. Is this not the norm? I can understand if they are talking about an operator making a mistake, but the article seems to imply that anyone running BGP can bring down the Internet... I think any competent provider can easily eliminate this threat from customers. Are there any types of penalties if an ISP is found to not be taking adequate precautions, other than the possible threat of losing business? -----Original Message----- From: Franck Martin [mailto:franck at genius.com] Sent: Monday, May 10, 2010 9:48 AM To: nanog at nanog.org Subject: Re: Securing the BGP or controlling it? APNIC allows you to put your BGP data in the whois, so like this you have a third party verification tool on who is peering with who. From jared at puck.nether.net Mon May 10 11:58:45 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 10 May 2010 12:58:45 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE838EB.3000000@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE838EB.3000000@foobar.org> Message-ID: On May 10, 2010, at 12:48 PM, Nick Hilliard wrote: > On 10/05/2010 17:00, Aaron Glenn wrote: >> my gut says things would do well to begin with simply making an effort >> at maintaining usable irr data and automagically generating sane >> filters. why don't people do that again? I hope I'm not naively >> misunderstanding a primary use of irr data in front of 10,000 of my >> closest friends... > > There are a lot of problems associated with using IRRDB filters for inbound > prefix filtering. > > - some clients announce lots of prefixes. This can make inbound prefix > filtering difficult in some situations. > > pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l > 967 There are certainly issues around what a customer may have as their primary path and what they are backup for. These issues make for very long prefix-lists. > - there are some endemic data reliability problems with the IRRDBs, > exacerbated by the fact that on most of the widely-used IRRDBs, there is no > link between the RIR and the IRRDB, which means that anyone can register > any address space. whois.ripe.net doesn't allow this, but lots of other > IRRDBs do. Certainly this is a function that you can petition your local RIR to do, have you made a proposal to them? > - the ripe whois server software does not support server-side as-set > expansion. This is a really serious problem if you're expanding large ASNs. Have you asked them to include this? > - there is very little client software. At least irrtoolset compiles these > days, but its front-end is very primitive. rpsltool provides some really > nice templating functionality, but doesn't implement large sections of the > rpsl standards. I certainly agree the tools here are suboptimal, but is that the the reason to throw the baby out with the bathwater? We're faced with a challenge here, where I surely agree with Peters argument that things won't get better here in the next ~7 years. Who is going to be the provider that turns away business because their customer is unwilling to register their routes in a klunky-toolset? What improvements to the toolset should go back to the community to improve filtering? If there is no RIR <-> IRR link, will people be willing/able to get a certificate when RPKI becomes more readily available? Will you accept a network outage because your certificate expires (vs a warning, ala SSL certs expired)? There are many questions here that require engagement by community members to provide viable solutions. Challenges certainly arise when you have nation-state telecom operators/incumbents involved as well that are unaccustomed to being told they MUST do something they may be unwilling to. - Jared From lists at billfehring.com Mon May 10 12:03:32 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 10 May 2010 10:03:32 -0700 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <017201caf060$f7e4bcd0$e7ae3670$@net> References: <017201caf060$f7e4bcd0$e7ae3670$@net> Message-ID: I don't think that you can buy new support contracts for the AS5800 series anymore. http://www.cisco.com/en/US/prod/collateral/iad/ps509/ps512/end_of_life_notice_c51-463159.html -Bill On Mon, May 10, 2010 at 09:50, Scott Berkman wrote: > I think the only one under support may be the Cisco AS series (AS5800 only > now?): > > http://www.cisco.com/en/US/products/hw/univgate/ps509/ > > The other platform I knew besides the TNT was the Nortel CVX but it is EOL > also. > > -Scott > > -----Original Message----- > From: Jerry Bonner [mailto:JBonner at enventis.com] > Sent: Monday, May 10, 2010 12:29 PM > To: nanog at nanog.org > Subject: Dial Concentrators - TNT / APX8000 R.I.P. > > I'm told by our Alcatel rep that the APX 8000 is no longer supported and > that we can no longer get hardware support because they "don't have any > spare parts". > > I share a certain amount of love for this platform dating back to Ascend, > but what am I to do now? Obviously no one is making large investments in > their dial platform, but are there any other viable alternatives out there > that are actually supported? > > ~jerry > > > > From nick at foobar.org Mon May 10 12:23:54 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 10 May 2010 18:23:54 +0100 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE838EB.3000000@foobar.org> Message-ID: <4BE8412A.3040604@foobar.org> On 10/05/2010 17:58, Jared Mauch wrote: > On May 10, 2010, at 12:48 PM, Nick Hilliard wrote: >> - there are some endemic data reliability problems with the IRRDBs, >> exacerbated by the fact that on most of the widely-used IRRDBs, there is no >> link between the RIR and the IRRDB, which means that anyone can register >> any address space. whois.ripe.net doesn't allow this, but lots of other >> IRRDBs do. > > Certainly this is a function that you can petition your local RIR to do, > have you made a proposal to them? RIPE does this automatically. But I have no idea how this sort of thing would be implemented between an RIR like ARIN and an IRRDB like whois.radb.net. >> - the ripe whois server software does not support server-side as-set >> expansion. This is a really serious problem if you're expanding large ASNs. > > Have you asked them to include this? I've enquired informally and was left with the impression that it would be difficult; the RIPE DB code is troublesome, and there are line protocol differences between the ripe server and the merit server which would make parsing an interesting proposition. > I certainly agree the tools here are suboptimal, but is that the the > reason to throw the baby out with the bathwater? Not at all - I use prefix filtering in anger, and it works very well in its place. > Who is going to be the provider that turns away business because their > customer is unwilling to register their routes in a klunky-toolset? Lots. They'll certainly take on the business, but I know of several well-known names who provide service in Dublin and who won't accept your prefixes unless they are registered in an IRRDB. > What improvements to the toolset should go back to the community to > improve filtering? If you're offering to hack code, great - email me offline :-) Nick From streiner at cluebyfour.org Mon May 10 12:31:49 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 10 May 2010 13:31:49 -0400 (EDT) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: On Mon, 10 May 2010, Jerry Bonner wrote: > I'm told by our Alcatel rep that the APX 8000 is no longer supported > and that we can no longer get hardware support because they "don't have > any spare parts". > > I share a certain amount of love for this platform dating back to > Ascend, but what am I to do now? Obviously no one is making large > investments in their dial platform, but are there any other viable > alternatives out there that are actually supported? Vendors aren't releasing much new dial gear anymore because customers aren't buying it. Your best bet might be to check the secondary market for TNT/APX8000 parts. I have a small handful of AS5300s still floating around for that handful of users who can't (or won't) ditch dialup. Luckily that number is small enough that I can replace any failed parts with parts from other chassis, since the ones I have were EOL'd long ago. jms From zaid at zaidali.com Mon May 10 12:32:47 2010 From: zaid at zaidali.com (Zaid Ali) Date: Mon, 10 May 2010 10:32:47 -0700 Subject: Securing the BGP or controlling it? In-Reply-To: Message-ID: What we need (as operators) is to get better at ensuring that advertisements are coming from the valid owner of said address space. What we don't need is a separate governance model which I worry this article is trying to imply. I still use RADB but I hear not every peer/provider checks there anymore? This is hearsay so interested in other opinions. As far as the mistakes pointed out in this article one can be assured that these things are bound to happen. The youtube situation could have been prevented if the peer opening a filter (and responsible for announcing out) had reach to a system where the other peer's advertisement can be verified. I don't think leaning on competency is a good way to go about solving this problem, we need a system or model in place to ensure we have a trust and verification system. Zaid On 5/10/10 9:54 AM, "Thomas Magill" wrote: > All of the major providers I have worked with have required proof of > 'ownership' of address space or an LoA from the registered holder of that > space before they would allow advertisements from me, which are then filtered. > Is this not the norm? I can understand if they are talking about an operator > making a mistake, but the article seems to imply that anyone running BGP can > bring down the Internet... I think any competent provider can easily > eliminate this threat from customers. Are there any types of penalties if an > ISP is found to not be taking adequate precautions, other than the possible > threat of losing business? > > -----Original Message----- > From: Franck Martin [mailto:franck at genius.com] > Sent: Monday, May 10, 2010 9:48 AM > To: nanog at nanog.org > Subject: Re: Securing the BGP or controlling it? > > APNIC allows you to put your BGP data in the whois, so like this you have a > third party verification tool on who is peering with who. > From jabley at hopcount.ca Mon May 10 13:22:15 2010 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 10 May 2010 14:22:15 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE838EB.3000000@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE838EB.3000000@foobar.org> Message-ID: On 2010-05-10, at 12:48, Nick Hilliard wrote: > - there are some endemic data reliability problems with the IRRDBs, > exacerbated by the fact that on most of the widely-used IRRDBs, there is no > link between the RIR and the IRRDB, which means that anyone can register > any address space. whois.ripe.net doesn't allow this, but lots of other > IRRDBs do. The RIPE db doesn't allow that for routes corresponding to address space assigned by the RIPE NCC. For other routes, you can register whatever you want (so long as nobody else got there first). I'm not complaining about this (I routinely recommend that people use the RIPE db for their non-RIPE address space because as far as I can tell it's about the best-maintained option, and it avoids all kinds of headaches trying to peer in Europe and send routes whose addresses were assigned elsewhere) but in the global context the idea that *everything* in the RIPE db has been subject to strong correlation with assignment/allocation data is false. Joe inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space country: EU # Country is really world wide org: ORG-IANA1-RIPE admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED remarks: The country is really worldwide. remarks: This address space is assigned at various other places in remarks: the world and might therefore not be in the RIPE database. mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-RPSL-MNT source: RIPE # Filtered inet6num: 0::/0 netname: ROOT descr: Root inet6num object country: EU org: ORG-IANA1-RIPE admin-c: IANA1-RIPE tech-c: CREW-RIPE tech-c: OPS4-RIPE mnt-by: RIPE-NCC-HM-MNT mnt-lower: RIPE-NCC-HM-MNT mnt-routes: RIPE-NCC-RPSL-MNT status: ALLOCATED-BY-RIR remarks: This network in not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks. source: RIPE # Filtered mntner: RIPE-NCC-RPSL-MNT descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. admin-c: RD132-RIPE auth: MD5-PW $1$ScJSM7nN$Xw3aAduCRZx4QUEq8QjR5/ remarks: ******************************************************* remarks: * The password for this object is 'RPSL', without the * remarks: * quotes. Do NOT use this maintainer as 'mnt-by'. * remarks: ******************************************************* mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT source: RIPE # Filtered From randy at psg.com Mon May 10 14:20:22 2010 From: randy at psg.com (Randy Bush) Date: Mon, 10 May 2010 21:20:22 +0200 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE82BAC.2010509@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: > this is a matter of risk analysis. No secure routing means we'll > continue to see the occasional high profile outage which is dealt with > very quickly. how soon we forget 7007, 128/8, ... over a day each, and global, and very big netowrks. if something like those happen again, we are gonna be spending a lot of time explaining our selves to people who wear funny clothes, and telling them why it is not going to happen again if they let us keep our jobs. randy From hank at efes.iucc.ac.il Mon May 10 14:56:29 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 10 May 2010 22:56:29 +0300 (IDT) Subject: Securing the BGP or controlling it? In-Reply-To: References: <8805496.719.1273510074525.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Mon, 10 May 2010, Thomas Magill wrote: > All of the major providers I have worked with have required proof of > 'ownership' of address space or an LoA from the registered holder of > that space before they would allow advertisements from me, which are > then filtered. Is this not the norm? I can understand if they are > talking about an operator making a mistake, but the article seems to > imply that anyone running BGP can bring down the Internet... I think > any competent provider can easily eliminate this threat from customers. > Are there any types of penalties if an ISP is found to not be taking > adequate precautions, other than the possible threat of losing business? ROTFLMAO. Competent provider? Penalties? Threats? You made my day. -Hank From vbono at 2nplus1.com Mon May 10 15:02:03 2010 From: vbono at 2nplus1.com (Vincent J.. Bono) Date: Mon, 10 May 2010 16:02:03 -0400 (EDT) Subject: Securing the BGP or controlling it? In-Reply-To: <29756003.11111273521337490.JavaMail.root@mail.2nplus1.com> Message-ID: <1402799.11131273521723110.JavaMail.root@mail.2nplus1.com> > this is a matter of risk analysis. No secure routing means we'll continue > to see the occasional high profile outage which is dealt with very quickly. Speaking from painful experience all kinds of variable can ensure that even when a problem is identified quickly and action taken expeditiously outages can and do take much longer than "very quickly" to correct. Also, while (IMHO) the much higher level of private interconnects / peering links in use today vs. 1997 makes willful route hijacking more difficult, building better security directly into the protocol is certainly in order. A good parallel is the SS7 network that runs "routing" for traditional voice signaling: it's "secured" by using a completely separate, out of band TDM network (DS1s and DS0s) but its also an "in the clear" protocol and could be subject to willful vandalism. From tkapela at gmail.com Mon May 10 15:31:18 2010 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 10 May 2010 16:31:18 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> On May 9, 2010, at 11:39 PM, Franck Martin wrote: > http://skunkpost.com/news.sp?newsId=2327 "Just how fragile is the internet?" Rhetoric, much? Interestingly, the article misses interception and other non-outage potentials due to (sub) prefix hijacking. -Tk From LarrySheldon at cox.net Mon May 10 15:52:34 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 10 May 2010 15:52:34 -0500 Subject: Securing the BGP or controlling it? In-Reply-To: <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> Message-ID: <4BE87212.2090805@cox.net> On 5/10/2010 15:31, Anton Kapela wrote: > > On May 9, 2010, at 11:39 PM, Franck Martin wrote: > >> http://skunkpost.com/news.sp?newsId=2327 > > "Just how fragile is the internet?" > > Rhetoric, much? > > Interestingly, the article misses interception and other non-outage > potentials due to (sub) prefix hijacking. At the risk of seeming to be a conspiracy theorist, I am worried that with "Central Authority" we might not have "hijacking" but "rerouting for inspection and correction". -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jmamodio at gmail.com Mon May 10 16:23:20 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 10 May 2010 16:23:20 -0500 Subject: Securing the BGP or controlling it? In-Reply-To: <1402799.11131273521723110.JavaMail.root@mail.2nplus1.com> References: <29756003.11111273521337490.JavaMail.root@mail.2nplus1.com> <1402799.11131273521723110.JavaMail.root@mail.2nplus1.com> Message-ID: > Also, while (IMHO) the much higher level of private interconnects / peering links in use today vs. 1997 makes willful route hijacking more difficult, building better security directly into the protocol is certainly in order. ?A good parallel is the SS7 network that runs "routing" for traditional voice signaling: it's "secured" by using a completely separate, out of band TDM network (DS1s and DS0s) but its also an "in the clear" protocol and could be subject to willful vandalism. Diff with SS7, we can't send a VoIP msg with every packet saying "Your packet can not be delivered as routed, please restart your computer and try again", ohh yes we can ICMP :-) Cheers Jorge From jeroen at mompl.net Mon May 10 16:39:13 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 10 May 2010 14:39:13 -0700 Subject: BGP (in)security makes the AP wire In-Reply-To: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> Message-ID: <4BE87D01.7010107@mompl.net> Steven Bellovin wrote: > http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html > > It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... I am very skeptical whenever I see claims of this nature "If I do X I can bring down large global system Y in a matter of minutes/hours" where X involves something reasonably simple any single person with some skill could do. -- http://goldmark.org/jeff/stupid-disclaimers/ From tkapela at gmail.com Mon May 10 16:40:32 2010 From: tkapela at gmail.com (Anton Kapela) Date: Mon, 10 May 2010 17:40:32 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: <48DCB021-6439-494F-98B8-5D6ABC910CCD@gmail.com> On May 10, 2010, at 12:28 PM, Jerry Bonner wrote: > Obviously no one is making large investments in their dial platform, but are there any other viable alternatives out there that are actually supported? The current 'still works, has features, etc' box is as5400xm, and is terming most of a full ct3 per chassis. Any-Service Any-Port, t.37 on/off ramping, and v.34/v.92 works quite well, as do the nifty high-touch features (mppc, stac, mlppp-lfi, hqos, etc), thanks to the npe-g1-worth of CPU in the box. We use this for v.110/120 isdn and switched-56 (yes, it still exists) calls, tdm-tdm ISDN switching, and a few pstn OOB channels. -Tk From randy at psg.com Mon May 10 17:04:35 2010 From: randy at psg.com (Randy Bush) Date: Tue, 11 May 2010 00:04:35 +0200 Subject: Securing the BGP or controlling it? In-Reply-To: <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> Message-ID: > Interestingly, the article misses interception and other non-outage > potentials due to (sub) prefix hijacking. you seem to be entering the world of attacks. the AP article's point was fat fingers. randy From LarrySheldon at cox.net Mon May 10 17:20:50 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 10 May 2010 17:20:50 -0500 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> Message-ID: <4BE886C2.8040209@cox.net> On 5/10/2010 17:04, Randy Bush wrote: >> Interestingly, the article misses interception and other non-outage >> potentials due to (sub) prefix hijacking. > > you seem to be entering the world of attacks. the AP article's point > was fat fingers. Interesting. I took it as a set up of why we NEED a Central Authority. *shrug* -- We'll see I guess, but probably not in time. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From danny at tcb.net Mon May 10 17:26:39 2010 From: danny at tcb.net (Danny McPherson) Date: Mon, 10 May 2010 16:26:39 -0600 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE82BAC.2010509@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: On May 10, 2010, at 9:52 AM, Nick Hilliard wrote: > > this is a matter of risk analysis. No secure routing means we'll continue > to see the occasional high profile outage which is dealt with very quickly. If 3 weeks (e.g., the recent 'i root w/China incident) is "very quickly" then we're operating on different timescales. > My gut instinct tells me that secure routing and the rpki venture well into > the realm of negative returns. I believe 'sucks less' falls into the realm of positive, so here we disagree. -danny From danny at tcb.net Mon May 10 17:26:35 2010 From: danny at tcb.net (Danny McPherson) Date: Mon, 10 May 2010 16:26:35 -0600 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE838EB.3000000@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE838EB.3000000@foobar.org> Message-ID: On May 10, 2010, at 10:48 AM, Nick Hilliard wrote: > There are a lot of problems associated with using IRRDB filters for inbound > prefix filtering. We used them over 15 years ago near ubiquitously and stopped mostly because: 1) there was nothing akin to route refresh so you had to bounce best routes or reset sessions to trigger readvertisement after policy updates. This made unscheduled a pain and required some turning of the steam valves. 2) traditional ACLs were used for routing policy specification and weren't incrementally updatable, which was a huge pita. 3) IRRs were insecure to update, no one ever deletes anything from IRRs, and some folks even proxy register IRR objects based on BGP routing table entries. 4) customers complained they had to maintain them (ohh, wait, we told them if they wanted to be routed they had no choice) Regarding 1, we have route refresh and inherent soft-reconfig today. Regarding 2, pretty much all implementations support this today (although it will be a pita to maintain near exact prefix list and ACL entries for a customer down the road when used for both routing policies and ingress anti-spoofing). Regarding 3, RPKI should help here quite a bit, either used directly, or enabling IRR object population - the RIRs that run IRRs and other other folks are helping with secure update mechanisms as well. Regarding 4 - they didn't scream as loud about the policy as they did when things broke because of the absence of it, that I know firsthand. > - some clients announce lots of prefixes. This can make inbound prefix > filtering difficult in some situations. > > pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l > 967 Yes, this needs to be automated, clearly. > - there are some endemic data reliability problems with the IRRDBs, > exacerbated by the fact that on most of the widely-used IRRDBs, there is no > link between the RIR and the IRRDB, which means that anyone can register > any address space. whois.ripe.net doesn't allow this, but lots of other > IRRDBs do. See 3 above. > - the ripe whois server software does not support server-side as-set > expansion. This is a really serious problem if you're expanding large ASNs. Do it yourself for now and file a feature request.. > - there is very little client software. At least irrtoolset compiles these > days, but its front-end is very primitive. rpsltool provides some really > nice templating functionality, but doesn't implement large sections of the > rpsl standards. Agreed, we need to do work here. -danny From blakjak at blakjak.net Mon May 10 17:36:16 2010 From: blakjak at blakjak.net (Mark Foster) Date: Tue, 11 May 2010 10:36:16 +1200 (NZST) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: <017201caf060$f7e4bcd0$e7ae3670$@net> Message-ID: <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> Does this not highlight a wider issue? I realise that dialup is hardly 'cutting edge' but there are providers out there with a significant number of dialup customers still on the books. Surely there's still a market for (what should be by now) a straightforward, well known piece of kit? In parts of the world where broadband is not ubiquitous and dialup remains useful as a Plan-B or is simply the only choice (for whatever reason), what are the practical choices now? Whilst folks may not be fielding 'new' dialup kit, I dare say that we're going to be continuing to see dialup customers on the books for the next 5 years, perhaps a lot longer? That's a whole product lifespan... On Tue, May 11, 2010 5:03 am, Bill Fehring wrote: > I don't think that you can buy new support contracts for the AS5800 series > anymore. > > http://www.cisco.com/en/US/prod/collateral/iad/ps509/ps512/end_of_life_notice_c51-463159.html > > -Bill > > On Mon, May 10, 2010 at 09:50, Scott Berkman wrote: > >> I think the only one under support may be the Cisco AS series (AS5800 >> only >> now?): >> >> http://www.cisco.com/en/US/products/hw/univgate/ps509/ >> >> The other platform I knew besides the TNT was the Nortel CVX but it is >> EOL >> also. >> From danny at tcb.net Mon May 10 17:36:00 2010 From: danny at tcb.net (Danny McPherson) Date: Mon, 10 May 2010 16:36:00 -0600 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE87212.2090805@cox.net> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> <4BE87212.2090805@cox.net> Message-ID: <8F19BBBF-8C57-4413-88B3-FC4B8389D281@tcb.net> On May 10, 2010, at 2:52 PM, Larry Sheldon wrote: > At the risk of seeming to be a conspiracy theorist, I am worried that > with "Central Authority" we might not have "hijacking" but "rerouting > for inspection and correction". Building a database (i.e,. RPKI) aligned with the Internet number resource allocation hierarchy attesting to who's authorized to originate what route announcements and telling you how to configure your routers are two fundamentally different things. If that database doesn't exist it's tough to discriminate between legitimate and malicious or erroneous announcements - irrespective of how you discriminate. If it does exist, and you use it, anyone that can rub two packets together is surely going to employ preferences that first consider organizational and local objectives, then potentially national, and then some global inputs. This basically helps people to make more informed decisions, methinks. -danny From deleskie at gmail.com Mon May 10 17:32:51 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 10 May 2010 22:32:51 +0000 Subject: Securing the BGP or controlling it? Message-ID: <1179832502-1273531193-cardhu_decombobulator_blackberry.rim.net-1889679506-@bda005.bisx.prod.on.blackberry> I've worked for a couple of very large providers. I can't speak for what the do they do today but both where very serious about proper filtering. I only hope they both still do it. -jim ------Original Message------ From: Hank Nussbacher To: Thomas Magill Cc: nanog at nanog.org Subject: RE: Securing the BGP or controlling it? Sent: May 10, 2010 3:56 PM On Mon, 10 May 2010, Thomas Magill wrote: > All of the major providers I have worked with have required proof of > 'ownership' of address space or an LoA from the registered holder of > that space before they would allow advertisements from me, which are > then filtered. Is this not the norm? I can understand if they are > talking about an operator making a mistake, but the article seems to > imply that anyone running BGP can bring down the Internet... I think > any competent provider can easily eliminate this threat from customers. > Are there any types of penalties if an ISP is found to not be taking > adequate precautions, other than the possible threat of losing business? ROTFLMAO. Competent provider? Penalties? Threats? You made my day. -Hank Sent from my BlackBerry device on the Rogers Wireless Network From deleskie at gmail.com Mon May 10 17:35:23 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 10 May 2010 22:35:23 +0000 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE87212.2090805@cox.net> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local><547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com><4BE87212.2090805@cox.net> Message-ID: <1148739534-1273531200-cardhu_decombobulator_blackberry.rim.net-1508623456-@bda005.bisx.prod.on.blackberry> I don't suspect we'd need a central authority for that. I'm sure it only enough for you traffic to pass with anyones national boundry to be 'at risk' of such things -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Larry Sheldon Date: Mon, 10 May 2010 15:52:34 To: Subject: Re: Securing the BGP or controlling it? On 5/10/2010 15:31, Anton Kapela wrote: > > On May 9, 2010, at 11:39 PM, Franck Martin wrote: > >> http://skunkpost.com/news.sp?newsId=2327 > > "Just how fragile is the internet?" > > Rhetoric, much? > > Interestingly, the article misses interception and other non-outage > potentials due to (sub) prefix hijacking. At the risk of seeming to be a conspiracy theorist, I am worried that with "Central Authority" we might not have "hijacking" but "rerouting for inspection and correction". -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From deleskie at gmail.com Mon May 10 17:41:00 2010 From: deleskie at gmail.com (deleskie at gmail.com) Date: Mon, 10 May 2010 22:41:00 +0000 Subject: Securing the BGP or controlling it? In-Reply-To: References: Message-ID: <1529303264-1273531249-cardhu_decombobulator_blackberry.rim.net-25930507-@bda005.bisx.prod.on.blackberry> Ziad, I agree, its unfortunate that so many people no longer require route registration. Not that it would solve all the issues. Tom School, Todd Underwood and I present some work we did looking @ this @ nanog in LA a while back. Unfortunately we could never find time to take it to the next steps. -jim Sent from my BlackBerry device on the Rogers Wireless Network -----Original Message----- From: Zaid Ali Date: Mon, 10 May 2010 10:32:47 To: Thomas Magill; Franck Martin; Subject: Re: Securing the BGP or controlling it? What we need (as operators) is to get better at ensuring that advertisements are coming from the valid owner of said address space. What we don't need is a separate governance model which I worry this article is trying to imply. I still use RADB but I hear not every peer/provider checks there anymore? This is hearsay so interested in other opinions. As far as the mistakes pointed out in this article one can be assured that these things are bound to happen. The youtube situation could have been prevented if the peer opening a filter (and responsible for announcing out) had reach to a system where the other peer's advertisement can be verified. I don't think leaning on competency is a good way to go about solving this problem, we need a system or model in place to ensure we have a trust and verification system. Zaid On 5/10/10 9:54 AM, "Thomas Magill" wrote: > All of the major providers I have worked with have required proof of > 'ownership' of address space or an LoA from the registered holder of that > space before they would allow advertisements from me, which are then filtered. > Is this not the norm? I can understand if they are talking about an operator > making a mistake, but the article seems to imply that anyone running BGP can > bring down the Internet... I think any competent provider can easily > eliminate this threat from customers. Are there any types of penalties if an > ISP is found to not be taking adequate precautions, other than the possible > threat of losing business? > > -----Original Message----- > From: Franck Martin [mailto:franck at genius.com] > Sent: Monday, May 10, 2010 9:48 AM > To: nanog at nanog.org > Subject: Re: Securing the BGP or controlling it? > > APNIC allows you to put your BGP data in the whois, so like this you have a > third party verification tool on who is peering with who. > From danny at tcb.net Mon May 10 17:42:38 2010 From: danny at tcb.net (Danny McPherson) Date: Mon, 10 May 2010 16:42:38 -0600 Subject: Securing the BGP or controlling it? In-Reply-To: <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <547278A6-15D7-4CC0-A043-17E8288401B6@gmail.com> Message-ID: <697233F9-2F7E-48D1-B71F-78DFB2898D1C@tcb.net> On May 10, 2010, at 2:31 PM, Anton Kapela wrote: > Interestingly, the article misses interception and other non-outage potentials due to (sub) prefix hijacking. I think it captures it in such a way that my grandmother might be more likely to grok it. Regardless, those are just more symptoms of the same underlying problem, no? And the "i root" incident was plausibly a hybrid of error and intercept, so there's a nice hefty gray area there as well. I suspect no one missed that.. -danny From cmadams at hiwaay.net Mon May 10 19:29:09 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 10 May 2010 19:29:09 -0500 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: <20100511002909.GA1109404@hiwaay.net> Once upon a time, Justin M. Streiner said: > I have a small handful of AS5300s still floating around for that handful > of users who can't (or won't) ditch dialup. Luckily that number is small > enough that I can replace any failed parts with parts from other chassis, > since the ones I have were EOL'd long ago. I'm in the same boat with TNTs. We bought replacement fans years ago (about the only TNT part we've had fail, outside the odd card or two). How are ISPs that still offer dialup going to handle dialup and IPv6? I know the TNTs don't do it, and I don't think most of the old equipment in use in many places does. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pbosworth at gmail.com Mon May 10 19:43:11 2010 From: pbosworth at gmail.com (Paul Bosworth) Date: Mon, 10 May 2010 19:43:11 -0500 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE87D01.7010107@mompl.net> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE87D01.7010107@mompl.net> Message-ID: I'm right there with you. I'm pretty sure the Internet would have crashed and burned long ago from human error if this was the case. People typically unintentionally bungle things worse than when they mean to. On Mon, May 10, 2010 at 4:39 PM, Jeroen van Aart wrote: > Steven Bellovin wrote: > >> >> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html >> >> It's a pretty reasonable article, too, though I don't know that I agree >> about the "simplicity of the routing system".... >> > > I am very skeptical whenever I see claims of this nature "If I do X I can > bring down large global system Y in a matter of minutes/hours" where X > involves something reasonably simple any single person with some skill could > do. > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > > -- Paul H Bosworth GSEC, GCFW, GCIH CCNP, CCIP, CCDP From marka at isc.org Mon May 10 19:47:52 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 11 May 2010 10:47:52 +1000 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: Your message of "Mon, 10 May 2010 19:29:09 EST." <20100511002909.GA1109404@hiwaay.net> References: <20100511002909.GA1109404@hiwaay.net> Message-ID: <201005110047.o4B0lq3w029587@drugs.dv.isc.org> In message <20100511002909.GA1109404 at hiwaay.net>, Chris Adams writes: > How are ISPs that still offer dialup going to handle dialup and IPv6? I > know the TNTs don't do it, and I don't think most of the old equipment > in use in many places does. Just tunnel IPv6 over IPv4 and run a tunnel broker. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From streiner at cluebyfour.org Mon May 10 19:55:08 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 10 May 2010 20:55:08 -0400 (EDT) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <20100511002909.GA1109404@hiwaay.net> References: <20100511002909.GA1109404@hiwaay.net> Message-ID: On Mon, 10 May 2010, Chris Adams wrote: > Once upon a time, Justin M. Streiner said: >> I have a small handful of AS5300s still floating around for that handful >> of users who can't (or won't) ditch dialup. Luckily that number is small >> enough that I can replace any failed parts with parts from other chassis, >> since the ones I have were EOL'd long ago. > > I'm in the same boat with TNTs. We bought replacement fans years ago > (about the only TNT part we've had fail, outside the odd card or two). > > How are ISPs that still offer dialup going to handle dialup and IPv6? I > know the TNTs don't do it, and I don't think most of the old equipment > in use in many places does. My suspicion is that providers' dial gear might be included in the chunks of their networks that are considered 'not native v6 capable' as another way to try to 'goose' more people off of dialup and onto a broadband connection where v6 might be supported more easily. jms From tony at lava.net Mon May 10 22:02:09 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 10 May 2010 17:02:09 -1000 (HST) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <20100511002909.GA1109404@hiwaay.net> References: <20100511002909.GA1109404@hiwaay.net> Message-ID: On Mon, 10 May 2010, Chris Adams wrote: > How are ISPs that still offer dialup going to handle dialup and IPv6? I > know the TNTs don't do it, and I don't think most of the old equipment > in use in many places does. 6to4 Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From aj at sneep.net Mon May 10 22:22:27 2010 From: aj at sneep.net (Alastair Johnson) Date: Tue, 11 May 2010 11:22:27 +0800 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> References: <017201caf060$f7e4bcd0$e7ae3670$@net> <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> Message-ID: <4BE8CD73.3050705@sneep.net> Mark Foster wrote: > Does this not highlight a wider issue? > > I realise that dialup is hardly 'cutting edge' but there are providers out > there with a significant number of dialup customers still on the books. > Surely there's still a market for (what should be by now) a > straightforward, well known piece of kit? > > In parts of the world where broadband is not ubiquitous and dialup remains > useful as a Plan-B or is simply the only choice (for whatever reason), > what are the practical choices now? > > Whilst folks may not be fielding 'new' dialup kit, I dare say that we're > going to be continuing to see dialup customers on the books for the next 5 > years, perhaps a lot longer? That's a whole product lifespan... Welcome to what telcos have been dealing with for 10 to 20 years with product lifecycles. The PSTN isn't exactly a growing market, and has lots of EOL switches, yet it continues to run. Secondary support markets, grey markets, and strategic migrations to carry internal sparing. Or you find a cost effective way to replace it with something; or you accept that the revenue vs. cost-to-maintain is too high and just kill the product. aj p.s. UTStarcom was still supporting the [former USR/3com] TotalControl chassis as of about 2 years ago; I don't know if they still do. They were positioning it as a migration platform for legacy X.25 networks. From aj at sneep.net Mon May 10 22:26:36 2010 From: aj at sneep.net (Alastair Johnson) Date: Tue, 11 May 2010 11:26:36 +0800 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <20100511002909.GA1109404@hiwaay.net> References: <20100511002909.GA1109404@hiwaay.net> Message-ID: <4BE8CE6C.7060200@sneep.net> Chris Adams wrote: > > How are ISPs that still offer dialup going to handle dialup and IPv6? I > know the TNTs don't do it, and I don't think most of the old equipment > in use in many places does. Most likely the customers still on dialup are not going to worry about IPv6 - if their systems even support it. In fact several operators I have spoken to have considered their legacy dialup plant as a good place to test Carrier Grade NAT in a low impact manner. Couple it with some kind of ALG (transparent proxy + DNS tricks) for IPv6-only sites and you have something which might work. If you really need native IPv6 support for dialup then using a legacy NAS as a dial-terminator LAC and tunneling to an IPv6 capable LNS might be a solution for you. aj From marka at isc.org Mon May 10 23:13:18 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 11 May 2010 14:13:18 +1000 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: Your message of "Mon, 10 May 2010 17:02:09 -1000." References: <20100511002909.GA1109404@hiwaay.net> Message-ID: <201005110413.o4B4DIsN031537@drugs.dv.isc.org> In message , Antonio Querubin writes: > On Mon, 10 May 2010, Chris Adams wrote: > > > How are ISPs that still offer dialup going to handle dialup and IPv6? I > > know the TNTs don't do it, and I don't think most of the old equipment > > in use in many places does. > > 6to4 You don't want 6to4. Even if you provide relay routers the return traffic is problematic. 6to4 also requires public IPv4 addresses and you will eventually want to share these between your customers. > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > -- 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 Mon May 10 23:29:31 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 11 May 2010 14:29:31 +1000 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: Your message of "Tue, 11 May 2010 14:13:18 +1000." <201005110413.o4B4DIsN031537@drugs.dv.isc.org> References: <20100511002909.GA1109404@hiwaay.net> <201005110413.o4B4DIsN031537@drugs.dv.isc.org> Message-ID: <201005110429.o4B4TV47031707@drugs.dv.isc.org> In message <201005110413.o4B4DIsN031537 at drugs.dv.isc.org>, Mark Andrews writes: > > > How are ISPs that still offer dialup going to handle dialup and IPv6? I > > > know the TNTs don't do it, and I don't think most of the old equipment > > > in use in many places does. > > > > 6to4 > > You don't want 6to4. Even if you provide relay routers the return > traffic is problematic. 6to4 also requires public IPv4 addresses > and you will eventually want to share these between your customers. 6rd would also be appropriate for this if you don't want to run a tunnel broker. -- 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 Tue May 11 00:42:41 2010 From: randy at psg.com (Randy Bush) Date: Tue, 11 May 2010 07:42:41 +0200 Subject: BGP (in)security makes the AP wire In-Reply-To: <4BE87D01.7010107@mompl.net> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE87D01.7010107@mompl.net> Message-ID: >> http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html >> >> It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... > > I am very skeptical whenever I see claims of this nature "If I do X I > can bring down large global system Y in a matter of minutes/hours" where > X involves something reasonably simple any single person with some skill > could do. except we have a history of it happening From tony at lava.net Tue May 11 00:42:53 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 10 May 2010 19:42:53 -1000 (HST) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <201005110413.o4B4DIsN031537@drugs.dv.isc.org> References: <20100511002909.GA1109404@hiwaay.net> <201005110413.o4B4DIsN031537@drugs.dv.isc.org> Message-ID: On Tue, 11 May 2010, Mark Andrews wrote: >> 6to4 > > You don't want 6to4. Even if you provide relay routers the return > traffic is problematic. 6to4 also requires public IPv4 addresses > and you will eventually want to share these between your customers. Providing 6to4 for dialup users is an adequate level of effort. And we're mot running out of public IPv4 addresses anytime soon for the blossoming dialup business ;). Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From streiner at cluebyfour.org Tue May 11 01:37:53 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 11 May 2010 02:37:53 -0400 (EDT) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <4BE8CD73.3050705@sneep.net> References: <017201caf060$f7e4bcd0$e7ae3670$@net> <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> <4BE8CD73.3050705@sneep.net> Message-ID: On Tue, 11 May 2010, Alastair Johnson wrote: > Welcome to what telcos have been dealing with for 10 to 20 years with product > lifecycles. The PSTN isn't exactly a growing market, and has lots of EOL > switches, yet it continues to run. Secondary support markets, grey markets, > and strategic migrations to carry internal sparing. > > Or you find a cost effective way to replace it with something; or you accept > that the revenue vs. cost-to-maintain is too high and just kill the product. Some telcos are starting to kill off legacy services as they reach the end of their life cycle. I saw an application from Verizon in West Virginia to modify their tariff to remove SMDS as a service. According to the filing, no customers were using it and vendor support for it was coming to an end. I'm assuming at some point that Verizon stopped selling the service and quietly told any remaining customers that they needed to transition to other services because SMDS would be turned off on a certain date. I've heard of some LECs starting to mull dropping frame relay as a supported service as well... jms From kilobit at gmail.com Tue May 11 03:24:42 2010 From: kilobit at gmail.com (bas) Date: Tue, 11 May 2010 04:24:42 -0400 Subject: SFP+ ER and ZR Message-ID: Hi Guys, I thought ER and ZR SFP+ optics were not available (yet) due to power and cooling "challenges". However on this site: http://www.excelight.com/products/datalink/sfpplus.asp They offer both ER and ZR SFP+ optics. Has anyone used or tested with these? If so with which equipment? Or have you found other vendors of these optics? Thanks in advance, Bas From cmaurand at xyonet.com Tue May 11 07:42:08 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 11 May 2010 08:42:08 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> References: <017201caf060$f7e4bcd0$e7ae3670$@net> <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> Message-ID: <4BE950A0.9000407@xyonet.com> On 5/10/2010 6:36 PM, Mark Foster wrote: > Does this not highlight a wider issue? > > I realise that dialup is hardly 'cutting edge' but there are providers out > there with a significant number of dialup customers still on the books. > Surely there's still a market for (what should be by now) a > straightforward, well known piece of kit? > > In parts of the world where broadband is not ubiquitous and dialup remains > useful as a Plan-B or is simply the only choice (for whatever reason), > what are the practical choices now? > > Whilst folks may not be fielding 'new' dialup kit, I dare say that we're > going to be continuing to see dialup customers on the books for the next 5 > years, perhaps a lot longer? That's a whole product lifespan... > > How about an Aastra CVX shelf? We used one at an ISP I used to work for in Maine. It worked well. Dial-up was considered the cash cow then. --C From rens at autempspourmoi.be Tue May 11 08:21:19 2010 From: rens at autempspourmoi.be (Rens) Date: Tue, 11 May 2010 15:21:19 +0200 Subject: IPv4 Multicast Message-ID: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Hi all, I would like to setup a multicast server sending out some streams and having 10-50 receivers at one location across an existing IP backbone. Here is the setup: Receivers <=> Cisco 3560G <=> Cisco 7206VXR <=> IP BACKBONE (OSPF & BGP) <=> Cisco 7206VXR <=> Cisco 4503 <=> streaming server Does anyone have any configuration examples for this or tutorials, everything on the net seems way to complex for my needs. Regards, Rens From nick at foobar.org Tue May 11 08:32:19 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 11 May 2010 14:32:19 +0100 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: <4BE95C63.90901@foobar.org> On 10/05/2010 20:20, Randy Bush wrote: > if something like those happen again, we are gonna be spending a lot of > time explaining our selves to people who wear funny clothes, and telling > them why it is not going to happen again if they let us keep our jobs. Yes, I have observed that people who wear funny clothes with blood constriction devices wrapped tightly around their necks seem to be concerned primarily with ass covering theatre. Risk analysis is ass covering without the theatre. You collect data, make a judgement based on that data, and if it turns out that the judgement says that signed bgp updates constitute more of a stability risk to network operations than the occasional shock problem, then you point these people with odd dress sense towards the conclusions of this risk analysis report, having made sure that the conclusions are printed in a 48pt font, with no more than 2 syllables per word, preferably with a filled circle preceding each sentence. It may well be that they will ignore the risk analysis and be more concerned with the theatre than with data; this happens all the time, an excellent example being airport security, where security theatre seems to be considered much more important than actual security. Or it could go the other way, where risk analysis dictates that sensible precautions be taken, but they are thrown out for other reasons. A good example here is road safety, where it would be sensible to speed limit all cars to 50km/h, and ban motorbikes and bull-bars; but instead we substantially choose to ignore the risk and accept an attrition rate of 80,000 people every year between Europe and the US. Nick From mmaaddooog at yahoo.com Tue May 11 08:34:10 2010 From: mmaaddooog at yahoo.com (Mmaad Dooog) Date: Tue, 11 May 2010 06:34:10 -0700 (PDT) Subject: BGP (in)security makes the AP wire Message-ID: <704953.46371.qm@web114313.mail.gq1.yahoo.com> Is anyone going to jump on the irony of the last two paragraphs? Having to use the excessively rigid, slow, static, boring expensive PSTN to fix the cool, fast, flexible cheap, cool, fun Internet? That'll work just fine, of course. Until, that is, one of the telcos in the path saves a few bucks and routes a call leg over the Internet. What will us network operators do when there is NO out of band management path to anything? What will happen when you can't even place a phone call? The PSTN ran about 80 years or so on in-band signaling until a very rational cost/benefit decision was made to remove signaling from the traffic path. Physically seperating signaling (SS7) and routing (LERG, etc) paths from the traffic (for all but the access link) was a large, expensive, difficult effort, but worth it. The PSTN is full of quasi-governmental central authorities for everything, and is all the better for it. At some point, the best-effort, cooperative, come-as-you-are paradigm that let the Internet grow fast and far will probably be overtaken by the societal need for reliable, deterministic, assured performance. This thread has discussed only evolutionary, incremental improvements. Who are the revolutionaries among us? MD Steven Bellovin smb at cs.columbia.edu Sun May 9 13:32:57 UTC 2010 * Previous message: Books for the NOC guys... * Next message: BGP (in)security makes the AP wire * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ________________________________ http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... --Steve Bellovin, http://www.cs.columbia.edu/~smb From khomyakov.andrey at gmail.com Tue May 11 08:36:28 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Tue, 11 May 2010 09:36:28 -0400 Subject: Rugged wireless bridge Message-ID: Hi all, I need to provide IP connectivity to an outdoor parking lot for security devices like a camera, and emergency phone and a gate. Does anyone have any suggestions on a wireless bridge and an outdoor rated switch if such exists? How do people provide IP to outdoor locations like a surface parking lot? Thanks, Andrey -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From swmike at swm.pp.se Tue May 11 08:43:12 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 11 May 2010 15:43:12 +0200 (CEST) Subject: IPv4 Multicast In-Reply-To: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> References: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Message-ID: On Tue, 11 May 2010, Rens wrote: > Does anyone have any configuration examples for this or tutorials, > everything on the net seems way to complex for my needs. Multicast Quick-Start Configuration Guide -- Mikael Abrahamsson email: swmike at swm.pp.se From truman at suspicious.org Tue May 11 08:57:22 2010 From: truman at suspicious.org (Truman Boyes) Date: Tue, 11 May 2010 09:57:22 -0400 Subject: Rugged wireless bridge In-Reply-To: References: Message-ID: You can use a soekris embedded computer. (http://soekris.com/). You can put the boards into rugged cases like this: http://socalfreenet.org/node/267 Here is the case: http://www.yourbroadbandstore.com/product.php?pid=201838 Kind regards, Truman On 11/05/2010, at 9:36 AM, Andrey Khomyakov wrote: > Hi all, > > I need to provide IP connectivity to an outdoor parking lot for security > devices like a camera, and emergency phone and a gate. Does anyone have any > suggestions on a wireless bridge and an outdoor rated switch if such exists? > How do people provide IP to outdoor locations like a surface parking lot? > > Thanks, > Andrey > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > From r.engehausen at gmail.com Tue May 11 09:10:36 2010 From: r.engehausen at gmail.com (Roy) Date: Tue, 11 May 2010 07:10:36 -0700 Subject: Rugged wireless bridge In-Reply-To: References: Message-ID: <4BE9655C.1010104@gmail.com> Lots of good stuff here http://www.wlanparts.com/ I have had good luck with the Ez-Bridge Lite On 5/11/2010 6:36 AM, Andrey Khomyakov wrote: > Hi all, > > I need to provide IP connectivity to an outdoor parking lot for security > devices like a camera, and emergency phone and a gate. Does anyone have any > suggestions on a wireless bridge and an outdoor rated switch if such exists? > How do people provide IP to outdoor locations like a surface parking lot? > > Thanks, > Andrey > > From tglassey at earthlink.net Tue May 11 09:13:09 2010 From: tglassey at earthlink.net (todd glassey) Date: Tue, 11 May 2010 07:13:09 -0700 Subject: Rugged wireless bridge In-Reply-To: References: Message-ID: <4BE965F5.3030302@earthlink.net> On 5/11/2010 6:57 AM, Truman Boyes wrote: > You can use a soekris embedded computer. (http://soekris.com/). You can put the boards into rugged cases like this: > > http://socalfreenet.org/node/267 > > Here is the case: > > http://www.yourbroadbandstore.com/product.php?pid=201838 > > Kind regards, > Truman > > > On 11/05/2010, at 9:36 AM, Andrey Khomyakov wrote: > >> Hi all, >> >> I need to provide IP connectivity to an outdoor parking lot for security >> devices like a camera, and emergency phone and a gate. Does anyone have any >> suggestions on a wireless bridge and an outdoor rated switch if such exists? >> How do people provide IP to outdoor locations like a surface parking lot? If it is going into a FIPS compliant deployment or there is legal impact of this system I would suggest something like the FortressTech ES520 which is approved for military rollout in battlefield applications. These are NOT cheap but you get what you pay for in todays world hopefully. The case the 520 is packaged in is unlike any other WAP I have worked with and we used them quite a bit for wireless-time services. http://www.fortresstech.com/Products/SecWiBridges.aspx Todd Glassey >> >> Thanks, >> Andrey >> >> -- >> Andrey Khomyakov >> [khomyakov.andrey at gmail.com] >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: tglassey.vcf Type: text/x-vcard Size: 125 bytes Desc: not available URL: From danny at tcb.net Tue May 11 09:13:27 2010 From: danny at tcb.net (Danny McPherson) Date: Tue, 11 May 2010 08:13:27 -0600 Subject: Securing the BGP or controlling it? In-Reply-To: <4BE95C63.90901@foobar.org> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE95C63.90901@foobar.org> Message-ID: <11C6D32D-B9EB-4D83-B0C7-F50A9D54BCA1@tcb.net> On May 11, 2010, at 7:32 AM, Nick Hilliard wrote: > Risk analysis is ass covering without the theatre. You collect data, make > a judgement based on that data, and if it turns out that the judgement says > that signed bgp updates constitute more of a stability risk to network > operations than the occasional shock problem So apply the risk management analogy here. We all know that pretty much anyone can assert reachability for anyone else's address space inter-domain on the Internet, in particular the closer you get to 'the core' the easier this gets. We also know that route "leaks" commonly occur that result in outages and the potential for intercept or other nefarious activity. Additionally, we know that deaggregation, and similar events result in wide-scale systemic effects. We also know that topologically localized events occur that can impact our reachability, whether we're party to the actual fault or not. We have a slew of empirical data to support all of these things, some more high profile than others, with route leaks likely occurring at the highest frequency (every single day). I would suspect that the probability of fire effecting your network availability is very low, as you can fail over to a new facility. OTOH, if you have a route hijack (intentional or not) failover to a new facility with that address space isn't going to help, and hijacks can be topologically localized - the same applies for DDoS. Yet I suspect your organization has invested reasonably in fire suppression systems, but the asset that matters most that enables the substrate of some applications and services that you care about - the availability of your address space within the global routing system, has no safeguards whatsoever, and can be impacted from anywhere in the world. I'd also venture a guess that we've had more routing issues that have resulted in network downtime of critical sites than we have had fires (if someone disproves that _nice dinner on me!). We've got empirical data, we understand the vulnerability and the risk (probability of a threat being used). Put that in your risk management equation and consider what assets are most vulnerable to your organization - I'd venture it's something to do with network, and if routing ain't working, network ain't working... -danny From bicknell at ufp.org Tue May 11 10:03:49 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 11 May 2010 08:03:49 -0700 Subject: BGP (in)security makes the AP wire In-Reply-To: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> Message-ID: <20100511150349.GA72680@ussenterprise.ufp.org> In a message written on Sun, May 09, 2010 at 09:32:57AM -0400, Steven Bellovin wrote: > http://www.nytimes.com/aponline/2010/05/08/business/AP-US-TEC-Fragile-Internet.html > > It's a pretty reasonable article, too, though I don't know that I agree about the "simplicity of the routing system".... I had avoided this topic at first, but some of the follow on comments make me feel compelled to post. Deep down inside every industry are things that on the surface seem dangerous; particularly to someone outside of the industry. These make for excellent press headlines "Entire xyz one keystroke from collapse!", but these stories do not understand even the smallest fraction of the interaction. Did you know there are no safeguards to prevent the pilot of your next airplane from flying it into a building? Least you think it's just nutjobs, http://en.wikipedia.org/wiki/B-25_Empire_State_Building_crash Did you know tanker trunks with 10,000 gallons of fuel are allowed to drive in front of your kids school? One truck took out a significant part of the MacArthur Maze in Oakland, http://articles.sfgate.com/2007-04-29/bay-area/17239903_1_tanker-truck-roadway-firefighters Did you know that one operator of a nuclear power plant could cause the entire thing to melt down, simply because they weren't trained? http://en.wikipedia.org/wiki/Three_Mile_Island_accident The problem with any of these situations is that they are in fact complex systems. There is no "one cause", ever. The article suggests that the lack of route authentication on peering is the issue; it is not, it is one part of a majorly complex issue. Adding a filter to every peering session will not prevent prefix hijacking, it will merely change how it is done. I agree with Randy that we, as an industry, need to take steps to prevent prefix hijacking. I don't think letting a reporter dictate the method from some scare article is the right answer. But we also need to realize there is a cost/benefit trade off. We can so lock things down and mire them up in change control that it costs the economy (us and our customers) millions of dollars every day in lost productivity, but we never have a hijack. The real shame is that no one is explaining that side of things. So I disagree completely with Steven, this was an under-informed reporter trying to scare people into thinking the Internet is a massive house of cards that needs deeper regulation, oversight, or something. It's not reasonable in any sense of the word, and is not a balanced, engineering based assessment of the risks and costs. If we want to get this right, we need to quantify the effect of a route leak in dollars, and the cost of detecting and preventing a route leak in dollars. We can then mix in some moral and ethical views of the group and make sane engineering decisions with known risks that everyone is comfortable implementing. I will say this, my upstreams mucking up routing registry filters have caused me outages hundreds of times. I've had sites down for days because of filtering issues. I've also run into many cases where I found routes taking suboptimal paths due to mis-entered filters along the way; problems that those in the middle could not even detect because they were being filtered! I think if major ISP's tried to implement routing registry filters on their PNI's we would have weeks of outages and suboptimal routing, and the cure would be far worse than the disease. I hope that work on things like RPKI and SOBGP provide us a better, more workable framework. However, the jury is very much still out in my opinion. -- 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: From hank at efes.iucc.ac.il Tue May 11 10:06:18 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 11 May 2010 18:06:18 +0300 (IDT) Subject: BGP (in)security makes the AP wire In-Reply-To: <704953.46371.qm@web114313.mail.gq1.yahoo.com> References: <704953.46371.qm@web114313.mail.gq1.yahoo.com> Message-ID: On Tue, 11 May 2010, Mmaad Dooog wrote: > Is anyone going to jump on the irony of the last two paragraphs? > Having to use the excessively rigid, slow, static, boring expensive PSTN > to fix the cool, fast, flexible cheap, cool, fun Internet? That'll work > just fine, of course. Until, that is, one of the telcos in the path > saves a few bucks and routes a call leg over the Internet. > > What will us network operators do when there is NO out of band > management path to anything? What will happen when you can't even place > a phone call? > > The PSTN ran about 80 years or so on in-band signaling until a very > rational cost/benefit decision was made to remove signaling from the > traffic path. Physically seperating signaling (SS7) and routing (LERG, > etc) paths from the traffic (for all but the access link) was a large, > expensive, difficult effort, but worth it. The PSTN is full of > quasi-governmental central authorities for everything, and is all the > better for it. http://www.metacafe.com/watch/89338/morse_code_leno/ -Hank From tme at americafree.tv Tue May 11 10:08:12 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 11 May 2010 11:08:12 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: <11C6D32D-B9EB-4D83-B0C7-F50A9D54BCA1@tcb.net> References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> <4BE95C63.90901@foobar.org> <11C6D32D-B9EB-4D83-B0C7-F50A9D54BCA1@tcb.net> Message-ID: Dear Danny; On May 11, 2010, at 10:13 AM, Danny McPherson wrote: > > On May 11, 2010, at 7:32 AM, Nick Hilliard wrote: > >> Risk analysis is ass covering without the theatre. You collect >> data, make >> a judgement based on that data, and if it turns out that the >> judgement says >> that signed bgp updates constitute more of a stability risk to >> network >> operations than the occasional shock problem > > So apply the risk management analogy here. We all know that > pretty much anyone can assert reachability for anyone else's > address space inter-domain on the Internet, in particular the > closer you get to 'the core' the easier this gets. We also > know that route "leaks" commonly occur that result in outages > and the potential for intercept or other nefarious activity. > Additionally, we know that deaggregation, and similar events > result in wide-scale systemic effects. We also know that > topologically localized events occur that can impact our reachability, > whether we're party to the actual fault or not. We have a slew of > empirical data to support all of these things, some more high profile > than others, with route leaks likely occurring at the highest > frequency (every single day). > > I would suspect that the probability of fire effecting your > network availability is very low, as you can fail over to a > new facility. OTOH, if you have a route hijack (intentional > or not) failover to a new facility with that address space > isn't going to help, and hijacks can be topologically localized > - the same applies for DDoS. Yet I suspect your organization > has invested reasonably in fire suppression systems, but the > asset that matters most that enables the substrate of some > applications and services that you care about - the availability > of your address space within the global routing system, has no > safeguards whatsoever, and can be impacted from anywhere in the > world. > > I'd also venture a guess that we've had more routing issues that > have resulted in network downtime of critical sites than we have had > fires (if someone disproves that _nice dinner on me!). But there is also recovery time, which you don't mention in your bet. If the building I am sitting in right now were to burn down to the ground, the client I am at would be affected for months and months. Yes, they have backups, and redundancy, but this is their HQ. If they (say) fat finger their BGP, well, it would be bad, but if they fix it this afternoon, everything will go back to normal shortly thereafter. So, sure, network outages may be more frequent than catastrophic fires, but that doesn't mean that the aggregated duration of disruption from network outages is greater than the aggregated disruption duration from fires. Regards Marshall > > We've got empirical data, we understand the vulnerability and the > risk (probability of a threat being used). Put that in your risk > management equation and consider what assets are most vulnerable > to your organization - I'd venture it's something to do with network, > and if routing ain't working, network ain't working... > > -danny > > From bicknell at ufp.org Tue May 11 10:08:16 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 11 May 2010 08:08:16 -0700 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: <20100511150816.GB72680@ussenterprise.ufp.org> In a message written on Mon, May 10, 2010 at 11:28:42AM -0500, Jerry Bonner wrote: > I share a certain amount of love for this platform dating back to Ascend, but what am I to do now? Obviously no one is making large investments in their dial platform, but are there any other viable alternatives out there that are actually supported? DSL, Cable Modems, WiFi, WiMax, FTTH..... Seriously, AT&T now offers $10 per month DSL: http://arstechnica.com/old/content/2007/06/att-launches-10-dsl-it-hopes-no-one-signs-up-for.ars, 768k down, 128k up. There comes a time when the old tech just doesn't make sense, even if a small customer base still wants 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: From jabley at hopcount.ca Tue May 11 10:29:06 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 11 May 2010 11:29:06 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <20100511150816.GB72680@ussenterprise.ufp.org> References: <20100511150816.GB72680@ussenterprise.ufp.org> Message-ID: On 2010-05-11, at 11:08, Leo Bicknell wrote: > There comes a time when the old tech just doesn't make sense, even > if a small customer base still wants it. There will also no doubt continue to be many customers for whom dial is the only option. It's not long ago that I lived in such a house, deceptively close to the outskirts of town but in terms of wire distance and load coils it might as well have been on the moon. The house was in a wireless dead zone by a river, there was no cable, and the only line of sight to another structure was through several acres of 2.4GHz-absorbing trees. The further you move away from urban centres, the easier it is to find examples of this. Joe From cmaurand at xyonet.com Tue May 11 10:30:49 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 11 May 2010 11:30:49 -0400 Subject: Rugged wireless bridge In-Reply-To: References: Message-ID: <4BE97829.3030203@xyonet.com> On 5/11/2010 9:36 AM, Andrey Khomyakov wrote: > Hi all, > > I need to provide IP connectivity to an outdoor parking lot for security > devices like a camera, and emergency phone and a gate. Does anyone have any > suggestions on a wireless bridge and an outdoor rated switch if such exists? > How do people provide IP to outdoor locations like a surface parking lot? > > http://www.cisco.com/en/US/products/ps10050/index.html --Curtis From cmaurand at xyonet.com Tue May 11 10:51:19 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 11 May 2010 11:51:19 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: <20100511150816.GB72680@ussenterprise.ufp.org> Message-ID: <4BE97CF7.4030008@xyonet.com> 30% of all people in the US (110 million) have no access to broadband. Large areas of my state have no access to broadband because its rural (Maine). Aastra CVX (it used to be a Nortel product.) --Curtis On 5/11/2010 11:29 AM, Joe Abley wrote: > On 2010-05-11, at 11:08, Leo Bicknell wrote: > > >> There comes a time when the old tech just doesn't make sense, even >> if a small customer base still wants it. >> > There will also no doubt continue to be many customers for whom dial is the only option. > > It's not long ago that I lived in such a house, deceptively close to the outskirts of town but in terms of wire distance and load coils it might as well have been on the moon. The house was in a wireless dead zone by a river, there was no cable, and the only line of sight to another structure was through several acres of 2.4GHz-absorbing trees. > > The further you move away from urban centres, the easier it is to find examples of this. > > > Joe > From shane at short.id.au Tue May 11 11:02:23 2010 From: shane at short.id.au (Shane Short) Date: Wed, 12 May 2010 00:02:23 +0800 Subject: Rugged wireless bridge In-Reply-To: <4BE97829.3030203@xyonet.com> References: <4BE97829.3030203@xyonet.com> Message-ID: <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> I've had multiple issues with the WAP200E units in the field-- from the Internal PoE cabling being crushed and not working properly, to finding some of the internal antennas wern't even soldered to the PCB properly. I'd definitely +1 on the ubiquiti stuff. however, they've been extremely solid. On 11/05/2010, at 11:30 PM, Curtis Maurand wrote: > On 5/11/2010 9:36 AM, Andrey Khomyakov wrote: >> Hi all, >> >> I need to provide IP connectivity to an outdoor parking lot for security >> devices like a camera, and emergency phone and a gate. Does anyone have any >> suggestions on a wireless bridge and an outdoor rated switch if such exists? >> How do people provide IP to outdoor locations like a surface parking lot? >> >> > http://www.cisco.com/en/US/products/ps10050/index.html > > --Curtis From gbonser at seven.com Tue May 11 11:04:54 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 11 May 2010 09:04:54 -0700 Subject: SFP+ ER and ZR In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA426F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: bas > Sent: Tuesday, May 11, 2010 1:25 AM > To: nanog > Subject: SFP+ ER and ZR > > Hi Guys, > > I thought ER and ZR SFP+ optics were not available (yet) due to power > and cooling "challenges". > > However on this site: > http://www.excelight.com/products/datalink/sfpplus.asp > They offer both ER and ZR SFP+ optics. > > Has anyone used or tested with these? If so with which equipment? > Or have you found other vendors of these optics? > > Thanks in advance, > > Bas Last time I checked there was an ER SFP+ optic in acceptance testing at one major network vendor. That was about a year ago so it would not surprise me if there was one available. The problem was heat dissipation in the small form factor. The optic module gets hot and doesn't live long. George From damin at nacs.net Tue May 11 11:32:56 2010 From: damin at nacs.net (Gregory J. Boehnlein) Date: Tue, 11 May 2010 12:32:56 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> References: <017201caf060$f7e4bcd0$e7ae3670$@net> <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> Message-ID: <00b201caf127$a0cf7710$e26e6530$@net> When I sold my business in January, we still had 4 PRI circuits that were providing Dial-Up access using Livingston Portmaster 3's. I bet those things will run for another 5 years! :) Dial Up still has a place in many areas where Broadband cannot cost-effectively reach. Better to have Dial Up than nothing at all. From pbosworth at gmail.com Tue May 11 11:33:37 2010 From: pbosworth at gmail.com (Paul Bosworth) Date: Tue, 11 May 2010 10:33:37 -0600 Subject: Rugged wireless bridge In-Reply-To: References: Message-ID: Hey Andrey, I've deployed Cisco Aironet 1300's for specifically what you're looking to do (as well as remote ATM connectivity). They are robust and have great centralized management tools if you have a large deployment. They're also very flexible and obviously have great support from the manufacturer. Thanks On Tue, May 11, 2010 at 7:36 AM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > Hi all, > > I need to provide IP connectivity to an outdoor parking lot for security > devices like a camera, and emergency phone and a gate. Does anyone have any > suggestions on a wireless bridge and an outdoor rated switch if such > exists? > How do people provide IP to outdoor locations like a surface parking lot? > > Thanks, > Andrey > > -- > Andrey Khomyakov > [khomyakov.andrey at gmail.com] > -- Paul H Bosworth GSEC, GCFW, GCIH CCNP, CCIP, CCDP From lists at mtin.net Tue May 11 11:38:32 2010 From: lists at mtin.net (Justin Wilson) Date: Tue, 11 May 2010 12:38:32 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <00b201caf127$a0cf7710$e26e6530$@net> Message-ID: There are those ppl who just want to do e-mail, are comfortable with dial-up, don?t want to pay for than $5-10 for internet, and can?t get anything else. -- Justin Wilson http://www.mtin.net/blog Wisp Consulting ? Tower Climbing ? Network Support From: "Gregory J. Boehnlein" Date: Tue, 11 May 2010 12:32:56 -0400 To: 'Mark Foster' , 'Bill Fehring' Cc: Subject: RE: Dial Concentrators - TNT / APX8000 R.I.P. When I sold my business in January, we still had 4 PRI circuits that were providing Dial-Up access using Livingston Portmaster 3's. I bet those things will run for another 5 years! :) Dial Up still has a place in many areas where Broadband cannot cost-effectively reach. Better to have Dial Up than nothing at all. From donvittony at gmail.com Tue May 11 12:55:02 2010 From: donvittony at gmail.com (Vitto Capabianco) Date: Tue, 11 May 2010 13:55:02 -0400 Subject: eBGP TTL matching requirement Message-ID: Folks, Is there a TTL value enforcment on EBGP session establishment? For some reason I thought that both peers have to have the SAMe value? Is that true? For example: default EBGP = TTL = 1 (if one end sends something other than 1 in its OPEN message, we won't bring up the adjecancy) multihop EBGP = TTL = 255 (by default) - likewise, if one end sends something else, adjecancy won't come up multihop EBGP = TTL = modified hop value - ex. 15 (both ends have to have it) I understand that ttl-security and its implications. Thanks, Vitto From patrick at ianai.net Tue May 11 13:09:42 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 May 2010 14:09:42 -0400 Subject: Securing the BGP or controlling it? In-Reply-To: References: <22860097.577.1273462765725.JavaMail.franck@franck-martins-macbook-pro.local> <4BE82BAC.2010509@foobar.org> Message-ID: On May 10, 2010, at 3:20 PM, Randy Bush wrote: >> this is a matter of risk analysis. No secure routing means we'll >> continue to see the occasional high profile outage which is dealt with >> very quickly. > > how soon we forget 7007, 128/8, ... over a day each, and global, and > very big netowrks. You are right, I forgot that 7007 took more than a day. I distinctly remember being able to use the 'Net later that same day, so I did more than "forget", I actually invented something in my memory. Moreover, Vinny physically unplugged (data _and_ power) all cables attached to the Bay Networks router which was the source of the problem in very little time. Maybe 30 minutes? It was Sprint's custom IOS image which ignored withdrawals that made the problem last a very long time. I would say that is two separate problems, but I guess you could argue they are related and we should be vigilant against hijacking in case Sean re-enters the field and cons $ROUTER_VENDOR into writing custom code because he's too cheap to upgrade his hardware. Whichever interpretation you prefer the last two sentences, having that information is germane to the discussion. Having all the facts allow us to make good decisions based on more than sound-bites and NYT articles. Of course, then we couldn't post cryptic one-liners trying to scare the newbies with our vast knowledge of historical events, however we spin them. And then where would we be? -- TTFN, patrick P.S. Lest anyone think I am arguing for (or against) one view or the other, I am not. Every big outage means someone has to explain to their management what went wrong, whether it was their fault or not. And protecting against every possible outage is hideously expensive. Both sides need to be considered. But hyperbole, half-truths, and spin is not the basis for a rational discussion. IMHO, of course. > if something like those happen again, we are gonna be spending a lot of > time explaining our selves to people who wear funny clothes, and telling > them why it is not going to happen again if they let us keep our jobs. > > randy > From patrick at ianai.net Tue May 11 13:10:57 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 11 May 2010 14:10:57 -0400 Subject: eBGP TTL matching requirement In-Reply-To: References: Message-ID: On May 11, 2010, at 1:55 PM, Vitto Capabianco wrote: > Is there a TTL value enforcment on EBGP session establishment No. -- TTFN, patrick > For some > reason I thought that both peers have to have the SAMe value? Is that > true? For example: > > default EBGP = TTL = 1 (if one end sends something other than 1 in its OPEN > message, we won't bring up the adjecancy) > multihop EBGP = TTL = 255 (by default) - likewise, if one end sends > something else, adjecancy won't come up > multihop EBGP = TTL = modified hop value - ex. 15 (both ends have to have > it) > > > I understand that ttl-security and its implications. > > Thanks, > > Vitto > From zeusdadog at gmail.com Tue May 11 13:35:18 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Tue, 11 May 2010 14:35:18 -0400 Subject: BGP and convergence time Message-ID: So, we have two upstreams, both coming in on Ethernet. One of our switch crashed and rebooted itself. Although we have other paths to egress out the network, because the router's Ethernet interface didn't go down, our router's BGP didn't realize the neighbor was down until default BGP timeout was reached. Our upstream connectivity was out for couple minutes. I am looking for ways to detect neighbor being down faster so traffic can be re-routed faster. I can do BFD internally but the issue is how the upstream is going to detect the outage and stop routing our traffic to that downed link. I have asked both of my upstreams and one said they don't do anything like that, second upstream I am still waiting on the answer. My question is, do other carriers do BFD or any other means to detect the neighbor being down faster than normal BGP will allow? (Both upstreams are major telcos [AT&T and Qwest], so I think they are less flexible than some others.) Or, has anyone succeeded in getting something done with those two carriers? Thanks! From sethm at rollernet.us Tue May 11 15:59:09 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 11 May 2010 13:59:09 -0700 Subject: BGP and convergence time In-Reply-To: References: Message-ID: <4BE9C51D.7040307@rollernet.us> On 5/11/2010 11:35, Jay Nakamura wrote: > So, we have two upstreams, both coming in on Ethernet. One of our > switch crashed and rebooted itself. Although we have other paths to > egress out the network, because the router's Ethernet interface didn't > go down, our router's BGP didn't realize the neighbor was down until > default BGP timeout was reached. Our upstream connectivity was out > for couple minutes. > > I am looking for ways to detect neighbor being down faster so traffic > can be re-routed faster. I can do BFD internally but the issue is how > the upstream is going to detect the outage and stop routing our > traffic to that downed link. I have asked both of my upstreams and > one said they don't do anything like that, second upstream I am still > waiting on the answer. > > My question is, do other carriers do BFD or any other means to detect > the neighbor being down faster than normal BGP will allow? (Both > upstreams are major telcos [AT&T and Qwest], so I think they are less > flexible than some others.) > > Or, has anyone succeeded in getting something done with those two carriers? > In my experience this is a pretty common problem with carrier Ethernet links where the interface is always "up" unless the directly connected switch/mux fails. Even then, it may still keep the port up through reboots. I like how Ethernet is cheap, but I hate how it lacks simple things like "link is down if any segment of the L1 or L2 between endpoints faults" that you get without silly tricks on a DSx or OC-x. (Then again, I suppose you're paying for that capability if it's important enough.) ~Seth From marcus at grmpf.org Tue May 11 16:18:45 2010 From: marcus at grmpf.org (Marcus Stoegbauer) Date: Tue, 11 May 2010 23:18:45 +0200 Subject: DENOG 2 - Call for Participation and Papers Message-ID: <4BE9C9B5.3040604@grmpf.org> DENOG 2 - Call for Participation and Papers The second meeting of the German Network Operators Group (DENOG) will be held in Frankfurt, Germany on the 4th of November 2010. We are pleased to hereby invite applications for presentations or lightning talks to be held at this event. General Information =================== DENOG is a community for professionals within Germany who are operating, designing or researching the Internet. It provides a technical forum where those working on, with and for the Internet can come together to solve problems with every aspect of their (net)work. The meeting is designed to provide an opportunity for the exchange of information among network operators, engineers, researchers and other professionals close to the network community. More information about DENOG (in German) can be found at http://www2.denog.de/ Information about the meeting will be published at http://www.denog.de/. Meeting Countdown ================= What When ------------------------------------------------------ Publication of Call for Papers May 11th, 2010 Deadline for all submissions August 15th, 2010 Beginning of Registration Period August 16th, 2010 Publication of final programme September 6th, 2010 Deadline for receipt of final slides October 24th, 2010 Meeting Day November 4th, 2010 Topics for Presentations/Talks ============================== The day will be divided into several sessions. The number and length of presentations per session is not fixed, although due to time constraints we would prefer the length of the presentations to be between 10 to 30 minutes. However proposals for longer/shorter presentations or presentations whose subject falls outside of the topics below are also welcome; please do not hesitate to submit them. Lightning Talks --------------- In addition to the topics mentioned below we will reserve slots for lightning talks, which consist of a few slides and will not last longer than 5 minutes. Lightning talks can be submitted until October 29th, with the deadline for submission of the corresponding slides being November 3rd. Topic #1: Power Efficiency in Networks --------------------------------------- For operators of networks and data centres of any size power efficiency has become more important. Servers and network gear with high power consumption are expensive because of high operating and cooling power costs; also in many places supplying more power into the location is no longer possible. How are you dealing with power problems in your environment? How do you efficiently cool a rack/a room/a datacenter? Can a migration to VoIP help you save power? Topic #2: Social Networks, Cloud Services and Information Security ------------------------------------------------------------------ Social Networks are an essential working tool for networkers and cloud services are also becoming increasingly popular. The security of your information and data in these networks is a crucial aspect which we want to discuss in this session. Topic #3: Network Neutrality ---------------------------- In the US, Network Neutrality has been a subject of controversy and debate. Is an ISP allowed to sell "Internet access" which only offers access to a subset of the whole Internet? Is an ISP allowed to prioritise video streams from Company A while imposing a higher delay to video streams from Company B? In Germany Network Neutrality is mainly an issue for mobile networks and not extensively discussed thus far. But what kind of problems will an upcoming debate on Network Neutrality bring to German ISPs and is there a good way to address these problems? Topic #4: Peering ------------------ Everything about your peering experience. Why are you doing it? How are you doing it? Have you written any useful tools which others might find interesting? Topic #5: ISP BOF ----------------- "All things ISP". From Network/SLA Management (for or against it), abuse handling and log systems to data centre layout and planning (including power and cooling), everything that is interesting to you as an ISP can be presented or discussed within this topic. Language of Slides and Talks ============================ To appeal to an international audience we ask you to produce your slides in English, but the spoken language of the presentation itself can be either German or English. Submission Guidelines ===================== All submissions must have a strong technical bias and must not be solely promotional for your employer. Please remember that your presentations should be suitable for a target audience of technicians from varied backgrounds, working for companies whose sizes may vary considerably. To submit a proposal for a presentation, we request that you provide the following information as plain text or PDF format to : * the name of the presenter (and if applicable your affiliation) * a working email address * the name and number of the topic which will contain the presentation * the title of the presentation * its expected length (in minutes) * the preferred spoken language for the presentation * a short abstract of the presentation (not more than 200 words) We also welcome suggestions for specific presentations which you feel would be valuable to the DENOG community. Please be aware that your presentation will be published on the DENOG website after the event. From randy at psg.com Tue May 11 16:59:36 2010 From: randy at psg.com (Randy Bush) Date: Tue, 11 May 2010 23:59:36 +0200 Subject: BGP and convergence time In-Reply-To: References: Message-ID: > I am looking for ways to detect neighbor being down faster so traffic > can be re-routed faster. BFD From blakjak at blakjak.net Tue May 11 17:15:08 2010 From: blakjak at blakjak.net (Mark Foster) Date: Wed, 12 May 2010 10:15:08 +1200 (NZST) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: Message-ID: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> On Wed, May 12, 2010 4:38 am, Justin Wilson wrote: > There are those ppl who just want to do e-mail, are comfortable with > dial-up, don?t want to pay for than $5-10 for internet, and can?t get > anything else. Indeed. The arguments for alternatives based on the fact theyre cheap, don't counter the fact that it's not available _everywhere_. Thus the wider concern I flagged; if the only source for equipment and spares is the grey market, aren't the vendors missing the boat on something which shouldn't even have a major overhead to maintain? What about developing nations where Internet isn't yet as commonplace as it is in the 'west' ? From ras at e-gerbil.net Tue May 11 18:40:54 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 11 May 2010 18:40:54 -0500 Subject: SFP+ ER and ZR In-Reply-To: References: Message-ID: <20100511234054.GU1261@gerbil.cluepon.net> On Tue, May 11, 2010 at 04:24:42AM -0400, bas wrote: > Hi Guys, > > I thought ER and ZR SFP+ optics were not available (yet) due to power > and cooling "challenges". > > However on this site: http://www.excelight.com/products/datalink/sfpplus.asp > They offer both ER and ZR SFP+ optics. > > Has anyone used or tested with these? If so with which equipment? > Or have you found other vendors of these optics? They aren't (yet), these are vaporware. Many amnufacturers are close to having reliable 40km optics, and several are making 20km+ overpowered LRs, but ZR and DWDM are still a ways out. There are also some CWDM units in the works, but because SFP+ doesn't support onboard EDC you are limited by dispersion to 10km in the traditional 8ch 1470-1610nm CWDM space over SMF28. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From zeusdadog at gmail.com Tue May 11 20:31:51 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Tue, 11 May 2010 21:31:51 -0400 Subject: BGP and convergence time In-Reply-To: References: Message-ID: Yes, I understand BFD. The question is, do carriers usually do BFD with customers? And if they say no, are there other remedies? AT&T doesn't seem to be even willing to change BGP timers. If anyone have been able to talk AT&T or Qwest in doing so, it would really help to find out how they convinced them. They are such a big bureaucracies that it's frustrating to do anything that makes sense. Although Qwest seems a lot more responsive than AT&T. On Tue, May 11, 2010 at 5:59 PM, Randy Bush wrote: >> I am looking for ways to detect neighbor being down faster so traffic >> can be re-routed faster. > > BFD > From surfer at mauigateway.com Tue May 11 20:36:57 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 11 May 2010 18:36:57 -0700 Subject: BGP and convergence time Message-ID: <20100511183657.4C01B60D@resin12.mta.everyone.net> --- zeusdadog at gmail.com wrote: From: Jay Nakamura AT&T doesn't seem to be even willing to change BGP timers. If anyone have been able to talk AT&T or Qwest in doing so, it would really help to ---------------------------------------- You set the timers on your side and the two sides negotiate then select the lowest timer settings. The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that. scott From ras at e-gerbil.net Tue May 11 20:56:28 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Tue, 11 May 2010 20:56:28 -0500 Subject: BGP and convergence time In-Reply-To: References: Message-ID: <20100512015628.GX1261@gerbil.cluepon.net> On Tue, May 11, 2010 at 09:31:51PM -0400, Jay Nakamura wrote: > Yes, I understand BFD. The question is, do carriers usually do BFD > with customers? And if they say no, are there other remedies? AT&T > doesn't seem to be even willing to change BGP timers. If anyone have > been able to talk AT&T or Qwest in doing so, it would really help to > find out how they convinced them. They are such a big bureaucracies > that it's frustrating to do anything that makes sense. Although Qwest > seems a lot more responsive than AT&T. Slow as the titanic carriers won't do anything innovative for anyone, regardless of the benefit. Try a clueful carrier and they'll be happy to run BFD with you. Of course after promoting it for more than a year now we have something like 5 peers and 0 customers using it (mostly because of broken vendor implementations), but hey it's never too late to start. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From rdobbins at arbor.net Tue May 11 21:07:15 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 12 May 2010 02:07:15 +0000 Subject: eBGP TTL matching requirement In-Reply-To: References: Message-ID: <66B7164D-5955-4636-AEAB-43693A69AB57@arbor.net> On May 12, 2010, at 1:10 AM, Patrick W. Gilmore wrote: > No. Concur, but the original poster should also look at the GTSM, which doesn't do what he asked about but which does make use of TTL as a validation mechanism: ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From sthaug at nethelp.no Wed May 12 02:40:03 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 12 May 2010 09:40:03 +0200 (CEST) Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: <91db8ec9557dc4ac9020d56cf1e719e9.squirrel@webmail.blakjak.net> <4BE8CD73.3050705@sneep.net> Message-ID: <20100512.094003.74666379.sthaug@nethelp.no> > I've heard of some LECs starting to mull dropping frame relay as a > supported service as well... The provider I work for stopped selling Frame Relay four years ago. However, we didn't throw out the last Nortel Passport switches until about one year ago. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From matthew at walster.org Wed May 12 10:02:01 2010 From: matthew at walster.org (Matthew Walster) Date: Wed, 12 May 2010 16:02:01 +0100 Subject: BGP and convergence time In-Reply-To: <20100511183657.4C01B60D@resin12.mta.everyone.net> References: <20100511183657.4C01B60D@resin12.mta.everyone.net> Message-ID: On 12 May 2010 02:36, Scott Weeks wrote: > You set the timers on your side and the two sides negotiate then select the lowest timer settings. ?The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that. Hold timers are negotiated in the OPEN message, I seem to remember, so surely you *have* to hard reset the connection to get the lower holdtime? M From zeusdadog at gmail.com Wed May 12 10:40:29 2010 From: zeusdadog at gmail.com (Jay Nakamura) Date: Wed, 12 May 2010 11:40:29 -0400 Subject: BGP and convergence time In-Reply-To: References: <20100511183657.4C01B60D@resin12.mta.everyone.net> Message-ID: On Wed, May 12, 2010 at 11:02 AM, Matthew Walster wrote: > On 12 May 2010 02:36, Scott Weeks wrote: >> You set the timers on your side and the two sides negotiate then select the lowest timer settings. ?The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that. > > Hold timers are negotiated in the OPEN message, I seem to remember, so > surely you *have* to hard reset the connection to get the lower > holdtime? I just tested this and, yes, with Cisco to Cisco, changing the setting won't reset the connection but you have to reset the connection to have the value take effect. I need to look up what happens when two sides are set to different values and which one takes precedent. From danny at tcb.net Wed May 12 10:52:48 2010 From: danny at tcb.net (Danny McPherson) Date: Wed, 12 May 2010 09:52:48 -0600 Subject: BGP and convergence time In-Reply-To: References: <20100511183657.4C01B60D@resin12.mta.everyone.net> Message-ID: On May 12, 2010, at 9:40 AM, Jay Nakamura wrote: > > I just tested this and, yes, with Cisco to Cisco, changing the setting > won't reset the connection but you have to reset the connection to > have the value take effect. I need to look up what happens when two > sides are set to different values and which one takes precedent. The holdtime isn't technically negotiated, both sides convey their value in the open message and the lower of the two is used by both BGP speakers. IIRC, neither J or C reset the session with the timer change, but the new holdtimer expiry value doesn't take effect until then. One other thing to note is that by default, keepalive intervals in those implementations are {holdtime/3}. Normally, if you're setting holdtime to something really lower (e.g., 10 seconds) you might want to increase the frequency of keepalives such that the probability of getting one through in times of instability rise. In particular, congestion incurred outside of BGP, as update messages themselves will serve as implicit keepalives, and with the amount of churn in BGP, empty updates (keepalives) are rare for most speakers with a global BGP view. -danny From rens at autempspourmoi.be Wed May 12 11:07:18 2010 From: rens at autempspourmoi.be (Rens) Date: Wed, 12 May 2010 18:07:18 +0200 Subject: IPv4 Multicast In-Reply-To: References: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Message-ID: I have done some tests with multicast streams, sender & receivers all in the same layer 2 vlan, but I also have a pc with just wireshark and I can see all this traffic. I can see that IGMP is enabled on all interfaces but do I need enable something else? Vlan 200: -------- IGMP snooping : Enabled IGMPv2 immediate leave : Disabled Explicit host tracking : Enabled Multicast router learning mode : pim-dvmrp CGMP interoperability mode : IGMP_ONLY -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: mardi 11 mai 2010 15:43 To: Rens Cc: nanog at nanog.org Subject: Re: IPv4 Multicast On Tue, 11 May 2010, Rens wrote: > Does anyone have any configuration examples for this or tutorials, > everything on the net seems way to complex for my needs. Multicast Quick-Start Configuration Guide -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.holstein at csuohio.edu Wed May 12 11:09:57 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Wed, 12 May 2010 12:09:57 -0400 Subject: CIDR blocks, by country Message-ID: <4BEAD2D5.5080908@csuohio.edu> I am aware of sites that list all the netblocks associated with China (for example) .. is there any place that publishes an updated list of what netblocks are used by what countries? (all of them) .. CIDR format would be ideal. If it matters, I'm specifically interested APNIC and AFRNIC. Regards, Michael Holstein Cleveland State Unviersity From lesmith at ecsis.net Wed May 12 11:22:01 2010 From: lesmith at ecsis.net (Larry Smith) Date: Wed, 12 May 2010 11:22:01 -0500 Subject: CIDR blocks, by country In-Reply-To: <4BEAD2D5.5080908@csuohio.edu> References: <4BEAD2D5.5080908@csuohio.edu> Message-ID: <201005121122.01475.lesmith@ecsis.net> On Wed May 12 2010 11:09, Michael Holstein wrote: > I am aware of sites that list all the netblocks associated with China > (for example) .. is there any place that publishes an updated list of > what netblocks are used by what countries? (all of them) .. CIDR format > would be ideal. > > If it matters, I'm specifically interested APNIC and AFRNIC. > > Regards, > > Michael Holstein > Cleveland State Unviersity Since blackholes.us went away, the only other one I have found semi-reliable is Country IP Blocks at http://www.countryipblocks.net -- Larry Smith lesmith at ecsis.net From Chris.Campbell at nebulassolutions.com Wed May 12 11:28:52 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Wed, 12 May 2010 17:28:52 +0100 Subject: CIDR blocks, by country In-Reply-To: <4BEAD2D5.5080908@csuohio.edu> Message-ID: Maxmind or Quova offer a commercial database if that?s what you need. Maxmind also do a less frequently updated free version. On 12/05/2010 17:09, "Michael Holstein" wrote: I am aware of sites that list all the netblocks associated with China (for example) .. is there any place that publishes an updated list of what netblocks are used by what countries? (all of them) .. CIDR format would be ideal. If it matters, I'm specifically interested APNIC and AFRNIC. Regards, Michael Holstein Cleveland State Unviersity From bpfankuch at cpgreeley.com Wed May 12 11:34:03 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Wed, 12 May 2010 10:34:03 -0600 Subject: CIDR blocks, by country In-Reply-To: <201005121122.01475.lesmith@ecsis.net> References: <4BEAD2D5.5080908@csuohio.edu> <201005121122.01475.lesmith@ecsis.net> Message-ID: <01759D50DC387C45A018FE1817CE27D76BC3AE6B36@CPExchange1.cpgreeley.com> http://countries.nerd.dk/ publishes files that can be used in some form of an RBL that covers most of this as well. I use this for a geolocated DNS system and it works well. I have actually manually referenced this to find where a specific block is from. -----Original Message----- From: Larry Smith [mailto:lesmith at ecsis.net] Sent: Wednesday, May 12, 2010 10:22 AM To: nanog at nanog.org Subject: Re: CIDR blocks, by country On Wed May 12 2010 11:09, Michael Holstein wrote: > I am aware of sites that list all the netblocks associated with China > (for example) .. is there any place that publishes an updated list of > what netblocks are used by what countries? (all of them) .. CIDR > format would be ideal. > > If it matters, I'm specifically interested APNIC and AFRNIC. > > Regards, > > Michael Holstein > Cleveland State Unviersity Since blackholes.us went away, the only other one I have found semi-reliable is Country IP Blocks at http://www.countryipblocks.net -- Larry Smith lesmith at ecsis.net From sherwin.ang at gmail.com Wed May 12 11:53:59 2010 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Thu, 13 May 2010 00:53:59 +0800 Subject: CIDR blocks, by country In-Reply-To: <4BEAD2D5.5080908@csuohio.edu> References: <4BEAD2D5.5080908@csuohio.edu> Message-ID: For the whole APNIC: http://www.apnic.net/publications/research-and-insights/ip-address-trends/apnic-resource-range ftp://ftp.apnic.net/apnic/stats/ carries raw data files updated daily for all allocations in a delimited file format. you may have to do some sorting, what i do is put it in a mysql database and do selects per country of interest. hth. On Thu, May 13, 2010 at 12:09 AM, Michael Holstein wrote: > I am aware of sites that list all the netblocks associated with China > (for example) .. is there any place that publishes an updated list of > what netblocks are used by what countries? (all of them) .. CIDR format > would be ideal. > > If it matters, I'm specifically interested APNIC and AFRNIC. > > Regards, > > Michael Holstein > Cleveland State Unviersity > > > From jcdill.lists at gmail.com Wed May 12 11:56:31 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 12 May 2010 09:56:31 -0700 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> References: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> Message-ID: <4BEADDBF.7080904@gmail.com> Mark Foster wrote: > On Wed, May 12, 2010 4:38 am, Justin Wilson wrote: > >> There are those ppl who just want to do e-mail, are comfortable with >> dial-up, don?t want to pay for than $5-10 for internet, and can?t get >> anything else. >> > > > Indeed. The arguments for alternatives based on the fact theyre cheap, > don't counter the fact that it's not available _everywhere_. > > Thus the wider concern I flagged; if the only source for equipment and > spares is the grey market, aren't the vendors missing the boat on > something which shouldn't even have a major overhead to maintain? > The source for equipment and spares isn't the "grey market" - it's the USED market. There should be ample used equipment to meet the small amount of dial-up equipment purchases needs for years to come as many ISPs phase out dial-up equipment and services and offer their old (still working but no-longer-needed) dial-up equipment for resale. > What about developing nations where Internet isn't yet as commonplace as > it is in the 'west' ? > Most developing nations today are leapfrogging right over POTS and dial-up into a cellular/wireless infrastructure. This is why there is so little demand for dial-up infrastructure equipment. If there's a significant need for dial-up equipment and support then at least one company will provide legacy support, perhaps act as a reseller to help provision used dial-up equipment and recondition the equipment etc. You *can* still buy brand new buggy whips: http://www.jedediahsbuggywhip.com/ http://www.drivingessentials.com/Whips.htm There are still vendors selling thousands of different types of radio tubes, even though they haven't been manufactured for many years: http://www.vacuumtubes.net/ jc From jared at puck.nether.net Wed May 12 12:07:39 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 12 May 2010 13:07:39 -0400 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <4BEADDBF.7080904@gmail.com> References: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> <4BEADDBF.7080904@gmail.com> Message-ID: On May 12, 2010, at 12:56 PM, JC Dill wrote: > You *can* still buy brand new buggy whips: > > http://www.jedediahsbuggywhip.com/ > http://www.drivingessentials.com/Whips.htm I get my wooden oars and paddles here: http://www.shawandtenney.com/ They are great and work well on the double-ended rowboats (canoe shaped) we have. - Jared From cmadams at hiwaay.net Wed May 12 12:13:13 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 12 May 2010 12:13:13 -0500 Subject: CIDR blocks, by country In-Reply-To: <01759D50DC387C45A018FE1817CE27D76BC3AE6B36@CPExchange1.cpgreeley.com> References: <4BEAD2D5.5080908@csuohio.edu> <201005121122.01475.lesmith@ecsis.net> <01759D50DC387C45A018FE1817CE27D76BC3AE6B36@CPExchange1.cpgreeley.com> Message-ID: <20100512171313.GA1362595@hiwaay.net> Once upon a time, Blake Pfankuch said: > http://countries.nerd.dk/ publishes files that can be used in some form of an RBL that covers most of this as well. I use this for a geolocated DNS system and it works well. I have actually manually referenced this to find where a specific block is from. I found that list to be out-of-date and slow to change (when errors were pointed out). I ended up taking the Maxmind free database and writing a perl DNS server to feed it. The free database is updated once a month and that is good enough for my uses. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From andree+nanog at toonk.nl Wed May 12 12:15:09 2010 From: andree+nanog at toonk.nl (Andree Toonk) Date: Wed, 12 May 2010 10:15:09 -0700 Subject: CIDR blocks, by country In-Reply-To: <4BEAD2D5.5080908@csuohio.edu> References: <4BEAD2D5.5080908@csuohio.edu> Message-ID: <4BEAE21D.3010905@toonk.nl> Hi Michael, .-- My secret spy satellite informs me that at 12/05/10 9:09 AM Michael Holstein wrote: > I am aware of sites that list all the netblocks associated with China > (for example) .. is there any place that publishes an updated list of > what netblocks are used by what countries? (all of them) .. CIDR format > would be ideal. See: http://www.bgpmon.net/IPtoCountry.txt This list is generated once a day. It should contain all prefixes in the BGP table of which it was able to determine the country. The list contains both IPv4 as well as IPv6 prefixes. > If it matters, I'm specifically interested APNIC and AFRNIC. I can supply similar lists based on country or continents if there's enough interest. Cheers, Andree From rsk at gsp.org Wed May 12 12:18:34 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 12 May 2010 13:18:34 -0400 Subject: CIDR blocks, by country In-Reply-To: <4BEAD2D5.5080908@csuohio.edu> References: <4BEAD2D5.5080908@csuohio.edu> Message-ID: <20100512171834.GA8334@gsp.org> On Wed, May 12, 2010 at 12:09:57PM -0400, Michael Holstein wrote: > I am aware of sites that list all the netblocks associated with China > (for example) .. is there any place that publishes an updated list of > what netblocks are used by what countries? (all of them) .. CIDR format > would be ideal. > > If it matters, I'm specifically interested APNIC and AFRNIC. I've found that ipdeny.com publishes an extensive and frequently-updated list of netblocks associated with about 225 countries. Also, see: http://www.okean.com/koreacidr.txt http://www.okean.com/chinacidr.txt for blocks for those two countries. I've not tried to make an assessment of which of these two resources is more accurate WRT cn and kr, but they do exhibit minor differences from time to time. ---Rsk From berg at wins.net Wed May 12 12:59:44 2010 From: berg at wins.net (Russell Berg) Date: Wed, 12 May 2010 12:59:44 -0500 Subject: 3G Network Internet Traffic Patterns? Message-ID: We have the opportunity to provide Internet connectivity to a newly forming 3G cellular provider in a mostly rural area. Our current wholesale ISP customer base is predominantly residential; our current peak traffic period is consistently between 8PM-10PM. Does anyone have traffic info or a graph showing peak times/traffic patterns for pure cellular networks? As you can imagine, we're interested in seeing if the peaks are coincident or not. TIA... Russell Berg Director - Product Development Airstream Communications Wisconsin Independent Network 800 Wisconsin Street, Suite 219 Building D02, Mailbox 107 Eau Claire, WI 54703 O: 715-832-3726 C: 715-579-8227 F: 715-832-3755 berg at wins.net www.wins.net From surfer at mauigateway.com Wed May 12 16:41:00 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 May 2010 14:41:00 -0700 Subject: BGP and convergence time Message-ID: <20100512144100.4C012F09@resin12.mta.everyone.net> --- danny at tcb.net wrote: From: Danny McPherson On May 12, 2010, at 9:40 AM, Jay Nakamura wrote: > I just tested this and, yes, with Cisco to Cisco, changing the setting > won't reset the connection but you have to reset the connection to > have the value take effect. I need to look up what happens when two > sides are set to different values and which one takes precedent. : The holdtime isn't technically negotiated, both sides convey their : value in the open message and the lower of the two is used by both : BGP speakers. This isn't a negotiation? : IIRC, neither J or C reset the session with the timer change, but the : new holdtimer expiry value doesn't take effect until then. We use Alcatel 7750s. Damn thing just resets the session; no warning, no nothing. :-( : One other thing to note is that by default, keepalive intervals in : those implementations are {holdtime/3}. Normally, if you're setting : holdtime to something really lower (e.g., 10 seconds) you might want : to increase the frequency of keepalives such that the probability of : getting one through in times of instability rise. In particular, : congestion incurred outside of BGP, as update messages themselves : will serve as implicit keepalives, and with the amount of churn in BGP, : empty updates (keepalives) are rare for most speakers with a global BGP : view. I have been looking for info on the negative impact on a router by increasing the keepalive frequency to a high rate. I'm sure it's minimal for a few BGP peers, but I could imagine with a lot of peers it's a non-zero impact. scott From surfer at mauigateway.com Wed May 12 16:30:04 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Wed, 12 May 2010 14:30:04 -0700 Subject: BGP and convergence time Message-ID: <20100512143004.4C0129BF@resin12.mta.everyone.net> --- matthew at walster.org wrote: From: Matthew Walster On 12 May 2010 02:36, Scott Weeks wrote: > You set the timers on your side and the two sides negotiate then select the lowest timer settings. The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that. Hold timers are negotiated in the OPEN message, I seem to remember, so surely you *have* to hard reset the connection to get the lower holdtime? -------------------------------------------------------- Of course you have to reset the session or it won't communicate the change, but what I wanted was to be able to soft-reset at my own convenience for the valuse to take effect. The routers we use just hard reset as soon as I typed the command. :-( scott From hugh at open.com.au Wed May 12 16:51:04 2010 From: hugh at open.com.au (Hugh Irvine) Date: Thu, 13 May 2010 07:51:04 +1000 Subject: Rugged wireless bridge In-Reply-To: <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> Message-ID: I've had the same problems with the WAP200E units - 3 DOA before getting two that worked. regards Hugh On 12 May 2010, at 02:02, Shane Short wrote: > I've had multiple issues with the WAP200E units in the field-- from the Internal PoE cabling being crushed and not working properly, to finding some of the internal antennas wern't even soldered to the PCB properly. > > I'd definitely +1 on the ubiquiti stuff. however, they've been extremely solid. > > > On 11/05/2010, at 11:30 PM, Curtis Maurand wrote: > >> On 5/11/2010 9:36 AM, Andrey Khomyakov wrote: >>> Hi all, >>> >>> I need to provide IP connectivity to an outdoor parking lot for security >>> devices like a camera, and emergency phone and a gate. Does anyone have any >>> suggestions on a wireless bridge and an outdoor rated switch if such exists? >>> How do people provide IP to outdoor locations like a surface parking lot? >>> >>> >> http://www.cisco.com/en/US/products/ps10050/index.html >> >> --Curtis > > NB: Have you read the reference manual ("doc/ref.html")? Have you searched the mailing list archive (www.open.com.au/archives/radiator)? Have you had a quick look on Google (www.google.com)? Have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. Includes support for reliable RADIUS transport (RadSec), and DIAMETER translation agent. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems. From swmike at swm.pp.se Wed May 12 17:24:43 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 13 May 2010 00:24:43 +0200 (CEST) Subject: 3G Network Internet Traffic Patterns? In-Reply-To: References: Message-ID: On Wed, 12 May 2010, Russell Berg wrote: > We have the opportunity to provide Internet connectivity to a newly > forming 3G cellular provider in a mostly rural area. Our current > wholesale ISP customer base is predominantly residential; our current > peak traffic period is consistently between 8PM-10PM. Does anyone have > traffic info or a graph showing peak times/traffic patterns for pure > cellular networks? As you can imagine, we're interested in seeing if the > peaks are coincident or not. TIA... There are a wide range of different cell providers with different customer bases, so this is impossible to answer. If you aim at "mobile broadband" users, then you'll get the peak in the evening just like your current peak, because it'll be similar users. If you aim at other groups of people, then you'll get different traffic patterns. -- Mikael Abrahamsson email: swmike at swm.pp.se From khomyakov.andrey at gmail.com Wed May 12 17:53:34 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Wed, 12 May 2010 18:53:34 -0400 Subject: Rugged wireless bridge In-Reply-To: References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> Message-ID: <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> Hi all again Thanks for all the links. Lots of wifi solutions. The main problem I'm facing is the fact that I need more than one copper ethernet connection at those outdoor locations. Meaning that I'll have at least two or three IP cameras (PoE desired) and a automatic security gate. So, I feel like some outdoor rated copper ethernet switches with PoE is the hardest part here. Anyone came across any 5-8 port PoE switches that can be put outdoors? thanks again From mike.lyon at gmail.com Wed May 12 18:00:20 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 12 May 2010 16:00:20 -0700 Subject: Rugged wireless bridge In-Reply-To: <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> Message-ID: Andrey, Some of the UBNT gear have two ethernet ports, some models pass PoE, some don't. What I would do is to get a switch with or without PoE, put them into a NEMA 4 enclosure. Then put water-proof ethernet feedthrough bushings on the enclosure. How many locations do you have to do this at? -Mike On Wed, May 12, 2010 at 3:53 PM, Andrey Khomyakov < khomyakov.andrey at gmail.com> wrote: > Hi all again > > Thanks for all the links. Lots of wifi solutions. The main problem I'm > facing is the fact that I need more than one copper ethernet connection at > those outdoor locations. Meaning that I'll have at least two or three IP > cameras (PoE desired) and a automatic security gate. So, I feel like some > outdoor rated copper ethernet switches with PoE is the hardest part here. > > Anyone came across any 5-8 port PoE switches that can be put outdoors? > > thanks again > From pete at altadena.net Wed May 12 18:03:42 2010 From: pete at altadena.net (Pete Carah) Date: Wed, 12 May 2010 19:03:42 -0400 Subject: Rugged wireless bridge In-Reply-To: <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> Message-ID: <4BEB33CE.80908@altadena.net> On 05/12/2010 06:53 PM, Andrey Khomyakov wrote: > Hi all again > > Thanks for all the links. Lots of wifi solutions. The main problem I'm facing is the fact that I need more than one copper ethernet connection at those outdoor locations. Meaning that I'll have at least two or three IP cameras (PoE desired) and a automatic security gate. So, I feel like some outdoor rated copper ethernet switches with PoE is the hardest part here. > > Anyone came across any 5-8 port PoE switches that can be put outdoors? > My friends all seem to be using ubiquiti wi-fi stuff lately. Somehow I've gotten on these guy's (paper catalog) mailing list. Not cheap, and I've never actually used them... Also there are other vendors in the industrial-electronics arena: http://www.bb-elec.com/ Don't know about their quality either, but in the industrial-electronics field one doesn't last long with bad stuff. -- Pete > thanks again > > From sethm at rollernet.us Wed May 12 18:04:20 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 12 May 2010 16:04:20 -0700 Subject: Rugged wireless bridge In-Reply-To: <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> Message-ID: <4BEB33F4.4010509@rollernet.us> On 5/12/2010 15:53, Andrey Khomyakov wrote: > Hi all again > > Thanks for all the links. Lots of wifi solutions. The main problem I'm facing is the fact that I need more than one copper ethernet connection at those outdoor locations. Meaning that I'll have at least two or three IP cameras (PoE desired) and a automatic security gate. So, I feel like some outdoor rated copper ethernet switches with PoE is the hardest part here. > > Anyone came across any 5-8 port PoE switches that can be put outdoors? > Like these? http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=90&Trail=1&TrailType=Top The EIRP305-T and EIRP610-2SFP-T have POE. ~Seth From mike.lyon at gmail.com Wed May 12 18:11:06 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Wed, 12 May 2010 16:11:06 -0700 Subject: Rugged wireless bridge In-Reply-To: <4BEB33F4.4010509@rollernet.us> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> Message-ID: Not sure how outdoor-worthy those guys are... -Mike On Wed, May 12, 2010 at 4:04 PM, Seth Mattinen wrote: > On 5/12/2010 15:53, Andrey Khomyakov wrote: > > Hi all again > > > > Thanks for all the links. Lots of wifi solutions. The main problem I'm > facing is the fact that I need more than one copper ethernet connection at > those outdoor locations. Meaning that I'll have at least two or three IP > cameras (PoE desired) and a automatic security gate. So, I feel like some > outdoor rated copper ethernet switches with PoE is the hardest part here. > > > > Anyone came across any 5-8 port PoE switches that can be put outdoors? > > > > Like these? > > > http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=90&Trail=1&TrailType=Top > > The EIRP305-T and EIRP610-2SFP-T have POE. > > ~Seth > > From khomyakov.andrey at gmail.com Wed May 12 18:19:16 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Wed, 12 May 2010 19:19:16 -0400 Subject: Rugged wireless bridge In-Reply-To: References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> Message-ID: <560757C9-176D-4AB9-BFD4-607CF72779DB@gmail.com> I got a two floor parking ram and a surface lot, so in a nut shell I have to do this twice. Two separate wifi links, two PoE switches 4-6 cameras at each location plus the entrance gates all IP enabled. Andrey On May 12, 2010, at 7:00 PM, Mike Lyon wrote: > Andrey, > > Some of the UBNT gear have two ethernet ports, some models pass PoE, some don't. > > What I would do is to get a switch with or without PoE, put them into a NEMA 4 enclosure. Then put water-proof ethernet feedthrough bushings on the enclosure. > > How many locations do you have to do this at? > > -Mike > > > On Wed, May 12, 2010 at 3:53 PM, Andrey Khomyakov wrote: > Hi all again > > Thanks for all the links. Lots of wifi solutions. The main problem I'm facing is the fact that I need more than one copper ethernet connection at those outdoor locations. Meaning that I'll have at least two or three IP cameras (PoE desired) and a automatic security gate. So, I feel like some outdoor rated copper ethernet switches with PoE is the hardest part here. > > Anyone came across any 5-8 port PoE switches that can be put outdoors? > > thanks again > From sethm at rollernet.us Wed May 12 18:22:50 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 12 May 2010 16:22:50 -0700 Subject: Rugged wireless bridge In-Reply-To: References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> Message-ID: <4BEB384A.1090601@rollernet.us> On 5/12/2010 16:11, Mike Lyon wrote: > Not sure how outdoor-worthy those guys are... > Put them in a box. ~Seth From khomyakov.andrey at gmail.com Wed May 12 18:23:24 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Wed, 12 May 2010 19:23:24 -0400 Subject: Rugged wireless bridge In-Reply-To: References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> Message-ID: <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> I found this sucker so far, I guess it has to be waterproof rather than just rugged. http://www.korenixsecurity.com/products/weatherproof-ethernet-switch/jetnet-3706-rj On May 12, 2010, at 7:11 PM, Mike Lyon wrote: > Not sure how outdoor-worthy those guys are... > > -Mike > > > On Wed, May 12, 2010 at 4:04 PM, Seth Mattinen wrote: > >> On 5/12/2010 15:53, Andrey Khomyakov wrote: >>> Hi all again >>> >>> Thanks for all the links. Lots of wifi solutions. The main problem I'm >> facing is the fact that I need more than one copper ethernet connection at >> those outdoor locations. Meaning that I'll have at least two or three IP >> cameras (PoE desired) and a automatic security gate. So, I feel like some >> outdoor rated copper ethernet switches with PoE is the hardest part here. >>> >>> Anyone came across any 5-8 port PoE switches that can be put outdoors? >>> >> >> Like these? >> >> >> http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=90&Trail=1&TrailType=Top >> >> The EIRP305-T and EIRP610-2SFP-T have POE. >> >> ~Seth >> >> From pete at altadena.net Wed May 12 19:30:19 2010 From: pete at altadena.net (Pete Carah) Date: Wed, 12 May 2010 20:30:19 -0400 Subject: Rugged wireless bridge In-Reply-To: <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> Message-ID: <4BEB481B.1050004@altadena.net> On 05/12/2010 07:23 PM, Andrey Khomyakov wrote: > I found this sucker so far, I guess it has to be waterproof rather than just rugged. > > http://www.korenixsecurity.com/products/weatherproof-ethernet-switch/jetnet-3706-rj > > > And, http://www.sixnet.com/product/8-port-ip67-ethernet-managed-unmanaged-switch-116.cfm I bet it isn't cheap... And I don't know where you get the connectors, either. -- Pete > On May 12, 2010, at 7:11 PM, Mike Lyon wrote: > > >> Not sure how outdoor-worthy those guys are... >> >> -Mike >> >> >> On Wed, May 12, 2010 at 4:04 PM, Seth Mattinen wrote: >> >> >>> On 5/12/2010 15:53, Andrey Khomyakov wrote: >>> >>>> Hi all again >>>> >>>> Thanks for all the links. Lots of wifi solutions. The main problem I'm >>>> >>> facing is the fact that I need more than one copper ethernet connection at >>> those outdoor locations. Meaning that I'll have at least two or three IP >>> cameras (PoE desired) and a automatic security gate. So, I feel like some >>> outdoor rated copper ethernet switches with PoE is the hardest part here. >>> >>>> Anyone came across any 5-8 port PoE switches that can be put outdoors? >>>> >>>> >>> Like these? >>> >>> >>> http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=90&Trail=1&TrailType=Top >>> >>> The EIRP305-T and EIRP610-2SFP-T have POE. >>> >>> ~Seth >>> >>> >>> > > > From pete at altadena.net Wed May 12 19:40:48 2010 From: pete at altadena.net (Pete Carah) Date: Wed, 12 May 2010 20:40:48 -0400 Subject: Rugged wireless bridge In-Reply-To: <4BEB481B.1050004@altadena.net> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> <4BEB481B.1050004@altadena.net> Message-ID: <4BEB4A90.9050806@altadena.net> On 05/12/2010 08:30 PM, Pete Carah wrote: > On 05/12/2010 07:23 PM, Andrey Khomyakov wrote: > >> I found this sucker so far, I guess it has to be waterproof rather than just rugged. >> >> http://www.korenixsecurity.com/products/weatherproof-ethernet-switch/jetnet-3706-rj >> >> >> >> > And, > http://www.sixnet.com/product/8-port-ip67-ethernet-managed-unmanaged-switch-116.cfm > > I bet it isn't cheap... And I don't know where you get the connectors, > either. > > -- Pete And: http://www.weidmuller.com/ethernet/ip67switches Note that Digikey sells IP67 RJ45's (don't know whose) for only $7 each... I'm afraid to ask about the mil ones from sixnet... -- Pete From jeroen at mompl.net Wed May 12 20:10:06 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 12 May 2010 18:10:06 -0700 Subject: BGP (in)security makes the AP wire In-Reply-To: References: <308599F2-201F-4C34-862B-4E4B6BF4C875@cs.columbia.edu> <4BE87D01.7010107@mompl.net> Message-ID: <4BEB516E.2030905@mompl.net> Randy Bush wrote: > except we have a history of it happening You mean the whole innertubes went down because some dewd haxx0red it? I believe that was the claim being made in so many words (maybe he was just trying to land that DARPA job). It's one thing for parts of the innertubes to go down, but the whole thing? -- http://goldmark.org/jeff/stupid-disclaimers/ From ras at e-gerbil.net Wed May 12 20:45:42 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 12 May 2010 20:45:42 -0500 Subject: BGP and convergence time In-Reply-To: References: <20100511183657.4C01B60D@resin12.mta.everyone.net> Message-ID: <20100513014542.GK1261@gerbil.cluepon.net> On Wed, May 12, 2010 at 09:52:48AM -0600, Danny McPherson wrote: > > The holdtime isn't technically negotiated, both sides convey their > value in the open message and the lower of the two is used by both BGP > speakers. IIRC, neither J or C reset the session with the timer > change, but the new holdtimer expiry value doesn't take effect until > then. Rest assured J will always reset the session if given given half a chance, and changing your holdtime is more than half. :) One thing I find interesting is that most other protocols will err on the side of caution and use the higher of two values like this when negotiating between two parties, but BGP does the opposite. I still run into bad bgp implementations which can't keep up with my 30 sec hold timers all the time *coughghettoequinixrouteservercough*. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From hrlinneweh at sbcglobal.net Thu May 13 04:21:30 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 13 May 2010 02:21:30 -0700 (PDT) Subject: Rugged wireless bridge In-Reply-To: <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> References: <4BE97829.3030203@xyonet.com> <28A45678-D7A5-4F0B-BCF4-E8BC97966A15@short.id.au> <954D12F6-EBA6-4FE3-8B52-7A642FB1340A@gmail.com> <4BEB33F4.4010509@rollernet.us> <79895EA9-DD4B-4D3E-99E1-603B8B332B17@gmail.com> Message-ID: <466163.10230.qm@web180312.mail.gq1.yahoo.com> Blackbox also has some offerings in this area, made to order http://www.blackbox.com/solutions/infrastructure/Wireless-Bridges.aspx -henry ________________________________ From: Andrey Khomyakov To: Nanog Sent: Wed, May 12, 2010 4:23:24 PM Subject: Re: Rugged wireless bridge I found this sucker so far, I guess it has to be waterproof rather than just rugged. http://www.korenixsecurity.com/products/weatherproof-ethernet-switch/jetnet-3706-rj On May 12, 2010, at 7:11 PM, Mike Lyon wrote: > Not sure how outdoor-worthy those guys are... > > -Mike > > > On Wed, May 12, 2010 at 4:04 PM, Seth Mattinen wrote: > >> On 5/12/2010 15:53, Andrey Khomyakov wrote: >>> Hi all again >>> >>> Thanks for all the links. Lots of wifi solutions. The main problem I'm >> facing is the fact that I need more than one copper ethernet connection at >> those outdoor locations. Meaning that I'll have at least two or three IP >> cameras (PoE desired) and a automatic security gate. So, I feel like some >> outdoor rated copper ethernet switches with PoE is the hardest part here. >>> >>> Anyone came across any 5-8 port PoE switches that can be put outdoors? >>> >> >> Like these? >> >> >> http://www.bb-elec.com/product_multi_family.asp?MultiFamilyId=90&Trail=1&TrailType=Top >> >> The EIRP305-T and EIRP610-2SFP-T have POE. >> >> ~Seth >> >> From randy at psg.com Thu May 13 10:16:33 2010 From: randy at psg.com (Randy Bush) Date: Thu, 13 May 2010 17:16:33 +0200 Subject: whois.rpki.net Message-ID: ruediger-style pseudo irr route: objects from the rpki testbed are available from whois.rpki.net rmac.psg.com:/Users/randy> whois -h whois.rpki.net 98.128.0.0/16 route: 98.128.0.0/16 descr: 98.128.0.0/16-24 origin: AS3130 notify: irr-hack at rpki.net mnt-by: MAINT-RPKI changed: irr-hack at rpki.net 20100323 source: RPKI this gives testbed players an easy way to see the state of their valid roas, as well as providing a path for using the rpki as an irr overlay (credit to ruediger). randy From dmm at 1-4-5.net Thu May 13 10:18:49 2010 From: dmm at 1-4-5.net (David Meyer) Date: Thu, 13 May 2010 08:18:49 -0700 Subject: [NANOG-announce] Draft NANOG 49 program available! Message-ID: <20100513151849.GA15415@1-4-5.net> Please see http://www.nanog.org/meetings/nanog49/agenda.php. A few dates of interest: (i). The registration fee increases on May 17. (ii). The special group rate at the hotel expires May 24. We're looking forward to seeing you all in San Francisco. Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From caleb.tennis at gmail.com Thu May 13 10:36:35 2010 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Thu, 13 May 2010 11:36:35 -0400 Subject: POE switches and lightning Message-ID: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? From MatlockK at exempla.org Thu May 13 10:50:54 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Thu, 13 May 2010 09:50:54 -0600 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2AB2@LMC-MAIL2.exempla.org> My first guess would be the lightning was close enough/powerful enough, to send out an EM Pulse which got picked up by the copper going to the devices. This EM Pulse may have been interpreted at the switchport as the device relinquishing power? Had you tried just unplugging one of the devices from Ethernet, and plugging it back in to reset the PoE exchange? Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Caleb Tennis [mailto:caleb.tennis at gmail.com] Sent: Thursday, May 13, 2010 9:37 AM To: North American Network Operators Group Subject: POE switches and lightning We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? From LarrySheldon at cox.net Thu May 13 11:19:11 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 13 May 2010 11:19:11 -0500 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <4BEC267F.9040909@cox.net> On 5/13/2010 10:36, Caleb Tennis wrote: > We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. > > What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. > > I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? I don't know how to account for this in a PoE world, but when I last managed a campus network, we had major issues (particularly in an active-thunder-storm environment) of severe difference in ground-potential between buildings. The only way we could survive was to connect buildings (including free-standing kiosks) with their own "grounds" using glass. Does anybody make a CAT 5 1-to-1 isolation transformer? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From pete at altadena.net Thu May 13 11:39:10 2010 From: pete at altadena.net (Pete Carah) Date: Thu, 13 May 2010 12:39:10 -0400 Subject: POE switches and lightning In-Reply-To: <4BEC267F.9040909@cox.net> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <4BEC267F.9040909@cox.net> Message-ID: <4BEC2B2E.4030501@altadena.net> On 05/13/2010 12:19 PM, Larry Sheldon wrote: > On 5/13/2010 10:36, Caleb Tennis wrote: > >> We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. >> >> What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. >> >> I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? >> > > I don't know how to account for this in a PoE world, but when I last > managed a campus network, we had major issues (particularly in an > active-thunder-storm environment) of severe difference in > ground-potential between buildings. > Cat 5 has isolation transformers in or just behind each jack. However, in most equipment the grounds aren't really isolated, and in the case of POE they (mostly) aren't at all. Lightning likes to do "interesting" things. It can induce a 20kv per few feet gradient (or more) across the ground mesh of a power substation (like 4/0 wire in a mesh of 4 foot squares or so; normally more complicated than that since it has to clear equipment etc...). It likes to eat power supplies in well-grounded equipment and leave cheaper stuff alone. It can hit an antenna, leave the receiver completely intact, and fry the power supply of the next box over. We tended to lose either fluorescent ballasts or the thermostat transformer in our furnace when I lived in an active ham's house in Alabama, the radios tended to live. (you should have seen his coax entry panel (1/4 inch copper sheet, grounded outside)), and stuff got manually disconnected from both antennas and power when a storm was expected (every afternoon :-). It wouldn't surprise me if the first answer was right and either the ground pulse or EMP reset the safety switches in the POE feeders. -- Pete From dts at senie.com Thu May 13 13:24:04 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 13 May 2010 14:24:04 -0400 Subject: POE switches and lightning In-Reply-To: <4BEC2B2E.4030501@altadena.net> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <4BEC267F.9040909@cox.net> <4BEC2B2E.4030501@altadena.net> Message-ID: While the equipment may well be affected by an EM pulse, if the gear returns to normal after a power cycle, then the equipment vendor didn't do their job fully developing the product. A product should be tested to take such pulses and should recover provided it has not suffered a catastrophic failure (and in fact it should contain sufficient protection to avoid such in most cases). In working on one particular router in the lab some years ago, I was verifying some software functionality and the hardware engineer I was working with reached over my shoulder and used a device that delivered a high voltage spike (simulated lightning) to a 10BaseT network port. After I peeled myself off the ceiling (and he stopped laughing), we set to work figuring out how to get the device to self-reset after such a strike. One component, an Ethernet hub chip, got into a confused state. I was able to detect this in software, so we adjusted the product design so that the software could yank the hub chip's reset line. It's unfortunate that products, both hardware and software, receive minimal quality testing these days. Guess it's not a surprise, since buyers seemed to prefer products that were quick to market, with lots of bugs, rather than reliability and resilience. On May 13, 2010, at 12:39 PM, Pete Carah wrote: > On 05/13/2010 12:19 PM, Larry Sheldon wrote: >> On 5/13/2010 10:36, Caleb Tennis wrote: >> >>> We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. >>> >>> What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. >>> >>> I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? >>> >> >> I don't know how to account for this in a PoE world, but when I last >> managed a campus network, we had major issues (particularly in an >> active-thunder-storm environment) of severe difference in >> ground-potential between buildings. >> > Cat 5 has isolation transformers in or just behind each jack. However, > in most equipment the grounds aren't really isolated, and in the case of > POE they (mostly) aren't at all. > > Lightning likes to do "interesting" things. It can induce a 20kv per > few feet gradient (or more) across the ground mesh of a power substation > (like 4/0 wire in a mesh of 4 foot squares or so; normally more > complicated than that since it has to clear equipment etc...). It likes > to eat power supplies in well-grounded equipment and leave cheaper stuff > alone. It can hit an antenna, leave the receiver completely intact, and > fry the power supply of the next box over. We tended to lose either > fluorescent ballasts or the thermostat transformer in our furnace when I > lived in an active ham's house in Alabama, the radios tended to live. > (you should have seen his coax entry panel (1/4 inch copper sheet, > grounded outside)), and stuff got manually disconnected from both > antennas and power when a storm was expected (every afternoon :-). > > It wouldn't surprise me if the first answer was right and either the > ground pulse or EMP reset the safety switches in the POE feeders. > > -- Pete > From mark.mayfield at metro-inet.us Thu May 13 13:26:10 2010 From: mark.mayfield at metro-inet.us (Mark Mayfield) Date: Thu, 13 May 2010 13:26:10 -0500 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> About a month ago, we had a lightning strike near our main campus. We lost one POE Cisco 3560 completely (apparently blown power supply), and in a separate but nearby building, another 3560 lost the ability to deliver POE, but continued to operate as a switch. Both had to be replaced. Both were on wiring closet type UPS'es with surge suppression, and those were unaffected. Mark -----Original Message----- From: Caleb Tennis [mailto:caleb.tennis at gmail.com] Sent: Thursday, May 13, 2010 10:37 AM To: North American Network Operators Group Subject: POE switches and lightning We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? Confidentiality Statement: The documents accompanying this transmission contain confidential information that is legally privileged. This information is intended only for the use of the individuals or entities listed above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of these documents is strictly prohibited. If you have received this information in error, please notify the sender immediately and arrange for the return or destruction of these documents. From paul at telcodata.us Thu May 13 13:45:30 2010 From: paul at telcodata.us (Paul Timmins) Date: Thu, 13 May 2010 14:45:30 -0400 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <4BEC48CA.8020506@telcodata.us> Caleb Tennis wrote: > We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. > > What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. > > I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? I use these on any cable that leaves my building. http://www.amazon.com/APC-PNET1GB-ProtectNet-Standalone-Protector/dp/B000BKUSS8 It seems to play well with PoE (I put mine before the injector), and also works well with T1s and POTS. -Paul From smb at cs.columbia.edu Thu May 13 13:52:19 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 13 May 2010 14:52:19 -0400 Subject: POE switches and lightning In-Reply-To: References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <4BEC267F.9040909@cox.net> <4BEC2B2E.4030501@altadena.net> Message-ID: <3DE5C54E-EE1D-4234-ACF4-22225637F729@cs.columbia.edu> On May 13, 2010, at 2:24 04PM, Daniel Senie wrote: > While the equipment may well be affected by an EM pulse, if the gear returns to normal after a power cycle, then the equipment vendor didn't do their job fully developing the product. A product should be tested to take such pulses and should recover provided it has not suffered a catastrophic failure (and in fact it should contain sufficient protection to avoid such in most cases). > > In working on one particular router in the lab some years ago, I was verifying some software functionality and the hardware engineer I was working with reached over my shoulder and used a device that delivered a high voltage spike (simulated lightning) to a 10BaseT network port. After I peeled myself off the ceiling (and he stopped laughing), we set to work figuring out how to get the device to self-reset after such a strike. One component, an Ethernet hub chip, got into a confused state. I was able to detect this in software, so we adjusted the product design so that the software could yank the hub chip's reset line. > > It's unfortunate that products, both hardware and software, receive minimal quality testing these days. Guess it's not a surprise, since buyers seemed to prefer products that were quick to market, with lots of bugs, rather than reliability and resilience. > It's not just a matter of "these days" -- lightning is awfully hard to deal with, because of how quirky the real-world behavior can be. I had to deal with this a lot in the 1970s on RS-232 lines -- we could never predict what would get fried. Of course, there was also a ground strikes very near my apartment, where the induced current tripped a circuit breaker, blew out a couple of lightbulbs, and and came in through the cable TV line to fry the cable box, fry the impedance-matching transformer, and fry the RF input stage on the television... --Steve Bellovin, http://www.cs.columbia.edu/~smb From pete at altadena.net Thu May 13 15:12:06 2010 From: pete at altadena.net (Pete Carah) Date: Thu, 13 May 2010 16:12:06 -0400 Subject: POE switches and lightning In-Reply-To: <3DE5C54E-EE1D-4234-ACF4-22225637F729@cs.columbia.edu> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <4BEC267F.9040909@cox.net> <4BEC2B2E.4030501@altadena.net> <3DE5C54E-EE1D-4234-ACF4-22225637F729@cs.columbia.edu> Message-ID: <4BEC5D16.1070003@altadena.net> On 05/13/2010 02:52 PM, Steven Bellovin wrote: > On May 13, 2010, at 2:24 04PM, Daniel Senie wrote: > > >> While the equipment may well be affected by an EM pulse, if the gear returns to normal after a power cycle, then the equipment vendor didn't do their job fully developing the product. A product should be tested to take such pulses and should recover provided it has not suffered a catastrophic failure (and in fact it should contain sufficient protection to avoid such in most cases). >> >> In working on one particular router in the lab some years ago, I was verifying some software functionality and the hardware engineer I was working with reached over my shoulder and used a device that delivered a high voltage spike (simulated lightning) to a 10BaseT network port. After I peeled myself off the ceiling (and he stopped laughing), we set to work figuring out how to get the device to self-reset after such a strike. One component, an Ethernet hub chip, got into a confused state. I was able to detect this in software, so we adjusted the product design so that the software could yank the hub chip's reset line. >> Luck. I've needed that kind of reset a few times... >> It's unfortunate that products, both hardware and software, receive minimal quality testing these days. Guess it's not a surprise, since buyers seemed to prefer products that were quick to market, with lots of bugs, rather than reliability and resilience. >> That is certainly true (and not entirely modern; you can read about that problem in old roman literature. When was "Zen and the art of motorcycle maintainance" written? - 1970's); however it is nearly impossible to protect well against close-by lightning. >> > It's not just a matter of "these days" -- lightning is awfully hard to deal with, because of how quirky the real-world behavior can be. I had to deal with this a lot in the 1970s on RS-232 lines -- we could never predict what would get fried. Of course, there was also a ground strikes very near my apartment, where the induced current tripped a circuit breaker, blew out a couple of lightbulbs, and and came in through the cable TV line to fry the cable box, fry the impedance-matching transformer, and fry the RF input stage on the television... > I can second Steve in spades; I used to work for the power company in Alabama... There you learn a LOT more than you ever wanted to know about lightning. Consider that one hit can destroy the inside of a >10Mw 66kv->12kv distribution transformer (I actually saw the strike involved; it was less than a mile from my apartment at the time, and dropped power to me; the apt was fed from an entirely different company... My power came back in a few minutes; the other load took almost a week (they had a redundant feed; it was a hospital, but they ran in a low-power mode till a BIG crane and big lo-boy truck came with another transformer)); how are you going to protect any computer from *that*... -- Pete > --Steve Bellovin, http://www.cs.columbia.edu/~smb > > > > > > > > From mcourtney at wlu.edu Thu May 13 16:23:13 2010 From: mcourtney at wlu.edu (Courtney, Mike) Date: Thu, 13 May 2010 17:23:13 -0400 Subject: Dark fiber / transport in Virginia Message-ID: All, I am interested in finding out about dark fiber / transport resources along I-81 or I-64 in the western part of Virginia. I?d like to find a transport provider that could connect to a ?meet me? room in either Roanoke, Charlottesville, Richmond, DC, or even Charleston, WV. I?m trying to price out alternatives to the telco transport and data delivery model and I?m new to the Virginia market. Thanks for any help that you can offer! -Mike From gladney at stsci.edu Thu May 13 16:28:28 2010 From: gladney at stsci.edu (Gary Gladney) Date: Thu, 13 May 2010 17:28:28 -0400 Subject: Dark fiber / transport in Virginia In-Reply-To: References: Message-ID: <009a01caf2e3$3a86ef20$af94cd60$@edu> You might try the cable operator Charter.com, I think believe they operate in that area. Gary -----Original Message----- From: Courtney, Mike [mailto:mcourtney at wlu.edu] Sent: Thursday, May 13, 2010 5:23 PM To: nanog at nanog.org Subject: Dark fiber / transport in Virginia All, I am interested in finding out about dark fiber / transport resources along I-81 or I-64 in the western part of Virginia. I'd like to find a transport provider that could connect to a "meet me" room in either Roanoke, Charlottesville, Richmond, DC, or even Charleston, WV. I'm trying to price out alternatives to the telco transport and data delivery model and I'm new to the Virginia market. Thanks for any help that you can offer! -Mike From mehmet at icann.org Thu May 13 17:04:04 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Thu, 13 May 2010 15:04:04 -0700 Subject: Dark fiber / transport in Virginia In-Reply-To: Message-ID: Abovenet/Verizon has fibers in those paths. mehmet On 5/13/10 2:23 PM, "Courtney, Mike" wrote: > All, > > I am interested in finding out about dark fiber / transport resources along > I-81 or I-64 in the western part of Virginia. I?d like to find a transport > provider that could connect to a ?meet me? room in either Roanoke, > Charlottesville, Richmond, DC, or even Charleston, WV. I?m trying to price out > alternatives to the telco transport and data delivery model and I?m new to the > Virginia market. > > Thanks for any help that you can offer! > > -Mike From mulitskiy at acedsl.com Thu May 13 17:18:12 2010 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Thu, 13 May 2010 18:18:12 -0400 Subject: ipv6 transit over tunneled connection Message-ID: <201005131818.12316.mulitskiy@acedsl.com> Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? Thanks, Michael From jack at crepinc.com Thu May 13 17:41:14 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Thu, 13 May 2010 18:41:14 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <201005131818.12316.mulitskiy@acedsl.com> References: <201005131818.12316.mulitskiy@acedsl.com> Message-ID: Occaid will generally transit you via two tunnels to their endpoints. I used them for a year with zero issues in addition to an HE tunnel. -Jack Carrozzo On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - > learning/labbing/experimenting/etc. > We've got to the point when we're also planning to request initial ipv6 > allocation from ARIN. > So I wonder what ipv6 transit options I have if my upstreams do not support > native ipv6 connectivity? > I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? > Either free or commercial? > Thanks, > > Michael > > From matt.shadbolt at gmail.com Thu May 13 19:09:49 2010 From: matt.shadbolt at gmail.com (Matt Shadbolt) Date: Fri, 14 May 2010 10:09:49 +1000 Subject: Abbott dumps NBN from budget reply Message-ID: Did anyone hear about this? Describing the National Broadband Network as a $43 billion "white elephant", > he confirmed the Coalition would not go ahead with the program Prime Minster > Kevin Rudd argues will deliver faster internet speeds across the country. > http://www.theaustralian.com.au/in-depth/budget/tony-abbott-would-slash-public-service-budget-reply/story-e6frgd66-1225866272354 So, vote for an internet filter or vote for no NBN? Matt. From matt.shadbolt at gmail.com Thu May 13 19:11:01 2010 From: matt.shadbolt at gmail.com (Matt Shadbolt) Date: Fri, 14 May 2010 10:11:01 +1000 Subject: Abbott dumps NBN from budget reply In-Reply-To: References: Message-ID: Sorry guys - meant to send this to AusNOG. Matt On Fri, May 14, 2010 at 10:09 AM, Matt Shadbolt wrote: > Did anyone hear about this? > > Describing the National Broadband Network as a $43 billion "white >> elephant", he confirmed the Coalition would not go ahead with the program >> Prime Minster Kevin Rudd argues will deliver faster internet speeds across >> the country. >> > > > http://www.theaustralian.com.au/in-depth/budget/tony-abbott-would-slash-public-service-budget-reply/story-e6frgd66-1225866272354 > > So, vote for an internet filter or vote for no NBN? > > Matt. > From morrowc.lists at gmail.com Thu May 13 20:39:28 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 13 May 2010 21:39:28 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <201005131818.12316.mulitskiy@acedsl.com> References: <201005131818.12316.mulitskiy@acedsl.com> Message-ID: On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. > We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. > So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? > I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris > Thanks, > > Michael > > From frnkblk at iname.com Thu May 13 21:28:13 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 13 May 2010 21:28:13 -0500 Subject: BGP and convergence time In-Reply-To: References: Message-ID: What about IP SLA with some EEM? This link may give you some ideas: http://blog.ioshints.info/2008/01/ospf-default-route-based-on-ip-sla.html Frank -----Original Message----- From: Jay Nakamura [mailto:zeusdadog at gmail.com] Sent: Tuesday, May 11, 2010 1:35 PM To: NANOG Subject: BGP and convergence time So, we have two upstreams, both coming in on Ethernet. One of our switch crashed and rebooted itself. Although we have other paths to egress out the network, because the router's Ethernet interface didn't go down, our router's BGP didn't realize the neighbor was down until default BGP timeout was reached. Our upstream connectivity was out for couple minutes. I am looking for ways to detect neighbor being down faster so traffic can be re-routed faster. I can do BFD internally but the issue is how the upstream is going to detect the outage and stop routing our traffic to that downed link. I have asked both of my upstreams and one said they don't do anything like that, second upstream I am still waiting on the answer. My question is, do other carriers do BFD or any other means to detect the neighbor being down faster than normal BGP will allow? (Both upstreams are major telcos [AT&T and Qwest], so I think they are less flexible than some others.) Or, has anyone succeeded in getting something done with those two carriers? Thanks! From frnkblk at iname.com Thu May 13 21:43:56 2010 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 13 May 2010 21:43:56 -0500 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <4BE97CF7.4030008@xyonet.com> References: <20100511150816.GB72680@ussenterprise.ufp.org> <4BE97CF7.4030008@xyonet.com> Message-ID: Thirty percent? If "no access" includes financial means or developed interest, that may be true, but 99% of all zip codes have at least person with internet access. And the FCC has stated that "95 percent of Americans, or 290 million people, have terrestrial broadband access" http://blog.zcorum.com/2010/03/national-broadband-plan-the-debate-begins/. Frank -----Original Message----- From: Curtis Maurand [mailto:cmaurand at xyonet.com] Sent: Tuesday, May 11, 2010 10:51 AM To: nanog at nanog.org Subject: Re: Dial Concentrators - TNT / APX8000 R.I.P. 30% of all people in the US (110 million) have no access to broadband. Large areas of my state have no access to broadband because its rural (Maine). Aastra CVX (it used to be a Nortel product.) --Curtis On 5/11/2010 11:29 AM, Joe Abley wrote: > On 2010-05-11, at 11:08, Leo Bicknell wrote: > > >> There comes a time when the old tech just doesn't make sense, even >> if a small customer base still wants it. >> > There will also no doubt continue to be many customers for whom dial is the only option. > > It's not long ago that I lived in such a house, deceptively close to the outskirts of town but in terms of wire distance and load coils it might as well have been on the moon. The house was in a wireless dead zone by a river, there was no cable, and the only line of sight to another structure was through several acres of 2.4GHz-absorbing trees. > > The further you move away from urban centres, the easier it is to find examples of this. > > > Joe > From joelja at bogus.com Thu May 13 22:13:23 2010 From: joelja at bogus.com (joel jaeggli) Date: Thu, 13 May 2010 20:13:23 -0700 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: References: <20100511150816.GB72680@ussenterprise.ufp.org> <4BE97CF7.4030008@xyonet.com> Message-ID: <4BECBFD3.5010209@bogus.com> On 2010-05-13 19:43, Frank Bulk wrote: > Thirty percent? If "no access" includes financial means or developed > interest, that may be true, but 99% of all zip codes have at least person > with internet access. And the FCC has stated that "95 percent of Americans, > or 290 million people, have terrestrial broadband access" > http://blog.zcorum.com/2010/03/national-broadband-plan-the-debate-begins/. > > Frank > > -----Original Message----- > From: Curtis Maurand [mailto:cmaurand at xyonet.com] > Sent: Tuesday, May 11, 2010 10:51 AM > To: nanog at nanog.org > Subject: Re: Dial Concentrators - TNT / APX8000 R.I.P. > > > 30% of all people in the US (110 million) have no access to broadband. > Large areas of my state have no access to broadband because its rural > (Maine). The rural population represented 20.7% of the us population in the 2000 census. about 70% of the US population is concentrated in about 2% of the land area. > Aastra CVX (it used to be a Nortel product.) > > --Curtis > > On 5/11/2010 11:29 AM, Joe Abley wrote: >> On 2010-05-11, at 11:08, Leo Bicknell wrote: >> >> >>> There comes a time when the old tech just doesn't make sense, even >>> if a small customer base still wants it. >>> >> There will also no doubt continue to be many customers for whom dial is > the only option. >> >> It's not long ago that I lived in such a house, deceptively close to the > outskirts of town but in terms of wire distance and load coils it might as > well have been on the moon. The house was in a wireless dead zone by a > river, there was no cable, and the only line of sight to another structure > was through several acres of 2.4GHz-absorbing trees. >> >> The further you move away from urban centres, the easier it is to find > examples of this. >> >> >> Joe >> > > > > From randy at psg.com Fri May 14 02:59:33 2010 From: randy at psg.com (Randy Bush) Date: Fri, 14 May 2010 09:59:33 +0200 Subject: nyc glass Message-ID: anyone have reccos for fiber from 60 hudson to 454 broadway thanks randy From joly at punkcast.com Fri May 14 04:14:17 2010 From: joly at punkcast.com (Joly MacFie) Date: Fri, 14 May 2010 05:14:17 -0400 Subject: nyc glass In-Reply-To: References: Message-ID: Surely 32 Ave of the Americas would be closer? j On Fri, May 14, 2010 at 3:59 AM, Randy Bush wrote: > anyone have reccos for fiber > ?from 60 hudson > ?to ? 454 broadway > > thanks > > randy > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From ssrigha at gmail.com Fri May 14 07:46:17 2010 From: ssrigha at gmail.com (shake righa) Date: Fri, 14 May 2010 15:46:17 +0300 Subject: BGP and convergence time In-Reply-To: References: Message-ID: Believe have narrowed down problem to layer 2. A ping to address 224.0.0.5 shows no reply. Believe problme to do with blocking of multicast Regards, Shake On Fri, May 14, 2010 at 5:28 AM, Frank Bulk wrote: > What about IP SLA with some EEM? This link may give you some ideas: > http://blog.ioshints.info/2008/01/ospf-default-route-based-on-ip-sla.html > > Frank > > -----Original Message----- > From: Jay Nakamura [mailto:zeusdadog at gmail.com] > Sent: Tuesday, May 11, 2010 1:35 PM > To: NANOG > Subject: BGP and convergence time > > So, we have two upstreams, both coming in on Ethernet. One of our > switch crashed and rebooted itself. Although we have other paths to > egress out the network, because the router's Ethernet interface didn't > go down, our router's BGP didn't realize the neighbor was down until > default BGP timeout was reached. Our upstream connectivity was out > for couple minutes. > > I am looking for ways to detect neighbor being down faster so traffic > can be re-routed faster. I can do BFD internally but the issue is how > the upstream is going to detect the outage and stop routing our > traffic to that downed link. I have asked both of my upstreams and > one said they don't do anything like that, second upstream I am still > waiting on the answer. > > My question is, do other carriers do BFD or any other means to detect > the neighbor being down faster than normal BGP will allow? (Both > upstreams are major telcos [AT&T and Qwest], so I think they are less > flexible than some others.) > > Or, has anyone succeeded in getting something done with those two carriers? > > Thanks! > > > > From ssrigha at gmail.com Fri May 14 07:54:01 2010 From: ssrigha at gmail.com (shake righa) Date: Fri, 14 May 2010 15:54:01 +0300 Subject: BGP and convergence time In-Reply-To: References: Message-ID: Apologies, kindly ignore my earlier responce. Rgrds, Shake On Fri, May 14, 2010 at 3:46 PM, shake righa wrote: > Believe have narrowed down problem to layer 2. > > A ping to address 224.0.0.5 shows no reply. > > Believe problme to do with blocking of multicast > > Regards, > Shake > > On Fri, May 14, 2010 at 5:28 AM, Frank Bulk wrote: > >> What about IP SLA with some EEM? This link may give you some ideas: >> http://blog.ioshints.info/2008/01/ospf-default-route-based-on-ip-sla.html >> >> Frank >> >> -----Original Message----- >> From: Jay Nakamura [mailto:zeusdadog at gmail.com] >> Sent: Tuesday, May 11, 2010 1:35 PM >> To: NANOG >> Subject: BGP and convergence time >> >> So, we have two upstreams, both coming in on Ethernet. One of our >> switch crashed and rebooted itself. Although we have other paths to >> egress out the network, because the router's Ethernet interface didn't >> go down, our router's BGP didn't realize the neighbor was down until >> default BGP timeout was reached. Our upstream connectivity was out >> for couple minutes. >> >> I am looking for ways to detect neighbor being down faster so traffic >> can be re-routed faster. I can do BFD internally but the issue is how >> the upstream is going to detect the outage and stop routing our >> traffic to that downed link. I have asked both of my upstreams and >> one said they don't do anything like that, second upstream I am still >> waiting on the answer. >> >> My question is, do other carriers do BFD or any other means to detect >> the neighbor being down faster than normal BGP will allow? (Both >> upstreams are major telcos [AT&T and Qwest], so I think they are less >> flexible than some others.) >> >> Or, has anyone succeeded in getting something done with those two >> carriers? >> >> Thanks! >> >> >> >> > From asr+nanog at latency.net Fri May 14 12:04:54 2010 From: asr+nanog at latency.net (Adam Rothschild) Date: Fri, 14 May 2010 13:04:54 -0400 Subject: nyc glass In-Reply-To: References: Message-ID: <20100514170453.GA71926@latency.net> On 2010-05-14-03:59:33, Randy Bush wrote: > anyone have reccos for fiber > from 60 hudson > to 454 broadway >From a cursory look at POP and GIS data not covered by NDA, I'm not finding any vendors currently built into 454 Broadway. The usual suspects for dark in the area include AboveNet, Lightower, and Lexent (Hugh O'Kane), all amenable to build jobs for the right opportunity... HTH, -a From brandon.galbraith at gmail.com Fri May 14 12:10:09 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 14 May 2010 12:10:09 -0500 Subject: Illinois Tollway dark fiber Message-ID: Has anyone had any experience working with the Illinois Tollway for dark fiber? Looking for good or bad experiences offline. Thanks! -brandon -- Brandon Galbraith Voice: 630.492.0464 From lowen at pari.edu Fri May 14 12:36:42 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 14 May 2010 13:36:42 -0400 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <201005141336.42511.lowen@pari.edu> On Thursday 13 May 2010 11:36:35 am Caleb Tennis wrote: > I was just curious if anyone had seen anything similar to this before? Our > incoming electrical power has surge suppression, and the power to the > switches is all through double conversion UPS, so I'm not quite sure why > any of them would have been impacted at all. I'm guessing that the strike > had some impact on the electrical ground, but I don't know what we can do > to prevent future strikes from causing the same issues. Thoughts? Inductively coupled EMP onto the CAT5. I've seen ethernet port chips vaporized on switches. I've even seen holes blown in port interface chips, and the switch continue working (have a DC powered Catalyst 2900XL switch with the center 8 ports in a nonworking state due to EMP from a close strike; the 2900XL is still running fine, just can't use those center eight ports anymore). The building it is installed in is on solar power, and at the time was off- grid. A Siteplayer Telnet was blown, and the eight ports were fried (one of which was connected to the Siteplayer Telnet that got blown) on the switch, but that was the extent of the damage. I'm from a broadcast engineering background, and have seen lightning's effects in many many devices, including vaporized PC traces, etc. Virtually all damage I've seen has been due to either EMP or improperly bonded grounding systems. In particular, if your telecom ground isn't bonded to the electrical NEC safety ground, you will get a voltage difference between the grounds, depending upon the voltage gradient in the ground. Whole books have been written on this subject; I've got one by Polyphaser about nuclear EMP (same concept, larger scale) protection for radio stations. Imagine the lightning bolt's ionization conduction channel as the primary side of many transformers, with every single conductor within many meters being potential secondaries. The closer the secondary, the more coupling. It's a 1:1 turns ratio, too, and so a 100% coupled secondary would give an equal amperage through the secondary. Air-core transformers are loosely coupled at best, but even a tenth of one percent coupling of a 100kiloampere lightning stroke is 100 amps in magnitude. Loosely coupled current transformers, like this, tend to generate large open circuit voltages, too. The most graphic evidence I've seen of the power of lightning-created EMP was made during a strike I saw in June of 1998 at a radio station's studios. The studios were in an old, 1950's vintage school building, built to 1950's civil defense standards for EMP resistance (rebar in a Faraday cage arrangement, metal roof, lightning rods on the roof). There is a 100 foot studio- transmitter link (STL) tower at one end of the building. The STL tower took a direct hit. The Faraday cage rebar verticals embedded in the walls became coupled secondaries, and large currents flowed. Every single CRT monitor in the entire 300 foot long building was left with a rainbow effect on the screen due to the residual magnetism from the EMP. Even monitors that weren't plugged in were rainbowed. Many PC's died that day, but I resurrected several hard drives where I could find identical control boards; no hard drive was unreadable due to magnetic issues, but only electrical (no bad heads or erased sections on the platters; every one I found a compatible replacement control board for was recovered). Made some good money degaussing CRT's that week. (used a bulk tape eraser; turned on the eraser, brought it close to the CRT, worked it over all surfaces, then slowing drew the eraser away from the CRT, and turned it off). The EMP was strong enough that there were a couple of pieces of spare equipment, located in a room less than 30 feet from the tower, that had lightning damage even though they weren't plugged in or connected to anything. One 250MCM ground wire from the tower was vaporized; there were three, and the other two survived, but with noticeable heat-induced discoloration (they were replaced, and the glassed-up ground rods were as well). Engineering estimates of the stroke current were that it was somewhat greater than 200kiloamperes. One of the STL transmitters was damaged, but on the audio side. Neither of the two STL transmitters sustained any RF output damage thanks to the sacrifice of the two daisy-chained Polyphaser arrestors (the arrestors acted as fuses, and had to be replaced, but they're a lot cheaper than a 950MHz Marti STL-10!). One of the two four foot Marti STL dishes had a melted feed, but the other one, which was lower on the tower (about 85 feet up) was undamaged. Fortunately, neither of the two half-inch heliax runs from the dishes were damaged. The 10base-2 LAN took extensive damage, but not every NIC. The most interesting damage was to the RG-58 cable itself, which had holes blown in it every 30 feet or so. Made a good argument to upgrade to 10Base-T at the time. At my current employer, which is a lightning magnet, we use Altelicon AL- CAT5HPW lightning arrestors on all cat5 installations that go outside a building. At any building known to have lighting issues, we put one of those on every cat5 going to the switch (Altelicon also makes four-port versions). Tripplite also makes cat5 PoE compatible arrestors. Lightning damage is completely predictable, if you have all the information, as it's all physics: we just never have complete information, like the coupling percentage from the primary ion channel to the various potential secondary conductors. Lightning will take the path of least resistance (which may not be the path you think), and it will generate EMP, which will create induced currents. Proper single-point star grounding and bonding of ground conductors and electrode fields is a must to reduce damage; multiple electrodes or electrode fields must be bonded, or you will get damage. You may get damage anyway; depends entirely on the physics of that particular stroke. Fun stuff, that's for sure. From tbeecher at localnet.com Fri May 14 12:59:32 2010 From: tbeecher at localnet.com (Tom Beecher) Date: Fri, 14 May 2010 13:59:32 -0400 Subject: SNMP Monitoring of a Transfer Switch relay Message-ID: <4BED8F84.5080100@localnet.com> I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. Thanks in advance, Tom From cscora at apnic.net Fri May 14 13:10:31 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 15 May 2010 04:10:31 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201005141810.o4EIAVCR007687@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 15 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 321353 Prefixes after maximum aggregation: 148341 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 156858 Total ASes present in the Internet Routing Table: 34007 Prefixes per ASN: 9.45 Origin-only ASes present in the Internet Routing Table: 29525 Origin ASes announcing only one prefix: 14346 Transit ASes present in the Internet Routing Table: 4482 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 341 Unregistered ASNs in the Routing Table: 120 Number of 32-bit ASNs allocated by the RIRs: 564 Prefixes from 32-bit ASNs in the Routing Table: 636 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 189 Number of addresses announced to Internet: 2216648704 Equivalent to 132 /8s, 31 /16s and 96 /24s Percentage of available address space announced: 59.8 Percentage of allocated address space announced: 65.1 Percentage of available address space allocated: 91.9 Percentage of address space in use by end-sites: 82.7 Total number of prefixes smaller than registry allocations: 154160 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76802 Total APNIC prefixes after maximum aggregation: 26762 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 73469 Unique aggregates announced from the APNIC address blocks: 32216 APNIC Region origin ASes present in the Internet Routing Table: 4033 APNIC Prefixes per ASN: 18.22 APNIC Region origin ASes announcing only one prefix: 1100 APNIC Region transit ASes present in the Internet Routing Table: 622 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 516278592 Equivalent to 30 /8s, 197 /16s and 201 /24s Percentage of available APNIC address space announced: 76.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/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: 133879 Total ARIN prefixes after maximum aggregation: 69162 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106795 Unique aggregates announced from the ARIN address blocks: 41618 ARIN Region origin ASes present in the Internet Routing Table: 13695 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5278 ARIN Region transit ASes present in the Internet Routing Table: 1351 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 730749728 Equivalent to 43 /8s, 142 /16s and 91 /24s Percentage of available ARIN address space announced: 62.2 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, 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, 54/8, 55/8, 56/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, 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: 73907 Total RIPE prefixes after maximum aggregation: 42884 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 66839 Unique aggregates announced from the RIPE address blocks: 43966 RIPE Region origin ASes present in the Internet Routing Table: 14455 RIPE Prefixes per ASN: 4.62 RIPE Region origin ASes announcing only one prefix: 7456 RIPE Region transit ASes present in the Internet Routing Table: 2159 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 425650848 Equivalent to 25 /8s, 94 /16s and 234 /24s Percentage of available RIPE address space announced: 74.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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28593 Total LACNIC prefixes after maximum aggregation: 6808 LACNIC Deaggregation factor: 4.20 Prefixes being announced from the LACNIC address blocks: 26992 Unique aggregates announced from the LACNIC address blocks: 13997 LACNIC Region origin ASes present in the Internet Routing Table: 1287 LACNIC Prefixes per ASN: 20.97 LACNIC Region origin ASes announcing only one prefix: 407 LACNIC Region transit ASes present in the Internet Routing Table: 223 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 73060608 Equivalent to 4 /8s, 90 /16s and 209 /24s Percentage of available LACNIC address space announced: 72.6 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7315 Total AfriNIC prefixes after maximum aggregation: 1835 AfriNIC Deaggregation factor: 3.99 Prefixes being announced from the AfriNIC address blocks: 5610 Unique aggregates announced from the AfriNIC address blocks: 1674 AfriNIC Region origin ASes present in the Internet Routing Table: 362 AfriNIC Prefixes per ASN: 15.50 AfriNIC Region origin ASes announcing only one prefix: 105 AfriNIC Region transit ASes present in the Internet Routing Table: 87 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC addresses announced to Internet: 17840640 Equivalent to 1 /8s, 16 /16s and 58 /24s Percentage of available AfriNIC address space announced: 53.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1848 8422 483 Korea Telecom (KIX) 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1306 293 155 TATA Communications formerly 7545 1196 232 105 TPG Internet Pty Ltd 17974 995 281 18 PT TELEKOMUNIKASI INDONESIA 9583 993 73 484 Sify Limited 4134 936 21190 403 CHINANET-BACKBONE 24560 897 304 167 Bharti Airtel Ltd., Telemedia 4808 844 1589 215 CNCGROUP IP network: China169 9829 777 676 41 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3929 3733 288 bellsouth.net, inc. 4323 3842 1116 406 Time Warner Telecom 1785 1784 699 131 PaeTec Communications, Inc. 7018 1550 5757 985 AT&T WorldNet Services 20115 1537 1505 655 Charter Communications 2386 1296 584 917 AT&T Data Communications Serv 6478 1240 256 108 AT&T Worldnet Services 3356 1200 10920 415 Level 3 Communications, LLC 22773 1170 2606 72 Cox Communications, Inc. 11492 1145 209 284 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 625 56 6 United Telecom of Georgia 3292 454 2027 393 TDC Tele Danmark 30890 440 116 206 Evolva Telecom 702 414 1869 329 UUNET - Commercial IP service 8551 403 356 37 Bezeq International 8866 393 117 18 Bulgarian Telecommunication C 3301 366 1421 322 TeliaNet Sweden 3320 365 7072 318 Deutsche Telekom AG 12479 336 576 5 Uni2 Autonomous System 3215 331 3218 100 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1555 2965 245 UniNet S.A. de C.V. 10620 1037 233 151 TVCABLE BOGOTA 28573 886 729 86 NET Servicos de Comunicao S.A 7303 719 372 101 Telecom Argentina Stet-France 6503 576 173 209 AVANTEL, S.A. 22047 543 310 15 VTR PUNTO NET S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 467 201 73 Empresa Nacional de Telecomun 14117 448 30 13 Telefonica del Sur S.A. 11172 444 99 72 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1250 445 10 TEDATA 24863 718 147 43 LINKdotNET AS number 36992 624 275 178 Etisalat MISR 3741 273 852 232 The Internet Solution 2018 216 231 112 Tertiary Education Network 33776 208 11 14 Starcomms Nigeria Limited 24835 177 78 10 RAYA Telecom - Egypt 6713 176 167 12 Itissalat Al-MAGHRIB 29571 172 19 9 Ci Telecom Autonomous system 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3929 3733 288 bellsouth.net, inc. 4323 3842 1116 406 Time Warner Telecom 4766 1848 8422 483 Korea Telecom (KIX) 1785 1784 699 131 PaeTec Communications, Inc. 8151 1555 2965 245 UniNet S.A. de C.V. 7018 1550 5757 985 AT&T WorldNet Services 20115 1537 1505 655 Charter Communications 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1306 293 155 TATA Communications formerly 2386 1296 584 917 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3842 3436 Time Warner Telecom 1785 1784 1653 PaeTec Communications, Inc. 4766 1848 1365 Korea Telecom (KIX) 8151 1555 1310 UniNet S.A. de C.V. 8452 1250 1240 TEDATA 17488 1316 1193 Hathway IP Over Cable Interne 4755 1306 1151 TATA Communications formerly 6478 1240 1132 AT&T Worldnet Services 22773 1170 1098 Cox Communications, Inc. 7545 1196 1091 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 1239 Sprint 26973 UNALLOCATED 12.39.154.0/23 1239 Sprint 26973 UNALLOCATED 12.39.155.0/24 1239 Sprint 26973 UNALLOCATED 12.39.159.0/24 1239 Sprint 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 26452 Local Communications Networks 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.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:10 /10:26 /11:67 /12:193 /13:401 /14:690 /15:1264 /16:11060 /17:5278 /18:8974 /19:18281 /20:22561 /21:22664 /22:29485 /23:29142 /24:168304 /25:947 /26:1198 /27:622 /28:143 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2513 3929 bellsouth.net, inc. 4323 2332 3842 Time Warner Telecom 4766 1481 1848 Korea Telecom (KIX) 1785 1247 1784 PaeTec Communications, Inc. 8452 1128 1250 TEDATA 17488 1063 1316 Hathway IP Over Cable Interne 11492 1061 1145 Cable One 18566 1040 1059 Covad Communications 10620 953 1037 TVCABLE BOGOTA 7018 932 1550 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:13 8:264 12:2013 13:10 15:23 16:3 17:8 20:21 24:1414 27:55 31:1 32:47 33:12 38:669 40:98 41:2468 44:3 47:26 52:6 55:6 56:2 57:24 58:724 59:509 60:434 61:1087 62:1048 63:1980 64:3849 65:2363 66:4199 67:1838 68:1105 69:2813 70:710 71:243 72:1816 73:2 74:2280 75:251 76:306 77:872 78:625 79:412 80:1008 81:794 82:492 83:442 84:703 85:1049 86:459 87:698 88:329 89:1547 90:88 91:2755 92:475 93:1109 94:1416 95:597 96:248 97:311 98:545 99:28 108:16 109:475 110:347 111:494 112:257 113:285 114:400 115:591 116:1031 117:639 118:425 119:967 120:141 121:733 122:1438 123:888 124:1109 125:1292 128:209 129:210 130:192 131:560 132:246 133:17 134:194 135:45 136:228 137:172 138:255 139:92 140:483 141:137 142:354 143:388 144:476 145:52 146:430 147:165 148:608 149:288 150:153 151:169 152:262 153:167 154:2 155:329 156:184 157:324 158:107 159:372 160:311 161:205 162:262 163:174 164:408 165:532 166:480 167:393 168:785 169:161 170:701 171:51 172:1 173:733 174:616 175:91 176:1 178:88 180:469 182:60 183:251 184:41 186:379 187:345 188:1320 189:775 190:3649 192:5733 193:4696 194:3354 195:2774 196:1217 197:1 198:3569 199:3432 200:5354 201:1514 202:7976 203:8268 204:4060 205:2337 206:2540 207:3034 208:3920 209:3432 210:2505 211:1237 212:1731 213:1676 214:664 215:70 216:4588 217:1531 218:497 219:372 220:1105 221:400 222:291 End of report From franck at genius.com Fri May 14 13:29:46 2010 From: franck at genius.com (Franck Martin) Date: Fri, 14 May 2010 11:29:46 -0700 (PDT) Subject: ipv6 transit over tunneled connection In-Reply-To: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> Message-ID: <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> ----- Original Message ----- From: "Christopher Morrow" To: "Michael Ulitskiy" Cc: nanog at nanog.org Sent: Thursday, 13 May, 2010 6:39:28 PM Subject: Re: ipv6 transit over tunneled connection On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - > learning/labbing/experimenting/etc. We've got to the point when we're > also planning to request initial ipv6 allocation from ARIN. > So I wonder what ipv6 transit options I have if my upstreams do not > support native ipv6 connectivity? > I see Hurricane Electric tunnel broker BGP tunnel. Is there anything > else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets? From kwallace at pcconnection.com Fri May 14 13:34:47 2010 From: kwallace at pcconnection.com (Wallace Keith) Date: Fri, 14 May 2010 14:34:47 -0400 Subject: SNMP Monitoring of a Transfer Switch relay In-Reply-To: <4BED8F84.5080100@localnet.com> References: <4BED8F84.5080100@localnet.com> Message-ID: <0E8773C725A1674E9F7B35EABB5EEEB1089D3F3B@MKA134.pcc.int> I've had good luck with devices from DPS; http://www.dpstele.com/ -Keith -----Original Message----- From: Tom Beecher [mailto:tbeecher at localnet.com] Sent: Friday, May 14, 2010 2:00 PM To: nanog at nanog.org Subject: SNMP Monitoring of a Transfer Switch relay I'm presently doing some research into a SNMP-enabled device to monitor a set of aux contacts on our transfer switch in order to be able to monitor it's status (on generator or on commercial) from our monitoring platform. I've seen a few interesting devices out there that can accomplish this, however I thought I'd query the list to see if anyone has thoughts about a particular unit they've worked with. Thanks in advance, Tom From jack at crepinc.com Fri May 14 13:43:00 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Fri, 14 May 2010 14:43:00 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> Message-ID: I agree - if you can get native v6 transit then more power to you. But tunnels are sure better than no IPv6 connectivity in my mind. Aside from slight performance/efficiency issues, I've never had an issue. -Jack Carrozzo On Fri, May 14, 2010 at 2:29 PM, Franck Martin wrote: > > > ----- Original Message ----- > From: "Christopher Morrow" > To: "Michael Ulitskiy" > Cc: nanog at nanog.org > Sent: Thursday, 13 May, 2010 6:39:28 PM > Subject: Re: ipv6 transit over tunneled connection > > On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy > wrote: > > Hello, > > > > We're in the early stage of planning ipv6 deployment - > > learning/labbing/experimenting/etc. We've got to the point when we're > > also planning to request initial ipv6 allocation from ARIN. > > So I wonder what ipv6 transit options I have if my upstreams do not > > support native ipv6 connectivity? > > I see Hurricane Electric tunnel broker BGP tunnel. Is there anything > > else? Either free or commercial? > > 1) see gblx/ntt/sprint/twt/vzb for transit-v6 > 2) tunnel inside your domain (your control, your MTU issues, your > alternate pathing of tunnels vs pipe) > 3) don't tunnel beyond your borders, really just don't > > tunnels are bad, always. > -chris > > I see so many times, that tunnels are bad for IPv6, but this is the way > IPv6 has been designed to work when you cannot get direct IPv6. So I would > not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 > states the use of tunnels). > > If the issue with tunnel is MTU, then a non-negligible part of IPv4 does > not work well with MTU different of 1500. With IPv6 we bring the concept of > jumbo packets, with large MTU. If we cannot work with non standard MTUs in > IPv6 tunnels, how will we work with jumbo packets? > > From jared at puck.nether.net Fri May 14 13:49:11 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 14 May 2010 14:49:11 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> Message-ID: <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big "I" Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: > I agree - if you can get native v6 transit then more power to you. But > tunnels are sure better than no IPv6 connectivity in my mind. Aside from > slight performance/efficiency issues, I've never had an issue. > > -Jack Carrozzo From sethm at rollernet.us Fri May 14 13:51:25 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 14 May 2010 11:51:25 -0700 Subject: SNMP Monitoring of a Transfer Switch relay In-Reply-To: <4BED8F84.5080100@localnet.com> References: <4BED8F84.5080100@localnet.com> Message-ID: <4BED9BAD.7070703@rollernet.us> On 5/14/2010 10:59, Tom Beecher wrote: > I'm presently doing some research into a SNMP-enabled device to monitor > a set of aux contacts on our transfer switch in order to be able to > monitor it's status (on generator or on commercial) from our monitoring > platform. I've seen a few interesting devices out there that can > accomplish this, however I thought I'd query the list to see if anyone > has thoughts about a particular unit they've worked with. > I went a different way with my electrical gear and used modbus. For me, the benefits are multiple devices on the 485 bus, monitoring lots of parameters and I can execute remote commands. I paid something like $300 for the xfer switch modbus card, which was cheaper than any SNMP contact closure device I could find at the time. I talk to it using Perl Modbus::Client with my monitoring server as the modbus master. It ended up being less of a hassle and much more flexible in the long run. You may or may not have your mind set on dry contact monitoring, but it's something to think about. ~Seth From morrowc.lists at gmail.com Fri May 14 13:57:20 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 May 2010 14:57:20 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> Message-ID: On Fri, May 14, 2010 at 2:29 PM, Franck Martin wrote: > I said somewhere in here... wierd quoting happened. > On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy > wrote: >> Hello, >> >> We're in the early stage of planning ipv6 deployment - >> learning/labbing/experimenting/etc. We've got to the point when we're >> also planning to request initial ipv6 allocation from ARIN. >> So I wonder what ipv6 transit options I have if my upstreams do not >> support native ipv6 connectivity? >> I see Hurricane Electric tunnel broker BGP tunnel. Is there anything >> else? Either free or commercial? > > 1) see gblx/ntt/sprint/twt/vzb for transit-v6 > 2) tunnel inside your domain (your control, your MTU issues, your > alternate pathing of tunnels vs pipe) > 3) don't tunnel beyond your borders, really just don't > > tunnels are bad, always. > -chris > > I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you > cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 > states the use of tunnels). Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6. > If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. > With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in > IPv6 tunnels, how will we work with jumbo packets? a non-negligible part of the ipv6 internet doesn't work at all with >1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites. -Chris From sethm at rollernet.us Fri May 14 14:00:52 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 14 May 2010 12:00:52 -0700 Subject: ipv6 transit over tunneled connection In-Reply-To: <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> Message-ID: <4BED9DE4.6020609@rollernet.us> On 5/14/2010 11:49, Jared Mauch wrote: > I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. > > I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. > > What parts of the big "I" Internet are not enabled or ready? > Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T simply told me not available yet. Tunnels are still a necessity. ~Seth From morrowc.lists at gmail.com Fri May 14 14:44:10 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 May 2010 15:44:10 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <4BED9DE4.6020609@rollernet.us> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> <4BED9DE4.6020609@rollernet.us> Message-ID: On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen wrote: > On 5/14/2010 11:49, Jared Mauch wrote: >> I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. >> >> I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. >> >> What parts of the big "I" Internet are not enabled or ready? >> > > Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if > you're closer to one of those (currently on month 11 of waiting, I'm > just letting it go because I'm curious how long it'll take), Sprint > isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility > is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T > simply told me not available yet. > > Tunnels are still a necessity. twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet. From bruns at 2mbit.com Fri May 14 14:43:10 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 14 May 2010 19:43:10 +0000 Subject: ipv6 transit over tunneled connection Message-ID: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. Brielle ------Original Message------ From: Jared Mauch To: Jack Carrozzo Cc: nanog at nanog.org Subject: Re: ipv6 transit over tunneled connection Sent: May 14, 2010 12:49 PM I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big "I" Internet are not enabled or ready? - Jared On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: > I agree - if you can get native v6 transit then more power to you. But > tunnels are sure better than no IPv6 connectivity in my mind. Aside from > slight performance/efficiency issues, I've never had an issue. > > -Jack Carrozzo -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From vasil at ludost.net Fri May 14 14:46:16 2010 From: vasil at ludost.net (Vasil Kolev) Date: Fri, 14 May 2010 22:46:16 +0300 Subject: IPv6 eyeballs? Message-ID: <1273866376.2104.8.camel@shrike.home.ludost.net> Hi all, This seems like the proper time to ask, seeing how many people are there asking for IPv6 transit - does anyone have any kind of stats how many eyeballs are there that have IPv6, and are there any of them that have a better service over v6 that over v4 (my guess here is universities or other academical institutions that have really big v6 pipes)? The reason for this question is that s few weeks ago I wrote an initial list of what we (as a medium-sized content provider) need to do to be able to push traffic over v6, and with careful testing and everything it should fit in six months. What's not known is it worth to start implementing it. We pretty much accept as given that no carrier will limit its own users to v6 only in the near (1-2-3 year) future, but with stuff like CGN/LSN degradation could be expected to show up in the v4 service. -- Regards, Vasil Kolev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: ???? ? ??????? ????????? ???? ?? ??????? URL: From cburwell at gmail.com Fri May 14 15:12:55 2010 From: cburwell at gmail.com (Chris Burwell) Date: Fri, 14 May 2010 16:12:55 -0400 Subject: SNMP Monitoring of a Transfer Switch relay In-Reply-To: <4BED8F84.5080100@localnet.com> References: <4BED8F84.5080100@localnet.com> Message-ID: I have used the APC Environmental Manager (EMU) to do this. In our case we ran a 4-pair line from the generator to the EMU. One pair was connected to the EMU so that we could monitor and alert on the run-cycles of the generator. Our transfer switch did not have these capabilities, but you could apply the same configuration we used for out generator. The EMU has built-in alerting as well as the ability to send SNMP traps. - Chris On Fri, May 14, 2010 at 1:59 PM, Tom Beecher wrote: > I'm presently doing some research into a SNMP-enabled device to monitor a > set of aux contacts on our transfer switch in order to be able to monitor > it's status (on generator or on commercial) from our monitoring platform. > I've seen a few interesting devices out there that can accomplish this, > however I thought I'd query the list to see if anyone has thoughts about a > particular unit they've worked with. > > Thanks in advance, > > Tom > > > From jared at puck.nether.net Fri May 14 15:36:28 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 14 May 2010 16:36:28 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> Message-ID: <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> On May 14, 2010, at 3:43 PM, Brielle Bruns wrote: > (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) > > > Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. I can say that we (NTT) have been IPv6 enabled or ready at all customer ports since ~2003. Anyone else who has not gotten there in the intervening years may have problems supporting you for your IPv4 as well :) > Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). You should be able to get native IPv6 in Seattle from a variety of providers. If you're not finding it, you're not really looking (IMHO). > Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. The tunneled part of the "IPv6" internet fell to the wayside a long time ago, there are stragglers and I have even seen people try to peer over tunnels in 2010, but anyone still adding that level of overlay (v6-over-v4) may find themselves in a world of hurt soon enough. - Jared (Curious about what incumbent carrier plans are for end-user - eg qwest, att, vz resi) From john at internetassociatesllc.com Fri May 14 15:44:17 2010 From: john at internetassociatesllc.com (John Lee) Date: Fri, 14 May 2010 15:44:17 -0500 Subject: POE switches and lightning In-Reply-To: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> Message-ID: <53A6C7E936ED8544B1A2BC990D254F9464591FFAAD@MEMEXG1.HOST.local> IMHO, Long runs of UTP (unshielded twisted pair) make wonderful antenna systems for EMI and EMP which is why they are matched to differential drivers and receivers to reject as much common noise as they are designed to. Older and larger Ethernet interfaces have drivers separated from the logic components that can handle higher over currents and voltages that are induced on the cable. Newer, smaller integral designs cannot usually handle as much power as the older designs. UTP systems in industrial environments require higher performance drivers that handle higher currents and voltages since they are induced by large motors, HVAC and florescent lighting systems. EMP (lightening) is a very wide band, high number of frequency bands signal with large amounts of power being induced into the systems they are impinging very rapidly. ITGOD (In the Good Old Days) we used to run everything through conduits which when properly grounded protected both power and signal circuits against lightning very well. There is a very large wifi network in multiple mile long structures connected by underground tunnels, in the most active thunder storm zone in the country, some of the issues were: ? There were a number of power and grounding zones in the buildings ? There were local grounds at each of the wiring closets that all equipment in that zone was tied to. (Have the earth ground checked and if it they are corroded or no longer working, have a new earth ground field dug or tie to the ?building steel? if it has one or more grounding points.) ? All inter zone runs were fiber ? Both PoE switches and local PoE bricks were used to power the remote access points to keep power drops over the utp to within design parameters. ? Some zones had switches with both fiber and PoE ports with the PoE ports handling local access points and the fiber ports running to smaller remote switches with PoE from there to the edge devices. ? If the power runs were too long and their was no local power available, custom cables were manufactured to increase power conductor sizes to lessen voltage drops ? All outside runs were in conduit and would preferably be fiber. When I installed my first Ethernet with RG-9, I had to ground the cable at the center of the run and tape each end of the cable since it had almost lethal voltage at the either end of the Ethernet cable. My analog circuits professor said forget this digital design stuff, it as an analog signal in a transmission medi(a)um. Regards, John (ISDN) Lee ________________________________________ From: Caleb Tennis [caleb.tennis at gmail.com] Sent: Thursday, May 13, 2010 11:36 AM To: North American Network Operators Group Subject: POE switches and lightning We had a lightning strike nearby yesterday that looks to have come inside our facility via a feeder circuit that goes outdoors underground to our facility's gate. What's interesting is that various POE switches throughout the entire building seemed to be affected in that some of their ports they just shut down/off. Rebooting these switches brought everything back to life. It didn't impact anything non-POE, and even then, only impacted some devices. But it was spread across the whole building, across multiple switches. I was just curious if anyone had seen anything similar to this before? Our incoming electrical power has surge suppression, and the power to the switches is all through double conversion UPS, so I'm not quite sure why any of them would have been impacted at all. I'm guessing that the strike had some impact on the electrical ground, but I don't know what we can do to prevent future strikes from causing the same issues. Thoughts? From nicholas.hatch at gmail.com Fri May 14 15:50:03 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Fri, 14 May 2010 13:50:03 -0700 Subject: SNMP Monitoring of a Transfer Switch relay In-Reply-To: <4BED8F84.5080100@localnet.com> References: <4BED8F84.5080100@localnet.com> Message-ID: On Fri, May 14, 2010 at 10:59 AM, Tom Beecher wrote: > I'm presently doing some research into a SNMP-enabled device to monitor a > set of aux contacts on our transfer switch in order to be able to monitor > it's status (on generator or on commercial) from our monitoring platform. > I've seen a few interesting devices out there that can accomplish this, > however I thought I'd query the list to see if anyone has thoughts about a > particular unit they've worked with. > I've found the Weathergoose II to be a good general-purpose SNMP monitoring device. They also have something called the Relaygoose which can accommodate more inputs and trigger relays as well. http://www.itwatchdogs.com/p_product_detail.php?pnum=1 -Nick From randy at psg.com Fri May 14 15:51:01 2010 From: randy at psg.com (Randy Bush) Date: Fri, 14 May 2010 21:51:01 +0100 Subject: nyc glass In-Reply-To: <20100514170453.GA71926@latency.net> References: <20100514170453.GA71926@latency.net> Message-ID: >> anyone have reccos for fiber >> from 60 hudson >> to 454 broadway > From a cursory look at POP and GIS data not covered by NDA, I'm not > finding any vendors currently built into 454 Broadway. later word from the customer is s/454/434/. grrrr. randy From cmadams at hiwaay.net Fri May 14 16:11:17 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 14 May 2010 16:11:17 -0500 Subject: SNMP Monitoring of a Transfer Switch relay In-Reply-To: <4BED8F84.5080100@localnet.com> References: <4BED8F84.5080100@localnet.com> Message-ID: <20100514211116.GG1201128@hiwaay.net> Once upon a time, Tom Beecher said: > I'm presently doing some research into a SNMP-enabled device to monitor > a set of aux contacts on our transfer switch in order to be able to > monitor it's status (on generator or on commercial) from our monitoring > platform. I've seen a few interesting devices out there that can > accomplish this, however I thought I'd query the list to see if anyone > has thoughts about a particular unit they've worked with. We have some old NetBotz (now part of APC) in our NOC, and ours have dry contact ports, so we hooked one up to our transfer switch. Works like a champ. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From randy at psg.com Fri May 14 16:22:50 2010 From: randy at psg.com (Randy Bush) Date: Fri, 14 May 2010 22:22:50 +0100 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <201005131818.12316.mulitskiy@acedsl.com> Message-ID: > 3) don't tunnel beyond your borders, really just don't > tunnels are bad, always. you are understaing your case. randy From paul at telcodata.us Fri May 14 16:23:23 2010 From: paul at telcodata.us (Paul Timmins) Date: Fri, 14 May 2010 17:23:23 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> Message-ID: <4BEDBF4B.2010306@telcodata.us> GBLX was great with native IPv6 setup. VZB was nearly impossible to get them to set it up, and I'm tunneled to a router halfway across the country. The router I was going to had serious PMTU issues that they recently cleared up, so now it's working satisfactorily. -Paul Brielle Bruns wrote: > (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) > > > Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. > > Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). > > Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. > > > Brielle > ------Original Message------ > From: Jared Mauch > To: Jack Carrozzo > Cc: nanog at nanog.org > Subject: Re: ipv6 transit over tunneled connection > Sent: May 14, 2010 12:49 PM > > I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. > > I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. > > What parts of the big "I" Internet are not enabled or ready? > > - Jared > > On May 14, 2010, at 2:43 PM, Jack Carrozzo wrote: > > >> I agree - if you can get native v6 transit then more power to you. But >> tunnels are sure better than no IPv6 connectivity in my mind. Aside from >> slight performance/efficiency issues, I've never had an issue. >> >> -Jack Carrozzo >> > > > > > From cidr-report at potaroo.net Fri May 14 17:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 May 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201005142200.o4EM049M057845@wattle.apnic.net> BGP Update Report Interval: 06-May-10 -to- 13-May-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 14118 1.5% 38.0 -- BSNL-NIB National Internet Backbone 2 - AS4538 11556 1.2% 148.2 -- ERX-CERNET-BKB China Education and Research Network Center 3 - AS10113 10587 1.1% 179.4 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 4 - AS28477 10116 1.1% 1124.0 -- Universidad Autonoma del Esstado de Morelos 5 - AS35931 9430 1.0% 3143.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS5800 9259 1.0% 41.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS8452 9054 0.9% 8.8 -- TEDATA TEDATA 8 - AS41786 8901 0.9% 423.9 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 9 - AS6389 7069 0.7% 6.5 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 10 - AS4847 6616 0.7% 82.7 -- CNIX-AP China Networks Inter-Exchange 11 - AS3549 6452 0.7% 96.3 -- GBLX Global Crossing Ltd. 12 - AS5976 5937 0.6% 52.1 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS8386 5868 0.6% 70.7 -- KOCNET KOCNET-AS 14 - AS8151 5820 0.6% 12.2 -- Uninet S.A. de C.V. 15 - AS30890 5705 0.6% 13.0 -- EVOLVA Evolva Telecom s.r.l. 16 - AS17974 5430 0.6% 13.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 17 - AS14522 5075 0.5% 16.1 -- Satnet 18 - AS36992 4866 0.5% 13.3 -- ETISALAT-MISR 19 - AS11492 4655 0.5% 10.9 -- CABLEONE - CABLE ONE, INC. 20 - AS25620 4578 0.5% 29.3 -- COTAS LTDA. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 9430 1.0% 3143.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS48754 2686 0.3% 2686.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 3 - AS29661 2401 0.2% 2401.0 -- INTI-AS INTI Autonomous System 4 - AS45670 2285 0.2% 2285.0 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 5 - AS13004 1695 0.2% 1695.0 -- SOX Serbian Open Exchange 6 - AS28477 10116 1.1% 1124.0 -- Universidad Autonoma del Esstado de Morelos 7 - AS31557 939 0.1% 939.0 -- IGT-MOLD-NET-AS IGT Communications AS 8 - AS3397 896 0.1% 896.0 -- DAVINCI - Davinci Broadband Inc. 9 - AS11613 806 0.1% 806.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 10 - AS28285 2939 0.3% 734.8 -- World Line Ltda 11 - AS4387 2863 0.3% 715.8 -- Secretaria de Ciencia y Tecnologia - Red Cientific 12 - AS53065 1849 0.2% 462.2 -- 13 - AS18399 1835 0.2% 458.8 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 14 - AS30341 1307 0.1% 435.7 -- SCTA-ASN - South Central Telephone Association 15 - AS41786 8901 0.9% 423.9 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 16 - AS8038 403 0.0% 403.0 -- 6CONNECT - 6connect, Inc. 17 - AS27560 796 0.1% 398.0 -- ULTCO - Universal Leaf Tobacco Company Inc. 18 - AS10445 2368 0.2% 394.7 -- HTG - Huntleigh Telcom 19 - AS28052 380 0.0% 380.0 -- Arte Radiotelevisivo Argentino 20 - AS43914 341 0.0% 341.0 -- ECCO-AS Ecco Holiday Sp. z o.o. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 58.207.96.0/19 10719 1.0% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 2 - 200.13.36.0/24 10092 1.0% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 188.187.184.0/24 8639 0.8% AS41786 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 4 - 64.76.40.0/24 6024 0.6% AS3549 -- GBLX Global Crossing Ltd. 5 - 198.140.43.0/24 5710 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 205.91.160.0/20 4083 0.4% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - 63.211.68.0/22 3711 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 206.184.16.0/24 2938 0.3% AS174 -- COGENT Cogent/PSI 9 - 91.212.23.0/24 2686 0.3% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 10 - 143.138.107.0/24 2443 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 202.92.235.0/24 2419 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 12 - 193.16.43.0/24 2401 0.2% AS29661 -- INTI-AS INTI Autonomous System 13 - 202.89.118.0/24 2285 0.2% AS45670 -- SOFTCRYLICNET1-IN #160,North Usman Road, Third Floor 14 - 193.16.111.0/24 2153 0.2% AS15836 -- AXAUTSYS ARAX I.S.P. AS31557 -- IGT-MOLD-NET-AS IGT Communications AS 15 - 187.86.61.0/24 1834 0.2% AS53065 -- 16 - 203.81.166.0/24 1821 0.2% AS18399 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 17 - 193.105.163.0/24 1695 0.2% AS13004 -- SOX Serbian Open Exchange 18 - 124.254.32.0/19 1587 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 19 - 124.14.64.0/18 1587 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 20 - 220.113.32.0/20 1586 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 May 14 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 14 May 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201005142200.o4EM00kk057836@wattle.apnic.net> This report has been generated at Fri May 14 21:11:53 2010 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 07-05-10 322970 198887 08-05-10 323192 198675 09-05-10 323061 198709 10-05-10 323051 198890 11-05-10 323433 199356 12-05-10 323659 199204 13-05-10 323972 199415 14-05-10 323865 199651 AS Summary 34411 Number of ASes in routing system 14621 Number of ASes announcing only one prefix 4433 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 99973792 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'). --- 14May10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 324681 200077 124604 38.4% All ASes AS6389 3929 293 3636 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4433 1584 2849 64.3% TWTC - tw telecom holdings, inc. AS4766 1848 497 1351 73.1% KIXS-AS-KR Korea Telecom AS22773 1170 77 1093 93.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1306 215 1091 83.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1316 327 989 75.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS7545 1201 244 957 79.7% TPG-INTERNET-AP TPG Internet Pty Ltd AS8151 1554 649 905 58.2% Uninet S.A. de C.V. AS6478 1240 337 903 72.8% ATT-INTERNET3 - AT&T WorldNet Services AS18566 1059 159 900 85.0% COVAD - Covad Communications Co. AS10620 1037 156 881 85.0% Telmex Colombia S.A. AS19262 1103 269 834 75.6% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1252 447 805 64.3% TEDATA TEDATA AS5668 834 184 650 77.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS7303 719 109 610 84.8% Telecom Argentina S.A. AS1785 1784 1185 599 33.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS4808 844 247 597 70.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS7018 1551 987 564 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS35805 625 67 558 89.3% UTG-AS United Telecom AS AS24560 897 358 539 60.1% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 890 384 506 56.9% NET Servicos de Comunicao S.A. AS4780 670 166 504 75.2% SEEDNET Digital United Inc. AS17676 570 79 491 86.1% GIGAINFRA Softbank BB Corp. AS3356 1201 713 488 40.6% LEVEL3 Level 3 Communications AS9443 556 74 482 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17908 528 78 450 85.2% TCISL Tata Communications AS7011 1124 677 447 39.8% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. AS18101 667 225 442 66.3% RIL-IDC Reliance Infocom Ltd Internet Data Centre, Total 37063 10901 26162 70.6% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.202.96.0/19 AS29571 CITelecom-AS 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS26452 BRING-AS - BringCom, Inc. 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.216.90.0/24 AS12731 IPHH IPHH Internet Port Hamburg GmbH 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.160.200.0/23 AS45122 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 195.210.26.0/23 AS48344 NETZWERK68A Sven Wefels - Netzwerk 68a 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.233.129.0/24 AS4378 HOSTINGCOM - WCP/32POINTS INTERMEDIATE HOLDING COMPANY, INC. 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.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.66.152.0/24 AS18499 208.66.153.0/24 AS18499 208.66.154.0/24 AS18499 208.66.155.0/24 AS18499 208.66.156.0/24 AS18499 208.66.157.0/24 AS18499 208.66.158.0/24 AS18499 208.66.159.0/24 AS18499 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.160.0/24 AS18499 209.177.161.0/24 AS18499 209.177.162.0/24 AS18499 209.177.163.0/24 AS18499 209.177.164.0/24 AS18499 209.177.165.0/24 AS18499 209.177.166.0/24 AS18499 209.177.167.0/24 AS18499 209.177.168.0/24 AS18499 209.177.169.0/24 AS18499 209.177.170.0/24 AS18499 209.177.171.0/24 AS18499 209.177.172.0/24 AS18499 209.177.173.0/24 AS18499 209.177.174.0/24 AS18499 209.177.175.0/24 AS18499 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From kaeo at merike.com Fri May 14 17:21:45 2010 From: kaeo at merike.com (Merike Kaeo) Date: Fri, 14 May 2010 15:21:45 -0700 Subject: ipv6 transit over tunneled connection In-Reply-To: <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> Message-ID: On May 14, 2010, at 1:36 PM, Jared Mauch wrote: > > On May 14, 2010, at 3:43 PM, Brielle Bruns wrote: > >> (Sent from my Blackberry, please avoid the flames as I can't do >> inline quoting) >> >> >> Native IPv6 is a crapshoot. About the only people in the US that >> I've seen that are no-bullshit IPv6 native ready is Hurricane >> Electric. NTT is supposedly as well but I can't speak as to where >> they have connectivity. > > I can say that we (NTT) have been IPv6 enabled or ready at all > customer ports since ~2003. Anyone else who has not gotten there > in the intervening years may have problems supporting you for your > IPv4 as well :) I had native eBGP with NTT in Dec 2005......this is when I was working with Connection By Boeing in Seattle. Worked like a charm. And yes, since I now live in Seattle, I have heard of some others doing native although haven't validated. > >> Being that there's issues that leave us unable to get native >> connectivity, we have a BGP tunnel thanks to HE (with a 20ms >> latency from Seattle to Freemont). > > You should be able to get native IPv6 in Seattle from a variety of > providers. If you're not finding it, you're not really looking > (IMHO). I'd 2nd that.... > >> Tunnels suck if not done correctly. We sometimes have faster and >> more reliable connections through IPv6, so ymmv. > > The tunneled part of the "IPv6" internet fell to the wayside a long > time ago, there are stragglers and I have even seen people try to > peer over tunnels in 2010, but anyone still adding that level of > overlay (v6-over-v4) may find themselves in a world of hurt soon > enough. > > - Jared (Curious about what incumbent carrier plans are for end- > user - eg qwest, att, vz resi) From kauer at biplane.com.au Fri May 14 17:44:53 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 15 May 2010 08:44:53 +1000 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> Message-ID: <1273877093.27133.18.camel@karl> On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote: > Tunnels promote poor paths "promote"? Tunnel topology does not (necessarily) match the underlying topology, especially if you choose (or are forced to accept) a distant broker. But "promote"? > , they bring along LOTS of issues wrt PMTUD, PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that a bad PMTU can wreak more havoc on v6 than v4, but most of the issues are workaroundable. > asymmetry of paths, improper/inefficient paths (see example paths from > several ripe preso's by jereon/others), longer latency. All relating to the above. I suspect you really mean paths in the underlying topology, which is a "by definition" issue. None of these are necessary features of tunnels. Given the relatively low number of tunnel terminating services, and the fairly low level of choice available to people who want tunnels, these are bigger problems than they need to be. More demand will see these problems (as with so many transitional issues) lessen substantially. > If the tunnel > exits your border you can't control what happens and you can't affect > that tunnels performance characteristics. Whereas with IPv4 you have complete control over everything that happens once packets exit your border? This is no different with IPv6 than with IPv4, except that you have fewer choices at present, so must make more drastic compromises. > it's 2010, get native v6. Easily said :-( If you can't get native IPv6, then using a tunnel lets you get started; it lets you begin educating, testing and even delivering IPv6-based services. If, on the other hand, you wait until everything is perfect, you will be waaaay behind the eight-ball. Oh - and tunnels are usually way cheaper than native connectivity, so it's easier to get the idea of going v6 past the bean-counters. So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But whichever you do, do it now. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sethm at rollernet.us Fri May 14 17:49:37 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 14 May 2010 15:49:37 -0700 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> <4BED9DE4.6020609@rollernet.us> Message-ID: <4BEDD381.1060302@rollernet.us> On 5/14/2010 12:44, Christopher Morrow wrote: > On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen wrote: >> On 5/14/2010 11:49, Jared Mauch wrote: >>> I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. >>> >>> I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. >>> >>> What parts of the big "I" Internet are not enabled or ready? >>> >> >> Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if >> you're closer to one of those (currently on month 11 of waiting, I'm >> just letting it go because I'm curious how long it'll take), Sprint >> isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility >> is poor, Level3 isn't accepting new IPv6 "beta" connections, and AT&T >> simply told me not available yet. >> >> Tunnels are still a necessity. > > twt, ntt, gblx, telia all have presence in the US, and all do v6 to > customer links. vote with wallet. Yeah I hear that a lot, but out of those four the only one that will serve my area is global crossing. ~Seth From tme at americafree.tv Fri May 14 17:52:37 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 14 May 2010 18:52:37 -0400 Subject: POE switches and lightning In-Reply-To: <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> Message-ID: <0D485411-B0F2-4E0B-B8E3-3148081B1BC4@americafree.tv> On May 13, 2010, at 2:26 PM, Mark Mayfield wrote: > About a month ago, we had a lightning strike near our main campus. > We lost one POE Cisco 3560 completely (apparently blown power > supply), and in a separate but nearby building, another 3560 lost > the ability to deliver POE, but continued to operate as a switch. > Both had to be replaced. Both were on wiring closet type UPS'es with > surge suppression, and those were unaffected. > > Mark > > -----Original Message----- > From: Caleb Tennis [mailto:caleb.tennis at gmail.com] > Sent: Thursday, May 13, 2010 10:37 AM > To: North American Network Operators Group > Subject: POE switches and lightning > > We had a lightning strike nearby yesterday that looks to have come > inside our facility via a feeder circuit that goes outdoors > underground to our facility's gate. > > What's interesting is that various POE switches throughout the > entire building seemed to be affected in that some of their ports > they just shut down/off. Rebooting these switches brought > everything back to life. It didn't impact anything non-POE, and > even then, only impacted some devices. But it was spread across the > whole building, across multiple switches. > > I was just curious if anyone had seen anything similar to this > before? Our incoming electrical power has surge suppression, and > the power to the switches is all through double conversion UPS, so > I'm not quite sure why any of them would have been impacted at all. > I'm guessing that the strike had some impact on the electrical > ground, but I don't know what we can do to prevent future strikes > from causing the same issues. Thoughts? > > It is not clear to me from the above if there are copper circuits coming into the building, but lightning can certainly zap those as well. In very high impact areas (such as mountaintops or Miami) it is a good idea to mandate that all incoming / outgoing circuits are on fiber, without exception. Marshall > > Confidentiality Statement: The documents accompanying this > transmission contain confidential information that is legally > privileged. This information is intended only for the use of the > individuals or entities listed above. If you are not the intended > recipient, you are hereby notified that any disclosure, copying, > distribution, or action taken in reliance on the contents of these > documents is strictly prohibited. If you have received this > information in error, please notify the sender immediately and > arrange for the return or destruction of these documents. > > From owen at delong.com Fri May 14 17:50:28 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 14 May 2010 15:50:28 -0700 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> Message-ID: <33E59B3A-027E-4BE7-8A32-7F7918283BF6@delong.com> On May 14, 2010, at 11:57 AM, Christopher Morrow wrote: > On Fri, May 14, 2010 at 2:29 PM, Franck Martin wrote: >> I said somewhere in here... wierd quoting happened. >> On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy >> wrote: >>> Hello, >>> >>> We're in the early stage of planning ipv6 deployment - >>> learning/labbing/experimenting/etc. We've got to the point when we're >>> also planning to request initial ipv6 allocation from ARIN. >>> So I wonder what ipv6 transit options I have if my upstreams do not >>> support native ipv6 connectivity? >>> I see Hurricane Electric tunnel broker BGP tunnel. Is there anything >>> else? Either free or commercial? >> >> 1) see gblx/ntt/sprint/twt/vzb for transit-v6 >> 2) tunnel inside your domain (your control, your MTU issues, your >> alternate pathing of tunnels vs pipe) >> 3) don't tunnel beyond your borders, really just don't >> >> tunnels are bad, always. >> -chris >> >> I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you >> cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 >> states the use of tunnels). > > Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, > asymmetry of paths, improper/inefficient paths (see example paths from > several ripe preso's by jereon/others), longer latency. If the tunnel > exits your border you can't control what happens and you can't affect > that tunnels performance characteristics. it's 2010, get native v6. > I will point out that most of these issues apply to 6to4 and Teredo auto- tunnels and not as much to GRE or 6in4 statically configured tunnels. There is a juniper bug which makes PMTU-D a problem if your tunnel is Juniper<->Juniper. >> If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. >> With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in >> IPv6 tunnels, how will we work with jumbo packets? > > a non-negligible part of the ipv6 internet doesn't work at all with >> 1280 mtu... due to tunnels and some other hackery :( jumbo packets > are a fiction, everyone should stop 10 years ago believing they will > ever work end-to-end between random sites. > Jumbo packets do work end to end in some random cases and PMTU-D works in most others. All of the tunnels I am using have at least a 1280 MTU, so, I'm not sure why you would think a tunnel wouldn't support 1280. Owen From owen at delong.com Fri May 14 17:58:06 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 14 May 2010 15:58:06 -0700 Subject: ipv6 transit over tunneled connection In-Reply-To: <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> Message-ID: <7C77D97A-5071-4B83-8704-DD4C286D3CAF@delong.com> On May 14, 2010, at 1:36 PM, Jared Mauch wrote: > > On May 14, 2010, at 3:43 PM, Brielle Bruns wrote: > >> (Sent from my Blackberry, please avoid the flames as I can't do inline quoting) >> >> >> Native IPv6 is a crapshoot. About the only people in the US that I've seen that are no-bullshit IPv6 native ready is Hurricane Electric. NTT is supposedly as well but I can't speak as to where they have connectivity. > > I can say that we (NTT) have been IPv6 enabled or ready at all customer ports since ~2003. Anyone else who has not gotten there in the intervening years may have problems supporting you for your IPv4 as well :) > True. >> Being that there's issues that leave us unable to get native connectivity, we have a BGP tunnel thanks to HE (with a 20ms latency from Seattle to Freemont). > > You should be able to get native IPv6 in Seattle from a variety of providers. If you're not finding it, you're not really looking (IMHO). > Depends. If he's in the Westin or some other colo, sure. If not, he may have last-mile expenses that exceed sanity for his situation leading to a tunneled solution. >> Tunnels suck if not done correctly. We sometimes have faster and more reliable connections through IPv6, so ymmv. > > The tunneled part of the "IPv6" internet fell to the wayside a long time ago, there are stragglers and I have even seen people try to peer over tunnels in 2010, but anyone still adding that level of overlay (v6-over-v4) may find themselves in a world of hurt soon enough. > I have to disagree with you here. Given the proportion of the IPv6 internet that is still connected via tunnels, your statement simply doesn't really hold. I will readily agree that where possible, native connections beat tunnels. However, tunnels can be a cost effective alternative where native connectivity is not yet readily available and they still work quite well if properly configured and structured. Owen From if at xip.at Fri May 14 18:42:45 2010 From: if at xip.at (Ingo Flaschberger) Date: Sat, 15 May 2010 01:42:45 +0200 (CEST) Subject: POE switches and lightning In-Reply-To: <0D485411-B0F2-4E0B-B8E3-3148081B1BC4@americafree.tv> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> <0D485411-B0F2-4E0B-B8E3-3148081B1BC4@americafree.tv> Message-ID: >> We had a lightning strike nearby yesterday that looks to have come inside >> our facility via a feeder circuit that goes outdoors underground to our >> facility's gate. Perhaps there was a "move" of the earth-level relative to the neutral line. I have no idea how neutral-line to earth potential is handled in us, but here in austria we use a so called "nullung". That means that the earth-ground potential line of the building (which includes also the lightning conductor) is connected to the neutral power line where it enters the building, keeping this potential-difference low. Theres also a potential between earth ground and the neutral-phase of the online-ups. The ethernet-cables; utp or stp? pannels correctly earthed? Perhaps a electrician should check the earthing. Also all copper lines that enter the building should be protected by lightning protectors. Kind regards, Ingo Flaschberger From jahiel at gmail.com Fri May 14 18:52:38 2010 From: jahiel at gmail.com (Graham Freeman) Date: Fri, 14 May 2010 16:52:38 -0700 Subject: Contacts re email deliverability problem to tmomail.net? Message-ID: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> Hi, folks, A client of mine is having trouble delivering (legitimate) email to tmomail.net, and I'm having trouble finding the right contact. (e.g. postmaster bounced). I've verified the legitimate nature of the email (only user-initiated, and nothing more), the valid SPF, A, PTR, and MX records, etc. We're also having no trouble sending the equivalent messages to the email-to-SMS gateways at ATT Wireless, Verizon Wireless, Sprint, etc. Any suggestions for the best points of contact at T-Mobile USA (tmomail.net)? thanks! Graham Freeman graham.freeman at cernio.com (Email/Jabber/SIP) +1 415 462 2991 (office) From sethm at rollernet.us Fri May 14 19:00:44 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 14 May 2010 17:00:44 -0700 Subject: POE switches and lightning In-Reply-To: References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> <0D485411-B0F2-4E0B-B8E3-3148081B1BC4@americafree.tv> Message-ID: <4BEDE42C.5050701@rollernet.us> On 5/14/2010 16:42, Ingo Flaschberger wrote: >>> We had a lightning strike nearby yesterday that looks to have come >>> inside our facility via a feeder circuit that goes outdoors >>> underground to our facility's gate. > > Perhaps there was a "move" of the earth-level relative to the neutral line. > I have no idea how neutral-line to earth potential is handled in us, but > here in austria we use a so called "nullung". > That means that the earth-ground potential line of the building (which > includes also the lightning conductor) is connected to the neutral power > line where it enters the building, keeping this potential-difference low. > In the US neutral and earth ground are supposed to be bonded only once at the service entrance. A separate ground from the neutral conductor is carried to sub-panels where is it not bonded. Additional bonding can cause weirdness and will turn the ground into a current carrying conductor. However, an older building I used to be in (built 1978) only gave me a neutral with bonded subs, so you'll run into all kinds of stuff depending on the age of the building. Working at a university was particularly interesting with of the vast range of building ages. ~Seth From LarrySheldon at cox.net Fri May 14 19:17:40 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 14 May 2010 19:17:40 -0500 Subject: POE switches and lightning In-Reply-To: <4BEDE42C.5050701@rollernet.us> References: <6DECDD46-48BC-46C2-9894-16A0FC4A14BB@gmail.com> <96CD2407B3027C4DACC7A0222BD3C4789FA41C0651@RVMAIL802.metro-inet.us> <0D485411-B0F2-4E0B-B8E3-3148081B1BC4@americafree.tv> <4BEDE42C.5050701@rollernet.us> Message-ID: <4BEDE824.1090700@cox.net> On 5/14/2010 19:00, Seth Mattinen wrote: > On 5/14/2010 16:42, Ingo Flaschberger wrote: >>>> We had a lightning strike nearby yesterday that looks to have come >>>> inside our facility via a feeder circuit that goes outdoors >>>> underground to our facility's gate. >> >> Perhaps there was a "move" of the earth-level relative to the neutral line. >> I have no idea how neutral-line to earth potential is handled in us, but >> here in austria we use a so called "nullung". >> That means that the earth-ground potential line of the building (which >> includes also the lightning conductor) is connected to the neutral power >> line where it enters the building, keeping this potential-difference low. >> > > In the US neutral and earth ground are supposed to be bonded only once > at the service entrance. A separate ground from the neutral conductor is > carried to sub-panels where is it not bonded. Additional bonding can > cause weirdness and will turn the ground into a current carrying > conductor. However, an older building I used to be in (built 1978) only > gave me a neutral with bonded subs, so you'll run into all kinds of > stuff depending on the age of the building. Working at a university was > particularly interesting with of the vast range of building ages. In my experience, each building has a building ground-point at the service entrance, as outlined. I the problem in a campus on some soils is that building grounds might be several volts apart--except during thunder storms when the voltage difference might be (it appears) thousands of volts, and with a lightning strike to one of them many thousands of volts. That is why I argue for glass only between buildings. I don't care how much PoE saves. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jarenangerbauer at gmail.com Fri May 14 19:23:58 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Fri, 14 May 2010 18:23:58 -0600 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> Message-ID: On Fri, May 14, 2010 at 5:52 PM, Graham Freeman wrote: > A client of mine is having trouble delivering (legitimate) email to tmomail.net, and I'm having trouble finding the right contact. I just tested, and was able to successfully send an email to my Tmobile address [myphone#]@tmomail.net. Are you getting bounces / failures back that are of any use? Also FWIW (and sanity check) any reason why your client wants to use email-to-SMS, rather than just SMS. From what I understand email-to-sms isn't the best platform for getting messages to mobile devices but I may be missing some client-specific visibility. --Jaren From jahiel at gmail.com Fri May 14 19:33:59 2010 From: jahiel at gmail.com (Graham Freeman) Date: Fri, 14 May 2010 17:33:59 -0700 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> Message-ID: <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> On 14 May 10, at 17:23 , Jaren Angerbauer wrote: > I just tested, and was able to successfully send an email to my > Tmobile address [myphone#]@tmomail.net. Are you getting bounces / > failures back that are of any use? Also FWIW (and sanity check) any > reason why your client wants to use email-to-SMS, rather than just > SMS. From what I understand email-to-sms isn't the best platform for > getting messages to mobile devices but I may be missing some > client-specific visibility. Hi, Jaren, Delivering SMS-to-SMS would be impractical and prohibitively expensive. This is for an iPhone messaging app that optionally delivers messages to SMS recipients for free. The business model depends on email-to-SMS gateways. Like you, we were able to deliver messages in low volumes, but as the app became increasingly popular (at one point in the Top 20 in the App Store) the volume exceeded a opaque-to-us rate limit at Tmobile, but not at other mobile providers - some of whom we're sending many more messages than we ever tried to deliver to Tmobile. Two examples out of thousands: >> Apr 30 23:52:52 pomelo.borange.com postfix/error[17836]: [ID 197553 mail.info] D44451D9570: to=<[xxxxxxxxxx]@tmomail.net>, relay=none, delay=80196, delays=80195/0.18/0/0, dsn=4.0.0, status=deferred (delivery temporarily suspended: host mm3.tmomail.net[66.94.25.228] refused to talk to me: 421 mail.tmail.com closing connection) >> >> May 1 16:17:58 pomelo.borange.com postfix/smtp[24906]: [ID 197553 mail.info] 7CC5D1E9D7F: to=<[xxxxxxxxxx]@tmomail.net>, relay=mm3.tmomail.net[66.94.9.228]:25, delay=59233, delays=59229/0/4.2/0, dsn=4.0.0, status=deferred (host mm3.tmomail.net[66.94.9.228] refused to talk to me: 421 mail.tmail.com closing connection) thanks, Graham From aiverson at spamresource.com Fri May 14 19:51:55 2010 From: aiverson at spamresource.com (Al Iverson) Date: Fri, 14 May 2010 19:51:55 -0500 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> Message-ID: On Fri, May 14, 2010 at 7:33 PM, Graham Freeman wrote: > Delivering SMS-to-SMS would be impractical and prohibitively expensive. ?This is for an iPhone messaging app that optionally delivers messages to SMS recipients for free. ?The business model depends on email-to-SMS gateways. I'm surprised more gateways aren't rate limiting or blocking you; my experience with these services is such that the providers really want you to utilize SMS instead, if you build up any sort of significant volume. I've certainly seen multiple providers delay this inbound mail periodically. Cheers, Al Iverson From mike at m5computersecurity.com Fri May 14 19:57:22 2010 From: mike at m5computersecurity.com (Michael J McCafferty) Date: Fri, 14 May 2010 17:57:22 -0700 Subject: Stand alone voltage/etc monitoring? Message-ID: <1273885042.873.241.camel@mike-desktop> NANOG, How can I best monitor power quality (ie: voltage, etc) as a colo customer? We monitor temperature and humidity in multiple places on each floor we are on, network bandwidth/errors/latency/pps/link-state on every link, power used per circuit, tons of metrics on servers, but I can't seem to find a simple and small way to monitor voltage, etc. I looked in the routers, cabinet-level switched power-strips (CDUs), switches, and servers, and I don't see anything we already have that can report that info. I see there are probably some small UPSes ($400 or so) that can report this info. Seems silly to buy UPSes to get that info. Is there a quick/small/handy/better way to get power quality info? If so, what is it? I don't own the facility. Thanks! Mike -- ************************************************************ Michael J. McCafferty Principal M5 Hosting http://www.m5hosting.com You can have your own custom Dedicated Server up and running today ! RedHat Enterprise, CentOS, Ubuntu, Debian, OpenBSD, FreeBSD, and more ************************************************************ From bmanning at vacation.karoshi.com Fri May 14 20:31:37 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sat, 15 May 2010 01:31:37 +0000 Subject: ipv6 transit over tunneled connection In-Reply-To: <1273877093.27133.18.camel@karl> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <1273877093.27133.18.camel@karl> Message-ID: <20100515013137.GA4479@vacation.karoshi.com.> er... if I may - this whining about the evils of tunnels rings a bit hollow, esp for those who think that a VPN is the right thing to do. --bill On Sat, May 15, 2010 at 08:44:53AM +1000, Karl Auer wrote: > On Fri, 2010-05-14 at 14:57 -0400, Christopher Morrow wrote: > > Tunnels promote poor paths > > "promote"? Tunnel topology does not (necessarily) match the underlying > topology, especially if you choose (or are forced to accept) a distant > broker. But "promote"? > > > , they bring along LOTS of issues wrt PMTUD, > > PMTUD that doesn't work on v6 probably doesn't work on v4. I agree that > a bad PMTU can wreak more havoc on v6 than v4, but most of the issues > are workaroundable. > > > asymmetry of paths, improper/inefficient paths (see example paths from > > several ripe preso's by jereon/others), longer latency. > > All relating to the above. I suspect you really mean paths in the > underlying topology, which is a "by definition" issue. None of these are > necessary features of tunnels. > > Given the relatively low number of tunnel terminating services, and the > fairly low level of choice available to people who want tunnels, these > are bigger problems than they need to be. More demand will see these > problems (as with so many transitional issues) lessen substantially. > > > If the tunnel > > exits your border you can't control what happens and you can't affect > > that tunnels performance characteristics. > > Whereas with IPv4 you have complete control over everything that happens > once packets exit your border? This is no different with IPv6 than with > IPv4, except that you have fewer choices at present, so must make more > drastic compromises. > > > it's 2010, get native v6. > > Easily said :-( > > If you can't get native IPv6, then using a tunnel lets you get started; > it lets you begin educating, testing and even delivering IPv6-based > services. If, on the other hand, you wait until everything is perfect, > you will be waaaay behind the eight-ball. > > Oh - and tunnels are usually way cheaper than native connectivity, so > it's easier to get the idea of going v6 past the bean-counters. > > So: Yep, native IPv6 if you can get it. Otherwise, take tunnels. But > whichever you do, do it now. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) > > GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF From bruns at 2mbit.com Fri May 14 20:58:42 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Fri, 14 May 2010 19:58:42 -0600 Subject: ipv6 transit over tunneled connection In-Reply-To: <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> Message-ID: <4BEDFFD2.2080509@2mbit.com> On 5/14/10 2:36 PM, Jared Mauch wrote: >> Being that there's issues that leave us unable to get native >> connectivity, we have a BGP tunnel thanks to HE (with a 20ms >> latency from Seattle to Freemont). > > You should be able to get native IPv6 in Seattle from a variety of > providers. If you're not finding it, you're not really looking > (IMHO). I can almost guarantee that noone can give us the level of service we get for the price we do - did an awful lot of research back in 2008 to find a new co-loc. We've also had nearly perfect uptime with the only downtime being caused by our own growing pains with equipment that has obsecure bugs relating to ipv4 and ipv6 BGP interactions. Changing providers isn't really an option for us as alternatives are guaranteed to push us over budget. $$$$ is a limiting factor for us since we're not a business focused on profit. Tunneling is our only option at this point. > >> Tunnels suck if not done correctly. We sometimes have faster and >> more reliable connections through IPv6, so ymmv. > > The tunneled part of the "IPv6" internet fell to the wayside a long > time ago, there are stragglers and I have even seen people try to > peer over tunnels in 2010, but anyone still adding that level of > overlay (v6-over-v4) may find themselves in a world of hurt soon > enough. I'm willing to run the risk that my tunneled connection may have problems - its part of the game of being on the leading edge. This is not directed at anyone in particular, but people forget that not everyone has thousands, tens of thousands, hundreds of thousands, etc of money in their budget to accomplish their goals. There are people out there, such as ourselves, that have a very limited budget to work within each month/year. Some of us do what we do out of our own pockets because we like doing it. For example, people have called me crazy for running P3 and P4 era HP DL360/380s instead of the new generation stuff, but those nice new servers cost serious coin, and I don't see people stepping up to fund these upgrades. Just an observation, but I'm fairly sure that I'm not the only one who feels that those with rather high budgets tend to forget that not everyone has the luxury of a virtual blank check. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From khuon at neebu.net Fri May 14 22:18:22 2010 From: khuon at neebu.net (Jake Khuon) Date: Sat, 15 May 2010 03:18:22 +0000 Subject: Stand alone voltage/etc monitoring? In-Reply-To: <1273885042.873.241.camel@mike-desktop> References: <1273885042.873.241.camel@mike-desktop> Message-ID: <1273893502.24072.25.camel@localhost> On Fri, 2010-05-14 at 17:57 -0700, Michael J McCafferty wrote: > I see there are probably some small UPSes ($400 or so) > that can report this info. Seems silly to buy UPSes to get that info. > > Is there a quick/small/handy/better way to get power quality info? If > so, what is it? I don't own the facility. I've looked at various inline power monitoring appliances solutions and honestly, most of them will cost more than a small UPS. The question is, where do you want to monitor the voltage? At the input side of the rack-PDU? Are your PDUs manageable? Do you want to monitor voltage to each device (output side of the PDU)? Or do you just want to sample monitor on the side (as opposed to inline) and fed from the same circuit feeding the input side of your PDUs assuming all your equipment/PDUs are receiving the same power quality? I monitor at the UPS for my home systems. My UPSes are APC brand. A SmartUPS 500 w/Web/SNMP card will run you about $350 to $400 and you poll them for input voltage and frequency. Here's a snapshot from a couple of years ago... I do have dirty power. http://farm1.static.flickr.com/226/464847907_c3038c21e4_o.png -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From mulitskiy at acedsl.com Fri May 14 22:25:10 2010 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Fri, 14 May 2010 23:25:10 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <201005131818.12316.mulitskiy@acedsl.com> References: <201005131818.12316.mulitskiy@acedsl.com> Message-ID: <201005142325.10617.mulitskiy@acedsl.com> Guys, I've started this thread looking for advice on available options. There's no doubt in my mind that native connectivity is better than tunnels, but unfortunately tunnel is the only way to get me started, 'cause my upstream does not support ipv6 (hopefully just yet) and I have no budget for additional circuits to ipv6-enabled carrier. So my question still stands: is anyone aware of a reasonable tunneled ipv6 transit service (I mean aside from HE tunnel broker)? The load will be really light. I don't expect we'll break a few Mbit/s in the nearest future and when we do then I guess it'll be the time to look for the native transit. Thanks, Michael On Thursday 13 May 2010 18:18:12 Michael Ulitskiy wrote: > Hello, > > We're in the early stage of planning ipv6 deployment - > learning/labbing/experimenting/etc. We've got to the point when we're also > planning to request initial ipv6 allocation from ARIN. So I wonder what > ipv6 transit options I have if my upstreams do not support native ipv6 > connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there > anything else? Either free or commercial? Thanks, > > Michael > From morrowc.lists at gmail.com Fri May 14 22:30:14 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 May 2010 23:30:14 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <4BEDFFD2.2080509@2mbit.com> References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> <4BEDFFD2.2080509@2mbit.com> Message-ID: On Fri, May 14, 2010 at 9:58 PM, Brielle Bruns wrote: > > Just an observation, but I'm fairly sure that I'm not the only one who feels > that those with rather high budgets tend to forget that not everyone has the > luxury of a virtual blank check. > awesome, take an old 2800 or 2500, plug in a t1 to one of the providers listed (twt seems like a great choice, or atlantech, who I think also does v6 and seems to offer 300$/mon t1's regularly), run v6 ONLY on that, take the 10/100m ether out the back and v6-up the rest of your network. See, done for 300$/month... the reason I said 'find a provider that does do native v6, terminate there and tunnel or spread-out internally from there' was exactly because spending 'tens of thousands of dollars' right off the bat was probably hard to justify. thanks though. -chris From morrowc.lists at gmail.com Fri May 14 22:32:54 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 14 May 2010 23:32:54 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <201005142325.10617.mulitskiy@acedsl.com> References: <201005131818.12316.mulitskiy@acedsl.com> <201005142325.10617.mulitskiy@acedsl.com> Message-ID: On Fri, May 14, 2010 at 11:25 PM, Michael Ulitskiy wrote: > So my question still stands: is anyone aware of a reasonable tunneled ipv6 > transit service (I mean aside from HE tunnel broker)? The load will be really > light. I don't expect we'll break a few Mbit/s in the nearest future and when > we do then I guess it'll be the time to look for the native transit. beware the uTorrent ... (see johnb's notes about this) sixxs i think also had NYC based tunnel boxes, no? usewr01 OCCAID Inc. uschi02 Your.Org, Inc. and I think kloch @carpathia was doing some of this for a time, though perhaps only ASH/PHX ? -chris From aj at sneep.net Sat May 15 00:04:18 2010 From: aj at sneep.net (Alastair Johnson) Date: Sat, 15 May 2010 13:04:18 +0800 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> References: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> Message-ID: <4BEE2B52.8020007@sneep.net> Mark Foster wrote: > Thus the wider concern I flagged; if the only source for equipment and > spares is the grey market, aren't the vendors missing the boat on > something which shouldn't even have a major overhead to maintain? There is no sales of new chassis, which means the manufacturing is shut down. The costs to maintain support and spares for an obsolete platform with a declining customer base and no further sales is quite high for the vendor. If they charged the real cost to provide support to the operator, most likely the operator wouldn't take the support contract. End result: end of support. If the operator /really/ needs to keep it going, they'll figure out a way to spare it. Telcos have been specialists in this regard for a long time. > What about developing nations where Internet isn't yet as commonplace as > it is in the 'west' ? They skip dialup. From joelja at bogus.com Sat May 15 00:55:50 2010 From: joelja at bogus.com (joel jaeggli) Date: Fri, 14 May 2010 22:55:50 -0700 Subject: Dial Concentrators - TNT / APX8000 R.I.P. In-Reply-To: <4BEE2B52.8020007@sneep.net> References: <9db7d259df24cfc20e6fde7402bf5335.squirrel@webmail.blakjak.net> <4BEE2B52.8020007@sneep.net> Message-ID: <4BEE3766.8090507@bogus.com> On 2010-05-14 22:04, Alastair Johnson wrote: > Mark Foster wrote: >> What about developing nations where Internet isn't yet as commonplace as >> it is in the 'west' ? > > They skip dialup. > dial modems are the end game for a 140 year old technology (300-3400hz pots lines). There is literally no reason if you don't already have that infrastructure that you would expend capital to replicate that sort of physical plant. From graham at apolix.co.za Sat May 15 03:37:37 2010 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 15 May 2010 10:37:37 +0200 Subject: Stand alone voltage/etc monitoring? In-Reply-To: <1273885042.873.241.camel@mike-desktop> References: <1273885042.873.241.camel@mike-desktop> Message-ID: <4BEE5D51.2020400@apolix.co.za> On 2010/05/15 02:57 AM, Michael J McCafferty wrote: > Is there a quick/small/handy/better way to get power quality info? If > so, what is it? I don't own the facility. The modern digital utility meters have extensive monitoring for power quality. We have been using meters from EDMI[1] that can report and record voltage, current, power factor, voltage and current waveforms, harmonics, demand profiles and many other things. The meters have serial interfaces and are fairly easy to connect up for remote access. [1] http://www.edmi-meters.com/ -- Graham Beneke graham at apolix.co.za | Apolix Internet Services Tel : +27-87-550-1010 | http://www.apolix.co.za/ Cell: +27-82-432-1873 | PO Box 1120 Skype: grbeneke | Melville, 2109 From graham at apolix.co.za Sat May 15 03:56:36 2010 From: graham at apolix.co.za (Graham Beneke) Date: Sat, 15 May 2010 10:56:36 +0200 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <201005131818.12316.mulitskiy@acedsl.com> Message-ID: <4BEE61C4.2000207@apolix.co.za> On 2010/05/14 03:39 AM, Christopher Morrow wrote: > 3) don't tunnel beyond your borders, really just don't We have managed to achieve that fairly well. We have colocated a single router in a provider in London with native IPv6 where we have our primary break out. We then tunnel over IPv4 between this router and our core. The tunneling protocol provides transparent L2 frame reassembly so we have MTU 1500 all the way to the edge of the network. -- Graham Beneke graham at apolix.co.za | Apolix Internet Services Tel : +27-87-550-1010 | http://www.apolix.co.za/ Cell: +27-82-432-1873 | PO Box 1120 Skype: grbeneke | Melville, 2109 From jeroen at unfix.org Sat May 15 05:43:17 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Sat, 15 May 2010 12:43:17 +0200 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <201005131818.12316.mulitskiy@acedsl.com> <201005142325.10617.mulitskiy@acedsl.com> Message-ID: <4BEE7AC5.9060400@unfix.org> On 2010-05-15 05:32, Christopher Morrow wrote: > On Fri, May 14, 2010 at 11:25 PM, Michael Ulitskiy wrote: > >> So my question still stands: is anyone aware of a reasonable tunneled ipv6 >> transit service (I mean aside from HE tunnel broker)? The load will be really >> light. I don't expect we'll break a few Mbit/s in the nearest future and when >> we do then I guess it'll be the time to look for the native transit. > > beware the uTorrent ... (see johnb's notes about this) > sixxs i think also had NYC based tunnel boxes, no? usewr01 is Newark, thus quite close. uschi02 is Chicago (UN/LOCODE++) thus not really around the corner unless you compare it to Tokio... SixXS never does transit/BGP though*. We only provide IPv6 connectivity to end-sites, thus to solve the problem where the last-mile cannot be IPv6 enabled, which is the general case for businesses and home users where their ISP didn't come around to enabling IPv6 (CPE's, DSLAM's, DOCSIS, it is getting there, but still generally a b**** ;) (* = http://www.sixxs.net/faq/connectivity/?faq=bgppeering) Core networks should be non-tunneled. It is silly to have to need a tunnel to another network to get IPv6 uplink connectivity. If you really are in a position that nobody else in the IXs you are present at can provide native IPv6 connectivity, then well, you should have started yelling about this years ago. See http://www.sixxs.net/faq/connectivity/?faq=ipv6transit with relevant links to the awesome peeringdb to figure out from whom you could be directly Yes, a tunnel is a good last-resort, but one is better off pushing for native IPv6. As for doing tunneled-BGP, come kids, the 6bone got shut down 4 years ago, for a reason... As for the places that you can't get native IPv6 transit, two words: business opportunity. That should light up the eyes of the folks who didn't realize what IPv6 is for some companies... there is an obvious example of a certain company which is playing their cards pretty well there, the question for them is though how long they can survive when the real big boys turn on their marketing engines, time will tell. [..] > and I think kloch @carpathia was doing some of this for a time, though > perhaps only ASH/PHX ? He is the one providing usqas01 (the IPv4/hosting part). Ping him directly though for other things. Greets, Jeroen From nick at foobar.org Sat May 15 05:48:03 2010 From: nick at foobar.org (Nick Hilliard) Date: Sat, 15 May 2010 11:48:03 +0100 Subject: ipv6 transit over tunneled connection In-Reply-To: References: <235599705-1273866306-cardhu_decombobulator_blackberry.rim.net-2110548843-@bda895.bisx.prod.on.blackberry> <06E17606-DA47-4CCF-98CF-845520287754@puck.nether.net> <4BEDFFD2.2080509@2mbit.com> Message-ID: <2EA2A8DE-E9ED-4498-836D-6064A5E1E1E7@foobar.org> On 15 May 2010, at 04:30, Christopher Morrow wrote: > See, done for 300$/month... $300/month + the cost of building fossils into your network on day 1. This cost is a whole pile more difficult to quantify than basic PoP service capex/opex, but it's recurrent and non zero. Nick From jarenangerbauer at gmail.com Sat May 15 10:29:07 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Sat, 15 May 2010 09:29:07 -0600 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> Message-ID: On Fri, May 14, 2010 at 6:51 PM, Al Iverson wrote: > I'm surprised more gateways aren't rate limiting or blocking you; my > experience with these services is such that the providers really want > you to utilize SMS instead, if you build up any sort of significant > volume. I've certainly seen multiple providers delay this inbound mail > periodically. Al beat me to responding to this, but +1 on his comment. IIUC, the email-to-sms is definitely not for commercial use (as in an iPhone app), and is more for 1 to 1 type communications. If your client is looking to build a business around SMS communications, they need to make the investment to use the standard SMS platforms. --Jaren From jahiel at gmail.com Sat May 15 17:38:22 2010 From: jahiel at gmail.com (Graham Freeman) Date: Sat, 15 May 2010 15:38:22 -0700 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> Message-ID: <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> > > On Fri, May 14, 2010 at 6:51 PM, Al Iverson wrote: >> I'm surprised more gateways aren't rate limiting or blocking you; my >> experience with these services is such that the providers really want >> you to utilize SMS instead, if you build up any sort of significant >> volume. I've certainly seen multiple providers delay this inbound mail >> periodically. Hi, Al, That may be, but it would surprise me. The carriers still get paid by virtue of charging the recipients for the SMSes, and in this particular case cutting off this line of communication is leaving money on the table, as email->SMS deliverability is desired yet optional/secondary functionality of the app. On 15 May 10, at 08:29 , Jaren Angerbauer wrote: > > Al beat me to responding to this, but +1 on his comment. IIUC, the > email-to-sms is definitely not for commercial use (as in an iPhone > app), and is more for 1 to 1 type communications. If your client is > looking to build a business around SMS communications, they need to > make the investment to use the standard SMS platforms. > > --Jaren Hi, Jaren, There appears to be a misunderstanding. The messages in question are in fact 1:1 interpersonal communication between my client's customers (the people who use my client's iPhone messaging app) and their correspondents (to whom we're trying to deliver via the email->SMS gateway). We're not sending ads, newsletters, or other such cruft. ... In any event, back to the original question: I would really appreciate any contacts at Tmobile who can help me sort this out. All of the Tmobile postmaster addresses I've tried have bounced. I've posted on the developer web forum, but that forum is specifically geared toward people developing on Tmobile phones, which isn't us. thanks, Graham From dmm at 1-4-5.net Sun May 16 09:58:14 2010 From: dmm at 1-4-5.net (David Meyer) Date: Sun, 16 May 2010 07:58:14 -0700 Subject: [NANOG-announce] Draft NANOG 49 program available! In-Reply-To: References: <20100513151849.GA15415@1-4-5.net> Message-ID: <20100516145814.GA3496@1-4-5.net> Matt, > I maybe the only one, but a lot of the tutorials during the 2 - 3:30 are > related and should be spread out between the 2 - 3:30 times and the 4 - 5:30 > times. I think if someone is interested in either they could pick one from > each session or one from each, but having an all in one in each session > really creates a problem in scheduling sessions. Thanks for the feedback. We try to schedule the tutorials to avoid just the sort of thing you are describing, so we'll take another look. Thanks again for the feedback. Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From itservices88 at gmail.com Sun May 16 13:14:58 2010 From: itservices88 at gmail.com (itservices88) Date: Sun, 16 May 2010 11:14:58 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Message-ID: Hi, I was building a test domain for trying out the dnssec. However as mentioned on various websites "ad" appears in the flags, but i can't see it. The domain i am using is not real and i am testing from the same machine, Fedora-12. Any help? Thanks options { dnssec-enable yes; dnssec-validation yes; }; [root at ns1 named-data]# dig +dnssec @localhost www ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> +dnssec @localhost www ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16601 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www. IN A ;; AUTHORITY SECTION: . 5221 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010051600 1800 900 604800 86400 . 5221 IN RRSIG SOA 8 0 86400 20100523070000 20100516060000 55138 . KTwve6TiQ6ShXCfEcbYusFWOCsx+IwCUumBr4GnwnNq1eqs7tqQaHqkJ T/ewcvjXvRGOmHjhGRgqkdESse+/fa+tz1sSdvMsTGGI2Ba9/Fbb43Ty eqsG5cFxbqfXOpwlA4ab9IR2Vkod6genONeYO6rrm2edNwQrf56wrtJr CNM= . 5221 IN RRSIG NSEC 8 0 86400 20100523070000 20100516060000 55138 . uIgAQvJUyLjAPwb7zB8wcJ4wk++21g+iF/bJGlpvz4iUJOMwkPgqA2s/ A8W0MhxBjo7918xg6yJeqYwXB+rGG14F7UZfOBVlXIqno5/kXzi4Carh /8sulBMyHbFmVlOht5SLU230ROaI6+4o0B6IRyiP5Vzgjt00zyFu26Rg Yb8= . 5221 IN NSEC ac. NS SOA RRSIG NSEC DNSKEY ws. 5221 IN RRSIG NSEC 8 1 86400 20100523070000 20100516060000 55138 . KsvM0PTDqWt0yoJNZ4k1UGTw0UtJZxsZa17bDHAyY7w1eocZlCqGJNd8 2/WDeJMfCkM+MakJLblnixlI6QcNYV6ctrKZkNuA/iX2rwapouVYoC7G HxvBLnb5TFWkCML+fhgOWza8RmRnCTY593uBgsPtcgEfTZAzYB+QFCEP 6oI= ws. 5221 IN NSEC ????. NS RRSIG NSEC ;; Query time: 11 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sun May 16 11:02:43 2010 ;; MSG SIZE rcvd: 641 =============================================================== On Wed, May 5, 2010 at 2:23 PM, Joe Abley wrote: > Root Zone DNSSEC Deployment > Technical Status Update 2010-05-05 > > This is the sixth of a series of technical status updates intended > to inform a technical audience on progress in signing the root zone > of the DNS. > > > ** The final transition to a signed root zone took place today > ** on J-Root, between 1700--1900 UTC. > ** > ** All root servers are now serving a signed root zone. > ** > ** All root servers will now generate larger responses to DNS > ** queries that request DNSSEC information. > ** > ** If you experience technical problems or need to contact > ** technical project staff, please send e-mail to rootsign at icann.org > ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred > ** if possible. > ** > ** See below for more details. > > > RESOURCES > > Details of the project, including documentation published to date, > can be found at . > > We'd like to hear from you. If you have feedback for us, please > send it to rootsign at icann.org. > > > DEPLOYMENT STATUS > > The incremental deployment of DNSSEC in the Root Zone is being > carried out first by serving a Deliberately Unvalidatable Root Zone > (DURZ), and subsequently by a conventionally signed root zone. > Discussion of the approach can be found in the document "DNSSEC > Deployment for the Root Zone", as well as in the technical presentations > delivered at RIPE, NANOG, IETF and ICANN meetings. > > All of the thirteen root servers have now made the transition to > the to the DURZ. No harmful effects have been identified. > > The final root server to make the transition, J-Root, started serving > the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. > > Initial observations relating to this transition will be presented > and discussed at the DNS Working Group meeting at RIPE 60 in Prague > on 2010-05-06. > > > PLANNED DEPLOYMENT SCHEDULE > > Already completed: > > 2010-01-27: L starts to serve DURZ > > 2010-02-10: A starts to serve DURZ > > 2010-03-03: M, I start to serve DURZ > > 2010-03-24: D, K, E start to serve DURZ > > 2010-04-14: B, H, C, G, F start to serve DURZ > > 2010-05-05: J starts to serve DURZ > > To come: > > 2010-07-01: Distribution of validatable, production, signed root > zone; publication of root zone trust anchor > > (Please note that this schedule is tentative and subject to change > based on testing results or other unforeseen factors.) > > > From rubensk at gmail.com Sun May 16 13:52:54 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 16 May 2010 15:52:54 -0300 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Message-ID: You probably need a trust anchor as well. See http://ftp.isc.org/isc/pubs/tn/isc-tn-2006-1.html. Rubens On Sun, May 16, 2010 at 3:14 PM, itservices88 wrote: > Hi, > > I was building a test domain for trying out the dnssec. However as mentioned > on various websites "ad" appears in the flags, but i can't see it. The > domain i am using is not real and i am testing from the same machine, > Fedora-12. Any help? > > Thanks > > > options { > ? ? ? ?dnssec-enable yes; > ? ? ? ?dnssec-validation yes; > }; > > [root at ns1 named-data]# dig +dnssec @localhost www > ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> +dnssec @localhost www > ; (2 servers found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16601 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;www. ? ? ? ? ? ? ? ? ? ? ? ? ? IN ? ? ?A > ;; AUTHORITY SECTION: > . ? ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?SOA ? ? a.root-servers.net. > nstld.verisign-grs.com. 2010051600 1800 900 604800 86400 > . ? ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?RRSIG ? SOA 8 0 86400 20100523070000 > 20100516060000 55138 . > KTwve6TiQ6ShXCfEcbYusFWOCsx+IwCUumBr4GnwnNq1eqs7tqQaHqkJ > T/ewcvjXvRGOmHjhGRgqkdESse+/fa+tz1sSdvMsTGGI2Ba9/Fbb43Ty > eqsG5cFxbqfXOpwlA4ab9IR2Vkod6genONeYO6rrm2edNwQrf56wrtJr CNM= > . ? ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?RRSIG ? NSEC 8 0 86400 > 20100523070000 20100516060000 55138 . > uIgAQvJUyLjAPwb7zB8wcJ4wk++21g+iF/bJGlpvz4iUJOMwkPgqA2s/ > A8W0MhxBjo7918xg6yJeqYwXB+rGG14F7UZfOBVlXIqno5/kXzi4Carh > /8sulBMyHbFmVlOht5SLU230ROaI6+4o0B6IRyiP5Vzgjt00zyFu26Rg Yb8= > . ? ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?NSEC ? ?ac. NS SOA RRSIG NSEC DNSKEY > ws. ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?RRSIG ? NSEC 8 1 86400 > 20100523070000 20100516060000 55138 . > KsvM0PTDqWt0yoJNZ4k1UGTw0UtJZxsZa17bDHAyY7w1eocZlCqGJNd8 > 2/WDeJMfCkM+MakJLblnixlI6QcNYV6ctrKZkNuA/iX2rwapouVYoC7G > HxvBLnb5TFWkCML+fhgOWza8RmRnCTY593uBgsPtcgEfTZAzYB+QFCEP 6oI= > ws. ? ? ? ? ? ? ? ? ? ? 5221 ? ?IN ? ? ?NSEC ? ?????. NS RRSIG NSEC > ;; Query time: 11 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun May 16 11:02:43 2010 > ;; MSG SIZE ?rcvd: 641 > > =============================================================== > On Wed, May 5, 2010 at 2:23 PM, Joe Abley wrote: > >> Root Zone DNSSEC Deployment >> Technical Status Update 2010-05-05 >> >> This is the sixth of a series of technical status updates intended >> to inform a technical audience on progress in signing the root zone >> of the DNS. >> >> >> ** ?The final transition to a signed root zone took place today >> ** ?on J-Root, between 1700--1900 UTC. >> ** >> ** ?All root servers are now serving a signed root zone. >> ** >> ** ?All root servers will now generate larger responses to DNS >> ** ?queries that request DNSSEC information. >> ** >> ** ?If you experience technical problems or need to contact >> ** ?technical project staff, please send e-mail to rootsign at icann.org >> ** ?or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred >> ** ?if possible. >> ** >> ** ?See below for more details. >> >> >> RESOURCES >> >> Details of the project, including documentation published to date, >> can be found at . >> >> We'd like to hear from you. If you have feedback for us, please >> send it to rootsign at icann.org. >> >> >> DEPLOYMENT STATUS >> >> The incremental deployment of DNSSEC in the Root Zone is being >> carried out first by serving a Deliberately Unvalidatable Root Zone >> (DURZ), and subsequently by a conventionally signed root zone. >> Discussion of the approach can be found in the document "DNSSEC >> Deployment for the Root Zone", as well as in the technical presentations >> delivered at RIPE, NANOG, IETF and ICANN meetings. >> >> All of the thirteen root servers have now made the transition to >> the to the DURZ. ?No harmful effects have been identified. >> >> The final root server to make the transition, J-Root, started serving >> the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. >> >> Initial observations relating to this transition will be presented >> and discussed at the DNS Working Group meeting at RIPE 60 in Prague >> on 2010-05-06. >> >> >> PLANNED DEPLOYMENT SCHEDULE >> >> Already completed: >> >> ?2010-01-27: L starts to serve DURZ >> >> ?2010-02-10: A starts to serve DURZ >> >> ?2010-03-03: M, I start to serve DURZ >> >> ?2010-03-24: D, K, E start to serve DURZ >> >> ?2010-04-14: B, H, C, G, F start to serve DURZ >> >> ?2010-05-05: J starts to serve DURZ >> >> To come: >> >> ?2010-07-01: Distribution of validatable, production, signed root >> ? ?zone; publication of root zone trust anchor >> >> ?(Please note that this schedule is tentative and subject to change >> ?based on testing results or other unforeseen factors.) >> >> >> > From itservices88 at gmail.com Sun May 16 17:54:10 2010 From: itservices88 at gmail.com (itservices88) Date: Sun, 16 May 2010 15:54:10 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Message-ID: Thanks for hint. I also found this a useful link: https://dlv.isc.org/about/using -dani On Sun, May 16, 2010 at 11:52 AM, Rubens Kuhl wrote: > You probably need a trust anchor as well. > See http://ftp.isc.org/isc/pubs/tn/isc-tn-2006-1.html. > > Rubens > > > On Sun, May 16, 2010 at 3:14 PM, itservices88 > wrote: > > Hi, > > > > I was building a test domain for trying out the dnssec. However as > mentioned > > on various websites "ad" appears in the flags, but i can't see it. The > > domain i am using is not real and i am testing from the same machine, > > Fedora-12. Any help? > > > > Thanks > > > > > > options { > > dnssec-enable yes; > > dnssec-validation yes; > > }; > > > > [root at ns1 named-data]# dig +dnssec @localhost www > > ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> +dnssec @localhost www > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16601 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 4096 > > ;; QUESTION SECTION: > > ;www. IN A > > ;; AUTHORITY SECTION: > > . 5221 IN SOA a.root-servers.net. > > nstld.verisign-grs.com. 2010051600 1800 900 604800 86400 > > . 5221 IN RRSIG SOA 8 0 86400 > 20100523070000 > > 20100516060000 55138 . > > KTwve6TiQ6ShXCfEcbYusFWOCsx+IwCUumBr4GnwnNq1eqs7tqQaHqkJ > > T/ewcvjXvRGOmHjhGRgqkdESse+/fa+tz1sSdvMsTGGI2Ba9/Fbb43Ty > > eqsG5cFxbqfXOpwlA4ab9IR2Vkod6genONeYO6rrm2edNwQrf56wrtJr CNM= > > . 5221 IN RRSIG NSEC 8 0 86400 > > 20100523070000 20100516060000 55138 . > > uIgAQvJUyLjAPwb7zB8wcJ4wk++21g+iF/bJGlpvz4iUJOMwkPgqA2s/ > > A8W0MhxBjo7918xg6yJeqYwXB+rGG14F7UZfOBVlXIqno5/kXzi4Carh > > /8sulBMyHbFmVlOht5SLU230ROaI6+4o0B6IRyiP5Vzgjt00zyFu26Rg Yb8= > > . 5221 IN NSEC ac. NS SOA RRSIG NSEC > DNSKEY > > ws. 5221 IN RRSIG NSEC 8 1 86400 > > 20100523070000 20100516060000 55138 . > > KsvM0PTDqWt0yoJNZ4k1UGTw0UtJZxsZa17bDHAyY7w1eocZlCqGJNd8 > > 2/WDeJMfCkM+MakJLblnixlI6QcNYV6ctrKZkNuA/iX2rwapouVYoC7G > > HxvBLnb5TFWkCML+fhgOWza8RmRnCTY593uBgsPtcgEfTZAzYB+QFCEP 6oI= > > ws. 5221 IN NSEC ????. NS RRSIG NSEC > > ;; Query time: 11 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Sun May 16 11:02:43 2010 > > ;; MSG SIZE rcvd: 641 > > > > =============================================================== > > On Wed, May 5, 2010 at 2:23 PM, Joe Abley wrote: > > > >> Root Zone DNSSEC Deployment > >> Technical Status Update 2010-05-05 > >> > >> This is the sixth of a series of technical status updates intended > >> to inform a technical audience on progress in signing the root zone > >> of the DNS. > >> > >> > >> ** The final transition to a signed root zone took place today > >> ** on J-Root, between 1700--1900 UTC. > >> ** > >> ** All root servers are now serving a signed root zone. > >> ** > >> ** All root servers will now generate larger responses to DNS > >> ** queries that request DNSSEC information. > >> ** > >> ** If you experience technical problems or need to contact > >> ** technical project staff, please send e-mail to rootsign at icann.org > >> ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred > >> ** if possible. > >> ** > >> ** See below for more details. > >> > >> > >> RESOURCES > >> > >> Details of the project, including documentation published to date, > >> can be found at . > >> > >> We'd like to hear from you. If you have feedback for us, please > >> send it to rootsign at icann.org. > >> > >> > >> DEPLOYMENT STATUS > >> > >> The incremental deployment of DNSSEC in the Root Zone is being > >> carried out first by serving a Deliberately Unvalidatable Root Zone > >> (DURZ), and subsequently by a conventionally signed root zone. > >> Discussion of the approach can be found in the document "DNSSEC > >> Deployment for the Root Zone", as well as in the technical presentations > >> delivered at RIPE, NANOG, IETF and ICANN meetings. > >> > >> All of the thirteen root servers have now made the transition to > >> the to the DURZ. No harmful effects have been identified. > >> > >> The final root server to make the transition, J-Root, started serving > >> the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. > >> > >> Initial observations relating to this transition will be presented > >> and discussed at the DNS Working Group meeting at RIPE 60 in Prague > >> on 2010-05-06. > >> > >> > >> PLANNED DEPLOYMENT SCHEDULE > >> > >> Already completed: > >> > >> 2010-01-27: L starts to serve DURZ > >> > >> 2010-02-10: A starts to serve DURZ > >> > >> 2010-03-03: M, I start to serve DURZ > >> > >> 2010-03-24: D, K, E start to serve DURZ > >> > >> 2010-04-14: B, H, C, G, F start to serve DURZ > >> > >> 2010-05-05: J starts to serve DURZ > >> > >> To come: > >> > >> 2010-07-01: Distribution of validatable, production, signed root > >> zone; publication of root zone trust anchor > >> > >> (Please note that this schedule is tentative and subject to change > >> based on testing results or other unforeseen factors.) > >> > >> > >> > > > From tim at pelican.org Mon May 17 03:51:10 2010 From: tim at pelican.org (Tim Franklin) Date: Mon, 17 May 2010 08:51:10 +0000 (GMT) Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <15527192.01274086189734.JavaMail.root@jennyfur.pelican.org> Message-ID: <5822128.21274086270746.JavaMail.root@jennyfur.pelican.org> > That may be, but it would surprise me. The carriers still get paid > by virtue of charging the recipients for the SMSes, and in this > particular case cutting off this line of communication is leaving > money on the table, as email->SMS deliverability is desired yet > optional/secondary functionality of the app. Paying to *receive* SMS? And I thought the UK mobile industry was doing a good job of screwing its customers... In all seriousness, I wonder if they're using the same platform for their email gateways world-wide, and / or rate-limiting globally on the assumption that they're *not* making any money, as would be the case in many other locations? Especially if the Tmobile US operation is tech-driven (or otherwise) from the German parent. Regards, Tim. From eric at atlantech.net Mon May 17 08:51:28 2010 From: eric at atlantech.net (Eric Van Tol) Date: Mon, 17 May 2010 09:51:28 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> References: <33361326.494.1273861611194.JavaMail.franck@dport-d820.genius.local> <18959438.496.1273861781840.JavaMail.franck@dport-d820.genius.local> <56516858-8108-41E8-BAB8-0139D1C93B2B@puck.nether.net> Message-ID: <2C05E949E19A9146AF7BDF9D44085B863C2BEC427F@exchange.aoihq.local> > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Friday, May 14, 2010 2:49 PM > To: Jack Carrozzo > Cc: nanog at nanog.org > Subject: Re: ipv6 transit over tunneled connection > > I'm curious what providers have not gotten their IPv6 > plans/networks/customer ports enabled. > > I know that Comcast is doing their trials now (Thanks John!) and will be > presenting at the upcoming NANOG about their experiences. > > What parts of the big "I" Internet are not enabled or ready? > We don't see Savvis, Level3, or AboveNet with IPv6 capabilities in our region (DC). Two years ago, neither Verizon or AT&T had IPv6, either. Not sure about them now, as we no longer use them for transit. One would think everyone would have v6 capabilities in the heart of government territory, but okay. For whatever reason, Verio actually charges (or used to) for their IPv6 separately from IPv4 and to top it all off, it wasn't significantly discounted. -evt From mulitskiy at acedsl.com Mon May 17 09:50:43 2010 From: mulitskiy at acedsl.com (Michael Ulitskiy) Date: Mon, 17 May 2010 10:50:43 -0400 Subject: ipv6 transit over tunneled connection In-Reply-To: <201005142325.10617.mulitskiy@acedsl.com> References: <201005131818.12316.mulitskiy@acedsl.com> <201005142325.10617.mulitskiy@acedsl.com> Message-ID: <201005171050.44075.mulitskiy@acedsl.com> Hello, Just wanted to say thanks to everybody who replied and/or offered help. I've got a few private peering offers, so I guess I'm ok now. Thanks a lot, Michael On Friday 14 May 2010 11:25:10 pm Michael Ulitskiy wrote: > Guys, > > I've started this thread looking for advice on available options. > There's no doubt in my mind that native connectivity is better than tunnels, > but unfortunately tunnel is the only way to get me started, 'cause my upstream > does not support ipv6 (hopefully just yet) and I have no budget for additional > circuits to ipv6-enabled carrier. > So my question still stands: is anyone aware of a reasonable tunneled ipv6 > transit service (I mean aside from HE tunnel broker)? The load will be really > light. I don't expect we'll break a few Mbit/s in the nearest future and when > we do then I guess it'll be the time to look for the native transit. > Thanks, > > Michael > > On Thursday 13 May 2010 18:18:12 Michael Ulitskiy wrote: > > Hello, > > > > We're in the early stage of planning ipv6 deployment - > > learning/labbing/experimenting/etc. We've got to the point when we're also > > planning to request initial ipv6 allocation from ARIN. So I wonder what > > ipv6 transit options I have if my upstreams do not support native ipv6 > > connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there > > anything else? Either free or commercial? Thanks, > > > > Michael > > > > From dsparro at gmail.com Mon May 17 10:29:09 2010 From: dsparro at gmail.com (Dave Sparro) Date: Mon, 17 May 2010 11:29:09 -0400 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> Message-ID: <4BF160C5.1050105@gmail.com> On 5/15/2010 6:38 PM, Graham Freeman wrote: > > That may be, but it would surprise me. The carriers still get paid > by virtue of charging the recipients for the SMSes, and in this > particular case cutting off this line of communication > is leaving money on the table, as email->SMS deliverability > is desired yet optional/secondary functionality of the app. Based on what I see in the marketplace today, I think that the average wireless carrier exec doesn't do the same math. For them, I think it's more like: Q: What's better than a service we can charge our users for? A: A service we can charge our users for, while at the same time charging somebody else. From pavel-subscriptions at pavel.pro Mon May 17 11:14:20 2010 From: pavel-subscriptions at pavel.pro (Pavel Stan) Date: Mon, 17 May 2010 19:14:20 +0300 Subject: [c-nsp] Huawei instead of Cisco In-Reply-To: References: Message-ID: <4BF16B5C.9000407@pavel.pro> Hi, My first advice regarding S9300 or any other Huawei box is not to trust any lab test they might propose to you, but get one demo box and place it in the target live environment, if possible. In particular for S9300, it's a surprisingly well done non-oversubscribed 10G IP-switch with hardware MPLS support, but no match for 76xx, so be sure to ask for a much lower price. S9300 is done using technology from the NE40 series ( not the NE40-E / NE80-E, who is positioned on same level with 7600 and also has the LPUF and LPUG cards that try to compete with ES+ cards ). Depending on your desired position on your customer's network, things could go well with this box for running L2 carrier services, as EoMPLS / TE looks good on them. For IPv4/v6 routing things get nasty, even if they have LC that support 512k FIB, QPPB, enough LFIB space. The problems that you should lookup with these things are the CPU processing limits, as it seems that the MPU, as they call it, is somehow too week for holding even a decent flow of control-plane traffic, so you might want to keep things simple there. >From the operational part, you must pray that you don't need to interact with their post-sales support team, as they are unable to help you on complex problems or give you info on "what happens with this packet inside the box" questions. They tend to escalate this problems to their over-worked suicidal R&D guys. Documentation is useless most of the times and looks like it was google translated from mandarin. For the software, try to get them to give you an image that has GA status with at least one maintenance release ( for ex. SRD2 ) as they try to push newer feature releases on to small customers for beta-testing. Don't trust anything they tell you but test it yourself, You would be surprised to find that simple things you would take for granted on Cisco/Juniper/Alcatel/etc are not implemented the way you expected. Also, what if hear from happy GSM/WDM/SDH Huawei owners is not relevant for IP/Ethernet/MPLS/Carrier Service, as they are totally different BUs with different experience and strategy. On the commercial side, they will do "ANYTHING" to sign with you, as they are desperately trying to extend their datacom portfolio to more than the current China Telecom, Asia and other banana republics customers that they currently have. Good luck! -- Pavel Stan pavel.stan at pavel.pro Felix Nkansah wrote: > Hi, > > A telco customer is evaluating tender proposals for next-generation Internet > POPs planned for deployment this year. > > Among the bidders is Huawei, who has a very beautiful technical proposal > document with great-looking design/platforms. > > They are positioning their Quidway S9300 terabit routing switch platform to > compete (the equivalent of the Cisco ASR 9000). > > The customer would have loved to go with Cisco 7609s, but is contemplating > Huawei's because of their low prices. > > I know Huawei is doing a good job in mobile switching and access networks, > but do you know how well they do with their products in data/IP/BGP/MPLS > solutions? > > How about the maturity of their software? Are there any hidden operational > costs too? What is the total cost of ownership when compared to Cisco's? > > Thanks. Felix > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From jarenangerbauer at gmail.com Mon May 17 11:42:21 2010 From: jarenangerbauer at gmail.com (Jaren Angerbauer) Date: Mon, 17 May 2010 10:42:21 -0600 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> Message-ID: On Sat, May 15, 2010 at 4:38 PM, Graham Freeman wrote: > There appears to be a misunderstanding. ?The messages in question are in fact 1:1 interpersonal communication between my client's customers (the people who use my client's iPhone messaging app) and their correspondents (to whom we're trying to deliver via the email->SMS gateway). ? ?We're not sending ads, newsletters, or other such cruft. > Thanks for the clarification on this -- I didn't think this was the latter type of messaging, and perhaps my use of "commercial" was the wrong terminology. That being said, as your client appears to have issues only when the volume goes up, perhaps TMobile is getting the perception that these message are in some way "commercial", based on volume -- just a thought. In any case, back to Al's point, I agreed with him because I'm under the impression that mobile providers are leery of companies using email-to-sms (vs straight SMS) because of the spam potential. IIUC, it's much easier to manage / control abuse issues with SMS. I'm a bit out of my expertise element here, so I could be missing something. --Jaren From jdfalk-lists at cybernothing.org Mon May 17 13:57:47 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Mon, 17 May 2010 12:57:47 -0600 Subject: Contacts re email deliverability problem to tmomail.net? In-Reply-To: <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> References: <5DD0B22F-B074-43F3-8B4B-F8C7287F0A79@gmail.com> <6991DB95-A60B-4971-B608-D24586486A31@gmail.com> <7BC05F2C-CAAD-43B7-9D8C-557ECA65D585@gmail.com> Message-ID: On May 15, 2010, at 4:38 PM, Graham Freeman wrote: > There appears to be a misunderstanding. The messages in question are in fact 1:1 interpersonal communication between my client's customers (the people who use my client's iPhone messaging app) and their correspondents (to whom we're trying to deliver via the email->SMS gateway). We're not sending ads, newsletters, or other such cruft. That's probably why the mail is only being deferred (as you indicated on the mailop list), rather than rejected outright. -- J.D. Falk Return Path Inc From deric.kwok2000 at gmail.com Mon May 17 18:15:01 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Mon, 17 May 2010 19:15:01 -0400 Subject: useful bgp example Message-ID: Hi My company will get 2 upstream provider. We will plan 2 routers and each router to connect one provider to use bgp for redundant. Do you have any useful bgp example and website to set it up? Thank you for your help From sethm at rollernet.us Mon May 17 18:48:35 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 17 May 2010 16:48:35 -0700 Subject: useful bgp example In-Reply-To: References: Message-ID: <4BF1D5D3.7000904@rollernet.us> On 5/17/2010 16:15, Deric Kwok wrote: > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? > > Thank you for your help > google.com There's a billion examples out there. Please don't inflict your network on the world you can't even get that far. Hire someone to do it for you. ~Seth From lists at billfehring.com Mon May 17 19:07:08 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 17 May 2010 17:07:08 -0700 Subject: useful bgp example In-Reply-To: References: Message-ID: Don't take this the wrong way, but I'd *highly* suggest hiring a network engineer that has done this before. The fact that you started here is very concerning, and if your ISP isn't filtering your sessions carefully, your mistakes can cause problems for other people. Here's a cisco example: http://tinyurl.com/33e36sf Good luck, Bill On Mon, May 17, 2010 at 16:15, Deric Kwok wrote: > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? > > Thank you for your help > > From lists at billfehring.com Mon May 17 19:11:42 2010 From: lists at billfehring.com (Bill Fehring) Date: Mon, 17 May 2010 17:11:42 -0700 Subject: useful bgp example In-Reply-To: References: Message-ID: On Mon, May 17, 2010 at 17:07, Bill Fehring wrote: > > Don't take this the wrong way, but I'd *highly* suggest hiring a network engineer that has done this before. The fact that you started here is very concerning, and if your ISP isn't filtering your sessions carefully, your mistakes can cause problems for other people. > Here's a cisco example: > http://tinyurl.com/33e36sf > Good luck, > Bill Also?I would suggest that you take a look at some of the NANOG presentation archives on this topic, particularly the "BGP 101" and "BGP 102" presentations from NANOG45, or the "Introduction to BGP" presentation from NANOG47. http://www.nanog.org/presentations/archive/index.php -Bill From ravi at cow.org Mon May 17 19:15:51 2010 From: ravi at cow.org (Ravi Pina) Date: Mon, 17 May 2010 20:15:51 -0400 Subject: useful bgp example In-Reply-To: References: Message-ID: <20100518001551.GJ45023@neu.cow.org> On Mon, May 17, 2010 at 05:11:42PM -0700, Bill Fehring wrote: > On Mon, May 17, 2010 at 17:07, Bill Fehring wrote: > > > > Don't take this the wrong way, but I'd *highly* suggest hiring a network engineer that has done this before. The fact that you started here is very concerning, and if your ISP isn't filtering your sessions carefully, your mistakes can cause problems for other people. > > Here's a cisco example: > > http://tinyurl.com/33e36sf > > Good luck, > > Bill > > Also?I would suggest that you take a look at some of the NANOG > presentation archives on this topic, particularly the "BGP 101" and > "BGP 102" presentations from NANOG45, or the "Introduction to BGP" > presentation from NANOG47. > > http://www.nanog.org/presentations/archive/index.php > > -Bill I think Internet Routing Architectures (2nd Edition) by Bassam Halab is also a must have. Read that and hopefully the scope of the work ahead will be brought into focus that you'll hire someone to do it correctly and document and possibly train you and/or your staff. -r From dougb at dougbarton.us Mon May 17 19:53:47 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 17 May 2010 17:53:47 -0700 Subject: useful bgp example In-Reply-To: <20100518001551.GJ45023@neu.cow.org> References: <20100518001551.GJ45023@neu.cow.org> Message-ID: <4BF1E51B.9080209@dougbarton.us> On 05/17/10 17:15, Ravi Pina wrote: > > I think Internet Routing Architectures (2nd Edition) by Bassam > Halab is also a must have. Read that and hopefully the scope of > the work ahead will be brought into focus that you'll hire > someone to do it correctly and document and possibly train you > and/or your staff. I agree completely, and wish that more people applied that same line of reasoning to other things, like, oh, say, DNS perhaps? :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From Valdis.Kletnieks at vt.edu Mon May 17 20:04:13 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 17 May 2010 21:04:13 -0400 Subject: useful bgp example In-Reply-To: Your message of "Mon, 17 May 2010 19:15:01 EDT." References: Message-ID: <9282.1274144653@localhost> On Mon, 17 May 2010 19:15:01 EDT, Deric Kwok said: > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? If your BGP clue is that low, I believe the entire NANOG community would advise you hire (even short-term if you can't afford a permanent) somebody who has successfully done this before to walk you through it and teach all the details to your staff. With the current tanking of the economy, I'm sure there's plenty of qualified BGP experts out there who would *love* even a 3-month contract to get this all working for you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From williamsjj at digitar.com Mon May 17 20:11:57 2010 From: williamsjj at digitar.com (Jason J. W. Williams) Date: Mon, 17 May 2010 19:11:57 -0600 Subject: useful bgp example In-Reply-To: <4BF1E51B.9080209@dougbarton.us> References: <20100518001551.GJ45023@neu.cow.org> <4BF1E51B.9080209@dougbarton.us> Message-ID: <51C0C1B1-49EA-42CB-B096-293ED4B5EC5E@digitar.com> I'd recommend BGP4 Inter-Domain Routing in the Internet by Stewart. Was very helpful when I was learning. -J -------- Jason J. W. Williams, COO/CTO DigiTar williamsjj at digitar.com V: 208.343.8520 F: 208.322.8522 M: 208.863.0727 www.digitar.com On May 17, 2010, at 6:53 PM, Doug Barton wrote: > > On 05/17/10 17:15, Ravi Pina wrote: >> >> I think Internet Routing Architectures (2nd Edition) by Bassam >> Halab is also a must have. Read that and hopefully the scope of >> the work ahead will be brought into focus that you'll hire >> someone to do it correctly and document and possibly train you >> and/or your staff. > > I agree completely, and wish that more people applied that same line of > reasoning to other things, like, oh, say, DNS perhaps? :) > > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > !SIG:4bf1e5a8162722700917759! > From jared at puck.nether.net Mon May 17 20:24:59 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 17 May 2010 21:24:59 -0400 Subject: useful bgp example In-Reply-To: References: Message-ID: <75896286-9273-490B-82B4-1F69CC758B4A@puck.nether.net> I have some examples here: http://puck.nether.net/bgp/ that may help you. Jared Mauch On May 17, 2010, at 7:15 PM, Deric Kwok wrote: > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? > > Thank you for your help From steve at ipv6canada.com Mon May 17 23:02:51 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Tue, 18 May 2010 00:02:51 -0400 Subject: useful bgp example In-Reply-To: References: Message-ID: <4BF2116B.6040108@ipv6canada.com> On 2010.05.17 19:15, Deric Kwok wrote: > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? One ``website'' I have in mind, but first, *ensure* that you have your prefix-list and other outbound filters in place before you try anything. *never* _test_ a multihome scenario before you are very confident that you don't mess things up for your upstreams (or the Internet in general). Not all upstream providers filter inbound (which is a problem on its own). Always, always, always ensure that you block all out (and in), and then slowly leak what you need to. With that said: http://www.armware.dk/RFC/bcp/bcp38.html Steve From steve at ipv6canada.com Mon May 17 23:57:01 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Tue, 18 May 2010 00:57:01 -0400 Subject: useful bgp example In-Reply-To: <75896286-9273-490B-82B4-1F69CC758B4A@puck.nether.net> References: <75896286-9273-490B-82B4-1F69CC758B4A@puck.nether.net> Message-ID: <4BF21E1D.5070709@ipv6canada.com> On 2010.05.17 21:24, Jared Mauch wrote: > I have some examples here: > > http://puck.nether.net/bgp/ that may help you. Along with Jared's excellent help site, here are others that I'd *highly* recommend reading/following *anything* that these two people offer as far as BGP is concerned. I've posted a link directly to each blog. You can do the rest ;) Ivan Pepelnjak http://www.ioshints.info/About_Ivan_Pepelnjak Iljitsch van Beijnum http://www.muada.com/Iljitsch_van_Beijnum/Iljitsch_blog/Iljitsch_blog.html Steve From gbonser at seven.com Tue May 18 00:04:07 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 17 May 2010 22:04:07 -0700 Subject: Config and scheduled event management software? Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA448A@RWC-EX1.corp.seven.com> Anyone have any recommendations of software for Configuration Management (change control for hardware, networks etc) and event scheduling? We are using a hodgepodge of homegrown stuff and RT but are outgrowing it. What's good? What sucks? George From ops.lists at gmail.com Tue May 18 00:56:38 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 18 May 2010 11:26:38 +0530 Subject: Config and scheduled event management software? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA448A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE09EA448A@RWC-EX1.corp.seven.com> Message-ID: http://snmpstat.sourceforge.net/ and its cisco configuration repository look good On Tue, May 18, 2010 at 10:34 AM, George Bonser wrote: > Anyone have any recommendations of software for Configuration Management > (change control for hardware, networks etc) and > event scheduling? > > We are using a hodgepodge of homegrown stuff and RT but are outgrowing > it. > > What's good? What sucks? -- Suresh Ramasubramanian (ops.lists at gmail.com) From elmi at 4ever.de Tue May 18 03:03:40 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 18 May 2010 10:03:40 +0200 Subject: Juniper SRX-210 -- CCC certificate required Message-ID: <20100518080340.GG40235@ronin.4ever.de> Hello altogether, I'm in kind of a pinch currently - I have to get a Juniper SRX-210 into China. That got the box stuck at import there, and they demand the CCC certificate from us. Unfortunately, Juniper has as yet not been willing or able to respond to this request (ongoing for weeks), and I wonder if anyone on this list might just have the certificate on file... If so, please help me out - I'm pretty desperate and would even consider buying you a beer at NANOG49. ;-) (Well, don't have to be desparate for that...) Yours, Elmar. From gordslater at ieee.org Tue May 18 03:47:10 2010 From: gordslater at ieee.org (gordon b slater) Date: Tue, 18 May 2010 09:47:10 +0100 Subject: Juniper SRX-210 -- CCC certificate required In-Reply-To: <20100518080340.GG40235@ronin.4ever.de> References: <20100518080340.GG40235@ronin.4ever.de> Message-ID: <1274172430.23402.6.camel@ub-g-d2> On Tue, 2010-05-18 at 10:03 +0200, Elmar K. Bins wrote: > Hello altogether, > > I'm in kind of a pinch currently - I have to get a Juniper > SRX-210 into China. That got the box stuck at import there, > and they demand the CCC certificate from us. > > Unfortunately, Juniper has as yet not been willing or able > to respond to this request (ongoing for weeks), and I wonder > if anyone on this list might just have the certificate on file... This maybe doesn't help you as much as a CCC istelf, but, seeing that it may have been "ongoing for weeks": ...something in the back of my head says they retracted from their initial stance recently (few month ago?) and said the CCC for IT security kit was only needed for Gov't Procurement kit - I could be very wrong, it was a snippet of casual conversation in passing. Maybe you're just up against extra red tape, officials not up to speed etc; or maybe it is for a Govt Contract after all. Good luck either way Gord -- No1 Box CLI From regnauld at nsrc.org Tue May 18 04:04:38 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 18 May 2010 11:04:38 +0200 Subject: Config and scheduled event management software? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA448A@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE09EA448A@RWC-EX1.corp.seven.com> Message-ID: <20100518090437.GA28501@macbook.catpipe.net> George Bonser (gbonser) writes: > Anyone have any recommendations of software for Configuration Management > (change control for hardware, networks etc) and > event scheduling? > > We are using a hodgepodge of homegrown stuff and RT but are outgrowing > it. > > What's good? What sucks? Hi George, I gather you're already using Rancid ? You should check out Netdot : https://netdot.uoregon.edu/ Cheers, Phil From elmi at 4ever.de Tue May 18 03:52:48 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 18 May 2010 10:52:48 +0200 Subject: Juniper SRX-210 -- CCC certificate required In-Reply-To: <1274172430.23402.6.camel@ub-g-d2> References: <20100518080340.GG40235@ronin.4ever.de> <1274172430.23402.6.camel@ub-g-d2> Message-ID: <20100518085248.GJ40235@ronin.4ever.de> Re Gordon, gordslater at ieee.org (gordon b slater) wrote: > ...something in the back of my head says they retracted from their > initial stance recently (few month ago?) and said the CCC for IT > security kit was only needed for Gov't Procurement kit - I could be very > wrong, it was a snippet of casual conversation in passing. Thank you for this side note already - I'll forward your thoughts, maybe it helps. Still, if anyone can dig something up... > Maybe you're just up against extra red tape, officials not up to speed > etc; or maybe it is for a Govt Contract after all. It's not for a government contract (it's for the renewal of the ".de" ccTLD DNS setup in Beijing), and they could have put the red tape around other stuff that's in there. I guess it's just the usual formalism. Unfortunately, Google doesn't come up with anything about SRX's and CCC certification, though there seems to be a version with chinese plugsets... Yours, Elmar. -- "Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch ernstgenommen." (Konrad Adenauer) --------------------------------------------------------------[ ELMI-RIPE ]--- From sshafi at gmail.com Tue May 18 04:14:11 2010 From: sshafi at gmail.com (Lala Lander) Date: Tue, 18 May 2010 02:14:11 -0700 Subject: Juniper SRX-210 -- CCC certificate required In-Reply-To: <20100518085248.GJ40235@ronin.4ever.de> References: <20100518080340.GG40235@ronin.4ever.de> <1274172430.23402.6.camel@ub-g-d2> <20100518085248.GJ40235@ronin.4ever.de> Message-ID: You should buy locally in China and Juniper's partner in china will provide you CCC. thanks, Shahid On Tue, May 18, 2010 at 1:52 AM, Elmar K. Bins wrote: > Re Gordon, > > gordslater at ieee.org (gordon b slater) wrote: > > > ...something in the back of my head says they retracted from their > > initial stance recently (few month ago?) and said the CCC for IT > > security kit was only needed for Gov't Procurement kit - I could be very > > wrong, it was a snippet of casual conversation in passing. > > Thank you for this side note already - I'll forward your thoughts, > maybe it helps. Still, if anyone can dig something up... > > > > Maybe you're just up against extra red tape, officials not up to speed > > etc; or maybe it is for a Govt Contract after all. > > It's not for a government contract (it's for the renewal of the > ".de" ccTLD DNS setup in Beijing), and they could have put the > red tape around other stuff that's in there. I guess it's just > the usual formalism. > > Unfortunately, Google doesn't come up with anything about SRX's > and CCC certification, though there seems to be a version with > chinese plugsets... > > Yours, > Elmar. > > -- > > "Machen Sie sich erst einmal unbeliebt. Dann werden Sie auch > ernstgenommen." > (Konrad > Adenauer) > > --------------------------------------------------------------[ ELMI-RIPE > ]--- > > > From elmi at 4ever.de Tue May 18 04:32:52 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 18 May 2010 11:32:52 +0200 Subject: Juniper SRX-210 -- CCC certificate required In-Reply-To: References: <20100518080340.GG40235@ronin.4ever.de> <1274172430.23402.6.camel@ub-g-d2> <20100518085248.GJ40235@ronin.4ever.de> Message-ID: <20100518093252.GN40235@ronin.4ever.de> sshafi at gmail.com (Lala Lander) wrote: > You should buy locally in China and Juniper's partner in china will provide > you CCC. Thank you for the insight, Shahid. Can you please send me your time machine? ;-) Elmar. From bobbyjim at gmail.com Tue May 18 10:06:41 2010 From: bobbyjim at gmail.com (Bobby Mac) Date: Tue, 18 May 2010 10:06:41 -0500 Subject: Cisco CSS 11503 SSL and reverse DNS Message-ID: Hi All: Will having correct reverse DNS mapping improve SSL performance on a 11503 during peak load? My guess is no but I don't want to pound my prod device to find out. -Bobby From sking at kingrst.com Tue May 18 11:13:49 2010 From: sking at kingrst.com (Steven King) Date: Tue, 18 May 2010 12:13:49 -0400 Subject: Cisco CSS 11503 SSL and reverse DNS In-Reply-To: References: Message-ID: <4BF2BCBD.5000201@kingrst.com> rDNS should not affect the performance of an SSL device. On 5/18/10 11:06 AM, Bobby Mac wrote: > Hi All: > > Will having correct reverse DNS mapping improve SSL performance on a 11503 > during peak load? My guess is no but I don't want to pound my prod device > to find out. > > -Bobby > -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From v.jones at networkingunlimited.com Tue May 18 11:31:34 2010 From: v.jones at networkingunlimited.com (Vincent C Jones) Date: Tue, 18 May 2010 12:31:34 -0400 Subject: useful bgp example In-Reply-To: <9282.1274144653@localhost> References: <9282.1274144653@localhost> Message-ID: <1274200294.27247.1294.camel@X61.NetworkingUnlimited.nul> On Mon, 2010-05-17 at 21:04 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 17 May 2010 19:15:01 EDT, Deric Kwok said: > > My company will get 2 upstream provider. We will plan 2 routers and > > each router to connect one provider to use bgp for redundant. > > Do you have any useful bgp example and website to set it up? > > If your BGP clue is that low, I believe the entire NANOG community would advise > you hire (even short-term if you can't afford a permanent) somebody who has > successfully done this before to walk you through it and teach all the details > to your staff. With the current tanking of the economy, I'm sure there's > plenty of qualified BGP experts out there who would *love* even a 3-month > contract to get this all working for you. At the risk of tooting my own horn, I concur with the recommendation to hire some help, but if all you are lacking is BGP clue-full-ness your challenge in getting help is finding someone clueful who is willing to take a quick and dirty assignment which will barely cover the cost of setting up a new client. The configuration itself is a one day task at most, of which most will be spent grilling you to find out what your _REAL_ requirements are to allow picking the appropriate canned solution that can be adapted to meet your true needs. If you need hand holding applying configurations, negotiating with service provider, filling out paper work, testing without downtime infliction, etc., then add more hours/days. Ditto if you've unfamiliar with basic high availability concepts like single point of failure and physical diversity. Ditto if your systems are not already set up in paranoid mode from a security viewpoint (hint, if you can log directly into your Internet facing router from where ever you are when on the road, you are at an unacceptable level of risk). Good luck and have fun! -- Vincent C. Jones Networking Unlimited, Inc. Phone: +1 201 568-7810 V.Jones at NetworkingUnlimited.com DISCLAIMER: My business is built around helping my clients understand that there is a lot more to improving network availability than just getting a second service provider and turning on BGP. A few years ago I wrote a book about what it takes and barely scratched the surface--the example configurations are still on-line at www.networkingunlimited.com. From joe.abley at icann.org Tue May 18 12:12:24 2010 From: joe.abley at icann.org (Joe Abley) Date: Tue, 18 May 2010 10:12:24 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: <4F5BC2F5-B28C-4599-A301-95A80EE999EF@icann.org> Root Zone DNSSEC Deployment Technical Status Update 2010-05-17 This is the seventh of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. CHANGE IN DEPLOYMENT SCHEDULE The date for the publication of the root zone trust anchor and the distribution of a validatable, signed root zone originally planned for 2010-07-01 has been changed. This final stage of root DNSSEC deployment is now scheduled to take place on 2010-07-15. The schedule change is intended to allow ICANN and VeriSign an additional two weeks for further analysis of the DURZ rollout, to finalise testing and best ensure the secure, stable and resilient implementation of the root DNSSEC production processes and systems. Prior to 2010-07-15 the U.S. Department of Commerce (DoC) will issue a public notice announcing the publication of the joint ICANN-VeriSign testing and evaluation report as well as the intent to proceed with the final stage of DNSSEC deployment. As part of this notice the DoC will include a public review and comment period prior to taking any action. This change has been reflected in the deployment plan and other documentation, and updated documents will be published at . PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ To come: 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From mjkelly at gmail.com Tue May 18 14:27:55 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Tue, 18 May 2010 15:27:55 -0400 Subject: Hulu rep... Message-ID: If there are any hulu reps on this list that can assist, please contact me off list. You're showing a /18 of ours coming from Canada for some reason. It's causing issues for customers who are assigned IPs from this range. Thanks. -- Matt From colbycciestudy at gmail.com Tue May 18 15:41:09 2010 From: colbycciestudy at gmail.com (Colby Glass) Date: Tue, 18 May 2010 16:41:09 -0400 Subject: useful bgp example In-Reply-To: References: Message-ID: Like everyone else said, don't undertake this unless you know what you're doing. Hire a consultant to come in, or hit the books. Internet Routing Arch is great, as is the O'Reilly BGP book. -- Colby Glass Network Engineer http://blog.alwaysthenetwork.com On Mon, May 17, 2010 at 7:15 PM, Deric Kwok wrote: > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? > > Thank you for your help > > From colbycciestudy at gmail.com Tue May 18 15:43:55 2010 From: colbycciestudy at gmail.com (Colby Glass) Date: Tue, 18 May 2010 16:43:55 -0400 Subject: IPv4 Multicast In-Reply-To: References: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Message-ID: My mcast is rust, but look into CGMP. Switches flood multicasts out all ports by default. -- Colby Glass Network Engineer http://blog.alwaysthenetwork.com On Wed, May 12, 2010 at 12:07 PM, Rens wrote: > I have done some tests with multicast streams, sender & receivers all in > the > same layer 2 vlan, but I also have a pc with just wireshark and I can see > all this traffic. > > I can see that IGMP is enabled on all interfaces but do I need enable > something else? > > Vlan 200: > -------- > IGMP snooping : Enabled > IGMPv2 immediate leave : Disabled > Explicit host tracking : Enabled > Multicast router learning mode : pim-dvmrp > CGMP interoperability mode : IGMP_ONLY > > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] > Sent: mardi 11 mai 2010 15:43 > To: Rens > Cc: nanog at nanog.org > Subject: Re: IPv4 Multicast > > On Tue, 11 May 2010, Rens wrote: > > > Does anyone have any configuration examples for this or tutorials, > > everything on the net seems way to complex for my needs. > > Multicast Quick-Start Configuration Guide > > < > http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a008009482 > 1.shtml > > > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > > From tonyb at go-concepts.com Tue May 18 19:44:34 2010 From: tonyb at go-concepts.com (Tony Bunce) Date: Wed, 19 May 2010 00:44:34 +0000 Subject: IPv4 Multicast In-Reply-To: References: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Message-ID: <38C452D903F47349B03EC558C5863D983C95B7@EXCH2010.gont> >>I can see that IGMP is enabled on all interfaces but do I need enable something else? You need to have a multicast router or enable IGMP querier on one of your switches. For IGMP snooping to work something on the network has to be sending out PIM hellos or IGMP query messages. Without that the switch will flood multicast traffic to all ports "The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter." http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml#understand Note if you go the router method ALL multicast traffic will be sent to the router, so don't expect it to work if you have 5Gbps of multicast connected to a router with a 1Gbps interface. If all your multicast traffic is on the same layer2 network then the IGMP querier feature should work fine. -Tony From frnkblk at iname.com Tue May 18 21:59:37 2010 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 18 May 2010 21:59:37 -0500 Subject: GSM modem test point with data and SMS support Message-ID: We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank From jahiel at gmail.com Wed May 19 01:16:03 2010 From: jahiel at gmail.com (Graham Freeman) Date: Tue, 18 May 2010 23:16:03 -0700 Subject: Seeking advice re problematic DID port-in-progress Message-ID: Hi, folks, After declining to sign a new 2-year $500/mo contract with my formerly-favorite inbound VOIP (DID) provider - a wholesaler based in Brussels - I'm completing the process of porting the last of my DIDs from them off to other providers with lower minimum purchase commitments. The first few dozen went smoothly, with no interruption in service (not counting the ~day of downtime that the Belgian provider put me through as part of their hardball contract negotiation tactics). However, the third-to-last DID has been in limbo for the last 3 days. Right after my new Toronto-based provider reported receiving a FOC date (25 May) for this DID, the DID in question disappeared from my control panel at the Belgian company, and calls to the DID consistently fail from various calling providers. The CDR reports at both provider control panels show no calls (neither successful nor unsuccessful) for the DID in question. When asked about this, the Belgian provider claims that they've been told by "a telco" (they would not name it) that the DID in question has been ported, which is (they claim) why the DID disappeared from my control panel. However, at least a dozen of the DIDs that I ported more than a month ago still show up in this control panel, even though I've confirmed repeatedly that all calls have been routing to the new provider since the port date. Additionally, my new Toronto-based provider (who have been fairly reliable) is certain that none of these calls are arriving at their network, which doesn't surprise them given the FOC of 25th May. Given these facts, and the way the Belgian provider has acted in the course of this contract negotiation, I think I'm being jerked around. The end-user of the DID in question would dearly like for their inbound calls to work again - ideally well before the 25th. I really don't want my next step to be an FCC complaint (I'm based in the US), but I'm not sure what my other options are. Any suggestions? Apologies in advance - and suggestions of better fora welcomed - if this isn't sufficiently on-topic. thanks, Graham From mvh at hosteurope.de Wed May 19 06:31:08 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 19 May 2010 13:31:08 +0200 Subject: eur.army.mil net ops contact? Message-ID: <4BF3CBFC.9060507@hosteurope.de> Hi there, I need to get in contact with someone from (eur.)army.mil network operations staff, since they seem to block our whole AS. Any hints how to reach them? TIA && rgds, Malte -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From robert at ufl.edu Wed May 19 06:37:47 2010 From: robert at ufl.edu (Robert D. Scott) Date: Wed, 19 May 2010 07:37:47 -0400 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3CBFC.9060507@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> Message-ID: <005f01caf747$b48cb760$1da62620$@edu> Normally you need to contact the entity you cannot reach, and they will open a ticket backwards through MilNet. This is the only process I have been able to get to work. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell -----Original Message----- From: Malte von dem Hagen [mailto:mvh at hosteurope.de] Sent: Wednesday, May 19, 2010 7:31 AM To: nanog at nanog.org Subject: eur.army.mil net ops contact? Hi there, I need to get in contact with someone from (eur.)army.mil network operations staff, since they seem to block our whole AS. Any hints how to reach them? TIA && rgds, Malte -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen From lists at xodus.org Wed May 19 06:43:38 2010 From: lists at xodus.org (Marc Powell) Date: Wed, 19 May 2010 06:43:38 -0500 Subject: eur.army.mil net ops contact? In-Reply-To: <005f01caf747$b48cb760$1da62620$@edu> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> Message-ID: <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> On May 19, 2010, at 6:37 AM, Robert D. Scott wrote: > Normally you need to contact the entity you cannot reach, and they will open > a ticket backwards through MilNet. This is the only process I have been able > to get to work. This has been my experience as well when we discovered many .mil institutions weren't properly updating BOGON filters. -- Marc From mvh at hosteurope.de Wed May 19 07:18:08 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 19 May 2010 14:18:08 +0200 Subject: eur.army.mil net ops contact? In-Reply-To: <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> Message-ID: <4BF3D700.1020607@hosteurope.de> On May 19, 2010, at 6:37 AM, Robert D. Scott wrote: > Normally you need to contact the entity you cannot reach, and they will open > a ticket backwards through MilNet. This is the only process I have been able > to get to work. Well, some of our customers try to send mails to them without success, so I am not sure what exactly "the entity" is. We cannot reach www.army.mil, we cannot reach their nameservers, we cannot reach their MXes. Any further hints? TIA && rgds, Malte PS: If someone from there wants to reach me, you maybe want to try noc.as20773 at gmail.com (as unlikely as that may be) ;-) -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From bill at edisys.co.uk Wed May 19 07:24:40 2010 From: bill at edisys.co.uk (William Hamilton) Date: Wed, 19 May 2010 13:24:40 +0100 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3D700.1020607@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> Message-ID: <4BF3D888.7080002@edisys.co.uk> On 19/05/2010 13:18, Malte von dem Hagen wrote: > On May 19, 2010, at 6:37 AM, Robert D. Scott wrote: > >> Normally you need to contact the entity you cannot reach, and they will open >> a ticket backwards through MilNet. This is the only process I have been able >> to get to work. >> > Well, some of our customers try to send mails to them without success, > so I am not sure what exactly "the entity" is. > > We cannot reach www.army.mil, we cannot reach their nameservers, we > cannot reach their MXes. Any further hints? > Raise the issue from outside your network? B From ops.lists at gmail.com Wed May 19 07:28:08 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 19 May 2010 17:58:08 +0530 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3D700.1020607@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> Message-ID: On Wed, May 19, 2010 at 5:48 PM, Malte von dem Hagen wrote: > We cannot reach www.army.mil, we cannot reach their nameservers, we > cannot reach their MXes. Any further hints? In plainer english - Your customer contacts his contact (friend / relative / customer etc) in the US army The army guy contacts his base IT staff to bitch about his email His base IT staff escalates the bitching up through a long and twisty channel Then you may or may not hear a status back, or get your AS unblocked Sit tight and wait, till then -- Suresh Ramasubramanian (ops.lists at gmail.com) From mvh at hosteurope.de Wed May 19 07:36:21 2010 From: mvh at hosteurope.de (Malte von dem Hagen) Date: Wed, 19 May 2010 14:36:21 +0200 Subject: eur.army.mil net ops contact? In-Reply-To: References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> Message-ID: <4BF3DB45.2080303@hosteurope.de> Am 19.05.10 14:24, schrieb William Hamilton: >> Any further hints? > > Raise the issue from outside your network? That's difficult, without any contact information. Am 19.05.10 14:28, schrieb Suresh Ramasubramanian: > Your customer contacts his contact (friend / relative / customer etc) > in the US army > The army guy contacts his base IT staff to bitch about his email > His base IT staff escalates the bitching up through a long and twisty channel > Then you may or may not hear a status back, or get your AS unblocked > Sit tight and wait, till then I am aware of this way, sure. I just hoped, there would be a more... efficient way. Thanks anyway. .m -- Malte von dem Hagen Teamleitung Network Engineering & Operation Abteilung Technik ----------------------------------------------------------------------- Host Europe GmbH - http://www.hosteurope.de Welserstra?e 14 - 51149 K?ln - Germany Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*) HRB 28495 Amtsgericht K?ln - USt-IdNr.: DE187370678 Gesch?ftsf?hrer: Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulverm?ller (*) 0,14 EUR/Min. aus dem dt. Festnetz; maximal 0,42 EUR/Min. aus den dt. Mobilfunknetzen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From ops.lists at gmail.com Wed May 19 07:41:34 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 19 May 2010 18:11:34 +0530 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3DB45.2080303@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> <4BF3DB45.2080303@hosteurope.de> Message-ID: There's this old joke - spread across multiple countries around the world - about there being three ways to do something .. 1. The right way 2. The wrong way 3. The army way viel gl?ck On Wed, May 19, 2010 at 6:06 PM, Malte von dem Hagen wrote: > Am 19.05.10 14:28, schrieb Suresh Ramasubramanian: >> Your customer contacts his contact (friend / relative / customer etc) >> in the US army >> The army guy contacts his base IT staff to bitch about his email >> His base IT staff escalates the bitching up through a long and twisty channel >> Then you may or may not hear a status back, or get your AS unblocked >> Sit tight and wait, till then > > I am aware of this way, sure. I just hoped, there would be a more... > efficient way. -- Suresh Ramasubramanian (ops.lists at gmail.com) From lists at xodus.org Wed May 19 07:42:04 2010 From: lists at xodus.org (Marc Powell) Date: Wed, 19 May 2010 07:42:04 -0500 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3DB45.2080303@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> <4BF3DB45.2080303@hosteurope.de> Message-ID: <4DF6D508-5FBF-4657-B1F2-FDABFD0DBB14@xodus.org> > I am aware of this way, sure. I just hoped, there would be a more... > efficient way. There is not. The various branches we worked with wouldn't touch it unless the ticket originated internally. Once that happened, we found them to be very cooperative and helpful. Another note - each branch is separate for the most part. If you're having problems reaching the Army, Navy, National Guard, etc..., they're pretty much independent and you need to work each one separately. -- Marc From jeroen at unfix.org Wed May 19 07:45:32 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 19 May 2010 14:45:32 +0200 Subject: eur.army.mil net ops contact? In-Reply-To: <4BF3DB45.2080303@hosteurope.de> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> <4BF3DB45.2080303@hosteurope.de> Message-ID: <4BF3DD6C.9060300@unfix.org> On 2010-05-19 14:36, Malte von dem Hagen wrote: [..] > I am aware of this way, sure. I just hoped, there would be a more... > efficient way. State publically that you know the location of a known terrorist somewhere in the top X of the wanted list. Tell them that they can reach you at email address Y, but only if they unblock Z. Some three-letter acronym person will now already be reading this thread intensely because of several trigger words above.... presto. Otherwise said: you are not important enough for attention ;) Nasty but probably true. Greets, Jeroen From nils.kolstein at sscplus.nl Wed May 19 07:57:07 2010 From: nils.kolstein at sscplus.nl (Nils Kolstein) Date: Wed, 19 May 2010 14:57:07 +0200 Subject: eur.army.mil net ops contact? In-Reply-To: <4DF6D508-5FBF-4657-B1F2-FDABFD0DBB14@xodus.org> References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> <4BF3DB45.2080303@hosteurope.de> <4DF6D508-5FBF-4657-B1F2-FDABFD0DBB14@xodus.org> Message-ID: <4BF3E023.5070608@sscplus.nl> > There is not. The various branches we worked with wouldn't touch it unless the ticket originated internally. Once that happened, we found them to be very cooperative and helpful. > > Another note - each branch is separate for the most part. If you're having problems reaching the Army, Navy, National Guard, etc..., they're pretty much independent and you need to work each one separately. > > -- > Marc > Actually, there is the Defense Information Systems Agency which provides support for all branches and partners (NATO etc..). Check http://www.disa.mil/contact/ I don't know if this contact page accepts issues from outside the US MIL organization (as Marc posted), but you might give it a try. Nils Kolstein From AdamKennedy at omnicity.net Wed May 19 09:18:15 2010 From: AdamKennedy at omnicity.net (Adam Kennedy) Date: Wed, 19 May 2010 10:18:15 -0400 Subject: GSM modem test point with data and SMS support In-Reply-To: References: Message-ID: The SAMBA modems are USB powered and can respond to normal AT commands for things like signal strength and so forth. Using the sms-tools kit, you can also send/receive SMS messages. The SAMBA modem I have supports EDGE. -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, May 18, 2010 11:00 PM To: nanog at nanog.org Subject: GSM modem test point with data and SMS support We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank From AdamKennedy at omnicity.net Wed May 19 09:21:45 2010 From: AdamKennedy at omnicity.net (Adam Kennedy) Date: Wed, 19 May 2010 10:21:45 -0400 Subject: GSM modem test point with data and SMS support In-Reply-To: References: Message-ID: Some additional information on the SAMBA modems can be found at the manufacturer site: http://www.falcomusa.com/ -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] Sent: Wednesday, May 19, 2010 10:18 AM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: GSM modem test point with data and SMS support The SAMBA modems are USB powered and can respond to normal AT commands for things like signal strength and so forth. Using the sms-tools kit, you can also send/receive SMS messages. The SAMBA modem I have supports EDGE. -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, May 18, 2010 11:00 PM To: nanog at nanog.org Subject: GSM modem test point with data and SMS support We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank From jwbensley at gmail.com Wed May 19 10:15:29 2010 From: jwbensley at gmail.com (James Bensley) Date: Wed, 19 May 2010 16:15:29 +0100 Subject: [OT]Bounce Back Message-ID: Got the below message back from Hotmail when emailing a friend I email every week. I have never experienced this particular error before, is this just an indication of high traffic between Google Mail and Hotmail? ---------- Forwarded message ---------- From: Mail Delivery Subsystem Date: 18 May 2010 23:06 Subject: Delivery Status Notification (Delay) To: me This is an automatically generated Delivery Status Notification THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: ? ? xxxxxxx at hotmail.co.uk Message will be retried for 2 more day(s) Technical details of temporary failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 421 421 RP-001 The mail server IP connecting to Windows Live Hotmail server has exceeded the rate limit allowed. Reason for rate limitation is related to IP/domain reputation problems. If you are not an email/network admin please contact your E-mail/Internet Service Provider for help. Email/network admins, please visit http://postmaster.live.com for email delivery information and support (state 13). ----- Original message ----- Received: by 10.231.184.75 with SMTP id cj11mt3081679ibb.51.1274129866890; ? ? ? ?Mon, 17 May 2010 13:57:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.15.198 with HTTP; Mon, 17 May 2010 13:57:13 -0700 (PDT) From: me Date: Mon, 17 May 2010 21:57:13 +0100 Message-ID: Subject: xxxxxxxx Content-Type: text/plain; charset=ISO-8859-1 -- Regards, James. http://www.jamesbensley.co.cc/ From bbillon-ml at splio.fr Wed May 19 10:22:19 2010 From: bbillon-ml at splio.fr (Benjamin BILLON) Date: Wed, 19 May 2010 17:22:19 +0200 Subject: [OT]Bounce Back In-Reply-To: References: Message-ID: <4BF4022B.7020702@splio.fr> High and bad, the message says it all! http://mail.live.com/mail/troubleshooting.aspx This is bad luck for you as you don't choose which IP address googlemail will use to contact Hotmail UK's servers. Le 19/05/2010 17:15, James Bensley a ?crit : > Got the below message back from Hotmail when emailing a friend I email > every week. I have never experienced this particular error before, is > this just an indication of high traffic between Google Mail and > Hotmail? > > > ---------- Forwarded message ---------- > From: Mail Delivery Subsystem > Date: 18 May 2010 23:06 > Subject: Delivery Status Notification (Delay) > To: me > > > This is an automatically generated Delivery Status Notification > > THIS IS A WARNING MESSAGE ONLY. > > YOU DO NOT NEED TO RESEND YOUR MESSAGE. > > Delivery to the following recipient has been delayed: > > xxxxxxx at hotmail.co.uk > > Message will be retried for 2 more day(s) > > Technical details of temporary failure: > Google tried to deliver your message, but it was rejected by the > recipient domain. We recommend contacting the other email provider for > further information about the cause of this error. The error that the > other server returned was: 421 421 RP-001 The mail server IP > connecting to Windows Live Hotmail server has exceeded the rate limit > allowed. Reason for rate limitation is related to IP/domain reputation > problems. If you are not an email/network admin please contact your > E-mail/Internet Service Provider for help. Email/network admins, > please visit http://postmaster.live.com for email delivery information > and support (state 13). > > ----- Original message ----- > > Received: by 10.231.184.75 with SMTP id cj11mt3081679ibb.51.1274129866890; > Mon, 17 May 2010 13:57:46 -0700 (PDT) > MIME-Version: 1.0 > Received: by 10.231.15.198 with HTTP; Mon, 17 May 2010 13:57:13 -0700 (PDT) > From: me > Date: Mon, 17 May 2010 21:57:13 +0100 > Message-ID: > Subject: xxxxxxxx > Content-Type: text/plain; charset=ISO-8859-1 > > From jharper at first-american.net Wed May 19 13:26:08 2010 From: jharper at first-american.net (Jeff Harper) Date: Wed, 19 May 2010 13:26:08 -0500 Subject: useful bgp example In-Reply-To: References: Message-ID: > -----Original Message----- > From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] > Sent: Monday, May 17, 2010 6:15 PM > To: nanog at nanog.org > Subject: useful bgp example > > Hi > > My company will get 2 upstream provider. We will plan 2 routers and > each router to connect one provider to use bgp for redundant. > Do you have any useful bgp example and website to set it up? > > Thank you for your help This jpg should help, has config on it as well. Jeff -------------- next part -------------- A non-text attachment was scrubbed... Name: bgp1.jpg Type: image/jpeg Size: 68776 bytes Desc: bgp1.jpg URL: From jared at puck.nether.net Wed May 19 13:29:21 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 19 May 2010 14:29:21 -0400 Subject: useful bgp example In-Reply-To: References: Message-ID: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> On May 19, 2010, at 2:26 PM, Jeff Harper wrote: >> -----Original Message----- >> From: Deric Kwok [mailto:deric.kwok2000 at gmail.com] >> Sent: Monday, May 17, 2010 6:15 PM >> To: nanog at nanog.org >> Subject: useful bgp example >> >> Hi >> >> My company will get 2 upstream provider. We will plan 2 routers and >> each router to connect one provider to use bgp for redundant. >> Do you have any useful bgp example and website to set it up? >> >> Thank you for your help > > This jpg should help, has config on it as well. > > Jeff > Nice, but you don't show it as-path filtering your transits out. I frequently see people take something learned from transit A and sending it to transit B, and if it happens to be the backup path in-use for your customer, your transits will accept it and likely pick you as best-path and hairpin through your network. - Jared From jharper at first-american.net Wed May 19 13:37:32 2010 From: jharper at first-american.net (Jeff Harper) Date: Wed, 19 May 2010 13:37:32 -0500 Subject: useful bgp example In-Reply-To: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> Message-ID: > -----Original Message----- > From: Jared Mauch [mailto:jared at puck.nether.net] > Sent: Wednesday, May 19, 2010 1:29 PM > To: Jeff Harper > Cc: Deric Kwok; nanog at nanog.org > Subject: Re: useful bgp example > > Nice, but you don't show it as-path filtering your transits out. I > frequently see people take something learned from transit A and sending > it to transit B, and if it happens to be the backup path in-use for > your customer, your transits will accept it and likely pick you as > best-path and hairpin through your network. > > - Jared Yeah, I left out the actual prefix-list contents, in hindsight I should have added it, so here it is. Also, a typo in the network statement, lol. network 1.1.1.0 mask 255.255.0.0 ip prefix-list NETZ description The networks we advertise via BGP ip prefix-list NETZ seq 10 permit 1.1.1.0/16 ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 From dwhite at olp.net Wed May 19 13:58:38 2010 From: dwhite at olp.net (Dan White) Date: Wed, 19 May 2010 13:58:38 -0500 Subject: useful bgp example In-Reply-To: References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> Message-ID: <20100519185837.GE4882@dan.olp.net> On 19/05/10?13:37?-0500, Jeff Harper wrote: >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Wednesday, May 19, 2010 1:29 PM >> To: Jeff Harper >> Cc: Deric Kwok; nanog at nanog.org >> Subject: Re: useful bgp example >> >> Nice, but you don't show it as-path filtering your transits out. I >> frequently see people take something learned from transit A and >sending >> it to transit B, and if it happens to be the backup path in-use for >> your customer, your transits will accept it and likely pick you as >> best-path and hairpin through your network. >> >> - Jared > >Yeah, I left out the actual prefix-list contents, in hindsight I should >have added it, so here it is. Also, a typo in the network statement, >lol. > >network 1.1.1.0 mask 255.255.0.0 > >ip prefix-list NETZ description The networks we advertise via BGP >ip prefix-list NETZ seq 10 permit 1.1.1.0/16 >ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 You should be using 192.168.2.0 for documented examples,or at least private space. Configs like this tend to get cut and pasted into routers and get changed only when they don't work. I just had to change a router config a couple of months ago that a consult had set up using 11.0.0.0/24 and 12.0.0.0/24, for point to point links. -- Dan White From v.jones at networkingunlimited.com Wed May 19 14:04:15 2010 From: v.jones at networkingunlimited.com (Vincent C Jones) Date: Wed, 19 May 2010 15:04:15 -0400 Subject: useful bgp example In-Reply-To: References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> Message-ID: <1274295855.3075.75.camel@X61.NetworkingUnlimited.nul> On Wed, 2010-05-19 at 13:37 -0500, Jeff Harper wrote: > > From: Jared Mauch [mailto:jared at puck.nether.net] > > Sent: Wednesday, May 19, 2010 1:29 PM > > To: Jeff Harper > > Cc: Deric Kwok; nanog at nanog.org > > Subject: Re: useful bgp example > > > > Nice, but you don't show it as-path filtering your transits out. I > > frequently see people take something learned from transit A and > sending > > it to transit B, and if it happens to be the backup path in-use for > > your customer, your transits will accept it and likely pick you as > > best-path and hairpin through your network. > > > > - Jared > > Yeah, I left out the actual prefix-list contents, in hindsight I should > have added it, so here it is. Also, a typo in the network statement, > lol. > > network 1.1.1.0 mask 255.255.0.0 > > ip prefix-list NETZ description The networks we advertise via BGP > ip prefix-list NETZ seq 10 permit 1.1.1.0/16 > ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 FYI: It's got to be either 1.1.1.0/24 or 1.1.0.0/16. And there is plenty more that belongs in an appropriate setup for a realistic usage scenario. This is why we are all advising the OP to get some knowledgeable help. Vince -- Vincent C. Jones Networking Unlimited, Inc. Phone: +1 201 568-7810 V.Jones at NetworkingUnlimited.com From mpalmer at hezmatt.org Wed May 19 15:14:40 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Thu, 20 May 2010 06:14:40 +1000 Subject: eur.army.mil net ops contact? In-Reply-To: References: <4BF3CBFC.9060507@hosteurope.de> <005f01caf747$b48cb760$1da62620$@edu> <959E47DF-B487-4FEC-8ED1-E04517658B7A@xodus.org> <4BF3D700.1020607@hosteurope.de> <4BF3DB45.2080303@hosteurope.de> Message-ID: <20100519201440.GG30482@hezmatt.org> On Wed, May 19, 2010 at 06:11:34PM +0530, Suresh Ramasubramanian wrote: > There's this old joke - spread across multiple countries around the > world - about there being three ways to do something .. > > 1. The right way > 2. The wrong way > 3. The army way I know it as "3. The railway", and boy ain't it the truth... - Matt From jimb at jsbc.cc Wed May 19 15:18:15 2010 From: jimb at jsbc.cc (Jim Burwell) Date: Wed, 19 May 2010 13:18:15 -0700 Subject: useful bgp example In-Reply-To: <20100519185837.GE4882@dan.olp.net> References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> <20100519185837.GE4882@dan.olp.net> Message-ID: <4BF44787.7090104@jsbc.cc> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/19/2010 11:58, Dan White wrote: > You should be using 192.168.2.0 for documented examples,or at least > private > space. Configs like this tend to get cut and pasted into routers and > get > changed only when they don't work. Should that be 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24 (TEST-NET-3) per RFC 5737 ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv0R4UACgkQ2fXFxl4S7sScDACgulmdHhk6QJX/OlfvP1cCMq2e TZcAoIgrbd9HPFjpoSJvRFbML8VgckKj =zKse -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5570 bytes Desc: S/MIME Cryptographic Signature URL: From frnkblk at iname.com Wed May 19 15:58:30 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Wed, 19 May 2010 15:58:30 -0500 Subject: GSM modem test point with data and SMS support In-Reply-To: References: Message-ID: Thanks for your response and three I received off-list. Multi-tech confirmed that none of their models can do SMS and EDGE at the same time. They have to be out of PPP mode to send and receive SMS. Frank -----Original Message----- From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] Sent: Wednesday, May 19, 2010 9:22 AM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: GSM modem test point with data and SMS support Some additional information on the SAMBA modems can be found at the manufacturer site: http://www.falcomusa.com/ -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] Sent: Wednesday, May 19, 2010 10:18 AM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: GSM modem test point with data and SMS support The SAMBA modems are USB powered and can respond to normal AT commands for things like signal strength and so forth. Using the sms-tools kit, you can also send/receive SMS messages. The SAMBA modem I have supports EDGE. -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, May 18, 2010 11:00 PM To: nanog at nanog.org Subject: GSM modem test point with data and SMS support We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank From jeroen at mompl.net Wed May 19 16:05:56 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 19 May 2010 14:05:56 -0700 Subject: HUMOUR: http://xkcd.com/742/ Message-ID: <4BF452B4.5040606@mompl.net> http://xkcd.com/742/ is a bit funny, especially if you read the "alt" text of the image. Especially in the light of ongoing discussions about IPv6 :-) -- http://goldmark.org/jeff/stupid-disclaimers/ From aosgood at streamline-solutions.net Wed May 19 16:18:33 2010 From: aosgood at streamline-solutions.net (Aaron D. Osgood) Date: Wed, 19 May 2010 21:18:33 +0000 Subject: GSM modem test point with data and SMS support In-Reply-To: References: Message-ID: <1692874486-1274303919-cardhu_decombobulator_blackberry.rim.net-1883490791-@bda325.bisx.prod.on.blackberry> Probably because MO/MT (mobile originated/mobile terminated) SMS takes place on the cellular "control" channel (somewhat like the "D" channel on a PRI span) and is not seen as "data" by the carrier. Sent from my BlackBerry? smartphone with Nextel Direct Connect -----Original Message----- From: "Frank Bulk - iName.com" Date: Wed, 19 May 2010 15:58:30 To: 'Adam Kennedy'; Subject: RE: GSM modem test point with data and SMS support Thanks for your response and three I received off-list. Multi-tech confirmed that none of their models can do SMS and EDGE at the same time. They have to be out of PPP mode to send and receive SMS. Frank -----Original Message----- From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] Sent: Wednesday, May 19, 2010 9:22 AM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: GSM modem test point with data and SMS support Some additional information on the SAMBA modems can be found at the manufacturer site: http://www.falcomusa.com/ -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] Sent: Wednesday, May 19, 2010 10:18 AM To: frnkblk at iname.com; nanog at nanog.org Subject: RE: GSM modem test point with data and SMS support The SAMBA modems are USB powered and can respond to normal AT commands for things like signal strength and so forth. Using the sms-tools kit, you can also send/receive SMS messages. The SAMBA modem I have supports EDGE. -- Adam Kennedy Network Engineer Omnicity, Inc. -----Original Message----- From: Frank Bulk [mailto:frnkblk at iname.com] Sent: Tuesday, May 18, 2010 11:00 PM To: nanog at nanog.org Subject: GSM modem test point with data and SMS support We have some interest in testing the real-world connectivity of several cellular towers using a GSM modem that has both a IP address on the WWAN and has SMS support. Is anyone aware of a self-contained box that supports both technologies? EDGE support is preferred, but GPRS would be acceptable. Frank From adam at nasa.gov Wed May 19 16:28:32 2010 From: adam at nasa.gov (Henson, Adam J. (ARC-IO)[PEROT SYSTEMS]) Date: Wed, 19 May 2010 16:28:32 -0500 Subject: AT&T Wireless DNS contact Message-ID: <941FB2EB-8A65-4344-AE34-FAEE855660A2@nasa.gov> Hi all, Apologies for the spam, but can someone at AT&T Wireless with DNS clue contact me off-list? Our iPhones are receiving intermittent SERVFAILs when querying your DNS servers over 3G. We're trying to go through the support chain but it's getting us nowhere fast. Thanks, Adam Henson Network Engineering NASA Ames Research Center adam at nasa.gov From franck at genius.com Wed May 19 16:36:25 2010 From: franck at genius.com (Franck Martin) Date: Wed, 19 May 2010 23:36:25 +0200 (CEST) Subject: AT&T Wireless DNS contact In-Reply-To: <941FB2EB-8A65-4344-AE34-FAEE855660A2@nasa.gov> Message-ID: <17097962.359.1274304981078.JavaMail.franck@new-host.home> iPhones (at the time of 2G) used to have a major issue, they would not fallback to the secondary DNS if the first failed. ----- Original Message ----- From: "Adam J. Henson (ARC-IO)[PEROT SYSTEMS]" To: nanog at nanog.org Sent: Wednesday, 19 May, 2010 11:28:32 PM Subject: AT&T Wireless DNS contact Hi all, Apologies for the spam, but can someone at AT&T Wireless with DNS clue contact me off-list? Our iPhones are receiving intermittent SERVFAILs when querying your DNS servers over 3G. We're trying to go through the support chain but it's getting us nowhere fast. Thanks, Adam Henson Network Engineering NASA Ames Research Center adam at nasa.gov From joelja at bogus.com Wed May 19 17:37:15 2010 From: joelja at bogus.com (joel jaeggli) Date: Wed, 19 May 2010 15:37:15 -0700 Subject: GSM modem test point with data and SMS support In-Reply-To: <1692874486-1274303919-cardhu_decombobulator_blackberry.rim.net-1883490791-@bda325.bisx.prod.on.blackberry> References: <1692874486-1274303919-cardhu_decombobulator_blackberry.rim.net-1883490791-@bda325.bisx.prod.on.blackberry> Message-ID: <4BF4681B.4070701@bogus.com> On 2010-05-19 14:18, Aaron D. Osgood wrote: > Probably because MO/MT (mobile originated/mobile terminated) SMS takes place on the cellular "control" channel (somewhat like the "D" channel on a PRI span) and is not seen as "data" by the carrier. A GPRS station class A device can do this... they have to have dual radios in order to do so. first one I had was nokia e90 communicator back in 2008. > Sent from my BlackBerry? smartphone with Nextel Direct Connect > > -----Original Message----- > From: "Frank Bulk - iName.com" > Date: Wed, 19 May 2010 15:58:30 > To: 'Adam Kennedy'; > Subject: RE: GSM modem test point with data and SMS support > > Thanks for your response and three I received off-list. > > Multi-tech confirmed that none of their models can do SMS and EDGE at the > same time. They have to be out of PPP mode to send and receive SMS. > > Frank > > -----Original Message----- > From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] > Sent: Wednesday, May 19, 2010 9:22 AM > To: frnkblk at iname.com; nanog at nanog.org > Subject: RE: GSM modem test point with data and SMS support > > Some additional information on the SAMBA modems can be found at the > manufacturer site: > http://www.falcomusa.com/ > > -- > Adam Kennedy > Network Engineer > Omnicity, Inc. > > > -----Original Message----- > From: Adam Kennedy [mailto:AdamKennedy at omnicity.net] > Sent: Wednesday, May 19, 2010 10:18 AM > To: frnkblk at iname.com; nanog at nanog.org > Subject: RE: GSM modem test point with data and SMS support > > The SAMBA modems are USB powered and can respond to normal AT commands for > things like signal strength and so forth. Using the sms-tools kit, you can > also send/receive SMS messages. The SAMBA modem I have supports EDGE. > > -- > Adam Kennedy > Network Engineer > Omnicity, Inc. > > > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Tuesday, May 18, 2010 11:00 PM > To: nanog at nanog.org > Subject: GSM modem test point with data and SMS support > > We have some interest in testing the real-world connectivity of several > cellular towers using a GSM modem that has both a IP address on the WWAN and > has SMS support. Is anyone aware of a self-contained box that supports both > technologies? EDGE support is preferred, but GPRS would be acceptable. > > Frank > > > > From joelja at bogus.com Wed May 19 23:34:05 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 19 May 2010 21:34:05 -0700 Subject: BGP and convergence time In-Reply-To: <20100512144100.4C012F09@resin12.mta.everyone.net> References: <20100512144100.4C012F09@resin12.mta.everyone.net> Message-ID: <4BF4BBBD.10303@bogus.com> On 05/12/2010 02:41 PM, Scott Weeks wrote: > > > --- danny at tcb.net wrote: From: Danny McPherson On May > 12, 2010, at 9:40 AM, Jay Nakamura wrote: > >> I just tested this and, yes, with Cisco to Cisco, changing the >> setting won't reset the connection but you have to reset the >> connection to have the value take effect. I need to look up what >> happens when two sides are set to different values and which one >> takes precedent. > > : The holdtime isn't technically negotiated, both sides convey their > : value in the open message and the lower of the two is used by both > : BGP speakers. > > This isn't a negotiation? > > > : IIRC, neither J or C reset the session with the timer change, but > the : new holdtimer expiry value doesn't take effect until then. > > We use Alcatel 7750s. Damn thing just resets the session; no > warning, no nothing. :-( > > > > : One other thing to note is that by default, keepalive intervals in > : those implementations are {holdtime/3}. Normally, if you're > setting : holdtime to something really lower (e.g., 10 seconds) you > might want : to increase the frequency of keepalives such that the > probability of : getting one through in times of instability rise. > In particular, : congestion incurred outside of BGP, as update > messages themselves : will serve as implicit keepalives, and with the > amount of churn in BGP, : empty updates (keepalives) are rare for > most speakers with a global BGP : view. > > I have been looking for info on the negative impact on a router by > increasing the keepalive frequency to a high rate. I'm sure it's > minimal for a few BGP peers, but I could imagine with a lot of peers > it's a non-zero impact. with a keep alive interval of 10 seconds you can expect to get 10pps from a 100 peers. the keepalive message is 19bytes That doesn't seem particularly hurtful even by the standards of 5 year old control plane processors. > scott > > > > > > From funkyfun at gmail.com Thu May 20 07:06:48 2010 From: funkyfun at gmail.com (Net) Date: Thu, 20 May 2010 08:06:48 -0400 Subject: Partial Use Of one Regions IP Block in another Message-ID: Hi folks, Are there any policies set by internet registries and/or transit providers today that prohibits organizations from using a Partially used IP Block allocated in one region say AP through APNIC to be comissioned and Propagated in another region such as EMEA serviced by RIPE?. Obv, the best approach would be to acquire a new Block in the 2nd region through its own registry, but sometimes due to strict prvisioning timelines, legal delays in getting the necessary approvals involved etc make this option less attractive. From an IPV4 space depletion perspective as well, it might be feasible if organizations having a large block in one region could split it amongst multiple regions to prevent Wastage. Any thoughts/expereinces and feedback would be appreciated. Regards, -- Sent from my mobile device From pfunix at gmail.com Thu May 20 07:56:25 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 20 May 2010 06:56:25 -0600 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: References: Message-ID: From my experience with the provider I have, when I try to acquire IP space to let's say on the RIPE side (Im on the LACNIC side) for reasons like greater visibility (some how). I believe that RIPE requires me to have a company registered on the EMEA side or have my provider place it for me. but i guess when i disengage with that provider, I may need to give back the IP space they have provided me. On Thu, May 20, 2010 at 6:06 AM, Net wrote: > Hi folks, > > Are there any policies set by internet registries and/or transit > providers today that prohibits organizations from using a Partially > used IP Block allocated in one region say AP through APNIC to be > comissioned and Propagated in another region such as EMEA serviced by > RIPE?. > > Obv, the best approach would be to acquire a new Block in the 2nd > region through its own registry, but sometimes due to strict > prvisioning timelines, legal delays in getting the necessary approvals > involved etc make this option less attractive. From an IPV4 space > depletion perspective as well, it might be feasible if organizations > having a large block in one region could split it amongst multiple > regions to prevent Wastage. > > Any thoughts/expereinces and feedback would be appreciated. > > Regards, > > -- > Sent from my mobile device > > -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From owen at delong.com Thu May 20 09:37:18 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 20 May 2010 07:37:18 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: References: Message-ID: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> There is absolutely nothing wrong with an organization getting all of it's IP resources world wide from a single registry if they prefer to do so. There is no policy prohibiting this in any registry. The policies are designed to prevent "registry shopping" by organizations with neither infrastructure nor presence in a region. There is no need, whatsoever to procure multiple address chunks from multiple registries in order to have infrastructure in more than one region. You state "Obv, the best approach...". I don't think so. I think the best approach is whatever allows you to make most efficient use of your address space. Usually this will be from a single RIR rather than a multiple RIR approach. Owen On May 20, 2010, at 5:06 AM, Net wrote: > Hi folks, > > Are there any policies set by internet registries and/or transit > providers today that prohibits organizations from using a Partially > used IP Block allocated in one region say AP through APNIC to be > comissioned and Propagated in another region such as EMEA serviced by > RIPE?. > > Obv, the best approach would be to acquire a new Block in the 2nd > region through its own registry, but sometimes due to strict > prvisioning timelines, legal delays in getting the necessary approvals > involved etc make this option less attractive. From an IPV4 space > depletion perspective as well, it might be feasible if organizations > having a large block in one region could split it amongst multiple > regions to prevent Wastage. > > Any thoughts/expereinces and feedback would be appreciated. > > Regards, > > -- > Sent from my mobile device From tonyb at go-concepts.com Thu May 20 10:09:09 2010 From: tonyb at go-concepts.com (Tony Bunce) Date: Thu, 20 May 2010 15:09:09 +0000 Subject: Bell South RTBH Message-ID: <38C452D903F47349B03EC558C5863D983CC828@EXCH2010.gont> Does anyone know if Bell South/AT&T (AS6386) has a RTBH BGP community? We just experienced a DoS attack and by the time we got through to support it had stopped. The tech told us they don't offer remote triggered blackholes but I'm not sure they exactly knew what we were asking for. It looks like our other upstream (Qwest) provides RTBH via BGP community "209:0" Thanks in advance! -Tony From itservices88 at gmail.com Thu May 20 10:33:47 2010 From: itservices88 at gmail.com (itservices88) Date: Thu, 20 May 2010 08:33:47 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Message-ID: I am having this problem now: # dnssec-signzone -N INCREMENT mydomain.org Verifying the zone using the following algorithms: RSASHA1. Missing RSASHA1 signature for . NSEC The zone is not fully signed for the following algorithms: RSASHA1. dnssec-signzone: fatal: DNSSEC completeness test failed. What could be wrong .... I have followed these steps: OS = centos 5.4 with bind-9.6.2-3.P1 dnssec-keygen -a RSASHA1 -b 1024 -n ZONE mydomain.org dnssec-keygen -f KSK -a RSASHA1 -b 2048 -n ZONE mydomain.org cat Kmydomain.org.+005+*.key >> mydomain.org dnssec-signzone -N INCREMENT mydomain.org Thanks -dani On Sun, May 16, 2010 at 11:52 AM, Rubens Kuhl wrote: > You probably need a trust anchor as well. > See http://ftp.isc.org/isc/pubs/tn/isc-tn-2006-1.html. > > Rubens > > > On Sun, May 16, 2010 at 3:14 PM, itservices88 > wrote: > > Hi, > > > > I was building a test domain for trying out the dnssec. However as > mentioned > > on various websites "ad" appears in the flags, but i can't see it. The > > domain i am using is not real and i am testing from the same machine, > > Fedora-12. Any help? > > > > Thanks > > > > > > options { > > dnssec-enable yes; > > dnssec-validation yes; > > }; > > > > [root at ns1 named-data]# dig +dnssec @localhost www > > ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> +dnssec @localhost www > > ; (2 servers found) > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16601 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 4096 > > ;; QUESTION SECTION: > > ;www. IN A > > ;; AUTHORITY SECTION: > > . 5221 IN SOA a.root-servers.net. > > nstld.verisign-grs.com. 2010051600 1800 900 604800 86400 > > . 5221 IN RRSIG SOA 8 0 86400 > 20100523070000 > > 20100516060000 55138 . > > KTwve6TiQ6ShXCfEcbYusFWOCsx+IwCUumBr4GnwnNq1eqs7tqQaHqkJ > > T/ewcvjXvRGOmHjhGRgqkdESse+/fa+tz1sSdvMsTGGI2Ba9/Fbb43Ty > > eqsG5cFxbqfXOpwlA4ab9IR2Vkod6genONeYO6rrm2edNwQrf56wrtJr CNM= > > . 5221 IN RRSIG NSEC 8 0 86400 > > 20100523070000 20100516060000 55138 . > > uIgAQvJUyLjAPwb7zB8wcJ4wk++21g+iF/bJGlpvz4iUJOMwkPgqA2s/ > > A8W0MhxBjo7918xg6yJeqYwXB+rGG14F7UZfOBVlXIqno5/kXzi4Carh > > /8sulBMyHbFmVlOht5SLU230ROaI6+4o0B6IRyiP5Vzgjt00zyFu26Rg Yb8= > > . 5221 IN NSEC ac. NS SOA RRSIG NSEC > DNSKEY > > ws. 5221 IN RRSIG NSEC 8 1 86400 > > 20100523070000 20100516060000 55138 . > > KsvM0PTDqWt0yoJNZ4k1UGTw0UtJZxsZa17bDHAyY7w1eocZlCqGJNd8 > > 2/WDeJMfCkM+MakJLblnixlI6QcNYV6ctrKZkNuA/iX2rwapouVYoC7G > > HxvBLnb5TFWkCML+fhgOWza8RmRnCTY593uBgsPtcgEfTZAzYB+QFCEP 6oI= > > ws. 5221 IN NSEC ????. NS RRSIG NSEC > > ;; Query time: 11 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Sun May 16 11:02:43 2010 > > ;; MSG SIZE rcvd: 641 > > > > =============================================================== > > On Wed, May 5, 2010 at 2:23 PM, Joe Abley wrote: > > > >> Root Zone DNSSEC Deployment > >> Technical Status Update 2010-05-05 > >> > >> This is the sixth of a series of technical status updates intended > >> to inform a technical audience on progress in signing the root zone > >> of the DNS. > >> > >> > >> ** The final transition to a signed root zone took place today > >> ** on J-Root, between 1700--1900 UTC. > >> ** > >> ** All root servers are now serving a signed root zone. > >> ** > >> ** All root servers will now generate larger responses to DNS > >> ** queries that request DNSSEC information. > >> ** > >> ** If you experience technical problems or need to contact > >> ** technical project staff, please send e-mail to rootsign at icann.org > >> ** or call the ICANN DNS NOC at +1 310 301 5817, e-mail preferred > >> ** if possible. > >> ** > >> ** See below for more details. > >> > >> > >> RESOURCES > >> > >> Details of the project, including documentation published to date, > >> can be found at . > >> > >> We'd like to hear from you. If you have feedback for us, please > >> send it to rootsign at icann.org. > >> > >> > >> DEPLOYMENT STATUS > >> > >> The incremental deployment of DNSSEC in the Root Zone is being > >> carried out first by serving a Deliberately Unvalidatable Root Zone > >> (DURZ), and subsequently by a conventionally signed root zone. > >> Discussion of the approach can be found in the document "DNSSEC > >> Deployment for the Root Zone", as well as in the technical presentations > >> delivered at RIPE, NANOG, IETF and ICANN meetings. > >> > >> All of the thirteen root servers have now made the transition to > >> the to the DURZ. No harmful effects have been identified. > >> > >> The final root server to make the transition, J-Root, started serving > >> the DURZ in a maintenance window between 1700--1900 UTC on 2010-05-05. > >> > >> Initial observations relating to this transition will be presented > >> and discussed at the DNS Working Group meeting at RIPE 60 in Prague > >> on 2010-05-06. > >> > >> > >> PLANNED DEPLOYMENT SCHEDULE > >> > >> Already completed: > >> > >> 2010-01-27: L starts to serve DURZ > >> > >> 2010-02-10: A starts to serve DURZ > >> > >> 2010-03-03: M, I start to serve DURZ > >> > >> 2010-03-24: D, K, E start to serve DURZ > >> > >> 2010-04-14: B, H, C, G, F start to serve DURZ > >> > >> 2010-05-05: J starts to serve DURZ > >> > >> To come: > >> > >> 2010-07-01: Distribution of validatable, production, signed root > >> zone; publication of root zone trust anchor > >> > >> (Please note that this schedule is tentative and subject to change > >> based on testing results or other unforeseen factors.) > >> > >> > >> > > > From Valdis.Kletnieks at vt.edu Thu May 20 10:53:13 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 May 2010 11:53:13 -0400 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: Your message of "Thu, 20 May 2010 08:33:47 PDT." References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> Message-ID: <4902.1274370793@localhost> On Thu, 20 May 2010 08:33:47 PDT, itservices88 said: > I am having this problem now: > > # dnssec-signzone -N INCREMENT mydomain.org > Verifying the zone using the following algorithms: RSASHA1. > Missing RSASHA1 signature for . NSEC Missing trust anchor? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From itservices88 at gmail.com Thu May 20 11:18:46 2010 From: itservices88 at gmail.com (itservices88) Date: Thu, 20 May 2010 09:18:46 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <4902.1274370793@localhost> References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> <4902.1274370793@localhost> Message-ID: I have these in named.conf dnssec-enable yes; dnssec-validation yes; // dnssec-lookaside "." trust-anchor "DLV.ISC.ORG"; With the trust-anchor uncommented, as soon as i enable and reload bind, dig gives timeout, while dig has no issues with first two commands enabled. -dani On Thu, May 20, 2010 at 8:53 AM, wrote: > On Thu, 20 May 2010 08:33:47 PDT, itservices88 said: > > I am having this problem now: > > > > # dnssec-signzone -N INCREMENT mydomain.org > > Verifying the zone using the following algorithms: RSASHA1. > > Missing RSASHA1 signature for . NSEC > > Missing trust anchor? > > From itservices88 at gmail.com Thu May 20 11:19:44 2010 From: itservices88 at gmail.com (itservices88) Date: Thu, 20 May 2010 09:19:44 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <4902.1274370793@localhost> References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> <4902.1274370793@localhost> Message-ID: Is there any specific dnssec mailing list, which might be more helpful. Thanks -dani On Thu, May 20, 2010 at 8:53 AM, wrote: > On Thu, 20 May 2010 08:33:47 PDT, itservices88 said: > > I am having this problem now: > > > > # dnssec-signzone -N INCREMENT mydomain.org > > Verifying the zone using the following algorithms: RSASHA1. > > Missing RSASHA1 signature for . NSEC > > Missing trust anchor? > > From gbonser at seven.com Thu May 20 11:14:36 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 20 May 2010 09:14:36 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> References: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, May 20, 2010 7:37 AM > To: Net > Cc: nanog at nanog.org > Subject: Re: Partial Use Of one Regions IP Block in another > > > You state "Obv, the best approach...". I don't think so. I think the > best > approach is whatever allows you to make most efficient use of your > address space. Usually this will be from a single RIR rather than a > multiple RIR approach. > > Owen The one drawback to that would be people who attempt to do geographical based service provisioning. Say a company based in the US uses part of their block in Europe or APAC. When they do a DNS request for a service address from $GLOBAL_CONTENT_PROVIDER, they end up getting the US service address because the content provider believes the request is coming from the US resulting in poor performance. In other words, if a service relies on connection to other services that try to do geographical affinity, it could lead to a sub-optimal experience. It could also cause problems where the content is different (or possibly prohibited) depending on the geographical location of the requestor which some folks try to determine by source address (but which is actually quite idiotic, in my opinion, because as you see from this thread, an IP address in no way relates to where the person really is, it only relates to where the entity to whom it was issued is located). Been there and experienced issues like that before. It can even be bad when you are given an IP block that might have been used before by someone in another region. George From owen at delong.com Thu May 20 11:36:02 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 20 May 2010 09:36:02 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> References: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> Message-ID: <852E4F34-3BAF-4D86-84FD-CB1CC547F5C9@delong.com> On May 20, 2010, at 9:14 AM, George Bonser wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Thursday, May 20, 2010 7:37 AM >> To: Net >> Cc: nanog at nanog.org >> Subject: Re: Partial Use Of one Regions IP Block in another >> >> >> You state "Obv, the best approach...". I don't think so. I think the >> best >> approach is whatever allows you to make most efficient use of your >> address space. Usually this will be from a single RIR rather than a >> multiple RIR approach. >> >> Owen > > The one drawback to that would be people who attempt to do geographical > based service provisioning. Say a company based in the US uses part of > their block in Europe or APAC. When they do a DNS request for a service > address from $GLOBAL_CONTENT_PROVIDER, they end up getting the US > service address because the content provider believes the request is > coming from the US resulting in poor performance. In other words, if a > service relies on connection to other services that try to do > geographical affinity, it could lead to a sub-optimal experience. > I have ZERO sympathy for people who attempt to do this getting wrong answers. There is little correlation between geography and IP addresses. In fact, I know lots of people who consider it a benefit to have ARIN addresses in other parts of the world because it allows them to get to content that isn't allowed to APNIC addresses on the belief that this somehow protects copyright or other issues for content distribution. I find that pretty amusing. > It could also cause problems where the content is different (or possibly > prohibited) depending on the geographical location of the requestor > which some folks try to determine by source address (but which is > actually quite idiotic, in my opinion, because as you see from this > thread, an IP address in no way relates to where the person really is, > it only relates to where the entity to whom it was issued is located). > Again, ZERO sympathy here. Especially where someone is trying to use source IP as a mechansim for determining who they are willing to distribute their content to. > Been there and experienced issues like that before. It can even be bad > when you are given an IP block that might have been used before by > someone in another region. > Can be bad when given an IP block that might have been used before by someone in the same region. That's not particularly different. Can be bad if you get space from one of the more recent /8s that has lots of cruft from having been used as pseudo-RFC-1918 space, too. We're scraping the bottom of the barrel for IPv4 space these days. It is what it is, and it's only going to get worse in IPv4. Time to go to IPv6. Owen From joelja at bogus.com Thu May 20 12:05:04 2010 From: joelja at bogus.com (joel jaeggli) Date: Thu, 20 May 2010 10:05:04 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <852E4F34-3BAF-4D86-84FD-CB1CC547F5C9@delong.com> References: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> <852E4F34-3BAF-4D86-84FD-CB1CC547F5C9@delong.com> Message-ID: <4BF56BC0.7060603@bogus.com> On 2010-05-20 09:36, Owen DeLong wrote: > We're scraping the bottom of the barrel for IPv4 space these days. > It is what it is, and it's only going to get worse in IPv4. Time to go > to IPv6. in ipv6 we're using our arin /32 in all regions where we appear... joel > Owen > > From gbonser at seven.com Thu May 20 12:19:39 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 20 May 2010 10:19:39 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <4BF56BC0.7060603@bogus.com> References: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> <852E4F34-3BAF-4D86-84FD-CB1CC547F5C9@delong.com> <4BF56BC0.7060603@bogus.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA45A3@RWC-EX1.corp.seven.com> > -----Original Message----- > From: joel jaeggli [mailto:joelja at bogus.com] > Sent: Thursday, May 20, 2010 10:05 AM > To: Owen DeLong > Cc: George Bonser; nanog at nanog.org > Subject: Re: Partial Use Of one Regions IP Block in another > > On 2010-05-20 09:36, Owen DeLong wrote: > > We're scraping the bottom of the barrel for IPv4 space these days. > > It is what it is, and it's only going to get worse in IPv4. Time to > go > > to IPv6. > > in ipv6 we're using our arin /32 in all regions where we appear... > > joel Exactly. So migrating to v6 has no bearing on the conversation. The same "problem" (a problem which some people create themselves by relying on the source IP to determine geographic location) exists with either protocol. There is just no way to tell where the device initiating the conversation is located by looking at the IP and the extent to which you can tell by where the traffic enters your network depends on the temperature of the potato as perceived by the network downstream from you. Did they haul it across an ocean before handing it to you? Geographical location by IP address is just plain nuts, but people will find a way to sell anything, I suppose. George From Valdis.Kletnieks at vt.edu Thu May 20 12:39:05 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 20 May 2010 13:39:05 -0400 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: Your message of "Thu, 20 May 2010 09:19:44 PDT." References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> <4902.1274370793@localhost> Message-ID: <8890.1274377145@localhost> On Thu, 20 May 2010 09:19:44 PDT, itservices88 said: > Is there any specific dnssec mailing list, which might be more helpful. https://lists.dns-oarc.net/mailman/listinfo/dns-operations (Unless I've fat-fingered it and it's elsewhere?) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jabley at hopcount.ca Thu May 20 12:54:06 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 20 May 2010 13:54:06 -0400 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> <4902.1274370793@localhost> Message-ID: <97D6FD46-2B12-4C8F-BF9F-654881219053@hopcount.ca> On 2010-05-20, at 12:18, itservices88 wrote: > I have these in named.conf > > dnssec-enable yes; > dnssec-validation yes; > // dnssec-lookaside "." trust-anchor "DLV.ISC.ORG"; > With the trust-anchor uncommented, as soon as i enable and reload bind, dig > gives timeout, while dig has no issues with first two commands enabled. You should probably take these questions to the bind-users list, where there are many people who will help you. See . Configuring DLV is quite possibly not what you want in this instance. Joe From sghuter at nsrc.org Thu May 20 12:55:48 2010 From: sghuter at nsrc.org (Steven G. Huter) Date: Thu, 20 May 2010 17:55:48 +0000 (GMT) Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <8890.1274377145@localhost> References: <8F204F18-9CA8-4B9C-B8C0-FCF0D73D2B20@icann.org> <4902.1274370793@localhost> <8890.1274377145@localhost> Message-ID: <20100520175346.U65833@psg.com> >> Is there any specific dnssec mailing list, which might be more helpful. DNSSEC Deployment http://www.dnssec-deployment.org/ steve From rganascim at gmail.com Thu May 20 13:25:04 2010 From: rganascim at gmail.com (Rafael Ganascim) Date: Thu, 20 May 2010 15:25:04 -0300 Subject: BGP Transit AS Message-ID: Hi all, I have a doubt about the bellow scenario, where the ISP1 use eBGP sessions to its peers and is a BGP Transit AS. ?NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 ? |???????????????????????????? | ? |???????????????????????????? | ? |???????????????????????????? | ? | annunce /21????????? | ? |???????????????????????????? | ?Customer1 --------------- ISP 1 Router1 ????????? announce /20 The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the Custormer1->ISP1 link. To solve this question, an solution that I found is filter Customer1 prefixes in BGP session between NSP1 and ISP1 Router2. But this don't appear scalable... Is this solution right ? What is the better solution for this scenario? How large ISPs solve this kind of problem? Thanks, Rafael From mksmith at adhost.com Thu May 20 14:49:54 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 20 May 2010 12:49:54 -0700 Subject: BGP Transit AS In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D520316080E119B@ad-exh01.adhost.lan> > -----Original Message----- > From: Rafael Ganascim [mailto:rganascim at gmail.com] > Sent: Thursday, May 20, 2010 11:25 AM > To: nanog at nanog.org > Subject: BGP Transit AS > > Hi all, > > I have a doubt about the bellow scenario, where the ISP1 use eBGP > sessions to its peers and is a BGP Transit AS. > > > ?NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 > ? |???????????????????????????? | > ? |???????????????????????????? | > ? |???????????????????????????? | > ? | annunce /21????????? | > ? |???????????????????????????? | > ?Customer1 --------------- ISP 1 Router1 > ????????? announce /20 > > > The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 > IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce > a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to > Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the > Custormer1->ISP1 link. > To solve this question, an solution that I found is filter Customer1 > prefixes in BGP session between NSP1 and ISP1 Router2. But this don't > appear scalable... > > Is this solution right ? What is the better solution for this > scenario? How large ISPs solve this kind of problem? > The more specific /21's are winning over the /20, so they will always be preferred by default. If you want to change that, you could announce the /20 to NSP1, or announce the /21's to ISP1. Mike From up at 3.am Thu May 20 14:55:08 2010 From: up at 3.am (James Smallacombe) Date: Thu, 20 May 2010 15:55:08 -0400 (EDT) Subject: SAS-70 Type II Colocation Message-ID: Looking for recommendations for SAS-70 type II certified colo providers in or around the Philly area. If you represent such a provider, please contact me OFF LIST. Thank you! PS: I checked the AUP for this list and I *think* this type of post is ok, but if it's not, I welcome correction. James Smallacombe PlantageNet, Inc. CEO and Janitor up at 3.am http://3.am ========================================================================= From joelja at bogus.com Thu May 20 15:33:58 2010 From: joelja at bogus.com (joel jaeggli) Date: Thu, 20 May 2010 13:33:58 -0700 Subject: BGP Transit AS In-Reply-To: References: Message-ID: <4BF59CB6.2000304@bogus.com> On 2010-05-20 11:25, Rafael Ganascim wrote: > Hi all, > > I have a doubt about the bellow scenario, where the ISP1 use eBGP > sessions to its peers and is a BGP Transit AS. > > > NSP 1 ------------------ ISP 1 Router2 ----------- NSP 2 > | | > | | > | | > | annunce /21 | > | | > Customer1 --------------- ISP 1 Router1 > announce /20 > > > The "Customer1" is client on both ISPs (ISP1 and NSP1) and have an /20 > IP prefix. To NSP1, it announce two /21 prefixes. To ISP1, it announce > a /20 prefix. If traffic comes from NSP 2 (connected only to ISP 1) to > Customer1, the ISP 1 Routers try to send data over NSP 1, ignoring the > Custormer1->ISP1 link. > To solve this question, an solution that I found is filter Customer1 > prefixes in BGP session between NSP1 and ISP1 Router2. But this don't > appear scalable... longest match wins... if you're customer 1 deaggregate the avertisement to isp 1 or re-aggregate the advertisement to nsp 1. either will achieve the same end. if you're isp1 consider what customer 1 was trying to achieve by doing this. e.g. they're traffic engineering (or they are clueless) and theirfore have a vested interest in the current path. > Is this solution right ? What is the better solution for this > scenario? How large ISPs solve this kind of problem? > > > Thanks, > > Rafael > From if at xip.at Thu May 20 15:51:00 2010 From: if at xip.at (Ingo Flaschberger) Date: Thu, 20 May 2010 22:51:00 +0200 (CEST) Subject: BGP Transit AS In-Reply-To: References: Message-ID: Dear Rafael, > Is this solution right ? What is the better solution for this > scenario? How large ISPs solve this kind of problem? communitie(filters) help to scale. for example lambdanet communities: remarks: Prepend communities to modify announcements to peers remarks: remarks: 13237:3811n announcements to AS12322 (Free) remarks: 13237:3812n announcements to AS3356 (Level3) remarks: 13237:3813n announcements to AS8220 (COLT) remarks: 13237:3814n announcements to AS286 (KPN Eurorings) remarks: 13237:3815n announcements to AS3303 (Swisscom) remarks: 13237:3818n announcements to AS9121 (TurkTelekom) remarks: 13237:3824n announcements to AS2914 (Verio) remarks: 13237:3825n announcements to AS4766 (Korea Telecom) remarks: 13237:3826n announcements to AS3491 (BtN) remarks: 13237:3828n announcements to AS8928 (Interoute) remarks: 13237:3830n announcements to AS1257 (Swipnet) remarks: 13237:3831n announcements to AS3292 (TeleDanmark) remarks: 13237:3832n announcements to AS3209 (Arcor) remarks: 13237:3833n announcements to AS3320 (DTAG) remarks: 13237:3835n announcements to AS6805 (Telefonica DE) remarks: 13237:3836n announcements to AS8447 (Telekom AT) remarks: 13237:3837n announcements to AS8881 (Versatel DE) remarks: 13237:3838n announcements to AS13184 (Hansenet) remarks: 13237:3855n announcements to AS6830 (Chello) remarks: 13237:3860n announcements to AS3257 (Tiscali Int.) remarks: 13237:3865n announcements to AS702 (MCI EU) remarks: 13237:3866n announcements to AS3549 (Global Crossing) remarks: 13237:3869n announcements to AS6453 (Tata/Teleglobe) remarks: 13237:3870n announcements to AS20676 (QSC) remarks: 13237:3876n announcements to AS2856 (BT UK) remarks: 13237:3877n announcements to AS2119 (Telenor) remarks: 13237:3891n announcements to AS1299 (TeliaSonera) remarks: 13237:3892n announcements to AS6461 (Abovenet) remarks: remarks: with n = 0,1,2,3 meaning remarks: n = 0 do not announce to peer remarks: n = 1 prepend "AS13237" remarks: n = 2 prepend "AS13237 AS13237" remarks: n = 3 prepend "AS13237 AS13237 AS13237" Kind regards, Ingo Flaschberger From funkyfun at gmail.com Thu May 20 16:51:18 2010 From: funkyfun at gmail.com (Net) Date: Thu, 20 May 2010 17:51:18 -0400 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA45A3@RWC-EX1.corp.seven.com> References: <2B1ED888-3CF6-4FFF-A1E9-5C6BD76A5163@delong.com> <5A6D953473350C4B9995546AFE9939EE09EA458D@RWC-EX1.corp.seven.com> <852E4F34-3BAF-4D86-84FD-CB1CC547F5C9@delong.com> <4BF56BC0.7060603@bogus.com> <5A6D953473350C4B9995546AFE9939EE09EA45A3@RWC-EX1.corp.seven.com> Message-ID: Thanks to all who replied and provided valuable input. Much appreciated Regards, On 5/20/10, George Bonser wrote: > > >> -----Original Message----- >> From: joel jaeggli [mailto:joelja at bogus.com] >> Sent: Thursday, May 20, 2010 10:05 AM >> To: Owen DeLong >> Cc: George Bonser; nanog at nanog.org >> Subject: Re: Partial Use Of one Regions IP Block in another >> >> On 2010-05-20 09:36, Owen DeLong wrote: >> > We're scraping the bottom of the barrel for IPv4 space these days. >> > It is what it is, and it's only going to get worse in IPv4. Time to >> go >> > to IPv6. >> >> in ipv6 we're using our arin /32 in all regions where we appear... >> >> joel > > Exactly. So migrating to v6 has no bearing on the conversation. The > same "problem" (a problem which some people create themselves by relying > on the source IP to determine geographic location) exists with either > protocol. There is just no way to tell where the device initiating the > conversation is located by looking at the IP and the extent to which you > can tell by where the traffic enters your network depends on the > temperature of the potato as perceived by the network downstream from > you. Did they haul it across an ocean before handing it to you? > > Geographical location by IP address is just plain nuts, but people will > find a way to sell anything, I suppose. > > George > > > -- Sent from my mobile device From carolw at merit.edu Thu May 20 16:17:09 2010 From: carolw at merit.edu (Carol Wadsworth) Date: Thu, 20 May 2010 17:17:09 -0400 Subject: [NANOG-announce] Book Now - Hotel Rate for NANOG 49 Expires Soon! Message-ID: <109252804394AF2F8B84A030@tulip.merit.edu> If you are attending NANOG 49, June 13-16, in San Francisco and need overnight lodging, the group room rate at The Westin St. Francis expires this coming Monday, May 24, so please make your reservation soon. NANOG 49 is being hosted by Netflix. For all meeting related details, please see: http://www.nanog.org/meetings/nanog49/index.php See you there! _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From matthias.flittner at de-cix.net Thu May 20 17:15:18 2010 From: matthias.flittner at de-cix.net (Matthias Flittner) Date: Fri, 21 May 2010 00:15:18 +0200 Subject: Off-Topic: use laptop only as USB power supply Message-ID: <4BF5B476.2020102@de-cix.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I'm not sure if anyone out there has an answer to this insane question: But is it possible to use my laptop only has power supply via usb for my mobile phone. Yes you heard right: I don't want to boot an operating system I only want to charge my battery of my mobile phone. No fan should be powered on. I only need voltage on the USB ports. Any suggestions? ;) best regards, FliTTi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL9bR2AAoJEIZn8Rym6s4A1TgH+gNSd8TRW34dvzgS03uTHKvi iZ3f+nciMeaJSN7Pq9Eugi3pgGvljKArcCiEmlV95BIP1i6hJiDuO7sOp/xx4yeO n8/iW6FyPBv5pqjuyhuTjs4GuG7ar4lM6/y4sYPT++bf5fWfwxjonYnmZakw2IVa 3fdsHeOIoyD45lirthSXXmynl/UO4ajYEwI+dqs2vpYcUYTgBW4WhQ1zMnVKJasn PtpuMx1M3a3xF3rFZ6PZ2KmtVRQhjpgaU1TYZO2jcABoKS9e7s2j5zFR+0nhIqzK hq2mQWGlA49Lgt+P21jsaJ8YZxD4AvZFnDXg3flR/FFTVIfVcWoQELvnWwv9iqs= =k+ae -----END PGP SIGNATURE----- From gabriel at dreamingcrow.com Thu May 20 17:22:02 2010 From: gabriel at dreamingcrow.com (Gabriel Cain) Date: Thu, 20 May 2010 15:22:02 -0700 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF5B476.2020102@de-cix.net> References: <4BF5B476.2020102@de-cix.net> Message-ID: <4BF5B60A.9070901@dreamingcrow.com> Get a minty boost from LadyAda and use batteries. Much lighter than carrying a laptop as a big battery around. :) http://www.ladyada.net/make/mintyboost/ -Gabriel Matthias Flittner wrote: > Hi there, > I'm not sure if anyone out there has an answer to this insane question: > But is it possible to use my laptop only has power supply via usb for my > mobile phone. Yes you heard right: I don't want to boot an operating > system I only want to charge my battery of my mobile phone. No fan should > be powered on. I only need voltage on the USB ports. > > Any suggestions? ;) From tmagill at providecommerce.com Thu May 20 18:05:58 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Thu, 20 May 2010 16:05:58 -0700 Subject: Useful TCL script? Message-ID: I had to come up with a way to monitor average packet size on an interface so I wrote the following script (cisco devices). I don't know if anyone finds it useful, but here it is if so. Also, there is one issue with it where if the total number of packets an interface has seen is over 7 digits, it will not calculate it. This appears to be a limitation of the expr command used in cisco TCL and mpexpr is not supported. If anyone else knows a way to bypass this issue I would be glad to hear it. For now it just tells you that the value is too high. I am also considering creating a job that can input the value into an OID that we can poll but not exactly sure how to do that so if anyone has any experience or good references (other than the cisco stuff I find on google) I would be thankful. I save this to flash: or disk: (depending on default tcl location per device) and assign the alias: alias exec psize tclsh psize.tcl Then use it like: Router#psize psize tun1 Packet Size Information for Tunnel1 ---------------------------------------------------- 5 minute input bits/sec = 43000 5 minute input packets/sec = 30 5 minute average packet size = 179 Bytes ---------------------------------------------------- 5 minute output bits/sec = 3000 5 minute output packets/sec = 3 5 minute average packet size = 125 Bytes ---------------------------------------------------- Total input bytes = 1678803 Total input packets = 7761 Total average packet size = 216 Bytes ---------------------------------------------------- Total output bytes = 133316 Total output packets = 1041 Total average packet size = 128 Bytes ---------------------------------------------------- This is my first attempt at a script this complex so if you have any input/suggestions they are welcome. ######################################################################## ##### # # # psize.tcl # # By Thomas Magill - 5/7/2010 # # # ######################################################################## ##### # # Get input from command line set ifname $argv # Check interface name for errors if {[string equal $ifname ""]} { puts "Usage: psize ifname"; return; } if { [ catch { exec "show ip interface $ifname" } errmsg ] } { puts "Invalid interface $ifname, command failed"; return} set cmdtext [ exec "show interface $ifname" ] # Pull interface information and calculate foreach line [split $cmdtext "\n"] { if {[regexp -nocase {^(\S+) is (.*), line protocol is (\S+)} $line ignore ifnamefull ifstatus iflinkstatus]} { } if {[regexp -nocase {5 minute input rate ([0-9]+) bits/sec, ([0-9]+) packets/sec} $line ignore bpsinfive ppsinfive]} { if {$ppsinfive == "0"} {set psizeinfive "0"} else {set psizeinfive [expr $bpsinfive / $ppsinfive]} set psizeinfive [expr $psizeinfive / 8] } if {[regexp -nocase {5 minute output rate ([0-9]+) bits/sec, ([0-9]+) packets/sec} $line ignore bpsoutfive ppsoutfive]} { if {$ppsoutfive == "0"} {set psizeoutfive "0"} else {set psizeoutfive [expr $bpsoutfive / $ppsoutfive]} set psizeoutfive [expr $psizeoutfive / 8] } if {[regexp -nocase {([0-9]+) packets input, ([0-9]+) bytes} $line ignore ppsintotal bpsintotal]} { if {$ppsintotal > "9999999"} {set psizeintotal "Too Large to Find"} elseif {$ppsintotal == "0"} {set psizeintotal "0"} else {set psizeintotal [expr $bpsintotal / $ppsintotal]} } if {[regexp -nocase {([0-9]+) packets output, ([0-9]+) bytes} $line ignore ppsouttotal bpsouttotal]} { if {$ppsouttotal > "9999999"} {set psizeouttotal "Too Large to Find"} elseif {$ppsouttotal == "0"} {set psizeouttotal "0"} else {set psizeouttotal [expr $bpsouttotal / $ppsouttotal]} } } # Output Data puts "\n\nPacket Size Information for $ifnamefull" puts "---------------------------------------------------------" puts " 5 minute input bits/sec = $bpsinfive " puts " 5 minute input packets/sec = $ppsinfive " puts " 5 minute average packet size = $psizeinfive Bytes " puts "---------------------------------------------------------" puts " 5 minute output bits/sec = $bpsoutfive " puts " 5 minute output packets/sec = $ppsoutfive " puts " 5 minute average packet size = $psizeoutfive Bytes " puts "---------------------------------------------------------" puts " Total input bytes = $bpsintotal " puts " Total input packets = $ppsintotal " puts " Total average packet size = $psizeintotal Bytes " puts "---------------------------------------------------------" puts " Total output bytes = $bpsouttotal " puts " Total output packets = $ppsouttotal " puts " Total average packet size = $psizeouttotal Bytes " puts "---------------------------------------------------------" Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From jeroen at mompl.net Thu May 20 18:08:02 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 20 May 2010 16:08:02 -0700 Subject: [OT]Bounce Back In-Reply-To: References: Message-ID: <4BF5C0D2.10406@mompl.net> James Bensley wrote: > Got the below message back from Hotmail when emailing a friend I email > every week. I have never experienced this particular error before, is > this just an indication of high traffic between Google Mail and > Hotmail? Yes, high traffic of an abusive nature, i.e. google's email servers spew out a lot of spam. Just because they're a big company doesn't mean they should get special treatment when they're sending spam. Google should try it bit harder to fight their abuse problem. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From dotis at mail-abuse.org Thu May 20 19:43:50 2010 From: dotis at mail-abuse.org (Douglas Otis) Date: Thu, 20 May 2010 17:43:50 -0700 Subject: [OT]Bounce Back In-Reply-To: <4BF5C0D2.10406@mompl.net> References: <4BF5C0D2.10406@mompl.net> Message-ID: <4BF5D746.2090604@mail-abuse.org> On 5/20/10 4:08 PM, Jeroen van Aart wrote: > James Bensley wrote: >> Got the below message back from Hotmail when emailing a friend I email >> every week. I have never experienced this particular error before, is >> this just an indication of high traffic between Google Mail and >> Hotmail? > > Yes, high traffic of an abusive nature, i.e. google's email servers > spew out a lot of spam. Just because they're a big company doesn't > mean they should get special treatment when they're sending spam. > Google should try it bit harder to fight their abuse problem. It seems the year began with major provider's user accounts being hacked. More than just speed is needed to defend these services. Other services that send password reset links via email may also want to rethink this strategy, in light of the situation. Clearly, the accounts are not being disabled. -Doug From paul at telcodata.us Thu May 20 19:52:52 2010 From: paul at telcodata.us (Paul Timmins) Date: Thu, 20 May 2010 20:52:52 -0400 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF5B476.2020102@de-cix.net> References: <4BF5B476.2020102@de-cix.net> Message-ID: <4BF5D964.6010700@telcodata.us> I think the last dell business notebook I had my hands on has a bios setting that enables usb power when the laptop is off and plugged into the AC adapter. It's not on by default. If you have one, you may want to check. -Paul Matthias Flittner wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there, > I'm not sure if anyone out there has an answer to this insane question: > But is it possible to use my laptop only has power supply via usb for my > mobile phone. Yes you heard right: I don't want to boot an operating > system I only want to charge my battery of my mobile phone. No fan should > be powered on. I only need voltage on the USB ports. > > Any suggestions? ;) > > best regards, > FliTTi > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJL9bR2AAoJEIZn8Rym6s4A1TgH+gNSd8TRW34dvzgS03uTHKvi > iZ3f+nciMeaJSN7Pq9Eugi3pgGvljKArcCiEmlV95BIP1i6hJiDuO7sOp/xx4yeO > n8/iW6FyPBv5pqjuyhuTjs4GuG7ar4lM6/y4sYPT++bf5fWfwxjonYnmZakw2IVa > 3fdsHeOIoyD45lirthSXXmynl/UO4ajYEwI+dqs2vpYcUYTgBW4WhQ1zMnVKJasn > PtpuMx1M3a3xF3rFZ6PZ2KmtVRQhjpgaU1TYZO2jcABoKS9e7s2j5zFR+0nhIqzK > hq2mQWGlA49Lgt+P21jsaJ8YZxD4AvZFnDXg3flR/FFTVIfVcWoQELvnWwv9iqs= > =k+ae > -----END PGP SIGNATURE----- > > > From adam at adamstas.com Thu May 20 21:39:58 2010 From: adam at adamstas.com (Adam Stasiniewicz) Date: Thu, 20 May 2010 22:39:58 -0400 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF5B476.2020102@de-cix.net> References: <4BF5B476.2020102@de-cix.net> Message-ID: My last Lenovo laptop had a setting in the BIOS for exactly that. Worked great for hotel rooms (which notoriously have very few power plugs) when I wanted to charge my cell phone and other devices over night. No clue about other vendors. Hope that helps, Adam -----Original Message----- From: Matthias Flittner [mailto:matthias.flittner at de-cix.net] Sent: Thursday, May 20, 2010 6:15 PM To: nanog at nanog.org Subject: Off-Topic: use laptop only as USB power supply -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I'm not sure if anyone out there has an answer to this insane question: But is it possible to use my laptop only has power supply via usb for my mobile phone. Yes you heard right: I don't want to boot an operating system I only want to charge my battery of my mobile phone. No fan should be powered on. I only need voltage on the USB ports. Any suggestions? ;) best regards, FliTTi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJL9bR2AAoJEIZn8Rym6s4A1TgH+gNSd8TRW34dvzgS03uTHKvi iZ3f+nciMeaJSN7Pq9Eugi3pgGvljKArcCiEmlV95BIP1i6hJiDuO7sOp/xx4yeO n8/iW6FyPBv5pqjuyhuTjs4GuG7ar4lM6/y4sYPT++bf5fWfwxjonYnmZakw2IVa 3fdsHeOIoyD45lirthSXXmynl/UO4ajYEwI+dqs2vpYcUYTgBW4WhQ1zMnVKJasn PtpuMx1M3a3xF3rFZ6PZ2KmtVRQhjpgaU1TYZO2jcABoKS9e7s2j5zFR+0nhIqzK hq2mQWGlA49Lgt+P21jsaJ8YZxD4AvZFnDXg3flR/FFTVIfVcWoQELvnWwv9iqs= =k+ae -----END PGP SIGNATURE----- From owen at delong.com Thu May 20 22:57:08 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 20 May 2010 20:57:08 -0700 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF5D964.6010700@telcodata.us> References: <4BF5B476.2020102@de-cix.net> <4BF5D964.6010700@telcodata.us> Message-ID: <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> Every Mac laptop I have ever used has powered the USB ports whenever connected to AC or airline power, regardless of whether asleep or awake. Not sure if it will power USB ports when powered, but, shut down or not. Have not tested that. Owen On May 20, 2010, at 5:52 PM, Paul Timmins wrote: > I think the last dell business notebook I had my hands on has a bios setting that enables usb power when the laptop is off and plugged into the AC adapter. > > It's not on by default. > > If you have one, you may want to check. > > -Paul > > Matthias Flittner wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi there, >> I'm not sure if anyone out there has an answer to this insane question: >> But is it possible to use my laptop only has power supply via usb for my >> mobile phone. Yes you heard right: I don't want to boot an operating >> system I only want to charge my battery of my mobile phone. No fan should >> be powered on. I only need voltage on the USB ports. >> >> Any suggestions? ;) >> >> best regards, >> FliTTi >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJL9bR2AAoJEIZn8Rym6s4A1TgH+gNSd8TRW34dvzgS03uTHKvi >> iZ3f+nciMeaJSN7Pq9Eugi3pgGvljKArcCiEmlV95BIP1i6hJiDuO7sOp/xx4yeO >> n8/iW6FyPBv5pqjuyhuTjs4GuG7ar4lM6/y4sYPT++bf5fWfwxjonYnmZakw2IVa >> 3fdsHeOIoyD45lirthSXXmynl/UO4ajYEwI+dqs2vpYcUYTgBW4WhQ1zMnVKJasn >> PtpuMx1M3a3xF3rFZ6PZ2KmtVRQhjpgaU1TYZO2jcABoKS9e7s2j5zFR+0nhIqzK >> hq2mQWGlA49Lgt+P21jsaJ8YZxD4AvZFnDXg3flR/FFTVIfVcWoQELvnWwv9iqs= >> =k+ae >> -----END PGP SIGNATURE----- >> >> >> > From john at internetassociatesllc.com Thu May 20 23:13:04 2010 From: john at internetassociatesllc.com (John Lee) Date: Thu, 20 May 2010 23:13:04 -0500 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: References: Message-ID: <53A6C7E936ED8544B1A2BC990D254F9464F915375D@MEMEXG1.HOST.local> Some pseudo random thoughts and questions? (my BGP is rusty.) 1. Does it violate your AUP with APNIC? 2. If the larger routing prefix is from APNIC will your upstream in the EMEA region filter or black hole the sub prefix since it is from APNIC and not RIPE and would appear to be a hijacked block? (In my experience in some European countries "rules" are more strictly enforced than in other areas of the globe. I will spare you the American, Russian and French standards organization joke.) 3. It would appear that again since it is in an APNIC sub-prefix would you need to "carry" the packets from a PoP in APNIC region to your facility in the EMEA assuming the sub prefix is not large enough to be propagated in normal BPG updates? 4. And if the bits did get through for a period of time would the transit provider determine that they did not want to carry them any more and add filtering at any random point in time? These questions assume that you do not have a single transit provider that covers both of your locations in the two different regions and can "custom route" the packets. John (ISDN) Lee ________________________________________ From: Net [funkyfun at gmail.com] Sent: Thursday, May 20, 2010 8:06 AM To: nanog at nanog.org Subject: Partial Use Of one Regions IP Block in another Hi folks, Are there any policies set by internet registries and/or transit providers today that prohibits organizations from using a Partially used IP Block allocated in one region say AP through APNIC to be comissioned and Propagated in another region such as EMEA serviced by RIPE?. Obv, the best approach would be to acquire a new Block in the 2nd region through its own registry, but sometimes due to strict prvisioning timelines, legal delays in getting the necessary approvals involved etc make this option less attractive. From an IPV4 space depletion perspective as well, it might be feasible if organizations having a large block in one region could split it amongst multiple regions to prevent Wastage. Any thoughts/expereinces and feedback would be appreciated. Regards, -- Sent from my mobile device From owen at delong.com Thu May 20 23:21:51 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 20 May 2010 21:21:51 -0700 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: <53A6C7E936ED8544B1A2BC990D254F9464F915375D@MEMEXG1.HOST.local> References: <53A6C7E936ED8544B1A2BC990D254F9464F915375D@MEMEXG1.HOST.local> Message-ID: On May 20, 2010, at 9:13 PM, John Lee wrote: > Some pseudo random thoughts and questions? (my BGP is rusty.) > > 1. Does it violate your AUP with APNIC? > Not if he has infrastructure in the remote location and infrastructure and/or HQ in APNIC region. > 2. If the larger routing prefix is from APNIC will your upstream in the EMEA region filter or black hole the sub prefix since it is from APNIC and not RIPE and would appear to be a hijacked block? (In my experience in some European countries "rules" are more strictly enforced than in other areas of the globe. I will spare you the American, Russian and French standards organization joke.) > LoL... In my experience, the guys that are getting money from you will route what you want routed unless they have reason to believe you are not legitimately entitled to route it. > 3. It would appear that again since it is in an APNIC sub-prefix would you need to "carry" the packets from a PoP in APNIC region to your facility in the EMEA assuming the sub prefix is not large enough to be propagated in normal BPG updates? > If that is true, yes. i was assuming that he was using a sub-prefix length <=/24 for EMEA region. If he's trying to run a /25 or longer, then, life will indeed suck, but, not because of the RIR issues, because of the long-prefix problem. > 4. And if the bits did get through for a period of time would the transit provider determine that they did not want to carry them any more and add filtering at any random point in time? > Unlikely if it's a legitimate route. It wouldn't appear any less legitimate than any other route and there are many inter-regional routes advertised just like this already that work just fine. > These questions assume that you do not have a single transit provider that covers both of your locations in the two different regions and can "custom route" the packets. > LoL Owen > John (ISDN) Lee > ________________________________________ > From: Net [funkyfun at gmail.com] > Sent: Thursday, May 20, 2010 8:06 AM > To: nanog at nanog.org > Subject: Partial Use Of one Regions IP Block in another > > Hi folks, > > Are there any policies set by internet registries and/or transit > providers today that prohibits organizations from using a Partially > used IP Block allocated in one region say AP through APNIC to be > comissioned and Propagated in another region such as EMEA serviced by > RIPE?. > > Obv, the best approach would be to acquire a new Block in the 2nd > region through its own registry, but sometimes due to strict > prvisioning timelines, legal delays in getting the necessary approvals > involved etc make this option less attractive. From an IPV4 space > depletion perspective as well, it might be feasible if organizations > having a large block in one region could split it amongst multiple > regions to prevent Wastage. > > Any thoughts/expereinces and feedback would be appreciated. > > Regards, > > -- > Sent from my mobile device From r.engehausen at gmail.com Thu May 20 23:51:05 2010 From: r.engehausen at gmail.com (Roy) Date: Thu, 20 May 2010 21:51:05 -0700 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> References: <4BF5B476.2020102@de-cix.net> <4BF5D964.6010700@telcodata.us> <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> Message-ID: <4BF61139.6040707@gmail.com> Why carry a laptop? Here are some examples http://www.walmart.com/ip/Belkin-Mini-Notebook-Surge-Portector-with-Built-In-USB-Charger/10248165?sourceid=1500000000000003142050&ci_src=14110944&ci_sku=10248165 http://www.cyberguys.com/product-details/?productid=39338 http://www.cyberguys.com/product-details/?productid=29278 From jlewis at lewis.org Fri May 21 00:07:32 2010 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 21 May 2010 01:07:32 -0400 (EDT) Subject: Partial Use Of one Regions IP Block in another In-Reply-To: References: <53A6C7E936ED8544B1A2BC990D254F9464F915375D@MEMEXG1.HOST.local> Message-ID: On Thu, 20 May 2010, Owen DeLong wrote: > LoL... In my experience, the guys that are getting money from you will > route what you want routed unless they have reason to believe you are > not legitimately entitled to route it. Like spammers buying IPs from RIPE region LIRs such as jump.ro, and then announcing those IPs only in the North American data centers where they're buying server hosting? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From scott at doc.net.au Fri May 21 01:11:58 2010 From: scott at doc.net.au (Scott Howard) Date: Thu, 20 May 2010 23:11:58 -0700 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF61139.6040707@gmail.com> References: <4BF5B476.2020102@de-cix.net> <4BF5D964.6010700@telcodata.us> <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> <4BF61139.6040707@gmail.com> Message-ID: On Thu, May 20, 2010 at 9:51 PM, Roy wrote: > Why carry a laptop? Here are some examples > > > http://www.walmart.com/ip/Belkin-Mini-Notebook-Surge-Portector-with-Built-In-USB-Charger/10248165?sourceid=1500000000000003142050&ci_src=14110944&ci_sku=10248165 > If you're looking at one of these, just be aware that they are 110 volts only. Scott. From graham.freeman at cernio.com Fri May 21 02:14:13 2010 From: graham.freeman at cernio.com (Graham Freeman) Date: Fri, 21 May 2010 00:14:13 -0700 Subject: Extended outage at Vitelity / XO? Message-ID: Hi, folks, All 30 of the DIDs I have at one of VOIP providers, Vitelity.net, have been offline for more than 8 hours as of this writing. Vitelity quickly acknowledged the problem, and are characterizing this as a "global DID outage" at XO Communications, affecting "over 100,000 of [Vitelity's] DIDs alone and many others throughout [XO's] network." Now, I know major outages do happen, and service with Vitelity has been generally good, but 8 hours and counting is pretty awful. I'm worried that this may in fact be the result of a contract dispute of some kind between Vitelity and XO, and, if so, that this may be an even bigger problem for me than it already is. Can anyone else confirm Vitelity's report of widespread outages with XO? thanks, Graham From cathya at isc.org Fri May 21 06:21:20 2010 From: cathya at isc.org (Cathy Almond) Date: Fri, 21 May 2010 12:21:20 +0100 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF61139.6040707@gmail.com> References: <4BF5B476.2020102@de-cix.net> <4BF5D964.6010700@telcodata.us> <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> <4BF61139.6040707@gmail.com> Message-ID: <4BF66CB0.70804@isc.org> Roy wrote: > Why carry a laptop? Here are some examples > > http://www.walmart.com/ip/Belkin-Mini-Notebook-Surge-Portector-with-Built-In-USB-Charger/10248165?sourceid=1500000000000003142050&ci_src=14110944&ci_sku=10248165 > > > http://www.cyberguys.com/product-details/?productid=39338 > > http://www.cyberguys.com/product-details/?productid=29278 > > Toshiba netbooks also have a (bios-enabled) USB charging port (and a netbook's something you might be lugging around anyway?) From rens at autempspourmoi.be Fri May 21 07:02:19 2010 From: rens at autempspourmoi.be (Rens) Date: Fri, 21 May 2010 14:02:19 +0200 Subject: IPv4 Multicast In-Reply-To: References: <2A9FF0C0C50540AA99133567E81FCD76@EU.corp.clearwire.com> Message-ID: <3DCC59EFC88647CA8549D13D158768BA@EU.corp.clearwire.com> I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens -----Original Message----- From: Mikael Abrahamsson [mailto:swmike at swm.pp.se] Sent: mardi 11 mai 2010 15:43 To: Rens Cc: nanog at nanog.org Subject: Re: IPv4 Multicast On Tue, 11 May 2010, Rens wrote: > Does anyone have any configuration examples for this or tutorials, > everything on the net seems way to complex for my needs. Multicast Quick-Start Configuration Guide -- Mikael Abrahamsson email: swmike at swm.pp.se From lorell at hathcock.org Fri May 21 07:16:03 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Fri, 21 May 2010 07:16:03 -0500 Subject: Mikrotik BGP Question Message-ID: <02b001caf8df$62324ea0$2696ebe0$@org> I am inheriting a WISP network with Mikrotik equipment throughout. One of my first duties is to make the network multihomed. We have our first internet connection at one location and our second internet connection will be delivered at a second location in a week or so. I understand all of the steps I need to go through with ARIN in terms of getting an ASN and so forth. My question is about BGP on the Mikrotik platform. The guy who I am supplanting swears that we are supposed to be bringing the second internet link to the same place as the first internet link for BGP to work properly. Obviously that is not true with major brand routers which would do the BGP job just fine. (And he's the same guy that has bridged this whole network, so it is easy to disbelieve his opinion.) But maybe he knows that Mikrotik can't perform BGP in the same way that other routers can. So here's the question. Is there something about running BGP on a Mikrotik platform that precludes having the internet connections come in at different locations? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 832-782-4656 (c) 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer From nick at foobar.org Fri May 21 07:23:18 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 21 May 2010 13:23:18 +0100 Subject: Mikrotik BGP Question In-Reply-To: <02b001caf8df$62324ea0$2696ebe0$@org> References: <02b001caf8df$62324ea0$2696ebe0$@org> Message-ID: <4BF67B36.3060507@foobar.org> On 21/05/2010 13:16, Lorell Hathcock wrote: > job just fine. (And he's the same guy that has bridged this whole network, > so it is easy to disbelieve his opinion.) ew. nasty. > So here's the question. Is there something about running BGP on a Mikrotik > platform that precludes having the internet connections come in at different > locations? I will refrain from making any smart-ass comments about Mikrotik and BGP, but no: there is no reason whatever that you can't take your internet feeds from different locations, so long as you have a good quality interior network link between those two locations, and your two routers talk iBGP to each other. Just make sure your boxes have enough RAM to cope with a full dfz feed. I.e. it's just the same as using any other router in this regard. Nick From ff30751 at verizon.net Fri May 21 07:35:52 2010 From: ff30751 at verizon.net (Edward A. Trdina III) Date: Fri, 21 May 2010 08:35:52 -0400 Subject: Extended outage at Vitelity / XO? In-Reply-To: References: Message-ID: <26E893AA3283453A99A38CA80A0A154F@ed165b19b94ca2> Graham- It is not just a problem with Vitelity. It is happening to all voip providers that use XO dids. Others are reporting the problem to be fixed now. Ed -----Original Message----- From: Graham Freeman [mailto:graham.freeman at cernio.com] Sent: Friday, May 21, 2010 3:14 AM To: NANOG list Subject: Extended outage at Vitelity / XO? Hi, folks, All 30 of the DIDs I have at one of VOIP providers, Vitelity.net, have been offline for more than 8 hours as of this writing. Vitelity quickly acknowledged the problem, and are characterizing this as a "global DID outage" at XO Communications, affecting "over 100,000 of [Vitelity's] DIDs alone and many others throughout [XO's] network." Now, I know major outages do happen, and service with Vitelity has been generally good, but 8 hours and counting is pretty awful. I'm worried that this may in fact be the result of a contract dispute of some kind between Vitelity and XO, and, if so, that this may be an even bigger problem for me than it already is. Can anyone else confirm Vitelity's report of widespread outages with XO? thanks, Graham From bclark at spectraaccess.com Fri May 21 07:39:39 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 21 May 2010 08:39:39 -0400 Subject: Mikrotik BGP Question In-Reply-To: <4BF67B36.3060507@foobar.org> References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> Message-ID: <4BF67F0B.6090207@spectraaccess.com> On 05/21/2010 08:23 AM, Nick Hilliard wrote: > I will refrain from making any smart-ass comments about Mikrotik and BGP, > but no: there is no reason whatever that you can't take your internet feeds > from different locations, so long as you have a good quality interior > network link between those two locations, and your two routers talk iBGP to > each other. Just make sure your boxes have enough RAM to cope with a full > dfz feed. > > I.e. it's just the same as using any other router in this regard. > > Nick > > I've used Mikrotiks for everything except BGP, but we don't use Mikrotiks for BGP only because we already had BGP on a different platform...personally, when it comes to BGP, I think people are better off running it on devices they are familiar with rather then trying to learn the idiosyncrasies of a new platform. Bret From james at cpctechnology.com Fri May 21 08:35:37 2010 From: james at cpctechnology.com (James J. Lumby II) Date: Fri, 21 May 2010 08:35:37 -0500 Subject: Extended outage at Vitelity / XO? Message-ID: <0D289D9E7FF02D4FA2DF37C3C870976A849F54DE50@CPC01.cpctechnology.local> Our carrier, icall, had the same problem, so it wasn't just vitality. It got fixed this morning: 2010-05-21 8:32AM EST - XO Communications and Acme Packet, the vendor of the failed equipment, have made repairs and resolved the issue. We do not expect any further issues at this time. A formal RFO will be provided once we have received one. 2010-05-20 9:53PM EST - XO technicans have been unable to remedy the issue in the projected timeline. We are awaiting further updates. 2010-05-20 8:48PM EST - XO technicans are on-site and have provided an estimated resolution time of 30 minutes. 2010-05-20 7:15PM EST - XO Communications, one of our primary inbound DID providers, is currently experiencing a major equipment outage. This outage is affecting many of our US inbound DIDs. So, no, it doesn't look like an billing dispute imo. Thank you, James Lumby CPC Technologies, LLC. http://www.cpctechnology.com 817-435-0010 x 5040 Subject: Extended outage at Vitelity / XO? To: NANOG list Message-ID: Content-Type: text/plain; charset=us-ascii Hi, folks, All 30 of the DIDs I have at one of VOIP providers, Vitelity.net, have been offline for more than 8 hours as of this writing. Vitelity quickly acknowledged the problem, and are characterizing this as a "global DID outage" at XO Communications, affecting "over 100,000 of [Vitelity's] DIDs alone and many others throughout [XO's] network." Now, I know major outages do happen, and service with Vitelity has been generally good, but 8 hours and counting is pretty awful. I'm worried that this may in fact be the result of a contract dispute of some kind between Vitelity and XO, and, if so, that this may be an even bigger problem for me than it already is. Can anyone else confirm Vitelity's report of widespread outages with XO? thanks, Graham From michael.holstein at csuohio.edu Fri May 21 08:48:47 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Fri, 21 May 2010 09:48:47 -0400 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF5B476.2020102@de-cix.net> References: <4BF5B476.2020102@de-cix.net> Message-ID: <4BF68F3F.70306@csuohio.edu> > > I only need voltage on the USB ports. Voltage won't be a problem .. current will be. By default, USB supplies 100ma of power. To switch into "high-power" mode (500ma) requires the device and the host agree on doing so. If you're at all handy with a soldering iron, this is a fun project to do what you need : http://www.ladyada.net/make/mintyboost/ There are also any number of commercial devices that can do universal voltage (100-250v 50/60hz) to 5v USB that are barely larger than a matchbook. Cheers, Michael Holstein Cleveland State University From jgreco at ns.sol.net Fri May 21 09:24:16 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 21 May 2010 09:24:16 -0500 (CDT) Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF68F3F.70306@csuohio.edu> from "Michael Holstein" at May 21, 2010 09:48:47 AM Message-ID: <201005211424.o4LEOG7p076359@aurora.sol.net> > If you're at all handy with a soldering iron, this is a fun project to > do what you need : http://www.ladyada.net/make/mintyboost/ Tekkeon's TekCharge MP1550 is a beefier version of this; it will work with two or four AA batteries, and provides USB. If you put rechargeables in, it can also charge them via a secondary charging port. This has become my solution of choice for backup power for power-hungry cell phones that drain their batteries every other day. The flexibility of being able to stop at any store and buy a pack of AA batteries in a crisis is great. For me, it's passed the pocket-indestructability test of having survived more than three months unprotected in my pocket, which typically does plastic thingies in. ... 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 lanson9 at cox.net Fri May 21 09:52:02 2010 From: lanson9 at cox.net (Jamie Sobczyk) Date: Fri, 21 May 2010 10:52:02 -0400 (EDT) Subject: IPv4 Multicast Message-ID: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> Make sure you have "ip multicast-routing" on both routers. On the router interfaces, make sure you have "ip pim sparse-mode" On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) "ip pim rp-address w.x.y.z" Also, make sure that routing is setup on your routers so that your receiver can ping your sender. On your routers you should be able to see the source unicast address and multicast address by typing "show ip mroute" you should see something like this: (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Port-channel15, Forward/Sparse, 7w0d/00:02:59, H (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA Incoming interface: Port-channel15, RPF nbr 10.7.193.138 Outgoing interface list: Port-channel17, Forward/Sparse, 4w5d/00:02:49, H On your switches, with igmp snooping enabled, you should be able to type: "show ip igmp snooping group" and see something like Vlan Group Type Version Port List ----------------------------------------------------------------------- 24 239.192.3.47 igmp v2 Gi1/0/21 That port listed is the port of the requester. -----Original Message----- I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens From morrowc.lists at gmail.com Fri May 21 09:52:23 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 21 May 2010 10:52:23 -0400 Subject: Mikrotik BGP Question In-Reply-To: <4BF67B36.3060507@foobar.org> References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> Message-ID: On Fri, May 21, 2010 at 8:23 AM, Nick Hilliard wrote: > On 21/05/2010 13:16, Lorell Hathcock wrote: > each other. ?Just make sure your boxes have enough RAM to cope with a full > dfz feed. note that you do NOT have to have a full feed on either location, if your goal is simply primary/backup links... getting default from both providers and sending your prefixes out to both (potentially preferring one with an intentionally longer aspath, or other normal tricks/config) will accomplish primary/backup just fine. Don't use a sledghammer when a push pin works. -chris From pete at altadena.net Fri May 21 11:34:22 2010 From: pete at altadena.net (Pete Carah) Date: Fri, 21 May 2010 12:34:22 -0400 Subject: Off-Topic: use laptop only as USB power supply In-Reply-To: <4BF61139.6040707@gmail.com> References: <4BF5B476.2020102@de-cix.net> <4BF5D964.6010700@telcodata.us> <590B2D29-CC0C-4077-951B-7E8BD9BED332@delong.com> <4BF61139.6040707@gmail.com> Message-ID: <4BF6B60E.5020103@altadena.net> On 05/21/2010 12:51 AM, Roy wrote: > Why carry a laptop? Here are some examples > > http://www.walmart.com/ip/Belkin-Mini-Notebook-Surge-Portector-with-Built-In-USB-Charger/10248165?sourceid=1500000000000003142050&ci_src=14110944&ci_sku=10248165 > > > http://www.cyberguys.com/product-details/?productid=39338 > > http://www.cyberguys.com/product-details/?productid=29278 I have two of these (bought from Fry's and Micro Center stores) and they work well (charging my iphone and headset as we speak :-). zip-linq also has a dual auto version that works well (I actually have 3 of that one, one for each of my and my wife's cars and another to leave in the backpack). Neither terribly expensive. You can also use a powered usb hub. Overkill unless you need the hub too... -- Pete > > > From cscora at apnic.net Fri May 21 13:09:30 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 22 May 2010 04:09:30 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201005211809.o4LI9UxE001800@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 22 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 321165 Prefixes after maximum aggregation: 148380 Deaggregation factor: 2.16 Unique aggregates announced to Internet: 156870 Total ASes present in the Internet Routing Table: 34042 Prefixes per ASN: 9.43 Origin-only ASes present in the Internet Routing Table: 29540 Origin ASes announcing only one prefix: 14366 Transit ASes present in the Internet Routing Table: 4502 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (36992) 22 Prefixes from unregistered ASNs in the Routing Table: 331 Unregistered ASNs in the Routing Table: 122 Number of 32-bit ASNs allocated by the RIRs: 581 Prefixes from 32-bit ASNs in the Routing Table: 661 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 162 Number of addresses announced to Internet: 2221080896 Equivalent to 132 /8s, 99 /16s and 1 /24s Percentage of available address space announced: 59.9 Percentage of allocated address space announced: 65.2 Percentage of available address space allocated: 91.9 Percentage of address space in use by end-sites: 82.9 Total number of prefixes smaller than registry allocations: 153934 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76497 Total APNIC prefixes after maximum aggregation: 26734 APNIC Deaggregation factor: 2.86 Prefixes being announced from the APNIC address blocks: 73497 Unique aggregates announced from the APNIC address blocks: 32320 APNIC Region origin ASes present in the Internet Routing Table: 4040 APNIC Prefixes per ASN: 18.19 APNIC Region origin ASes announcing only one prefix: 1110 APNIC Region transit ASes present in the Internet Routing Table: 622 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 519920448 Equivalent to 30 /8s, 253 /16s and 91 /24s Percentage of available APNIC address space announced: 77.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/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: 134171 Total ARIN prefixes after maximum aggregation: 69108 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107058 Unique aggregates announced from the ARIN address blocks: 41502 ARIN Region origin ASes present in the Internet Routing Table: 13697 ARIN Prefixes per ASN: 7.82 ARIN Region origin ASes announcing only one prefix: 5273 ARIN Region transit ASes present in the Internet Routing Table: 1352 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 731107360 Equivalent to 43 /8s, 147 /16s and 208 /24s Percentage of available ARIN address space announced: 62.3 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, 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, 54/8, 55/8, 56/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, 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: 74051 Total RIPE prefixes after maximum aggregation: 42968 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 67010 Unique aggregates announced from the RIPE address blocks: 44081 RIPE Region origin ASes present in the Internet Routing Table: 14472 RIPE Prefixes per ASN: 4.63 RIPE Region origin ASes announcing only one prefix: 7471 RIPE Region transit ASes present in the Internet Routing Table: 2175 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 21 Number of RIPE addresses announced to Internet: 426216928 Equivalent to 25 /8s, 103 /16s and 141 /24s Percentage of available RIPE address space announced: 74.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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28205 Total LACNIC prefixes after maximum aggregation: 6791 LACNIC Deaggregation factor: 4.15 Prefixes being announced from the LACNIC address blocks: 26657 Unique aggregates announced from the LACNIC address blocks: 13910 LACNIC Region origin ASes present in the Internet Routing Table: 1291 LACNIC Prefixes per ASN: 20.65 LACNIC Region origin ASes announcing only one prefix: 405 LACNIC Region transit ASes present in the Internet Routing Table: 225 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 73134848 Equivalent to 4 /8s, 91 /16s and 243 /24s Percentage of available LACNIC address space announced: 72.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7345 Total AfriNIC prefixes after maximum aggregation: 1861 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 5640 Unique aggregates announced from the AfriNIC address blocks: 1668 AfriNIC Region origin ASes present in the Internet Routing Table: 365 AfriNIC Prefixes per ASN: 15.45 AfriNIC Region origin ASes announcing only one prefix: 107 AfriNIC Region transit ASes present in the Internet Routing Table: 83 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 24 Number of AfriNIC addresses announced to Internet: 17856768 Equivalent to 1 /8s, 16 /16s and 121 /24s Percentage of available AfriNIC address space announced: 53.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1848 8422 483 Korea Telecom (KIX) 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1306 293 151 TATA Communications formerly 7545 1212 232 105 TPG Internet Pty Ltd 17974 1059 281 18 PT TELEKOMUNIKASI INDONESIA 9583 990 73 485 Sify Limited 24560 900 305 169 Bharti Airtel Ltd., Telemedia 4134 872 21191 403 CHINANET-BACKBONE 4808 845 1587 214 CNCGROUP IP network: China169 9829 791 681 34 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3932 3733 288 bellsouth.net, inc. 4323 3843 1116 404 Time Warner Telecom 1785 1783 699 130 PaeTec Communications, Inc. 7018 1540 5754 980 AT&T WorldNet Services 20115 1538 1506 654 Charter Communications 2386 1281 568 911 AT&T Data Communications Serv 6478 1248 257 99 AT&T Worldnet Services 3356 1191 10887 407 Level 3 Communications, LLC 22773 1155 2604 64 Cox Communications, Inc. 11492 1146 210 285 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 627 56 6 United Telecom of Georgia 3292 454 2027 393 TDC Tele Danmark 30890 442 116 207 Evolva Telecom 702 414 1869 328 UUNET - Commercial IP service 8551 402 355 38 Bezeq International 8866 396 117 18 Bulgarian Telecommunication C 3320 367 7072 318 Deutsche Telekom AG 3301 365 1413 321 TeliaNet Sweden 12479 337 576 5 Uni2 Autonomous System 3215 329 3218 101 France Telecom Transpac Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1553 2965 245 UniNet S.A. de C.V. 10620 1042 234 152 TVCABLE BOGOTA 28573 877 720 76 NET Servicos de Comunicao S.A 7303 729 377 107 Telecom Argentina Stet-France 6503 580 173 209 AVANTEL, S.A. 22047 545 310 15 VTR PUNTO NET S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 470 202 73 Empresa Nacional de Telecomun 14117 455 30 13 Telefonica del Sur S.A. 11172 444 99 72 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1262 445 10 TEDATA 24863 712 147 39 LINKdotNET AS number 36992 643 278 184 Etisalat MISR 3741 270 852 231 The Internet Solution 2018 216 231 112 Tertiary Education Network 33776 213 11 14 Starcomms Nigeria Limited 6713 176 167 12 Itissalat Al-MAGHRIB 24835 175 78 10 RAYA Telecom - Egypt 29571 172 19 9 Ci Telecom Autonomous system 29975 132 490 17 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3932 3733 288 bellsouth.net, inc. 4323 3843 1116 404 Time Warner Telecom 4766 1848 8422 483 Korea Telecom (KIX) 1785 1783 699 130 PaeTec Communications, Inc. 8151 1553 2965 245 UniNet S.A. de C.V. 7018 1540 5754 980 AT&T WorldNet Services 20115 1538 1506 654 Charter Communications 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1306 293 151 TATA Communications formerly 2386 1281 568 911 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3843 3439 Time Warner Telecom 1785 1783 1653 PaeTec Communications, Inc. 4766 1848 1365 Korea Telecom (KIX) 8151 1553 1308 UniNet S.A. de C.V. 8452 1262 1252 TEDATA 17488 1316 1193 Hathway IP Over Cable Interne 4755 1306 1155 TATA Communications formerly 6478 1248 1149 AT&T Worldnet Services 7545 1212 1107 TPG Internet Pty Ltd 22773 1155 1091 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.202.96.0/19 29571 Ci Telecom Autonomous system 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.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:10 /10:26 /11:67 /12:194 /13:401 /14:689 /15:1269 /16:11071 /17:5272 /18:8978 /19:18255 /20:22557 /21:22602 /22:29441 /23:29089 /24:168288 /25:949 /26:1204 /27:618 /28:142 /29:9 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2516 3932 bellsouth.net, inc. 4323 2329 3843 Time Warner Telecom 4766 1480 1848 Korea Telecom (KIX) 1785 1247 1783 PaeTec Communications, Inc. 8452 1140 1262 TEDATA 17488 1063 1316 Hathway IP Over Cable Interne 11492 1062 1146 Cable One 18566 1040 1059 Covad Communications 10620 958 1042 TVCABLE BOGOTA 7018 925 1540 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:13 8:263 12:2002 13:10 14:1 15:23 16:3 17:8 20:21 24:1431 27:99 31:1 32:47 33:12 38:671 40:98 41:2486 44:3 47:26 52:6 55:7 56:2 57:24 58:724 59:497 60:434 61:1071 62:1062 63:1979 64:3854 65:2353 66:4203 67:1844 68:1112 69:2836 70:714 71:243 72:1820 73:2 74:2292 75:252 76:309 77:859 78:633 79:414 80:1015 81:789 82:482 83:453 84:697 85:1060 86:466 87:704 88:330 89:1551 90:88 91:2755 92:505 93:1114 94:1426 95:596 96:280 97:314 98:548 99:28 108:32 109:481 110:353 111:502 112:261 113:286 114:402 115:556 116:1038 117:641 118:442 119:920 120:139 121:725 122:1432 123:897 124:1106 125:1294 128:210 129:209 130:193 131:560 132:246 133:17 134:193 135:44 136:226 137:173 138:255 139:92 140:482 141:135 142:353 143:383 144:476 145:52 146:428 147:165 148:614 149:288 150:153 151:169 152:261 153:167 154:2 155:324 156:155 157:325 158:107 159:375 160:314 161:185 162:262 163:179 164:407 165:346 166:475 167:393 168:783 169:160 170:705 171:51 172:2 173:739 174:644 175:93 176:1 178:93 180:477 182:60 183:254 184:45 186:383 187:346 188:1340 189:782 190:3640 192:5739 193:4693 194:3358 195:2769 196:1211 197:1 198:3567 199:3433 200:5308 201:1500 202:7983 203:8287 204:4062 205:2323 206:2528 207:3036 208:3893 209:3415 210:2503 211:1242 212:1735 213:1677 214:660 215:70 216:4613 217:1538 218:487 219:371 220:1106 221:400 222:315 223:1 End of report From andy at nosignal.org Fri May 21 13:50:13 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 21 May 2010 19:50:13 +0100 Subject: Partial Use Of one Regions IP Block in another In-Reply-To: References: Message-ID: <7EDB9990-0B4D-4937-B960-F0D8790D4B6B@nosignal.org> On 20 May 2010, at 13:06, Net wrote: > Are there any policies set by internet registries and/or transit providers today that prohibits organizations from using a Partially used IP Block allocated in one region say AP through APNIC to be comissioned and Propagated in another region such as EMEA serviced by RIPE?. In some circumstances, deaggregation of your rir-assigned prefix might lead to partial reachability (some networks filter on rir minimum assignment sizes - not a problem in itself, but some unclever networks exist, that don't additionally take a default). Whatever you announce, make sure it's irr registered too, for the networks who transit or peer with you, who automatically build pfx filters. Happy weekend, Andy From tkapela at gmail.com Fri May 21 16:26:44 2010 From: tkapela at gmail.com (Anton Kapela) Date: Fri, 21 May 2010 17:26:44 -0400 Subject: IPv4 Multicast In-Reply-To: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> Message-ID: <57DC174B-A808-4B38-8F9C-69AB01510F4A@gmail.com> On May 21, 2010, at 10:52 AM, Jamie Sobczyk wrote: > With my VLC receiver I can see the channels via SAP, but when I join the > multicast group I don't receive anything. verify packets actually land on the receiver (tcpdump, etc) interface. verify that your host has a route for 224/4 pointing out the interface you hope joins are leaving from. ensure iptables isn't blocking either the outgoing igmp join, and make sure that it's permitting the incoming mcast-dest packets. if any of these are wrong/failing, then mcast won't work. -Tk From choprboy at dakotacom.net Fri May 21 16:46:27 2010 From: choprboy at dakotacom.net (Choprboy) Date: Fri, 21 May 2010 14:46:27 -0700 Subject: Mikrotik BGP Question In-Reply-To: <02b001caf8df$62324ea0$2696ebe0$@org> References: <02b001caf8df$62324ea0$2696ebe0$@org> Message-ID: <201005211446.27936.choprboy@dakotacom.net> On Friday 21 May 2010 05:16, Lorell Hathcock wrote: > I am inheriting a WISP network with Mikrotik equipment throughout. One of > my first duties is to make the network multihomed. We have our first > internet connection at one location and our second internet connection will > be delivered at a second location in a week or so. [snip] > My question is about BGP on the Mikrotik platform. The guy who I am > supplanting swears that we are supposed to be bringing the second internet > link to the same place as the first internet link for BGP to work properly. > Obviously that is not true with major brand routers And it is not true with Mikrotik either... I work for a WISP that uses Mikrotik almost exclusively, everything from our core to customer CPEs. We have multiple Mikrotik edge routers at diverse locations, with 200+Mbs internet connections thru different providers, all running full BGP feeds, and all sharing those feeds between each other. A simple 1U box with a good MB, 1-2GB RAM, flash drive for booting, and good multi-port Gb ethernet cards for each is all that is needed. We are a small ISP by most standards, but we have had no problem running 180Mbs and 40,000pps in/out on just one of our edges, while carrying on with multiple BGP feeds and exchange between our internal routers. Adrian From martin at airwire.ie Fri May 21 16:56:11 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Fri, 21 May 2010 22:56:11 +0100 Subject: Mikrotik BGP Question In-Reply-To: <4BF67F0B.6090207@spectraaccess.com> References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> <4BF67F0B.6090207@spectraaccess.com> Message-ID: <4BF7017B.9050501@airwire.ie> On 21/05/10 13:39, Bret Clark wrote: > On 05/21/2010 08:23 AM, Nick Hilliard wrote: >> I will refrain from making any smart-ass comments about Mikrotik and BGP, >> but no: there is no reason whatever that you can't take your internet >> feeds >> from different locations, so long as you have a good quality interior >> network link between those two locations, and your two routers talk >> iBGP to >> each other. Just make sure your boxes have enough RAM to cope with a >> full >> dfz feed. >> >> I.e. it's just the same as using any other router in this regard. >> >> Nick >> >> > I've used Mikrotiks for everything except BGP, but we don't use > Mikrotiks for BGP only because we already had BGP on a different > platform...personally, when it comes to BGP, I think people are better > off running it on devices they are familiar with rather then trying to > learn the idiosyncrasies of a new platform. While Mikrotik's BGP implementation isn't very sofisticated, there is no reason, why you can't have your feeds in different places. As Nick outlined, you need to set iBGP up between the boxes. I'm running myself a ISP on mainly Mikrotik basis (basestations and clients, approx 2500 users) and I've been extensively testing Mikrotik's BGP stack in the last 4 years (from 2.9 and up). Mikrotik wrote the whole routing stack from scratch in 3.x, which resultet in tons of problems and bugs. In my opinion, it still isn't where it should be. Don't get me wrong, but there are several pitfalls. - Mikrotik still has some memory leaks in the BGP stack somewhere, causing funny issues at times. - Filters aren't adequate for my use, and lacking a lot on IPv4, but even more on IPv4. First of all, you will need at least a RB1000, RB1100 or a PC based Mikrotik router to get enough ram, to accomodate one full-table or more. Anything less and you can forget it. I'm running a mix of Quagga boxes, Cisco and recently Juniper instead for BGP. For our internal routing OSPF on Mikrotik definatly does the job. Just my 2c. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From cidr-report at potaroo.net Fri May 21 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 May 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201005212200.o4LM01gW056852@wattle.apnic.net> BGP Update Report Interval: 13-May-10 -to- 20-May-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4538 36343 3.2% 6.9 -- ERX-CERNET-BKB China Education and Research Network Center 2 - AS17974 28658 2.5% 63.3 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 3 - AS14420 23276 2.1% 56.8 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 4 - AS36992 17477 1.5% 28.4 -- ETISALAT-MISR 5 - AS5800 13012 1.1% 52.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS4323 12992 1.1% 4.5 -- TWTC - tw telecom holdings, inc. 7 - AS9829 10704 0.9% 23.9 -- BSNL-NIB National Internet Backbone 8 - AS28477 10236 0.9% 1137.3 -- Universidad Autonoma del Esstado de Morelos 9 - AS8452 8620 0.8% 8.9 -- TEDATA TEDATA 10 - AS32528 7885 0.7% 1577.0 -- ABBOTT Abbot Labs 11 - AS13979 7864 0.7% 6.2 -- ATT-IPFR - AT&T WorldNet Services 12 - AS24560 7543 0.7% 8.5 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 13 - AS41786 6870 0.6% 312.3 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 14 - AS3549 6659 0.6% 107.4 -- GBLX Global Crossing Ltd. 15 - AS17488 6338 0.6% 5.4 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 16 - AS8151 5472 0.5% 8.9 -- Uninet S.A. de C.V. 17 - AS12641 5338 0.5% 5.7 -- BT_MPLS BT Global Services MPLS core network 18 - AS22773 5243 0.5% 7.4 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 19 - AS34984 4741 0.4% 21.2 -- TELLCOM-AS Tellcom Iletisim Hizmetleri 20 - AS20115 4637 0.4% 5.4 -- CHARTER-NET-HKY-NC - Charter Communications TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 2637 0.2% 2637.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 2 - AS35931 3341 0.3% 1670.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 7885 0.7% 1577.0 -- ABBOTT Abbot Labs 4 - AS50788 1336 0.1% 1336.0 -- OSYPENKO-AS FOP Osypenko Vitalij Volodymyrovych 5 - AS28477 10236 0.9% 1137.3 -- Universidad Autonoma del Esstado de Morelos 6 - AS11613 936 0.1% 936.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 7 - AS18399 645 0.1% 645.0 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 8 - AS28052 576 0.1% 576.0 -- Arte Radiotelevisivo Argentino 9 - AS29544 1097 0.1% 548.5 -- MAURITEL-AS 10 - AS29493 419 0.0% 419.0 -- GRIDPNPI Institution of Russian Science Academy Petersburg Nuclear Physics Institute of B.P. Konstantinov RAN 11 - AS10445 2378 0.2% 396.3 -- HTG - Huntleigh Telcom 12 - AS3505 738 0.1% 369.0 -- WINDSTREAM - Windstream Communications Inc 13 - AS7534 1318 0.1% 329.5 -- SILKERA-TW NEW SILKERA NETWORK 14 - AS27067 658 0.1% 329.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 15 - AS38331 328 0.0% 328.0 -- ITS-AS-ID-AP Institut Teknologi Sepuluh Nopember 16 - AS41786 6870 0.6% 312.3 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 17 - AS15102 3095 0.3% 281.4 -- ASN-WIBAND-1 - WiBand Communications Corp. 18 - AS37144 259 0.0% 259.0 -- VALUCARD-NG 19 - AS10697 4308 0.4% 253.4 -- Interlink S.R.L. 20 - AS50257 444 0.0% 222.0 -- A-MOBILE-AS JV A-Mobile Ltd. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 58.207.96.0/19 10764 0.9% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 2 - 200.13.36.0/24 10213 0.8% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 188.187.184.0/24 6677 0.5% AS41786 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 4 - 64.76.40.0/24 6114 0.5% AS3549 -- GBLX Global Crossing Ltd. 5 - 130.36.34.0/24 3910 0.3% AS32528 -- ABBOTT Abbot Labs 6 - 130.36.35.0/24 3909 0.3% AS32528 -- ABBOTT Abbot Labs 7 - 206.184.16.0/24 2941 0.2% AS174 -- COGENT Cogent/PSI 8 - 200.50.186.0/24 2828 0.2% AS10697 -- Interlink S.R.L. 9 - 91.212.23.0/24 2637 0.2% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 10 - 143.138.107.0/24 2505 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 11 - 205.91.160.0/20 2160 0.2% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 12 - 198.140.43.0/24 2133 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 180.233.225.0/24 1433 0.1% AS38680 -- CMBHK-AS-KR CMB 14 - 202.92.235.0/24 1404 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 15 - 193.107.224.0/22 1336 0.1% AS50788 -- OSYPENKO-AS FOP Osypenko Vitalij Volodymyrovych 16 - 213.55.112.0/21 1277 0.1% AS24757 -- EthioNet-AS 17 - 213.55.96.0/20 1277 0.1% AS24757 -- EthioNet-AS 18 - 90.150.0.0/24 1254 0.1% AS35400 -- MFIST Interregoinal Organization Network Technologies 19 - 200.50.187.0/24 1217 0.1% AS10697 -- Interlink S.R.L. 20 - 63.211.68.0/22 1208 0.1% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 May 21 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 21 May 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201005212200.o4LM00rk056846@wattle.apnic.net> This report has been generated at Fri May 21 21:11:33 2010 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 14-05-10 323865 199699 15-05-10 324098 199496 16-05-10 323596 199360 17-05-10 323452 199701 18-05-10 323785 199621 19-05-10 323719 199654 20-05-10 323706 199032 21-05-10 323888 199190 AS Summary 34458 Number of ASes in routing system 14643 Number of ASes announcing only one prefix 4434 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95566912 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'). --- 21May10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 324007 199137 124870 38.5% All ASes AS6389 3932 293 3639 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4434 1053 3381 76.3% TWTC - tw telecom holdings, inc. AS4766 1848 497 1351 73.1% KIXS-AS-KR Korea Telecom AS4755 1306 216 1090 83.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS22773 1154 69 1085 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS18566 1059 34 1025 96.8% COVAD - Covad Communications Co. AS7545 1217 253 964 79.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS17488 1316 360 956 72.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6478 1248 344 904 72.4% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1551 649 902 58.2% Uninet S.A. de C.V. AS19262 1122 271 851 75.8% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1257 443 814 64.8% TEDATA TEDATA AS10620 1042 230 812 77.9% Telmex Colombia S.A. AS5668 847 143 704 83.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS24560 900 268 632 70.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7303 730 115 615 84.2% Telecom Argentina S.A. AS4808 845 247 598 70.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS1785 1784 1193 591 33.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS7018 1539 981 558 36.3% ATT-INTERNET4 - AT&T WorldNet Services AS35805 627 94 533 85.0% UTG-AS United Telecom AS AS4780 662 167 495 74.8% SEEDNET Digital United Inc. AS17676 571 80 491 86.0% GIGAINFRA Softbank BB Corp. AS3356 1192 706 486 40.8% LEVEL3 Level 3 Communications AS9443 558 74 484 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS33588 611 160 451 73.8% BRESNAN-AS - Bresnan Communications, LLC. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. AS7011 1111 666 445 40.1% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS28573 875 431 444 50.7% NET Servicos de Comunicao S.A. AS36992 643 209 434 67.5% ETISALAT-MISR Total 37136 10360 26776 72.1% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.160.200.0/23 AS45122 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.233.129.0/24 AS4378 HOSTINGCOM - WCP/32POINTS INTERMEDIATE HOLDING COMPANY, INC. 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.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.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From joelja at bogus.com Fri May 21 17:28:15 2010 From: joelja at bogus.com (joel jaeggli) Date: Fri, 21 May 2010 15:28:15 -0700 Subject: Mikrotik BGP Question In-Reply-To: <201005211446.27936.choprboy@dakotacom.net> References: <02b001caf8df$62324ea0$2696ebe0$@org> <201005211446.27936.choprboy@dakotacom.net> Message-ID: <4BF708FF.6010104@bogus.com> Tutorial: Introduction to BGP http://nanog.org/meetings/nanog47/abstracts.php?pt=MTQ0MSZuYW5vZzQ3&nm=nanog47 Tutorial: BGP 102 http://nanog.org/meetings/nanog48/abstracts.php?pt=MTUyMiZuYW5vZzQ4&nm=nanog48 http://wiki.mikrotik.com/wiki/Manual:BGP_Case_Studies On 2010-05-21 14:46, Choprboy wrote: > On Friday 21 May 2010 05:16, Lorell Hathcock wrote: >> I am inheriting a WISP network with Mikrotik equipment throughout. One of >> my first duties is to make the network multihomed. We have our first >> internet connection at one location and our second internet connection will >> be delivered at a second location in a week or so. > [snip] >> My question is about BGP on the Mikrotik platform. The guy who I am >> supplanting swears that we are supposed to be bringing the second internet >> link to the same place as the first internet link for BGP to work properly. >> Obviously that is not true with major brand routers > > > And it is not true with Mikrotik either... I work for a WISP that uses > Mikrotik almost exclusively, everything from our core to customer CPEs. We > have multiple Mikrotik edge routers at diverse locations, with 200+Mbs > internet connections thru different providers, all running full BGP feeds, > and all sharing those feeds between each other. A simple 1U box with a good > MB, 1-2GB RAM, flash drive for booting, and good multi-port Gb ethernet cards > for each is all that is needed. > > We are a small ISP by most standards, but we have had no problem running > 180Mbs and 40,000pps in/out on just one of our edges, while carrying on with > multiple BGP feeds and exchange between our internal routers. > > > Adrian > > From if at xip.at Fri May 21 18:42:59 2010 From: if at xip.at (Ingo Flaschberger) Date: Sat, 22 May 2010 01:42:59 +0200 (CEST) Subject: Mikrotik BGP Question In-Reply-To: <02b001caf8df$62324ea0$2696ebe0$@org> References: <02b001caf8df$62324ea0$2696ebe0$@org> Message-ID: Dear Lorell, > My question is about BGP on the Mikrotik platform. The guy who I am > supplanting swears that we are supposed to be bringing the second internet > link to the same place as the first internet link for BGP to work properly. > Obviously that is not true with major brand routers which would do the BGP > job just fine. (And he's the same guy that has bridged this whole network, > so it is easy to disbelieve his opinion.) But maybe he knows that Mikrotik > can't perform BGP in the same way that other routers can. > > So here's the question. Is there something about running BGP on a Mikrotik > platform that precludes having the internet connections come in at different > locations? That depends on the netwoek in between this two locations. There could be a lot of good reasons why this is no good idea; please bring some light into this. Kind regards, Ingo Flaschberger From ml at kenweb.org Sat May 22 10:52:52 2010 From: ml at kenweb.org (ML) Date: Sat, 22 May 2010 11:52:52 -0400 Subject: DWDM hardware recommendations Message-ID: <4BF7FDD4.6070103@kenweb.org> I'm in the process of researching DWDM equipment for a new ring I'm about to light. Only two dark fibers to start. My only experience with WDM is a ring lit with MRV CWDM equipment by another provider. The MRV equipment hasn't failed once in the years I've had the service. Good/bad/ugly thoughts on MRV? What I'm looking for is the ability to drop 10G and 1G channels on the same ring. Upgradability to 40G channels is a plus. I haven't been told I should plan for OC-n but it would nice if I had the option. Does anyone have a recommendation that might fit these requirements? Thanks From guxiaojian at gmail.com Sat May 22 13:43:59 2010 From: guxiaojian at gmail.com (Jian Gu) Date: Sat, 22 May 2010 11:43:59 -0700 Subject: useful bgp example In-Reply-To: References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> Message-ID: You don't need ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 You can use RFC1918 space address for iBGP peering. On Wed, May 19, 2010 at 11:37 AM, Jeff Harper wrote: > >> -----Original Message----- >> From: Jared Mauch [mailto:jared at puck.nether.net] >> Sent: Wednesday, May 19, 2010 1:29 PM >> To: Jeff Harper >> Cc: Deric Kwok; nanog at nanog.org >> Subject: Re: useful bgp example >> >> Nice, but you don't show it as-path filtering your transits out. ?I >> frequently see people take something learned from transit A and > sending >> it to transit B, and if it happens to be the backup path in-use for >> your customer, your transits will accept it and likely pick you as >> best-path and hairpin through your network. >> >> - Jared > > Yeah, I left out the actual prefix-list contents, in hindsight I should > have added it, so here it is. Also, a typo in the network statement, > lol. > > network 1.1.1.0 mask 255.255.0.0 > > ip prefix-list NETZ description The networks we advertise via BGP > ip prefix-list NETZ seq 10 permit 1.1.1.0/16 > ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 > > > From lorell at hathcock.org Sat May 22 16:55:57 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Sat, 22 May 2010 16:55:57 -0500 Subject: Mikrotik BGP Question In-Reply-To: References: <02b001caf8df$62324ea0$2696ebe0$@org> Message-ID: <03b501caf9f9$8f315bb0$ad941310$@org> We are putting a private PTP metro ethernet (fiber based) link between the two locations. And both locations will have one internet connection. I am reading that Mikrotik has a memory leak in its BGP implementation. Any more info about this? Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 832-782-4656 (c) 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -----Original Message----- From: Ingo Flaschberger [mailto:if at xip.at] Sent: Friday, May 21, 2010 6:43 PM To: Lorell Hathcock Cc: nanog at nanog.org Subject: Re: Mikrotik BGP Question Dear Lorell, > My question is about BGP on the Mikrotik platform. The guy who I am > supplanting swears that we are supposed to be bringing the second internet > link to the same place as the first internet link for BGP to work properly. > Obviously that is not true with major brand routers which would do the BGP > job just fine. (And he's the same guy that has bridged this whole network, > so it is easy to disbelieve his opinion.) But maybe he knows that Mikrotik > can't perform BGP in the same way that other routers can. > > So here's the question. Is there something about running BGP on a Mikrotik > platform that precludes having the internet connections come in at different > locations? That depends on the netwoek in between this two locations. There could be a lot of good reasons why this is no good idea; please bring some light into this. Kind regards, Ingo Flaschberger From if at xip.at Sat May 22 18:07:24 2010 From: if at xip.at (Ingo Flaschberger) Date: Sun, 23 May 2010 01:07:24 +0200 (CEST) Subject: Mikrotik BGP Question In-Reply-To: <03b501caf9f9$8f315bb0$ad941310$@org> References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> Message-ID: Dear Lorell, > We are putting a private PTP metro ethernet (fiber based) link between the > two locations. And both locations will have one internet connection. this network between should be no problem, what routing protocols do you use in your network? ospf? Kind regards, Ingo Flaschberger From guxiaojian at gmail.com Sat May 22 21:14:14 2010 From: guxiaojian at gmail.com (Jian Gu) Date: Sat, 22 May 2010 19:14:14 -0700 Subject: Useful TCL script? In-Reply-To: References: Message-ID: Wouldn't SNMP walk/get gives you what you need? On Thu, May 20, 2010 at 4:05 PM, Thomas Magill wrote: > I had to come up with a way to monitor average packet size on an > interface so I wrote the following script (cisco devices). ?I don't know > if anyone finds it useful, but here it is if so. ?Also, there is one > issue with it where if the total number of packets an interface has seen > is over 7 digits, it will not calculate it. ?This appears to be a > limitation of the expr command used in cisco TCL and mpexpr is not > supported. ?If anyone else knows a way to bypass this issue I would be > glad to hear it. ?For now it just tells you that the value is too high. > I am also considering creating a job that can input the value into an > OID that we can poll but not exactly sure how to do that so if anyone > has any experience or good references (other than the cisco stuff I find > on google) I would be thankful. > > > > I save this to flash: or disk: (depending on default tcl location per > device) and assign the alias: > > > > alias exec psize tclsh psize.tcl > > > > Then use it like: > > > > Router#psize psize tun1 > > > > Packet Size Information for Tunnel1 > > ---------------------------------------------------- > > ?5 minute input bits/sec = 43000 > > ?5 minute input packets/sec ?= 30 > > ?5 minute average packet size = 179 Bytes > > ---------------------------------------------------- > > ?5 minute output bits/sec = 3000 > > ?5 minute output packets/sec ?= 3 > > ?5 minute average packet size = 125 Bytes > > ---------------------------------------------------- > > ?Total input bytes = 1678803 > > ?Total input packets ?= 7761 > > ?Total average packet size = 216 Bytes > > ---------------------------------------------------- > > ?Total output bytes = 133316 > > ?Total output packets ?= 1041 > > ?Total average packet size = 128 Bytes > > ---------------------------------------------------- > > > > This is my first attempt at a script this complex so if you have any > input/suggestions they are welcome. > > > > ######################################################################## > ##### > > # > # > > # psize.tcl > # > > # By Thomas Magill - 5/7/2010 > # > > # > # > > ######################################################################## > ##### > > # > > # Get input from command line > > set ifname $argv > > # Check interface name for errors > > if {[string equal $ifname ""]} { puts "Usage: psize ifname"; return; } > > if { [ catch { exec "show ip interface $ifname" } errmsg ] } { > > puts "Invalid interface $ifname, command failed"; return} > > set cmdtext [ exec "show interface $ifname" ] > > # Pull interface information and calculate > > foreach line [split $cmdtext "\n"] { > > ?if {[regexp -nocase {^(\S+) is (.*), line protocol is (\S+)} $line > ignore ifnamefull ifstatus iflinkstatus]} { > > } > > ?if {[regexp -nocase {5 minute input rate ([0-9]+) bits/sec, ([0-9]+) > packets/sec} $line ignore bpsinfive ppsinfive]} { > > ?if {$ppsinfive == "0"} {set psizeinfive "0"} else {set psizeinfive > [expr $bpsinfive / $ppsinfive]} > > ?set psizeinfive [expr $psizeinfive / 8] > > } > > ?if {[regexp -nocase {5 minute output rate ([0-9]+) bits/sec, ([0-9]+) > packets/sec} $line ignore bpsoutfive ppsoutfive]} { > > ?if {$ppsoutfive == "0"} {set psizeoutfive "0"} else {set psizeoutfive > [expr $bpsoutfive / $ppsoutfive]} > > ?set psizeoutfive [expr $psizeoutfive / 8] > > } > > ?if {[regexp -nocase {([0-9]+) packets input, ([0-9]+) bytes} $line > ignore ppsintotal bpsintotal]} { > > ?if {$ppsintotal > "9999999"} {set psizeintotal "Too Large to Find"} > elseif {$ppsintotal == "0"} {set psizeintotal "0"} else {set > psizeintotal [expr $bpsintotal / $ppsintotal]} > > } > > ?if {[regexp -nocase {([0-9]+) packets output, ([0-9]+) bytes} $line > ignore ppsouttotal bpsouttotal]} { > > ?if {$ppsouttotal > "9999999"} {set psizeouttotal "Too Large to Find"} > elseif {$ppsouttotal == "0"} {set psizeouttotal "0"} else {set > psizeouttotal [expr $bpsouttotal / $ppsouttotal]} > > } > > ?} > > # Output Data > > ?puts "\n\nPacket Size Information for $ifnamefull" > > ?puts "---------------------------------------------------------" > > ?puts " ?5 minute input bits/sec = $bpsinfive ? ? ? ? ? ? ? ? ? " > > ?puts " ?5 minute input packets/sec ?= $ppsinfive ? ? ? ? ? ? ? " > > ?puts " ?5 minute average packet size = $psizeinfive Bytes ? ? ?" > > ?puts "---------------------------------------------------------" > > ?puts " ?5 minute output bits/sec = $bpsoutfive ? ? ? ? ? ? ? ? " > > ?puts " ?5 minute output packets/sec ?= $ppsoutfive ? ? ? ? ? ? " > > ?puts " ?5 minute average packet size = $psizeoutfive Bytes ? ? " > > ?puts "---------------------------------------------------------" > > ?puts " ?Total input bytes = $bpsintotal ? ? ? ? ? ? ? ? ? ? ? ?" > > ?puts " ?Total input packets ?= $ppsintotal ? ? ? ? ? ? ? ? ? ? " > > ?puts " ?Total average packet size = $psizeintotal Bytes ? ? ? ?" > > ?puts "---------------------------------------------------------" > > ?puts " ?Total output bytes = $bpsouttotal ? ? ? ? ? ? ? ? ? ? ?" > > ?puts " ?Total output packets ?= $ppsouttotal ? ? ? ? ? ? ? ? ? " > > ?puts " ?Total average packet size = $psizeouttotal Bytes ? ? ? " > > ?puts "---------------------------------------------------------" > > > > > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA ?92121 > > > > ProFlowers ?| redENVELOPE > ?| Cherry Moon Farms > ?| Shari's Berries > > > > > From lorell at hathcock.org Sat May 22 23:46:27 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Sat, 22 May 2010 23:46:27 -0500 Subject: Mikrotik BGP Question In-Reply-To: References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> Message-ID: <001a01cafa32$e8369340$b8a3b9c0$@org> We will implement OSPF. Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 832-782-4656 (c) 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -----Original Message----- From: Ingo Flaschberger [mailto:if at xip.at] Sent: Saturday, May 22, 2010 6:07 PM To: Lorell Hathcock Cc: nanog at nanog.org Subject: RE: Mikrotik BGP Question Dear Lorell, > We are putting a private PTP metro ethernet (fiber based) link between the > two locations. And both locations will have one internet connection. this network between should be no problem, what routing protocols do you use in your network? ospf? Kind regards, Ingo Flaschberger From graham at apolix.co.za Sun May 23 01:21:47 2010 From: graham at apolix.co.za (Graham Beneke) Date: Sun, 23 May 2010 08:21:47 +0200 Subject: Mikrotik BGP Question In-Reply-To: <4BF7017B.9050501@airwire.ie> References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> <4BF67F0B.6090207@spectraaccess.com> <4BF7017B.9050501@airwire.ie> Message-ID: <4BF8C97B.3020801@apolix.co.za> On 2010/05/21 11:56 PM, Martin List-Petersen wrote: > - Mikrotik still has some memory leaks in the BGP stack somewhere, > causing funny issues at times. > > - Filters aren't adequate for my use, and lacking a lot on IPv4, but > even more on IPv4. I haven't seen either of those issues running the v4.x stream of RouterOS. The memory leak was solved a while ago and Mikrotik has fairly short release cycles. We have extensive inbound and outbound filters on our eBGP doing most of the normal things that you would do on a cisco. The IPv6 filters must be built via the terminal to avoid limitations with the current GUI but they also work very well -- Graham Beneke From matthew at walster.org Sun May 23 03:31:20 2010 From: matthew at walster.org (Matthew Walster) Date: Sun, 23 May 2010 09:31:20 +0100 Subject: DWDM hardware recommendations In-Reply-To: <4BF7FDD4.6070103@kenweb.org> References: <4BF7FDD4.6070103@kenweb.org> Message-ID: On 22 May 2010 16:52, ML wrote: > Does anyone have a recommendation that might fit these requirements? I've used the MRV Lambdadrivers for a ring using DWDM, 16 channel MUX/DEMUX, with one channel using an 8-in-1 10G TDM device (tunable). No complaints here apart from the need to use MU connectors. M From rmaunier at neotelecoms.com Sun May 23 06:58:01 2010 From: rmaunier at neotelecoms.com (Raphael Maunier) Date: Sun, 23 May 2010 13:58:01 +0200 Subject: DWDM hardware recommendations In-Reply-To: <4BF7FDD4.6070103@kenweb.org> References: <4BF7FDD4.6070103@kenweb.org> Message-ID: <716208ED-5905-4D22-8057-9806E118F1C0@neotelecoms.com> Hello, We moved from MRV to Ekinops (http://www.ekinops.net/). Mrv was really stable ( no issue for the last 3 years), but they are slow in innovation. The new cards just came out. For a simple and cheap solution, I will benchmark, Mrv, Ekinops and BTI. The most innovative and with easy R&D access is Ekinops ( we got special version of a code for a card) You can also contact Transmode but they are slow in response and we clearly don't understand their strategy with multiples card and multiples series. I worked with a customer using transmode, for a simple ring solution, he have 4 type of connectors !!! :) -- Rapha?l Maunier NEO TELECOMS CTO / Responsable Ing?nierie AS8218 On May 22, 2010, at 5:52 PM, ML wrote: > I'm in the process of researching DWDM equipment for a new ring I'm > about to light. Only two dark fibers to start. My only experience with > WDM is a ring lit with MRV CWDM equipment by another provider. The MRV > equipment hasn't failed once in the years I've had the service. > Good/bad/ugly thoughts on MRV? > > What I'm looking for is the ability to drop 10G and 1G channels on the > same ring. Upgradability to 40G channels is a plus. I haven't been > told I should plan for OC-n but it would nice if I had the option. > > Does anyone have a recommendation that might fit these requirements? > > Thanks > > From nick at foobar.org Sun May 23 06:36:24 2010 From: nick at foobar.org (Nick Hilliard) Date: Sun, 23 May 2010 12:36:24 +0100 Subject: DWDM hardware recommendations In-Reply-To: References: <4BF7FDD4.6070103@kenweb.org> Message-ID: On 23 May 2010, at 09:31, Matthew Walster wrote: > No complaints here apart from the need to use MU connectors. MU gives slightly lower attenuation than other types of physical connector (i.e. non spliced). It's a minor pain if you don't have an easy source of MU patch cables, but there are sound reasons for using it. I use Transmode kit, and have found it to be very reliable. Would have no problem recommending it to others. Nick From chris at travelingtech.net Sun May 23 17:16:58 2010 From: chris at travelingtech.net (Christopher Gatlin) Date: Sun, 23 May 2010 17:16:58 -0500 Subject: Useful TCL script? In-Reply-To: References: Message-ID: That is a stellar TCL script! I generally use netflow to glean information regarding average packet size. show ip cache-flow will provide it via the CLI, or a netflow collector will graph it statistically over time. Chris On Thu, May 20, 2010 at 6:05 PM, Thomas Magill wrote: > I had to come up with a way to monitor average packet size on an > interface so I wrote the following script (cisco devices). I don't know > if anyone finds it useful, but here it is if so. Also, there is one > issue with it where if the total number of packets an interface has seen > is over 7 digits, it will not calculate it. This appears to be a > limitation of the expr command used in cisco TCL and mpexpr is not > supported. If anyone else knows a way to bypass this issue I would be > glad to hear it. For now it just tells you that the value is too high. > I am also considering creating a job that can input the value into an > OID that we can poll but not exactly sure how to do that so if anyone > has any experience or good references (other than the cisco stuff I find > on google) I would be thankful. > > > > I save this to flash: or disk: (depending on default tcl location per > device) and assign the alias: > > > > alias exec psize tclsh psize.tcl > > > > Then use it like: > > > > Router#psize psize tun1 > > > > Packet Size Information for Tunnel1 > > ---------------------------------------------------- > > 5 minute input bits/sec = 43000 > > 5 minute input packets/sec = 30 > > 5 minute average packet size = 179 Bytes > > ---------------------------------------------------- > > 5 minute output bits/sec = 3000 > > 5 minute output packets/sec = 3 > > 5 minute average packet size = 125 Bytes > > ---------------------------------------------------- > > Total input bytes = 1678803 > > Total input packets = 7761 > > Total average packet size = 216 Bytes > > ---------------------------------------------------- > > Total output bytes = 133316 > > Total output packets = 1041 > > Total average packet size = 128 Bytes > > ---------------------------------------------------- > > > > This is my first attempt at a script this complex so if you have any > input/suggestions they are welcome. > > > > ######################################################################## > ##### > > # > # > > # psize.tcl > # > > # By Thomas Magill - 5/7/2010 > # > > # > # > > ######################################################################## > ##### > > # > > # Get input from command line > > set ifname $argv > > # Check interface name for errors > > if {[string equal $ifname ""]} { puts "Usage: psize ifname"; return; } > > if { [ catch { exec "show ip interface $ifname" } errmsg ] } { > > puts "Invalid interface $ifname, command failed"; return} > > set cmdtext [ exec "show interface $ifname" ] > > # Pull interface information and calculate > > foreach line [split $cmdtext "\n"] { > > if {[regexp -nocase {^(\S+) is (.*), line protocol is (\S+)} $line > ignore ifnamefull ifstatus iflinkstatus]} { > > } > > if {[regexp -nocase {5 minute input rate ([0-9]+) bits/sec, ([0-9]+) > packets/sec} $line ignore bpsinfive ppsinfive]} { > > if {$ppsinfive == "0"} {set psizeinfive "0"} else {set psizeinfive > [expr $bpsinfive / $ppsinfive]} > > set psizeinfive [expr $psizeinfive / 8] > > } > > if {[regexp -nocase {5 minute output rate ([0-9]+) bits/sec, ([0-9]+) > packets/sec} $line ignore bpsoutfive ppsoutfive]} { > > if {$ppsoutfive == "0"} {set psizeoutfive "0"} else {set psizeoutfive > [expr $bpsoutfive / $ppsoutfive]} > > set psizeoutfive [expr $psizeoutfive / 8] > > } > > if {[regexp -nocase {([0-9]+) packets input, ([0-9]+) bytes} $line > ignore ppsintotal bpsintotal]} { > > if {$ppsintotal > "9999999"} {set psizeintotal "Too Large to Find"} > elseif {$ppsintotal == "0"} {set psizeintotal "0"} else {set > psizeintotal [expr $bpsintotal / $ppsintotal]} > > } > > if {[regexp -nocase {([0-9]+) packets output, ([0-9]+) bytes} $line > ignore ppsouttotal bpsouttotal]} { > > if {$ppsouttotal > "9999999"} {set psizeouttotal "Too Large to Find"} > elseif {$ppsouttotal == "0"} {set psizeouttotal "0"} else {set > psizeouttotal [expr $bpsouttotal / $ppsouttotal]} > > } > > } > > # Output Data > > puts "\n\nPacket Size Information for $ifnamefull" > > puts "---------------------------------------------------------" > > puts " 5 minute input bits/sec = $bpsinfive " > > puts " 5 minute input packets/sec = $ppsinfive " > > puts " 5 minute average packet size = $psizeinfive Bytes " > > puts "---------------------------------------------------------" > > puts " 5 minute output bits/sec = $bpsoutfive " > > puts " 5 minute output packets/sec = $ppsoutfive " > > puts " 5 minute average packet size = $psizeoutfive Bytes " > > puts "---------------------------------------------------------" > > puts " Total input bytes = $bpsintotal " > > puts " Total input packets = $ppsintotal " > > puts " Total average packet size = $psizeintotal Bytes " > > puts "---------------------------------------------------------" > > puts " Total output bytes = $bpsouttotal " > > puts " Total output packets = $ppsouttotal " > > puts " Total average packet size = $psizeouttotal Bytes " > > puts "---------------------------------------------------------" > > > > > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > > > > -- From mysidia at gmail.com Sun May 23 18:13:49 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 23 May 2010 18:13:49 -0500 Subject: Useful TCL script? In-Reply-To: References: Message-ID: On Sun, May 23, 2010 at 5:16 PM, Christopher Gatlin wrote: > That is a stellar TCL script! > I generally use netflow to glean information regarding average packet size. Seems like a good script to me. My only criticism would be pretty hard to do anything about... you're averaging an average over a longer period of time than the underlying data that computes the average. dividing 5 minute average databytes approximation by 5 minute average packets approximation is probably not a very reliable estimate for 5 minute average packet size. Even ignoring roundoff errors, an amount of error is introduced by averaging less precise samples, than the device should have access to (if it could compute that rolling average itself using 1 minute or higher resolution data) The less stable the packet size, the more error your approximation should have. Example of 5 minute average over 5 60-second bps divided by pps samples... Versus taking the two 5 minute average rates and dividing them. 60sec average after 1min 2min 3min 4min 5min | Actual 5 minute average rate | bps 100000 200000 300000 400000 850000 | 370000 pps 600 300 900 1000 3620 | 1284 bps/pps 166.67 666.67 333.33 400 234.80 | 360.294 BPS / PPS that would be computed by 370000 / 1284 = 288.16 bits When 360.294 bits should be the answer, is an error of 72.134 bits (or 9 bytes out of 45 bytes), Representing an introduced error of ~20% -- -J From tmagill at providecommerce.com Sun May 23 19:26:31 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Sun, 23 May 2010 17:26:31 -0700 Subject: Useful TCL script? In-Reply-To: References: Message-ID: It was more of a quick and dirty project and a reason for me to learn some TCL. I wasn't aware of any way to get the value from snmp or any cli command so I pulled the info I did have (show int) and worked with that. As I try to improve my TCL skills, I will probably work on this. In fact, I have already updated it somewhat but do not have the final r2. This was basically a random fun project for me and thought some people may find value in the (semi) finished product. Thanks to everyone for the input though. It gives me things to try to figure out. And I am definitely no match major so the margin of error was really the last thing on my mind... I was just automating what one of my team was doing manually. As far as the comments of using netflow, I usually agree but we have the solarwinds netflow product which I am not a fan of at all and find it hard to get the useful data I want. Other products I have used allow such better ability to drill in to data but solarwinds has let me down in the netflow arena. -----Original Message----- From: James Hess [mailto:mysidia at gmail.com] Sent: Sunday, May 23, 2010 4:14 PM To: Christopher Gatlin Cc: Thomas Magill; nanog at nanog.org Subject: Re: Useful TCL script? On Sun, May 23, 2010 at 5:16 PM, Christopher Gatlin wrote: > That is a stellar TCL script! > I generally use netflow to glean information regarding average packet size. Seems like a good script to me. My only criticism would be pretty hard to do anything about... you're averaging an average over a longer period of time than the underlying data that computes the average. dividing 5 minute average databytes approximation by 5 minute average packets approximation is probably not a very reliable estimate for 5 minute average packet size. Even ignoring roundoff errors, an amount of error is introduced by averaging less precise samples, than the device should have access to (if it could compute that rolling average itself using 1 minute or higher resolution data) The less stable the packet size, the more error your approximation should have. Example of 5 minute average over 5 60-second bps divided by pps samples... Versus taking the two 5 minute average rates and dividing them. 60sec average after 1min 2min 3min 4min 5min | Actual 5 minute average rate | bps 100000 200000 300000 400000 850000 | 370000 pps 600 300 900 1000 3620 | 1284 bps/pps 166.67 666.67 333.33 400 234.80 | 360.294 BPS / PPS that would be computed by 370000 / 1284 = 288.16 bits When 360.294 bits should be the answer, is an error of 72.134 bits (or 9 bytes out of 45 bytes), Representing an introduced error of ~20% -- -J From if at xip.at Sun May 23 20:55:34 2010 From: if at xip.at (Ingo Flaschberger) Date: Mon, 24 May 2010 03:55:34 +0200 (CEST) Subject: Mikrotik BGP Question In-Reply-To: <001a01cafa32$e8369340$b8a3b9c0$@org> References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> Message-ID: Dear Lorell, > We will implement OSPF. so what arguments speak against 2 bgp upstreams? Kind regards, Ingo Flaschberger From joelja at bogus.com Mon May 24 00:26:39 2010 From: joelja at bogus.com (joel jaeggli) Date: Sun, 23 May 2010 22:26:39 -0700 Subject: Mikrotik BGP Question In-Reply-To: References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> Message-ID: <4BFA0E0F.50103@bogus.com> On 2010-05-23 18:55, Ingo Flaschberger wrote: > Dear Lorell, > >> We will implement OSPF. > > so what arguments speak against 2 bgp upstreams? It's not an either or proposition... ospf carries your internal routes, ibgp carries you external routes between internal routers. you can carry default around in either in fact you probably should since routers that don't need a nuanced view of the outside world don't need to carry such a big table. > Kind regards, > Ingo Flaschberger > > From gbonser at seven.com Mon May 24 00:48:01 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 23 May 2010 22:48:01 -0700 Subject: Mikrotik BGP Question In-Reply-To: <4BFA0E0F.50103@bogus.com> References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> <4BFA0E0F.50103@bogus.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA465C@RWC-EX1.corp.seven.com> > -----Original Message----- > From: joel jaeggli [mailto:joelja at bogus.com] > Sent: Sunday, May 23, 2010 10:27 PM > To: Ingo Flaschberger > Cc: nanog at nanog.org > Subject: Re: Mikrotik BGP Question > > On 2010-05-23 18:55, Ingo Flaschberger wrote: > > Dear Lorell, > > > >> We will implement OSPF. > > > > so what arguments speak against 2 bgp upstreams? > > It's not an either or proposition... Well, I believe the original poster said that one of his colleagues swore that BGP multihoming wouldn't work unless both feeds terminated on the same router. I suppose said colleague has never heard of iBGP between two routers of the local AS. Those two routers should probably take a full table and exchange them between the two but going inside the network, yeah, they should probably simply originate a default into the the ospf routing. But I am making some assumptions here. I am assuming the two routers have connectivity between them sufficient to handle the required traffic in case one of the upstreams fails (backhaul bandwidth is at least equal to upstream bandwidth). Maybe the colleague knew that the links between the sites were insufficient and that is why both links were desired on the same physical unit or something. It is impossible to sort out other people's networking from short blurbs on a mailing list. George From fw at deneb.enyo.de Mon May 24 04:34:40 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 24 May 2010 11:34:40 +0200 Subject: Mikrotik BGP Question In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA465C@RWC-EX1.corp.seven.com> (George Bonser's message of "Sun, 23 May 2010 22:48:01 -0700") References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> <4BFA0E0F.50103@bogus.com> <5A6D953473350C4B9995546AFE9939EE09EA465C@RWC-EX1.corp.seven.com> Message-ID: <87wrut1w3z.fsf@mid.deneb.enyo.de> * George Bonser: > Well, I believe the original poster said that one of his colleagues > swore that BGP multihoming wouldn't work unless both feeds terminated on > the same router. I suppose said colleague has never heard of iBGP > between two routers of the local AS. Those two routers should probably > take a full table and exchange them between the two but going inside the > network, yeah, they should probably simply originate a default into the > the ospf routing. Does this really work that well? Won't you still get loops or blackholes unless the eBGP routes on all border routers are identical? I think you also need iBGP speakers along all feasible paths between eBGP speakers. From chip.gwyn at gmail.com Mon May 24 08:51:23 2010 From: chip.gwyn at gmail.com (chip) Date: Mon, 24 May 2010 09:51:23 -0400 Subject: DWDM hardware recommendations In-Reply-To: <4BF7FDD4.6070103@kenweb.org> References: <4BF7FDD4.6070103@kenweb.org> Message-ID: I've been pretty happy with the Adva FSP3000R7 units. Lots of options for 1g and 10g and they are very helpful with setup and design. There's a lot more to it than just coming up with an attenuation budget. --chip On Sat, May 22, 2010 at 11:52 AM, ML wrote: > I'm in the process of researching DWDM equipment for a new ring I'm > about to light. Only two dark fibers to start. My only experience with > WDM is a ring lit with MRV CWDM equipment by another provider. The MRV > equipment hasn't failed once in the years I've had the service. > Good/bad/ugly thoughts on MRV? > > What I'm looking for is the ability to drop 10G and 1G channels on the > same ring. Upgradability to 40G channels is a plus. I haven't been > told I should plan for OC-n but it would nice if I had the option. > > Does anyone have a recommendation that might fit these requirements? > > Thanks > > > -- Just my $.02, your mileage may vary, batteries not included, etc.... From lorell at hathcock.org Mon May 24 09:31:33 2010 From: lorell at hathcock.org (Lorell Hathcock) Date: Mon, 24 May 2010 09:31:33 -0500 Subject: Mikrotik BGP Question In-Reply-To: References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> Message-ID: <00de01cafb4d$e2165b50$a64311f0$@org> None in my mind. The legacy network operator was unfamiliar with actual best practice enterprise/carrier networking policies that he thought that for BGP to work on a two internet feed network, both internet connections have to be delivered to the same location. I thought since he has more insight into Mikrotik, that he knew about a bug with Mikrotik that made the argument true. Feedback from NANOG list members that also run Mikrotik has proven that there is no problem with running current rev levels of the Mikrotik RouterOS and BGP with internet feeds at two different locations. Sincerely, Lorell Hathcock OfficeConnect.net | 832-665-3400 x101 (o) | 832-782-4656 (c) 713-992-2343 (f) | lorell at officeconnect.net Texas State Security Contractor License | ONSSI Certified Channel Partner Axis Communications Channel Partner | BICSI Corporate Member Leviton Authorized Installer -----Original Message----- From: Ingo Flaschberger [mailto:if at xip.at] Sent: Sunday, May 23, 2010 8:56 PM To: Lorell Hathcock Cc: nanog at nanog.org Subject: RE: Mikrotik BGP Question Dear Lorell, > We will implement OSPF. so what arguments speak against 2 bgp upstreams? Kind regards, Ingo Flaschberger From gbonser at seven.com Mon May 24 10:48:00 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 24 May 2010 08:48:00 -0700 Subject: Mikrotik BGP Question In-Reply-To: <87wrut1w3z.fsf@mid.deneb.enyo.de> References: <02b001caf8df$62324ea0$2696ebe0$@org><03b501caf9f9$8f315bb0$ad941310$@org><001a01cafa32$e8369340$b8a3b9c0$@org><4BFA0E0F.50103@bogus.com><5A6D953473350C4B9995546AFE9939EE09EA465C@RWC-EX1.corp.seven.com> <87wrut1w3z.fsf@mid.deneb.enyo.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA4667@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Florian Weimer > Sent: Monday, May 24, 2010 2:35 AM > To: George Bonser > Cc: joel jaeggli; Ingo Flaschberger; nanog at nanog.org > Subject: Re: Mikrotik BGP Question > > * George Bonser: > > > Does this really work that well? Won't you still get loops or > blackholes unless the eBGP routes on all border routers are identical? As opposed to what, injecting the entire BGP table into your igp? That generally doesn't work well. > > I think you also need iBGP speakers along all feasible paths between > eBGP speakers. I was assuming the eBGP speakers were directly connected over some sort of interconnecting backhaul. Again, you can't really figure out what someone's topology is from a short blurb on a mailing list. Yes, if there are intervening hops, they will need to speak iBGP as well and possibly configured as route reflectors if it isn't practical to fully mesh everything. Maybe there is a reason the legacy operator said both uplinks must be connected to the same router. If the two locations are not interconnected, that would be one reason. I don't believe the original poster described their internal connectivity. George From fw at deneb.enyo.de Mon May 24 10:50:43 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Mon, 24 May 2010 17:50:43 +0200 Subject: Mikrotik BGP Question In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA4667@RWC-EX1.corp.seven.com> (George Bonser's message of "Mon, 24 May 2010 08:48:00 -0700") References: <02b001caf8df$62324ea0$2696ebe0$@org> <03b501caf9f9$8f315bb0$ad941310$@org> <001a01cafa32$e8369340$b8a3b9c0$@org> <4BFA0E0F.50103@bogus.com> <5A6D953473350C4B9995546AFE9939EE09EA465C@RWC-EX1.corp.seven.com> <87wrut1w3z.fsf@mid.deneb.enyo.de> <5A6D953473350C4B9995546AFE9939EE09EA4667@RWC-EX1.corp.seven.com> Message-ID: <87632ds3ho.fsf@mid.deneb.enyo.de> * George Bonser: >> Does this really work that well? Won't you still get loops or >> blackholes unless the eBGP routes on all border routers are identical? > > As opposed to what, injecting the entire BGP table into your igp? As opposed to just injecting defaults. > Maybe there is a reason the legacy operator said both uplinks must be > connected to the same router. If the two locations are not > interconnected, that would be one reason. I don't believe the original > poster described their internal connectivity. There was a follow-up that mentioned that there's a direct connection, so they just have to make the other paths infeasible. From jharper at first-american.net Mon May 24 11:27:51 2010 From: jharper at first-american.net (Jeff Harper) Date: Mon, 24 May 2010 11:27:51 -0500 Subject: useful bgp example In-Reply-To: References: <8B6E58DA-0DD3-43EC-AEDC-7DECDF2DA3FD@puck.nether.net> Message-ID: > -----Original Message----- > From: Jian Gu [mailto:guxiaojian at gmail.com] > Sent: Saturday, May 22, 2010 1:44 PM > To: Jeff Harper > Cc: Jared Mauch; nanog at nanog.org > Subject: Re: useful bgp example > > You don't need > > ip prefix-list NETZ seq 1000 deny 0.0.0.0/0 le 32 > I know, I just use it as one of those things I like to do as a habit. From allan.eising+gmane at gmail.com Mon May 24 11:28:44 2010 From: allan.eising+gmane at gmail.com (Allan Eising) Date: Mon, 24 May 2010 16:28:44 +0000 (UTC) Subject: Mikrotik BGP Question References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> <4BF67F0B.6090207@spectraaccess.com> <4BF7017B.9050501@airwire.ie> <4BF8C97B.3020801@apolix.co.za> Message-ID: On Sun, 23 May 2010 08:21:47 +0200, Graham Beneke wrote: > On 2010/05/21 11:56 PM, Martin List-Petersen wrote: >> - Mikrotik still has some memory leaks in the BGP stack somewhere, >> causing funny issues at times. >> >> - Filters aren't adequate for my use, and lacking a lot on IPv4, but >> even more on IPv4. > > I haven't seen either of those issues running the v4.x stream of > RouterOS. The memory leak was solved a while ago and Mikrotik has fairly > short release cycles. > > We have extensive inbound and outbound filters on our eBGP doing most of > the normal things that you would do on a cisco. The IPv6 filters must be > built via the terminal to avoid limitations with the current GUI but > they also work very well In some ways, I find the MikroTik RouterOS routing filter syntax a little more powerful than Cisco's route-maps. As routing filters work the same way as firewall filters, you can group rules in "chains" and reuse parts of your filters in other filters by jumping to another chain. This could be used, for instance, on a peering setup, where you have a number of rules per peer but also some common filtering for all peers, or to handle specific and generic filtering for your customers. I haven't yet found anything that I missed being able to with filters, at least with BGP. With other routing protocols, it's another story. Regards, Allan Eising From dmburgess at linktechs.net Mon May 24 11:44:54 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Mon, 24 May 2010 11:44:54 -0500 Subject: Mikrotik BGP Question References: <02b001caf8df$62324ea0$2696ebe0$@org><4BF67B36.3060507@foobar.org> <4BF67F0B.6090207@spectraaccess.com><4BF7017B.9050501@airwire.ie> <4BF8C97B.3020801@apolix.co.za> Message-ID: <91522911795E174F97E7EF8B792A1031228E4A@ltiserver.LTI.local> in V3 RouterOS's BGP support is very decent. We typically don't have any issues with it! :) Whats nice is a router with 2 gig of RAM (cheap RAM too) can take multiple full table BGP feeds without issues. Something else that's nice on our Dual Core systems is that while you are receiving the routes, you are only doing so on one core, instead of hitting high CPU while you receive all those, you only go up to 50% (on dual core system, and lower for quad and dual-quad systems). So you don't have the huge CPU issue when you pull those routes. We had some upstream limit the BGP to something stupid like 128k! Takes 50 min to get all the routes! ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Allan Eising [mailto:allan.eising+gmane at gmail.com] Sent: Monday, May 24, 2010 11:29 AM To: nanog at nanog.org Subject: Re: Mikrotik BGP Question On Sun, 23 May 2010 08:21:47 +0200, Graham Beneke wrote: > On 2010/05/21 11:56 PM, Martin List-Petersen wrote: >> - Mikrotik still has some memory leaks in the BGP stack somewhere, >> causing funny issues at times. >> >> - Filters aren't adequate for my use, and lacking a lot on IPv4, but >> even more on IPv4. > > I haven't seen either of those issues running the v4.x stream of > RouterOS. The memory leak was solved a while ago and Mikrotik has fairly > short release cycles. > > We have extensive inbound and outbound filters on our eBGP doing most of > the normal things that you would do on a cisco. The IPv6 filters must be > built via the terminal to avoid limitations with the current GUI but > they also work very well In some ways, I find the MikroTik RouterOS routing filter syntax a little more powerful than Cisco's route-maps. As routing filters work the same way as firewall filters, you can group rules in "chains" and reuse parts of your filters in other filters by jumping to another chain. This could be used, for instance, on a peering setup, where you have a number of rules per peer but also some common filtering for all peers, or to handle specific and generic filtering for your customers. I haven't yet found anything that I missed being able to with filters, at least with BGP. With other routing protocols, it's another story. Regards, Allan Eising From tmagill at providecommerce.com Mon May 24 13:21:45 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Mon, 24 May 2010 11:21:45 -0700 Subject: Quick IP6/BGP question Message-ID: >From the provider side, are most of you who are implementing IP6 peerings running BGP over IP4 and just using IP6 address families to exchange routes or doing IP6 peering? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From oberman at es.net Mon May 24 13:26:10 2010 From: oberman at es.net (Kevin Oberman) Date: Mon, 24 May 2010 11:26:10 -0700 Subject: Quick IP6/BGP question In-Reply-To: Your message of "Mon, 24 May 2010 11:21:45 PDT." Message-ID: <20100524182610.0EBD71CC3A@ptavv.es.net> > Date: Mon, 24 May 2010 11:21:45 -0700 > From: "Thomas Magill" > > >From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? Can't speak for "most of us", but we run an iBGP v4 mesh carrying both v4 and v6 routes. For external peers, we run separate peerings. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From mksmith at adhost.com Mon May 24 13:26:32 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 24 May 2010 11:26:32 -0700 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D520316080E1325@ad-exh01.adhost.lan> > -----Original Message----- > From: Thomas Magill [mailto:tmagill at providecommerce.com] > Sent: Monday, May 24, 2010 11:22 AM > To: nanog at nanog.org > Subject: Quick IP6/BGP question > > >From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > At the Seattle Internet Exchange we have both IPv4 and IPv6 peering, via discrete addresses, on the same interface. Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From cra at WPI.EDU Mon May 24 13:30:29 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 24 May 2010 14:30:29 -0400 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: <20100524183029.GG12801@angus.ind.WPI.EDU> On Mon, May 24, 2010 at 11:21:45AM -0700, Thomas Magill wrote: > From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? I've never liked how you have to configure ::w.x.y.z/96 style IPv4-compatible IPv6 addresses in order to use IPv6 NLRIs with IPv4 BGP sessions, so I've always used separate native IPv6 sessions. From owen at delong.com Mon May 24 13:29:44 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 24 May 2010 11:29:44 -0700 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: At Hurricane, most of our IPv6 peerings are exchanging over IPv6 addresses. In general, most routers work better if you run IPv4 peering on IPv4 and IPv6 peering on IPv6. In many cases, this is because the configuration files are less confusing more than any underlying dependency in the router OS. YMMV, but, my recommendation is to peer v6 on v6 and v4 o v4. Owen On May 24, 2010, at 11:21 AM, Thomas Magill wrote: >> From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > > From tmagill at providecommerce.com Mon May 24 13:39:26 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Mon, 24 May 2010 11:39:26 -0700 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: Thanks (to you and everyone else that answered before). It sounds like everyone is in agreement. I mostly ask because a customer of mine is considering venturing into the ISP business and expressed interest in offering IP6. If that is the case, I want to do it correctly from the start. -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Monday, May 24, 2010 11:30 AM To: Thomas Magill Cc: nanog at nanog.org Subject: Re: Quick IP6/BGP question At Hurricane, most of our IPv6 peerings are exchanging over IPv6 addresses. In general, most routers work better if you run IPv4 peering on IPv4 and IPv6 peering on IPv6. In many cases, this is because the configuration files are less confusing more than any underlying dependency in the router OS. YMMV, but, my recommendation is to peer v6 on v6 and v4 o v4. Owen On May 24, 2010, at 11:21 AM, Thomas Magill wrote: >> From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > > From Wesley.E.George at sprint.com Mon May 24 13:41:08 2010 From: Wesley.E.George at sprint.com (George, Wes E IV [NTK]) Date: Mon, 24 May 2010 13:41:08 -0500 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: We've done it both ways. We've found that there are sometimes issues with announcing IPv6 NLRI over IPv4 BGP sessions depending on your chosen vendor and code version on both sides of the session. Specifically, we have seen some implementations where an IPv4-mapped IPv6 address (usually the IPv4 router-id or neighbor address) is announced as the next-hop, or a link-local address is used as the next-hop, or some random junk is announced as the next-hop, even with next-hop-self configured. All of these result in the receiving router dropping the announcements because it doesn't have a route to the next-hop. It's usually possible to work around this by using route policies to force the correct next-hop to be written on in/outbound announcements, and as we find it working improperly, we've been reporting bugs, but I thought it would be worth bringing this up as a caveat so that you can make sure your hardware/software of choice is behaving properly if you choose to go this route. Also, I know of at least one vendor that didn't implement the converse functionality in CLI yet - it's impossible to configure an IPv6 neighbor address in the IPv4 address family in order to exchange IPv4 NLRI over an IPv6 BGP session. Thanks, Wes George -----Original Message----- From: Thomas Magill [mailto:tmagill at providecommerce.com] Sent: Monday, May 24, 2010 2:22 PM To: nanog at nanog.org Subject: Quick IP6/BGP question >From the provider side, are most of you who are implementing IP6 peerings running BGP over IP4 and just using IP6 address families to exchange routes or doing IP6 peering? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. From andy at nosignal.org Mon May 24 13:50:58 2010 From: andy at nosignal.org (Andy Davidson) Date: Mon, 24 May 2010 19:50:58 +0100 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: <5D60E9E3-C332-442C-BC5E-79738B0758B6@nosignal.org> On 24 May 2010, at 19:21, Thomas Magill wrote: > From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? Different sessions, one for v4, one for v6. This keeps config saner, therefore debugging easier. It means you can split out your v4 and v6 edge in the future should you want to, without having to renumber and split out the sessions then. Thanks Andy From sethm at rollernet.us Mon May 24 13:57:32 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 24 May 2010 11:57:32 -0700 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: <4BFACC1C.1050603@rollernet.us> On 5/24/10 11:21 AM, Thomas Magill wrote: >>From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? > > Within my core I run multiprotocol BGP. At the edge it's all configured with separate v4 and v6 neighbors. ~Seth From streiner at cluebyfour.org Mon May 24 14:43:57 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Mon, 24 May 2010 15:43:57 -0400 (EDT) Subject: Quick IP6/BGP question In-Reply-To: <17838240D9A5544AAA5FF95F8D520316080E1325@ad-exh01.adhost.lan> References: <17838240D9A5544AAA5FF95F8D520316080E1325@ad-exh01.adhost.lan> Message-ID: On Mon, 24 May 2010, Michael K. Smith - Adhost wrote: > At the Seattle Internet Exchange we have both IPv4 and IPv6 peering, via > discrete addresses, on the same interface. That's how we do it here as well. jms From tmagill at providecommerce.com Mon May 24 15:00:09 2010 From: tmagill at providecommerce.com (Thomas Magill) Date: Mon, 24 May 2010 13:00:09 -0700 Subject: Cisco ASR Message-ID: Anyone using ASRs? We are demoing one to possibly upgrade our 7206s. We are seeing what looks like a memory leak on the RP. Cisco is looking at it and says they haven't seen it before. I am wondering if anyone else has run across this. With the default 2G of memory the RP only had about 1% free memory, and the router was rebooting every 5 days or so when the RP ran out. We upgraded and now have about 60% free on the RP, but I still see the used memory incrementing at a pretty steady rate. We are running IOS-XE 12.2(33)XNF. The router is currently not even routing traffic, just acting as a BGP peer so it has one set of full tables. It seems to be a process on the Linux OS side that has the leak as the IOS memory commands show everything staying pretty static. Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 mailto:tmagill at providecommerce.com provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers | redENVELOPE | Cherry Moon Farms | Shari's Berries From dmfh at dmfh.cx Mon May 24 16:41:53 2010 From: dmfh at dmfh.cx (DMFH) Date: Mon, 24 May 2010 17:41:53 -0400 Subject: NIKSUN? Thoughts? Message-ID: <20100524214153.415784013@nexus6.priv.dmfh.cx> All: I've been digging for more information about NIKSUN, http:// www.niksun.com, and found this sort-of informative post here, , which got me to join in here and ask if anyone has had more experience with them recently. I'm taking a look at their "Enterprise" kit, so far, so good, I'm able to place the probes at egress points in my network and get down to packet / other data wherever through a single interface and avoid "probe hopping", but before I expand my trial a bit more - anyone used this before? The prior poster(s) just seemed to be using only a single product like old Sniffers & I'm curious about bigger deployments. /dmfh From esavage at digitalrage.org Mon May 24 19:05:56 2010 From: esavage at digitalrage.org (Elijah Savage III) Date: Mon, 24 May 2010 20:05:56 -0400 Subject: Cisco ASR In-Reply-To: Message-ID: On 5/24/10 4:00 PM, "Thomas Magill" wrote: > Anyone using ASRs? We are demoing one to possibly upgrade our 7206s. > We are seeing what looks like a memory leak on the RP. Cisco is looking > at it and says they haven't seen it before. I am wondering if anyone > else has run across this. With the default 2G of memory the RP only had > about 1% free memory, and the router was rebooting every 5 days or so > when the RP ran out. We upgraded and now have about 60% free on the RP, > but I still see the used memory incrementing at a pretty steady rate. > We are running IOS-XE 12.2(33)XNF. > > > > The router is currently not even routing traffic, just acting as a BGP > peer so it has one set of full tables. It seems to be a process on the > Linux OS side that has the leak as the IOS memory commands show > everything staying pretty static. > > > > Thomas Magill > Network Engineer > > Office: (858) 909-3777 > > Cell: (858) 869-9685 > mailto:tmagill at providecommerce.com > > > provide-commerce > 4840 Eastgate Mall > > San Diego, CA 92121 > > > > ProFlowers | redENVELOPE > | Cherry Moon Farms > | Shari's Berries > > I am using a few 1002's and I am not seeing that issue. I will get you the IOS train later. From darden at armc.org Tue May 25 06:37:48 2010 From: darden at armc.org (Darden, Patrick S.) Date: Tue, 25 May 2010 07:37:48 -0400 Subject: Google Op Plz In-Reply-To: Message-ID: Could a Google Op get in touch with me off-list please? I have a fairly stupid situation.... --p From randy at psg.com Tue May 25 09:28:39 2010 From: randy at psg.com (Randy Bush) Date: Tue, 25 May 2010 16:28:39 +0200 Subject: looking glass Message-ID: so i went to get a looking glass going, and went to install lg (http://freshmeat.net/projects/lg/) on freebsd 8. it is perl insanity. among other cpan sikness, it wants to build an entire perl implementation of ssh, with 666 other library modules included when there is a perfectly fine ssh client on the machine. is there a decent looking glass package that does not fill my machine with trash? randy From ken.gilmour at gmail.com Tue May 25 09:33:58 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Tue, 25 May 2010 08:33:58 -0600 Subject: looking glass In-Reply-To: References: Message-ID: I've used BGPLG for a few years on OpenBSD. Pretty solid and reliable On 25 May 2010 08:28, Randy Bush wrote: > so i went to get a looking glass going, and went to install lg > (http://freshmeat.net/projects/lg/) on freebsd 8. > > it is perl insanity. among other cpan sikness, it wants to build an > entire perl implementation of ssh, with 666 other library modules > included when there is a perfectly fine ssh client on the machine. > > is there a decent looking glass package that does not fill my machine > with trash? > > randy > > > From lists at quux.de Tue May 25 09:38:32 2010 From: lists at quux.de (Jens Link) Date: Tue, 25 May 2010 16:38:32 +0200 Subject: looking glass In-Reply-To: (Randy Bush's message of "Tue, 25 May 2010 16:28:39 +0200") References: Message-ID: <87d3wkm4gn.fsf@bowmore.quux.de> Randy Bush writes: > is there a decent looking glass package that does not fill my machine > with trash? Haven't tried it but what about RANCID? http://www.shrubbery.net/rancid/man/lg_intro.1.html Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From greg at bestnet.kharkov.ua Tue May 25 09:40:31 2010 From: greg at bestnet.kharkov.ua (Gregory Edigarov) Date: Tue, 25 May 2010 17:40:31 +0300 Subject: looking glass In-Reply-To: References: Message-ID: <20100525174031.64aba428@greg.bestnet.kharkov.ua> On Tue, 25 May 2010 16:28:39 +0200 Randy Bush wrote: > so i went to get a looking glass going, and went to install lg > (http://freshmeat.net/projects/lg/) on freebsd 8. > > it is perl insanity. among other cpan sikness, it wants to build an > entire perl implementation of ssh, with 666 other library modules > included when there is a perfectly fine ssh client on the machine. > > is there a decent looking glass package that does not fill my machine > with trash? it is called OpenBSD. it will fill your machine with OpenBSD though, don't know if you can afford it. :-) -- With best regards, Gregory Edigarov From jabley at hopcount.ca Tue May 25 09:41:24 2010 From: jabley at hopcount.ca (Joe Abley) Date: Tue, 25 May 2010 16:41:24 +0200 Subject: looking glass In-Reply-To: References: Message-ID: On 2010-05-25, at 16:28, Randy Bush wrote: > so i went to get a looking glass going, and went to install lg > (http://freshmeat.net/projects/lg/) on freebsd 8. There's a script bundled with rancid. I haven't used it; no doubt it's insane in its own way (what isn't?) http://www.shrubbery.net/rancid/man/lg_intro.1.html Joe From cmadams at hiwaay.net Tue May 25 10:18:13 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 25 May 2010 10:18:13 -0500 Subject: looking glass In-Reply-To: References: Message-ID: <20100525151813.GB1058671@hiwaay.net> Once upon a time, Randy Bush said: > it is perl insanity. among other cpan sikness, it wants to build an > entire perl implementation of ssh, with 666 other library modules > included when there is a perfectly fine ssh client on the machine. That would be because the perfectly fine ssh client on the machine does not have a programmatic interface (OpenSSH has no library version and no interest in making a library version), so using it has to fall back to a complicated mess that creates a TTY, creates an SSH process attached to the TTY, and then do Expect-style "send a string, wait for a string" (which is a real PITA for error handling). If you are writing a program to make SSH connections, you are much better off using a different SSH client that has a library, e.g. libssh2, perl's Net::SSH::Perl or Net::SSH2 (which is a perl interface to libssh2), etc. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From martin at airwire.ie Tue May 25 10:37:44 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 25 May 2010 16:37:44 +0100 Subject: Mikrotik BGP Question In-Reply-To: References: <02b001caf8df$62324ea0$2696ebe0$@org> <4BF67B36.3060507@foobar.org> <4BF67F0B.6090207@spectraaccess.com> <4BF7017B.9050501@airwire.ie> <4BF8C97B.3020801@apolix.co.za> Message-ID: <4BFBEEC8.4040600@airwire.ie> On 24/05/10 17:28, Allan Eising wrote: > In some ways, I find the MikroTik RouterOS routing filter syntax a little > more powerful than Cisco's route-maps. As routing filters work the same > way as firewall filters, you can group rules in "chains" and reuse parts > of your filters in other filters by jumping to another chain. This could > be used, for instance, on a peering setup, where you have a number of > rules per peer but also some common filtering for all peers, or to handle > specific and generic filtering for your customers. > > I haven't yet found anything that I missed being able to with filters, at > least with BGP. With other routing protocols, it's another story. It's different thinking for every router platform/os, really. On Cisco/Quagga you can also reuse filtering rules by using peering-groups. At the end of the day, everybody has to find their best medium. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From martin at airwire.ie Tue May 25 10:40:04 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 25 May 2010 16:40:04 +0100 Subject: Quick IP6/BGP question In-Reply-To: References: Message-ID: <4BFBEF54.7040601@airwire.ie> On 24/05/10 19:21, Thomas Magill wrote: >>From the provider side, are most of you who are implementing IP6 > peerings running BGP over IP4 and just using IP6 address families to > exchange routes or doing IP6 peering? Most Internet Exchanges do not allow to mix on the same transport. So IPv4 peering over IPv4 transport, IPv6 peering over IPv6 transport, you can use the same interface though. The separation also helps troubleshooting. So we always try to keep peering and transport the same. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From FScalzo at verisign.com Tue May 25 10:40:57 2010 From: FScalzo at verisign.com (Scalzo, Frank) Date: Tue, 25 May 2010 11:40:57 -0400 Subject: ISP Security BOG - Nanog 49 San Francisco Message-ID: <34CFC0F0FAC11344A64DCE47A5BFB55E29BB99@DUL1WNEXMB09.vcorp.ad.vrsn.com> Hello All, Nanog 49 is just a couple weeks away, and we're looking for agenda topics for the ISP Security BOF. Currently, on the agenda we have Levi Gundert talking about "Investigating botnets and current attribution feasibility", and Duane Wessels giving a DNSSEC update, and we working on getting someone to speak about the China routing incident. If there are any topics you would like to see, or better yet present (slides welcome but not required), please let either me or Danny McPherson know ASAP. Thanks! Frank From martin at airwire.ie Tue May 25 10:43:28 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Tue, 25 May 2010 16:43:28 +0100 Subject: looking glass In-Reply-To: References: Message-ID: <4BFBF020.2090008@airwire.ie> On 25/05/10 15:28, Randy Bush wrote: > so i went to get a looking glass going, and went to install lg > (http://freshmeat.net/projects/lg/) on freebsd 8. > > it is perl insanity. among other cpan sikness, it wants to build an > entire perl implementation of ssh, with 666 other library modules > included when there is a perfectly fine ssh client on the machine. > > is there a decent looking glass package that does not fill my machine > with trash? I used the Multi-Router looking glass and adapted it to my use --> http://freshmeat.net/projects/mrlg4php/ Not sure, how much you fancy or already have PHP knocking about. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From jared at puck.nether.net Tue May 25 13:15:33 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 25 May 2010 14:15:33 -0400 Subject: IPv4 Multicast In-Reply-To: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> Message-ID: On May 21, 2010, at 10:52 AM, Jamie Sobczyk wrote: > On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) > "ip pim rp-address w.x.y.z" I also add on the 'override' term at the end, because any auto-rp messages will be preferred over the static config unless you set override. - Jared From sherwin.ang at gmail.com Wed May 26 03:10:19 2010 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Wed, 26 May 2010 16:10:19 +0800 Subject: Cisco ASR In-Reply-To: References: Message-ID: using ASR1006 here, had 2 automatic reboots last friday which is not a good sign. System image file is "bootflash:/asr1000rp1-adventerprisek9.02.04.02.122-33.XND2.bin" Last reload reason: Critical software exception, check bootflash:crashinfo_RP_01_00_20100521-080244-XXX last thing i always see before boom, May 21 07:27:11.752 XXX: %BGP-6-BIGCHUNK: Big chunk pool request (252) for community. Replenishing with malloc i am starting to feel ASR1000 series' software is not yet ready for primetime, but there are newer software available, will try that first and if it still fails, then i'll cancel all ASR1000 orders. On Tue, May 25, 2010 at 8:05 AM, Elijah Savage III wrote: > On 5/24/10 4:00 PM, "Thomas Magill" wrote: > >> Anyone using ASRs? ?We are demoing one to possibly upgrade our 7206s. >> We are seeing what looks like a memory leak on the RP. ?Cisco is looking >> at it and says they haven't seen it before. ?I am wondering if anyone >> else has run across this. ?With the default 2G of memory the RP only had >> about 1% free memory, and the router was rebooting every 5 days or so >> when the RP ran out. ?We upgraded and now have about 60% free on the RP, >> but I still see the used memory incrementing at a pretty steady rate. >> We are running IOS-XE 12.2(33)XNF. >> >> >> >> The router is currently not even routing traffic, just acting as a BGP >> peer so it has one set of full tables. ?It seems to be a process on the >> Linux OS side that has the leak as the IOS memory commands show >> everything staying pretty static. >> >> >> >> Thomas Magill >> Network Engineer >> >> Office: (858) 909-3777 >> >> Cell: (858) 869-9685 >> mailto:tmagill at providecommerce.com >> >> >> provide-commerce >> 4840 Eastgate Mall >> >> San Diego, CA ?92121 >> >> >> >> ProFlowers ?| redENVELOPE >> ?| Cherry Moon Farms >> ?| Shari's Berries >> >> > I am using a few 1002's and I am not seeing that issue. I will get you the > IOS train later. > > > > From dbelev at gmail.com Wed May 26 03:17:30 2010 From: dbelev at gmail.com (Dean Belev) Date: Wed, 26 May 2010 11:17:30 +0300 Subject: Cisco 7606 RSP720 - no SVI bit/packets counters Message-ID: <4BFCD91A.8000601@gmail.com> Hi all, Another strange Cisco behavior - or may be unknown one. Creating SVI interface with a lot of traffic passing through - nothing suspicious. Until ... /7606#sh int vlan XXX Vlan537 is up, line protocol is up Hardware is EtherSVI, address is MAC (bia 001c.b0b7.6400) Description: 0449-070C001#NetLan_Int Internet address is IP/30 MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, reliability 255/255, txload 1/255, rxload 0/255 Encapsulation ARPA, loopback not set Keepalive not supported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:08:18 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) *30 second input rate 0 bits/sec, 0 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec* L2 Switched: ucast: 25025 pkt, 2426613 bytes - mcast: 0 pkt, 0 bytes L3 in Switched: ucast: 3597038 pkt, 3755053095 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 2000511 pkt, 602156179 bytes mcast: 0 pkt, 0 bytes 3678505 packets input, 3803335802 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 1899084 packets output, 568639522 bytes, 0 underruns 0 output errors, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out/ #### 7606#sh int vlan XXX summary *: interface is up IHQ: pkts in input hold queue IQD: pkts dropped from input queue OHQ: pkts in output hold queue OQD: pkts dropped from output queue RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) TRTL: throttle count Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL -------------------------------------------------------------------------------------------------------- *VlanXXX 0 0 0 0 *0 0 0 0 * 0 ####### All counters but RXBS/RXPS/TXBS/TXPS showing there is a traffic (~400 Mbps). Also visible using MIB values. But the SVI bits/packets not showing it. There are 146 SVIs configured there (we have another Cisco 7609 RSP720 with 393 ones and no such a problem present). We deleted around 10 interfaces trying to release any resources - without result, delete/create the interface - the same. Is there any limit I do not know. I tried to read about any limits of the number of SVIs - no result. Are there any assumptions? Thank you in advance! Best~ /Dean Belev Network Management Team Neterra Ltd. Sofia, Bulgaria Phone: +359 2 974 33 11 Fax: +359 2 975 34 36 Mobile: +359 886 663 123 http://www.neterra.net/ From anderson at cbn.net.id Wed May 26 03:26:18 2010 From: anderson at cbn.net.id (Anderson) Date: Wed, 26 May 2010 15:26:18 +0700 Subject: Cisco ASR In-Reply-To: References: Message-ID: <4BFCDB2A.3080105@cbn.net.id> for a few days ago, i just tested the ASR1006, i tested it for 2 weeks and it never reboot itself. i was using IOS: asr1000rp2-adventerprisek9.BLD_V122_33_XNE_ASR_RLS5_THROTTLE_LATEST_20090926_060026.bin i tested it for bgp propagation and pppoe. i think it enough good. #Anderson Lumbantobing CBN www.cbn.net.id On 5/26/2010 3:10 PM, Sherwin Ang wrote: > using ASR1006 here, had 2 automatic reboots last friday which is not a > good sign. > > System image file is > "bootflash:/asr1000rp1-adventerprisek9.02.04.02.122-33.XND2.bin" > Last reload reason: Critical software exception, check > bootflash:crashinfo_RP_01_00_20100521-080244-XXX > > last thing i always see before boom, > > May 21 07:27:11.752 XXX: %BGP-6-BIGCHUNK: Big chunk pool request (252) > for community. Replenishing with malloc > > i am starting to feel ASR1000 series' software is not yet ready for > primetime, but there are newer software available, will try that first > and if it still fails, then i'll cancel all ASR1000 orders. > > > > > On Tue, May 25, 2010 at 8:05 AM, Elijah Savage III > wrote: > >> On 5/24/10 4:00 PM, "Thomas Magill" wrote: >> >> >>> Anyone using ASRs? We are demoing one to possibly upgrade our 7206s. >>> We are seeing what looks like a memory leak on the RP. Cisco is looking >>> at it and says they haven't seen it before. I am wondering if anyone >>> else has run across this. With the default 2G of memory the RP only had >>> about 1% free memory, and the router was rebooting every 5 days or so >>> when the RP ran out. We upgraded and now have about 60% free on the RP, >>> but I still see the used memory incrementing at a pretty steady rate. >>> We are running IOS-XE 12.2(33)XNF. >>> >>> >>> >>> The router is currently not even routing traffic, just acting as a BGP >>> peer so it has one set of full tables. It seems to be a process on the >>> Linux OS side that has the leak as the IOS memory commands show >>> everything staying pretty static. >>> >>> >>> >>> Thomas Magill >>> Network Engineer >>> >>> Office: (858) 909-3777 >>> >>> Cell: (858) 869-9685 >>> mailto:tmagill at providecommerce.com >>> >>> >>> provide-commerce >>> 4840 Eastgate Mall >>> >>> San Diego, CA 92121 >>> >>> >>> >>> ProFlowers | redENVELOPE >>> | Cherry Moon Farms >>> | Shari's Berries >>> >>> >>> >> I am using a few 1002's and I am not seeing that issue. I will get you the >> IOS train later. >> >> >> >> >> > > From elmi at 4ever.de Wed May 26 03:54:32 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 26 May 2010 10:54:32 +0200 Subject: Cisco ASR In-Reply-To: <4BFCDB2A.3080105@cbn.net.id> References: <4BFCDB2A.3080105@cbn.net.id> Message-ID: <20100526085432.GP40235@ronin.4ever.de> Re guys, just to enforce the statement that the ASR is not really in the Kindergarten anymore: rt uptime is 22 weeks, 1 day, 17 hours, 33 minutes Uptime for this control processor is 22 weeks, 1 day, 17 hours, 34 minutes System returned to ROM by reload at 11:00:33 CET Mon Dec 21 2009 System restarted at 16:16:32 CET Mon Dec 21 2009 System image file is "bootflash:asr1000rp1-advipservicesk9.02.04.02.122-33.XND2.bin" [...] cisco ASR1002 (2RU) processor with 1759125K/6147K bytes of memory. 4 Gigabit Ethernet interfaces 32768K bytes of non-volatile configuration memory. 4194304K bytes of physical memory. 7798783K bytes of eUSB flash at bootflash:. Configuration register is 0x2102 -------------------------------------------------------------------------- Unfortunately, it is also correct that the box crashes with soft-reconfig enabled (it's my bug, actually). Cisco told me they could not reproduce it in the lab, so there's no fix yet. With soft-reconfig disabled, the system works and is stable and fast. CPU is almost zero (2%), with >150 v4 and >40 v6 BGP sessions active. Just to mention it - I'd have preferred an NPE-G2 with some hardware forwarding board. That system simply rocks. But well, I guess this is evolution... Elmar. From rodunn at cisco.com Wed May 26 06:26:46 2010 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 26 May 2010 07:26:46 -0400 Subject: Cisco 7606 RSP720 - no SVI bit/packets counters In-Reply-To: <4BFCD91A.8000601@gmail.com> References: <4BFCD91A.8000601@gmail.com> Message-ID: <4BFD0576.1000404@cisco.com> Dean, Probably good to move this over to cisco-nsp at puck.nether.net and answer the questions below over there. What code is it? Looks like a bug where the IDB counters are not being bumped on the SVI. Is it L3 switching traffic through the SVI or L2 (intra vlan traffic between L2 ports)? Rodney On 5/26/10 4:17 AM, Dean Belev wrote: > Hi all, > > Another strange Cisco behavior - or may be unknown one. > Creating SVI interface with a lot of traffic passing through - nothing > suspicious. > Until ... > > /7606#sh int vlan XXX > Vlan537 is up, line protocol is up > Hardware is EtherSVI, address is MAC (bia 001c.b0b7.6400) > Description: 0449-070C001#NetLan_Int > Internet address is IP/30 > MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec, > reliability 255/255, txload 1/255, rxload 0/255 > Encapsulation ARPA, loopback not set > Keepalive not supported > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:00, output 00:00:00, output hang never > Last clearing of "show interface" counters 00:08:18 > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 > Queueing strategy: fifo > Output queue: 0/40 (size/max) > *30 second input rate 0 bits/sec, 0 packets/sec > 30 second output rate 0 bits/sec, 0 packets/sec* > L2 Switched: ucast: 25025 pkt, 2426613 bytes - mcast: 0 pkt, 0 bytes > L3 in Switched: ucast: 3597038 pkt, 3755053095 bytes - mcast: 0 pkt, 0 > bytes mcast > L3 out Switched: ucast: 2000511 pkt, 602156179 bytes mcast: 0 pkt, 0 bytes > 3678505 packets input, 3803335802 bytes, 0 no buffer > Received 0 broadcasts (0 IP multicasts) > 0 runts, 0 giants, 0 throttles > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored > 1899084 packets output, 568639522 bytes, 0 underruns > 0 output errors, 0 interface resets > 0 unknown protocol drops > 0 output buffer failures, 0 output buffers swapped out/ > #### > 7606#sh int vlan XXX summary > > *: interface is up > IHQ: pkts in input hold queue IQD: pkts dropped from input queue > OHQ: pkts in output hold queue OQD: pkts dropped from output queue > RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec) > TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec) > TRTL: throttle count > > Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL > -------------------------------------------------------------------------------------------------------- > > *VlanXXX 0 0 0 0 *0 0 0 0 * 0 > ####### > > All counters but RXBS/RXPS/TXBS/TXPS showing there is a traffic (~400 > Mbps). > Also visible using MIB values. But the SVI bits/packets not showing it. > There are 146 SVIs configured there (we have another Cisco 7609 RSP720 > with 393 ones and no such a problem present). > We deleted around 10 interfaces trying to release any resources - > without result, delete/create the interface - the same. > > Is there any limit I do not know. I tried to read about any limits of > the number of SVIs - no result. > Are there any assumptions? > > Thank you in advance! > > Best~ > > /Dean Belev > Network Management Team > Neterra Ltd. > Sofia, Bulgaria > Phone: +359 2 974 33 11 > Fax: +359 2 975 34 36 > Mobile: +359 886 663 123 > http://www.neterra.net/ From rodunn at cisco.com Wed May 26 06:32:50 2010 From: rodunn at cisco.com (Rodney Dunn) Date: Wed, 26 May 2010 07:32:50 -0400 Subject: Cisco ASR In-Reply-To: References: Message-ID: <4BFD06E2.5000500@cisco.com> Sherwin, Let's move this specific crash/code question over to cisco-nsp at puck.nether.net. Try the 12.2(33)XNF1 release. If you would like to try and find the matching bug for what you are seeing before you upgrade email me offline with the crashinfo file and the full logs and I'll get someone to take a look at it with you. Thanks, Rodney On 5/26/10 4:10 AM, Sherwin Ang wrote: > using ASR1006 here, had 2 automatic reboots last friday which is not a > good sign. > > System image file is > "bootflash:/asr1000rp1-adventerprisek9.02.04.02.122-33.XND2.bin" > Last reload reason: Critical software exception, check > bootflash:crashinfo_RP_01_00_20100521-080244-XXX > > last thing i always see before boom, > > May 21 07:27:11.752 XXX: %BGP-6-BIGCHUNK: Big chunk pool request (252) > for community. Replenishing with malloc > > i am starting to feel ASR1000 series' software is not yet ready for > primetime, but there are newer software available, will try that first > and if it still fails, then i'll cancel all ASR1000 orders. > > > > > On Tue, May 25, 2010 at 8:05 AM, Elijah Savage III > wrote: >> On 5/24/10 4:00 PM, "Thomas Magill" wrote: >> >>> Anyone using ASRs? We are demoing one to possibly upgrade our 7206s. >>> We are seeing what looks like a memory leak on the RP. Cisco is looking >>> at it and says they haven't seen it before. I am wondering if anyone >>> else has run across this. With the default 2G of memory the RP only had >>> about 1% free memory, and the router was rebooting every 5 days or so >>> when the RP ran out. We upgraded and now have about 60% free on the RP, >>> but I still see the used memory incrementing at a pretty steady rate. >>> We are running IOS-XE 12.2(33)XNF. >>> >>> >>> >>> The router is currently not even routing traffic, just acting as a BGP >>> peer so it has one set of full tables. It seems to be a process on the >>> Linux OS side that has the leak as the IOS memory commands show >>> everything staying pretty static. >>> >>> >>> >>> Thomas Magill >>> Network Engineer >>> >>> Office: (858) 909-3777 >>> >>> Cell: (858) 869-9685 >>> mailto:tmagill at providecommerce.com >>> >>> >>> provide-commerce >>> 4840 Eastgate Mall >>> >>> San Diego, CA 92121 >>> >>> >>> >>> ProFlowers | redENVELOPE >>> | Cherry Moon Farms >>> | Shari's Berries >>> >>> >> I am using a few 1002's and I am not seeing that issue. I will get you the >> IOS train later. >> >> >> >> > From bblackford at gmail.com Wed May 26 07:20:27 2010 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 26 May 2010 05:20:27 -0700 Subject: Cisco ASR In-Reply-To: <4BFD06E2.5000500@cisco.com> References: <4BFD06E2.5000500@cisco.com> Message-ID: I've been running two asr1002's in production now on XND2 and so far (he knocks on wood) they've been stable. Very simple config on my end, OSPF, BGP with full routes, all interfaces are fixed, IOW, no add on SPAs. I can push well over 100k PPS on each interface and the boxes are asleep. My NPE-Gx's would fall over at that rate. All in all, I've been pleased with them. Now, if I could just jail break the ASR;s and load JUNOS.... ;) -b On Wed, May 26, 2010 at 4:32 AM, Rodney Dunn wrote: > Sherwin, > > Let's move this specific crash/code question over to > cisco-nsp at puck.nether.net. > > Try the 12.2(33)XNF1 release. > > If you would like to try and find the matching bug for what you are seeing > before you upgrade email me offline with the crashinfo file and the full > logs and I'll get someone to take a look at it with you. > > Thanks, > Rodney > > > On 5/26/10 4:10 AM, Sherwin Ang wrote: >> >> using ASR1006 here, had 2 automatic reboots last friday which is not a >> good sign. >> >> System image file is >> "bootflash:/asr1000rp1-adventerprisek9.02.04.02.122-33.XND2.bin" >> Last reload reason: Critical software exception, check >> bootflash:crashinfo_RP_01_00_20100521-080244-XXX >> >> last thing i always see before boom, >> >> May 21 07:27:11.752 XXX: %BGP-6-BIGCHUNK: Big chunk pool request (252) >> for community. Replenishing with malloc >> >> i am starting to feel ASR1000 series' software is not yet ready for >> primetime, but there are newer software available, will try that first >> and if it still fails, then i'll cancel all ASR1000 orders. >> >> >> >> >> On Tue, May 25, 2010 at 8:05 AM, Elijah Savage III >> ?wrote: >>> >>> On 5/24/10 4:00 PM, "Thomas Magill" ?wrote: >>> >>>> Anyone using ASRs? ?We are demoing one to possibly upgrade our 7206s. >>>> We are seeing what looks like a memory leak on the RP. ?Cisco is looking >>>> at it and says they haven't seen it before. ?I am wondering if anyone >>>> else has run across this. ?With the default 2G of memory the RP only had >>>> about 1% free memory, and the router was rebooting every 5 days or so >>>> when the RP ran out. ?We upgraded and now have about 60% free on the RP, >>>> but I still see the used memory incrementing at a pretty steady rate. >>>> We are running IOS-XE 12.2(33)XNF. >>>> >>>> >>>> >>>> The router is currently not even routing traffic, just acting as a BGP >>>> peer so it has one set of full tables. ?It seems to be a process on the >>>> Linux OS side that has the leak as the IOS memory commands show >>>> everything staying pretty static. >>>> >>>> >>>> >>>> Thomas Magill >>>> Network Engineer >>>> >>>> Office: (858) 909-3777 >>>> >>>> Cell: (858) 869-9685 >>>> mailto:tmagill at providecommerce.com >>>> >>>> >>>> provide-commerce >>>> 4840 Eastgate Mall >>>> >>>> San Diego, CA ?92121 >>>> >>>> >>>> >>>> ProFlowers ? ?| redENVELOPE >>>> ? ?| Cherry Moon Farms >>>> ? ?| Shari's Berries >>>> >>>> >>> I am using a few 1002's and I am not seeing that issue. I will get you >>> the >>> IOS train later. >>> >>> >>> >>> >> > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From rens at autempspourmoi.be Wed May 26 08:21:28 2010 From: rens at autempspourmoi.be (Rens) Date: Wed, 26 May 2010 15:21:28 +0200 Subject: IPv4 Multicast In-Reply-To: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> Message-ID: <03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> I have all those things you mentioned below. The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2 I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC and below you have the output of my routers & switches at that time: On my RP router I see for show ip mroute: (*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41 (10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 (*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19 (*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03 (*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39 (*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38 (*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40 On my other router I have: (*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54 (10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54 (*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56 (*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53 (*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50 (*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48 (*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:52 On the switch where the RP is connected: Vlan Group Version Port List --------------------------------------------------------- 200 224.0.1.40 v2 Gi2/24 200 224.2.127.254 v2 Gi2/24 200 239.255.255.255v2 Gi2/24 On the switch where the receiver is connected: Vlan Group Type Version Port List ----------------------------------------------------------------------- 200 224.0.1.40 igmp v2 Gi0/24 200 224.2.127.254 igmp v2 Gi0/1, Gi0/24 200 239.195.255.255 igmp v2 Gi0/1, Gi0/24 200 239.255.0.2 igmp v2 Gi0/1, Gi0/24 200 239.255.255.250 igmp v2 Gi0/2, Gi0/24 200 239.255.255.255 igmp v2 Gi0/1, Gi0/24 -----Original Message----- From: Jamie Sobczyk [mailto:lanson9 at cox.net] Sent: vendredi 21 mai 2010 16:52 To: rens at autempspourmoi.be Cc: nanog at nanog.org Subject: RE: IPv4 Multicast Make sure you have "ip multicast-routing" on both routers. On the router interfaces, make sure you have "ip pim sparse-mode" On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) "ip pim rp-address w.x.y.z" Also, make sure that routing is setup on your routers so that your receiver can ping your sender. On your routers you should be able to see the source unicast address and multicast address by typing "show ip mroute" you should see something like this: (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Port-channel15, Forward/Sparse, 7w0d/00:02:59, H (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA Incoming interface: Port-channel15, RPF nbr 10.7.193.138 Outgoing interface list: Port-channel17, Forward/Sparse, 4w5d/00:02:49, H On your switches, with igmp snooping enabled, you should be able to type: "show ip igmp snooping group" and see something like Vlan Group Type Version Port List ----------------------------------------------------------------------- 24 239.192.3.47 igmp v2 Gi1/0/21 That port listed is the port of the requester. -----Original Message----- I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens From everton.marques at gmail.com Wed May 26 08:41:52 2010 From: everton.marques at gmail.com (Everton Marques) Date: Wed, 26 May 2010 10:41:52 -0300 Subject: IPv4 Multicast In-Reply-To: <03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> <03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: Does "show ip mroute count" on the 1841 (RP) display activity on traffic counters? Is the VLC sender directing multicast to the 1841 (RP) thru a default route? Is the VLC sender issuing multicast packets with a high-enough multicast TTL ? Everton On Wed, May 26, 2010 at 10:21 AM, Rens wrote: > I have all those things you mentioned below. > The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2 > I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC > and below you have the output of my routers & switches at that time: > > On my RP router I see for show ip mroute: > > (*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41 > > (10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT > Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 > > (*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19 > > (*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03 > > (*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39 > > (*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10 > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38 > > (*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59 > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40 > > On my other router I have: > > (*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54 > > (10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54 > > (*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56 > > (*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53 > > (*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50 > > (*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48 > > (*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags: SJCL > Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 > Outgoing interface list: > FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:52 > > On the switch where the RP is connected: > > Vlan Group Version Port List > --------------------------------------------------------- > 200 224.0.1.40 v2 Gi2/24 > 200 224.2.127.254 v2 Gi2/24 > 200 239.255.255.255v2 Gi2/24 > > On the switch where the receiver is connected: > > Vlan Group Type Version Port List > ----------------------------------------------------------------------- > 200 224.0.1.40 igmp v2 Gi0/24 > 200 224.2.127.254 igmp v2 Gi0/1, Gi0/24 > 200 239.195.255.255 igmp v2 Gi0/1, Gi0/24 > 200 239.255.0.2 igmp v2 Gi0/1, Gi0/24 > 200 239.255.255.250 igmp v2 Gi0/2, Gi0/24 > 200 239.255.255.255 igmp v2 Gi0/1, Gi0/24 > > -----Original Message----- > From: Jamie Sobczyk [mailto:lanson9 at cox.net] > Sent: vendredi 21 mai 2010 16:52 > To: rens at autempspourmoi.be > Cc: nanog at nanog.org > Subject: RE: IPv4 Multicast > > Make sure you have > "ip multicast-routing" > on both routers. > > On the router interfaces, make sure you have > "ip pim sparse-mode" > > On both routers, make sure you have the same rp address assigned and > that you can ping this ip address from both routers. (I prefer to make > it a loopback interface) > "ip pim rp-address w.x.y.z" > > Also, make sure that routing is setup on your routers so that your > receiver can ping your sender. > > On your routers you should be able to see the source unicast address and > multicast address by typing "show ip mroute" > you should see something like this: > (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S > Incoming interface: Null, RPF nbr 0.0.0.0 > Outgoing interface list: > Port-channel15, Forward/Sparse, 7w0d/00:02:59, H > > (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA > Incoming interface: Port-channel15, RPF nbr 10.7.193.138 > Outgoing interface list: > Port-channel17, Forward/Sparse, 4w5d/00:02:49, H > > On your switches, with igmp snooping enabled, you should be able to > type: > "show ip igmp snooping group" and see something like > Vlan Group Type Version Port List > ----------------------------------------------------------------------- > 24 239.192.3.47 igmp v2 Gi1/0/21 > That port listed is the port of the requester. > > > > > -----Original Message----- > I have setup a lab for this multicast. > > VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender > > The 2 switches only provide L2 access, they have IGMP snooping active > > On both 1841's I have pim parse-mode & sap listen on all interfaces + > configured a static RP, the one closest to the sender. > > With my VLC receiver I can see the channels via SAP, but when I join the > multicast group I don't receive anything. > > Could someone help me to troubleshoot this? > > Thanks in advance, > > Rens > > > > From rens at autempspourmoi.be Wed May 26 09:09:42 2010 From: rens at autempspourmoi.be (Rens) Date: Wed, 26 May 2010 16:09:42 +0200 Subject: IPv4 Multicast In-Reply-To: References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> <03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: Woot! It was the TTL on the VLC sender that was on default, changed it to 10 and now and I have my video. Thanks for your help. _____ From: Everton Marques [mailto:everton.marques at gmail.com] Sent: mercredi 26 mai 2010 15:42 To: Rens Cc: Jamie Sobczyk; nanog at nanog.org Subject: Re: IPv4 Multicast Does "show ip mroute count" on the 1841 (RP) display activity on traffic counters? Is the VLC sender directing multicast to the 1841 (RP) thru a default route? Is the VLC sender issuing multicast packets with a high-enough multicast TTL ? Everton On Wed, May 26, 2010 at 10:21 AM, Rens wrote: I have all those things you mentioned below. The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2 I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC and below you have the output of my routers & switches at that time: On my RP router I see for show ip mroute: (*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41 (10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 (*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19 (*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03 (*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39 (*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38 (*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40 On my other router I have: (*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54 (10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54 (*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56 (*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53 (*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50 (*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48 (*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:52 On the switch where the RP is connected: Vlan Group Version Port List --------------------------------------------------------- 200 224.0.1.40 v2 Gi2/24 200 224.2.127.254 v2 Gi2/24 200 239.255.255.255v2 Gi2/24 On the switch where the receiver is connected: Vlan Group Type Version Port List ----------------------------------------------------------------------- 200 224.0.1.40 igmp v2 Gi0/24 200 224.2.127.254 igmp v2 Gi0/1, Gi0/24 200 239.195.255.255 igmp v2 Gi0/1, Gi0/24 200 239.255.0.2 igmp v2 Gi0/1, Gi0/24 200 239.255.255.250 igmp v2 Gi0/2, Gi0/24 200 239.255.255.255 igmp v2 Gi0/1, Gi0/24 -----Original Message----- From: Jamie Sobczyk [mailto:lanson9 at cox.net] Sent: vendredi 21 mai 2010 16:52 To: rens at autempspourmoi.be Cc: nanog at nanog.org Subject: RE: IPv4 Multicast Make sure you have "ip multicast-routing" on both routers. On the router interfaces, make sure you have "ip pim sparse-mode" On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) "ip pim rp-address w.x.y.z" Also, make sure that routing is setup on your routers so that your receiver can ping your sender. On your routers you should be able to see the source unicast address and multicast address by typing "show ip mroute" you should see something like this: (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Port-channel15, Forward/Sparse, 7w0d/00:02:59, H (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA Incoming interface: Port-channel15, RPF nbr 10.7.193.138 Outgoing interface list: Port-channel17, Forward/Sparse, 4w5d/00:02:49, H On your switches, with igmp snooping enabled, you should be able to type: "show ip igmp snooping group" and see something like Vlan Group Type Version Port List ----------------------------------------------------------------------- 24 239.192.3.47 igmp v2 Gi1/0/21 That port listed is the port of the requester. -----Original Message----- I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens From rens at autempspourmoi.be Wed May 26 09:59:02 2010 From: rens at autempspourmoi.be (Rens) Date: Wed, 26 May 2010 16:59:02 +0200 Subject: IPv4 Multicast In-Reply-To: References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1><03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: One more question: If I would now connect another switch (WS-C3524-XL) between the VLC receiver and the 3560G like this: VLC receiver - 3524XL - 3560G - 1841 - 1841 - 4503 - VLC sender That 3524XL only supports CGMP, what do I need to change on the config to not broadcast this multicast traffic? Do I need to configure the ip cgmp router-only on the 1841 at Receiver? -----Original Message----- From: Rens [mailto:rens at autempspourmoi.be] Sent: mercredi 26 mai 2010 16:10 To: 'Everton Marques' Cc: nanog at nanog.org; 'Jamie Sobczyk' Subject: RE: IPv4 Multicast Woot! It was the TTL on the VLC sender that was on default, changed it to 10 and now and I have my video. Thanks for your help. _____ From: Everton Marques [mailto:everton.marques at gmail.com] Sent: mercredi 26 mai 2010 15:42 To: Rens Cc: Jamie Sobczyk; nanog at nanog.org Subject: Re: IPv4 Multicast Does "show ip mroute count" on the 1841 (RP) display activity on traffic counters? Is the VLC sender directing multicast to the 1841 (RP) thru a default route? Is the VLC sender issuing multicast packets with a high-enough multicast TTL ? Everton On Wed, May 26, 2010 at 10:21 AM, Rens wrote: I have all those things you mentioned below. The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2 I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC and below you have the output of my routers & switches at that time: On my RP router I see for show ip mroute: (*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41 (10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 (*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19 (*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03 (*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39 (*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38 (*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40 On my other router I have: (*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54 (10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54 (*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56 (*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53 (*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50 (*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48 (*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:52 On the switch where the RP is connected: Vlan Group Version Port List --------------------------------------------------------- 200 224.0.1.40 v2 Gi2/24 200 224.2.127.254 v2 Gi2/24 200 239.255.255.255v2 Gi2/24 On the switch where the receiver is connected: Vlan Group Type Version Port List ----------------------------------------------------------------------- 200 224.0.1.40 igmp v2 Gi0/24 200 224.2.127.254 igmp v2 Gi0/1, Gi0/24 200 239.195.255.255 igmp v2 Gi0/1, Gi0/24 200 239.255.0.2 igmp v2 Gi0/1, Gi0/24 200 239.255.255.250 igmp v2 Gi0/2, Gi0/24 200 239.255.255.255 igmp v2 Gi0/1, Gi0/24 -----Original Message----- From: Jamie Sobczyk [mailto:lanson9 at cox.net] Sent: vendredi 21 mai 2010 16:52 To: rens at autempspourmoi.be Cc: nanog at nanog.org Subject: RE: IPv4 Multicast Make sure you have "ip multicast-routing" on both routers. On the router interfaces, make sure you have "ip pim sparse-mode" On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) "ip pim rp-address w.x.y.z" Also, make sure that routing is setup on your routers so that your receiver can ping your sender. On your routers you should be able to see the source unicast address and multicast address by typing "show ip mroute" you should see something like this: (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Port-channel15, Forward/Sparse, 7w0d/00:02:59, H (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA Incoming interface: Port-channel15, RPF nbr 10.7.193.138 Outgoing interface list: Port-channel17, Forward/Sparse, 4w5d/00:02:49, H On your switches, with igmp snooping enabled, you should be able to type: "show ip igmp snooping group" and see something like Vlan Group Type Version Port List ----------------------------------------------------------------------- 24 239.192.3.47 igmp v2 Gi1/0/21 That port listed is the port of the requester. -----Original Message----- I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens From mwalter at 3z.net Wed May 26 10:17:10 2010 From: mwalter at 3z.net (Mike Walter) Date: Wed, 26 May 2010 11:17:10 -0400 Subject: txt.att.net operators In-Reply-To: References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1><03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: We have been struggling to locate someone at AT&T that handles the txt.att.net servers. We have clients in our data center that can no longer send emails to mobile phones via 10digit at txt.att.net. We have contacted AT&T and they say there is no problem on their end. We can ping the server, but simply cannot connect to port 25. We have checked all firewalls of each client. Some ranges of IPs work and others don't. Looking for someone with a clue who can assist. Mike Walter From Brad.Beck at meritain.com Wed May 26 10:27:00 2010 From: Brad.Beck at meritain.com (Brad Beck) Date: Wed, 26 May 2010 11:27:00 -0400 Subject: Latency between GCI Anchorage and VZB in NY Message-ID: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> All, I've been working diligently to improve performance of interactive applications (Citrix, terminal) that are run by users in our office located in Anchorage, and are served by a managed Internet connection provided by GCI. Our applications reside in the Buffalo, NY area. Via MTR, I've seen no or almost-no lost packets, whereas RTT averages around 124ms and at times is as high as 328ms. I'm looking for feedback from others regarding this RTT, hopefully from customers of GCI. 328ms RTT is high as far as I'm concerned, and it seems like this could be controlled a little better. If this is status quo for GCI->VZB/MCI connections, then I'd be interested in that feedback as well. Thanks in advance Note: 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 dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. From Loralee.Wood at circles.com Wed May 26 10:27:23 2010 From: Loralee.Wood at circles.com (Wood, Loralee) Date: Wed, 26 May 2010 11:27:23 -0400 Subject: help finding knowledgable BGP person at Cogeco/old Fibrewired in Canada Message-ID: <8FE782328DC3F94F83C4E70C625D32E1077A7308@BOSEXCHANGE.circles.local> Hello- If anyone from Cogeco is monitoring this list, can you please contact me off list. Our BGP advertisement through you is not propagated to any routers that I can see, and test thru looking glass. Now, all our inbound traffic is traversing our least preferred connection. Apologies for the NANOG distribution, but getting thru your new support system always routes me to another company handling end-user connections. Thank you ------------------------------------------------------------------------------This message contains information that may be confidential and proprietary. Unless you are the intended recipient (or authorized to receive this message for the intended recipient), you may not use, copy, disseminate or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail, and delete the message immediately. ============================================================================== From swmike at swm.pp.se Wed May 26 10:38:57 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 26 May 2010 17:38:57 +0200 (CEST) Subject: Latency between GCI Anchorage and VZB in NY In-Reply-To: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> References: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> Message-ID: On Wed, 26 May 2010, Brad Beck wrote: > I've been working diligently to improve performance of interactive > applications (Citrix, terminal) that are run by users in our office > located in Anchorage, and are served by a managed Internet connection > provided by GCI. Our applications reside in the Buffalo, NY area. I don't know anything about your specific case... but with an 100% optimum light-path you're looking at ~55 ms RTT between ANC-NYC (1ms RTT per 100km of fiber): Of course fiber very seldom goes direct path, so 124ms sounds plausable and could most likely be improved by a little bit by choosing another provider, but would that really substantially improve your interactivity problem? -- Mikael Abrahamsson email: swmike at swm.pp.se From nenolod at systeminplace.net Wed May 26 12:05:19 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Wed, 26 May 2010 12:05:19 -0500 Subject: Latency between GCI Anchorage and VZB in NY In-Reply-To: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> References: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> Message-ID: <1274893519.7848.29.camel@petrie> Hi, On Wed, 2010-05-26 at 11:27 -0400, Brad Beck wrote: > All, > > I've been working diligently to improve performance of interactive > applications (Citrix, terminal) that are run by users in our office > located in Anchorage, and are served by a managed Internet connection > provided by GCI. Our applications reside in the Buffalo, NY area. > The interactivity problem probably has more to do with your Citrix setup. What specs are your Citrix server(s)? I doubt it is virtualized, but just in case, is it? I ask because it sounds more like iowait. Process Explorer (sysinternals) can be useful for listing CPU and I/O hungry applications on the Citrix server(s). > Via MTR, I've seen no or almost-no lost packets, whereas RTT averages > around 124ms and at times is as high as 328ms. > > I'm looking for feedback from others regarding this RTT, hopefully > from customers of GCI. 328ms RTT is high as far as I'm concerned, and > it seems like this could be controlled a little better. Spikes in RTT are likely normal. Your managed internet connection is probably provided over an MPLS private network, which means that it still has to share packet queues with other customers. William From maxsec at gmail.com Wed May 26 11:20:10 2010 From: maxsec at gmail.com (Martin Hepworth) Date: Wed, 26 May 2010 17:20:10 +0100 Subject: Latency between GCI Anchorage and VZB in NY In-Reply-To: References: <330978F411B1E04FA5870873EB0863030EB28161E2@bufamhmail02.ad.meritain.com> Message-ID: On 26 May 2010 16:38, Mikael Abrahamsson wrote: > On Wed, 26 May 2010, Brad Beck wrote: > > I've been working diligently to improve performance of interactive >> applications (Citrix, terminal) that are run by users in our office located >> in Anchorage, and are served by a managed Internet connection provided by >> GCI. Our applications reside in the Buffalo, NY area. >> > > I don't know anything about your specific case... but with an 100% optimum > light-path you're looking at ~55 ms RTT between ANC-NYC (1ms RTT per 100km > of fiber): > > < > http://gc.kls2.com/cgi-bin/gc?PATH=anc-nyc%0D%0A&RANGE=&PATH-COLOR=red&PATH-UNITS=km&PATH-MINIMUM=&SPEED-GROUND=&SPEED-UNITS=kts&RANGE-STYLE=best&RANGE-COLOR=navy&MAP-STYLE= > > > > Of course fiber very seldom goes direct path, so 124ms sounds plausable and > could most likely be improved by a little bit by choosing another provider, > but would that really substantially improve your interactivity problem? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > > Brad I'd be looking at WAN optimisers like Riverbed, Juniper, Silverpeak etc. Even if you move providers and it works better today there's no saying they won't move their paths about and you'll be back on the same boat tomorrow. -- Martin Hepworth Oxford, UK From morrowc.lists at gmail.com Wed May 26 13:11:39 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 26 May 2010 14:11:39 -0400 Subject: txt.att.net operators In-Reply-To: References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1> <03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: On Wed, May 26, 2010 at 11:17 AM, Mike Walter wrote: > We have been struggling to locate someone at AT&T that handles the > txt.att.net servers. ?We have clients in our data center that can no > longer send emails to mobile phones via 10digit at txt.att.net. ?We have > contacted AT&T and they say there is no problem on their end. ?We can > ping the server, but simply cannot connect to port 25. ?We have checked > all firewalls of each client. ?Some ranges of IPs work and others don't. > Looking for someone with a clue who can assist. this is not a guaranteed service, nor does it have an official SLA, and inbound mail/connections from louder speakers are often just dropped, either at the TCP layer, or at the application layer (even after what seems like a completed SMTP conversation.) If you depend upon SMS for things, smtp -> sms gateways at the provider aren't reliable enough. From jabley at hopcount.ca Wed May 26 13:53:41 2010 From: jabley at hopcount.ca (Joe Abley) Date: Wed, 26 May 2010 20:53:41 +0200 Subject: Quick IP6/BGP question In-Reply-To: <4BFBEF54.7040601@airwire.ie> References: <4BFBEF54.7040601@airwire.ie> Message-ID: <5842A1A6-0F40-4CA0-951E-6C7D00A50A61@hopcount.ca> On 2010-05-25, at 17:40, Martin List-Petersen wrote: > On 24/05/10 19:21, Thomas Magill wrote: >>> From the provider side, are most of you who are implementing IP6 >> peerings running BGP over IP4 and just using IP6 address families to >> exchange routes or doing IP6 peering? > > Most Internet Exchanges do not allow to mix on the same transport. So > IPv4 peering over IPv4 transport, IPv6 peering over IPv6 transport, you > can use the same interface though. Most Internet Exchanges don't care what BGP protocol options consenting neighbours decide to use, in my experience. (If they cared, what could they do?) Joe From patrick at ianai.net Wed May 26 13:55:10 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Wed, 26 May 2010 14:55:10 -0400 Subject: Quick IP6/BGP question In-Reply-To: <5842A1A6-0F40-4CA0-951E-6C7D00A50A61@hopcount.ca> References: <4BFBEF54.7040601@airwire.ie> <5842A1A6-0F40-4CA0-951E-6C7D00A50A61@hopcount.ca> Message-ID: <70E25F4E-C517-4ACB-8C39-8C2DF4E3C62F@ianai.net> On May 26, 2010, at 2:53 PM, Joe Abley wrote: > On 2010-05-25, at 17:40, Martin List-Petersen wrote: > >> On 24/05/10 19:21, Thomas Magill wrote: >>>> From the provider side, are most of you who are implementing IP6 >>> peerings running BGP over IP4 and just using IP6 address families to >>> exchange routes or doing IP6 peering? >> >> Most Internet Exchanges do not allow to mix on the same transport. So >> IPv4 peering over IPv4 transport, IPv6 peering over IPv6 transport, you >> can use the same interface though. > > Most Internet Exchanges don't care what BGP protocol options consenting neighbours decide to use, in my experience. (If they cared, what could they do?) Don't care? I think you mean "don't know". The exchange that starts snooping my BGP session to see what I am trading with my peer is the exchange that will lose my business. -- TTFN, patrick From martin at airwire.ie Wed May 26 14:40:33 2010 From: martin at airwire.ie (Martin List-Petersen) Date: Wed, 26 May 2010 20:40:33 +0100 Subject: Quick IP6/BGP question In-Reply-To: <70E25F4E-C517-4ACB-8C39-8C2DF4E3C62F@ianai.net> References: <4BFBEF54.7040601@airwire.ie> <5842A1A6-0F40-4CA0-951E-6C7D00A50A61@hopcount.ca> <70E25F4E-C517-4ACB-8C39-8C2DF4E3C62F@ianai.net> Message-ID: <4BFD7931.5020404@airwire.ie> On 26/05/10 19:55, Patrick W. Gilmore wrote: > On May 26, 2010, at 2:53 PM, Joe Abley wrote: >> On 2010-05-25, at 17:40, Martin List-Petersen wrote: >> >>> On 24/05/10 19:21, Thomas Magill wrote: >>>>> From the provider side, are most of you who are implementing IP6 >>>> peerings running BGP over IP4 and just using IP6 address families to >>>> exchange routes or doing IP6 peering? >>> >>> Most Internet Exchanges do not allow to mix on the same transport. So >>> IPv4 peering over IPv4 transport, IPv6 peering over IPv6 transport, you >>> can use the same interface though. >> >> Most Internet Exchanges don't care what BGP protocol options consenting neighbours decide to use, in my experience. (If they cared, what could they do?) > > Don't care? I think you mean "don't know". > > The exchange that starts snooping my BGP session to see what I am trading with my peer is the exchange that will lose my business. > Ok, let's clarify, what I was on about: I was talking about the peering sessions to the route-servers. What the IXP members do peering wise between themselves is hardly enforced. Kind regards, Martin List-Petersen -- Airwire - Ag Nascadh Pobail an Iarthair http://www.airwire.ie Phone: 091-865 968 From travis+ml-nanog at subspacefield.org Wed May 26 21:47:12 2010 From: travis+ml-nanog at subspacefield.org (travis+ml-nanog at subspacefield.org) Date: Wed, 26 May 2010 19:47:12 -0700 Subject: wanted: WAN connectivity statistics Message-ID: <20100527024712.GL9146@subspacefield.org> Hey all, I was wondering if anyone can direct me to information about WAN connectivity statistics. I'd like to get an idea of the typical frequency and length of outages, distribution (is it gaussian?) and any relevant confounding factors (routing stabilization times, network topology issues, etc.). Thanks! Travis -- A Weapon of Mass Construction My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email john at subspacefield.org to get blacklisted. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From okechukwu at gmail.com Thu May 27 02:30:34 2010 From: okechukwu at gmail.com (Okechukwu) Date: Thu, 27 May 2010 10:30:34 +0300 Subject: tagged.com contact Message-ID: Is there anyone from tagged.com (or parent co.) on the list that can contact me off list to help with a blocked IP range issue? Thanks in advance for any help. ./Okech From dhetzel at gmail.com Thu May 27 06:10:54 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 27 May 2010 07:10:54 -0400 Subject: thoughts? Message-ID: http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 From randy at psg.com Thu May 27 06:38:44 2010 From: randy at psg.com (Randy Bush) Date: Thu, 27 May 2010 13:38:44 +0200 Subject: thoughts? In-Reply-To: References: Message-ID: > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html shocking news! From eric at atlantech.net Thu May 27 06:40:15 2010 From: eric at atlantech.net (Eric Van Tol) Date: Thu, 27 May 2010 07:40:15 -0400 Subject: thoughts? In-Reply-To: References: Message-ID: <2C05E949E19A9146AF7BDF9D44085B863C2BEC44CC@exchange.aoihq.local> > -----Original Message----- > From: Dorn Hetzel [mailto:dhetzel at gmail.com] > Sent: Thursday, May 27, 2010 7:11 AM > To: nanog at nanog.org > Subject: thoughts? > > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 Wow. A news story about the depletion of IP addresses? Shocking, since this is the first I've personally heard about this. I can't believe that this has never once even been brought up on NANOG, cisco-nsp, juniper-nsp, ARIN PPML, ARIN Discuss, or any other telecommunications list to which most of us subscribe. In other news, I understand that the Americans have won their independence from England? Did anyone else know this? -evt * Sorry for the snarkiness, it's just that posts like this ignite flame wars between those unwilling to spend the trivial cost for IPv6 addresses and those who are pushing for IPv6. Instead, it's obviously more cost-effective to spend *hours* reading and writing multiple arguments against IPv6 than it is to just implement it. From bclark at spectraaccess.com Thu May 27 06:42:56 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 27 May 2010 07:42:56 -0400 Subject: thoughts? In-Reply-To: References: Message-ID: <4BFE5AC0.3030503@spectraaccess.com> Not any different then when Bob Metcalf predicted the Internet would melt down in the late 1990's and looked like a fool when it never happened! Even though I don't disagree IP4 address are rapidly getting used up, most of us on this list have the "know how" and tenacity to work through current and future problems. I think a lot of people like to claim the sky is falling sooner rather then later. On 05/27/2010 07:10 AM, Dorn Hetzel wrote: > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 > From jmamodio at gmail.com Thu May 27 06:59:39 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 27 May 2010 06:59:39 -0500 Subject: thoughts? In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863C2BEC44CC@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B863C2BEC44CC@exchange.aoihq.local> Message-ID: > In other news, I understand that the Americans have won their independence from England? ?Did anyone else know this? Is Texas still part of Mexico ? Don't know how to fill the ARIN forms ... -J From Chris.Campbell at nebulassolutions.com Thu May 27 07:02:45 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Thu, 27 May 2010 13:02:45 +0100 Subject: thoughts? In-Reply-To: References: Message-ID: I like the personal title: "Daniel Karrenberg, IP address expert" ________________________________________ From: Dorn Hetzel [dhetzel at gmail.com] Sent: 27 May 2010 12:10 To: nanog at nanog.org Subject: thoughts? http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 From randy at psg.com Thu May 27 07:06:41 2010 From: randy at psg.com (Randy Bush) Date: Thu, 27 May 2010 14:06:41 +0200 Subject: thoughts? In-Reply-To: References: Message-ID: > I like the personal title: > "Daniel Karrenberg, IP address expert" humility is always touching From jwbensley at gmail.com Thu May 27 07:07:52 2010 From: jwbensley at gmail.com (James Bensley) Date: Thu, 27 May 2010 13:07:52 +0100 Subject: thoughts? In-Reply-To: References: Message-ID: On 27 May 2010 12:10, Dorn Hetzel wrote: > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 > Disgraceful scaremongery, CCN should be ashamed. -- Regards, James. http://www.jamesbensley.co.cc/ - There are only 10 kinds of people in the world, those who understand trinary, those who don't understand trinary and those who don't understand trinary. From LarrySheldon at cox.net Thu May 27 07:13:20 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 07:13:20 -0500 Subject: thoughts? In-Reply-To: References: Message-ID: <4BFE61E0.1000207@cox.net> On 5/27/2010 06:10, Dorn Hetzel wrote: > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 I am guessing that once the Obama Administration has taken control of this public utility, all of the problems will be resolved. I for one will be afraid to use it. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu May 27 07:14:32 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 07:14:32 -0500 Subject: thoughts? In-Reply-To: <2C05E949E19A9146AF7BDF9D44085B863C2BEC44CC@exchange.aoihq.local> References: <2C05E949E19A9146AF7BDF9D44085B863C2BEC44CC@exchange.aoihq.local> Message-ID: <4BFE6228.3060807@cox.net> On 5/27/2010 06:40, Eric Van Tol wrote: > In other news, I understand that the Americans have won their > independence ..... Have we? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu May 27 07:16:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 07:16:53 -0500 Subject: thoughts? In-Reply-To: References: Message-ID: <4BFE62B5.4090803@cox.net> On 5/27/2010 07:07, James Bensley wrote: > Disgraceful scaremongery, CCN should be ashamed. CNN too. Does anybody take them seriously? Watch them? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From packetgeek at yahoo.com Thu May 27 07:30:05 2010 From: packetgeek at yahoo.com (Charles Bronson) Date: Thu, 27 May 2010 05:30:05 -0700 (PDT) Subject: thoughts? In-Reply-To: References: Message-ID: <443324.62118.qm@web33403.mail.mud.yahoo.com> > Message: 6 > Date: Thu, 27 May 2010 07:10:54 -0400 > From: Dorn Hetzel > Subject: thoughts? > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 I'm not sure what these "IP Addresses" are that they speak of. But can't we have the government just print more? Charles Bronson From jmamodio at gmail.com Thu May 27 07:34:24 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 27 May 2010 07:34:24 -0500 Subject: thoughts? In-Reply-To: <443324.62118.qm@web33403.mail.mud.yahoo.com> References: <443324.62118.qm@web33403.mail.mud.yahoo.com> Message-ID: > I'm not sure what these "IP Addresses" are that they speak of. But can't we have the government just print more? We have to kick ICANN out of the picture and let the UN and ITU figure what to do ... From LarrySheldon at cox.net Thu May 27 07:34:44 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 07:34:44 -0500 Subject: thoughts? In-Reply-To: <443324.62118.qm@web33403.mail.mud.yahoo.com> References: <443324.62118.qm@web33403.mail.mud.yahoo.com> Message-ID: <4BFE66E4.5000207@cox.net> On 5/27/2010 07:30, Charles Bronson wrote: >> Message: 6 > >> Date: Thu, 27 May 2010 07:10:54 -0400 From: Dorn Hetzel >> Subject: thoughts? To: nanog at nanog.org >> Message-ID: >> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 > >> > I'm not sure what these "IP Addresses" are that they speak of. But > can't we have the government just print more? Naw, they can't do that, silly. They will set up an exchange where you can buy address credits from undeveloped nations. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From dhetzel at gmail.com Thu May 27 08:06:26 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Thu, 27 May 2010 09:06:26 -0400 Subject: thoughts? Message-ID: Perhaps my brevity got the better of me. I should have said something like "any thoughts on whether the migration of this 'news' into the 'mainstream' media will eventually result in some sort of y2k like 'panic' and will that 'panic', if it comes to pass, have operational impact?" From Chris.Campbell at nebulassolutions.com Thu May 27 08:25:21 2010 From: Chris.Campbell at nebulassolutions.com (Chris Campbell) Date: Thu, 27 May 2010 14:25:21 +0100 Subject: thoughts? In-Reply-To: References: Message-ID: If the mainstream can sell more papers/get more viewers then in all likelyhood, yes. ________________________________________ From: Dorn Hetzel [dhetzel at gmail.com] Sent: 27 May 2010 14:06 To: nanog at nanog.org Subject: thoughts? Perhaps my brevity got the better of me. I should have said something like "any thoughts on whether the migration of this 'news' into the 'mainstream' media will eventually result in some sort of y2k like 'panic' and will that 'panic', if it comes to pass, have operational impact?" From Valdis.Kletnieks at vt.edu Thu May 27 08:35:52 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 May 2010 09:35:52 -0400 Subject: thoughts? In-Reply-To: Your message of "Thu, 27 May 2010 09:06:26 EDT." References: Message-ID: <72586.1274967352@localhost> On Thu, 27 May 2010 09:06:26 EDT, Dorn Hetzel said: > Perhaps my brevity got the better of me. I should have said something like > "any thoughts on whether the migration of this 'news' into the 'mainstream' > media will eventually result in some sort of y2k like 'panic' and will that > 'panic', if it comes to pass, have operational impact?" It's going to go down *exactly* like Y2K did - there will be a lot of hype, some sites won't notice because they saw the problem coming a decade ago and did the right thing back then, a lot of sites will try to get moving and find that their schedules are shot because third-party vendors don't have their shit together, a lot of sites are going to have engineers burning the midnight oil in a hurry because they dragged their feet, almost everybody will get hit by unexpected legacy glitches, 5 years from now the general populace will be asking what all the fuss was about, and a decade from now, we'll still be finding little "surprises" in our code base. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bill at herrin.us Thu May 27 09:14:59 2010 From: bill at herrin.us (William Herrin) Date: Thu, 27 May 2010 10:14:59 -0400 Subject: thoughts? In-Reply-To: References: Message-ID: On Thu, May 27, 2010 at 8:07 AM, James Bensley wrote: > On 27 May 2010 12:10, Dorn Hetzel wrote: >> http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 > > Disgraceful scaremongery, CCN should be ashamed. Why should CNN be ashamed? They're quoting a thoroughly bone-headed statement from someone in a position where he should know better. > "The internet as we know it will no longer be able to > grow," [said] Daniel Karrenberg, chief scientist at RIPE NCC -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cburwell at gmail.com Thu May 27 09:21:01 2010 From: cburwell at gmail.com (Chris Burwell) Date: Thu, 27 May 2010 10:21:01 -0400 Subject: FIOS Router Message-ID: I'm doing some research for a group that has a 100Mb FIOS Internet connection at their site. I was surprised to learn that Verizon supplied them with the same Actiontec router that they provided me with on my 10Mb connection at home. Needless to say the Actiontec router is not up to the task of moving all of that traffic (they are using about 80Mb now and sometimes max out their connection). Verizon has been good about replacing the router multiple time when they finally fail, however having to power-cycle the router multiple times per day is not acceptable. What I would like to do is set them up with a router/firewall that is capable of handling their current bandwidth needs as well as their anticipated future growth. My concern is terminating the FIOS connection from the ONT directly to something like a Cisco 3900 (Output from the ONT is CAT5 terminating to RJ-45). I have been searching around the Internet and found one discussion where someone claims to have been able to accomplish just this using a Cisco 871 router. Based on the loose discussions that I have read it seems that the FIOS connection configuration can vary from area to area. I am also aware that we can configure the Actiontec router as a bridge, but I would much rather remove it altogether particularly with the amount of traffic this group is moving. Has anyone been able to accomplish this or something similar with any hardware other then the router Verizon provides? Any insight on Verizon's official stance on this would be helpful. If there is someone from Verizon out there that can contact me about the technical aspects of doing this, that would be much appreciated as well. - Chris From khomyakov.andrey at gmail.com Thu May 27 09:48:11 2010 From: khomyakov.andrey at gmail.com (Andrey Khomyakov) Date: Thu, 27 May 2010 10:48:11 -0400 Subject: FIOS Router In-Reply-To: References: Message-ID: I worked for a small business that purchased 20Mbps FiOS. I threw the actiontech out the day it showed up in the mail. Plugged the copper hand off from the ONT into my 2851 and never looked back. I can't recall what was involved back then in doing so. Verizon clearly stated that they won't support that. In other words, i'd have to hook up the actiontech every time I would need to call them, but that never happened. The link was solid day in and day out. So the only time I ever used it when VZN tech showed up to "make sure everything works" on the first day of service. iirc, I was researching that before I did that and stumbled upon some forums that claimed that if I hook up the actiontech first and then take it out and plug in something else, I'll have issues with VZN caching my MAC address or some bullsh*t like that. But that only seemed to apply in case of if the customer is using a DHCP address. At the time we paid for a block of 5 IPs, so we had static. In short, I never say a single issue, but just to be fair, I only did NAT out for user access. Never hosted a server on it or anything like that. The only thing I recall bugging VZN about is for them to hand me off RJ45 copper, rather than coax, but sounds like you've got RJ45 hand off already, so you should be set. Hope this helps. Andrey On Thu, May 27, 2010 at 10:21 AM, Chris Burwell wrote: > I'm doing some research for a group that has a 100Mb FIOS Internet > connection at their site. I was surprised to learn that Verizon > supplied them with the same Actiontec router that they provided me > with on my 10Mb connection at home. Needless to say the Actiontec > router is not up to the task of moving all of that traffic (they are > using about 80Mb now and sometimes max out their connection). Verizon > has been good about replacing the router multiple time when they > finally fail, however having to power-cycle the router multiple times > per day is not acceptable. > > What I would like to do is set them up with a router/firewall that is > capable of handling their current bandwidth needs as well as their > anticipated future growth. My concern is terminating the FIOS > connection from the ONT directly to something like a Cisco 3900 > (Output from the ONT is CAT5 terminating to RJ-45). I have been > searching around the Internet and found one discussion where someone > claims to have been able to accomplish just this using a Cisco 871 > router. Based on the loose discussions that I have read it seems that > the FIOS connection configuration can vary from area to area. > > I am also aware that we can configure the Actiontec router as a > bridge, but I would much rather remove it altogether particularly with > the amount of traffic this group is moving. > > Has anyone been able to accomplish this or something similar with any > hardware other then the router Verizon provides? Any insight on > Verizon's official stance on this would be helpful. If there is > someone from Verizon out there that can contact me about the technical > aspects of doing this, that would be much appreciated as well. > > - Chris > > -- Andrey Khomyakov [khomyakov.andrey at gmail.com] From dstorandt at teljet.com Thu May 27 10:26:55 2010 From: dstorandt at teljet.com (David Storandt) Date: Thu, 27 May 2010 11:26:55 -0400 Subject: FIOS Router In-Reply-To: References: Message-ID: Would a hardware firewall appliance do the trick? Limited routing features should be sufficient for an access application typical of FIOS. A Cisco ASA 5510 or Juniper SSG5 wouldn't be bad choices. From andrew.wallace at rocketmail.com Thu May 27 10:32:36 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 27 May 2010 08:32:36 -0700 (PDT) Subject: BT strike could affect internet and phone connections Message-ID: <307305.95478.qm@web59615.mail.ac4.yahoo.com> Internet and phone connections across Britain could go into meltdown as BT workers threaten their first national strike for 23 years... ?Many business and residential phonelines could go out of action, and if broadband crashes then thousands and thousands of people will find their internet goes down.? http://www.metro.co.uk/news/828021-threat-of-bt-strike-could-affect-internet-and-phone-connections -- Andrew http://sites.google.com/site/n3td3v/ From dts at senie.com Thu May 27 10:33:50 2010 From: dts at senie.com (Daniel Senie) Date: Thu, 27 May 2010 11:33:50 -0400 Subject: FIOS Router In-Reply-To: References: Message-ID: <4311C3FA-F99E-40C9-8C62-27FC407A40E5@senie.com> I've deployed SonicWALL NSA appliances for use on FiOS with good results. With any firewall, size it to be able to handle the bandwidth and applications involved. On May 27, 2010, at 11:26 AM, David Storandt wrote: > Would a hardware firewall appliance do the trick? Limited routing features > should be sufficient for an access application typical of FIOS. A Cisco ASA > 5510 or Juniper SSG5 wouldn't be bad choices. From gbonser at seven.com Thu May 27 10:46:47 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 27 May 2010 08:46:47 -0700 Subject: thoughts? In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Dorn Hetzel > Sent: Thursday, May 27, 2010 4:11 AM > To: nanog at nanog.org > Subject: thoughts? > > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt= > T2 Somebody should do something! From tim at pelican.org Thu May 27 10:48:09 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 27 May 2010 15:48:09 +0000 (GMT) Subject: BT strike could affect internet and phone connections In-Reply-To: <307305.95478.qm@web59615.mail.ac4.yahoo.com> Message-ID: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> > Internet and phone connections across Britain could go into meltdown > as BT workers threaten their first national strike for 23 years... > > ?Many business and residential phonelines could go out of action, and > if broadband crashes then thousands and thousands of people will find > their internet goes down.? > > http://www.metro.co.uk/news/828021-threat-of-bt-strike-could-affect-internet-and-phone-connections I get a lovely vision from that of a real old-style manual switchboard operator, frantically plugging internet connections together with patch cords as each SYN packet rings a little bell. Clearly BT engineers being on strike will stop broken things from being fixed[0]. I'm very unclear how it will cause things that are working today to suddenly "go into meltdown"... Regards, Tim. [0] As a residential customer, it's arguable how much of a change this is. From jmamodio at gmail.com Thu May 27 10:48:39 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 27 May 2010 10:48:39 -0500 Subject: [Warning Tin Hat required] Cyber War book ... Message-ID: Who read Richard Clarke's latest book "Cyber War" ? Any comments from an operational stand point ? Regards Jorge From r.engehausen at gmail.com Thu May 27 10:58:40 2010 From: r.engehausen at gmail.com (Roy) Date: Thu, 27 May 2010 08:58:40 -0700 Subject: thoughts? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> Message-ID: <4BFE96B0.6010208@gmail.com> On 5/27/2010 8:46 AM, George Bonser wrote: >> -----Original Message----- >> From: Dorn Hetzel >> Sent: Thursday, May 27, 2010 4:11 AM >> To: nanog at nanog.org >> Subject: thoughts? >> >> >> > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt= > >> T2 >> > Somebody should do something! > > > Don't worry. Obama will appoint a bipartisan committee to investigate which will report back in two years. Congress will hold hearings. A bill will be proposed to tax IP addresses. From LarrySheldon at cox.net Thu May 27 11:11:59 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 11:11:59 -0500 Subject: BT strike could affect internet and phone connections In-Reply-To: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> Message-ID: <4BFE99CF.2020602@cox.net> On 5/27/2010 10:48, Tim Franklin wrote: >> Internet and phone connections across Britain could go into meltdown >> as BT workers threaten their first national strike for 23 years... >> >> ???Many business and residential phonelines could go out of action, and >> if broadband crashes then thousands and thousands of people will find >> their internet goes down.??? >> >> http://www.metro.co.uk/news/828021-threat-of-bt-strike-could-affect-internet-and-phone-connections > > I get a lovely vision from that of a real old-style manual switchboard > operator, frantically plugging internet connections together with patch > cords as each SYN packet rings a little bell. > > Clearly BT engineers being on strike will stop broken things from > being fixed[0]. I'm very unclear how it will cause things that are > working today to suddenly "go into meltdown"... In between the cord board and today, then the switchmen or repeatermen went on strike, they pulled down all the patch cords and make-busy plugs to put all the broken equipment back into service. For the first few hours all we did was reshoot troubles that should have been repaired long before but were "too hard". One of the engineers discovered that a lot of stuff in the Master Test Frame was broken, mis-wired, etc, with lots of workarounds in use. We made it all right, including ensuring that the workarounds wouldn't work any more. (Since we left the place with nothing broken, we figured the "managers" would have enough time to train and enforce procedures before customers noticed. Much.) > [0] As a residential customer, it's arguable how much of a change this is. One small step will take out our residential telephone, TV cable, and Internet Access in one swell foop. [I wonder if we had a dry run last night....everything (including the provider's telephone when called from a cell phone) were out for about a 1/2 hour last evening. Eggs and baskets.] -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From peter.hicks at poggs.co.uk Thu May 27 11:14:00 2010 From: peter.hicks at poggs.co.uk (Peter Hicks) Date: Thu, 27 May 2010 17:14:00 +0100 Subject: BT strike could affect internet and phone connections In-Reply-To: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> Message-ID: <4BFE9A48.5050509@poggs.co.uk> On 27/05/2010 16:48, Tim Franklin wrote: > I get a lovely vision from that of a real old-style manual switchboard > operator, frantically plugging internet connections together with > patch cords as each SYN packet rings a little bell. http://www.youtube.com/watch?v=AgqEIp2YmtE Poggs From rsm at fast-serv.com Thu May 27 11:25:16 2010 From: rsm at fast-serv.com (Randy McAnally) Date: Thu, 27 May 2010 12:25:16 -0400 Subject: FIOS Router In-Reply-To: References: Message-ID: <20100527162418.M36244@fast-serv.com> I've been using linux/iptables since day 1. 100Mbps is a walk in the park. ---------- Original Message ----------- From: Chris Burwell To: NANOG Sent: Thu, 27 May 2010 10:21:01 -0400 Subject: FIOS Router > I'm doing some research for a group that has a 100Mb FIOS Internet > connection at their site. I was surprised to learn that Verizon > supplied them with the same Actiontec router that they provided me > with on my 10Mb connection at home. Needless to say the Actiontec > router is not up to the task of moving all of that traffic (they are > using about 80Mb now and sometimes max out their connection). Verizon > has been good about replacing the router multiple time when they > finally fail, however having to power-cycle the router multiple > times per day is not acceptable. > > What I would like to do is set them up with a router/firewall that is > capable of handling their current bandwidth needs as well as their > anticipated future growth. My concern is terminating the FIOS > connection from the ONT directly to something like a Cisco 3900 > (Output from the ONT is CAT5 terminating to RJ-45). I have been > searching around the Internet and found one discussion where someone > claims to have been able to accomplish just this using a Cisco 871 > router. Based on the loose discussions that I have read it seems that > the FIOS connection configuration can vary from area to area. > > I am also aware that we can configure the Actiontec router as a > bridge, but I would much rather remove it altogether particularly > with the amount of traffic this group is moving. > > Has anyone been able to accomplish this or something similar with any > hardware other then the router Verizon provides? Any insight on > Verizon's official stance on this would be helpful. If there is > someone from Verizon out there that can contact me about the > technical aspects of doing this, that would be much appreciated as well. > > - Chris ------- End of Original Message ------- From bruns at 2mbit.com Thu May 27 11:26:01 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 27 May 2010 10:26:01 -0600 Subject: FIOS Router In-Reply-To: References: Message-ID: <4BFE9D19.2000402@2mbit.com> On 5/27/10 8:21 AM, Chris Burwell wrote: > I'm doing some research for a group that has a 100Mb FIOS Internet > connection at their site. I was surprised to learn that Verizon > supplied them with the same Actiontec router that they provided me > with on my 10Mb connection at home. Needless to say the Actiontec > router is not up to the task of moving all of that traffic (they are > using about 80Mb now and sometimes max out their connection). Verizon > has been good about replacing the router multiple time when they > finally fail, however having to power-cycle the router multiple times > per day is not acceptable. Which Actiontec did they give your client? There's like 3 different revisions of the Actiontec MoCA/Ethernet routers, and I know some of the earliest ones have some odd issues. The Actiontec MI424WR is actually a fairly beefy and nice router - but its hampered by two major things in terms of performance: 1) The ethernet hand-off from the ONT to the Actiontec is only 100BT. As we all know, 100mbit != actual 100mbit transfer. I believe MoCA can do better then 100mbit, so you'd have to use the MoCA port to get closer. 2) Jungo OpenRG is a pile, and buggy. My parents have FiOS and their MI424WR won't hand out any IP addresses for DNS other then itself no matter how I configure it. There's a bizarre slowdown when DNS is handled by the MI424WR, that I have yet to figure out. Yay for closed source crap bolted on top of open source stuff to 'replace' non-broken functionality with something that a company can restrict. > > What I would like to do is set them up with a router/firewall that is > capable of handling their current bandwidth needs as well as their > anticipated future growth. My concern is terminating the FIOS > connection from the ONT directly to something like a Cisco 3900 > (Output from the ONT is CAT5 terminating to RJ-45). I have been > searching around the Internet and found one discussion where someone > claims to have been able to accomplish just this using a Cisco 871 > router. Based on the loose discussions that I have read it seems that > the FIOS connection configuration can vary from area to area. > > I am also aware that we can configure the Actiontec router as a > bridge, but I would much rather remove it altogether particularly with > the amount of traffic this group is moving. > > Has anyone been able to accomplish this or something similar with any > hardware other then the router Verizon provides? Any insight on > Verizon's official stance on this would be helpful. If there is > someone from Verizon out there that can contact me about the technical > aspects of doing this, that would be much appreciated as well. Like I said, your going to be hampered by the fact that the ethernet handoff from the ONT is 100BT. Don't forget, there's all this overhead between ethernet, TCP/IP, the ATM network, etc that will even further limit your performance. If you call up and badger Verizon, you should be able to get them to switch between MoCA and ethernet handoffs if needed - I've only personally managed to get them to switch to ethernet once without faking a problem on our end to get a tech to come out and do it. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bruns at 2mbit.com Thu May 27 11:35:57 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 27 May 2010 10:35:57 -0600 Subject: FIOS Router In-Reply-To: <20100527162418.M36244@fast-serv.com> References: <20100527162418.M36244@fast-serv.com> Message-ID: <4BFE9F6D.7090002@2mbit.com> On 5/27/10 10:25 AM, Randy McAnally wrote: > I've been using linux/iptables since day 1. 100Mbps is a walk in the park. See the response I just posted, but in all likely, he's being hampered by the fact the handoff from the ONT is 100BT ethernet and OpenRG (which bolts on top of a Linux OS and 'replaces' the functionality of iptables and such). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From gbonser at seven.com Thu May 27 11:41:01 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 27 May 2010 09:41:01 -0700 Subject: thoughts? In-Reply-To: <4BFE96B0.6010208@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> <4BFE96B0.6010208@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Roy > Sent: Thursday, May 27, 2010 8:59 AM > To: nanog at nanog.org > Subject: Re: thoughts? > > On 5/27/2010 8:46 AM, George Bonser wrote: > >> -----Original Message----- > >> From: Dorn Hetzel > >> Sent: Thursday, May 27, 2010 4:11 AM > >> To: nanog at nanog.org > >> Subject: thoughts? > > Don't worry. Obama will appoint a bipartisan committee to investigate > which will report back in two years. Congress will hold hearings. A > bill will be proposed to tax IP addresses. > And ensure access to IP addresses by the homeless. The are also rumblings about taking portions of 10/8 and making a national IP address preserve where the addresses must remain unused and in their natural state while a monument to 196.168/16 is planned for the lobby of UN Headquarters in New York. It is hoped that the 10/8 IPs in reserve will return to their original state despite the hard use they have experienced over recent decades. But beware, North Korea has been issuing counterfeit ARIN IP addresses and some third world countries have been found to be trafficking in 0/8 which is extremely dangerous. Addresses recently imported by ARIN from APNIC have been found to actually be 127/8 IPs that have simply had the original numbers scraped off and new numbers so skillfully applied that it is difficult to tell them from the original. Be careful out there. Where does one get an IP address degree? From Valdis.Kletnieks at vt.edu Thu May 27 11:56:59 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 May 2010 12:56:59 -0400 Subject: thoughts? In-Reply-To: Your message of "Thu, 27 May 2010 08:46:47 PDT." <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> Message-ID: <6828.1274979419@localhost> On Thu, 27 May 2010 08:46:47 PDT, George Bonser said: > > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html > Somebody should do something! We started deploying IPv6 in testbed mode on our production network in 1997, so we're waiting for the rest of you slackers to get caught up. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jharper at first-american.net Thu May 27 12:00:21 2010 From: jharper at first-american.net (Jeff Harper) Date: Thu, 27 May 2010 12:00:21 -0500 Subject: thoughts? In-Reply-To: <443324.62118.qm@web33403.mail.mud.yahoo.com> References: <443324.62118.qm@web33403.mail.mud.yahoo.com> Message-ID: > -----Original Message----- > From: Charles Bronson [mailto:packetgeek at yahoo.com] > Sent: Thursday, May 27, 2010 7:30 AM > To: nanog at nanog.org > Subject: Re: thoughts? > > I'm not sure what these "IP Addresses" are that they speak of. But > can't we have the government just print more? > > > Charles Bronson Wal-Mart's got a 24 pack on sale for $9.99! From LarrySheldon at cox.net Thu May 27 12:09:38 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 12:09:38 -0500 Subject: thoughts? In-Reply-To: References: <443324.62118.qm@web33403.mail.mud.yahoo.com> Message-ID: <4BFEA752.9020108@cox.net> We are missing the point. The Administration will, as it has so ably done in the Carbon Dioxide emergency, declare the the IP layer a hazardous zone and institute taxes to make the costs skyrocket, thereby reducing usage. [Note to list nannies: I know. I had stopped. I let several beautiful openings go by un-used. But this one had to be addressed. I'll try very hard to resist.] -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From ted at fred.net Thu May 27 12:24:18 2010 From: ted at fred.net (Ted Fischer) Date: Thu, 27 May 2010 13:24:18 -0400 Subject: thoughts? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seve n.com> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> <4BFE96B0.6010208@gmail.com> <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seven.com> Message-ID: <20100527172420.5028310364A@mail-out06.xecu.net> pssst ... Anybody wanna buy a block of 240 ... I got /8s, /16s, /24s, even a /32 if you want just one to "frame" ... or you can have the whole 240/4 for such a deal No guarantees they will work, but they are one of those {soon to be rare} unassigned IPv4 addresses you've heard so much about At 12:41 PM 5/27/2010, you wrote: > > -----Original Message----- > > From: Roy > > Sent: Thursday, May 27, 2010 8:59 AM > > To: nanog at nanog.org > > Subject: Re: thoughts? > > > > On 5/27/2010 8:46 AM, George Bonser wrote: > > >> -----Original Message----- > > >> From: Dorn Hetzel > > >> Sent: Thursday, May 27, 2010 4:11 AM > > >> To: nanog at nanog.org > > >> Subject: thoughts? > > > > Don't worry. Obama will appoint a bipartisan committee to investigate > > which will report back in two years. Congress will hold hearings. A > > bill will be proposed to tax IP addresses. > > > >And ensure access to IP addresses by the homeless. The are also >rumblings about taking portions of 10/8 and making a national IP address >preserve where the addresses must remain unused and in their natural >state while a monument to 196.168/16 is planned for the lobby of UN >Headquarters in New York. It is hoped that the 10/8 IPs in reserve will >return to their original state despite the hard use they have >experienced over recent decades. But beware, North Korea has been >issuing counterfeit ARIN IP addresses and some third world countries >have been found to be trafficking in 0/8 which is extremely dangerous. >Addresses recently imported by ARIN from APNIC have been found to >actually be 127/8 IPs that have simply had the original numbers scraped >off and new numbers so skillfully applied that it is difficult to tell >them from the original. Be careful out there. > >Where does one get an IP address degree? From Bryan at bryanfields.net Thu May 27 12:34:38 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 27 May 2010 13:34:38 -0400 Subject: thoughts? In-Reply-To: <4BFEA752.9020108@cox.net> References: <443324.62118.qm@web33403.mail.mud.yahoo.com> <4BFEA752.9020108@cox.net> Message-ID: <4BFEAD2E.2030809@bryanfields.net> On 5/27/2010 13:09, Larry Sheldon wrote: > We are missing the point. > > The Administration will, as it has so ably done in the Carbon Dioxide > emergency, declare the the IP layer a hazardous zone and institute taxes > to make the costs skyrocket, thereby reducing usage. If some one from the government comes to take your IP address from you, shoot them in the head. Paraphrasing G. Gordon Liddy :) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From andrew.wallace at rocketmail.com Thu May 27 12:42:37 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 27 May 2010 10:42:37 -0700 (PDT) Subject: BT strike could affect internet and phone connections In-Reply-To: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> Message-ID: <840456.96100.qm@web59602.mail.ac4.yahoo.com> On Thu, May 27, 2010 at 4:48 PM, Tim Franklin wrote: >> Internet and phone connections across Britain could go into meltdown >> as BT workers threaten their first national strike for 23 years... >> >> ?Many business and residential phonelines could go out of action, and >> if broadband crashes then thousands and thousands of people will find >> their internet goes down.? >> >> http://www.metro.co.uk/news/828021-threat-of-bt-strike-could-affect-internet-and-phone-connections > > I get a lovely vision from that of a real old-style manual switchboard > operator, frantically plugging internet connections together with patch > cords as each SYN packet rings a little bell. > > Clearly BT engineers being on strike will stop broken things from > being fixed[0]. I'm very unclear how it will cause things that are > working today to suddenly "go into meltdown"... > Look at it from an attackers point of view. If you're thinking about carrying out an electronic jihad of some kind when is the best time? A normal working day or during an engineers strike that only happens once every 23 years? -- Andrew http://sites.google.com/site/n3td3v/ From cburwell at gmail.com Thu May 27 12:46:30 2010 From: cburwell at gmail.com (Chris Burwell) Date: Thu, 27 May 2010 13:46:30 -0400 Subject: FIOS Router In-Reply-To: <20100527173848.GA62903@latency.net> References: <20100527173848.GA62903@latency.net> Message-ID: Thanks for the information everyone! Most I will spec out several solutions for them, but the preferred solution will probably be a firewall just because most appliances will do more routing then they would need. I was looking at the Sonicwall NS series because it looks like they provide good throughput for the price. Brielle: Thank you for the info about the Ethernet port on the ONT. I will make sure to relay that information. At this point I believe they would want to make their service stable and worry about maximum bandwidth once that is done. The router they have is the MI424WR, which is what I have for my home service. I don't have many complaints about it at home, however it's clear that it's not up to the task in the case of my client. They have had the router replaced by Verizon 4 times in about as many months. - Chris From bruns at 2mbit.com Thu May 27 12:54:32 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 27 May 2010 11:54:32 -0600 Subject: FIOS Router In-Reply-To: References: <20100527173848.GA62903@latency.net> Message-ID: <4BFEB1D8.5020606@2mbit.com> On 5/27/10 11:46 AM, Chris Burwell wrote: > Brielle: Thank you for the info about the Ethernet port on the ONT. I > will make sure to relay that information. At this point I believe they > would want to make their service stable and worry about maximum > bandwidth once that is done. > I was actually corrected off list that its possible to get 100mbit over 100Base-TX, but its entirely possible that cheapie cards and such may not be able to hit that high of performance. > The router they have is the MI424WR, which is what I have for my home > service. I don't have many complaints about it at home, however it's > clear that it's not up to the task in the case of my client. They have > had the router replaced by Verizon 4 times in about as many months. > I believe its possible to install DD-WRT on the MI424WR. http://dd-wrt.com/wiki/index.php/MI424WR You might have luck with running pure Linux on that rather then Jungo's commercial linux abomination that Verizon uses. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From tim2.sanderson at gmail.com Thu May 27 13:03:13 2010 From: tim2.sanderson at gmail.com (Tim Sanderson) Date: Thu, 27 May 2010 14:03:13 -0400 Subject: AT&T U-verse Message-ID: <045401cafdc6$e081b7f0$a18527d0$@gmail.com> What are people doing for business U-verse connections? AT&T installs a gateway device that doesn't necessarily allow the business to use their own router/firewall. The AT&T gateway is not just a VDSL modem. At least I have not been able to get it to work. The web interface seems to suggest that a pass-through situation can be configured and I have following al the directions but it doesn't appear to work. Has anyone worked with business U-verse and been able to park a cisco router between the private LAN and AT&T gateway? Tim From david.reader at zeninternet.co.uk Thu May 27 13:16:44 2010 From: david.reader at zeninternet.co.uk (David Reader) Date: Thu, 27 May 2010 19:16:44 +0100 Subject: BT strike could affect internet and phone connections In-Reply-To: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> References: <307305.95478.qm@web59615.mail.ac4.yahoo.com> <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> Message-ID: <20100527191644.b0405ef2.david.reader@zeninternet.co.uk> On Thu, 27 May 2010 15:48:09 +0000 (GMT) Tim Franklin wrote: > Clearly BT engineers being on strike will stop broken things from > being fixed[0]. I'm very unclear how it will cause things that are > working today to suddenly "go into meltdown"... Quite, and.. it's not unheard-of for reliability of services to actually improve when no-one's mucking about with them! d. From Bryan at bryanfields.net Thu May 27 13:22:18 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Thu, 27 May 2010 14:22:18 -0400 Subject: BT strike could affect internet and phone connections In-Reply-To: <20100527191644.b0405ef2.david.reader@zeninternet.co.uk> References: <307305.95478.qm@web59615.mail.ac4.yahoo.com> <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <20100527191644.b0405ef2.david.reader@zeninternet.co.uk> Message-ID: <4BFEB85A.6060909@bryanfields.net> On 5/27/2010 14:16, David Reader wrote: > On Thu, 27 May 2010 15:48:09 +0000 (GMT) > Tim Franklin wrote: > >> Clearly BT engineers being on strike will stop broken things from >> being fixed[0]. I'm very unclear how it will cause things that are >> working today to suddenly "go into meltdown"... > > Quite, and.. it's not unheard-of for reliability of services to > actually improve when no-one's mucking about with them! however during a strike, the strikers will be destroying their companies network. Think about a firebomb down a man hole and no one to fix it, bullet holes through switch gear and the like. Unions fight dirty. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From Valdis.Kletnieks at vt.edu Thu May 27 13:23:06 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 May 2010 14:23:06 -0400 Subject: BT strike could affect internet and phone connections In-Reply-To: Your message of "Thu, 27 May 2010 10:42:37 PDT." <840456.96100.qm@web59602.mail.ac4.yahoo.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> Message-ID: <11023.1274984586@localhost> On Thu, 27 May 2010 10:42:37 PDT, "andrew.wallace" said: > Look at it from an attackers point of view. If you're thinking about carrying > out an electronic jihad of some kind when is the best time? A normal working > day or during an engineers strike that only happens once every 23 years? A co-worker of mine was asked by somebody high in the US government in late 1999 if he was worried about attackers trying to pull something on New Year's. Randy thought for a moment, and said "Hell no. There's going to be 3 zillion engineers and programmers watching for any minor hiccup that day. The time to pull something would be late January, when everybody's relaxed and stopped worrying". The room got very quiet... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dmburgess at linktechs.net Thu May 27 13:26:51 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 27 May 2010 13:26:51 -0500 Subject: FIOS Router References: <20100527173848.GA62903@latency.net> <4BFEB1D8.5020606@2mbit.com> Message-ID: <91522911795E174F97E7EF8B792A1031228ED7@ltiserver.LTI.local> While I replied of list, RouterOS (Mikrotik) can do 100meg in many of their inexpensive devices. WE have a fiber loop here running our office that we can pull 70+ meg and its a 200 buck unit! We actually make a device called a PowerRouter, these are x86 versions, vs 680mhz mips processors. These can route at GigE speeds. Not to mention you get all of the firewalling, traffic management, QoS, etc with it as well. Just another option. ----------------------------------------------------------- Dennis Burgess, CCNA, Mikrotik Certified Trainer, MTCNA, MTCRE, MTCWE, MTCTCE, MTCUME Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Brielle Bruns [mailto:bruns at 2mbit.com] Sent: Thursday, May 27, 2010 12:55 PM To: nanog at nanog.org Subject: Re: FIOS Router On 5/27/10 11:46 AM, Chris Burwell wrote: > Brielle: Thank you for the info about the Ethernet port on the ONT. I > will make sure to relay that information. At this point I believe they > would want to make their service stable and worry about maximum > bandwidth once that is done. > I was actually corrected off list that its possible to get 100mbit over 100Base-TX, but its entirely possible that cheapie cards and such may not be able to hit that high of performance. > The router they have is the MI424WR, which is what I have for my home > service. I don't have many complaints about it at home, however it's > clear that it's not up to the task in the case of my client. They have > had the router replaced by Verizon 4 times in about as many months. > I believe its possible to install DD-WRT on the MI424WR. http://dd-wrt.com/wiki/index.php/MI424WR You might have luck with running pure Linux on that rather then Jungo's commercial linux abomination that Verizon uses. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Thu May 27 13:28:17 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 27 May 2010 14:28:17 -0400 Subject: AT&T U-verse In-Reply-To: <045401cafdc6$e081b7f0$a18527d0$@gmail.com> References: <045401cafdc6$e081b7f0$a18527d0$@gmail.com> Message-ID: <30C5AF3C-8128-46BE-8210-B347747FFCFD@puck.nether.net> On May 27, 2010, at 2:03 PM, Tim Sanderson wrote: > What are people doing for business U-verse connections? AT&T installs a > gateway device that doesn't necessarily allow the business to use their own > router/firewall. The AT&T gateway is not just a VDSL modem. At least I have > not been able to get it to work. The web interface seems to suggest that a > pass-through situation can be configured and I have following al the > directions but it doesn't appear to work. Has anyone worked with business > U-verse and been able to park a cisco router between the private LAN and > AT&T gateway? I've had various issues with end-users on these solutions, and the most common issue is that you can not entirely disable the firewall/smart packet features, and there are things like the "Misc" in the firewall config. They also appear to try to do some application specific handling of things like sip-alg on udp/5060, but it doesn't quite work right. If there are ways to COMPLETELY disable this stuff, I'd love to hear about it as it'd be useful for a few people I know, including a small business that is constantly fighting/fiddling with the box and would prefer some dumb DSL device for their pool of IPs. This is another place where Comcast seems to "get it right(tm)" vs SWBell, er ameritech, er SBC, er ATT. From mmzinyi at yahoo.com Thu May 27 13:47:06 2010 From: mmzinyi at yahoo.com (jacob miller) Date: Thu, 27 May 2010 11:47:06 -0700 (PDT) Subject: Hung Telnet Sessions on Sco Unix Message-ID: <268255.45440.qm@web39505.mail.mud.yahoo.com> Am running an application on Sco Unix but am having the following problem. Application is hunging sporadically. Am accessing the application via telnet.Have changed the link thinking that this could be the problem but to no avail. Have increased keep alives on the routers and increased capacity on them. service tcp-keepalives-in and out.But this has not sorted the problem out. Any thing that i need to be looking at or am missing Thanks From joesox at gmail.com Thu May 27 13:58:04 2010 From: joesox at gmail.com (JoeSox) Date: Thu, 27 May 2010 11:58:04 -0700 Subject: Guam Message-ID: I am trying to gain some knowledge about setting up a T1 network in Guam. I am in Washington State so I am not sure who to contact over there. We normally deal with QWest but they do not provide service there. I see a GTA Teleguam but I am not sure the wisest place to start. If anyone has any experience, POCs, or knowledge to pass along to this Guam noob I would really appreciate it. -- Thanks, Joe From bfeeny at mac.com Thu May 27 14:01:19 2010 From: bfeeny at mac.com (Brian Feeny) Date: Thu, 27 May 2010 15:01:19 -0400 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <268255.45440.qm@web39505.mail.mud.yahoo.com> References: <268255.45440.qm@web39505.mail.mud.yahoo.com> Message-ID: <8385EB62-3797-4295-B3C6-02641FD61B8F@mac.com> I don't think this is the appropriate list for asking a question about a problem with telnet to a sco box. I don't understand why you think "service tcp-keepalives-in/out" has any effect on traffic to and from a host to a SCO box. This command is for traffic to and from the router itself. Look for errors on the link, double check all routing, in both directions, check masks, gateways, things like that. Fiddling with knobs on the router is likely not the fix, especially the ones you are messing with. Brian On May 27, 2010, at 2:47 PM, jacob miller wrote: > Am running an application on Sco Unix but am having the following problem. > > Application is hunging sporadically. > > Am accessing the application via telnet.Have changed the link thinking that this could be the problem but to no avail. > > Have increased keep alives on the routers and increased capacity on them. > service tcp-keepalives-in and out.But this has not sorted the problem out. > > > Any thing that i need to be looking at or am missing > > Thanks > > > > From trelane at trelane.net Thu May 27 14:14:26 2010 From: trelane at trelane.net (Andrew D Kirch) Date: Thu, 27 May 2010 15:14:26 -0400 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <8385EB62-3797-4295-B3C6-02641FD61B8F@mac.com> References: <268255.45440.qm@web39505.mail.mud.yahoo.com> <8385EB62-3797-4295-B3C6-02641FD61B8F@mac.com> Message-ID: <4BFEC492.6040601@trelane.net> I'm not sure why anyone is running SCO Unix. Call their technical support, enjoy the crickets. Andrew On 05/27/2010 03:01 PM, Brian Feeny wrote: > I don't think this is the appropriate list for asking a question about a problem with telnet to a sco box. I don't understand why you think "service tcp-keepalives-in/out" has any effect on traffic to and from a host to a SCO box. This command is for traffic to and from the router itself. > > Look for errors on the link, double check all routing, in both directions, check masks, gateways, things like that. Fiddling with knobs on the router is likely not the fix, especially the ones you are messing with. > > Brian > > On May 27, 2010, at 2:47 PM, jacob miller wrote: > > >> Am running an application on Sco Unix but am having the following problem. >> >> Application is hunging sporadically. >> >> Am accessing the application via telnet.Have changed the link thinking that this could be the problem but to no avail. >> >> Have increased keep alives on the routers and increased capacity on them. >> service tcp-keepalives-in and out.But this has not sorted the problem out. >> >> >> Any thing that i need to be looking at or am missing >> >> Thanks >> >> >> >> >> > > > From tony at lava.net Thu May 27 14:16:35 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 27 May 2010 09:16:35 -1000 (HST) Subject: .mil dns problems? Message-ID: Anyone seeing trouble resolving some .mil hostnames consistently today? Specifically those below: www.dco.dod.mil www.my.af.mil Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jwbensley at gmail.com Thu May 27 14:20:18 2010 From: jwbensley at gmail.com (James Bensley) Date: Thu, 27 May 2010 20:20:18 +0100 Subject: .mil dns problems? In-Reply-To: References: Message-ID: https://www.my.af.mil/ = SSL Cert not verified, but otherwise working fine. http://www.dco.dod.mil/ is not working. -- Regards, James. http://www.jamesbensley.co.cc/ - There are only 10 kinds of people in the world, those who understand trinary, those who don't understand trinary and those who don't understand trinary. From nanog at enger.us Thu May 27 14:22:39 2010 From: nanog at enger.us (Robert Enger - NANOG) Date: Thu, 27 May 2010 12:22:39 -0700 Subject: FIOS Router In-Reply-To: <4BFE9D19.2000402@2mbit.com> References: <4BFE9D19.2000402@2mbit.com> Message-ID: <4BFEC67F.4090309@enger.us> Sadly, I have only the 50/20 FiOS service. I would love to get 100/100. Where do I sign up. My initial installation used MoCA. It would not reliably deliver 50Mbps on tcp-based download tests. (coax network brand new, very small). Test results were erratic, typically between 30 and 40Mbps. Technician told me to put up with it (not making this up). I fought with VZ and had them re-provision me to 100BaseT connection on the ONT. I immediately observed reliable, consistent download speeds at 51.8Mbps. (Since dropped to 49.2 after their speed re-provisioning a few months ago.) MoCA is a half-duplex channel with sophisticated MAC (e.g. BW reservations and so forth). The MoCA diag displays show that the STBs see each other and the Actiontech at speeds over 220Mbps. I doubt the issue is inadequate phy connection. I assume the interplay between the MoCA MAC and TCP yields poor performance. But, I did not research this. I had them take my Internet off the MoCA path and it has worked fine since. So, how I go about getting 100/100? From jabley at hopcount.ca Thu May 27 14:26:27 2010 From: jabley at hopcount.ca (Joe Abley) Date: Thu, 27 May 2010 21:26:27 +0200 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <268255.45440.qm@web39505.mail.mud.yahoo.com> References: <268255.45440.qm@web39505.mail.mud.yahoo.com> Message-ID: <9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> On 2010-05-27, at 20:47, jacob miller wrote: > Am running an application on Sco Unix but am having the following problem. > > Application is hunging sporadically. That seems consistent with my memory of SCO Unix. From bortzmeyer at nic.fr Thu May 27 14:27:59 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 27 May 2010 21:27:59 +0200 Subject: .mil dns problems? In-Reply-To: References: Message-ID: <20100527192759.GA1992@sources.org> On Thu, May 27, 2010 at 09:16:35AM -1000, Antonio Querubin wrote a message of 10 lines which said: > Anyone seeing trouble resolving some .mil hostnames consistently today? Yes, most DNS servers of .MIL are unresponsive: % check_soa mil There was no response from EUR2.NIPR.mil CON2.NIPR.mil has serial number 2010052701 There was no response from PAC1.NIPR.mil There was no response from PAC2.NIPR.mil There was no response from CON1.NIPR.mil There was no response from EUR1.NIPR.mil % check_soa mil There was no response from EUR1.NIPR.mil There was no response from CON2.NIPR.mil There was no response from CON1.NIPR.mil There was no response from EUR2.NIPR.mil There was no response from PAC2.NIPR.mil There was no response from PAC1.NIPR.mil DoS attack, may be? From john-nanog at johnpeach.com Thu May 27 14:31:23 2010 From: john-nanog at johnpeach.com (John Peach) Date: Thu, 27 May 2010 15:31:23 -0400 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> References: <268255.45440.qm@web39505.mail.mud.yahoo.com> <9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> Message-ID: <20100527153123.312fbdfa@godzilla> On Thu, 27 May 2010 21:26:27 +0200 Joe Abley wrote: > > On 2010-05-27, at 20:47, jacob miller wrote: > > > Am running an application on Sco Unix but am having the following problem. > > > > Application is hunging sporadically. > > That seems consistent with my memory of SCO Unix. > > Did you remember to get the licence for the TCP/IP stack? From kyled at noelcomm.com Thu May 27 14:36:41 2010 From: kyled at noelcomm.com (Kyle Duren) Date: Thu, 27 May 2010 12:36:41 -0700 Subject: MRLG Missing? Message-ID: <4BFEC9C9.5070204@noelcomm.com> I know we just had a small discussion about this, looking glass stuff and such, but I had a copy of MRLG (the one from John Fraizer - OP-SEC.US) a while ago about I cannot seem to find the tarball anymore. The op-sec site appears to be dead, and so is a mirror site someone else put online a while ago (https://arpa.com/code/mrlg-5.4.1.tgz). Does anyone know what happened to John and his version of MRLG, I found it to be one of the best/most comprehensive looking glass setups available. thanks, Kyle From cburwell at gmail.com Thu May 27 14:40:29 2010 From: cburwell at gmail.com (Chris Burwell) Date: Thu, 27 May 2010 15:40:29 -0400 Subject: FIOS Router In-Reply-To: <4BFEC67F.4090309@enger.us> References: <4BFE9D19.2000402@2mbit.com> <4BFEC67F.4090309@enger.us> Message-ID: To be honest, I'm not sure how they got the 100Mb service. The fastest service I have seen on the FiOS website is the 50/20. I can only assume that it varies by region. - Chris On Thu, May 27, 2010 at 3:22 PM, Robert Enger - NANOG wrote: > ?Sadly, I have only the 50/20 FiOS service. ?I would love to get 100/100. > ?Where do I sign up. > > My initial installation used MoCA. ?It would not reliably deliver 50Mbps on > tcp-based download tests. ?(coax network brand new, very small). ?Test > results were erratic, typically between 30 and 40Mbps. ?Technician told me > to put up with it (not making this up). > > I fought with VZ and had them re-provision me to 100BaseT connection on the > ONT. ?I immediately observed reliable, consistent download speeds at > 51.8Mbps. ?(Since dropped to 49.2 after their speed re-provisioning a few > months ago.) > > MoCA is a half-duplex channel with sophisticated MAC (e.g. BW reservations > and so forth). ? The MoCA diag displays show that the STBs see each other > and the Actiontech at speeds over 220Mbps. ?I doubt the issue is inadequate > phy connection. ?I assume the interplay between the MoCA MAC and TCP yields > poor performance. ?But, I did not research this. ?I had them take my > Internet off the MoCA path and it has worked fine since. > > So, how I go about getting 100/100? > > > > From fw at deneb.enyo.de Thu May 27 14:55:10 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 27 May 2010 21:55:10 +0200 Subject: .mil dns problems? In-Reply-To: <20100527192759.GA1992@sources.org> (Stephane Bortzmeyer's message of "Thu, 27 May 2010 21:27:59 +0200") References: <20100527192759.GA1992@sources.org> Message-ID: <87r5kxxgpt.fsf@mid.deneb.enyo.de> * Stephane Bortzmeyer: > DoS attack, may be? Looks more like a routing issue. Looks like the .MIL operators put all their eggs into one basket. 8-( From MatlockK at exempla.org Thu May 27 14:53:26 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Thu, 27 May 2010 13:53:26 -0600 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <20100527153123.312fbdfa@godzilla> References: <268255.45440.qm@web39505.mail.mud.yahoo.com><9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> <20100527153123.312fbdfa@godzilla> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2B2C@LMC-MAIL2.exempla.org> As well as the "don't sue me because I want to stop using them" license? Ask Autozone about that one :) Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: John Peach [mailto:john-nanog at johnpeach.com] Sent: Thursday, May 27, 2010 1:31 PM To: nanog at nanog.org Subject: Re: Hung Telnet Sessions on Sco Unix On Thu, 27 May 2010 21:26:27 +0200 Joe Abley wrote: > > On 2010-05-27, at 20:47, jacob miller wrote: > > > Am running an application on Sco Unix but am having the following problem. > > > > Application is hunging sporadically. > > That seems consistent with my memory of SCO Unix. > > Did you remember to get the licence for the TCP/IP stack? From andrew.wallace at rocketmail.com Thu May 27 14:57:42 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 27 May 2010 12:57:42 -0700 (PDT) Subject: BT strike could affect internet and phone connections In-Reply-To: <11023.1274984586@localhost> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> Message-ID: <767009.81922.qm@web59605.mail.ac4.yahoo.com> On Thu, May 27, 2010 at 7:23 PM, wrote: > On Thu, 27 May 2010 10:42:37 PDT, "andrew.wallace" said: >> Look at it from an attackers point of view. If you're thinking about carrying >> out an electronic jihad of some kind when is the best time? A normal working >> day or during an engineers strike that only happens once every 23 years? > > A co-worker of mine was asked by somebody high in the US government in late > 1999 if he was worried about attackers trying to pull something on New Year's. > Randy thought for a moment, and said "Hell no. There's going to be 3 zillion > engineers and programmers watching for any minor hiccup that day. The time to > pull something would be late January, when everybody's relaxed and stopped > worrying". > > The room got very quiet... :) > > Are you *still* using the same threat models as you were 11 years ago? -- Andrew http://sites.google.com/site/n3td3v/ From morrowc.lists at gmail.com Thu May 27 15:24:21 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 27 May 2010 16:24:21 -0400 Subject: FIOS Router In-Reply-To: References: <4BFE9D19.2000402@2mbit.com> <4BFEC67F.4090309@enger.us> Message-ID: On Thu, May 27, 2010 at 3:40 PM, Chris Burwell wrote: > To be honest, I'm not sure how they got the 100Mb service. The fastest > service I have seen on the FiOS website is the 50/20. I can only > assume that it varies by region. It does, or it used to... rumors were DFW was a good place to get the 100/100 service. As to the actiontec, just ditch it, if you have cat-5 from the ONT you've been presented with an ethernet LAN, plug that into any old switch and feed your end systems off that (presuming you have more than 1 ip address and static addressing). If you NEED a router/firewall, then get an ssg5 or use a little linux-alike box. -Chris >On Thu, May 27, 2010 at 3:22 PM, Robert Enger - NANOG wrote: >> ?Sadly, I have only the 50/20 FiOS service. ?I would love to get 100/100. >> ?Where do I sign up. >> >> My initial installation used MoCA. ?It would not reliably deliver 50Mbps on >> tcp-based download tests. ?(coax network brand new, very small). ?Test >> results were erratic, typically between 30 and 40Mbps. ?Technician told me >> to put up with it (not making this up). >> >> I fought with VZ and had them re-provision me to 100BaseT connection on the >> ONT. ?I immediately observed reliable, consistent download speeds at >> 51.8Mbps. ?(Since dropped to 49.2 after their speed re-provisioning a few >> months ago.) >> >> MoCA is a half-duplex channel with sophisticated MAC (e.g. BW reservations >> and so forth). ? The MoCA diag displays show that the STBs see each other >> and the Actiontech at speeds over 220Mbps. ?I doubt the issue is inadequate >> phy connection. ?I assume the interplay between the MoCA MAC and TCP yields >> poor performance. ?But, I did not research this. ?I had them take my >> Internet off the MoCA path and it has worked fine since. >> >> So, how I go about getting 100/100? >> >> >> >> > > From ler762 at gmail.com Thu May 27 15:42:53 2010 From: ler762 at gmail.com (Lee) Date: Thu, 27 May 2010 16:42:53 -0400 Subject: thoughts? In-Reply-To: <6828.1274979419@localhost> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> <6828.1274979419@localhost> Message-ID: On 5/27/10, Valdis.Kletnieks at vt.edu wrote: > On Thu, 27 May 2010 08:46:47 PDT, George Bonser said: >> > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html >> Somebody should do something! > > We started deploying IPv6 in testbed mode on our production network in 1997, > so we're waiting for the rest of you slackers to get caught up. :) & it took only 11 years for the USG to catch up: http://www.whitehouse.gov/omb/rewrite/pubpress/2008/070108_scorecard.html Lee From franck at genius.com Thu May 27 16:19:15 2010 From: franck at genius.com (Franck Martin) Date: Thu, 27 May 2010 23:19:15 +0200 (CEST) Subject: Guam In-Reply-To: Message-ID: <21185695.550.1274995155005.JavaMail.franck@new-host.home> see www.pacnog.org or alternatively www.picisoc.org ----- Original Message ----- From: "JoeSox" To: nanog at nanog.org Sent: Thursday, 27 May, 2010 8:58:04 PM Subject: Guam I am trying to gain some knowledge about setting up a T1 network in Guam. I am in Washington State so I am not sure who to contact over there. We normally deal with QWest but they do not provide service there. I see a GTA Teleguam but I am not sure the wisest place to start. If anyone has any experience, POCs, or knowledge to pass along to this Guam noob I would really appreciate it. -- Thanks, Joe From Valdis.Kletnieks at vt.edu Thu May 27 16:19:47 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 27 May 2010 17:19:47 -0400 Subject: BT strike could affect internet and phone connections In-Reply-To: Your message of "Thu, 27 May 2010 12:57:42 PDT." <767009.81922.qm@web59605.mail.ac4.yahoo.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> Message-ID: <17804.1274995187@localhost> On Thu, 27 May 2010 12:57:42 PDT, "andrew.wallace" said: > Are you *still* using the same threat models as you were 11 years ago? No, it's just in the late 90's our threat models and protocols were already advanced to where everybody else is just getting to now. You won't be able to comprehend our *current* threat models till 2021 or so. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From deepak at ai.net Thu May 27 16:26:20 2010 From: deepak at ai.net (Deepak Jain) Date: Thu, 27 May 2010 17:26:20 -0400 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> References: <268255.45440.qm@web39505.mail.mud.yahoo.com> <9D6633AC-53BA-4F49-9E23-6197BF18107E@hopcount.ca> Message-ID: > On 2010-05-27, at 20:47, jacob miller wrote: > > > Am running an application on Sco Unix but am having the following > problem. > > > > Application is hunging sporadically. > > That seems consistent with my memory of SCO Unix. > Me too, but I don't think this is the right list for it. DJ From henry at AegisInfoSys.com Thu May 27 16:33:39 2010 From: henry at AegisInfoSys.com (Henry Yen) Date: Thu, 27 May 2010 17:33:39 -0400 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <268255.45440.qm@web39505.mail.mud.yahoo.com>; from jacob miller on Thu, May 27, 2010 at 11:47:06AM -0700 References: <268255.45440.qm@web39505.mail.mud.yahoo.com> Message-ID: <20100527173339.J25919@AegisInfoSys.com> On Thu, May 27, 2010 at 11:47:06AM -0700, jacob miller wrote: > Am running an application on Sco Unix but am having the following problem. > > Application is hunging sporadically. > > Am accessing the application via telnet.Have changed the link thinking > that this could be the problem but to no avail. Are your telnet sessions running through a firewall-like device? If so, perhaps the firewall tables are timing out the session after a long enough period of activity? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From joesox at gmail.com Thu May 27 16:46:19 2010 From: joesox at gmail.com (JoeSox) Date: Thu, 27 May 2010 14:46:19 -0700 Subject: Guam In-Reply-To: <21185695.550.1274995155005.JavaMail.franck@new-host.home> References: <21185695.550.1274995155005.JavaMail.franck@new-host.home> Message-ID: Thanks everyone for all the responses. -- Thanks, Joe On Thu, May 27, 2010 at 2:19 PM, Franck Martin wrote: > see www.pacnog.org or alternatively www.picisoc.org > > ----- Original Message ----- > From: "JoeSox" > To: nanog at nanog.org > Sent: Thursday, 27 May, 2010 8:58:04 PM > Subject: Guam > > I am trying to gain some knowledge about setting up a T1 network in > Guam. I am in Washington State so I am not sure who to contact over > there. We normally deal with QWest but they do not provide service > there. I see a GTA Teleguam but I am not sure the wisest place to > start. If anyone has any experience, POCs, or knowledge to pass along to > this Guam noob I would really appreciate it. > > -- Thanks, Joe > From graeme at graemef.net Thu May 27 17:36:56 2010 From: graeme at graemef.net (Graeme Fowler) Date: Thu, 27 May 2010 23:36:56 +0100 Subject: .mil dns problems? In-Reply-To: <87r5kxxgpt.fsf@mid.deneb.enyo.de> References: <20100527192759.GA1992@sources.org> <87r5kxxgpt.fsf@mid.deneb.enyo.de> Message-ID: <1274999816.4700.5.camel@ernie.internal.graemef.net> On Thu, 2010-05-27 at 21:55 +0200, Florian Weimer wrote: > Looks more like a routing issue. Looks like the .MIL operators put > all their eggs into one basket. 8-( >From .uk, the .pac and .con servers respond fine but the .eur servers don't. Go figure. Graeme From andreas at naund.org Thu May 27 17:38:47 2010 From: andreas at naund.org (Andreas Ott) Date: Thu, 27 May 2010 15:38:47 -0700 Subject: Hung Telnet Sessions on Sco Unix In-Reply-To: <268255.45440.qm@web39505.mail.mud.yahoo.com>; from mmzinyi@yahoo.com on Thu, May 27, 2010 at 11:47:06AM -0700 References: <268255.45440.qm@web39505.mail.mud.yahoo.com> Message-ID: <20100527153847.E6086@naund.org> Hi, On Thu, May 27, 2010 at 11:47:06AM -0700, jacob miller wrote: > Have increased keep alives on the routers and increased capacity on them. > service tcp-keepalives-in and out.But this has not sorted the problem out. Are there any firewalls doing NAT and keeping table entries for inspecting sessions among your "routers"? Check for drops there. -andreas From ken.gilmour at gmail.com Thu May 27 18:27:16 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 27 May 2010 17:27:16 -0600 Subject: Junos Asymmetric Routing Message-ID: Hi all, I have a very peculiar situation here that i seem to have difficulty explaining in such a way for people to understand. I just got off the phone to the Juniper Devs after about 4 hours with no result. They understand the problem but can't seem to think of a working solution (last solution led to the primary firewall hard crashing and then failing over after a commit (which also makes me wonder what made the primary crash and not the secondary)). I am wondering if there is anyone "creative" on the list who has encountered and worked around this problem before... Here goes *sigh* ISP1 - 1.1.1.0/24 ISP2 - 2.2.2.0/24 ISP1 is the default gateway, ISP2 is a backup provider but which is always active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. Client comes in on ISP2's link (non default gateway) but for some reason, the packets seem to be going back out through the link for ISP1. So look at it this way: SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in TCPDump, the firewall at 2.2.2.1 never sees it. Here's a log snippet (I can send you more if you need: May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 You will see that the orig and out zones are the same zone, however this was a last ditch effort (putting both interfaces into one zone, effectively creating a swamp). Our current (non-preferred) solution is to put match-all rules on our Catalyst 6513s and put both providers into a swamp and the switch will then intercept the packets if they are destined for the wrong interface and send them out the right one based on a bunch of boolean. We've tried setting up a virtual instance on the offending interface and a firewall filter, but this had little to no effect (at one point it stopped passing the packets to the end machine altogether). We're using small SRX 650ies. Why do we want to do it this way you ask? In the event of a BGP session failure we need to be able to use our statically routed IPs and rely on someone else. Thanks! Ken From LarrySheldon at cox.net Thu May 27 18:40:08 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 18:40:08 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFF02D8.2010703@cox.net> On 5/27/2010 18:27, Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. With the default gateway, that is the behaviour I would expect--I don't see how the router could do otherwise. (This assumes that source routing is not being used.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From curupas at gmail.com Thu May 27 18:59:19 2010 From: curupas at gmail.com (Ricardo Tavares) Date: Thu, 27 May 2010 20:59:19 -0300 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Hi Ken, Not sure if I correctly undestand you but default route its the route that the packet must follow if it do not have a specific route for the destination, so, if the next-hop for the source IP (3.3.3.3) is not in the route table then the packet will follow the default route (ISP1). So, this behavior is correct. Just for troubleshooting purpose install a static route like: set routing-option static route 3.3.3.0/24 next-hop (ISP2) If this works fine then verify the route table, are you using BGP to receive such routing info? If you are not filtering the update maybe the sender is. Regards, Ricardo On Thu, May 27, 2010 at 8:27 PM, Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: ?route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > -- Rio de Janeiro Ciclopata! Cora??o Brasiliense e Floripano! Twitter: http://www.twitter.com/curupas Orkut: http://www.orkut.com.br/Main#Profile?rl=mp&uid=6915582353112941469 Vai Encarar? http://www.vaiencarar.com.br From curupas at gmail.com Thu May 27 19:07:09 2010 From: curupas at gmail.com (Ricardo Tavares) Date: Thu, 27 May 2010 21:07:09 -0300 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Hi Ken, Not sure if I correctly undestand you but default route its the route that the packet must follow if it do not have a specific route for the destination, so, if the next-hop for the source IP (3.3.3.3) is not in the route table then the packet will follow the default route (ISP1). So, this behavior will be correct if next-hop for 3.3.3.0/24 is not installed. Just for troubleshooting purpose install a static route like: set routing-options static route 3.3.3.0/24 next-hop (ISP2) If this works fine then verify the route table, are you using BGP to receive such routing info? If you are not filtering the update maybe the sender is. Verify the received routes using the "show route protocol bgp receive-protocol bgp x.x.x.x" (x.x.x.x is the bgp neighbor) Regards, Ricardo On Thu, May 27, 2010 at 8:27 PM, Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: ?route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > From joelja at bogus.com Thu May 27 19:17:47 2010 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 May 2010 17:17:47 -0700 Subject: BT strike could affect internet and phone connections In-Reply-To: <840456.96100.qm@web59602.mail.ac4.yahoo.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> Message-ID: <4BFF0BAB.5060904@bogus.com> On 2010-05-27 10:42, andrew.wallace wrote: > Look at it from an attackers point of view. If you're thinking about > carrying out an electronic jihad of some kind when is the best time? > A normal working day or during an engineers strike that only happens > once every 23 years? Not to put to fine a point on it, a normal working day is the best time to strike if you want to maximize the value of your attack. > -- Andrew > > http://sites.google.com/site/n3td3v/ > > > > > From ken.gilmour at gmail.com Thu May 27 19:38:11 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Thu, 27 May 2010 18:38:11 -0600 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares! On 27 May 2010 18:07, Ricardo Tavares wrote: > Not sure if I correctly undestand you but default route its the route > that the packet must follow if it do not have a specific route for the > destination, so, if the next-hop for the source IP (3.3.3.3) is not in > the route table then the packet will follow the default route (ISP1). > Yes I believe that would be the default if the session was initiated on the inside, but if it comes from outside on a particular interface which is not the default route, why would the router then send the packet out another interface? Should the device not route session-based traffic according to where it originated? > > So, this behavior will be correct if next-hop for 3.3.3.0/24 is not > installed. Just for troubleshooting purpose install a static route > like: > > set routing-options static route 3.3.3.0/24 next-hop > (ISP2) > Yes sir, this works, but when you change the static route to point 0.0.0.0/0to the next hop on the virtual router for the particular interface (ISP2) it starts going over the interface for ISP1 again. I also set qualified-next-hop for ISP2 in the main routing table to no avail. > If this works fine then verify the route table, are you using BGP to > receive such routing info? If you are not filtering the update maybe > the sender is. Verify the received routes using the "show route > protocol bgp receive-protocol bgp x.x.x.x" (x.x.x.x is the bgp > neighbor) > Yes sir, I have also gone to the extent of deactivating BGP and using only static routes. Thanks for your help! Regards, Ken From joelja at bogus.com Thu May 27 19:48:56 2010 From: joelja at bogus.com (joel jaeggli) Date: Thu, 27 May 2010 17:48:56 -0700 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFF12F8.3050900@bogus.com> On 2010-05-27 17:38, Ken Gilmour wrote: > Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares! > > On 27 May 2010 18:07, Ricardo Tavares wrote: > >> Not sure if I correctly undestand you but default route its the route >> that the packet must follow if it do not have a specific route for the >> destination, so, if the next-hop for the source IP (3.3.3.3) is not in >> the route table then the packet will follow the default route (ISP1). >> > > Yes I believe that would be the default if the session was initiated on the > inside, but if it comes from outside on a particular interface which is not > the default route, why would the router then send the packet out another > interface? Should the device not route session-based traffic according to > where it originated? nope, forwarding decisions are made on the basis of the FIB. if stateful filtering policy and the configuration of the forwarding plane are not congruent then packet will be out of state and likely discarded by your policy. > >> >> So, this behavior will be correct if next-hop for 3.3.3.0/24 is not >> installed. Just for troubleshooting purpose install a static route >> like: >> >> set routing-options static route 3.3.3.0/24 next-hop >> (ISP2) >> > > Yes sir, this works, but when you change the static route to point > 0.0.0.0/0to the next hop on the virtual router for the particular > interface (ISP2) it > starts going over the interface for ISP1 again. I also set > qualified-next-hop for ISP2 in the main routing table to no avail. > > >> If this works fine then verify the route table, are you using BGP to >> receive such routing info? If you are not filtering the update maybe >> the sender is. Verify the received routes using the "show route >> protocol bgp receive-protocol bgp x.x.x.x" (x.x.x.x is the bgp >> neighbor) >> > > Yes sir, I have also gone to the extent of deactivating BGP and using only > static routes. > > Thanks for your help! > > Regards, > > Ken > From andrew.wallace at rocketmail.com Thu May 27 19:57:57 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 27 May 2010 17:57:57 -0700 (PDT) Subject: BT strike could affect internet and phone connections In-Reply-To: <17804.1274995187@localhost> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> <17804.1274995187@localhost> Message-ID: <987202.97348.qm@web59616.mail.ac4.yahoo.com> On Fri, May 28, 2010 at 1:17 AM, joel jaeggli wrote: > On 2010-05-27 10:42, andrew.wallace wrote: >> >> Look at it from an attackers point of view. If you're thinking about >> carrying out an electronic jihad of some kind when is the best time? >> A normal working day or during an engineers strike that only happens >> once every 23 years? > > Not to put to fine a point on it, a normal working day is the best time to > strike if you want to maximize the value of your attack. The point I'm getting at is this strike of this nature is a threat to national security and the internet is supposed to be classed as critical infrastructure, so shouldn't it be against the law for them to strike? Or has the law in the UK not got as far as the United States has on deeming what's critical infrastructure yet? We are far behind the United States and its about time we played catch-up. -- Andrew http://sites.google.com/site/n3td3v/ From curupas at gmail.com Thu May 27 20:21:05 2010 From: curupas at gmail.com (Ricardo Tavares) Date: Thu, 27 May 2010 22:21:05 -0300 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: f the route announce is coming from the BGP neighbor you need to verify if the next-hop indicated for this route is itself reached by the router, if by recursion the router do not resolve how to go to the next-hop then the announced route will be not available. THe bgp sender must set the next-hop with a reachable address, sometimes this is achieved by the sender using the next-hop-self in the export policy, but it is possible other situations where the next-hop is unreachable. If the sender is using a specific address for all the next-hops for all the announced routes you will need just a static route pointing to the gateway for his next-hop. If the BGP session for some reasons goes down then the default route will apply and the redundancy through ISP1 will work fine. Best Regards, Ricardo On Thu, May 27, 2010 at 9:38 PM, Ken Gilmour wrote: > Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares! > > On 27 May 2010 18:07, Ricardo Tavares wrote: >> >> Not sure if I correctly undestand you but default route its the route >> that the packet must follow if it do not have a specific route for the >> destination, so, if the next-hop for the source IP (3.3.3.3) is not in >> the route table then the packet will follow the default route (ISP1). > > Yes I believe that would be the default if the session was initiated on the > inside, but if it comes from outside on a particular interface which is not > the default route, why would the router then send the packet out another > interface? Should the device not route session-based traffic according to > where it originated? > >> >> So, this behavior will be correct if next-hop for 3.3.3.0/24 is not >> installed. Just for troubleshooting purpose install a static route >> like: >> >> set routing-options static route 3.3.3.0/24 next-hop >> (ISP2) > > Yes sir, this works, but when you change the static route to point 0.0.0.0/0 > to the next hop on the virtual router for the particular interface (ISP2) it > starts going over the interface for ISP1 again. I also set > qualified-next-hop for ISP2 in the main routing table to no avail. > >> >> If this works fine then verify the route table, are you using BGP to >> receive such routing info? If you are not filtering the update maybe >> the sender is. Verify the received routes using the "show route >> protocol bgp receive-protocol bgp x.x.x.x" (x.x.x.x is the bgp >> neighbor) > > Yes sir, I have also gone to the extent of deactivating BGP and using only > static routes. > > Thanks for your help! > > Regards, > > Ken > From LarrySheldon at cox.net Thu May 27 20:49:06 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 27 May 2010 20:49:06 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFF2112.3060002@cox.net> On 5/27/2010 19:38, Ken Gilmour wrote: > Wow, very fast responses, Thanks Larry Sheldon and Ricardo Tavares! > > On 27 May 2010 18:07, Ricardo Tavares wrote: > >> Not sure if I correctly undestand you but default route its the route >> that the packet must follow if it do not have a specific route for the >> destination, so, if the next-hop for the source IP (3.3.3.3) is not in >> the route table then the packet will follow the default route (ISP1). >> > > Yes I believe that would be the default if the session was initiated on the > inside, but if it comes from outside on a particular interface which is not > the default route, why would the router then send the packet out another > interface? Should the device not route session-based traffic according to > where it originated? I'm close to the edge of what I know (or remember--i've been inactive for a while) but when a packet arrives on an interface, the routing engine has to decide where to poke it bqased on what is in the packet--there is no information as to where it came from, or to what it is a response. If it isn't in the IP header, it isn't available for routing decisions. ("Policy routing" can provide additional data, as can source routing. But one requires a human being to provide the rule, and the other requires somebody or something else outside the router to calculate the route. I don't think anybody much allows source routing anymore.) -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From gbonser at seven.com Thu May 27 23:58:55 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 27 May 2010 21:58:55 -0700 Subject: BT strike could affect internet and phone connections In-Reply-To: <987202.97348.qm@web59616.mail.ac4.yahoo.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org><840456.96100.qm@web59602.mail.ac4.yahoo.com><11023.1274984586@localhost><767009.81922.qm@web59605.mail.ac4.yahoo.com><17804.1274995187@localhost> <987202.97348.qm@web59616.mail.ac4.yahoo.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE09EA47D2@RWC-EX1.corp.seven.com> > -----Original Message----- > From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] > Sent: Thursday, May 27, 2010 5:58 PM > To: joelja at bogus.com > Cc: nanog at nanog.org > Subject: Re: BT strike could affect internet and phone connections > > On Fri, May 28, 2010 at 1:17 AM, joel jaeggli wrote: > > On 2010-05-27 10:42, andrew.wallace wrote: > >> > >> Look at it from an attackers point of view. If you're thinking about > >> carrying out an electronic jihad of some kind when is the best time? > >> A normal working day or during an engineers strike that only happens > >> once every 23 years? > > > > Not to put to fine a point on it, a normal working day is the best > time to > > strike if you want to maximize the value of your attack. > > The point I'm getting at is this strike of this nature is a threat to > national security and the internet is supposed to be classed as > critical infrastructure, so shouldn't it be against the law for them to > strike? > Sounds to me like the best defense the UK could implement would be fostering competition with BT. BT goes on strike, customers move elsewhere, life goes on. From guxiaojian at gmail.com Fri May 28 00:46:16 2010 From: guxiaojian at gmail.com (Jian Gu) Date: Thu, 27 May 2010 22:46:16 -0700 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the problem gracefully? when connection requests coming in through ISP2, source NAT the incoming traffic's source IP with IPs on firewall inside interface, that way when server replies, firewall 2.2.2.1 will guarantee to receive the ACK because ACK traffic won't follow default routing to ISP1. On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: ?route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > From jbfixurpc at gmail.com Fri May 28 01:33:02 2010 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Fri, 28 May 2010 02:33:02 -0400 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFF639E.90603@gmail.com> That would seem to be a good resolution (Firewall/NAT) . Aside from that, perhaps a load balancer for each segment might help? One question that comes to mind is why (if ISP2 is a backup) would valid traffic be using that route? Unless maybe your loadbalancing using a DNS round robin perhaps to hit the second IP space or loadbalancing the 2 ISPs? Another "maybe" resolve would be to multi-home the application to that segment, i.e. 2 nics on the server, one on the primary network, the other on the secondary with appropriate Def.GWs, of course since there is little information on the infrastructure here this may not be possible. I suppose if one were to get really detailed about this, you could look into reverse routing using MAC, but theoretically that would/could open a whole other set of issues. Regards, Joe Blanchard Jian Gu wrote: > Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the > problem gracefully? when connection requests coming in through ISP2, > source NAT the incoming traffic's source IP with IPs on firewall > inside interface, that way when server replies, firewall 2.2.2.1 will > guarantee to receive the ACK because ACK traffic won't follow default > routing to ISP1. > > On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour wrote: > >> Hi all, >> >> I have a very peculiar situation here that i seem to have difficulty >> explaining in such a way for people to understand. I just got off the phone >> to the Juniper Devs after about 4 hours with no result. They understand the >> problem but can't seem to think of a working solution (last solution led to >> the primary firewall hard crashing and then failing over after a commit >> (which also makes me wonder what made the primary crash and not the >> secondary)). I am wondering if there is anyone "creative" on the list who >> has encountered and worked around this problem before... >> >> Here goes *sigh* >> >> ISP1 - 1.1.1.0/24 >> ISP2 - 2.2.2.0/24 >> >> ISP1 is the default gateway, ISP2 is a backup provider but which is always >> active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. >> Client comes in on ISP2's link (non default gateway) but for some reason, >> the packets seem to be going back out through the link for ISP1. >> >> So look at it this way: >> >> SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the >> firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in >> TCPDump, the firewall at 2.2.2.1 never sees it. >> >> Here's a log snippet (I can send you more if you need: >> >> May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig >> ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 >> >> You will see that the orig and out zones are the same zone, however this was >> a last ditch effort (putting both interfaces into one zone, effectively >> creating a swamp). >> >> Our current (non-preferred) solution is to put match-all rules on our >> Catalyst 6513s and put both providers into a swamp and the switch will then >> intercept the packets if they are destined for the wrong interface and send >> them out the right one based on a bunch of boolean. >> >> We've tried setting up a virtual instance on the offending interface and a >> firewall filter, but this had little to no effect (at one point it stopped >> passing the packets to the end machine altogether). We're using small SRX >> 650ies. Why do we want to do it this way you ask? In the event of a BGP >> session failure we need to be able to use our statically routed IPs and rely >> on someone else. >> >> Thanks! >> >> Ken >> >> > > > From joelja at bogus.com Fri May 28 03:10:36 2010 From: joelja at bogus.com (joel jaeggli) Date: Fri, 28 May 2010 01:10:36 -0700 Subject: BT strike could affect internet and phone connections In-Reply-To: <987202.97348.qm@web59616.mail.ac4.yahoo.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> <17804.1274995187@localhost> <987202.97348.qm@web59616.mail.ac4.yahoo.com> Message-ID: <4BFF7A7C.4060102@bogus.com> On 2010-05-27 17:57, andrew.wallace wrote: > On Fri, May 28, 2010 at 1:17 AM, joel jaeggli > wrote: >> On 2010-05-27 10:42, andrew.wallace wrote: >>> >>> Look at it from an attackers point of view. If you're thinking >>> about carrying out an electronic jihad of some kind when is the >>> best time? A normal working day or during an engineers strike >>> that only happens once every 23 years? >> >> Not to put to fine a point on it, a normal working day is the best >> time to strike if you want to maximize the value of your attack. > > The point I'm getting at is this strike of this nature is a threat to > national security and the internet is supposed to be classed as > critical infrastructure, so shouldn't it be against the law for them > to strike? The phone system has been critical infrastructure for 120 years... > Or has the law in the UK not got as far as the United States has on > deeming what's critical infrastructure yet? > > We are far behind the United States and its about time we played > catch-up. I don't think a CWA strike has been declared illegal in recent history... > -- Andrew > > http://sites.google.com/site/n3td3v/ > > > > From daniel.karrenberg at ripe.net Fri May 28 06:38:44 2010 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 28 May 2010 13:38:44 +0200 Subject: thoughts? In-Reply-To: References: Message-ID: <20100528113844.GA1946@reif.karrenberg.net> On 27.05 07:10, Dorn Hetzel wrote: > http://www.cnn.com/2010/TECH/05/27/internet.crunch.2012/index.html?hpt=T2 Certainly no news for people on this list I would hope. ;-) My objective when talking to reporters who write for the *business* section is to project that mere awareness is not good enough anymore for businesses; businesses need to have a plan. For you all on this list this should help the next time you talk to the suits who decide about strategy and investments ... independently of which particular strategy you are going to recommend. The non-technical press always simplifies and exaggerates; this is a fact of life. I am sure all of us evaluate news stories based on the source. It is fine if you say to the suits "this is exaggerated, let's ......", just make the right decision. ;-) This reporter did a very reasonable job considering the space he has to operate in. Daniel Karrenberg IP address expert Not my words, but not wrong either. contributions: RFC2050/BCP012, RFC1918/BCP005, address policies in RIPE region ... founding CEO of first RIR "Prediciting the future is easy..., getting it right is the dificult part." From williams.bruce at gmail.com Fri May 28 06:58:50 2010 From: williams.bruce at gmail.com (Bruce Williams) Date: Fri, 28 May 2010 04:58:50 -0700 Subject: thoughts? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> <4BFE96B0.6010208@gmail.com> <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seven.com> Message-ID: On Thu, May 27, 2010 at 9:41 AM, George Bonser wrote: > > Where does one get an IP address degree? > > > The same place anything of value is found - Wall St. They are creating CIPO's - Collateralized IP Obligations. They will create a market so people "borrow" IP addresses, the people who loan the IP addresses can hedge to insure they will get them back, then they can trade the obligations and there will soon be trillions of IP4 addresses on paper. There will be liquidity in the IP market. We are not running out, we need liquidity, that's all. Bruce Williams From mark at hermsdorfer.net Fri May 28 07:37:28 2010 From: mark at hermsdorfer.net (Mark Hermsdorfer) Date: Fri, 28 May 2010 08:37:28 -0400 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: On Thu, May 27, 2010 at 8:38 PM, Ken Gilmour wrote: > > Yes I believe that would be the default if the session was initiated on the > inside, but if it comes from outside on a particular interface which is not > the default route, why would the router then send the packet out another > interface? Should the device not route session-based traffic according to > where it originated? > > Ken, As others have pointed out typically interfaces are not kept track of in state tables. Having said that, I've worked in the past with the ScreenOS based SSG platforms that do this. So if you're coming from an SSG background this makes sense. These devices seem to keep track of source interface in their state tables. For example I've worked on a one-arm'ed Load Balancer with no Source NAT such that one would typically require some policy based routing to get the traffic back to the LB, to be have the Destination NAT handled. However, with a Juniper SSG, as the router, it's state tables kept track of the interfaces and routed traffic correctly without any policy based routing required. When I took over administration of that environment I spent some time trying to figure out how the routing worked since there was no configuration such as policy based routes that would make sense. Having said that, If the JunOS based SRX platform does not do session tracking in the same was as the SSG platform it would seem that the most reasonable solution would be to NAT the traffic as has already been pointed out. Mark -- Cheers! Mark Hermsdorfer From jbates at brightok.net Fri May 28 08:08:32 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 May 2010 08:08:32 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFFC050.1080705@brightok.net> Ken Gilmour wrote: > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > Your BGP config with ISP2 is probably unideal. This has lead to packets coming in via ISP2 despite the fact you prefer to use ISP1. Often, people only do AS Prepend to alter traffic patterns. However, if a packet finds it's way to your directly connected ISP, an AS Prepend is not enough. It will be sent to you based on local preference. Setting appropriate communities with your ISP can often override this preference so they will send the packet towards your ISP1 instead of direct. Jack From rsm at fast-serv.com Fri May 28 08:12:56 2010 From: rsm at fast-serv.com (Randy McAnally) Date: Fri, 28 May 2010 09:12:56 -0400 Subject: FIOS Router In-Reply-To: <4BFE9F6D.7090002@2mbit.com> References: <20100527162418.M36244@fast-serv.com> <4BFE9F6D.7090002@2mbit.com> Message-ID: <20100528130713.M98529@fast-serv.com> ---------- Original Message ----------- From: Brielle Bruns > See the response I just posted, but in all likely, he's being > hampered by the fact the handoff from the ONT is 100BT ethernet and > OpenRG (which bolts on top of a Linux OS and 'replaces' the > functionality of iptables and such). I really meant a real Linux server (or desktop box loaded with CentOS, Deb, ect) with some basic IPtables rules and dual NIC. I never intended to use any kind of appliance or router device loaded with 'brand x' Linux. A 100bT hand-off should have NO issues reaching ~98Mbps without packet loss; just a little extra latency as you start filling buffers. Since the first day our FiOS was installed, we switched out the cruddy Dlink router (later swapped with Actiontec) with a Linux box running CentOS and a simple iptables script. I later added a Atheros-based wifi card with HostAP and madwifi to create an AP from the same box. Linux/Wifi is not for all of course, but the dual-nic and IPtables part pretty much anyone can do...you could just as easily hang a small wifi router off the box. -R From jbates at brightok.net Fri May 28 08:15:09 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 May 2010 08:15:09 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFFC1DD.5090200@brightok.net> Ken Gilmour wrote: > Yes I believe that would be the default if the session was initiated on the > inside, but if it comes from outside on a particular interface which is not > the default route, why would the router then send the packet out another > interface? Should the device not route session-based traffic according to > where it originated? > > To my knowledge, routers don't generally route based on session. They maintain flow information is cases, but you learn quickly that it's a one way record, and the corresponding flows may have a different path. There are exceptions, and perhaps some Junipers even support more oddball session based routing, though my m120 and cisco don't seem to. Jack From jmaimon at ttec.com Fri May 28 09:13:52 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 28 May 2010 10:13:52 -0400 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFFCFA0.3060602@ttec.com> Firewalls that can route and service properly multiple "untrusts"? Good luck. Hit or miss. Constant flux. Place a router in front of it and that will get you a ways there. Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > > From smb at cs.columbia.edu Fri May 28 09:24:29 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 28 May 2010 10:24:29 -0400 Subject: BT strike could affect internet and phone connections In-Reply-To: <4BFF7A7C.4060102@bogus.com> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> <17804.1274995187@localhost> <987202.97348.qm@web59616.mail.ac4.yahoo.com> <4BFF7A7C.4060102@bogus.com> Message-ID: <2CE28CB1-F404-4A6C-829E-8F2F81B1D52C@cs.columbia.edu> On May 28, 2010, at 4:10 36AM, joel jaeggli wrote: > On 2010-05-27 17:57, andrew.wallace wrote: >> On Fri, May 28, 2010 at 1:17 AM, joel jaeggli >> wrote: >>> On 2010-05-27 10:42, andrew.wallace wrote: >>>> >>>> Look at it from an attackers point of view. If you're thinking >>>> about carrying out an electronic jihad of some kind when is the >>>> best time? A normal working day or during an engineers strike >>>> that only happens once every 23 years? >>> >>> Not to put to fine a point on it, a normal working day is the best >>> time to strike if you want to maximize the value of your attack. >> >> The point I'm getting at is this strike of this nature is a threat to >> national security and the internet is supposed to be classed as >> critical infrastructure, so shouldn't it be against the law for them >> to strike? > > The phone system has been critical infrastructure for 120 years... > >> Or has the law in the UK not got as far as the United States has on >> deeming what's critical infrastructure yet? >> >> We are far behind the United States and its about time we played >> catch-up. > > I don't think a CWA strike has been declared illegal in recent history... > In general, strikes by telco, power company employees, etc., are legal in the US. Under certain circumstances involving the national interest, the president can order workers back to their jobs for 80 days, after which they're free to walk out again. The only people who can never strikes are public employees. --Steve Bellovin, http://www.cs.columbia.edu/~smb From JTyler at fiberutilities.com Fri May 28 10:06:39 2010 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Fri, 28 May 2010 10:06:39 -0500 Subject: Junos Asymmetric Routing In-Reply-To: <4BFFCFA0.3060602@ttec.com> References: <4BFFCFA0.3060602@ttec.com> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F943724597E19@comsrv01.fg.local> When you set-up your virtual-instance, was your ISP2 interface a member of that instance? I have a working setup that ran on a J-series running 9.6 something. This is a Juniper guide I used but it was a little bit different and didn't work for me. http://www.juniper.net/us/en/local/pdf/day-one-guides/7100110-en.pdf I used below: --Routing instance: routing-instances { DSL { instance-type virtual-router; interface ge-0/0/1.0; // <-- Most important part - ISP2 Interface must be a member to get correct incoming context. routing-options { static { route 0.0.0.0/0 next-hop 172.24.1.1; // ISP2 next hop } } } } --Firewall filter: firewall { filter DSL { term DSL { from { address { 192.0.1.210/32; // This is the address that will go into the virtual router (ISP2 addresses should go here) } } then { count source-route; log; routing-instance DSL; } } term default { // Everything else uses default routing table. then { count defualt-counter; log; accept; } } } } Jensen Tyler Network Engineer Fiberutilities Group, LLC -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Friday, May 28, 2010 9:14 AM To: Ken Gilmour Cc: nanog at nanog.org Subject: Re: Junos Asymmetric Routing Firewalls that can route and service properly multiple "untrusts"? Good luck. Hit or miss. Constant flux. Place a router in front of it and that will get you a ways there. Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > > From ken.gilmour at gmail.com Fri May 28 10:09:58 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 28 May 2010 09:09:58 -0600 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Hi Jian, Yes sir that's what I thought too. The packets are being NATted (and I also used a bit of DNAT for port forwarding to test the theory) but the result is the same. Regards, Ken On 27 May 2010 23:46, Jian Gu wrote: > Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the > problem gracefully? when connection requests coming in through ISP2, > source NAT the incoming traffic's source IP with IPs on firewall > inside interface, that way when server replies, firewall 2.2.2.1 will > guarantee to receive the ACK because ACK traffic won't follow default > routing to ISP1. > > On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour > wrote: > > Hi all, > > > > I have a very peculiar situation here that i seem to have difficulty > > explaining in such a way for people to understand. I just got off the > phone > > to the Juniper Devs after about 4 hours with no result. They understand > the > > problem but can't seem to think of a working solution (last solution led > to > > the primary firewall hard crashing and then failing over after a commit > > (which also makes me wonder what made the primary crash and not the > > secondary)). I am wondering if there is anyone "creative" on the list who > > has encountered and worked around this problem before... > > > > Here goes *sigh* > > > > ISP1 - 1.1.1.0/24 > > ISP2 - 2.2.2.0/24 > > > > ISP1 is the default gateway, ISP2 is a backup provider but which is > always > > active. Client comes in on ISP1's link, traffic goes back out on ISP1s > link. > > Client comes in on ISP2's link (non default gateway) but for some reason, > > the packets seem to be going back out through the link for ISP1. > > > > So look at it this way: > > > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by > the > > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > > TCPDump, the firewall at 2.2.2.1 never sees it. > > > > Here's a log snippet (I can send you more if you need: > > > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 > *orig > > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > > > You will see that the orig and out zones are the same zone, however this > was > > a last ditch effort (putting both interfaces into one zone, effectively > > creating a swamp). > > > > Our current (non-preferred) solution is to put match-all rules on our > > Catalyst 6513s and put both providers into a swamp and the switch will > then > > intercept the packets if they are destined for the wrong interface and > send > > them out the right one based on a bunch of boolean. > > > > We've tried setting up a virtual instance on the offending interface and > a > > firewall filter, but this had little to no effect (at one point it > stopped > > passing the packets to the end machine altogether). We're using small SRX > > 650ies. Why do we want to do it this way you ask? In the event of a BGP > > session failure we need to be able to use our statically routed IPs and > rely > > on someone else. > > > > Thanks! > > > > Ken > > > From ken.gilmour at gmail.com Fri May 28 10:16:01 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 28 May 2010 09:16:01 -0600 Subject: Junos Asymmetric Routing In-Reply-To: <4BFF639E.90603@gmail.com> References: <4BFF639E.90603@gmail.com> Message-ID: Hi Joe, Interesting questions, Answers are below your questions: On 28 May 2010 00:33, Joe Blanchard wrote: > That would seem to be a good resolution (Firewall/NAT) . Aside from that, > perhaps a load > balancer for each segment might help? > Possibly but this will cost money to implement and there is no guarantee that it will work. > One question that comes to mind is why (if ISP2 is a backup) would valid > traffic > be using that route? > Several reasons, but the two main reasons are: 1. Some clients might find one path faster than another (e.g. vpn.example.com vs vpn2.example.com). If they are on the same provider then chances are that they will have better remote access that way. 2. If BGP fails we want all of our statically routed IP addresses to work too, this is our solution to be able to guarantee connectivity to payment processors (so quite important to ensure that we can make money) > Unless maybe your loadbalancing using a DNS round robin perhaps to hit the > second IP space or loadbalancing > the 2 ISPs? > No round robin... This is the last resort if BGP fails > Another "maybe" resolve would be to multi-home the application to that > segment, i.e. 2 nics on the > server, one on the primary network, the other on the secondary with > appropriate Def.GWs, of course > since there is little information on the infrastructure here this may not > be possible. > I suppose if one were to get really detailed about this, you could look > into reverse routing using MAC, but > theoretically that would/could open a whole other set of issues. > I can go extremely detailed offlist but there would be far too much information to post to NANOG otherwise, and it would probably just annoy people and result in flaming more than anything. > > Regards, > Joe Blanchard > > > > Jian Gu wrote: > >> Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the >> problem gracefully? when connection requests coming in through ISP2, >> source NAT the incoming traffic's source IP with IPs on firewall >> inside interface, that way when server replies, firewall 2.2.2.1 will >> guarantee to receive the ACK because ACK traffic won't follow default >> routing to ISP1. >> >> On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour >> wrote: >> >> >>> Hi all, >>> >>> I have a very peculiar situation here that i seem to have difficulty >>> explaining in such a way for people to understand. I just got off the >>> phone >>> to the Juniper Devs after about 4 hours with no result. They understand >>> the >>> problem but can't seem to think of a working solution (last solution led >>> to >>> the primary firewall hard crashing and then failing over after a commit >>> (which also makes me wonder what made the primary crash and not the >>> secondary)). I am wondering if there is anyone "creative" on the list who >>> has encountered and worked around this problem before... >>> >>> Here goes *sigh* >>> >>> ISP1 - 1.1.1.0/24 >>> ISP2 - 2.2.2.0/24 >>> >>> ISP1 is the default gateway, ISP2 is a backup provider but which is >>> always >>> active. Client comes in on ISP1's link, traffic goes back out on ISP1s >>> link. >>> Client comes in on ISP2's link (non default gateway) but for some reason, >>> the packets seem to be going back out through the link for ISP1. >>> >>> So look at it this way: >>> >>> SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by >>> the >>> firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in >>> TCPDump, the firewall at 2.2.2.1 never sees it. >>> >>> Here's a log snippet (I can send you more if you need: >>> >>> May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 >>> *orig >>> ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 >>> >>> You will see that the orig and out zones are the same zone, however this >>> was >>> a last ditch effort (putting both interfaces into one zone, effectively >>> creating a swamp). >>> >>> Our current (non-preferred) solution is to put match-all rules on our >>> Catalyst 6513s and put both providers into a swamp and the switch will >>> then >>> intercept the packets if they are destined for the wrong interface and >>> send >>> them out the right one based on a bunch of boolean. >>> >>> We've tried setting up a virtual instance on the offending interface and >>> a >>> firewall filter, but this had little to no effect (at one point it >>> stopped >>> passing the packets to the end machine altogether). We're using small SRX >>> 650ies. Why do we want to do it this way you ask? In the event of a BGP >>> session failure we need to be able to use our statically routed IPs and >>> rely >>> on someone else. >>> >>> Thanks! >>> >>> Ken >>> >>> >>> >> >> >> >> > > From JTyler at fiberutilities.com Fri May 28 10:16:26 2010 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Fri, 28 May 2010 10:16:26 -0500 Subject: Junos Asymmetric Routing In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F943724597E19@comsrv01.fg.local> References: <4BFFCFA0.3060602@ttec.com> <1A8A762BD508624A8BDAB9F5E1638F943724597E19@comsrv01.fg.local> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F943724597E1E@comsrv01.fg.local> Sorry ken I sent the wrong link. Below is the correct one: Configuration Example: Configure J-Series/SRX for dual ISP without dynamic routing protocols. http://kb.juniper.net/index?page=content&id=KB15545&actp=search&searchid=1263410684167&smlogin=true Still note virtual-router instance is needed not forwarding instance as in this guide. Jensen Tyler Network Engineer Fiberutilities Group, LLC -----Original Message----- From: Jensen Tyler [mailto:JTyler at fiberutilities.com] Sent: Friday, May 28, 2010 10:07 AM To: Ken Gilmour Cc: nanog at nanog.org Subject: RE: Junos Asymmetric Routing When you set-up your virtual-instance, was your ISP2 interface a member of that instance? I have a working setup that ran on a J-series running 9.6 something. This is a Juniper guide I used but it was a little bit different and didn't work for me. http://www.juniper.net/us/en/local/pdf/day-one-guides/7100110-en.pdf I used below: --Routing instance: routing-instances { DSL { instance-type virtual-router; interface ge-0/0/1.0; // <-- Most important part - ISP2 Interface must be a member to get correct incoming context. routing-options { static { route 0.0.0.0/0 next-hop 172.24.1.1; // ISP2 next hop } } } } --Firewall filter: firewall { filter DSL { term DSL { from { address { 192.0.1.210/32; // This is the address that will go into the virtual router (ISP2 addresses should go here) } } then { count source-route; log; routing-instance DSL; } } term default { // Everything else uses default routing table. then { count defualt-counter; log; accept; } } } } Jensen Tyler Network Engineer Fiberutilities Group, LLC -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: Friday, May 28, 2010 9:14 AM To: Ken Gilmour Cc: nanog at nanog.org Subject: Re: Junos Asymmetric Routing Firewalls that can route and service properly multiple "untrusts"? Good luck. Hit or miss. Constant flux. Place a router in front of it and that will get you a ways there. Ken Gilmour wrote: > Hi all, > > I have a very peculiar situation here that i seem to have difficulty > explaining in such a way for people to understand. I just got off the phone > to the Juniper Devs after about 4 hours with no result. They understand the > problem but can't seem to think of a working solution (last solution led to > the primary firewall hard crashing and then failing over after a commit > (which also makes me wonder what made the primary crash and not the > secondary)). I am wondering if there is anyone "creative" on the list who > has encountered and worked around this problem before... > > Here goes *sigh* > > ISP1 - 1.1.1.0/24 > ISP2 - 2.2.2.0/24 > > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. > > So look at it this way: > > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by the > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it in > TCPDump, the firewall at 2.2.2.1 never sees it. > > Here's a log snippet (I can send you more if you need: > > May 27 21:38:49 21:38:48.1509569:CID-1:RT: route lookup: dest-ip 3.3.3.3 *orig > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 > > You will see that the orig and out zones are the same zone, however this was > a last ditch effort (putting both interfaces into one zone, effectively > creating a swamp). > > Our current (non-preferred) solution is to put match-all rules on our > Catalyst 6513s and put both providers into a swamp and the switch will then > intercept the packets if they are destined for the wrong interface and send > them out the right one based on a bunch of boolean. > > We've tried setting up a virtual instance on the offending interface and a > firewall filter, but this had little to no effect (at one point it stopped > passing the packets to the end machine altogether). We're using small SRX > 650ies. Why do we want to do it this way you ask? In the event of a BGP > session failure we need to be able to use our statically routed IPs and rely > on someone else. > > Thanks! > > Ken > > From ken.gilmour at gmail.com Fri May 28 10:20:33 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 28 May 2010 09:20:33 -0600 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Hi Mark, On 28 May 2010 06:37, Mark Hermsdorfer wrote: > > Ken, > > As others have pointed out typically interfaces are not kept track of in > state tables. Having said that, I've worked in the past with the ScreenOS > based SSG platforms that do this. So if you're coming from an SSG > background this makes sense. > Yes sir I have used SSG for several years but mainly used BSD for the last decade and most recently OpenBSD. There is an easy fix for this on PF for OpenBSD and that is to tag the packets from each provider (as in not using 802.1q but a specific function in PF). This works extremely well > > These devices seem to keep track of source interface in their state > tables. For example I've worked on a one-arm'ed Load Balancer with no > Source NAT such that one would typically require some policy based routing > to get the traffic back to the LB, to be have the Destination NAT handled. > However, with a Juniper SSG, as the router, it's state tables kept track of > the interfaces and routed traffic correctly without any policy based routing > required. When I took over administration of that environment I spent some > time trying to figure out how the routing worked since there was no > configuration such as policy based routes that would make sense. > > Having said that, If the JunOS based SRX platform does not do session > tracking in the same was as the SSG platform it would seem that the most > reasonable solution would be to NAT the traffic as has already been pointed > out. > > Mark > > -- > Cheers! > Mark Hermsdorfer > From ken.gilmour at gmail.com Fri May 28 10:21:43 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 28 May 2010 09:21:43 -0600 Subject: Junos Asymmetric Routing In-Reply-To: <4BFFC050.1080705@brightok.net> References: <4BFFC050.1080705@brightok.net> Message-ID: Hi Jack On 28 May 2010 07:08, Jack Bates wrote: > > Your BGP config with ISP2 is probably unideal. This has lead to packets > coming in via ISP2 despite the fact you prefer to use ISP1. Often, people > only do AS Prepend to alter traffic patterns. However, if a packet finds > it's way to your directly connected ISP, an AS Prepend is not enough. It > will be sent to you based on local preference. Setting appropriate > communities with your ISP can often override this preference so they will > send the packet towards your ISP1 instead of direct. > > Strangely, BGP actually works without issues. The only issue is with statically routed ranges. From ken.gilmour at gmail.com Fri May 28 10:23:34 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Fri, 28 May 2010 09:23:34 -0600 Subject: Junos Asymmetric Routing In-Reply-To: <4BFFCFA0.3060602@ttec.com> References: <4BFFCFA0.3060602@ttec.com> Message-ID: Hi Joe, On 28 May 2010 08:13, Joe Maimon wrote: > Firewalls that can route and service properly multiple "untrusts"? > > Good luck. Hit or miss. Constant flux. > > Place a router in front of it and that will get you a ways there. We replaced our OpenBSD routers with these SRXes since they were supposed to be multifunction devices (gateways and routers at the same time) which was the selling point. So we expected them to do asymmetric routing and were told they could, easily, but apparently they are not acting normally and also the configuration is perfect according to JTAC. From adrian at creative.net.au Fri May 28 10:24:34 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 28 May 2010 23:24:34 +0800 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <20100528152434.GU6812@skywalker.creative.net.au> On Fri, May 28, 2010, Ken Gilmour wrote: > Yes sir I have used SSG for several years but mainly used BSD for the last > decade and most recently OpenBSD. There is an easy fix for this on PF for > OpenBSD and that is to tag the packets from each provider (as in not using > 802.1q but a specific function in PF). This works extremely well That keeps per-connection state. Be aware of the repercussions! Adrian From adrian at creative.net.au Fri May 28 10:30:19 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 28 May 2010 23:30:19 +0800 Subject: Junos Asymmetric Routing In-Reply-To: References: <4BFFCFA0.3060602@ttec.com> Message-ID: <20100528153019.GV6812@skywalker.creative.net.au> > We replaced our OpenBSD routers with these SRXes since they were supposed to > be multifunction devices (gateways and routers at the same time) which was > the selling point. So we expected them to do asymmetric routing and were > told they could, easily, but apparently they are not acting normally and > also the configuration is perfect according to JTAC. It sounds like a mis-communication on everyones' parts. I've come across plenty of systems-oriented people who believe the behaviour of network edge devices is what you've said - because various hosts (eg Linux) treat sockets, routing, ethernet active/standby, etc a specific way and this is not how "traditional" routing/edge devices behave. :) Adrian From jbates at brightok.net Fri May 28 10:44:16 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 28 May 2010 10:44:16 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: <4BFFC050.1080705@brightok.net> Message-ID: <4BFFE4D0.20906@brightok.net> Ken Gilmour wrote: > > Strangely, BGP actually works without issues. The only issue is with > statically routed ranges. Same rules apply, just without control on your end. If a packet hits ISP2, ISP2 will send it to you by most ISP standards (prefer direct customers over peers). Outbound, you will send your normal route (you prefer ISP1). There are methods of handling session based routing in some products from what I gather, but in traditional routing, each direction of a session is independent (session = 2 flows) and the router is unaware of actual sessions. Some real world examples I've dealt with which reduces asymmetric routing, though not always eliminates it. 1) full backup ISP (we don't use it unless there's no other options) a. AS prepend (tell the outside world we prefer them not to come this way) b. community to ISP setting local pref (if the packet does hit provider, tell the provider we prefer them to use their external peer over sending direct to us). c. set local pref on received routes so they are least preferred. 2) backup with partial traffic (generally we want to receive and send packets via this ISP if the customer is directly connected to them). a. AS prepend (least preferred way to reach me) b. set local pref on received routes based on providers communities (perhaps we'll only send this way if it's a non-bgp customer, or to any network which didn't come through exchange points; very ISP dependent). The goal of the second is to reduce asymmetric traffic, while allowing us to use the backup link to reach the ISP's networks and their directly connected customers. Some multihomed customers may still go asymmetric. Primarily used in cases where ISP has piss poor exchange connectivity at times, so you want to reach their customers without going the long way around through the exchanges. The first I've used before with split network scenarios, where one provider handles some networks, and the other provider handles other networks. Setting the local pref forces traffic even on ISP2 (backup ISP for specific network) to make it's way to ISP1 (primary ISP for the specific network) instead of coming direct (suboptimal, but symmetric). Source address based policy rules pushed traffic back out the correct path for that network so long as it was available. Jack From LarrySheldon at cox.net Fri May 28 11:06:49 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 28 May 2010 11:06:49 -0500 Subject: thoughts? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE09EA4773@RWC-EX1.corp.seven.com> <4BFE96B0.6010208@gmail.com> <5A6D953473350C4B9995546AFE9939EE09EA4777@RWC-EX1.corp.seven.com> Message-ID: <4BFFEA19.4020202@cox.net> On 5/28/2010 06:58, Bruce Williams wrote: > On Thu, May 27, 2010 at 9:41 AM, George Bonser wrote: > >> >> Where does one get an IP address degree? >> >> >> > > The same place anything of value is found - Wall St. > > They are creating CIPO's - Collateralized IP Obligations. They will > create a market so people "borrow" IP addresses, the people who loan > the IP addresses can hedge to insure they will get them back, then > they can trade the obligations and there will soon be trillions of IP4 > addresses on paper. There will be liquidity in the IP market. We are > not running out, we need liquidity, that's all. Sounds like something that would be a natural for Al Gore. "Collateralized IP Obligations"? I'm afraid to ask. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From sam at themerritts.org Fri May 28 11:06:56 2010 From: sam at themerritts.org (Sam Hayes Merritt, III) Date: Fri, 28 May 2010 11:06:56 -0500 (CDT) Subject: BT strike could affect internet and phone connections In-Reply-To: <2CE28CB1-F404-4A6C-829E-8F2F81B1D52C@cs.columbia.edu> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> <17804.1274995187@localhost> <987202.97348.qm@web59616.mail.ac4.yahoo.com> <4BFF7A7C.4060102@bogus.com> <2CE28CB1-F404-4A6C-829E-8F2F81B1D52C@cs.columbia.edu> Message-ID: On Fri, 28 May 2010, Steven Bellovin wrote: > The only people who can never strikes are public employees. I know we've left the realm of NANOG, but come again? Oakland teacher strike of 2010. various teacher strikes in the Chicago area over the years air traffic controllers in 1981 postal workers in 1978 1968 Memphis garbagemen 1974 Baltimore police strike 1969 Cicero, Illinois police strike 1919 Boston police strike 1980 Chicago firefighters strike sam From LarrySheldon at cox.net Fri May 28 11:14:33 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 28 May 2010 11:14:33 -0500 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <4BFFEBE9.9040201@cox.net> On 5/28/2010 07:37, Mark Hermsdorfer wrote: > Having said that, If the JunOS based SRX platform does not do session > tracking in the same was as the SSG platform it would seem that the most > reasonable solution would be to NAT the traffic as has already been pointed > out. Gonna really highlight my ignorance here, but.... Given the terminology (primary" and "secondary" or "standby" (I forget the exact terms used) in the OP, is it true that traffic arriving on the secondary when the primary is up is a bad thing? Given that to be true, is there no way in BGP to make the secondary look poorer than the primary? Or something. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From smb at cs.columbia.edu Fri May 28 11:38:54 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 28 May 2010 12:38:54 -0400 Subject: BT strike could affect internet and phone connections In-Reply-To: References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> <840456.96100.qm@web59602.mail.ac4.yahoo.com> <11023.1274984586@localhost> <767009.81922.qm@web59605.mail.ac4.yahoo.com> <17804.1274995187@localhost> <987202.97348.qm@web59616.mail.ac4.yahoo.com> <4BFF7A7C.4060102@bogus.com> <2CE28CB1-F404-4A6C-829E-8F2F81B1D52C@cs.columbia.edu> Message-ID: On May 28, 2010, at 12:06 56PM, Sam Hayes Merritt, III wrote: > > On Fri, 28 May 2010, Steven Bellovin wrote: > >> The only people who can never strikes are public employees. > > I know we've left the realm of NANOG, but come again? I should have added the word "legally", and then for most jurisdictions. > > Oakland teacher strike of 2010. > various teacher strikes in the Chicago area over the years > air traffic controllers in 1981 > postal workers in 1978 > 1968 Memphis garbagemen > 1974 Baltimore police strike > 1969 Cicero, Illinois police strike > 1919 Boston police strike > 1980 Chicago firefighters strike > > > sam > > --Steve Bellovin, http://www.cs.columbia.edu/~smb From mjkelly at gmail.com Fri May 28 11:51:51 2010 From: mjkelly at gmail.com (Matt Kelly) Date: Fri, 28 May 2010 12:51:51 -0400 Subject: ATT blocking issue.... Message-ID: <0163A1FC-4FB4-471A-AF56-D6104171DBE6@gmail.com> Can someone at ATT contact me off list to help with a problem? It appears you're blocking a /19 of ours from all mail delivery. Emails to postmaster and the normal web forms have gone unanswered. Thanks. -- Matt From cscora at apnic.net Fri May 28 13:09:51 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 29 May 2010 04:09:51 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201005281809.o4SI9pEK029536@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 29 May, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 321666 Prefixes after maximum aggregation: 148426 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 156760 Total ASes present in the Internet Routing Table: 34085 Prefixes per ASN: 9.44 Origin-only ASes present in the Internet Routing Table: 29586 Origin ASes announcing only one prefix: 14361 Transit ASes present in the Internet Routing Table: 4499 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 332 Unregistered ASNs in the Routing Table: 121 Number of 32-bit ASNs allocated by the RIRs: 591 Prefixes from 32-bit ASNs in the Routing Table: 675 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 162 Number of addresses announced to Internet: 2257820704 Equivalent to 134 /8s, 147 /16s and 156 /24s Percentage of available address space announced: 60.9 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 91.9 Percentage of address space in use by end-sites: 83.0 Total number of prefixes smaller than registry allocations: 153947 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 76876 Total APNIC prefixes after maximum aggregation: 26795 APNIC Deaggregation factor: 2.87 Prefixes being announced from the APNIC address blocks: 73868 Unique aggregates announced from the APNIC address blocks: 32526 APNIC Region origin ASes present in the Internet Routing Table: 4061 APNIC Prefixes per ASN: 18.19 APNIC Region origin ASes announcing only one prefix: 1119 APNIC Region transit ASes present in the Internet Routing Table: 631 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 520615232 Equivalent to 31 /8s, 7 /16s and 245 /24s Percentage of available APNIC address space announced: 77.6 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/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: 133880 Total ARIN prefixes after maximum aggregation: 68966 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 106763 Unique aggregates announced from the ARIN address blocks: 40970 ARIN Region origin ASes present in the Internet Routing Table: 13704 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5273 ARIN Region transit ASes present in the Internet Routing Table: 1348 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 731534880 Equivalent to 43 /8s, 154 /16s and 86 /24s Percentage of available ARIN address space announced: 62.3 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, 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, 54/8, 55/8, 56/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, 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: 74212 Total RIPE prefixes after maximum aggregation: 43045 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 67190 Unique aggregates announced from the RIPE address blocks: 44130 RIPE Region origin ASes present in the Internet Routing Table: 14487 RIPE Prefixes per ASN: 4.64 RIPE Region origin ASes announcing only one prefix: 7464 RIPE Region transit ASes present in the Internet Routing Table: 2168 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 428079040 Equivalent to 25 /8s, 131 /16s and 247 /24s Percentage of available RIPE address space announced: 75.0 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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/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, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28430 Total LACNIC prefixes after maximum aggregation: 6826 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 26846 Unique aggregates announced from the LACNIC address blocks: 14057 LACNIC Region origin ASes present in the Internet Routing Table: 1295 LACNIC Prefixes per ASN: 20.73 LACNIC Region origin ASes announcing only one prefix: 398 LACNIC Region transit ASes present in the Internet Routing Table: 227 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 24 Number of LACNIC addresses announced to Internet: 73279744 Equivalent to 4 /8s, 94 /16s and 41 /24s Percentage of available LACNIC address space announced: 72.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7359 Total AfriNIC prefixes after maximum aggregation: 1852 AfriNIC Deaggregation factor: 3.97 Prefixes being announced from the AfriNIC address blocks: 5668 Unique aggregates announced from the AfriNIC address blocks: 1668 AfriNIC Region origin ASes present in the Internet Routing Table: 363 AfriNIC Prefixes per ASN: 15.61 AfriNIC Region origin ASes announcing only one prefix: 107 AfriNIC Region transit ASes present in the Internet Routing Table: 82 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 15 Number of AfriNIC addresses announced to Internet: 17983744 Equivalent to 1 /8s, 18 /16s and 105 /24s Percentage of available AfriNIC address space announced: 53.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1847 8422 483 Korea Telecom (KIX) 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1310 293 153 TATA Communications formerly 7545 1279 232 104 TPG Internet Pty Ltd 17974 1067 281 19 PT TELEKOMUNIKASI INDONESIA 9583 1001 74 491 Sify Limited 24560 907 306 171 Bharti Airtel Ltd., Telemedia 4134 875 21259 406 CHINANET-BACKBONE 4808 848 1571 213 CNCGROUP IP network: China169 9829 797 681 34 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3922 3733 287 bellsouth.net, inc. 4323 3364 1116 404 Time Warner Telecom 1785 1787 699 130 PaeTec Communications, Inc. 20115 1528 1498 656 Charter Communications 7018 1515 5735 965 AT&T WorldNet Services 2386 1285 569 914 AT&T Data Communications Serv 6478 1252 257 97 AT&T Worldnet Services 3356 1186 10883 405 Level 3 Communications, LLC 22773 1155 2604 64 Cox Communications, Inc. 11492 1149 207 70 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 628 56 6 United Telecom of Georgia 3292 454 2028 395 TDC Tele Danmark 30890 444 116 208 Evolva Telecom 702 415 1869 330 UUNET - Commercial IP service 8551 402 355 38 Bezeq International 8866 399 117 18 Bulgarian Telecommunication C 3301 368 1414 323 TeliaNet Sweden 3320 365 7072 318 Deutsche Telekom AG 34984 358 88 183 BILISIM TELEKOM 12479 337 576 5 Uni2 Autonomous System Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1522 2965 245 UniNet S.A. de C.V. 10620 1050 236 151 TVCABLE BOGOTA 28573 893 724 77 NET Servicos de Comunicao S.A 7303 730 377 107 Telecom Argentina Stet-France 6503 588 174 209 AVANTEL, S.A. 22047 545 310 15 VTR PUNTO NET S.A. 7738 477 922 30 Telecomunicacoes da Bahia S.A 3816 473 204 73 Empresa Nacional de Telecomun 14117 455 30 13 Telefonica del Sur S.A. 11172 443 99 71 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1283 445 10 TEDATA 24863 713 147 39 LINKdotNET AS number 36992 638 278 185 Etisalat MISR 3741 270 852 231 The Internet Solution 2018 217 231 112 Tertiary Education Network 33776 213 11 14 Starcomms Nigeria Limited 6713 176 167 12 Itissalat Al-MAGHRIB 24835 176 78 10 RAYA Telecom - Egypt 29571 172 19 9 Ci Telecom Autonomous system 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3922 3733 287 bellsouth.net, inc. 4323 3364 1116 404 Time Warner Telecom 4766 1847 8422 483 Korea Telecom (KIX) 1785 1787 699 130 PaeTec Communications, Inc. 20115 1528 1498 656 Charter Communications 8151 1522 2965 245 UniNet S.A. de C.V. 7018 1515 5735 965 AT&T WorldNet Services 17488 1316 140 123 Hathway IP Over Cable Interne 4755 1310 293 153 TATA Communications formerly 2386 1285 569 914 AT&T Data Communications Serv Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 3364 2960 Time Warner Telecom 1785 1787 1657 PaeTec Communications, Inc. 4766 1847 1364 Korea Telecom (KIX) 8151 1522 1277 UniNet S.A. de C.V. 8452 1283 1273 TEDATA 17488 1316 1193 Hathway IP Over Cable Interne 7545 1279 1175 TPG Internet Pty Ltd 4755 1310 1157 TATA Communications formerly 6478 1252 1155 AT&T Worldnet Services 22773 1155 1091 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.0.0.0/8 237 Merit Network 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.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:21 /9:10 /10:26 /11:67 /12:194 /13:402 /14:692 /15:1274 /16:11080 /17:5285 /18:8994 /19:18272 /20:22581 /21:22622 /22:29517 /23:29210 /24:168435 /25:964 /26:1259 /27:628 /28:108 /29:10 /30:7 /31:0 /32:8 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2513 3922 bellsouth.net, inc. 4323 1850 3364 Time Warner Telecom 4766 1479 1847 Korea Telecom (KIX) 1785 1251 1787 PaeTec Communications, Inc. 8452 1170 1283 TEDATA 11492 1063 1149 Cable One 17488 1063 1316 Hathway IP Over Cable Interne 18566 1040 1059 Covad Communications 10620 966 1050 TVCABLE BOGOTA 7018 908 1515 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1 4:13 8:261 12:2012 13:10 14:1 15:23 16:3 17:8 20:21 24:1424 27:111 31:1 32:47 33:12 38:673 40:98 41:2520 44:3 47:26 52:8 55:7 56:2 57:24 58:728 59:503 60:456 61:1080 62:1062 63:1974 64:3612 65:2348 66:4251 67:1826 68:1113 69:2855 70:714 71:243 72:1824 73:2 74:2093 75:253 76:309 77:863 78:624 79:425 80:1010 81:801 82:480 83:448 84:691 85:1058 86:466 87:693 88:333 89:1552 90:90 91:2776 92:505 93:1112 94:1423 95:598 96:280 97:315 98:566 99:28 108:32 109:492 110:360 111:500 112:263 113:296 114:411 115:578 116:1035 117:645 118:444 119:934 120:142 121:741 122:1436 123:913 124:1104 125:1315 128:211 129:210 130:193 131:559 132:247 133:17 134:196 135:45 136:222 137:171 138:256 139:103 140:482 141:136 142:353 143:386 144:475 145:52 146:424 147:165 148:611 149:291 150:153 151:169 152:261 153:168 154:2 155:326 156:156 157:325 158:107 159:374 160:315 161:179 162:258 163:180 164:407 165:348 166:473 167:398 168:781 169:165 170:710 171:53 172:2 173:767 174:661 175:92 176:1 178:145 180:479 182:79 183:128 184:45 186:392 187:345 188:1343 189:794 190:3662 192:5749 193:4695 194:3355 195:2783 196:1202 198:3564 199:3430 200:5365 201:1508 202:8017 203:8307 204:4066 205:2332 206:2526 207:3042 208:3889 209:3412 210:2508 211:1243 212:1748 213:1688 214:656 215:69 216:4659 217:1536 218:488 219:378 220:1123 221:399 222:316 223:1 End of report From guxiaojian at gmail.com Fri May 28 15:49:10 2010 From: guxiaojian at gmail.com (Jian Gu) Date: Fri, 28 May 2010 13:49:10 -0700 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: Then you should look at your IGP, right? On Fri, May 28, 2010 at 8:09 AM, Ken Gilmour wrote: > Hi Jian, > > Yes sir that's what I thought too. The packets are being NATted (and I also > used a bit of DNAT for port forwarding to test the theory) but the result is > the same. > > Regards, > > Ken > > On 27 May 2010 23:46, Jian Gu wrote: >> >> Wouldn't simply configure source NAT on firewall 2.2.2.1 resolve the >> problem gracefully? when connection requests coming in through ISP2, >> source NAT the incoming traffic's source IP with IPs on firewall >> inside interface, that way when server replies, firewall 2.2.2.1 will >> guarantee to receive the ACK because ACK traffic won't follow default >> routing to ISP1. >> >> On Thu, May 27, 2010 at 4:27 PM, Ken Gilmour >> wrote: >> > Hi all, >> > >> > I have a very peculiar situation here that i seem to have difficulty >> > explaining in such a way for people to understand. I just got off the >> > phone >> > to the Juniper Devs after about 4 hours with no result. They understand >> > the >> > problem but can't seem to think of a working solution (last solution led >> > to >> > the primary firewall hard crashing and then failing over after a commit >> > (which also makes me wonder what made the primary crash and not the >> > secondary)). I am wondering if there is anyone "creative" on the list >> > who >> > has encountered and worked around this problem before... >> > >> > Here goes *sigh* >> > >> > ISP1 - 1.1.1.0/24 >> > ISP2 - 2.2.2.0/24 >> > >> > ISP1 is the default gateway, ISP2 is a backup provider but which is >> > always >> > active. Client comes in on ISP1's link, traffic goes back out on ISP1s >> > link. >> > Client comes in on ISP2's link (non default gateway) but for some >> > reason, >> > the packets seem to be going back out through the link for ISP1. >> > >> > So look at it this way: >> > >> > SYN comes from client at 3.3.3.3 aimed at 2.2.2.2, packet is received by >> > the >> > firewall. Firewall sends a SYN/ACK but the firewall at 1.1.1.1 sees it >> > in >> > TCPDump, the firewall at 2.2.2.1 never sees it. >> > >> > Here's a log snippet (I can send you more if you need: >> > >> > May 27 21:38:49 21:38:48.1509569:CID-1:RT: ?route lookup: dest-ip >> > 3.3.3.3 *orig >> > ifp reth3.0* *output_ifp reth2.0* orig-zone 19 out-zone 19 vsd 3 >> > >> > You will see that the orig and out zones are the same zone, however this >> > was >> > a last ditch effort (putting both interfaces into one zone, effectively >> > creating a swamp). >> > >> > Our current (non-preferred) solution is to put match-all rules on our >> > Catalyst 6513s and put both providers into a swamp and the switch will >> > then >> > intercept the packets if they are destined for the wrong interface and >> > send >> > them out the right one based on a bunch of boolean. >> > >> > We've tried setting up a virtual instance on the offending interface and >> > a >> > firewall filter, but this had little to no effect (at one point it >> > stopped >> > passing the packets to the end machine altogether). We're using small >> > SRX >> > 650ies. Why do we want to do it this way you ask? In the event of a BGP >> > session failure we need to be able to use our statically routed IPs and >> > rely >> > on someone else. >> > >> > Thanks! >> > >> > Ken >> > > > From fw at deneb.enyo.de Fri May 28 16:27:28 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 28 May 2010 23:27:28 +0200 Subject: Junos Asymmetric Routing In-Reply-To: (Ken Gilmour's message of "Thu, 27 May 2010 17:27:16 -0600") References: Message-ID: <874ohrd8e7.fsf@mid.deneb.enyo.de> * Ken Gilmour: > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. You cannot use Juniper's software forwarding platforms in this scenario. This may sound like a drastic verdict, but I think it's a pretty accurate summary of the situation. Perhaps you can coax the software forwarding platforms into packet mode (instead of flow mode), but from the documentation, I get the feeling that Juniper doesn't want you to do that (at least on J-series). You also lose some functionality if you do that. Moving the filters to a different box doesn't help, either. So you either have to buy real Juniper routers (and the necessary service modules to implement this), or switch vendors. From jeroen at mompl.net Fri May 28 16:39:51 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 28 May 2010 14:39:51 -0700 Subject: Reputable VPS provider with Dutch static IPs Message-ID: <4C003827.2050300@mompl.net> Does anyone know a reputable virtual private server provider in the Netherlands, which provides static IPs that are located in the Netherlands according to those pesky geoIP checkers. It also should provide Debian stable (Lenny right now) and not cost more than ~$30 a month. Of course the company should not have problems dealing with international customers (Dutch organisations can be a bit anal sometimes :-). Thank you, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From dougb at dougbarton.us Fri May 28 16:42:12 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 28 May 2010 14:42:12 -0700 Subject: .mil dns problems? In-Reply-To: References: Message-ID: <4C0038B4.7050702@dougbarton.us> On 05/27/10 12:16, Antonio Querubin wrote: > Anyone seeing trouble resolving some .mil hostnames consistently today? > Specifically those below: > > www.dco.dod.mil > www.my.af.mil I'm seeing A records for both of these locally, the 2nd one is even Akamai'zed. :) hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From cidr-report at potaroo.net Fri May 28 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 May 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201005282200.o4SM02CQ079516@wattle.apnic.net> BGP Update Report Interval: 20-May-10 -to- 27-May-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS14420 33287 3.0% 80.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 2 - AS5800 20231 1.8% 112.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 3 - AS4323 15200 1.4% 4.9 -- TWTC - tw telecom holdings, inc. 4 - AS8452 11866 1.1% 12.8 -- TEDATA TEDATA 5 - AS4538 10961 1.0% 142.4 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS28477 10079 0.9% 1119.9 -- Universidad Autonoma del Esstado de Morelos 7 - AS24560 9762 0.9% 10.9 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS32528 9270 0.8% 1854.0 -- ABBOTT Abbot Labs 9 - AS17974 7985 0.7% 13.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS6389 7570 0.7% 2.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS17488 7389 0.7% 5.7 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 12 - AS30890 7367 0.7% 17.1 -- EVOLVA Evolva Telecom s.r.l. 13 - AS36992 7336 0.7% 12.2 -- ETISALAT-MISR 14 - AS9829 7155 0.7% 18.6 -- BSNL-NIB National Internet Backbone 15 - AS35805 6929 0.6% 11.0 -- UTG-AS United Telecom AS 16 - AS3549 6595 0.6% 80.4 -- GBLX Global Crossing Ltd. 17 - AS10697 5894 0.5% 267.9 -- Interlink S.R.L. 18 - AS5786 5877 0.5% 31.8 -- UPRENET - University of Puerto Rico 19 - AS20115 5456 0.5% 7.0 -- CHARTER-NET-HKY-NC - Charter Communications 20 - AS9394 5391 0.5% 5.1 -- CRNET CHINA RAILWAY Internet(CRNET) TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS50788 2657 0.2% 2657.0 -- OSYPENKO-AS FOP Osypenko Vitalij Volodymyrovych 2 - AS32528 9270 0.8% 1854.0 -- ABBOTT Abbot Labs 3 - AS48754 1784 0.2% 1784.0 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 4 - AS38680 1531 0.1% 1531.0 -- CMBHK-AS-KR CMB 5 - AS28477 10079 0.9% 1119.9 -- Universidad Autonoma del Esstado de Morelos 6 - AS27067 2170 0.2% 1085.0 -- DNIC-ASBLK-27032-27159 - DoD Network Information Center 7 - AS18399 3901 0.3% 975.2 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 8 - AS11613 778 0.1% 778.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 9 - AS29493 711 0.1% 711.0 -- GRIDPNPI Institution of Russian Science Academy Petersburg Nuclear Physics Institute of B.P. Konstantinov RAN 10 - AS39342 602 0.1% 602.0 -- MEDIATRAFFIC Mediatraffic Oy as-number 11 - AS28052 522 0.1% 522.0 -- Arte Radiotelevisivo Argentino 12 - AS47348 452 0.0% 452.0 -- PEACE_GLOBAL Peace Global Satellite Communications Limited 13 - AS5573 1697 0.1% 424.2 -- KRASNET-AS KRASNET Regional Telecommunications Network 14 - AS10445 2456 0.2% 409.3 -- HTG - Huntleigh Telcom 15 - AS9120 407 0.0% 407.0 -- COHAESIONET Cohaesio A/S 16 - AS39984 374 0.0% 374.0 -- STARZENTERTAINMENT - Starz Entertainment Group LLC 17 - AS37144 358 0.0% 358.0 -- VALUCARD-NG 18 - AS34205 315 0.0% 315.0 -- MRBD-AS Far East Telecommunications Company 19 - AS50037 299 0.0% 299.0 -- SERVERKURSK-AS Server Ltd. 20 - AS30402 575 0.1% 287.5 -- HARRIS - Harris Interactive Inc. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 58.207.96.0/19 10746 0.9% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 2 - 200.13.36.0/24 10055 0.8% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 64.76.40.0/24 6122 0.5% AS3549 -- GBLX Global Crossing Ltd. 4 - 130.36.34.0/24 4602 0.4% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 4602 0.4% AS32528 -- ABBOTT Abbot Labs 6 - 203.81.166.0/24 3071 0.3% AS18399 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit 7 - 143.138.107.0/24 3025 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 8 - 206.184.16.0/24 3001 0.2% AS174 -- COGENT Cogent/PSI 9 - 200.50.186.0/24 2847 0.2% AS10697 -- Interlink S.R.L. 10 - 200.50.187.0/24 2811 0.2% AS10697 -- Interlink S.R.L. 11 - 193.107.224.0/22 2657 0.2% AS50788 -- OSYPENKO-AS FOP Osypenko Vitalij Volodymyrovych 12 - 111.68.29.0/24 2331 0.2% AS45324 -- GMEDIA-AS-ID Global Media Teknologi, PT AS4800 -- LINTASARTA-AS-AP Network Access Provider and Internet Service Provider 13 - 91.212.23.0/24 1784 0.1% AS48754 -- SOBIS-AS SC SOBIS SOLUTIONS SRL 14 - 180.233.225.0/24 1531 0.1% AS38680 -- CMBHK-AS-KR CMB 15 - 202.92.235.0/24 1461 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 214.13.40.0/21 1240 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - 214.27.74.0/23 1154 0.1% AS5800 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - 213.228.107.0/24 1141 0.1% AS5573 -- KRASNET-AS KRASNET Regional Telecommunications Network 19 - 124.14.64.0/18 1090 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange 20 - 220.113.32.0/20 1090 0.1% AS4847 -- CNIX-AP China Networks Inter-Exchange Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu 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 May 28 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 28 May 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201005282200.o4SM00Fq079508@wattle.apnic.net> This report has been generated at Fri May 28 21:11:35 2010 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 21-05-10 323888 199085 22-05-10 323862 198966 23-05-10 323771 199305 24-05-10 323937 199731 25-05-10 324054 199837 26-05-10 324186 200482 27-05-10 324293 200645 28-05-10 324653 200477 AS Summary 34500 Number of ASes in routing system 14648 Number of ASes announcing only one prefix 4462 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95847488 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'). --- 28May10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 324765 200492 124273 38.3% All ASes AS6389 3921 295 3626 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4462 1413 3049 68.3% TWTC - tw telecom holdings, inc. AS4766 1847 497 1350 73.1% KIXS-AS-KR Korea Telecom AS22773 1155 69 1086 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1310 235 1075 82.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1059 34 1025 96.8% COVAD - Covad Communications Co. AS17488 1316 309 1007 76.5% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6478 1253 344 909 72.5% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1522 622 900 59.1% Uninet S.A. de C.V. AS19262 1123 271 852 75.9% VZGNI-TRANSIT - Verizon Internet Services Inc. AS8452 1298 451 847 65.3% TEDATA TEDATA AS10620 1050 230 820 78.1% Telmex Colombia S.A. AS7545 1298 574 724 55.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS5668 846 136 710 83.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS7303 729 114 615 84.4% Telecom Argentina S.A. AS4808 843 229 614 72.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS1785 1787 1182 605 33.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS4804 678 84 594 87.6% MPX-AS Microplex PTY LTD AS7018 1518 973 545 35.9% ATT-INTERNET4 - AT&T WorldNet Services AS35805 628 111 517 82.3% UTG-AS United Telecom AS AS4780 665 166 499 75.0% SEEDNET Digital United Inc. AS3356 1187 691 496 41.8% LEVEL3 Level 3 Communications AS17676 572 81 491 85.8% GIGAINFRA Softbank BB Corp. AS9443 559 75 484 86.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS33588 606 125 481 79.4% BRESNAN-AS - Bresnan Communications, LLC. AS7011 1121 653 468 41.7% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS24560 907 455 452 49.8% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 893 445 448 50.2% NET Servicos de Comunicao S.A. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. AS36992 638 208 430 67.4% ETISALAT-MISR Total 37268 11102 26166 70.2% Top 30 total Possible Bogus Routes 31.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 63.140.213.0/24 AS22555 UTC - Universal Talkware Corporation 63.143.251.0/24 AS22555 UTC - Universal Talkware Corporation 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 78.41.80.0/24 AS29158 DE-IP69 Tux-Service 78.41.81.0/24 AS29158 DE-IP69 Tux-Service 78.41.82.0/24 AS29158 DE-IP69 Tux-Service 78.41.83.0/24 AS29158 DE-IP69 Tux-Service 78.41.84.0/24 AS29158 DE-IP69 Tux-Service 78.41.86.0/24 AS29158 DE-IP69 Tux-Service 78.41.87.0/24 AS29158 DE-IP69 Tux-Service 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 119.160.200.0/23 AS45122 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/8 AS237 MERIT-ASN Merit Network Inc. 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS2905 TICSA-ASN 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.0.0/18 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.233.129.0/24 AS4378 HOSTINGCOM - WCP/32POINTS INTERMEDIATE HOLDING COMPANY, INC. 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 200.108.176.0/20 AS14551 UUNET-SA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.128.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.89.8.0/22 AS6648 BAYAN-TELECOMMUNICATIONS Bayan Telecommunications, Inc. 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 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.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.15.168.0/21 AS46753 TDAMERITRADETRUST - TD Ameritrade Trust 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 CYBERSURF - Cybersurf Inc. 205.210.145.0/24 AS11814 CYBERSURF - Cybersurf Inc. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 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.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.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.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.77.224.0/22 AS174 COGENT Cogent/PSI 208.77.229.0/24 AS174 COGENT Cogent/PSI 208.77.230.0/23 AS174 COGENT Cogent/PSI 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 212.114.96.0/19 AS12859 NL-BIT BIT BV 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.163.144.0/20 AS35985 ONERINGNET-ATL-1 - One Ring Networks, Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From andy at nosignal.org Sat May 29 04:23:47 2010 From: andy at nosignal.org (Andy Davidson) Date: Sat, 29 May 2010 10:23:47 +0100 Subject: BT strike could affect internet and phone connections In-Reply-To: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> References: <5086911.61274975289487.JavaMail.root@jennyfur.pelican.org> Message-ID: <856A72E5-D382-4288-AEE1-343758D58B24@nosignal.org> On 27 May 2010, at 16:48, Tim Franklin wrote: >> Internet and phone connections across Britain could go into meltdown >> as BT workers threaten their first national strike for 23 years... > I get a lovely vision from that of a real old-style manual switchboard > operator, frantically plugging internet connections together with patch > cords as each SYN packet rings a little bell. So off-topic it hurts, but... http://www.youtube.com/watch?v=AgqEIp2YmtE Andy > From strizhov at cs.colostate.edu Sat May 29 06:20:46 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Sat, 29 May 2010 05:20:46 -0600 Subject: 2010 RM IPv6 Summit Message-ID: <4C00F88E.8000406@cs.colostate.edu> Lots of interesting talks at the Rocky Mountain IPv6 summit: http://www.rmv6tf.org/SpringEvent2010.htm -- Sincerely, Mikhail Strizhov. From andy at nosignal.org Sun May 30 02:10:48 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 30 May 2010 08:10:48 +0100 Subject: MRLG Missing? In-Reply-To: <4BFEC9C9.5070204@noelcomm.com> References: <4BFEC9C9.5070204@noelcomm.com> Message-ID: <42D3C0EB-E54C-445E-9F75-4020FB5E2FFC@nosignal.org> On 27 May 2010, at 20:36, Kyle Duren wrote: > I know we just had a small discussion about this, looking glass stuff > and such, but I had a copy of MRLG (the one from John Fraizer - > OP-SEC.US) a while ago about I cannot seem to find the tarball anymore. > The op-sec site appears to be dead, and so is a mirror site someone else > put online a while ago (https://arpa.com/code/mrlg-5.4.1.tgz). Does > anyone know what happened to John and his version of MRLG, Is this the main distribution ? I don't have the original tarball, but I have a hacked-on version of 5.4.1 in production. I added in ipv6 command support for LONAP's MRLG install - http://www.lonap.net/cgi-bin/mrlg.cgi I can send you this version if you would like it. Andy From andy at nosignal.org Sun May 30 06:16:22 2010 From: andy at nosignal.org (Andy Davidson) Date: Sun, 30 May 2010 12:16:22 +0100 Subject: Junos Asymmetric Routing In-Reply-To: References: Message-ID: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> On 28 May 2010, at 00:27, Ken Gilmour wrote: > ISP1 is the default gateway, ISP2 is a backup provider but which is always > active. Client comes in on ISP1's link, traffic goes back out on ISP1s link. > Client comes in on ISP2's link (non default gateway) but for some reason, > the packets seem to be going back out through the link for ISP1. This is perfectly normal and acceptable. The problem you are having (the traffic ultimately disappearing) is that bad behaviour is happening, caused by flow-mode. It does not work. Juniper trying to force flow-mode in J-series since 9.4 has helped our Cisco mid-range hardware sales no end. Are you reading Juniper ? It does not work ! Anyway, I digress. You need to put a filter on your interfaces that references a filter later on to not session track a flow. I think you need to be running Junos-jsr[0] 10.0 or 10.1 to use this : interfaces { ge-0/0/X { family inet { filter { input [ packet-mode-in ....... ] output [ packet-mode-out ......... ] } } } } firewall { family inet { filter packet-mode-out { term stuff { from { something } then { packet-mode; accept; } } } } } When we were trying to make this work reliably in the References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> Message-ID: > You need to put a filter on your interfaces that references a filter later on to not session track a flow. ?I think you need to be running Junos-jsr[0] 10.0 or 10.1 to use this : The same goes for 9.x, just be sure to except traffic to the router (like BGP session) from the packet-mode, they need to be in flow mode. Traffic routed from one interface to another can be in packet mode. Rubens From fw at deneb.enyo.de Sun May 30 11:12:44 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 30 May 2010 18:12:44 +0200 Subject: Junos Asymmetric Routing In-Reply-To: (Rubens Kuhl's message of "Sun, 30 May 2010 12:57:13 -0300") References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> Message-ID: <87vda5z7ur.fsf@mid.deneb.enyo.de> * Rubens Kuhl: >> You need to put a filter on your interfaces that references a >> filter later on to not session track a flow. ?I think you need to >> be running Junos-jsr[0] 10.0 or 10.1 to use this : > > The same goes for 9.x, just be sure to except traffic to the router > (like BGP session) from the packet-mode, they need to be in flow mode. > Traffic routed from one interface to another can be in packet mode. And that's totally broken because your perfectly fine multihop BGP session could break when rerouting occurs. *sigh* From randy at psg.com Sun May 30 11:39:39 2010 From: randy at psg.com (Randy Bush) Date: Sun, 30 May 2010 18:39:39 +0200 Subject: Junos Asymmetric Routing In-Reply-To: <87vda5z7ur.fsf@mid.deneb.enyo.de> References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> <87vda5z7ur.fsf@mid.deneb.enyo.de> Message-ID: > your perfectly fine multihop BGP session could break when rerouting > occurs. one of the many reasons that there are no perfectly fine multi-hop bgp sessions. randy From fw at deneb.enyo.de Sun May 30 11:46:45 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 30 May 2010 18:46:45 +0200 Subject: Junos Asymmetric Routing In-Reply-To: (Randy Bush's message of "Sun, 30 May 2010 18:39:39 +0200") References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> <87vda5z7ur.fsf@mid.deneb.enyo.de> Message-ID: <8739x9xrpm.fsf@mid.deneb.enyo.de> * Randy Bush: >> your perfectly fine multihop BGP session could break when rerouting >> occurs. > > one of the many reasons that there are no perfectly fine multi-hop bgp > sessions. Uhm, is there a way around them when building the iBGP mesh? From randy at psg.com Sun May 30 11:49:00 2010 From: randy at psg.com (Randy Bush) Date: Sun, 30 May 2010 18:49:00 +0200 Subject: Junos Asymmetric Routing In-Reply-To: <8739x9xrpm.fsf@mid.deneb.enyo.de> References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> <87vda5z7ur.fsf@mid.deneb.enyo.de> <8739x9xrpm.fsf@mid.deneb.enyo.de> Message-ID: >>> your perfectly fine multihop BGP session could break when rerouting >>> occurs. >> one of the many reasons that there are no perfectly fine multi-hop bgp >> sessions. > Uhm, is there a way around them when building the iBGP mesh? nope From rubensk at gmail.com Sun May 30 11:49:17 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 30 May 2010 13:49:17 -0300 Subject: Junos Asymmetric Routing In-Reply-To: <8739x9xrpm.fsf@mid.deneb.enyo.de> References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> <87vda5z7ur.fsf@mid.deneb.enyo.de> <8739x9xrpm.fsf@mid.deneb.enyo.de> Message-ID: On Sun, May 30, 2010 at 1:46 PM, Florian Weimer wrote: > * Randy Bush: > >>> your perfectly fine multihop BGP session could break when rerouting >>> occurs. >> >> one of the many reasons that there are no perfectly fine multi-hop bgp >> sessions. > > Uhm, is there a way around them when building the iBGP mesh? Not using flow-based devices as datagram routers when they aren't ? Rubens From fw at deneb.enyo.de Sun May 30 11:54:59 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 30 May 2010 18:54:59 +0200 Subject: Junos Asymmetric Routing In-Reply-To: (Rubens Kuhl's message of "Sun, 30 May 2010 13:49:17 -0300") References: <89CEA058-1CA1-4DCF-A0B1-4F9197641CB0@nosignal.org> <87vda5z7ur.fsf@mid.deneb.enyo.de> <8739x9xrpm.fsf@mid.deneb.enyo.de> Message-ID: <878w71wcrg.fsf@mid.deneb.enyo.de> * Rubens Kuhl: > On Sun, May 30, 2010 at 1:46 PM, Florian Weimer wrote: >> * Randy Bush: >> >>>> your perfectly fine multihop BGP session could break when rerouting >>>> occurs. >>> >>> one of the many reasons that there are no perfectly fine multi-hop bgp >>> sessions. >> >> Uhm, is there a way around them when building the iBGP mesh? > > Not using flow-based devices as datagram routers when they aren't ? Then the sessions are still multi-hop. 8-) Flow-based forwarding is only bad if you notice it. Usually, that happens with random packets you don't want to forward anyway, but Juniper managed to build something that's unusable in a fairly wide range of scenarios. From oberman at es.net Sun May 30 12:16:14 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 30 May 2010 10:16:14 -0700 Subject: Junos Asymmetric Routing In-Reply-To: Your message of "Sun, 30 May 2010 18:39:39 +0200." Message-ID: <20100530171614.B57F71CC2A@ptavv.es.net> > Date: Sun, 30 May 2010 18:39:39 +0200 > From: Randy Bush > > > your perfectly fine multihop BGP session could break when rerouting > > occurs. > > one of the many reasons that there are no perfectly fine multi-hop bgp > sessions. I remember a posting to this list back in the late 90s from Tony Li, who knows a bit about BGP. He urged that multi-hop BGP never be used and pointed out that it had not been intended for use except as a test tool, not a production one and should have been stripped from IOS before it was shipped. While there are a few good cases for using it, it is generally a bad, bad idea. And this thread demonstrates that he had reason for the warning -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From rens at autempspourmoi.be Mon May 31 09:05:35 2010 From: rens at autempspourmoi.be (Rens) Date: Mon, 31 May 2010 16:05:35 +0200 Subject: IPv4 Multicast In-Reply-To: References: <1323717.33065.1274453522694.JavaMail.lanson9@127.0.0.1><03738BA62965416C8CE5B7A375B81A45@EU.corp.clearwire.com> Message-ID: <574DFD71DEF04BA08A46CC3BC908FBEA@EU.corp.clearwire.com> Something weird today when I did some more tests today... When I configured a subinterface with the: ip pim sparse-mode (config)#int GigabitEthernet 3/0.310 (config-subif)#ip pim sparse-mode May 31 15:48:40.218 CET: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 10.11.130.1 on interface GigabitEthernet3/0.310 At that point all my L2TPv3 tunnels on the other subinterfaces on Gi3 stopped working. When I removed the command, everything came back up again. Is this a bug or am I missing something? Regards, Rens -----Original Message----- From: Rens [mailto:rens at autempspourmoi.be] Sent: mercredi 26 mai 2010 16:59 To: 'Everton Marques' Cc: nanog at nanog.org; 'Jamie Sobczyk' Subject: RE: IPv4 Multicast One more question: If I would now connect another switch (WS-C3524-XL) between the VLC receiver and the 3560G like this: VLC receiver - 3524XL - 3560G - 1841 - 1841 - 4503 - VLC sender That 3524XL only supports CGMP, what do I need to change on the config to not broadcast this multicast traffic? Do I need to configure the ip cgmp router-only on the 1841 at Receiver? -----Original Message----- From: Rens [mailto:rens at autempspourmoi.be] Sent: mercredi 26 mai 2010 16:10 To: 'Everton Marques' Cc: nanog at nanog.org; 'Jamie Sobczyk' Subject: RE: IPv4 Multicast Woot! It was the TTL on the VLC sender that was on default, changed it to 10 and now and I have my video. Thanks for your help. _____ From: Everton Marques [mailto:everton.marques at gmail.com] Sent: mercredi 26 mai 2010 15:42 To: Rens Cc: Jamie Sobczyk; nanog at nanog.org Subject: Re: IPv4 Multicast Does "show ip mroute count" on the 1841 (RP) display activity on traffic counters? Is the VLC sender directing multicast to the 1841 (RP) thru a default route? Is the VLC sender issuing multicast packets with a high-enough multicast TTL ? Everton On Wed, May 26, 2010 at 10:21 AM, Rens wrote: I have all those things you mentioned below. The VLC server (10.0.1.2) sends out 2 streams on 239.255.0.1 & 239.255.0.2 I see both in SAP, when I try to join 239.255.0.2, nothing happens in VLC and below you have the output of my routers & switches at that time: On my RP router I see for show ip mroute: (*, 239.255.255.255), 5d04h/00:03:26, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:41 (10.0.1.2, 239.255.255.255), 1d06h/00:03:28, flags: LT Incoming interface: FastEthernet0/0.200, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:26 (*, 239.255.0.2), 00:01:10/00:03:19, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:10/00:03:19 (*, 239.255.255.250), 00:07:19/00:03:07, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:07:22/00:03:03 (*, 239.195.255.255), 1d06h/00:02:39, RP 172.16.0.2, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:01:24/00:02:39 (*, 224.2.127.254), 5d04h/00:03:10, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:03:10 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:38 (*, 224.0.1.40), 5d04h/00:02:40, RP 172.16.0.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 1d06h/00:02:59 FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:40 On my other router I have: (*, 239.255.255.255), 5d04h/stopped, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:54 (10.0.1.2, 239.255.255.255), 1d06h/00:02:58, flags: LJT Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 1d06h/00:02:54 (*, 239.255.0.2), 00:01:55/00:02:56, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:01:55/00:02:56 (*, 239.255.255.250), 00:08:04/00:02:53, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:08:04/00:02:53 (*, 239.195.255.255), 5d04h/00:02:50, RP 172.16.0.2, flags: SJC Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 00:02:08/00:02:50 (*, 224.2.127.254), 5d04h/00:02:48, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:48 (*, 224.0.1.40), 5d04h/00:02:52, RP 172.16.0.2, flags: SJCL Incoming interface: FastEthernet0/1, RPF nbr 192.168.0.2 Outgoing interface list: FastEthernet0/0.200, Forward/Sparse, 5d04h/00:02:52 On the switch where the RP is connected: Vlan Group Version Port List --------------------------------------------------------- 200 224.0.1.40 v2 Gi2/24 200 224.2.127.254 v2 Gi2/24 200 239.255.255.255v2 Gi2/24 On the switch where the receiver is connected: Vlan Group Type Version Port List ----------------------------------------------------------------------- 200 224.0.1.40 igmp v2 Gi0/24 200 224.2.127.254 igmp v2 Gi0/1, Gi0/24 200 239.195.255.255 igmp v2 Gi0/1, Gi0/24 200 239.255.0.2 igmp v2 Gi0/1, Gi0/24 200 239.255.255.250 igmp v2 Gi0/2, Gi0/24 200 239.255.255.255 igmp v2 Gi0/1, Gi0/24 -----Original Message----- From: Jamie Sobczyk [mailto:lanson9 at cox.net] Sent: vendredi 21 mai 2010 16:52 To: rens at autempspourmoi.be Cc: nanog at nanog.org Subject: RE: IPv4 Multicast Make sure you have "ip multicast-routing" on both routers. On the router interfaces, make sure you have "ip pim sparse-mode" On both routers, make sure you have the same rp address assigned and that you can ping this ip address from both routers. (I prefer to make it a loopback interface) "ip pim rp-address w.x.y.z" Also, make sure that routing is setup on your routers so that your receiver can ping your sender. On your routers you should be able to see the source unicast address and multicast address by typing "show ip mroute" you should see something like this: (*, 239.192.3.47), 7w0d/00:02:59, RP 10.31.0.1, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Port-channel15, Forward/Sparse, 7w0d/00:02:59, H (10.5.9.51, 239.192.3.47), 4w5d/00:03:27, flags: TA Incoming interface: Port-channel15, RPF nbr 10.7.193.138 Outgoing interface list: Port-channel17, Forward/Sparse, 4w5d/00:02:49, H On your switches, with igmp snooping enabled, you should be able to type: "show ip igmp snooping group" and see something like Vlan Group Type Version Port List ----------------------------------------------------------------------- 24 239.192.3.47 igmp v2 Gi1/0/21 That port listed is the port of the requester. -----Original Message----- I have setup a lab for this multicast. VLC receiver - 3560G - 1841 - 1841 - 4503 - VLC sender The 2 switches only provide L2 access, they have IGMP snooping active On both 1841's I have pim parse-mode & sap listen on all interfaces + configured a static RP, the one closest to the sender. With my VLC receiver I can see the channels via SAP, but when I join the multicast group I don't receive anything. Could someone help me to troubleshoot this? Thanks in advance, Rens From ras at e-gerbil.net Mon May 31 14:24:21 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 31 May 2010 14:24:21 -0500 Subject: Junos Asymmetric Routing In-Reply-To: <20100530171614.B57F71CC2A@ptavv.es.net> References: <20100530171614.B57F71CC2A@ptavv.es.net> Message-ID: <20100531192420.GN1261@gerbil.cluepon.net> On Sun, May 30, 2010 at 10:16:14AM -0700, Kevin Oberman wrote: > > I remember a posting to this list back in the late 90s from Tony Li, > who knows a bit about BGP. He urged that multi-hop BGP never be used > and pointed out that it had not been intended for use except as a test > tool, not a production one and should have been stripped from IOS > before it was shipped. > > While there are a few good cases for using it, it is generally a bad, > bad idea. And this thread demonstrates that he had reason for the > warning I think you guys may be getting a tad carried away with the crusade against multihop BGP. The only thing you're really giving up when you use it is liveness detection, which as we all know BGP is actually pretty terrible at implementing anyways (hows that 180 sec IOS default working out for you?). There are much better mechanisms out there, like BFD, which could be used to provide better liveness detection to BGP through nexthop invalidation. I'm not saying everyone should run out and do all their peering over multihop EBGP without carefully considering a replacement for the liveness detection component, I just hate it when people get religious about such a simple concept for no good reason (well, other than Randy Bush getting to do his best Andy Rooney impersonation :P). Multihop BGP is no more evil than anything else we do with the Internet, and the fact that we've all managed to use it successfully for IBGP proves that it can work out just fine. There are some pretty interesting things you can accomplish as far as large scale traffic engineering if you can free yourself from the requirement of speaking EBGP with a directly connected neighbor, processed by whatever slow overpriced router CPU could be stuffed into that box. Again, I just hate to see the concepts dismissed out of hand because of some old BGP ideology about a problem that can be addressed any number of other ways. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)